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

Re: comments on ikev2 05 (cryptography)



Charlie,

> From: Charlie_Kaufman@notesdev.ibm.com
> 
> > Second issue: adding g^ir to the prf+ derivation
> > ============
> >
> > The key derivation presented in 05 is:
> >
> >      SKEYSEED = prf(Ni | Nr, g^ir)
> >
> >        {SK_d, SK_ai, SK_ar, SK_ei, SK_er}
> >                  = prf+ (SKEYSEED, g^ir | Ni | Nr | SPIi | SPIr )
> >
> > The key derivation in 04 was the same except that g^ir was not included.
> > The "benefit" of including g^ir under prf is that the DH key randomizes
> each
> > of the iterations of prf under the prf+ definition, thus providing
> seemingly
> > better (heuristic) security.
> > The drawback is that the inclusion of g^ir eliminates the mathematical
> > support behind the use of a prf. As I explained in the past: since
> SKEYSEED
> > is derived from g^ir then the (circular) construction
> > prf+(SKEYSEED, g^ir ....) cannot be formally claimed to be secure.
> 
> Actually, this change was made between -03 and -04. I have only a vague
> recollection as to why. I remember a discussion on the list in early
> December, but don't remember who the advocates for the change were and
> can't find it now. I'm tempted to change it back based on Hugo's objection,
> but would hate to have someone else who doesn't notice this note object in
> -07. Would anyone care to express an opinion? I think everyone agrees that
> the change has no practical impact on security either way.
 
As Hugo said, adding g^ir to the input of the prf+ would prevent us from
claiming that the key derivation mechanism of IKE is sound from a
cryptographic point of view, based on the standard cryptographic formulation
of pseudorandom functions. (This is due to the fact that a pseudorandom
function provides no guarantee on the security of the outcome when its input
is significantly related to its key - which is the case in the current
spec.)

So now the question is whether the existence of a security proof has
"practical impact" on the protocol or not. I tend to say that it does.
As a customer, I'd rather spend my money on a security product that
has a security proof assciated with it. 

(but, no, i woldn't want the proof in my owner's manual :)

Ran