Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Valery Smyslov <svan@elvis.ru> Wed, 08 January 2020 13:28 UTC

Return-Path: <svan@elvis.ru>
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 8BE9F1200F4; Wed, 8 Jan 2020 05:28:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Nc_TU1pbauM5; Wed, 8 Jan 2020 05:28:00 -0800 (PST)
Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA14F1200B7; Wed, 8 Jan 2020 05:28:00 -0800 (PST)
Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1ipBNM-0006cm-65; Wed, 08 Jan 2020 16:27:56 +0300
Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1ipBNK-00015B-Tx; Wed, 08 Jan 2020 16:27:56 +0300
Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 8 Jan 2020 16:27:54 +0300
Received: from chichi (10.100.100.7) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 8 Jan 2020 16:27:51 +0300
From: Valery Smyslov <svan@elvis.ru>
To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>
CC: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, 'The IESG' <iesg@ietf.org>, david.waltermire@nist.gov
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>
In-Reply-To: <840A17D3-61C5-4C22-B5E0-E8A89AF0AB31@kuehlewind.net>
Date: Wed, 08 Jan 2020 16:27:49 +0300
Message-ID: <00e001d5c627$6c537290$44fa57b0$@elvis.ru>
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/ZhtxErcpkYXQMbldDrAeYv7v4CDBb0iwFmxbgmArS44baoATotAA==
Content-Language: ru
X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru
X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru
X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: Clean, bases: 2020/01/08 12:33:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2020/01/08 02:05:00 #14989725
X-KLMS-AntiVirus-Status: Clean, skipped
X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/otkuDi8Xp-Tas9VSIQeytp6196w>
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:28:03 -0000

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?

[...]

> >>>> 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.

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
> >>>
> >>>
> >
> >
> >