RE: [HOKEY] EMSK Issue

FWIW, I agree with Glen's take here.  To avoid repeating myself, here
are pointers to emails that I sent in response to this thread on the
IETF list (for the benefit of those not on the list): 

http://www.ietf.org/mail-archive/web/ietf/current/msg50860.html
http://www.ietf.org/mail-archive/web/ietf/current/msg50880.html

- Vidya

> -----Original Message-----
> From: hokey-bounces@ietf.org [mailto:hokey-bounces@ietf.org] 
> On Behalf Of Glen Zorn
> Sent: Tuesday, March 18, 2008 8:31 AM
> To: Charles Clancy
> Cc: ietf@ietf.org; hokey@ietf.org; Bernard Aboba
> Subject: Re: [HOKEY] EMSK Issue
> 
> Charles Clancy <> scribbled on :
> 
> > HOKEY,
> > 
> > From Bernard's "walled garden" LC comments, I've created 
> the following 
> > issue below in the issue tracker.
> 
> Some of us don't subscribe to the IETF list (due to the 
> extremely poor S/N ratio).  Someone did forward me Bernard's 
> original message & to me it appears to fall squarely into the 
> N category (either that or it is an early April 1 RFC 
> candidate).  I understand, though, that it is actually 
> receiving serious discussion on the IETF list, so I'm happy 
> that you are bringing some of that discussion to this forum.  
> Of course, common courtesy would have required that the WG 
> the work of which is being disparaged in outrageous fashion 
> be included in the discussion but courtesy seems to be in 
> short supply.
> 
> > 
> > http://www.ltsnet.net:8080/hokey/issue39
> > EMSK: applicability statement, scope
> > 
> > The EMSK document, as-is, allows (or more precisely does not
> > disallow) for broader use of keys than it should.  
> 
> That may be somebody's claim; however, RFC 3748 says:
> 
>    Extended Master Session Key (EMSK)
>       Additional keying material derived between the EAP client and
>       server that is exported by the EAP method.  The EMSK is at least
>       64 octets in length.  The EMSK is not shared with the
>       authenticator or any other third party.  The EMSK is 
> reserved for
>       future uses that are not defined yet.
> 
> This doesn't appear to me to constrain the uses of the EMSK; 
> furthermore, since Bernard is not just one of the authors of 
> 3748 but also a co-Chair of the working group that published 
> it, it seems like the time & place to constrain the usage of 
> the EMSK would have been during the drafting of the RFC and 
> in the eap WG.  
> 
> > There could
> > be interoperability issues if applications require 
> EAP-generated keys, 
> > breaking the layering of the Internet protocol stack.
> 
> What does that mean?  How can _keys_ cause layer violations?
> 
> > 
> > Some sort of statement regarding applicability and scoping 
> of derived 
> > keys is necessary for this document.
> > 
> > --
> > t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> > electrical & computer engineering, university of maryland 
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www.ietf.org/mailman/listinfo/hokey
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
> 
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf