[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More DoS resistant Base Mode
How to make IKE more resistant against DoS
is also discussed in
http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-00.txt
The idea is quite similar:
the draft uses intermediate random fresh value (which is reconstructed
if the initiator really pays cost to verify the responder's signature)
as an additional input to the HASH payload in the ack message
from the client; if the client (maybe a DoS attacker) does not
follow the protocol (i.e. skip the verification of the responder's
signature), he/she cannot produce the correct HASH, which is
efficiently (<-- hashing is inexpensive computation)
detected by the responder.
This mechanism discourages DoS attackers
by ``falling-together'' nightmare;
if the attacker and the responder
have the same level of computational power,
the attacker must exhaust his/her own resource
in order to exhaust that of the target
since a bogus acknowledgment material is detected by the light verification
procedure before computationally-expensive verification.
Althogh this is currently focused on Signature authentication,
I recommend the change of the HASH payload format
in a way that the payload can use DoS-resistant mechanism
based on an additional input as above.
Then we might find a similar trick in other authentication mode.
Why don't we discuss this matter together and go on further
to make IKE more resistant against DoS.
----
Kanta MATSUURA
----
Ari Huttunen <Ari.Huttunen@datafellows.com> wrote:
>>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
---- **** ----
Kanta MATSUURA, Ph.D.
Lecturer
3rd Department,
Institute of Industrial Science, University of Tokyo,
Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN
Tel: +81-3-3402-6231 (ext. 2325)
Fax: +81-3-3479-1736
E-Mail: kanta@iis.u-tokyo.ac.jp
References: