Valery Smyslov writes: > > I did understand that, but I do not see point of sending extra 8-octets as > the first 8- > > octets already identifies the IKE SA... > > The point is that we want to re-use IKEv2 header, which contains two > IKE SPIs.
Sure, but this does not have anything to do with the issue in hand, i.e., how to identify the IKE SA in the notify payload. The notify payload normally only has 8 octets to identify the IKE SA and now you suddenly want to have 16 octets instead. > In normal IKEv2 each side selects its own IKE SPI, but in > G-IKEv2 it is impossible. It is the GCKS that provides GMs with SPI > for rekey SA and GMs will have to use it to select the right SA. Yes, but as the GM will always only use the first 8 octets of the IKE SPIs in the IKEv2 header we could simply use that to identify the IKE SA. > Obviously, GCKS is unaware of the SAs each GM might have (it may be > a member of several groups controlled by different GCKSs and besides > it may have a lot of ordinary IKE SAs too), so the GCKS selects SPI > in random. To minimize the chance of collision it is better to use > full 16 bytes of available room in IKEv2 header instead of only > selecting SPIi, since GMs won't contribute to this process anyway. Probability of having random collision with IKE SA when only using 64-bit IKE SPI is that I would ignore that. This is long lived SPI value, typically it will stay same for long time (hours, days, or even weeks). Also I think there is also the source IP address of the IKE packets that can be used to identify the GCKS so there should not be problems even if the SPIi somehow should collide. If I remember correctly the IKE SA packets the GCKS is sending will be using the unicast source IP address of the GCKS, and may contain either unicast address of the GM or the multicast address. The source address would not be multicast or broadcast address. > After some thinking I realized, that the whole section is not correct - > it was written before key wrapping was added to G-IKEv2. I deleted > most of it text. Now it reads as: > > 6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security > > G-IKEv2 can take advantage of the protection provided by Postquantum > Preshared Keys (PPK) for IKEv2 [RFC8784]. However, the use of PPK > leaves the initial IKE SA susceptible to quantum computer (QC) > attacks. Group SA keys are protected with the default KWK (GSK_w), > which is derived from SK_d and thus cannot be broken even by attacker > equipped with a QC. However, other data sent over the initial IKE SA > may be susceptible to an attacker equipped with a QC of a sufficient > size. Such an attacker can store all the traffic until it obtains > such a QC and then decrypt it (Store Now Decrypt Later attack). See > Section 6 of [RFC8784] for details. > > While the group keys are protected with PPK and thus are immune to > QC, GCKS implementations that care about other data sent over initial > IKE SA MUST rely on IKEv2 extensions that protect even initial IKE SA > against QC (like [I-D.ietf-ipsecme-ikev2-qr-alt]). > > Is it OK now? Yes. -- kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
