Re: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS

[Jeffrey Hutzelman <jhutz at cmu.edu>]

--On Wednesday, June 10, 2009 05:53:59 AM -0400 David B Harrington 
<dbharrington at comcast.net> wrote:

> Hi,
>
> Randy Presuhn described it best. The simplest way to approach this
> problem is to have the RADIUS authorization attributes simply there in
> the background. Screw the ASIs; we want to finish this within five
> years. A RADIUS-aware ACM can simply utilize the RADIUS attributes.
>
> My concern is maintaining the modularity that was deliberately created
> by the SNMPv3 WG to allow modular extensibility. This is all about
> separating who knows what. RADIUS knows about authorization
> attributes, not about VACM.
>
> When the charter says that RADIUS provides VACM username-to-groupname
> dynamic provisioning, that is wrong. RADIUS provides a policy name.
> How that translates to VACM access control is dependent on the
> (extended) VACM access control model. That permits additional access
> control models to also utilize the RADIUS attributes.


I thought the plan was to charter work specifically to define a way for 
_VACM_ to get provisioning data from _RADIUS_.  That is...

(1) This is an extension to VACM which describes one way it can interact
   with something outside the scope of SNMP to do its job.  It doesn't
   communicate with the rest of SNMP (except to use information that
   any ACM already has at its disposal) and it applies only to VACM.

(2) By the same token, it relates specifically to RADIUS, via the
   just-completed NAS management document, and not to any arbitrary
   AAA protocol.

This really shouldn't create a new "AAA subsystem" abstraction for 
connecting any ACM to any AAA.  If we did that, we'd _still_ have to
define the interactions between that new abstraction and each of VACM
and RADIUS, and we really don't know enough about the possibilities
to construct an abstraction for any case other than (VACM->RADIUS).

-- Jeff