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

From: "Martin Soukup" <[email-masked]>
Date: Wed, 13 Apr 2005 00:44:31 -0400

Why isn't OOBK tied to a session lifetime? Why is one kind of key special
and gets a lifetime and the other doesn't? Is one not the favourite? I know
of some pretty good examples of OOBK's with lifetimes (e.g. things that use
X.509, a.k.a. EAP). Am I missing something?

Martin.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Blumenthal, Uri
> Sent: April 5, 2005 12:03 PM
> To: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> 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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 12 Apr 2005 22:14:08 -0700

Hi -

> From: "Martin Soukup" <[email-masked]>
> To: "'Blumenthal, Uri'" <[email-masked]>; "Sharon Chisholm" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 12, 2005 9:44 PM
> Why isn't OOBK tied to a session lifetime?
...

It could be. For example, if one used an OOBK mechanism in
conjuntion with snmpv3 USM, the mechanism could be
a set to the usm user table, or made automatic (to work with
"kidnapped" boxes) by augmenting the usm user table with
a key expiration date.

What's important is defining the sequence of interactions
so that the keys are delivered to the right places so the
useful communication can begin.

Randy