Subject: [IPsec] Proposed work item: EAP-only authentication in IKEv2

From: Yaron Sheffer <[email-masked]>
Date: Sun, 29 Nov 2009 19:18:31 +0200

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!").

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 30 Nov 2009 15:06:16 -0800 (PST)

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.
>  
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 1 Dec 2009 08:47:15 +0200

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.

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.

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.

- 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.

- 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.

Thanks,
	Yaron

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 1:06
> To: Yaron Sheffer
> Cc: [email-masked]
> Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
> 
> 
>   Hello,
> 
> Scanned by Check Point Total Security Gateway.