Subject: RE: [Isms] Informal consensus on dropping out of band keying?

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 12 Apr 2005 10:38:30 -0700

Hi,

Strongly favor IBK.  
Would accept (unhappily) EBK.
Strongly opposed to OBK.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Robert Story
> Sent: Tuesday, April 12, 2005 1:19 PM
> To: [email-masked]
> Subject: [Isms] Informal consensus on dropping out of band keying?
> 
> 
> We are just about half-way to our next dead-line, and I don't 
> get the sense
> that we are making much progress. If we could narrow the 
> discussion down to 2
> architectures, instead of 3, that would be some progress.
> 
> Ken posted the three architectures for discussion on 3/18. 
> Since then, there
> hasn't been too much discussion. I've summarized the 
> preferences for people who
> have expressed one. If I mis-characterized your preference, 
> please let me know.
> 
> 
> (OOBK = Out of band keying, IBK = In band keying, EK = 
> Encapsulate keying)
> 
> Wes Hardaker expressed a preference for IBK or EK.
> Kaushik Narayan expressed a preference for EK or IBK.
> Sharon Chisholm epxressed a preference for OOBK.
> Uri Blumenthal expressed a preference for IBK.
> Robert Story expressed a preference for IBK or EK.
> Ira McDonald expressed a preference for IBK (or at least not OOBK).
> 
> So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK 
> would be ok, and 3
> also said EK would be ok.
> 
> If you haven't expressed a preference for one or two of the
> architectures, now would be a good time to do so.
> 
> _______________________________________________
> 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: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 12 Apr 2005 13:54:35 -0400

For me *both* encapsulated and inband are OK. So count me in "at least
not OOBK".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Story
Sent: Tuesday, April 12, 2005 10:19 AM
To: [email-masked]
Subject: [Isms] Informal consensus on dropping out of band keying?

We are just about half-way to our next dead-line, and I don't get the
sense
that we are making much progress. If we could narrow the discussion down
to 2
architectures, instead of 3, that would be some progress.

Ken posted the three architectures for discussion on 3/18. Since then,
there
hasn't been too much discussion. I've summarized the preferences for
people who
have expressed one. If I mis-characterized your preference, please let
me know.

(OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate
keying)

So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok,
and 3
also said EK would be ok.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 12 Apr 2005 15:09:28 -0400

hi

I think those are the two solutions with the best chance of providing
something that can also be leveraged in netconf.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Tuesday, April 12, 2005 2:59 PM
To: Wes Hardaker
Cc: [email-masked]
Subject: Re: [Isms] Informal consensus on dropping out of band keying?

On Tue, Apr 12, 2005 at 10:34:58AM -0700, Wes Hardaker wrote:
 
> Good summary, thanks.  I suspected that's about where things lay. 
> However, I think you must have missed at least a few opinions that 
> might be discernible from comments (Juergen's S. for example I know 
> has posted a fair amount, though I don't remember which he agreed with 
> or disagreed with; I know that David P. is in favor of IBK but I'm not 
> sure of his opinions on the other 2).

I am in favor of "encapsulation keying" but could also live with a
out-of-band keying solution if it really solves the integration problem
without introducing a rather complex machinery.
 
/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Martin Soukup" <[email-masked]>
Date: Tue, 12 Apr 2005 22:51:14 -0400

What specific applications similar to SNMP are you thinking of?

Martin.

> Behalf Of Sam Hartman
> Sent: April 12, 2005 4:38 PM
> To: Robert Story
> Cc: [email-masked]
> Hi.  I'd like to express a personal preference for encapsulation
> followed by IBK.  I think OBK can be made to work and if that were the
> group's choice, that would be doable.  However OBK seems like it will
> have a lot of issues because you will need to integrate the key
> management protocol and the SNMP protocol.  OBK seems the least like
> the approaches we have chosen for applications similar to SNMP.
> 
> That said, OBK does seem similar to the approach we chose for IPsec.
> So the IETF does have experience with OBK-like approaches.
> 
> I favor encapsulation because it seems to be the closest fit to the
> approach commonly taken in the apps area.  That approach seems to work
> quite well and I'd expect it to work here.  I also would expect it to
> allow significant reuse of code.
> 
> IBK seems like it can work too.  I think it would be a fine approach.
> I think making IBK work will be somewhat more involved than
> encapsulation.
> 
> 
> --Sam
>

---

From: "Martin Soukup" <[email-masked]>
Date: Tue, 12 Apr 2005 23:14:58 -0400

Which IETF keying and security problems are being solved with encapsulation
keying other than application transport protocols? I admit that I'm not up
on all the latest protocols, but this seems counter to what I know.

Martin.

> Behalf Of David B Harrington
> Sent: April 12, 2005 3:40 PM
> To: 'Wes Hardaker'; 'Robert Story'
> Cc: [email-masked]
> Subject: RE: [Isms] Informal consensus on dropping out of band keying?
> 
> Hi,
> 
> I support the encapsulated approach, because that approach is
> consistent with how many other IETF keying and security problems are
> being resolved already, and we need to avoid reinventing the wheel for
> SNMP.
> 
> I expect that in the future, the fact that there are many solutions
> now using or moving toward encapsulation for security will drive
> improved standardization of the security protocols involved, and SNMP
> should be ready to also converge on those standard solutions. I think
> an encapsulated approach should focus on utilizing IETF standardized
> layer 7 interfaces for encapsulated security and transport, such as
> SASL, BEEP, or SSH.
> 
> For encapsulated; not much interested in the other architectures.
> 
> dbh
> 
> > [mailto:[email-masked]] On Behalf Of Wes Hardaker
> > Sent: Tuesday, April 12, 2005 1:35 PM
> > To: Robert Story
> > Cc: [email-masked]
> > >>>>> On Tue, 12 Apr 2005 13:19:11 -0400, Robert Story
> > <[email-masked]> said:
> >
> > Robert> We are just about half-way to our next dead-line, and I
> don't
> > Robert> get the sense that we are making much progress. If we could
> > Robert> narrow the discussion down to 2 architectures, instead of 3,
> > Robert> that would be some progress.
> >
> > I do wonder if we should consider having an interim in late May?
> I'm
> > not sure where we could hold it and how many people would be
> > interested, but I suspect it would help to make progress.
> >
> >
> > --
> > Wes Hardaker
> > Sparta, Inc.
> >

---

From: "Martin Soukup" <[email-masked]>
Date: Tue, 12 Apr 2005 23:35:57 -0400

I have a definite preference for OOBK.
I would, unhappily, tolerate EK. If we go with EK, I'm not sure what the
advantages of using v3 really are though when running in an integrated
mode...

Reasons I significantly prefer OOBK (in order of importance):

1. There is no requirement for implicit trust of the session initiator of
the session provider. In OOBK the exchange of credentials is generally with
the AAA (when running in this mode and the AAA is available). This can be
dealt with by using independent key information from any centrally known
user credentials, but this is a pain, and not really an integrated approach.
2. OOBK is most reusable and in line with other management protocols IMO,
and is the most reusable (e.g. for netconf, OSS/J, WBEM - see Liberty and
SAML, Kerberos for non-IETF OOBK (where the K is an auth key)). IBK and EK
do not provide a decoupling of the security context from the communication
context which need to be decoupled since in an integrated security
infrastructure the communication context is separate from the security
context for good reason.
3. The OOBK is most modular and can be evolved in the field without impacts
to running devices.
4. OOBK has the most potential, IMO, of reuse of existing technologies
(other than perhaps some degenerate EK mechanisms)
5. OOBK is the only mechanism that doesn't modify the existing protocol
exchanges and is thus 100% backwards compatible
6. I believe that OOBK will provide much cheaper and operationally simple
integration with existing AAA systems

martin.

> Sent: April 12, 2005 1:19 PM
> To: [email-masked]
> have expressed one. If I mis-characterized your preference, please let me
> know.
> 
> 
> (OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate keying)
> 
> So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok, and
> 3