On Thu, Nov 16, 2006 at 06:35:25PM -0800, Narayanan, Vidya wrote: > > > > It's worth keeping in mind that there are very few existing > > RFC 3748-compliant EAP implementations. So most existing EAP > > method implementations do not generate an EMSK, and most > > existing EAP implementations would not do anything with the > > EMSK if it were to be generated. > > > > Well, the question is this - is the requirement to interoperate with > existing standards or existing implementations? Given that we have a > spec that says what it does, it seems to make sense to interoperate with > that. If we are going by existing implementations, there is probably > more than one flavor and then there is the question of when the MSK is > directly delivered to the authenticator and when it isn't and how the > peer knows that. > > In this case, I tend to agree with Charles that it is better to have to > fix non-compliant implementations than try to design around them. Also, > if we choose to ignore the standard and use the implementations that > don't produce an EMSK as a data point, the standard doesn't seem to be > serving a purpose then - perhaps, we should then consider revising > RFC3748 to reflect what we want to use as a starting point for > requirements?
Revising RFC 3748 to add a mandatory usage of EMSK would break interoperability with existing EAP implementations, because EAP does not define a *version* field used for distinguishing old and new specifications. Yoshihiro Ohba > > Vidya > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
