Subject: [NSIS] RE: GIST Responder Cookie Generation

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 10 Nov 2005 19:30:01 -0000

hi roland, all,

i've added some text on this to the relevant section in 8.5:

  "To support the validation simplicity requirement, the Responder can
   check the liveness data to filter out some blind (flooding) attacks
   before beginning any cryptographic cookie verification.  To support
   this usage, the liveness data must be carried in the clear and not be
   easily guessable; this rules out the timestamp approach, and suggests
   the use of sequence of secrets with the liveness data identifying the
   position in the sequence.  The rollover frequency of the secret must
   be high enough that the secret cannot be brute-forced during its
   lifetime.  Note that any node can use a Query to discover the current
   liveness data, so it remains hard to defend against sophisticated
   attacks which disguise such 'probes' within a flood of Queries from
   forged source addresses.  Therefore, it remains important to use an
   efficient hashing mechanism or equivalent."

So, at the moment I think the best we get from this is some partial 
protection (because I don't see a way to prevent an attacker extracting
valid cleartext liveness data with a Query). I think it is useful, but
we still need to have fast hash (or whatever) verification as part of
the requirement.

(unless someone can think of a better way ...)

Robert H.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 24 October 2005 05:45
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: GIST Responder Cookie Generation
> 
> 
> Hi Robert,
> 
> Hancock, Robert wrote:
> > Certainly there is a case for adding the issues about
> > blind attacks and strength of the secret (if secret-based
> > liveness data is used) to the discussion of the cookie
> > requirements. I've created 
> > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue97
> > to capture it.
> 
> Ok, thanks.
> 
> > What i'm not certain about is where to document the more
> > detailed ideas about how to defend against the problems,
> > e.g. rollover rate, key length and so on. ideally they'd
> > be written down somewhere. but it seems to me that the
> 
> Yep.
> 
> > gist spec itself is not the best place for them: specifically,
> > it would be good to allow them to evolve and be added to 
> > rather freely, because they don't affect interoperability,
> 
> 100% agreed. That's what I meant by "(not in the sense of a too strict
> specification)". Therefore I requested only to provide
> additional background on the threats rather than giving
> exact numbers for rollover rate or key length. These will
> evolve over time and 64-bit may seem sufficient *today*
> for one parameter but this setting should be adapted over
> time as threats and CPUs evolve...
> 
> > whereas the spec is supposed to be (or become) stable. i'd
> > like to see an implementors guide, but i'm not sure what 
> > other people think about that.
> 
> That would be a nice thing to have, but I'm not sure what
> else would go in there at the moment.
> 
> Regards,
>  Roland
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Fri, 11 Nov 2005 00:10:23 +0100

Hi Robert,

> i've added some text on this to the relevant section in 8.5:

[and this is a quite good proposal...]

>    be high enough that the secret cannot be brute-forced during its

...and thus the secret must be long enough, too

>    forged source addresses.  Therefore, it remains important to use an

Nodes that send queries from spoofed source addresses will not succeed in
discovering the liveness data, so I'm a little bit confused here.
If an attacker has the liveness data, he can send a lot of Confirms
whose cookies must be checked. In this case the hash function must be
efficient in order to avoid an attack on CPU resources. An attack
on state resources by sending a lot of Confirms will still not be
possible.

Yep.

> valid cleartext liveness data with a Query). I think it is useful, but

No, there is no way to prevent that. But I think this is probably not
a serious problem since the attacking node must be reachable.
In summary we have two lines of defense:
1. cookies against attackers that try to exhaust state resources
   by sending from spoofed addresses (also a blind attacker)
2. liveness data against blind attacks trying to exhaust CPU resources
   by letting the responder perform cookie validity checks for
   confirm messages.

> (unless someone can think of a better way ...)

Yes, input welcome.

Regards,
 Roland