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

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

David Harrington writes...

> I think it is fine for RADIUS to provide a user/policy,
> and for VACM to translate...

Are we contemplating something other than the "identity transform" here?  If
not, why use the word "translate"?  If so, how is domain-wide correctness
guaranteed?

> ... that into user/groupname even if there are no entries
> specifying the views and permissions for the groupname. The
> isAccessAllowed() will simply say "no" for any  group for which no
> views/permissions are defined.

Yes, I see that.  As the default for a new group entry is no access, there
is no security risk.  OTOH, what's the operational advantage of populating
the tables with useless / erroneous group names?  Conversely, what's the
disadvantage of simply ignoring any non-existing group names, and dismissing
them as a mis-configuration?  You many, of course, want a counter of these
someplace.

> The WG will need to deal with mid-session changes to user/policy
> assignments and/or policy configuration changes.

This can be tricky.  One possible solution is for a "significant' have of
policy definition in the NAS to trigger a RADIUS re-authentication request.

> IIRC, RADIUS servers can specify "interrupts" - hey, client, I
> need to revoke the current access-accept and force you to ask me
> again, because some things have changed.

You're thinking of Dynamic RADIUS, which allows for changes of
authorization, initiated by the RADIUS server.  Of course, the RADIUS server
isn't likely to be aware of changes in MIB values on the NAS.