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

["David B Harrington" <ietfdbh at comcast.net>]

Hi,

I think this discussion is going off into ratholes. Allowing for
static configuration does not REQUIRE static copnfiguration, nor
preclude dynamic configuration; Allowing for dynamic configuration
does not preclude static configuration where desired.

A AAA system could provide a mapping that is stored in the LCD as part
of the session configuration. In this case, the securityname is not
necessarily the same as the username used for authentication. For
example, RADIUS permits sending an accounting identity to be sent as
part of the ACCESS-ACCEPT message, if I recall correctly. This could
be stored in the LCD and thus be "picked up" as the value for
securityName rather than defaulting to the "username" field from the
ACCESS-REQUEST message (which is the current source for the tm-cached
identity).

If desired, an SNMP MIB could be designed, comparable to the USM-MIB,
that permitted static assignemnts of usernames to securityNames.

If desired, an LCD, possibly but not necessarily in MIB format, could
be populated using CLI scripts or other non-SNMP configuration.

The elements of procedure first look in the LCD, and if there is no
assignment then securityname defaults to the mechanism-specific
username: 
	if ((securityname = LCD::lookup(username)) is FALSE) {
		then securityName = username;
	}

David Harrington
dbharrington at comcast.net

> -----Original Message-----
> From: isms-bounces at lists.ietf.org 
> [mailto:isms-bounces at lists.ietf.org] On Behalf Of Nelson, David
> Sent: Tuesday, October 25, 2005 12:02 PM
> To: isms at ietf.org
> Subject: RE: [Isms] #32: is the securityName=username default OK?
> 
> Kaushik Narayan writes...
> 
> > I think some authentication systems and even some domains such as
> DOCSIS
> > might require mapping of the authenticated "name" to a
securityName.
> 
> I suppose there might be such a requirement, but could you give us a
> concrete example?
> 
> > It might be better to handle this within ISMS configuration (which
> would
> > probably be implementation dependent) and not security model
> independent
> > configuration since the mapping might be specific to particular
> > authentication systems.
> 
> This seems like a potential pit-fall to me.  I can see all sorts of
> interoperability problems arising out of localized, implementation
> specific mappings of identity.  It may work very well in specific
> deployment environments, where the rules are universally understood.
> However, I can see difficulties in obtaining correct results from
> multi-vendor interoperability testing.
> 
> If the tmSecurityName is a function of local per-user (or 
> per-meta-user)
> configuration information, then how is ISMS fundamentally 
> different from
> USM?  ISMS is supposed to be more than USM over SSH.  :-)
> 
> 
> _______________________________________________
> Isms mailing list
> Isms at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms