Subject: RE: [Isms] securityName

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 1 Aug 2005 14:44:14 -0700

From: Blumenthal, Uri [mailto:[email-masked]] 
>> and my personal goal for
>> ISMS is for SNMP to directly leverage an existing authentication
>>system within our deployment.

>You seem to be missing the fact that another important 
>issue the WG is struggling with is mapping of whatever 
>credentials Security System returns, to ACM rules to 
>obtain access control decisions (without which 
>authentication is not very useful).

Actually, I covered that point in the email message that I sent to the
ISMS WG two minutes before the posting you have responded to.

To re-iterate, what concerns me about these emails is that I believe the
most foundational problem that the ISMS WG needs to resolve is "To what
extent will we continue to leverage SNMPv3 USM and VACM?" Some postings
presuppose that we won't change those interfaces. Others presuppose a
whole-scale replacement. Until consensus is formed on this fundamental
issue, I don't see how a long discussion of transport security is likely
to be very fruitful.

>> As I've said many times, SNMPv3 authentication is 
>>totally unlike all other authentication systems in our deployment

>No it is not. 

>At the moment it's much alike IPsec with manual 
>keying (which coincidentally is employed by some 
>applications and protocols).

I don't consider ad hoc "manual keying" to be an authentication system.
Since you apparently do, then I understand why you disagree with my
statement. 

Regardless, my personal aspirations for the ISMS WG to enable SNMP
leverage an existing, scalable enterprise authentication infrastructure
alternative such as Kerberos, PKI, or Radius.

--Eric

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

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 2 Aug 2005 10:21:40 +0200

A clarification, perhaps.

Tom Petch

----- Original Message -----
From: "Fleischman, Eric" <[email-masked]>
To: "Blumenthal, Uri" <[email-masked]>; "Tom Petch"
<[email-masked]>; "Kaushik Narayan" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 01, 2005 11:44 PM
Subject: RE: [Isms] securityName

to be very fruitful. <snip>

Eric,

I don't see any proposal to change USM; borrow ideas from it perhaps to create a
new xSM but USM must remain unaltered for those who are using it satisfactorily.
PDUs with the appropriate value of securityModel will continue to get fed into
it.

VACM is in two parts, the admin (securityName to Group mapping MIB module) and
the real thing, the rules defining what objects can have what done to them with
what security by what groups.  The latter is recognised as complex to administer
(in the isms charter) but is out of scope for isms; again, I see no proposal to
change that on this list.

SNMPv3 Architecture defines generic models, of eg Message Processing, Access
Control and Security and defines interfaces between these generic models in the
form of ASIs.  Where we got stuck six months ago and are still stuck is that a
literal adherence to these ASIs renders our task difficult or impossible,
depending on your subjective point of view, and this is the circle we continue
to circumnavigate.

The example of this that has attracted the most discussion is the securityName
to Group mapping.  My prejudice (which has some support) is that we must have
the option to get this information from a security server and not require the
administrators to have to do anything to maintain it in 'agents' to prevent a
compromise of security.  If you regard the generic Access Model AFI as
sacrosanct, this presents a problem because this mapping is embedded in the
Access Model and cannot be outsourced, regardless of whether the Access Model is
VACM or anoACM.  Juergen listed four options; for me, we have to do one, we
cannot leave things as they stand.  At the other end of the spectrum is a
reading of the charter that says this is VACM, therefore we cannot change it; to
me, that means winding up isms and starting xsms with a different charter.

But it isn't the only example and I am slightly puzzled why the others seem not
to get discussed.  dbh has raised them several times; most are a consequence of
moving integrity, authentication, encryption out of SNMP space and down into the
depths of transport.  The architecture did not allow for this either IMHO:-) so
again we need new AFIs or caches or Architecture or ...  (eg the xSM is the
place where encryption is done- well, no it is done in SSH, not in SNMP space at
all)

Hope this helps you.

Tom Petch