From nobody Wed Jan 1 14:01:22 2020 Return-Path: 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 40390120020 for ; Wed, 1 Jan 2020 14:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 AvBA-UA0Ldi5 for ; Wed, 1 Jan 2020 14:01:19 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8CECB12000F for ; Wed, 1 Jan 2020 14:01:19 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 001M1DRv016874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Jan 2020 17:01:15 -0500 Date: Wed, 1 Jan 2020 14:01:12 -0800 From: Benjamin Kaduk To: Paul Wouters Cc: Sean Turner , IPsec List Message-ID: <20200101220112.GG35479@kduck.mit.edu> References: <20191223184651.GC35479@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 22:01:21 -0000 On Mon, Dec 30, 2019 at 09:41:11PM -0500, Paul Wouters wrote: > On Mon, 23 Dec 2019, Benjamin Kaduk wrote: > > > "this document" (i.e., the RFC-to-be) does not actually effecuate the move > > to Historic status; the separate "status-change" document does so. Looking > > at a recent example in RFC 8429, we see this phrased akin to "Accordingly, > > IKEv1 has been moved to Historic status" with no claim of doing so because > > of the current document. > > Changed, see https://tools.ietf.org/rfcdiff?url2=draft-pwouters-ikev1-ipsec-graveyard-04.txt > > Paul > > >> requests IANA to close all IKEv1 registries. > >> > >> 2: Change section title > >> > >> s/Deprecating IKEv1/RFC 2409 to Historic > > > > This is probably okay to keep (I see Paul took the changes already), but > > the first sentence is still "IKEv1 is deprecated", which is sending mixed > > signals. > > Is it a mixed signal? I've left the sentence in for now, but I'm fine if > we decide to remove it. I can always do that after adoption when I need > to re-submit the draft under the new name anyway. I guess it's not entirely clear. https://ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ implies that "Historic" is for technology that is "retired", but in some usage, "deprecated" has more of a connotation of "not the best choice right now" which is not necessarily fully "retired". We can leave it as-is for now. -Ben From nobody Fri Jan 3 01:13:43 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2087120044; Fri, 3 Jan 2020 01:13:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <157804281685.20483.2187565509491747863.idtracker@ietfa.amsl.com> Date: Fri, 03 Jan 2020 01:13:36 -0800 Archived-At: Subject: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 09:13:37 -0000 Éric Vyncke 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: ---------------------------------------------------------------------- Thank you for the work put into this document. I found it very interesting to read BTW. I have only one minor non-blocking comment: please read RFC 8126 to have a correct IANA section about "type 16435" (and others). Same applies for section 5.1. I hope that this helps to improve this document or any future one of yours, Regards, -éric From nobody Fri Jan 3 18:11:15 2020 Return-Path: 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 AD5AD12006F; Fri, 3 Jan 2020 18:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 NdRbqN5gFxV3; Fri, 3 Jan 2020 18:11:11 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17E01200DB; Fri, 3 Jan 2020 18:11:10 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id C4E6825C10E8; Sat, 4 Jan 2020 04:11:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24079.62523.749850.19969@fireball.acr.fi> Date: Sat, 4 Jan 2020 04:11:07 +0200 From: Tero Kivinen To: =?iso-8859-1?Q?=C9ric?= Vyncke Cc: "The IESG" , draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, ipsec@ietf.org In-Reply-To: <157804281685.20483.2187565509491747863.idtracker@ietfa.amsl.com> References: <157804281685.20483.2187565509491747863.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: Subject: [IPsec] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-i?= =?iso-8859-1?q?etf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 02:11:14 -0000 =C9ric Vyncke via Datatracker writes: > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - >=20 > Thank you for the work put into this document. I found it very > interesting to read BTW. I have only one minor non-blocking comment: > please read RFC 8126 to have a correct IANA section about "type > 16435" (and others). Same applies for section 5.1. As an IANA expert for those registries, I have no idea why you think the IANA Section for them are not correct. What do you think is wrong with them=3F The 16435 number has already been allocated from the Status notification registry by IANA, and as far I as understand the IANA section for creating the "IKEv2 Post-quantum Preshared Key ID Types" contains everything that is needed. --=20 kivinen@iki.fi From nobody Fri Jan 3 21:02:23 2020 Return-Path: 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 CF54D12006B; Fri, 3 Jan 2020 21:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.097 X-Spam-Level: X-Spam-Status: No, score=-13.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mLzvYRTn; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Ly+tu5Q6 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 ePR80FXZabeC; Fri, 3 Jan 2020 21:02:13 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E575B120020; Fri, 3 Jan 2020 21:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45257; q=dns/txt; s=iport; t=1578114132; x=1579323732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l73AI/pu3LY4M9DRWw/KBtcixsgaS3LORQ2sQlGkWkc=; b=mLzvYRTnd2NuGdKWTj3w3HLeWx2a/ZLtW2d8KDIw3jtw2ZlTX7hEvtCK KVhG5H93ZsOoK+PyzT87batJ9GK8caDihXs8ncKTKOZ/pMzgXjgy9eliF 9v+OorFG1sGkYLNhrI8F1qrlq+PGoJr1e1jnFhXIogkuN3kGCkmZn9PKB w=; X-Files: Diff_ draft-ietf-ipsecme-qr-ikev2-10.xml - draft-ietf-ipsecme-qr-ikev2-11.xml.html, smime.p7s : 33231, 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AjpGxWRZ2qzUChy5qbKg2lrf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAADsGxBe/5NdJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoFAQELAYFTKScFbBMYLSAECyqECYFegWgDiwGCX4EBhyaPZoE?= =?us-ascii?q?uFIEQA1QCBwEBAQkDAQEYAQoKAgEBgwqBNgKBaSQ2Bw4CAw0BAQQBAQECAQU?= =?us-ascii?q?EbYU3DIVeAQEBAQMBARARBAYTAQEpAwsBCwQCAQgRBAEBHgMBCQICAiULGgM?= =?us-ascii?q?IAgQBDQUIBhSCNUyBeU0DHw8BAgygWgKBOIhhdX8zgn4BAQWBSUGCfhiCBQc?= =?us-ascii?q?JgTYBgVKKRhqBQT+BEUeCFzU+glkLAQEBAQEBGIEUAQsHASErgmMygiyNJCm?= =?us-ascii?q?CcYV7gh6FKIUvi24KgjWDYYI4gRuPAYJGdocHhEGLVoNHiwyIU5IGAgQCBAU?= =?us-ascii?q?CDgEBBYFZCSlnWBEIcBUaIYJsCUcYDYYuhkAkBwIaFYM7hRSFP3QBgSeLNBE?= =?us-ascii?q?XgTxfAQE?= X-IronPort-AV: E=Sophos;i="5.69,393,1571702400"; d="html'217?p7s'217?scan'217,208,217";a="696763935" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jan 2020 05:01:47 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 00451lwm001733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 4 Jan 2020 05:01:47 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 Jan 2020 23:01:46 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 Jan 2020 23:01:46 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 4 Jan 2020 00:01:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jWh178bLtx84jBNoGWvnDpbll/pKUo4mxLVIFY2QNo6yErHMeeIQcif4/iyYPSIpEwoyLpJG42u029N9HHut6hqVXhess32F2NjBgF40pS6zprUPO7yIYXkfOrpjij9XJ0P5FUlUn/EnKucITDIbJS4xi2kTzhcy3EHP6y0OEgCUVfBy/CHjsJxfDTdKtGPU0ggfpeIKD9IBmd2C5bIOc3ZANjtJTI6g1wMuErjKM15ZmxBjbBJ7Pg8yHOLLChAuOyXAk7AGCRypxoR5CgAUr7PREKOxzVxIOhL4lzbyeC9Xq2iOXUHRrLbN1I9wRdZJ70sqa/qwC4w2jUF6LkPF/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vMXcjxdvlu//4wEJS30TwqMDvOXSjlLW9LFgWdk9EjM=; b=csTkF2ElQ1AlRvb2a89VeZ8rXF692xLCx6YauMVmX8c9nztkULnZ/vU6LTVhKyqo8CiSuDPi0r8vcx7jApoqszmN5HKmbTzaQSg5H1QZHVLqiPnBpFo0MTuu/sQ/jC8kdhNbYg1iczDdl5rw62zjmmqZX+Q+FC6uZvg+WA0lUFJRD1vATNmOBxLjHnHtIZs9AOy4TtZV3io3J3dno+V4oz4PEyjgeyLAkUopKeKXKf85FkDNnAIYetUItQjviJiRZGjkuW64glw0aG6rplXxq8/reb1Qjk+9H1hrKm65KdH4Vl+dvzKQtQoP9wZjgCysvZoy0HASyokwfdBcZfFN9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vMXcjxdvlu//4wEJS30TwqMDvOXSjlLW9LFgWdk9EjM=; b=Ly+tu5Q6HscUIkNRaiXn5tZT7AzD+XO8Rc99MXAShwnp8LT+CZ/4VrmwxLUDkL7+720b5SYC6NihnqxWjrZsoF4//8kVdvEnM/bXv/A97vwjBwiLfKevlq/y1R1Th7zI/QLwKzS1GKxd5tPjq82DyxyFSX8PLCwzrD4o+FeW6Tg= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2658.namprd11.prod.outlook.com (52.135.255.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Sat, 4 Jan 2020 05:01:45 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2602.012; Sat, 4 Jan 2020 05:01:45 +0000 From: "Panos Kampanakis (pkampana)" To: "Eric Vyncke (evyncke)" , The IESG CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: =?utf-8?B?W0lQc2VjXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-ipsecme-qr-ikev2-10:_(with_COMMENT)?= Thread-Index: AQHVwhYmI5qLfWVavkSUZ9xvy2nhFKfZ8v3w Date: Sat, 4 Jan 2020 05:01:45 +0000 Message-ID: References: <157804281685.20483.2187565509491747863.idtracker@ietfa.amsl.com> In-Reply-To: <157804281685.20483.2187565509491747863.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1008::241] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 94f52f41-5d13-4a50-17d5-08d790d33251 x-ms-traffictypediagnostic: BN7PR11MB2658: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(366004)(346002)(376002)(501584002)(469094003)(13464003)(199004)(189003)(86362001)(76116006)(66446008)(66946007)(66476007)(66556008)(64756008)(66616009)(71200400001)(478600001)(2906002)(7696005)(966005)(52536014)(33656002)(316002)(224303003)(54906003)(110136005)(6506007)(81156014)(5660300002)(53546011)(4326008)(55016002)(81166006)(9686003)(8936002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2658; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5YggZ6EsCzdQpO2nQLaJj32Z4mjVSs3C2zK/2SNiDRMMLXN6fCCF2Lg2egysF1EH2ao2T0VZ4qc7de8Y8XMI3ZHGjP/SqofmRH5xV/AZXYV/Sqo2e2vfqo7I+BwvqBiwJNoWcESUQBLq8EI5Xsqo/6uL5c7nheSEoIJVRn5TAV2jG1pZPfGVe3qO+0nSaPm47FqEb+Orx3252Vl8SvYc3YzRehOwoRbkLYg/+9YAN1UHbf6V4HrTUrzDBHAFoue48zarURTeMR9WgctsPhmyc/JQTe/HDyndAsqmVmfRwkHAnbYcElAZUgPWS4vjqQAVGcWq2QdvdV0Edu4ILf0LIdWj19nosVU+zfjiyHxheObH2WdoptmU9+Z6VelUDEEVnHhxN3lrZvO9oY9RRMecwB92cJvE3lI9UYzQMZ37/2Iyzzas1mG+i21WRQfC0gm1jUr2WEBXe9TSDc75yi9nwInOHFTn8pxXhyJpZnuzw3onWrdu/EEWZ1Btj5WPAgLjPDbJWFeLg6AOMjCE1iXDUECMaoPlzm3ckc0z5LXACiCBBOqDEbdnedvoUUehR/0sdsf90buhrZ/MGNsfiMZk5g== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0005_01D5C292.26160A10" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 94f52f41-5d13-4a50-17d5-08d790d33251 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2020 05:01:45.1639 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2s53/023LxAm/ec9mcnTQoQcGYFes7BW6NpKESRF4SUxuOxLT4fUj+oTdaUlMJ0qWMA2m3fraVFuAXxctzZSpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2658 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 05:02:16 -0000 ------=_NextPart_000_0005_01D5C292.26160A10 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0006_01D5C292.26160A10" ------=_NextPart_001_0006_01D5C292.26160A10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi =C3=89ric,=20 To improve the IANA section a bit we followed the guidelines in RFC8126 = more religiously and I am attaching the diff here.=20 Let me know if there are more changes you would like to suggest for the = IANA section.=20 Rgs, Panos -----Original Message----- From: IPsec On Behalf Of =C3=89ric Vyncke via = Datatracker Sent: Friday, January 03, 2020 4:14 AM To: The IESG Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; david.waltermire@nist.gov; = draft-ietf-ipsecme-qr-ikev2@ietf.org Subject: [IPsec] =C3=89ric Vyncke's No Objection on = draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) =C3=89ric Vyncke 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: ---------------------------------------------------------------------- Thank you for the work put into this document. I found it very = interesting to read BTW. I have only one minor non-blocking comment: = please read RFC 8126 to have a correct IANA section about "type 16435" = (and others). Same applies for section 5.1. I hope that this helps to improve this document or any future one of = yours, Regards, -=C3=A9ric _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_001_0006_01D5C292.26160A10 Content-Type: text/html; name="Diff_ draft-ietf-ipsecme-qr-ikev2-10.xml - draft-ietf-ipsecme-qr-ikev2-11.xml.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Diff_ draft-ietf-ipsecme-qr-ikev2-10.xml - draft-ietf-ipsecme-qr-ikev2-11.xml.html" =0A= =0A= =0A= =0A= =0A= Diff: draft-ietf-ipsecme-qr-ikev2-10.xml - = draft-ietf-ipsecme-qr-ikev2-11.xml =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
< draft-ietf-ipsecme-qr-ikev2-10.xml  draft-ietf-ipsecme-qr-ikev2-11.xml >
=
skipping to = change at = line 46 =C2=B6 = skipping to change at line 46 =C2=B6
<!-- use = symbolic references tags, i.e, [RFC2119] instead of [1] --> = <!-- use symbolic references tags, i.e, = [RFC2119] instead of [1] -->
<?rfc = sortrefs=3D"yes" ?> <?rfc = sortrefs=3D"yes" ?>
<!-- sort the = reference entries alphabetically --> <!-- sort the reference entries alphabetically = -->
<!-- control = vertical white space <!-- control = vertical white space
(using these = PIs as follows is recommended by the RFC Editor) --> = (using these PIs as follows is recommended = by the RFC Editor) -->
<?rfc = compact=3D"yes" ?> <?rfc = compact=3D"yes" ?>
<!-- do not = start each main section on a new page --> <!-- do not start each main section on a new page = -->
<?rfc = subcompact=3D"no" ?> <?rfc = subcompact=3D"no" ?>
<!-- keep one = blank line between list items --> <!-- keep one blank line between list items = -->
<!-- end of = list of popular I-D processing instructions --> <!-- end of list of popular I-D processing = instructions -->
<rfc = category=3D"std" docName=3D"draft-ietf-ipsecme-qr-ikev2-10" ipr=3D"trust2009=0A= 02"> <rfc category=3D"std" = docName=3D"draft-ietf-ipsecme-qr-ikev2-11" = ipr=3D"trust2009=0A= 02">
<!-- = category values: std, bcp, info, exp, and historic <!-- category values: std, bcp, info, exp, and = historic
ipr values: = full3667, noModification3667, noDerivatives3667 ipr values: full3667, noModification3667, = noDerivatives3667
you can add = the attributes updates=3D"NNNN" and obsoletes=3D"NNNN" you can add the attributes updates=3D"NNNN" and = obsoletes=3D"NNNN"
they will = automatically be output with "(if approved)" --> they will automatically be output with "(if = approved)" -->
=
<!-- ***** = FRONT MATTER ***** --> <!-- = ***** FRONT MATTER ***** -->
=
= <front> <front>
<!-- The = abbreviated title is used in the page header - it is only nece=0A= ssary if the <!-- The = abbreviated title is used in the page header - it is only nece=0A= ssary if the
full = title is longer than 39 characters --> full title is longer than 39 characters = -->
=
skipping to = change at = line 166 =C2=B6 = skipping to change at line 166 =C2=B6
<t>It = was considered important to minimize the changes to IKEv2. = <t>It was considered important to = minimize the changes to IKEv2.
The = existing mechanisms to do authentication and key exchange = remain The existing mechanisms = to do authentication and key exchange remain
in place = (that is, we continue to do (EC)DH, and potentially PKI = in place (that is, we continue to do = (EC)DH, and potentially PKI
= authentication if configured). This document does not replace the aut=0A= hentication authentication if = configured). This document does not replace the aut=0A= hentication
checks that = the protocol does; instead, it is done as a parallel chec=0A= k.</t> checks that the = protocol does; instead, it is done as a parallel chec=0A= k.</t>
=
<section = title=3D"Changes"> = <section title=3D"Changes">
= <t>RFC EDITOR PLEASE DELETE THIS SECTION.</t> = <t>RFC EDITOR PLEASE DELETE THIS = SECTION.</t>
= <t>Changes in this draft in each version = iterations.</t> = <t>Changes in this draft in each version = iterations.</t>
=
= <t>draft-ietf-ipsecme-qr-ikev2-11
= <list = style=3D"symbols">
= = <t>Updates the IANA section based on Eric V.'s IESG = Review.</t>
= = </list></t>
= =
= <t>draft-ietf-ipsecme-qr-ikev2-10 <t>draft-ietf-ipsecme-qr-ikev2-10
<list = style=3D"symbols"> <list = style=3D"symbols">
= <t>Addresses issues raised during IETF LC.</t> = <t>Addresses issues raised = during IETF LC.</t>
= </list></t> = </list></t>
=
= <t>draft-ietf-ipsecme-qr-ikev2-09 <t>draft-ietf-ipsecme-qr-ikev2-09
<list = style=3D"symbols"> <list = style=3D"symbols">
= <t>Addresses issues raised in AD review.</t> = <t>Addresses issues raised in = AD review.</t>
= </list></t> = </list></t>
=
=
skipping to = change at = line 567 =C2=B6 = skipping to change at line 572 =C2=B6
for = those implementations that choose not to disclose the type of=0A= PPK to active attackers.</t> = for those implementations that choose not to disclose the type of=0A= PPK to active attackers.</t>
=
= <t>PPK_ID_FIXED (2) - in this case the format of the PPK_ID and t=0A= he PPK are fixed octet strings; the remaining bytes of the = <t>PPK_ID_FIXED (2) - in this = case the format of the PPK_ID and t=0A= he PPK are fixed octet strings; the remaining bytes of the
PPK_ID = are a configured value. We assume that there is a fixed m=0A= apping between PPK_ID and PPK, which is PPK_ID are a configured value. We assume that = there is a fixed m=0A= apping between PPK_ID and PPK, which is
= configured locally to both the initiator and the responder. The =0A= responder can use the PPK_ID to look up the corresponding = configured locally to both the = initiator and the responder. The =0A= responder can use the PPK_ID to look up the corresponding
PPK = value. Not all implementations are able to configure arbitrar=0A= y octet strings; to improve the potential interoperability, = PPK value. Not all implementations = are able to configure arbitrar=0A= y octet strings; to improve the potential interoperability,
it is = recommended that, in the PPK_ID_FIXED case, both the PPK an=0A= d the PPK_ID strings be limited to the base64 character set, = it is recommended that, in the = PPK_ID_FIXED case, both the PPK an=0A= d the PPK_ID strings be limited to the base64 character set,
namely = the 64 characters 0-9, A-Z, a-z, + and /.</t> namely the 64 characters 0-9, A-Z, a-z, + and = /.</t>
= </list></t> = </list></t>
=
<t>The PPK_ID type value 0 is reserved; = values 3-127 are reserved f=0A= or IANA; values 128-255 are for private use among mutually consenting = parti=0A= es.</t>
= </section> = </section>
=
<section = title=3D"Operational Considerations"> <section title=3D"Operational = Considerations">
= <t>The need to maintain several independent sets of security creden=0A= tials can significantly complicate a security administrator's = job, <t>The need to = maintain several independent sets of security creden=0A= tials can significantly complicate a security administrator's = job,
and can = potentially slow down widespread adoption of this specifica=0A= tion. It is anticipated, that administrators will try to simplify their = job and can potentially slow = down widespread adoption of this specifica=0A= tion. It is anticipated, that administrators will try to simplify their = job
by = decreasing the number of credentials they need to maintain. This=0A= section describes some of the considerations for PPK = management.</t> by = decreasing the number of credentials they need to maintain. This=0A= section describes some of the considerations for PPK = management.</t>
= <section title=3D"PPK Distribution"> <section title=3D"PPK = Distribution">
= <t>PPK_IDs of the type PPK_ID_FIXED (and the corresponding PPKs) =0A= are assumed to be configured within the IKE device in an out-of-band = fashio=0A= n. <t>PPK_IDs of the = type PPK_ID_FIXED (and the corresponding PPKs) =0A= are assumed to be configured within the IKE device in an out-of-band = fashio=0A= n.
= While the method of distribution is a local matter and out=0A= of scope of this document or IKEv2, <xref target=3D"RFC6030"/> = describes a f=0A= ormat for While the = method of distribution is a local matter and out=0A= of scope of this document or IKEv2, <xref target=3D"RFC6030"/> = describes a f=0A= ormat for
for the = transport and provisioning of symmetric keys. That format=0A= could be reused using the PIN profile (defined in Section 10.2 of = <xref ta=0A= rget=3D"RFC6030"/>) for = the transport and provisioning of symmetric keys. That format=0A= could be reused using the PIN profile (defined in Section 10.2 of = <xref ta=0A= rget=3D"RFC6030"/>)
=
skipping to = change at = line 680 =C2=B6 = skipping to change at line 684 =C2=B6
= immediately, but instead waits some time for more responses (possibly=0A= retransmitting the request). = immediately, but instead waits some time for more responses (possibly=0A= retransmitting the request).
If all the = received responses contain no USE_PPK, then the exchange i=0A= s aborted.</t> If all the = received responses contain no USE_PPK, then the exchange i=0A= s aborted.</t>
=
<t>If = using PPK is optional for both peers, then in case of misconfig=0A= uration (e.g. mismatched PPK_ID) the IKE SA <t>If using PPK is optional for both peers, = then in case of misconfig=0A= uration (e.g. mismatched PPK_ID) the IKE SA
will be = created without protection against quantum computers. It is a=0A= dvised that if PPK was configured, but will be created without protection against quantum = computers. It is a=0A= dvised that if PPK was configured, but
was not = used for a particular IKE SA, then implementations SHOULD aud=0A= it this event. was not used for = a particular IKE SA, then implementations SHOULD aud=0A= it this event.
= </t> </t>
= </section> = </section>
=
<section = title=3D"IANA Considerations"> = <section title=3D"IANA Considerations">
= <t>This document defines three new Notify Message Types in the = "Notif=0A= y Message Types - Status Types" registry:</t> <t>This document defines three new Notify = Message Types in the "Notif=0A= y Message Types - Status Types" registry = (https://www.iana.org/assignments/=0A= ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16):</= t>
<figure = align=3D"center"> <figure = align=3D"center">
= <artwork align=3D"left"><![CDATA[ <artwork = align=3D"left"><![CDATA[
16435 = USE_PPK [THIS RFC] 16435 = USE_PPK [THIS RFC]
16436 = PPK_IDENTITY [THIS RFC] 16436 = PPK_IDENTITY [THIS RFC]
16437 = NO_PPK_AUTH [THIS RFC] 16437 = NO_PPK_AUTH [THIS RFC]
= ]]></artwork> = ]]></artwork>
= </figure> = </figure>
=
= <t>This document also creates a new IANA registry "IKEv2 = Post-quantum=0A= Preshared Key ID Types" in = <t>This document also creates a new IANA registry "IKEv2 = Post-quantum=0A= Preshared Key ID Types" in
IKEv2 = IANA registry (https://www.iana.org/assignments/ikev2-parameter=0A= s/) for the PPK_ID types. The initial values of the new registry = are:</t> IKEv2 IANA = registry (https://www.iana.org/assignments/ikev2-parameter=0A= s/) for the PPK_ID types used in the notification = messages defined in this =0A= specification. The initial values of the new registry = are:</t>
<figure = align=3D"center"> <figure = align=3D"center">
= <artwork align=3D"left"><![CDATA[ <artwork = align=3D"left"><![CDATA[
PPK_ID Type = Value Reference PPK_ID = Type Value Reference
----------- = ----- --------- ----------- ----- ---------
Reserved = 0 [THIS RFC] Reserved = 0 [THIS RFC]
PPK_ID_OPAQUE = 1 [THIS RFC] PPK_ID_OPAQUE 1 [THIS RFC]
PPK_ID_FIXED = 2 [THIS RFC] PPK_ID_FIXED 2 [THIS RFC]
Unassigned = 3-127 [THIS RFC] Unassigned 3-127 [THIS RFC]
Reserved for private use 128-255 [THIS = RFC] Private = Use 128-255 [THIS RFC]
= ]]></artwork> = ]]></artwork>
= </figure> = </figure>
=
= <t>Changes and additions to this registry = are by Expert Review <xref =0A= target=3D"RFC8126" />.</t> <t>The PPK_ID type = value 0 is reserved; values 3-127 are to be assign=0A= ed by IANA; values 128-255 are for private use among mutually consenting = pa=0A= rties. To register new PPK_IDs in the unassigned range, a Type name, a = Valu=0A= e between 3 and 127 and a Reference specification need to be defined. = Chang=0A= es and additions to the unassigned range of this registry are by the = Expert=0A= Review Policy <xref target=3D"RFC8126" />. Changes and additions = to the priv=0A= ate use range of this registry are by the Private Use Policy <xref = target=3D"=0A= RFC8126" />.</t>
= </section> = </section>
= </middle> = </middle>
=
<!-- = *****BACK MATTER ***** --> = <!-- *****BACK MATTER ***** -->
=
= <back> <back>
<!-- = References split into informative and normative --> <!-- References split into informative and = normative -->
= <references title=3D"Normative References"> <references title=3D"Normative = References">
= &RFC2119; = &RFC2119;
= &RFC8174; = &RFC8174;
 End of changes. 7 change blocks. 
6 lines changed or = deleted 10 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/t= ools/rfcdiff/
=0A= =0A= =0A= ------=_NextPart_001_0006_01D5C292.26160A10-- ------=_NextPart_000_0005_01D5C292.26160A10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA0MDUwMTQzWjAvBgkqhkiG9w0BCQQxIgQgbDcck74TbfVE7o5qmn9uSqwbW/BMzfy2 SdikGCNPGWIwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA QWyE3D0tEKl0iYzb6ei2hZgZF2pn31uHIlJ7YDq/f0XQHrwhlCulF+aiofyD6l86Q2Wu7/2O9fwc X2SNVDuySnHpOblwlIRzyebeeXXEiyfx2jiOg10sZX/6fil9jHtPiwYL9PprVYa3QaaxEyoxMeVw U2Z8jR/cCJEOzoPp4XE4VWl86YIFd+8/NFAD9uRk3Zb2sEG4upvxe8l9KhMLpRFYBgNtLiiwMsNE +PyQKRwovuC+KZa/a0FakxgtX+xBPmRz6TalU4w2xSvYchDvMsefPwEwzg2Bx8KCDfU+dYyMJ6k1 WPyJ2SIPzbqt3MnMWPe4zsE6p/Q/7Yxsck+/dgAAAAAAAA== ------=_NextPart_000_0005_01D5C292.26160A10-- From nobody Sat Jan 4 00:06:17 2020 Return-Path: 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 B54D8120124; Sat, 4 Jan 2020 00:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=F/Y20LP4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vDOoaQsZ 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 ySulwYxc3yMH; Sat, 4 Jan 2020 00:06:10 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B072D1200BA; Sat, 4 Jan 2020 00:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1824; q=dns/txt; s=iport; t=1578125169; x=1579334769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LkMCl4pckZv5+OrJeFVKW2U3+Hrg2TpsDy41Rrk7bZY=; b=F/Y20LP44qHR8039i86ekhT5G/7VDnEm4yJv7yAHepF2HmtvTh2REieG BiKZOklnvJh7N7hyGFsF6LZGza4FTmR7b5ZdJOwQZcz1CvB9sSDOXRpKm hgbgZH1kAbXfoBuKdii3dlFcr9aRlxPVPKcFX63ZdSizMx/jL09WFWbf2 o=; IronPort-PHdr: =?us-ascii?q?9a23=3AJJhoJhfLbpeuZ9LNhLhW1S/KlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YjIrGs9BWXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhAQCTRhBe/5hdJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWsEAQELAYFTUAWBRCAECyqECYNGA4sAgjqYMoJSA1QJAQEBDAE?= =?us-ascii?q?BLQIBAYRAAheBUiQ3Bg4CAw0BAQQBAQECAQUEbYU3DIVfAgEDEhERDAEBKQ4?= =?us-ascii?q?BDwIBCBoCJgICAjAVBQsCBA4FIoMAgkcDLgGgeAKBOIhhdYEygn4BAQWFDhi?= =?us-ascii?q?CDAmBDigBjBgagUE/gREnDBSCTD6ESReCeTKCLI1Ngjg5nl4KgjWWGhuCRod?= =?us-ascii?q?9hEGLVoNHpWUCBAIEBQIOAQEFgWgjgVhwFWUBgkFQGA2NEjiDO4pTdIEojXc?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.69,394,1571702400"; d="scan'208";a="403999181" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jan 2020 08:06:08 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 004868KS028667 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 4 Jan 2020 08:06:08 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 4 Jan 2020 02:06:08 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 4 Jan 2020 02:06:07 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 4 Jan 2020 03:06:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qcj576Vn5iJb2Jxlt1mNYFrM5bbiZBysGIRTE/tsyJZdndUuD6rU8v1FECQCGUYZSeBPAoYJ1mE9hAMrfybWndK908SztTPx9FUQ43bRVDxIyaUY1tExCfJkLsyIPzKQ4UyXHRTx+fHFabV9h/mRCK2hyqd3d3xN/QCE1ZIfRcRDQt2N/f7/uU/PQoNomD4u61a2LiE++7cq8mgfr7CrERftQu0r+dixdQq/xwPMBv5hBudmJNQwUlRFHaSutoot6SBfct+RLHtHqkCCVSYmNPnj1nkp2hsReMVwhopBvYgKeLah4rJgFH3k+1pj8Pnt81hre9b0qmJbljt0jV0ivw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LkMCl4pckZv5+OrJeFVKW2U3+Hrg2TpsDy41Rrk7bZY=; b=amJFCEw2cNd1xLUeasWgl0ilCdGh/KOLaBLHCg8M/jc2X3WMHoVubavepUgfQEYPlgSH0w7hLnhtHmYR50Dc12DK2XrwEbbGPjNgxbSIYz47a+yX6KCkXRfPFdkmpmZJZvA6WgMA8m60IE8tA3LG+zeVLCWSCobqpvczI02k1wgVhjtC96ktA8PBVPeuocieMOEUpMT7b8LklH64LnIGJVftlI66etCoWKPT7xzZ8n4z7IGdjqzH9kC6A3TxJ6sE6/jb///pLa0j1iS/fH7PCvhxIEuM71fCvfQrLr6LxadTnobvWzEVm4GmpCCmCwtOzZ/IOomBNBzE76E2p/OwWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LkMCl4pckZv5+OrJeFVKW2U3+Hrg2TpsDy41Rrk7bZY=; b=vDOoaQsZHMNXap8Iewn1XULvZFxFU4QNttPecZqDTUYrnc7Zuw8xWT9gAeLJ26JnIn17y2tROFjifabE893to2ZSf5/Fpus2JhvIceDdST6F3TCBl++igRftyF1tuchi+Y6oB/hfug5hu4rp5pTCsyDymRsQ8l981nhDTxnRrkg= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1417.namprd11.prod.outlook.com (10.168.103.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Sat, 4 Jan 2020 08:06:06 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::e513:46a6:f62f:6263]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::e513:46a6:f62f:6263%6]) with mapi id 15.20.2602.012; Sat, 4 Jan 2020 08:06:06 +0000 From: "Eric Vyncke (evyncke)" To: Tero Kivinen CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , David Waltermire , "The IESG" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaXBz?= =?utf-8?Q?ecme-qr-ikev2-10:_(with_COMMENT)?= Thread-Index: AQHVwqRP9cfXc/jNtE2DikLDpvrZeKfaNxqA Date: Sat, 4 Jan 2020 08:06:06 +0000 Message-ID: <7E566316-7267-4AC7-A79D-51AC2DA9EBC4@cisco.com> References: <157804281685.20483.2187565509491747863.idtracker@ietfa.amsl.com> <24079.62523.749850.19969@fireball.acr.fi> In-Reply-To: <24079.62523.749850.19969@fireball.acr.fi> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:212a:b0f9:c8c9:1c00] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54c77de2-e316-4825-1055-08d790ecf367 x-ms-traffictypediagnostic: DM5PR11MB1417: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39860400002)(376002)(346002)(199004)(189003)(8936002)(81156014)(316002)(54906003)(186003)(6506007)(33656002)(5660300002)(2616005)(478600001)(224303003)(81166006)(6486002)(36756003)(4326008)(66556008)(76116006)(86362001)(66446008)(2906002)(66946007)(71200400001)(6916009)(64756008)(91956017)(66476007)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1417; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ShG1F8OYqAB73hpPuSo2WwUrWddioEjialy36YinWXqIm6KqkFWPsEoyTA1CM8Xq3HwqMR2z0J6Z2NBtxcMRDSKtYtqTZ8JnwwLA5EuxtaZAbXswvbYm9FA1ysKbpgVR1lzY2HWlF/SFeY1bABBo2FP7smgw3nVyCf7LcsdJK6Ybmw/ypSNjNBTrBsqLyNQ6ud7NhCWdDsHFy4LhZmp8ERXjCpl2ni9NUqJ1BUziWnU6PQkUWaIoVfdNt74kGqDmwIm9p5OCukhHq907Se9RZnuQKk6ZCvF31NUPERzZx1UV+Y2E9Qgw6F1IFuVrj/pdjJMRJdMi5XvCAMMMED2UEDHbR2VWiu8zHTPCjzUPq0JpIjZ42W2Ui33FPyn1KzfDuAglihpT6vh/Ufdhl03PRnwUEzKnCiy2rRq8olrZh5IAfSZ44BmwuwxyWMALlva6 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 54c77de2-e316-4825-1055-08d790ecf367 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2020 08:06:06.5299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JIxAdQh03ZTCYVlyGMg8PV7LyevKWkxQe/LnOES+nUT7/WLeR7DnL5jX31GeBQY/5O/oZ3VXrmXJ7gNSCzXrrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1417 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 08:06:12 -0000 VGVybywNCg0KSW5kZWVkLCBJIHNob3VsZCBoYXZlIGNoZWNrZWQgdGhlIElBTkEgSUtFdjIgcmVn aXN0cnkgYmVmb3JlIHdyaXRpbmcgbXkgY29tbWVudC4gVGhlIElBTkEgdGFibGUgaGFzIGFscmVh ZHkgdGhlIHJlbGV2YW50IGVudHJpZXMgZm9yIFVTRV9QUEsgYW5kIG90aGVycyAoeW91IHByb2Jh Ymx5IGFza2VkIHNlcGFyYXRlbHkgYmVmb3JlKS4NCg0KTXkgYmFkLCBzb3JyeSBhYm91dCB0aGF0 DQoNCi3DqXJpYw0KDQrvu79PbiAwNC8wMS8yMDIwLCAwMzoxMSwgImllc2cgb24gYmVoYWxmIG9m IFRlcm8gS2l2aW5lbiIgPGllc2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2l2aW5l bkBpa2kuZmk+IHdyb3RlOg0KDQogICAgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciB3cml0 ZXM6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBDT01NRU5UOg0KICAgID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgID4gDQogICAgPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMg ZG9jdW1lbnQuIEkgZm91bmQgaXQgdmVyeQ0KICAgID4gaW50ZXJlc3RpbmcgdG8gcmVhZCBCVFcu IEkgaGF2ZSBvbmx5IG9uZSBtaW5vciBub24tYmxvY2tpbmcgY29tbWVudDoNCiAgICA+IHBsZWFz ZSByZWFkIFJGQyA4MTI2IHRvIGhhdmUgYSBjb3JyZWN0IElBTkEgc2VjdGlvbiBhYm91dCAidHlw ZQ0KICAgID4gMTY0MzUiIChhbmQgb3RoZXJzKS4gU2FtZSBhcHBsaWVzIGZvciBzZWN0aW9uIDUu MS4NCiAgICANCiAgICBBcyBhbiBJQU5BIGV4cGVydCBmb3IgdGhvc2UgcmVnaXN0cmllcywgSSBo YXZlIG5vIGlkZWEgd2h5IHlvdSB0aGluaw0KICAgIHRoZSBJQU5BIFNlY3Rpb24gZm9yIHRoZW0g YXJlIG5vdCBjb3JyZWN0LiBXaGF0IGRvIHlvdSB0aGluayBpcyB3cm9uZw0KICAgIHdpdGggdGhl bT8NCiAgICANCiAgICBUaGUgMTY0MzUgbnVtYmVyIGhhcyBhbHJlYWR5IGJlZW4gYWxsb2NhdGVk IGZyb20gdGhlIFN0YXR1cw0KICAgIG5vdGlmaWNhdGlvbiByZWdpc3RyeSBieSBJQU5BLCBhbmQg YXMgZmFyIEkgYXMgdW5kZXJzdGFuZCB0aGUgSUFOQQ0KICAgIHNlY3Rpb24gZm9yIGNyZWF0aW5n IHRoZSAiSUtFdjIgUG9zdC1xdWFudHVtIFByZXNoYXJlZCBLZXkgSUQgVHlwZXMiDQogICAgY29u dGFpbnMgZXZlcnl0aGluZyB0aGF0IGlzIG5lZWRlZC4NCiAgICAtLSANCiAgICBraXZpbmVuQGlr aS5maQ0KICAgIA0KICAgIA0KDQo= From nobody Mon Jan 6 09:24:48 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9F31208C7; Mon, 6 Jan 2020 09:24:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157833148623.8068.10752260409166984408.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 09:24:46 -0800 Archived-At: Subject: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:24:46 -0000 Alissa Cooper 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: ---------------------------------------------------------------------- I think this document should formally update RFC 7296. Was that discussed in the WG? I think the citation for [NISTPQCFP] should link to the actual call for proposals. Section 6: "In addition, the policy SHOULD be set to negotiate only quantum- resistant symmetric algorithms; while this RFC doesn't claim to give advice as to what algorithms are secure (as that may change based on future cryptographical results), below is a list of defined IKEv2 and IPsec algorithms that should not be used, as they are known to provide less than 128 bits of post-quantum security" This paragraph mixes normative SHOULD with non-normative "should not" in the same paragraph. I was wondering if that is intentional. From nobody Mon Jan 6 09:26:10 2020 Return-Path: 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 254FE120871; Mon, 6 Jan 2020 09:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cooperw.in header.b=0yg/yoR+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IJa6IEJC 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 ll6OqdYwDu-u; Mon, 6 Jan 2020 09:25:57 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9CE1208C1; Mon, 6 Jan 2020 09:25:57 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0E69D22101; Mon, 6 Jan 2020 12:25:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 06 Jan 2020 12:25:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=g egEicOU4QiNK0ZkIduJUWhOuZej/CpoFxG3rMhv3/g=; b=0yg/yoR+qLqA9iWk9 8mFWgXwkLSsPS9NvfeEmc9YpdsTtHLfnUmOWufmCvIt0FJFaYh15U+oi9kDxDMR2 hw9H9XyO9cC1X9CpoYA4a8QPOZeI2rjSC9aMFxuK3kDkhQIJfpipAm+4EqjeQF3F Bp6BlEaU/7hWvPR/pQ0yE7N/tMklpLSdCcnkB/s3orlXQ/M//zyIpmTYr+D7Eaye ggO/9dhtPiCdfTuFpqCW3b1qMo9eAl/etkDHczAKBA8BiIjvGP8cAQ7DX9gN5Yw6 KfinXwMM13UIxGwYNwTSOeK5Zg/EvNyTmnY6m991az3xzHK+eDd4e5Dn9AZHCQue RI61w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=gegEicOU4QiNK0ZkIduJUWhOuZej/CpoFxG3rMhv3 /g=; b=IJa6IEJCtt9AH1YHNVIzlsulawECrP3qPvVuIyj8FhN1YS74NrZ1o/aor 5MuOtjnT0mjgLSJDFP1QgWM2OngymEiow3TwpWEI8mGCUurOhi48HuM7X2P7EcQi ZGIP2U4GXir6oFQqY+0RZt5dtnRCDnLA0re0ir79tkCN4m4DQI22s+ZPWESYmjuz wiO3ckCBCQaN54Dt4nmPtunUk6k2bAljqdNpY1KKlg29ARozfe99XKqhyBBEZqGU vPhiz+Lh9lE9V/ITGO3c8eLYkjFgXZLpFPtV5cwoHM9AUVs4cp/joYSKdiRXH9x5 AMfAnBXleSy5pexyBQJAt8P5Zv1Lg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehtddguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekvdenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id A9D7C80066; Mon, 6 Jan 2020 12:25:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157626827886.12929.4367951047776204825@ietfa.amsl.com> Date: Mon, 6 Jan 2020 12:25:53 -0500 Cc: gen-art@ietf.org, ipsec@ietf.org, last-call@ietf.org, draft-ietf-ipsecme-qr-ikev2.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C65D43A-D669-44B2-BFC0-C4C14DA7CFF3@cooperw.in> References: <157626827886.12929.4367951047776204825@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:26:00 -0000 Christer, thanks for your review. Valery, thanks for your responses. I = entered a No Objection ballot. Alissa > On Dec 13, 2019, at 3:17 PM, Christer Holmberg via Datatracker = wrote: >=20 > Reviewer: Christer Holmberg > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ipsecme-qr-ikev2-09 > Reviewer: Christer Holmberg > Review Date: 2019-12-13 > IETF LC End Date: 2019-12-25 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: The document is well-written, and almost ready for = publication. > However, I have a couple of minor comments that I would like the = authors to > address. >=20 > Major issues: None >=20 > Minor issues: >=20 > Q1: >=20 > The Security Considerations lists IKEv2/IPSec algorithms that are not > considered quantum-resistant. However, that is not mentioned anywhere = else. I > think it would be good to mention that in the Abstract and/or = Introduction. >=20 > Q2: >=20 > Section 3 says: >=20 > "If the responder does not support this specification or does not = have > any PPK configured, then it ignores the received notification and > continues with the IKEv2 protocol as normal." >=20 > I assume the ignoring of a non-supported notification and continuing = with > normal IKEv2 is part of the IKEv2 specification. If so, I suggest to = say add > something like: >=20 > ", as described in RFCXXXX." >=20 > Nits/editorial comments: >=20 > Q3: >=20 > The Security Considerations talk about the Grover's algorithm. Please = add a > reference. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Jan 6 09:37:28 2020 Return-Path: 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 8DCC3120973; Mon, 6 Jan 2020 09:37:21 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 etVtt9VT_p44; Mon, 6 Jan 2020 09:37:19 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 BCBB1120970; Mon, 6 Jan 2020 09:37:19 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47s2kz2NDgzCvT; Mon, 6 Jan 2020 18:37:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1578332235; bh=4l62FELHloRWzowERG23INfgK80tZUykD+kUqu/zxxQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bd8jX9WpjwHEi7RecRUu9vrpP9DmcSGvb8HfoTE06QiRXpMcgeyfKyOHn+R2+RkW/ ZRGyMEs4MWUiw+0pyjfTLKiQojimZLNQ6GUOrdckHmF2CPRTbHY7ThuVlgNuDSHl37 4g3866qGehCrQckAXCgBFipPM3OZzp8pnRTTpKP4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FYcDC6cyQC7I; Mon, 6 Jan 2020 18:37:14 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 6 Jan 2020 18:37:14 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 34366602980B; Mon, 6 Jan 2020 12:37:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 307F466AA8; Mon, 6 Jan 2020 12:37:13 -0500 (EST) Date: Mon, 6 Jan 2020 12:37:13 -0500 (EST) From: Paul Wouters To: Alissa Cooper cc: The IESG , "ipsec@ietf.org WG" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org In-Reply-To: <157833148623.8068.10752260409166984408.idtracker@ietfa.amsl.com> Message-ID: References: <157833148623.8068.10752260409166984408.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Alissa Cooper'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:37:22 -0000 On Mon, 6 Jan 2020, Alissa Cooper via Datatracker wrote: > I think this document should formally update RFC 7296. Was that discussed in > the WG? Extensions do not update the core RFC, unless they change behaviour specified in that core RFC. That is, someone implementing the core RFC should know about this extension because they need to change something in their implementation of the core RFC (not this document). I do not think that is the case here. So I do not think it should Update 7296. > I think the citation for [NISTPQCFP] should link to the actual call for > proposals. Is that a really stable link? I'm sceptical (of most external links) > Section 6: > > "In addition, the policy SHOULD be set to negotiate only quantum- > resistant symmetric algorithms; while this RFC doesn't claim to give > advice as to what algorithms are secure (as that may change based on > future cryptographical results), below is a list of defined IKEv2 and > IPsec algorithms that should not be used, as they are known to > provide less than 128 bits of post-quantum security" > > This paragraph mixes normative SHOULD with non-normative "should not" in the > same paragraph. I was wondering if that is intentional. I think capitalizing "should not" makes sense. Paul From nobody Mon Jan 6 09:40:48 2020 Return-Path: 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 B4E6B120981; Mon, 6 Jan 2020 09:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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] 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 MZ537X_yKaOm; Mon, 6 Jan 2020 09:40:38 -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 56ACA12091B; Mon, 6 Jan 2020 09:40:38 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ioWMk-0003UI-ER; Mon, 06 Jan 2020 20:40:34 +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 ) id 1ioWMj-0001Eg-RB; Mon, 06 Jan 2020 20:40:34 +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; Mon, 6 Jan 2020 20:40:33 +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; Mon, 6 Jan 2020 20:40:29 +0300 From: Valery Smyslov To: 'Alissa Cooper' , 'The IESG' CC: , 'David Waltermire' , , References: <157833148623.8068.10752260409166984408.idtracker@ietfa.amsl.com> In-Reply-To: <157833148623.8068.10752260409166984408.idtracker@ietfa.amsl.com> Date: Mon, 6 Jan 2020 20:40:29 +0300 Message-ID: <005001d5c4b8$637f2080$2a7d6180$@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: AQIqYLehJT5Fphz9giMcbzvY4uXDqqc0rDNQ 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/06 16:02:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2020/01/06 16:18:00 #14976795 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] Alissa Cooper'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:40:47 -0000 Hi Alissa, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I think this document should formally update RFC 7296. Was that = discussed > in the WG? I don't think it is necessary. This document defines an extension to = IKEv2, which is negotiated by means of exchange of notifications (a "de facto" = standard negotiation=20 mechanism in IKEv2), so it doesn't change anything defined in RFC7296. = An application compliant=20 with RFC7296 will remain compliant after this specification is = (hopefully) be published as RFC. We have a lot of extensions to IKEv2 defined they didn't update RFC7296. > I think the citation for [NISTPQCFP] should link to the actual call = for > proposals. I'll let Panos or Scott comment on it. > Section 6: >=20 > "In addition, the policy SHOULD be set to negotiate only quantum- > resistant symmetric algorithms; while this RFC doesn't claim to = give > advice as to what algorithms are secure (as that may change based = on > future cryptographical results), below is a list of defined IKEv2 = and > IPsec algorithms that should not be used, as they are known to > provide less than 128 bits of post-quantum security" >=20 > This paragraph mixes normative SHOULD with non-normative "should not" > in the > same paragraph. I was wondering if that is intentional. I think that it's OK here (because the first SHOULD is normative, while the second is just an advise of what algorithms are not secure from current cryptographers point of view). Regards, Valery. From nobody Mon Jan 6 10:12:28 2020 Return-Path: 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 A6694120981; Mon, 6 Jan 2020 10:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CNMePOa1; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=03stEZ2J 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 NtolS1dO9Xhm; Mon, 6 Jan 2020 10:12:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F901209D6; Mon, 6 Jan 2020 10:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9641; q=dns/txt; s=iport; t=1578334331; x=1579543931; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e8JDeLz1/gGthxi67MyJ6XsOTY48nEGC7ERcjLwd7c4=; b=CNMePOa1kRrIj0MKXEhxh8Q5gjjYEy+WC1FMHmTpkPlEKawpk1+BJ0bD QmnKK+Dhrc4rAMzqSdd0muS4SpCTg/+lTHotKhXIKGVQt9XSQuJw57TCt MYuZdo/wFp/XPmU5aVsWufSknwQfb8KwzWoDpZWbWUZikaElhsxymbSXa g=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3Ai9dfkxNMYzxEFxn4B18l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjL/fvdyU8FexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYBQBVdxNe/4gNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBVFAFbCstIAQLKodPA4sBgl+YDYJSA1QCBwEBAQkDAQEYDQg?= =?us-ascii?q?CAQGEQAKBaSQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAgEBARALIwEBLAs?= =?us-ascii?q?BBAcEAgEIDgMEAQEvAiULHQgCBAENBQgGFIMBgXlNAw4RDwECDKJOAoE4iGG?= =?us-ascii?q?CJ4J+AQEFgUlBgngYggUHAwaBNoFTikYagUE/gRFHgkw+gmQBAYFlFYMrgiy?= =?us-ascii?q?NKSSJTZgDCoI2g2GCOIEbjwGCRpgVjlOBR4cMjniDDgIEAgQFAg4BAQWBaSK?= =?us-ascii?q?BWHAVO4JsUBgNjRIMFxWDO4F/gxWFP3SBKI0/AQE?= X-IronPort-AV: E=Sophos;i="5.69,403,1571702400"; d="p7s'?scan'208";a="692567858" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 18:12:09 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 006IC9fQ011891 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2020 18:12:09 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 12:12:08 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 12:12:08 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 13:12:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hpIuf/wAz7TW/2Enq9cykeoYdE3enVR6b1yCYXSnxttIXNv6lEf0w34SONQY0I+kdeWiuqikgnbTaMaPIuI/2yfS6qCRp0aL6Xk3M8ibZAr4bGDJ+vn12g/WIO2tjIFEfeFxocOjfW+xrJq9YoV6TPsjz37epMvxmDY6a9ZSBihmvb732J6sF5qN8DzTvP8wSWBXgF8i5ojx0JFmJb6feXtcAcPdbzZqCAp0qboMxkFA8H0cUgLpmbKOCA6gz7rbbCmwONCon05XMMI57/mcFT0y7lRpvM/D/D0TMUCwzMCfzb3wWKvZ9fY0VBppgyef5E0iQPbLbJui1uFDXLFCFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3PNqj/SveowBf5jMCWgOM1f6wTAYd2AYuI7+9hTWyEg=; b=J/qV97ZxQrVae6dUVLq6Ty8qQ2Vljo6tsSNA6Ug+XzV4JQS9tRGYa80WDMz21+SSs0XD1BbulLiE+cAV4HhkCk/vYk6OwDkStsXJ9FdWZwRrLO/ozIpx57bliXAbgpryLyUwLIhVZMWlmcrcZ0j423FLfjvUmXfqB9CXYpSq9J8aSPm/0wdkGoFpVQGZ18+tCavkG9dOynVJ2mHrvHuhTo6i7BmfjLTV30s5J9bNze0eIWxDMMD5S3lFZZxT3//3ypcDARoIxS95+z/gJ6L4ObDhYmfD98IUErlPVmKN8olP2WQXhmLlJyhvDGOxAZKixc1vV227RzZpbteOIhV0OQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3PNqj/SveowBf5jMCWgOM1f6wTAYd2AYuI7+9hTWyEg=; b=03stEZ2Jv8VMwTL5eG2AnSOm1SubjRFyA46fTUAztq1cLHiQ4ZCfI5h65Zi7Mn2zX2hrSByrEm4WhLPhlmUL7VXERG0JnakJOAeTtHFrhB6uhkWz1thDOmO2khLa/qWFIRpE41Eml3+aSLjL/b5oUokIqC0ed/+v9mVtZzFD4Yk= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2721.namprd11.prod.outlook.com (52.135.243.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Mon, 6 Jan 2020 18:12:06 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2602.016; Mon, 6 Jan 2020 18:12:06 +0000 From: "Panos Kampanakis (pkampana)" To: Valery Smyslov , "'Alissa Cooper'" , "'The IESG'" CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "'David Waltermire'" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Thread-Index: AQIqYLehJT5Fphz9giMcbzvY4uXDqqc0rDNQgAAFcZA= Date: Mon, 6 Jan 2020 18:12:06 +0000 Message-ID: References: <157833148623.8068.10752260409166984408.idtracker@ietfa.amsl.com> <005001d5c4b8$637f2080$2a7d6180$@elvis.ru> In-Reply-To: <005001d5c4b8$637f2080$2a7d6180$@elvis.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::1da] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34be8501-dca9-47d6-2e58-08d792d3f08f x-ms-traffictypediagnostic: BN7PR11MB2721: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(136003)(396003)(346002)(13464003)(51444003)(199004)(189003)(110136005)(54906003)(66556008)(66476007)(71200400001)(66616009)(66446008)(64756008)(66946007)(76116006)(966005)(52536014)(5660300002)(86362001)(316002)(186003)(8676002)(7696005)(81166006)(81156014)(2906002)(6506007)(8936002)(478600001)(53546011)(9686003)(4326008)(33656002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2721; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 58E4BkurdC1HMsp6uu6swxpaWuma7+vKF+oILvY1A2mGJVNWWlG5oo5TSs4ck3Myy48+K+DBVoElZ0HwoDH/233mQFHZ3pm++9eIb8F0CALDPFWiJHMXNa/IEifl+UUZMaGEQGyIOUjMtZyv9COnFfjca6JJNcb5FL6H0Kpn84hWjLL3Coutx1ueHRI7HoDctFFBtGu5AJ+vaAfVRHVV0V8zM4Tm0CGkWvlxVIdIwQ1YLxOZdsBLrIkt7zjBM8flAOFm9eH1ZDy9ebzdArKU/9mhPS59AbVmv4s8j/KvIHEYAvLUpty2DBhN2jFUJ0mcEXhfzBXsyQNr1dL8U3Lv5mJFLVNA1TZ37nd86Is/gESju0wCjiOF6A6j7rmseFzZDaASHTMzxQy9HwSgr3dgF5O8ySCXIKRIK6u/vFqidVTySe6ywSnlljQ+zeeD2sRA54dSEhNR8Wi8hWBGZhNaBM/+OIMd/i7tq4CxPY27uQQFoi2gU5dsdohe2961KB9BCqw2Aes2uspwOenuPGnn8+peg1fIX8Hc7yFbJeYZXYNv8qYZ+hz/UL1ObYAFCLMA x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0035_01D5C492.E47F3970" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 34be8501-dca9-47d6-2e58-08d792d3f08f X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 18:12:06.7055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 397NdTSsNL66bMbiwdlKiz9D1W6wMxjChwMIWKzfslyWq6t5qjvZiT62XUBAvSh4Q7NSyheIw6hGZHfs8VfFFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2721 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [IPsec] Alissa Cooper'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 18:12:21 -0000 ------=_NextPart_000_0035_01D5C492.E47F3970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alissa, Just adding a couple more responses: >> I think the citation for [NISTPQCFP] should link to the actual call for proposals. We will add a link to the CFP pointing to https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/document s/call-for-proposals-final-dec-2016.pdf Hopefully the URL will not change as Paul also pointed out. >> future cryptographical results), below is a list of defined IKEv2 and >> IPsec algorithms that should not be used, as they are known to >> provide less than 128 bits of post-quantum security" > I think that it's OK here (because the first SHOULD is normative, while the second is just an advise of what algorithms are not secure from current cryptographers point of view). As authors, we require 256-bit keys (assuming Grover halves key search time which makes it 128-bits of PQ security). Now, NIST has in their FAQs that they consider 128-bits AES (64-bit PQ security level) good enough for a long time because Grover cannot be parallelized. Even though we see the rationale behind this, we feel that using 256-bit keys for this draft (128-bit PQ security) is trivial and without extra cost so that is what implementers should use. But we did not make this a normative "SHOULD" just to avoid conflicting with NIST. We wanted to stay loyal to what we say in the Sec Considerations section "while this RFC doesn't claim to give advice as to what algorithms are secure [...]". Let us know if there are objections. Panos -----Original Message----- From: IPsec On Behalf Of Valery Smyslov Sent: Monday, January 06, 2020 12:40 PM To: 'Alissa Cooper' ; 'The IESG' Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; 'David Waltermire' ; draft-ietf-ipsecme-qr-ikev2@ietf.org Subject: Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Hi Alissa, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I think this document should formally update RFC 7296. Was that > discussed in the WG? I don't think it is necessary. This document defines an extension to IKEv2, which is negotiated by means of exchange of notifications (a "de facto" standard negotiation mechanism in IKEv2), so it doesn't change anything defined in RFC7296. An application compliant with RFC7296 will remain compliant after this specification is (hopefully) be published as RFC. We have a lot of extensions to IKEv2 defined they didn't update RFC7296. > I think the citation for [NISTPQCFP] should link to the actual call > for proposals. I'll let Panos or Scott comment on it. > Section 6: > > "In addition, the policy SHOULD be set to negotiate only quantum- > resistant symmetric algorithms; while this RFC doesn't claim to give > advice as to what algorithms are secure (as that may change based on > future cryptographical results), below is a list of defined IKEv2 and > IPsec algorithms that should not be used, as they are known to > provide less than 128 bits of post-quantum security" > > This paragraph mixes normative SHOULD with non-normative "should not" > in the > same paragraph. I was wondering if that is intentional. I think that it's OK here (because the first SHOULD is normative, while the second is just an advise of what algorithms are not secure from current cryptographers point of view). Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0035_01D5C492.E47F3970 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA2MTgxMjA1WjAvBgkqhkiG9w0BCQQxIgQgPEvgheGJEylCTDBPArLEUGpVMkzmSeVm JJ/W5t8eJ3IwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA aeSHz2zKkrc63iNh7MoHALxMGIosPwUaAx+1DWM10aMsh/idXE4HQrcFAZ0FMzKBDAa4Mb48rejp HWgee4Xt/r8CVv9KLpLdHC28N07iR131XRe+0LC8TgkEvDauta7xGSf3umGg0nthBKcF0l0yVDcv Bm7tdp8rvSjtxyAjHNaaZqfRBRprC9iskFq7MA7ZMc3ALbykeZ9P/NM1VnzwgSuxRVde9mqSSFWN KcGixbs7y7sRwxONZXWA87VpTaXCQDKnDlEEd0N576p1OfIP+wTCkypl8HnTlXcdO3Nc1aTyOgB2 Zr0v+ci77UZQEo8M+B+uTOiV1f/sKwaowdAhwwAAAAAAAA== ------=_NextPart_000_0035_01D5C492.E47F3970-- From nobody Tue Jan 7 05:41:19 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 786611200E9; Tue, 7 Jan 2020 05:41:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 05:41:13 -0800 Archived-At: Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:41:14 -0000 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...? From nobody Tue Jan 7 10:16:11 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE1E120131; Tue, 7 Jan 2020 10:16:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <157842096510.21009.1290558752728035892.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 10:16:05 -0800 Archived-At: Subject: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 18:16:05 -0000 Alexey Melnikov 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: ---------------------------------------------------------------------- Thank you for this document. One small suggestion below: 5.1. PPK_ID format o PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the PPK are fixed octet strings; the remaining bytes of the PPK_ID are a configured value. We assume that there is a fixed mapping between PPK_ID and PPK, which is configured locally to both the initiator and the responder. The responder can use the PPK_ID to look up the corresponding PPK value. Not all implementations are able to configure arbitrary octet strings; to improve the potential interoperability, it is recommended that, in the PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 characters 0-9, A-Z, a-z, + and /. In order to avoid any doubt, I suggest you make it clear that you mean ASCII encoding here. For this you should add a normative reference to RFC 20 in the last quoted sentence. From nobody Tue Jan 7 20:12:12 2020 Return-Path: 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 1C25D1200D7; Tue, 7 Jan 2020 20:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JtKNjuVQ; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=rMQivlIz 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 Af-q627Bc83l; Tue, 7 Jan 2020 20:12:03 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3754120043; Tue, 7 Jan 2020 20:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8356; q=dns/txt; s=iport; t=1578456723; x=1579666323; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UaaNDdek+OEK6eJiD5+Ifn4XpPJUxzriiktnvxhCriY=; b=JtKNjuVQnr2yQf+7G3KH/Tfx+a0g9NICuZLrlVt/PqZuNAY3miUPj6m9 2zc6R7D3/uY8v6wAulKTKqvnUv/JjOKg/qXsZpKb8OwqGZh4xqGu/V13r jClHOwJsZmZI8ORqQk1V+zXt14LODPVFoOPq09Ok6pB0cqMc/tCyOBSvr g=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3Ae+UTjBzvqFkiQI3XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4BQB1VRVe/49dJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBVFAFbCstIAQLKodPA4sGgl+YDYFCgRADVAIHAQEBCQMBARg?= =?us-ascii?q?LCgIBAYRAAoFpJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDAQEQLgEBLAs?= =?us-ascii?q?BCwQCAQgOAwQBAR4RAiULHQgCBAENBQgGFIMBgXlNAx8PAQIMoHsCgTiIYYI?= =?us-ascii?q?ngn4BAQWBSUGDChiCBQcDBoE2gVOKRhqBQT+BEUeCTD6CZAEBAQIBgSwBCwc?= =?us-ascii?q?BIYNAgiyNLCSJTZgHCoI2g2GCOIEdhTuJSIJHh36EQ4tYjlOIVJIPAgQCBAU?= =?us-ascii?q?CDgEBBYFpImdYEQhwFTuCbFAYDY0SCRoVgzuFFIU/dAGBJ40REReCGwEB?= X-IronPort-AV: E=Sophos;i="5.69,408,1571702400"; d="p7s'?scan'208";a="409726116" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 04:12:01 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0084C1YG030046 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2020 04:12:01 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 22:12:00 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 22:12:00 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 7 Jan 2020 22:12:00 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SpiJaMVXihk7xl5gSjYcIO+c9LCvpbzBqnFeelfekq2+FBezBNd9iVqd/HkOux6sUvzovIKVIw7I9InkfwQwKwDHnIXLMRoajin4BvPEE5Sce7gKQmPWy84Sm0QeZLH8Vny4gYWtUQIplh6O1z/OwPU9LfTP7UzZWIiEGXSnWT4Kl/zUY6JtiHnLK4wFEW+27R8BRG3M4I+2qjDkAHw66YkKbckXQ3sLuMdxZocRopaW82coGpxsC6AddNSOWkjd0HS0LzBkeAecA2S7hgYucpb7F3vbrYlbTgHjqHJ84/BusAYoyiD15g2MjISSpRUhSvpemOrOuSVSBNcYUiJ6Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yMV8p34bDm3D9bSoVw2iVpyWOZrB7I6ucKHoiEV4IPo=; b=FH3wXpP/gA0h4IquNf5Cd5prIEKUU+VYasg0DRqIR7ynOTP0ZozRXJfp6m4mwRLFsNTTzjsSAceue6xunRfOmDPzqplO1pZfYWyxQP2UNUbEmCVgGRKqKSESknOsIK2tFU/P8Rp8kHT+OWvwZCmiQgZ5fbhCYZSQSqoOC57NQy6sjppdziAxOGqm/bQjakrvwk8Z8wYa0ADEJdt90arAwaWS7TNXoubN1Z2oJaTi0QtC5nWfkH/Qjl3dPugxKACwdqrxElV39Z0LH3y7busyx7ekyJ8j7O6sBFNC+ieABNFjUYQFqH6vkPR1nQWCSXhM02dIo86EFwkO2kYQLCo9zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yMV8p34bDm3D9bSoVw2iVpyWOZrB7I6ucKHoiEV4IPo=; b=rMQivlIzbQ5DO7AYxcaXrp5L+Ih6tJwTLYrbo/JR4lX/si3l+Owko3NH2nzJ3/C15yprdxW/hho5gsUtDbCSmCjDa7L7lcFwfwq/z0AKLvmNMHH7dm8lQ2s77MBBtUXqXGVfxcBLMfDHXTUci+AGKlpgIKFv/7ilezJQSnYy4z4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2737.namprd11.prod.outlook.com (52.135.244.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Wed, 8 Jan 2020 04:11:59 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2602.016; Wed, 8 Jan 2020 04:11:59 +0000 From: "Panos Kampanakis (pkampana)" To: Alexey Melnikov , The IESG CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Thread-Index: AQHVxYaZxN6VmHmO7EGzwA9rNUh1+6fgKBsw Date: Wed, 8 Jan 2020 04:11:57 +0000 Message-ID: References: <157842096510.21009.1290558752728035892.idtracker@ietfa.amsl.com> In-Reply-To: <157842096510.21009.1290558752728035892.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::17b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35884652-1033-4cd8-819e-08d793f0e860 x-ms-traffictypediagnostic: BN7PR11MB2737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(396003)(376002)(39860400002)(199004)(189003)(13464003)(966005)(8936002)(86362001)(9686003)(8676002)(55016002)(4326008)(2906002)(186003)(33656002)(6506007)(53546011)(81156014)(66476007)(81166006)(5660300002)(7696005)(71200400001)(52536014)(478600001)(54906003)(66616009)(76116006)(316002)(110136005)(64756008)(66446008)(66946007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2737; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FjOwHFfXyqBib1mKOgxWniiv3MqOZ/mlteQXrIMGZVaONOpIOBWH0O5zMAn32zVpP+8w0mzslTL/W8UFJsfVlmahqKFmNmWbdrw1d8dPaDbXOuBYj1ir9v5Kl4yXK84GV/y8FkJdnNWgXYeFP2Ca12c5MWUg159Y5MPCMEa+lCqzl9ubT+8XZ6wr/ijK0hRb2NVF3wiEvmAqA6L/W4mOsimCrIYssCqL23ryt8NZ/GY4ynnVStn40UhsUtsxa7ddGUAIRwnvqqdfx8SZGxs77qCsmHC2/1T63H87c/+YtpNgDm6NhShdNBDIYSOnv4Qc8X0EBOP8ahYzbu6mJ+0/Wesrvq2y3VwqQ7UutRwpmxJN/X6ErmKYK9WpNjahf/d1Prm0a0m7i+KF3o64sFBzne7FNexUObE23HBc0zvGwGVxqAZELusJdQrggDfZ724TkXxNB1hSU5HyA1a0RXkGdV9pdEGOWEWs4+0e/+df3R2X4PhEgFezDJCWf2HH9GzpcoLW92PjU8bp3RWMo+orFCksnSmksb8jRQmG+8m78qHqPgdc/IespDaAiiYz7Zo/ x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0005_01D5C5AF.DB09AA10" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 35884652-1033-4cd8-819e-08d793f0e860 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 04:11:59.5357 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PL+ACSmr03JELIXXir89p3I9O7WfTcFTIWNJSjt9E7X6zpvtCmHwUd/A9C7UvR7tLkOtJg3jw9Pq8n6AmqeFDA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2737 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [IPsec] Alexey Melnikov'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 04:12:06 -0000 ------=_NextPart_000_0005_01D5C5AF.DB09AA10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Alexey. The text will now read [...] both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 ASCII [RFC0020] characters 0-9, A-Z, a-z, + and /. -----Original Message----- From: IPsec On Behalf Of Alexey Melnikov via Datatracker Sent: Tuesday, January 07, 2020 1:16 PM To: The IESG Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; david.waltermire@nist.gov; draft-ietf-ipsecme-qr-ikev2@ietf.org Subject: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Alexey Melnikov 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: ---------------------------------------------------------------------- Thank you for this document. One small suggestion below: 5.1. PPK_ID format o PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the PPK are fixed octet strings; the remaining bytes of the PPK_ID are a configured value. We assume that there is a fixed mapping between PPK_ID and PPK, which is configured locally to both the initiator and the responder. The responder can use the PPK_ID to look up the corresponding PPK value. Not all implementations are able to configure arbitrary octet strings; to improve the potential interoperability, it is recommended that, in the PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 characters 0-9, A-Z, a-z, + and /. In order to avoid any doubt, I suggest you make it clear that you mean ASCII encoding here. For this you should add a normative reference to RFC 20 in the last quoted sentence. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0005_01D5C5AF.DB09AA10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA4MDQxMTU2WjAvBgkqhkiG9w0BCQQxIgQgsQLj2cpL7QxGRNVnjNFIoYa2RU2swWAk 19NVxWxmA9MwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA jKWQIVyWOG3Vz5s3G54JffWuaEgBLgahi9hZwe5Ybe0YWI79S7Le9CnCU5mGvDS5QX3Q6Kv1wnFj UtZiCQrnFwm8a8TH4RVKRg+BOSHMcTih4gzTDTS+1MGESjAMspey4COSesBZWervKRMFUsUuLsUS b5Nr73pXzyyhHRm6HUY8Tpl72lkA6Qf8Hr5NoAtMwRl8m0+iQ8ZBjZo41e5zvxTFxIds2uLMEvXB ggZK38tNLnCyg8PtPD74+QP15d0R/n9Y1gPAG7lA7Z2sKo17xA1PdCSiAeRD3w2oJmIpTgqYKbe4 i19p4qTDeGbmym13lPGAuq/sQ1Sun0M7owmYlwAAAAAAAA== ------=_NextPart_000_0005_01D5C5AF.DB09AA10-- From nobody Tue Jan 7 20:55:19 2020 Return-Path: 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 F1B89120041; Tue, 7 Jan 2020 20:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jjlVOslR; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=QcE6zwUC 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 WwwWtk4EwVma; Tue, 7 Jan 2020 20:55:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39559120025; Tue, 7 Jan 2020 20:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10627; q=dns/txt; s=iport; t=1578459315; x=1579668915; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zrV8F8FGa2lkd5PG1HkADd3bscdsg0SFdZwTpl/AvE0=; b=jjlVOslRfFwfxDVONv0VkfO7puW4DBjLkesobGMWjWO4HjCPJ8+OI0uy Jcfdhcaz8i2PJt7SwAVeZxVI6zr53Jgti5edyuhroNrtvtMgK7GLxQ4oW tELbCKbL0A3yQ78EQpKl3Wba7YUlNoCSd5PpY7Q2oNe9lqWfwKTlktV3X c=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AEB1IDR/mtd0A6/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaGAEjjJfjjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOCAA7YBVe/4MNJK1mHQEBAQkBEQU?= =?us-ascii?q?FAYF8gVQkBScFbCstIAQLKoQJg0YDiwaCX5gNgUKBEANUAgcBAQEJAwEBGAs?= =?us-ascii?q?KAgEBhEACgWkkOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQMBARARHQEBLAs?= =?us-ascii?q?BCwQCAQgRBAEBHg0CAgIlCxoDCAIEAQ0FCAYUgwGBeU0DHw8BAgygdQKBOIh?= =?us-ascii?q?hdYEygn4BAQWBSUGDChiCBQcDBoE2gVOKRhqBQT+BEUeCTD6CZAEBAQIBgSM?= =?us-ascii?q?JARIBCRgwgl4ygiyNPgYMJoJLiBmWSgqCNoNhgjiBHYU7iUiCR4d+kBuDR4s?= =?us-ascii?q?MiFSSDwIEAgQFAg4BAQWBaSJnWBEIcBU7gmxQGA2NEjhvAQKCSYUUhT90AYE?= =?us-ascii?q?njSKBU18BAQ?= X-IronPort-AV: E=Sophos;i="5.69,408,1571702400"; d="p7s'?scan'208";a="698436346" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 04:55:08 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0084t5pp017310 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2020 04:55:08 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 22:55:04 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 23:55:03 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 7 Jan 2020 22:55:03 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KEx4FabJJmivB4Yx1TxJUmRaC5M344rnYbyi1z8MGtgL75piKT+/uBkaMPYYdmKLvFfKDVcD7Zta3jUTxY4NUdN4Nf0spSBN/ltUnyOGrAkxHBWeLVFV6Xv3ye7drBto16JrE1q6+m9hzCcqcNvubHuf9sU1C94GcNXg/PtZWvij7z9U/xDpzIK0FcTyRTPRbANMkOmT2MUl97eHPzsCjwtDNBrqwdU4381gqKV6HfdGoz9ej+YFrhsmaurVCY/2UsVXfSkvKIQRK+W55ZpoSFjdYAEwPQbVogfj+hzFRa5VJ+J+MVFjE1f48leYFOwNV9m1xt6iPVC1odOReF9pbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hQ05iyFb6l6/kuYTkJNHKk1o59THnS1uo64i7orXVDM=; b=PTaYLeOWsNSjqpHR9vQr+rGeZKDnEN/h+w7iicjBwTXDIx/YsVHI5wWjOQrEuZgUsmGF8uOKxmOPx8WgT4H1c+IqWC1tTxcpAY12XuELZH2Fy9vf4LRaD54EhjQM7JJBi8U42wshZTfWTRtWH+pqoqLVXcoTOrRYFuWIXBOngLi/ZV3qwftjW/G5bD1ckzZg+sEUBcR/bgzvqfqw8TeoYRgHA9Pw/SxLdZyKnjBGzVRMiWPShMT0PsGtBWY5hsuw8IxKw1mdQ1axiXtevu2Ku9l7VhT4d6qwLSYUCQ4CdbhHMgL3CTo8yetosU1fSOMiE1GTwsaJyAbOarQrcgWmJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hQ05iyFb6l6/kuYTkJNHKk1o59THnS1uo64i7orXVDM=; b=QcE6zwUCoS0ImW5/bjl4o5Go8jpY1MgHHv5YNuIcSOMfuy0IFbJbBqI/MdzGCZVLijFOjDtoAfnlYAFuVt81lbKzIARQMm4mlSXlWlVMr+Vgy1xTvsesSjNE+28bL28EcQITPZRb8J9LU+yz8NjiwmJsHltWYCnq8bV+R9A5Z2o= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2676.namprd11.prod.outlook.com (52.135.254.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Wed, 8 Jan 2020 04:55:02 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2602.016; Wed, 8 Jan 2020 04:55:02 +0000 From: "Panos Kampanakis (pkampana)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: =?utf-8?B?W0lQc2VjXSBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9uIGRy?= =?utf-8?Q?aft-ietf-ipsecme-qr-ikev2-10:_(with_COMMENT)?= Thread-Index: AQHVxWBDRUXe2IfoW0+06Wm2vRLZBqfgKRyg Date: Wed, 8 Jan 2020 04:55:02 +0000 Message-ID: References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> In-Reply-To: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::17b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c8de91d0-9ef8-451a-4859-08d793f6ec1b x-ms-traffictypediagnostic: BN7PR11MB2676: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(39860400002)(136003)(366004)(13464003)(199004)(189003)(33656002)(6506007)(71200400001)(7696005)(66446008)(66946007)(64756008)(66616009)(66476007)(224303003)(66556008)(76116006)(186003)(66574012)(52536014)(53546011)(86362001)(81156014)(81166006)(8936002)(4326008)(54906003)(966005)(5660300002)(478600001)(9686003)(2906002)(110136005)(55016002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2676; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z225Dnqa1PFqyj6uSCFtLG5WJDc4MSFxuSObUBWHnl7/mpj0VTwmnnj44lAs0HQ+6Vfsnd7QL/1KkCeFUCRrofvhP8mQYEBsJnAQL+mtLE/A0thMUTsJvVadysGxFlanXHK99gRFqjdwwvqA/7ppxSZVcE3dnPu7+9dP3amMIVz3UdUaTu7fgZE7QCENyyqCqZOv0/NleGBKd+idp/JYr3Q8Z/1UKYyykHPgMxbBPo/Dt8c8hdI4z272z6Bq3UdeF0BMw1pASLSPFr/qwTsyzit1O8qBWolHt7w4DANz0zJ8Vc5aL5VG603XL5jyvREaq/PpPmcICHTDXocQXaVQc68nzT4oPtsTB07HUFbgFQf4KEGdlXdItb/J8XMj1luyVM3gNjtkoVdde7I3OjKLRO8+b4hsQUeOFrc6fLDPvQRhIJFNXHwCyybTI3QJz1LBhaf0X/xbmCeUTcNpWxp1ug+E2+Yz+1bCGzymCA3s74C/54D2//+ww7SDzRnb+tdC3nGt2aMUDHXqS8ObCdnEA4PV+Xe43hJIU3ErIhsfm/olMgPX2RfbxiGlez44QQz8 x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0012_01D5C5B5.DF412A80" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c8de91d0-9ef8-451a-4859-08d793f6ec1b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 04:55:02.5115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZTAJLtSDOlGf6F4Cl0L3cZ9T6aOiD3yT5Dyfswe0UF4Ezp57RAta/hoEvbHBwtt/hhaHjfsRFCCI043r4zteYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2676 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 04:55:18 -0000 ------=_NextPart_000_0012_01D5C5B5.DF412A80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, To try to answer your questions 1) You are right. This is mentioned in a paragraph below that reads=20 [...] 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=20 only if using PPKs for communication with this responder is optional for the initiator (based on the mandatory_or_not flag),=20 then the initiator MAY include a notification NO_PPK_AUTH in the=20 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.=20 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.=20 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.=20 Rgs, Panos -----Original Message----- From: IPsec On Behalf Of Mirja K=C3=BChlewind = via Datatracker Sent: Tuesday, January 07, 2020 8:41 AM To: The IESG Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; david.waltermire@nist.gov; = draft-ietf-ipsecme-qr-ikev2@ietf.org Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Mirja K=C3=BChlewind 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 ------=_NextPart_000_0012_01D5C5B5.DF412A80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA4MDQ1NTAwWjAvBgkqhkiG9w0BCQQxIgQgbGKlkfiU4HnKBAD6GcGJylRxmhrJOO8u EcL/D8fQ1AYwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA D2OuXBt6a3GkR5CVesiQZFdHkLPx9JZiLWHOBPVE1SaMIqGVcTZerj1+gvqepQDeXeDTbmIgjCdE XYkDQBIM1dpTnjTGZEk78iCxvPfaVtYZEWYtlJKv5CxgmtZPjLpYokzHvFId7op7oydLQcYcFqUe kxFhb+D04Lz6CQBrJFZAnrg8/NvKvt8Vlhn3IDt2dOTmQy9ZT8QNvGAUFwmrwYcP1plq44HzA3u0 Cu0JKevosVVSh5IZvlXPaN8QQ7nvIkhDhEBiKXaLDvTBOZ8yXg6kCWKyGbSR5SR+s7s/TiOGl2ZM 7RrGZ2XvapOUM6vBZRRp0UXzGf5fLOd2PVrEUwAAAAAAAA== ------=_NextPart_000_0012_01D5C5B5.DF412A80-- From nobody Tue Jan 7 21:46:52 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21872120025; Tue, 7 Jan 2020 21:46:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <157846240313.20876.14052335668083715754.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 21:46:43 -0800 Archived-At: Subject: [IPsec] Barry Leiba's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 05:46:43 -0000 Barry Leiba 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: ---------------------------------------------------------------------- Yes, an interesting document, and thanks for that. A few editorial comments: — Section 1 — to be quantum resistant, that is, invulnerable to an attacker with a quantum computer. “Invulnerable” isn’t the same as “not vulnerable”: it has a stronger connotation. You should probably use “not vulnerable” or “resistant” instead. By bringing post- quantum security to IKEv2, this note removes the need to use Make it “this document”, please. This document does not replace the authentication checks that the protocol does; instead, it is done as a parallel check. What’s the antecedent to “it”? Should “it is” instead be “they are”? — Section 3 — when the initiator believes it has a mandatory to use PPK You need hyphens in “mandatory-to-use”. — I also find it interesting that Alexey thought you needed to add a normative reference for “ASCII”, bit not for “base64”. Personally, I think both are sufficiently well known that you need neither. From nobody Wed Jan 8 01:27:24 2020 Return-Path: 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 C7E4712002F; Wed, 8 Jan 2020 01:27:22 -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 Hbmg4n-oNNrJ; Wed, 8 Jan 2020 01:27:19 -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 69169120024; Wed, 8 Jan 2020 01:27:18 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ip7cQ-0003lp-N9; Wed, 08 Jan 2020 12:27:15 +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 ) id 1ip7cL-0007qT-Vi; Wed, 08 Jan 2020 12:27:14 +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 12:27:09 +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 12:27:06 +0300 From: Valery Smyslov To: "'Panos Kampanakis (pkampana)'" , =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , 'The IESG' CC: , , , References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 8 Jan 2020 12:27:04 +0300 Message-ID: <00bc01d5c605$ca5916f0$5f0b44d0$@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/ZhtxErcpkYXQMbldDrqEFcWkA= 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 08:44: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: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 09:27:23 -0000 Hi Panos, Mirja, > Hi Mirja, >=20 > To try to answer your questions >=20 > 1) You are right. This is mentioned in a paragraph below that reads >=20 > [...] 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). >=20 > But for clarity we will slightly rephrase the sentence you pointed out = to >=20 > 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=20 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. >=20 > 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 >=20 > -----Original Message----- > From: IPsec On Behalf Of Mirja K=C3=BChlewind = via > Datatracker > Sent: Tuesday, January 07, 2020 8:41 AM > To: The IESG > Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; = david.waltermire@nist.gov; > draft-ietf-ipsecme-qr-ikev2@ietf.org > Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf-ipsecme-qr- > ikev2-10: (with COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 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! >=20 > 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? >=20 > 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? >=20 > 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...? >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jan 8 01:41:56 2020 Return-Path: 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 899EA12002F; Wed, 8 Jan 2020 01:41:54 -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 prY0vj_zGjZS; Wed, 8 Jan 2020 01:41:51 -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 639EC120024; Wed, 8 Jan 2020 01:41:51 -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 1ip7qU-0002zt-1N; Wed, 08 Jan 2020 10:41:46 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <00bc01d5c605$ca5916f0$5f0b44d0$@elvis.ru> Date: Wed, 8 Jan 2020 10:41:45 +0100 Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-qr-ikev2@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net> References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> <00bc01d5c605$ca5916f0$5f0b44d0$@elvis.ru> To: Valery Smyslov , "Panos Kampanakis (pkampana)" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578476511;dc69d880; X-HE-SMSGID: 1ip7qU-0002zt-1N Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 09:41:54 -0000 Hi Panos, hi Valery, Please see below. > On 8. Jan 2020, at 10:27, Valery Smyslov wrote: >=20 > Hi Panos, Mirja, >=20 >> Hi Mirja, >>=20 >> To try to answer your questions >>=20 >> 1) You are right. This is mentioned in a paragraph below that reads >>=20 >> [...] 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). >>=20 >> But for clarity we will slightly rephrase the sentence you pointed = out to >>=20 >> 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. >=20 > 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: >=20 > 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. >=20 >> 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. >=20 > 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. Since you both disagree by an order of magnitude, it seems to me that = some more advise would actually be helpful. It=E2=80=99s fully = understood that there is no one value that fits all but providing = further advise what this value depends on and what could be a good range = in most cases could be helpful. I would actually think that given the = misconfiguration is on the other end and the person implementing this = value has no idea about what the misconfiguration would be, it=E2=80=99s = anyway guessing, so why not guess now and give some advise. >=20 >> 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. >=20 > 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=20 > 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. >=20 >> 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. >>=20 >> 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. >=20 > 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. 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=E2=80=A6 Mirja >=20 > Regards, > Valery. >=20 >> Rgs, >> Panos >>=20 >> -----Original Message----- >> From: IPsec On Behalf Of Mirja K=C3=BChlewind = via >> Datatracker >> Sent: Tuesday, January 07, 2020 8:41 AM >> To: The IESG >> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; = david.waltermire@nist.gov; >> draft-ietf-ipsecme-qr-ikev2@ietf.org >> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf-ipsecme-qr- >> ikev2-10: (with COMMENT) >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-ipsecme-qr-ikev2-10: No Objection >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> 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! >>=20 >> 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? >>=20 >> 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? >>=20 >> 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...? >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 From nobody Wed Jan 8 01:42:22 2020 Return-Path: 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 ECF8E120860; Wed, 8 Jan 2020 01:42:14 -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 fZQar6rTubAK; Wed, 8 Jan 2020 01:42:12 -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 BBCD5120842; Wed, 8 Jan 2020 01:42:12 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ip7qr-0003uF-Lt; Wed, 08 Jan 2020 12:42:09 +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 ) id 1ip7qr-0007wf-9a; Wed, 08 Jan 2020 12:42:09 +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 12:42:05 +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 12:42:02 +0300 From: Valery Smyslov To: 'Barry Leiba' , 'The IESG' CC: , 'David Waltermire' , , References: <157846240313.20876.14052335668083715754.idtracker@ietfa.amsl.com> In-Reply-To: <157846240313.20876.14052335668083715754.idtracker@ietfa.amsl.com> Date: Wed, 8 Jan 2020 12:41:59 +0300 Message-ID: <00bd01d5c607$dfe2ef80$9fa8ce80$@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: AQIAZoldgL89aeTgmU6lphWRb8BCVaeLJ8HQ 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 08:44: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: Subject: Re: [IPsec] Barry Leiba'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 09:42:17 -0000 Hi Barry, > Barry Leiba has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Yes, an interesting document, and thanks for that. A few editorial > comments: >=20 > =E2=80=94 Section 1 =E2=80=94 >=20 > to be quantum resistant, that is, invulnerable to an attacker with = a > quantum computer. >=20 > =E2=80=9CInvulnerable=E2=80=9D isn=E2=80=99t the same as =E2=80=9Cnot = vulnerable=E2=80=9D: it has a stronger > connotation. You should probably use =E2=80=9Cnot vulnerable=E2=80=9D = or =E2=80=9Cresistant=E2=80=9D > instead. OK, thanks. > By bringing post- > quantum security to IKEv2, this note removes the need to use >=20 > Make it =E2=80=9Cthis document=E2=80=9D, please. OK. > This document does not replace the > authentication checks that the protocol does; instead, it is done = as > a parallel check. >=20 > What=E2=80=99s the antecedent to =E2=80=9Cit=E2=80=9D? Should = =E2=80=9Cit is=E2=80=9D instead be =E2=80=9Cthey are=E2=80=9D? I think it was meant that using PPK doesn't directly influence peer = authentication=20 in IKEv2, but I agree that the wording is not clear enough. It's probably better to rephrase it: This document does not replace the authentication checks that the protocol does; instead, they are=20 strengthened by using an additional secret key. Is it better? > =E2=80=94 Section 3 =E2=80=94 >=20 > when the initiator believes it has a mandatory to use PPK >=20 > You need hyphens in =E2=80=9Cmandatory-to-use=E2=80=9D. OK. THank you, Valery. >=20 > =E2=80=94 >=20 > I also find it interesting that Alexey thought you needed to add a = normative > reference for =E2=80=9CASCII=E2=80=9D, bit not for = =E2=80=9Cbase64=E2=80=9D. Personally, I think both are > sufficiently well known that you need neither. >=20 From nobody Wed Jan 8 03:55:46 2020 Return-Path: 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 05B7D12001E; Wed, 8 Jan 2020 03:55:39 -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 hs99Y0jKD-NI; Wed, 8 Jan 2020 03:55:35 -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 508ED120019; Wed, 8 Jan 2020 03:55:35 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ip9vw-00061g-2m; Wed, 08 Jan 2020 14:55:32 +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 ) id 1ip9vv-0000QR-El; Wed, 08 Jan 2020 14:55:32 +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 14:55:30 +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 14:55:28 +0300 From: Valery Smyslov To: 'Mirja Kuehlewind' , "'Panos Kampanakis (pkampana)'" CC: 'The IESG' , , , , References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> <00bc01d5c605$ca5916f0$5f0b44d0$@elvis.ru> <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net> In-Reply-To: <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net> Date: Wed, 8 Jan 2020 14:55:26 +0300 Message-ID: <00c801d5c61a$83eb6870$8bc23950$@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/ZhtxErcpkYXQMbldDrAeYv7v4CDBb0i6gh6q2A 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 11:05: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: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 11:55:39 -0000 Hi Mirja, > Hi Panos, hi Valery, >=20 > Please see below. >=20 > > On 8. Jan 2020, at 10:27, Valery Smyslov 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. >=20 > 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. How about the following text? 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 indicates this optionality to the responder by = including a notification=20 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. >=20 > Since you both disagree by an order of magnitude, it seems to me that > some more advise would actually be helpful. It=E2=80=99s fully = understood that there > is no one value that fits all but providing further advise what this = value > depends on and what could be a good range in most cases could be = helpful. > I would actually think that given the misconfiguration is on the other = end > and the person implementing this value has no idea about what the > misconfiguration would be, it=E2=80=99s anyway guessing, so why not = guess now and > give some advise. How about: In this situation, it is RECOMMENDED that the initiator caches the negative result of the negotiation 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=20 the responder to treat it as DoS attack. Note, that this situation=20 is most likely a result of misconfiguration and some re- configuration of the peers would probably be needed. =20 > >> 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. >=20 > 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=20 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. >=20 > Having some downgrade detection would enable to log an attack if = optional > PPK was used.=20 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=20 are build. Besides, prerequisites for this attack are that an attacker=20 be able to modify IKE messages (i.e. be on the path) and peers use = signatures for authentication.=20 > 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=E2=80=A6 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 >=20 >=20 >=20 > > > > Regards, > > Valery. > > > >> Rgs, > >> Panos > >> > >> -----Original Message----- > >> From: IPsec On Behalf Of Mirja = K=C3=BChlewind via > >> Datatracker > >> Sent: Tuesday, January 07, 2020 8:41 AM > >> To: The IESG > >> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; = david.waltermire@nist.gov; > >> draft-ietf-ipsecme-qr-ikev2@ietf.org > >> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf-ipsecme-qr- > >> ikev2-10: (with COMMENT) > >> > >> Mirja K=C3=BChlewind 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 > > > > From nobody Wed Jan 8 04:10:40 2020 Return-Path: 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 8896A120073; Wed, 8 Jan 2020 04:10:34 -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 8a9oscPzB0N0; Wed, 8 Jan 2020 04:10:32 -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 999CA120019; Wed, 8 Jan 2020 04:10:31 -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 1ipAAN-0005CT-OW; Wed, 08 Jan 2020 13:10:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <00c801d5c61a$83eb6870$8bc23950$@elvis.ru> Date: Wed, 8 Jan 2020 13:10:26 +0100 Cc: "Panos Kampanakis (pkampana)" , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, The IESG , david.waltermire@nist.gov Content-Transfer-Encoding: quoted-printable Message-Id: <840A17D3-61C5-4C22-B5E0-E8A89AF0AB31@kuehlewind.net> References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> <00bc01d5c605$ca5916f0$5f0b44d0$@elvis.ru> <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net> <00c801d5c61a$83eb6870$8bc23950$@elvis.ru> To: Valery Smyslov X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578485431;a0ef6406; X-HE-SMSGID: 1ipAAN-0005CT-OW Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 12:10:35 -0000 Hi Valery, Please see inline. > On 8. Jan 2020, at 12:55, Valery Smyslov wrote: >=20 > Hi Mirja, >=20 >> Hi Panos, hi Valery, >>=20 >> Please see below. >>=20 >>> On 8. Jan 2020, at 10:27, Valery Smyslov wrote: >>>=20 >>> Hi Panos, Mirja, >>>=20 >>>> Hi Mirja, >>>>=20 >>>> To try to answer your questions >>>>=20 >>>> 1) You are right. This is mentioned in a paragraph below that reads >>>>=20 >>>> [...] 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). >>>>=20 >>>> But for clarity we will slightly rephrase the sentence you pointed = out to >>>>=20 >>>> 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. >>>=20 >>> 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: >>>=20 >>> 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. >>=20 >> 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. >=20 > 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=20 > 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=E2=80=99s = 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 =E2=80=9Cthe initiation indicates=E2=80=9D = is confusing here and it should actually say =E2=80=9Cthe initiator = includes a NO_PPK_AUTH notification to indicate this optionality to the = responder=E2=80=9C=E2=80=A6? > How about the following text? >=20 > 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 indicates this optionality to the responder by = including a notification=20 > NO_PPK_AUTH in the above message. >=20 >>>> 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. >>>=20 >>> 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. >>=20 >> Since you both disagree by an order of magnitude, it seems to me that >> some more advise would actually be helpful. It=E2=80=99s fully = understood that there >> is no one value that fits all but providing further advise what this = value >> depends on and what could be a good range in most cases could be = helpful. >> I would actually think that given the misconfiguration is on the = other end >> and the person implementing this value has no idea about what the >> misconfiguration would be, it=E2=80=99s anyway guessing, so why not = guess now and >> give some advise. >=20 > How about: >=20 > In this situation, it is RECOMMENDED > that the initiator caches the negative result of the negotiation > 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=20 > the responder to treat it as DoS attack. Note, that this situation=20= > is most likely a result of misconfiguration and some re- > configuration of the peers would probably be needed. Sounds good to me. Thanks! >=20 >>>> 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. >>>=20 >>> 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. >>=20 >> Kind of same here. Given you two disagree here already, I think it = would be >> good to give further advise. >=20 > I'm reluctant to provide concrete figures, because RFC7296 = deliberately=20 > 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: >=20 > 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=E2=80=99t have an open connection = and therefore you need an timeout. I would recommend to at least say = something like:=20 "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).=E2=80=9D (Please use your own wording=E2=80=A6) >=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> Having some downgrade detection would enable to log an attack if = optional >> PPK was used.=20 >=20 > 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=20= > are build. Besides, prerequisites for this attack are that an attacker=20= > be able to modify IKE messages (i.e. be on the path) and peers use = signatures for authentication.=20 >=20 >> 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=E2=80=A6 >=20 > 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. Okay! Mirja >=20 > Regards, > Valery. >=20 >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> Regards, >>> Valery. >>>=20 >>>> Rgs, >>>> Panos >>>>=20 >>>> -----Original Message----- >>>> From: IPsec On Behalf Of Mirja K=C3=BChlewin= d via >>>> Datatracker >>>> Sent: Tuesday, January 07, 2020 8:41 AM >>>> To: The IESG >>>> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; = david.waltermire@nist.gov; >>>> draft-ietf-ipsecme-qr-ikev2@ietf.org >>>> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf-ipsecme-qr- >>>> ikev2-10: (with COMMENT) >>>>=20 >>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>> draft-ietf-ipsecme-qr-ikev2-10: No Objection >>>>=20 >>>> 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.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> 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! >>>>=20 >>>> 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? >>>>=20 >>>> 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? >>>>=20 >>>> 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...? >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>>=20 >=20 >=20 >=20 From nobody Wed Jan 8 05:20:07 2020 Return-Path: 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 559931200F4; Wed, 8 Jan 2020 05:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Log9DcIA7Q8L; Wed, 8 Jan 2020 05:20:00 -0800 (PST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) (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 3D7481200B7; Wed, 8 Jan 2020 05:20:00 -0800 (PST) Received: by mail-io1-f68.google.com with SMTP id h8so3178291iob.2; Wed, 08 Jan 2020 05:20:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=blEFC0/XTpdNM0GeYeZe23NlHex2oxO+S53QBmZiEGQ=; b=bhenqxUh7WQPnfbPu0RLA2mY0K0rq6vymY+/jM+Kax1kI6YJty8pDSYShFD2jyxhol EqAXnp27ozHWpGg743tPhzXAQszJmCYAxC207bTps3Xc+Xpcub7VQddCFtqzjaBve1xK 7griVayyNMyah4ApDZRXff+UYkT/5WTTDuCBQRI3vDaYUD7+UU91rJnscrjyXNCG1b74 qyl0gxTTh/CYkxuNpns0Bl8kzRJqCXWLUXPP/iqZM3r2w8OmQ4ZgJ+n4A/pM0Eg1jM24 Lv+mmRFxhuNF2r/EqlE2zz+lTOoiXAf2sF5AQ2v150inRm3sNHHQMy/ZsiDfvV/bwr8h YFlg== X-Gm-Message-State: APjAAAU66puwdQ04FL9BRq9rUZQmLVWAhDcUExzVG2PWIKx718jFV8Yx 3aKkorJECMUhVx5iaIH0IUokORpj6DcqtD+PVrR4bw== X-Google-Smtp-Source: APXvYqzxTS2mJEpBTmS7AcgfPu42bH8W+jh3ViPtQGjulmCHRvGfAWUhs7iSDznEConJV95mH+SyHuTSjRPf/JaiPYI= X-Received: by 2002:a02:4e46:: with SMTP id r67mr4074577jaa.118.1578489599291; Wed, 08 Jan 2020 05:19:59 -0800 (PST) MIME-Version: 1.0 References: <157846240313.20876.14052335668083715754.idtracker@ietfa.amsl.com> <00bd01d5c607$dfe2ef80$9fa8ce80$@elvis.ru> In-Reply-To: <00bd01d5c607$dfe2ef80$9fa8ce80$@elvis.ru> From: Barry Leiba Date: Wed, 8 Jan 2020 08:20:01 -0500 Message-ID: To: Valery Smyslov Cc: The IESG , draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, ipsec@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] Barry Leiba'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:20:01 -0000 All good, Valery, and thanks for the quick response. Barry On Wed, Jan 8, 2020 at 4:42 AM Valery Smyslov wrote: > > Hi Barry, > > > Barry Leiba 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.ht= ml > > 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: > > ---------------------------------------------------------------------- > > > > Yes, an interesting document, and thanks for that. A few editorial > > comments: > > > > =E2=80=94 Section 1 =E2=80=94 > > > > to be quantum resistant, that is, invulnerable to an attacker with a > > quantum computer. > > > > =E2=80=9CInvulnerable=E2=80=9D isn=E2=80=99t the same as =E2=80=9Cnot v= ulnerable=E2=80=9D: it has a stronger > > connotation. You should probably use =E2=80=9Cnot vulnerable=E2=80=9D = or =E2=80=9Cresistant=E2=80=9D > > instead. > > OK, thanks. > > > By bringing post- > > quantum security to IKEv2, this note removes the need to use > > > > Make it =E2=80=9Cthis document=E2=80=9D, please. > > OK. > > > This document does not replace the > > authentication checks that the protocol does; instead, it is done as > > a parallel check. > > > > What=E2=80=99s the antecedent to =E2=80=9Cit=E2=80=9D? Should =E2=80= =9Cit is=E2=80=9D instead be =E2=80=9Cthey are=E2=80=9D? > > I think it was meant that using PPK doesn't directly influence peer authe= ntication > in IKEv2, but I agree that the wording is not clear enough. > It's probably better to rephrase it: > > This document does not replace the > authentication checks that the protocol does; instead, they are > strengthened by using an additional secret key. > > Is it better? > > > =E2=80=94 Section 3 =E2=80=94 > > > > when the initiator believes it has a mandatory to use PPK > > > > You need hyphens in =E2=80=9Cmandatory-to-use=E2=80=9D. > > OK. > > THank you, > Valery. > > > > > =E2=80=94 > > > > I also find it interesting that Alexey thought you needed to add a norm= ative > > reference for =E2=80=9CASCII=E2=80=9D, bit not for =E2=80=9Cbase64=E2= =80=9D. Personally, I think both are > > sufficiently well known that you need neither. > > > > From nobody Wed Jan 8 05:22:07 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AC1200B7; Wed, 8 Jan 2020 05:22:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <157848972183.22539.2744332616397571958.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2020 05:22:01 -0800 Archived-At: Subject: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:22:02 -0000 Roman Danyliw 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: ---------------------------------------------------------------------- These are all editorial. ** Section 1. Per “Recent achievements in developing quantum computers …”, is there a citation? ** Section 1. Per: If the preshared key has sufficient entropy and the PRF, encryption and authentication transforms are quantum-secure, then the resulting system is believed to be quantum resistant, that is, invulnerable to an attacker with a quantum computer. -- The definition of quantum resistant doesn’t seem exactly precise. A quantum-resistant algorithm isn’t “invulnerable to an attacker with a quantum computer”, rather isn’t it instead no easier to attack than with known classical architectures? -- The first clause says the underlying primitives are quantum-secure, but then says that this translated into something being quantum-resistant. I found it confusing to mix both terms (which sometimes are used interchangeably) ** Section 1. Per “This document describes a way to extend IKEv2 to have a similar property; assuming that the two end systems share a long secret key then the resulting exchange is quantum resistant.”, I stumbled over this language a bit because I wasn’t sure which property you were referencing – was it the list of things in the previous paragraph’s last sentence that made it “quantum-secure”? ** Section 3. Per the description of modified IKEv2 key derivation: -- Recommend explicitly citing the relevant section: OLD: Then, it computes this modification of the standard IKEv2 key derivation: NEW: Then, it computes this modification of the standard IKEv2 key derivation from Section 2.14 of [RFC7296]: -- Recommend explaining the notation/relationship between the “prime versions” of the sub-keys (i.e., SK_d’ and SK_pi’ and SK_pr’) in the this SKEYSEED formula with the SKEYSEED formula in Section 2.14 of [RFC72196]. ** Editorial Nits: -- Section 1. Editorial. s/this note/this document/ -- trying to be consistent on how the I-D references itself. -- Section 4. Editorial. Recommended clarity: OLD: This will not affect the strength against a passive attacker; it would mean that an attacker with a quantum computer (which is sufficiently fast to be able to break the (EC)DH in real time) would not be able to perform a downgrade attack. NEW: This will not alter the resistance to a passive attack as even an attacker with a quantum computer (which is sufficiently fast to be able to break the (EC)DH in real time) would not be able to perform a downgrade attack. -- Section 5.2.3. Typo. s/Addtionally/Additionally/ -- Section 6. Typo. s/transmited/transmitted/ From nobody Wed Jan 8 05:28:04 2020 Return-Path: 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 ) 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 ) 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 To: 'Mirja Kuehlewind' CC: "'Panos Kampanakis (pkampana)'" , , , , 'The IESG' , References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.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, 8 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: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:28:03 -0000 Hi Mirja, > Hi Valery, >=20 > Please see inline. >=20 > > On 8. Jan 2020, at 12:55, Valery Smyslov wrote: > > > > Hi Mirja, > > > >> Hi Panos, hi Valery, > >> > >> Please see below. > >> > >>> On 8. Jan 2020, at 10:27, Valery Smyslov 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. >=20 > This depends: if you look at this from the receiver side, it a = description of > the protocol behaviour. But for the sender it=E2=80=99s 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 = =E2=80=9Cthe > initiation indicates=E2=80=9D is confusing here and it should actually = say =E2=80=9Cthe initiator > includes a NO_PPK_AUTH notification to indicate this optionality to = the > responder=E2=80=9C=E2=80=A6? 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=20 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. >=20 > 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.=20 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.=20 > So there is state anyway. Here you don=E2=80=99t have an open = connection and therefore you need an > timeout.=20 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).=E2=80=9D >=20 > (Please use your own wording=E2=80=A6) The whole idea of thwarting this attack is not to trust=20 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=20 comparing with the core spec. Regards, Valery. [...] > Mirja >=20 >=20 > > > > Regards, > > Valery. > > > >> Mirja > >> > >> > >> > >>> > >>> Regards, > >>> Valery. > >>> > >>>> Rgs, > >>>> Panos > >>>> > >>>> -----Original Message----- > >>>> From: IPsec On Behalf Of Mirja = K=C3=BChlewind > via > >>>> Datatracker > >>>> Sent: Tuesday, January 07, 2020 8:41 AM > >>>> To: The IESG > >>>> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; > david.waltermire@nist.gov; > >>>> draft-ietf-ipsecme-qr-ikev2@ietf.org > >>>> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf-ipsecme- > qr- > >>>> ikev2-10: (with COMMENT) > >>>> > >>>> Mirja K=C3=BChlewind 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 > >>> > >>> > > > > > > From nobody Wed Jan 8 05:31:34 2020 Return-Path: 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 In-Reply-To: <00e001d5c627$6c537290$44fa57b0$@elvis.ru> Date: Wed, 8 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)" , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.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 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: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >=20 > Hi Mirja, >=20 >> Hi Valery, >>=20 >> Please see inline. >>=20 >>> On 8. Jan 2020, at 12:55, Valery Smyslov wrote: >>>=20 >>> Hi Mirja, >>>=20 >>>> Hi Panos, hi Valery, >>>>=20 >>>> Please see below. >>>>=20 >>>>> On 8. Jan 2020, at 10:27, Valery Smyslov wrote: >>>>>=20 >>>>> Hi Panos, Mirja, >>>>>=20 >>>>>> Hi Mirja, >>>>>>=20 >>>>>> To try to answer your questions >>>>>>=20 >>>>>> 1) You are right. This is mentioned in a paragraph below that = reads >>>>>>=20 >>>>>> [...] 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). >>>>>>=20 >>>>>> But for clarity we will slightly rephrase the sentence you = pointed out to >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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: >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> This depends: if you look at this from the receiver side, it a = description of >> the protocol behaviour. But for the sender it=E2=80=99s 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 = =E2=80=9Cthe >> initiation indicates=E2=80=9D is confusing here and it should = actually say =E2=80=9Cthe initiator >> includes a NO_PPK_AUTH notification to indicate this optionality to = the >> responder=E2=80=9C=E2=80=A6? >=20 > It is definitely better, thank you! >=20 > 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=20 > to indicate this optionality to the responder. >=20 > Is it OK now? I still think use of normative language would be appropriate here. >=20 > [...] >=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> Kind of same here. Given you two disagree here already, I think it = would >> be >>>> good to give further advise. >>>=20 >>> 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: >>>=20 >>> 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. >>=20 >> 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.=20 >=20 > I meant another part of 2.4: >=20 > The number of retries and length of timeouts are not covered in this > specification because they do not affect interoperability.=20 >=20 >> So there is state anyway. Here you don=E2=80=99t have an open = connection and therefore you need an >> timeout.=20 >=20 > 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. >=20 >> 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).=E2=80=9D >>=20 >> (Please use your own wording=E2=80=A6) >=20 > The whole idea of thwarting this attack is not to trust=20 > 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=20 > comparing with the core spec. Okay. I wasn=E2=80=99t aware that these are existing time-outs. I think = the document could be more clear about this then. Mirja >=20 > Regards, > Valery. >=20 > [...] >=20 >> Mirja >>=20 >>=20 >>>=20 >>> Regards, >>> Valery. >>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards, >>>>> Valery. >>>>>=20 >>>>>> Rgs, >>>>>> Panos >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: IPsec On Behalf Of Mirja = K=C3=BChlewind >> via >>>>>> Datatracker >>>>>> Sent: Tuesday, January 07, 2020 8:41 AM >>>>>> To: The IESG >>>>>> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; >> david.waltermire@nist.gov; >>>>>> draft-ietf-ipsecme-qr-ikev2@ietf.org >>>>>> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf-ipsecme- >> qr- >>>>>> ikev2-10: (with COMMENT) >>>>>>=20 >>>>>> Mirja K=C3=BChlewind has entered the following ballot position = for >>>>>> draft-ietf-ipsecme-qr-ikev2-10: No Objection >>>>>>=20 >>>>>> 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.) >>>>>>=20 >>>>>>=20 >>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss- >> criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be found = here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> 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! >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>>> 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...? >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 From nobody Wed Jan 8 06:04:34 2020 Return-Path: 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 E3A8812004C; Wed, 8 Jan 2020 06:04:32 -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 1UFTBDQ6DEZj; Wed, 8 Jan 2020 06:04:31 -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 E2924120044; Wed, 8 Jan 2020 06:04:30 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ipBwf-0006ri-TC; Wed, 08 Jan 2020 17:04:26 +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 ) id 1ipBwc-0001K9-Jy; Wed, 08 Jan 2020 17:04:25 +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 17:04:21 +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 17:04:19 +0300 From: Valery Smyslov To: 'Mirja Kuehlewind' CC: , , , , "'Panos Kampanakis (pkampana)'" , 'The IESG' References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.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> In-Reply-To: Date: Wed, 8 Jan 2020 17:04:17 +0300 Message-ID: <00ea01d5c62c$84270cb0$8c752610$@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/ZhtxErcpkYXQMbldDrAeYv7v4CDBb0iwFmxbgmArS44bYB5ziBPwFLHo29p+ey3dA= 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 13:16:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2020/01/08 12:44:00 #14992744 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 14:04:33 -0000 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? >=20 >=20 > 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=E2=80=99t 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).=E2=80=9D > >> > >> (Please use your own wording=E2=80=A6) > > > > 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. >=20 > Okay. I wasn=E2=80=99t 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=20 (see section 2.4 of [RFC7296] for more details on retransmission timers = in IKEv2).=20 If all the received responses contain no USE_PPK, then the exchange is = aborted. Regards, Valery. > Mirja >=20 >=20 >=20 > > > > Regards, > > Valery. > > > > [...] > > > >> Mirja > >> > >> > >>> > >>> Regards, > >>> Valery. > >>> > >>>> Mirja > >>>> > >>>> > >>>> > >>>>> > >>>>> Regards, > >>>>> Valery. > >>>>> > >>>>>> Rgs, > >>>>>> Panos > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: IPsec On Behalf Of Mirja > K=C3=BChlewind > >> via > >>>>>> Datatracker > >>>>>> Sent: Tuesday, January 07, 2020 8:41 AM > >>>>>> To: The IESG > >>>>>> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; > >> david.waltermire@nist.gov; > >>>>>> draft-ietf-ipsecme-qr-ikev2@ietf.org > >>>>>> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf- > ipsecme- > >> qr- > >>>>>> ikev2-10: (with COMMENT) > >>>>>> > >>>>>> Mirja K=C3=BChlewind 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 > >>>>> > >>>>> > >>> > >>> > >>> > > > > From nobody Wed Jan 8 06:06:44 2020 Return-Path: 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 DD17912004C; Wed, 8 Jan 2020 06:06:41 -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 SX90kxuUF37x; Wed, 8 Jan 2020 06:06:38 -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 1C0BC12008B; Wed, 8 Jan 2020 06:06:38 -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 1ipByh-0004Qs-U1; Wed, 08 Jan 2020 15:06:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <00ea01d5c62c$84270cb0$8c752610$@elvis.ru> Date: Wed, 8 Jan 2020 15:06:31 +0100 Cc: ipsecme-chairs@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org, "Panos Kampanakis (pkampana)" , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.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> <00ea01d5c62c$84270cb0$8c752610$@elvis.ru> To: Valery Smyslov X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578492398;46028137; X-HE-SMSGID: 1ipByh-0004Qs-U1 Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 14:06:42 -0000 Hi Valery, Both look good to me. Thanks! One typo: s/mesages/messages/ Thanks! Mirja > On 8. Jan 2020, at 15:04, Valery Smyslov wrote: >=20 > Hi Mirja, >=20 > [...] >=20 >>> It is definitely better, thank you! >>>=20 >>> 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. >>>=20 >>> Is it OK now? >>=20 >>=20 >> I still think use of normative language would be appropriate here. >=20 > OK. >=20 > 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. >=20 >>> [...] >>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> Kind of same here. Given you two disagree here already, I think = it >> would >>>> be >>>>>> good to give further advise. >>>>>=20 >>>>> 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: >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> I meant another part of 2.4: >>>=20 >>> The number of retries and length of timeouts are not covered in = this >>> specification because they do not affect interoperability. >>>=20 >>>> So there is state anyway. Here you don=E2=80=99t have an open = connection and >> therefore you need an >>>> timeout. >>>=20 >>> 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. >>>=20 >>>> 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).=E2=80=9D >>>>=20 >>>> (Please use your own wording=E2=80=A6) >>>=20 >>> 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. >>=20 >> Okay. I wasn=E2=80=99t aware that these are existing time-outs. I = think the document >> could be more clear about this then. >=20 > Is this better? >=20 > 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=20 > (see section 2.4 of [RFC7296] for more details on retransmission = timers in IKEv2).=20 > If all the received responses contain no USE_PPK, then the exchange is = aborted. >=20 > Regards, > Valery. >=20 >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> Regards, >>> Valery. >>>=20 >>> [...] >>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards, >>>>> Valery. >>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>> Valery. >>>>>>>=20 >>>>>>>> Rgs, >>>>>>>> Panos >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: IPsec On Behalf Of Mirja >> K=C3=BChlewind >>>> via >>>>>>>> Datatracker >>>>>>>> Sent: Tuesday, January 07, 2020 8:41 AM >>>>>>>> To: The IESG >>>>>>>> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; >>>> david.waltermire@nist.gov; >>>>>>>> draft-ietf-ipsecme-qr-ikev2@ietf.org >>>>>>>> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf- >> ipsecme- >>>> qr- >>>>>>>> ikev2-10: (with COMMENT) >>>>>>>>=20 >>>>>>>> Mirja K=C3=BChlewind has entered the following ballot position = for >>>>>>>> draft-ietf-ipsecme-qr-ikev2-10: No Objection >>>>>>>>=20 >>>>>>>> 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.) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss- >>>> criteria.html >>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The document, along with other ballot positions, can be found = here: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>> COMMENT: >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>> 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! >>>>>>>>=20 >>>>>>>> 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? >>>>>>>>=20 >>>>>>>> 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? >>>>>>>>=20 >>>>>>>> 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...? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> IPsec mailing list >>>>>>>> IPsec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20 >=20 From nobody Wed Jan 8 06:09:57 2020 Return-Path: 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" To: "'Mirja Kuehlewind'" , "'Valery Smyslov'" Cc: , , , , "'Panos Kampanakis \(pkampana\)'" , "'The IESG'" References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.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> <00ea01d5c62c$84270cb0$8c752610$@elvis.ru> In-Reply-To: Date: Wed, 8 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: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 14:09:56 -0000 > Hi Valery, >=20 > Both look good to me. Thanks! >=20 > One typo: s/mesages/messages/ Thank you! Regards, Valery. > Thanks! > Mirja >=20 >=20 >=20 > > On 8. Jan 2020, at 15:04, Valery Smyslov 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=E2=80=99t 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).=E2=80=9D > >>>> > >>>> (Please use your own wording=E2=80=A6) > >>> > >>> 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=E2=80=99t 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=C3=BChlewind > >>>> via > >>>>>>>> Datatracker > >>>>>>>> Sent: Tuesday, January 07, 2020 8:41 AM > >>>>>>>> To: The IESG > >>>>>>>> Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; > >>>> david.waltermire@nist.gov; > >>>>>>>> draft-ietf-ipsecme-qr-ikev2@ietf.org > >>>>>>>> Subject: [IPsec] Mirja K=C3=BChlewind's No Objection on = draft-ietf- > >> ipsecme- > >>>> qr- > >>>>>>>> ikev2-10: (with COMMENT) > >>>>>>>> > >>>>>>>> Mirja K=C3=BChlewind 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 > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > > > > > > >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jan 8 06:42:15 2020 Return-Path: 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 3F7B1120106; Wed, 8 Jan 2020 06:42:07 -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 aCBIT2w81qBv; Wed, 8 Jan 2020 06:42:04 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 4F141120100; Wed, 8 Jan 2020 06:42:04 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id 203so2601048lfa.12; Wed, 08 Jan 2020 06:42:04 -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=hXIcNN7eFaLqquOJxDkbUoMcBAdBEgfrkX+UM7KI738=; b=ckKsW5rMzu10Z3y3uFf9F7+lcDilEHDqwGvnjkxUIz4ey8lVAYVd71KAdHAtINOFRZ 4JQn4VwisnezuJoMJXXjQ+TSO9xDC/89MqcRy16yrzqPyvnqJoAdua6YZjLUGjKWRaVM RD2yT405owfDZSJhKjxDqw2KK8Kcy0WWg+8kv4p/Ux4HWLyvq2H7HLKr+dt1RZiwI+9k 50qlb2VY3eDZjlwHkCM4T7H2J9vp4GrP0heoNZCvRP/Nv6SFlJRY7mL+7xRUomRxT69B 0hHZD93xHF8w1HO+l6IxkmSGLKA/yxHuNjSsRNWvXmLX34CP0QHBFFWLl/4QNAq/5tK7 7eMA== 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=hXIcNN7eFaLqquOJxDkbUoMcBAdBEgfrkX+UM7KI738=; b=mQIEOia40x7GvidzcWBYNRo/qx92q8fjZojhBRBmI/l0TY71fXfa3GpUJH46aZWg9E 016c4AEM3niPnTyo1bRu2//Ks7Vrl6QsubUVg9hN2wkyXWWq2zEyNwA8efjb5Cz+SePF iPrxr/EyzQwyDvrX2/YbmLfH4+v0kyS3wIq3MoCJn6lDTIKYetQbGK8N3Ev5wWocBczG KHDn64iRvhbEs/O/8ol8rSN7BszRiuG16s6lGK0AtsZaTO8b7SMfVz/a/wgXyfJu7FU4 NDmwRHWixov7UsyWB2u57wO/MwgIeXBWl5sJJBOfKFStnkHxlj2vtghHnenk00CYMauR MFCw== X-Gm-Message-State: APjAAAXjP2FgOCTSlDtRSmdDvSEi3j0q5a5CrELuQH/v238qPMRme6DB aawmUVTvnuxqdc8jKNTOBZo= X-Google-Smtp-Source: APXvYqw1mDm1nZIf8Q4Ubm0UQOENtFQAr0m1y5QlcOgmFiWMTD0SM+zP+0sCaoHuMUOmNrGtGAvHPA== X-Received: by 2002:a19:7401:: with SMTP id v1mr2984457lfe.129.1578494522434; Wed, 08 Jan 2020 06:42:02 -0800 (PST) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id m21sm1489645lfh.53.2020.01.08.06.42.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jan 2020 06:42:01 -0800 (PST) From: "Valery Smyslov" To: "'Roman Danyliw'" , "'The IESG'" Cc: , , , References: <157848972183.22539.2744332616397571958.idtracker@ietfa.amsl.com> In-Reply-To: <157848972183.22539.2744332616397571958.idtracker@ietfa.amsl.com> Date: Wed, 8 Jan 2020 17:41:59 +0300 Message-ID: <00ec01d5c631$c8b5ea40$5a21bec0$@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: AQFITT44UlchcJP7OR6RvXiyPMteCqj7tQ5A Content-Language: ru Archived-At: Subject: Re: [IPsec] Roman Danyliw'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 14:42:08 -0000 Hi Roman, > Roman Danyliw has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > These are all editorial. >=20 > ** Section 1. Per =E2=80=9CRecent achievements in developing quantum = computers > =E2=80=A6=E2=80=9D, is > there a citation? Do you mean a citation about achievements? I'm not sure it's easy to = find a stable reference here, but probably Scott or David or Panos have a good one... > ** Section 1. Per: > If the preshared key has > sufficient entropy and the PRF, encryption and authentication > transforms are quantum-secure, then the resulting system is = believed > to be quantum resistant, that is, invulnerable to an attacker with = a > quantum computer. >=20 > -- The definition of quantum resistant doesn=E2=80=99t seem exactly = precise. A > quantum-resistant algorithm isn=E2=80=99t =E2=80=9Cinvulnerable to an = attacker with a > quantum > computer=E2=80=9D, rather isn=E2=80=99t it instead no easier to attack = than with known > classical architectures? My understanding is that it's infeasible to break such a system even=20 with a help of quantum computer.=20 Grover's algorithm still gives an attacker equipped with QC an advantage comparing with classical architectures, but=20 proper selection of algorithms and key lengths doesn't=20 allow him to break the system. It was discussed a bit during AD's review of the draft: https://mailarchive.ietf.org/arch/msg/ipsec/8AEgzGjqsDMTUy1X0IB4JWv_zlE And probably my co-authors will give more authoritative answer here. > -- The first clause says the underlying primitives are quantum-secure, = but > then > says that this translated into something being quantum-resistant. I = found it > confusing to mix both terms (which sometimes are used interchangeably) To be frank I don't feel difference here, but again I rely on my = co-authors here. > ** Section 1. Per =E2=80=9CThis document describes a way to extend = IKEv2 to have a > similar property; assuming that the two end systems share a long = secret key > then the resulting exchange is quantum resistant.=E2=80=9D, I stumbled = over this > language a bit because I wasn=E2=80=99t sure which property you were = referencing =E2=80=93 > was > it the list of things in the previous paragraph=E2=80=99s last = sentence that made it > =E2=80=9Cquantum-secure=E2=80=9D? I believe it is a property of being "quantum-secure" (or "quantum = resistant"). If we change all instances of "quantum resistant" with "quantum-secure" in the Section 1, will the text be more clear? > ** Section 3. Per the description of modified IKEv2 key derivation: >=20 > -- Recommend explicitly citing the relevant section: > OLD: > Then, it computes this modification of the standard IKEv2 key = derivation: >=20 > NEW: > Then, it computes this modification of the standard IKEv2 key = derivation > from > Section 2.14 of [RFC7296]: OK. > -- Recommend explaining the notation/relationship between the = =E2=80=9Cprime > versions=E2=80=9D > of the sub-keys (i.e., SK_d=E2=80=99 and SK_pi=E2=80=99 and = SK_pr=E2=80=99) in the this SKEYSEED > formula with the SKEYSEED formula in Section 2.14 of [RFC72196]. I'm not sure I fully understand what you mean. I think we provide formulas of how prime and non-prime versions are correlated (i.e. how non-prime versions are computed from prime = versions). Am I missing something? > ** Editorial Nits: >=20 > -- Section 1. Editorial. s/this note/this document/ -- trying to be = consistent > on how the I-D references itself. OK, already noted by Barry. > -- Section 4. Editorial. Recommended clarity: >=20 > OLD: > This will not affect the strength against a > passive attacker; it would mean that an attacker with a quantum > computer (which is sufficiently fast to be able to break the (EC)DH > in real time) would not be able to perform a downgrade attack. >=20 > NEW: > This will not alter the resistance to a passive attack as even an = attacker with > a quantum computer (which is sufficiently fast to be able to break the > (EC)DH > in real time) would not be able to perform a downgrade attack. No, this would change the meaning. The idea here that the second = optional step of marking all PPKs as mandatory has no effect against passive = attackers (because PPK is already used for all connections), instead by this step we protect ourselves against a hypothetical downgrade attack performed by active attacker. So, how about: This will not affect the strength against a passive attacker, but it would mean that an active attacker with a = quantum computer (which is sufficiently fast to be able to break the (EC)DH in real time) would not be able to perform a downgrade attack. > -- Section 5.2.3. Typo. s/Addtionally/Additionally/ >=20 > -- Section 6. Typo. s/transmited/transmitted/ Thank you, Valery. >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jan 8 08:29:30 2020 Return-Path: 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 3A7B212022E for ; Wed, 8 Jan 2020 08:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=sn3rd.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 sC94opmcKKy9 for ; Wed, 8 Jan 2020 08:29:27 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 79CB4120152 for ; Wed, 8 Jan 2020 08:29:27 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id j5so3236749qtq.9 for ; Wed, 08 Jan 2020 08:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OsflFNiow06K3zzR2jT+qheK+OZEzpxAe+QqMSZWMNY=; b=U3aRQRhuGw6l6I7u1KDJG4Aeipy9cRszL6YZ2ThqVhAuHP3/NoZNw01fcZ1BqBRdq6 HtR/th6lI8bBloqPCRxCJMtbVIV8ncxfUKkHAoFv04J714KpgWikmjDk+IGPzD/ceUcm IJW5GvcZhC4Kn230yQYe77bD/jWJ6SLM92Mx0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OsflFNiow06K3zzR2jT+qheK+OZEzpxAe+QqMSZWMNY=; b=tfy6z+wtd0O8HKBYE1/I+z+TdBi6Gg4a2GVNqUCyWCkIU/JaDEIRzw9qOF28+3Gvd7 NyrGNVdYToI0NwSbJ1hXyEqA3bnQ4EStNwERLT6Oo4bAXnTQXwNWXTjh/sQ8W+LmR2bC ja+I10ksCM5YAbGPc97pTjIXS1LX69w0T7k8SyM5/DPfa0WGRjDIb6TUE6/hyl0zB6r3 1j1IDRSIXN2/JeWWwXUs9351kJjef7QnHGxMIIRyIYgwCaSTSXfRUDv+QoN0mR6/rSTC 6PTjl9cqKmdCqN7F0mpmk1ICG4+OYY2zdwaSjwJ4nppjA342Lg2gLZDMhEdvgT+VRKH+ kllA== X-Gm-Message-State: APjAAAX0NwPlyqY0t+4aEpJuCn+IO5tZixWdYnUytpPiOs/AN65VxY4e 5tfM5lpNVI3jKE21tWcz2bgGGA== X-Google-Smtp-Source: APXvYqzUt61/X6JaBwKS8A6FBvREzNv/D1XfnRpYwBeAeKOvNBvIT14FJEI5Zn5F+v5ac8MdwACdnw== X-Received: by 2002:ac8:7155:: with SMTP id h21mr3961762qtp.95.1578500966706; Wed, 08 Jan 2020 08:29:26 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id c3sm1626852qkk.8.2020.01.08.08.29.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 08:29:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <20200101220112.GG35479@kduck.mit.edu> Date: Wed, 8 Jan 2020 11:29:25 -0500 Cc: Paul Wouters , IPsec List Content-Transfer-Encoding: quoted-printable Message-Id: <1C1317B7-05FD-4D82-874B-AC3E045FAC8D@sn3rd.com> References: <20191223184651.GC35479@kduck.mit.edu> <20200101220112.GG35479@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 16:29:29 -0000 > On Jan 1, 2020, at 17:01, Benjamin Kaduk wrote: >=20 > On Mon, Dec 30, 2019 at 09:41:11PM -0500, Paul Wouters wrote: >> On Mon, 23 Dec 2019, Benjamin Kaduk wrote: >>=20 >>> "this document" (i.e., the RFC-to-be) does not actually effecuate = the move >>> to Historic status; the separate "status-change" document does so. = Looking >>> at a recent example in RFC 8429, we see this phrased akin to = "Accordingly, >>> IKEv1 has been moved to Historic status" with no claim of doing so = because >>> of the current document. >>=20 >> Changed, see = https://tools.ietf.org/rfcdiff?url2=3Ddraft-pwouters-ikev1-ipsec-graveyard= -04.txt >>=20 >> Paul >>=20 >>>> requests IANA to close all IKEv1 registries. >>>>=20 >>>> 2: Change section title >>>>=20 >>>> s/Deprecating IKEv1/RFC 2409 to Historic >>>=20 >>> This is probably okay to keep (I see Paul took the changes already), = but >>> the first sentence is still "IKEv1 is deprecated", which is sending = mixed >>> signals. >>=20 >> Is it a mixed signal? I've left the sentence in for now, but I'm fine = if >> we decide to remove it. I can always do that after adoption when I = need >> to re-submit the draft under the new name anyway. >=20 > I guess it's not entirely clear. > = https://ietf.org/about/groups/iesg/statements/designating-rfcs-historic-20= 14-07-20/ > implies that "Historic" is for technology that is "retired", but in = some > usage, "deprecated" has more of a connotation of "not the best choice = right > now" which is not necessarily fully "retired". >=20 > We can leave it as-is for now. >=20 > -Ben BTW - however this ends up, I hope the WG will adopt this draft. spt= From nobody Wed Jan 8 09:07:25 2020 Return-Path: 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 8ADB312089F; Wed, 8 Jan 2020 09:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dQBizgtR; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=QfWOxfDJ 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 BJdlnIZjCsXy; Wed, 8 Jan 2020 09:07:17 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BCA120885; Wed, 8 Jan 2020 09:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13929; q=dns/txt; s=iport; t=1578503236; x=1579712836; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FcDlAAIi6V9VvLThUA0tcn3iIQV6brIcQYiCpmWZypo=; b=dQBizgtRYl0c2XqhIWmw/0p/mREbCBDe6q5h+pU5PptzFH5RNCE6e9yB ZWA2uBZxiHXgi49uaolQTlmrFhKRqpkIY9o+4mg+piSelcGtntVX1/boa mJ8DlDL1zvL18tc6Haf5/3Lfv3R3qTo9dJJukMxdQL5NWnzGNGNEnqrIk Q=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AdtdajBBO4ZlW8mrDXNlxUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNP3jajQzGs1qX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnBQDGChZe/4kNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBVFAFbCstIAQLKoQJg0YDiwaCX5gNgUKBEANUAgcBAQEJAwE?= =?us-ascii?q?BGAsKAgEBhEACgWokOBMCAw0BAQQBAQECAQUEbYULBiYMhV4BAQEBAgEBARA?= =?us-ascii?q?RHQEBLAQHAQQHBAIBBgIRBAEBKwICAiULHQgCBAENBQgGFIMBgXlNAw4RDwE?= =?us-ascii?q?CDJAVkGQCgTiIYXWBMoJ+AQEFgTUBAwQMQYMMGIIFBwMGgTaBU4d9gkkagUE?= =?us-ascii?q?/gRFHgkw+gmQBAQEBAQGBLAESASEVG4JeMoIsjVUvgkKeZQqCNoNhgjiBHY8?= =?us-ascii?q?HgkeHfpAdjlWIV5IRAgQCBAUCDgEBBYFpIjcwWBEIcBU7gmxQGA2GEYcBOIM?= =?us-ascii?q?7hRSFP3QBgSeNIYIyAQE?= X-IronPort-AV: E=Sophos;i="5.69,410,1571702400"; d="p7s'?scan'208";a="420173373" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 17:07:15 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 008H7FkM026906 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2020 17:07:15 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 11:07:14 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 11:07:14 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 8 Jan 2020 12:07:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U7SkKYu8eDSnxF7vKtO1/jc65qHzQpdUk42ZkX11POsgnfttruZzefcNkExSWSm6yeK1CUBojL817tbkoVbM6IYZLZOyQH1RypS6kkGbOyVO0VPL66gLSaejJsI0jT2QIiEHPFBOwnY9QMUpPARX76K0iiLgRmlH9hef3yb1bUfHPSI03e1ExAtdtHA9SqVTsGHY5jH+camkdl/vz9AD5oC20G1yyA0lN6aLcSJJ7ozoLV+/LcqZpycTVbPRwqn3wk3oieQIRIGwg9p2ODoxfqBsbZCQy5kgLsaPfJvZL41ZbYVTEIFNUGLGzn8wBQcjAw2A9B6HxhdEJpMywMpW+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sJV6hcE7OOXn0WPW3wlqkPG8msbDwjMN2vO0j0yYpZA=; b=CpLW7R9TNi1ZI7PFbw8EtCnl2CQtVInfL55bWUbFAu6LfK5OsF4B5cF5rB+gBDERf0dAa3QYg1MJhlhsVaCbNosq61vre8VnJGie8KL9OHWiaVilbfRJUH7cfI/xwS9YYA0l2SQi7IJC7ERGAWXpikuENlGdfCyUJnVREoKke4STMsly8DwqUpB9bFYto7m5pnwKB0QDraHJ20u+YJFN4zp7npcJ2FyUmaF54io1tJ/13RoZ+w/lIZ/NU+K0h2M/9t00to53EJttVb8LodSh3dPEG427QB8oo7UE+BUpHdfUozsstp0f7GacmLNg5W4aW3r5uFRPdcTzxUEcT9aPXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sJV6hcE7OOXn0WPW3wlqkPG8msbDwjMN2vO0j0yYpZA=; b=QfWOxfDJvYh/7u1jykTqANDsOk0xWmWzieDQPDqP8ssVOA0QdCjL9QrTyzBEFZgCBc6RsDVVNnLl5kKKx32rslw5iZkHC2Ne3jRSlBBx0N9L1aq9PZmzFM4JNdDa9vEAGGteh890R0V1jqJ/AzkDIGf9sluSjWLm4Vj+9owHcyg= Received: from DM6PR11MB2555.namprd11.prod.outlook.com (20.176.98.161) by DM6PR11MB3674.namprd11.prod.outlook.com (20.178.231.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Wed, 8 Jan 2020 17:07:12 +0000 Received: from DM6PR11MB2555.namprd11.prod.outlook.com ([fe80::9d2c:809e:a5ac:efd2]) by DM6PR11MB2555.namprd11.prod.outlook.com ([fe80::9d2c:809e:a5ac:efd2%6]) with mapi id 15.20.2623.008; Wed, 8 Jan 2020 17:07:12 +0000 From: "Panos Kampanakis (pkampana)" To: Valery Smyslov , "'Roman Danyliw'" , "'The IESG'" CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Thread-Index: AQHVxiasGIY8ZJ1kkEu+aQGbZOljnafg10KAgAARmNA= Date: Wed, 8 Jan 2020 17:07:12 +0000 Message-ID: References: <157848972183.22539.2744332616397571958.idtracker@ietfa.amsl.com> <00ec01d5c631$c8b5ea40$5a21bec0$@gmail.com> In-Reply-To: <00ec01d5c631$c8b5ea40$5a21bec0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:8115:d592:a8c6:2a7a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06f49d5d-eab7-4bba-41ab-08d7945d346c x-ms-traffictypediagnostic: DM6PR11MB3674: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(376002)(39860400002)(346002)(13464003)(189003)(199004)(186003)(7696005)(478600001)(52536014)(66446008)(66946007)(66616009)(64756008)(66556008)(2906002)(8676002)(966005)(81156014)(5660300002)(8936002)(4326008)(71200400001)(76116006)(81166006)(66476007)(33656002)(6506007)(53546011)(316002)(110136005)(9686003)(54906003)(55016002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3674; H:DM6PR11MB2555.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3dVzriEVSWZnmYG2vQX6VTFrbJ6u4S+Uw9ffoT+0nxor72qiA14i9NMKObFJWl3hiGgwx2frt64OPNaxASPHetinCeG6J94QeXAd72HRr2Owawd9tPHGsrBNtUxs5Dfhmst1Wqpr0wYcuChMHTLAxTLx1+BAxEIJwlJJ71fGcJx3yNG9LalAo3BGg+p457R5LRKSFZAFaY1XLYintjCgiq3/kQtUgq0LjH5vePHcA7P/qly3GuspLDZnRNaeMkYPHohqaBIMYw5R4PXEhtl4CRLWdjJV+xIMgMebaHSAKbxyrlo7OlX+i/5pSmAibxvEuP9lDLlRyLx3L2AAtKi3Y0pKnXg3SybTBxN6fitpbSdX4in1W+aFyOLlMqfLQat5sgjSH0ZAR4XSTPhYttcanRaqBxRLTr0Gr3Gw4KWTkR0V8hntrrsFNgUvv4fG0z5id66daKT8qrhI8PMA5QhbSrJlZ1N1a4F3qjqy4JHUmmEVsPlOpBczdCisyY24kLie7kza/r8en4gVfKbREjOyJVXdd8kj7+j+Elfn2KcRT+nZi6HhM8//r7Ek6hk3rx7J x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0014_01D5C61C.2837FF00" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06f49d5d-eab7-4bba-41ab-08d7945d346c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 17:07:12.7164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6Cpd1gVq+fXDUvqhWTkzT+ZD64AwlffzS1rwsvxhlV7KDy+4QjVm0uH7DUrGm96ioCG04xeiFGZ9ODuW3D9rfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3674 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [IPsec] Roman Danyliw'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 17:07:20 -0000 ------=_NextPart_000_0014_01D5C61C.2837FF00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Two more comments in addition to Valery's.=20 > > ** Section 1. Per =E2=80=9CRecent achievements in developing = quantum computers =E2=80=A6=E2=80=9D, is there a citation? [I-D.hoffman-c2pq] is a good citation which we use already that talks = about the QC concern and Grover and Shor's algorithms. So we could cite = it here as well. Now about the latest QC advancements, the latest that I = know of was Google's quantum supremacy one = https://www.nature.com/articles/d41586-019-03224-w But that will change = with other announcements that will come a later. So, I am afraid there = is no good citation here other than [I-D.hoffman-c2pq].=20 > -- The definition of quantum resistant doesn=E2=80=99t seem exactly = precise. =20 There have been four terms that can be used interchangeably. = Quantum-safe used by ETSI, post-quantum used by NIST, quantum-secure, = and quantum-resistant. Practically all these mean algorithms that are = not susceptible to a variant of Shor's algorithm and offer adequate = classical and PQ security. NIST defines it as "cryptographic systems = that are secure against both quantum and classical computers, and can = interoperate with existing communications protocols and networks. ". I = guess we could use one of the terms throughout the document. And we = could rephrase the sentence=20 invulnerable to an attacker with a quantum computer. to say something like=20 secure against classical attackers=20 of today or future attackers with a=20 quantum computer. Rgs,=20 Panos -----Original Message----- From: IPsec On Behalf Of Valery Smyslov Sent: Wednesday, January 08, 2020 9:42 AM To: 'Roman Danyliw' ; 'The IESG' Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; david.waltermire@nist.gov; = draft-ietf-ipsecme-qr-ikev2@ietf.org Subject: Re: [IPsec] Roman Danyliw's No Objection on = draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Hi Roman, > Roman Danyliw has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > These are all editorial. >=20 > ** Section 1. Per =E2=80=9CRecent achievements in developing quantum=20 > computers =E2=80=A6=E2=80=9D, is there a citation? Do you mean a citation about achievements? I'm not sure it's easy to = find a stable reference here, but probably Scott or David or Panos have = a good one... > ** Section 1. Per: > If the preshared key has > sufficient entropy and the PRF, encryption and authentication > transforms are quantum-secure, then the resulting system is = believed > to be quantum resistant, that is, invulnerable to an attacker with = a > quantum computer. >=20 > -- The definition of quantum resistant doesn=E2=80=99t seem exactly = precise. =20 > A quantum-resistant algorithm isn=E2=80=99t =E2=80=9Cinvulnerable to = an attacker with=20 > a quantum computer=E2=80=9D, rather isn=E2=80=99t it instead no easier = to attack than=20 > with known classical architectures? My understanding is that it's infeasible to break such a system even = with a help of quantum computer.=20 Grover's algorithm still gives an attacker equipped with QC an advantage = comparing with classical architectures, but proper selection of = algorithms and key lengths doesn't allow him to break the system. It was discussed a bit during AD's review of the draft: https://mailarchive.ietf.org/arch/msg/ipsec/8AEgzGjqsDMTUy1X0IB4JWv_zlE And probably my co-authors will give more authoritative answer here. > -- The first clause says the underlying primitives are quantum-secure, = > but then says that this translated into something being=20 > quantum-resistant. I found it confusing to mix both terms (which=20 > sometimes are used interchangeably) To be frank I don't feel difference here, but again I rely on my = co-authors here. > ** Section 1. Per =E2=80=9CThis document describes a way to extend = IKEv2 to=20 > have a similar property; assuming that the two end systems share a=20 > long secret key then the resulting exchange is quantum = resistant.=E2=80=9D, I=20 > stumbled over this language a bit because I wasn=E2=80=99t sure which = property=20 > you were referencing =E2=80=93 was it the list of things in the = previous=20 > paragraph=E2=80=99s last sentence that made it = =E2=80=9Cquantum-secure=E2=80=9D? I believe it is a property of being "quantum-secure" (or "quantum = resistant"). If we change all instances of "quantum resistant" with "quantum-secure" in the Section 1, will the text be more clear? > ** Section 3. Per the description of modified IKEv2 key derivation: >=20 > -- Recommend explicitly citing the relevant section: > OLD: > Then, it computes this modification of the standard IKEv2 key = derivation: >=20 > NEW: > Then, it computes this modification of the standard IKEv2 key=20 > derivation from Section 2.14 of [RFC7296]: OK. > -- Recommend explaining the notation/relationship between the = =E2=80=9Cprime=20 > versions=E2=80=9D > of the sub-keys (i.e., SK_d=E2=80=99 and SK_pi=E2=80=99 and = SK_pr=E2=80=99) in the this=20 > SKEYSEED formula with the SKEYSEED formula in Section 2.14 of = [RFC72196]. I'm not sure I fully understand what you mean. I think we provide formulas of how prime and non-prime versions are = correlated (i.e. how non-prime versions are computed from prime = versions). Am I missing something? > ** Editorial Nits: >=20 > -- Section 1. Editorial. s/this note/this document/ -- trying to be=20 > consistent on how the I-D references itself. OK, already noted by Barry. > -- Section 4. Editorial. Recommended clarity: >=20 > OLD: > This will not affect the strength against a > passive attacker; it would mean that an attacker with a quantum > computer (which is sufficiently fast to be able to break the (EC)DH > in real time) would not be able to perform a downgrade attack. >=20 > NEW: > This will not alter the resistance to a passive attack as even an=20 > attacker with a quantum computer (which is sufficiently fast to be=20 > able to break the (EC)DH in real time) would not be able to perform a=20 > downgrade attack. No, this would change the meaning. The idea here that the second = optional step of marking all PPKs as mandatory has no effect against = passive attackers (because PPK is already used for all connections), = instead by this step we protect ourselves against a hypothetical = downgrade attack performed by active attacker. So, how about: This will not affect the strength against a passive attacker, but it would mean that an active attacker with a = quantum computer (which is sufficiently fast to be able to break the (EC)DH in real time) would not be able to perform a downgrade attack. > -- Section 5.2.3. Typo. s/Addtionally/Additionally/ >=20 > -- Section 6. Typo. s/transmited/transmitted/ Thank you, Valery. >=20 >=20 > _______________________________________________ > 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 ------=_NextPart_000_0014_01D5C61C.2837FF00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA4MTcwNzExWjAvBgkqhkiG9w0BCQQxIgQgznplhL+3HcgVNP2YekK+PqExkibZ+wPO AFbPCDzN7zQwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA H95E94q3YZsVdliyPoFqSSlvhRRc5/QwosnfTCGTqLZ9CFItGljK3TrKrTWKwiYZjexgzj2WdUCV 7UAPruCWKzbDM4YE0syGit77M60Coeq8vKGd9XVKE4asy2g5Seo9huaGXQrCd0Pmy/9/KUHykThn 6QYRsLrxmGnfmMGYCNZWpx9ML5p1HTWdFxwxIoRxNegypzCsMgQodp991vWAPrvJ+wP178Aw3+qx NSdqVlQTKq8GKLnxURmmKOLIJmEB+JRnR/IWz/N1jC+U8xt12FsNv+/2REqHbknBi+Fpji74+VK+ RMcpvtbsHMDUznggQo0E61QRfju7+aTSHLdHrQAAAAAAAA== ------=_NextPart_000_0014_01D5C61C.2837FF00-- From nobody Wed Jan 8 09:22:26 2020 Return-Path: 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 C62811208AB; Wed, 8 Jan 2020 09:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 2N9JZm3B3e6I; Wed, 8 Jan 2020 09:22:22 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 8E5AF1208B9; Wed, 8 Jan 2020 09:22:22 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47tGJr4xmrzF8S; Wed, 8 Jan 2020 18:22:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1578504140; bh=6KVFCd2LgWJ2409b2T2fHS5/aJdVVNWZA4K7YGgnWM0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZlOhSp0bHBTZAyP2kXMYrKmxDSP02gbSlS9DAWnExg8KftikS8zEs+XotvECl7mrc n1aKlVKWmqoqBPUoxqbUFh8zTJmmbL3OkZk2WGomuKvM8mtTUnUjyy0SIhyxQ8BUBF XS8z2KuAB8dNOvTTI9C0wHwXliO+Ig0ZNFrWWm6M= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7KqgiOpovlvc; Wed, 8 Jan 2020 18:22:19 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 8 Jan 2020 18:22:19 +0100 (CET) Received: from [10.206.84.155] (199-7-157-32.eng.wind.ca [199.7.157.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 45BF26001425; Wed, 8 Jan 2020 12:22:18 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net> Date: Wed, 8 Jan 2020 12:22:17 -0500 Cc: Valery Smyslov , "Panos Kampanakis (pkampana)" , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, The IESG , david.waltermire@nist.gov Content-Transfer-Encoding: quoted-printable Message-Id: References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> <00bc01d5c605$ca5916f0$5f0b44d0$@elvis.ru> <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net> To: Mirja Kuehlewind Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ipsecme-qr-ikev2-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 17:22:25 -0000 > On Jan 8, 2020, at 04:41, Mirja Kuehlewind wrote: >=20 >>=20 >> I think one or two RTT is too short, moreover since it's an initial reque= st, >> no RTT is yet measured (IKEv2 uses UDP as primary transport). >> We try here to be in line with core IKEv2 spec, which deliberately=20 >> 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. >=20 > Kind of same here. Given you two disagree here already, I think it would b= e good to give further advise. I agree with Valerie. We don=E2=80=99t do that on purpose. A 100gbps connect= ion is different from a satellite connection. Let the implementation handle t= hat part. >> I agree with Panos: the downgrade is possible only if using PPK is option= al >> for both, in which case both parties agree that downgrade is OK. >=20 > Having some downgrade detection would enable to log an attack if optional P= PK was used. That would be lost in the noise when using mixed ppl/noppk use I think. As s= aid, one is expected to only allow noppk during migration, which would be ve= ry limited in time (like hours or days for static tunnels, maybe weeks or a f= ew months for remote access VPN updates to happen) Paul= From nobody Wed Jan 8 13:48:26 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CDB12003E; Wed, 8 Jan 2020 13:48:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <157852009927.22485.15123997628919595988.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2020 13:48:19 -0800 Archived-At: Subject: [IPsec] Martin Vigoureux's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 21:48:19 -0000 Martin Vigoureux 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: ---------------------------------------------------------------------- Hi, It seems to me there are places where 2119/8174 keywords would make sense. Few examples, with suggestions: If the initiator is configured to use a post-quantum preshared key with the responder (whether or not the use of the PPK is mandatory), then it will include a notification USE_PPK in the IKE_SA_INIT request message as follows: >>MUST include If the initiator needs to resend this initial message with a cookie (because the responder response included a COOKIE notification), then the resend would include the USE_PPK notification if the original message did. >>MUST (or SHOULD?) include by the way, if it is a resend of the message described in the paragraph above, then "if the original message did" seems superfluous. Otherwise the responder replies with the IKE_SA_INIT message including a USE_PPK notification in the response: >>MUST reply initiator and the responder. The responder can use the PPK_ID to look up the corresponding PPK value. Not all implementations are able to configure arbitrary octet strings; to improve the potential interoperability, it is recommended that, in the PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 characters 0-9, A-Z, a-z, + and /. >>RECOMMENDED values 3-127 are reserved for IANA; Maybe it's just because I'm not used to that wording, but why "reserved for IANA" ? The table seems to qualify them as unassigned. From nobody Wed Jan 8 15:48:04 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D401208B9; Wed, 8 Jan 2020 15:47:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157852727628.22527.5762506193173961280.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2020 15:47:56 -0800 Archived-At: Subject: [IPsec] Adam Roach's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 23:47:57 -0000 Adam Roach 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: ---------------------------------------------------------------------- Thanks for the work done on this protocol extension. I only have two relatively minor comments. --------------------------------------------------------------------------- §5.1: > It is anticipated > that later standards will extend this technique to allow dynamically > changing PPK values. It's likely that future specifications will extend the technique even before becoming standards. Consider changing "standards" to "specifications." --------------------------------------------------------------------------- §5.1: > Not all implementations are > able to configure arbitrary octet strings; to improve the > potential interoperability, it is recommended that, in the > PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited > to the base64 character set, namely the 64 characters 0-9, A-Z, > a-z, + and /. This is a little confusing, since the base64 character set has 65 characters in it (the 64 cited, plus '='). If the omission of '=' is intentional, please add a short statement indicating so -- otherwise, implementors may assume that its omission is unintentional and include it in their IDs. To the extent that the problem describes arises in the field, this has the potential to cause cause similar issues. From nobody Wed Jan 8 22:12:38 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3019120220; Wed, 8 Jan 2020 22:12:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157855035655.22493.15695714831672285496@ietfa.amsl.com> Date: Wed, 08 Jan 2020 22:12:36 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 06:12:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Group Key Management using IKEv2 Authors : Brian Weis Valery Smyslov Filename : draft-ietf-ipsecme-g-ikev2-00.txt Pages : 52 Date : 2020-01-08 Abstract: This document presents a set of IKEv2 exchanges that comprise a group key management protocol. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 8 23:15:48 2020 Return-Path: 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 0FB34120020; Wed, 8 Jan 2020 23:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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] 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 nTK9k6QJrfrl; Wed, 8 Jan 2020 23:15:38 -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 83FEF120220; Wed, 8 Jan 2020 23:15:38 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ipS2Y-0008NS-Ct; Thu, 09 Jan 2020 10:15:34 +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 ) id 1ipS2X-00004x-5c; Thu, 09 Jan 2020 10:15:34 +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; Thu, 9 Jan 2020 10:15:33 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Thu, 9 Jan 2020 10:15:32 +0300 From: Valery Smyslov To: 'Adam Roach' , 'The IESG' CC: , 'David Waltermire' , , References: <157852727628.22527.5762506193173961280.idtracker@ietfa.amsl.com> In-Reply-To: <157852727628.22527.5762506193173961280.idtracker@ietfa.amsl.com> Date: Thu, 9 Jan 2020 10:15:37 +0300 Message-ID: <08d601d5c6bc$97722850$c65678f0$@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: AQJzNWDF2HhuFj6Cl/A7+jzM8rmPNqanDZeA 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/09 06:53:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2020/01/09 05:07:00 #14996825 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] Adam Roach'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 07:15:41 -0000 Hi Adam, > Adam Roach has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Thanks for the work done on this protocol extension. I only have two > relatively minor comments. >=20 > = -------------------------------------------------------------------------= -- >=20 > =C2=A75.1: >=20 > > It is anticipated > > that later standards will extend this technique to allow = dynamically > > changing PPK values. >=20 > It's likely that future specifications will extend the technique even = before > becoming standards. Consider changing "standards" to "specifications." OK, makes sense. > = -------------------------------------------------------------------------= -- >=20 > =C2=A75.1: >=20 > > Not all implementations are > > able to configure arbitrary octet strings; to improve the > > potential interoperability, it is recommended that, in the > > PPK_ID_FIXED case, both the PPK and the PPK_ID strings be = limited > > to the base64 character set, namely the 64 characters 0-9, A-Z, > > a-z, + and /. >=20 > This is a little confusing, since the base64 character set has 65 = characters > in it (the 64 cited, plus '=3D'). If the omission of '=3D' is = intentional, > please add a short statement indicating so -- otherwise, implementors = may > assume that its omission is unintentional and include it in their IDs. = To > the extent that the problem describes arises in the field, this has = the > potential to cause cause similar issues. The omission was unintentional, we'll add '=3D' to the list of = characters. Thank you, Valery. From nobody Thu Jan 9 00:04:39 2020 Return-Path: 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 03CE812002E; Thu, 9 Jan 2020 00:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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] 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 4vyK-DXQzOAm; Thu, 9 Jan 2020 00:04:29 -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 9B1EB120013; Thu, 9 Jan 2020 00:04:29 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ipSnq-0000R2-Gw; Thu, 09 Jan 2020 11:04:26 +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 ) id 1ipSnq-0000XB-4u; Thu, 09 Jan 2020 11:04:26 +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; Thu, 9 Jan 2020 11:04:25 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Thu, 9 Jan 2020 11:04:25 +0300 From: Valery Smyslov To: 'Martin Vigoureux' , 'The IESG' CC: , 'David Waltermire' , , References: <157852009927.22485.15123997628919595988.idtracker@ietfa.amsl.com> In-Reply-To: <157852009927.22485.15123997628919595988.idtracker@ietfa.amsl.com> Date: Thu, 9 Jan 2020 11:04:30 +0300 Message-ID: <08de01d5c6c3$6ba47500$42ed5f00$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLead1yXvl74INi5I0QBk6sINiU7qXQpXdw 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/09 06:53:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2020/01/09 05:07:00 #14996825 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] Martin Vigoureux'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 08:04:32 -0000 Hi Martin, > Martin Vigoureux 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: > ---------------------------------------------------------------------- > > Hi, > > It seems to me there are places where 2119/8174 keywords would make sense. > Few examples, with suggestions: > If the initiator is configured to use a post-quantum preshared key > with the responder (whether or not the use of the PPK is mandatory), > then it will include a notification USE_PPK in the IKE_SA_INIT > request message as follows: > >>MUST include Isn't it just a protocol description and not a requirement? Anyway, I have no problem with using RFC2119 language here, but a few years ago I was told by one of ADs that I improperly used RFC2119 language when I wrote a very similar sentence: "if initiator is configured with foo it MAY include a bar notification in its request"; I was told then that plain English must be used in this case :-) > If the initiator needs to resend this initial message with a cookie > (because the responder response included a COOKIE notification), then > the resend would include the USE_PPK notification if the original > message did. > >>MUST (or SHOULD?) include I don't think it is needed here. Section 2.6 of RFC7296 has already a requirement, that ...the initiator MUST then retry the IKE_SA_INIT request, and include the COOKIE notification containing the received data as the first payload, and all other payloads unchanged. So we don't impose new requirement, we just remind readers that USE_PPK will also be included in the resend message. > by the way, if it is a resend of the message described in the paragraph above, > then "if the original message did" seems superfluous. It is a resend, but the resending message is a bit different from the original, since it includes the cookie received from the responder. See section 2.6 of RFC7296 for details. > Otherwise the responder replies with the IKE_SA_INIT message including a > USE_PPK notification in the response: > >>MUST reply > > initiator and the responder. The responder can use the PPK_ID to > look up the corresponding PPK value. Not all implementations are > able to configure arbitrary octet strings; to improve the > potential interoperability, it is recommended that, in the > PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited > to the base64 character set, namely the 64 characters 0-9, A-Z, > a-z, + and /. > >>RECOMMENDED The "recommended" here is intentionally made non-normative, otherwise the requirement is too strong (there are a number of use cases, where the requirement for PPK to be base64 limited makes a little sense, like hardware tokens etc.). So it's just a general recommendation. > values 3-127 are reserved for IANA; > Maybe it's just because I'm not used to that wording, but why "reserved for > IANA" ? The table seems to qualify them as unassigned. Is there a difference? I've been thinking that "reserved for IANA" means that these values are currently unassigned, but IANA will use them for future assignments... Thank you, Valery. From nobody Thu Jan 9 04:01:17 2020 Return-Path: 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 252CE120885; Thu, 9 Jan 2020 04:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 pG8dPGSqMe3k; Thu, 9 Jan 2020 04:01:12 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2103.outbound.protection.outlook.com [40.107.22.103]) (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 4ED4D120890; Thu, 9 Jan 2020 04:01:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m4BgYANWgsjrb1EExBNu9o1kBMHh97kGSiUBPyCQNb6GBTgBJzPbojkNXMxgt74JEGDMQhNOHy6rY51F2r4F6DSmzQOhJH6WjFSsF95PIHyHspDbghHZnr0QBspqXVEEskDrRS9/efN0ODPo7wk/eB4LwHoTmJIm2F3PzoKqx2Wu8ltdCDSe0WPXt8x3u/1dSKhFKup2ydEuCfQkTSzcP6T/DOZDjf2ZaDO4GMCZoTvbigl0rcYtzkXUITKrcnT1evv9b80UGzGqqawqLZcmeml2YOIXMO3woL3/yQg/Qkt83g3u5Khjac/Lx1WYNWwm9L8p4MBPdHYcZZ7cHMe0ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=go1jGdUlzx+OMXA+svltOarHLBSxPVqx+Ckwb6zps9U=; b=lDtwx4OarIrSASv6w03ZIOdl5Lj7KKI5N6stQpueyXeMAy1l0pPI1YWZI6IC6thPRbhHcdcbYCGLshl6oncKOjsxeJBZ7tCj81JLhw58k2aA4gT6adkPzMfC9OH3RKGAlkLPwOouZDPIVC7Wm9INbCbPA7Gd2tNOxvDwY3pUREvXbUB2Ba1GZRNcQWgaWORgZFxr3n8aAUdFSyKLzwYnh4XJdzZhdtGHoYP+mQtzMPfspbuoDbu6Oc112JLAEtI4h7DbKyiF0RZx1WfIKGMHuhYwqCQKCZtklpvf8J1rYtZ3EoFj+RbG2N4wMAZSq1DhlZqNomruH0+Q0VcJMY9L3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=go1jGdUlzx+OMXA+svltOarHLBSxPVqx+Ckwb6zps9U=; b=QOufRyKde8mvOQaqifYBsxhjqSYR5EbIyAHBG8ghnxNQPF+mjVOk3Dte2vfGRYk9ua7nlaIMtyBUlT4C5dqp5JsynwqMk6tvJsTPt+idBy8KmGIPP+1B7mtZMPgaKba0byhmivY8nJ0U5mdgzensxlWNBooO609d/DZYUfYtFIM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from DB7PR07MB4140.eurprd07.prod.outlook.com (52.134.96.142) by DB7PR07MB5627.eurprd07.prod.outlook.com (20.178.47.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.7; Thu, 9 Jan 2020 12:01:09 +0000 Received: from DB7PR07MB4140.eurprd07.prod.outlook.com ([fe80::b1d0:9cc:48cb:e49]) by DB7PR07MB4140.eurprd07.prod.outlook.com ([fe80::b1d0:9cc:48cb:e49%5]) with mapi id 15.20.2644.006; Thu, 9 Jan 2020 12:01:09 +0000 To: Valery Smyslov , 'The IESG' Cc: draft-ietf-ipsecme-qr-ikev2@ietf.org, 'David Waltermire' , ipsecme-chairs@ietf.org, ipsec@ietf.org References: <157852009927.22485.15123997628919595988.idtracker@ietfa.amsl.com> <08de01d5c6c3$6ba47500$42ed5f00$@elvis.ru> From: Martin Vigoureux Message-ID: <09c7f062-b7f0-84d4-97cf-bd268d655255@nokia.com> Date: Thu, 9 Jan 2020 13:01:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 In-Reply-To: <08de01d5c6c3$6ba47500$42ed5f00$@elvis.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PR0P264CA0168.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::36) To DB7PR07MB4140.eurprd07.prod.outlook.com (2603:10a6:5:1::14) MIME-Version: 1.0 Received: from [172.30.2.230] (131.228.2.20) by PR0P264CA0168.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9 via Frontend Transport; Thu, 9 Jan 2020 12:01:08 +0000 X-Originating-IP: [131.228.2.20] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1126ac40-db6a-4000-8788-08d794fb9d27 X-MS-TrafficTypeDiagnostic: DB7PR07MB5627: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 02778BF158 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(366004)(199004)(189003)(52314003)(2906002)(81166006)(8676002)(36756003)(16526019)(31686004)(186003)(8936002)(26005)(4326008)(66574012)(5660300002)(52116002)(81156014)(498600001)(66946007)(6666004)(66556008)(66476007)(110136005)(6486002)(16576012)(966005)(956004)(44832011)(2616005)(86362001)(31696002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5627; H:DB7PR07MB4140.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1NgZgoa72oCK/LjTR/Fmee2T+P7sDsYaGjyixr1LakCzL4llqJHB1On/o4PACojZzBuE6Om/Y428WYeJBlREeYmQScyRjrtiKyqnwWnPc1vregQuf7jAPCvcMaj1i8A5nras7P91uREus4Rd/vy0v2+kTU1GScw3fAJeo5kQ4ZJ7wRIZuJkHk96GuWj7M8vl/D4FnRwMgBsI46mviYWmtqCXfJmFcO4WymGM7JXutssNV7KKoaBHVFhuD5loQMEYEEIKffZWFF/+P9O+eYwnUb49lP7lgLeE8NyGzS925a5NvkqLhY1NfuwJZMkv3MJgiUTMg80eCDXunKTlJ71mGUB9PXc2Wwrt42aJs9I0sRwpDUHNZSMNGXQM0K79hUHPEIhOkwFowVK9X7+XwdsCGrM3NHK4DFVx953orv+lw4bhQCLDQ+02M1QnSivAMRaAvqaHGPNGizEl+ersOAzYqx8Aa1DjsbYmIF5aTLJZR4vq3s/NYv34myt0pf6p/KR23gJQcQKL9dGuD2fhTJn2eX1Ctl02uQ7qg9EmAty6txBl3PxqDVyqo7IskmNshkM+ X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1126ac40-db6a-4000-8788-08d794fb9d27 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2020 12:01:09.1979 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WJ9IXB7vUS7dPL7LN8XbzTSwdgtkDq5MFtdWQdixsA8LUcltn7+gqt/t6xHavcykXZIknz8kfmT0mrmNmQoJ5CzobLSlYPrvbtiYzHUyu6g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5627 Archived-At: Subject: Re: [IPsec] Martin Vigoureux'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 12:01:15 -0000 Hello Valery, thank you for your feedback. Please see in-inline. Le 2020-01-09 à 9:04, Valery Smyslov a écrit : > Hi Martin, > >> Martin Vigoureux 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: >> ---------------------------------------------------------------------- >> >> Hi, >> >> It seems to me there are places where 2119/8174 keywords would make sense. >> Few examples, with suggestions: >> If the initiator is configured to use a post-quantum preshared key >> with the responder (whether or not the use of the PPK is mandatory), >> then it will include a notification USE_PPK in the IKE_SA_INIT >> request message as follows: >>>> MUST include > > Isn't it just a protocol description and not a requirement? it is, but for a implementation to behave like that I tend to think that having a requirement in the first place would make sense. > > Anyway, I have no problem with using RFC2119 language here, > but a few years ago I was told by one of ADs that > I improperly used RFC2119 language when I wrote > a very similar sentence: "if initiator is configured with foo > it MAY include a bar notification in its request"; > I was told then that plain English must be used in this case :-) ADs can have different points of view :-) Yet, I'm not seeking to change to the doc, so if you feel this is fine like that (and I agree that at least it's not wrong) then don't change anything. > >> If the initiator needs to resend this initial message with a cookie >> (because the responder response included a COOKIE notification), then >> the resend would include the USE_PPK notification if the original >> message did. >>>> MUST (or SHOULD?) include > > I don't think it is needed here. Section 2.6 of RFC7296 has already > a requirement, that > > ...the initiator MUST then retry the > IKE_SA_INIT request, and include the COOKIE notification containing > the received data as the first payload, and all other payloads > unchanged. my bad. I did a quick read of that section and obviously missed the last part of that sentence ... > > So we don't impose new requirement, we just remind readers that > USE_PPK will also be included in the resend message. > >> by the way, if it is a resend of the message described in the paragraph above, >> then "if the original message did" seems superfluous. > > It is a resend, but the resending message is a bit different from the original, > since it includes the cookie received from the responder. > See section 2.6 of RFC7296 for details. > >> Otherwise the responder replies with the IKE_SA_INIT message including a >> USE_PPK notification in the response: >>>> MUST reply >> >> initiator and the responder. The responder can use the PPK_ID to >> look up the corresponding PPK value. Not all implementations are >> able to configure arbitrary octet strings; to improve the >> potential interoperability, it is recommended that, in the >> PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited >> to the base64 character set, namely the 64 characters 0-9, A-Z, >> a-z, + and /. >>>> RECOMMENDED > > The "recommended" here is intentionally made non-normative, > otherwise the requirement is too strong (there are a number > of use cases, where the requirement for PPK to be base64 limited makes a little sense, > like hardware tokens etc.). So it's just a general recommendation. ok, understood. > >> values 3-127 are reserved for IANA; >> Maybe it's just because I'm not used to that wording, but why "reserved for >> IANA" ? The table seems to qualify them as unassigned. > > Is there a difference? I've been thinking that "reserved for IANA" means > that these values are currently unassigned, but IANA will use them for future assignments... As said, this is the first time I see this written this way, so I raised the question. If it is well understood that this means "unassigned" then fine. What is ultimately important is what is written in the table/registry. > > Thank you, > Valery. > > > regards, martin From nobody Fri Jan 10 00:01:44 2020 Return-Path: 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 4F655120895 for ; Fri, 10 Jan 2020 00:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FTW0MP6A-K4V for ; Fri, 10 Jan 2020 00:01:42 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 4F59B120894 for ; Fri, 10 Jan 2020 00:01:42 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q3V00I1ASYTS4@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 10 Jan 2020 02:01:41 -0600 (CST) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q3V00LGSSYDZ7@trixy.bergandi.net> for ipsec@ietf.org; Fri, 10 Jan 2020 00:01:25 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 10 Jan 2020 00:01:25 -0800 Date: Fri, 10 Jan 2020 00:01:39 -0800 From: Dan Harkins In-reply-to: <20191223184651.GC35479@kduck.mit.edu> To: ipsec@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <20191223184651.GC35479@kduck.mit.edu> X-PMAS-Software: PreciseMail V3.3 [200108] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 08:01:43 -0000 On 12/23/19 10:46 AM, Benjamin Kaduk wrote: > Since we're in pedantic process mode... [snip] > Perhaps something like "IKEv1 is no longer relevant for Internet > systems" would work, though I suspect we could even get away without such > an intro sentence and just dive in straight with "Systems running IKEv1 > should be upgraded and reconfigured to run IKEv2.   See that's the thing. There is nothing compelling to force the change away from "no longer relevant" so people still use it. If there was something compelling to make people want to change we wouldn't be forced to do this, sigh, die die die nonsense. Perhaps, "we're the IETF and we are really serious now". That should dispel all doubt in whoever happens to read this RFC. That way we won't need a die die die die or a die die die die die die.   Dan. From nobody Fri Jan 10 03:40:05 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D71B21208B5; Fri, 10 Jan 2020 03:39:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157865639271.27581.4661383369956651848@ietfa.amsl.com> Date: Fri, 10 Jan 2020 03:39:52 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 11:39:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Multiple Key Exchanges in IKEv2 Authors : C. Tjhai M. Tomlinson G. Bartlett S. Fluhrer D. Van Geest O. Garcia-Morchon Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-multiple-ke-00.txt Pages : 23 Date : 2020-01-08 Abstract: This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing of a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie- Hellman key exchange, so that the resulting shared key is resistant against quantum computer attacks. Another possible application is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document updates RFC7296 by renaming a tranform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 10 04:45:36 2020 Return-Path: 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 9463212008F for ; Fri, 10 Jan 2020 04:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 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, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 E-kOgT9VsbVN for ; Fri, 10 Jan 2020 04:45:32 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 A44BB12006E for ; Fri, 10 Jan 2020 04:45:31 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id n12so1378840lfe.3 for ; Fri, 10 Jan 2020 04:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=cFVAE1XsZkxKZgq0gygT5icHOflJ/ToqNTw+CYw7q6k=; b=V3raOcS622rXh9A/iXQAuDNoMaNoGT5WuAD+guQkvHKs91aY4Zt8XYHKEJuDgssN8I jYO70WVU0qPUY+J0WD37tb2wWtdNW8L6G3XpTaRNbLpj0SWZJwKowbmIOQAsyhnghmDC F5Oc926xDLMeAdb77io7/WYGtqfPgPfy/uxCieObz+0X1F9XkWizQcUNMDW524EWiMr+ Ll0gP3Vm1gF2tJJh4Wzq7J3XVeLhGZ8qbj/ua5lEAxxPKkgh7jemmPndjoIVFkgUuii5 K629zg1eLNTZei9WylYBl4HkmVn0zK2mpPmkyd22cpqxqr6AGu7VhpWdVCzNm3wyZY+J EhEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=cFVAE1XsZkxKZgq0gygT5icHOflJ/ToqNTw+CYw7q6k=; b=jfmbAKXjXH2yZSUPDE1cv/t+FgzF0xDA2aZg9ypulqwb7Hn64pEQxVWPJYsRWcGh0L cUxI2xEla2WS6Pb8TOL0udCEMUriPR/tJYJjQ6C1OOpZ1PNNdGoqy55kyYDj7S2BY7Ve umRzN/AyhNVSwtOSuPHflPctdCHGhUVdeZlZddmq58NaJx9oxzlMQlZBEnEUBBGT+JPZ 16ZnGco2vTCC3ypnXUhXwBmGnVEhdtBY7+jk+IezGjt7Ht6rFULZnC5TT7MJaZYLnaev OZRdVWuHjUo+Eizk7y0gUlcVXByFwvfu2D/Hlue3R5sf2NVSbEcq6pTEXIXj8wg+I8/I 4Udg== X-Gm-Message-State: APjAAAU25zsV8qN1q1EFTSNdoFQlIIQPwDk4sRWYQO+NT7UMVgfLyLA0 aVZukrrb0iEJ3s0001V5Nb0F83Sv X-Google-Smtp-Source: APXvYqyrokkw5ojQ8O4tLaiTMJkz4x9neemvLB3q8/3nUQMzzaaar19Msppn8cP/PBAzBLPLvmDmmw== X-Received: by 2002:ac2:44ce:: with SMTP id d14mr2307034lfm.140.1578660329652; Fri, 10 Jan 2020 04:45:29 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n11sm945618ljg.15.2020.01.10.04.45.28 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jan 2020 04:45:29 -0800 (PST) From: "Valery Smyslov" To: References: <157865639271.27581.4661383369956651848@ietfa.amsl.com> In-Reply-To: <157865639271.27581.4661383369956651848@ietfa.amsl.com> Date: Fri, 10 Jan 2020 15:45:33 +0300 Message-ID: <0a0901d5c7b3$d9ed5220$8dc7f660$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE8lvVuJDEySeKGR6kc3UwpgwNvp6kWNgTA Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 12:45:34 -0000 Hi, a new version of the draft has been published. 1. The draft name is changed to reflect its adoption by the WG and to better reflect its current concept 2. The concept is shifted from focusing on PQ hybrid mode only to defining a general way of combining several key exchanges (whether being classic or PQ) in IKEv2 3. A new dedicated exchange type (IKE_FOLLOWUP_KE) is defined for performing additional key exchanges following CREATE_CHILD_SA exchange (many folks on the list and off the list asked for this) 4. Extra nonces are excluded from additional key exchanges, a pair of nonces exchanged in IKE_SA_INIT (or CREATE_CHILD_SA) is used instead (some people complained that extra nonces complicated implementations, and it seems that they are not needed for security) 5. IANA considerations text is fixed 6. Some important clarifications and a lot of minor text improvements Please, review. Regards, Valery (for the authors). > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, January 10, 2020 2:40 PM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Multiple Key Exchanges in IKEv2 > Authors : C. Tjhai > M. Tomlinson > G. Bartlett > S. Fluhrer > D. Van Geest > O. Garcia-Morchon > Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-multiple-ke-00.txt > Pages : 23 > Date : 2020-01-08 > > Abstract: > This document describes how to extend the Internet Key Exchange > Protocol Version 2 (IKEv2) to allow multiple key exchanges to take > place while computing of a shared secret during a Security > Association (SA) setup. The primary application of this feature in > IKEv2 is the ability to perform one or more post-quantum key > exchanges in conjunction with the classical (Elliptic Curve) Diffie- > Hellman key exchange, so that the resulting shared key is resistant > against quantum computer attacks. Another possible application is > the ability to combine several key exchanges in situations when no > single key exchange algorithm is trusted by both initiator and > responder. > > This document updates RFC7296 by renaming a tranform type 4 from > "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and > renaming a field in the Key Exchange Payload from "Diffie-Hellman > Group Num" to "Key Exchange Method". It also renames an IANA > registry for this transform type from "Transform Type 4 - Diffie- > Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange > Method Transform IDs". These changes generalize key exchange > algorithms that can be used in IKEv2. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jan 10 09:09:29 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DC2120A6A; Fri, 10 Jan 2020 09:09:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157867616739.27617.3327414513327375112.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2020 09:09:27 -0800 Archived-At: Subject: [IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 17:09:27 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: Yoav Nir Tero Kivinen Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. Non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines. The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. Milestones: Dec 2019 - The internal address failure indication in IKEv2 to IESG May 2020 - G-DOI for IKEv2 to IESG May 2020 - Postquantum cryptography document for IKEv2 to IESG Aug 2020 - The security labels support for IKEv2 to IESG Aug 2020 - TCP-encapsulation guidelines document to IESG Nov 2020 - Traffic Flow Confidentiality document to IESG Jun 2021 - The ESP on contrained network to IESG Jun 2021 - Signature algorithm negotiation for IKEv2 to IESG From nobody Sun Jan 12 22:35:51 2020 Return-Path: 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 B31AD120073 for ; Sun, 12 Jan 2020 22:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 MVNyR6I1Y5Kz for ; Sun, 12 Jan 2020 22:35:48 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7427B120088 for ; Sun, 12 Jan 2020 22:35:47 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00D6ZgdD018597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 01:35:44 -0500 Date: Sun, 12 Jan 2020 22:35:41 -0800 From: Benjamin Kaduk To: Dan Harkins Cc: ipsec@ietf.org Message-ID: <20200113063541.GB66991@kduck.mit.edu> References: <20191223184651.GC35479@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 06:35:50 -0000 On Fri, Jan 10, 2020 at 12:01:39AM -0800, Dan Harkins wrote: > > > On 12/23/19 10:46 AM, Benjamin Kaduk wrote: > > Since we're in pedantic process mode... > [snip] > > Perhaps something like "IKEv1 is no longer relevant for Internet > > systems" would work, though I suspect we could even get away without such > > an intro sentence and just dive in straight with "Systems running IKEv1 > > should be upgraded and reconfigured to run IKEv2. > > See that's the thing. There is nothing compelling to force the change > away > from "no longer relevant" so people still use it. If there was something > compelling to make people want to change we wouldn't be forced to do this, > sigh, die die die nonsense. Perhaps, "we're the IETF and we are really > serious now". That should dispel all doubt in whoever happens to read this > RFC. That way we won't need a die die die die or a die die die die die die. I'm only aboue 95% sure I'm parsing you properly -- you're saying that if there was a clear reason to move from IKEv1 to IKEv2 the market would have done it already and we wouldn't be bothering with a doc like this? That is, that what we're really doing is akin to "we're the IETF and we pinky-swear that we're not going to touch this anymore" as opposed to "here is a list of the ways that using IKEv1 is going to bite you"? Thanks, Ben From nobody Mon Jan 13 07:36:45 2020 Return-Path: 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 28A301200F1 for ; Mon, 13 Jan 2020 07:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 mmfN7pw45Gva for ; Mon, 13 Jan 2020 07:36:41 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 69C6B120033 for ; Mon, 13 Jan 2020 07:36:41 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q4100BA9Y15CN@wwwlocal.goatley.com> for ipsec@ietf.org; Mon, 13 Jan 2020 09:36:41 -0600 (CST) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q4100726Y08Q0@trixy.bergandi.net> for ipsec@ietf.org; Mon, 13 Jan 2020 07:36:08 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 13 Jan 2020 07:36:08 -0800 Date: Mon, 13 Jan 2020 07:36:38 -0800 From: Dan Harkins In-reply-to: <20200113063541.GB66991@kduck.mit.edu> To: Benjamin Kaduk Cc: ipsec@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <20191223184651.GC35479@kduck.mit.edu> <20200113063541.GB66991@kduck.mit.edu> X-PMAS-Software: PreciseMail V3.3 [200110] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 15:36:43 -0000 On 1/12/20 10:35 PM, Benjamin Kaduk wrote: > On Fri, Jan 10, 2020 at 12:01:39AM -0800, Dan Harkins wrote: >> On 12/23/19 10:46 AM, Benjamin Kaduk wrote: >>> Since we're in pedantic process mode... >> [snip] >>> Perhaps something like "IKEv1 is no longer relevant for Internet >>> systems" would work, though I suspect we could even get away without such >>> an intro sentence and just dive in straight with "Systems running IKEv1 >>> should be upgraded and reconfigured to run IKEv2. >>   See that's the thing. There is nothing compelling to force the change >> away >> from "no longer relevant" so people still use it. If there was something >> compelling to make people want to change we wouldn't be forced to do this, >> sigh, die die die nonsense. Perhaps, "we're the IETF and we are really >> serious now". That should dispel all doubt in whoever happens to read this >> RFC. That way we won't need a die die die die or a die die die die die die. > I'm only aboue 95% sure I'm parsing you properly -- you're saying that if > there was a clear reason to move from IKEv1 to IKEv2 the market would have > done it already and we wouldn't be bothering with a doc like this? That > is, that what we're really doing is akin to "we're the IETF and we > pinky-swear that we're not going to touch this anymore" as opposed to "here > is a list of the ways that using IKEv1 is going to bite you"?   Yes, that's what I'm saying. From discussing this over the past few meetings it seems the motivation for this is because people are still getting pressure in their companies to work on IKEv1 or support IKEv1 or whatever and people want it to go away. But they're losing that argument at work so they want a document with the imprimatur of the IETF that they can wave at the PLM person (or whoever) and say, "SEE! IT'S DEAD! Finished. No more. Over. The IETF has spoken!"   So my "we're the IETF and we're serious this time" was sarcastic (and that comes out poorly in email, hence the parsing difficulty) because I don't think this is what the RFC process is for.   IKEv1 is done, it's over, it's dead. It's been like that for more than a decade. We already made a statement that we won't touch IKEv1 anymore and we made that statement fifteen years ago. And we're still doing "die die die" stuff that's now been refashioned into a "graveyard" effort in order to address the sensitive sensibilities of the new IETF, but it's still the same thing. It's trying add an underscore and an exclamation point to a statement that was already made. Because we're really serious this time-- it's in the graveyard!   Dan. From nobody Mon Jan 13 08:55:59 2020 Return-Path: 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 384631208D4 for ; Mon, 13 Jan 2020 08:55:57 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 PAw_ZgSMdmHP for ; Mon, 13 Jan 2020 08:55:55 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 402A71208D1 for ; Mon, 13 Jan 2020 08:55:55 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47xKTy6ljnzDFr; Mon, 13 Jan 2020 17:55:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1578934550; bh=93/bIElCLXxAKM4gTFRcsA9m4fY3652u+b23uXUY0Fc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sJs7MBHsPB8qWE7X3gcH8GxqoXD1Oxml5LiXMofGo+JnHnZ3ksO12vrlQuiy89QU5 tMLapcSKXx1eWq8/ClscE1paix9x63YU/Bf3Ip/7Mz8dyqIkE0b0cYNa7jP81hXSbW BzV1VpXmUw+Luf6TocMs8MJncfNYDpmXYLeaKQz4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l0csP-Rsye_x; Mon, 13 Jan 2020 17:55:49 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Jan 2020 17:55:48 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 069A46084CDD; Mon, 13 Jan 2020 11:55:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 02DE938563; Mon, 13 Jan 2020 11:55:48 -0500 (EST) Date: Mon, 13 Jan 2020 11:55:47 -0500 (EST) From: Paul Wouters To: Dan Harkins cc: Benjamin Kaduk , ipsec@ietf.org In-Reply-To: Message-ID: References: <20191223184651.GC35479@kduck.mit.edu> <20200113063541.GB66991@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 16:55:57 -0000 On Mon, 13 Jan 2020, Dan Harkins wrote: > IKEv1 is done, it's over, it's dead. It's been like that for more than a > decade. I think there is a big difference between "done developing it" and "done running it". A decade ago almost everything was IKEv1. Today, with the exception of Android and ten year old gear, everything is IKEv2. And Android is scheduled to fix that this summer. So the move to Historic does seem valid now, and was not 10 years ago. > We already made a statement that we won't touch IKEv1 anymore and we made that > statement fifteen years ago. And we're still doing "die die die" stuff that's now > been refashioned into a "graveyard" effort in order to address the sensitive > sensibilities of the new IETF, but it's still the same thing. It's trying add an > underscore and an exclamation point to a statement that was already made. Because > we're really serious this time-- it's in the graveyard! I agree, it is kind of a symbolic gesture. But I think it will help (and not harm), so I think we should just publish it for those who can use it as a lever to migrate more older setups to new. To be honest, the biggest gain will be that people stop using DH1024, DH1536 and SHA1 that are defacto the only DH groups used with IKEv1. Paul From nobody Mon Jan 13 09:58:29 2020 Return-Path: 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 CABC412089F; Mon, 13 Jan 2020 09:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 WURrFZ9e2oIm; Mon, 13 Jan 2020 09:58:18 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7B91D12088C; Mon, 13 Jan 2020 09:57:58 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00DHvpcQ000342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 12:57:53 -0500 Date: Mon, 13 Jan 2020 09:57:50 -0800 From: Benjamin Kaduk To: Valery Smyslov Cc: "'Roman Danyliw'" , "'The IESG'" , ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-qr-ikev2@ietf.org Message-ID: <20200113175750.GE66991@kduck.mit.edu> References: <157848972183.22539.2744332616397571958.idtracker@ietfa.amsl.com> <00ec01d5c631$c8b5ea40$5a21bec0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00ec01d5c631$c8b5ea40$5a21bec0$@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Roman Danyliw'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 17:58:21 -0000 On Wed, Jan 08, 2020 at 05:41:59PM +0300, Valery Smyslov wrote: > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-ipsecme-qr-ikev2-10: No Objection > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- [...] > > > -- Recommend explaining the notation/relationship between the “prime > > versions” > > of the sub-keys (i.e., SK_d’ and SK_pi’ and SK_pr’) in the this SKEYSEED > > formula with the SKEYSEED formula in Section 2.14 of [RFC72196]. > > I'm not sure I fully understand what you mean. > I think we provide formulas of how prime and non-prime versions > are correlated (i.e. how non-prime versions are computed from prime versions). > Am I missing something? I think the idea is something in the general vicinity of "the un-primed values SK_d, SK_pi, and SK_pr are used as inputs to subsequent steps of the IKEv2 exchange; this document uses the primed versions to represent the output of prf+ that are used directly in regular IKEv2, in order to introduce an additional operation (combination with PPK) between prf+ and subsequant usage". A reader looking at this document and RFC 7296 side-by-side will see that where RFC 7296 sets {SK_d [...]} = prf+ (SKEYSEED, [...]), this document uses the "primed" versions, and might wonder what's different between SK_d (RFC 7296) and SK_d' (this document). -Ben From nobody Mon Jan 13 10:02:54 2020 Return-Path: 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 A54C712088C; Mon, 13 Jan 2020 10:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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] 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 Qe6lO3Rx83Cs; Mon, 13 Jan 2020 10:02:44 -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 AAA2312081D; Mon, 13 Jan 2020 10:02:44 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ir42z-0008UT-07; Mon, 13 Jan 2020 21:02:41 +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 ) id 1ir42y-0007MI-JO; Mon, 13 Jan 2020 21:02:40 +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; Mon, 13 Jan 2020 21:02:39 +0300 Received: from chichi (10.100.100.14) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Mon, 13 Jan 2020 21:02:36 +0300 From: Valery Smyslov To: 'Benjamin Kaduk' , 'Valery Smyslov' CC: 'Roman Danyliw' , 'The IESG' , , , , References: <157848972183.22539.2744332616397571958.idtracker@ietfa.amsl.com> <00ec01d5c631$c8b5ea40$5a21bec0$@gmail.com> <20200113175750.GE66991@kduck.mit.edu> In-Reply-To: <20200113175750.GE66991@kduck.mit.edu> Date: Mon, 13 Jan 2020 21:02:36 +0300 Message-ID: <006e01d5ca3b$a2f25790$e8d706b0$@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: AQFITT44UlchcJP7OR6RvXiyPMteCgEnPNshAfavx6io6uzkwA== 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/13 17:43:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2020/01/13 15:17:00 #15029529 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] Roman Danyliw'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 18:02:47 -0000 Hi Ben, > On Wed, Jan 08, 2020 at 05:41:59PM +0300, Valery Smyslov wrote: > > > > > Roman Danyliw has entered the following ballot position for > > > draft-ietf-ipsecme-qr-ikev2-10: No Objection > > > > > > = ---------------------------------------------------------------------- > > > COMMENT: > > > = ---------------------------------------------------------------------- > [...] > > > > > -- Recommend explaining the notation/relationship between the = =E2=80=9Cprime > > > versions=E2=80=9D > > > of the sub-keys (i.e., SK_d=E2=80=99 and SK_pi=E2=80=99 and = SK_pr=E2=80=99) in the this SKEYSEED > > > formula with the SKEYSEED formula in Section 2.14 of [RFC72196]. > > > > I'm not sure I fully understand what you mean. > > I think we provide formulas of how prime and non-prime versions > > are correlated (i.e. how non-prime versions are computed from prime > versions). > > Am I missing something? >=20 > I think the idea is something in the general vicinity of "the = un-primed > values SK_d, SK_pi, and SK_pr are used as inputs to subsequent steps = of the > IKEv2 exchange; this document uses the primed versions to represent = the > output of prf+ that are used directly in regular IKEv2, in order to > introduce an additional operation (combination with PPK) between prf+ = and > subsequant usage". A reader looking at this document and RFC 7296 > side-by-side will see that where RFC 7296 sets {SK_d [...]} =3D prf+ > (SKEYSEED, [...]), this document uses the "primed" versions, and might > wonder what's different between SK_d (RFC 7296) and SK_d' (this > document). Thank you for clarification, we'll add similar clarification to the = draft. Regards, Valery. > -Ben From nobody Mon Jan 13 10:04:44 2020 Return-Path: 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 705AE120983; Mon, 13 Jan 2020 10:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 s6ug66cyjczH; Mon, 13 Jan 2020 10:04:32 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 C67CF12097F; Mon, 13 Jan 2020 10:04:32 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00DI4Uh7007175; Mon, 13 Jan 2020 13:04:30 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 00DI4Uh7007175 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1578938671; bh=dBaMiQQIkkCbOd2/hhn1PwBrKEpX4OgGyNbsSBA8rcM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Heq4sS4mkytvjlGYf78aadx5+USOHD144DvZosVq+FRVyyjrIm4D5xI5YBTht2XlW iwiOGRYmCRSdtaj1KIMeRuv1GjV2Y6IWm2YnmXcd+6cDqvPTxvEhEax64Zu1nqN6d8 A9Jb8A0mKyPmTXvRKp1+nJYQF3zgIm+UoSbaErBI= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00DI4RAw013080; Mon, 13 Jan 2020 13:04:27 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Mon, 13 Jan 2020 13:04:27 -0500 From: Roman Danyliw To: Benjamin Kaduk , Valery Smyslov CC: "'The IESG'" , "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" , "draft-ietf-ipsecme-qr-ikev2@ietf.org" Thread-Topic: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Thread-Index: AQHVxiahojmk0/apfkqJJDpcutCg3qfhKxSAgAgSYQD//6yMIA== Date: Mon, 13 Jan 2020 18:04:26 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E710417B@marchand> References: <157848972183.22539.2744332616397571958.idtracker@ietfa.amsl.com> <00ec01d5c631$c8b5ea40$5a21bec0$@gmail.com> <20200113175750.GE66991@kduck.mit.edu> In-Reply-To: <20200113175750.GE66991@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Roman Danyliw'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 18:04:36 -0000 SGkhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gS2Fk dWsgPGthZHVrQG1pdC5lZHU+DQo+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMywgMjAyMCAxMjo1 OCBQTQ0KPiBUbzogVmFsZXJ5IFNteXNsb3YgPHNteXNsb3YuaWV0ZkBnbWFpbC5jb20+DQo+IENj OiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyAnVGhlIElFU0cnIDxpZXNnQGlldGYub3Jn PjsNCj4gaXBzZWNAaWV0Zi5vcmc7IGlwc2VjbWUtY2hhaXJzQGlldGYub3JnOyBkYXZpZC53YWx0 ZXJtaXJlQG5pc3QuZ292OyBkcmFmdC0NCj4gaWV0Zi1pcHNlY21lLXFyLWlrZXYyQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIFJvbWFuIERhbnlsaXcncyBObyBPYmplY3Rpb24gb24g ZHJhZnQtaWV0Zi1pcHNlY21lLXFyLQ0KPiBpa2V2Mi0xMDogKHdpdGggQ09NTUVOVCkNCj4gDQo+ IE9uIFdlZCwgSmFuIDA4LCAyMDIwIGF0IDA1OjQxOjU5UE0gKzAzMDAsIFZhbGVyeSBTbXlzbG92 IHdyb3RlOg0KPiA+DQo+ID4gPiBSb21hbiBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+ID4gZHJhZnQtaWV0Zi1pcHNlY21lLXFyLWlrZXYy LTEwOiBObyBPYmplY3Rpb24NCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4g PiA+IENPTU1FTlQ6DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gWy4uLl0NCj4gPg0K PiA+ID4gLS0gUmVjb21tZW5kIGV4cGxhaW5pbmcgdGhlIG5vdGF0aW9uL3JlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRoZSDigJxwcmltZQ0KPiA+ID4gdmVyc2lvbnPigJ0NCj4gPiA+IG9mIHRoZSBzdWIt a2V5cyAoaS5lLiwgU0tfZOKAmSBhbmQgU0tfcGnigJkgYW5kIFNLX3By4oCZKSBpbiB0aGUgdGhp cw0KPiA+ID4gU0tFWVNFRUQgZm9ybXVsYSB3aXRoIHRoZSBTS0VZU0VFRCBmb3JtdWxhIGluIFNl Y3Rpb24gMi4xNCBvZg0KPiBbUkZDNzIxOTZdLg0KPiA+DQo+ID4gSSdtIG5vdCBzdXJlIEkgZnVs bHkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuLg0KPiA+IEkgdGhpbmsgd2UgcHJvdmlkZSBmb3Jt dWxhcyBvZiBob3cgcHJpbWUgYW5kIG5vbi1wcmltZSB2ZXJzaW9ucyBhcmUNCj4gPiBjb3JyZWxh dGVkIChpLmUuIGhvdyBub24tcHJpbWUgdmVyc2lvbnMgYXJlIGNvbXB1dGVkIGZyb20gcHJpbWUN Cj4gdmVyc2lvbnMpLg0KPiA+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQo+IA0KPiBJIHRoaW5r IHRoZSBpZGVhIGlzIHNvbWV0aGluZyBpbiB0aGUgZ2VuZXJhbCB2aWNpbml0eSBvZiAidGhlIHVu LXByaW1lZCB2YWx1ZXMNCj4gU0tfZCwgU0tfcGksIGFuZCBTS19wciBhcmUgdXNlZCBhcyBpbnB1 dHMgdG8gc3Vic2VxdWVudCBzdGVwcyBvZiB0aGUNCj4gSUtFdjIgZXhjaGFuZ2U7IHRoaXMgZG9j dW1lbnQgdXNlcyB0aGUgcHJpbWVkIHZlcnNpb25zIHRvIHJlcHJlc2VudCB0aGUNCj4gb3V0cHV0 IG9mIHByZisgdGhhdCBhcmUgdXNlZCBkaXJlY3RseSBpbiByZWd1bGFyIElLRXYyLCBpbiBvcmRl ciB0byBpbnRyb2R1Y2UgYW4NCj4gYWRkaXRpb25hbCBvcGVyYXRpb24gKGNvbWJpbmF0aW9uIHdp dGggUFBLKSBiZXR3ZWVuIHByZisgYW5kIHN1YnNlcXVhbnQNCj4gdXNhZ2UiLiAgQSByZWFkZXIg bG9va2luZyBhdCB0aGlzIGRvY3VtZW50IGFuZCBSRkMgNzI5NiBzaWRlLWJ5LXNpZGUgd2lsbCBz ZWUNCj4gdGhhdCB3aGVyZSBSRkMgNzI5NiBzZXRzIHtTS19kIFsuLi5dfSA9IHByZisgKFNLRVlT RUVELCBbLi4uXSksIHRoaXMgZG9jdW1lbnQNCj4gdXNlcyB0aGUgInByaW1lZCIgdmVyc2lvbnMs IGFuZCBtaWdodCB3b25kZXIgd2hhdCdzIGRpZmZlcmVudCBiZXR3ZWVuDQo+IFNLX2QgKFJGQyA3 Mjk2KSBhbmQgU0tfZCcgKHRoaXMgZG9jdW1lbnQpLg0KDQpZZXMuICBUaGF0J3MgdGhlIGtpbmQg b2YgY2xhcmlmeWluZyBsYW5ndWFnZSBJIHRoaW5rIHdvdWxkIGhlbHAuICBJdCdzIG5vdCB0aGF0 IHRoZSBmb3JtdWxhIGlzbid0IHNlbGYtY29uc2lzdGVudCB0byB0aGlzIGRyYWZ0LiAgSXQncyB0 aGF0IHdoZW4gdGhpcyBkb2N1bWVudCBzYXlzIGNvbXB1dGUgYSAic3RhbmRhcmQgSUtFdjIga2V5 IGRlcml2YXRpb24iIGFuZCB0aGVuICJhIHJlYWRlciBsb29raW5nIGF0IHRoaXMgZG9jdW1lbnQg YW5kIFJGQzcyOTYgLi4uIG1pZ2h0IHdvbmRlciB3aGF0J3MgdGhlIGRpZmZlcmVuY2UgLi4uIiAo YXMgQmVuIHNhaWQpLiAgDQoNClRoYW5rcywNClJvbWFuDQo= From nobody Mon Jan 13 10:12:41 2020 Return-Path: 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 D906412089F; Mon, 13 Jan 2020 10:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 mVf49NFwZb1U; Mon, 13 Jan 2020 10:12:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8F03F12088C; Mon, 13 Jan 2020 10:12:38 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00DICXJN005670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 13:12:35 -0500 Date: Mon, 13 Jan 2020 10:12:33 -0800 From: Benjamin Kaduk To: Barry Leiba Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-qr-ikev2@ietf.org Message-ID: <20200113181233.GF66991@kduck.mit.edu> References: <157846240313.20876.14052335668083715754.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <157846240313.20876.14052335668083715754.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Barry Leiba'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 18:12:40 -0000 On Tue, Jan 07, 2020 at 09:46:43PM -0800, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-ipsecme-qr-ikev2-10: No Objection > [...] > > I also find it interesting that Alexey thought you needed to add a normative > reference for “ASCII”, bit not for “base64”. Personally, I think both are > sufficiently well known that you need neither. In this case I'm inclined to agree, given the way that the base64 alphabet is used. (We do sometimes get into trouble with base64 vs. base64url, and I've asked for specific section references on occasion to disambiguate...) -Ben From nobody Mon Jan 13 10:54:10 2020 Return-Path: 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 8C5D912096D for ; Mon, 13 Jan 2020 10:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 D-haCDVOwCXi for ; Mon, 13 Jan 2020 10:54:07 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C376312088C for ; Mon, 13 Jan 2020 10:54:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D2903897D; Mon, 13 Jan 2020 13:53:31 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BB070A3B; Mon, 13 Jan 2020 13:53:56 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org, Benjamin Kaduk In-Reply-To: References: <20191223184651.GC35479@kduck.mit.edu> <20200113063541.GB66991@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] graveyard: deprecate->historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 18:54:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> IKEv1 is done, it's over, it's dead. It's been like that for more th= an >> a decade. > I think there is a big difference between "done developing it" and > "done running it". A decade ago almost everything was IKEv1. Today, > with the exception of Android and ten year old gear, everything is > IKEv2. And Android is scheduled to fix that this summer. So the move = to > Historic does seem valid now, and was not 10 years ago. +1 >> We already made a statement that we won't touch IKEv1 anymore and we >> made that statement fifteen years ago. And we're still doing "die die >> die" stuff that's now been refashioned into a "graveyard" effort in >> order to address the sensitive sensibilities of the new IETF, but it= 's >> still the same thing. It's trying add an underscore and an exclamati= on >> point to a statement that was already made. Because we're really >> serious this time-- it's in the graveyard! > I agree, it is kind of a symbolic gesture. But I think it will help > (and not harm), so I think we should just publish it for those who can > use it as a lever to migrate more older setups to new. To be honest, > the biggest gain will be that people stop using DH1024, DH1536 and SH= A1 > that are defacto the only DH groups used with IKEv1. It will gain more than symbolism if it becomes an audit checkpoint, and will actually push people to upgrade. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4cvMQACgkQgItw+93Q 3WXMnwgAvpGqlNriMBbzoceEVEpsVyJow0PR6ALaFbv9fMNTCQE6/b2kpsbTOa4B QbJwbdVGMO5rSf7HpTNtuVKWAI5HjscwkGcy1MLjOze9KvhsWpeQ7/o+BWddGf1j c+ZpUsbDuvFgSqOZLJwziaDyQjw6gMEHUJ/mK39qGI9SGDv/WClju2RMBQUc2Aha XyMlbb6D63LbXH4J3ptKOM89UYo+exiXeMBXzPvlvQKSmy9YBZolNsknic+MYwow YsSd+CaJVED11x2gB6MzN3JzLdFMWuCTsxk2eeK532u4URX47y3a/BgJup/1NrHr dGsoakGPoACBaOGX8CGIfk0gS1kpbA== =Towg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 14 21:16:57 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEAF12010F; Tue, 14 Jan 2020 21:16:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157906540345.11743.14247555047270819801@ietfa.amsl.com> Date: Tue, 14 Jan 2020 21:16:43 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 05:16:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Mixing Preshared Keys in IKEv2 for Post-quantum Security Authors : Scott Fluhrer Panos Kampanakis David McGrew Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-11.txt Pages : 20 Date : 2020-01-14 Abstract: The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-11 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 14 21:25:20 2020 Return-Path: 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 E9A2A12006B for ; Tue, 14 Jan 2020 21:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WwJQ0cHq; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=U4YznOwZ 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 SzzFT58XX4P8 for ; Tue, 14 Jan 2020 21:25:14 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D7D120048 for ; Tue, 14 Jan 2020 21:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8329; q=dns/txt; s=iport; t=1579065914; x=1580275514; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TLMw6AA0AqQ19q58dOHja21qgiCGRAraUVaagBaNUI0=; b=WwJQ0cHqWRd8xGIVL/DaY/PtEAVvl1meCpMZYlde2z14oZ0yp01zt0ep NTh7LhajvJ+gsChv/SN/2gC36N6dL79Tio26ELbInRuEppLFZkaoeDHB7 tjtmV9+aF6fLbhdM8gGKn2ReXScd+fUVUUJm1s5pWNxFcAHG1PS8Nbccs 0=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AMfxdLBSCVEQDf197AcPlyGtUddpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQ5FcFaXVls13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmFAARoh5e/5BdJa1mhBVQBWwrLSA?= =?us-ascii?q?ECyqHVQOLBk6CEZgOglIDVAIHAQEBCQMBARgLCgIBAYRAAoF+JDgTAgMNAQE?= =?us-ascii?q?EAQEBAgEFBG2FNwELhV4BAQEBAwEBEC4BASwMCwQCAQgRBAEBLwIlCx0IAgQ?= =?us-ascii?q?TCAYUgwWBfU0DHw8BAgygGAKBOIhhgieCfgEBBYEzAg5BgxkYggUHCYE2gVO?= =?us-ascii?q?DSYZ8GoFBP4ERR4JMPoJkAQECAQEYgUkVgyuCLI4IiSKYGAqCOINlgjiBH48?= =?us-ascii?q?Ngkd4hwuQJI5biFySHAIEAgQFAg4BAQWBaSKBWHAVGiGCbAlHGA2IEhKDUIU?= =?us-ascii?q?UhT90gSiLWgEB?= X-IronPort-AV: E=Sophos;i="5.70,321,1574121600"; d="p7s'?scan'208";a="405192158" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2020 05:25:06 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 00F5P3Sm013674 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Jan 2020 05:25:05 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 Jan 2020 23:24:56 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 Jan 2020 23:24:54 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 14 Jan 2020 23:24:54 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZiXNduaMq50bu/2hYE+55yfnEWMBNpinUvNcU0+8jaitijaye0N75ESWf/mRznW+cEJ4VxXiCjxDDTKSNygpUEh45H1N6+NNAX6fxchgAd7Qk9yGCPSMRFtItUohgtAoIkheBdvJhyl3aFzQBE/XI0ypeUqB1HHmWb8V+AMy5pc5xihvsgCcWEcdNJ6YfsnI07Sf/wLeseYe7F5e/tZvpc6RFc9/PEByxu/WN+YZ/78DapLmzsf8mykcygp3C+UF/GZ8wfUddZf2HyiM5stvGMnsPQEd7yPkYRXTmU1KwrnS1OKlc+xdsK7URDQ9dAI/J5v10DQdn9AfBk1z5VtH/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mE0yKXciVIg4looiUnR3Tx6R5QHbRmDlKEvdAUi8Xp4=; b=Ntqjr5QgWVwwlPUpvFFYrYDcSApSJczRxaLDSwbNsumRjjznCofTzknWlGAHCxfQeeECx8p/EL1+1YJUXDE1253Y8akFszhpuriIM/ozFhurpA41HQjApzsbhr6Qe/YmJNBvR4KFG6hwtoj+FA/KOaGhTqqsL6cniRsDDJczsrUt3o8u6JDdsGlW+boGyZmtEw/aevpjbmPfiEG/DJZOWN6z4cHZR8cGdJezAKEBnHJmhJMerWw9I30XhaW+9DcWjgdfNqauqfAHaNZ/5DE2Fscdq0we8QtNl1IjA9YgqWkLkeRvZSsFDA2cnrVjyI1OUfmBuPbY4a2jtMMc4iw0mA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mE0yKXciVIg4looiUnR3Tx6R5QHbRmDlKEvdAUi8Xp4=; b=U4YznOwZWVeoem/ZIfL2pioeTg7dQLqEM/zlqW7AcUSHpoym3im2U7qcDWs5noi5QMOXZIScARSG5oqSKYxNkR8vtDsIACusVOfHiKM5EmF24jbDQZy+e4UkA0GsKYID5X+XAATtwh1V8p6RXbUNiH6Lx0OeTxyC2AKWJ/Bh3sE= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2545.namprd11.prod.outlook.com (52.135.244.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Wed, 15 Jan 2020 05:24:53 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2623.018; Wed, 15 Jan 2020 05:24:53 +0000 From: "Panos Kampanakis (pkampana)" To: "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-11.txt Thread-Index: AQHVy2M6oJu51FtC40OIkr5wZ0wV9KfrMCGg Date: Wed, 15 Jan 2020 05:24:53 +0000 Message-ID: References: <157906540345.11743.14247555047270819801@ietfa.amsl.com> In-Reply-To: <157906540345.11743.14247555047270819801@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1005::39c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 65402d14-fce8-4685-584f-08d7997b4057 x-ms-traffictypediagnostic: BN7PR11MB2545: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(346002)(376002)(366004)(189003)(199004)(81166006)(6916009)(316002)(8676002)(33656002)(8936002)(81156014)(966005)(7696005)(2906002)(55016002)(86362001)(6506007)(53546011)(71200400001)(52536014)(9686003)(66574012)(5660300002)(66616009)(66476007)(64756008)(66446008)(478600001)(66556008)(66946007)(76116006)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2545; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i6ydW0eG591QtP35o10Dq9fuZOripZ4p4FLD/r7vLWa/htKdMJfIPIZQTee60NQP4uCpGGv3Ow+xLjhrsFMBQDxkOI+nPiCiHa+O4YOjxBbSnGx1KMSPzqnbKAyFDfMYw4Le/6frsyJHSlxogkFSxaze8m6kCzk7c07ZcURq1Qm3uOqAEqjn3B2u16hpbZ+VywcNpSvUgDdMPpCuMGlW2Nn+FIV4ipdcx0OMBKNRI9Ooj3CLzTJ2TmXDJKo5dsE54zONokabvuNOUABaPfhNU7lC7+/mL55TSUE6Vb+t9zGrRHlDqaQWZLOZiQ72p/BHun3wsqCoY98f+6t7OTSubohecmKh47PYSjr+kZq4o49GNTcF6me1ZgYjh3aFIDrPhu3iQ8FmmXz3LeSv+weF2OCIiS4/T33300+YTNd6DeOF3wFdc/utQ6wBiSupx3XUsBhd+irPonVGY1J4bzoyibe0UYWfFfMyB8RY0Wld0PQ= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_003F_01D5CB3A.34333310" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 65402d14-fce8-4685-584f-08d7997b4057 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 05:24:53.3738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4nOTaNPrbfCFMDDaedSK8pKZgQoBU2uOXPfWyRq+AUNTL5bPLKdLOaAXTWIyZuv2RZg57RulT2NRLYGOPndwaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2545 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 05:25:19 -0000 ------=_NextPart_000_003F_01D5CB3A.34333310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, This iteration addresses all feedback received in the IESG Review. Thanks to Alissa, Adam, Barry, Alexey, Mijra, Roman, Martin and Eric for their reviews. Rgs, Panos -----Original Message----- From: IPsec On Behalf Of internet-drafts@ietf.org Sent: Wednesday, January 15, 2020 12:17 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Mixing Preshared Keys in IKEv2 for Post-quantum Security Authors : Scott Fluhrer Panos Kampanakis David McGrew Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-11.txt Pages : 20 Date : 2020-01-14 Abstract: The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-11 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_003F_01D5CB3A.34333310 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTE1MDUyNDUyWjAvBgkqhkiG9w0BCQQxIgQgJ/0MFGVw3i376xJEI8d9xmOGlG90h1zW AQJPX+sEzP0wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA fLn+LZvDGpA4R6HhzFIGnGuj8zQVlri547TPWsENHHNWXeV7r8vzWeirJzvAxMb4MKjzIwQHcQC3 4qVkkOzBKbUoTxH6+A27NEHB63Gx4hsaswC7UnnWA6PBVqUWrrkMcW7/PpcOnfECjxuMwxsB3Zu6 c4YkpPXYndtaezInjN0+asKPLOA1QhbljEXxrlXdtaubAWXu9/ERSRxpaqBMb1NXfDK9/hf0tnJK fkVXsrZiUjBroo2r9UJNNfWJkVZnCJLmg955E5i2B7V/13eh/22vcUMG4rT/jIFHUGpJbNGqLAOF dJRq5fBLIFDbj6pbTUW5SzEyLhrHvjlaP84lDQAAAAAAAA== ------=_NextPart_000_003F_01D5CB3A.34333310-- From nobody Thu Jan 16 14:26:14 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF39F12004A; Thu, 16 Jan 2020 14:26:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Cc: David Waltermire , The IESG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org, david.waltermire@nist.gov, rfc-editor@rfc-editor.org, kaduk@mit.edu Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157921356384.26135.4240143873642577225.idtracker@ietfa.amsl.com> Date: Thu, 16 Jan 2020 14:26:03 -0800 Archived-At: Subject: [IPsec] Protocol Action: 'Mixing Preshared Keys in IKEv2 for Post-quantum Security' to Proposed Standard (draft-ietf-ipsecme-qr-ikev2-11.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 22:26:04 -0000 The IESG has approved the following document: - 'Mixing Preshared Keys in IKEv2 for Post-quantum Security' (draft-ietf-ipsecme-qr-ikev2-11.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ Technical Summary The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. Working Group Summary The document has been highly reviewed and discussed and presented during multiple meetings and through the mailing list. The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors, to include implementors. In addition to mailing list discussions, the draft has been presented and discussed during the 98 tru 102 IETF meetings. The draft has been supported by the participants in the room on various hums for the specific design decisions made in the document. Document Quality The document is supported by implementors, and authors also represent a subset of implementors. Interoperability has been confirmed by at least four independent implementations from Cisco, Apple, libreswan and ELVIS-PLUS. There likely additional implementations that the WG are not aware of at this time. Personnel David Waltermire is the document shepherd and Benjamin Kaduk is the responsible AD. RFC Editor Note In Section 6, please make the change: OLD exchange immediately. Instead it waits for more response messages retransmitting the request as if no responses were received at all, until either the received message contains the USE_PPK or the exchange times out (see section 2.4 of [RFC7296] for more details about retransmission timers in IKEv2). If neither of the received responses contains USE_PPK, then the exchange is aborted. NEW exchange immediately. Instead it waits for more response messages, retransmitting the request as if no responses were received at all, until either the received message contains USE_PPK or the exchange times out (see section 2.4 of [RFC7296] for more details about retransmission timers in IKEv2). If none of the received responses contain USE_PPK, then the exchange is aborted. From nobody Thu Jan 23 02:54:53 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51695120024; Thu, 23 Jan 2020 02:54:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157977689129.22798.16473678731120701517.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2020 02:54:51 -0800 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 107 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 10:54:51 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: acme i2nsf Technology Overlap: curdle tls saag cfrg tcpm lake Key Participant Conflict: uta 6lo 6tisch lwig ace People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jan 23 12:59:13 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C72C1200CD; Thu, 23 Jan 2020 12:59:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157981315136.22794.2248069210939923708.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2020 12:59:11 -0800 Archived-At: Subject: [IPsec] ipsecme - Update to a Meeting Session Request for IETF 107 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 20:59:12 -0000 An update to a meeting session request has just been submitted by Yoav Nir, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Yoav Nir Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: acme i2nsf tls Technology Overlap: tcpm curdle saag cfrg lake Key Participant Conflict: uta 6lo 6tisch lwig ace People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: ---------------------------------------------------------