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).
IETF mailing list