Hi Tero,
The attack can be easily modified so that the message sent from the
attacker to the responder looks unsuspicious. All that attacker need
to do is to find C1 and C2 so, that the COOKIE notification type in
C1 is changed to any unused status notification type in C2. It is
just a little bit harder than the current version of attack. However
after that the message sent from the attacker to the responder will
look like:
M' = HDR | Nx=C2 | SAi' | KEi' | NONCEi' | Ny=(SAi | KEi | NONCEi | info_i)
Attacker cannot do that, as attacker will not be able to get original
initiator to reflect the Nx=C1 back in the m1. Cookies notifications
are used because are required from the initiator to be copied from the
original SA_INIT reply to the retry SA_INIT request.
For that unknown notification that would not work, i.e. when the
attacker sends back the
SA_INIT(ck=|C1|SA',gx'|ni|)
the initiator will ignore the first notification if it not cookie, and
will not retry with message sending cookie notification.
You missed the point. The attacker finds a collision so that
C1 (sent to initiator) contains COOKIE notification (with
SAi', KEi', NONCEi' included), while in C2 (sent to responder)
the notification type is changed from COOKIE to smth unknown
(and of course the length changed too, as in original attack).
So the responder will see two unknown status notifications (Nx and Ny)
and will just ignore them. Nothing suspicious.
If the attacker changes the m1' to contain some other notification in
the beginning that cookie notification he needs to find different type
of collison where the prefix is no longer constant, i.e., he needs to
modify that.
He need to do that anyway. Note, that the ck and ck' cookie
length in the original attack must be correct and different
(ck = C1 | SAi' | g^xi' |NONCEi, while ck' = C2). The other option
for the attacker is to make the length of ck and ck' equal, but in this
case the length of m and m' will be different and he must
find a collision so that the length field in HDR and HDR'
be correct (m' will be longer than m). The authors
write about this on p.13:
We also observe that the two prefixes are very similar:
we only need the length of the cookie to be different.
Following the format of IKE message, the length field
is on bytes 22 and 23 of the hashed transcript, and
all previous bytes must have a fixed value. Hence, we
can _almost_ use a common-prefix collision attack, if the
collision algorithm introduces a difference in bytes 22-
23, and no difference in preceding bytes.
So it is not a pure collision attack. In the modified attack the
additional requirement is that not only length of the notification be different,
but also the type of notification in C2 changes from COOKIE in C1 to
any unused status notification. It makes finding a collision harder,
but I think not too much.
So the only real defense against this attack is an unpredictability
of SPIi.
And checking the small subgroups in Diffie-Hellman, i.e., not using
groups 22-24.
Sure.
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
