As much fun as I've had in catching up with this thread, I'd like to remind all of us that we, at the IETF, do not dictate the way systems get built in the real world. There are SDOs that have gone ahead and defined their own hierarchies out of the MSK and EMSK for various usages at higher layers. And, I use the term "usage" here, since "application" seems unclear in terms of layering - for the purposes of this document, "application" refers to anything that may be able to use EAP keying material and not literally Layer 7. Having said that, I find it interesting that some people here find it okay for Mobile IP to use EAP keying material, but not other applications. I have to deduce that this is because the term "applications" to many of us reminds us of real applications, rather than applications of the keying material. I don't see why the argument that using EAP-based keying material for applications would hinder them running over non-EAP capable interfaces would not apply to Mobile IP. Mobile IP is as much decoupled from a specific interface as any application is - so, does that mean it is okay to not be able to provide mobility across non-EAP capable interfaces using Mobile IP? That would certainly defeat the purpose of the protocol! Not to say that Mobile IP is THE solution to mobility, but let's save that discussion for another day. All said and done, here is what it boils down to - any application of EAP keying material to other services (using the term here to include things ranging from handoffs to mobility to L7 applications) is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those services are only running over EAP-capable interfaces (well, without horrible abominations, anyway). So, if a network access provider requiring EAP is rolling out applications, I don't see a good reason why the application cannot use keys coming out of the EMSK. Our role at the IETF should be in defining the applicability of using such key material such that readers understand that this does not work when the application provider is independent of the network access provider or when the application runs over interfaces that do not do EAP. And, I believe our role ends there. Jari wrote "Tighten up the language in the hokey spec to not allow application keying, and we're done" and I don't believe we are. We can do that and just sit back and watch non-compliant key hierarchies propping up everywhere (and worry about interoperating with those when we write our next spec) or do the responsible thing, which would be to clearly define the applicability, along with providing an interoperable means of defining the key hierarchy for those usages that want to/can use it. Vidya _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf