ikev2-07: last nits

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

Charlie,

thanks for taking care of my comments on 06 (and for the overall wonderful
work).  Here there are  a few remaining editorial issues that need some 
polishing (nothing controversial, I hope) . The pointers refer to version 07.
In most cases I am suggesting explicit text to make yuor work easier
(but feel free to improve it...)


(1) Page 23 sec 2.10: 

Current text: These nonces are used to add freshness to the key derivation
technique used to obtain keys for CHILD_SAs.

Proposed text: These nonces are used to add freshness to the key derivation
technique used to obtain keys for CHILD_SA, and to extract strong
pseudorandom bits from the Diffie-Hellman key.

Explanation: I added the text after the comma which is an essential 
part of the rationale behind IKE's key derivation technique [SIGMA]

(2) Page 26 2.14

Current text: Ni and Nr are the nonces, stripped of any headers. If the
negotiated prf takes a fixed length key, Ni and Nr MUST each be truncated to
one half of the fixed key length.

Proposed text: Ni and Nr are the nonces, stripped of any headers. If the
negotiated prf takes a fixed length key, the key Ni | Nr MUST be formed by 
truncating each of Ni and Nr to one half of the fixed key length (if 
truncation is performed then the exceeding most significant bits of each 
nonce are not used when forming the prf key Ni | Nr).

Explanation: I added the specification that in case of truncation one uses the
least significant bits of the nonces (choosing the "lsb" was arbitrary).  The
current text is under-specified since it says to truncate the nonces to half
the key length but is silent about which bits to use.  (Also, I tried to write
this in a way that makes clear that the truncation is done only for the sake
of forming the key to prf, but not for other uses of the nonces -- if this is
still not clear maybe more explicit text on this is needed.)

(3) Page 27 2.15:

Current text: This is typically insecure because user chosen passwords are
unlikely to have sufficient unpredictability to resist dictionary attacks.

Proposed text: This is typically insecure because user chosen passwords are
unlikely to have sufficient unpredictability to resist dictionary attacks,
and these attacks are not prevented in this authentication method
(applications using password-based authentication for bootstrapping an IKE
exchange should use the authentication method in section 2.16 which is
designed to prevent off-line dictionary attacks).

Explanation: I added this explicit design decision, namely, not having
designed pre-shared mode to prevent dictionary attacks; also it is important
to say explicitly that password authentication should be used only in the
framework of the EAP methods from sec 2.16. If you do not like this text here,
it can be moved to security considerations.

(4) Page 27 2.15
Current text: The pad string is added so that if the shared secret is derived
from a password, the IKE implementation need not store the password in
cleartext, but rather can store a one way transformation of it that could not
be used as a password equivalent for protocols other than IKEv2.

Proposed text: The pad string is added so that if the shared secret is derived
from a password, the IKE implementation need not store the password in
cleartext, but rather can store the value prf(Shared Secret,"Key Pad for
IKEv2") that could not be used as a password equivalent for protocols other
than IKEv2.

Explanation: the current text is too general. The above is more specific
and then probably clearer.

(5) Page 29 2.17                                                                

Current text:

 For CREATE_CHILD_SA exchanges with PFS the keying material is defined as:
 
      KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr )

Proposed text: erase g^ir (ph2)

Explanation: this is a leftover from 06. You erased g^ir from other places
where it was unneeded but this one stayed. If I understand correctly, the
value SK_d used in this derivation is computed in section 2.18 using
SKEYSEED which, in turn, is already derived from g^ir (new) . 
Thus re-using g^ir (ph2) (here `ph2' and `new' refer to the same thing) 
under SK_d is of no help (and spoils the theoretical analysis).

(6) Page 81 Sec 5 (Security Considerations)

Current text: The strength of all keys are limited by the size of the output
of the negotiated prf function. For this reason, a prf function whose output
is less than 128 bits (e.g. 3DES-CBC) MUST never be used with this protocol.

Discussion: You may want to add that a prf that outputs less bits than its
own key is also unsuited for use (even if its output is longer than 128 bits).
The reason for this is that SKEYSEED is produced by a (single) application
of the prf and its length needs to be that of the prf key.

Important: The above specifications on the usable prf's should go to the
normative part of the document (sections 2.13 or 2.14) rather than in these
Security Considerations. I suggest to also add there that SKEYSEED is to be at
least of the length of a secure key for the negotiated prf (and if this prf is
of fixed-length key then SKEYSEED is to be of exactly this length).

(7) Security Considerations

Add text (possibly before the last paragraph on NAT traversal): For
information on the rationale of many of the cryptographic design choices in
this protocol see [SIGMA].

Explanation: it is important to provide a pointer for analysts of the
protocol (especially due to the many subtleties surrounding this design), 
and for those that may need to update/change the protocol in the future. 
(And for this purpose a ps/pdf document seems more useful than a ascii based
rfc.)

Hopefully my LAST set of comments before the closing of this WG (am I
being too optimistic?)

Hugo