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@xxxxxxxx [mailto:hokey-bounces@xxxxxxxx] > On Behalf Of Glen Zorn > Sent: Tuesday, March 18, 2008 8:31 AM > To: Charles Clancy > Cc: ietf@xxxxxxxx; hokey@xxxxxxxx; 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@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/hokey > _______________________________________________ > HOKEY mailing list > HOKEY@xxxxxxxx > https://www.ietf.org/mailman/listinfo/hokey > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf