[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2: SA attribute processing rules
William:
>The following topics are addressed in this mail for IKEv2:
>
>A.) How to handle unrecognized attribute types
>B.) Gap in private use range
>C.) Regarding how we indicate "mutually consenting parties" - vendor ID
>can't be used.
>D.) No real clarification on SA attribute handling
>E.) Implied requirement for 1536, should be 2048 or 3072.
>F.) Be clear what fails the negotiation and what doesn't.
I agree with the bulk of your comments. However, I do want to respond to
item E.
>E.) Implied requirement for 1536, should be 2048 or 3072. The example
>suite given suggests that DH1536 would be a "default". It doesn't say
>whether it's a MUST support. I think we need something greater than
>DH1024, but why does IKEv2 need to specify it ? Given the strength
>calculation in Tero's MODP draft, DH1536 supports by one calculation
>only 90bits entropy, which is still much less than 3DES ~112bits entropy
>(from Schneier's Applied Cryptography) which is included in that suite,
>and insuffient for keying 128bit AES. So DH2048 or DH3072 should be the
>choice to ensure IKE DH is not the weakest point, and thus force the
>attack to the 3DES keys, which of course is being rekeyed far more often
>than the DH is generated in most cases.
There has been some discussion of this in a separate thread, but it has not
reached an obvious conclusion. However, I want to correct one aspect of
your description. Maybe you already understand this, and you used loose
wording, but I know that many people miss this important point.
If one wants, say, 80 bits of protection, then it is appropriate to select
mechanisms that each provide this level of protection, or more. Achieving
80-bit security would allow many choices:
Diffie-Hellman: 1024, 1280, 1536, 2048, and so on
Encryption: 3DES, AES-128, AES-192, AES-256, others
Alternatively, if one want 90 bits of protection, as you point out,
Diffie-Hellman with 1024-bit keys is no longer appropriate, but all of the
encryption algorithm alternatives are still viable.
One would not normally select a symmetric cipher that provides exactly
desired protection. There are not that many quality algorithms floating
around, each with different key sizes. Although there are a few that take
variable length keys, these are not the most widely adopted by teh IPsec
community. Further, it is not a good practice to roll your own symmetric
cipher. It is not likely to be secure, and even if it is secure, it is not
likely to be widely implemented. For this reason, one normally selects a
symmetric cipher that is well known, widely implemented, and provides
adequate performance. For this reason, I expect to see movement from 3DES
to AES-128. Not because 112 bits of security is problematic, rather
because AES is fast. More security and fewer cycles.
The Diffie-Hellman key size selection is different. One choose exactly the
desired level of protection, without the same interoperability
concerns. Yet, there is a huge performance penalty for selecting a bigger
key than necessary. Some hardware implementations may have a maximum
buffer size, and many of these will resort to software if the hardware
buffer size is exceeded. This means that there is a huge performance cliff
if the hardware buffer size is exceeded.
In summary, one should select the fastest, widely deployed, well studied
symmetric cipher that exceeds the security requirements; however, one
should select the Diffie-Hellman key size that provides the desired
security, and no more.
So, what should IKEv2 impose as the MUST implement Diffie-Hellman key
sizes? In my opinion, 1024 should be on the list for backward
compatibility with the currently fielded devices. Further, either 1280 of
1536 should be required. This allows us to move incrementally forward,
without imposing a huge performance hit. Of course, support for even
bigger keys is encouraged, but not required.
Russ