Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
"Valery Smyslov" <smyslov.ietf@gmail.com> Wed, 08 January 2020 14:09 UTC
Return-Path: <smyslov.ietf@gmail.com>
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 7E1401200B4; Wed, 8 Jan 2020 06:09:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ul_0q-WSjUMd; Wed, 8 Jan 2020 06:09:53 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 2240012008B; Wed, 8 Jan 2020 06:09:53 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id w1so3471571ljh.5; Wed, 08 Jan 2020 06:09:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=lLH765aqSfBMJkUwHIj2RcT6X/v8MQvP09gP/8M2LnA=; b=W/KW8H9iMGes4ok56NZPI+ffeXe/LWx76a0NYlLHH1c27A9IR0xTlklA5q0aTF78ZR c+5ouaESp40xi4qSxPRLirUcxuOXHxGxvYKWNohC9UM3a0lCdS8xfSzUehgccV+5NCMH FVGGovqzfgcJNLyPs8W3WqLLVKQNVSU1LKxkvyncnsH5OlLvL+H7Fna1gy/yNZZXIpmh WCM+yzpYFBpgLzFbfgXZH7qMBwkWVMtqdBcociTvkU1U1GMG+E1lEPwVztddTmVdmYcE HIvs5dytoYAA55784MxvzZGFLJ6ModqKqOhPN8b2LJZIdYe3R1ewdwAC1F3YQnBSlFMw +tQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=lLH765aqSfBMJkUwHIj2RcT6X/v8MQvP09gP/8M2LnA=; b=sfPn1nI57ZEqY0RFe6VKBabWg5uk0R1f/AQtzuvRus44ndG9JtqdTvqEh0NzQnj653 +OLDgzC/qZ8msfS+xVCrZ67vAQpdFzDku9p0IGYrGBvXkpDGd/hgomVRY7E51v5/TjP8 CGvgSb2PnTJH0JwIaYLu7cwCOm7tpoU11WXF4vel1wKy6jVwKK44yCNx0QExTYvfPN4b 5LgqxISWZo1/K4m1wbfsLclXb44hW3Yfug6ZpnKhgHRo3Ce23RBgWISyMcRP0+jmgLSa /zzAP0fdS0L5Pig2R+fL1r5R7vbjlY6MM9tgrJz/DVPNO0ESUXUamm9B+y4HOX+81pXQ HMDQ==
X-Gm-Message-State: APjAAAV4vupKx/5Nc5M7HUAyAbAYBbWUpSjRRObiyhn9iDCVTzbGhpKJ FHa3Bv7sorDJx2WbvYUoX8g=
X-Google-Smtp-Source: APXvYqyT4xP+nGAuxwVprOq5/RirZe8ATrjXAM5IbIX4+RwnqByptjOzaoV1VkpLZ7KbfZ72Q1weVQ==
X-Received: by 2002:a2e:9613:: with SMTP id v19mr3041885ljh.47.1578492591355; Wed, 08 Jan 2020 06:09:51 -0800 (PST)
Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id l1sm1435608lfj.71.2020.01.08.06.09.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jan 2020 06:09:50 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>, 'Valery Smyslov' <svan@elvis.ru>
Cc: ipsecme-chairs@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org, "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, 'The IESG' <iesg@ietf.org>
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> <A9C49A2D-A441-4447-B834-C45AE8D1E9B2@kuehlewind.net> <00ea01d5c62c$84270cb0$8c752610$@elvis.ru> <E6D47E9D-E877-4590-84CA-A889759DBC65@kuehlewind.net>
In-Reply-To: <E6D47E9D-E877-4590-84CA-A889759DBC65@kuehlewind.net>
Date: Wed, 08 Jan 2020 17:09:48 +0300
Message-ID: <00eb01d5c62d$49b8e660$dd2ab320$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGY4KgrgL+s46p1j/ZhtxErcpkYXQMbldDrAeYv7v4CDBb0iwFmxbgmArS44bYB5ziBPwFLHo29AlMwRyIBvfLOVafHMnAQ
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Wn7cv94pYHIq_y7mmMfLfAjWE-M>
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 14:09:56 -0000
> Hi Valery, > > Both look good to me. Thanks! > > One typo: s/mesages/messages/ Thank you! Regards, Valery. > Thanks! > Mirja > > > > > On 8. Jan 2020, at 15:04, Valery Smyslov <svan@elvis.ru> 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 <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 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