[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ikev2-07: last nits



At 11:51 PM -0400 5/1/03, Charlie_Kaufman@notesdev.ibm.com wrote:
>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.

Fully agree.

>  Since it got added there
>have been a series of problems (including the one earlier in this note).

Here's more. Section 2.15 says:
     If the negotiated prf takes a fixed size key, the shared secret MUST
     be of that fixed size.

This is completely wrong. It means that the two sides need to know 
before they choose their preshared secret what the prf that they will 
negotiate every time will be.

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

I support your original suggestion: prohibit prfs with fixed-size 
keys. If someone really wants to add one or more of them later, they 
can write an extension to IKEv2 that clearly specifies how to do it.

--Paul Hoffman, Director
--VPN Consortium