On 3/14/2008 5:44 AM, Pasi(_dot_)Eronen(_at_)nokia(_dot_)com wrote:
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.
I look at this from the perspective of alternatives. The alternative is
to require additional configuration of keys for applications, which to
say in simple terms, is not simple! The other alternative is to require
something like IKEv2-EAP, which of course relies on the same credentials
as EAP originally would have.
The TSK is the link layer key; the EMSK is a temporary key generated
after verification of EAP method credentials. So, I am not sure I
understand the references to bad engineering.
Could you also explain how enabling key management for applications in
one context hinders the ability of link layers and applications evolving
independently? Is this an instance of the 'good' being an enemy of
'perfect' argument?
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).
Glad we agree that we can use this for mobile IP.
If someone could explain to me why this is bad in concrete terms that
would be useful. If we want to engage in a debate on what might break
some of the principles we fondly state but do not quite follow, I am
happy to engage in that debate. That would be about applying the
"rules" consistently and not arbitrarily.
regards,
Lakshminath
Best regards,
Pasi
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf