Scott, thank you. How dense of me! Doubling the work effort is equivalent to adding one bit to the effective strength, not doubling the number of bits.
Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: "Scott Fluhrer" <sfluh...@cisco.com> To: Scott C Moonen/Raleigh/i...@ibmus, <ipsec@ietf.org> Date: 06/29/2009 01:01 PM Subject: RE: [IPsec] guidelines for choice of D-H group From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott C Moonen Sent: Monday, June 29, 2009 12:30 PM To: ipsec@ietf.org Subject: [IPsec] guidelines for choice of D-H group RFCs 4753 and 5114 provide vague recommendations for choice of Diffie-Hellman group relative to symmetric key sizes. They don't specifically address how to look at a set of chosen SA encryption and authentication algorithms and arrive at a choice of suitable Diffie-Hellman group, nor do they address the use of PFS. So: 1) For the IKE SA, the Diffie-Hellman operation generates two encryption and two authentication keys. Should the Diffie-Hellman strength generally be equivalent to the longest key length, or to the sum of the key lengths? If we sum up all four symmetric key lengths, most choices will exceed the strength provided by the currently available Diffie-Hellman groups. But if we don't sum up the symmetric key lengths, then we are making Diffie-Hellman the weakest link in the chain (i.e., we aren't obtaining significant added value by generating different values for each of SK_ei, SK_er, SK_ai, SK_ar). Which is the case? It's pointless to make it much stronger than the longest key, as each individual symmetric key can be attacked separately. For example, suppose that SK_ei was an 128 bit AES key; the attacker could recover that key by finding a packet encrypted with that key, and do a trial decrypt based on successive keys, and stop when he finds a key that makes a plausible plaintext. The important point is that he can do this without knowing what the other keys SK_er, SK_ai, SK_ar are, and so those other keys don't add to the security in this specific attack. More generally, suppose the attacker is able to recover SK_ei with effort A (for example, if AES-128 is being used, and we're using brute force to recover the key, then A=2**127 decrypt operations expected), and similarly SK_er, SK_ai, SK_ar can be recovered with efforts B, C, D, then the time taken to recover all four is A+B+C+D, which is no more than 4 times the largest of the four (and this is assuming that the attacker is actually interested in all four, which is generally not the case). 1b) In any case, we don't have suitable Diffie-Hellman groups for use with HMAC-SHA2-384 and HMAC-SHA2-512. Interestingly, the upcoming NIST and DoD standards push into the realm of 256-bit symmetric algorithms (HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes group 19 a MUST). Do the folks from DoD or NIST have any comments on this disparity? 2) If we are recommending parity between symmetric algorithms and DH group choice, is there any place that we are also recommending the use of perfect forward secrecy to guard against weaknesses there? Not using perfect forward secrecy goes even further to make the Diffie-Hellman the weakest link in the chain. And yet RFC 4308 does not require PFS, and NIST's own RFC 4869 doesn't even mention it. Do the folks from NIST have any comments on why PFS is not mandated, let alone mentioned, in RFC 4869? 3) IKEv2 does not allow perfect forward secrecy for the first child SA. Similar to question 1 above, how does that play into the recommendation for DH group size to choose? Admittedly, there probably isn't much lost if the IKE SA keys are compromised. So should we look only at the child SA symmetric key sizes when considering what IKE SA DH group is appropriate? Or should we sum up the IKE and child SA symmetric key lengths? Same answer to the last question: the IKE and the IPSec SA keys can be attacked separately, and so making the DH stronger than the longest individual key doesn't gain you anything from a security standpoint. -- scott
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
