Re: ikev2-07: last nits

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

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

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

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

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

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

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