Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 29 Apr 2005 17:56:46 -0700

The motivation for EUSM was to implement a solution with minimal changes
to USM.  For this reason we choose to use out-of-band keying.  I am
still strongly in favor of out-of-band keying.

I have not been convinced by any of the discussion that out-of-band
keying is any more difficult or problematic than any of the other
methods so I am opposed to both encapsulation and in-band keying as I
believe they both will require more changes to existing USM
implementations.   

If it is shown that another keying architecture is less invasive to USM
or the working group decides that protection mechanisms within USM need
to be replaced then I would reconsider my opposition. 

Joe 

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Tuesday, April 26, 2005 2:22 PM
> To: [email-masked]
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> Dear all,
> 
> We have to come to an agreement on the architecture we will use.
> Ken asked some days ago, but only one of the replies stated a 
> clear position.
> 
> Shall I take this as an indicator that the rest is not decided yet?
> Or does not care?  Or can we go on with the table that Robert posted?
> 
> >
> > Keying|      For             | Against | Abstain
> > ------+----------------------+---------+-------------
> > OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> > IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> > EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
> >
> >
> > Key:  Y=YES/preference    (y=second pref/implied pref)
> >       M=MAYBE/second pref (m=implied second pref)
> >       N=NO
> >       -=no explicit rejection (no comment)
> >
> > OOB | IB  | EK  | Name (alphabetical by first name)
> > ----+-----+-----+----------------------------------
> >  N  |  N  |  Y  | David Harrington
> >  -  |  y  |  -  | David Perkins
> >  N  |  Y  |  M  | Ira McDonald
> >  M  |  -  |  Y  | Juergen Schoenwaelder  Y  |  M  |  -  | Kaushik 
> > Narayan  Y  |  -  |  -  | Marcus Leech  Y  |  -  |  M  | 
> Martin Soukup  
> > N  |  Y  |  M  | Robert Story  m  |  y  |  Y  | Sam Hartman 
>  Y  |  -  
> > |  m  | Sharon Chisolm
> >  -  |  M  |  Y  | Tom Petch
> >  -  |  Y  |  Y  | Uri Blumenthal
> >  -  |  Y  |  M  | Wes Hardaker
> >
> 
> Has anybody changed her/his mind?
> Or does anybody want to replace a dash by a letter?
> 
> Thanks,
> 
>     Juergen
> -- 
> Juergen Quittek        [email-masked]       Tel: +49 
> 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 
> 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   
> http://www.netlab.nec.de
> 
> 
> 
> --On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
> 
> > ISMS members,
> >
> > There's been a lot of discussion recently on the mailing list about 
> > the pros and cons of different security models.  I think the 
> > discussion has been good, but unfortunately I don't think 
> it's getting 
> > any closer to a consensus (I thank Robert for trying to draw things 
> > closer; unfortunately Juergen and I have been rather busy off-line, 
> > and I apologize for that).  I know that some on the mailing 
> list have 
> > expressed a preference for choosing a security protocol first, but 
> > we've been tasked with choosing the architecture first, and 
> I believe 
> > that is the appropriate approach.
> >
> > Anyway, I'd like to call for a consensus on the security 
> architecture.
> > As we all know, the three choices are:
> >
> > - Out of band keying (the architecture used by EUSM)
> > - In-bakd keying (the architecture used by SBSM)
> > - Encapsulation keying (the architecture used by TLSM)
> >
> > What I would like to see is WG members express which 
> architecture(s) 
> > they prefer (you can choose more than one, but please, don't choose 
> > all three).  Please feel free to state your reasons for 
> your choices, 
> > but in the interests of reaching consensus in a reasonable 
> timeframe, 
> > I am asking that WG members please refrain from commenting on other 
> > people's choices unless they feel that the person has stated a fact 
> > which is obviously wrong.
> >
> > Thanks for your time,
> >
> > --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: Wes Hardaker <[email-masked]>
Date: Fri, 29 Apr 2005 19:58:11 -0700

>>>>> On Fri, 29 Apr 2005 17:56:46 -0700, "Salowey, Joe" <[email-masked]> said:

Joe> The motivation for EUSM was to implement a solution with minimal
Joe> changes to USM.

For reasons I've still yet to see posted to the list, although I've asked.

Joe> For this reason we choose to use out-of-band keying.  I am still
Joe> strongly in favor of out-of-band keying.

Every architecture could use USM underneath for traffic protection, so
that's not really a good argument for OOB, IMHO.

Joe> I have not been convinced by any of the discussion that
Joe> out-of-band keying is any more difficult or problematic than any
Joe> of the other methods so I am opposed to both encapsulation and
Joe> in-band keying as I believe they both will require more changes
Joe> to existing USM implementations.

If you want to use USM and if you assume it will be used then it
probably won't matter which architecture you pick because the results
of implementing any of the architectures could be feeding the keys
into USM.  This is truly identical for OOB and for IB.  (there may be
other reasons for not wanting to pick one or the other, but
compatibility with USM can be done with either).  EK is less straight
forward, though it could be done that way but I'm not sure you'd want to.

Joe> If it is shown that another keying architecture is less invasive
Joe> to USM or the working group decides that protection mechanisms
Joe> within USM need to be replaced then I would reconsider my
Joe> opposition.

Can you explain *why* the other architectures are more invasive?

Lets take a concrete example.  Consider one instance of IBK that has
already been defined (just for example, I'm not arguing at the moment
that it's the right choice for an IBK implementation because it's not
relevant here): SBSM.  The results of the keying exchange of SBSM
could simply result in a USM principal ending up with the negotiated
keys.  Can you explain how that's affecting USM in some way that OOB
wouldn't be?

-- 
Wes Hardaker
Sparta, Inc.