some comments on ikev2 04

[Hugo Krawczyk <hugo@xxxxxxxxxxxxxxxxx>]

Charlie,

Browsing over ikev2-04 I noticed several issues that may require 
clarifications or simple textual changes. None is crucial, yet here is a
list for you to consider.

(1) prf, authentication, etc:

The draft refers to  "prf", "MAC", and "integrity protection" as 
synonyms. Moreover, it seems that there is only one algorithm negotiated
for all of these functionalities (this includes key derivation,
authentication in preshared mode, and identity protection in SK{}). 
If this understanding is correct, I would suggest to make this more
clear and explicit in the text. If not, please let me know where is a
differentiation between these transforms.

Apropos, since the notion of "pseudorandom function" is not well 
represented in the more popular books about cryptography, it may 
be a good idea that ikev2 includes some language about what is meant
(assumed) as a good prf.
The following text (with a small addition) is from ike (v1):

 prf(key, msg) is the keyed pseudo-random function-- often a keyed
     hash function-- used to generate a deterministic output that
     appears pseudo-random, namely, indistinguishable from random
     for an observer who does not hold the prf key.  
     Pseudo-random functions prf's are used both for key derivations and
     for authentication (i.e. as a keyed MAC). (See [KBC96]).


(2) Anti-DoS cookie: I suggest that in your illustration of how to compute
the cookie (page 19) you add to the input of the hash the value Ni.
The rationale is that with this addition an attacker that
sees message 2 sent from R to I but did not see the corresponding message
1 from I to R cannot use this cookie since it does not know Ni. With
your definition, the attacker can use this cookie in a DoS attack by
forging I's source IP address (IPi) in its response (i.e. posing as I in
message 3). To do  this it does not need to see the original first message
from I. 
You may want to take a look at Section 2.3 of my draft
http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt
The proposal there is similar to what you do, but it includes
the nonce Ni and also an anti-replay value T to prevent
attackers from replaying valid cookies. The way way you do it is fine but
requires frequent changes of the <secret> to obsolete old cookies.

(3) Nonces (sec 4.10). You say that nonces need to be "at least equal to
the key size of the strongest cryptographic algorithm used".
Someone may understand that as 1024 (or even 2048) bits as the DH key
size... You do not care about "key size" but about "algorithm strength"

And, in a related issue: the key to prf in the derivation of the SKEYSEED
is Ni|Nr. If you think of HMAC (I know you do) this is not a problem since
HMAC has its built-in mechanism to deal with variable length keys.
But other perfectly good prf's (e.g. AES-CBC-MAC) will not accept too long
keys. You may want to say that the concatentation of Ni|Nr must be of the
length of the prf, but if it is longer than specified for the prf
then each nonce is truncated to contribute half of the bits of the key.

(4) Section 4.13, end of second par:
replace
"the fixed key size is the size of the output of the HMAC"
with 
"the fixed key size is the size of the output of the underlying hash
function"

The reason is that people may be confused about what the length of the 
"output of HMAC" is. Especially in the ipsec context some people think
that HMAC outputs 96 bits (I have a lot of experience dealing with these
confusions)

(5) Last words in 4.14: change them to
"the length of the output of the underlying hash function"

(6) Sec 4.15. I do not understand what good it makes to concatenate the
string "Key Pad for IKEv2" to the shared secret. You justify it on the 
seemingly "inevitable" use of passwords as shared keys. However, even in
this case how does the concatenated string help? If for any reason you
still want to put this string there make it an additional input to the
prf, not a concatenation to the key.

(7) Security considerations:

- can you explain to me what is the meaning of the first paragraph.
In what sense is the entropy of the DH consumed? (what is this entropy
anyway?) Maybe you want to say that using the same phase 1 with many 
non-DH phase 2's compromises the PFS property of the protocol.

-last par: I do not exactly understand the diffeentiation between
"random", "pseudo-random" and "strongly random" in this text.
I think that ALL these quantities should be cryptographically strong 
pseudo-random ("purely random" is a special case)

(8) I include this to make sure that there is at least one suggestion
that you will buy: there is a typo in the title of section 4.17 in the
TOC...

Hugo