> On 16 Feb 2018, at 21:09, Tero Kivinen <kivi...@iki.fi> wrote: > > Yoav Nir writes: >>> 2) The privacy of the initiator's identity in the presence of a man in >>> the middle attacker is not protected. >>> >>> Today an attacker with full control of the network can receive the >>> IDi/IDr sent by the initiator in the first AUTH packet. We should >>> add a mechanism to IKEv2 that allows the initiator to only send >>> IDi/IDr to known entities (e.g. that possess a shared secret). >> >> This is more feasible. I understand the issue, but the only use case >> where I think it’s important is remote access. It would make sense >> in remote access to reverse the order of authentication so that the >> responder identifies and authenticates first, but you’d still need >> the initiator to send the IDr first. > > The reason why we defined IKEv2 so that initiator provides identity > first, was that if responder provides identity first, then attackers > can make probe attacks and collect identities of the remote peers, > even when the IPsec is not currently in use. I.e., like we might run > nmap to find out the open ports, this would also provide authenticated > (if using certificateS) identity of the peer…
I realize this, but one side has to identify itself first, and with remote access I think it’s more important to protect the initiator identity than to protect that fact that some organization has an IPsec remote access concentrator. In fact we can run nmap and find which ports are open, and we can and do scan for HTTP(S) servers on ports 80 and 443, and we do get their certificates.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
