Subject: RE: [Isms] Thoughts on Encapsulation

From: "Nelson, David" <[email-masked]>
Date: Thu, 5 May 2005 11:00:40 -0400

Uri Blumenthal writes...

> What seems the most straightforward from SNMP point of view is to
create
> a security model tag that would identify the key exchange SNMP
packets,
> and within those packets encapsulate the information necessary to
> complete the key exchange (utilizing whatever mechanisms, be it GSS,
> straight Krb, PKI, ...). Once the keys are computed, any [other]
> security model can be used to protect the negotiated session.

I might be confused in my thinking, but my understanding of the EK
architecture is that the encapsulation protocol (e.g. TLS) provides the
session context now missing in SNMPv3 USM.  We all understand the need
to bind the negotiated keys to the session, and for both end-points to
have a consistent view of session state.  OBK had the problem of needing
to create the session context using existing (e.g. USM) protocol
features.  This is not impossible, of course.

So, one advantage of having chosen the EK architecture is that the
session context and session-to-key binding already exists.  The only
disadvantage of EK is that the actual encapsulation is a bit of
overhead.  I think that having chosen EK, we need to apply the protocol
selection in a straightforward fashion.  I think that means we need to
encapsulate the SNMP data stream.

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 5 May 2005 14:06:59 -0400

Perhaps this is the simplest: new transport SNMPoDTLS. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kaushik Narayan
Sent: Thursday, May 05, 2005 1:59 PM
To: Nelson, David
Cc: [email-masked]
Subject: RE: [Isms] Thoughts on Encapsulation

Hi All,

The use of TLS to encapsulate all SNMP packets would mean that
we had an architecture discussion on keying approaches and the
result would be a new transport specification for SNMP.

The current SNMP specification provides the option to use SNMPoUDP
and SNMPoTCP, the choice of TLS as a transport will definitely have
performance implications for SNMPoUDP applications that will probably
undermine the reason for these applications to use UDP in the first
place.

regards,
   kaushik!

At 08:32 AM 5/5/2005, Nelson, David wrote:
>It seems to me that ISMS using EK is not going to closely fit into the
>SNMP Security Model architecture as described in RFC 2571.  I say that
>because an encapsulating security layer typically sits below the
>application, (roughly) in the socket layer.  In RFC 2571 we have the
>Security Model in the middle of the application protocol stack.
>
>I would suggest, however, that we either "just get over it", and make
>progress, or decide that conformity with the RFC 2571 architecture
model
>is of sufficient importance that we need to revisit the EK decision.
>
>I'm suggesting that we make the decision to "just get over it" now,
>because if we wait until the EK protocol selection and ISMS design
phase
>to deal with this conceptual issue, we run the risk of de-railing
again.

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 5 May 2005 17:04:23 -0400

David Harrington writes...

> The TLSM document describes in reasonable detail an EK architecture
> can fit into the RFC3411 architecture by describing the flow that
> connects the transport mapping of an encapsulating transport with the
> expected output of a security model, which is later used for SNMP
> applications and access control.

OK, I'll read it again, more carefully this time.