Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 14 Apr 2005 12:35:15 -0400

> As I understand it, I think we're trying to allow SNMP engines to
> communicate securely using existing credentials in an existing
> infrastructure. 

Absolutely yes.

> As such, by the time we're done, it seems reasonable to expect that
> SNMP engines using ISMS will clearly know what set of credentials
> they are using. 

This assumption does not hold. It is one of the problem aspects.
 
If SNMP engine knew what credentials it had, it would be much easier to
design and drop-in a "convertor" that authenticates the exchange for a
short-term key using those identities. As it is, SNMP engines operate on
behalf and with the credentials of their users. Even the user list has
to be explicitly configured in (SNMP doesn't automatically assume that
if there's /etc/password file - then every entry describes a legitimate
SNMP user). 

It is one source of configuration inconvenience: somebody has to
explicitly configure SNMP entity and tell it what users it should
recognize and what credentials they will use.

Another configuration issue is to map each user onto Access Control
group. 

All these are actually trivial - but constitute extra efforts and don't
happen automatically (and often require extra code which isn't there
now).  Some vendors sell configuration tools that automate the above
tasks.

And what became my standard "broken needle" in this WG - the absense of
session concept and therefore absense of two important things: (a)
separation between (and presence of both) long-term and short-term
secrets, and (b) absense of reasonable life-time of short-term secrets.

Originally SNMP assumption was - "SNMP agent knows nothing. Management
station takes care of all of the above issues, re-keys when necessary,
etc." This logic doesn't work any more.

> Associated with all the IETF security credentials I'm
> familiar with is an authenticated identity.  Sometimes this identity
> is implicit or tautological (for example the identity of a raw public
> key is often that key), but it does exist.

Identities on the hosts exist. But the automatic conversion and mapping
between them and SNMP user list - does not. Something like just
installing SSH package and having it immediately figure that there is
/etc/password file, and every entry of it defines an SSH user with
password as initial credentials. No access control or mapping issues.

It is not scientifically difficult to map from any of the existing
identities to SNMP identities, or port those identities to SNMP. The
difficulty is creating those mappings. Some want /etc/password, some -
RADIUS (RADIUS must confirm the user and give session key), some want
Kerberos or Active Directory... Wes is probably the closest in
addressing users' wishes - the issus is how to analyze (from security
point of view) the monster that must emerge to satisfy all the
requirements.

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Apr 2005 12:55:30 -0400

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

    >> As I understand it, I think we're trying to allow SNMP engines
    >> to communicate securely using existing credentials in an
    >> existing infrastructure.

    Blumenthal,> Absolutely yes.

    >> As such, by the time we're done, it seems reasonable to expect
    >> that SNMP engines using ISMS will clearly know what set of
    >> credentials they are using.

    Blumenthal,> This assumption does not hold. It is one of the
    Blumenthal,> problem aspects.
 
    Blumenthal,> If SNMP engine knew what credentials it had, it would
    Blumenthal,> be much easier to design and drop-in a "convertor"
    Blumenthal,> that authenticates the exchange for a short-term key
    Blumenthal,> using those identities. As it is, SNMP engines
    Blumenthal,> operate on behalf and with the credentials of their
    Blumenthal,> users. Even the user list has to be explicitly
    Blumenthal,> configured in (SNMP doesn't automatically assume that
    Blumenthal,> if there's /etc/password file - then every entry
    Blumenthal,> describes a legitimate SNMP user).

No, I'm arguing an SNMP engine will know what credentials *it* *hash*,
not *its users have*.  I.E. an SNMP engine will know what key it
shares with a RADIUS server, what TLS certificate it has, what SSH key
it has, or what Kerberos key it has.  Other SNMP engines (managers)
will know what username/password they have, what Kerberos ticket they
have, what key they share with RADIUS, what certificate they have.

I do not think the problem before us can be solved without either
allowing for man-in-the-middle attacks or requiring that an SNMP
engine have some credential. Either solution seems to allow sessions
be established for informs.