Subject: [Hipsec] Cookie Proposal

From: [email-masked] (Henderson, Thomas R)
Date: Tue Apr 6 16:47:00 2004

> -----Original Message-----
> From: JW [mailto:[email-masked]]=20
> Sent: Friday, April 02, 2004 7:26 PM
> To: [email-masked]
> Subject: [Hipsec] Cookie Proposal
>=20
>=20

> 2. For the cookie included in an R1, the signature field does=20
> not cover
>     the I or K values. If there is any additional data in the cookie's
>     opaque field, the signature also does not cover that data. When
>     computing the signature, these fields MUST be set to zero. Before
>     verifying the signature, these fields must be saved, set to zero,
>     and then restored after verifying the signature. For the cookie
>     included in an I2, the signature covers the entire cookie (this
>     should simplify processing).
>=20
>     The idea here is that if an implementation has a cheap source of
>     random numbers, the responder can hand out a new puzzle to each
>     I1 without needing to recompute a signature. The K is also left
>     outside the signature since if a responder is experiencing heavy
>     load and wishes to slow down initiators by increasing K, the last
>     thing it wants to do is to undertake an expensive signing=20
> operation.
>     I can't see any security problems with this right now, but if
>     there are any, this suggestion is weakened.
>=20
>=20

Jon,
Somewhere your proposal morphed from excluding I from signature to=20
both I and K.  If K is outside, it puts the initiator at risk to=20
grind away on a really hard problem if the K value is rewritten by
a man-in-the-middle.  Further, this mischief, if it is not too blatant,
might go undetected by the end hosts, since a solution for larger K is
also solution for smaller K.

It seems to me that, upon changes in loading, the responder can=20
undertake the operation of generating a new R1 once, or precompute a=20
few with larger K "just in case," if that is a concern.

Tom =20

---

From: [email-masked] (Jonathan Wood)
Date: Tue Apr 6 17:37:01 2004

Hello Tom,

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 
overly-
hard K values anyway (i.e. don't accept any over 20). Otherwise, any
responder could attack initiators that way. If a 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).

Also, if the K value is changed, it is detectable at the 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 wrong cookie).
For my opaque cookie proposal, you can just make K part of the MAC
computation.

If my reasoning is correct, then it is simpler to just assign a K 
according
to load conditions than to precalculate lots of R1s or create a new R1
and signature.

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 
thought
it might make things a bit simpler for implementations. The alternatives
you suggest below are certainly reasonable. I am more interested in
seeing the I fall outside the signature.

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.

Jon

On Apr 6, 2004, at 2:32 PM, Henderson, Thomas R wrote:

>
> Jon,
> Somewhere your proposal morphed from excluding I from signature to
> both I and K.  If K is outside, it puts the initiator at risk to
> It seems to me that, upon changes in loading, the responder can
> undertake the operation of generating a new R1 once, or precompute a
> Tom
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec