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

Re: question about IKE Quick Mode

Hello, Cathy.

> attack.  In that
> case, according to draft-ietf-ipsec-isakmp-oakley-08.txt, 
> the identities are implicitly assumed to be
> to be the IP addresses of the ISAKMP peers.  However, a key in that
> case would be associated with *two* IP addresses, and it's not clear
> from the specification of the messages in IKE which one would
> be the originator of the message.  This appears to allow

Which key you mean here? In this state of IKE all keys are associated 
with SAs, for processing of phase II messages with the current 
IKE-SA, which itself is identified by IKE cookies. 
However, I see the issue you address.

> for a situation in which an initiator B can be convinced that
> it has successfully completed a Quick Mode exchange with a responder
> A, while in fact an intruder has fooled it into completing
> a Quick Mode Exchange with itself.
> This is done by having B initiate a Quick Mode exchange with A.
> The intruder intercepts this message, and replays it back to B
> as A initiating a quick mode exchange with B.  B as responder produces
> a message which the intruder sends to B as initiator as a message from
> the responder A, and so on, until at the end B is convinced that it
> shares a key with A when actually it is sharing a key with itself.

This is a very interesting attack, because A doesn't need to break 
any key, just need to "reflect" the message. But from my point of 
view, IKE is resistent against the passive form of this attack: The 
"magic number" is the message ID. For the first Quick Mode exchange 
initiated by B, it's M-ID, say is 1. If A simply reflects this 
message, B identifies the associated IKE-SA and realizes, that there 
is no finished quick mode exchange with A AND M-ID 1. 
I'm not shure, what the "standard behavior" of an IKE 
implementation is now; "Pluto", the GNU-IKE-daemon, increments it's 
associated M-ID, if there is no so-called "full state" (i.e. finished 
phase II) for A and the received M-ID. That is, phase II IV (and also 
HASH(1)) wouldn't match anymore and the message is ignored.

The active form of this attack is more problematic, that is, A could 
modify the message; but therefore it must have SKEYID_a and SKEYID_e, 
at least. Because in that case, there are other, more serious attacks 
possible, I suppose, you don't mean this kind of attack. 

Regards,
Kai

# Kai Martius                                                           #
# Dpt. of Medical CS and Biometrics / Dresden University of Technology  #
# PGP Fingerprint: to be compared after download of my key              #
# Key and more info (especially IP-security related) see my Homepage    #
# http://www.imib.med.tu-dresden.de/imib/personal/kai.html              #
References: