Re: Secure legacy authentication for IKEv2

[Derrell Piper <ddp@xxxxxxxxxxxxxxxxx>]

Hugo,

I think I was the main opponent to using EAP, but I'm willing to 
concede this point if it helps get us to consensus.  I see now that 
using EAP is cryptographically no worse than what we proposed with SLA 
(see other thread) and you make some good arguments here for its 
adoption (as do others).

Note that SLA proposed a strict client-directed authentication 
exchange.  For each client request, the server's response either 
completed the exchange or contained an additional challenge.  The SLA 
protocol did not allow for negotiation of the LAM type (without 
restarting the exchange).  This was chosen primarily so that the client 
could aggressively send his credentials in message three.  RFC2284 
(EAP) instead implements a request/response protocol run by the 
responder ("authenticator" in RFC2284) and allows for flexibility in 
authentication type negotiation (the client can "nak" the requested 
type and request something else).

So here's a fairly straightforward substitution of EAP for CHRE in SLA:

We'll need to define an EAP payload:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Next Payload  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                           EAP Packet                          ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Critical Bit MUST be set in all EAP payloads.  The EAP Packet and
  its contents are defined in RFC2284.

The first two messages remain almost the same as for SLA.  The response 
from the gateway now also includes the EAP identity request and begins 
the EAP protocol.  Note that this is only a request; identity 
protection for the client is not compromised if the server 
authentication fails.

Initiator (client)					Responder (gateway)
------------------					-------------------
HDR, SAi1, KEi, Ni				-->
							<--  HDR, SAr1, KEr, Nr,
								  EAP(Request/Identity), AUTH

The responder's AUTH payload is computed over all of message one 
concatenated with all of message two.  Because the contents of the AUTH 
payload cannot be known when creating the concatenation, a dummy AUTH 
payload is constructed which consists of the payload header that would 
have been used (including a correct length field), but with each octet 
of the contents set to 0x0.

The client MUST both verify the signature as being valid for the 
gateway's public key as well as verify that the signed exchange matches 
the actual data sent by the client in the first message.

Message 3 contains the EAP identity response:

HDR*, SAi2, TSi, TSr,
  EAP(Reply/Identity)			-->

Message 4 through message N-1 have the following format and essentially 
define a challenge/response exchange between the gateway (acting as an 
RFC2284 "authenticator") and the client (an RFC2284 "peer"):

	HDR*, EAP(n)

Message N is the last message, and MUST come from the responder.  If 
the responder successfully authenticates the initiator, message N is:

                                   <--	HDR*, EAP(SUCCESS),
									  SAr2, TSi, TSr

If the responder does not successfully authenticate the initiator, 
message N is:

                                   <--    HDR*, EAP(FAILURE)

Best case we complete the exchange in six messages vs. four for CHRE in 
SLA.  (NB: this is still a whole lot better than the nine or ten 
required for IKEv1 when using a standard MM/QM exchange).  Note also 
that the even number of messages defined here plays well with IKEv2's 
retransmission policy (c.f. IKEv2 (03) Section 4.1).

Derrell

On Friday, December 20, 2002, at 05:30 PM, Hugo Krawczyk wrote:

> It is up to the "legacy authentication" community to come up with 
> solutions to
> these problems (which arise from the essentially-insecure use of 
> credentials
> in mixed protected/unprotected environments). Moreover, if you support 
> EAP
> exchanges and the EAP community comes up with measures to alleviate 
> these
> attacks in the context of EAP then you get the benefits of this 
> solution
> automatically. If you do CHRE then you don't.
>
> That's a good reason to support EAP in SLA.
>
> And it is not the only benefit:
> There is a lot of deployment of EAP and the definition of 
> authentication
> mechanisms over EAP can be (and is) done independently of IKE.  In my
> view, it is better to leave these definitions in the hands of people
> (such as the EAP WG) that specifically care about transport of client
> authentication. If you rely on EAP then all you have to care about is 
> to
> build a sound tunneling mechanism for EAP in the context of IKEv2
> (rather than building profiles that depend on the specifics of 
> secure-id,
> radius, etc.) And, as said, the EAP guys are better suited to take 
> care of
> problems in the "legacy authentication" world such as the above "man 
> in the
> middle attacks" against tunneled authentication that have been a 
> concern
> lately in this community.
>
> And adopting EAP into SLA is easy, just copy PIC.