Re: [Isms] Moving into some design/architecture issues ofExtendedVACM

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Dave Nelson" <d.b.nelson at comcast.net>
> To: <isms at ietf.org>
> Sent: Thursday, June 11, 2009 8:54 PM
> Subject: Re: [Isms] Moving into some design/architecture issues ofExtendedVACM
...
> > PS: Does the RADIUS client have the "rights" to modify any existing
> >     writable matching table entries? Will it revert the changes when
> >     the session dies?
> 
> I think it needs to revert, yes.
> 
> While we talk loosely of the RADIUS authorization information being used to
> update the VACM MIB Module in the same sense that the SNMP engine would do
> in response to an SNMP SET, we may be taking this too literally.  I think
> that the RADIUS information kept by the VACM Extension should be transient,
> with a lifetime limited to that of the secure transport session.
...

Repeating myself: this would interact badly with security policy updates.
It is much safer for changes to vacmGroupName in a vacmSecurityToGroupEntry
to behave just like they would if they had been set.  If they can "revert", then an entry
which appeared to be up-to-date when inspected by a security administrator could
silently become not-up-to-date because a secure transport session ended.
This would make a hash  of security policy configuration management.

Simple really is preferable here.  It's less work for the implementor,
both of management applications and in the guts of the SNMP implementation.
It's less work for the security administrator.  And it would be a lot simpler
for this WG.

Randy