Re: [Isms] ISMS/SSH and notifications

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Fri, 9 May 2008 08:17:05 -0400, "Purvis, Ray" <rpurvis at mitre.org> said:

RP> Yes, of course, I had USM on the brain.  For TSM, the notification receiver
RP> doesn't really have a whole lot to do with the securityName, does it?

It is important to identify who sent the message.  Notification
receivers are fairly boring in their current ability to log stuff,
however.  Frequently they just display logs associated with an IP
address and possibly a port.

Right now the SNMP standards don't dictate that the securityName be used
much on the notification receiver side.  Note that even the
NOTIFICATION-LOG-MIB doesn't have an entry fro the securityName used to
send the message (just the context engineID and transport information).
There is no securityName for SNMPv1/SNMPv2c so to some extent this does
make sense.

Net-SNMP (a single point of data as a reference) actually does use the
securityName to authorize what a received notification is allowed to do
(log, forward and execute being the current 3 possible outputs to the
authorization process).  I think Net-SNMP is fairly unique here as most
notification receivers don't do any authorization checks other than to
assure the packet has been properly authenticated.

But...  My point was that there is no current standard that requires
they be the same on both sides.  Both sides may need to make a decision
or use the resulting securityName.  But there isn't a requirement that
the be administratively identical on both sides.  The SSH transport will
accept a user name on the client side to "use" in the transport, and the
server side will be able to extract that same name.  There is no reason
why administratively it can't be the name configured on both sides to be
*the* securityName.  But there is no *current* great reason why on the
sending side it couldn't be different as well.

I think I'm digressing a bit though.  The original point of my message
had nothing to do with the security name the notification receiver was
using (it essentially would be the ssh user name accepted through the
ssh transport).

The issue on the table originally "if USM INFORMs considers the remote
notification receiver to be authoritative, and thus the securityName is
technically defined by the remote side and if SSH doesn't give us a
"name" to use to identify the INFORM receiver with, then what do we use
to do a VACM authorization check?".   My point was: we have information
on the client side that we can use already.  If we want to use the user
name we sent as a client, that's fine.  If we want to use something
different, that's fine too (IMHO here).  The important thing, and this
is critical, is that whatever we decide to call the notification
receiver securityName-wise we MUST make sure the public key returned by
the SSH server and authenticated by the SSH client side is the same as
the public key we were expecting.  Otherwise, all bets are off.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms