Hi Martin,
If you (or anybody else) support EAP-only auth (or any of the other 6 drafts),
please commit to review it assuming it becomes a WG document. *This* was the
main point of this discussion thread: we cannot make progress without committed
editors and reviewers.
Thanks, and apologies for picking on you :-)
Yaron
> -----Original Message-----
> From: Martin Willi [mailto:mar...@strongswan.org]
> Sent: Tuesday, December 01, 2009 11:27
> To: Dan Harkins
> Cc: Yaron Sheffer; ipsec@ietf.org
> Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
>
> Hi Dan,
>
> > 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.
>
> EAP authentication was not primarily included in IKEv2 to implement some
> kind of password authentication on top if IKEv2, but to reuse existing
> EAP methods and infrastructure.
>
> The most demanding user of IKEv2 currently is the mobile/telco industry;
> There are several specs in 3GPP and 3GPP2 using it. Many of them have
> chosen IKEv2 because they can use their existing EAP-AKA/SIM
> infrastructure for authentication.
>
> > It seems to me that EAP-only authentication in IKEv2:
> > 1. does not solve a general problem;
>
> It does. It allows to omit public key authentication in cases where
> mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2
> spec that already uses EAP-AKA/TLS only authentication, but does not
> follow this draft. I really see a need for this WG item.
>
> > 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
>
> If you're just talking about password authentication, yes. But this
> allows IKEv2 to work in existing infrastructures (EAP over
> RADIUS/DIAMETER). We currently see a strong demand for such solutions.
>
> > To provide the benefits of EAP-only authentication [...] it would be
> > much better to support the inclusion of "Secure PSK authentication" as
> > a work item.
>
> Implementing password authentication on top of EAP may be one reason for
> this draft, but there are several others. And the separated EAP layer
> allows you to forward authentication to an existing AAA server.
> Further, many vendors already have generic EAP support. Implementing PSK
> authentication on top of it is probably simpler and more flexible than
> integrating it in IKEv2 directly.
>
> Best regards
> Martin
>
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
