Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 08 January 2020 13:31 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75C91200F4; Wed, 8 Jan 2020 05:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yehm9UfKeyx; Wed, 8 Jan 2020 05:31:25 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E341200F1; Wed, 8 Jan 2020 05:31:25 -0800 (PST)
Received: from 200116b82ce1a4005104981634920ee5.dip.versatel-1u1.de ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipBQf-0002c0-8e; Wed, 08 Jan 2020 14:31:21 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <00e001d5c627$6c537290$44fa57b0$@elvis.ru>
Date: Wed, 08 Jan 2020 14:31:20 +0100
Cc: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org, david.waltermire@nist.gov, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9C49A2D-A441-4447-B834-C45AE8D1E9B2@kuehlewind.net>
References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> <BN7PR11MB2547A0216F2B8566B112811AC93E0@BN7PR11MB2547.namprd11.prod.outlook.com> <00bc01d5c605$ca5916f0$5f0b44d0$@elvis.ru> <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net> <00c801d5c61a$83eb6870$8bc23950$@elvis.ru> <840A17D3-61C5-4C22-B5E0-E8A89AF0AB31@kuehlewind.net> <00e001d5c627$6c537290$44fa57b0$@elvis.ru>
To: Valery Smyslov <svan@elvis.ru>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578490285;c347dea9;
X-HE-SMSGID: 1ipBQf-0002c0-8e
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/xj-uWxLQJ_2MLBxI2BAQeejJbIo>
Subject: Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 13:31:28 -0000
Hi Valery, Inline again. > On 8. Jan 2020, at 14:27, Valery Smyslov <svan@elvis.ru> wrote: > > Hi Mirja, > >> Hi Valery, >> >> Please see inline. >> >>> On 8. Jan 2020, at 12:55, Valery Smyslov <svan@elvis.ru> wrote: >>> >>> Hi Mirja, >>> >>>> Hi Panos, hi Valery, >>>> >>>> Please see below. >>>> >>>>> On 8. Jan 2020, at 10:27, Valery Smyslov <svan@elvis.ru> wrote: >>>>> >>>>> 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. >>>> >>>> I think what you propose is actually to replace the MAY by a MUST. In >> any >>>> case using normative language is helpful here because that is an action >> that >>>> needs to be implemented somehow, so the implementor would need to >>>> know what the protocol is supposed to do. >>> >>> I have no problem with using normative MUST here, since it doesn't >>> change the meaning of the text. That said, I still prefer to avoid using >>> it here (by following section 6 of RFC2119), because in my >>> understanding it is just a description of protocol behaviour and not a >> special requirement. >> >> This depends: if you look at this from the receiver side, it a description of >> the protocol behaviour. But for the sender it’s an action that must be >> specified. I think the below text is mention to describe the requirement on >> the sender, so normative language is appropriate. Maybe the wording “the >> initiation indicates” is confusing here and it should actually say “the initiator >> includes a NO_PPK_AUTH notification to indicate this optionality to the >> responder“…? > > 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. > > [...] > >>>>>> 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. Mirja > > Regards, > Valery. > > [...] > >> Mirja >> >> >>> >>> Regards, >>> Valery. >>> >>>> Mirja >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> Valery. >>>>> >>>>>> Rgs, >>>>>> Panos >>>>>> >>>>>> -----Original Message----- >>>>>> From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Mirja Kühlewind >> via >>>>>> Datatracker >>>>>> Sent: Tuesday, January 07, 2020 8:41 AM >>>>>> To: The IESG <iesg@ietf.org> >>>>>> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; >> david.waltermire@nist.gov; >>>>>> draft-ietf-ipsecme-qr-ikev2@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] Mirja Kühlewind's No Objection on draft-i… Mirja Kühlewind via Datatracker
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Panos Kampanakis (pkampana)
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Valery Smyslov
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Mirja Kuehlewind
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Valery Smyslov
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Mirja Kuehlewind
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Valery Smyslov
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Mirja Kuehlewind
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Valery Smyslov
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Mirja Kuehlewind
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Valery Smyslov
- Re: [IPsec] Mirja Kühlewind's No Objection on dra… Paul Wouters