Subject: [Isms] What identity

From: "David T. Perkins" <[email-masked]>
Date: Thu, 18 Aug 2005 09:03:42 -0700 (PDT)

HI,

On the Call home functionality, don't you have the same issue
as described below? That is, if you want to set up a session,
what identity is to be used by the client and server, and is
it possible for the client to "hint" to the server the
identity to use?

Regards,
/david t. perkins

---------- Forwarded message ----------
Date: Wed, 17 Aug 2005 21:30:04 -0700 (PDT)
From: David T. Perkins <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: [Isms] Security question for SNMP notifications

HI,

The model that SNMPv3/USM uses for delivering notifications 
(with are traps and informs), is that the notification
delivery system as defined in RFC 3413 is configured
for identities at transport address targets. There may
be multiple identities at each transport address, and
if so, a notification may be sent to each one. On the
notification receiver side, each SNMPv3/USM message
is verified with the credentials of the identity
specified in the notification SNMP message.

When a session approach is used, if a session is created
by a notification originator (the client) to a notification
receiver (the server) and mutul authentication is to be done,
then which identifies should be used by the client and
manager. For me, the "natural" identities are the
managed system for the client, and a user for the
server. However, to do this, then on session creation,
the client must tell the server what ID to use,
since the server can support many identities.
(Or at least, that is the model today, and it
"lines up" with the identities used when the
session is created by a "command generator".

So, from a "security purity" standpoint, what options
are there? I can see:
 1) yes, it is Ok for the client to tell the server
    the identity that the server should use.
 2) no, this is not OK. There can be only one
    identity used per transport address
 3) some other approach

Regards,
/david t. perkins

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms