Subject: RE: [Isms] #32: is the securityName=username default OK?

From: "Nelson, David" <[email-masked]>
Date: Mon, 24 Oct 2005 11:30:46 -0400

David B Harrington writes...

> So, if the mapping between a mechanism-specific "username" and a
> corresponding securityname is not explicitly specified in the Local
> Configuration Datastore, then is setting securityName to the username
> (tmSecurityname) associated with the session the right thing to do?

While nothing would preclude having USM-style local configuration
information dealing with the creation of securityName, I think the
straightforward thing to do is eliminate any local configuration
dependency and *always* use the tmSecurityName as the securityName. 

This effectively deprecates the concept of a model independent
securityName.  While that was probably a nice concept in theory, and
practical as long as local configuration was intrinsically part of the
authentication mechanism, I think it makes little sense when used with
existing authentication (or AAA) infrastructures.  Remember, the whole
premise is to leverage existing, centralized identity management, so
having to configure an identity transform on each managed entity makes
no sense to me.  We don't want to have to configure the identities on
each managed entity, so why should we have to configure an identity
transform?

IMHO, the proposed default behavior is the only required behavior.

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 24 Oct 2005 19:07:58 -0400

Hi,
 
Comments inline.

> dependency and *always* use the tmSecurityName as the securityName. 

Remember that ISMS supplements USM. USM requires a local configuration
dependency, therefore we cannot eliminate it.

> each managed entity, so why should we have to configure an identity

One reason why we have securityName is so that a system logging
facility that logs changes to the SNMP system can use a human-readable
name in the log - the securityName. We have no guarantee that the
tmSecurityName is human-readable.

The more obvious reason for securityname is to allow multiple
authentication mechanisms to map to a common securityname for a user
(or a group of users, or whatever) for use by the access control
system. 

I do not believe all organizations will always have only one mechanism
for authenticating all people and other entities (such as
applications), regardless of the device from which they are
authenticating, the firmware version of the device from which they are
authenticating, or the location from which they are authenticating.
Having a mechanism to bind multiple mechanism-specific identities to
ojne SNMp identity seems a good thing.

David Harrington
[email-masked]