RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID?

["David T. Perkins" <[e-mail]>]

HI,

Let's take a step and look at this with a view that includes
support for proxies, and compare with USM.


Reviewing:
 1) management info (from RFC 3411, section 3.3) is identified
     by items:
     a) an engineID (which needs to be unique only within a
               a management domain). In SNMPv3 requests,
               this is the value of field contextEngineID
     b) context value, which in SNMPv3 requests is the
               value of field contextName.
     c) object type (an OID value), which is the prefix
               of each variable (a variable is an OID value)
               (see RFC 3416, section 2.1)
     d) object index (an OID fragment), which is the
               suffix of each variable
 2) the value of field contextEngineID determines if a
     request is to be processed "locally" by the SNMP
     entity that recieved it or forwarded to another
     SNMP entity for processing. (from RFC 3413, section 1.5)

 3) In SSH, a server is identified by a transport address
     (SSH experts jump in if I've used the incorrect terminology)
     and is authenticated via use of a public key pair (RSA or DSA).
     (from draft-ietf-secsh-transport-24.txt and
     draft-ietf-secsh-architecture-22.txt)

 4) In SSH, a client is identified by a "user name" (from
     draft-ietf-secsh-userauth-27.txt, section 5) and
     is authenticated via a mechanism identified by 
     a "method name". The typical ones are "publickey"
     and "password" (see draft-ietf-secsh-assignednumbers-12.txt,
     section 4.8)

 5) There is presently, no standard "interchange" format that is
     used by "SNMP management apps" to map between "SNMP
     agent's" transport address and an SNMP engineID.
     
 6) In SNMPv3/USM, identities are specified by the
     pair engineID and user name. (RFC 3414, section 1.5.2)
     In SNMPv3/USM message exchange, the field
     msgSecurityParameters in SNMPv3 messages is
     encoded with the format as specified by 
     UsmSecurityParameters (RFC 3414, section 2.4)
     USM specifies which SNMP engineID is to be
     used in message exchange between the two
     SNMP entities with the two different engineIDs. 

What it appears that you are proposing is to make the
public key (or maybe just the "finger print" of the
public key) from an SSH server's key pair, an identity.
(FYI, a finger print is a MD5 hash of the public key, and
is 16 octets long)

This seems incorrect/problematic due to:
1) the key pair used to verify an SSH server can be
    changed without changing the identity of the server
2) there is no infrastructure for starting from
    a public key (or finger print) and mapping
    to a transport address.

Note that I agree with you that just like SNMPv3/USM,
that in SNMPv3/ISMS when there are multiple SNMP entities
running on a system that each must use a unique transport
address. And the SNMP engineID that each is using
should be different.

Also note that I pointed out several times in the
past that when an SNMP entity is running certain
"SNMP applications" (such as a command generator (that is
an SNMP management application)) that the value of the
engineID is NOT made known via SNMP operations, and thus
NEVER needs to be created!
This works out well in use of SSH when the SSH client
is a command generator and the SSH server is a command
responder. 

If one gets strict and believes that a command
generator must have an engineID, then please remember
in an SSH world, the client side is identified
by a user name and method specific credentials
which may not be a public key.

Hope this helps.

On Mon, 17 Oct 2005, Blumenthal, Uri wrote:
> SSH purpose (besides establishing a secure pipe) is to authenticate the
> user to the host (various mechanisms available) and to prove host's
> identity to the user (by host's PK).
> 
> Since there may be more than one SNMP engine on one host, and they
> (conceivably) may have different "access rights" etc, ability to
> differentiate between them makes sense.
> 
> This implies that different engines should have different public keys.
> Otherwise from security point of view only one SNMP engine will be
> allowed on one SSH host.
> 
> An alternative: all the security will depend on "SSH layer" - something
> responsible for all the SSH communications of this host, and
> multiplexing traffic between various services that use SSH for
> protection.
> 
> 
> -----Original Message-----
> From: David T. Perkins [mailto:[e-mail]] 
> Sent: Monday, October 17, 2005 2:22 AM
> To: Blumenthal, Uri
> Cc: [e-mail]
> Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and
> SNMPengineID?
> 
> HI,
> 
> I don't follow. Would you fill in the details. Part of the reason
> that I don't follow is that I see no relationship between
> the SSH identifies and their keys and SNMP engineIDs.
> In USM, an identity is the pair (engineID (which is called
> the security engineID) and user name). SSH has no notion
> of SNMP engineIDs.
> 
> On Sun, 16 Oct 2005, Blumenthal, Uri wrote:
> 
> >     David> #8: Do we need a mapping between the SSH key (or other SSH
> >     David> engine identifier) and SNMP engineID? What happens if an
> >     David> agent "spoofs" another engineID, and an NMS perfoms a SET
> >     David> of sensitive parameters to the agent?
> > 
> > > I cannot answer this question because I don't have enough
> > > understanding of SNMP.  I can answer a related question.
> > >
> > > You must authenticate each party  back to some name the user
> provided.
> > 
> > IMHO there must be a mapping between ISMS-usable SSH keys and related
> > SNMP engine IDs.
> > 
> 
> Regards,
> /david t. perkins

Regards,
/david t. perkins


_______________________________________________
Isms mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/isms