cookie definition in IKEv2-04

[Ran Canetti <canetti@xxxxxxxxxxxxxx>]

Charlie,

Regarding section 4.6 (cookies):
I'm glad that you defined the cookie as a separate payload. It's much better
this way. One remark though. The text says:


>   A good way to do this is to set the responder cookie to be:
>
>      Cookie = <SecretVersionNumber> | Hash(IPi | SPIi | <secret>)
>
>   where <secret> is a randomly generated secret known only to the
>   responder and periodically changed.  


The goal of the second field in the cookie is to allow the responder
to verify, when it gets the cookie back from the initiator, that 
the cookie it got is the same as the cookie it sent. 
The cryptographic mechanism that provides this functionality is a MAC.
So the second field in the cookie should be computed using a MAC function,
rather than plain unkeyed hash.
 
There are ofcourse many ways to compute a MAC. There is no reason to mandate
one way on top of the other (especially since this is not an interoperability
issue). In any case, if for sake of concreteness you want to give an
example of a hash-based MAC then I'd use HMAC - it has better properties
than the rudimentary "append the key" method implied by the current text.

In addition, it may be good to add that if the responder wishes to reduce
its state per exchange when under attack, then it can use the cookie as 
a replacement for storage. That is, define

      Cookie = <SecretVersionNumber> | <state> | 
                             MAC(<secret>, IPi | IP | <state>)

where <state> is any additional information that the responder chooses.
(Potentially, the information in <state> may be encrypted, if the responder
so chooses.)

Best,

Ran