Hi Yaron, On Mon, November 30, 2009 10:47 pm, Yaron Sheffer wrote: > Hello Dan, > > [WG co-chair hat off] > > EAP-only authentication is a small IKE extension that does not change the > existing IKE architecture; neither does it change many of the extant > implementations. Given the right EAP methods, it would provide us exactly > what EAP was supposed to provide from day one: mutual non-PKI > authentication.
I don't know where you came up with the idea that EAP was supposed to provide us with mutual non-PKI authentication from day one. It was designed for PPP and the trust model for which it was designed is DRAMATICALLY DIFFERENT than the trust model used for IKE. > And the solution is generic: any suitable EAP method can be deployed, so > implementors can make their own security/interoperability/IPR/simplicity > tradeoffs, instead of having one specific authentication method mandated. Please do not overstate your proposal. The only type of EAP method that is suitable is one in which a password, and only a password, is the authentication credential, and each side possesses that credential. Any other EAP method can quite happily be handled in IKEv2 today, no need for new EAP-only authentication proposals. > To address your specific concerns: > > - The case of client-to-gateway authentication happens to be one of the > top use cases of IKE/IPsec. Certainly not a "small use case". I'm not > saying that EAP-only auth is limited to this use case, but it certainly > solves it well. I don't want to get in a case of dueling marketing departments but let's just say we disagree. Site-to-site IKE/IPsec is large, transport-only IKE/IPsec is less so, and the <poof> that became the UMA market put a serious dent in client-to-gateway IKEv2. But I will agree with you that client-to-gateway IKE/IPsec using IKEv1 and insecure proprietary hacks is also quite large today. And hopefully you will agree that it would be good to provide a _secure_ solution to that market. I will take issue with your statement about limited use of EAP-only auth. It really is limited. What you are proposing is for one, and only one, use case of IKEv2. And what you are proposing is more complicated than just solving it directly in IKE. You have failed to justify the increased complexity and decreased utility. > - It would depend very much on the specific product/scenario whether "both > client and server state machines" need to be implemented. Specifically > this is incorrect for client-to-gateway. > > - EAP as you well know is a 3-party protocol, it is not necessarily > terminated on the IKE peer. So it is incorrect to say that "both sides > MUST possess the shared secret" - exactly the right parties will need to: > the client and the authentication server. Actually EAP is a 2-party protocol that, for optimization reasons, has become viewed as a 3-party protocol. And therein lies the problem. Both sides will need to possess the shared secret for this proposal to be applicable to all use cases of IKEv2. Note that a simpler proposal that solves the exact problem you're trying to solve is applicable to all use cases of IKEv2. You have to decide whether your proposal has limited applicability or whether it requires unnecessary implementation of EAP state machines, you can't have both. I'm sure you will agree that encapsulating messages in EAP buys nothing and doubling the number of messages also buys nothing. But they both cost something. Again, we have cost with no gain with your proposal but less cost and more gain with mine. And now the security problem: an IKEv2 gateway can claim ANY identity during EAP-only authentication. That has serious implications with the security claims of IKE. If password-based authentication is provided as part of IKE this security problem goes away. > - EAP-only auth can also be applied to scenarios where no Auth Server is > deployed. However in these cases both peers would indeed need a full EAP > implementation. > > - The EAP community is (very slowly) coming to terms with EAP channel > bindings. While this is not provided by your EAP-PWD (and I hope this is > fixed before publication), EAP-EKE has been extended to add this > capability. Very slowly being the operative words. And this disclaimer also nullifies your previous statement of this being a "generic solution". It really only applies to EAP methods that are password-only and have some extra capability above-and-beyond EAP. On the other hand, we could have all this with less complexity by going with draft-harkins-ipsecme-spsk-auth. It's a choice of more complexity, less utility, and less security OR less complexity, more utility and more security. I don't understand why you want to go with the former. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
