> > > 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.
Anyway, those were only proposals. > > 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.... :-) Alas :-) > > 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-WG > > 0/ > > 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... That's true. > > 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. I've been always thinking that only "IPSec" is a form for which one would get punished by the chairs since Paul's H. chairing :-) Nowadays even SEC ADs use "IPSECME" in their slides: https://datatracker.ietf.org/meeting/120/materials/slides-120-saag-chair-sli des Perhaps let them know this is unacceptable? :-) Kidding aside, I've changed to "IPsecME". > > 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... I did my best to address this. Please check. > > 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... I disagree, it does. I prefer notification format to depend on notify type than on notification content. > 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. It is not that simple. Actually, your proposal complicates code and adds potential vulnerabilities. Note, that the current draft uses both PPK_IDENTITY_KEY (with confirmation) in request and PPK_IDENTITY (w/o confirmation, the same as in RFC 8784) in response. All PPK_ID types (currently defined and future) are eligible to appear in both notifications. The reason two notification are used is that only responder checks the confirmation. The initiator proposes PPK and provides the confirmation, the responder checks whether it is correct. There is no need for initiator to check it again, thus the confirmation is omitted in response. If it were included in the response then we'd have a bunch of problems: the initiator have either check it again (for what?) or ignore. In the former case we have to handle situations when the confirmation is incorrect (that actually is difficult to be handled gracefully, since this is probably a broken responder implementation in which case the initiator should not even inform the responder about the problem, making it difficult to debug if that happens). In the latter case we have a perfect covert channel (data that is transmitted, but never used in the protocol), which I want to avoid. For these reason the response doesn't include confirmation and uses different notification type. > > > 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 :-) I can help you :-) https://www.rfc-editor.org/rfc/rfc8784.html#name-exchanges > > 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. IKE_INTERMEDIATE (RFC 9242) doesn't define how additional keys are stirred into session keys computation - it is agnostic to this key derivation. It is Multiple Key Exchanges (RFC 9370) which does. Both this specification and RFC 9370 use IKE_INTERMEDIATE, but they are independent from each other and I see no reason why they have to use the same method for key derivation. I can even imagine that some new specification appears in the future that will rely on IKE_INTERMEDIATE and specify another method (more secure or more efficient) for session keys calculation. > 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 Yes, this is a perfectly valid situation. I routinely test this case in my testbed. > 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. No, this is incorrect interpretation. The draft says: Once the PPK is negotiated in the last IKE_INTERMEDIATE exchange, the IKE SA keys are recalculated. Note that if the IKE SA keys are also recalculated as the result of the other actions performed in the IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]), then applying PPK MUST be done after all of them, so that recalculating IKE SA keys with PPK is the last action before they are used in the IKE_AUTH exchange. So, the correct sequence is: 1) complete what RFC 9370 requires SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) {SK_d(n) | SK_ai(n) | SK_ar (n)| SK_ei(n) | SK_er(n) | SK_pi(n) | SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr ) (actually, you only need SK_d(n) here, so if you are smart enough skip computation of all other SK_*) 2) apply PPK to the result SKEYSEED' = prf+ (PPK, SK_d(n)) {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr ) > 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... See above for the rationale. In addition the proposed use of PPK is more challenging for some reasons. In particular, standard use of prf assumes that the first argument is a random (usually secret) key and the second argument is an arbitrary (usually public) data. When you apply secret key as a public argument, this may be challenging in some cryptographic libraries and sometimes requires hacks (well, I know that IKEv2 uses this inversion when SKEYSEED is being initially calculated and we need to handle this, but for the very good reason - you know that nonces are random and the result of DH computation - not, so you _have_ to swap them to meet the cryptographic requirements the standard prf requires for its arguments). > > > 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 added a clarification: 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 (no matter how: in IKE_AUTH, in IKE_INTERMEDIATE or in CREATE_CHILD_SA) or not. > 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> I don't think it updates RFC 8784, since it doesn't affect operations described there (unless you think that the ability to make additional use of PPKs not mentioned there is qualified as "update"). So, I rely on the chairs whether this draft should be an update for RFC 8784. > 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? In this case it should be Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security (isn't it too long?) And I also changed a short title to "Enhanced Use of PPKs in IKEv2". And since "alternative approach" is no more used in the text of the document, it makes sense to rename the notify: s/USE_PPK_ALT/USE_PPK_INT > > 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. Done. > > > 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. I used the proposed text with some modifications: 1. The main advantage of using PPK in the IKE_INTERMEDIATE exchange instead of the IKE_AUTH exchange is that it allows IKE_AUTH to be fully protected. This means that the ID payloads and any other sensitive content sent in the IKE_AUTH are protected against quantum computers. The prominent example of situation when cryptographic keys are transferred in the modified IKE_AUTH exchange (called GSA_AUTH) of G-IKEv2 [I-D.ietf-ipsecme-g-ikev2]. 2. In addition to the IKE_AUTH exchange being fully protected, the initial IKE SA is also fully protected, which is important when sensitive information, e.g. cryptographic keys, is transferred over initial IKE SA. The prominent example of such situation is the GSA_REGISTRATION exchange of G-IKEv2 [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. > > 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. I've submitted yet another version. Please check, there are some other text changes, that logically followed the proposed ones. Let's see how many iterations we need to converge :-) Regards, Valery. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
