I would prefer not to say anything at all. But that may not be realistic. I do understand Jari's concern that there *could* be some issues if no used correctly. I think the main objection as I understand it is that Network Access Authentication should be decoupled for Application Authentication. That is, if we use the EMSK derived from Network Access Authentication to derive keys for applications we are coupling the two authentications. This can be bad as Jari puts it because those applications that are coupled to one Network may not work when the user is connect to another network. I agree but not generally. That is, there are some applications for which coupling makes perfect sense. Applications that strictly run within the context of a Network Access session could benefit by having their application keys bootstrapped from EMSK. For example, Over-the-Air provisioning application and location based applications that are part of the network. Bootstrapping the keys from EMSK creates a single-sign-on and elliminates the need to have to provision keys for each of the applications and elliminates the need to run extra messaging to create session keys etc. Application like a web server may not be appropriate to have its keys derived from EMSK because these application are network agnostic. So we need to say something. But that something needs to indicate the issues so that SDOs understand when to use the EMSK thingy and when not to use it. I do not support making blanket statements such as Application MUST not derive their keys from EMSK. Also note that there are ways to use the EMSK even in the case of the Applications that are access network agnostic. And we should not block this scenario. > -----Original Message----- > From: hokey-bounces@xxxxxxxx [mailto:hokey-bounces@xxxxxxxx] > On Behalf Of Glen Zorn > Sent: Tuesday, March 18, 2008 11: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