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

["Dave Nelson" <d.b.nelson at comcast.net>]

David B Harrington writes...

> "obtaining VACM authorization information via RADIUS" seems to 
> violate the modularity of the RFC3411 architecture.

Well, perhaps it violates the *aspirations* for modularity.  It's clear to
me that the access control decision is encapsulated entirely in the Access
Control Subsystem.  There is no ASI that allows for the ACS to obtain access
control guidance from any other subsystem.  We encountered that problem in
the work ISMS recently completed.  We created a new Transport Subsystem, and
a "cache" to allow the TS to communicate with the Security Subsystem without
modifying the existing ASIs.  It's pretty clear, in hind sight, that the
Security Subsystem design was never sufficiently modular to foresee the
possibility of the security mechanism being provided outside of that
subsystem.  Are you suggesting we use the same tactic here?  That we create
a new AAA Subsystem and a "cache" that allows it to communicate with the
ACS?

> There should be two steps.
> 1) obtaining authorization information via RADIUS, using "Remote
> Authentication Dial-In User Service (RADIUS) Authorization for Network
> Access Server (NAS) Management". The authorization information should
> be in an access model independent form, so it can be used with
> different access control models.

In other words, we create an AAA Subsystem.

> If user/groupname bindings can be installed dynamically, even though
> the policy (group access) is not provisioned, a new access control
> model or extension or an implementation might go get the values to
> dynamically provision the policy details automatically, rather than
> requiring operators to preconfigure the access rights for groups who
> may never actually need to manage the device.

Well, such a thing is possible, of course, but in the absence of a specific
mechanism, simply providing access by default raises real security concerns,
whether or not it is a matter of local policy.

> I think it is important to recognize that the SNMPv3 WG deliberately
> made the binding mechanism between a principal and the AC policy the
> responsibility of the specific AC model. Another AC model might use a
> different binding mechanism to bind the principal and the
> RADIUS-provisioned policy name.

By the same logic, as the binding mechanism *is* the responsibility of a
specific ACM, who's to say it cannot chose to use RADIUS?  What mandates
that the source of access control information be "modular"?  Nothing that I
see in the current definition of the ACS.

> RADIUS should supply a model-independent policy name, with no RADIUS
> knowledge of how the binding will occur within an AC model.

Having an AAA Subsystem might be a good thing.  My question is whether it is
a necessary thing, and whether it would be worth the extra time and effort.

> The VACM extension should apply that RADIUS-provisioned policy name to
> the authenticated identity using the VACM-specific username-to-groupname
> mapping table.

I think that's exactly what's been proposed.