RE: Clarification of EAP authentication in IKEv2?

[Pasi.Eronen@xxxxxxxxx]

Hi Hannes,

I did rephrase some of the text for clarity (perhaps failing 
in that goal), but my intention was not to go beyond what I 
initially proposed. I guess the key paragraph is this one:

   The authentication of the responder can be based solely on an
   EAP method that provides mutual authentication and
   establishes a shared key. In this case, the responder omits
   the AUTH payload from message 4. Alternatively, the responder
   can be authenticated using either public key signatures or a
   shared secret, in which case the AUTH payload in message 4 is
   calculated as described in Section 2.15.

...and the part that might be misleading is probably the "can"
in the first sentence. Would something like this be better?

   If using an EAP method that provides mutual authentication
   and establishes a shared key, the responder MAY omit the
   normal IKEv2 authentication based on public key signatures
   (or shared secrets, not established with EAP). In this case,
   message 4 does not contain an AUTH payload. It is also
   permissible to use public key signatures (or shared secrets)
   in addition to EAP, in which case the AUTH payload in message 4 
   is calculated as described in Section 2.15.

Best regards,
Pasi

> -----Original Message-----
> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxxxxxx]
> Sent: Tuesday, December 30, 2003 2:05 PM
> To: Eronen Pasi (NRC/Helsinki); hugo@xxxxxxxxxxxxxxxxx;
> ipsec@xxxxxxxxxxxxxxxxx
> Subject: RE: Clarification of EAP authentication in IKEv2?
> 
> hi pasi, 
> 
> your current description seems to go beyond your initial
> proposal. It seems that this proposal addresses every EAP
> method which provides mutual authentication and generates
> keying material and replaces the public key based responder
> authentication (within IKEv2) totally with the EAP server
> authentication of the EAP method.
> 
> is the AUTH payload computed in such a way that it binds the
> Diffie-Hellman derived key and the key generated by the EAP
> method?
> 
> ciao
> hannes
> 
> > -----Original Message-----
> > From: Pasi.Eronen@xxxxxxxxx [mailto:Pasi.Eronen@xxxxxxxxx] 
> > Sent: Dienstag, 30. Dezember 2003 10:51
> > To: hugo@xxxxxxxxxxxxxxxxx; ipsec@xxxxxxxxxxxxxxxxx
> > Subject: RE: Clarification of EAP authentication in IKEv2?
> > 
> > 
> > Hugo,
> > 
> > Thanks for taking the time to look at this. The MitM attack 
> > you describe below is basically the same as identified by 
> > Asokan, Niemi and Nyberg in their "Man-in-the-middle in 
> > tunneled authentication protocols" paper.
> > 
> > It does not work in IKEv2 _if_ the EAP method also establishes 
> > a shared key (which is used to generate AUTH payloads).
> > 
> > Currently all EAP methods that provide mutual authentication 
> > also establish a shared key -- but the text I proposed didn't 
> > mention this explicitly (and I guess some hypothetical EAP 
> > method could violate it, though I don't know why anyone would 
> > do that). So, I agree the text should be clarified to mention 
> > that just mutual authentication is not enough -- the method 
> > must also establish a shared key for AUTH payloads.
> > 
> > BTW, Section 2.16 seems to have another small problem: the 
> > initiator (EAP peer) sends its AUTH payload (based on the 
> > EAP-generated key) first, in the same message as its last EAP 
> > payload.  However, in EAP the peer does not always know when 
> > the last EAP round has been reached (many EAP methods have a 
> > variable number of rounds, and in some of them, the peer does 
> > not know the last one in advance).  Also, currently it's (sort
> > of) assumed that EAP methods "export" established key only 
> > after the conversation has successfully finished (so 
> > including the AUTH payload when the "key becomes available" 
> > and continuing the EAP exchange after that doesn't work 
> > fine either).
> > 
> > Taking these (and your comments) into account, here is my 
> > proposal for Section 2.16 (replacing everything but the 
> > firsttwo paragraphs):
> > 
> >    An initiator indicates a desire to use extended
> >    authentication by leaving out the AUTH payload from message
> >    3. By including an IDi payload but not an AUTH payload, the
> >    initiator has declared an identity but has not proven it. If
> >    the responder is willing to use an extended authentication
> >    method, it will place an EAP payload in message 4 and defer
> >    sending SAr2, TSi, and TSr until initiator authentication is
> >    complete in a subsequent IKE_AUTH exchange.
> > 
> >    The EAP exchange ends when the Responder sends the Initiator
> >    an EAP payload containing either a success or failure
> >    type. The IKE_AUTH exchanges are completed by exchanging AUTH
> >    payloads, using the syntax for shared secrets specified in
> >    Section 2.15.
> > 
> >    For EAP methods that create a shared key as a side effect of
> >    authentication, that shared key MUST be used by both the
> >    Initiator and Responder to generate the AUTH payloads. This
> >    key MUST NOT be used for any other purpose than the
> >    generation of these AUTH payloads.
> > 
> >    For EAP methods that do not establish a shared key, the AUTH
> >    payloads are calculated using (TO BE DETERMINED; see below). 
> >    Such EAP methods SHOULD NOT be used, as they are subject to a
> >    number of man-in-the-middle attacks if these EAP methods are
> >    used in other protocols that do not use a
> >    server-authenticated tunnel. Please see the Security
> >    Considerations section for more details.
> > 
> >    The authentication of the responder can be based solely on an
> >    EAP method that provides mutual authentication and
> >    establishes a shared key. In this case, the responder omits
> >    the AUTH payload from message 4. Alternatively, the responder
> >    can be authenticated using either public key signatures or a
> >    shared secret, in which case the AUTH payload in message 4 is
> >    calculated as described in Section 2.15.
> > 
> >    In typical case, the initial SA establishment will appear  
> >    as follows. 
> > 
> >       Initiator                        Responder
> >      -----------                      -----------
> >       HDR, SAi1, KEi, Ni         -->
> > 
> >                                  <--   HDR, SAr1, KEr, Nr, [CERTREQ]
> > 
> >       HDR, SK { IDi, [CERTREQ,] [IDr,]
> >                 SAi2, TSi, TSr}  -->
> > 
> >                                  <--   HDR, SK { IDr, [CERT,] [AUTH,]
> >                                                  EAP(Request) }
> > 
> >       HDR, SK { EAP(Response) }  -->
> > 
> >                                  <--   HDR, SK { EAP(Request) }
> > 
> >       HDR, SK { EAP(Response) }  -->
> > 
> >                                  <--   HDR, SK { EAP(Success) }
> > 
> >       HDR, SK { AUTH }  -->
> > 
> >                                  <--   HDR, SK { AUTH, SAr2, TSi, TSr }
> > 
> >    The example above shows two EAP Request/Response pairs. The
> >    Initiator of an IKE_SA using EAP SHOULD be capable of
> >    extending the initial protocol exchange to at least ten
> >    IKE_AUTH exchanges in the event the Responder sends
> >    notification messages and/or retries the authentication
> >    prompt.
> > 
> > I left the case on non-key-generating EAP methods open, 
> > since while your proposal for using SK_ai/SK_ar looks good, 
> > how do we actually ensure that the algorithm is the same as 
> > used for integrity within the SK{} construct? They're 
> > negotiated separately... would using some public-but-random 
> > value like prf(Ni|Nr,"EAP") be ok, or do we need to derive 
> > one more key from SKEYSEED?
> > 
> > Best regards,
> > Pasi