On Sun, Nov 26, 2006 at 09:14:42AM -0500, Charles Clancy wrote: > 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.
If the reauth protocols require changes to all peers, authenticators and servers, then isn't it a big deal? I can't realistically assume that such upgrade can be done at one time. > > 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. That is certainly possible, but my argument was that HOKEY-compliant implementations must interoperate with HOKEY non-compliant (but still RFC3748-compliant and some of them are WFA-certified) implementations regardless of whether HOKEY will be WFA-certified or not. > > 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. In my reading of the existing reauth proposal, implicit signaling for reauth capability discovery is made based on whether the peer, authenticator and server understand a new Code which will be siliently discarded by the recipient that do not understand it. This means that reauth implementations based on the existing proposal would need to rely on timeouts to detect implementations that do not support reauth. Relying on timeouts will significantly affect handover performance. Of course, other solution would be possible to detect reauth-unsupported implementations without relying on versioning or timeouts, but versioning were the simplest way for capability discovery. Yoshihiro Ohba > > -- > t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
