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

[Yaron Sheffer <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, December 01, 2009 1:06
> To: Yaron Sheffer
> Cc: [e-mail]
> Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
> 
> 
>   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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> 
> 
> Scanned by Check Point Total Security Gateway.