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

["Dave Nelson" <d.b.nelson at comcast.net>]

Juergen Schoenwaelder writes...

> here are a few comments (posted as a technical contributor) on the
> RADIUS / VACM document:

I think you have nicely summarized the open technical issues in the -00
draft.

> A: How specific should the document refer to the TSM? Should we try to
>    phrase things such that things still work in case we replace TSM
>    with something else?

I think that might be nice to do.  My one concern is that the mechanism of
this document is dependent upon the tmStateReference.  While some
yet-to-be-written security model might also work with a secure transport
model, allowing the VACM extensions in this document to be used without a
RADIUS-aware transport model seems to open up a security issue, or at the
very least an undefined mode of operation. 
 
> B: I suggest that we do not overwrite existing table entries.

There seems to be some support for that in the list discussions to date.
What we haven't determined is how additional entries are to be structured
and what precedence they have with respect to the existing entries.  I think
some further discussion of this issue is needed.

> C: The aging I think needs more work so that we can handle situations
>    where user joe logs into an agent at t1 and a second time at t2 and
>    then the first session ends at t3. The second session should not
>    loose the group name mapping entry in this case. So implementations
>    somehow need to do some reference counting.

Yes.

> D: I am not sure why the USM discussion in the security considerations
>    section is needed.

Well, if VACM entries are configured so as to seriously restrict access, and
we are relying on dynamic VACM group bindings, what happens if the network
is down and we are using the USM "back door" credentials for access?  Don't
we need corresponding VACM configuration?  This more of an operational
consideration, than a security consideration, however.

> E: Is there a need for a MIB module exposing an augmentation of the
>    VACM table with session/timeout information? Such a table would
>    allow a management application that is aware of this extension to
>    detect where some name to group mapping entries are originating
>    from. But on the other hand, we do not generally indicate where
>    some config snippet is originating from in SNMP land...

The authors expected that the draft would eventually need to specify a MIB
module for this and other items, based on the flow of list discussion to
date, but the ideas hadn't sufficiently gelled at the time -00 was written
to allow inclusion of that MIB module.

> Though we will have time to discuss things later today in the WG
> meeting, I brought this to the list since not all contributors and in
> particular the document editors make it to Stockholm.

Yes.  Continued discussion of these items on the list will help us prepare
the next draft revision.  Thanks!