Keing the prf

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

There is one issue that was subject of discussion in the last weeks and I
believe requires a better resolution. I refer to the problem that ikev2
(including -12) defines two uses of the prf function (in sections 2.15 and
2.16)  where the prf is keyed with SK_a. This is problematic since SK_a is
defined as a key to the "integrity algorithm" which may be different than
the prf. Indeed the integrity algorithm and prf have different transform
types (#3 and #2) respectively, and then are negotiated independetly (in
particular they may use different algorihms).

Why is this a problem?

First, because the two transforms may require keys of different lengths,
in particular SK_a may be too short to key the prf.

Second, it is a wrong cryptographic practice to use the same key with two
different algorithms. This may or may not translate into actual attacks,
but it certainly spoils the otherwise sound design of the protocol.
It will also invite "attacks" from future formal analysts (beyond the
operational issues referred to in the first item).

I believe that the problem is best solved by deriving an additional pair
of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in the
above two cases. It is certainly easy to specify and to implement
(and easier than to justify why this wasn't done).

Specifically add the pair SK_pi, SK_pr to the key derivation formula in
2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to
prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to
last paragraph of section 2.16 with "SK_pi and SK_pr"

I suggest that this be solved before the official last call (otherwise you
can see this as a comment provided in the last call phase).

Hugo