Re: [Isms] ISMS/SSH and notifications

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

> -----Original Message-----
> From: Wes Hardaker [mailto:wjhns1 at hardakers.net] 
[...]
> 
> DH> On the other hand, specific standard applications MAY 
> imply or require
> DH> in their elements of procedure that the securityName is the same
> DH> between the ACM and the SM. I think this is the case for the NO
> DH> described in RFC3413 section 3.3, in paragraph (2).
> 
> I'd like to reword that before I agree with it:
> 
> ... require in their elements of procedure that the 
> securityName is the same
> between the ACM and   the SM
>                     ^
>                     output of

Your rewording is incorrect because it presupposes this is an incoming
message. 
RFC3413 section 3.3 is actually about Notification Originator
Applications.
In either direction, it is the design of the application that makes
any binding between the securityName used for ACM and SM. 
For incoming, an application design MAY use the output of the SM when
invoking the ACM.
For outgoing, the application chooses the securityName, and the design
MAY use the same one for both ACM and SM purposes.

In the SNMPv3 WG, we worked to eliminate the explicit binding between
a security model and an ACM. There were too many issues caused by
(often-invalid) assumptions made by access control designs, about the
"strength" of authentication, integrity, and confidentiality provided
by different algorithms. These "strengths" could easily change over
time, and the strength of algorithms depends too much on the
environment to which they are being applied.
The SNMPv3 approach differed from the earlier monolithic SNMPv2p,
snmpv2u, and snmpv2* designs which had explicit sharing of information
between the message security and access controls, including knowledge
of the specific algorithms and credentials used.

The SNMPv3 approach uses layered security. In SNMPv3, we broke the
architecture into separate subsystems (layers, more or less). The
security model provides message security at a lower layer than the
using application; the interface to upper layers (the applications)
only provides the model used, a human-readable handle for the
principal authenticated, and an indication of security services
provided. All information about the specifics of the algorithms or
credentials used at lower layers is deliberately hidden from the upper
layers. This approach permits algorithm agility, and eliminates
assumptions about the strengths of different algorithms when
configuring access controls. (The ACM does consider the expected
strength of the security model.)

> 
> Remember, I never said that the SM wasn't responsible for 
> passing on the
> securityName.  I only said that it could do it in a number of 
> ways; one
> of which could be a lookup table for which the keys might be 
> some other
> aspect of the packet/protocols involved (such as the keying 
> material and
> possibly parameters passed to it via the application just as the USM
> user name to use is currently passed to it via the application).

I disagree with this. The application does not pass the USM user name
to use; it passes the securityName to use, and the security model to
use to determine how to translate the securityName to a
security-model-specific credential. USM happens to use the
securityname to lookup the corresponding USM user name in a table to
determine the credentials. The application layer does not know how the
lower-layer security model translates from securityName to an
SM-specific credential (for outgoing) or how the lower-layer security
model translates from an SM-specific credential to securityName (for
incoming).

> 
> I did *not* ever state (or mean to imply) that the securityName
chosen
> wouldn't be agreed to by the SM.  Only how that mapping was done.
> 
> >> 2) The initiating application (NG or CG) is the one that 
> >> actually tells the remote side who it is when USM is used.  More
> >> importantly, it really says "we're both Bob; I can prove 
> I'm Bob and
> >> please prove you are too when you send a response".  The CR and
NR
> >> merely use this fact to look up the proper keying material 
> to use to
> >> ensure that they can be Bob.
> 
> DH> I haven't hunted this one down, but I believe it is incorrect to
> DH> state that an **ACM** should have authentication 
> credentials in its
> DH> tables.
> 
> I never meant to say that if I did, 

You didn't. Tom said the public key should be stored in VACM tables.
You didn't seem to notice that.

David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com

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