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

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Tue, Jun 16, 2009 at 02:43:14AM +0200, Randy Presuhn wrote:
> 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,

you have the same probem if I as the security administrator change the
VACM table and then RADIUS comes in and simply changes what I have
carefully configured. I tend to agree with Dave Nelson that having a
single table modified by two different entities is likely asking for
trouble. You might argue that the problem is really the conflict
between RADIUS policy and the security administrator's policy. My
counter argument to that is that if both would be in fine synchrony,
we would not need the RADIUS interface in the first place.

/js

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