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