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

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

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.

dbh

> -----Original Message-----
> From: Dave Nelson [mailto:d.b.nelson at comcast.net] 
> Sent: Tuesday, June 09, 2009 11:23 PM
> To: 'David B Harrington'; 'Romascanu, Dan (Dan)'; 
> ops-dir at ietf.org; aaa-doctors at ietf.org; mib-doctors at ietf.org
> Cc: 'Juergen Schoenwaelder'; 'Pasi Eronen'
> Subject: RE: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS
> 
> 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.
> 
> 
>