Re: Clarification of EAP authentication in IKEv2?

[Jari Arkko <jari.arkko@kolumbus.fi>]

Hugo,

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

I may be missing something obvious here, but I do not understand
how the attacker forges the necessary AUTH payloads.

At the end of the whole EAP authentication run you are supposed
to use the AUTH payloads, based on a shared secret derived during
EAP authentication. Section 2.16 says:

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

And Section 2.15 in turn says:

    ... the peers
    are authenticated by having each sign (or MAC using a shared secret
    as the key) a block of data.  For the responder, the octets to be
    signed start with the first octet of the first SPI in the header of
    the second message and end with the last octet of the last payload in
    the second message. ...
    Similarly, the initiator signs the first message, starting with the
    first octet of the first SPI in the header and ending with the last
    octet of the last payload.

My interpretation of this is that the AUTH payload will authenticate
the first two messages sent by the peers. These contains the Diffie-
Hellman payloads, so the MITM's attempt to change them would be
detected, or? Note that the MITM would not have access to the shared
secret generated by EAP.

Having said this, the text in the draft does raise some questions
that had no immediately obvious answers, at least not to me. Could
be the heavy christmas food, but I wondered about the following:

- Why does 2.15 say "when not using extended authentication" but
   still 2.16 refers to 2.15?

- The beginning of 2.15, does it talk about only the *signature*
   case, or is shared secret MAC case included? It does not make
   sense to me that the two cases would sign different data, but
   the formula for shared secret case in 2.15 does not include
   the appended nonces and prf SK_a[ir]. Is this intentional?

- What are the "message octets" defined in the 2.15 shared
   secret case formula? Are they the same message octets and
   additional data as is talked about in the above text? Or
   different?

> Therefore (and this is why I am cc-ing Charlie directly) we really need a
> better text in 2.16.

I agree.

--Jari