Changing the key deriveration

["Theodore Ts'o" <tytso@mit.edu>]

In a recent message, Steve Kent made the following statement:

>When I last spoke with Russ, he indicated that he was prepared to
>tolerate another delay on the IKE v2 document to incorporate the
>change that Hugo suggested, to incorporate bits from an key-based EAP
>method into the PRF for the keys used for encryption & integrity.

This presumably is referring to Hugo's proposal of January 13th, which
I've included below.  On a recent concall of the IPSEC management team,
we discussed on how to handle this, given that (a) there has been no
response or discussion to Hugo's proposal on the mailing list to date,
and (b) a number of us get hives with the thought of making changes to
something as critical as IKEv2's cryptographic core at the last minute
without some adequate and thoughtful review.

So we propose the following path forward.  First, that we ask the Hugo
to clarify his objection.  It appears to be mainly a certificational
weakness in that it may make it harder to prove correctness at least
when using normal crypto algorithms.  Is this a fair characterization,
or is there a fundamental problem in normal usage?

Secondly, we'd like to ask the Crypto Forum Research Group in the IRTF,
whose charter it is to provide a resource to IETF working group to
review uses of cryptographic mechanisms if they might be willing to give
us review of the current key agreement mechanisms found in sections
2.14, 2.15, and 2.16 of draft-ietf-ipsec-ikev2-12.txt as well as the
proposed change by Hugo.  Ran and David: Is this a good use of the CFRG,
and would you be willing to ask them to engage in this review?

Based on the answers from Hugo and the CFRG, the working group will
hopefully have sufficient information in order to quickly come to
consensus about whether we need to make any changes to ikev2-12.

Does this seem a reasonable way forward?  I don't want to unduly prolong
an already very long process, but it seems to us that it is better to
put examine this issue and put it to rest now, instead of waiting until
Russ finishes reviewing the document (it is in his queue) and starts
IETF last call.  

					- Ted

------------------

Date: Tue, 13 Jan 2004 22:10:50 +0200 (IST)
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Subject: Keing the prf
To: Theodore Ts'o <tytso@mit.edu>
cc: Russ Housley <housley@vigilsec.com>, byfraser@cisco.com,
        Charlie Kaufman <charliek@microsoft.com>,
        IPsec WG <ipsec@lists.tislabs.com>

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