Subject: [Isms] Next steps for Extended VACM?

From: "Dave Nelson" <[email-masked]>
Date: Wed, 29 Jul 2009 09:34:00 -0400

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?

(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.

(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?

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"?

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?

---

From: "David Harrington" <[email-masked]>
Date: Wed, 29 Jul 2009 17:27:35 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Nelson
> Sent: Wednesday, July 29, 2009 3:34 PM
> To: [email-masked]
> Subject: [Isms] Next steps for Extended VACM?
> 

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

> seems a likely container which already has similarly 
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.

> contain all entries from the old table, but with the "RADIUS 

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.

> 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.

> attempted to add a new row but couldn't because of a name collision?

discussed aove.

> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Jul 2009 19:10:38 +0200

> forth.  Is that about right?

I think this is fair statement.
 
> seems a likely container which already has similarly TM-session-scoped state

Storing something in the tmStateReference has no value since it is
never passed to the ACM and it is not needed since we do (1).

> this" and one that's an index of the corresponding row in the existing

Not quite right. The VACM security to group mapping table remains the
only table that does security to group mappings. A device supporting
the radius extension will provide an augmenting table indicating which
entries in the VACM security to group mapping table belong to the
RADIUS client - and if needed providing any additional information we
need to make visible.

> attempted to add a new row but couldn't because of a name collision?

It is common practice to have counters when the processing in elements
of procedures stops due to such error situation. So I guess the answer
is yes.

/js (writing as technical contributor)

-- 
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/>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 29 Jul 2009 13:26:26 -0400

Juergen Schoenwaelder writes...

> > (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.
> 

Well, since (1) -- elided in this reply -- is completely unspecified, it
*could* be implemented by passing a pointer to tmStateReference.  How we
pass information is opaque to the document, so one pointer is just as good
as another, right?  I'm going to think about whether it might be useful for
the Extended VACM "manager" to have access to the tmStateRefeence for other
reasons.  That fact that it isn't passed to VACM in an ASI doesn't, IMHO,
prevent it from being passed in an implementation-dependent fashion.  After
all, a "sneak path" is a "sneak path".  :-)

> > (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.
> 

Ah, I see.  An augmenting table, without use of the AUGMENTS keyword, using
a common indexing scheme to tie back to the original table.  Gotcha.

I'm sure a first draft of the SMI will bring out more specific comments...

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 29 Jul 2009 13:45:27 -0400

David Harrington writes...

> 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 EOP.

SHOULD or MUST?

Since is this is an SNMP document, I think that specifying Elements of
Procedure, and generally structuring is as much like other SNMP documents as
the authors may be capable of is a reasonable suggestion. 

> datastore associated with a session.

And exactly how does the "local data-store associated with the session"
differ from "tmStateReference"?  A rose by any other name...

> point where it has no access to tmStateReference.

Unless, of course, the implementation-dependent information passing method
is simply to pass a pointer to the tmStateReference.  :-)

> We are developing RADIUS-aware VACM; I will refer to this extension in

Hmmm.  I'm not too fond of that nomenclature, so I won't adopt it.

> processing is done, with no required changes.

Right.

> with the same index, and replacement by creation of a new row with the

Sounds like a good start.

> All of this EOP happens outside the scope of VACM.

It happens in what I've been calling the VACM Extension or Extended VACM
"manager" (in reference to its role in "managing" the VACM MIB table(s).  I
think we agree on where all this happens, but perhaps not yet on the best
name for it.

> then RACM may need to delete the corresponding extra columns.

OK.