Subject: [NSIS] RE: GIST Responder Cookie Generation

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 24 Oct 2005 13:06:49 +0100

Hi Roland,

I think this is a very useful piece of analysis.

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.

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

cheers,

robert h.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 22 October 2005 21:23
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: GIST Responder Cookie Generation
> 
> 
> Hi Robert,
> 
> we asked ourselfs some practical questions when implementing
> the responder cookie mechanism. While the GIST draft provides
> already a very good basis for an implementation, I think it
> would be helpful to give a little more advice and security
> background for implementers (not in the sense of a too strict
> specification) in order to avoid weak implementations.
> 
> I see two attacks against the cookie mechanism:
> 1) A blind attacker sends GIST-Confirm messages with random and
>    invalid cookies. The responder must check if the cookie is
>    correct. Extremly high message rates may exhaust CPU
>    resources. However, the responder will only check the
>    cookie in case the liveness data is correct (i.e.
>    it lies within the validity period).
> 2) An on-path attacker records the GIST-Response message
>    and performs a brute force offline attack on the secret.
>    Once he knows the secret, the attacker can launch
>    a DoS attack within the remaining validity period of
>    the secret by resource exhaustion due to rapid state
>    creation.
> 
> Consequently, I see two requirements following from these
> two attacks:
> 1) Liveness data should not be guessable by a blind
>    attacker.
> 2) The secret must be long enough so that a brute force
>    attack will not be feasible in the lifetime of the
>    secret. Thus a second requirement is that a new secret
>    is generated frequently enough so that an attacker has
>    not enough time to perform an offline attack on the
>    secret.
> 
> Following the IKEv2 approach we decided to use a generation
> number of the secret as liveness data instead of a
> timestamp (that could be guessed more easily). But how
> large should this generation number be?
> We think that it must be at least 32-bit wide (randomly
> chosen at the beginning), because the probability
> for a blind attacker is then small enough to hit a valid
> secret generation number by chance.
> The secret must be large enough, too, presumably 64-bit
> at least. Furthermore, the next secret must be generated
> soon enough so that an attacker has not enough time to
> perform a brute force attack to find out the secret.
> Usually you want to store at least one old secret, so
> the validity time of a secret is twice as long as the
> period for secret generation in this case.
> 
> My request is therefore to provide a little more
> background so that an implementer can make reasonable
> choices. Even if my above statements are incorrect
> it may be a sign that some details are still not
> clear enough and some security area guys can try to
> clarify.
> 
> Best regards,
>  Roland
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Mon, 24 Oct 2005 14:45:26 +0200

Hi Robert,

> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue97

Ok, thanks.

> be written down somewhere. but it seems to me that the

Yep.

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

> 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