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

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 17 Oct 2005 11:22:00 -0400

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:[email-masked]] 
Sent: Monday, October 17, 2005 2:22 AM
To: Blumenthal, Uri
Cc: [email-masked]
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

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

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 17 Oct 2005 12:36:48 -0700 (PDT)

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.

Regards,
/david t. perkins

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Oct 2005 18:18:09 -0400

>>>>> "Blumenthal," == Blumenthal, Uri <[email-masked]> writes:

    Blumenthal,> This implies that different engines should have
    Blumenthal,> different public keys.  Otherwise from security point
    Blumenthal,> of view only one SNMP engine will be allowed on one
    Blumenthal,> SSH host.

I don't follow because as you point out:

    Blumenthal,> An alternative: all the security will depend on "SSH
    Blumenthal,> layer" - something responsible for all the SSH
    Blumenthal,> communications of this host, and multiplexing traffic
    Blumenthal,> between various services that use SSH for protection.

right.  In this model, you need a name to address PDUs to the snmp
engines, but the security binding is handled at the ssh layer.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2005 05:23:53 -0400

>>>>> "David" == David T Perkins <[email-masked]> writes:

    David>  3) In SSH, a server is identified by a transport address
    David> (SSH experts jump in if I've used the incorrect
    David> terminology) 

I'm not sure that the ssh protocol documents specify how servers are
named.  I think this may be a local matter.  It sounds from the
architecture document like servers are typically named by hostname,
but many implementations also name servers by IP address.

I'd appreciate a more specific citation to a claim that servers are
identified by transport address.

    David> and is authenticated via use of a public key
    David> pair (RSA or DSA).  (from draft-ietf-secsh-transport-24.txt
    David> and draft-ietf-secsh-architecture-22.txt)

And is often authenticated by a public key.  There is already another
standards track mechanism for authenticating servers:
draft-ietf-secsh-gssapi-keyex, which like the core ssh documents is
waiting in the rfc-editor queue.

Other mechanisms are possible.

>From this I conclude that anything in SSHSM that depends on the
particular way servers are authenticated will limit the applicability
of SSHSM.  It may be appropriate (and possibly even necessary) to
define ways of managing certain information based on particular
authentication methods.  It is desirable to avoid depending on
particular authentication methods and is probably desirable to be
conservative in accepting authentication method information that may
not be available from some authentication methods into architectural
elements in SSHSM or TMSM.

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

A client is authenticated by zero or more methods.  Method are in fact
named.

--Sam