Valery Smyslov writes: > > 4.4.1. Group Policies > > > > Having terms Group Security Association Policy (GSA Policy) and Group > > associated Policy (GAP are bit difficult to read, as those two are so > similar. > > Perhaps Group Policy (GP) and Group Security Association Policy (GSAP)? > > 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. > > 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... > > 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. Most likely they will/should try to re-establish connection to GCKS after the senders stop sending and SA is idle. > > 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. > > 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. > > -- > > > > 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... :-) -- kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
