Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

[Yaron Sheffer <[e-mail]>]

Hi Dan,

I will not argue about the implementation complexity. Such arguments are useless in general, and I certainly cannot argue with your first-hand experience.

But EAP does solve, perfectly, the client-to-server use case. The password can be offloaded to AAA or not, depending on security and performance considerations. And multiple choices are available for the authentication method, depending on various criteria like performance, IPR, security strength and others.

To repeat what I'd already said, the "lying NAS" problem can be easily solved with channel bindings, and will (eventually) be solved. Adding a few protected fields to any particular EAP method is not a big deal.

Thanks,
	Yaron


> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Tuesday, December 01, 2009 22:04
> To: Yaron Sheffer
> Cc: Tero Kivinen; [e-mail]; Matthew Cini Sarreo
> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication
> (SPSK) - NO
> 
> 
>   Hi Yaron,
> 
>   EAP is a client/server protocol. If either side can initiate the
> exchange (necessary for site-to-site and transport) then each side
> will be required to implement BOTH the EAP client and EAP server
> state machines. "[P]eople who already have client-side EAP" will
> need to add server-side EAP to their IPsec client implementation
> and people who have server-side EAP today will need to add client-
> side EAP to their gateway implementation. You say it's "not adding a
> lot"; I disagree. Having written an EAP implementation (as well as
> 802.1x and several EAP methods) I can tell you it's a good sized
> chunk of code that needs testing and debugging.
> 
>   Doing what you propose means:
> 
>      1. no AAA server for off-load is possible since both sides need
>         to possess the shared secret and there is no AAA server in
>         the world that can _initiate_ EAP.
>      2. the EAP encapsulation serves no purpose since the conversation
>         is just between the two peers.
>      3. it takes twice as many messages.
>      4. it involves a pointless exchange of identities which brings up
>         further complexity in the case when the identity in the EAP
>         exchange differs from the one in the IKE exchange. You'll need
>         to check, what do you do and why?
> 
>   All this added complexity to a security product for what gain? Nothing.
> For the other use case-- true client/server-- the EAP-only proposal
> also has a security issue since the server can claim any identity it
> chooses and the AAA server terminating EAP will "authenticate" it.
> 
>   So for 2 uses cases it's pointless complexity and for the other use
> case it's got a security problem. Why is this a good idea? Because
> "this is not adding a lot"? That's like saying that dirt doesn't taste
> that bad without explaining why someone would want to eat dirt in the
> first place.
> 
>   Dan.
> 
> On Tue, December 1, 2009 5:17 am, Yaron Sheffer wrote:
> > 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:[e-mail]]
> >> Sent: Tuesday, December 01, 2009 15:04
> >> To: Yaron Sheffer
> >> Cc: Dan Harkins; Matthew Cini Sarreo; [e-mail]
> >> 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.
> >> --
> >> [e-mail]
> >>
> >> Scanned by Check Point Total Security Gateway.
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> 
> 
> Scanned by Check Point Total Security Gateway.