Re: comments on ikev2 05 (editorial)

[Charlie_Kaufman@notesdev.ibm.com]

Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
> Here is a list of (mostly) editorial changes to ikev2-05 that I suggest
> for the next revision of the document.
> It includes several of the more significant editorial comments on version
04
> included in a message from Jan 23rd (message under the subject:
> "some comments
> on ikev2 04") and not reflected in 05.

Sorry to have somehow missed these changes last time around, and thank you
for the careful review. I've incorporated your comments except as noted
below:

> (9) Section 2.14 page 25:
>
> >>>   subsequent exchanges.  SKEYSEED and its derivatives are computed as
> >>>   follows:
> >>>
> >>>       SKEYSEED = prf(Ni | Nr, g^ir)
>
> What happens if Ni|Nr is longer than the prf key? You should specify that
the
> values concatenated above are Ni and Nr each truncated (if
> necessary) to half the
> length of the prf key. (This is particularly relevant to prf's basedon
block
> ciphers, e.g. AES-CBC-MAC.)

I'm not comfortable with this change. When the prf is HMAC, which accepts
an arbitrary length key, there is no problem. I'm concerned that truncating
the nonces makes the protocol more fragile in the case where an
implementation fails to choose the nonces adequately randomly. I added: "If
the prf does not accept variable length key, its specification for use with
IKEv2 must include a procedure for deriving its required fixed length key
from a variable length key".

I'll start a new string asking the AES-CBC MAC advocates how they
want to handle this.

> (11) Then in the same section you specify:
>
> >>>   In the case of a pre-shared key, the AUTH value is computed as:
> >>>
> >>>      AUTH = prf(Shared Secret | "Key Pad for IKEv2", <message bytes>)
> >>>
> >>>   where the string "Key Pad for IKEv2" is ASCII encoded and not null
> >>>   terminated. The shared secret can be variable length. The pad
string
> >>>   is added so that if the shared secret is derived from a password,
> >>>   this exchange will not compromise use of the same password in other
> >>>   protocols.  As noted above, deriving the shared secret from a
> >>>   password is not secure.  This construction is used because it is
> >>>   anticipated that people will do it anyway.
> >>>
>
> As I noted in a previous message this pad does not give anything.
> It does not hurt either except for giving a false feeling of security.
> If I am confused and you have an argument why this pad helps please
> explain to me.
> The only way this can help against another protocol it that protocol
> uses the same prf
> with the same <message bytes>.
> And, again, if you still want to add the pad, it should be
> concatenated to the input not
> to the keyL that is
>
>       AUTH = prf(Shared Secret, "Key Pad for IKEv2" | <message bytes>)

I added the following explanatory text:

The pad string is added so that if the shared secret is derived from a
password, the IKE implementation need not store the password in cleartext,
but rather can store a one way transformation of it that could not be used
as a password equivalent for protocols other than IKEv2.

Adding the key pad as a prefix to the message bytes does not in general
give the same security benefit.

If you still don't understand the goal, I can try to elaborate more. If you
do understand but think it does not provide the promised benefit, please
explain.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).