From nobody Mon Oct 5 05:16:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3191AC425 for ; Mon, 5 Oct 2015 05:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 8j2Zlp1qEjEJ for ; Mon, 5 Oct 2015 05:16:09 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738471AC422 for ; Mon, 5 Oct 2015 05:16:09 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-f4-56120a431349 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 54.47.32596.34A02165; Mon, 5 Oct 2015 07:27:31 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 08:16:07 -0400 From: Daniel Migault To: Michael Richardson , Yoav Nir Thread-Topic: [IPsec] RFC4307 update Thread-Index: AQHQ+e8o8QBswXZNPk2wGpoCC0p1n55SW9cAgAAbMgCAACNMAIAKQAZw Date: Mon, 5 Oct 2015 12:16:06 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11216BB62@eusaamb107.ericsson.se> References: <22025.15464.790587.801082@fireball.acr.fi> <23473.1443455828@sandelman.ca> <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> <15982.1443469248@sandelman.ca> In-Reply-To: <15982.1443469248@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPrK4zl1CYwds2dYv9W16wWfQc6me3 WHrsA5MDs8fOWXfZPZYs+cnk0TJnD3MAcxSXTUpqTmZZapG+XQJXxuFj3UwF88QqNv7exNrA eEW0i5GTQ0LARGJR2w82CFtM4sK99UA2F4eQwFFGidZXm9khnGWMEp+7PjCDVLEJGEm0AS0F sUUE/CRmzT0C1s0soCpxd/9UVhBbWEBZYuHSZcwQNSoSk/ctg6p3k9j26w9YPQtQvGfrdqA4 BwevgK/EzHYBiF3rGCXuTjzLBFLDKaAj8WviLLA5jEDXfT+1hglil7jErSfzmSCuFpBYsuc8 M4QtKvHy8T9WCFtJYtLSc6wg85kFNCXW79KHaFWUmNL9EOwcXgFBiZMzn7BMYBSbhWTqLISO WUg6ZiHpWMDIsoqRo7Q4tSw33chgEyMwbo5JsOnuYNzz0vIQowAHoxIP7wMDwTAh1sSy4src Q4zSHCxK4rz7l9wPFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDYXsj5c1X5LIb4yfc6NcoE k3W36PAW1NryK8r/fR76onB/s4fvf29Vrn7W/FlGnBfFnku8u96xS/ybyN24r8s2HhHddJ1l UhbXQ7aJoSuPGjHu6mczPcp1gvlJiqQ63wNn6T8Tl1xsDd4vGdm631AtR/PPzcPrAh5LPNFc F3yVw53Vep56ULYSS3FGoqEWc1FxIgBjdDX6fAIAAA== Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 12:16:11 -0000 SGksIA0KDQpUaGVyZSBpcyBhIG5lZWQgdG8gaGF2ZSB0aGF0IGtpbmQgb2YgZG9jdW1lbnQgZm9y IDNHUFAvU0EzLiBVbmxlc3Mgc29tZW9uZSBoYXMgYWxyZWFkeSB3cml0dGVuIHRoZSB1cGRhdGUs IEkgY2FuIHByb3ZpZGUgb25lIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsuDQoNCkJSLCANCkRhbmll bCAgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSVBzZWMgW21haWx0bzpp cHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQpT ZW50OiBNb25kYXksIFNlcHRlbWJlciAyOCwgMjAxNSAzOjQxIFBNDQpUbzogWW9hdiBOaXINCkNj OiBpcHNlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJUHNlY10gUkZDNDMwNyB1cGRhdGUNCg0K DQpZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPj4gVGVybyBLaXZp bmVuIDxraXZpbmVuQGlraS5maT4gd3JvdGU6DQogICAgPj4+IFdlIGRpZCB1cGRhdGUgY3J5cHRv Z3JhcGhpYyBhbGdvcml0aG1zIGZvciBFU1AgYW5kIEFIDQogICAgPj4+IChSRkM0MzA1LT40ODM1 LT43MzIxKSwgYnV0IHdlIGhhdmUgbmV2ZXIgdXBkYXRlZCB0aGUgUkZDNDMwNy4NCiAgICA+Pg0K ICAgID4+PiBJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSB1cGRhdGUgZm9yIHRoYXQgZG9jdW1lbnQg dG9vLCBhcyBpdCBub3cNCiAgICA+Pj4gZGVmaW5lcyBmb2xsb3dpbmcgbWFkYW50b3J5IHRvIGlt cGxlbWVudCBhbGdvcml0aG1zOg0KICAgID4+DQogICAgPj4+IDEwMjQgTU9EUCBHcm91cCwgRU5D Ul8zREVTLCBQUkZfSE1BQ19TSEExLCBBVVRIX0hNQUNfU0hBMV85Ni4NCiAgICA+Pg0KICAgID4+ PiBBbmQgSSB0aGluayBhdCBsZWFzdCB0aGUgMTAyNC1iaXQgTU9EUCBncm91cHAsIGFuZCBwZXJo YXBzIHRoZSAzREVTDQogICAgPj4+IGFsc28gc2hvdWxkIGJlIGNoYW5nZWQgdG8gc29tZXRoaW5n IG1vcmUgc3VpdGFibGUuIEZvciBleG1wbGUNCiAgICA+Pj4gMjA0OC1iaXQgTU9EUCBncm91cCBh bmQgRU5DUl9BRVNfQ0JDLi4uDQogICAgPj4NCiAgICA+PiBJIGd1ZXNzIHRoZSBjYW4tby13b3Jt cyBjYWxsZWQgRUNEU0Egd2lsbCBzaG93IHVwIHRvbyBhcyBhIFNIT1VMRCsuDQoNCiAgICA+IERv ZXMgaXQgaGF2ZSB0bz8gNDMwNyBkb2VzIG5vdCBtZW50aW9uIGFueSBzaWduYXR1cmUgYWxnb3Jp dGhtcy4gRUNESA0KICAgID4gd2l0aCBOSVNUIGN1cnZlcyBhbmQvb3IgdGhlIG5ldyBjdXJ2ZXMg bWlnaHQgc2hvdWxkIG1ha2UgYW4gYXBwZWFyYW5jZS4NCg0KU29ycnksIHRoYXQncyB3aGF0IEkg bWVhbnQgdG8gd3JpdGUsIGJ1dCBteSBmaW5nZXIgc2xpcHBlZC4NCg0KICAgID4+IERvZXMgM0RF UyBnbyB0byBNQVk/DQoNCiAgICA+IEkgdGhpbmsgc28uDQoNCiAgICA+PiBEb2VzIFNIQTEgZ28g dG8gTVVTVC0/DQogICAgPj4NCiAgICA+PiBXZSBoYWRuJ3QgbGlzdGVkIFNIQTIgYXQgYWxsIGJl Zm9yZS4gIFdlIGFsc28gaGF2ZSBubyBHQ00vQ0NNIHRoaW5ncw0KICAgID4+IHNwZWNpZmllZC4N CiAgICA+Pg0KICAgID4+IEFyZSB3ZSBvYmxpZ3RlZCB0byBsaXN0IHRoZW0gYXMgU0hPVUxEKyBm b3IgYXdoaWxlPw0KDQogICAgPiBJIHRoaW5rIHdlIHNob3VsZCByZWZsZWN0IHdoYXQgaXMgY29t bW9uL2Jlc3QgcHJhY3RpY2Ugbm93LiBBRVMtR0NNIGlzDQogICAgPiBub3cgd2lkZWx5IGltcGxl bWVudGVkIGFuZCBmYXN0ZXIgdGhhbiB0aGUgY29tYmluYXRpb24gb2YgQUVTLUNCQyBhbmQNCiAg ICA+IEhNQUMtU0hBLXNvbWV0aGluZy4gSSB0aGluayBpdOKAmXMgYSBwcmltZSBjYW5kaWRhdGUg Zm9yIE1VU1QuIENUUiB3YXMNCiAgICA+IGFsd2F5cyB1bmNvbW1vbi4gQ2hhQ2hhMjArUG9seTEz MDUgaXMgc28gbmV3IHRoYXQgaXQgY2FuJ3QgYmUgTVVTVCB0aGlzDQogICAgPiBpdGVyYXRpb24u IE1heWJlIG5leHQgdGltZS4NCg0KQWdyZWVkLg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxt Y3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgIC09IElQdjYg SW9UIGNvbnN1bHRpbmcgPS0NCg0KDQoNCg== From nobody Wed Oct 7 07:17:52 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CDE1A92BC for ; Wed, 7 Oct 2015 07:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 6PxcvbCFfQ8q for ; Wed, 7 Oct 2015 07:17:38 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 D17781A92B2 for ; Wed, 7 Oct 2015 07:17:37 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t97EHRMP011428 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 7 Oct 2015 16:17:28 +0200 X-Hashcash: 1:22:151007:ipsec@ietf.org::pSl6OCURg4v+UTb3:2Q3f From: Simon Josefsson To: ipsec@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Wed, 07 Oct 2015 16:17:26 +0200 Message-ID: <87wpuyn4p5.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [IPsec] Please review draft-ietf-ipsecme-safecurves X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 14:17:40 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi. I haven't seen any comments on this document. If anyone has a few minutes, please read and comment on this draft: https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-00 As far as I know, there are no known open issues or even nits. Feedback From=20implementers is especially appreciated. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWFSl2AAoJEIYLf7sy+BGd3yEH/00tRxk8bb3jQMidf3spHFow msYpttESClYeRTjP61fIkbo7xmABUUi86TGTGZFfbo6pNCF5gTxqVGFiW+9c/vf2 nybPaSuZaAh6jYeoCk/5u+3JxNYrLyuBK36LV961WA5toDA/KQd097fMqsMvKlxx JlKfbk8D9F4bhh8kAo4GAhbS6/qv52rXQ0ERJUmvLKP7amFjOczqhV07qQT/db4V 3TFk/DV3KPw9Py2y+iG4K8wu07l34oNnDivfiUzPmKkNhAGHDXIIiS5sdkHvEgjh vo+2FLQXKOSuMQPxPMSHuNXpUtZpo8wAQ2g/bQYQ/W7tR2LMWx5Izs+IFlNK0vA= =Lkd1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 9 03:57:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FBF1B2AAE for ; Fri, 9 Oct 2015 03:57:27 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 YvK4f98M9E3P for ; Fri, 9 Oct 2015 03:57:22 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 07DE21B2AA1 for ; Fri, 9 Oct 2015 03:57:22 -0700 (PDT) Received: by wicge5 with SMTP id ge5so63050263wic.0 for ; Fri, 09 Oct 2015 03:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9ufqDPni4inWRlIlh+mVr3d3llJ6lOeTAyjo+tDdPpk=; b=N51UBg8pAMv+ssA2ZQsdNSl7vnCHAUmwgzjtsJ3j8st3B/5gDp4u9FWX+KY9zc7z9d HSfdA/K4LjY/0ErDl+bd5RsgcaQL9nvaqf3cZcNfPuGOufY6DUi8C25npeVgMTTJ4pzc c99iyW7HrHLKlH17k94b/bGPyIjnzFVWXCTW6sAykKDB2nbW8WaicErGm5gkefhCqWq9 HLJe0ymVO758yO516YnZOHILAlStL6UGs5xO+fHuzoHChnytj+qcMJNU2TmjdDTmKScW AAfILDkUVopE5bL1AsMQEO7HTCG5Qomuah3t79zHOIYd0cHfqD3ZwAG6wtdAUXpxxuPV GuAg== X-Received: by 10.180.87.138 with SMTP id ay10mr8922033wib.12.1444388240548; Fri, 09 Oct 2015 03:57:20 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id fr10sm11001680wib.14.2015.10.09.03.57.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Oct 2015 03:57:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: Date: Fri, 9 Oct 2015 13:57:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> To: IPsecME WG X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 10:57:27 -0000 > On Sep 28, 2015, at 6:10 PM, Paul Hoffman = wrote: >=20 > Sure. Someone volunteer to write up the short draft, and that author = should put Jeff Schiller at the top of the acknowledgements, and send it = to the WG. >=20 > --Paul Hoffman A new version of I-D, draft-nir-ipsecme-rfc4307bis-00.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Name: draft-nir-ipsecme-rfc4307bis Revision: 00 Title: Cryptographic Algorithms for Use in the Internet Key = Exchange Version 2 (IKEv2) Document date: 2015-10-09 Group: Individual Submission Pages: 6 URL: = https://www.ietf.org/internet-drafts/draft-nir-ipsecme-rfc4307bis-00.txt Status: = https://datatracker.ietf.org/doc/draft-nir-ipsecme-rfc4307bis/ Htmlized: = https://tools.ietf.org/html/draft-nir-ipsecme-rfc4307bis-00 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange protocol provides a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. From nobody Fri Oct 9 05:19:26 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227861B3A5C for ; Fri, 9 Oct 2015 05:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 T5zPC8gcvaeA for ; Fri, 9 Oct 2015 05:19:21 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20FE1B3A56 for ; Fri, 9 Oct 2015 05:19:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nXT3T5PQrz3LV; Fri, 9 Oct 2015 14:19:17 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Oskt8XKS X-OPENPGPKEY: Message passed unmodified 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 IEibVu8mHgO9; Fri, 9 Oct 2015 14:19:15 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 9 Oct 2015 14:19:15 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 083F380030; Fri, 9 Oct 2015 08:19:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444393154; bh=I0JRrcjtPwRR9reTywHep+2+Xz7v9e0N50sHsMTXix4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Oskt8XKSrbJiRRHUjoJZ9p2Z7Nc5FuO2Udj8bsK9iVPfjpAQzJpSlu5m+v0lwg1Fd lmB7mNfnxSR06uc7FxD8N5dn/HeJfJ9PeyhZwCHaWiiNxkkz9bLpUODcZOLHwCMLeQ OBFwFpAGpHI0Dp6huoY+Rl1RENCZRsTZ/K4JMn+Y= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t99CJD35001231; Fri, 9 Oct 2015 08:19:13 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 9 Oct 2015 08:19:13 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> Message-ID: References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-1311174527-1444392420=:429" Content-ID: Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 12:19:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1311174527-1444392420=:429 Content-Type: text/plain; CHARSET=US-ASCII; format=flowed Content-ID: On Fri, 9 Oct 2015, Yoav Nir wrote: >> On Sep 28, 2015, at 6:10 PM, Paul Hoffman wrote: >> >> Sure. Someone volunteer to write up the short draft, and that author should put Jeff Schiller at the top of the acknowledgements, and send it to the WG. >> >> --Paul Hoffman > > > A new version of I-D, draft-nir-ipsecme-rfc4307bis-00.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. Oops. Guess our drafts crossed the beams. I had send one to Daniel to look at. I've attached it in case some text is useful. It was based more on the structure of RFC 7321. I actually like how 7321 has the tables filled with links to the actual RFC's. (which I had not done yet myself) Some comments on your text: I think AES_CBC should be MUST- as it is on the way out. I have talked with one of the AES_GCM authors and got the advise to only use the largest octet ICV's. Why are you promoting the 8 octet version instead of the 16 octet version? I also think AES_GCM should be a MUST, not a SHOULD. It is the preferred algorithm at this point. I also think 3DES probably should be a SHOULD- because it is the only other non-AES algorithm in widespread use. While we all want it to go away, we should do so only after chacha20-poly1305 sees more adoption. Why is sha2-512 not a SHOULD? Can we add a recommendation to use integ == prf for non-AEAD algorithms? Windows uses 8192 modp, which I think should be a SHOULD. I think we should mention modp 1536 as SHOULD- or MAY. Can we recommend that the initial exchanges and create child sa use the same MODP group? and that we recommend PFS for create_child_sa. Can we recommend that a default proposal set should have at least one MUST algorithm for each type? Can we recommend not to apply these recommendations for IKEv1 because that will cause more interop problems (see my draft for text) Paul --8323328-1311174527-1444392420=:429 Content-Type: text/xml; NAME=draft-ikev2-algorithm-update-00.xml Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=draft-ikev2-algorithm-update-00.xml PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCg0KPCFE T0NUWVBFIHJmYyBTWVNURU0gInJmYzI2MjkuZHRkIiBbDQo8IUVOVElUWSBy ZmMyMTE5IFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yMTE5LnhtbCI+DQo8 IUVOVElUWSByZmMyNDA1IFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMu aWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yNDA1 LnhtbCI+DQo8IUVOVElUWSByZmMyNDA5IFNZU1RFTSAiaHR0cDovL3htbDJy ZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNl LlJGQy4yNDA5LnhtbCI+DQo8IUVOVElUWSByZmMzNTI2IFNZU1RFTSAiaHR0 cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwv cmVmZXJlbmNlLlJGQy4zNTI2LnhtbCI+DQo8IUVOVElUWSByZmM0MTA2IFNZ U1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40MTA2LnhtbCI+DQo8IUVOVElUWSBy ZmM0NDk0IFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40NDk0LnhtbCI+DQo8 IUVOVElUWSByZmM0NTQzIFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMu aWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40NTQz LnhtbCI+DQo8IUVOVElUWSByZmM0ODY4IFNZU1RFTSAiaHR0cDovL3htbDJy ZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNl LlJGQy40ODY4LnhtbCI+DQo8IUVOVElUWSByZmM1MTE0IFNZU1RFTSAiaHR0 cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwv cmVmZXJlbmNlLlJGQy41MTE0LnhtbCI+DQo8IUVOVElUWSByZmM1MTE2IFNZ U1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41MTE2LnhtbCI+DQo8IUVOVElUWSBy ZmM1MjgyIFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41MjgyLnhtbCI+DQo8 IUVOVElUWSByZmM1NzM5IFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMu aWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41NzM5 LnhtbCI+DQo8IUVOVElUWSByZmM1OTAzIFNZU1RFTSAiaHR0cDovL3htbDJy ZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNl LlJGQy41OTAzLnhtbCI+DQo8IUVOVElUWSByZmM1OTMwIFNZU1RFTSAiaHR0 cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwv cmVmZXJlbmNlLlJGQy41OTMwLnhtbCI+DQo8IUVOVElUWSByZmM3Mjk2IFNZ U1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy43Mjk2LnhtbCI+DQo8IUVOVElUWSBy ZmM3MzIxIFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy43MzIxLnhtbCI+DQo8 IUVOVElUWSByZmM3NjM0IFNZU1RFTSAiaHR0cDovL3htbDJyZmMudG9vbHMu aWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy43NjM0 LnhtbCI+DQpdPg0KDQo8cmZjIGNhdGVnb3J5PSJzdGQiIGlwcj0idHJ1c3Qy MDA5MDIiIGRvY05hbWU9ImRyYWZ0LWlrZXYyLWFsZ29yaXRobS11cGRhdGUt MDAiPg0KDQo8P3htbC1zdHlsZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVm PSdyZmMyNjI5LnhzbHQnID8+DQoNCjw/cmZjIHRvYz0ieWVzIiA/Pg0KPD9y ZmMgc3ltcmVmcz0ieWVzIiA/Pg0KPD9yZmMgc29ydHJlZnM9Im5vIj8+DQo8 P3JmYyBpcHJub3RpZmllZD0ibm8iID8+DQo8P3JmYyBzdHJpY3Q9InllcyIg Pz4NCg0KICAgIDxmcm9udD4NCiAgICAgICAgPHRpdGxlIGFiYnJldj0iaWtl djIgYWxnbyB1cGRhdGUiPkNyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIEltcGxl bWVudGF0aW9uIFJlcXVpcmVtZW50cyBhbmQgVXNhZ2UgR3VpZGFuY2UgZm9y IElLRXYyPC90aXRsZT4NCiAgICAgICAgPGF1dGhvciBpbml0aWFscz0nUC4n IHN1cm5hbWU9IldvdXRlcnMiIGZ1bGxuYW1lPSdQYXVsIFdvdXRlcnMnPg0K ICAgICAgICAgICAgPG9yZ2FuaXphdGlvbj5SZWQgSGF0PC9vcmdhbml6YXRp b24+DQogICAgICAgICAgICA8YWRkcmVzcz4NCiAgICAgICAgICAgICAgICA8 ZW1haWw+cHdvdXRlcnNAcmVkaGF0LmNvbTwvZW1haWw+DQogICAgICAgICAg ICA8L2FkZHJlc3M+DQogICAgICAgIDwvYXV0aG9yPg0KICAgICAgICA8YXV0 aG9yIGluaXRpYWxzPSdELicgc3VybmFtZT0iTWlnYXVsdCIgZnVsbG5hbWU9 J0RhbmllbCBNaWdhdWx0Jz4NCiAgICAgICAgICAgIDxvcmdhbml6YXRpb24+ RXJpY3Nzb248L29yZ2FuaXphdGlvbj4NCiAgICAgICAgICAgIDxhZGRyZXNz Pg0KICAgICAgICAgICAgICAgIDxlbWFpbD5kYW5pZWwubWlnYXVsdEBlcmlj c3Nvbi5jb208L2VtYWlsPg0KICAgICAgICAgICAgPC9hZGRyZXNzPg0KICAg ICAgICA8L2F1dGhvcj4NCiAgICAgICAgPGRhdGUvPg0KICAgICAgICA8YWJz dHJhY3Q+DQogICAgICAgIDx0Pg0KICAgICAgICBUaGlzIGRvY3VtZW50IHVw ZGF0ZXMgdGhlIENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIEltcGxlbWVudGF0 aW9uDQogICAgICAgIFJlcXVpcmVtZW50cyBmb3IgdGhlIEludGVybmV0IEtl eWluZyBFeGNoYW5nZSBwcm90b2NvbCB2ZXJzaW9uIDIgKElLRXYyKS4NCiAg ICAgICAgSXQgYWxzbyBhZGRzIHVzYWdlIGd1aWRhbmNlIHRvIGhlbHAgaW4g dGhlIHNlbGVjdGlvbiBvZiB0aGVzZSBhbGdvcml0aG1zLg0KICAgICAgICA8 L3Q+DQogICAgICAgIDx0Pg0KICAgICAgICBUaGUgSUtFdjIgcHJvdG9jb2wg bWFrZXMgdXNlIG9mIHZhcmlvdXMgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1z IHRvDQogICAgICAgIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IGFuZC9vciBk YXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbiBiZWZvcmUNCiAgICAgICAgYWdy ZWVpbmcgb24ga2V5aW5nIG1hdGVyaWFsIGZvciB1c2Ugd2l0aCBJUCBTZWN1 cml0eSAoSVBzZWMpDQogICAgICAgIFRvIGVuc3VyZSBpbnRlcm9wZXJhYmls aXR5IGJldHdlZW4gZGlzcGFyYXRlIGltcGxlbWVudGF0aW9ucywNCiAgICAg ICAgdGhlIElLRXYyIHN0YW5kYXJkIHNwZWNpZmllcyBhIHNldCBvZiBtYW5k YXRvcnktdG8tDQogICAgICAgIGltcGxlbWVudCBhbGdvcml0aG1zLiAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGN1cnJlbnQgc2V0IG9mDQogICAg ICAgIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgYWxnb3JpdGhtcyBmb3IgSUtF djIsIHNwZWNpZmllcw0KICAgICAgICBhbGdvcml0aG1zIHRoYXQgc2hvdWxk IGJlIGltcGxlbWVudGVkIGJlY2F1c2UgdGhleSBtYXkgYmUgcHJvbW90ZWQg dG8NCiAgICAgICAgbWFuZGF0b3J5IGF0IHNvbWUgZnV0dXJlIHRpbWUsIGFu ZCBhbHNvIHJlY29tbWVuZHMgYWdhaW5zdCB0aGUNCiAgICAgICAgaW1wbGVt ZW50YXRpb24gb2Ygc29tZSBvYnNvbGV0ZSBhbGdvcml0aG1zLiAgVXNhZ2Ug Z3VpZGFuY2UgaXMgYWxzbw0KICAgICAgICBwcm92aWRlZCB0byBoZWxwIHRo ZSB1c2VyIG9mIElLRXYyIGJlc3QgYWNoaWV2ZSB0aGVpciBzZWN1cml0eQ0K ICAgICAgICBnb2FscyB0aHJvdWdoIGFwcHJvcHJpYXRlIGNob2ljZXMgb2Yg Y3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zLg0KICAgICAgICA8L3Q+DQogICAg ICAgIDx0Pg0KICAgICAgICBXaGlsZSB0aGUgcmVjb21tZW5kYXRpb25zIGZv ciB0aGlzIGRvY3VtZW50IHdvdWxkIGVxdWFsbHkgYXBwbHkgdG8gSUtFdjEN CiAgICAgICAgPHhyZWYgdGFyZ2V0PSJSRkMyNDA5Ii8+LCBubyBzdWdnZXN0 aW9ucyBhcmUgbWFkZSB0byB1cGRhdGUgSUtFdjEuIE1vc3QNCiAgICAgICAg SUtFdjEgaW1wbGVtZW50YXRpb25zIGF0IHRoaXMgdGltZSBhcmUgZnJvemVu IGFuZCB2ZW5kb3JzIHdpbGwgbm90IGJlIGFibGUNCiAgICAgICAgdG8gdXBk YXRlIHRoZSByZWNvbW1lbmRlZCBhbGdvcml0aG1zIGluIHN1Y2ggaW1wbGVt ZW50YXRpb25zLiBVcGRhdGluZyB0aGUNCiAgICAgICAgSUtFdjEgc3BlY2lm aWNhdGlvbiB3b3VsZCB0aGVyZWZvciBsZWFkIHRvIGluY3JlYXNlZCBpbnRl cm9wZXJhYmlsaXR5IGlzc3Vlcy4NCiAgICAgICAgSUtFdjEgZGVwbG95bWVu dHMgYXJlIGVuY291cmFnZWQgdG8gdXBncmFkZSB0byBJS0V2Mi4NCiAgICAg ICAgPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgVGhpcyBkb2N1bWVudCB1 cGRhdGVzIFJGQyA3Mjk2Lg0KICAgICAgICA8L3Q+DQogICAgICAgIDwvYWJz dHJhY3Q+DQogICAgPC9mcm9udD4NCg0KICAgIDxtaWRkbGU+DQogICAgIDxz ZWN0aW9uIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPg0KICAgICAgPHQ+DQogICAg ICBUaGUgSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIFByb3RvY29sIHZlcnNpb24g MiAoSUtFdjIpLCBzcGVjaWZpZWQgaW4NCiAgICAgIDx4cmVmIHRhcmdldD0i UkZDNzI5NiIvPiwgcHJvdmlkZXMgYSB3YXkgZm9yIHR3byBwYXJ0aWVzIHRv IHBlcmZvcm0NCiAgICAgIGFuIGF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdl Lg0KICAgICAgPC90Pg0KICAgICAgPHQ+DQogICAgICBUbyBlbnN1cmUgaW50 ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpc3BhcmF0ZSBpbXBsZW1lbnRhdGlv bnMsIGl0IGlzDQogICAgICBuZWNlc3NhcnkgdG8gc3BlY2lmeSBhIHNldCBv ZiBtYW5kYXRvcnktdG8taW1wbGVtZW50IGFsZ29yaXRobXMuDQogICAgICBU aGlzIGVuc3VyZXMgdGhhdCB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgYWxnb3Jp dGhtIHRoYXQgYWxsDQogICAgICBpbXBsZW1lbnRhdGlvbnMgd2lsbCBoYXZl IGluIGNvbW1vbi4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZQ0KICAg ICAgY3VycmVudCBzZXQgb2YgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBhbGdv cml0aG1zIGZvciBJS0V2MiwNCiAgICAgIHNwZWNpZmllcyBhbGdvcml0aG1z IHRoYXQgc2hvdWxkIGJlIGltcGxlbWVudGVkIGJlY2F1c2UgdGhleSBtYXkg YmUNCiAgICAgIHByb21vdGVkIHRvIG1hbmRhdG9yeSBhdCBzb21lIGZ1dHVy ZSB0aW1lLCBhbmQgYWxzbyByZWNvbW1lbmRzDQogICAgICBhZ2FpbnN0IHRo ZSBpbXBsZW1lbnRhdGlvbiBvZiBzb21lIG9ic29sZXRlIGFsZ29yaXRobXMu ICBVc2FnZQ0KICAgICAgZ3VpZGFuY2UgaXMgYWxzbyBwcm92aWRlZCB0byBo ZWxwIHRoZSB1c2VyIG9mIElLRXYyIGJlc3QgYWNoaWV2ZQ0KICAgICAgdGhl aXIgc2VjdXJpdHkgZ29hbHMgdGhyb3VnaCBhcHByb3ByaWF0ZSBjaG9pY2Vz IG9mIG1lY2hhbmlzbXMuDQogICAgICA8L3Q+DQogICAgICA8dD4NCiAgICAg IFRoZSBuYXR1cmUgb2YgY3J5cHRvZ3JhcGh5IGlzIHRoYXQgbmV3IGFsZ29y aXRobXMgc3VyZmFjZQ0KICAgICAgY29udGludW91c2x5IGFuZCBleGlzdGlu ZyBhbGdvcml0aG1zIGFyZSBjb250aW51b3VzbHkgYXR0YWNrZWQuICBBbg0K ICAgICAgYWxnb3JpdGhtIGJlbGlldmVkIHRvIGJlIHN0cm9uZyB0b2RheSBt YXkgYmUgZGVtb25zdHJhdGVkIHRvIGJlIHdlYWsNCiAgICAgIHRvbW9ycm93 LiAgR2l2ZW4gdGhpcywgdGhlIGNob2ljZSBvZiBtYW5kYXRvcnktdG8taW1w bGVtZW50IGFsZ29yaXRobQ0KICAgICAgc2hvdWxkIGJlIGNvbnNlcnZhdGl2 ZSBzbyBhcyB0byBtaW5pbWl6ZSB0aGUgbGlrZWxpaG9vZCBvZiBpdCBiZWlu Zw0KICAgICAgY29tcHJvbWlzZWQgcXVpY2tseS4gIFRob3VnaHQgc2hvdWxk IGFsc28gYmUgZ2l2ZW4gdG8gcGVyZm9ybWFuY2UNCiAgICAgIGNvbnNpZGVy YXRpb25zLCBhcyBtYW55IHVzZXMgb2YgSUtFdjIgd2lsbCBiZSBpbiBlbnZp cm9ubWVudHMgd2hlcmUNCiAgICAgIHBlcmZvcm1hbmNlIGlzIGEgY29uY2Vy bi4NCiAgICAgIDwvdD4NCiAgICAgIDx0Pg0KICAgICAgVGhlIElLRXYyIG1h bmRhdG9yeS10by1pbXBsZW1lbnQgYWxnb3JpdGhtKHMpIG1heSBuZWVkIHRv IGNoYW5nZQ0KICAgICAgb3ZlciB0aW1lIHRvIGFkYXB0IHRvIG5ldyBkZXZl bG9wbWVudHMgaW4gY3J5cHRvZ3JhcGh5LiAgRm9yIHRoaXMNCiAgICAgIHJl YXNvbiwgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIG1hbmRhdG9yeS10by1p bXBsZW1lbnQgYWxnb3JpdGhtcyBpcw0KICAgICAgbm90IGluY2x1ZGVkIGlu IHRoZSBtYWluIElLRSBzcGVjaWZpY2F0aW9ucywgYnV0IGlzDQogICAgICBp bnN0ZWFkIHBsYWNlZCBpbiB0aGlzIGRvY3VtZW50LiAgSWRlYWxseSwgdGhl IG1hbmRhdG9yeS10by1pbXBsZW1lbnQNCiAgICAgIGFsZ29yaXRobSBvZiB0 b21vcnJvdyBzaG91bGQgYWxyZWFkeSBiZSBhdmFpbGFibGUgaW4gbW9zdA0K ICAgICAgaW1wbGVtZW50YXRpb25zIG9mIElLRSBieSB0aGUgdGltZSBpdCBp cyBtYWRlIG1hbmRhdG9yeS4gIFRvDQogICAgICBmYWNpbGl0YXRlIHRoaXMs IHRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyBzdWNoIGFsZ29yaXRobXMsIGFz IHRoZXkNCiAgICAgIGFyZSBrbm93biB0b2RheS4gIFRoZXJlIGlzIG5vIGd1 YXJhbnRlZSB0aGF0IHRoZSBhbGdvcml0aG1zIHRoYXQgd2UNCiAgICAgIHBy ZWRpY3Qgd2lsbCBiZSBtYW5kYXRvcnkgaW4gdGhlIGZ1dHVyZSB3aWxsIGFj dHVhbGx5IGJlIHNvLiAgQWxsDQogICAgICBhbGdvcml0aG1zIGtub3duIHRv ZGF5IGFyZSBzdWJqZWN0IHRvIGNyeXB0b2dyYXBoaWMgYXR0YWNrIGFuZCBt YXkgYmUNCiAgICAgIGJyb2tlbiBpbiB0aGUgZnV0dXJlLg0KICAgICAgPC90 Pg0KICAgICAgIDxzZWN0aW9uIHRpdGxlPSJDb252ZW50aW9ucyBVc2VkIGlu IFRoaXMgRG9jdW1lbnQiPg0KICAgICAgICA8dD4NCiAgICAgICAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLA0KICAgICAgICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcw0KICAgICAgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMjExOSIvPi4NCiAg ICAgICAgPC90Pg0KICAgICAgPC9zZWN0aW9uPg0KICAgICA8L3NlY3Rpb24+ DQoNCiAgICAgPHNlY3Rpb24gdGl0bGU9IkltcGxlbWVudGF0aW9uIFJlcXVp cmVtZW50cyI+DQogICAgIDx0Pg0KICAgICBUaGlzIHNlY3Rpb24gc3BlY2lm aWVzIHRoZSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgdGhhdCBNVVNUIGJl DQogICAgIGltcGxlbWVudGVkLCBhbmQgcHJvdmlkZXMgZ3VpZGFuY2UgYWJv dXQgb25lcyB0aGF0IFNIT1VMRCBvciBTSE9VTEQNCiAgICAgTk9UIGJlIGlt cGxlbWVudGVkLg0KICAgICA8L3Q+DQogICAgIDx0Pg0KICAgICBJbiB0aGUg Zm9sbG93aW5nIHNlY3Rpb25zLCBhbGwgQUVTIG1vZGVzIGFyZSBmb3IgMTI4 LWJpdCBBRVMuIDE5Mi1iaXQNCiAgICAgYW5kIDI1Ni1iaXQgQUVTIE1BWSBi ZSBzdXBwb3J0ZWQgZm9yIHRob3NlIG1vZGVzLCBidXQgdGhlIHJlcXVpcmVt ZW50cw0KICAgICBoZXJlIGFyZSBmb3IgMTI4LWJpdCBBRVMuDQogICAgIDwv dD4NCiAgICAgICA8c2VjdGlvbiB0aXRsZT0iSUtFIENvbWJpbmVkIE1vZGUg QWxnb3JpdGhtcyI+DQogICAgICAgPHQ+DQogICAgICAgSUtFIENvbWJpbmVk IG1vZGUgYWxnb3JpdGhtcyBwcm92aWRlIGJvdGggY29uZmlkZW50aWFsaXR5 IGFuZCBhdXRoZW50aWNhdGlvbg0KICAgICAgIHNlcnZpY2VzOyBpbiBjcnlw dG9ncmFwaGljIHRlcm1zLCB0aGVzZSBhcmUgYXV0aGVudGljYXRlZCBlbmNy eXB0aW9uDQogICAgICAgYWxnb3JpdGhtcyA8eHJlZiB0YXJnZXQ9IlJGQzUx MTYiLz4uIEF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbiB0cmFuc2Zvcm1zDQog ICAgICAgYXJlIGxpc3RlZCBpbiB0aGUgRVNQIGVuY3J5cHRpb24gdHJhbnNm b3JtcyBJQU5BIHJlZ2lzdHJ5Lg0KICAgICAgIDwvdD4NCiAgICAgICA8dD4N CiAgICAgICBXaGVyZSBtdWx0aXBsZSBvY3RldCBzaXplcyBmb3IgSUNWJ3Mg YXJlIGRlZmluZWQsIG9ubHkgdGhlIGxhcmdlc3QgSUNWIHNpemUNCiAgICAg ICBzaG91bGQgYmUgdXNlZC4NCiAgICAgICA8L3Q+DQogICAgICAgPHQ+DQog ICAgICAgICAgIDxmaWd1cmUgYWxpZ249ImNlbnRlciI+DQogICAgICAgICAg ICAgICAgPGFydHdvcmsgYWxpZ249ImxlZnQiPjwhW0NEQVRBWw0KUmVxdWly ZW1lbnQgICAgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIEFsZ29yaXRobQ0K LS0tLS0tLS0tLS0gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KTVVTVCAgICAgICAgICAgQUVTLUdDTSB3aXRoIGEgMTYgb2N0ZXQg SUNWIFtSRkM1MjgyXQ0KU0hPVUxEKyAgICAgICAgQ0hBQ0hBMjBfUE9MWTEz MDUgW1JGQzc2MzRdDQpNQVkgICAgICAgICAgICBBRVMtQ0NNICB3aXRoIGEg MTYgb2N0ZXQgSUNWIFtSRkM1MjgyXQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXV0+PC9hcnR3b3JrPg0KICAgICAgICAg ICAgPC9maWd1cmU+DQogICAgICAgPC90Pg0KICAgICAgIDwvc2VjdGlvbj4N Cg0KICAgICAgIDxzZWN0aW9uIHRpdGxlPSJJS0UgRW5jcnlwdGlvbiBBbGdv cml0aG1zIj4NCiAgICAgICA8dD4NCiAgICAgICAgICAgPGZpZ3VyZSBhbGln bj0iY2VudGVyIj4NCiAgICAgICAgICAgICAgICA8YXJ0d29yayBhbGlnbj0i bGVmdCI+PCFbQ0RBVEFbDQpSZXF1aXJlbWVudCAgICBFbmNyeXB0aW9uIEFs Z29yaXRobQ0KLS0tLS0tLS0tLS0gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KU0hPVUxELSAgICAgICAgM0RFU19DQkMgW1JGQzcy OTZdICAgICAgICANClNIT1VMRC0gICAgICAgIEFFU19DQkMgW1JGQzcyOTZd ICAgICAgICANClNIT1VMRC0gICAgICAgIENBTkVMTElBX0NCQyBbUkZDNzI5 Nl0gICAgICAgIA0KTUFZICAgICAgICAgICAgQUVTX0NUUiBbUkZDNTkzMF0N Ck1VU1QgTk9UICAgICAgIERFU19DQkMgW1JGQzI0MDVdDQpNVVNUIE5PVCAg ICAgICBCTE9XRklTSCBbUkZDNzI5Nl0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIF1dPjwvYXJ0d29yaz4NCiAgICAgICAg ICAgIDwvZmlndXJlPg0KICAgICAgIDwvdD4NCiAgICAgICA8L3NlY3Rpb24+ DQogICAgICAgPHNlY3Rpb24gdGl0bGU9IklLRSAgQXV0aGVudGljYXRpb24g QWxnb3JpdGhtcyI+DQogICAgICAgPHQ+DQogICAgICAgICAgIDxmaWd1cmUg YWxpZ249ImNlbnRlciI+DQogICAgICAgICAgICAgICAgPGFydHdvcmsgYWxp Z249ImxlZnQiPjwhW0NEQVRBWw0KUmVxdWlyZW1lbnQgICAgQXV0aGVudGlj YXRpb24gQWxnb3JpdGhtDQotLS0tLS0tLS0tLSAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNVVNUICAgICAgICAgICBITUFDLVNI QTJfMjU2XzEyOCBbUkZDNDg2OF0NCk1VU1QtICAgICAgICAgIEhNQUMtTUQ1 IFtSRkM3Mjk2XQ0KTVVTVC0gICAgICAgICAgSE1BQy1TSEExLTk2IFtSRkM3 Mjk2XQ0KU0hPVUxEICAgICAgICAgSE1BQy1TSEEyXzM4NF8xOTIgW1JGQzQ4 NjhdDQpTSE9VTEQgICAgICAgICBITUFDLVNIQTJfNTEyXzI1NiBbUkZDNDg2 OF0NCk1BWSAgICAgICAgICAgIEFFUy1DTUFDLTk2IFtSRkM0NDk0XQ0KTUFZ ICAgICAgICAgICAgQUVTXzEyOF9HTUFDIFtSRkM0NTQzXQ0KTUFZICAgICAg ICAgICAgQUVTXzE5Ml9HTUFDIFtSRkM0NTQzXQ0KTUFZICAgICAgICAgICAg QUVTXzI1Nl9HTUFDIFtSRkM0NTQzXQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXV0+PC9hcnR3b3JrPg0KICAgICAgICAg ICAgPC9maWd1cmU+DQogICAgICAgPC90Pg0KICAgICAgIDwvc2VjdGlvbj4N CiAgICAgICA8c2VjdGlvbiB0aXRsZT0iSUtFIERpZmZpZS1IZWxsbWFuIEdy b3VwcyI+DQogICAgICAgPHQ+DQogICAgICAgICAgIDxmaWd1cmUgYWxpZ249 ImNlbnRlciI+DQogICAgICAgICAgICAgICAgPGFydHdvcmsgYWxpZ249Imxl ZnQiPjwhW0NEQVRBWw0KUmVxdWlyZW1lbnQgICAgR3JvdXANCi0tLS0tLS0t LS0tICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk1V U1QgICAgICAgICAgIDIwNDgtYml0IE1PRFAgR3JvdXAgW1JGQzM1MjZdDQpN VVNUICAgICAgICAgICA0MDk2LWJpdCBNT0RQIEdyb3VwIFtSRkMzNTI2XQ0K TVVTVCAgICAgICAgICAgODE5Mi1iaXQgTU9EUCBHcm91cCBbUkZDMzUyNl0N Ck1VU1Q/ICAgICAgICAgIDI1Ni1iaXQgcmFuZG9tIEVDUCBncm91cCBbUkZD NTkwM10NCk1VU1Q/ICAgICAgICAgIDM4NC1iaXQgcmFuZG9tIEVDUCBncm91 cCBbUkZDNTkwM10NCk1VU1Q/ICAgICAgICAgIDUyMS1iaXQgcmFuZG9tIEVD UCBncm91cCBbUkZDNTkwM10NClNIT1VMRCAgICAgICAgIDMwNzItYml0IE1P RFAgR3JvdXAgW1JGQzM1MjZdDQpTSE9VTEQgICAgICAgICA2MTQ0LWJpdCBN T0RQIEdyb3VwIFtSRkMzNTI2XQ0KTUFZICAgICAgICAgICAgMTkyLWJpdCBS YW5kb20gRUNQIEdyb3VwIFtSRkM1MTE0XQ0KTUFZICAgICAgICAgICAgMjI0 LWJpdCBSYW5kb20gRUNQIEdyb3VwIFtSRkM1MTE0XQ0KU0hPVUxELSAgICAg ICAgMTAyNC1iaXQgTU9EUCBHcm91cCBbUkZDNzI5Nl0NClNIT1VMRC0gICAg ICAgIDE1MzYtYml0IE1PRFAgR3JvdXAgW1JGQzcyOTZdDQpNVVNUIE5PVCAg ICAgICA3NjgtYml0IE1PRFAgR3JvdXAgW1JGQzcyOTZdDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBdXT48L2FydHdvcms+ DQogICAgICAgICAgICA8L2ZpZ3VyZT4NCiAgICAgICA8L3Q+DQogICAgICAg PC9zZWN0aW9uPg0KICAgICAgPC9zZWN0aW9uPg0KDQogICAgICA8c2VjdGlv biB0aXRsZT0iVXNhZ2UgR3VpZGFuY2UiPg0KICAgICAgPHQ+DQogICAgICBT aW5jZSBpbiBJS0V2MiwgYW4gSVBzZWMgU0EgY2FuIGJlIGNyZWF0ZWQgdXNp bmcgdGhlIEluaXRpYWwgRXhjaGFuZ2VzIG9yIHRoZSBDUkVBVEVfQ0hJTERf U0ENCiAgICAgIEV4Y2hhbmdlLCBpdCBpcyByZWNvbW1lbmRlZCB0byB1c2Ug dGhlIHNhbWUgRGlmZmllLUhlbGxtYW4gR3JvdXAgZm9yIHRoZXNlIEV4Y2hh bmdlcy4NCiAgICAgIDwvdD4NCiAgICAgIDwvc2VjdGlvbj4NCg0KICAgICAg PHNlY3Rpb24gdGl0bGU9IlJhdGlvbmFsZSI+DQogICAgICA8dD4NCiAgICAg IFRoaXMgc2VjdGlvbiBleHBsYWlucyB0aGUgcHJpbmNpcGxlcyBiZWhpbmQg dGhlIGltcGxlbWVudGF0aW9uDQogICAgICByZXF1aXJlbWVudHMgZGVzY3Jp YmVkIGFib3ZlLg0KICAgICAgPC90Pg0KICAgICAgPHQ+DQogICAgICBUaGUg YWxnb3JpdGhtcyBsaXN0ZWQgYXMgIk1BWSBpbXBsZW1lbnQiIGFyZSBub3Qg bWVhbnQgdG8gYmUgZW5kb3JzZWQNCiAgICAgIG92ZXIgb3RoZXIgbm9uLXN0 YW5kYXJkIGFsdGVybmF0aXZlcy4gQWxnb3JpdGhtcyBsaXN0ZWQgYXMgIlNI T1VMRC0gaW1wbGVtZW50Ig0KICAgICAgYXJlIGN1cnJlbnRseSBpbiB3aWRl IHVzZSBidXQgYXJlIGV4cGVjdGVkIHRvIGJlY29tZSBsZXNzIGZhdm91cmFi bGUgaW4gdGhlIHNob3J0DQogICAgICB0ZXJtLiBBbGdvcml0aG1zIGxpc3Rl ZCBhcyAiU0hPVUxEKyIgYXJlIGV4cGVjdGVkIHRvIGJlY29tZSBhIE1VU1Qg aW4gdGhlIHNob3J0IHRlcm0uDQogICAgICA8L3Q+DQoNCiAgICAgICA8c2Vj dGlvbiB0aXRsZT0iQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIj4NCiAgICAg ICA8dD4NCiAgICAgICBUaGlzIGRvY3VtZW50IGVuY291cmFnZXMgdGhlIHVz ZSBvZiBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24NCiAgICAgICBhbGdvcml0 aG1zIGJlY2F1c2UgdGhleSBjYW4gcHJvdmlkZSBzaWduaWZpY2FudCBlZmZp Y2llbmN5IGFuZA0KICAgICAgIHRocm91Z2hwdXQgYWR2YW50YWdlcywgYW5k IHRoZSB0aWdodCBiaW5kaW5nIGJldHdlZW4gYXV0aGVudGljYXRpb24NCiAg ICAgICBhbmQgZW5jcnlwdGlvbiBjYW4gYmUgYSBzZWN1cml0eSBhZHZhbnRh Z2UgPHhyZWYgdGFyZ2V0PSJSRkM1MTE2Ii8+Lg0KICAgICAgIDwvdD4NCiAg ICAgICA8dD4NCiAgICAgICBBRVMtR0NNIDx4cmVmIHRhcmdldD0iUkZDNDEw NiIvPiBicmluZ3Mgc2lnbmlmaWNhbnQgcGVyZm9ybWFuY2UgYmVuZWZpdHMN CiAgICAgICBhbmQgaGFzIGVtZXJnZWQgYXMgdGhlIHByZWZlcnJlZCBhdXRo ZW50aWNhdGVkIGVuY3J5cHRpb24gbWV0aG9kIGluIElLRSwNCiAgICAgICBJ UHNlYyBhbmQgb3RoZXIgc3RhbmRhcmRzLCBhbmQgaXMgdGhlcmVmb3Igc2V0 IGFzIGEgTVVTVC4NCiAgICAgICA8L3Q+DQogICAgICAgPHQ+DQogICAgICAg Q0hBQ0hBMjAtUE9MWTEzMDUgPHhyZWYgdGFyZ2V0PSJSRkM3NjM0Ii8+IGhh cyBlbWVyZ2VkIGFzIHN0cm9uZywgZmFzdA0KICAgICAgIGFuZCBpbmRlcGVu ZGFudCBhbHRlcm5hdGl2ZSB0byBBRVMtR0NNIGFzIGlzIHRoZXJlZm9yIGlu dHJvZHVjZWQgYXMgU0hPVUxEKw0KICAgICAgIDwvdD4NCiAgICAgICA8L3Nl Y3Rpb24+DQogICAgICAgPHNlY3Rpb24gdGl0bGU9IkVuY3J5cHRpb24gYW5k IEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobXMiPg0KICAgICAgIDx0Pg0KICAg ICAgIEFsZ29yaXRobXMgdGhhdCByZXF1aXJlIGEgc2VwZXJhdGUgZW5jcnlw dGlvbiBhbmQgYXV0aGVudGljYXRpb24gc3RlcCBhcmUNCiAgICAgICBnZW5l cmFsbHkgbGVzcyBmYXZvdXJhYmxlIHRoYW4gQXV0aGVudGljYXRlZCBFbmNy eXB0aW9uLiBVc2Ugb2YgdGhlc2UNCiAgICAgICBzZXBlcmF0ZWQgYWxnb3Jp dGhtcyBpcyBleHBlY3RlZCB0byBkZWNsaW5lIGFuZCBuZXcgc2VwZXJhdGUg ZW5jcnlwdGlvbiBhbmQNCiAgICAgICBhdXRoZW50aWNhdGlvbiBhbGdvcml0 aG1zIGFyZSB1bmxpa2VseSB0byBiZSBwcm9wb3NlZC4NCiAgICAgICA8L3Q+ DQogICAgICAgPHQ+DQogICAgICAgV2hpbGUgdGhlIEhNQUMgdmVyc2lvbnMg b2YgTUQ1IGFuZCBTSEExIGFyZSBzdGlsbCBjb25zaWRlcmVkIHNhZmUsIHRo ZXNlIGFsZ29yaXRobXMNCiAgICAgICBhcmUgc2VlaW5nIGFuIGV2ZXIgaW5j cmVhc2luZyByZWR1Y3Rpb24gaW4gc3RyZW5ndGggZHVlIHRvIG5ldyBjcnlw dGFuYWx5c2VzIHJlc2VhcmNoLg0KICAgICAgIFRoZSB1c2Ugb2YgTUQ1IGFu ZCBTSEExIGlzIHN0cm9uZ2x5IGRpc2NvdXJhZ2VkIGF0IHRoaXMgcG9pbnQu DQogICAgICAgPC90Pg0KICAgICAgIDwvc2VjdGlvbj4NCiAgICAgICA8c2Vj dGlvbiB0aXRsZT0iR3JvdXBzIj4NCiAgICAgICA8dD5Tb21ldGhpbmcgYWJv dXQgdGhpcyBiZWluZyBhIHdhcnpvbmUgd2l0aCBubyBjbGVhciB3aW5uZXJz IHlldD8NCiAgICAgICA8L3Q+DQogICAgICAgPC9zZWN0aW9uPg0KICAgICAg PC9zZWN0aW9uPg0KDQogICAgICA8c2VjdGlvbiB0aXRsZT0iU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMiPg0KICAgICAgPC9zZWN0aW9uPg0KDQogICAgICAg IDxzZWN0aW9uIHRpdGxlPSJBY2tub3dsZWRnbWVudHMiPg0KICAgICAgICAg ICAgPHQ+DQogICAgICAgICAgICBUaGlzIGRvY3VtZW50IGxldmVyYWdlcyBt b3N0IHRleHQgPHhyZWYgdGFyZ2V0PSJSRkM3MzIxIi8+IHdoaWNoIHdhcyB3 cml0dGVuIGJ5IFAgSG9mZm1hbg0KICAgICAgICAgICAgYW5kIEQuIE1jR3Jl dy4NCiAgICAgICAgICAgIDwvdD4NCiAgICAgICAgPC9zZWN0aW9uPg0KDQog ICAgICAgIDxzZWN0aW9uIHRpdGxlPSJJQU5BIENvbnNpZGVyYXRpb25zIj4N CiAgICAgICAgICAgIDx0Pk5vbmUNCiAgICAgICAgICAgIDwvdD4NCiAgICAg ICAgPC9zZWN0aW9uPg0KICAgIDwvbWlkZGxlPg0KDQogICAgPGJhY2s+DQog ICAgICAgIDxyZWZlcmVuY2VzIHRpdGxlPSdOb3JtYXRpdmUgUmVmZXJlbmNl cyc+DQogICAgICAgICAgICAmcmZjMjExOTsNCiAgICAgICAgICAgICZyZmMy NDA5Ow0KICAgICAgICAgICAgJnJmYzQxMDY7DQogICAgICAgICAgICAmcmZj MzUyNjsNCiAgICAgICAgICAgICZyZmM0NDk0Ow0KICAgICAgICAgICAgJnJm YzQ1NDM7DQogICAgICAgICAgICAmcmZjNDg2ODsNCiAgICAgICAgICAgICZy ZmM1MjgyOw0KICAgICAgICAgICAgJnJmYzUxMTQ7DQogICAgICAgICAgICAm cmZjNTExNjsNCiAgICAgICAgICAgICZyZmM1NzM5Ow0KICAgICAgICAgICAg JnJmYzU5MDM7DQogICAgICAgICAgICAmcmZjNTkzMDsNCiAgICAgICAgICAg ICZyZmM3Mjk2Ow0KICAgICAgICAgICAgJnJmYzczMjE7DQogICAgICAgICAg ICAmcmZjNzYzNDsNCiAgICAgICAgPC9yZWZlcmVuY2VzPg0KDQogICAgICAg IDxyZWZlcmVuY2VzIHRpdGxlPSdJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzJz4N CiAgICAgICAgICAgICZyZmMyNDA1Ow0KICAgICAgICA8L3JlZmVyZW5jZXM+ DQogICAgPC9iYWNrPg0KPC9yZmM+DQo= --8323328-1311174527-1444392420=:429-- From nobody Fri Oct 9 07:17:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22D1B405B for ; Fri, 9 Oct 2015 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 uAAfy8mhf1Hk for ; Fri, 9 Oct 2015 07:17:53 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 49E8C1B4057 for ; Fri, 9 Oct 2015 07:17:49 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so69308012wic.1 for ; Fri, 09 Oct 2015 07:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8/2NX5xqYfSSSoBosIxyY0Rf8kPLrsexP/AlnVWfAQw=; b=bQiGymtAd6TO018ckcz115T6Jk8q0runSXpfl+9X9go3doqQi4+B5n81Uvt7gjoYYO QBsaDIglSNNf2J4BHodmQvrdN+/KiHByKWNTbNDr6ReNRsbwUseo/cJWpmBD0CtnMUVK snmrfr6tQgn7q2gswbuNUrSxSsgRryHrt1OAeFFDHvgxpr8ke9Fv67gOycNZF2XdZPgK O0ckiEdrRfTtHYFWzog/bkEMfVZxFmOjnmCIT/r5dJFl8Pu0GsXrIEINcRqInPsnz84x 8n94QheonyVs4MyKl8QbUxQwc3CdP+eJV2bYZDWNvrdpwyuXBNf1I7qjrJnJuMU2Olej Qkjw== MIME-Version: 1.0 X-Received: by 10.180.102.226 with SMTP id fr2mr11607065wib.3.1444400267832; Fri, 09 Oct 2015 07:17:47 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.88.98 with HTTP; Fri, 9 Oct 2015 07:17:47 -0700 (PDT) In-Reply-To: References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> Date: Fri, 9 Oct 2015 10:17:47 -0400 X-Google-Sender-Auth: NdugaUggAqJAMUQ2hgRfSRNl3nM Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=f46d04451965e0baf30521aca480 Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 14:17:55 -0000 --f46d04451965e0baf30521aca480 Content-Type: text/plain; charset=UTF-8 Hi, Here are my comments on the draft: I would thought: AES_CBC is no more than MUST- for interoperability but could be dowgraded also to SHOULD. In addition I would also have recommend max length IV for AES-GCM unless there is special constrains like IoT devices. AES-GCM with a 16 octet ICV MUST AES-CCM with a 16 octet ICV MUST Especially thinking of constrained devices. AES-GCM with 8 octet SHOULD : the reason for not having SHOULD+ is that most IoT devices seems to use CCM AES-CCM with 8 octet SHOULD+ I would have thought of 3DES with similar or slightly less weight as CHACHA20_POLY1025 so CHACHA20_POLY1025 SHOULD 3DES SHOULD or SHOULD- I also agree we should mentionned that recommendation only applies to IKEv2. BR, Daniel On Fri, Oct 9, 2015 at 8:19 AM, Paul Wouters wrote: > On Fri, 9 Oct 2015, Yoav Nir wrote: > > On Sep 28, 2015, at 6:10 PM, Paul Hoffman wrote: >>> >>> Sure. Someone volunteer to write up the short draft, and that author >>> should put Jeff Schiller at the top of the acknowledgements, and send it to >>> the WG. >>> >>> --Paul Hoffman >>> >> >> >> A new version of I-D, draft-nir-ipsecme-rfc4307bis-00.txt >> has been successfully submitted by Yoav Nir and posted to the >> IETF repository. >> > > Oops. Guess our drafts crossed the beams. I had send one to Daniel > to look at. I've attached it in case some text is useful. It was > based more on the structure of RFC 7321. > > I actually like how 7321 has the tables filled with links to the > actual RFC's. (which I had not done yet myself) > > Some comments on your text: > > I think AES_CBC should be MUST- as it is on the way out. > > I have talked with one of the AES_GCM authors and got the advise to > only use the largest octet ICV's. Why are you promoting the 8 octet > version instead of the 16 octet version? I also think AES_GCM should > be a MUST, not a SHOULD. It is the preferred algorithm at this point. > > I also think 3DES probably should be a SHOULD- because it is the only > other non-AES algorithm in widespread use. While we all want it to go > away, we should do so only after chacha20-poly1305 sees more adoption. > > Why is sha2-512 not a SHOULD? > > > Can we add a recommendation to use integ == prf for non-AEAD algorithms? > > Windows uses 8192 modp, which I think should be a SHOULD. I think we > should mention modp 1536 as SHOULD- or MAY. > > Can we recommend that the initial exchanges and create child sa use > the same MODP group? and that we recommend PFS for create_child_sa. > > Can we recommend that a default proposal set should have at least one > MUST algorithm for each type? > > Can we recommend not to apply these recommendations for IKEv1 because > that will cause more interop problems (see my draft for text) > > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --f46d04451965e0baf30521aca480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here are my comments on the draft:

I wo= uld thought:
AES_CBC is no more than MUST- for interoperability but cou= ld be dowgraded also to SHOULD.

In addition I would also have recom= mend max length IV for AES-GCM unless there is special constrains like IoT = devices.
AES-GCM with a 16 octet ICV MUST
AES-CCM with a 16 octet ICV= MUST

Especially thinking of constrained devices.
AES-GCM with 8 = octet SHOULD : the reason for not having SHOULD+ is that most IoT devices s= eems to use CCM
AES-CCM with 8 octet SHOULD+

I would have though= t of 3DES with similar or slightly less weight as CHACHA20_POLY1025 so
= CHACHA20_POLY1025 SHOULD
3DES SHOULD or SHOULD-

I also agree we = should mentionned that recommendation only applies to IKEv2.

BR, Daniel

On Fri, Oct 9, 2015 at 8:19 AM, Paul Wouters <paul@nohats.ca> = wrote:
On Fri, 9 Oct 201= 5, Yoav Nir wrote:

On Sep 28, 2015, at 6:10 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

Sure. Someone volunteer to write up the short draft, and that author should= put Jeff Schiller at the top of the acknowledgements, and send it to the W= G.

--Paul Hoffman


A new version of I-D, draft-nir-ipsecme-rfc4307bis-00.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.

 Oops. Guess our drafts crossed the beams. I had send one to Daniel
to look at. I've attached it in case some text is useful. It was
based more on the structure of RFC 7321.

I actually like how 7321 has the tables filled with links to the
actual RFC's. (which I had not done yet myself)

Some comments on your text:

I think AES_CBC should be MUST- as it is on the way out.

I have talked with one of the AES_GCM authors and got the advise to
only use the largest octet ICV's. Why are you promoting the 8 octet
version instead of the 16 octet version? I also think AES_GCM should
be a MUST, not a SHOULD. It is the preferred algorithm at this point.

I also think 3DES probably should be a SHOULD- because it is the only
other non-AES algorithm in widespread use. While we all want it to go
away, we should do so only after chacha20-poly1305 sees more adoption.

Why is sha2-512 not a SHOULD?


Can we add a recommendation to use integ =3D=3D prf for non-AEAD algorithms= ?

Windows uses 8192 modp, which I think should be a SHOULD. I think we
should mention modp 1536 as SHOULD- or MAY.

Can we recommend that the initial exchanges and create child sa use
the same MODP group? and that we recommend PFS for create_child_sa.

Can we recommend that a default proposal set should have at least one
MUST algorithm for each type?

Can we recommend not to apply these recommendations for IKEv1 because
that will cause more interop problems (see my draft for text)


Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--f46d04451965e0baf30521aca480-- From nobody Fri Oct 9 07:52:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1CF1B4257 for ; Fri, 9 Oct 2015 07:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PaDiw782O7Um for ; Fri, 9 Oct 2015 07:52:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A388C1B4256 for ; Fri, 9 Oct 2015 07:52:40 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nXXSP4Lkmz3LZ; Fri, 9 Oct 2015 16:52:37 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=BMll3q5X X-OPENPGPKEY: Message passed unmodified 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 7fbtI2sjhfZh; Fri, 9 Oct 2015 16:52:34 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 9 Oct 2015 16:52:34 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EDF8B80030; Fri, 9 Oct 2015 10:52:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444402352; bh=1R95UBSXW6V603UjO53vHWrcz87hVyZV8B0sjOSAvSs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=BMll3q5XYPGlWCuI0/CPwZl4iz6+TEy3ZrTjWfc5EMYpox+cubWw3Ls0yOZGzC7Tu Elfy0c23ovgLkxImXPfmVz311Hg1kbIno3MpXkzlh5iUwUFo1txpMeEq5YVLfaVNFa +yypIfwpmUNDc3Uejacmj/BA/UcCWmJRqagTBCYc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t99EqWKJ010137; Fri, 9 Oct 2015 10:52:32 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 9 Oct 2015 10:52:32 -0400 (EDT) From: Paul Wouters To: Daniel Migault In-Reply-To: Message-ID: References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 14:52:43 -0000 On Fri, 9 Oct 2015, Daniel Migault wrote: > Especially thinking of constrained devices. > AES-GCM with 8 octet SHOULD : the reason for not having SHOULD+ is that most IoT devices seems to use CCM > AES-CCM with 8 octet SHOULD+ I would prefer that constrained devices put their specs in draft-ietf-lwig-ikev2-minimal https://tools.ietf.org/html/draft-ietf-lwig-ikev2-minimal-03 Or that we list that those versions should only be used if the server is talking to constrained devices. But maybe that's too much text, and we should stick to SHOULD (as most implementations handle all octet sizes anyway) > I would have thought of 3DES with similar or slightly less weight as CHACHA20_POLY1025 so Without actual interop and deployment experience, I would not yet want to officially prefer CHACHA20_POLY1025 over 3DES. Paul From nobody Fri Oct 9 08:04:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E841B435E for ; Fri, 9 Oct 2015 08:04:11 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 yDZvvA0x7NQr for ; Fri, 9 Oct 2015 08:04:05 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 6C2921B435B for ; Fri, 9 Oct 2015 08:04:05 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so74466965wic.1 for ; Fri, 09 Oct 2015 08:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EcnH1Fbf8bxZ5OpOFCs/S5AEmN3UpF/ElcgsiXXmJu4=; b=bfY51G+PQcMpeX++unvR8j386mebMO5jOEDO9pD7oX2xHcgKbVhdeFKwe89xtaeikv jaY3ZkZU50WtpNwdXZQFW+OuO9UlLB26l7sSC0lYKQkV9P+u63LIml2e8Gf2ud1ORBS5 j+I9yZX6k63P4WG1Z9HW8VTgp9NmE6JiTFdoBYkL9iAMC+wyR2RS/KkIfeJmcVbe6fFL dhQlYyzml9hrN2+9u7kAgOtnJQZMAAimEVZh/P2lDYe7hNPTtC/9nhGLjUYaOqXWcSgG l/eUiTWlXjUq4nCoGBEowrsu5QRqgid0QKgsSqCT4htsy+nIAOdTdINhZkiCazB7vokI CRuA== X-Received: by 10.180.87.225 with SMTP id bb1mr11659932wib.0.1444403043923; Fri, 09 Oct 2015 08:04:03 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id p4sm11813715wia.15.2015.10.09.08.04.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Oct 2015 08:04:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F9B48DB8-8559-4DF1-90F1-373A8EA93E89" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: Date: Fri, 9 Oct 2015 18:04:00 +0300 Message-Id: <7F78DEC3-FBF4-4BFC-831C-0F1216D51F18@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> To: Daniel Migault , Paul Wouters X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 15:04:12 -0000 --Apple-Mail=_F9B48DB8-8559-4DF1-90F1-373A8EA93E89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. I=E2=80=99ll reply to Daniel=E2=80=99s and Paul=E2=80=99s comments. Note = that this draft is a starting point to feed into discussion. Just like = this kind of discussion. Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation = with only one algorithm, the choice for maximum interoperability would = be AES-CBC. This is the same as 3DES-CBC when RFC 4307 was published. I = didn=E2=80=99t make it a MUST- because I don=E2=80=99t know what the = next MUST is going to be. AES-GCM: =E2=80=9C8 octet ICV=E2=80=9D vs =E2=80=9C16 octet ICV=E2=80=9D = - that was a mistake. Of course I meant 16, and I will fix it in -01. As = for requirement level, as far as I know, AES-GCM got a lot of adoption = for IPsec, but not so much for IKE. Why? Because it is only defined = since RFC 5282, and also because it cannot be used in IKEv1, and also = because its speed advantage doesn=E2=80=99t matter much in IKE. My = implementation does not have it for IKE (just an example) AES-CCM: Why a MUST? I don=E2=80=99t have any interest in implementing = it.=20 So with no clear direction on what the next =E2=80=9Cgo to=E2=80=9D = algorithm is going to be, I don=E2=80=99t think it=E2=80=99s time yet to = hint at AES-CBC=E2=80=99s deprecation. SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm. = Do we need it? The future seems to be AEAD algorithms, so do we really = need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be = the future? "Can we add a recommendation to use integ =3D=3D prf for non-AEAD = algorithms?=E2=80=9D - I don=E2=80=99t thin we can in this document. = That would be changing IKE, no? Group 18 (8192 bits) - IMO this is so slow that I don=E2=80=99t like = making it a SHOULD. "Can we recommend that the initial exchanges and create child sa use the same MODP group? and that we recommend PFS for create_child_sa.=E2=80=9D= The former is a sensible recommendation, but it belongs in 7296, not = here.=20 As for recommending PFS, I=E2=80=99m not sure. This is not the same as = TLS. PFS in TLS prevents exposing encryption keys with the future = exposure of a long-term secret - the private key. In IKE the IPsec encryption key depends not on the long term secret, but = on another ephemeral value - the SK_d. This is far less problematic, so = I=E2=80=99m not sure such a recommendation is worth the cost. "Can we recommend that a default proposal set should have at least one MUST algorithm for each type?=E2=80=9D I didn=E2=80=99t understand this. What is a default proposal set? "Can we recommend not to apply these recommendations for IKEv1 because that will cause more interop problems (see my draft for text)=E2=80=9D I think we should just ignore IKEv1 at this point. You definitely should = not use AES-GCM with IKEv1. Yoav --Apple-Mail=_F9B48DB8-8559-4DF1-90F1-373A8EA93E89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

I=E2=80= =99ll reply to Daniel=E2=80=99s and Paul=E2=80=99s comments. Note that = this draft is a starting point to feed into discussion. Just like this = kind of discussion.

Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 = implementation with only one algorithm, the choice for maximum = interoperability would be AES-CBC. This is the same as 3DES-CBC when RFC = 4307 was published. I didn=E2=80=99t make it a MUST- because I don=E2=80=99= t know what the next MUST is going to be.

AES-GCM: =E2=80=9C8 octet ICV=E2=80=9D = vs =E2=80=9C16 octet ICV=E2=80=9D - that was a mistake. Of course I = meant 16, and I will fix it in -01. As for requirement level, as far as = I know, AES-GCM got a lot of adoption for IPsec, but not so much for = IKE. Why? Because it is only defined since RFC 5282, and also because it = cannot be used in IKEv1, and also because its speed advantage doesn=E2=80=99= t matter much in IKE. My implementation does not have it for IKE (just = an example)

AES-CCM: Why a MUST?  I don=E2=80=99t have any interest = in implementing it. 

So with no clear direction on what the next =E2=80=9Cgo to=E2=80= =9D algorithm is going to be, I don=E2=80=99t think it=E2=80=99s time = yet to hint at AES-CBC=E2=80=99s deprecation.

SHA-512: I assume you mean HMAC-SHA-512 = as PRF and integrity algorithm. Do we need it? The future seems to be = AEAD algorithms, so do we really need PRF_HMAC_SHA2_512 ? Perhaps = something SHA-3 based is going to be the future?

"Can we add a = recommendation to use integ =3D=3D prf for non-AEAD algorithms?=E2=80=9D = - I don=E2=80=99t thin we can in this document. That would be changing = IKE, no?

Group 18 (8192 bits) - IMO this is so slow that I don=E2=80=99t= like making it a SHOULD.

"Can we recommend that the initial exchanges = and create child sa use
the same MODP group? and = that we recommend PFS for create_child_sa.=E2=80=9D

The former is a sensible recommendation, but it belongs in = 7296, not here. 
As for recommending PFS, I=E2=80=99m not sure. This is not = the same as TLS. PFS in TLS prevents exposing encryption keys with the = future exposure of a long-term secret - the private = key.
In IKE the IPsec = encryption key depends not on the long term secret, but on another = ephemeral value - the SK_d. This is far less problematic, so I=E2=80=99m = not sure such a recommendation is worth the = cost.

"Can we recommend that a default proposal = set should have at least one
MUST algorithm for each = type?=E2=80=9D

I didn=E2=80=99t understand this. What is a default proposal = set?

"Can we recommend not to = apply these recommendations for IKEv1 because
that = will cause more interop problems (see my draft for text)=E2=80=9D

I think we should = just ignore IKEv1 at this point. You definitely should not use AES-GCM = with IKEv1.

Yoav

= --Apple-Mail=_F9B48DB8-8559-4DF1-90F1-373A8EA93E89-- From nobody Fri Oct 9 08:17:04 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318481A802E for ; Fri, 9 Oct 2015 08:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 5tds8uw99jqw for ; Fri, 9 Oct 2015 08:17:01 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 877301B43A5 for ; Fri, 9 Oct 2015 08:17:01 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so75182017wic.0 for ; Fri, 09 Oct 2015 08:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=mrPFUz1ApJH9hitSP6SAitHdwowd7efbCYlqeHSupYQ=; b=Vo0V9YXJD3ByGEzk/moSR57ohYZnegT0TM3KcYmvSSkNZ3meejMwLRnb6Je2fHAeiq FBZ1ErT4anyrT2rvwMeV3SgGcqQT1H9zINlixpe65QK5Drg/tI55FoWa4i7CtIhklB/3 xfcXc96VKrJX7ZIhFPa/PSXHa/lFvK6mRm8BrdsqtgTn9OeLE4tVUr0nMlsnc8R8/CR2 EJ+ZeUkNnTWvJCSw7Rq4wxehHmscijTVmBDzF09VWjra+iGCw3XK5ysjvxErjfhH3hHu nJXG3QnwoFPHXjy9KZf+grhQwLbtmbjlAOuVTx3IDTfU6MAntpMgNNKKFl3gTRSMr0mC hWiQ== X-Received: by 10.180.107.1 with SMTP id gy1mr11789624wib.56.1444403819810; Fri, 09 Oct 2015 08:16:59 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-178-5-101.red.bezeqint.net. [79.178.5.101]) by smtp.googlemail.com with ESMTPSA id g5sm11839307wix.13.2015.10.09.08.16.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 08:16:58 -0700 (PDT) To: Yoav Nir , Daniel Migault , Paul Wouters References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> <7F78DEC3-FBF4-4BFC-831C-0F1216D51F18@gmail.com> From: Yaron Sheffer Message-ID: <5617DA63.5050008@gmail.com> Date: Fri, 9 Oct 2015 18:16:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7F78DEC3-FBF4-4BFC-831C-0F1216D51F18@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 15:17:03 -0000 RFC 4307 just barely mentions key lengths, by implying that ENCR_AES_CBC really means AES-128-CBC. I think the new document should be clear about recommended key lengths for the relevant algorithms. This may be opening a can of worms, but you don't have interoperability without it. Thanks, Yaron On 10/09/2015 06:04 PM, Yoav Nir wrote: > Hi. > > Ill reply to Daniels and Pauls comments. Note that this draft is a > starting point to feed into discussion. Just like this kind of discussion. > > Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation > with only one algorithm, the choice for maximum interoperability would > be AES-CBC. This is the same as 3DES-CBC when RFC 4307 was published. I > didnt make it a MUST- because I dont know what the next MUST is going > to be. > > AES-GCM: 8 octet ICV vs 16 octet ICV - that was a mistake. Of course > I meant 16, and I will fix it in -01. As for requirement level, as far > as I know, AES-GCM got a lot of adoption for IPsec, but not so much for > IKE. Why? Because it is only defined since RFC 5282, and also because it > cannot be used in IKEv1, and also because its speed advantage doesnt > matter much in IKE. My implementation does not have it for IKE (just an > example) > > AES-CCM: Why a MUST? I dont have any interest in implementing it. > > So with no clear direction on what the next go to algorithm is going > to be, I dont think its time yet to hint at AES-CBCs deprecation. > > SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm. > Do we need it? The future seems to be AEAD algorithms, so do we really > need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be > the future? > > "Can we add a recommendation to use integ == prf for non-AEAD > algorithms? - I dont thin we can in this document. That would be > changing IKE, no? > > Group 18 (8192 bits) - IMO this is so slow that I dont like making it a > SHOULD. > > "Can we recommend that the initial exchanges and create child sa use > the same MODP group? and that we recommend PFS for create_child_sa. > > The former is a sensible recommendation, but it belongs in 7296, not here. > As for recommending PFS, Im not sure. This is not the same as TLS. PFS > in TLS prevents exposing encryption keys with the future exposure of a > long-term secret - the private key. > In IKE the IPsec encryption key depends not on the long term secret, but > on another ephemeral value - the SK_d. This is far less problematic, so > Im not sure such a recommendation is worth the cost. > > "Can we recommend that a default proposal set should have at least one > MUST algorithm for each type? > > I didnt understand this. What is a default proposal set? > > "Can we recommend not to apply these recommendations for IKEv1 because > that will cause more interop problems (see my draft for text) > > I think we should just ignore IKEv1 at this point. You definitely should > not use AES-GCM with IKEv1. > > Yoav > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Oct 9 08:32:51 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7AF1B4418 for ; Fri, 9 Oct 2015 08:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_45=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 IjL3VzE62583 for ; Fri, 9 Oct 2015 08:32:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893551B441F for ; Fri, 9 Oct 2015 08:32:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nXYLk3Brgz3Kd; Fri, 9 Oct 2015 17:32:46 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=DUIkwBlu X-OPENPGPKEY: Message passed unmodified 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 Y8SYQgCwk2ou; Fri, 9 Oct 2015 17:32:45 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 9 Oct 2015 17:32:45 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 68BCA80300; Fri, 9 Oct 2015 11:32:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444404764; bh=rePbkFskncZ377JBc1xLC8ztrXUACAo4oo2HMEOv0/Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DUIkwBlu6lG3nFbwGjAVWrxm6BshYSHwwtTsncDN56oMleCEu9xbDnjdWPg8fsgR9 FI5hCrGcQQefP2Z6BgkyMJ4wWJ2lKcEcQewKNonZVO+FAxy7JPlQKpeoo6og4Foluv oM9komaGCRb1TrHs28eSHY1fx5Kz/ZHtIS98ecdA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t99FWhVr013220; Fri, 9 Oct 2015 11:32:43 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 9 Oct 2015 11:32:43 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <7F78DEC3-FBF4-4BFC-831C-0F1216D51F18@gmail.com> Message-ID: References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> <7F78DEC3-FBF4-4BFC-831C-0F1216D51F18@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG , Daniel Migault Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 15:32:50 -0000 On Fri, 9 Oct 2015, Yoav Nir wrote: > Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only one algorithm, the choice for maximum > interoperability would be AES-CBC. This is the same as 3DES-CBC when RFC 4307 was published. I didn’t make it a MUST- because > I don’t know what the next MUST is going to be. Fair enough. > AES-GCM: “8 octet ICV” vs “16 octet ICV” - that was a mistake. Of course I meant 16 Good. > requirement level, as far as I know, AES-GCM got a lot of adoption for IPsec, but not so much for IKE. Why? Because it is > only defined since RFC 5282, and also because it cannot be used in IKEv1, and also because its speed advantage doesn’t matter > much in IKE. My implementation does not have it for IKE (just an example) For us (libreswan) it was stalled because the codebase had a bunch of CBC assumptions in the code. It took more time to change those and so CTR and GCM stalled. I was actually surprised that when we were ready with ikev2, that ikev1 didn't even specify it. I guess I agree there is no real advantage that we know of, except the general statement about AEAD security versus ENCR+INTEG being better. If we can avoid timing based attacjs or oracles that would be a plus? > AES-CCM: Why a MUST?  I don’t have any interest in implementing it. That came in via the MUST for ESP in RFC7321. I don't particularly want it. > So with no clear direction on what the next “go to” algorithm is going to be, I don’t think it’s time yet to hint at > AES-CBC’s deprecation. Fair enough. But I think these discussions should be summarized similarly to RFC 7321 - which is why I also had written a "Rationale" section. > SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm. Do we need it? The future seems to be AEAD > algorithms, so do we really need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be the future? For non-AEAD I'm a little nervous to only have HMAC-SHA-256. I think we might want to have HMAC-SHA-512 as a temporary stopgap in the future, although once we have SHA-3 we could again drop it for a SHA-3 version. > "Can we add a recommendation to use integ == prf for non-AEAD algorithms?” - I don’t thin we can in this document. That would > be changing IKE, no? Well, our algo/cipher changes also modifies IKE (7296) doesn't it? I don't think 7296 makes any recommendations. (also I did put in "updates 7296" in my text :) The reason I'm asking was that we ran into this because libreswan only supports specifing PRF for AEAD and otherwise picks the INTEG as PRF. This caused us to fail a TAHI test. I had to argue about that failure, and I'd rather have some RFC text to do the arguing for me. > Group 18 (8192 bits) - IMO this is so slow that I don’t like making it a SHOULD. hmm, okay. I would like something non-ECC that's larger than 2048 though. > "Can we recommend that the initial exchanges and create child sa use > the same MODP group? and that we recommend PFS for create_child_sa.” > The former is a sensible recommendation, but it belongs in 7296, not here.  Same as above. I would be good to have it somewhere, because I've had this discussion a few times as well. Why not here, where we talk about IKE crypto recommendations specifically. It seems the right place to me. > As for recommending PFS, I’m not sure. This is not the same as TLS. PFS in TLS prevents exposing encryption keys with the > future exposure of a long-term secret - the private key. > In IKE the IPsec encryption key depends not on the long term secret, but on another ephemeral value - the SK_d. This is far > less problematic, so I’m not sure such a recommendation is worth the cost. Then we wasn't it dropped from CREATE_CHILD_SA? What we have now is that different implementations with different defaults cause interop issues on CREATE_CHILD_SA. (which is nasty when problems only show up at rekey time) > "Can we recommend that a default proposal set should have at least one > MUST algorithm for each type?” > I didn’t understand this. What is a default proposal set? The defaults in the configuration. If the administrator sets no explicit proposals or proposal elements. So if the software starts negotiating the admin forcing the algorithms, there is guaranteed to be a proposal that will work because it only uses MUST's. Again, this is to enhance interoperability. > "Can we recommend not to apply these recommendations for IKEv1 because > that will cause more interop problems (see my draft for text)” > > I think we should just ignore IKEv1 at this point. You definitely should not use AES-GCM with IKEv1. Again, as implementor/vendor it really helps me to have RFC text somewhere that makes this clear so I don't have to argue with customers on why we don't support GCM for IKEv1. Paul From nobody Fri Oct 9 08:43:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891E31B43FC for ; Fri, 9 Oct 2015 08:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 co49mHQxRi-U for ; Fri, 9 Oct 2015 08:43:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0041A907F for ; Fri, 9 Oct 2015 08:43:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nXYb36nRHzHY9; Fri, 9 Oct 2015 17:43:27 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=COnLzbkl X-OPENPGPKEY: Message passed unmodified 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 xV31qSNwiHUC; Fri, 9 Oct 2015 17:43:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 9 Oct 2015 17:43:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5873C80300; Fri, 9 Oct 2015 11:43:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444405406; bh=c/0qovC23WY0pRnvDh6lnjyHqskn+aNVm0oaA9JG2iY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=COnLzbkl8Y8yVxDuXT/nJC/IMajNvuWvvhmUUKnk9JgKLdACkafhKEF/mrYhqFqlS Ti6wVAdFFo8XqFDqd0pIBnRTuQuve8sFlTZnlihHrLzzbW8CCyJbwiYCfD/gSLx/UX Age5m+VERq0OpVjFHsM1r/AuNjKz9mka6X7d7fqM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t99FhPBC013756; Fri, 9 Oct 2015 11:43:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 9 Oct 2015 11:43:25 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <5617DA63.5050008@gmail.com> Message-ID: References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> <7F78DEC3-FBF4-4BFC-831C-0F1216D51F18@gmail.com> <5617DA63.5050008@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 15:43:30 -0000 On Fri, 9 Oct 2015, Yaron Sheffer wrote: > RFC 4307 just barely mentions key lengths, by implying that ENCR_AES_CBC > really means AES-128-CBC. I think the new document should be clear about > recommended key lengths for the relevant algorithms. This may be opening a > can of worms, but you don't have interoperability without it. If we do, I suggest recommending 128/256 and demoting 192 to MAY. No one uses 192 that I know, although I dont enter TLA datacenters much :P Paul From reyk.floeter@googlemail.com Fri Oct 9 10:07:07 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAEC1B48BF for ; Fri, 9 Oct 2015 10:07:07 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 CDMs_LVkPhHc for ; Fri, 9 Oct 2015 10:07:05 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 26A7A1B48B8 for ; Fri, 9 Oct 2015 10:07:03 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so76560725wic.1 for ; Fri, 09 Oct 2015 10:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=VyjJF/xP1vxKIkru8eyX4tt7FusVXGNq6A0fHXyCspo=; b=O5AoWoOLgVAsEqQy7JnvcGeW7FWEFEjRs/v22V6vrcPTf3Y0Awp2LirOf3RlpFj+iL vgh9WTQrm/qawJooQITr0AbQg2QOmrqn+3lRiYmRDRd3Wl74R8K8CZ/5TmjD/i6SIEvE pm2b/hSYEtlbp+1OJo/sG9VD0bSSve/tUwROmGUPabEQ6pi7a93mZ1wah6m6KozeH0A7 LF/hOJwCXWmKjcR6k8kAPD36MTi2RhnBRfM1K5n7A8VoFUcvILXkuECUt8jyF8SGAD8C zUo8+pJFIgcKX2u/qh6mIUirDHytBgR1BVHrvYeNQh4e6i0fM8mR5Hx+L3GPGclfGcYQ OQCw== X-Received: by 10.194.92.166 with SMTP id cn6mr16026611wjb.6.1444410421720; Fri, 09 Oct 2015 10:07:01 -0700 (PDT) Received: from autobahn.atexit.net (autobahn.atexit.net. [83.246.66.20]) by smtp.googlemail.com with ESMTPSA id uj4sm3144016wjc.34.2015.10.09.10.07.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 10:07:01 -0700 (PDT) Sender: Reyk Floeter Date: Fri, 9 Oct 2015 19:22:28 +0200 From: Reyk Floeter To: ipsec@ietf.org Message-ID: <20151009172228.GA29678@autobahn.atexit.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: mikeb@openbsd.org Subject: [IPsec] draft-ietf-ipsecme-safecurves-00 and IKEv2 in OpenBSD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 17:17:09 -0000 Hi, OpenBSD includes IKEv2 support since the 4.8 release in 2010. The software aka. OpenIKED is an independent, ISC-licensed, and open source implementation that focusses on simplicity and proactive security. I'm the main author but it has turned into a group effort with a number of contributors. See http://www.openbsd.org/ and and http://www.openiked.org/ for more details. While keeping the code base lean, we do support a number of IKEv2 extensions and crypto algorithms. We're especially interested in two recent activities of the working group: 1. RFC 7634 "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec": I appreciate the addition of chacha20-poly1305 and it will be added to iked soon (first for IKESAs before CHILDSAs). We support the proposed addition to RFC 4307. 2. draft-ietf-ipsecme-safecurves-00 "Curve25519 and Curve448 for IKEv2 Key Agreement": iked supports Curve25519 since August 2014. I compared the draft with our implementation and it matches the described application. We're currently using an xform type 4 id from the private space, but we hope to switch to an official id once it is assigned by IANA. Curve25519: We hope that the addition of Curve25519 will be finalized in an RFC. We also hope that it will be added as SHOULD or MUST in a future update of RFC 4307. Curve448: We discussed Curve448 internally and we are not going to add the curve at this point. Compared to Curve25519 it had much less cryptographer review, provides a less proven and more complex reference implementation, and is basically "too new". We also think that Curve25519 provides sufficient security at present. Afaik, there are no plans to add Curve448 in OpenSSH or LibreSSL either. The draft should clarify Curve448 as an optional extension for potentially higher security levels or omit it completely. We're not fully convinced of the meaningfulness of the security levels in this regard. After all, Curve25519 is a solid choice. Reyk From nobody Sat Oct 10 08:07:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168CC1A044F for ; Sat, 10 Oct 2015 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553] autolearn=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 wjc0pNd6Oa3M for ; Sat, 10 Oct 2015 08:07:20 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 873F21A0423 for ; Sat, 10 Oct 2015 08:07:20 -0700 (PDT) Received: from [10.32.60.32] (50-1-51-139.dsl.dynamic.fusionbroadband.com [50.1.51.139]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t9AF7JKr093729 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Oct 2015 08:07:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-139.dsl.dynamic.fusionbroadband.com [50.1.51.139] claimed to be [10.32.60.32] From: "Paul Hoffman" To: "IPsecME WG" Date: Sat, 10 Oct 2015 08:07:19 -0700 Message-ID: In-Reply-To: <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 15:07:21 -0000 There seems to be interest in the WG in adopting this work, and it seems that draft-nir-ipsecme-rfc4307bis is a reasonable starting point (although there is already some good debate about the specifics). Yoav and Tero: please resumbit this document as draft-ietf-ipsecme-rfc4307bis with any changes you have seen from the past few days that you want. WG: we will make this an active topic of discussion (along with our other topic, closing out the DDoS document). --Paul Hoffman From nobody Mon Oct 12 06:50:48 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBD11B3274 for ; Mon, 12 Oct 2015 06:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 q5Q1KbmhCbwE for ; Mon, 12 Oct 2015 06:50:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 6D5E51B3275 for ; Mon, 12 Oct 2015 06:50:41 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t9CDoZG7013963 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Oct 2015 16:50:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t9CDoYS0008585; Mon, 12 Oct 2015 16:50:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22043.47786.556863.635512@fireball.acr.fi> Date: Mon, 12 Oct 2015 16:50:34 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <22025.15464.790587.801082@fireball.acr.fi> <1FA0BD51-A1ED-4A9B-A8BB-5DB9BBB492BE@gmail.com> <7F78DEC3-FBF4-4BFC-831C-0F1216D51F18@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 32 min X-Total-Time: 33 min Archived-At: Cc: IPsecME WG , Daniel Migault , Yoav Nir Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 13:50:44 -0000 Paul Wouters writes: > > AES-CCM: Why a MUST=3F =C2=A0I don=E2=80=99t have any interest in i= mplementing it. >=20 > That came in via the MUST for ESP in RFC7321. I don't particularly wa= nt > it. I think AES-CCM is useful to have as SHOULD, as it is useful in certain environments, but I do not want to mark it as MUST, as it is not used in other environments. On the other hand I assume that in practice those IoT implementations are going to ignore this completely, and only implement the ciphers they use, and they will not be implementing all mandatory to implement ciphers, as they do not have space for them.=20 > > SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity > > algorithm. Do we need it=3F The future seems to be AEAD algorithms,= > > so do we really need PRF=5FHMAC=5FSHA2=5F512 =3F Perhaps something = SHA-3 > > based is going to be the future=3F >=20 > For non-AEAD I'm a little nervous to only have HMAC-SHA-256. I think > we might want to have HMAC-SHA-512 as a temporary stopgap in the > future, although once we have SHA-3 we could again drop it for a > SHA-3 version. I think having HMAC-SHA2-256 now, and adding longer SHA3 based PRF in future might be better.=20 > > "Can we add a recommendation to use integ =3D=3D prf for non-AEAD > > algorithms=3F=E2=80=9D - I don=E2=80=99t thin we can in this docume= nt. That would be > > changing IKE, no=3F >=20 > Well, our algo/cipher changes also modifies IKE (7296) doesn't it=3F No this document does not change RFC 7296. The RFC 7296 does not specify mandatory to implement algorithms just for this reason. I.e. they are left out from the IKEv2 rfc, and moved to this separate RFC. > I don't think 7296 makes any recommendations. (also I did put in > "updates 7296" in my text :) The reason I'm asking was that we ran > into this because libreswan only supports specifing PRF for AEAD and > otherwise picks the INTEG as PRF. This caused us to fail a TAHI > test. I had to argue about that failure, and I'd rather have some > RFC text to do the arguing for me. I think adding text that would say INTEG =3D=3D PRF in this document wo= uld be changing the IKEv2, and would make several implementations non-complient with the this RFC, or at least go against SHOULD in here if they do allow INTEG !=3D PRF. Also there is no need that INTEG would need to be same as PRF. Even if the AUTH=5FAES=5FXCBC=5F96 is fine for the integrity algorithm, I am mu= ch more happy to use HMAC=5FSHA2 as PRF, than to use the AES128=5FCBC as P= RF (there are some concerns about how good PRF it really is). Oh, btw we need to fix the name of the PRF=5FAES128=5FCBC, it should be= called PRF=5FAES128=5FXCBC. It is XCBC not CBC (the title of RFC4434 sa= ys AES-XCBC-PRF-128). And we could make IANA action in this draft to fix the name in iana registry too.=20 > > Group 18 (8192 bits) - IMO this is so slow that I don=E2=80=99t lik= e > > making it a SHOULD.=20 >=20 > hmm, okay. I would like something non-ECC that's larger than 2048 > though. We are writing mandatory to implement algorithms list, you are free to implement longer groups. If you have implemented 2048-bit group, adding longer groups is not an issue. On the other hand if we want to make any other group as SHOULD, we should stick to the 3072 or 4096 bit groups, which provide more than enough security when you take in to account of memory required to crack those groups.=20 > > "Can we recommend that the initial exchanges and create child sa us= e > > the same MODP group=3F and that we recommend PFS for create=5Fchild= =5Fsa.=E2=80=9D > > The former is a sensible recommendation, but it belongs in 7296, no= t here.=C2=A0 >=20 > Same as above. I would be good to have it somewhere, because I've had= > this discussion a few times as well. Why not here, where we talk abou= t > IKE crypto recommendations specifically. It seems the right place to = me. Actually I can see that people might want to use long Diffie-Hellman for the IKEv2 SA, just to get maximal protection for all traffic, and then do fast Diffie-Hellman every few minutes when they rekey their traffic keys. So I do not think such recommendation would be good. > > As for recommending PFS, I=E2=80=99m not sure. This is not the same= as > > TLS. PFS in TLS prevents exposing encryption keys with the future > > exposure of a long-term secret - the private key. In IKE the IPsec > > encryption key depends not on the long term secret, but on another > > ephemeral value - the SK=5Fd. This is far less problematic, so I=E2= =80=99m > > not sure such a recommendation is worth the cost. >=20 > Then we wasn't it dropped from CREATE=5FCHILD=5FSA=3F What we have no= w is that > different implementations with different defaults cause interop issue= s > on CREATE=5FCHILD=5FSA. (which is nasty when problems only show up at= rekey > time) If one end has unsecure policy which you do not want to accept, the right fix is to either allow that policy which you consider unsecure, or fix the configuration of the other end. Yes, there can still be misconfigurations with IKEv2 too...=20 > > "Can we recommend that a default proposal set should have at least > > one MUST algorithm for each type=3F=E2=80=9D I didn=E2=80=99t under= stand this. What > > is a default proposal set=3F >=20 > The defaults in the configuration. If the administrator sets no expli= cit > proposals or proposal elements. So if the software starts negotiating= > the admin forcing the algorithms, there is guaranteed to be a proposa= l > that will work because it only uses MUST's. Again, this is to enhance= > interoperability. We do not have default configuration. Also nothing we write here does not affect anybody USING ciphers. We only specify what must be implemented, we do not specify what will be used. It seems you would like to write profile document describing default configuration for IKEv2=3F I do not think such profile belongs to this document, but you can write new UI Suite document and define your default cipher settings, and other configuration parameter settings. Then you can refer to that... :-) And yes, we might want to specify new UI suites especially for the CHACHA20=5FPOLY1305... > > "Can we recommend not to apply these recommendations for IKEv1 beca= use > > that will cause more interop problems (see my draft for text)=E2=80= =9D > >=20 > > I think we should just ignore IKEv1 at this point. You definitely > > should not use AES-GCM with IKEv1.=20 >=20 > Again, as implementor/vendor it really helps me to have RFC text some= where > that makes this clear so I don't have to argue with customers on why = we > don't support GCM for IKEv1. You should argue, that as IKEv1 was obsoleted 10 years ago, it needs to be obsoleted from the implementations too... Or at least it should be disabled by default for all configurations, and it can only be enabled in the configuration by explitly adding the value of "Pre-Shared key for the Internet Protocol" in configuration file, and if you do not know the key listed in that draft, there is no way to enable ikev1... :-) --=20 kivinen@iki.fi From nobody Mon Oct 12 08:18:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8841A6FC5 for ; Mon, 12 Oct 2015 08:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 9MdIYjS3HX8i for ; Mon, 12 Oct 2015 08:18:45 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 1EDB11A6FC3 for ; Mon, 12 Oct 2015 08:18:45 -0700 (PDT) Received: from [10.32.60.31] (50-1-51-139.dsl.dynamic.fusionbroadband.com [50.1.51.139]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t9CFIiHH000341 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Oct 2015 08:18:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-139.dsl.dynamic.fusionbroadband.com [50.1.51.139] claimed to be [10.32.60.31] From: "Paul Hoffman" To: "IPsecME WG" Date: Mon, 12 Oct 2015 08:18:46 -0700 Message-ID: <07BFC339-0970-4648-9B70-9E7DDBE4604B@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Subject: [IPsec] Scope of RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 15:18:45 -0000 On 12 Oct 2015, at 6:50, Tero Kivinen wrote: > I think AES-CCM is useful to have as SHOULD, as it is useful in > certain environments, but I do not want to mark it as MUST, as it is > not used in other environments. > > On the other hand I assume that in practice those IoT implementations > are going to ignore this completely, and only implement the ciphers > they use, and they will not be implementing all mandatory to implement > ciphers, as they do not have space for them. This is a reasonable observation about deployment of IPsec. In the pre-IoT past, we have had the same discussion, with some developers saying "I am supposed to write a system for a particular customer who has a particular set of algorithms that they have chosen for their application; why should that be considered out of compliance with the IETF?" Thus, the WG needs to decide the desired scope of the requirements for this document are and put them into the document. Without that, we can endlessly debate about particular choices for "MUST" and even "SHOULD". --Paul Hoffman From nobody Mon Oct 12 14:27:40 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433341A0470 for ; Mon, 12 Oct 2015 14:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 bKZ8WfU7d9Zu for ; Mon, 12 Oct 2015 14:27:38 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 EF4741A044F for ; Mon, 12 Oct 2015 14:27:37 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9CLRSYJ006987 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 12 Oct 2015 23:27:30 +0200 From: Simon Josefsson To: Reyk Floeter References: <20151009172228.GA29678@autobahn.atexit.net> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151012:ipsec@ietf.org::c6GR4ecN0tpE2m0Z:+9I X-Hashcash: 1:22:151012:mikeb@openbsd.org::cVT8ODcA4RJrJF5v:26q6 X-Hashcash: 1:22:151012:reyk@openbsd.org::RHTb7QA9E3vhcijt:9XCq Date: Mon, 12 Oct 2015 23:27:27 +0200 In-Reply-To: <20151009172228.GA29678@autobahn.atexit.net> (Reyk Floeter's message of "Fri, 9 Oct 2015 19:22:28 +0200") Message-ID: <87k2qr93r4.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: ipsec@ietf.org, mikeb@openbsd.org Subject: Re: [IPsec] draft-ietf-ipsecme-safecurves-00 and IKEv2 in OpenBSD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 21:27:39 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Reyk Floeter writes: > 2. draft-ietf-ipsecme-safecurves-00 "Curve25519 and Curve448 for IKEv2 > Key Agreement":=20 > > iked supports Curve25519 since August 2014. I compared the draft with > our implementation and it matches the described application. We're > currently using an xform type 4 id from the private space, but we hope > to switch to an official id once it is assigned by IANA. > > Curve25519: We hope that the addition of Curve25519 will be finalized > in an RFC. We also hope that it will be added as SHOULD or MUST in a > future update of RFC 4307. Thanks for feedback! > Curve448: We discussed Curve448 internally and we are not going to add > the curve at this point. Compared to Curve25519 it had much less > cryptographer review, provides a less proven and more complex > reference implementation, and is basically "too new". We also think > that Curve25519 provides sufficient security at present. Afaik, there > are no plans to add Curve448 in OpenSSH or LibreSSL either. The draft > should clarify Curve448 as an optional extension for potentially > higher security levels or omit it completely. > > We're not fully convinced of the meaningfulness of the security levels > in this regard. After all, Curve25519 is a solid choice. I can understand these concerns for an implementer. I think there is little harm in the draft specifying how to use Curve448 for potential future use though. I agree normative language or mandatory-to-implement recommendations for Curve448 may be premature, at least until other implementers speak up in favor of implementing it. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWHCW/AAoJEIYLf7sy+BGdieEH/3INWeGJ/QHG//18AKmFyCcw VQTGiDTya3+PH94R4EbSfVaRLS1VeGZ5bycct9X47vPn3DPvSx9lafgqW+BKIgbO u0MwRS4J6TfSLYpqVJcbexL0Myg64vYPUcmRlgsY4PAzyyBxn52MIhqWDUNeo/N7 cliznDX258RqNPwu4+K64LDuPX9OLOnJUG1SYE1/6QgRdD6kI49evR4VYz+PvkGt xBqMO1kMqfeOsKV2xz9o1Aq7azJY4UKhxEaqzjbRsjNcMIp+sy9ut9IZbgaVPdEb 6SquBLhuGka2BpIabp8omH0yJadLtF0XbhN694jjNCTMuTDuaSWWyKXeSiXWrsY= =2qsn -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 12 16:30:40 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517B11B2B95 for ; Mon, 12 Oct 2015 16:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1SHabGAJTIGn for ; Mon, 12 Oct 2015 16:30:37 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15DB1B2B92 for ; Mon, 12 Oct 2015 16:30:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nZbpf6gskz3M2; Tue, 13 Oct 2015 01:30:34 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=mtH3dpak X-OPENPGPKEY: Message passed unmodified 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 eGaDBf7BL3rY; Tue, 13 Oct 2015 01:30:34 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 13 Oct 2015 01:30:33 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 92FCC80030; Mon, 12 Oct 2015 19:30:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444692632; bh=FoEEsmtPq3cXRV2eIbg/TAL5v7ocNiW4ciCBipCKN7o=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mtH3dpaks6JAl43IYNY3AiGd57JX1Dv7H0IwlOxVEw++j93GoRsQaDcZzyKI8M5et uypVEsfgwWZjZSenN1IY0+q6TNdH+UXRxgekEBUPJpitxMwYtxE+UiUqXHycvIAta2 WEZ8Cbf4DMzSrV01SX05y8xwGQ5P223IVo/onKWY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t9CNUUPn007824; Mon, 12 Oct 2015 19:30:30 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 12 Oct 2015 19:30:30 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <07BFC339-0970-4648-9B70-9E7DDBE4604B@vpnc.org> Message-ID: References: <07BFC339-0970-4648-9B70-9E7DDBE4604B@vpnc.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Scope of RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 23:30:39 -0000 On Mon, 12 Oct 2015, Paul Hoffman wrote: >> On the other hand I assume that in practice those IoT implementations >> are going to ignore this completely, and only implement the ciphers >> they use, and they will not be implementing all mandatory to implement >> ciphers, as they do not have space for them. > > This is a reasonable observation about deployment of IPsec. In the pre-IoT > past, we have had the same discussion, with some developers saying "I am > supposed to write a system for a particular customer who has a particular set > of algorithms that they have chosen for their application; why should that be > considered out of compliance with the IETF?" Right, and comments on that can go into draft-ietf-lwig-ikev2-minimal > Thus, the WG needs to decide the desired scope of the requirements for this > document are and put them into the document. Without that, we can endlessly > debate about particular choices for "MUST" and even "SHOULD". My preference is for one document to clarify all crypto considerations and updates. And for that document to update 7296. Paul From nobody Tue Oct 13 13:57:05 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90E1A8BBF for ; Tue, 13 Oct 2015 13:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 3OviYZdW4how for ; Tue, 13 Oct 2015 13:57:03 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 E8D101A8BB4 for ; Tue, 13 Oct 2015 13:57:02 -0700 (PDT) Received: by wicge5 with SMTP id ge5so210077384wic.0 for ; Tue, 13 Oct 2015 13:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=oOiPaNetSSEGSBEOCfpSNafPAtNJtGuISNSasdQaRsU=; b=CNaUW00EqjJreY/Z/anF3VmbH8B5cNkxBAVmgWG2vLVrhB+etAzy8+iUyzWRS/AQiM p4rQANQVWMnoK4kc4dZ04kpHCxpak836Rv/0e4OiuK2mwZ6PlOa8zuWRpKs6WptYbP57 I+ZngHXsk1JiwONCjhvaAviq4brmVmYh/M23atLdWaDETNQgdq5p28Zf7YyPJCOLkPKK X0okgkIRTUM4vMrdyR5F0PDwenwAUZmWDdhGsmcHER7NuVadPyKsdAJxG6+vzhwBOuOj B6AfvvFQ/7AhGrbDTnam6FBi2kqIPS93eiSRpGqyavPooaq/OIVDWHCUgBNrGASLHPhV d+tQ== MIME-Version: 1.0 X-Received: by 10.180.198.142 with SMTP id jc14mr84511wic.32.1444769821553; Tue, 13 Oct 2015 13:57:01 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.88.98 with HTTP; Tue, 13 Oct 2015 13:57:01 -0700 (PDT) Date: Tue, 13 Oct 2015 16:57:01 -0400 X-Google-Sender-Auth: a6WUlRE2WPZZGKPd8InWpy83E-E Message-ID: From: Daniel Migault To: Tero Kivinen Content-Type: multipart/alternative; boundary=047d7b625314ff21f2052202af6a Archived-At: Cc: IPsecME WG , Paul Wouters , Yoav Nir Subject: [IPsec] RFC4307bis -- 3GPP inputs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:57:04 -0000 --047d7b625314ff21f2052202af6a Content-Type: text/plain; charset=UTF-8 Hi, 3GPP is also looking at updating its IKEv2 profile - most likely in November. I beleive it would be good to know about it and eventually to position RFC4307bis toward them. So far the differences I see with [1] are: - DH group 19 (256-bit random ECP group) is MUST in 3GPP instead of SHOULD in [1]. - PRF_HMAC_SHA2_384; is MUST in 3GPP and is not mentionned in [1]. - Diffie-Hellman group 20 (384-bit random ECP group) is SHOULD in 3GPP instead of MAY in [1]. - DH group 2 (1024-bit MODP) is MUST NOT in 3GPP instead of SHOULD NOT in [1]. Are they any opinion to upgrade the requiremenst of [1] regarding 3GPP IKEv2 profiles? [1] https://tools.ietf.org/html/draft-nir-ipsecme-rfc4307bis-00 --047d7b625314ff21f2052202af6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

3GPP is also looking at updating its IKEv= 2 profile - most likely in November. I beleive it would be good to know abo= ut it and eventually to position RFC4307bis toward them. So far the differe= nces I see with [1] are:

=C2=A0=C2=A0 - DH group 19 (256-bit random = ECP group) is MUST in 3GPP instead of SHOULD in [1].
=C2=A0=C2=A0 - PRF= _HMAC_SHA2_384; is MUST in 3GPP and is not mentionned in [1].
=C2=A0=C2= =A0 - Diffie-Hellman group 20 (384-bit random ECP group) is SHOULD in 3GPP = instead of MAY in [1].
=C2=A0=C2=A0 - DH group 2 (1024-bit MODP) is MUST= NOT in 3GPP instead of SHOULD NOT in [1].

Are they any opinio= n to upgrade the requiremenst of [1] regarding 3GPP IKEv2 profiles?

[1] https://tools.ietf.org/html/draft-nir-ipsecme-rfc4307bis-00

--047d7b625314ff21f2052202af6a-- From nobody Tue Oct 13 14:13:05 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB8C1A9008 for ; Tue, 13 Oct 2015 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 P06IM5NAsU1G for ; Tue, 13 Oct 2015 14:13:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4041A8FD7 for ; Tue, 13 Oct 2015 14:13:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nb8jR4gFwzHcg; Tue, 13 Oct 2015 23:12:59 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=gV/ipTW4 X-OPENPGPKEY: Message passed unmodified 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 oGj384Lp6JHe; Tue, 13 Oct 2015 23:12:57 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 13 Oct 2015 23:12:57 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 41DE280030; Tue, 13 Oct 2015 17:12:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444770776; bh=S0yvp9oYc9kGX9xKZaiYqdICf5Xe1ZKDzcK3LZ4CPIk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gV/ipTW4uqip+hPq7htwLamSsNVpn001p78Ao7zsVG8Ay1WkonvB4fRft4Hk/8vm5 BwJ1tp3kAWQm5BdGSWy9j/iWPbvRqRy5jttnFlpuVhOmdtxPSCMWkPCgoJTC5NanrM waU6MHYJjvNiryQ3Wf3hgXvDbQPUEAapJlN7WtGw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t9DLCta3003185; Tue, 13 Oct 2015 17:12:55 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 Oct 2015 17:12:55 -0400 (EDT) From: Paul Wouters To: Daniel Migault In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG , Yoav Nir , Tero Kivinen Subject: Re: [IPsec] RFC4307bis -- 3GPP inputs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 21:13:03 -0000 On Tue, 13 Oct 2015, Daniel Migault wrote: > 3GPP is also looking at updating its IKEv2 profile - most likely in November. I beleive it would be good to know about it and > eventually to position RFC4307bis toward them. So far the differences I see with [1] are: Are the requirements for the 3GPP IKEv2 profile (suite) the same as the requirements for RFC4307bis? >    - DH group 19 (256-bit random ECP group) is MUST in 3GPP instead of SHOULD in [1]. >    - PRF_HMAC_SHA2_384; is MUST in 3GPP and is not mentionned in [1]. >    - Diffie-Hellman group 20 (384-bit random ECP group) is SHOULD in 3GPP instead of MAY in [1]. >    - DH group 2 (1024-bit MODP) is MUST NOT in 3GPP instead of SHOULD NOT in [1]. Does 3GPP have a rationale for their decisions? Without a rationale, it is a little hard to justify any decision or any change. Which is why I have been pushing that we add a rationale as well for RFC4307bis. For instance, why is PRF_HMAC_SHA2_384 a MUST? Isn't PRF_HMAC_SHA2_256 good enough? Same for group 19/20. I can see that since 3GPP started out much later, they never deployed group 2, so a MUST NOT for them could make sense, but since group 2 is too common for internet hosts doing IKE, I can see why RFC4307bis wants to use SHOULD NOT. Paul From nobody Tue Oct 13 17:47:31 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B811A92B5 for ; Tue, 13 Oct 2015 17:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 107wem1nT0Wa for ; Tue, 13 Oct 2015 17:47:27 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F991A9080 for ; Tue, 13 Oct 2015 17:47:27 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-36-561d39c9bcd6 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 70.AC.26730.9C93D165; Tue, 13 Oct 2015 19:05:13 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Tue, 13 Oct 2015 20:47:25 -0400 From: Daniel Migault To: Paul Wouters Thread-Topic: RFC4307bis -- 3GPP inputs Thread-Index: AQHRBfv9+iTc62wQikOmn8nmuIuVGZ5qIjCg Date: Wed, 14 Oct 2015 00:47:24 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11216D8D8@eusaamb107.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXSPn+5JS9kwgweHTC32b3nBZnH0/HM2 i/e3LjFZLD32gcmBxWPnrLvsHkuW/GTyOPx1IYvH93lMASxRXDYpqTmZZalF+nYJXBlPj55i L3glUjH1fwN7A+MSkS5GTg4JAROJNZfus0DYYhIX7q1nA7GFBI4ySjRdk+xi5AKylzNKvG39 yASSYBMwkmg71M8OYosIKEpMOvMIqJmDg1kgQWL2LwOQsLCAmsT/fysYIUrUJdav3wxWIgLU uv12GkiYRUBV4krHerCJvAK+Eue621kgVrUzStxbfxSsl1PAUWJe70dmEJsR6Lbvp9aANTAL iEvcejKfCeJmAYkle84zQ9iiEi8f/2OFsJUk5ry+xgxxmqbE+l36EK2KElO6H7JD7BWUODnz CcsERrFZSKbOQuiYhaRjFpKOBYwsqxg5SotTy3LTjQw3MQKj6JgEm+MOxgWfLA8xCnAwKvHw KnyVDhNiTSwrrsw9xCjNwaIkzjtvxv1QIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwL5357 t5t93mRJ5a6vy0vNpqac5vOr+zFXrNDzjbAOn4Ho3perbkWIzFH9O+mlxCKv0ueHc1f3tz55 17k9/ZSz88NauYnzbi1T38Krc6k5jC8xOSTwUvrcT9VV0ktuZoTozChiiv6/iO31qlDTNUeL jB75ppi/ePKGrW+S8+y97yc6xt3+G7FViaU4I9FQi7moOBEAx54DQoMCAAA= Archived-At: Cc: IPsecME WG , Yoav Nir , Tero Kivinen Subject: Re: [IPsec] RFC4307bis -- 3GPP inputs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 00:47:29 -0000 TXkgZ3Vlc3MgaXMgdGhhdCB0aGVpciByZXF1aXJlbWVudHMgc2hvdWxkIGJlIHNpbWlsYXIgYXMg dGhvc2UgZm9yIHJmYzQzMDdiaXMsIGJ1dCBhcyB5b3UgbWVudGlvbiwgdGhlIGhpc3Rvcnkgb2Yg Y3J5cHRvIHN1aXRlIGRlcGxveW1lbnQgbWF5IGJlIGRpZmZlcmVudC4gICBUaGVzZSBwcm9maWxl cyB3aWxsIGJlIGRpc2N1c3NlZCBpbiBmdXR1cmUgbWVldGluZ3MsIHNvIHRoZXkgbWlnaHQgZXZv bHZlLiANCg0KSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBwcm92aWRlIG91ciByYXRpb25hbCBmb3Ig b3VyIGNob2ljZS4gVGhpcyB3aWxsIGJlIHVzZWZ1bCBmb3IgZXZlcnlvbmUsIGluY2x1ZGluZyBv dGhlciBjb21tdW5pdGllcyB0byBtYWtlIHRoZWlyIG93biBjaG9pY2UgYWNjb3JkaW5nIHRvIHRo ZWlyIG93biBzcGVjaWZpZXMuDQoNCkJSLCANCkRhbmllbA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogUGF1bCBXb3V0ZXJzIFttYWlsdG86cGF1bEBub2hhdHMuY2FdIA0KU2Vu dDogVHVlc2RheSwgT2N0b2JlciAxMywgMjAxNSA1OjEzIFBNDQpUbzogRGFuaWVsIE1pZ2F1bHQN CkNjOiBUZXJvIEtpdmluZW47IElQc2VjTUUgV0c7IFlvYXYgTmlyDQpTdWJqZWN0OiBSZTogUkZD NDMwN2JpcyAtLSAzR1BQIGlucHV0cw0KDQpPbiBUdWUsIDEzIE9jdCAyMDE1LCBEYW5pZWwgTWln YXVsdCB3cm90ZToNCg0KPiAzR1BQIGlzIGFsc28gbG9va2luZyBhdCB1cGRhdGluZyBpdHMgSUtF djIgcHJvZmlsZSAtIG1vc3QgbGlrZWx5IGluIA0KPiBOb3ZlbWJlci4gSSBiZWxlaXZlIGl0IHdv dWxkIGJlIGdvb2QgdG8ga25vdyBhYm91dCBpdCBhbmQgZXZlbnR1YWxseSB0byBwb3NpdGlvbiBS RkM0MzA3YmlzIHRvd2FyZCB0aGVtLiBTbyBmYXIgdGhlIGRpZmZlcmVuY2VzIEkgc2VlIHdpdGgg WzFdIGFyZToNCg0KQXJlIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSAzR1BQIElLRXYyIHByb2Zp bGUgKHN1aXRlKSB0aGUgc2FtZSBhcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBSRkM0MzA3YmlzPw0K DQo+IMKgwqAgLSBESCBncm91cCAxOSAoMjU2LWJpdCByYW5kb20gRUNQIGdyb3VwKSBpcyBNVVNU IGluIDNHUFAgaW5zdGVhZCBvZiBTSE9VTEQgaW4gWzFdLg0KPiDCoMKgIC0gUFJGX0hNQUNfU0hB Ml8zODQ7IGlzIE1VU1QgaW4gM0dQUCBhbmQgaXMgbm90IG1lbnRpb25uZWQgaW4gWzFdLg0KPiDC oMKgIC0gRGlmZmllLUhlbGxtYW4gZ3JvdXAgMjAgKDM4NC1iaXQgcmFuZG9tIEVDUCBncm91cCkg aXMgU0hPVUxEIGluIDNHUFAgaW5zdGVhZCBvZiBNQVkgaW4gWzFdLg0KPiDCoMKgIC0gREggZ3Jv dXAgMiAoMTAyNC1iaXQgTU9EUCkgaXMgTVVTVCBOT1QgaW4gM0dQUCBpbnN0ZWFkIG9mIFNIT1VM RCBOT1QgaW4gWzFdLg0KDQpEb2VzIDNHUFAgaGF2ZSBhIHJhdGlvbmFsZSBmb3IgdGhlaXIgZGVj aXNpb25zPyAgV2l0aG91dCBhIHJhdGlvbmFsZSwgaXQgaXMgYSBsaXR0bGUgaGFyZCB0byBqdXN0 aWZ5IGFueSBkZWNpc2lvbiBvciBhbnkgY2hhbmdlLiBXaGljaCBpcyB3aHkgSSBoYXZlIGJlZW4g cHVzaGluZyB0aGF0IHdlIGFkZCBhIHJhdGlvbmFsZSBhcyB3ZWxsIGZvciBSRkM0MzA3YmlzLg0K DQpGb3IgaW5zdGFuY2UsIHdoeSBpcyBQUkZfSE1BQ19TSEEyXzM4NCBhIE1VU1Q/IElzbid0IFBS Rl9ITUFDX1NIQTJfMjU2IGdvb2QgZW5vdWdoPyBTYW1lIGZvciBncm91cCAxOS8yMC4gSSBjYW4g c2VlIHRoYXQgc2luY2UgM0dQUCBzdGFydGVkIG91dCBtdWNoIGxhdGVyLCB0aGV5IG5ldmVyIGRl cGxveWVkIGdyb3VwIDIsIHNvIGEgTVVTVCBOT1QgZm9yIHRoZW0gY291bGQgbWFrZSBzZW5zZSwg YnV0IHNpbmNlIGdyb3VwIDIgaXMgdG9vIGNvbW1vbiBmb3IgaW50ZXJuZXQgaG9zdHMgZG9pbmcg SUtFLCBJIGNhbiBzZWUgd2h5IFJGQzQzMDdiaXMgd2FudHMgdG8gdXNlIFNIT1VMRCBOT1QuDQoN ClBhdWwNCg== From nobody Wed Oct 14 01:04:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B798F1B2C2A for ; Wed, 14 Oct 2015 01:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sTJGG_eRFEAM for ; Wed, 14 Oct 2015 01:04:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9771B2C26 for ; Wed, 14 Oct 2015 01:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3789; q=dns/txt; s=iport; t=1444809840; x=1446019440; h=from:to:subject:date:message-id:mime-version; bh=LePeVTnd7AUDQnZ5MIPwtGNkKfVZ2duBgJ6G9lR3K20=; b=YE6xQ65eBO3nYthJZnnlUC4KMIBqSjD4jlgOt1rf5pfbDayKP8MyUetS xZVVLmX6jthWN+j7jOSYQI5AFYBmvbN6W4HSZW8fK1Lvona7vRHOGfOFv nnNqhav+dJUmlACSIfIlNlVq1Tle/uNbn3EY9bPSmiF76YVlGnd6VcX09 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkAgDCCx5W/4gNJK1egllNgUi9fAENgVqDE4IKgjk4FAEBAQEBAQF/C4QtgQsBDHQnBIhBnyijQwELAR+Gdo5ABY1HiE4BeYwhnAkBHwEBQoQChlqBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="scan'208,217";a="197668251" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 14 Oct 2015 08:03:59 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t9E83xNv001247 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Oct 2015 08:03:59 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 03:03:45 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 03:03:45 -0500 From: "Hema Tripathi (hetripat)" To: "ipsec@ietf.org" Thread-Topic: Query regarding transport mode in IKEv2 Thread-Index: AQHRBlbZ4lNDAuoGdkia4S/B6WLDVQ== Date: Wed, 14 Oct 2015 08:03:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.142.41.154] Content-Type: multipart/alternative; boundary="_000_D2440A0713B6Bhetripatciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Query regarding transport mode in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 08:04:01 -0000 --_000_D2440A0713B6Bhetripatciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to interpret the following excerpt from the RFC-5996. " The USE_TRANSPORT_MODE notification MAY be included in a request message that also includes an SA payload requesting a Child SA. It requests that the Child SA use transport mode rather than tunnel mode for the SA created. If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the Child SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA." Its the last two lines in this paragraph that are not clear to me. My doubt= is regarding the following line, "If the responder declines the request, the Child SA will be established in= tunnel mode". It uses "will be ", so not sure if that's a MUST or implementation's choice= . If responder declines the request, is CHILD SA still established in tunne= l mode? -- Regards, Hema --_000_D2440A0713B6Bhetripatciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <97E5D25473B0CA4A8EEDEEFD161438BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to interpret the following excerpt from the RFC-5996.

“ The USE_TRANSPORT_MODE notification M=
AY be included in a request
   message that also includes an SA payload requesting a Child SA.  It
   requests that the Child SA use transport mode rather than tunnel mode
   for the SA created.  If the request is accepted, the response MUST
   also include a notification of type USE_TRANSPORT_MODE.  If the
   responder declines the request, the Child SA will be established in
   tunnel mode.  If this is unacceptable to the initiator, the initiator
   MUST delete the SA.”
Its the last two lines in this paragraph that=
 are not clear to me. My doubt is regarding the following line,
"If the responder declines the request, the Child SA wi=
ll be established in tunnel=
 mode”. 
It uses "will=
 be “, so not sure if that’s a MUST or implementation's choice.=
 =
If responder declines the request, is CHILD SA still established in tunnel =
mode? 
--
Regards,
Hema
--_000_D2440A0713B6Bhetripatciscocom_-- From nobody Wed Oct 14 11:07:34 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD581AD241 for ; Wed, 14 Oct 2015 11:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2jKHxkB7QJ6p for ; Wed, 14 Oct 2015 11:07:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7A11A90F0 for ; Wed, 14 Oct 2015 11:07:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nbhXw36j3z3R2; Wed, 14 Oct 2015 20:07:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=O57qe+pe X-OPENPGPKEY: Message passed unmodified 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 7uQn096g9PGM; Wed, 14 Oct 2015 20:07:14 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 14 Oct 2015 20:07:13 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 21DEC800B0; Wed, 14 Oct 2015 14:07:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444846033; bh=EnZSiNVpqvGG/25BQBABMYyByLLjpPC4UedrO/G02ao=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O57qe+peYf3KHSlWkhTHDvk7ZmYFk2r6Cp7oigXxb8cPh1zQT70hc0CwycJBKbsNL muoAwO1e8vyDvErddph6cGfzb1nnJowpBtzk/wWHS3TvLnMMhq46o1kdr8Z3OdbUlg MMJJQyGk72J+eMQVE9PCWVM+3Om1nwFqYThQeGd8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t9EI7CXt030273; Wed, 14 Oct 2015 14:07:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 14 Oct 2015 14:07:12 -0400 (EDT) From: Paul Wouters To: "Hema Tripathi (hetripat)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Query regarding transport mode in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 18:07:33 -0000 On Wed, 14 Oct 2015, Hema Tripathi (hetripat) wrote: > I am trying to interpret the following excerpt from the RFC-5996. > > “ The USE_TRANSPORT_MODE notification MAY be included in a request > message that also includes an SA payload requesting a Child SA. It > requests that the Child SA use transport mode rather than tunnel mode > for the SA created. If the request is accepted, the response MUST > also include a notification of type USE_TRANSPORT_MODE. If the > responder declines the request, the Child SA will be established in > tunnel mode. If this is unacceptable to the initiator, the initiator > MUST delete the SA.” > > Its the last two lines in this paragraph that are not clear to me. My doubt is regarding the following line, > > "If the responder declines the request, the Child SA will be established in tunnel mode”. > > It uses "will be “, so not sure if that’s a MUST or implementation's choice. If responder declines the request, is CHILD SA s > till established in tunnel mode?  I think the reason it uses "will be" is that the responder will first install the IPsec SA in tunnel mode, then send its IKE_AUTH reply that states to the initiator "no transport mode" so then the initiator "will" have to install the SA in transport mode. To be honest, I don't even know what our implementation currently does, I think it might just send back NO_PROPOSAL_CHOSEN. (We don't like parental SA's without children) Paul From nobody Sat Oct 17 23:33:33 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075371B2D71; Sat, 17 Oct 2015 23:33:32 -0700 (PDT) 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] autolearn=ham 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 iaiolY38ibXB; Sat, 17 Oct 2015 23:33:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC11B2D75; Sat, 17 Oct 2015 23:33:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018063329.7039.78291.idtracker@ietfa.amsl.com> Date: Sat, 17 Oct 2015 23:33:29 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 06:33:32 -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 Working Group of the IETF. Title : Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-00.txt Pages : 7 Date : 2015-10-17 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange protocol provides a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-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 Sun Oct 18 14:09:46 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471EE1AD0C9 for ; Sun, 18 Oct 2015 14:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 gRHja2fmI6iY for ; Sun, 18 Oct 2015 14:09:43 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 5BF8B1AD0C7 for ; Sun, 18 Oct 2015 14:09:43 -0700 (PDT) Received: by ykdz2 with SMTP id z2so41621446ykd.3 for ; Sun, 18 Oct 2015 14:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=zcwV4MCQ1shHr8dtfpcHs/vuEh2eIT9biyl8tc0wsbo=; b=CReZv0mlMY6bUVg97ALVbaiNTJFm6PVORsWAkbS2VjDpegAJ58iJ2q8dQ8Jijw2h9Z 4lxVBdWJol/ylBvsqa0TNZ8ll+QvaEjmoyP+tLzX6Vs5xDFviFHsEFk57gGyswRfM656 ALKRtCA4xaSqCQknxEHaFmFannLJtaYbRSYDU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=zcwV4MCQ1shHr8dtfpcHs/vuEh2eIT9biyl8tc0wsbo=; b=D7xHF20o7ZUzf/gUHrRyzJTfsG5cO3e0losXNTReCok8H+0rU5CtQqe5HS+O0C5WcQ YYm9kUYnD6kFug/vyJ52FtklRk/ZQftp1RP/DCNpR7rq8xEkKEGGLdzLAgT7JZSw2SGu J8KMshpDVE9S9ttfuSMEvT7+/w3S2KEJtwRKoCZh15jyn6bVbICC6ZGFoUsg8www7tMo FP+f3sl+gruiU1W3+g6+VRCiKSN6WwlSGGamEF+wK/WNesEQhuEtL6AJcWX/v13mo3ep BaWsnKT50AeEJ+qN1duXg0HBhXvym97OFhmVzODGaK3CTBgYCFhwjiGmlc5oyWxP+5b2 qGKQ== X-Gm-Message-State: ALoCoQlS5SFObR+Ceo8JERRYXYrf3HP7PfXHLy7ZcYeWUYpagkTh5uUGxyh0n2RzGJeMdhMwobKo X-Received: by 10.129.57.139 with SMTP id g133mr20076847ywa.143.1445202582490; Sun, 18 Oct 2015 14:09:42 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id h81sm6887962ywc.40.2015.10.18.14.09.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Oct 2015 14:09:41 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20151018063329.7039.78291.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 17:09:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34F1A1D1-CAAC-4BC2-B567-5FDFB6A80A5B@sn3rd.com> References: <20151018063329.7039.78291.idtracker@ietfa.amsl.com> To: IPsecME WG X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 21:09:45 -0000 Nits only: 1. This draft should probably obsolete 4307. 2. Couldn=92t hurt to make 4307 an *informative* reference. 3. s3.4: r/[IKEv2]/[RFC7296]=20 4. So I was going to say that you should add [RFC3536] & [RFC4753] as = normative references but I guess the 1st para in s3.1 takes care of all = the algorithm references in the draft. Personally, I think that=92s = fine as long as all the MUST/SHOULDs are either standards track or in = the downref registry (e.g., RFC4753) - and I just clicked throughout = them all and they are. Here=92s to saving trees and not including a ton = of unnecessary references. spt From nobody Tue Oct 20 03:11:34 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F701B3201 for ; Tue, 20 Oct 2015 03:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 eEU_rM7LMlbY for ; Tue, 20 Oct 2015 03:11:28 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 191A61B31FF for ; Tue, 20 Oct 2015 03:11:28 -0700 (PDT) Received: from [192.168.114.1] (235-194.icannmeeting.org [199.91.194.235]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t9KABPBB005405 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Oct 2015 03:11:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 235-194.icannmeeting.org [199.91.194.235] claimed to be [192.168.114.1] From: "Paul Hoffman" To: "IPsecME WG" Date: Tue, 20 Oct 2015 11:11:24 +0100 Message-ID: References: <20151019171017.18302.86429.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Subject: [IPsec] Fwd: Protocol Action: 'Generic Raw Public Key Support for IKEv2' to Proposed Standard (draft-kivinen-ipsecme-oob-pubkey-14.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 10:11:33 -0000 Of interest to the WG Forwarded message: > From: The IESG > To: IETF-Announce > Cc: Kathleen.Moriarty.ietf@gmail.com, > draft-kivinen-ipsecme-oob-pubkey@ietf.org, The IESG , > rfc-editor@rfc-editor.org > Subject: Protocol Action: 'Generic Raw Public Key Support for IKEv2' > to Proposed Standard (draft-kivinen-ipsecme-oob-pubkey-14.txt) > Date: Mon, 19 Oct 2015 10:10:17 -0700 > > The IESG has approved the following document: > - 'Generic Raw Public Key Support for IKEv2' > (draft-kivinen-ipsecme-oob-pubkey-14.txt) as Proposed Standard > > This document has been reviewed in the IETF but is not the product of > an > IETF Working Group. > > The IESG contact person is Kathleen Moriarty. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/ > > > > > > Technical Summary > > The document extends IKEv2 with generic support for multiple > formats of raw public keys. This is expected to be used in IOT > settings and/or setups using DANE. Raw RSA keys were removed > from IKEv2 in its latest iteration (RFC 7296) in anticipation of > this document. > > Working Group Summary > > There was not enough IPsecME WG energy behind the draft, > so it never became a WG document. But the chairs do > support its publication as an AD-sponsored Standards Track > RFC so as not to lose an existing IKEv2 feature > (http://www.ietf.org/mail-archive/web/ipsec/current/msg08358.html). > The document updates RFC 7296. > > Document Quality > > This is a small extension to the protocol and > it was written by experienced IPsec implementors; > moreover, it re-enacts and extends functionality that's > been there for a while. It has had several reviews by > experienced IPsecMe WG participants. > > idnits should a reference to an obsoleted RFC, this is > correct as that is the appropriate reference. > -- Obsolete informational reference (is this intentional?): RFC 5996 > (Obsoleted by RFC 7296) > > Personnel > > The document shepherd is Yaron Sheffer. > The responsible Area Director is Kathleen Moriarty. >