Subject: [NSIS] GIST Responder Cookie Generation

From: Roland Bless <[email-masked]>
Date: Sat, 22 Oct 2005 22:23:22 +0200

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