Hi Yoshi, -----Original Message----- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Monday, November 27, 2006 5:48 PM To: Madjid Nakhjiri Cc: 'Yoshihiro Ohba'; [EMAIL PROTECTED]; [email protected] Subject: Re: [Hokeyp] USRK issue
<snip> > > 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. Re-keying key wrapping key may not necessary mean immediate re-keying the keys wrapped by the key wrapping key, because the wrapped key has no cryptographic dependency with the key wrapping key. In the case of Kerberos, whether immediate re-keying is needed when key wrapping key is invalidated seems to be rather an authorization policy issue. Madjid>> I thought we were discussing rekeying of USRKs, so I assumed your Kerberos example was a use case for USRK spec and that is why I said the key wrapping key could be a USRK. And yes, this being an "authorization policy" is exactly the point I am making In the case of key-hierarchy based approach, there is a cryptographic dependency between the root key and its child keys. Hence, if the root key is re-keyed, then the old root key is not valid, and it is natural to think that the child keys derived from the old root key are no longer valid and re-keying is needed. Madjid>>I don't think cryptographic dependency necessarily translates into life time dependency, especially if the authorization entity (AAA server) is possibly different from the entity generating the key (EAP server). Yes, if you need to rekey using a root key and the root key is now updated, you should use the updated key, but I think that can be worked into the AAA server-EAP server API. I am using this terminology, since we know EMSK is not exported from EAP layer. > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
