OE IPsec part 5, The (Wo)Man in the Middle

In my opportunistic encryption project I envisioned two possible scenarios. Unfortunately it seems like one of them is open to a man in the middle attack at least in the use I envisioned.

In the first scenario I need a local DNS resolver that captures any A or AAAA queries and also looks up the IPSECKEY record for the same name. The resolver then loads the public key into the IKE daemon before returning the query results. When the IKE dialogue starts the peer is authenticated with the preloaded key and we send our own ID to it.

I have written a small resolver that does all this except loading the key into the IKE daemon.

In the second scenario the two IKE daemons send their FQDN as IDs and the IKE daemons queries DNS for the IPSECKEY of their peers. Unfortunately this scenario is likely vulnerable to a man in the middle attack even if we're using signed DNS records at least as long as we use forward zones. The bond is weak between the connection identifier, the IP address, and the name.

Imagine if someone, the Evil Eavesdropper Eve, were to listen in on an IKE dialogue where Alice is initalizing the dialogue with Bob. Alice has queried for Bob's address and is attempting to start an IKE dialogue with that IP address.

Eve captures all the traffic and spoofs replies from the intended peer, Bob. Instead of getting Bob's FQDN (bob.example.org) Alice gets Eve's FQDN (eve.example.org) as ID. Alice then queries for the IPSECKEY for eve.example.org and it validates fine in DNSSEC since it's Eve's record, not Bob's, and Alice continues the dialogue, not realizing that she's not talking to Bob.

Of course, all this might be visible in logs since Eve sends her real name as ID but by then it is probably too late.

I believe scenario #1 isn't vulnerable, since the FQDN used to query for A/AAAA and IPSECKEY comes from the user or a local process and not the peer, but more analysis is needed.