Re: [Isms] ISMS/SSH and notifications

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Tue, 13 May 2008 23:16:10 -0400, "David Harrington" <ietfdbh at comcast.net> said:

DH> There is no binding between the IsAccessAllowed answer and the actual
DH> access to the underlying instrumentation. Even if IsAccessAllowed says
DH> "no", an application MAY still decide to access the underlying
DH> instrumentation.

Good point that I forgot, thanks for catching it.

DH> For a minimal device such as a printer that has only notifications
DH> such as "out of paper" and "out of ink", a specific SNMP application
DH> could be written that performs no access control, because the only
DH> notifications are not sensitive.

One might argue it's still performing it "architecturally"; it's just
always returning "ok".

DH> There is no architectural binding between an applications' use of ACM
DH> and the security model. Having the security check that this is the
DH> same securityName used for ACM would violate the modularity of the
DH> subsystems (and would disallow the minimal printer applications). 

Actually there would be some security gain there that wouldn't break the
applications you're talking about; but I won't dive into that here as
it's out of scope.

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

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 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, but I could see how you interpreted
it that way.  Specifically, the application does say "I'm Bob" and also
specifies other parameters like "and my engineID for this message is
XXX" but you're right, it's up to the SM to find the right key.

I was, unfortunately, combining the SM and the application into
"application" in the above statements and I do apologize for that.  My
bad.  (I was thinking of the application has a whole, stack included, as
I wrote the above not the "CG, CR, ..." type application above the stack).
The SM does hold the "keys".

DH> I think it is inaccurate to refer to an NO as an ssh client.

Also true; the NO itself is not.  For the NO to be useful it has to send
the message out to the point where the SM and the transport deal with it
and you're right, from an architectural standpoint it's the transport
that is the client.

However, I don't think my terminology blunders invalidate my points at
least :-)

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms