Subject: Re: [Isms] securityName

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Jul 2005 21:12:28 -0700

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 26, 2005 8:13 PM
> Subject: RE: [Isms] securityName
...
> I have serious concerns with the EUSM dynamic population of the
> vacmSecurityToGroupTable.

EUSM doesn't populate the vacmSecurityToGroupTable.
It provides a way for the mapping information for an authenticated
user to be delivered from the authentication infrastructure, avoiding
the need to pre-configure vacmSecurityToGroupTable for all users.

Any solution that doesn't address this part of the problem will require
that SNMP management systems touch every managed system whenever
a user is created or deleted.  (The former requirement is stronger than the
latter, but the latter is a matter of configuration management sanity.)
I would argue that, from an operational perspective, as long as SNMP
management infrastructure has to touch vacmSecurityToGroupTable
for every user add/delete, ISMS doesn't really make things any more
manageable.

> The SNMPv3 architecture separates authentication from access control
> so that subsystems can be updated with new models independent of other
> subsystems. We need to make a decision about which subsystem defines
> the user-to-group mappings or the architectural modularity goes to
> hell. The SNMPv3 WG decided this should be done in the access control
> subsystem.

The user/group mapping is an edge case.  Although we put it in VACM
(because it was an optimization to reduce the size of access
control configuration) one could argue that this optimization (having a
security name for auditing purposes, but mapping it to a role for
purposes of allowing optimization of access control configuration size)
is *relatively* security model neutral.

Requiring the authentication infrastructure to tickle managed systems
with VACM updates whenever a new user is added or deleted is not
a very attractive integration, in my opinion, and would scale far less well
than delivering the information when needed, i.e., when the user is
authenticated.

> As I recall, the consensus of the SNMPv3 WG was that not all access
> control models would necessarily support a security-to-group mapping.

Another way of looking at it is that in those other models we considered.
each conceptual group would have exactly one user (snmpv2p) or
a user might belong to multiple groups (Unix-like).  Both could be
supported by an EUSM-like way of delivering the information,
regardless of architectural purity.

> VACM represented one approach to access control, but there were
> supporters of other approaches as well, especially for purposes of
> leveraging existing access control mechanisms. We need to be careful
> we don't limit future access control models to accommodate the VACM
> approach in this case.

Agree.  But it's also important that ISMS actually addresses the integration
problem.  Propagation of full VACM configuration is out of scope, and I
think this is ok.  But not addressing the user/group mapping leaves us
with a "solution" that is operationally only marginally better than what we
have today:  it makes key changes tidier, but doesn't simplify user add/delete.

> The EUSM approach of dynamically configuring the
> vacmSecurityToGroupTable  violates the SNMPv3 architecture goals,

It didn't actually create / delete table entries, if I recall correctly.
Whether it should have is a separate discussion; I can see pros
and cons both ways.  We were careful in the evaluation to put
it in terms of conveying the mappings, and not nail down whether
those mappings would actually show up in the table, since this
raises all sorts of interesting interaction questions.

> since another security model (such as USM) would not necessarily do
> this dynamic configuration of VACM tables, and an access control model
> that doesn't use the vacmSecurityToGroupTable cannot work with the
> EUSM proposal.

I don't see how this follows.  If a security model uses only the authenticated
user name, then any group mappings delivered by the authentication service
can be ignored.

> If the consensus of this WG (and the rest of the IETF, of course) is
> that it does make sense to require all security models to also
> generate a securityGroupName, then maybe we should define a
> user-to-group mapping table as part of the security (authentication)
> subsystem rather than as part of the access control subsystem, and
> modify USM and VACM to shift the vacmSecurityToGroupTable
> functionality into the USM security model, and change the ASIs to pass
> a groupname.
...

I could see making the user/group mapping part of the security model,
but I could also see making it part of the "glue" between them, since
to some extent it's security model and access control model neutral.
But I don't think such changes are *necessary*.  All that's happening
is that three related pieces of information are coming from the authentication
server rather than two.

Randy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2005 09:21:06 +0200

> for every user add/delete, ISMS doesn't really make things any more

I believe the mapping of a user identity to the group determines this
user identities' access rights. Hence I consider this mapping being
part of VACM access control. In fact, the whole group concept is a
VACM concept and does not exist as an architectural concept visible
outside this specific access control model. Correct me if I am wrong.

The objective of SNMP over TLS/SSH is to leverage existing on-the-wire
security protocols with the main goal to reuse keying material /
mechanisms that is/are already known by the device. Sure, this does
not address the access control configuration issue and how you can get
access control information from a central repository, e.g. an AAA
server - I think this is not a bug.

My understanding of the charter is that we were asked to solve the
first part of the problem and if we manage to get agreement in a
timely fashion (!), we might do followup work to address the other
part of the problem space.

Note that I would love to have a mechanism to define full ACM configs
in a centralized fashion for all the boxes I worry about. Perhaps we
have to simply agree that this is just device configuration like any
other access control lists and hope that NETCONF provides the tools to
solve this. (All VACM configurations I have ever created for
operational purposes were actually written either by editing config
files on hosts or by using CLI commands.)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany