Re: [Isms] Moving into some design / architecture issues of Extended VACM

[kaushik <kaushik at cisco.com>]

Hi Randy,

Sorry for the delayed response.

I was referring to notion of "authoritative source" really at a system
level. A typical environment will have some form of Identity management
system, for e.g. An LDAP server, as an authoritative source of user
identities and group mappings. RADIUS servers will typically acquire
attributes on a per session basis to evaluate network access policies and I
was hoping that a similar model could flow down to VACM wherein the group
mapping provided by the RADIUS server had the semantics of a temporal
read-only attribute. This is probably in line with the model Juergen
suggested where we have a separate RADIUS VACM table that store
user-to-group mappings received from RADIUS.

Regards,
 kaushik


On 6/12/09 12:04 AM, "Randy Presuhn" <randy_presuhn at mindspring.com> wrote:

> Hi -
> 
>> From: "kaushik" <kaushik at cisco.com>
>> To: "Dave Nelson" <d.b.nelson at comcast.net>; <isms at ietf.org>
>> Sent: Thursday, June 11, 2009 3:27 PM
>> Subject: Re: [Isms] Moving into some design / architecture issues of Extended
>> VACM
> ...
>> The issue I have with this model is that we are using the RADIUS
>> user-to-group mapping which is a temporal association valid for the duration
>> of the session and provisioning a persistent piece of configuration on the
>> SNMP engine. I am not sure the semantics match and this could create
>> potential problems around whether the RADIUS server or SNMP engine is
>> authoritative source for user-to-group mapping since entries can be added to
>> the vacmSecurityToGroupTable without knowledge of the RADIUS server.
> 
> "Authoritative source"?  Whoever has the necessary access rights to update
> the vacmSecurityToGroupTable is authoritative, as far as VACM is concerned,
> and whatever the current configuration of VACM is will govern who can do what
> to anything via SNMP.
> 
> The persistance of the information is governed by
> vacmSecurityToGroupStorageType.
> If the entry already exists, that's already been configured.  If a new entry
> needs to
> be created, 'volatile' is the only type that makes sense.  Forcing persistence
> does
> not make sense.
> 
> I think the crucial point is whether the information coming from the RADIUS
> server
> is trusted as much as information coming from a security administrator.  If it
> is, then
> updating vacmGroupName with the most recently received information makes
> sense.
> If the RADIUS server is not trusted as much as a security administrator, then
> information
> from it should not be used for making user/group mapping decisions.
> 
> It does *not* make sense for the value of vacmGroupName to "revert" upon
> termination
> of the session or some other condition.  Consider the operational scenario
> where the
> update of the RADIUS server is slightly out-of-phase with a VACM access
> control policy push.
> Simple update of vacmGroupName will produce the correct answer.  Doing a
> "revert"
> will result in vacmGroupName being *temporarily* updated via RADIUS to the
> correct value,
> the SNMP push will walk on by, and then the "revert" will restore it to a now
> obsolete value.  Not good,
> so to fix *that* you'd have to add additional state and require the push
> application to
> write to objects that would appear to already have the correct value.  Yuck!
> 
> This isn't netconf.  This is SNMP.  Let's remember what the "S" is supposed to
> stand for.
> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms