Re: comments on ikev2 05 (cryptography)

[Charlie_Kaufman@notesdev.ibm.com]

> First Issue: Macing the identity.
> ===========
> The text we agreed upon was (this text appears in my message to the list
> on Jan 23rd, Charlie's agreed to it in his response message; there were
no
> objections in the list).
> ...
> Instead of this, the text of 05 changes the values MIDr=prf(SK_ar,IDr)
and
> MIDi=prf(SK_ai,IDi) with the contents of payloads IDr and IDi,
respectively.
>
> I have no idea what motivated this change.  I guess that Charlie
convinced
> himself (or someone convinced him) that putting the identities under the
> signatures achieves the same effect as adding the MAC (or prf) of the
> identities as we agreed earlier.  THIS IS WRONG.

Hanson's Razor: Never ascribe to malice that which can be adequately
explained by incompetence. I didn't convince myself, nor did anyone
convince me. I just made the changes to the spec from memory and got it
wrong. I've fixed it in the draft I'm working on.

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

> Now, somewhat too late for IKE but on time
> for IKEv2 I have written the sigma paper to document this rationale
> (and a more
> mathematical paper with Ran with a rigorous analysis of these protocols).

> This rationale is too involved to be added as part of the ikev2 document,
> instead I do ask that the security considerations section provides
> a pointer to the sigma paper (whose coming revision will also include the
> rationale for the prf+ based key derivation).

Sure. Can you send me the latest current citation and the new one as soon
as it is available?

>    The strength of a key derived from a Diffie-Hellman exchange using
>    any of the groups defined here depends on the inherent strength of
>    the group, the size of the exponent used, and the entropy provided by
>    the random number generator used. Due to these inputs it is difficult
>    to determine the strength of a key for any of the defined groups.
>    Diffie-Hellman group number two when used with a strong random number
>    generator and an exponent no less than 160 bits is sufficient to use
>    for 3DES.  Groups three through five provide greater security. Group
>
> I do not agree that 160 bits are sufficient for use with 3DES given that
these
> exponents allow for a full break of the DH exchange in 2^80
> operations. I would
> suggest a minimum of 180 or even 200 bits.

Done!

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