Bernard Aboba wrote: > 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. There are two fundamentally different ways you could use EAP as an application layer security mechanism, and I think it's important to make a distinction between them. First, you could embed EAP payloads in the application protocol itself. There have been proposals for adding EAP authentication to, e.g., TLS and HTTP this way. This isn't a totally horrible idea from architectural point of view; however, certain properties of EAP make it problematic to use this way (e.g., without channel bindings, EAP would not authenticate the identity of the TLS/HTTP server, only some backend AAA server). You don't need draft-ietf-hokey-emsk-hierarchy for this way of using EAP. Second, you could run EAP in the link layer, and use draft-ietf-hokey-emsk-hierarchy to derive additional keys that get distributed to application endpoints and used there. I think this is what the emsk-hierarchy draft means when it talks about using keys for "higher layer application authentication", and I guess you were primarily concerned about this case. Here I agree with you fully: this is an extremely bad idea. Architecturally linking application security to the link layer is just bad engineering, and hinders the ability of link layers and applications evolve independently of each other. The emsk-hierarchy document should not give higher layer applications as an example use case; instead, it should explain why this is a bad idea, and recommend that keys derived from link layer authentication should be used solely for "link-layerish" things (such as link layer handoffs; Mobile IP is a borderline case here). Best regards, Pasi _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf