Comment on draft-ike-implementation regarding nonce size

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

   Nonce size is another characteristic that is neither negotiated nor
   announced but that the two ends must somehow be able to agree on.
   Our software accepts anything between 8 and 256, and defaults to 16.
   These numbers were chosen rather arbitrarily, but we have seen no
   interoperability failures here.

I don't understand your assertion that the two sides need to agree on the
nonce size. There is nothing in the protocol which says that the size of the
Ni and Nr must match.

On the other hand, I agree that IKEv1 does remain curiously silent on how
big the nonce ought to be. Our code is notorious for stress-testing others
with our 40 byte nonces. I have done my own investigation and I have come to
the following conclusions: It does no good for the nonce too be bigger than
the keymat you need to generate. If you need a 128 bit key for encryption
and a 128 bit key for authentication, then a 32 byte nonce is the maximum --
16 if you trust the peer's RNG. (If you don't trust your own RNG, then you
can generate a large nonce and hash it down to 32 bytes.) Even this is
overkill; if you trust your PRF, you can go as low as k*n^2, where n is the
number of keys you want to generate from the DH key and k is your safety
margin. Since a key size of > 256 is inconceivable at this point, there is
no particular reason why IKE needs to support > 64 byte nonces.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.