RE: Clarification of EAP authentication in IKEv2?

[Pasi.Eronen@nokia.com]

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

> -----Original Message-----
> From: ext Hugo Krawczyk [mailto:hugo@ee.technion.ac.il]
> Sent: Wednesday, December 24, 2003 10:35 PM
> To: Eronen Pasi (NRC/Helsinki)
> Cc: IPsec WG
> Subject: Re: Clarification of EAP authentication in IKEv2?
> 
> 
> Pasi,
> 
> what you suggest as the right interpretation of the text in 2.16
> is actually a TOTALLY INSECURE protocol.
> As Michael Richardson wrote:
> 
> > An EAP method that provided mutual authentication would 
> > authenticate the EAP authenticator, not the IKEv2 responder.
> >
> > I do not think that we provided EAP<->IKEv2 channel bindings.
> 
>
> More precisely, without the signature-based authentication by
> the responder there is NO authentication at all of the DH
> values from which the ipsec's traffic keys are derived.
>
> Specifically, by skipping the signature authentication, the
> protocol is open to a classic m-i-t-m attack: The attacker
> sits between I and R, sending its own chosen KEr' to I and its
> own chosen KEi' to R.  Let's call Ki the DH key produced by
> the values KEi (legitimately chosen by I) and KEr', and call
> Kr' the key produced from the values KEr (chosen by R) and
> KEi'. Now, I and R follow the EAP protocol but I "protects"
> the EAP exchange using Ki while R "protects" the exchange
> using Kr. The attacker receives each of the EAP msgs from I
> and R, decrypts them using the keys Ki and Kr, respectively,
> and forwards them to the intended recipient after
> re-encrypting (and MACing) the message with the key Kr and Ki,
> respectively.
>
> As a result, the EAP authentication succeeds at I and R, but
> now the intitator derives the session keys from Ki while R
> derives them from Kr.  Both keys are known to the attacker!
> 
> Therefore (and this is why I am cc-ing Charlie directly) we
> really need a better text in 2.16. One that says explicitly
> that the signature by the responder (payload AUTH in the forth
> message) is mandatory (in particular, a MUST for security). It
> may also be worth noting explicitly that the EAP extensions to
> IKEv2 are intended ONLY to provide extensible methds for
> initiator authentication, and NOT for responder's
> authentication.
> 
> As a side note, if one wants to be able to use EAP-generated
> keys directly for ipsec's key generation, that is possible
> too, but requires a DIFFERENT mechanism. In any case,
> providing such a mechanism has never been a stated goal in
> IKEv1 (and its ipsra extensions) or IKEv2.
> 
> Finally, re-reading the text of section 2.16, I find the
> following text a bit confusing:

>   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 an AUTH payload using the
>   syntax for shared secrets specified in section 2.15. This
>   shared key MUST NOT be used for any other purpose.
> 
> It would be worth clarifying that the AUTH payloads referred
> to in this paragraph are those included in msgs 5 and beyond
> (not the AUTH payload of message 4). Also, I would re-phrase
> the last sentence as
> 
>   This EAP-generated shared key MUST NOT be used for any 
>   purpose other than the generation of these AUTH payloads.
> 
> Hugo
> 
> PS: Seeing how easily secure protocols can be turned insecure
> by small changes or interpretations, it may be worth
> explaining (maybe in the sec considerations section) the
> following point: While in the regular IKEv2 exchanges,
> encryption (under the SK{} construct) is needed only for
> privacy issues (such as identity protection), in the case of
> the protocol in section 2.16, encryption is an integral part
> of the cryptographic authentication of the exchange. IN
> particular, if someone, one day, wants to get rid of the
> encryption is the SK{} construct and leave only the MAC, that
> would leave ikev2 main exhcnages secure, but would turn the
> EAP extensions totally insecure. [For those interested in the
> technical aspects of the cryptographic design of this protocol
> see http://citeseer.nj.nec.com/halevi98publickey.html]
> 
> On Thu, 18 Dec 2003 Pasi.Eronen@nokia.com wrote:
> 
> > (I'm sending this again, since for some reason my
> > post on Tuesday didn't come through.)
> >
> >
> > Hi,
> >
> > IKEv2-11, Section 2.16 says:
> >
> >  In addition to authentication using public key signatures and
> >  shared secrets, IKE supports authentication using methods
> >  defined in RFC 2284 [EAP]. Typically, these methods are
> >  asymmetric (designed for a user authenticating to a server),
> >  and they may not be mutual. For this reason, these protocols
> >  are typically used to authenticate the initiator to the
> >  responder and are used in addition to a public key signature
> >  based authentication of the responder to the initiator.
> >
> > Recently, some people have interpreted the last sentence as
> > "public key signature based authentication of the responder
> > MUST be used".
> >
> > Another possible interpretation is that _typically_ the responder
> > is authenticated with public key signatures (for the reasons
> > given earlier in the paragraph), but other alternatives (such
> > as EAP method that provides mutual authentication, or even
> > shared secret) may be possible in some circumstances.
> >
> > Any comments?
> >
> > Personally, I support the latter interpretation; since otherwise
> > only initiator authentication is extensible, not responder
> > (and I think this would be an unnecessary limitation... after all,
> > if the point of EAP is to allow users to choose an authentication
> > method that best suits their needs, why should this be limited
> > to initiator authentication?).
> >
> > This could be perhaps clarified by adding the following
> > paragraph below the sequence diagram:
> >
> >  If the authentication of the responder is based solely on a
> >  mutually authenticating EAP method, 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.
> >
> > Best regards,
> > Pasi
> >