Hi Tero, > > I see your point. I would leave GSA as is, and perhaps would change > > GAP to Group Related policy (GR policy). "Policy" will not be part of > > abbreviation in both cases. Your opinion? I didn't make any changes > > yet... > > Ok for me.
Or, even better, we can call it Group-Wise (GW) policy (I hope you are OK with this too). I made these changes, please review. > > > 4.4.2. Group Security Association Policy Substructure > > > > > > The SPI size for the IKE is 16, not 8, like in standard RFC7296 IKEv2. > > > As the 8-first octets of the IKE SPI is the initiator SPI and it is > > > only > > one part that is > > > used to identify the Rekey SA, so I think it could be possible to > > > just > > send 8-octets, > > > i.e., the initiator SPI, and simply say that the Responder SPI of > > > the > > Rekey SA is > > > simply ignored, i.e., receipient MUST use the Inititor SA to find > > > the > > rekey SA, and > > > ignore the Responder SPI on recipient (and either that Initiator > > > MUST or > > SHOULD > > > use the responder SPI static for all Rekey SA messages). > > > > > > Or we could define we send SPIi, and the SPIr will always be same as > > > SPIi, > > so > > > each rekey SA will have identical SPIi and SPIr. > > > > > > Similar changes for the section 4.5.2. > > > > Note, that a new IKE protocol GIKE_REKEY is used here, for which the > > size of SPI is 16 octets. I see no problem here. > > 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. 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. 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. > > > 4.4.2.2.1. GSA_KEY_LIFETIME Attribute > > > > > > Why is this attribute needed? The senders should take cere of the > > > rekeying the SA before too much data is sent over it, so there is no > > > security reason for this. Is this just to allow clients to clean up > > > extra SAs in case they loose connectivity, but why then this MUST be > > > sent. > > > > > > I think we could just remove this attribute. > > > > The sender cannot rekey GSA, it is the GCKS who can only do it. > > If for any reason the connectivity with the GCKS is lost or it > > unexpectedly goes offline, then the group continues to live on its own > > and the SA lifetime can be exceeded. This attribute is a safeguard for > > this case - each group sender will know the lifetime of the SA and > > stops using it after that time even if no new SA is established by the > > GCKS. > > So if the connectivity to the GCKS is lost then then there is no way to rekey GSA, > thus it would be enough for the senders to simply stop sending and then lifetime is > not exceeded. Yes, receivers will not know when to remove the SA, but that is not > an issue for security, just extra resources. Actually, GSA_KEY_LIFETIME is provided to all GMs, not only senders. The receivers should also delete SA once it is expired, so no extra resources is wasted. > Most likely they will/should try to re-establish connection to GCKS after the senders > stop sending and SA is idle. It is anticipated. > > > 4.4.2.2.2. GSA_INITIAL_MESSAGE_ID Attribute > > > > > > Could we use similar method to transport the upper 32-bits of the ESN? > > > This would of course only work in case the GCKS is actually either > > > part of > > the > > > group or knows the current upper 32-bits of the ESN using some other > > method (for > > > example if it is the sender to that SA). > > > > > > Should we provide method for this even if would not work always? > > > > This will reliably only work if the GCKS is the only sender in the group. > > I'm not sure we should add support only for this particular case. > > I think the GCKS being the only sender is quite common, so we might want to > support that. I'd rather to postpone this. If a new ESPv4 becomes a reality soon, there will be no need to complicate this already complicated protocol. > > > 6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security > > > > > > This sentence needs to say something that if implementations cares > > > those issues then it needs to: > > > > > > For these reasons the GCKS MUST NOT send GSA and KD payloads in the > > > GSA_AUTH response message and MUST return a new notification > > > REKEY_IS_NEEDED instead. > > > > > > As you noted the GSK_w is protected, so store now, decrypt later > > > attack is already not applicable. The IKEv2 with PPK is not really > > > designed to be safe against the attackers who can do online real > > > time QC attacks on the exchanges, and break the for example > > > authentication used in the IKEv2. The IKEv2 with PPK is designed to > > > protect against the attacks, where someone stores traffic now, and > > > then when they do get quantum computes they can decrypt the data. > > > > > > G-IKEv2 is as safe against such attacks as is standard IKEv2. > > > > > > It attacker can break encryption and authentication of the G-IKEv2 > > > messages it still can't affect the multicast traffic keys which are > > > protected using GSK_w which is derived from SK_d. > > > > > > It can send messages that changes the keys to random keys which will > > > cause DoS attacks, but it can do DoS most likely anyways even > > > without breaking the encryption and authentication. > > > > Changed this text to: > > > > GCKS implementations that care about these issues MUST NOT send GSA > > and KD payloads in the GSA_AUTH response message and MUST return a > > new notification REKEY_IS_NEEDED instead. > > Perhaps the text should note that GSK_w is protected against store now decrypt > later attacks in all cases. 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? > > > -- > > > > > > Appendix A. Use of LKH in G-IKEv2 > > > > > > How does one specify that it will use LKH? I do not think we have > > > any way of specifying it anymore? If so remove the whole appendix A. > > > > No special indication is needed. The GCKS sends either a single group > > protection key wrapped with GSK_w to all members (no LKH) or provides > > each GM with its own key (protected with GSK_w) and with an array of > > keys where each subsequent key is protected by the previous one in the > > array, ending up with the group protection key. The GMs logic is the > > same in both cases - it must find the group protection key using all > > the keys supplied by the GCKS, starting from GSK_w which the GM always > > knows. See also Section 3.2. > > Ok. Did not really understood that from there, but if you say so... > :-) Thank you, I submitted -13 version. Regards, Valery. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
