Subject: [Hipsec] Splitting the COOKIE parameters

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 15 03:52:00 2004

To make the protocol more modular and simpler in some
sense, I would suggest splitting the COOKIE parameters
into separate BIRTHDAY, PUZZLE and SOLUTION parameters.

Here is the proposed text:

BIRTHDAY

   The BIRTHDAY parameter contains an 96-bit unsigned integer,
   indicating the current generation of valid puzzles.  The
   sender is supposed to increment the Birthday value periodically.
   It is RECOMMENDED that the Birthday value is incremented at
   least as often as old PUZZLE values are deprecated so that
   SOLUTIONs to them are no more accepted.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Birthday, 12 bytes                                            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A question:  Should we have separately a sender BIRTHDAY and receiver
BIRTHDAY parameters?  I don't remember any more how the semantics
were defined in the current draft, but to me it makes more sense to
send the sender's birthday.  However, for the puzzle solution processing
it MAY be useful to include the responder's birthday in I2.  However, 
now
that we have the Opaque field/parameter, the birthday's role is more
reverted to replay protection for the receiver of the birthday than
for information for the (stateless) responder when receiving I2.

Opinions?

PUZZLE

   The PUZZLE parameter contains the puzzle difficulty K and an
   64-bit puzzle random integer #I.  A puzzle MAY be augmented by
   including an ECHO_REQUEST parameter to an R1.  The contents
   of the ECHO_REQUEST are then echoed back in ECHO_RESPONSE, allowing
   the Responder to use the included information as a part of puzzle
   processing.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | K, 4 bytes                                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random # I, 8 bytes                                           |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SOLUTION

   The SOLUTION parameter contains a solution to a puzzle.  It also
   echoes back the random difficulty K and the puzzle integer #I.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | K, 4 bytes                                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random #I, 8 bytes                                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Puzzle solution #J, 8 bytes                                   |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Question:  Do we need to echo back K and #I now that we have the
Opaque field/parameter?  The required information could as easily
be stored there?

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Thu Apr 15 07:05:02 2004

Pekka,

More thoughts below,

On Thursday 15 April 2004 10:42, Pekka Nikander wrote:
>   <snip/>
> A question:  Should we have separately a sender BIRTHDAY and
> receiver BIRTHDAY parameters?  I don't remember any more how the
> semantics were defined in the current draft, but to me it makes
> more sense to send the sender's birthday.  However, for the puzzle
> solution processing it MAY be useful to include the responder's
> birthday in I2.  However, now
> that we have the Opaque field/parameter, the birthday's role is
> more reverted to replay protection for the receiver of the birthday
> than for information for the (stateless) responder when receiving
> I2.
>
> Opinions?

IMHO, this "receiver birthday" looks very similar to a  "Transaction 
ID ", i.e., the initiator sending a "receiver birthday" in I2 is 
really just  echoing back the "sender birthday" he just received in 
the R1 from the responder.

So, I dunno. Perhaps we could define a "Transaction ID" (either in the 
base header or in a new parameter) and keep only a "sender birthday".

>    of the ECHO_REQUEST are then echoed back in ECHO_RESPONSE,
> allowing the Responder to use the included information as a part of
> puzzle processing.
>
>
>   <snip/>
>
>
> SOLUTION
>
>    <snip/>

I agree that sending back K and I would be redundant information. As 
PUZZLE and SOLUTION are now two different parameters, I would prefer 
simplicity and no ambiguity, i.e.,  drop K and I in the SOLUTION.

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 15 07:17:02 2004

> simplicity and no ambiguity, i.e.,  drop K and I in the SOLUTION.

The case is not that clear cut.  Using the opaque info requires
you to verify its integrity first, i.e., compute at least one hash.
And only after that you know if the I2 is related to any R1 that
you have sent recently.  On the other hand, using #I (and K) directly
as an index to the right puzzle may be made very cheaply.  Indeed,
if you have a (too) simple implementation, you can use them just
directly.  (Which is, of course, unsecure.)  [Afterthought:  Of
course, you could store just an index and a once in the opaque field,
and check that the index points to the same nonce in your own data
structures, but you can do that almost as easily with #I.]

Hence, I would not *necessarily* be dropping #I and K from SOLUTION
(if we adopt it).  I think that a SOLUTION without #I and K is
more aesthetic, but OTOH it is only 8 bytes more (you still need
padding for #J) and leaves the implementations the possibility of
not using the opaque field/parameter at all.

--Pekka

---

From: [email-masked] (Jonathan Wood)
Date: Fri Apr 16 12:57:19 2004

> not using the opaque field/parameter at all.

Yes, I think that it would be good to keep the #I and K in the SOLUTION
to allow implementations more flexibility in verifying puzzles.

Jon