Subject: RE: [Isms] securityName

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 25 Jul 2005 14:03:32 -0700

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, July 25, 2005 1:01 PM
> To: Salowey, Joe; [email-masked]; 'Tom Petch'
> Cc: [email-masked]
> Subject: RE: [Isms] securityName
> 
> Hi Joe,
> 
> The SNMPv3/USM design foresaw the need for mappings from 
> multiple model-dependent identities (e.g. USM and Community 
> models) to a model-independent identity, so the same user 
> utilizing different securityModels could be mapped to one 
> securityName, for expected use by the access control 
> subsystem. This is identified by the tuple { securityModel, 
> securityName }.
> 
> Under what circumstances do you envision needing the ability 
> to map from one model-specific identity to multiple 
> securityNames, and how would you know which mapping applied?
> 

[Joe] One example that is often cited is to allow for an application
proxy where the application proxy authenticates to the device and the
requests to act as a certain user.  In SASL name to be used for
authorization is communicated using the authorization identity so it is
explicitly communicated, in other cases it is directly requested as part
of the application protocol.  

> David Harrington
> [email-masked]
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Salowey, Joe
> > Sent: Monday, July 25, 2005 2:33 PM
> > To: [email-masked]; Tom Petch
> > Cc: [email-masked]
> > Subject: RE: [Isms] securityName
> > 
> >  
> > 
> > > I think the securityName comes from the authentication protocol 
> > > which usually in my environment authenticates a user 
> identity. Yes, 
> > > this requires to have different ssh connections if different 
> > > identities access a device. But I think this is also how you get 
> > > into most CLIs as a different user.
> > >  
> > 
> > [Joe] There is typically be a mapping function between the 
> > securityName and an authenticated identity.  This mapping could be 
> > from one authenticated identity to many securityNames, however the 
> > mapping needs to be authorized in order for this to be secure.  The 
> > securityName
> may
> > be implicitly derived (such as equivalent to the authenticated name
> or
> > some well defined porcessing of the authenticated name) or 
> it can be 
> > explicitly defined in an SNMP PDU or as a SASL authorization ID.
> The
> > authorized mapping rules between authenticated identity and 
> security 
> > name can be maintained locally or remotely.
> > 
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> 

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