comments on ikev2 05 (cryptography)

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

I have several remarks on the ikev2 draft version 05.
Most of them are just editorial.
I will send those in a separate message.

Here I point out to two main issues related to the cryptographic design
of IKEv2.  None of these issues is new but rather reflect "negative progress"
relative to what we agreed over the list (the first issue) or what already was 
in version 04 (the second issue).  Fixing these issues involves no added complexity 
(in some cases it is actually a simplification).
Don't be surprised if you feel this message as just a familiar deja vu...

First Issue: Macing the identity.
===========

The text we agreed upon was (this text appears in my message to the list 
on Jan 23rd, Charlie's agreed to it in his response message; there were no
objections in the list).

   4.15 Authentication of the IKE-SA

   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.  Appended to this (for purposes
   of computing the signature) [are] the initiator's nonce Ni (just the
   value, not the payload containing it), [and a value MIDr computed as
   prf(SK_ar,IDr). Note that neither the nonce Ni or value MIDi are
   transmitted.]  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.
   Appended to this (for purposes of computing the signature) [are] the
   responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)].

Note: The text between [...] denotes the suggested changes relative to 
      version 04; the terms MIDi,MIDr can be omitted as they are not
      referred to in other parts of the spec.

Instead of this, the text of 05 changes the values MIDr=prf(SK_ar,IDr) and
MIDi=prf(SK_ai,IDi) with the contents of payloads IDr and IDi, respectively.

I have no idea what motivated this change.  I guess that Charlie convinced 
himself (or someone convinced him) that putting the identities under the 
signatures achieves the same effect as adding the MAC (or prf) of the 
identities as we agreed earlier.  THIS IS WRONG.
The added identities do NOTHING to solve the issues that motivated the
addition of the values MIDi and MIDr. Actually, adding the plain identities
(as done in 05) inside the signature has no real cryptographic advantage.

Recall that the problem in 04 was that the design was susceptible to
seemingly "innocent changes" to the protocol that actually render the
protocol insecure. One such potential change, illustrated very clearly 
with the initial design of the SLA protocol, is moving the signature 
to a message that is not covered by the SK{} transform (in SLA the 
responder's signature was moved to message 2 which cannot be encrypted 
and then one cannot apply SK{} to it).  This strips the responder's identity 
from the protection of the outside MAC provided by SK{} and makes the protocol 
insecure by opening it to authentication attacks ("identity misbinding").  
As I pointed out, this problem is easily resolved by including the 
MAC OF THE SIGNER'S IDENTITY inside the signature. 
All of this, which may be very counter-intuitive at first glance,
is explained in full detail in my sigma paper (to which I referred here 
repeatedly in relation to this and other ikev2 design issues).
Moreover, if you read that paper you will see that the solution in 05, 
i.e.  putting the signer's identity (instead of its MAC) under the 
signature does nothing to prevent the authentication attack.
Indeed, the same attacks that are possible without the identity inside 
the signature are possible also if you include the identity.
The point is in MACing THE IDENTITY as provided by the MIDi/r values
in my original proposal.

The other vulnerability of the design in 04 was that if one does not transmit the 
identity of the responder in message 4 (for example, by moving it to message 2), 
or similarly if one omits the transmission of the initiator's identity from message 3
then (again) the authentication features of the protocol are broken. 
(Yes, this is explained in the sigma paper too :).
It may seem at first glance that incorporating the identity of the signer 
under the signature solves this problem.  This is wrong too. 
Also in this case the authentication of the protocol is broken (even 
with the SK{} transform covering the signature).
In contrast, the inclusion of the MACed identity solves this problem too
by freeing the security of the authentication from the actual positioning
of the transmitted identity and from the need to apply SK{} on top of the
signature. (The SK{} is still needed for identity hiding and for authenticating 
the piggybacked CHILD-SA elements, SA2 and TS.)

Therefore, PLEASE PLEASE PLEASE, go back to our agreed solution: instead of
adding the signer's identity to the signed data, add to it the MAC of this
identity.

I do not see room for controversy here, but if anyone objects to this please send your
rationale to this list (preferably after reading the full rationale for these changes in
the sigma paper).


Second issue: adding g^ir to the prf+ derivation
============

The key derivation presented in 05 is:

     SKEYSEED = prf(Ni | Nr, g^ir)

       {SK_d, SK_ai, SK_ar, SK_ei, SK_er}
                 = prf+ (SKEYSEED, g^ir | Ni | Nr | SPIi | SPIr )

The key derivation in 04 was the same except that g^ir was not included.
The "benefit" of including g^ir under prf is that the DH key randomizes each
of the iterations of prf under the prf+ definition, thus providing seemingly
better (heuristic) security.
The drawback is that the inclusion of g^ir eliminates the mathematical
support behind the use of a prf. As I explained in the past: since SKEYSEED 
is derived from g^ir then the (circular) construction 
prf+(SKEYSEED, g^ir ....) cannot be formally claimed to be secure.

This (in contrast to the MAC(ID) issue above) may not have immediate
practical consequences since the standard candidates for prf (such as 
HMAC-SHA1 or AES) do not necessarily break when g^ir is included under prf+.
On the other hand, the alleged benefit of including g^ir has no practical 
relevance at all. Indeed, the supporters of this inclusion 
in the past have argued that this is necessary to avoid "reducing"
the strength of the derived keys to the strength of the prf. 
This, however, is a misleading argument since the keys derived later
via the KEYMAT mechanism are still NO STRONGER than the prf. 
Indeed, this derivation uses the same prf keyed with SK_d and thus is 
no stronger than the prf even if we used g^ir as an argument to prf+ 
when deriving SK_d.

Furthermore, we do not need the key derivation to be stronger than the
crypto algorithms for which these keys are used (e.g. in ipsec).
Thus the best you can do is to choose a prf that matches the strength of
these algorithms, and that's what  HMAC-SHA1 or AES give you.
And for those that 128 or 160 bits of strength are not enough:
you can use HMAC-SHA-256 as the prf (but then don't forget to match it with 
DH exponents of 16000 bits [draft-ietf-ipsec-ciph-aes-cbc-0x.txt]).

Bottom line: by including g^ir under prf+ we loose the theoretical soundness
without any practical gain. Not a wise tradeoff.

Security Considerations
=======================

One thing that is clear from the above issues (especially the first)
is that the cryptographic design of IKEv2 is not well understood.
This was a big problem with IKEv1 too and led to a lot of misunderstandings
over the years (and even unfounded "rumours" of insecurity). 
To some extent, I take  personal responsibility for this situation for never 
documenting this rationale. Now, somewhat too late for IKE but on time 
for IKEv2 I have written the sigma paper to document this rationale (and a more
mathematical paper with Ran with a rigorous analysis of these protocols).  
This rationale is too involved to be added as part of the ikev2 document,
instead I do ask that the security considerations section provides 
a pointer to the sigma paper (whose coming revision will also include the
rationale for the prf+ based key derivation). 
There could be the option, in principle, of making an ascii (ietf-friendly)
version of the paper for publication as an i-d (or informational RFC) but 
that's probably a lot of work and I am not sure that an ascii version 
of such a paper will have any advantage to a publicly available pdf or 
postscript versions (does the ietf allow to publish rfc's in pdf/ps format?).

Finally one more comment on the security considerations text establishing that:

   The strength of a key derived from a Diffie-Hellman exchange using
   any of the groups defined here depends on the inherent strength of
   the group, the size of the exponent used, and the entropy provided by
   the random number generator used. Due to these inputs it is difficult
   to determine the strength of a key for any of the defined groups.
   Diffie-Hellman group number two when used with a strong random number
   generator and an exponent no less than 160 bits is sufficient to use
   for 3DES.  Groups three through five provide greater security. Group

I do not agree that 160 bits are sufficient for use with 3DES given that these
exponents allow for a full break of the DH exchange in 2^80 operations. I would
suggest a minimum of 180 or even 200 bits.

Hugo