Re: [Isms] Moving into some design / architecture issues ofExtendedVACM
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 

> > "Authoritative source"?  Whoever has the necessary access rights
> > to update the vacmSecurityToGroupTable is authoritative, as far
> > as VACM is concerned...
> 
> That's today's model.  It's not at all clear to me it should 
> be the model
> going forward in a RADIUS-enabled extended VACM.
> 
[...]
> RADIUS needs to be in control of the user-to-group mapping.  
> SNMP is in
> charge of the group-to-access-rights mapping.  Neither should 
> attempt to
> mind the other's business.  Yes, they do need to work in 
> concert, such that
> the set of group is commonly understood.  Having commonly 
> understood group
> names is REQUIRED to be able to use RADIUS in this fashion.

I strongly object to a "VACM extension" that works this way.
That is a totally different access control model, with different
assumptions, and it shoulkd use its own MIB module.

That way VACM and RADIUS-ACM models can coexust.
And THAT is a key tenet of SNMPv3.

dbh


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.