Subject: RE: [Isms] securityName

From: "Nelson, David" <[email-masked]>
Date: Thu, 28 Jul 2005 11:45:01 -0400

> To implement what you are asking for without changing the current SNMP
> architecture, one could probably map, within the security model, the
> authenticated user identities to security names using an N:1 mapping
> function. The VACM security name to group mapping would then likely be
> a static 1:1 mapping. In other words, the users "joe" and "fred" would
> be mapped to the security name "helpdesk" within the security model
> while the VACM security name to group mapping would most likely map
> 1:1 the "helpdesk" security name to the "helpdesk" VACM group.

Why wouldn't it be more straightforward to map authenticated user
identities to securityNames on a 1:1 basis?

My previous use of the term of "roles" meant organizational title, job
description, and function (i.e. labels in the Human Resources Department
domain).  The generally accepted IT Department practice is to associate
roles with authorization credentials, such as group membership or access
rights.  It is my opinion that the provisioning of access rights on the
managed entity (by means of VACM, or whatever) need to be bound to the
provisioning of access rights in the centralized AAA infrastructure.  It
would therefore make more sense to me to have a securityGroup name that
is provided by the SNMP authentication module, and that comes from the
AAA server.

Attempting to centralize the authentication of identity, and the
management of keys in a centralized fashion, but leaving the binding of
access rights to a non-centralized mapping, is very problematic, IMHO.

I don't think it is reasonable to request that users of ISMS protocols
deploy a separate AAA infrastructure for network administration
purposes.  Most customers will want to use the infrastructure that they
already have, and part of that infrastructure is access rights
information.  The fact that my user account may authenticate via AAA and
provide authorization for remote VPN access to my company's network does
not mean that my same account should authorize me to access the various
managed entities in that network via SNMNP/ISMS.

I guess the point is that *authorization* matters, and it exists today
as part of the AAA infrastructure that we are attempting to re-use.

> Note that with USM, we currently have the N:1 mapping in VACM and the
> 1:1 mapping within USM. The approach sketched above would use the VACM
> N:1 mapping effectivly as a 1:1 mapping and move the real mapping into
> the security model.

I agree.

> From an architectural point of view, I don't really see a problem to
> achieve an N:1 mapping of users to roles within a security model - I
> believe RFC 2576 already sets a precedence (even though the community
> security model has probably not been used in this way so far).

I think the N:1 mapping of users to roles (as I use the word) occurs in
the centralized AAA server.  I would call the mapping that occurs in the
security model a 1:1 mapping of organizational role to SNMP access
control rule-set.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms