Hi Tero, thank you for your review. Please see inline.
> When checking whether this document is ready for WGLC I did quick review of > it. > Here are my comments: > > ---------------------------------------------------------------------- > 1. Introduction > ... > [RFC8784] defines an IKEv2 extension for protecting > today's IPsec traffic against future quantum computers. > > When referencing to numbers always use the "name" of the document and only > add RFC number as a reference. This will help readers to read the document, > when they do not need to keep mapping from RFC number to name of the > document in their head. > > I.e., change to: > > Mixing PPKs in the IKEv2 for post-quantum security [RFC8784] > defines an IKEv2 extension for protecting today's IPsec traffic > against future quantum computers. Changed to Extension to IKEv2 for mixing preshared keys for post- quantum security defined in [RFC8784] allows today's IPsec traffic to be protected against future quantum computers. > -- > 1. Introduction > > > At the time > this extension was being developed, it was a consensus in the IPSECME > WG that only IPsec traffic needs to have such a protection. It was > believed that no sensitive information is transferred over IKE SA and > extending the protection to also cover IKE SA traffic would require > serious modifications to core IKEv2 protocol, that contradicted to > one of the goals to minimize such changes. > > This is not really correct. At the time it was seen that doing IKEv2 rekey > immediately after IKE SA is created will solve this problem and it is already > standardized how it can be done, so there was no need to make special case for > those users who happen to use IKEv2 sending their propriatery data that needs > protection. Besides proprietary data there are peers' identities that are transmitted in IKE_AUTH and immediate rekey won't help protecting them. If my memory serves me, the WG decided to sacrifice their protection in favor of protocol simplicity, emphasizing that PPK is a short-term solution until post-quantum KE methods are standardized. https://mailarchive.ietf.org/arch/msg/ipsec/Mjp2picLCfy8zhb9g3XebmbvekM/ > I still think adding special mode for those rare use cases will just cause > more > problems than what it solves. If the users who required this would simply have > added few lines to their code to use childless initial SA (RFC6023) and then > immediately trigger standard IKE SA rekey they could have been protected since > PPK rfc was published. This wouldn't solve the problem when sensitive data is transmitted in IKE_AUTH (e.g. in G-IKEv2). The way to circumvent this with immediate G-IKEv2 rekey is described in the G-IKEv2 draft and is really ugly. > More correct way of saying this would be: > > At the time of this extension was developed it was a consensus that > doing the IKE SA rekey immediately after IKE SA is created would > provide protection for the IKE SA itself and solve the situations > where sensitive information would be transferred over IKE SA. It was > considered that special protocol just for that was not needed, as > there was already existing standard way to achieve same result. I don't think your proposed text is accurate. Immediate IKE SA rekey wouldn't completely solve the problem (IKE_AUTH content would still be vulnerable, including peers' identities). https://mailarchive.ietf.org/arch/msg/ipsec/saNRET_aNkITI5jQ46pOI2e-WG0/ I think that the current text better reflects the situation. I can modify it a bit as follows: At the time this extension was being developed, it was a consensus in the IPSECME WG that it is the IPsec traffic that mostly needs to have such a protection. It was believed that information transferred over IKE SA (including peers' identities) is less important and extending the protection to also cover initial IKE SA would require serious modifications to core IKEv2 protocol, that contradicted to one of the goals to minimize such changes. It was also decided that immediate rekey of initial IKE SA would add this protection to the new IKE SA (albeit it wouldn't provide identity protection of the peers). > Now, when we already have IKE_INTERMEDIATE that means we do not need > another special exchange, and can use it, so making this method now is easier. > -- > > Since [RFC8784] was written, a new IKE_INTERMEDIATE exchange for > IKEv2 was defined in [RFC9242]. While the primary motivation for > developing this exchange was to allow multiple key exchanges to be > used in IKEv2 (which is defined in [RFC9370]), the IKE_INTERMEDIATE > exchange itself can be used for other purposes too. > > Expand the names of the RFCs in this paragraph too. Changed to: Some time after the protocol extension for mixing preshared keys in IKEv2 for post- quantum security was defined in [RFC8784], a new IKE_INTERMEDIATE exchange for IKEv2 [RFC9242] was developed. > -- > > This specification makes use of the IKE_INTERMEDIATE exchange to > define an alternative approach to [RFC8784], which allows getting > protection against quantum computers for initial IKE SA. > > I do not think this is alternative approach to the RFC (which could be IEEE > specification :-), it is alternative approach protocol described in that RFC, > so saying > "alternative approach to the mixing PPK to the IKEv2". Changed to: This specification makes use of the IKE_INTERMEDIATE exchange to define an alternative approach to the mixing preshared keys in IKEv2 for post-quantum security, which allows getting protection against quantum computers for initial IKE SA. > -- > > Another issue with [RFC8784] is that it assumes that PPKs are static > entities, which are changed very infrequently. For this reason PPKs > are only used once - when an initial IKE SA is established. This > restriction makes it difficult to use [RFC8784] when PPKs are changed > relatively frequently, for example as a result of Quantum Key > Distribution (QKD). If a fresh PPK becomes available before the IKE > SA is expired, there is no way to use it except for deleting this IKE > SA and re-creating a new once from scratch using the fresh PPK. > > I think it would be good idea to define how to describe the "Mixing PPKs in > the > IKEv2 for post-quantum security [RFC8784]" in this document, just using > [RFC8784] is not a good way to do that. Perhaps using something like "the > original > PPK approach" or similar would be better. > > Change most use of RFC8784 to that or add the name before the RFC reference. > Also change "[RFC7296]" to "IKEv2 [RFC7296]". Changed to: Another issue with use of PPKs as it is defined in [RFC8784] is that this approach assumes that PPKs are static entities, which are changed very infrequently. For this reason PPKs are only used once - when an initial IKE SA is established. This restriction makes it difficult to use PPKs as defined in [RFC8784] when they are changed relatively frequently, for example as a result of Quantum Key Distribution (QKD). I looked through the draft and I don't think we have to preface [RFC8784] with its name in *all* cases - in most cases the context is clear and it is referenced a lot of times. I've added "IKEv2" before "[RFC7296]". > -- > > 3.1. Creating Initial IKE SA > > * PPK_ID (variable) -- PPK_ID as defined in Section 5.1 of > [RFC8784]. > > I assume the receiver will know the length of the PPK_ID by knowing that PPK > Confirmation is fixed length of 8 octets? Perhaps this should be stated here. Added a note: The receiver can determine the length of PPK_ID by subtracting 8 (the length of PPK Confirmation) from the Notification Data length. > -- > > 3.1. Creating Initial IKE SA > > The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify > > Why do we need a new status notification, why can't we used the PPK_IDENTITY > notification have already defined in Mixing PPK in the > IKEv2 for Post-quantum Security [RFC8784]? > > Instead of having new status type, we could simply define new PPK_ID format, > which would include the PPK Confirmation. I.e., define > PPK_ID_OPAQUE_WITH_CONFIRMATION (3) and define its format to be exactly > as PPK_ID_OPAQUE except the last 8 octets are PPK Confirmation field as > described in Figure 1. > > This could also be defined so that it has internal format specifying the > length of the > confirmation field, and then confirmation field, and the the ID data. > > This would allow using that PPK_ID format also with old PPK method. In this case additional checks should be performed to make sure that only PPK_ID formats with confirmation are used for this extension. It's easier to check this based on the Notify Type, than on PPK_ID format. The latter is usually performed much deeper in code, when you parse the ID. In other words, having its own Notify type allows to make sanity checks easier. > -- > > 3.1.1. Computing IKE SA Keys > > This section computes keys differently from the Multiple Key Exchanges in the > IKEv2 [RFC9370], which uses: > > SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) > > Why does this use different method of generating the keys than multiple key > exchanges? We did have some cryptographers checking the one in Multiple Key > Exchanges so perhaps reusing the same would be better. In this case the PPK > can > be assumed to be shared secret between devices, i.e., SK(n). The current calculation follows RFC 8784, with the difference, that the result is treated as new SKEYSEED. SKEYSEED' = prf+ (PPK, SK_d) This is the most straightforward and conservative use of prf (with uniformly random PPK as a key) and it also had some cryptographers checking (as co-authors of RFC 8784) this approach. > -- > > 3.2. Using PPKs in the CREATE_CHILD_SA Exchange > > Can the implemenation try use N(PPK_IDENTITY_KEY, PPK_ID_1) in child > exchange even if the initial IKE SA was created using old PPK method, or if no > PPK method was used at all when creating initial IKE SA? Yes. The draft explicitly allows this: If a fresh PPK is available to both peers at the time when an IKE SA is active, peers MAY use this PPK without creating a new IKE SA from scratch. In this case the PPK can be used for creating additional IPsec SAs and for rekeying both IKE and IPsec SAs regardless whether the current IKE SA was created with use of a PPK or not. > Those are status Notify payloads, so they will be ignored by receiver if it > does not > support them, or does not want to use them, and if it resposes with > PPK_IDENTITY notify, then initiator will know that it supported PPK and > wanted to > use it in the this child sa exchange. Exactly. This was an intention. > This would allow using PPK in specific Child SAs only (i.e., you could use > non PPK > in most SAs but some of the child SAs might still use it). > It would also allow upgrading your IKEv2 SA from non PPK to PPK enabled one, > by > rekeying IKEv2 SA with PPK_IDENTITY notifies. Yes. > -- > > Appendix A. Comparison this Specification with RFC8784 > > The main disadvantage of the approach defined in this document is > that it requires an additional round trip (the IKE_INTERMEDIATE > exchange) to set up IKE SA. However, if the IKE_INTERMEDIATE > exchange has to be used for some other purposes in any case, then PPK > stuff can be piggybacked with other payloads, thus eliminating this > penalty. > > This is not really true, as if using old PPK method and user wants to protect > IKE v2 > SA it would need to do, IKE_SA_INIT, IKE_AUTH, and CREATE_CHILD_SA (to > rekey IKE SA), and now it uses IKE_SA_INIT, IKE_INTERMEDIATE and > IKE_AUTH, so the number of round trips is same for same protection. It was meant that if you don't need IKE SA protection, then you get IPsec SA with two exchanges. With this specification you always need three. Changed to: The main disadvantage of the approach defined in this document is that it always requires an additional round trip (the IKE_INTERMEDIATE exchange) to set up IKE SA and initial IPsec SA. > Another difference is that this will provide PPK protection for IDi and IDr, > and CERT > and CERTREQ payloads, which is not provided by the old PPK method, even if > rekeying is used. This is covered in the list of advantages. Added some clarification: 1. The main advantage of this specification compared to approach from [RFC8784] is that it allows an initial IKE SA to be fully protected against quantum computers, including information transferred in the IKE_AUTH exchange. > Also this method needs to pick PPKs without the help of IDi and IDr, as they > are > not available when picking PPK, but as initiator needs to pick PPK in old > method > without help of IDr and responder only has one to pick from the difference is > not > big... Do you think we have to mention this? I've submitted a new version. Please check, whether your concerns are resolved. Regards, Valery. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
