Ok, all good with me. Thanks Valery! Sent using a virtual keyboard on a phone
> On Nov 30, 2022, at 12:03, Valery Smyslov <[email protected]> wrote: > > We are converging :-) > >>> I'm a bit reluctant to add all this information to the abstract. It is >>> already a bit too long >>> (since Éric and Warren suggested to augment it with the explanation text of >>> how >>> this design helps in situation when PQ algorithms are less trusted). So >>> currently >>> the abstract is: >>> >>> This document describes how to extend the Internet Key Exchange >>> Protocol >>> Version 2 (IKEv2) to allow multiple key exchanges to take place >>> while computing a shared secret during a Security Association (SA) >>> setup. >>> >>> The primary application of this feature in IKEv2 is the ability to >>> perform one or more >>> post-quantum key exchanges in conjunction with the classical >>> (Elliptic Curve) Diffie-Hellman (EC)DH >> key exchange, >>> so that the resulting shared key is resistant against quantum >>> computer attacks. >>> Since there is currently no post-quantum key exchange that is trusted >>> at >>> the level that (EC)DH is trusted for against conventional >>> (non-quantum) >>> adversaries, performing multiple key exchanges with different >>> post-quantum algorithms along >>> with the well-established classical key exchange algorithms addresses >>> this concern, since the >>> overall security is at least as strong as each individual primitive. >>> >>> Another possible application for this extension is the ability to >>> combine several key exchanges >>> in situations when no single key exchange algorithm is trusted by >>> both initiator and responder. >>> >>> This document updates RFC7296 by renaming a transform type 4 from >>> "Diffie-Hellman Group (D-H)" >>> to "Key Exchange Method (KE)" and renaming a field in the Key >>> Exchange Payload from "Diffie- >> Hellman Group Num" >>> to "Key Exchange Method". It also renames an IANA registry for this >>> transform type >>> from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to >>> "Transform Type 4 - Key Exchange Method Transform IDs". These changes >>> generalize >>> key exchange algorithms that can be used in IKEv2. >>> >>> Do you *really* want to make it longer? I'm not sure that if we just mention >>> the names of the added exchange and notifies, that will help readers of the >>> abstract >>> to understand what this document is about... >> >> This document updates RFC7296. It introduces the IKE_FOLLOWUP_KE Exchange. >> It renames [...] >> >>> [update] >>> >>> I've just noticed your message sent in response to Warren. So, since you >>> insist :-), >>> I suggest adding the following text before "This document updates...": >>> >>> This document utilizes the IKE_INTERMEDIATE exchange to perform multiple >>> key exchanges when >>> an IKE SA is being established and introduces a new IKEv2 exchange >>> IKE_FOLLOWUP_KE to perform >>> them when IKE SA is up (during rekeys or creating additional Child SAs). >>> >>> is it now OK? >> >> Also fine :) > > Great! > >>>> I don't think it would hurt pointing to Section 2.4 of RFC 7296. I see >>>> this as a likely possible implemention mistake. >>> >>> My problem with your proposal here is that this situation is not >>> specific to this document. In other words, whether the initiator >>> proposes any additional key exchanges or not, if an attacker >>> manages to send a response before the genuine responder >>> and the initiator continues establishing IKE SA using this response, >>> then it will fail. There is nothing specific to the multiple key exchanges. >>> And we implicitly assume that implementations follow RFC 7296. >> >> I want to prevent code like: >> >> if (AKE-required && !AKE-received) >> return STF_FATAL // kills state >> >> I know it is a "reminder", but I think an important one. > > RFC 7296 states that the proposed defense against this attack is a MAY > (due to relatively high cost of the defense). So, I've added the following > text at the end > of 3.2.1: > > It is possible that an attacker manages to send a response to the > initiator's IKE_SA_INIT request > before the genuine responder. If the initiator continues creating IKE SA > using this response, the attempt will fail. > Implementers may wish to consider a possible defense technique described > in Section 2.4 of [RFC7296]. > > We really cannot advise something marked as MAY, we can only remind that this > technique exists. > >>>> Just give it some thought, but if we leave it as is that is fine too. >>> >>> As I'm lazy, I prefer to do nothing here (unless you or my co-authors >>> strongly disagree :-)) >> >> Fine with me. Can't get worse than CREATE_CHILD_SA I guess :P > > CREATE_CHILD_SA_FOLLOWUP_KEY_EXCHANGE? :-) > Oh, sorry, you seemed to propose something similar :-) > >>>> I also think that is only a reason to ignore the CREATE_CHILD_SA, and >>>> not a reason to destroy the existing IKE SA (and thus any existing Child >>>> SA) >>> >>> Well, generally invalid response means that there is something wrong >>> with the peer thus we cannot be sure that it follows spec. >> >> Yeah but stabbing them in the heart in case they might be dying is a bit >> drastic :P >> >> Put it in another way, I would violate the RFC on this point and keep >> the existing IKE SA until its lifetime has been reached. >> >>>>> I think that the text may be clarified a bit. How about? >>>> >>>> I guess first we need to agree on what to do..... >>> >>> OK, let me clarify our point. >>> >>> First, there is nothing specific to the multiple key exchanges here. The >>> situation is that >>> the responder sends a message that is inappropriate from the protocol point >>> of view. >>> There may be many reasons to consider it inappropriate - missing mandatory >>> payload, incorrect choice of algorithms etc., this specification just adds >>> one >>> more reason - duplicated algorithms. >>> >>> What should the initiator do in this situation? It generally cannot send >>> INVALID_SYNTAX, >>> since RFC 7296 discourages doing so (section 2.21.3): >>> >>> Because sending such >>> error messages as an INFORMATIONAL exchange might lead to further >>> errors that could cause loops, such errors SHOULD NOT be sent. >>> >>> The initiator generally cannot continue using this SA, because of possible >>> the states on the peers are now out of sync (the responder thinks the >>> exchange completed >> successfully). >>> So the safe way is to delete the problem SA. If it is not yet created, then >>> just stop creating it, >>> otherwise send a Delete payload. >>> >>> Note, that the text you proposed >>> >>> the initiator should log the error and MUST abort the exchange with a >>> permanent error >>> >>> actually has the same consequence. Since the responder sent a response with >>> no error notify, >>> it thinks that the exchange is completed successfully. On the other hand, >>> your text suggests >>> that the initiator treat this exchange as failed. So, the states on the >>> initiator and the responder >>> are now out of sync. RFC 7296 states (2.21.3): >>> >>> If errors are seen that indicate that the peers do not have the same >>> state, it might be good to delete the IKE SA to clean up state and >>> start over. >> >> "might" :-) > > Yes, RFC 7296 is not very clear here, using RFC 2119 language would be more > appropriate :-) > >> Again, I agree on killing the newly failed SA. But let's say you have an >> IKE SA up and a Child SA up (might even be a child using classic algo >> only), I don't see why adding a new Child SA that fails should kill the >> existing functional Child SA and IKE SA. >> >> Sure there should be a loop detection and exponential back-off on >> failures to prevent a DoS of trying to get this post-quantum Child SA >> up. But tearing down the existing Child SA and IKE SA will presumbly >> just cause a more complicated loop anyway. These working SA's will come >> back up again and then get torn down again when the post-quantum Child >> SA fails. So I don't think your suggestion is better. > > Well, to get to some compromise we can state in the draft that in this > situation > the initiator MAY send a Delete payload to delete the IKE SA itself > and MUST NOT initiate any IKE_FOLLOWUP_KE exchanges. > > If the responder's message contains one or more duplicated choices, the > initiator > should log the error and MUST treat the exchange as failed. > The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) > exchanges, so that no new SA is created. > If this happens in the CREATE_CHILD_SA exchange, then the initiator MAY > delete the IKE SA, > over which the invalid message was received, by sending a Delete payload. > > Is it OK now? > >>>>>> ### Section 3.2.2 >>>>>> ``` >>>>>> The other keying materials SK_d, SK_ai, SK_ar, SK_ei, >>>>>> SK_er, SK_pi, SK_pr are updated as: >>>>>> >>>>>> [...] >>>>>> ``` >>>>>> Why not say: The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er, >>>>>> SK_pi, SK_pr are generated from the SKEYSEED(n) as per RFC 7296. >>>>> >>>>> No objection. >>>> >>>> Just to clarify, where I wrote [...] I meant to cover the illustration >>>> under the text as well. The point of this change was to not repeat a >>>> stock 7296 exchange (which might confuse implementers in believeing this >>>> is different from stock 7296) >>> >>> I'd rather to keep the illustration. There is a subtle difference from RFC >>> 7296 - >>> while keys have "generation", the SPIs and nonces are used from the >>> IKE_SA_INIT. >>> The illustration makes this difference more clear, in my opinion. >> >> If you want to keep the illustration, then just ignore this entire >> change I proposed or it becomes duplicative. > > OK. > > The updated PR is available at: > https://github.com/post-quantum/ietf-pq-ikev2/pull/22 > >> If you get a new draft before tomorrow 10am EST, I can update my DISCUSS >> to a YES ballot :) > > We'll do our best :-) > > Thank you, > Valery. > >> Paul > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
