[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clarification of EAP authentication in IKEv2?



Jari and Pasi,

Jari is right that the mitm attack as I described will not work
in the case of mutually-authenticating AND key-generating EAP methods
since in this case the AUTH payloads (sent at the end of the EAP exchange)
are calculated over the KE values and then serve to authenticate these
values. (I was wrongly assuming that AUTH was computed on the EAP messages).

Yet, I would strongly oppose the interpretation (and text) offered by Pasi
that the responder's signature (and its verification by the intitiator) can
be skipped in an ikev2-compliant implementation. Doing this opens the
protocol to dangerous uses, including some (other) forms of mitm.

The basic observation here is that in a signature-less run of the protocol
the whole envelopping of the EAP messages under the SK_e and SK_a keys is
completely meaningless since the authentication of the DH values (from
which SK_e and SK_a are derived) comes only at the end of the (EAP) protocol.
At that point the initiator may discover that it was "protecting" its
exchange with an attacker-generated SK_e key!

Moreover, this envelopping gives a false sense of security which can easily
lead applications to, for example, send sensitive information as part of the
exchange assuming its protection under SK_e.
As a more immediate threat, what this signature-less version of ikev2 is
doing is to allow the same Asokan-Niemi-Nyberg mitm attacks (in reverse
direction) that the key-generating EAP extensions of ikev2 were designed to
avoid, namely, the "stealing" of EAP runs from one context to another.
Specifically, by impersonating a signature-less responder in the IKE exchange,
the attacker can trick an initiator, that is willing to run the EAP method
in a IKEv2-context only, to participate (without its knowledge) in an
external (i.e., non-ikev2 protected) run of the protocol using the same
credentials and same EAP method.

For those that want to use a full-fledge key-generating EAP exchange in IKE
(e.g., Pasi), I propose to develop a (simple) extension to IKEv2
authentication in which the key generated by the EAP method is used to
generate a value for SKEYSEED from which the pertinenet SK_e and SK_a keys
are derived, and then use these keys directly in a CREATE_CHILD_SA exchange.
This is the simplest extensibility approach for IKEv2 (but be careful about
the details...).  And just in case someone is misunderstanding my intention:
I am NOT suggesting that this extension be part of the basic IKEv2 document!!

Hugo