Re: ikev2-07: last nits

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

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

On Thu, 1 May 2003 Charlie_Kaufman@notesdev.ibm.com wrote:

> 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."

sounds perfect to me.

> 
> > (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?

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

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