Subject: [Hipsec] Cookie Proposal

From: [email-masked] (Henderson, Thomas R)
Date: Tue Apr 6 18:01:01 2004

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]=20
> Sent: Tuesday, April 06, 2004 3:25 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] Cookie Proposal
>=20
>=20
>=20
> Hello Tom,
>=20
> Yes, I did change the proposal so that the signature would not include
> K. My rational was that a man-in-the-middle attack would not be able
> to cause significant trouble, since initiators must guard against=20
> overly-
> hard K values anyway (i.e. don't accept any over 20). Otherwise, any
> responder could attack initiators that way. If a=20
> man-in-the-middle wants
> to engage in a DOS attack, there are much simpler ways to go about it
> (for example, just change 1 bit in the R1 and cause the checksum
> to fail).
>=20
> Also, if the K value is changed, it is detectable at the=20
> responder - for
> the hashing scheme outlined in the appendix, if the K is part of
> the hash, a changed K will be detected (by hashing to the=20
> wrong cookie).
> For my opaque cookie proposal, you can just make K part of the MAC
> computation.
>=20
> If my reasoning is correct, then it is simpler to just assign a K=20
> according
> to load conditions than to precalculate lots of R1s or create a new R1
> and signature.

OK, I will buy that argument.

>=20
> Having said that, however, whether or not the K is protected by the
> signature is not all that important to me. I just included it since I=20
> thought
> it might make things a bit simpler for implementations. The=20
> alternatives
> you suggest below are certainly reasonable. I am more interested in
> seeing the I fall outside the signature.
>=20
> Regarding both the I and K values in the R1, I think having the
> signature not cover them is OK since they are protected by other
> mechanisms, such as the hashing scheme in the appendix. If they
> are changed, the worst that can happen is DOS, and the severity
> of the DOS exposure is no worse than if they are covered by the
> signature.

I agree that the I is more important than the K, I was just trying to
rise to your challenge of finding security problems in leaving K =
outside. =20
If K is checked or folded into the hashing scheme, then I think it is =
fine
either way.  If there is MITM, there are probably other worse
attacks to subtly degrade but not block communications.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 8 04:30:01 2004

After having thought a little bit about this, I haven't
found any reasons why we couldn't leave I outside of the
signature.  However, I would not necessarily change the
SIG2 signature algorithm but just move the puzzle payload
before or after the signature.  But I am open here as SIG2
is R1 specific anyway.  (Maybe it should be renamed as
SIG-R1?)

However, there are two considerations that we have to
keep in mind, *especially* if we move resynchronization
out of the base spec.

  1. Middle boxes

     In general, an R1 may traverse a number of middle
     boxes, either because it is explicitly routed so
     (the "control plane" case) or just because it happens
     to traverse different IP domains and must pass NATs.

     In this case, it would be desirable that the initiator
     is able to gain *some* assurance that the R1 was actually
     generated by the responder.  Hence, I still think it
     desirable to have the signature, and I still call for
     careful thinking about what to cover with the signature
     and what not.  But more about that later.

  2. Replay attacks

     Even though we were not so worried about MitM attacks
     (since a MitM may launch worse attacks, as Jon reasoned),
     we still have to worry about replay attacks.

     Consider a case where Alice sends an I1 to Bob, and Bob
     replies with a fresh R1.  However at the same time
     Mallory replays an old R1.  Which R1 should Alice process?
     In the worst case she would receive the replayed old R1
     several hundred milliseconds before the fresh one.
     In such a case she should be able to detect that the
     latter is more recent than the former and abort
     processing of the former one.

So far we have determined that it is OK and actually
necessary to leave the initiator HIT outside of the signature.

It also looks OK to leave #I outside of the signature,
since a wrong #I only makes the initiator to produce a wrong
answer, it does not change the magnitude of work.

Even if we kept #I still under the signature, there would be
cases where a replay attack would work, making the initiator
to produce a wrong answer.  For example, if the responder
is currently unreachable, a replay attack could trick the
initiator to produce an old answer that is not valid any
more.  On the other hand, if the responder is reachable,
the initiator will receive also the right R1 and not only
the old one, and it will (also) produce the right answer.
I don't see any big difference here.  The only difference
is in the case of middle boxes, and there it apparently
doesn't matter.  [I have to admit that I haven't quite
thought through some of the "control plane" cases, and that
I am still a little bit worried, but not that much.]

What comes to #K, I would keep it still protected.  While
a false #K alone does not necessarily make the initiator
to produce a wrong answer, it may trick the initiator to
unnecessarily burn CPU.  Pretty bad for some portable
devices which may run out of battery.  Having #K signed
has the *potential* effect of partially protecting some
devices against replay attacks.

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.]

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Thu Apr 8 06:34:01 2004

Pekka Nikander wrote:

> This is apparently a change to the
> a new issue.  

So, shortly:

- I will be left out from the signature
- K will be included in the signature
- Birthday will remain in COOKIE TLVs in any case
- Opaque field will be added to the COOKIE TLVs

In addition to the TLV changes, some text has to be edited (I will
return to this next week).

In Issue 26, it was already defined that the BIRTHDAY_COOKIE will be
separated into two TLVs: COOKIE_REQUEST and COOKIE_RESPONSE. I haven't
yet edited it into the base draft (10-pre1), as the existence of the
birthday field was (at that time) dependent on the resync-issue.

The following COOKIE TLVs were already earlier in issue 26. So, the
addition to the previous discussion is that we include the Birthday
again in the TLV. (I'll close issue 26 and continue with the new issue
number). In the future the COOKIE TLVs would look something like:

6.2.4 COOKIE_REQUEST

         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, 8 bytes                                             |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | K, 4 bytes                                                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Random # I, 8 bytes                                           |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Opaque                            /
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        /                                               |    Padding    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type           3
        Length         28
        K              K is the number of verified bits
        Random # I     random number
        Opaque         opaque bytes (possible zero), set by responder.

     Birthday, Random #I and K are represented as 64-bit integers, in
     network byte order.

6.2.5 COOKIE_RESPONSE

         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, 8 bytes                                             |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Random # I, 8 bytes                                           |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Random # J, 8 bytes                                           |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Opaque                            /
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        /                                               |    Padding    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type           5
        Length         28
        Random # I     random number
        Random # J     random number
        Opaque         opaque bytes (possible zero), sent by Responder
                       in COOKIE_REQUEST TLV and returned unchanged by
                       initiator.

     Birthday, Random #I and Random #J are represented as 64-bit
     integers, in network byte order.

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 8 06:37:01 2004

> - I will be left out from the signature

I think so, yes.

> - K will be included in the signature

Yes.

> - Birthday will remain in COOKIE TLVs in any case

I think it was earlier decided to split the COOKIE parameter
into a BIRTHDAY parameter and PUZZLE/SOLUTION parameters.
But maybe I misunderstood some of the issue 26 discussion.

> - Opaque field will be added to the COOKIE TLVs

I think so, yes.

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Thu Apr 8 06:50:02 2004

> But maybe I misunderstood some of the issue 26 discussion.

The removal of birthday was requested by Thomas earlier (related to
resync removal from the base draft). It is discussed more under
issue 15.

/petri

---

From: [email-masked] (Jonathan Wood)
Date: Thu Apr 8 20:38:00 2004

Looks good to me - I'm OK with the K being included in the
signature. One comment inline:

> - Opaque field will be added to the COOKIE TLVs

The Opaque field is left out out the signature in the
COOKIE_REQUEST.

Pekka and Tom - thanks for spending some cycles thinking
about this.

Jon