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

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 25 Oct 2005 13:48:26 -0700

Mapping does not always require per-user local configuration.  In the
case where you are mapping a mechanism specific name to an application
usable name the configuration is often a set of rules that apply to all
(or a subset) of entities authenticated by a particular method.  For
example for an X.509 PKC you may have a rule that selects the
appropriate field from the cert (such as DN) and applies some processing
on that field (removal of ASN.1, selection of a name element).  It is
possible for the rules for one application to differ from another.  

In some cases an entity wants to assert a name that it wants to use to
reduce ambiguity in mapping to an application usable name or to be used
instead of an authenticated mechanism specific name.  This could be
accomplished in SSHSM though the SNMP securityName field.  This could
also be done in SSH for some authentication mechanisms where an asserted
name is allowed in addition to the authenticated name (I think the SSH
specs are a bit vague on this). The verifier needs to validate that the
asserted name is a valid alias for the authenticated name.  Depending on
the mapping function this could involve the use of information from a
third party and/or local configuration. 

I think mapping will need to happen and that mapping functions may vary
from deployment to deployment.  It seems useful for an entity to be able
to assert a name it wants to use.  Mapping can happen within the SSH
implementation without direct involvement of SSHSM.  If the securityName
field in the SNMP message then SSHSM would need to be involved in the
mapping.  Doing the mapping in SSHSM adds complexity and probably should
be at most optional (the complexity might be less if we had a decent
name mapping API).   

It is also possible that additional mapping may be desired for
authorization mechanism specific attributes such as groups, roles etc.
While these are also interesting, I think they are currently out of
scope. 

Joe

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, October 25, 2005 11:10 AM
> To: [email-masked]
> Subject: RE: [Isms] #32: is the securityName=username default OK?
> 
> David B Harrington writes...
> 
> > I think this discussion is going off into ratholes.
> 
> What may be a rathole of inconsequential detail for one may 
> be a fundamental requirement for another. YMMV.
> 
> > Allowing for
> > static configuration does not REQUIRE static copnfiguration, nor 
> > preclude dynamic configuration; Allowing for dynamic configuration 
> > does not preclude static configuration where desired.
> 
> Granted.  I see no harm is allowing the option for local, 
> static authentication information.  OTOH, my opinion is that, 
> if local, static authentication information is *all* you 
> need, then USM meets your requirements today.
> 
> > 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).
> 
> It could, but why is this a requirement for ISMS?  I may be 
> dense, but I still fail to see the value added by this 
> additional complexity.
> 
> > If desired, an SNMP MIB could be designed, comparable to 
> the USM-MIB, 
> > that permitted static assignemnts of usernames to securityNames.
> 
> Yes, and that would make ISMS significantly different from 
> USM in what way?
>  
> > If desired, an LCD, possibly but not necessarily in MIB 
> format, could 
> > be populated using CLI scripts or other non-SNMP configuration.
> 
> Ditto.
> 
> I don't object to a "compatibility" mode for ISMS in which it 
> effectively behaves as USM, but if that is all we see as 
> needed, then I suggest we don't bother and close the WG.  I 
> firmly believe that in order to be successful, and solve the 
> customer problems that USM does not solve, that ISMS MUST 
> have a mandatory to implement mode of operation in which it 
> is fully independent of any locally configured per-user (or 
> per-meta-user) authentication information.
> 
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 25 Oct 2005 19:46:59 -0700

Hi -

> From: "Salowey, Joe" <[email-masked]>
> To: "Nelson, David" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, October 25, 2005 1:48 PM
...
> be at most optional (the complexity might be less if we had a decent
...

Do you envision that these mappings would be configured via a MIB, or
would some other mechanism ensure that the various implementations in
a deployment were using the right mappings?

Randy