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.