Hi Paul,
I think that comparing QC-based attack with MITM is a bit incorrect,
since Man-in-the-Middle can only learn what the Initiator sends,
while an attacker equipeed with QC can also learn what the Responder
replyis. Besides, unlike Man-in-the-Middle, this is a passive attack
and the peers could never know that their conversation is revealed.
Anyway, I think that MITM in IKEv2 is covered in enough detail
in RFC7296, so I don't see the need to mention it here.
Otherwise, the two texts basically say the same. I admit that yours
is easier to read :-), but let's see what the RFC says :-)
Regards,
Valery.
On Fri, 18 Jan 2019, Valery Smyslov wrote:
> a new version of draft-ietf-ipsecme-qr-ikev2 (-06) has been posted.
> It addresses Paul Wouters' comment about the Security Considerations text.
Thanks!
I have another minor suggested change :)
current:
Note that [RFC6023] allows to
skip creating Child SA in the IKE_AUTH exchange, so that the
supporting peers can rekey the IKE SA before any Child SA is created.
Note also that some information (identities of the peers, feature
negotiation notifications, Vendor IDs etc.) is always exchanged in
initial exchanges and thus cannot be protected from the attack
described above by performing an IKE SA rekey.
new:
It is possible to create a childless IKE SA in IKE_AUTH as specified
in [RFC6023]. This prevents Child SA configuration information from
being transmited in the original IKE SA that is not protected by
a PPK. Information in the initial IKE_INIT and IKE_AUTH exchanges,
such as peer identities, feature notifications and Vendor ID's cannot
be hidden from the attack described above, even if the additional IKE
SA rekey is performed. Although this information would also be available
to a Man-in-the-middle attacker without a quantum computer.
This removes the two "note" from sentences which make them less easy
to read, and quantifies the leaked information a bit in the context of
a simple MITM, non-quantum attack. It explains a bit better why there
isn't a strong reason to try and hide the peer identities and VIDs from
attackers with quantum computers.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
