Re: ikev2-07: last nits

[Charlie_Kaufman@notesdev.ibm.com]

I've indicated the changes I've made to reflect these proposals. If anyone
disagrees, please speak up. I can back them out, but it's easier to do the
edits as I go along...

      --Charlie

> (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]
>
Done.

> (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.)
>
I agree the current text could be misinterpreted, but I don't like your
fix. Most significant and least significant is a confusing concept when
dealing with bit strings, and may not even be well defined. Adding to the
confusion, the nonces are strings of octets, where msb and lsb are well
defined within the octet but I don't believe it's obvious which are the
most and least significant octet.

How about the following?

"If the negotiated prf takes a fixed length key and the lengths of Ni and
Nr do not add up to that length, half the bits must come from Ni and half
from Nr, taking the first bits from each."


> (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.
>
Done.

> (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.
>
Done.

> (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).
>
We understand differently :-}

I took out the g^ir in the derivation of the IKE keys from SKEYSEED because
g^ir was used in the derivation of SKEYSEED. But for child SAs, if there is
a second Diffie-Hellman exchange specifically for the creation of that
child SA, that g^ir needs to be wound in somewhere. In the construction
above SK_d is derived from SKEYSEED, which is derived from g^ir. But that's
a different g^ir than the one here.

This section and section 2.18 are parallel. This one talks about keying
material for an ESP or AH SA. 2.18 talks about keying material for a new
IKE SA. In both cases, the (optional) new g^ir must be wound in.

The label 'ph2' is an obsolete reference to 'Phase 2'. I changed it to
'new' to match the language in section 2.18.

Am I missing something?


> (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).
>
I believe that the use of a prf other than HMAC (or at least not accepting
a variable length key) is dangerously poorly thought out, and my
inclination is to take out all references to it. Since it got added there
have been a series of problems (including the one earlier in this note). I
hadn't noticed - but you are certainly correct - that the spec assumes that
if the prf has a fixed length key that the key length is the same as the
output length. That allows AES128-CBC, but no others come to mind. We could
keep patching, but is this really a requirement? It was motivated by people
who were going to put AES in hardware and didn't want to have to implement
a digest function as well. I'll buy that for the fast path (packet
integrity checks), but do we really need to engineer for that case for the
performance-irrelevant key expansion case? If so, could someone make a more
specific suggestion as to how to fix this.

> (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.)
>
Done.

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

> Hugo
>
>

      --charlie