Subject: Re: ikev2-07: last nits

From: [email-masked]
Date: Thu, 1 May 2003 23:51:47 -0400

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 12 May 2003 22:43:22 +0300 (IDT)

> > 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
> > The reason for this is that SKEYSEED is produced by a (single) application

I do not think so. I believe that the interesting cases are well treated,
if not at the outmost generality. It's true that HMAC has the nice
property of taking care of variable lenth prf's but the problems raised by
fixed-length prf's are not that significant and are dealt with
satisfactorily in 07 (except for the above remark on |key| <= |block|
and an additional remark that I have below).

> output length. That allows AES128-CBC, but no others come to mind. 

First, AES128-CBC is THE fixed-key prf one would like to use in addition
to HMAC, so it is not a worthless example (after all what you have in mind
is yet another single prf instantiation, namely, HMAC-SHA1). Second, there
are ways to deal with the case in which block length is shorter than the
key size (as long as the block length is not too short as in the case of
3DES) but at this point this may add more complexity (or feelings of "not
thought enough") than necessary, especially that at the end this will be
used with AES128 anyway).

> specific suggestion as to how to fix this.

I believe the text in 07 regarding fixed-length keys is good.
It needs the addition that I noted in my prvious msg (point (6) above)
and the following fix that I missed the previous time:

In section 2.13 you write:
                 When the key for the prf function has fixed length,
   the data provided as a key is truncated or padded with zeros as
   necessary unless exceptional processing is explained following the
   formula.

This rule of padding with zeros is bad and, fortunately, unnecessary. In
all places where a fixed-length key prf is allowed you already have
specific language that tells you how to deal with this case and none of
them requires such a padding. So I suggest that you remove the above text.

Finally, I will take the opportunity to respond to Paul Hoffman's
complaint regarding the fixed-length prf that he raised in another email
on this thread:

Paul> Here's more. Section 2.15 says:
Paul>      If the negotiated prf takes a fixed size key, the shared secret MUST
Paul>      be of that fixed size.
Paul>  
Paul> This is completely wrong. It means that the two sides need to know
Paul> before they choose their preshared secret what the prf that they will
Paul> negotiate every time will be.
  
I do not see this as a reason to disqualify support of AES as prf.
In most cases the parties sharing a preshared key out of band will know 
(or even fix) the prf they will be using. Moreover, the ikev2 draft says
explicitly (page 27) that: "if the keys were exchanged out of band, the key
types must have been similarly learned."
Those who dislike the idea of having to commit to a specific key length at the
time of presharing, can always use the HMAC-based prf.

Hugo

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 13 May 2003 02:00:07 +0300 (IDT)

(this msg was supposed to be sent  before the message I sent
earlier today, but somehow it managed to hide in my "postponed" folder)

Charlie, 

I agree with most of your decisions here. I will refer to a couple
on which I have some additional comments.

> from Nr, taking the first bits from each."

sounds perfect to me.

> 'new' to match the language in section 2.18.

No. I was the one missing something (important). You are right and the
g^ir should stay for the reasons you exlain. 

Now that I (seem to) understand the differentiation between sections 2.17 and
2.18, I'd like to ask this question: is there any good reason to make this
distinction?  What I mean is that one could specify that all child-sa 
negotiations must rekey the IKE SA. Namely, in every child-sa negotiation 
one first computes a new SKEYSEED (as specified now in section 2.18) and then
derives SK_a/d/e. This simplifies a bit the specification and has no real
performance issue since the cost of computing SKEYSEED is negligible.  
This approach enhances the security of the protocol by providing significant
forward security even in the cases where the child-sa does not use a new DH
exponent. Of course, doing so raises some synchronization issues between the
parties but these already exist when rekeying an IKE SA as per section 2.18.

I will answer to your coments on point (6) below in a separate message.

Thanks for taking care of these fixes

Hugo