Hello, I do not believe this is a reasonable activity to spend WG time on. The reason is that for this proposal to be useful for more than a small, specific, edge condition the following must apply:
- both sides MUST implement both client- and server-side EAP state machines. - both sides MUST possess the shared secret. And in that case EAP encapsulation of the underlying key exchange would be completely pointless and extraneous, would double the number of messages required to complete the exchange, and would increase the amount of security-critical code. More work for no benefit...not a good idea. In addition, EAP-only authentication increases potential insecurity, where an external EAP server can authenticate any identity an IKEv2 gateway wants to claim-- the "lying NAS problem". Authentication depends on a verifiable identity and if one side can claim any identity it chooses then the mutual authentication properties of IKE cannot be met. Even if one believes that the small, specific, edge condition is really important there is an alternative to address that case, one that can also address other peer-to-peer, subnet-to-subnet, and tranport mode, use cases. That is the "Secure PSK authentication" option as defined in draft-harkins-ipsecme-spsk-auth-00.txt. It seems to me that EAP-only authentication in IKEv2: 1. does not solve a general problem; 2. solves the specific problem it is aimed at poorly-- doubling of the number of messages, requiring writing and testing of new state EAP state machines that are, otherwise, unnecessary; and, 3. is insecure (unless something used nowhere today is employed: EAP channel bindings). To provide the benefits of EAP-only authentication-- certificate-less mutual authentication based only on a password-- it would be much better to support the inclusion of "Secure PSK authentication" as a work item. That work item will not only address the small use case that EAP-only authentication is aimed at, it will also address other peer-to-peer, subnet-to-subnet, and transport-mode use cases. And it will do so in a manner that ensures security. regards, Dan. On Sun, November 29, 2009 9:18 am, Yaron Sheffer wrote: > This draft proposes an IKEv2 extension to allow mutual EAP-based > authentication in IKEv2, eliminating the need for one of the peers to > present a certificate. This applies to a small number of key-generating > EAP methods that allow mutual authentication. > > Proposed starting point: > http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt. > > Please reply to the list: > > - If this proposal is accepted as a WG work item, are you committing to > review multiple versions of the draft? > - Are you willing to contribute text to the draft? > - Would you like to co-author it? > > Please also reply to the list if: > > - You believe this is NOT a reasonable activity for the WG to spend time > on. > > If this is the case, please explain your position. Do not explore the fine > technical details (which will change anyway, once the WG gets hold of the > draft); instead explain why this is uninteresting for the WG or for the > industry at large. Also, please mark the title clearly (e.g. "DES40-export > in IPsec - NO!"). > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec