Thanks for the detailed reviews Paul. I don't think the new text is changing
the meaning of the text that is already there. Anyone reading either of the
two, would be able to understand the point. Thus, I feel there is no need to
make the new change this late in WGLC process.
Panos
-----Original Message-----
From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Paul Wouters
Sent: Friday, January 18, 2019 10:22 AM
To: Valery Smyslov <smyslov.i...@gmail.com>
Cc: IPsecME WG <ipsec@ietf.org>; ipsecme-cha...@ietf.org;
david.walterm...@nist.gov
Subject: Re: [IPsec] New Version Notification for
draft-ietf-ipsecme-qr-ikev2-06.txt
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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
