[Top] [All Lists]

Re: IETF Last Call on Walled Garden Standard for the Internet

2008-03-14 08:12:33
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.


Best regards,
IETF mailing list

IETF mailing list

<Prev in Thread] Current Thread [Next in Thread>