Re: Possible problem in IKEv2?

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

The solution proposed by Pasi seems fine except that instead of using a
dummy key to compute the AUTH value by the initiator why not specify (in
sec 2.16):

   "For EAP methods that do not establish a shared key, the AUTH value
    will be computed using the negotiated integrity algorithm keyed with
    the key SK_ai."

Cryptographically speaking a MAC or PRF keyed with a fixed dummy string
(say all 0's) may be, in principle, very weak and easily forgeable. SO why
not use the available key SK_ai for integrity protecting the first msg via
the AUTH value? It is important, however, that the same integrity
algorithm used under the SK{} construct (which already uses SK_ai)
be used for computing the above AUTH value.
Do you see any problem with this solution?

BTW, in passing I noted the following sentence in sec 1.2:

   The Initiator [...] integrity protects
   the contents of the first two messages using the AUTH payload (see
   section 2.15).

In the current specification of ikev2 AUTH as computed by the intiator
only protects the first msg (while the responder's AUTH protects the
second msg). I suggest to rephrase accordingly.

Hugo


> You're right!
>
> While non-key-generating EAP methods are explicitly discouraged, it is
> likely people will use them and we should make the protection as good as
> we can. The AUTH payloads have two purposes in the cryptographic
> exchange: to authenticate the parties and to protect the first two
> messages from modification. These functions could have been provided
> independently, but they weren't.
>
> The threat here is that a man-in-the-middle could trick IKE peers using
> a non-key-generating EAP method to use weaker cryptographic algorithms
> than the strongest that they both support. They would both have to be
> willing to use the weaker cryptographic algorithms, and if the attacker
> can break the weaker algorithms in real time (during the exchange) then
> there is no way we can defend against it. So this is clearly a fringe
> case.But we've engineered for much more fringe cases than this in the
> past.
>
> I can think of a number of ways of fixing this, but yours has the virtue
> of minimizing word changes to the spec and lines of code to an
> implementation. This is very late in the process to be making
> cryptographic changes, but I feel like this one is worth doing.
>
> **Can I get a ruling from our chairs?**
>
> 	--Charlie
>
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of
> Pasi.Eronen@nokia.com
> Sent: Friday, October 31, 2003 1:50 AM
> To: ipsec@lists.tislabs.com
> Subject: Possible problem in IKEv2?
>
> Hi,
>
> When using a non-key-generating EAP method, the initiator never
> generates any AUTH payloads. In this case, KEi/Ni are authenticated
> implicitly (by the ability to provide correct EAP Responses
> that are protected with SK_ai). However, it seems the client's
> AUTH payload has a second purpose as well: to provide integrity
> protection for the first message.
>
> Ifthe initiator never generates an AUTH payload, is there anything
> that prevents an attacker from, e.g., removing some proposals
> from SAi1? (Or modifying some other payloads than KEi/Ni in the
> first message?)
>
> (Or have I missed some detail of this?)
>
> If this is indeed the case, I think the easiest solution would be
> to always include the AUTH payloads; if the EAP method does not
> generate keys, use some known fixed string (such as a single zero
> octet) as the key. Since the AUTH payload is protectedby SK_ai,
> this should ensure that the first message was not modified (by
> someone who doesn't know the initiator's private DH value).
>
> Best regards,
> Pasi
>
>