Jari Arkko said: "For what it is worth, this ex-EAP co-chair also thinks that the use of EAP keys for applications is a very bad idea. And I too am concerned about introducing walled gardens through this. Having said that, I think there are legitimate uses of EMSK in the area of network access, such as various fast handover proposals in EAP. My understanding is that HOKEY is working on this. So perhaps one potential direction for resolving your issues is to provide a much stricter IANA section and an applicability note. I realize that this does not prevent people from grabbing values. But I note that I know of one case at least where this has already happened, even without an IETF specification. Arguably the situation with a (sufficiently tight) spec might be better, because we can use the spec to explain what usage is inappropriate. I realize we have RFC 3748 already, but since use of EMSK has been an IETF topic for 5+ years, I think it would be reasonable to state what the final rules are on taking specific keys out of the EMSK. Disclaimer: I read the draft very quickly after your note, and have not done a full review. I will do a very in-depth review when this document comes to the IESG." Thanks Jari. I have no objection to any use of the EMSK relating to link layer handoff, or even to IP layer things that might be somewhat related (e.g. Mobile IP). But utilizing EAP as an application layer security mechanism does seem inappropriate. In terms of how to fix this within the document, I have no good ideas at the moment. The derivation of new keys via labels brings with it an extraordinary degree of flexibility which seems like it would be very difficult to control. The issue may not be so much about trying to stop this (which is probably impossible), but to somehow make it clear that these usages are considered a bad idea by the IETF, so that customers and users cannot be confused by vendors claiming compliance to an IETF standard. Also, I think it is a bad idea to allow SDOs to create their own usages without at least undergoing IETF review. Again, we cannot stop them from doing that, but at least we can set expectations. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf