Subject: RE: [Isms] #8: Do we need a mapping between the SSH key and SNMPengineID?

From: "David B Harrington" <[email-masked]>
Date: Mon, 17 Oct 2005 17:46:16 -0400

Hi,

I would like to remind people that there is a distinction between the
use of contextEngineID and the use of securityEngineID. As Juergen
pointed out, there is the "information authoritative" engine and the
"key authoritative" engine (plus "clock authoritative" and "access
control authoritative"). The distinctions can be important to this
question.

SSH key in this question really means "authenticated SSH server
identity".

So this question really has three interpretations: 
Do we need a mapping between the SSH server identity and
securityEngineID?
Do we need a mapping between the SSH server identity and
contextEngineID?
Do we need a mapping between the SSH server identity and snmpEngineID?

Regarding securityEngineID:

USM doesn't explicitly authenticate the engineID, but it does
authenticate the securityEngineID implicitly via the clock check
(weakly) and the localized keys.

So there is the question of whether there should be a mapping between
the authentication of the SSH server and the associated SNMP engine,
to replace the implicit authentication provided by localized keys.

However, to send the message containing the spoofed engineID, the
engine will need to establish a tunnel using SSH authentication, so I
personally believe that such a spoofing attack is not a concern.

Regarding contextEngineID authentication:

USM, the current instantiation of SNMPv3 security, does not
authenticate the contextEngineID passed in a message. In fact, USM
really doesn't process the PDU portion of a message except to
encrypt/decrypt it. 

But when processing is to be done locally, the contextEngineID equals
the snmpEngineID managed object, and when the local engine will be
information-authoritative (i.e. in a response message), the elements
of procedure include checking whether the securityEngineID matches the
local snmpEngineID during message processing. This check strikes me as
an  implicit binding between the securityEngineID and the
"information-authoritative" engine (the local contextEngineID).

This raises the question of whether there should be a binding between
the authenticated SSH server identity and the
information-authoritative engine (assuming the SSH server is always on
the information-authoritative side).

Regarding contextEngineID multiple registrations:

RFC3412 allows multiple contextEngineIDs to be registered with the
dispatcher. From RFC3412: "Note: Implementations may provide a means
of requesting registration for simultaneous multiple contextEngineID
values, e.g., all contextEngineID values, ...".
This apparently would enable a single SSH server to provide security
for multiple contextEngines. The SNMP dispatcher would handle the
multiplexing of contextEngines (note this only applies to
contextEngines, not securityEngines). 

[Note that RFC3411 seems to disagree with RFC3412 on whether a single
SNMP entity can have multiple engineIDs - "Since there is a one-to-
   one association between SNMP engines and SNMP entities, it also
   uniquely and unambiguously identifies the SNMP entity within that
   administrative domain." ]

[Note that in a previous message I said one VACM instantiation could
not apply to multiple engines; I was obviously incorrect in that
assertion.]

[Note that using multiple contextEngineIDs might be problematic, when
checking whether securityEngineID matches snmpEngineID, since
snmpEngineID should match the contextEngineID when processing is
local.]

But multiple registrations is only one way engine multiplexing can be
accomplished. A single SSH server could support multiple engines
(securityEngineIDs or contextEngineIDs) by having them use different
ports. In this case, SSH would effectively be handling the
multiplexing of engines.

Looked at from the other direction, SNMP currently has no mechanism
for multiplexing SSH servers, and has no parameter in the ASIs to
allow an application to select which server to use (or which host key,
etc.) for an outgoing message.

If there was a binding between the securityEngineID and the SSH server
(or the host key), established in advance or when the session was
established, then when an application specified the securityEngineID,
it would be apparent (to the SSHSM) which SSH server (or host key) to
use.

David Harrington
[email-masked]

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