On 3/14/2008 5:44 AM, [EMAIL PROTECTED] 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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
