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

["Blumenthal, Uri" <uri.blumenthal at intel.com>]

First, it is a good practice for any discernable entity to have unique
cryptographic material (keys).
Second, if SNMP manager is OK with ascertaining only the host to where
it directs its commands - then no need for separate keys. If however the
manager wants to make sure that he talks with a certain *agent* - must
have separate keys.

> Reviewing:...................
>  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)

Because SSH protocol and implementation offers access to a *host*, not
to any one particular application running on that host. It may or may
not be OK for SNMP. 

>  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.
     
Of course, especially since this mapping is not a bijection (more than
one agent on one host or IP address).

>  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. 

In USM, SNMP engines don't have their own credentials and thus only user
identity truly matters. Engine ID is used in USM cryptography mostly for
key localization. Agent authentication is implicit (if the key localized
to a given agent works - then it must be the correct agent). SSH
protocol requires defined credentials on both ends: user has his
credentials, and the host has its key.

> 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.

No. I am suggesting that if there's a need to differentiate between one
SNMP-SSH agent and other SSH "entities" on a target host - it implies
the need for SNMP-SSH agent to have its own public key pair, as if it
was a separate "host". And whatever the identity of SNMP "agent" is - it
would have to be bound to the public key used to ascertain its identity.
Nowhere did I imply (nor said) that the key itself (or its fingerprint)
should be used as/for identity (nor do I really care).

> (FYI, a finger print is a MD5 hash of the public key, and
> is 16 octets long)

Wow! Thanks for letting me know.  :-)

> 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.

What seems problematic to me is that people hope to use existing SSH
installations (one key pair per host), without providing extra keys and
mechanisms to deal with them. 

> 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.

Difference of engine ID necessarily implies difference in keying
material it uses.

> 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. 

Yes, but my concern is SNMP application(s) like 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.

Command generator probably does need an engine ID - but let's confine
ourselves to the server case for now. How do you plan to authenticate an
ISMS SNMP agent?

> Hope this helps.

Sorry - not much.


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:dperkins at dsperkins.com] 
> Sent: Monday, October 17, 2005 2:22 AM
> To: Blumenthal, Uri
> Cc: isms at ietf.org
> 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
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms