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:dhark...@lounge.org]
> Sent: Tuesday, December 01, 2009 1:06
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> 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
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
>
>
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
