Re: [Isms] comments on draft-nelson-isms-extended-vacm-00

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

Hi,

This particular binding between the info delivered from RADIUS to VACM
uses the "other" path:
implementation-dependent magic happens! The RADIUS management
attributes are stored in an implementation-dependent manner.

The RADIUS management attributes are principal-specific.
The principal-specific attributes can be found using
securitymodel/securityname/securitylevel.
isAccessAllowed already supports these fields.

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Monday, July 27, 2009 3:31 PM
> To: Dave Nelson
> Cc: isms at ietf.org
> Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00
> 
> On Mon, Jul 27, 2009 at 02:54:27PM +0200, Dave Nelson wrote:
>  
> > The transport populates tmStateReference.  It's up to the 
> extended VACM code
> > to do something with that information, i.e., populate MIB tables.
> 
> Except that the ASIs do not pass the tmStateReference to VACM.
>  
> > My concern is related to attempting to use extended VACM, 
> and thus the
> > tmStateRefrence, in the absence of a RADIUS-aware secure 
> transport.  The
> > only input to the VACM's ASI that would indicate whether 
> there is or is not
> > a RADIUS-aware transport at work would be the Security 
> Model selector.  Do
> > you see another way to accomplish this?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>