Valery Smyslov writes: > > 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.
Yes. And I do remember saying that there are ways to protect them with using pseudo ID metchanism if such is needed, and for other data we also saw there was a ways to protect it if needed. > 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. I currently only on section 3.1 so I have not yet seen what is there, but on the other hand g-ikev2 is one of those rare cases, that are not seen in the internet regularly today.... :-) > > 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). Yes, but it was seen at the time that we do not need special protocol, as there are ways to solve the issues other ways, so the text is accurate describing what was happening at that time. This is the reason why original PPK did not do what you do now. > https://mailarchive.ietf.org/arch/msg/ipsec/saNRET_aNkITI5jQ46pOI2e-WG0/ And the discussion from this was that we decided to go on with the PPK as defined now because we saw that immediately rekeying IKE SA would solve some problems, and using pseudonyms etc would solve identity problems. Btw, people did not seem to care about identity protection so much, that they would have written draft about how to do pseudonyms... > 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). This seems to be correct, and I can accept that, except I can't accept that spelling of IPsecME... :-) If you fix the spelling then that text is perfect. > 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 think you should remove the RFC8784 reference in most of case as instead just talk old / previous etc PPK method. I consider everything that is inside [] to be something that can be safely changed to [1] [2] [3] etc and the text still needs to be readable. In your case it would not be in all cases. Thats why adding some name in front of the [RFC12312] reference is important. Even if the RFC8721 is used so many times in the draft, I still do not have that mapping in my head, so I will use random RFC8751 instead of it... > > 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. I do not think that makes that big difference. We currently have 2 PPK ID formats defined, and I would assume most implementations uses only one of them... On the other hand I think having PPK ID format that includes confirmation would benefit the old PPK method too. And when you are calling the function to verify that PPK ID passes confirmation it would always fail for those formats which do not have confirmaton, thus that would automatically check that only ones that have confirmation are accepted. > > 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 I had to google RFC8784 to see what it was :-) > 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. But you are now doing IKE_INTERMEDIATE, thus using the same method for mixing entropy to the SKEYSEED as other protocols using the same exchange would be good. Btw, you still need to explain what happens if you do multiple key exchanges and this in the same IKE_INTERMEDIATE exchange, i.e., currently you throw away the SKEYSEED generated by multiple key exchanegs, as you do: SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) and SKEYSEED' = prf+ (PPK, SK_d) {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr ) and the 2nd SKEYSEED' does not use the SKEYSEED generated before. If you defined the operation as: SKEYSEED(n) = prf(SK_d(n-1), PPK | [ SK(n) ] | Ni | Nr) where SK(n) is left out if no other key exhcnage was done in this IKE_INTERMEDIATE exchange, then that would solve that problem, and if we trust this method for post quantum key exchange algorithms, we should trust the method also for PPK... > > 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. That does not explictly say that you can also try to upgrade from old PPK method too. So implementations do not really care about the protection of the IKE SA, but do care about the ability to change PPKs over time, so in that case they might use original PPK method but still use PPK_IDENTITY_KEY during the IKE SA rekey to change PPK. I think we need names for two PPKs, as I do think both of them are going to exists in future, and perhaps this draft should actually update the original PPK RFC<insert number here> Perhaps PPK in IKE_AUTH, and PPK in IKE_INTERMEDIATE? And then we could say PPK in CREATE_CHILD_EXCHANGE which could be used regardless whether PPK was done in IKE_AUTH or in IKE_INTERMEDIATE, which would be the part that updates PPK in IKE_AUTH rfc. So then the ths draft name coul be Mixing Preshared keys in IKE_INTERMEDIATE exchange of IKEv2 for Post-quantum Security? > > 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. Good. > > 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. I would change "The main" to "One". I do not think we need to specify which is main disadvantage... but otherwise ok. > > 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. I think identity protection is so important that I would made it a separate bullet. Something like this: 1. The main advantage of doing PPK in IKE_INTERMEDIATE instead of IKE_AUTH is that it allows IKE_AUTH to be fully protected. This means that the ID payloads sent in the IKE_AUTH are protected against quantum computers. 2. In addition to the IKE_AUTH being fully protected, the initial IKE SA is also fully protected, which is important for those IKE which transfer sensitive information, e.g. cryptographic keys, over initial IKE SA. The prominent example of such extensions is [I-D.ietf-ipsecme-g-ikev2]. 3. As the PPK exchange happens as separate exchange before IKE_AUTH this means that initiator can propose several PPKs and responder can pick one. This is not possible when PPK exchange happens in the IKE_AUTH. This feature could simplify PPK rollover. 4. With this specification there is no need for the initiator to calculate the content of the AUTH payload twice (with and without PPK) to support a situation when using PPK is optional for both sides. And I think using PPK in IKE_AUTH and PPK in IKE_INTERMEDIATE as names for these two methods here, and I think that actually works well. > > 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 am fine leaving this out... > I've submitted a new version. Please check, whether your concerns > are resolved. I think changin to refer the old with "PPK in IKE_AUTH" and this method as "PPK in IKE_INTERMEDIATE" would make this document much better, and we should clarify that the section 3.2 is common for both PPK in IKE_AUTH and PPK in IKE_INTERMEDIATE. -- kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
