[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

More DoS resistant Base Mode



I read the base mode draft last week, and I was impressed in
how much better it is against DoS attacks than either base
mode or aggressive mode. (I'm not a cryptoanalyst(TM), though.)
However, I think you could make it even more resistant to DoS
attacks.

The attack I am thinking about is what Simpson calls
the Cookie Crumb Attack in his draft. Basically, I believe
you can change base mode so that the responder creates no
state after receiving the first message. Instead, the responder
hashes all relevant information to the R-cookie. The initiator
will then resend everything in the second message, and the responder
will check everything by comparing the hash with the R-cookie.
The initiator can't cheat because the responder hashes also some
locally known secret in there.

The modified exchanges are below. My intention is not to claim
that what I've written is actually secure or works, but to show
that this change is feasible to implement. The downside is that
some of the messages become considerably larger than they were,
and the ISAKMP base exchange will need to be modified more than
the IKE base mode has done. Also, there are most likely better
ways of achieving this than what I found. (One such way would
be do define a Responder State Payload that responder could send
to the initiator, to be subsequently sent back to the responder,
and which could contain anything the responder wishes. This way
you wouldn't have to modify the cookie generation at all.)

I could do more work on this before sending this to the list,
but I'd rather not in case the idea is totally rejected.
Anyway, please feel free to punch holes in this.

(I also can't claim the credit for this method of making
a protocol stateless. I read it somewhere else in some
other context...)

Base Mode Authenticated with Signatures
=======================================

   Initiator                       Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, [CERT,] SIG_I  =>
                           <= HDR, KE, [CERT,] SIG_R
 

CHANGE TO:

   Initiator                       Responder

   HDR, SA, Idii, Ni_b     => (1)
                           <= HDR, SA, Idir, Nr_b
                              (No state retained at Responder yet.)
   HDR, KE, [CERT,] SIG_I,
(*)IDii, Ni_b, SA, NR_b    => (2)
                           <= HDR, KE, [CERT,] SIG_R

(*) IDii, Ni_b, NR_b are copies of what was exchanged in
    the first messages. SA is what responder sent in the first reply.

(1) The responder puts in the R-cookie a hash of all the information that would need
     to be retained as state in the responder in the ordinary protocol. This includes
     a private secret, SA, IDii, Ni_b, Nr_b, I-cookie. The current time and date ARE NOT
     included. The ISAKMP RFC mentions that they are to be hashed because the R-cookie
     needs to be unique. I think the R-cookie is similarly unique if the I-cookie is
     unique.

(2) The responder now has all the information it had at point (1), since the information
    is retransmitted by the initiator. If the initiator tries to send incorrect values,
    this is caught by checking the hash of all information (including the secret value)
    and if this does not produce the R-cookie, the exchange is terminated.

Base Mode Authenticated with Pre Shared Keys
============================================

  Initiator                               Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, HASH_I         =>
                           <= HDR, KE, HASH_R
 

CHANGE TO:

   Initiator                               Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, HASH_I,
(*)SA, IDii, Ni_b, Nr_b    =>
                           <= HDR, KE, HASH_R

As in signature mode..

Base Mode Authenticated with Public Key Encryption
==================================================

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <IDii_b>Pubkey_r,
   <Ni_b>Pubkey_r           =>
                                 HDR, SA, <IDir_b>PubKey_i,
                            <=   <Nr_b>PubKey_i
   HDR, KE, HASH_I          =>
                            <=   HDR, KE, HASH_R

CHANGE TO:

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <IDii_b>Pubkey_r,
   <Ni_b>Pubkey_r           => (1)
                                 HDR, SA, <IDir_b>PubKey_i,
                                 <Nr_b>PubKey_i,
                              (*)<IDii_b>localkey_r,
                                 <Ni_b>localkey_r,
                                 <Nr_b>localkey_r
   HDR, KE, HASH_I,
(*)SA, [HASH(1),]
   <IDii_b>localkey_r,
   <Ni_b>localkey_r,
   <Nr_b>localkey_r         => (2)
                            <=   HDR, KE, HASH_R

(*) Resent stuff follows this marker..

(1) Responder creates a locally known encryption key localkey_r. This can be the
    same for several initiators, so no initiator specific state is retained.

(2) The localkey_r is used to decrypt the resent stuff. This is much faster
    than if the initiator would have resent <IDii_b>Pubkey_r, etc, which would
    have required PK operations.

Base Mode Authenticated with Revised Public Key Encryption
==========================================================

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <Ni_b>Pubkey_r,
   <IDii_b>Ke_i            =>
                              HDR, SA, <Nr_b>PubKey_i,
                           <= <IDir_b>Ke_r
   HDR, <KE>Ke_i, HASH_I   =>
                           <= HDR, <KE>_Ke_r, HASH_R

CHANGE TO:

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <Ni_b>Pubkey_r,
   <IDii_b>Ke_i            =>
                              HDR, SA, <Nr_b>PubKey_i,
                              <IDir_b>Ke_r,
                           (*)<Ni_b>localkey_r,
                              <IDii_b>localkey_r,
                           <= <Nr_b>localkey_r,
   HDR, <KE>Ke_i, HASH_I,
(*)SA, [HASH(1),]
   <Ni_b>localkey_r,
   <Nr_b>localkey_r,
   <IDii_b>localkey_r      =>
                           <= HDR, <KE>_Ke_r, HASH_R

As in authentication with encryption...

--
Ari Huttunen                   GSM: +358 40 5524634
Senior Software Engineer       fax : +358 9 8599 xxxx

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security
 


Follow-Ups: