Scott C Moonen writes:
> Apologies for missing the fact that it is not strictly man-in-the-middle
> attack. Certainly the attacker won't be able to take advantage of the
> revelation if he is not in the middle, but it's still improper to reveal
> the token.
Attacker does not need to actually even see the token, it is enough if
he just manages to get it forwarded to the other end (for example
using spoofed source IP addresses).
I.e. lets say situation is as following:
...
... .. +---------+
. ... /--| Host B1 |
+--------+ . .. +---------------+ / +---------+
| Host A |-------. Internet .---| Load Balancer |-
+--------+ . . +---------------+ \ +---------+
.. ... \--| Host B2 |
+----------+ /....... +---------+
| Attacker |-------
+----------+
The Host A is the token taker, and Host B is load balancing cluster
using Host B1 and B2, which are using same QCD secret, but separate
IKE databases.
Now if Attacker knows IP addresses of A and B1/B2, and IKE SPIs used
between host A and Host B1, it can create valid looking IKE packet
having Host A's source IP address, Host B2 destination IP address,
and known IKE SPIs. The contents does not matter as host B2 cannot
decrypt it. Host B will reply with packet:
<-- HDR(SPIi,SPIr) N(INVALID_IKE_SPI), N(QCD_TOKEN)
using source IP address of B2, and destination address of A.
This packet will be automatically routed directly to A, and attacker
does not even need to tell his own IP address at all while attacking.
RFC 5996 says that "Incoming IKE packets are mapped to an IKE SA only
using the packet's SPI, not using (for example) the source IP address
of the packet.", which means that Host A will accept that QCD_TOKEN
even when it does have Host B2's IP address instead of B1's IP
address, and it will tear down the IKE SA.
This is why I do think man-in-the-middle is wrong term, as the
attacker does not even need to see the reply packets. It is enough for
attacker to see one IKE SA packet between A and B1 and know the IP
address of B2 to launch the attacker, and attacker does not even need
to disclose his own IP address to do the attack.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
