Re: Secure legacy authentication for IKEv2

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

"In principle" this sounds correct (up to an authentication
problem in message 2 that I hinted to in a previous message but which is
orthogonal to the issues related to EAP authentication). 

At the more specific level, I recommend that you follow PIC in its use and
specification of EAP exchanges. They were designed by two knowedgeable
guys: Yaron Sheffer and Bernard Aboba who I believe will be willing to
help here. In order to utilize PIC in the SLA context you need to:

(1) format messages 1 and 2 according to IKEv2 payloads 
(2) refer to IKEv2 for key derivation
(3) use HDR* in the sense of IKEv2 (thus no need for the HASH payload in
messages 3 and 4 that PIC uses)
(4) eliminate the credential-request and credential payloads used in PIC.

Hugo

PS: Question: you say that the SLA exchange with EAP must have 6 messages
at least. Aren't there EAP methods where the server (responder in SLA)
sends its challenge already in the first EAP message? In this case the
whole SLA exchange can be completed in 4 msgs rather than 6.

On Sat, 21 Dec 2002, Derrell Piper wrote:

> 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.
> 
>