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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf