Hi Yoshi, I cced EMU since I thought we could use some of the expertise there.
Yes, this absolutely has to do the "key derivation" portion of application keying. We just thought the term "application" is confusing and used "usage specific" instead. Please note that the full scope of "application keying" is a lot wider than just deriving the USRKs. No child key derivation, key distribution or authorization issues are being discussed. We may however need to create a "handover USRK" if we go based on EMSK for hokey. So at least we got a small part of "application keying" idea approved in the charter and that is not a bad thing IMO. Now, any time you have a key hierarchy where the lifetimes are completely dependent on the top level key lifetimes, you need to re-key the whole tree. I don't know how that is different for Kerberos, say you are doing a Kerberos-EAP combo method, where your key wrapping mechanism uses a key that itself is based on an EMSK that is refreshed, then you are back to square one. You have to rekey your key wrapping key too. I don't agree with the fact that rekeying one USRK would require rekeying other USRK, there supposed to be a crypto-separation between the USRKs and from USRK up to EMSK. So as long as you can access the EMSK you can rekey an individual USRK if you want. Now as far as the need for rekeying USRK based on rekeying EMSK, the more philosophic question is this: say I have a usage (take Mobile IP) that needs a MIP-USRK, from which a bunch of other MIP related keys are derived (say Mobile node-home agent key, MN_HA_key). The AAA needs to authorize MIP before the MIP-USRK is generated, but EMSK is not exported to the AAA layer, which means, the AAA server/layer needs to request the EAP/ method layer/"EMSK-key holder" to generate the MIP-USRK for it. At this point and beyond, it should be up to the AAA server to decide how long the user is authorized to do MIP and then decide the life time for MIP-USRK or the children keys (MN_HA_KEY). Why would the AAA have to tie the MIP-USRK or MN_HA_KEY to the EMSK anymore? Why should MIP authorization and security be tied to the initial EAP access authentication? If you agree with this, then EMSK rekeying would not automatically require USRK rekeying for every USRK? If not, then yes, there is a problem. Madjid -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoshihiro Ohba Sent: Wednesday, November 22, 2006 5:46 PM To: [EMAIL PROTECTED] Subject: [Hokeyp] USRK issue (I tried to reply the following thread but somehow my reply did not appear to the list: http://www.opendiameter.org/pipermail/hokeyp/2006-November/000356.html, so let me post with a new thread.) I have a fundamental issue with deriving multiple root keys used for different purposes as a form of key hierarchy. There are two reasons. When re-keying of EMSK happens, it would require all USRKs derived from EMSK to be re-keyed, regardless of the purposes the USRKs are used for. Second, it is difficult to re-key only a specific USRK without re-keying other USRKs as well. If we consider use of EAP for multiple different types of applications, this issue seems critical to me. I would suggest further investigating this fundamental issue before WG adoption of draft-salowey-eap-emsk-deriv-01. My sense is that a Kerberos-like approach (i.e., use of tickets that carries encrypted key and associated attributes including lifetime and key scope/usage) is much better than key derivation approach such as described in draft-salowey-eap-emsk-deriv-01, from key management perspective even if we consider the complexity aspect of a Kerberos-like approach. I would like to also point out that USRK is related to so called "application keying" in HOAKEY BOF in March 2006, and "application keying" was ruled out from the BOF discussion. Regards, Yoshihiro Ohba _______________________________________________ Hokeyp mailing list [EMAIL PROTECTED] http://www.opendiameter.org/mailman/listinfo/hokeyp _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
