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

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 18 Apr 2005 13:39:48 -0400

I was saying that CURRENTLY *by conscious design* SNMP entities do not
have credentials of its own, and operate exclusively on behalf of users
who request operations.

It is OK to create a different design, that awards an SNMP engine with
its own *secure* identity - binding some kind of a key to snmpEngineID
(just RSA/DSA PK pair, SSH key, whatever). 

This addition will not remove the need to either create a list of
authorized users for each entity, or to define how authorization will be
done online in a reasonable and practical way (or both :-).

-----Original Message-----
From: Fleischman, Eric [mailto:[email-masked]] 
Sent: Monday, April 18, 2005 10:34 AM
To: Blumenthal, Uri; Sam Hartman
Cc: [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

Uri,

I am not sure that I am correctly understanding the intent of your
posting. Are you stating that because the USM SNMP engine doesn't have
its own credentials, that ISMS shouldn't as well? Or perhaps you only
want to warn us that providing such credentials carries with it
additional overhead? Or perhaps you are intending something else? 

For example, let's pretend for the moment that the WG is interested in
leveraging some of the concepts found in Eric Rescorla's DTLS ID
(http://www.ietf.org/internet-drafts/draft-rescorla-dtls-04.txt). In
this (pretend) example, are you arguing against assigning a PKI identity
to the SNMP engine in order to permit mutual authentication?

--Eric

>> No, I'm arguing an SNMP engine will know what credentials *it* *has*,

>> not *its users have*.  I.E. an SNMP engine will know what key it 
>> shares with a RADIUS server...

>An SNMP engine has *NO* credentials of its own, period. Never had. 
>All the access is done on behalf of *users* by other engines.

>Yes it would make cryptography easier if engines had some credentials 
>(i.e. was associated with some ID that possessed long-term keys, etc). 
>But it would introduce an *additional* burden of provisioning the SNMP 
>engines, and mapping *their* identities onto existing infrastructure 
>(RADIUS database? SSH? /etc/password?).

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Apr 2005 14:10:14 -0400

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

    Blumenthal,> I was saying that CURRENTLY *by conscious design*
    Blumenthal,> SNMP entities do not have credentials of its own, and
    Blumenthal,> operate exclusively on behalf of users who request
    Blumenthal,> operations.

Is the following a technically accurate restatement of the above:

Currently, by design, USM SNMP engines share a credential for each
user?

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 Apr 2005 12:19:24 -0700

Hi -

> From: "Sam Hartman" <[email-masked]>
> To: "Blumenthal, Uri" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, April 18, 2005 11:10 AM
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
>

> Currently, by design, USM SNMP engines share a credential for each
...

Key localization and proxy would require a lot of qualifiers on the
restatement before I'd be willing to buy into it.  For example, suppose
Engine A and Engine B are configured so that user X of a command
generator using engine A can do a "get" from a command responder
using Engine B.  As good as that is, it does *NOT* mean that user X
can employ a notification generator using engine B to send information
back to A.  The localized keys to authenticate X at A and X at B are
different, and would be different entries in the usm user table.  That's
why the table has the indexes that it does.

Randy