Re: IKEv2: SA attribute processing rules

[Russ Housley <housley@xxxxxxxxxxxx>]

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