On 2/3/2008 1:23 AM, Glen Zorn wrote: > Lakshminath Dondeti <> scribbled on Sunday, February 03, 2008 1:30 PM: > > ... > >> There was also the issue of not being able to export EAP session IDs >> (IIRC) that I referred to in my other message. > > Hmmm. draft-ietf-eap-keying-22.txt says > > EAP methods supporting key derivation and mutual authentication > SHOULD export a method-specific EAP conversation identifier known as > the Session-Id, as well as one or more method-specific peer > identifiers (Peer-Id(s)) and MAY export one or more method-specific > server identifiers (Server-Id(s)). EAP methods MAY also support the > import and export of channel binding parameters. EAP method > specifications developed after the publication of this document MUST > define the Peer-Id, Server-Id and Session-Id. The Peer-Id(s) and > Server-Id(s), when provided, identify the entities involved in > generating EAP keying material. For existing EAP methods the Peer-Id, > Server-Id and Session-Id are defined in Appendix A. > > Not sure where the "can't export session IDs" idea came from, but the > above would seem to contradict it. > > ... > Hi Glen, Yeah, that was my recollection from an old discussion (that SHOULD was a MAY not too long ago). In any event, it appears that my statements were incorrect or at least ambiguous. My sincere apologies! If the session-id based keyname derivation can be made to work, I have no objection to use it. I looked at draft and in fact, this is what is stated there: NameDerivationKey = EAP Session-ID, when K used in rRK derivation is the EMSK, NameDerivationKey = DSRK Name, when K used in rRK derivation is the DSRK. I looked at some old versions and there was an explanation "Unlike the rRK_name, the EAP session ID is not used to derive the rIK_name. This is done in order to avoid any collisions with USRK names. The key label used for USRKs is IANA registered, while the string "rIK Name" is not. " We probably need to mix in the domain name too to avoid key label collision. I also recall (I know my recollection is bad :) ) Vidya and I discussing that ID collisions may be likely due to at least a couple of other reasons too when the domain specific keying is considered. The various EAP servers do not coordinate session ID derivation and not all methods derive sufficiently long and random session IDs. I now checked session ID derivation in some methods again and it seems reasonably random in methods that I care about (I know that's irresponsible :), but the generic solution is already in the draft). Any suggestions on the direction here? Would it help if we used the following? NameDerivationKey = f(EAP Session-ID, domain-name), when K used in rRK derivation is the DSRK. regards, Lakshminath _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf