On Wed, November 22, 2006 9:07 am, Yoshihiro Ohba wrote: > A HOKEY compliant implementation should be able to revert to the > legacy mode of operation (i.e., use of MSK in the current way) so that > it still interoperates with a HOKEY non-compliant implementation > without ending up with a communication failure or changing the HOKEY > non-compliant implementation. Note that a HOKEY non-compliant > implementation is still RFC3748 compliant as long as it generates MSK > and EMSK even if it does not use EMSK.
Let me point this out again. In order to support HOKEY, EAP implementations MUST change to implement the reauth protocols. Thus, I don't understand why fixing broken methods to export the EMSK at the same time is such a big deal. I'm not convinced by the certification arguments. EAP implementations will all have to be recertified by whomever to check HOKEY compatability anyway. Proper use of the EMSK would be tested then. I'm also not convinced by the versioning arguments, since you'd never need to use the EMSK if you weren't executing some HOKEY reauth protocol. If an implementation didn't derive/export the EMSK, then it has no business executing a reauth. By executing a reauth, an implementation is implicitly signaling that it can derive EMSKs for the originally-executed method. -- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
