Re: [Isms] open issues

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

The securityName represents the principal on whose behalf the
notification was originated. So typically, this is not the host, but
the identity of the "user" on whose behalf the notification is sent.

**on whose behalf** was an important phrase during SNMNPv3
development.

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Randy Presuhn
> Sent: Wednesday, April 30, 2008 11:20 AM
> To: isms at ietf.org
> Subject: Re: [Isms] open issues
> 
> Hi -
> 
> > From: <Pasi.Eronen at nokia.com>
> > To: <randy_presuhn at mindspring.com>; <isms at ietf.org>
> > Sent: Wednesday, April 30, 2008 1:02 AM
> > Subject: RE: [Isms] open issues
> ...
> > Perhaps we're discovering a limitation that RFC 341x didn't really
> > consider: when you use pairwise secret keys, the key (and its
> > securityName) always identifies (at least implicitly) both 
> ends of the
> > relationship. In case of public key crypto, that's not the case.
> 
> My recollection was that we consciously used this property in 
> the design
> of USM.  I don't recall any discussions of whether the 
> property held true for
> public keys.
> 
> ...
> > > RFC 3413 section 3.4 specifies that securityName is provided
> > > to the notification receiver application.
> >
> > Yes.. but it's not clear whether this is always the same 
> securityName
> > that was provided by the notification originator application
> > (identifying the receiver, used for access control on the
originator
> > side), or a securityName identifying the originator.
> >
> > For pairwise secret keys, it doesn't matter. For public 
> keys, if it's
> > important to know the former on the notification receiver side, we
> > might need to pass it separately from the SSH user name.
> 
> The assumption when the architecture was designed was that the
> securityName delivered to the notification receiver application
would
> be whatever one was supplied by the notification generator, 
> which would
> be whatever was used by access control to determine whether 
> the information
> should be permitted to be delivered to that party.  It's 
> *not* a securityName
> identifying "the originator" - the only thing in the 
> architecture that comes close
> to that concept would be the snmpEngineID.
> 
> Randy
> 
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
> 

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