Re: [Isms] Next steps for Extended VACM?

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

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Dave Nelson
> Sent: Wednesday, July 29, 2009 3:34 PM
> To: isms at ietf.org
> Subject: [Isms] Next steps for Extended VACM?
> 
> I wanted to parrot back some thoughts I took away from 
> Monday's ISMS WG
> meeting on the direction for the RADIUS-aware Extended VACM 
> draft, to see if
> others remember the discussion the same way.  I also have 
> some questions.
> 
> (1) We don't want to specify _how_ the NAS moves the access policy
> information from the RADIUS client to the Extended VACM 
> "manager", just that
> it predictably and reliably do so, and that it pay heed to 
> session timeout
> limits, session disconnects, multiple sessions using the same 
> policy, and so
> forth.  Is that about right?

We do not want to see how.
We might want to specify what it must heed, and what behavior SHOULD
be followed.
I think this might be addressed in some EOP that precede the VACM EOM

> 
> (2) We don't want to suggest using the tmStateReference, even 
> though this
> seems a likely container which already has similarly 
> TM-session-scoped state
> information.
> 
The tmStateReference does not get passed to applications or ACM
subsystems, and we do not want to rewrite the ASIs to do so. It does
not seem to make much sense to explicitly store the info using a field
in tmStateReference if the EOP cannot look at that field because the
tmSateReference isn't passed to the ACM subsystem.

From RFC 5590: 
   The tmState might contain both long-term and short-term
information.
   The session information typically remains valid for the duration of
   the transport session, might be used for several messages, and
might
   be stored in a local configuration datastore.

It would seem appropriate to store the RADIUS attributes in the local
datastore associated with a session. 
The RADIUS-handling EOP will need access to RADIUS attributes at a
point where it has no access to tmStateReference.


> (3) We don't want the Extended VACM "manager" to modify the 
> existing VACM
> securityName-to-group MIB table, but rather to maintain a new 
> Extended VACM
> securityName-to-group MIB table.  This new table will look a 
> lot like the
> old table, but will have a couple extra columns, one for "can 
> RADIUS change
> this" and one that's an index of the corresponding row in the
existing
> table.
> 
> There are parts of this that I don't understand.  Should the new
table
> contain all entries from the old table, but with the "RADIUS 
> can't change
> this" flag set?

I think we want a MIB module to supplement the existing VACM MIB. The
supplementary table is indexed using the same index as the VACM table.

Since we are developing an extension to VACM, it can add rows and
delete rows from the existing VACM table.
We are developing RADIUS-aware VACM; I will refer to this extension in
my email as RACM.

All rows RACM creates/deletes MUST have an extra column that specifies
it was created by RACM (and which indicates that the row might be
deleted by RADIUS-aware VACM) and contains additional parameters, such
as lifetime. 

The RACM doc should specify the EOP for creating a row. If a row
exists for the user that was not created by the RACM, then RACM cannot
create it, and should increment an error counter. This will probably
be a RACM-specific error, and should be defined in the RACM-MIB. I
believe the creation process should create the row in the same table
that VACM currently uses. After RACM creates the row, normal VACM EOP
processing is done, with no required changes.

The RACM doc should specifiy the EOP for deleting a row. It does not
try to restore previous row contents; it just deletes the row it
created earlier. The rows should be deleted under certain conditions:
1) A SET changes RowStatus to delete
2) the session expires
3) a re-auth occurs occurs, forcing the deletion of the current row
with the same index, and replacement by creation of a new row with the
same index. 

All of this EOP happens outside the scope of VACM.
I didn't check whether there are any conditions in which VACM EOP adds
or deletes a row dynamically. I don't think there is. But if there is,
then RACM may need to delete the corresponding extra columns.

> 
> Internally, what should VACM do in following its EOP?  Look 
> only at the new
> table, with the old table being some form of "backing store"? 
>  Otherwise we
> need some sort of precedence relation between the two tables, 
> and I didn't
> hear that being advocated.
> 
> Do we need something to enable the VACM "extended mode"?

It would probably be good to allow the operator to enable/disable the
extension.
If the switch is set to disable, then any exsting RACM entries should
be deleted.
The SecCons should discuss implications of this.

> 
> Would it be useful to count the number to times that the VACM
"manger"
> attempted to add a new row but couldn't because of a name collision?

discussed aove.

> 
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>