Hi Tero,
I think you are too quick to dismiss the option of using EAP-only for
site-to-site and transport deployments, where the EAP state machine is embedded
into the IKE endpoint. For people who already have client-side EAP, this is not
adding a lot. It's not as efficient as tailor-made password authentication in
IKE, but OTOH it is much more generic.
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Tuesday, December 01, 2009 15:04
> To: Yaron Sheffer
> Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org
> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication
> (SPSK) - NO
>
> Yaron Sheffer writes:
> > I'm sorry, but you are misstating the difference between the
> > proposals. One is adding a notification and eliminating one existing
> > (certificate) check; the other is adding an IKE mode, and changing
> > the protocol state machine in the process.
>
> Not true.
>
> Both are adding new IKEv2 authentication mode.
>
> In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also
> makes it so that server DOES NOT need to have certificate and public
> key, meaning it does not send it s first AUTH payload in message 4.
>
> The main benefit from this is that the server DOES NOT need to have
> private key.
>
> (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt)
>
> We currently already have 4 authentication modes.
>
> Client Server
> 1) Shared key Shared key
> 2) Public key Shared key
> 3) Shared key Public key
> 4) EAP Public key
>
> EAP only will add one more:
>
> 5) mutual-EAP mutual-EAP
>
> and SPSK will add one more:
>
> 6) Password Password
>
> > Regardless of all the other pros and cons, the proposals are clearly
> > not comparable as far as changing the protocol.
>
> The changes required for EAP only might be smaller, but testing effort
> for both of them is same, except EAP only really requires you to test
> with all supported mutual key generating EAP methods (and also test
> with others and make sure they are not accepted).
>
> One thing I think most of you are missing is that their usage
> scenarios are COMPLETELY different.
>
> EAP-only can be used when there is clear client-server setup, existing
> EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there
> is no certificates or shared keys in use at all. This setup is
> asymmetric, one party (the user) always initiates the connection. SPSK
> cannot be used in such setup, as there is no password it can find.
>
> SPSK can be used when there is requirement for host to host (or site
> to site) connection, where either end can initiate traffic and
> exchanges and where entities still want to use passwords instead of
> public keys to authenticate. Shared keys could be used there, but in
> most setups the shared keys used in those scenarios are not strong
> enough to be resistant against dictionary attacks. EAP-only cannot be
> used there as this is not client-server setup. In these setup the
> authentication needs to be symmetric.
>
> For this reason I do not think we need to decide to take on or the
> other, we can take both as I do see use for both of them.
>
> If I would need to select one, I would select SPSK, as that is
> something which cannot be done by IKEv2 now.
>
> EAP-only is an optimization (both in protocol level, and especially in
> adminstrative level) for the existing EAP-Public key authentication.
> --
> kivi...@iki.fi
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
