Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
> On Jan 8, 2020, at 04:41, Mirja Kuehlewind wrote: > >> >> 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 agree with Valerie. We don’t do that on purpose. A 100gbps connection is different from a satellite connection. Let the implementation handle that part. >> I agree with Panos: the downgrade is possible only if using PPK is optional >> for both, in which case both parties agree that downgrade is OK. > > Having some downgrade detection would enable to log an attack if optional PPK > was used. That would be lost in the noise when using mixed ppl/noppk use I think. As said, one is expected to only allow noppk during migration, which would be very limited in time (like hours or days for static tunnels, maybe weeks or a few months for remote access VPN updates to happen) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
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 On Behalf Of Mirja > >> Kühlewind > >>>> via > >>>>>>>> Datatracker > >>>>>>>> Sent: Tuesday, January 07, 2020 8:41 AM > >>>>>>>> To: The IESG > >>>>>>>> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; > >>>> david.walterm...@nist.gov; > >>>>>>>> draft-ietf-ipsecme-qr-ik...@ietf.org > >>>>>>>> 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 > >>>>>>>> IPsec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > > > > > > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
(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 On Behalf Of Mirja >> Kühlewind >>>> via >>>>>>>> Datatracker >>>>>>>> Sent: Tuesday, January 07, 2020 8:41 AM >>>>>>>> To: The IESG >>>>>>>> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; >>>> david.walterm...@nist.gov; >>>>>>>> draft-ietf-ipsecme-qr-ik...@ietf.org >>>>>>>> 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 >>>>>>>> IPsec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> > > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
lear 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 On Behalf Of Mirja > Kühlewind > >> via > >>>>>> Datatracker > >>>>>> Sent: Tuesday, January 07, 2020 8:41 AM > >>>>>> To: The IESG > >>>>>> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; > >> david.walterm...@nist.gov; > >>>>>> draft-ietf-ipsecme-qr-ik...@ietf.org > >>>>>> 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 > >>>>>> IPsec@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ipsec > >>>>> > >>>>> > >>> > >>> > >>> > > > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
;>> (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. Mirja > > Regards, > Valery. > > [...] > >> Mirja >> >> >>> >>> Regards, >>> Valery. >>> >>>> Mirja >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> Valery. >>>>> >>>>>> Rgs, >>>>>> Panos >>>>>> >>>>>> -Original Message- >>>>>> From: IPsec On Behalf Of Mirja Kühlewind >> via >>>>>> Datatracker >>>>>> Sent: Tuesday, January 07, 2020 8:41 AM >>>>>> To: The IESG >>>>>> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; >> david.walterm...@nist.gov; >>>>>> draft-ietf-ipsecme-qr-ik...@ietf.org >>>>>> 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/ >>>>>> >>>>>> >>>&g
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
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. Regards, Valery. [...] > Mirja > > > > > > Regards, > > Valery. > > > >> Mirja > >> > >> > >> > >>> > >>> Regards, > >>> Valery. > >>> > >>>> Rgs, > >>>> Panos > >>>> > >>>> -Original Message- > >>>> From: IPsec On Behalf Of Mirja Kühlewind > via > >>>> Datatracker > >>>> Sent: Tuesday, January 07, 2020 8:41 AM > >>>> To: The IESG > >>>> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; > david.walterm...@nist.gov; > >>>> draft-ietf-ipsecme-qr-ik...@ietf.org > >>>> 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 > >>>> IPsec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ipsec > >>> > >>> > > > > > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
; and doesn't make attempts to create it again for some time. > This period of time may vary, but it is believed that waiting >for at least few minutes before next connection attempt will not cause > the responder to treat it as DoS attack. Note, that this situation > is most likely a result of misconfiguration and some re- > configuration of the peers would probably be needed. Sounds good to me. Thanks! > >>>> 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. So there is state anyway. Here you don’t have an open connection and therefore you need an timeout. 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…) > >>>> 4) I am not sure adding one more notification for downgrade detection >>>> adds much here. Remember IKEv2 has subsequent messages to do >>>> IKE_AUTH etc and we wanted to not introduce more significant >> deviations >>>> on IKEv2. >>>> >>>> If the PPK is optional for both peers then downgrade is possible but it is >> the >>>> cost of being flexible to allow some peers to use PPK and some to not. If >> any >>>> of the peers has PPK as mandatory then downgrade will be caught and >>>> rejected as explained in the Sec Considerations section, so I think we are >> OK >>>> there. >>> >>> I agree with Panos: the downgrade is possible only if using PPK is optional >>> for both, in which case both parties agree that downgrade is OK. >> >> Having some downgrade detection would enable to log an attack if optional >> PPK was used. > > The downgrade attack here is mostly a theoretical one. To successfully > mount it an attacker must be able to break digital signatures in real time > (i.e. within a minute). Given the figures Scott Fluhrer has posted to the > ipsecme list, > it is unlikely to be achievable even when full scale quantum computers > are build. Besides, prerequisites for this attack are that an attacker > be able to modify IKE messages (i.e. be on the path) and peers use signatures > for authentication. > >> This could give further insights for the network admin or >> provide some motivation to move quickly to mandatory PPK. Alternative >> you could of course even have another config option where PPK is optional >> but you still close the connection with an error if downgrade is detected >> later on. Was just an idea… > > Note, that a requirement to log the situation when both peers have PPK and > the SA is created > without using it is alrea
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
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. > >> 4) I am not sure adding one more notification for downgrade detection > >> adds much here. Remember IKEv2 has subsequent messages to do > >> IKE_AUTH etc and we wanted to not introduce more significant > deviations > >> on IKEv2. > >> > >> If the PPK is optional for both peers then downgrade is possible but it is > the > >> cost of being flexible to allow some peers to use PPK and some to not. If > any > >> of the peers has PPK as mandatory then downgrade will be caught and > >> rejected as explained in the Sec Considerations section, so I think we are > OK > >> there. > > > > I agree with Panos: the downgrade is possible only if using PPK is optional > > for both, in which case both parties agree that downgrade is OK. > > Having some downgrade detection would enable to log an attack if optional > PPK was used. The downgrade attack here is mostly a theoretical one. To successfully mount it an attacker must be able to break digital signatures in real time (i.e. within a minute). Given the figures Scott Fluhrer has posted to the ipsecme list, it is unlikely to be achievable even when full scale quantum computers are build. Besides, prerequisites for this attack are that an attacker be able to modify IKE messages (i.e. be on the path) and peers use signatures for authentication. > This could give further insights for the network admin or > provide some motivation to move quickly to mandatory PPK. Alternative > you could of course even have another config option where PPK is optional > but you still close the connection with an error if downgrade is detected > later on. Was just an idea… Note, that a requirement to log the situation when both peers have PPK and the SA is created without using it is already in the draft (as SHOULD). And any failed connection attempt is usually an auditable event. Regards, Valery. > Mirja > > > > > > > Regards, > > Valery. > > > >> Rgs, > >> Panos > >> > >> -Original Message- > >> From: IPsec On Behalf Of Mirja Kühlewind via > >> Datatracker > >> Sent: Tuesday, January 07, 2020 8:41 AM > >> To: The IESG > >> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; > >> draft-ietf-ipsecme-qr-ik...@ietf.org > >> 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 > &g
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
ou could of course even have another config option where PPK is optional but you still close the connection with an error if downgrade is detected later on. Was just an idea… Mirja > > Regards, > Valery. > >> Rgs, >> Panos >> >> -Original Message- >> From: IPsec On Behalf Of Mirja Kühlewind via >> Datatracker >> Sent: Tuesday, January 07, 2020 8:41 AM >> To: The IESG >> Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; >> draft-ietf-ipsecme-qr-ik...@ietf.org >> 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 >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi Panos, Mirja, > Hi Mirja, > > To try to answer your questions > > 1) You are right. This is mentioned in a paragraph below that reads > >[...] or continue without using the >PPK (if the PPK was not configured as mandatory and the initiator >included the NO_PPK_AUTH notification in the request). > > But for clarity we will slightly rephrase the sentence you pointed out to > >only if using PPKs for communication with this responder >is optional for the initiator (based on the mandatory_or_not flag), >then the initiator MAY include a notification NO_PPK_AUTH in the >above message. After re-reading this para, I think that uppercase "MAY" is not needed here, because if the initiator doesn't include NO_PPK_AUTH, then it leaves no chances for the responder to complete IKE SA without using PPK, so in this case using PPK becomes in fact mandatory. I think the proper text should be: 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 notification NO_PPK_AUTH in the above message. > 2) It is a little hard to include a time that would match all situations. It > really > depends on the server DoS protection policy and when it kicks on. The > initiator cannot really know how fast is considered too fast for the > responder so it has to make a conservative decision. Adding a " (e.g., > seconds) " would probably suffice here. Since this situation is most probably caused by misconfiguration (or some attack), I think that the period of inactivity for the initiator should be longer, at least several minutes. Anyway, I agree that it's hard to give universal advice here. I'd leave the text as is, since the reference to "misconfiguration" in this para gives in my opinion enough hint of how long to wait. > 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. > 4) I am not sure adding one more notification for downgrade detection > adds much here. Remember IKEv2 has subsequent messages to do > IKE_AUTH etc and we wanted to not introduce more significant deviations > on IKEv2. > > If the PPK is optional for both peers then downgrade is possible but it is the > cost of being flexible to allow some peers to use PPK and some to not. If any > of the peers has PPK as mandatory then downgrade will be caught and > rejected as explained in the Sec Considerations section, so I think we are OK > there. I agree with Panos: the downgrade is possible only if using PPK is optional for both, in which case both parties agree that downgrade is OK. Regards, Valery. > Rgs, > Panos > > -Original Message- > From: IPsec On Behalf Of Mirja Kühlewind via > Datatracker > Sent: Tuesday, January 07, 2020 8:41 AM > To: The IESG > Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; > draft-ietf-ipsecme-qr-ik...@ietf.org > 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 notif
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi Mirja, To try to answer your questions 1) You are right. This is mentioned in a paragraph below that reads [...] or continue without using the PPK (if the PPK was not configured as mandatory and the initiator included the NO_PPK_AUTH notification in the request). But for clarity we will slightly rephrase the sentence you pointed out to only if using PPKs for communication with this responder is optional for the initiator (based on the mandatory_or_not flag), then the initiator MAY include a notification NO_PPK_AUTH in the above message. 2) It is a little hard to include a time that would match all situations. It really depends on the server DoS protection policy and when it kicks on. The initiator cannot really know how fast is considered too fast for the responder so it has to make a conservative decision. Adding a " (e.g., seconds) " would probably suffice here. 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. 4) I am not sure adding one more notification for downgrade detection adds much here. Remember IKEv2 has subsequent messages to do IKE_AUTH etc and we wanted to not introduce more significant deviations on IKEv2. If the PPK is optional for both peers then downgrade is possible but it is the cost of being flexible to allow some peers to use PPK and some to not. If any of the peers has PPK as mandatory then downgrade will be caught and rejected as explained in the Sec Considerations section, so I think we are OK there. Rgs, Panos -Original Message- From: IPsec On Behalf Of Mirja Kühlewind via Datatracker Sent: Tuesday, January 07, 2020 8:41 AM To: The IESG Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; draft-ietf-ipsecme-qr-ik...@ietf.org 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
