Panos Kampanakis (pkampana) writes: > 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.
WGLC is not late, it is early... Paul's text is easier to read, and I think that pointing out that initiators Peer identity, feature negotiatons, vendor ids are already available for active attacker doing man in the middle of the connection is good point. Usually the responder already has static address, thus most of this information is already known to everybody, so initiators information is more important. Also we can later add protection for both peer identities if we like, i.e. use random one use pseudonyms in the initial exchange. Paul Wouters writes: > 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 last sentence should probably be rewritten to be more accurate, i.e.: Although initiators 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
