Subject: [Hipsec] Splitting the COOKIE parameters

From: [email-masked] (Henderson, Thomas R)
Date: Mon Apr 19 20:52:04 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Thursday, April 15, 2004 5:08 AM
> To: Julien Laganier
> Cc: [email-masked]
> Subject: Re: [Hipsec] Splitting the COOKIE parameters
> 
> 
> >> 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?
> >
> > 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.
> 
> 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.
> 

Another option: K does not need to be 4 bytes.  Highest order 2-3 bytes
could be used as an optional opaque field by responder, to index the puzzle
somehow, if needed.  Then, just include K (4 bytes) in solution and do not 
send back I or necessarily use separate opaque data TLV.

However, could you explain why Birthday is 96 bits?  This is likely
cumbersome data type to support on the native system.  Incrementing
once per second, a 32 bit counter takes over 100 years to roll over.

Tom

p.s. in general I think that the splitting of these parameters, and
the opaque TLVs, are nice changes.

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 20 06:16:00 2004

>> The case is not that clear cut.
>>

Sounds like a good idea.  However, I would still like to carry #I
explicitly in the solution.  Its only 8 bytes, I2 will be large
anyway, and including #I gives some freedom to the Responder 
implementation.
I would not like if the responder would must remember #I.

Something like the following:

PUZZLE

       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, 1 byte     | Opaque, 3 bytes                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random # I, 8 bytes                                           |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   #K is covered by SIGNATURE2
   Opaque and #I are NOT covered by SIGNATURE2 but zeroed before
   computing the message digest.

   The rationale for the placement of #K, Opaque and #I is that it
   makes it easier to implement the signature zeroing in some
   implementations.

SOLUTION

       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, 1 byte     | Opaque, 3 bytes                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random #I, 8 bytes                                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Puzzle solution #J, 8 bytes                                   |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   #K and Opaque copied verbatim from the PUZZLE.

   All fields covered by SIGNATURE, nothing zeroed.

> once per second, a 32 bit counter takes over 100 years to roll over.

Just alignment.  32 bits may not be enough for busy servers and
such, otherwise it might be sufficient.

If we want to save some bytes, maybe we could combine BIRTHDAY
to the DIFFIE_HELLMAN parameter?

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Group ID    |               Reserved                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Birthday, 8 bytes                                             |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Public Value                           /
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                               |            padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Birthday would then be present also in (some) UPDATEs, which
might be good.   On the other hand, birthday would become more
like D-H generation number, which may or may not be good, depending
on how you cycle your D-H keys vs. how you cycle your puzzles.

Yet another possibility would be to place it in PUZZLE but not
in SOLUTION, making a new PUZZLE to be as follows.

       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, 1 byte     | Opaque, 3 bytes                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random #I, 8 bytes                                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Birthday, 8 bytes                                             |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hence, the Birthday in a PUZZLE is replaced with the #J in a SOLUTION.
The different Type values make the intention clear.

--Pekka