Re: [Isms] open issues

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Randy Presuhn
> Sent: Wednesday, April 30, 2008 8: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.
> 
[Joe] USM key localization changes this a bit in that the key that is
used depends upon both the security name and Engine ID.  I don't think
that this is explicitly part of the architecture, but it does creep into
to how one deals with the security issues. 

> ...
> > > 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.
> 
[Joe] When considering authorization for delivering notifications you
want to authorize the identity of the recipient of the notification.  In
USM this corresponds to the one holding the key associated with the
security name that can decrypt the message upon reception. 

> 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