Hi Valery, Both look good to me. Thanks!
One typo: s/mesages/messages/ Thanks! Mirja > On 8. Jan 2020, at 15:04, Valery Smyslov <[email protected]> wrote: > > Hi Mirja, > > [...] > >>> It is definitely better, thank you! >>> >>> For this purpose, if using PPKs for communication with this responder >>> is optional for the initiator (based on the mandatory_or_not flag), >>> then the initiator includes a NO_PPK_AUTH notification in the above >> message >>> to indicate this optionality to the responder. >>> >>> Is it OK now? >> >> >> I still think use of normative language would be appropriate here. > > OK. > > For this purpose, if using PPKs for communication with this responder > is optional for the initiator (based on the mandatory_or_not flag), > then the initiator MUST include a NO_PPK_AUTH notification in the above > message to indicate this optionality to the responder. > >>> [...] >>> >>>>>>>> 3) Waiting for one or two RTTs is probably a good rule. The side- >> effect >>>>>> could >>>>>>>> be that the initiator stays waiting for responses for too long which >>>> delays >>>>>>>> the handshake. I am not sure we can mandate in absolute time >>>> because >>>>>> it >>>>>>>> depends on the relative distance between client and server. We can >>>>>>>> probably include " (e.g., one round-trip) " in the text. >>>>>>> >>>>>>> I think one or two RTT is too short, moreover since it's an initial >> request, >>>>>>> no RTT is yet measured (IKEv2 uses UDP as primary transport). >>>>>>> We try here to be in line with core IKEv2 spec, which deliberately >>>>>>> doesn't give any concrete figures of how long to wait for an response >>>>>>> (section 2.4 of RFC7296). So, I'd leave the text as is. >>>>>> >>>>>> Kind of same here. Given you two disagree here already, I think it >> would >>>> be >>>>>> good to give further advise. >>>>> >>>>> I'm reluctant to provide concrete figures, because RFC7296 deliberately >>>>> doesn't do it and this is just an extension to the IKEv2. I'd rather >> reference >>>>> the core spec here. How about the following text: >>>>> >>>>> To thwart >>>>> this kind of attack it is RECOMMENDED, that if using PPKs is >>>>> mandatory for the initiator and the received response doesn't contain >>>>> the USE_PPK notification, then the initiator doesn't abort the >>>>> exchange immediately, but instead waits for more responses >>>>> retransmitting the request until either the received message >>>>> contains the USE_PPK or connection times out (see section 2.4 of >>>> [RFC7296] >>>>> for more details). If all the received responses contain no USE_PPK, >> then >>>> the exchange is aborted. >>>> >>>> I looked at section 2.4 of RFC7296 and the situation is actually different >>>> there because the initiator will accept/open multiple connections and >> then >>>> close them again if detected to not be proper. >>> >>> I meant another part of 2.4: >>> >>> The number of retries and length of timeouts are not covered in this >>> specification because they do not affect interoperability. >>> >>>> So there is state anyway. Here you don’t have an open connection and >> therefore you need an >>>> timeout. >>> >>> Sure we need a timeout. But this is exactly the same timeout which >>> IKEv2 initiator uses when trying to establish initial connection with the >> peer. >>> >>>> I would recommend to at least say something like: >>>> "Ideally the timeout would be in the order of the RTT plus additional >>>> processing delays at the responder. As these times are not known the >>>> timeout should be choosen sufficiently larger, however, state may be >>>> removed anytime when needed (e.g. in an attack situation).” >>>> >>>> (Please use your own wording…) >>> >>> The whole idea of thwarting this attack is not to trust >>> the responses not containing USE_PPK notification (suspecting that they >> may be forged). >>> So the initiator continues to retransmit and wait for other responses. >>> For how long? For the same period of time that it would retransmit and >> wait for any response >>> as if no responses were received at all. So, we introduce no new timeouts >> here >>> comparing with the core spec. >> >> Okay. I wasn’t aware that these are existing time-outs. I think the document >> could be more clear about this then. > > Is this better? > > To thwart > this kind of attack it is RECOMMENDED, that if using PPKs is > mandatory for the initiator and the received response doesn't contain > the USE_PPK notification, then the initiator doesn't abort the > exchange immediately, but instead waits for more response mesages > retransmitting the request as if no responses were received at all, > until either the received message contains the USE_PPK or exchange times out > (see section 2.4 of [RFC7296] for more details on retransmission timers in > IKEv2). > If all the received responses contain no USE_PPK, then the exchange is > aborted. > > Regards, > Valery. > >> Mirja >> >> >> >>> >>> Regards, >>> Valery. >>> >>> [...] >>> >>>> Mirja >>>> >>>> >>>>> >>>>> Regards, >>>>> Valery. >>>>> >>>>>> Mirja >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Valery. >>>>>>> >>>>>>>> Rgs, >>>>>>>> Panos >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: IPsec <[email protected]> On Behalf Of Mirja >> Kühlewind >>>> via >>>>>>>> Datatracker >>>>>>>> Sent: Tuesday, January 07, 2020 8:41 AM >>>>>>>> To: The IESG <[email protected]> >>>>>>>> Cc: [email protected]; [email protected]; >>>> [email protected]; >>>>>>>> [email protected] >>>>>>>> Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf- >> ipsecme- >>>> qr- >>>>>>>> ikev2-10: (with COMMENT) >>>>>>>> >>>>>>>> Mirja Kühlewind has entered the following ballot position for >>>>>>>> draft-ietf-ipsecme-qr-ikev2-10: No Objection >>>>>>>> >>>>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email >>>>>>>> addresses included in the To and CC lines. (Feel free to cut this >>>>>> introductory >>>>>>>> paragraph, however.) >>>>>>>> >>>>>>>> >>>>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss- >>>> criteria.html >>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>> >>>>>>>> >>>>>>>> The document, along with other ballot positions, can be found here: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> COMMENT: >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> 1) One small question on section 3: >>>>>>>> "if using PPKs for communication with this responder >>>>>>>> is optional for the initiator, then the initiator MAY include a >>>>>>>> notification NO_PPK_AUTH in the above message." >>>>>>>> This does mean that NO_PPK_AUTH notification should not be sent >>>> when >>>>>>>> the mandatory_or_not flag indicates that PPK is mandatory, right? >> Or >>>> is >>>>>> that >>>>>>>> a separate configuration? Would be good to clarify in the doc! >>>>>>>> >>>>>>>> 2) Section 6 says: >>>>>>>> "In this situation, it is RECOMMENDED >>>>>>>> that the initiator caches the negative result of the negotiation for >>>>>>>> some time and doesn't make attempts to create it again for some >>>> time," >>>>>>>> Would it be possible to give any hints about what "some time" >> means >>>> or >>>>>> at >>>>>>>> least the order of magnitude? Maybe it could be recommended to >>>> wait a >>>>>>>> couple of seconds? Or how long is it usually expected to take until >> the >>>>>> half- >>>>>>>> open connection will be expired? >>>>>>>> >>>>>>>> 3) Also here: >>>>>>>> "then the initiator doesn't abort the >>>>>>>> exchange immediately, but instead waits some time for more >>>> responses >>>>>>>> (possibly retransmitting the request)." >>>>>>>> How long should one wait? Probably 1-2 RTTs if the RTT is known or >>>>>> maybe >>>>>>>> there is some good max value like 500ms or 1s or more...? Is there >>>> any >>>>>> risk >>>>>>>> in waiting too long? >>>>>>>> >>>>>>>> 3) And one high-level comment (without knowing to much details >>>> about >>>>>>>> IKEv2): >>>>>>>> Would it be possible do a downgrade detection, meaning when >> non- >>>> PKK >>>>>>>> encryption is established the initiator would tell the responser again >>>> that >>>>>> it >>>>>>>> was initially requesting PKK, just to double-check...? >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> IPsec mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> > > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
