Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 5 Apr 2005 12:02:46 -0400

One problem with out-of-band keying is that it isn't tied with the
session lifetime. It might be OK for one-time key setup, but less useful
for routine access authorization. 

Another problem is how to integrate it smoothly, and yet another one -
[artificially] created need to maintain and synchronize two protocols
and implementations.

Summary: I'm a strong proponent of in-band keying.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Chisholm
Sent: Tuesday, April 05, 2005 10:33 AM
To: [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

hi

Out of band keying is what is required.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of Ken Hornstein
Sent: Friday, March 18, 2005 6:40 PM
To: [email-masked]
Subject: [Isms] Discussion: Architecture direction for ISMS

Greetings all,

As you all know, the outcome from the ISMS working group meeting was
that
due to a number of events, we are now tasked with deciding on the
architecture to use for ISMS.  As discussed in the meeting, there are
three
obvious choices, which neatly correspond to the three proposed ISMS
protocols.  Note that choosing a security architecture doesn't
necessarily
mean we have to choose the particular proposed protocol; my expectation
is
that once we pick a particular architecture, we'll develop a new
protocol
based on that architecture.

As I see it, we have the following architectures to choose from.  Note
that
when I say "features", I'm not making a decision on whether or not a
feature
is good or bad; it's just some of the more important points to consider.
I
have no doubt others will have other features to bring up about each
architecture.

- "Out of Band Keying"

  This is the approach chosen by EUSM.  Essentially, a seperate protocol
  exchange is conducted between the manager and agent (or a third party)
  and a key is then established/derived for use with standard USM.

  Features:

  - Can make use of existing USM (already-analyzed protocol).
  - Likely wide variety of IETF protocols to use as out-of-band keying
protocol
  - Encryption/checksum modes limited to ones supported by USM
  - Extra care would be required to assure keying material derived from
    out-of-band exchange is matched with a particular USM session.

- "In Band Keying"

  This is the approach taken by SBSM.  The security protocol is
  contained within SNMP payloads and likely whatever protocol is chosen
  will have a way to secure the PDU contents.

  Features:

  - Requires new SNMP security model.
  - Is more in line with the traditional way security is applied to
    application protocols.
  - Exact privacy/integrity details will need to be specified by this or
    other protocol (depending on which framework is chosen).

- "Encapsulation keying"

  This is the approach taken by TLSM.  An encapsulation protocol (such
  as TLS) is used to "wrap" SNMP payloads.  A traditional USM could be
  run underneath this protocol.

  - Likely requires no changes to SNMP protocol.
  - Is used by a number of other protocols with a great deal of success.
  - _May_ require the use of TCP.
  - Traditional TLS only performs authentication for some mechanisms,
may
    require additional work to support other authentication schemes.

I am sure that others will have additional features to add to the ones
I've
listed above.  Anyway, please, anyone that has any thoughts, please lets
get
them out there!

--Ken

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

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

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

---

From: Robert Story <[email-masked]>
Date: Tue, 5 Apr 2005 12:32:33 -0400

On Tue, 5 Apr 2005 12:02:46 -0400 Blumenthal, wrote:
BU> Another problem is how to integrate it smoothly, and yet another one -
BU> [artificially] created need to maintain and synchronize two protocols
BU> and implementations.
BU> 
BU> Summary: I'm a strong proponent of in-band keying.

I agree with Uri here, with encapsulation keying being my second choice.

---

From: Marcus Leech <[email-masked]>
Date: Tue, 05 Apr 2005 14:56:53 -0400

>for routine access authorization. 
Ok, so call me thick-as-a-brick, but I find *zero* references to 
"sessions" (or, consequently,
  their lifetimes) in RFC3414.  Granted, we *need* the notion of 
sessions, but I can't
  see why an external keying protocol necessarily precludes correct 
synchronization.

There are certainly schemes one could think of (perhaps involving 
functional overloading
  of existing protocol elements in USM/RFC3414) that would overlay a 
session concept, and
  continue to allow for a near-complete divorce between USM and its key 
management protocol.