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

["David Harrington" <ietfdbh at comcast.net>]

Hi,

I think Juergen's suggestion of a precedence table in a MIB might make
sense. That keeps the system SNMP-manageable, allows the administrator
the choice of precedence, and allows us to have a separate MIB module
and associated elements of procedure for RADIUS ACM support.
Effectively, we can design a new RADIUS ACM, and use the precedence
table as the selector mechanism. 

I assume the ACM precedence table must be preconfigured, just as the
policies are. I do think there will be plenty of problems forcing one
ACM to always have precedence, and I can envision admins wanting one
system to have precedence for some users (e.g., the IT staff, in case
of the need to override RADIUS), while other users should always be
controlled under the RADIUS approach. But setting precedence by user
would require preconfiguration of the users. ACM Precedence probably
needs to be by group. Setting precedence might be able to be added for
a user/group mapping by adding an ACM selector to the RADIUS
attributes. That might not work for the it-group, though. I think the
precedence table needs to be similar to a capabilities negotiation; an
admin can configure the table to say "RADIUS takes precedence for this
group if it is available; otherwise USM MAY be used by this group."
For non-emergency uses, RADIUS could specify the precedece order for a
group, but somehow, the security admin needs to be able to say that
"this group needs authorization to override a RADIUS rejection".

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, June 16, 2009 1:07 AM
> To: Randy Presuhn
> Cc: isms at ietf.org
> Subject: Re: [Isms] Moving into some design / architecture 
> issues ofExtendedVACM
> 
> On Tue, Jun 16, 2009 at 02:53:57AM +0200, Randy Presuhn wrote:
> > 
> > I think it has a real problem from the perspective of 
> security configuration
> > management.  A security administrator should be able to find out
how
> > a system's security policy is configured, regardless of 
> whether RADIUS
> > is in use.  This means the "shadow" table would need to be 
> visible to
> > management.  However, the security administrator should also be
able
> > to configure and update the "real" VACM configuration whether
RADIUS
> > is in use at the moment or not.  This means that "write"
operations
> > would need to affect both the shadow and the "real" configuration.
> > However, to determine whether the "real" configuration is in need
of
> > update, it must be possible for the administrator to 
> retrieve it.  This
> > conflict is irreconcilable.
> > 
> > To kluge around it, I think you'd have to use a separate 
> SNMP context for the
> > shadow.  This is just too ugly and convoluted a thing to do 
> for no real
> > benefit, particularly since it would require standardizing 
> a context name
> > for this kluge.
> 
> I do not think you need to mess around with contexts. If we can make
> multiple ACMs to work, the problem has a solution.
> 
> /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/>
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>