RE: [Isms] charter proposal

["David B Harrington" <ietfdbh at comcast.net>]

> If all these questions do not have a well established clear answer,
> then I guess I misunderstood those who said that user->group mapping
> is something we have to do via AAA because it is widely used
> elsewhere.

Dave Nelson and I and the engineers at Enterasys started discussing
well over a year ago the need for vendor-specific management
attributes to provide granular user-to-policy mappings, and comparable
attributes are currently being discussed in RADEXT. We started our
discussions because there did not appear to be a set of RADIUS (or
other AAA protocol) attributes that could be used to provide such a
mapping for network management purposes at the desired level of
granularity for VACM groups or other network management access control
"named" policies. 

The only existing standard management attributes seem to be the remote
management Service-Types defined in RFC 2865 [RFC2865]. The available
services provide access to the interactive, ASCII-text, Command Line
Interface (CLI) of the managed entity, but do not do any user-to-group
mapping that I can see.

The only other option I've seen is the Congdon approach (RFC3580) for
having RADIUS identify user-to-VLAN mappings (the RADIUS server
typically indicates the desired VLAN by including tunnel attributes
within the Access-Accept), and then policy filters (i.e. the user is
allowed to use the SNMP protocol) can be applied to traffic on that
VLAN. I don't see how this could be effectively utilized for
user-to-VACM Group mappings.

I would be interested in hearing from vendors and operators and the
people arguing for this user-to-group-mapping feature just HOW they
currently use AAA to provide user-to-group mappings for network
management access control.

David Harrington
dbharrington at comcast.net




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