comments on ikev2 05 (cryptography)
Hugo Krawczyk <hugo@ee.technion.ac.il> Tue, 04 March 2003 01:44 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20538 for <ipsec-archive@lists.ietf.org>; Mon, 3 Mar 2003 20:44:39 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22932 Mon, 3 Mar 2003 18:38:44 -0500 (EST)
Date: Tue, 04 Mar 2003 01:42:07 +0200
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: IPsec WG <ipsec@lists.tislabs.com>
Subject: comments on ikev2 05 (cryptography)
Message-ID: <Pine.GSO.4.21.0303040141180.16458-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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
- comments on ikev2 05 (cryptography) Hugo Krawczyk
- Re: comments on ikev2 05 (cryptography) Charlie_Kaufman
- Re: comments on ikev2 05 (cryptography) Andrew Krywaniuk
- Re: comments on ikev2 05 (cryptography) Ran Canetti
- Re: comments on ikev2 05 (cryptography) Charlie_Kaufman
- Re: comments on ikev2 05 (cryptography) Hugo Krawczyk
- Re: comments on ikev2 05 (cryptography) Hugo Krawczyk