Re: [Isms] securityName

["Tom Petch" <nwnetworks at dial.pipex.com>]

A clarification, perhaps.

Tom Petch

----- Original Message -----
From: "Fleischman, Eric" <eric.fleischman at boeing.com>
To: "Blumenthal, Uri" <uri.blumenthal at intel.com>; "Tom Petch"
<nwnetworks at dial.pipex.com>; "Kaushik Narayan" <kaushik at cisco.com>
Cc: <isms at ietf.org>
Sent: Monday, August 01, 2005 11:44 PM
Subject: RE: [Isms] securityName


From: Blumenthal, Uri [mailto:uri.blumenthal at intel.com]
>> 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. <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


_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms