> > 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? Vidya _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
