Re: Clarification of EAP authentication in IKEv2?

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

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
>