Re: [Isms] Moving into some design/architecture issuesofExtendedVACM

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

Hi,

I suggest the RADIUS attributes be stored and associated with a
RADIUS-authorized session. When the session goes down, the attributes
and the session authorization are deleted. The VACM-RADIUS extension
should check whether RADIUS authorization attributes are present and
valid or not, much as SSHTM checks whether we have a present-and-valid
tmStateRefreence. If the session is closed there will be no
authorization attributes available. 

Representing this in a MIB or an ASI construct helps to standardize
this, including the terminology, so we can better check whether
independent implementations will have interoperable assumptions. This
also makes the job for the WG harder. But this may also make the IESG
more comfortable that we have an interoperable solution. An operators
might want to be able to see what is happening regarding RADIUS
authorizations.

I think limiting the MIB-ified part to the VACM user-to-group table,
and augmenting the table using standard MIB things, like lifetime
objects and RowStatus to indicate/manipulate the entries, as Juergen
suggested, could be fairly simple. We might want some type of "void
pointer" in the table to the implementation-dependent
session-associated authorization information. 

We already have a "void pointer" tmSessionID in the tmStateReference
with which the attributes could be associated in an
implementation-dependent manner. 

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Dave Nelson
> Sent: Tuesday, June 16, 2009 9:46 AM
> To: isms at ietf.org
> Subject: Re: [Isms] Moving into some design/architecture 
> issuesofExtendedVACM
> 
> David Harrington writes...
> 
> > I think we actually have consensus about persistence.
> > 
> > I think everybody expects that the user-to-group mapping should go
> > away when the radius-authorized session ends; ...
> 
> Excellent!
> 
> > ... we just need to figure how to do that without redesigning
> > snmpv3 and the rfc3411 architecture.
> 
> I eagerly await suggestions, as I have (temporarily) run out of
ideas.
> 
> 
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>