Re: [Cfrg] Re: Changing the key deriveration

[canetti <canetti@watson.ibm.com>]

Sorry for the delayed reaction. Let me try to be concise:

1. I strongly support the move to change the spec. Using the same key to
two different algorithms is a big "no no" that, on top of other drawbacks,
does not allow mathematical proofs of security to go through.
(Not being amenable to analysis is a considerable *practical* weakness, 
even if do not see how to turn the weakness into an explicit attack...)

2. Both the solution suggested by Hugo (to derive two more keys from SEEDKEY,
to be used for the PRF by the sender/responder, respectively), and the
solution suggested by Hilarie (to use SK_d, the key meant for deriving the
IPSEC keying material as the key to the PRF) are in principle sound.
However, Hugo's solution seems somewhat more robust: It seems preferable to
keep the ``virginity'' of the derivation key, SK_d, and refrain from using
it inside the protocol. This feeling is compounded by the fact that in the
password-based authentication mode the PRF is applied to messages of a generic 
password-based protocol, so the door may be open to "oracle attacks" that 
use the parties to obtain values of PRF(SK_d,...) on desired values.

So, in conclusion, if we're already changing the spec for better
analyzability/provability, then I think we should play it safe and 
derive two extra keys from SEEDKEY, rather than use SK_d.
(The difference in performance and complexity between the two options
seems minimal.)

Ran


On Fri, 20 Feb 2004, Paul Hoffman / VPNC wrote:

> At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote:
> >Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15,
> >first paragraph) with SK_d does resolve the problem of using two
> >algorithms (prf and integrity) with the same key, and it is much better
> >than what is done now.
> 
> There have been no more comments on this, and the ADs are still 
> waiting for a final draft of this document so they can move all three 
> IKEv2 documents to IETF last call.
> 
> Charlie: are you OK with this solution? If so, can you get the new 
> draft out soon, such as when the Internet Drafts window opens?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
>