RE: Clarification of EAP authentication in IKEv2?

[Pasi.Eronen@nokia.com]

Hugo Krawczyk wrote:
> 
> 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!

Yes, you're right in that putting the EAP messages inside SK{}
does not achieve much without signatures (except possibly some
identity privacy against passive eavesdroppers).  However, the
EAP methods which are likely to be useful in this situation are
ones that don't require that envelope: they were designed to run
without it in e.g. wireless LANs.

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

It's quite clear that without the signature, the initiator at
this point (before the AUTH payloads with EAP-derived keys) does
not know who is the other party it shares SK_e with.  But, as
the EAP methods were designed to be useful even without any
encryption (during the EAP exchange), I don't think this false
sense of security is very important.

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

Yes, if the responder is not authenticated before starting EAP,
he can clearly forward the EAP messages to somewhere else
(assuming the same credentials make sense in some other context:
and this is more of a deployment issue). This is quite normal in
EAP: for instance, the wireless LAN access point (or whatever)
is not authenticated before starting EAP.

However, this does not allow a successful "MitM" attack: sure,
the attacker pretending to be an IKEv2 responder can forward the
EAP payloads to, for instance, a wireless LAN access point;
however, both conversations (IKEv2 and 802.11i) will eventually
fail because the attacker doesn't know the key established by
the EAP method.

(I'm assuming that the EAP method does mutual authentication and
establishes a key. Clearly several attacks are possible for EAP
methods that don't do this.)

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

This would be very complex (since some values for SK_a/SK_e are
needed before the EAP method is finished), and in my opinion,
the wrong approach. I believe it's much better to derive
SKEYSEED the way it's currently done (with DH), and just 
use EAP to authenticate the Diffie-Hellman values and nonces 
(via AUTH payload).

This approach is quite simple, it works (with good EAP methods),
and has some nice properties like PFS.

If the WG consensus is that the base IKEv2 spec must prohibit
this, I guess the easiest "extension" would be to specify a new
Notify payload value (e.g. EAP_ONLY_AUTHENTICATION_SUPPORTED); 
if the initiator would include this in message #3, the responder 
would know that skipping public-key/shared secret authentication 
is ok.

Best wishes for the New Year,
Pasi