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
