Subject: [Hipsec] Cookie Proposal

From: [email-masked] (Henderson, Thomas R)
Date: Sat Apr 10 14:33:00 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Thursday, April 08, 2004 2:20 AM
> To: <[email-masked]> <[email-masked]>
> Cc: Henderson, Thomas R; Jonathan Wood
> Subject: Re: [Hipsec] Cookie Proposal
>=20
>=20
> Finally, due to the desire to make it possible for Alice
> to make a difference between a replayed and fresh R1s,
> I think that we need to retain the birthday parameter
> even if we remove resynchronization out of the base spec,
> and even make it stronger.  Basically, it seems to me best
> to increment birthday count whenever old R1s are not
> accepted any more.  This is apparently a change to the
> current draft, and therefore probably requires opening
> a new issue.  [Petri, please.]
>=20

What are the rules for processing multiple R1s?  If we
include a counter in the R1s, should a responder then
accept a new R1 and start over again, when it receives
an R1 while in state I2-sent and the R1 counter is higher?

Once a host does not have any association anymore with=20
another host, should it be required to flush all state=20
associated with its peer's birthday count?  A general=20
problem that I foresee that we want to make sure we don't=20
fall prey to is when, for some reason, a host's (supposedly=20
non-volatile) birthday counter is wiped clean (e.g., OS=20
reinstallation?), we want to make sure that we don't block=20
that host from connecting to other hosts because of its=20
restarted birthday count.

An alternative for now would be to not worry about the R1
replay vulnerability, which doesn't look that severe=20
(we could add it later as a new non-critical R1 parameter).

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Sun Apr 11 01:17:01 2004

> an R1 while in state I2-sent and the R1 counter is higher?

If you were speaking about I1-sent, or the (unnamed)
sub-state when the initiator is still solving the puzzle,
and if the new-counter > (old-counter+1), then I would
say yes.  What comes to I2-sent, I don't know.  If the
new-counter is clearly higher than the old-counter, i.e.
new-counter > (old-counter + 2..3), then starting over
might be a good optimisation.  The details need to be
worked out, and care must be taken with various border
conditions like packets crossing in the network, both
initiating at the same time, etc.

Things depend also on whether you verify the responder's
signature in R1 before you start solving the puzzle or
whether you defer signature verification only to those
cases where #K is high or you encounter a failure or
otherwise ambiguous condition.

As an initial approximation, I would probably implement
it as follows:

   1. Upon receiving R1, check #K.  If not too high,
      just start solving the puzzle, without bothering
      with the signature.

   2. If #K is high, check signature, then start solving
      the puzzle.

   3. Upon receiving a new R1 while solving the puzzle,
      check the signature in that R1 which has a larger
      R1-counter (birthday counter) value.  If the signature
      verifies OK, check the difference in R1 counters.
      If that indicates that the one of the R1s is probably too
      old, throw the old R1 away and act accordingly.

   4. Upon receiving a new R1 after solving the puzzle
      (i.e. while in I2-sent), do roughly the same as
      in case #3.

> Once a host does not have any association anymore with
> another host, should it be required to flush all state
> associated with its peer's birthday count?

Well, I think it SHOULD forget about the birthday counter,
but that it MAY also store it.  A policy issue.  You
probably do want to store the birthday counter of your
very-important-server, but not the birthday counter of the
zillions of web sites you visit.

> A general
> problem that I foresee that we want to make sure we don't
> fall prey to is when, for some reason, a host's (supposedly
> non-volatile) birthday counter is wiped clean (e.g., OS
> reinstallation?),

If a host looses its birthday count, it probably looses its
private key, too.  If someone reinstalls the private key,
they can probably also reset the birthday counter into some
sensible value.  (Of course, this does not apply to some very
small devices that have ROM but not NVRAM etc.; see below.)
This apparently needs to be documented under operational
considerations.

Should we have a separate section about operational
considerations?  Or even a separate draft?

> we want to make sure that we don't block
> that host from connecting to other hosts because of its

Right.  That's the reason for the aforementioned "SHOULD
forget".

> replay vulnerability, which doesn't look that severe

I think the birthday count parameter could be non-critical
from the very beginning, allowing implementations to ignore
it.  Anyway, its purpose is to protect the initiator from
some replay attacks, and if the initiator does not want to
have that protection, it is not exactly a protocol concern.
Of course, for the sake of devices that have only ROM but
not NVRAM, we could define that including the birthday count
in R1 is RECOMMENDED but not MANDATORY.

--Pekka