From nobody Wed Feb 1 04:16:45 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3C3129440 for ; Wed, 1 Feb 2017 04:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKLxEYxkkrXX for ; Wed, 1 Feb 2017 04:16:42 -0800 (PST) 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 7396D12994F for ; Wed, 1 Feb 2017 04:16:42 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v11CGeHT020674 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 1 Feb 2017 14:16:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v11CGerg028956; Wed, 1 Feb 2017 14:16:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22673.53672.262474.774171@fireball.acr.fi> Date: Wed, 1 Feb 2017 14:16:40 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 6 min Archived-At: Subject: [IPsec] Early Code Point allocation for INTERNAL_DNS_DOMAIN for draft-pauly-ipsecme-split-dns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 12:16:43 -0000 The authors of the draft-pauly-ipsecme-split-dns has asked the early IANA code point allocation for the INTERNAL_DNS_DOMAIN specified in draft-pauly-ipsecme-split-dns. This request only covers INTERNAL_DNS_DOMAIN and does NOT include INTERNAL_DNSSEC_TA. As a WG chair I have checked the request, and the draft, and I think it fullfills the conditions specified in the RFC7120 section 2 for the early code point allocation: a. The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC. b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field. Including the (d) i.e., I think there is enough interest in the community for the early implementation and deployment of the code point. This email is just to verify that nobody has any objections to this interpretation that there is enough interest in the community. Send your comments to the list if you have anything to say about the early code point allocation request. As this thing was actually requested some time ago, but got hold in vacations etc during the xmas, I do not plan to wait for too long for comments, so please send them ASAP (preferrably by the end of week) so we can start the IANA process for the early allocation soon. -- kivinen@iki.fi From nobody Wed Feb 1 05:24:36 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FC129DF5 for ; Wed, 1 Feb 2017 05:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z33PdSxQ8_5b for ; Wed, 1 Feb 2017 05:24:33 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 66E18129DF3 for ; Wed, 1 Feb 2017 05:24:33 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id c7so16998801itd.1 for ; Wed, 01 Feb 2017 05:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rZnBxhSVe51ot+30Jnx6sGQd1fhID/Q6krslydNoELo=; b=LllOyPGKmARc8HtMsa2UtTj5eVVCDipan8A1DXaDhXQXlQ18vDoxqNw7Z7V3MjLbIQ kVVKULtEcXo4G5nctTU9zTv0H8leuClBMd/dF/et0ZUtWtnNURxRCVnVADY3LQxFopBy cFo39UGBENuHWLpdwJIawv7BQ1vq37yZbMeZQupnsSmFzIBZ1pjHTnZSJly93RPa0KkE 3sP1K1yj/L0IJL/W0rdvxsT0sTXBEjLKCHxw5E9UdirBMBb3+1enHMX524UtFsJdWhXe wKuhgeWuSZvHj7f6rvZ5ZAkKGOB7d6tJy0/TPgLVx0V7KNATdeccB1iG9Ghee1+9XVrD PIDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rZnBxhSVe51ot+30Jnx6sGQd1fhID/Q6krslydNoELo=; b=CHCC0enshy//iH707IWjOOctoxOBhvxJkxC75ggZMmZsIPvXF4XBba2XaPurwBvbRM zORvtQCluubEnmELT8BJ0oCZZG2g6bXXTLVvrEG7dFKGEHvmrZqzqeAd+dxXVi1frpBW uOBmKnXQHrW7zuCGJg3MH11ObOdJTa7e6EQ18TEC3+BRPSRRrYJ/BVctwzyc0DwoP0Rr fjvRd8f9QnqaiveV+rsQ5Uu5Jxp31ol27EbwA72qh+6owKs+1e8FQ9uD7hzAaJsGPOsH NaExt61lnNrDKxgIS999ZkghmJi2a3IpLtDfxgyRZJ7I51cHGhu+nsotREwj0iZlpCvv hmWg== X-Gm-Message-State: AIkVDXLwx/QJohDrk2umczAgOinIc+XZwSIuYrIFnLH93vQRHyqIrtGZwLOSHYe9biORVCG1/nNCluh5biAJAQ== X-Received: by 10.36.164.75 with SMTP id v11mr2238137iti.101.1485955472764; Wed, 01 Feb 2017 05:24:32 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.5.201 with HTTP; Wed, 1 Feb 2017 05:24:32 -0800 (PST) Received: by 10.107.5.201 with HTTP; Wed, 1 Feb 2017 05:24:32 -0800 (PST) In-Reply-To: References: From: Daniel Migault Date: Wed, 1 Feb 2017 08:24:32 -0500 X-Google-Sender-Auth: dRZB7BHyUmJkrsPkV5aNlJpWo6o Message-ID: To: "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary=f403045fbba81b4788054777f884 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption of draft-pauly-ipsecme-split-dns as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 13:24:35 -0000 --f403045fbba81b4788054777f884 Content-Type: text/plain; charset=UTF-8 I support the adoption of this draft. I have reviewed the draft and believe it is in good shape. I am ready for more reviews. Yours Daniel On Jan 30, 2017 15:59, "Waltermire, David A. (Fed)" < david.waltermire@nist.gov> wrote: This is the call for adoption of https://datatracker.ietf.org/ doc/draft-pauly-ipsecme-split-dns/ as an IPSecME working group (WG) document. By adopting this draft, the WG is agreeing to take this on as an official WG item to continue work on the draft. Please reply to this message with any comments supporting or concerns against adopting this draft. This call will run until Friday, February 10th, 2017 UTC 23:59. Thanks, Dave and Tero _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --f403045fbba81b4788054777f884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of this draft. I have reviewed the= draft and believe it is in good shape. I am ready for more reviews.
Yours
Daniel

On Jan 30, 2017 15:59, "Walte= rmire, David A. (Fed)" <david.waltermire@nist.gov> wrote:
This is the call for adoption of https://datatracker.ietf.org/doc/draft-pauly-ipsecme-spli= t-dns/ as an IPSecME working group (WG) document.

By adopting this draft, the WG is agreeing to take this on as an official W= G item to continue work on the draft. Please reply to this message with any= comments supporting or concerns against adopting this draft. This call wil= l run until Friday, February 10th, 2017 UTC 23:59.

Thanks,
Dave and Tero

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

--f403045fbba81b4788054777f884-- From nobody Thu Feb 2 00:01:36 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAA7129406 for ; Thu, 2 Feb 2017 00:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_xnZwMh0qFK for ; Thu, 2 Feb 2017 00:01:33 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 D084A1293F8 for ; Thu, 2 Feb 2017 00:01:32 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x1so4252847lff.0 for ; Thu, 02 Feb 2017 00:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=HcdDo4Vr4qkvjAReqMahNY4cToPivWfKuvBc3ADORMg=; b=Mas3aZkJTXnbnUZTPbCBj+zeoYKNKE+3UrKql4OGqkrOw+ZMbHrA6/o0XlpfybN5lL 3ilQpb+e9BP6nU0FUtK0ru3/+ajX/k7M7aCZEtW9SxxDRRF27AY9WRtwsLYA0lAyRV6R Tsj/wMTMpr9bu8h/Q71bdE+NdnNhBW/jsd2jAyG/pjsr5rAwl/ONbqxZtUXt5lb7FVF/ 0xiMFQE6tuHAoB8XVPJiu7VrassRHJAKc6zic1mfJXb9eoZdOuUQU0cTXKXWCf2Z9LVb qp9CtldBUWLiQH2VHqjYI18N5PlhsHkfMI3COihH48Bk2cUTw0lTUB3ZxZyg9FqBWS9g CGxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=HcdDo4Vr4qkvjAReqMahNY4cToPivWfKuvBc3ADORMg=; b=n6xiqGvuQQjmGSw4m6VzgsQWY/lK2NFjnBtOe5571eodx4nvsCozba8JWucAZCeCWc XX68PNFU3bgV+5QhwqRvlqhStud++xiKL8B4KwdYklHOJXFwG6xP2YpmstXkVz8sSBwE WTkhruvXccGcjlvXTXmPE0+Ncuj/kctaeL2XSoghKDAwZRauRniQipN5KNI2bwyjwzsP 1oSEkD4PJy71BZtyKmQcuPh+gPeEsdP3OZ+2lgSSCjF9ywII8B4SHpNWWaki2Y7TTfqJ RUEOMfdzxqpIZxwhoKjQbhPQ8OvVh/9aRg2sf/6A9KodQi8h7ojJt4qdjl0fNIU6EVbJ iyTw== X-Gm-Message-State: AIkVDXLR67oCi07nzVkN/ZBbTf/yGY+IASsw+vLipLlEjSLpR68sWW40JK5soQYT8EETOA== X-Received: by 10.46.21.23 with SMTP id s23mr2731034ljd.54.1486022491018; Thu, 02 Feb 2017 00:01:31 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id w4sm2448638ljd.23.2017.02.02.00.01.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 00:01:30 -0800 (PST) From: "Valery Smyslov" To: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: In-Reply-To: Date: Thu, 2 Feb 2017 11:01:31 +0300 Message-ID: <0e6301d27d2a$90e9b720$b2bd2560$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMeNBPp1XToUDzY+C2vUV6hEp0zr5697IRA Content-Language: ru Archived-At: Subject: Re: [IPsec] Call for adoption of draft-pauly-ipsecme-split-dns as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 08:01:34 -0000 Hi, I support adoption this document. I think it presents a useful functionality. Regards, Valery. > This is the call for adoption of https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ as an > IPSecME working group (WG) document. > > By adopting this draft, the WG is agreeing to take this on as an official WG item to continue work on the > draft. Please reply to this message with any comments supporting or concerns against adopting this draft. > This call will run until Friday, February 10th, 2017 UTC 23:59. > > Thanks, > Dave and Tero > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 2 04:13:56 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84161129424 for ; Thu, 2 Feb 2017 04:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gceyjswQRo4J for ; Thu, 2 Feb 2017 04:13:53 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 0C2721279EB for ; Thu, 2 Feb 2017 04:13:53 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id z134so7413708lff.3 for ; Thu, 02 Feb 2017 04:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=5PRI9+o5zVAXnmk16UnT5LHCOjFNeotc3ZPpPDoobXs=; b=B/23hOHPGoiYKCxVNeFXOTCJxyWjLQEMFa3iAX0KbsAl7U1JoRzDMqWMsjwkr7r/rw +IeCErfFgqMgvrALFcwHoUmCX8Jm4ER/YWohlDARxk4ToQHnr+LIevnn2sx/q9Vh83Ju QlLDzwXm/Uyv/aWPpYT6dSe4xyEuoqGEiRsj3V1i1jyvo4WLTVAlxN/3YvglU5XZnQyD TTEMi3+MStzfjatqtBMF6qjthUDCoWUNfWb02B6TmBd3JXQzQV/bLxv567h4C7wDGIYz Y1YYScgg7UnlvHYE1RHh/sqqlTd44RZmaS+qM8C2t4m+n3op0p6NEEc60BgvXRp70xOJ j1QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=5PRI9+o5zVAXnmk16UnT5LHCOjFNeotc3ZPpPDoobXs=; b=i21QQhAagf7Nn9/43aN+97RjkqeE9ri+QbRoLo3To1/Ev9Qmsn83aRwvArpc3/6nyq gT7WPMlWtbiCNNF7rBDLDK76n2qq46DTsY4G8hn708Q5gHJ+BI8RTKzK72z3iZsgkGWr vSgfyzQHvk28+V/apgRNGmJYPQdPBae7DgvFsqFZdQav5JAtF7VvRsJUKQPZ6o7KBNLT +vn5dAQJfkkp+zsUZFDY6SGLkb4B1K2vK7A31isetVhK1XP1es6fHaxSeG63Mg49Me2m DozHNWeopk2h24ccJoFTM3IAosuO16TzwxcYldJDqdTXCXH4CCo+TCOKgGhijJes2tXW a9bw== X-Gm-Message-State: AIkVDXLZF44LIORmShFNQcFEhYDz4pAVpuImtXBIV51OhbixfWVuSzNus3IrQlj/1npEcA== X-Received: by 10.25.72.20 with SMTP id v20mr2551171lfa.46.1486037631061; Thu, 02 Feb 2017 04:13:51 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k127sm6556582lfg.10.2017.02.02.04.13.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 04:13:50 -0800 (PST) From: "Valery Smyslov" To: , "'IPsecME WG'" , "'Tero Kivinen'" Date: Thu, 2 Feb 2017 15:13:51 +0300 Message-ID: <0f8601d27d4d$d11e3fa0$735abee0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJ9KqLuE62EAdlYRGSsggck+joBFQ== Content-Language: ru Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:13:54 -0000 Hi, here is my review of draft-ietf-ipsecme-tcp-encaps-05. The draft is in a good shape, but a bit of final polishing is required. 1. The terms "tunnel", "tunneled" are used throughout the document when referring to ESP SA. I think it is technically incorrect, since ESP supports both tunnel and transport modes, so the document should use more appropriate terms like "IPsec SA", "ESP packets" etc. 2. Section 4. This value is only sent once, by the Initiator only, at the beginning of any stream of IKE and ESP messages. If other framing protocols are used within TCP to further encapsulate or encrypt the stream of IKE and ESP messages, the Stream Prefix must be at the start of the Initiator's IKE and ESP message stream within the added protocol layer [Appendix A]. Using "Initiator" is wrong here, since the TCP stream may be re-established after the peers rekeyed IKE SA and changed their roles (so that original Initiator becomes Responder). It either must be "original Initiator" (with all explanations who it is, as in Section 6) or, preferably, "originator of TCP stream" (or smth like that). Actually, "Initiator" is used in a lot of places throughout the document and in most cases it means "original Initiator of the first IKE SA in a series of possible successive rekeys of this SA". It is good to look through all these uses and either clarify this term in all places it is used, or add some para in the beginning of the draft, e.g. like it is done in RFC4555: In this document, the term "initiator" means the party who originally initiated the first IKE_SA (in a series of possibly several rekeyed IKE_SAs); "responder" is the other peer. During the lifetime of the IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA exchanges; in this case, the terms "exchange initiator" and "exchange responder" are used. The term "original initiator" (which in [IKEv2] refers to the party who started the latest IKE_SA rekeying) is not used in this document. I also noticed that both "Initiator" and "initiator" are used in the document (as well as "Responder" and "responder"). It's better to use one form (preferably with capital letter, like in RFC7296). RFC Editor will change them to one form in any case, so you can ease her work a bit. I'd also suggest to introduce some term for the party, that creates TCP session (e.g. "TCP originator") and use it where appropriate, so that IKE roles are clearly distinct from TCP roles. In this case you can get rid of "Initiator" in most places replacing it with "TCP originator". 3. Section 6. When the IKE initiator uses TCP encapsulation for its negotiation,... "its negotiation" is confusing here, since TCP encapsulation is not negotiated. I suggest removing "for its negotiation" completely (or change to "for IKE SA negotiation"). 4. Section 6. Once all SAs have been deleted,... "all SAs" is confusing. Later in this section it is stated that multiple IKE SAs MUST NOT share a single TCP connection. Is this a leftover from an early design? 5. Section 6. If the connection is being used to resume a previous IKE session... For clarity: s/connection/TCP connection 6. Section 6. A responder SHOULD at any given time send packets for an IKE SA and its Child SAs over only one TCP connection. Why only Responder? What about Initiator? I think this requirement is valid for both. 7. Section 6. In order to be considered valid for choosing a TCP connection, an IKE message successfully decrypt and be authenticated, not be a retransmission of a previously received message, and be within the expected window for IKE message IDs. Similarly, an ESP message must pass authentication checks and be decrypted, not be a replay of a previous message. "an IKE message successfully decrypt" - is it OK with the grammar? Shouldn't it be: "an IKE message must be successfully decrypted"? What about ES, I think that it is a good thing to add a requirement, that ESP window size MUST be set to 1 if TCP encapsulation is in use. Larger windows are useless with TCP, since there is no packet reordering. On the other hand, setting window size to 1 will effectively block an attack vector that was described by Tero, when an attacker sends old packet with fake TCP header. If window size is 1, then this packet will be dropped immediately without any changes in the ESP logic. 8. Section 6. Multiple IKE SAs MUST NOT share a single TCP connection. Please add clarification: "unless one of them is a rekey of another, in which case two SAs sharing a single TCP connection coexist for a short period of time" (or smth similar). Regards, Valery. From nobody Thu Feb 2 08:06:14 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 694AC12947A; Thu, 2 Feb 2017 08:06:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148605156539.13830.6416316067398939320.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 08:06:05 -0800 Archived-At: Cc: ipsec@ietf.org, draft-ietf-ipsecme-rfc4307bis.all@ietf.org, ietf@ietf.org Subject: [IPsec] Review of draft-ietf-ipsecme-rfc4307bis-15 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:06:05 -0000 Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. (Apologies for the late submission.) For more information, please see the FAQ at . Document: draft-ietf-ipsecme-rfc4307bis-?? Reviewer: Pete Resnick Review Date: 2017-02-02 IETF LC End Date: 2017-01-31 IESG Telechat date: 2017-02-16 Summary: This document is basically ready, but there are a large number of nits, so many that I would think additional review would be desired. Major issues: None Minor issues: None Nits/editorial comments: [Note: I do not see any particular technical problems with the document, but I don't have expertise in this area. I have listed below many clarifications and fixes to typographical and grammatical errors. (I did not note all of the punctuation errors as none of them left ambiguity.) Normally, I would simply list these as nits/editorial comments and leave it at that. But there are so many of these that I'm a bit concerned that the document did not receive sufficient technical review, given that it went through 15 versions and nobody fixed all of these editorial issues. That said, that is an issue between the AD and the WG.] It seems like section 2 should be moved up above section 1 since these specialized conventions are used in section 1. 1: The second to last sentence is ungrammatical and hard to read. Try this: OLD This document describes the parameters of the IKE protocol and updates the IKEv2 specification because it changes the mandatory to implement authentication algorithms of the section 4 of the RFC7296 by saying RSA key lengths of less than 2048 are SHOULD NOT. NEW This document describes the parameters of the IKE protocol. It also updates the IKEv2 specification because it changes the mandatory to implement authentication algorithms of section 4 of RFC 7296 by saying RSA key lengths of less than 2048 SHOULD NOT be used. END 1.1, first sentence: s/then/than 1.1, last sentence: s/in a separate document/in this separate document. 1.2: The last sentence of the third paragraph repeats what is in the last paragraph of 1.2 and therefore redundant. You can strike it. 2: I suggest adding a sentence after the first paragraph for clarification: "When used in the tables in this document, these terms indicate that the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or MAY be implemented as part of an IKEv2 implementation." 4307 never said that specifically, and I've always found it weird. 3.1, first paragraph: s/an integrity algorithms in Section 3.3/one of the integrity algorithms in Section 3.3 3.1, third paragraph: s/CRFG/the Crypto Forum Research Group (CFRG) of the IRTF (You not only didn't define it, you got the acronym backwards.) 3.1, third from last paragraph: s/on those cases/in those cases 3.1, second from last paragraph: s/implementation/implementations 3.1, last paragraph: s/of-the-shelves/off-the-shelf ; s/therefor/therefore 3.3, last paragraph: s/status ware/statuses were 3.4, third paragraph: s/were/was 3.4, fourth paragraph: s/vulnerable to be broken/vulnerable to being broken 3.4, last paragraph: s/thater/that; s/academia have/academia has 4: s/concerned on/concerned with 4.1, first paragraph: OLD RSA Digital Signature is not recommended for keys smaller then 2048, but since these signatures only have value in real-time, and need no future protection, smaller keys was kept at SHOULD NOT instead of MUST NOT. NEW See section 4.1.1 for a discussion of key length recommendations for use in RSA Digital Signature. END (If you want, include some of the original text in 4.1.1. 4.1, third paragraph: s/it does not/they do not 4.2, paragraphs 1, 2, & 3: s/When Digital Signature authentication/When a Digital Signature authentication ; also, strike the word "then" in the first two paragraphs. From nobody Thu Feb 2 09:03:35 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E9E12989D; Thu, 2 Feb 2017 09:03:34 -0800 (PST) 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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148605501434.13908.11811625866383590414.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 09:03:34 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:03:34 -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 of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Daniel Migault John Mattsson Paul Wouters Yoav Nir Tero Kivinen Filename : draft-ietf-ipsecme-rfc7321bis-03.txt Pages : 13 Date : 2017-02-02 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-03 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 Thu Feb 2 09:10:55 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204381294D7 for ; Thu, 2 Feb 2017 09:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xxCikGLZFKY for ; Thu, 2 Feb 2017 09:10:53 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158481294BA for ; Thu, 2 Feb 2017 09:10:53 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vDmjQ0m5fz3Tb for ; Thu, 2 Feb 2017 18:10:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1486055450; bh=zV3CYHMYDNadb1xKOe4W0QlrsC32cICbGXzb3CiCP0g=; h=Date:From:To:Subject:In-Reply-To:References; b=j8sqUh3uj9vrpVPNcGCWPZrvi7qLoVD6lT09bVZjJkYgIE/ryx2DXaBkuRy4oNG6n jaH3SgzBv9BwQqys9ZmuvtygByGgdNqnL0jSMP76J/32d8OZ2/Zg213rPmq9pGYnH3 /h/KJ9wfIGEKEpnPGndyDOYqKzp5aVBUrYXeQusQ= 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 KI0Slr5hcGXQ for ; Thu, 2 Feb 2017 18:10:48 +0100 (CET) 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 for ; Thu, 2 Feb 2017 18:10:48 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AC9233F284C; Thu, 2 Feb 2017 12:10:41 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca AC9233F284C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A838E41D9263 for ; Thu, 2 Feb 2017 12:10:41 -0500 (EST) Date: Thu, 2 Feb 2017 12:10:41 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <148605501434.13908.11811625866383590414.idtracker@ietfa.amsl.com> Message-ID: References: <148605501434.13908.11811625866383590414.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:10:55 -0000 On Thu, 2 Feb 2017, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-03 Minor editorial changes only based on Tero's feedack. The previous version has the editorial changes and table fix pointed out by Timothy Carlin. https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-02 Paul From nobody Fri Feb 3 13:08:30 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D20129506; Fri, 3 Feb 2017 13:08:26 -0800 (PST) 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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148615610610.4011.4775827779521147331.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2017 13:08:26 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:08:26 -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 of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-06.txt Pages : 22 Date : 2017-02-03 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment as well as ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 3 13:13:46 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FFF129698 for ; Fri, 3 Feb 2017 13:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.655 X-Spam-Level: X-Spam-Status: No, score=-8.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q4SNMx41ihE for ; Fri, 3 Feb 2017 13:13:43 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 022801294FB for ; Fri, 3 Feb 2017 13:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486156422; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q/eMMhHjXx+5X28w2d7ROhcgNsNU4FCMgyAFv8hS8EU=; b=1wuNmAgjt3hnfrSR2lR0joac6NsXM3FrO0jeqdNF8NzRt8jiYpiim1mI0iuyA48Z 3oQbfZ8rJd9KPPIrn5XaQXRSgGzUjKh2JSDCUGXGrqqa0olINV0N7DXoUmjELVeo Q0YlmZYmB7y0wpTyJc7+g5qUZUFlnun0UOJ/TrHD5v+lxQVqIwC3yxBdW2Q3E2Lq KI/SBWrEagfOOaWCPgOyMLIytLN/t1M8lDaTkDXIDsxJriErbBfrusBF5o65wY+j koj7mmpqC+JjmAgp5VjV6PWOhZgDp7GiWkSP1TCQe4gKXNlbXQy4u2ubEKPatQTQ MIXQGCYtYx+9KiHlg1pWJg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id BC.90.21821.682F4985; Fri, 3 Feb 2017 13:13:42 -0800 (PST) X-AuditID: 11973e13-695109a00000553d-d0-5894f286611d Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 30.F1.00867.682F4985; Fri, 3 Feb 2017 13:13:42 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from da0602a-dhcp221.apple.com (da0602a-dhcp221.apple.com [17.226.23.221]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OKT008F2HMU3B40@nwk-mmpp-sz07.apple.com>; Fri, 03 Feb 2017 13:13:42 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <0f8601d27d4d$d11e3fa0$735abee0$@gmail.com> Date: Fri, 03 Feb 2017 13:13:42 -0800 Message-id: <0377D36E-8572-466F-A595-77F2AE5D4A07@apple.com> References: <0f8601d27d4d$d11e3fa0$735abee0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUi2FAYpdv2aUqEwcwvxhb7t7xgszh6/jmb xY0PM9kcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZXz58o2t4K1exe/HKxgb GC+qdDFyckgImEicnnyWtYuRi0NIYC+jxLq3/Uwwif7GVawgtpDAIUaJtx3BIDavgKDEj8n3 WLoYOTiYBeQlDp6XBQkzC2hJfH/UygJRvoxJYuqEIpASYQEJic17EkHCwgLmEtPWNLKD2GwC KhLHv21gBinhFLCQWDXdAyTMIqAq8XbJFEaIiXYSfx+dZgQp4RWwkTi+VgHEFAKa0no3H6RC BKj65rafzBDnykp0L5zGDPKHhMAeNonDb66yTmAUnoXk5FkIJ89CcvICRuZVjEK5iZk5upl5 pnqJBQU5qXrJ+bmbGEEhPt1OeAfj6VVWhxgFOBiVeHgXzJ8SIcSaWFZcmXuIUZqDRUmcNw8k JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXGW+PRljw9ZGLN/dTgfFpN9w+JF6053z5iM2kWF kTZHK189+LH4UIG60YZbcZW6DVPubqquW+r7arv7vyUzdnc839RbGtFy9dDUjKUKa5/8mct7 1C7t6pzNOtPfPLZd3/8/+hb7pG/PrxTcMeJe+uV4LeceFs3benfuhizapnzrmP0njh63btND SizFGYmGWsxFxYkALhfCSVICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42IRbCj+oNv2aUqEwd5WbYv9W16wWRw9/5zN 4saHmWwOzB47Z91l91iy5CeTx+GvC1kCmKO4bFJSczLLUov07RK4Mr58+cZW8Fav4vfjFYwN jBdVuhg5OSQETCT6G1exQthiEhfurWcDsYUEDjFKvO0IBrF5BQQlfky+x9LFyMHBLCAvcfC8 LEiYWUBL4vujVhaI8mVMElMnFIGUCAtISGzekwgSFhYwl5i2ppEdxGYTUJE4/m0DM0gJp4CF xKrpHiBhFgFVibdLpjBCTLST+PvoNCNICa+AjcTxtQogphDQlNa7+SAVIkDVN7f9ZIY4V1ai e+E05gmMgrOQXDkL4cpZSK5cwMi8ilGgKDUnsdJML7GgICdVLzk/dxMjOFQLo3YwNiy3OsQo wMGoxMO7YP6UCCHWxLLiylxgKHAwK4nw+rwECvGmJFZWpRblxxeV5qQWH2JMBrp+IrOUaHI+ MI7ySuINTUwMTIyNzYyNzU3MSRNWEuedJjQxQkggPbEkNTs1tSC1CGYLEwenVANj6M23hV+V WKcoRTRumnf3xlI+W4Po29cWJiSKCM7KZ3BZXuez92NxRqj86vpp7pbXGp/0MrydFJ1ibsy9 lvkHy/v8K3eLbj6MlypKeSBv4JHwKOt0qGnW0uWyq9Nfv527Xa426mPmmw9pNw886Zt84Pem +pS7iwM3ha75GXBh/5f3c9jaDD/XKbEUZyQaajEXFScCAM6IwnaZAgAA Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:13:45 -0000 Hi Valery, Thanks so much for your comments! I have posted a new version of the draft here: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06 Responses inline. Best, Tommy > On Feb 2, 2017, at 4:13 AM, Valery Smyslov wrote: > > Hi, > > here is my review of draft-ietf-ipsecme-tcp-encaps-05. > The draft is in a good shape, but a bit of final polishing is required. > > 1. The terms "tunnel", "tunneled" are used throughout the document > when referring to ESP SA. I think it is technically incorrect, since > ESP supports both tunnel and transport modes, so the document > should use more appropriate terms like "IPsec SA", "ESP packets" etc. Great point. I have removed the references to tunnel, and replaced with SA, generally. > > 2. Section 4. > This value is > only sent once, by the Initiator only, at the beginning of any stream > of IKE and ESP messages. > > If other framing protocols are used within TCP to further encapsulate > or encrypt the stream of IKE and ESP messages, the Stream Prefix must > be at the start of the Initiator's IKE and ESP message stream within > the added protocol layer [Appendix A]. > > Using "Initiator" is wrong here, since the TCP stream may be re-established > after the peers rekeyed IKE SA and changed their roles (so that original > Initiator becomes Responder). It either must be "original Initiator" > (with all explanations who it is, as in Section 6) or, preferably, > "originator of TCP stream" (or smth like that). > > Actually, "Initiator" is used in a lot of places throughout the document > and in most cases it means "original Initiator of the first IKE SA in a series > of possible successive rekeys of this SA". It is good to look through > all these uses and either clarify this term in all places it is used, or add > some para in the beginning of the draft, e.g. like it is done in RFC4555: > > In this document, the term "initiator" means the party who originally > initiated the first IKE_SA (in a series of possibly several rekeyed > IKE_SAs); "responder" is the other peer. During the lifetime of the > IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA > exchanges; in this case, the terms "exchange initiator" and "exchange > responder" are used. The term "original initiator" (which in [IKEv2] > refers to the party who started the latest IKE_SA rekeying) is not > used in this document. > > I also noticed that both "Initiator" and "initiator" are used in the document > (as well as "Responder" and "responder"). It's better to use one form > (preferably with capital letter, like in RFC7296). RFC Editor will change > them to one form in any case, so you can ease her work a bit. I've switched to use the capitalized version of Initiator and Responder. > > I'd also suggest to introduce some term for the party, that creates > TCP session (e.g. "TCP originator") and use it where appropriate, > so that IKE roles are clearly distinct from TCP roles. In this case > you can get rid of "Initiator" in most places replacing it with "TCP originator". I added the terms "TCP Originator" and "TCP Responder" in the terminology section, with an explanation of this distinction. I've used the new terms where appropriate throughout the document. > > 3. Section 6. > When the IKE initiator uses TCP encapsulation for its negotiation,... > > "its negotiation" is confusing here, since TCP encapsulation is not negotiated. > I suggest removing "for its negotiation" completely (or change to "for IKE SA negotiation"). Removed the phrase. > > 4. Section 6. > Once all > SAs have been deleted,... > > "all SAs" is confusing. Later in this section it is stated that multiple IKE SAs > MUST NOT share a single TCP connection. Is this a leftover from an early design? Switched to "Once the SA has been..." > > 5. Section 6. > If the connection is being used to resume a previous IKE session... > > For clarity: s/connection/TCP connection Switched to "if a TCP connection". > > 6. Section 6. > A responder SHOULD at any given time send packets for an IKE SA and > its Child SAs over only one TCP connection. > > Why only Responder? What about Initiator? I think this requirement > is valid for both. Slightly modified the phrasing. The paragraph above describes the Initiator/Originator behavior. > > 7. Section 6. > In order to be considered valid for choosing a TCP > connection, an IKE message successfully decrypt and be authenticated, > not be a retransmission of a previously received message, and be > within the expected window for IKE message IDs. Similarly, an ESP > message must pass authentication checks and be decrypted, not be a > replay of a previous message. > > "an IKE message successfully decrypt" - is it OK with the grammar? > Shouldn't it be: "an IKE message must be successfully decrypted"? Thanks for catching! Fixed. > > What about ES, I think that it is a good thing to add > a requirement, that ESP window size MUST be set to 1 if TCP > encapsulation is in use. Larger windows are useless with TCP, > since there is no packet reordering. On the other hand, setting > window size to 1 will effectively block an attack vector that was described > by Tero, when an attacker sends old packet with fake TCP header. > If window size is 1, then this packet will be dropped immediately > without any changes in the ESP logic. Added this recommendation to the security considerations. > > 8. Section 6. > Multiple IKE SAs MUST NOT share a single TCP connection. > > Please add clarification: "unless one of them is a rekey of another, > in which case two SAs sharing a single TCP connection coexist for > a short period of time" (or smth similar). Added the clarification. > > Regards, > Valery. > From nobody Tue Feb 7 05:55:12 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16743129C18 for ; Tue, 7 Feb 2017 05:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.096 X-Spam-Level: * X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.795, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht4YQ-SUhOO5 for ; Tue, 7 Feb 2017 05:54:56 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 6D3B0129547 for ; Tue, 7 Feb 2017 05:54:56 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id z134so63314599lff.3 for ; Tue, 07 Feb 2017 05:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=GwrFBfvJZejBIYgZM8YAZW8aIiKUq8t62wOI1rv/89k=; b=PEZzz/tSY6DyhXQvUOuExLLDjas/Jp981Xm7v4j1dTnViAAUG0EVixZP2ohojnIAOu cNxuIo11yJBRuSWyxxLNY7pj2jLwrcTDL1Iq0/iSvDomvAmoN5JtmcW3DnW4Q5EYiYwA ogL2zzKDRsIsWA7qQjIhnE9QVkxJ+tDVr7gJ9OEl+g9QzH9msRzEbuTnFR+Tk8AR7liR NCth3qNksm6iHgihiWFwbljH4CvSeQVcPAqhLS1R3D+gAuKp4eLRTlSpFiS5mfP0iZpF AXw7tXMhC0H0vmNs/RPrKje5wdF3UOrPl/Em/WUTDTn2jxAjR+JASdErb+Z+GrUj4A81 hiAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=GwrFBfvJZejBIYgZM8YAZW8aIiKUq8t62wOI1rv/89k=; b=udNa4nHmxL4SDrP/IOsQW+1EWRRHpGtJ6o6OkLakARoKFYpSzeDEsMXo8BrgsK1j8h UtT27FvK3nQnV79DuhshZXqDizUX2KPFbr3ilGGyHKbUjntC8+uTh40hMtY5LecWuyDg 60xLcMm6F7lDxSueiQdtTqJQSn4joHuN3iHSkqGlS7PhxCCqZmg5bg06jBqI3FY5o5JM HG9BrmvK/7pVBOaQqDskn/0dLAIVuYKh5Wovlk5gEpzbdiLahMABcvl2hpFKFX6fBPWg ZN8eeYxtQSoJ0Kx9GI7OM9kV9gEdzZw0Q8+30QbbfzFUlfGX3m+7zUag7Pt4x2PwxqSR mm8w== X-Gm-Message-State: AIkVDXLLtQSB8bHG01ZJgWXz1V1sMmvFqqkjdxq8T2DJ+FUHqs/Gjj7fYjQZI/oI3dMZnQ== X-Received: by 10.46.80.16 with SMTP id e16mr6343527ljb.33.1486475694353; Tue, 07 Feb 2017 05:54:54 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e23sm1365704lji.29.2017.02.07.05.54.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Feb 2017 05:54:53 -0800 (PST) From: "Valery Smyslov" To: References: <0f8601d27d4d$d11e3fa0$735abee0$@gmail.com> <0377D36E-8572-466F-A595-77F2AE5D4A07@apple.com> In-Reply-To: <0377D36E-8572-466F-A595-77F2AE5D4A07@apple.com> Date: Tue, 7 Feb 2017 16:54:53 +0300 Message-ID: <132a01d28149$c28186f0$478494d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ1kjyl2UehsnZQ/HuYkoZaC5JIRQJHvxFyoAUpRoA= Content-Language: ru Archived-At: Cc: 'IPsecME WG' , 'Tero Kivinen' Subject: Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:55:02 -0000 Hi Tommy, thank you for the quick update. A couple nits: 1. Section 1.2: s/the the/the 2. Section 1.2: The TCP Originator MUST be the same as the "Original Initiator", or the Initiator of the first IKE SA exchange for a given IKE session. Again, this is confusing. In RFC7296 the term " Original Initiator" is defined as: The "original initiator always refers to the party who initiated the exchange that resulted in the current IKE SA. In other words, if the "original responder" starts rekeying the IKE SA, that party becomes the "original initiator" of the new IKE SA." "the Initiator of the first IKE SA exchange for a given IKE session" is also wrong, since IKE session means IKE SA and it can be a rekey of previous IKE SA when entities swap their original roles. This is now what we want it to mean, so an additional clarification is needed. Something along the lines: The TCP Originator MUST be the same as the entity who originally initiated the first IKE SA (in a series of possibly several rekeyed IKE SAs). Otherwise it looks good. Regards, Valery. > Hi Valery, > > Thanks so much for your comments! I have posted a new version of the draft here: > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06 > > Responses inline. > > Best, > Tommy > > > On Feb 2, 2017, at 4:13 AM, Valery Smyslov wrote: > > > > Hi, > > > > here is my review of draft-ietf-ipsecme-tcp-encaps-05. > > The draft is in a good shape, but a bit of final polishing is required. > > > > 1. The terms "tunnel", "tunneled" are used throughout the document > > when referring to ESP SA. I think it is technically incorrect, since > > ESP supports both tunnel and transport modes, so the document > > should use more appropriate terms like "IPsec SA", "ESP packets" etc. > > Great point. I have removed the references to tunnel, and replaced with SA, generally. > > > > > 2. Section 4. > > This value is > > only sent once, by the Initiator only, at the beginning of any stream > > of IKE and ESP messages. > > > > If other framing protocols are used within TCP to further encapsulate > > or encrypt the stream of IKE and ESP messages, the Stream Prefix must > > be at the start of the Initiator's IKE and ESP message stream within > > the added protocol layer [Appendix A]. > > > > Using "Initiator" is wrong here, since the TCP stream may be re-established > > after the peers rekeyed IKE SA and changed their roles (so that original > > Initiator becomes Responder). It either must be "original Initiator" > > (with all explanations who it is, as in Section 6) or, preferably, > > "originator of TCP stream" (or smth like that). > > > > Actually, "Initiator" is used in a lot of places throughout the document > > and in most cases it means "original Initiator of the first IKE SA in a series > > of possible successive rekeys of this SA". It is good to look through > > all these uses and either clarify this term in all places it is used, or add > > some para in the beginning of the draft, e.g. like it is done in RFC4555: > > > > In this document, the term "initiator" means the party who originally > > initiated the first IKE_SA (in a series of possibly several rekeyed > > IKE_SAs); "responder" is the other peer. During the lifetime of the > > IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA > > exchanges; in this case, the terms "exchange initiator" and "exchange > > responder" are used. The term "original initiator" (which in [IKEv2] > > refers to the party who started the latest IKE_SA rekeying) is not > > used in this document. > > > > I also noticed that both "Initiator" and "initiator" are used in the document > > (as well as "Responder" and "responder"). It's better to use one form > > (preferably with capital letter, like in RFC7296). RFC Editor will change > > them to one form in any case, so you can ease her work a bit. > > I've switched to use the capitalized version of Initiator and Responder. > > > > > I'd also suggest to introduce some term for the party, that creates > > TCP session (e.g. "TCP originator") and use it where appropriate, > > so that IKE roles are clearly distinct from TCP roles. In this case > > you can get rid of "Initiator" in most places replacing it with "TCP originator". > > I added the terms "TCP Originator" and "TCP Responder" in the terminology section, with an explanation of > this distinction. I've used the new terms where appropriate throughout the document. > > > > > 3. Section 6. > > When the IKE initiator uses TCP encapsulation for its negotiation,... > > > > "its negotiation" is confusing here, since TCP encapsulation is not negotiated. > > I suggest removing "for its negotiation" completely (or change to "for IKE SA negotiation"). > > Removed the phrase. > > > > > 4. Section 6. > > Once all > > SAs have been deleted,... > > > > "all SAs" is confusing. Later in this section it is stated that multiple IKE SAs > > MUST NOT share a single TCP connection. Is this a leftover from an early design? > > Switched to "Once the SA has been..." > > > > > 5. Section 6. > > If the connection is being used to resume a previous IKE session... > > > > For clarity: s/connection/TCP connection > > Switched to "if a TCP connection". > > > > > 6. Section 6. > > A responder SHOULD at any given time send packets for an IKE SA and > > its Child SAs over only one TCP connection. > > > > Why only Responder? What about Initiator? I think this requirement > > is valid for both. > > Slightly modified the phrasing. The paragraph above describes the Initiator/Originator behavior. > > > > > 7. Section 6. > > In order to be considered valid for choosing a TCP > > connection, an IKE message successfully decrypt and be authenticated, > > not be a retransmission of a previously received message, and be > > within the expected window for IKE message IDs. Similarly, an ESP > > message must pass authentication checks and be decrypted, not be a > > replay of a previous message. > > > > "an IKE message successfully decrypt" - is it OK with the grammar? > > Shouldn't it be: "an IKE message must be successfully decrypted"? > > Thanks for catching! Fixed. > > > > > What about ES, I think that it is a good thing to add > > a requirement, that ESP window size MUST be set to 1 if TCP > > encapsulation is in use. Larger windows are useless with TCP, > > since there is no packet reordering. On the other hand, setting > > window size to 1 will effectively block an attack vector that was described > > by Tero, when an attacker sends old packet with fake TCP header. > > If window size is 1, then this packet will be dropped immediately > > without any changes in the ESP logic. > > Added this recommendation to the security considerations. > > > > > 8. Section 6. > > Multiple IKE SAs MUST NOT share a single TCP connection. > > > > Please add clarification: "unless one of them is a rekey of another, > > in which case two SAs sharing a single TCP connection coexist for > > a short period of time" (or smth similar). > > Added the clarification. > > > > > Regards, > > Valery. > > From nobody Tue Feb 7 09:44:24 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE660129DEB for ; Tue, 7 Feb 2017 09:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhiyR-7IKozj for ; Tue, 7 Feb 2017 09:44:20 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 E1A2A129592 for ; Tue, 7 Feb 2017 09:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486489460; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mO7qa7JL5WrW/n/IrJSx0KADlmaKzV92aJPIlloEavI=; b=PoIYjy8cBRZ9QgWAdF3C1oxPkfHett1vrxkrtaH1a4HazmxEzcgM6kwP3OCsjm8U V5uHzy3IiNrL/7gQOGeEiSy25tRcgGJpJrnKZWhNsKCEyJA7ZCkoBijde8x76iYa dUWNTEAUBHoECq2VqcdxzmFu2EwnJ8VaMm/R5I1ro/hP3zJSmdnpH4I4KYeDRIjZ siVcCSbzQVBI9iG2sjZnKsdXUHfnrqBgud5X8ZzSQeAByYXA+Gggqj52Rms+nKWC Ks5mCu/75QEzSWxPuxy+a6T8mxxUcWWc3y8lIZfnsmTDDCxrmS9P8NIRhNOikKWg CmtcYplYzDTzxXJY+sfhiA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 86.52.21821.4770A985; Tue, 7 Feb 2017 09:44:20 -0800 (PST) X-AuditID: 11973e13-695109a00000553d-09-589a0774626c Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay8.apple.com (Apple SCV relay) with SMTP id 31.25.12381.4770A985; Tue, 7 Feb 2017 09:44:20 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.26.34] (unknown [17.153.26.34]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Dec 14 2016)) with ESMTPSA id <0OL000JW0MLVXG10@nwk-mmpp-sz07.apple.com>; Tue, 07 Feb 2017 09:44:20 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <132a01d28149$c28186f0$478494d0$@gmail.com> Date: Tue, 07 Feb 2017 09:44:19 -0800 Message-id: <9C8B0C3E-8533-488D-A2A7-2F13AAC4C1B4@apple.com> References: <0f8601d27d4d$d11e3fa0$735abee0$@gmail.com> <0377D36E-8572-466F-A595-77F2AE5D4A07@apple.com> <132a01d28149$c28186f0$478494d0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FCYplvCPivCYMdxTYv9W16wWRw9/5zN 4saHmWwOzB47Z91l91iy5CeTx+GvC1kCmKO4bFJSczLLUov07RK4Mm7tvc1UMM++Yse2FvYG xquGXYycHBICJhIrPlxkA7GFBPYxSjS/zIeJH185i7WLkQsofohR4uCbZ6wgCV4BQYkfk++x dDFycDALyEscPC8LEmYW0JL4/qiVBaK+g0ni4a8uNpAaYQEJic17EkFqhAXsJRZNWsACYrMJ qEgc/7aBGaSEU8BCYut7Y5Awi4CqxM3222wQI+0k/j46zQix1UbiVsslNojxMxgltq6EOEcE pGHbT2aIm2UluhdOYwYpkhDYwyYxrfE+ywRG4VlIzp6FcPYsJGcvYGRexSiUm5iZo5uZZ6qX WFCQk6qXnJ+7iREU6tPthHcwnl5ldYhRgINRiYc3o2NGhBBrYllxZe4hRmkOFiVxXn6TmRFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGBcZya/wEWDhXm/g/P/N/iV1ts6JjZFLtdZ7Oy54 dGvVxvXzRP/vmFQg/sC2QOSZk7WvRnml+IflR5+35v829Vhurtl//PqLNd2afyO8g7qUpszv UfjjmLVo7uVaG5OtYqerFbz9Xr08dnX5zWblC3Hlj+aFb9rcF3+xWq3o2qz7RkliHyLyypRY ijMSDbWYi4oTAeMe2IVWAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRbCj+oFvCPivCYGarisX+LS/YLI6ef85m cePDTDYHZo+ds+6yeyxZ8pPJ4/DXhSwBzFFcNimpOZllqUX6dglcGbf23mYqmGdfsWNbC3sD 41XDLkZODgkBE4njK2exQthiEhfurWfrYuTiEBI4xChx8M0zsASvgKDEj8n3WLoYOTiYBeQl Dp6XBQkzC2hJfH/UygJR38Ek8fBXFxtIjbCAhMTmPYkgNcIC9hKLJi1gAbHZBFQkjn/bwAxS wilgIbH1vTFImEVAVeJm+202iJF2En8fnWaE2GojcavlEtQ5Mxgltq6EOEcEpGHbT2aIm2Ul uhdOY57AKDgLyaWzEC6dheTSBYzMqxgFilJzEist9BILCnJS9ZLzczcxgoO2MG0HY9Nyq0OM AhyMSjy8GR0zIoRYE8uKK3OBQcHBrCTCO+vjzAgh3pTEyqrUovz4otKc1OJDjMlAD0xklhJN zgdGVF5JvKGJiYGJsbGZsbG5iTlpwkrivJ77gbYKpCeWpGanphakFsFsYeLglGpgnP0z9XRZ 3h3FLT03+mt2PJe8mex0VUOiJDt3xYb18t2V+49vFJA07JvpvGnJRc+TXfw+ruLGHQfchOeH /+79UPOyyjPQ6Ovqa7J9qzb6Zd6ZdDdWRDU4jstosb8N6/LpAnE1M3tzjV+9zdW7eeKdSMgG thCNlZ8Dlk2aMnOK9PSe6iU9N9OfKrEUZyQaajEXFScCAOdcg1aeAgAA Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:44:23 -0000 Hi Valery, Thanks for the feedback! I'll clarify that the TCP Originator is the same as the original initiator of the first IKE SA, as well as fixing the typographical errors. If anyone else has more feedback, please chime in! I'll wait a day or so before updating the draft, to batch any other changes that should be made. Thanks, Tommy > On Feb 7, 2017, at 5:54 AM, Valery Smyslov wrote: > > Hi Tommy, > > thank you for the quick update. A couple nits: > > 1. Section 1.2: > s/the the/the > > 2. Section 1.2: > The TCP > Originator MUST be the same as the "Original Initiator", or the > Initiator of the first IKE SA exchange for a given IKE session. > > Again, this is confusing. In RFC7296 the term " Original Initiator" is defined as: > The "original initiator > always refers to the party who initiated the exchange that resulted > in the current IKE SA. In other words, if the "original responder" > starts rekeying the IKE SA, that party becomes the "original > initiator" of the new IKE SA." > > "the Initiator of the first IKE SA exchange for a given IKE session" is also > wrong, since IKE session means IKE SA and it can be a rekey of previous > IKE SA when entities swap their original roles. > > This is now what we want it to mean, so an additional clarification is needed. > Something along the lines: > > The TCP Originator MUST be the same as the entity who originally > initiated the first IKE SA (in a series of possibly several rekeyed > IKE SAs). > > Otherwise it looks good. > > Regards, > Valery. > >> Hi Valery, >> >> Thanks so much for your comments! I have posted a new version of the draft here: >> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06 >> >> Responses inline. >> >> Best, >> Tommy >> >>> On Feb 2, 2017, at 4:13 AM, Valery Smyslov wrote: >>> >>> Hi, >>> >>> here is my review of draft-ietf-ipsecme-tcp-encaps-05. >>> The draft is in a good shape, but a bit of final polishing is required. >>> >>> 1. The terms "tunnel", "tunneled" are used throughout the document >>> when referring to ESP SA. I think it is technically incorrect, since >>> ESP supports both tunnel and transport modes, so the document >>> should use more appropriate terms like "IPsec SA", "ESP packets" etc. >> >> Great point. I have removed the references to tunnel, and replaced with SA, generally. >> >>> >>> 2. Section 4. >>> This value is >>> only sent once, by the Initiator only, at the beginning of any stream >>> of IKE and ESP messages. >>> >>> If other framing protocols are used within TCP to further encapsulate >>> or encrypt the stream of IKE and ESP messages, the Stream Prefix must >>> be at the start of the Initiator's IKE and ESP message stream within >>> the added protocol layer [Appendix A]. >>> >>> Using "Initiator" is wrong here, since the TCP stream may be re-established >>> after the peers rekeyed IKE SA and changed their roles (so that original >>> Initiator becomes Responder). It either must be "original Initiator" >>> (with all explanations who it is, as in Section 6) or, preferably, >>> "originator of TCP stream" (or smth like that). >>> >>> Actually, "Initiator" is used in a lot of places throughout the document >>> and in most cases it means "original Initiator of the first IKE SA in a series >>> of possible successive rekeys of this SA". It is good to look through >>> all these uses and either clarify this term in all places it is used, or add >>> some para in the beginning of the draft, e.g. like it is done in RFC4555: >>> >>> In this document, the term "initiator" means the party who originally >>> initiated the first IKE_SA (in a series of possibly several rekeyed >>> IKE_SAs); "responder" is the other peer. During the lifetime of the >>> IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA >>> exchanges; in this case, the terms "exchange initiator" and "exchange >>> responder" are used. The term "original initiator" (which in [IKEv2] >>> refers to the party who started the latest IKE_SA rekeying) is not >>> used in this document. >>> >>> I also noticed that both "Initiator" and "initiator" are used in the document >>> (as well as "Responder" and "responder"). It's better to use one form >>> (preferably with capital letter, like in RFC7296). RFC Editor will change >>> them to one form in any case, so you can ease her work a bit. >> >> I've switched to use the capitalized version of Initiator and Responder. >> >>> >>> I'd also suggest to introduce some term for the party, that creates >>> TCP session (e.g. "TCP originator") and use it where appropriate, >>> so that IKE roles are clearly distinct from TCP roles. In this case >>> you can get rid of "Initiator" in most places replacing it with "TCP originator". >> >> I added the terms "TCP Originator" and "TCP Responder" in the terminology section, with an > explanation of >> this distinction. I've used the new terms where appropriate throughout the document. >> >>> >>> 3. Section 6. >>> When the IKE initiator uses TCP encapsulation for its negotiation,... >>> >>> "its negotiation" is confusing here, since TCP encapsulation is not negotiated. >>> I suggest removing "for its negotiation" completely (or change to "for IKE SA negotiation"). >> >> Removed the phrase. >> >>> >>> 4. Section 6. >>> Once all >>> SAs have been deleted,... >>> >>> "all SAs" is confusing. Later in this section it is stated that multiple IKE SAs >>> MUST NOT share a single TCP connection. Is this a leftover from an early design? >> >> Switched to "Once the SA has been..." >> >>> >>> 5. Section 6. >>> If the connection is being used to resume a previous IKE session... >>> >>> For clarity: s/connection/TCP connection >> >> Switched to "if a TCP connection". >> >>> >>> 6. Section 6. >>> A responder SHOULD at any given time send packets for an IKE SA and >>> its Child SAs over only one TCP connection. >>> >>> Why only Responder? What about Initiator? I think this requirement >>> is valid for both. >> >> Slightly modified the phrasing. The paragraph above describes the Initiator/Originator behavior. >> >>> >>> 7. Section 6. >>> In order to be considered valid for choosing a TCP >>> connection, an IKE message successfully decrypt and be authenticated, >>> not be a retransmission of a previously received message, and be >>> within the expected window for IKE message IDs. Similarly, an ESP >>> message must pass authentication checks and be decrypted, not be a >>> replay of a previous message. >>> >>> "an IKE message successfully decrypt" - is it OK with the grammar? >>> Shouldn't it be: "an IKE message must be successfully decrypted"? >> >> Thanks for catching! Fixed. >> >>> >>> What about ES, I think that it is a good thing to add >>> a requirement, that ESP window size MUST be set to 1 if TCP >>> encapsulation is in use. Larger windows are useless with TCP, >>> since there is no packet reordering. On the other hand, setting >>> window size to 1 will effectively block an attack vector that was described >>> by Tero, when an attacker sends old packet with fake TCP header. >>> If window size is 1, then this packet will be dropped immediately >>> without any changes in the ESP logic. >> >> Added this recommendation to the security considerations. >> >>> >>> 8. Section 6. >>> Multiple IKE SAs MUST NOT share a single TCP connection. >>> >>> Please add clarification: "unless one of them is a rekey of another, >>> in which case two SAs sharing a single TCP connection coexist for >>> a short period of time" (or smth similar). >> >> Added the clarification. >> >>> >>> Regards, >>> Valery. >>> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Feb 8 05:41:16 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA0129A59 for ; Wed, 8 Feb 2017 05:41:15 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRpilVOhbEfV for ; Wed, 8 Feb 2017 05:41:14 -0800 (PST) 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 942D1129A60 for ; Wed, 8 Feb 2017 05:41:13 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v18DfAn4022847 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 Feb 2017 15:41:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v18DfA7P012746; Wed, 8 Feb 2017 15:41:10 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22683.8182.349840.103676@fireball.acr.fi> Date: Wed, 8 Feb 2017 15:41:10 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Subject: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:41:15 -0000 This message will start two week working group last call for the draft-nir-ipsecme-eddsa-00 [1] draft. Please send your comments, questions etc to WG mailing list before 2017-02-24. If you belive that the document is ready to be submitted to the IESG for consideration as a standard track RFC please send a short message stating this also. This document has been mostly ready for some time, but we have been waiting for curdle and cfrg to do some work needed for this. Firstly we needed to get oids from the curdle, and the draft-ietf-curdle-pkix-03 [2] allocating the oids is in the WGLC in curdle WG. Secondly we have been waiting for the CFRG to decide wheter we should use contextes or not. This is same issue than in the TLS wg, so we go with the same resolution. CFRG has now decided [3] that no contexes is used in TLS case, and as IPsec is in similar situation, we go with that. So as those things we have been waiting for, are now cleared this document can now go forward. [1] https://datatracker.ietf.org/doc/draft-nir-ipsecme-eddsa/ [2] https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ [3] https://www.ietf.org/mail-archive/web/cfrg/current/msg08934.html -- kivinen@iki.fi From nobody Wed Feb 8 05:45:28 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11818129A7F for ; Wed, 8 Feb 2017 05:45:27 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b058aFGK1-NF for ; Wed, 8 Feb 2017 05:45:26 -0800 (PST) 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 30D03129A72 for ; Wed, 8 Feb 2017 05:45:26 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v18DjOba015526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 Feb 2017 15:45:24 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v18DjObl016466; Wed, 8 Feb 2017 15:45:24 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22683.8436.17422.21276@fireball.acr.fi> Date: Wed, 8 Feb 2017 15:45:24 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] Meeting in the Chicago IETF 98 and agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:45:27 -0000 I think we have still enough drafts going forward and work to do that is useful for us to meet in the Chicago. I am planning to put in a request for one 1.5 hour session, but if someone has some other agenda items which are not in our current items to be worked on (rfc4307bis, rfc7321bis, eddsa, tcp-encaps, QR, split-dns, implicit-iv) then send agenda request to us, and we will see what we can do. -- kivinen@iki.fi From nobody Wed Feb 8 07:55:34 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89C7129BF3 for ; Wed, 8 Feb 2017 07:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vheX4hqo0K-h for ; Wed, 8 Feb 2017 07:55:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A1D129BED for ; Wed, 8 Feb 2017 07:55:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C3E45B80F7C; Wed, 8 Feb 2017 07:55:31 -0800 (PST) To: charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, david.waltermire@nist.gov, kivinen@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170208155531.C3E45B80F7C@rfc-editor.org> Date: Wed, 8 Feb 2017 07:55:31 -0800 (PST) Archived-At: Cc: ipsec@ietf.org, text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, charset=UTF-8@rfc-editor.org, nmalykh@gmail.com Subject: [IPsec] [Editorial Errata Reported] RFC7296 (4930) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:55:33 -0000 The following errata report has been submitted for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7296&eid=4930 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3.16 Original Text ------------- Note that since IKE passes an indication of initiator identity in the first message in the IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity requests. The initiator MAY, however, respond to such requests if it receives them. Corrected Text -------------- Notes ----- The last sentence of this section contains unnecessary repetition written above (the last sentence in description of Type field). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Feb 8 11:02:27 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EE7129D90 for ; Wed, 8 Feb 2017 11:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYjT-v-of7U6 for ; Wed, 8 Feb 2017 11:02:25 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 7F306129DCC for ; Wed, 8 Feb 2017 11:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486580503; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=noeapH+j3Vs842UnNMj2gOYmoRQ8XVvJdWHFfn7yL4s=; b=vMKnvTwhkedDXe8sJAzfjASYIflmAqfbxYurYC3v+FkxbsnEzNwmTzUHHep6NEas dG2M07Ah8Qn76D91Jt7Shi5XFZGfPDLKkKMq13Xm5IHw4F5RA0XUuL8/qD0jy12O 0TuYIERv0vaBXT+Ov1xd+LA7t2Mvand/BZms1GapZTwiIKm5ZtlJKzVslx54xgoH Fq1x7pQdKByz1LwoGKhuS8hvxyAUubyqvU3ByonPS8r4b6Bi/0239CZclyXIIpy4 0aCN6/1HE3Am6W5ffPdt38LzIxtWmgWDJQ12JMvtIddkXpdhhHxXOG+T1y+h9Gsm XWMjf0KW+glf9cgr0G4Now==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 70.F5.21821.71B6B985; Wed, 8 Feb 2017 11:01:43 -0800 (PST) X-AuditID: 11973e13-695109a00000553d-01-589b6b172cfb Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay5.apple.com (Apple SCV relay) with SMTP id 47.16.05881.71B6B985; Wed, 8 Feb 2017 11:01:43 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.90.196] (unknown [17.153.90.196]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Dec 14 2016)) with ESMTPSA id <0OL200ICRKUT1D20@nwk-phonehomebzp-sz01.apple.com>; Wed, 08 Feb 2017 11:01:43 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <22683.8182.349840.103676@fireball.acr.fi> Date: Wed, 08 Feb 2017 11:01:43 -0800 Message-id: References: <22683.8182.349840.103676@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FAYoSuePTvCYNYlEYv9W16wWRw9/5zN gcljyZKfTB6Hvy5kCWCK4rJJSc3JLEst0rdL4Mp4M/MTW8E3vorJ9yYzNzA28HQxcnJICJhI rNzWx9LFyMUhJLCXUeLsjAY2mMSm77OBEhxAiWOMEm98QcK8AoISPybfAwszC8hLHDwvCxJm FtCS+P6oFWrMLCaJtsuTmUESwgLSEl0X7rJC2P4Sl5ftZATpZQNqOLDGCCTMKWAusWjRfLAS FgFViTP7LjNCzBSSWLhgKyPEWhuJR48fgY0UEjCT2H9sIguILSKgKLH7yVYmiItlJT49/8kO YW9gk1i5W3QCo/AsJFfPQrh6FpKrFzAyr2IUyk3MzNHNzDPVSywoyEnVS87P3cQICunpdsI7 GE+vsjrEKMDBqMTDe8F6doQQa2JZcWXuIUZpDhYlcV5+k5kRQgLpiSWp2ampBalF8UWlOanF hxiZODilGhi9m0U15slHuWo83dOyqUyrRiYh1HvC6ltcJrPvzniiPFGEYXvNju2lV0NCOZNS azIyUh6+Nzc9ZuR8V8s7vZt71juhCQvcGzzsfqyrXn9KqPID1yw1pyiVEjM+q/L7zi3CIZ53 b22pXZKyhb+G+T8/1wQ9fv5gg3DPTdkzZoQdTHeZ7uKkoMRSnJFoqMVcVJwIAFVT3FBKAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUiON3OQVc8e3aEwY2rAhb7t7xgszh6/jmb A5PHkiU/mTwOf13IEsAUxWWTkpqTWZZapG+XwJXxZuYntoJvfBWT701mbmBs4Oli5OSQEDCR 2PR9NguELSZx4d56ti5GDg4hgWOMEm98QcK8AoISPybfYwEJMwvISxw8LwsSZhbQkvj+qBUo zAVUPYtJou3yZGaQhLCAtETXhbusELa/xOVlOxlBetmAGg6sMQIJcwqYSyxaNB+shEVAVeLM vsuMEDOFJBYu2MoIsdZG4tHjR2AjhQTMJPYfmwh2pYiAosTuJ1uZIC6Wlfj0/Cf7BEbBWUgu nYVw6Swkly5gZF7FKFCUmpNYaaqXWFCQk6qXnJ+7iREUnA2FETsY/y+zOsQowMGoxMN7wXp2 hBBrYllxZe4hRgkOZiUR3jlJQCHelMTKqtSi/Pii0pzU4kOMyUD3T2SWEk3OB0ZOXkm8oYmJ gYmxsZmxsbmJOWnCSuK8nvtnRAgJpCeWpGanphakFsFsYeLglGpgNFgw6U1J29RDcT27DW/t vPuY037h9bnzpB3ntmXdV680PFL+YoeiRNNuve7IA2XJrwwCfkesS2l+1ZnGKFj4YEE0R3He g+RVDrP3rvh9YrG0U9c59jj9RwauLnkH573xkjn9t5ln8a4bws/YfA8cqAnq2fVFMChs0lPJ VfnW+d9n/f7rwf25RImlOCPRUIu5qDgRAHMUMHKSAgAA Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:02:26 -0000 Tero, I've reviewed this draft. I support it and believe it is ready to move forward towards becoming a standards-track RFC. Also, would it make sense to ask IANA for early assignment of the code point? Using 0 sounds reasonable to me. Minor typo in the introduction: "we define a new value has in the SIGNATURE_HASH_ALGORITHMS notification," s/value has in/value hash in/ Thanks, David > On Feb 8, 2017, at 05:41, Tero Kivinen wrote: > > This message will start two week working group last call for the > draft-nir-ipsecme-eddsa-00 [1] draft. > > Please send your comments, questions etc to WG mailing list before > 2017-02-24. If you belive that the document is ready to be submitted > to the IESG for consideration as a standard track RFC please send a > short message stating this also. > > This document has been mostly ready for some time, but we have been > waiting for curdle and cfrg to do some work needed for this. Firstly > we needed to get oids from the curdle, and the > draft-ietf-curdle-pkix-03 [2] allocating the oids is in the WGLC in > curdle WG. > > Secondly we have been waiting for the CFRG to decide wheter we should > use contextes or not. This is same issue than in the TLS wg, so we go > with the same resolution. CFRG has now decided [3] that no contexes is > used in TLS case, and as IPsec is in similar situation, we go with > that. > > So as those things we have been waiting for, are now cleared this > document can now go forward. > > [1] https://datatracker.ietf.org/doc/draft-nir-ipsecme-eddsa/ > [2] https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > [3] https://www.ietf.org/mail-archive/web/cfrg/current/msg08934.html > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Feb 8 11:15:16 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33752129E13 for ; Wed, 8 Feb 2017 11:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X6UX2UTBXYB for ; Wed, 8 Feb 2017 11:15:13 -0800 (PST) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 078E9129D9C for ; Wed, 8 Feb 2017 11:14:50 -0800 (PST) Received: by mail-wr0-x244.google.com with SMTP id k90so9609256wrc.3 for ; Wed, 08 Feb 2017 11:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IdmfKu0zqydDcpve3SS/al5n8XAgDbO9+cMxsm4ebYA=; b=M/2TXVyApBHFApF8HstSX2jKh4XIjXNQsM93ABwPgLjiZnC4ZFiywLIsxhqI6i5Dsq PUQkSshAqFyp+MzWib24RALJX5XhJTFGrnBeTevzXhFonecZSEOlrpOGJFIWDPlBjGg6 wZpmCuQ1eX5K8UDbnizaWmgXX6US7sLAwtPL9gt0Q4/8u7HDQd22nkcGC5UgC+Co1S/+ gA/bOSd5NwO9wGI7Its3wgxrYpu2Z3DoZZTwIJ1GmPo6Apia46UrIGZrx/IPYxB8K1Iv xGgI0bKhvaYAHqnBZwAE0Z26YslZIJPqbPDFQaZIETUUzDblG4+rTHJvx6YY4zGY26Tq YE8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IdmfKu0zqydDcpve3SS/al5n8XAgDbO9+cMxsm4ebYA=; b=DEVFp5rfOXx7lt5GIKW/kNSZqSRQkp14RQSmg9clw5ZeYgNFZx8p9x+Kf9lL3174af /jaiGvnxoWXyxqYNvxiFNKi3SnpX2+TI5Vab+yn+hDXwgCvj+zxl7dDoVQzSSm3zfq4N Gon3gAxqB6FQYWMcN4x7FzmKaZVo3G7dgRYPFjXFw/+WTRp3rRw+hDuQMLdtvvOp81kk bvqZnqE/PwQ0RblrTHwKnSmNtABpX5bsMFqpHVj5qMt57+69CDAzt9wdJ/zpp+otl16Q /7f5znGG/3K/MC4LUOiIG9yWQIylO26Kz5YlCkz/9WeheTiNGnUAgBdONpmb9Tzb4EUd FjAA== X-Gm-Message-State: AIkVDXKI5vbQfgRiG60eKrPCkYCEkI/6rY6BuE3Tq001uAkl89umfZ3NoTQuO5IHjQSaFg== X-Received: by 10.223.164.66 with SMTP id e2mr11739368wra.47.1486581288545; Wed, 08 Feb 2017 11:14:48 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 191sm4864659wmo.21.2017.02.08.11.14.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 11:14:18 -0800 (PST) From: Yoav Nir Message-Id: <6E43ECDE-CB69-4EF5-8FB7-49C46D5A6DF6@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_68C21FCA-0638-4122-B2A6-04A97120271B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 21:14:15 +0200 In-Reply-To: <20170208155531.C3E45B80F7C@rfc-editor.org> To: RFC Errata System References: <20170208155531.C3E45B80F7C@rfc-editor.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: nmalykh@gmail.com, pe@iki.fi, Paul Hoffman , Tero Kivinen , "IPsecme WG \(ipsec@ietf.org\)" , Kathleen.Moriarty.ietf@gmail.com, "Waltermire, David A. \(Fed\)" , charliekaufman@outlook.com, Stephen Farrell Subject: Re: [IPsec] [Editorial Errata Reported] RFC7296 (4930) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:15:15 -0000 --Apple-Mail=_68C21FCA-0638-4122-B2A6-04A97120271B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is factually true, and it dates back to RFC 5996 (but not 4306). It obviously doesn=E2=80=99t confuse anyone, so I guess it should be = either =E2=80=9Cheld for document update=E2=80=9D Yoav > On 8 Feb 2017, at 17:55, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7296, > "Internet Key Exchange Protocol Version 2 (IKEv2)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7296&eid=3D4930 >=20 > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh >=20 > Section: 3.16 >=20 > Original Text > ------------- > Note that since IKE passes an indication of initiator identity in = the > first message in the IKE_AUTH exchange, the responder SHOULD NOT = send > EAP Identity requests. The initiator MAY, however, respond to such > requests if it receives them. >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > The last sentence of this section contains unnecessary repetition = written above (the last sentence in description of Type field). >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) > -------------------------------------- > Title : Internet Key Exchange Protocol Version 2 (IKEv2) > Publication Date : October 2014 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. = Kivinen > Category : INTERNET STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_68C21FCA-0638-4122-B2A6-04A97120271B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYm24HAAoJELhJCxUKWMyZMfcIAKBrEVAhcuhb28fY37JNlS1H HeIIrn+NqXONl2P3vRD9TX9xvbcOkxyenO/79wDB85p42vP77XF49xib1wOTG9BB JOyS5H32OE5wHwH9ZUKJjbV1X1nvZjgSvrz/M3oWk26RBwb1S9vCOTxM1sOazFDF q+oFZuBI6OVEqWAc+Ez0YQaRyfrOwZRkCBYo8PzMoCSVChzmB+gtOm7r+negIYkY eoxD04JlwUwYSwnjlPs2EbpdQuia/4c28/85FkzH+hZJw9KbXzZ1zPYmPVRq4EpI UEIbvfL2KsggbKvCKOJOgW0DqnBwzXPX9jwSSV/BpoztDEiK0nBSFeWgMqFi3Wk= =+9j8 -----END PGP SIGNATURE----- --Apple-Mail=_68C21FCA-0638-4122-B2A6-04A97120271B-- From nobody Thu Feb 9 04:24:38 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4391299C2 for ; Thu, 9 Feb 2017 04:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Az6LkLJpoCk for ; Thu, 9 Feb 2017 04:24:35 -0800 (PST) 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 3ABE31299C1 for ; Thu, 9 Feb 2017 04:24:35 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v19COLL3010942 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Feb 2017 14:24:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v19COIiS022868; Thu, 9 Feb 2017 14:24:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22684.24434.947636.251404@fireball.acr.fi> Date: Thu, 9 Feb 2017 14:24:18 +0200 From: Tero Kivinen To: RFC Errata System In-Reply-To: <20170208155531.C3E45B80F7C@rfc-editor.org> References: <20170208155531.C3E45B80F7C@rfc-editor.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Cc: nmalykh@gmail.com, nir.ietf@gmail.com, pe@iki.fi, text/plain@rfc-editor.org, paul.hoffman@vpnc.org, charset=UTF-8@rfc-editor.org, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, rfc-editor@rfc-editor.orgContent-Type, david.waltermire@nist.gov, charliekaufman@outlook.com, stephen.farrell@cs.tcd.ie Subject: [IPsec] [Editorial Errata Reported] RFC7296 (4930) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 12:24:38 -0000 RFC Errata System writes: > The following errata report has been submitted for RFC7296, > "Internet Key Exchange Protocol Version 2 (IKEv2)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7296&eid=4930 > > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh > > Section: 3.16 > > Original Text > ------------- > Note that since IKE passes an indication of initiator identity in the > first message in the IKE_AUTH exchange, the responder SHOULD NOT send > EAP Identity requests. The initiator MAY, however, respond to such > requests if it receives them. > > Corrected Text > -------------- > > > Notes > ----- > The last sentence of this section contains unnecessary repetition > written above (the last sentence in description of Type field). This is true, but when we discussed it last time while in RFC editor phase of the rfc5996bis (which came out to be RFC7296) we decided that this emphasis is useful, and decided to keep it. https://www.ietf.org/mail-archive/web/ipsec/current/msg09362.html https://www.ietf.org/mail-archive/web/ipsec/current/msg09365.html At that point we fixed the text to use same RFC2119 wording in both places. I do not think there has been anything that really changed the reasons why we decided to kept it twice in the document since that, so I think the text should stay at it is now. > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) > -------------------------------------- > Title : Internet Key Exchange Protocol Version 2 (IKEv2) > Publication Date : October 2014 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen > Category : INTERNET STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- kivinen@iki.fi From nobody Thu Feb 9 04:40:51 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5527F1299DA for ; Thu, 9 Feb 2017 04:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFtudnp_JcpF for ; Thu, 9 Feb 2017 04:40:49 -0800 (PST) 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 2D4731299CC for ; Thu, 9 Feb 2017 04:40:48 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v19Cec9B024490 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Feb 2017 14:40:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v19CeceM029258; Thu, 9 Feb 2017 14:40:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22684.25414.470545.969594@fireball.acr.fi> Date: Thu, 9 Feb 2017 14:40:38 +0200 From: Tero Kivinen To: David Schinazi In-Reply-To: References: <22683.8182.349840.103676@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 13 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 12:40:50 -0000 Ah I noticed that my last call email had wrong draft name in the subject line and in the link. The correct draft name is of course draft-ietf-ipsecme-eddsa-00 not *-nir-* version. David Schinazi writes: > I've reviewed this draft. I support it and believe it is ready to move forward > towards becoming a standards-track RFC. Also, would it make sense to ask > IANA for early assignment of the code point? Using 0 sounds reasonable to me. As this is expert review registry there is no need to ask for early allocation, the normal process is just to fill in the IANA general request for assignments, which then goes to the IANA and they will then send it to the expert (me) for verification. If normal number (other than 0) would be given out, then I would just say yes, but allocating 0, which in registry is marked as: 0 Reserved [RFC7427] and is not part of the : 5-1023 Unassigned range, then I would be bit more hesitant to give it out, and would most likely want to poll the WG and list before making decision. I actually myself think it would be better to just allocate next free number from the unassigned space, and keep the value 0 as reserved... For example we do not use value 0 of Encryption Algorithms transform to mean ENCR_NULL, we do have separate number allocated for it. On the other hand we do have value 0 meaning NONE in the Integrity algorithm transform ID table and for diffie hellman values, but there the meaning is bit different, it means there is no value for that id, here it would be meaning that there is this identity function version of the hash function. As an expert and as a implementor I think I would prefer next free number over 0... Quite commonly in the code we use value 0 as meaning, we have not yet received anything, or we have not yet initialized this field, and having separate value for identity function might make things easier. But if others have good reasons why the value 0 is better, feel free to tell me... -- kivinen@iki.fi From nobody Thu Feb 9 08:13:38 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4C7129B69 for ; Thu, 9 Feb 2017 08:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYKp_cFgJDES for ; Thu, 9 Feb 2017 08:13:35 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 C11F0129B67 for ; Thu, 9 Feb 2017 08:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486656775; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BsNRyb7wTnCt28kBrooGH0phIobIYiq8MYF+F/zG9Rc=; b=XiSOqu/yTsJF0Noxb7bcMgE1NWG4PM/SHC5FpoI1frCXNLHjkzp1JdM0di8/9pWM bFLULqyGzWGrHXLfQ8LxhiZ+E0OPoKRi4yYMn0ivcv2ou3YURCajPmFlwUw9z2SB O/b2pjHhp3Wa8SRgSoTUl3X7G6li2MaCOAG1NLKeJ/u4b/aQvsiej8FQ188DrMzV Mz6Lz8ib8mSShSUwwfn2vgXdq3PVVqAiBnIukNnRYjyA8mpuQ6MfMdsOhYfKjiDp xgxl0UrU5vd9GtiSAUG3VmixjbCSSAS8YYrelkP6l/ucCRW4giFwoYsjiBmtoUiw 7Zc8W+RzSU8wUnc6QXRisQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id F1.04.10104.7059C985; Thu, 9 Feb 2017 08:12:55 -0800 (PST) X-AuditID: 11973e12-ad23a9a000002778-b6-589c9507bf76 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay6.apple.com (Apple SCV relay) with SMTP id E7.D7.00867.6059C985; Thu, 9 Feb 2017 08:12:55 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.65.195] (unknown [17.153.65.195]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Dec 14 2016)) with ESMTPSA id <0OL400LU27PI7I20@nwk-mmpp-sz12.apple.com>; Thu, 09 Feb 2017 08:12:54 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <22684.25414.470545.969594@fireball.acr.fi> Date: Thu, 09 Feb 2017 08:12:52 -0800 Message-id: <1F3EB5DA-3BF3-45CD-A31E-3D170B5B4F01@apple.com> References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FAYpcs+dU6EwY+nnBb7t7xgszh6/jmb A5PHkiU/mTwOf13IEsAUxWWTkpqTWZZapG+XwJWx6udtpoKv4hWfv01ka2B8IdTFyMkhIWAi sWDXJBYQW0hgL6PE720FMPFbs1tYIeKHGCUarzqC2LwCghI/Jt8DqufgYBaQlzh4XhYkzCyg JfH9UStQmAuovItJ4uq3fUwgNcICEhKb9ySC1AgL+EtcXraTEcRmE1CROP5tAzOIzSlgIXF2 fxc7iM0ioCpxas0eJoiZFhJ355xhhVhrIzG99xQzxPzpjBKfFzwDaxARUJTY/WQrE8TNshLd C6eBFUkIbGGTeHriL9MERuFZSO6ehXD3LCR3L2BkXsUolJuYmaObmWeil1hQkJOql5yfu4kR FNbT7YR2MJ5aZXWIUYCDUYmH90XNnAgh1sSy4srcQ4zSHCxK4rxCJjMjhATSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTDOuudh5i2gE6DdzR58f9EcocQ335PfHrC8P/t4hvaE4MlSXA1Kjnoq /30ir5g8lBD0EOldF5vwZ9dh1sKGve9lefaybJv3Yf031k3v3Jqj1jfNs24tU508ecnB//tS LhxI2M8gKDFhsxm7y2HZF3euX+5bOPcbt9Op1fmzJ2/Z+O/q76zD1WmTlFiKMxINtZiLihMB 56vifkwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42IRbCg+o8s+dU6EQfNXVov9W16wWRw9/5zN gcljyZKfTB6Hvy5kCWCK4rJJSc3JLEst0rdL4MpY9fM2U8FX8YrP3yayNTC+EOpi5OSQEDCR uDW7hRXCFpO4cG89G4gtJHCIUaLxqiOIzSsgKPFj8j2WLkYODmYBeYmD52VBwswCWhLfH7UC hbmAyruYJK5+28cEUiMsICGxeU8iSI2wgL/E5WU7GUFsNgEViePfNjCD2JwCFhJn93exg9gs AqoSp9bsYYKYaSFxd84ZVoi1NhLTe08xQ8yfzijxecEzsAYRAUWJ3U+2MkHcLCvRvXAa8wRG wVlITp2FcOosJKcuYGRexShQlJqTWGmml1hQkJOql5yfu4kRHKCFUTsYG5ZbHWIU4GBU4uF9 UTMnQog1say4MhcYFBzMSiK8l/uBQrwpiZVVqUX58UWlOanFhxiTgR6YyCwlmpwPjJ68knhD ExMDE2NjM2NjcxNz0oSVxHk998+IEBJITyxJzU5NLUgtgtnCxMEp1cDolMzHENm9TErqTajg g/PMYfxuyUpqTiIsX2Lsdxs36i5VKXIw3HX87+Fg44k+7LEbXKu3e521DPr7++UjP5Ony1dd 998qZ/Kv2mbatMSbD3gdlYW91L3+clffXTV5sZrqZkdb0eOMW1YFf/l8/vEN4T3sprdfTGR5 yr8hZKWFD2O6zgThX85KLMUZiYZazEXFiQDKBcXElAIAAA== Archived-At: Cc: ipsec@ietf.org, David Schinazi Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:13:37 -0000 Thanks for sending out the corrected draft name, Tero. I think this draft is in good shape in general and we should move forward with it. The only thing that seems to need ironing out is the specific IANA hash value. I can see the argument either way: as the draft points out, 0 makes sense for the Identity hash, since it can be viewed as "no hash at all". However, I agree with your point that 0 may often be used in code to indicate an uninitialized value. I would be concerned if existing implementations flagged 0 as an error, here, as well. I think it would make sense to do a quick poll of the WG to get some consensus on this. At this point, I'm mildly in favor of a new value (5). Thanks, Tommy > On Feb 9, 2017, at 4:40 AM, Tero Kivinen wrote: > > Ah I noticed that my last call email had wrong draft name in the > subject line and in the link. The correct draft name is of course > draft-ietf-ipsecme-eddsa-00 not *-nir-* version. > > David Schinazi writes: >> I've reviewed this draft. I support it and believe it is ready to move forward >> towards becoming a standards-track RFC. Also, would it make sense to ask >> IANA for early assignment of the code point? Using 0 sounds reasonable to me. > > As this is expert review registry there is no need to ask for early > allocation, the normal process is just to fill in the IANA general > request for assignments, which then goes to the IANA and they will > then send it to the expert (me) for verification. > > If normal number (other than 0) would be given out, then I would just > say yes, but allocating 0, which in registry is marked as: > > 0 Reserved [RFC7427] > > and is not part of the : > > 5-1023 Unassigned > > range, then I would be bit more hesitant to give it out, and would > most likely want to poll the WG and list before making decision. > > I actually myself think it would be better to just allocate next free > number from the unassigned space, and keep the value 0 as reserved... > > For example we do not use value 0 of Encryption Algorithms transform > to mean ENCR_NULL, we do have separate number allocated for it. On the > other hand we do have value 0 meaning NONE in the Integrity algorithm > transform ID table and for diffie hellman values, but there the > meaning is bit different, it means there is no value for that id, here > it would be meaning that there is this identity function version of > the hash function. > > As an expert and as a implementor I think I would prefer next free > number over 0... Quite commonly in the code we use value 0 as meaning, > we have not yet received anything, or we have not yet initialized this > field, and having separate value for identity function might make > things easier. But if others have good reasons why the value 0 is > better, feel free to tell me... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 9 08:58:07 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430B0129C08 for ; Thu, 9 Feb 2017 08:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQHM_2S0r0ZN for ; Thu, 9 Feb 2017 08:58:04 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26317129C06 for ; Thu, 9 Feb 2017 08:58:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vK45L5NwRz3Ql; Thu, 9 Feb 2017 17:57:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1486659478; bh=8aSr7FiImemWNkyl979SLC8jXnMeCupef5RKWgE0b2s=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GFnPW2U55BjKUlrnVxE2AArx3SFQhSlRLJno6x2rXhEmpxBBFdB0T3GgtIp+3am06 2L4ePvKEoIiTKoAv/MZ/BEtUeqqLy+GT06WW3GaB9M7ciOn58znbmfT1g2TLqQs/Tw uRbvtVjf0u/8R3NsJdE8DomwQfe0n0resCz16k80= 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 0TS9lHZo4euC; Thu, 9 Feb 2017 17:57:56 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 9 Feb 2017 17:57:55 +0100 (CET) Received: from [193.111.228.71] (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id A507155A557; Thu, 9 Feb 2017 11:57:53 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A507155A557 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14D27) In-Reply-To: <1F3EB5DA-3BF3-45CD-A31E-3D170B5B4F01@apple.com> Date: Thu, 9 Feb 2017 11:57:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <1F3EB5DA-3BF3-45CD-A31E-3D170B5B4F01@apple.com> To: Tommy Pauly Archived-At: Cc: ipsec@ietf.org, David Schinazi , Tero Kivinen Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:58:06 -0000 Yes I forgot to reply. I strongly object to assigning 0 for real values. It s= hould be left for implementations to detect a value has not been set. Paul Sent from my iPhone > On Feb 9, 2017, at 11:12, Tommy Pauly wrote: >=20 > Thanks for sending out the corrected draft name, Tero. I think this draft i= s in good shape in general and we should move forward with it. >=20 > The only thing that seems to need ironing out is the specific IANA hash va= lue. I can see the argument either way: as the draft points out, 0 makes sen= se for the Identity hash, since it can be viewed as "no hash at all". Howeve= r, I agree with your point that 0 may often be used in code to indicate an u= ninitialized value. I would be concerned if existing implementations flagged= 0 as an error, here, as well. >=20 > I think it would make sense to do a quick poll of the WG to get some conse= nsus on this. At this point, I'm mildly in favor of a new value (5). >=20 > Thanks, > Tommy >=20 >> On Feb 9, 2017, at 4:40 AM, Tero Kivinen wrote: >>=20 >> Ah I noticed that my last call email had wrong draft name in the >> subject line and in the link. The correct draft name is of course >> draft-ietf-ipsecme-eddsa-00 not *-nir-* version. >>=20 >> David Schinazi writes: >>> I've reviewed this draft. I support it and believe it is ready to move f= orward >>> towards becoming a standards-track RFC. Also, would it make sense to ask= >>> IANA for early assignment of the code point? Using 0 sounds reasonable t= o me. >>=20 >> As this is expert review registry there is no need to ask for early >> allocation, the normal process is just to fill in the IANA general >> request for assignments, which then goes to the IANA and they will >> then send it to the expert (me) for verification. >>=20 >> If normal number (other than 0) would be given out, then I would just >> say yes, but allocating 0, which in registry is marked as: >>=20 >> 0 Reserved [RFC7427] >>=20 >> and is not part of the : >>=20 >> 5-1023 Unassigned >>=20 >> range, then I would be bit more hesitant to give it out, and would >> most likely want to poll the WG and list before making decision. >>=20 >> I actually myself think it would be better to just allocate next free >> number from the unassigned space, and keep the value 0 as reserved... >>=20 >> For example we do not use value 0 of Encryption Algorithms transform >> to mean ENCR_NULL, we do have separate number allocated for it. On the >> other hand we do have value 0 meaning NONE in the Integrity algorithm >> transform ID table and for diffie hellman values, but there the >> meaning is bit different, it means there is no value for that id, here >> it would be meaning that there is this identity function version of >> the hash function.=20 >>=20 >> As an expert and as a implementor I think I would prefer next free >> number over 0... Quite commonly in the code we use value 0 as meaning, >> we have not yet received anything, or we have not yet initialized this >> field, and having separate value for identity function might make >> things easier. But if others have good reasons why the value 0 is >> better, feel free to tell me... >> --=20 >> kivinen@iki.fi >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 9 09:01:13 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB174129C06; Thu, 9 Feb 2017 09:01:11 -0800 (PST) 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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148665967195.20586.9624209980242769498.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 09:01:11 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:01:12 -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 of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-07.txt Pages : 22 Date : 2017-02-09 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-07 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 Thu Feb 9 09:05:13 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F6B129C17 for ; Thu, 9 Feb 2017 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZYHHi8EidcZ for ; Thu, 9 Feb 2017 09:05:11 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 1B568129C0F for ; Thu, 9 Feb 2017 09:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486659882; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rKFkIjuoUF0bqEaXG9EgW1CUTTY2swSP8UDCWOjUvYM=; b=0koIQiK4asUxY2VJ7ruMqJZo+THHJ80n7natrP8L0XhNmTd4To+Rwo23W4Q66bWg rLh38ucKIrqx/6A5zbliCP8QlGI2kVNfD4868Bd87f8+qC2oyNRRmRTxlWpW9kyv Bm4njN5sez3TGhBPld8ulkr8buGBxm5XLbIlJlbiUg6vFYKdBf3BAJTBNcYjXzU/ 1vi5yzAeeYydyGoU6G2fLWitDssonkMHE/xvxsxTJ68WuvSp3GThAShpj692DS95 2SAce5Ccq0NjmbDhMcVo7PxL6RS/EZg+NwGEf4RVcJhGN1NY2fa0e1dMk6V5MauP OFt8LOVK8Jg7ZUu2c2ygvg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id CF.B6.14588.A21AC985; Thu, 9 Feb 2017 09:04:42 -0800 (PST) X-AuditID: 11973e16-fa0ae9a0000038fc-5d-589ca12ae59f Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay8.apple.com (Apple SCV relay) with SMTP id D6.30.12381.A21AC985; Thu, 9 Feb 2017 09:04:42 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.65.195] (unknown [17.153.65.195]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Dec 14 2016)) with ESMTPSA id <0OL400ICRA3TXV00@nwk-mmpp-sz07.apple.com>; Thu, 09 Feb 2017 09:04:42 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Date: Thu, 09 Feb 2017 09:04:41 -0800 References: <0f8601d27d4d$d11e3fa0$735abee0$@gmail.com> <0377D36E-8572-466F-A595-77F2AE5D4A07@apple.com> <132a01d28149$c28186f0$478494d0$@gmail.com> <9C8B0C3E-8533-488D-A2A7-2F13AAC4C1B4@apple.com> To: Valery Smyslov , IPsecME WG , Tero Kivinen In-reply-to: <9C8B0C3E-8533-488D-A2A7-2F13AAC4C1B4@apple.com> Message-id: X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FCYpqu1cE6EwY4rlhb7t7xgszh6/jmb xY0PM9kcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZXT0PmEpWOxS8frnedYG xtVmXYycHBICJhIbrzUzdzFycQgJ7GOUmH78EytMYtL8bhaIxCFGiQ9rFzKBJHgFBCV+TL4H lODgYBaQlzh4XhYkzCygJfH9UStUfReTxOKmnawgNcICEhKb9ySC1LAJqEgc/7aBGcQWFrCX WDRpAdgYFgFVibUXVCFaTzNKXOvbwQ4SFxFIljj6pASknFPAVuJy5xNGiAtsJFrfXWSHOFNW onvhNLD7JQS2sElMOHOacQKj0Cwkl85CuHQWkksXMDKvYhTKTczM0c3MM9dLLCjISdVLzs/d xAgK6el2YjsYH66yOsQowMGoxMM7oWpOhBBrYllxZe4hRmkOFiVxXn6TmRFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGBcu7pFir47xFH9TGvRiy9+aLzn9pz8vaFw95Y7u/CVTjIoLlv0q Ulr+7YIC77FuhanpCqrXgqTmxEg1hnzu274o7OuqjJSpl+ckL8j8sSxk5eUL/6Orii9Z2mz6 //G2UWyeQXPBx0YFNcdtBXt3nDH4HBbzvfLvowlZ5wIdF19+d8BU1vNQvYoSS3FGoqEWc1Fx IgDbYdp9SgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUi2FD8QVdr4ZwIg+9HTCz2b3nBZnH0/HM2 ixsfZrI5MHvsnHWX3WPJkp9MHoe/LmQJYI7isklJzcksSy3St0vgyujofcJSsNil4vXP86wN jKvNuhg5OSQETCQmze9mgbDFJC7cW8/WxcjFISRwiFHiw9qFTCAJXgFBiR+T7wEVcXAwC8hL HDwvCxJmFtCS+P6olQWivotJYnHTTlaQGmEBCYnNexJBatgEVCSOf9vADGILC9hLLJq0AGwM i4CqxNoLqhCtpxklrvXtYAeJiwgkSxx9UgJSzilgK3G58wkjxAU2Eq3vLrJDnCkr0b1wGvME RoFZSI6bhXDcLCTHLWBkXsUoUJSak1hpoZdYUJCTqpecn7uJERyahWk7GJuWWx1iFOBgVOLh nVA1J0KINbGsuDIX6HsOZiURXpOZQCHelMTKqtSi/Pii0pzU4kOMyUDnT2SWEk3OB8ZNXkm8 oYmJgYmxsZmxsbmJOWnCSuK8nvtnRAgJpCeWpGanphakFsFsYeLglGpg5Nmy1NThocP6ladu Hd36zkpqS/lbwTV3f6dfUhHeu41N9XrolVhFrj/rXzS1yxYfuSHw+PylpfxhM5gq0+RWMueu reKcnOu14quY7bR7n27Ul+2UvVwzX3TbLm2lAo/4tbwm/Bv/Vd/jFbi/c7vUsmnx7vNWX9kW Iuro563hVLPgbMrEs/3szUosxRmJhlrMRcWJAHQm1KaRAgAA Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:05:13 -0000 Hello, I've posted a new draft with a fix for the TCP Originator vs Original Initiator explanation, and a couple typos. https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-07 I believe this addresses all outstanding comments! Thanks, Tommy > On Feb 7, 2017, at 9:44 AM, Tommy Pauly wrote: > > Hi Valery, > > Thanks for the feedback! I'll clarify that the TCP Originator is the same as the original initiator of the first IKE SA, as well as fixing the typographical errors. > > If anyone else has more feedback, please chime in! I'll wait a day or so before updating the draft, to batch any other changes that should be made. > > Thanks, > Tommy > >> On Feb 7, 2017, at 5:54 AM, Valery Smyslov wrote: >> >> Hi Tommy, >> >> thank you for the quick update. A couple nits: >> >> 1. Section 1.2: >> s/the the/the >> >> 2. Section 1.2: >> The TCP >> Originator MUST be the same as the "Original Initiator", or the >> Initiator of the first IKE SA exchange for a given IKE session. >> >> Again, this is confusing. In RFC7296 the term " Original Initiator" is defined as: >> The "original initiator >> always refers to the party who initiated the exchange that resulted >> in the current IKE SA. In other words, if the "original responder" >> starts rekeying the IKE SA, that party becomes the "original >> initiator" of the new IKE SA." >> >> "the Initiator of the first IKE SA exchange for a given IKE session" is also >> wrong, since IKE session means IKE SA and it can be a rekey of previous >> IKE SA when entities swap their original roles. >> >> This is now what we want it to mean, so an additional clarification is needed. >> Something along the lines: >> >> The TCP Originator MUST be the same as the entity who originally >> initiated the first IKE SA (in a series of possibly several rekeyed >> IKE SAs). >> >> Otherwise it looks good. >> >> Regards, >> Valery. >> >>> Hi Valery, >>> >>> Thanks so much for your comments! I have posted a new version of the draft here: >>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06 >>> >>> Responses inline. >>> >>> Best, >>> Tommy >>> >>>> On Feb 2, 2017, at 4:13 AM, Valery Smyslov wrote: >>>> >>>> Hi, >>>> >>>> here is my review of draft-ietf-ipsecme-tcp-encaps-05. >>>> The draft is in a good shape, but a bit of final polishing is required. >>>> >>>> 1. The terms "tunnel", "tunneled" are used throughout the document >>>> when referring to ESP SA. I think it is technically incorrect, since >>>> ESP supports both tunnel and transport modes, so the document >>>> should use more appropriate terms like "IPsec SA", "ESP packets" etc. >>> >>> Great point. I have removed the references to tunnel, and replaced with SA, generally. >>> >>>> >>>> 2. Section 4. >>>> This value is >>>> only sent once, by the Initiator only, at the beginning of any stream >>>> of IKE and ESP messages. >>>> >>>> If other framing protocols are used within TCP to further encapsulate >>>> or encrypt the stream of IKE and ESP messages, the Stream Prefix must >>>> be at the start of the Initiator's IKE and ESP message stream within >>>> the added protocol layer [Appendix A]. >>>> >>>> Using "Initiator" is wrong here, since the TCP stream may be re-established >>>> after the peers rekeyed IKE SA and changed their roles (so that original >>>> Initiator becomes Responder). It either must be "original Initiator" >>>> (with all explanations who it is, as in Section 6) or, preferably, >>>> "originator of TCP stream" (or smth like that). >>>> >>>> Actually, "Initiator" is used in a lot of places throughout the document >>>> and in most cases it means "original Initiator of the first IKE SA in a series >>>> of possible successive rekeys of this SA". It is good to look through >>>> all these uses and either clarify this term in all places it is used, or add >>>> some para in the beginning of the draft, e.g. like it is done in RFC4555: >>>> >>>> In this document, the term "initiator" means the party who originally >>>> initiated the first IKE_SA (in a series of possibly several rekeyed >>>> IKE_SAs); "responder" is the other peer. During the lifetime of the >>>> IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA >>>> exchanges; in this case, the terms "exchange initiator" and "exchange >>>> responder" are used. The term "original initiator" (which in [IKEv2] >>>> refers to the party who started the latest IKE_SA rekeying) is not >>>> used in this document. >>>> >>>> I also noticed that both "Initiator" and "initiator" are used in the document >>>> (as well as "Responder" and "responder"). It's better to use one form >>>> (preferably with capital letter, like in RFC7296). RFC Editor will change >>>> them to one form in any case, so you can ease her work a bit. >>> >>> I've switched to use the capitalized version of Initiator and Responder. >>> >>>> >>>> I'd also suggest to introduce some term for the party, that creates >>>> TCP session (e.g. "TCP originator") and use it where appropriate, >>>> so that IKE roles are clearly distinct from TCP roles. In this case >>>> you can get rid of "Initiator" in most places replacing it with "TCP originator". >>> >>> I added the terms "TCP Originator" and "TCP Responder" in the terminology section, with an >> explanation of >>> this distinction. I've used the new terms where appropriate throughout the document. >>> >>>> >>>> 3. Section 6. >>>> When the IKE initiator uses TCP encapsulation for its negotiation,... >>>> >>>> "its negotiation" is confusing here, since TCP encapsulation is not negotiated. >>>> I suggest removing "for its negotiation" completely (or change to "for IKE SA negotiation"). >>> >>> Removed the phrase. >>> >>>> >>>> 4. Section 6. >>>> Once all >>>> SAs have been deleted,... >>>> >>>> "all SAs" is confusing. Later in this section it is stated that multiple IKE SAs >>>> MUST NOT share a single TCP connection. Is this a leftover from an early design? >>> >>> Switched to "Once the SA has been..." >>> >>>> >>>> 5. Section 6. >>>> If the connection is being used to resume a previous IKE session... >>>> >>>> For clarity: s/connection/TCP connection >>> >>> Switched to "if a TCP connection". >>> >>>> >>>> 6. Section 6. >>>> A responder SHOULD at any given time send packets for an IKE SA and >>>> its Child SAs over only one TCP connection. >>>> >>>> Why only Responder? What about Initiator? I think this requirement >>>> is valid for both. >>> >>> Slightly modified the phrasing. The paragraph above describes the Initiator/Originator behavior. >>> >>>> >>>> 7. Section 6. >>>> In order to be considered valid for choosing a TCP >>>> connection, an IKE message successfully decrypt and be authenticated, >>>> not be a retransmission of a previously received message, and be >>>> within the expected window for IKE message IDs. Similarly, an ESP >>>> message must pass authentication checks and be decrypted, not be a >>>> replay of a previous message. >>>> >>>> "an IKE message successfully decrypt" - is it OK with the grammar? >>>> Shouldn't it be: "an IKE message must be successfully decrypted"? >>> >>> Thanks for catching! Fixed. >>> >>>> >>>> What about ES, I think that it is a good thing to add >>>> a requirement, that ESP window size MUST be set to 1 if TCP >>>> encapsulation is in use. Larger windows are useless with TCP, >>>> since there is no packet reordering. On the other hand, setting >>>> window size to 1 will effectively block an attack vector that was described >>>> by Tero, when an attacker sends old packet with fake TCP header. >>>> If window size is 1, then this packet will be dropped immediately >>>> without any changes in the ESP logic. >>> >>> Added this recommendation to the security considerations. >>> >>>> >>>> 8. Section 6. >>>> Multiple IKE SAs MUST NOT share a single TCP connection. >>>> >>>> Please add clarification: "unless one of them is a rekey of another, >>>> in which case two SAs sharing a single TCP connection coexist for >>>> a short period of time" (or smth similar). >>> >>> Added the clarification. >>> >>>> >>>> Regards, >>>> Valery. >>>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 9 09:21:29 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F2A129C07 for ; Thu, 9 Feb 2017 09:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bg2Ym6BoXNL for ; Thu, 9 Feb 2017 09:21:26 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 7D98A129485 for ; Thu, 9 Feb 2017 09:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486660886; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ms9HGjzW7Kc8o4Q5cClx4kmJ3hosxwsnhnJhT9DrN08=; b=ucqUXo6rQUZg0ucJXGq5IS7QyGnIpsQ/fsH/8dRTqZslbfo477ibMbIPpP2QglWC 0KNTbKruaWxr8Jb3HYizk976JRTcvUQ/qzWVqoP9N4KxAQICGKVuHa3iKLU8bXJY HOQSxtZsFcv/y/UxTTR8XfIi5fc/yeAuFQSg8tBZsEBKbSCcyyA996ErEC3fsjqA DQQGuHj0GC1VUEwQboo1YoGHDxBjjze3WAwWBwGVpHDJiriM4KuJMYjt3ddSnZTt iMDHABMVWbDDal+oPD5WU/HpYvYXxy2gF68uozUTTCEh/ka+P7sFnAw6qEUDCW+t Dpqf+vdXivtEC99QhkVI5w==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 0F.67.09465.615AC985; Thu, 9 Feb 2017 09:21:26 -0800 (PST) X-AuditID: 11973e15-360719a0000024f9-ed-589ca5164202 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay3.apple.com (Apple SCV relay) with SMTP id 8F.1E.20093.515AC985; Thu, 9 Feb 2017 09:21:26 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.48.158] (unknown [17.153.48.158]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Dec 14 2016)) with ESMTPSA id <0OL400AFOAVGV050@nwk-phonehomebzp-sz01.apple.com>; Thu, 09 Feb 2017 09:21:25 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: Date: Thu, 09 Feb 2017 09:21:21 -0800 Message-id: References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <1F3EB5DA-3BF3-45CD-A31E-3D170B5B4F01@apple.com> To: Paul Wouters X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FAYrCu2dE6EwdzFvBb7t7xgszh6/jmb xftbl5gcmD2WLPnJ5HH460IWj+/zmAKYo7hsUlJzMstSi/TtErgyujousxQckK040nSKsYFx hXgXIyeHhICJxLV9/5m6GLk4hAT2MkocanvBDpOYs6SHDSJxjFFiwv4OFpAEr4CgxI/J94Bs Dg5mAXmJg+dlQcLMAloS3x+1skDUz2KSWLByNVi9sIC0RNeFu6wQtr/E5WU7GUF62YAaDqwx AglzCthKnF75hgnEZhFQlfi7aws7xPhgiUdLTCC22kh0fP7BDDH+L6PE8/nTGEESIgKKEpPO PGKBuFlW4tPzn+wgRRICB9gkDl/dxDiBUXgWkrNnIZw9C8nZCxiZVzEK5SZm5uhm5pnpJRYU 5KTqJefnbmIEhfp0O9EdjGdWWR1iFOBgVOLhfVkzJ0KINbGsuDL3EKM0B4uSOK+EycwIIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw1B4Nmi6Re3zglwdDwwsk6qcBTCy9+aZa9+dRmjeOi 5kclLPM3X0uJrHgy/yhP2dOii0wXGxpPsa66weAU7bX4R8Jhu40bXGRz3zL+urZf9MjD0yGJ YRcUFsYU3v+WWRZ1WeTPzpLZBUod8heO8siaxLrW3Sn1c3usv/V5Y5O59ZQrARPvTN+rxFKc kWioxVxUnAgA4OFm0VYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42IRnG7noCu2dE6EwZO3rBb7t7xgszh6/jmb xftbl5gcmD2WLPnJ5HH460IWj+/zmAKYo7hsUlJzMstSi/TtErgyujousxQckK040nSKsYFx hXgXIyeHhICJxJwlPWwQtpjEhXvrgWwuDiGBY4wSE/Z3sIAkeAUEJX5Mvgdkc3AwC8hLHDwv CxJmFtCS+P6olQWifhaTxIKVq8HqhQWkJbou3GWFsP0lLi/byQjSywbUcGCNEUiYU8BW4vTK N0wgNouAqsTfXVvYIcYHSzxaYgKx1Uai4/MPZojxfxklns+fxgiSEBFQlJh05hELxM2yEp+e /2SfwCg4C8mlsxAunYXk0gWMzKsYBYpScxIrjfUSCwpyUvWS83M3MYJCtqEweAfjn2VWhxgF OBiVeHgnVM2JEGJNLCuuzD3EKMHBrCTCO28RUIg3JbGyKrUoP76oNCe1+BBjMtD9E5mlRJPz gfGUVxJvaGJiYGJsbGZsbG5iTpqwkjiv5/4ZEUIC6YklqdmpqQWpRTBbmDg4pRoYbVtX2LTf jPh7SlZM33HDameXVfdbPLkNP0jdmCW81udvLssO3q93kosPH7+3t9/drvzG/RhrDe6Pr3fG GHzuurbqbYPTyvUxzRcmin2b19pgJPd+3vJVG6ZVx+ss7jv3+f2bux4r9i6fuXCy5LKFeQdk /oanTXXRXjO/wW/lnjC7l7dPXFoi2KDEUpyRaKjFXFScCABnuwfcnQIAAA== Archived-At: Cc: ipsec@ietf.org, Tero Kivinen , Tommy Pauly Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:21:28 -0000 Based on these arguments, I agree that a new value (5) is preferable to 0. David > On Feb 9, 2017, at 08:57, Paul Wouters wrote: > > Yes I forgot to reply. I strongly object to assigning 0 for real values. It should be left for implementations to detect a value has not been set. > > Paul > > Sent from my iPhone > >> On Feb 9, 2017, at 11:12, Tommy Pauly wrote: >> >> Thanks for sending out the corrected draft name, Tero. I think this draft is in good shape in general and we should move forward with it. >> >> The only thing that seems to need ironing out is the specific IANA hash value. I can see the argument either way: as the draft points out, 0 makes sense for the Identity hash, since it can be viewed as "no hash at all". However, I agree with your point that 0 may often be used in code to indicate an uninitialized value. I would be concerned if existing implementations flagged 0 as an error, here, as well. >> >> I think it would make sense to do a quick poll of the WG to get some consensus on this. At this point, I'm mildly in favor of a new value (5). >> >> Thanks, >> Tommy >> >>> On Feb 9, 2017, at 4:40 AM, Tero Kivinen wrote: >>> >>> Ah I noticed that my last call email had wrong draft name in the >>> subject line and in the link. The correct draft name is of course >>> draft-ietf-ipsecme-eddsa-00 not *-nir-* version. >>> >>> David Schinazi writes: >>>> I've reviewed this draft. I support it and believe it is ready to move forward >>>> towards becoming a standards-track RFC. Also, would it make sense to ask >>>> IANA for early assignment of the code point? Using 0 sounds reasonable to me. >>> >>> As this is expert review registry there is no need to ask for early >>> allocation, the normal process is just to fill in the IANA general >>> request for assignments, which then goes to the IANA and they will >>> then send it to the expert (me) for verification. >>> >>> If normal number (other than 0) would be given out, then I would just >>> say yes, but allocating 0, which in registry is marked as: >>> >>> 0 Reserved [RFC7427] >>> >>> and is not part of the : >>> >>> 5-1023 Unassigned >>> >>> range, then I would be bit more hesitant to give it out, and would >>> most likely want to poll the WG and list before making decision. >>> >>> I actually myself think it would be better to just allocate next free >>> number from the unassigned space, and keep the value 0 as reserved... >>> >>> For example we do not use value 0 of Encryption Algorithms transform >>> to mean ENCR_NULL, we do have separate number allocated for it. On the >>> other hand we do have value 0 meaning NONE in the Integrity algorithm >>> transform ID table and for diffie hellman values, but there the >>> meaning is bit different, it means there is no value for that id, here >>> it would be meaning that there is this identity function version of >>> the hash function. >>> >>> As an expert and as a implementor I think I would prefer next free >>> number over 0... Quite commonly in the code we use value 0 as meaning, >>> we have not yet received anything, or we have not yet initialized this >>> field, and having separate value for identity function might make >>> things easier. But if others have good reasons why the value 0 is >>> better, feel free to tell me... >>> -- >>> kivinen@iki.fi >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Feb 10 03:02:07 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AB31270B4; Fri, 10 Feb 2017 03:02:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148672452596.27817.5204579495369933693.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 03:02:05 -0800 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, kivinen@iki.fi Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 98 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 11:02:06 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: cfrg saag tls curdle tcpinc mile sacm Second Priority: 6tisch lwig ace Third Priority: uta 6lo dane tcpm netmod People who must be present: Kathleen Moriarty Tero Kivinen David Waltermire Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Fri Feb 10 03:07:59 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817FF1294CA for ; Fri, 10 Feb 2017 03:07:57 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgSGmjlZDA4S for ; Fri, 10 Feb 2017 03:07:56 -0800 (PST) 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 CB8311270B4 for ; Fri, 10 Feb 2017 03:07:55 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1AB7rGS005686 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 10 Feb 2017 13:07:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1AB7rWa019540; Fri, 10 Feb 2017 13:07:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22685.40713.158534.998993@fireball.acr.fi> Date: Fri, 10 Feb 2017 13:07:53 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] IPsecME status update 2017-02-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 11:07:57 -0000 IETF 98 session request done for 1.5 hours. Agenda could be: - Document status of "finished" documents - rfc4307bis - rfc7321bis - Document status of "almost finished" documents - EdDSA - tcp-encaps - Document status of other adopted WG drafts - split-dns - Work items - Quantum Resistance - Implicit IV - Other items Document Status: - draft-ietf-ipsecme-rfc4307bis (David) Publication requested. On the 2017-02-16 telechat. - draft-ietf-ipsecme-rfc7321bis (David) Should be ready to go forward along with 4307bis. Now in WGLC. - draft-ietf-ipsecme-eddsa (Tero) Got oids, CFRG said no context. In WGLC. - draft-ietf-ipsecme-tcp-encaps (Tero) Done the WGLC, waiting for writeup. New work: - Quantum Resistance (David) Adopted as WG document. - draft-pauly-ipsecme-split-dns (David) In WG adaptotation call. - draft-mglt-ipsecme-implicit-iv (Tero) This was also accepted as charter item, but would like to see few more reviews before taking it as WG draft. -- kivinen@iki.fi From nobody Fri Feb 10 08:24:59 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B9B129A2F; Fri, 10 Feb 2017 08:24:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148674389416.29219.175584681049210938.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 08:24:54 -0800 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-rfc4307bis@ietf.org, shares@ndzh.com, david.waltermire@nist.gov Subject: [IPsec] Benoit Claise's No Objection on draft-ietf-ipsecme-rfc4307bis-15: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:24:54 -0000 Benoit Claise has entered the following ballot position for draft-ietf-ipsecme-rfc4307bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here is Sue Hares' OPS DIR feedback: Status: Read for publication with editorial nits (see below) General Comment: Thank you for this interesting, informative, and well-written draft. My editorial nits are just places you might improve the clarity of the draft. Sue Hares ======================= Editorial Nits: #1 – Section 1.3, p 4, paragraph 1 Old/The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. / New: /The recommendations of this document mostly target IKEv2 implementation as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. / Note: Either implementation as implementations Or implementers as implementers need to create implementations #2 – section 1.3, p. 4,paragraph 2 3) Old/ This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations for implementations./ New / This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations regarding implementations./ #3 section 3.1, p. 6 , paragraph 2, starting with “ENCR_CHACHA20_POLY1305” Please expand the abbreviation CRFG. I believe this this is the first use of the abbreviation. #4 section 3.4, p 9-10, several paragraphs in here did not provide the final status 4.a p9, last paragraph on page old/ Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as a replacement for 1024-bit MODP Group. / new/ Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 to MUST as a replacement for 1024-bit MODP Group. / 4.b p. 9, first paragraph on page, line 1 Old/ Group 19 or 256-bit random ECP group was not specified in RFC4307, as this group were not defined at that time. Group 19 is widely implemented and considered secure./ New / Group 19 or 256-bit random ECP group was not specified in RFC4307, as this group were not defined at that time. Group 19 is widely implemented and considered secure so Group 19’s status is SHOULD. 4.c p.9, paragraph 4, line Old/ Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its status was MAY. It can be broken within hours using cheap of-the- shelves hardware. It provides no security whatsoever./ New/ Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its status was MAY. It can be broken within hours using cheap of-the- shelves hardware. It provides no security whatsoever. Therefore, its current stsatus is MUST not. #5 section 4.1, p 12, paragraph 2-4: Final status not indicatd 5.a: paragraph 2 Old/ Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in the RFC7296./ New:/ Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in the RFC7296. The status is MUST. / 5.b paragraph 3 Old/ ECDSA based Authentication Methods are also expected to be downgraded as it does not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. / New/ ECDSA based Authentication Methods are also expected to be downgraded as it does not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. ECADSA-based Authentication Methods status is “SHOULD”. / 5.c. paragraph 4 Old:/ DSS Digital Signature is bound to SHA-1 and has the same level of security as 1024-bit RSA. It is expected to be downgraded to MUST NOT in the future./ New/ DSS Digital Signature is bound to SHA-1 and has the same level of security as 1024-bit RSA. It is currently at SHOULD NOT, but it is expected to be downgraded to MUST NOT in the future./ 5.d paragraph 5 Old/ Digital Signature [RFC7427] is expected to be promoted as it provides hash function, signature format and algorithm agility./ New/ Digital Signature [RFC7427] is expected to be promoted as it provides hash function, signature format and algorithm agility. Its current status is SHOULD. From nobody Mon Feb 13 06:20:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B066F1295D1 for ; Mon, 13 Feb 2017 06:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 e7deHVA8OAq1 for ; Mon, 13 Feb 2017 06:20:37 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B600E129590 for ; Mon, 13 Feb 2017 06:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20937; q=dns/txt; s=iport; t=1486995636; x=1488205236; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3YR0vvxjMOA0LHJnOZP31PDBRi/JR+CvoKyN3kgc6KY=; b=PR7xkluHzfqecgTASi2fhDclkN7ovbyHO4IV2C9MiJvDilb73xycNvI/ fdeUqARYV/PrfAexXn6hOgNz6qLSHA3xrgmL442Yk/YTPLJrommg2aDA4 gxvVHcQfk4RPv4m/gJbjAEoJaEa2N3wR+BWBemRZwSXHakbidfv/1yWen 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AwCAv6FY/5ldJa1VCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJvY2GBCQefZpdChiICgmdCFQECAQEBAQEBAWIohGkBAQEELVwCAQg?= =?us-ascii?q?RBAEBIQcHMhQJCAEBBBMIiWKwVotEAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYQrg?= =?us-ascii?q?iGEb4QtXYUvBYl0kX4BkgqCBI8KiCyGT4QZATUigQBRFYUCHYFhdYkhgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,156,1484006400"; d="scan'208,217";a="197605578" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 14:20:35 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1DEKYoU014997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Feb 2017 14:20:34 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 09:20:34 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 13 Feb 2017 09:20:34 -0500 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Quantum Resistant IKEv2 Thread-Index: AdJQCCXgkOeGxGfPROWQbtulvkq0wA1+2LKA Date: Mon, 13 Feb 2017 14:20:33 +0000 Message-ID: <20854b976b8546139adf78889bf75c3e@XCH-RTP-006.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.62] Content-Type: multipart/alternative; boundary="_000_20854b976b8546139adf78889bf75c3eXCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:20:38 -0000 --_000_20854b976b8546139adf78889bf75c3eXCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, I held this informal poll, and here are the results: - For the first question ("how do we stir in the PPK"), there were= no strong opinions; some people did express a preference for the third opt= ion (Valery's suggestion to modify only the initial SK_d). I'll update the= draft to reflect that. - For the second question ("how important is anonymity"), it would= appear that the majority opinion is that this could be handled in a follow= -up draft. Michael Richards also suggested we attempt to address how to distribute the= PPKs. However, I would agree with Valery Smyslov; this is out of scope fo= r this document; for example, the current IKE RFC allows preshared secrets,= and does not address how to distribute them. I'll be published an updated draft shortly; are there any other issues peop= le feel need to be addressed? From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer (sfl= uhrer) Sent: Tuesday, December 06, 2016 4:32 PM To: IPsecme WG (ipsec@ietf.org) Subject: [IPsec] Quantum Resistant IKEv2 In the WG meeting in Seoul, we discussed the Quantum Resistant proposal for= IKEv2, and decided to make the current draft (draft-fluhrer-qr-ikev2-03) a= s work item. During the discussion, two items were raised, and I would like to hear how = the wider WG feels about these two items: - The first item is "how exactly do we stir in the preshared key (= PPK) into the keying material". By my count, three options were on the tab= le: o There is the option listed in the draft, where we modify both the KEYMA= T and SKEYSEED computations; stirring it into the KEYMAT implies that the I= Psec SAs are generated with QR-resistant keying material, while stirring it= into the SKEYSEED implies that any child IKE SAs implies that any IKE SA (= other than the initial one) also has QR-resistant keying material. This la= tter was done specifically so that an implementation can have protected IKE= SAs (by negotiating a child SA immediately) o Dan Harkins suggested that we modify only the KEYMAT. This is a simple= r option, and will continue to protect the IPsec SAs; however this implies = that any data protected by the IKE SA could potentially be recovered by a Q= uantum Computer. o Valery Smyslov gave a suggestion that we instead stir in the PPK into t= he initial SK_d; as all keying material is generated based on that, this wo= uld also mean that IPsec SAs and any child IKE SAs are also protected. Thi= s also means that an implementation would not need to remember the PPK afte= r the initial negotiation. The only downside I can see is that we would ha= ve to be a bit careful about when we update the SK_d (obviously, before we = actually use it). To me, all three strike me as reasonable ideas (unless we decide that we wi= ll need to protect the real identity data encrypted via the IKE SA; in that= case, Dan's idea doesn't protect that). Can I get opinions as to which st= rikes the group as the best? Are there any fourth options that people woul= d want to put on the table? - The second item is anonymity; some people were interested in pre= serving anonymity (however, not at the expense of excessive complexity). O= ne idea that was brought up was that the initial exchange would be done usi= ng pseudonyms (which would be sufficient for the responder to identity the = PPK), and then once initial IKE SAs have been established (in a QR form), e= xchange the real identities. My questions: o Would this idea of pseudonyms actually give any real identity protectio= n? Wouldn't that assume that several initiators use the same PPK (so they = could use the same pseudonym)? Is that the sort of thing we should be enco= uraging? o Should this be addressed in this draft, or could it be addressed in a f= ollow-up draft? o If it would be addressed in a follow-up, would any hooks be required? = For example, would we want to introduce an opaque bit in a notify message t= o indicate this? o Would we be happy with always negotiating a child SA (as none of the th= ree proposals for stirring in the PPK attempt to protect the initial IKE SA= )? My opinion is that this could be placed in a follow-up draft. Thoughts??? --_000_20854b976b8546139adf78889bf75c3eXCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, I held this informal poll,= and here are the results:

 =

- = ;         For the first qu= estion (“how do we stir in the PPK”), there were no strong opin= ions; some people did express a preference for the third option (ValeryR= 17;s suggestion to modify only the initial SK_d).  I’ll update the draft to reflect that.

- = ;         For the second q= uestion (“how important is anonymity”), it would appear that th= e majority opinion is that this could be handled in a follow-up draft.=

 =

Michael Richards also su= ggested we attempt to address how to distribute the PPKs.  However, I = would agree with Valery Smyslov; this is out of scope for this document; fo= r example, the current IKE RFC allows preshared secrets, and does not address how to distribute them.

 =

I’ll be published = an updated draft shortly; are there any other issues people feel need to be= addressed?

 =

 

From: IPsec [m= ailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Tuesday, December 06, 2016 4:32 PM
To: IPsecme WG (ipsec@ietf.org)
Subject: [IPsec] Quantum Resistant IKEv2

 

In the WG meeting in Seoul, we discussed the Quantum= Resistant proposal for IKEv2, and decided to make the current draft (draft= -fluhrer-qr-ikev2-03) as work item.

 

During the discussion, two items were raised, and I = would like to hear how the wider WG feels about these two items:=

 

-     &= nbsp;    The first item is “how exactly do we stir in = the preshared key (PPK) into the keying material”.  By my count,= three options were on the table:

o   There is the option listed in the draft, whe= re we modify both the KEYMAT and SKEYSEED computations; stirring it into th= e KEYMAT implies that the IPsec SAs are generated with QR-resistant keying = material, while stirring it into the SKEYSEED implies that any child IKE SAs implies that any IKE SA (other= than the initial one) also has QR-resistant keying material.  This la= tter was done specifically so that an implementation can have protected IKE= SAs (by negotiating a child SA immediately)

o   Dan Harkins suggested that we modify only th= e KEYMAT.  This is a simpler option, and will continue to protect the = IPsec SAs; however this implies that any data protected by the IKE SA could= potentially be recovered by a Quantum Computer.

o   Valery Smyslov gave a suggestion that we ins= tead stir in the PPK into the initial SK_d; as all keying material is gener= ated based on that, this would also mean that IPsec SAs and any child IKE S= As are also protected.  This also means that an implementation would not need to remember the PPK after the = initial negotiation.  The only downside I can see is that we would hav= e to be a bit careful about when we update the SK_d (obviously, before we a= ctually use it).

To me, all three strike m= e as reasonable ideas (unless we decide that we will need to protect the re= al identity data encrypted via the IKE SA; in that case, Dan’s idea d= oesn’t protect that).  Can I get opinions as to which strikes the group as the best?  Are there any fourth opti= ons that people would want to put on the table?

 

-     &= nbsp;    The second item is anonymity; some people were inte= rested in preserving anonymity (however, not at the expense of excessive co= mplexity).  One idea that was brought up was that the initial exchange= would be done using pseudonyms (which would be sufficient for the responder to identity the PPK), and then once = initial IKE SAs have been established (in a QR form), exchange the real ide= ntities.  My questions:

o   Would this idea of pseudonyms actually give = any real identity protection?  Wouldn’t that assume that several= initiators use the same PPK (so they could use the same pseudonym)?  = Is that the sort of thing we should be encouraging?

o   Should this be addressed in this draft, or c= ould it be addressed in a follow-up draft?

o   If it would be addressed in a follow-up, wou= ld any hooks be required?  For example, would we want to introduce an = opaque bit in a notify message to indicate this?

o   Would we be happy with always negotiating a = child SA (as none of the three proposals for stirring in the PPK attempt to= protect the initial IKE SA)?

My opinion is that this c= ould be placed in a follow-up draft.

 

Thoughts???

--_000_20854b976b8546139adf78889bf75c3eXCHRTP006ciscocom_-- From nobody Mon Feb 13 07:56:31 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6933C1296E8 for ; Mon, 13 Feb 2017 07:56:29 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g259hHXZflLW for ; Mon, 13 Feb 2017 07:56:28 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF6B1296E7 for ; Mon, 13 Feb 2017 07:56:27 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vMVXT0bNVz37M; Mon, 13 Feb 2017 16:56:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487001385; bh=QxPJUolEfJc4l61mmj/+RY2d8F7xjsTkA8qKWLZubAo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=I7wwXAw5c99iv79oW5hu3qOq8thuPKOoDerHMXZjywAzmYr5VBnDXAQKPTHQmSUBU gBGcw8hxMj+2Pn7ywbDF2e400R20Hc02WJN+q3NcTbS7isemp/0mLyuifkb57z64Mz XuskYouqfeN4YKn08aBMDZ0b6ViyN/ANkGVlBeGc= 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 C4IzUg609YQM; Mon, 13 Feb 2017 16:56:24 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Feb 2017 16:56:23 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7DA582DEFF6; Mon, 13 Feb 2017 10:56:22 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7DA582DEFF6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 632FE41DA420; Mon, 13 Feb 2017 10:56:22 -0500 (EST) Date: Mon, 13 Feb 2017 10:56:22 -0500 (EST) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" In-Reply-To: <20854b976b8546139adf78889bf75c3e@XCH-RTP-006.cisco.com> Message-ID: References: <20854b976b8546139adf78889bf75c3e@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20 (LRH 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 \(ipsec@ietf.org\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:56:29 -0000 On Mon, 13 Feb 2017, Scott Fluhrer (sfluhrer) wrote: > Ok, I held this informal poll, and here are the results: The IETF is about forming a consensus. Asking for an opinion is good, but quantifying them should really be avoided as much as possibe. So while I think it is a good thing that you are asking (polling) the group with questions, I'm a little nervous when it appears that decisions are made in the draft based on the count of responses, especially seeing the turn out of responses is around 5 people. > -          For the first question (“how do we stir in the PPK”), there were no strong opinions; some people did express a preference for > the third option (Valery’s suggestion to modify only the initial SK_d).  I’ll update the draft to reflect that. I'm not convinced there is consensus on this topic yet. I've seen good arguments for different approaches. > -          For the second question (“how important is anonymity”), it would appear that the majority opinion is that this could be handled > in a follow-up draft. That indeed seemed to be the case, and importantly also aligns with the approach of the ID sending in the base IKEv2 document. And people pointed out no protocol changes are needed for implementations to use ephemeral IDs - as long we provide for that option as a NOTIFY in the IKE_INIT exchange. So perhaps this does need to be specified in the draft as an optional payload with value. > Michael Richards also suggested we attempt to address how to distribute the PPKs.  However, I would agree with Valery Smyslov; this is out > of scope for this document; for example, the current IKE RFC allows preshared secrets, and does not address how to distribute them. I agree. If we address how to distribute PPK's we would have basically created META-IKE. > o   There is the option listed in the draft, where we modify both the KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies > that the IPsec SAs are generated with QR-resistant keying material, while stirring it into the SKEYSEED implies that any child IKE SAs > implies that any IKE SA (other than the initial one) also has QR-resistant keying material.  This latter was done specifically so that an > implementation can have protected IKE SAs (by negotiating a child SA immediately) [...] > o   Valery Smyslov gave a suggestion that we instead stir in the PPK into the initial SK_d; as all keying material is generated based on > that, this would also mean that IPsec SAs and any child IKE SAs are also protected.  This also means that an implementation would not need > to remember the PPK after the initial negotiation.  The only downside I can see is that we would have to be a bit careful about when we > update the SK_d (obviously, before we actually use it). This and the "optionally immediately perform a IKE rekey" could use more discussion in my view. > o   Should this be addressed in this draft, or could it be addressed in a follow-up draft? [this] being ID protection, I do think that since IDs and PPK identifiers are closely related, it belongs in this document. > o   Would we be happy with always negotiating a child SA (as none of the three proposals for stirring in the PPK attempt to protect the > initial IKE SA)? > > My opinion is that this could be placed in a follow-up draft. I think this needs further discussion, as the optimal outcome would be for the WG to agree on one approach and avoid another bell and whistle to pick from. Paul From nobody Mon Feb 13 11:06:35 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C288B1297D4 for ; Mon, 13 Feb 2017 11:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3JNg7IH93sR for ; Mon, 13 Feb 2017 11:06:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F09F1296EE for ; Mon, 13 Feb 2017 11:06:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B9B7420560; Mon, 13 Feb 2017 14:27:50 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 87E826381A; Mon, 13 Feb 2017 14:06:27 -0500 (EST) From: Michael Richardson To: Paul Wouters In-Reply-To: References: <20854b976b8546139adf78889bf75c3e@XCH-RTP-006.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:06:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> Michael Richards also suggested we attempt to address how to >> distribute the PPKs.=C2=A0 However, I would agree with Valery Smyslo= v; this >> is out >> of scope for this document; for example, the current IKE RFC allows >> preshared secrets, and does not address how to distribute them. > I agree. If we address how to distribute PPK's we would have basically > created META-IKE. I'm specifically asking that we agree on some simple things. Like that they be written in hex, or bubble-babble, or base64, etc. Simple stuff so that we can get a PPK from one machine (via sneaker-net) to another machine without needing to write some perl to convert. =2D- =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAliiA7MACgkQgItw+93Q 3WXukAf/TBwvHPYLIOxnwd399KOLvw/GJXJO9q8boCUqzGG/nJo9LKI1RCRFCqkv KfYX9RM1eCj4hLKNG2EIGQzE6RxZJwGpzvvp9VkCrCG72BW498OsC8hgudNJyy4m sEnN67JuWTBgQX8EgLICgaJ/deyLtltBF/oTuBErrHsX/xqQYO19cM178SEonhS/ I4Pt+wnv/N0+yeH9ChMKyf95vQt9IQWnoS+ZWw+hF2Aw93ID6dZCDh9iPM2d2Qta FGgOewDnXz1CkhI1TtoFwkDna4InUa1yzBsrzZRXKTQwofECVNIhCd1Fl/jq2P89 dBni2LgRMaWz53AVKLN/2/X3FZG6Vg== =q72z -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 14 17:06:50 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE7D129669 for ; Tue, 14 Feb 2017 17:06:49 -0800 (PST) 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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cldjQwR9ELtx for ; Tue, 14 Feb 2017 17:06:48 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 382D512706D for ; Tue, 14 Feb 2017 17:06:48 -0800 (PST) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 0E5751E0010 for ; Tue, 14 Feb 2017 17:06:48 -0800 (PST) To: ipsec@ietf.org References: <20854b976b8546139adf78889bf75c3e@XCH-RTP-006.cisco.com> <2110.1487012787@obiwan.sandelman.ca> From: Dan Harkins Message-ID: Date: Tue, 14 Feb 2017 17:06:47 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2110.1487012787@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 01:06:49 -0000 Hi Michael, On 2/13/17 11:06 AM, Michael Richardson wrote: > Paul Wouters wrote: > >> Michael Richards also suggested we attempt to address how to > >> distribute the PPKs. However, I would agree with Valery Smyslov; this > >> is out > >> of scope for this document; for example, the current IKE RFC allows > >> preshared secrets, and does not address how to distribute them. > > > I agree. If we address how to distribute PPK's we would have basically > > created META-IKE. > > I'm specifically asking that we agree on some simple things. > Like that they be written in hex, or bubble-babble, or base64, etc. > Simple stuff so that we can get a PPK from one machine (via sneaker-net) to > another machine without needing to write some perl to convert. > Think of whom you're trying to protect against. The first to have a QC are most likely nation-states that you really aren't too happy with today and will most likely be less happy with in 20 years. If we have some specification on using sneaker-net with hex or bubble-babble or base64, etc that's what's gonna be deployed and it's gonna be the weakest link in this scheme. I dare say that your sneaker-net would need to be protected by men with guns that you trust implicitly driving armored cars to come close to the security you think you're getting by mixing the PSK into the keying material. On top of that, I think it would be good to try and make sharing the PSK as difficult as possible. If there are > 1 people running around with a group PSK then successfully breaking into the computer of one of them will void the security the I-D is providing for the entire group. If we make it easy to share that will be the first thing that will be done. A sneaker-net compatible flat file would encourage the laziest and least secure behavior. PKIX defined a symmetric key package and it has many options to securely wrap an arbitrary symmetric key, or many symmetric keys in a package. It can also include a key id to use when describing the symmetric key. We should look at something like that. It's ASN.1 and everyone hates ASN.1 but an alternative could be defined with JSON or something like that. The symmetric key package can be deployed using the EST extensions that Sean Turner has proposed-- you authenticate EST using a certificate, the EST server uses your authenticated identity to locate your package and sends it to you. Yes it requires you to implement a whole bunch of other stuff but I think it's worth the price we're placing on the PSK. If you hate my idea then at least take this as an argument for declaring the matter out of scope for the QC-resistant I-D and tackling it later. regards, Dan. From nobody Wed Feb 15 01:09:09 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAFD128AC9 for ; Wed, 15 Feb 2017 01:09:07 -0800 (PST) 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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vEp71oHKbYD for ; Wed, 15 Feb 2017 01:09:05 -0800 (PST) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B65F128B38 for ; Wed, 15 Feb 2017 01:09:05 -0800 (PST) Received: from [152.96.214.154] (unknown [152.96.214.154]) by mail.strongswan.org (Postfix) with ESMTPSA id 71D1E40170; Wed, 15 Feb 2017 10:09:02 +0100 (CET) To: Tero Kivinen References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> From: Andreas Steffen Message-ID: <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> Date: Wed, 15 Feb 2017 10:09:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <22684.25414.470545.969594@fireball.acr.fi> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000105060301070507060407" Archived-At: Cc: ipsec@ietf.org, David Schinazi Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 09:09:07 -0000 This is a cryptographically signed message in MIME format. --------------ms000105060301070507060407 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Tero, I personally think that 0 would have been legitimate for the "Identity" hash but the next unassigned value (5) is also ok for me. Could you please ask IANA for an early assignment of the code point? strongSwan 5.5.2 with Ed25519 support is ready to be deployed, thus we would be able to release the stable version as soon as the code point has been assigned. Best regards Andreas Steffen On 09.02.2017 13:40, Tero Kivinen wrote: > Ah I noticed that my last call email had wrong draft name in the > subject line and in the link. The correct draft name is of course > draft-ietf-ipsecme-eddsa-00 not *-nir-* version. >=20 > David Schinazi writes: >> I've reviewed this draft. I support it and believe it is ready to move= forward >> towards becoming a standards-track RFC. Also, would it make sense to a= sk >> IANA for early assignment of the code point? Using 0 sounds reasonable= to me. >=20 > As this is expert review registry there is no need to ask for early > allocation, the normal process is just to fill in the IANA general > request for assignments, which then goes to the IANA and they will > then send it to the expert (me) for verification. >=20 > If normal number (other than 0) would be given out, then I would just > say yes, but allocating 0, which in registry is marked as: >=20 > 0 Reserved [RFC7427] >=20 > and is not part of the : >=20 > 5-1023 Unassigned >=20 > range, then I would be bit more hesitant to give it out, and would > most likely want to poll the WG and list before making decision. >=20 > I actually myself think it would be better to just allocate next free > number from the unassigned space, and keep the value 0 as reserved... >=20 > For example we do not use value 0 of Encryption Algorithms transform > to mean ENCR_NULL, we do have separate number allocated for it. On the > other hand we do have value 0 meaning NONE in the Integrity algorithm > transform ID table and for diffie hellman values, but there the > meaning is bit different, it means there is no value for that id, here > it would be meaning that there is this identity function version of > the hash function.=20 >=20 > As an expert and as a implementor I think I would prefer next free > number over 0... Quite commonly in the code we use value 0 as meaning, > we have not yet received anything, or we have not yet initialized this > field, and having separate value for identity function might make > things easier. But if others have good reasons why the value 0 is > better, feel free to tell me... >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D[INS-HSR]=3D=3D --------------ms000105060301070507060407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CwUwggUbMIIEA6ADAgECAhBuUxLd3zNyJYxWKYW719FJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTA5MTkyNzQxWhcNMTcwOTA5MTkyNzQxWjBYMScwJQYDVQQDDB5hbmRy ZWFzLnN0ZWZmZW5Ac3Ryb25nc3dhbi5vcmcxLTArBgkqhkiG9w0BCQEWHmFuZHJlYXMuc3Rl ZmZlbkBzdHJvbmdzd2FuLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKHS uZp+jtu8bNOw/9/xh4LKs/ZWzxMF12nZSKWYm/2+jokenFQ3i2VaAtvqD1zdVRfsNWvUDu/e 6VN0PPTyzSbZW/2a8WMa9WSmi9WBTGv8uI7LOMq2kRdRrlhjW5FVwVramtBd0mT9/4Y2qOYh HtlEA5Lj3djfTnWKtF8gc3Uc6ZPNMbtVhA5+9CW1aqZx2tuukC1uYZdLgYOQoCRySMFa7lVD OoMk5fOZePKsM/RfN45Pn1drY7jsfWNdnuo9AZtSf75Vs6E8ffELt6aU1jp7CRCXc1KgHeZC gdFZVhO3Kzbi1lCr0T+o80+IoEJH2hMh12V+ndfhErjCLc5wtKsCAwEAAaOCAcIwggG+MA4G A1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUG99dVPmyPEV8VjDhmwI8by/ngYswHwYDVR0jBBgwFoAUJIFsOWG+SQ+P txtGK8kotSdIbWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3NjYS5jbGllbnQxLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9zY2EtY2xpZW50MS5jcmwwKQYDVR0RBCIwIIEeYW5kcmVhcy5zdGVmZmVuQHN0cm9u Z3N3YW4ub3JnMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAE QDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3Ns LmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBAKE27itDRB20DgVxymhhr0XDgjXgOGuu W8Y04kWMDhUjzzP2wKcZM4lwmmU1tAe9afnpbXO6CuBnW2F0qIVCmk4698Oi7K18SiQu6RoB L+1IbFHxoz4AQvRHTkuB09xJOlJl5w4rS1KOd1qtd0qsiGiXzjEGB+ggwPSloQ5+c9x4XwDE eI4jbHIh589UskSBuTtKxfaPxs/20AX2QN4ZdyLcWqf4Cg2gMn8oQwgC2dBCXSPRHjTua9q2 PNZThVkd5fml5N3PC/iCPbQ5jLp1CaR9pJHq7mQDkV7eEJ3a53V8ii+TF9NrCSb8v/KeoR39 5PDNwk1m8obnE7lQay4Fa/MwggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqG SIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYw MTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQL EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3 w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwObhajcVmnKVxhrUwkZPXR AwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51 M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsSslxLce0CGWRs T8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrOAyDPFJVU vKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2Zz Y2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRz c2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5j cnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFul F2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8B Aluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs 0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp 4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW /ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2 D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQyCkC2aNNsK5cWOojBar5c7HplX9aHYUCZ ouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3 s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2B2NLatidKE/m7G+rB9m+FlVg IiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS 3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKa xnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQblMS3d8zciWMVimF u9fRSTANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTcwMjE1MDkwOTAyWjAvBgkqhkiG9w0BCQQxIgQgN4QUYfvdHZ4HCKw6 6LvqrctP9zbx3ZOtxeFIjhZfnIUwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJ YIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYBBAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EC EG5TEt3fM3IljFYphbvX0UkwgZwGCyqGSIb3DQEJEAILMYGMoIGJMHUxCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEG5T Et3fM3IljFYphbvX0UkwDQYJKoZIhvcNAQEBBQAEggEAG4OMH6vWY1HhWe1wkKOpanC4Rqew S+iGnrsWiPl4i8j+rUl2bLLcbCE+n2NuHsT5HmgTUf1r/ZU9AmzBnrlxxggfTPKgBWwC8FwB RGlz0h90qJhbdlYWLLTxl4bFTxXZG7hChUjQZo4BwawKOfGLVYA3dfEcAMEqMRduTxZ03QEu pP4GDr4J7ttkLjTgY8bBvua+Xv/g/berpedmdpargCjR52JnRp76oMC5e1jxdDi5IzwH//BN gEDqL1gRQ/5FZfY2al/El/oW19eSFT3Mq9KboEs/lA100+I3Zcd9feRIbI7L2mc40T0lYLgr rQa6G38RArHjxvn4x2mXEkAVPgAAAAAAAA== --------------ms000105060301070507060407-- From nobody Wed Feb 15 07:11:16 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD9129676 for ; Wed, 15 Feb 2017 07:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgVfYJXiUEUi for ; Wed, 15 Feb 2017 07:11:13 -0800 (PST) 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 6E9AE12966E for ; Wed, 15 Feb 2017 07:11:13 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1FFB2Nv022796 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Feb 2017 17:11:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1FFB1Aj000550; Wed, 15 Feb 2017 17:11:01 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22692.28549.958589.705943@fireball.acr.fi> Date: Wed, 15 Feb 2017 17:11:01 +0200 From: Tero Kivinen To: Andreas Steffen In-Reply-To: <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: Cc: ipsec@ietf.org, David Schinazi Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 15:11:15 -0000 Andreas Steffen writes: > I personally think that 0 would have been legitimate for the "Identity" > hash but the next unassigned value (5) is also ok for me. > > Could you please ask IANA for an early assignment of the code point? > strongSwan 5.5.2 with Ed25519 support is ready to be deployed, > thus we would be able to release the stable version as soon as > the code point has been assigned. Before we can make code point allocation, we need to agree on whether it is going to be zero or next number. As you can see from the emails in this list there is not agreement on this yet, so even if authors make IANA request to ask for assignment, when it comes to me (as for expert review) few days later, I would wait for the comments on the list to agree on which number we are going to allocate. Now it seems more people are supporting allocating something else than zero... As for the process: > > As this is expert review registry there is no need to ask for early > > allocation, the normal process is just to fill in the IANA general > > request for assignments, which then goes to the IANA and they will > > then send it to the expert (me) for verification. And then we will then come back to this list to finish this discussion... -- kivinen@iki.fi From nobody Wed Feb 15 08:56:09 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70A7129682 for ; Wed, 15 Feb 2017 08:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoPDvpX4qci1 for ; Wed, 15 Feb 2017 08:56:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37761129649 for ; Wed, 15 Feb 2017 08:56:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B09D42054C; Wed, 15 Feb 2017 12:17:34 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D876A6381A; Wed, 15 Feb 2017 11:56:04 -0500 (EST) From: Michael Richardson To: Dan Harkins In-Reply-To: References: <20854b976b8546139adf78889bf75c3e@XCH-RTP-006.cisco.com> <2110.1487012787@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:56:08 -0000 --=-=-= Content-Type: text/plain Dan Harkins wrote: > Think of whom you're trying to protect against. The first to have a > QC are most likely nation-states that you really aren't too happy with > today and will most likely be less happy with in 20 years. If we have > some specification on using sneaker-net with hex or bubble-babble or > base64, etc that's what's gonna be deployed and it's gonna be the > weakest link in this scheme. I dare say that your sneaker-net would > need to be protected by men with guns that you trust implicitly driving > armored cars to come close to the security you think you're getting by > mixing the PSK into the keying material. I don't think your model (protected by men with guns) is necessarily wrong. I am imagining Brinks trucks myself, but we can also consider a staring role for Keanu Reeves... or Agent 86, as you wish. > On top of that, I think it would be good to try and make sharing the > PSK as difficult as possible. If there are > 1 people running around Hmm. My concern is more along the lines of: getting this PSK entered correctly is difficult, so when the boss is breathing down your neck, you simply turn off the mechanism. > PKIX defined a symmetric key package and it has many options to > securely wrap an arbitrary symmetric key, or many symmetric keys in a > package. It can also include a key id to use when describing the > symmetric key. We should look at something like that. It's ASN.1 and > everyone hates ASN.1 but an alternative could be defined with JSON or > something like that. The symmetric key package can be deployed using > the EST extensions that Sean Turner has proposed-- you authenticate EST > using a certificate, the EST server uses your authenticated identity to > locate your package and sends it to you. Yes it requires you to > implement a whole bunch of other stuff but I think it's worth the price > we're placing on the PSK. This sounds like a great idea. I will even agree to eat the pre-established ASN.1 here. I had no preconceived notion as to the format, just that we have a specific way to get the stuff in. (I don't think, in a post-QM world, we can authenticate the EST with a certificate though, but that's a detail. I think it's still an armored Brinks truck with a thumb drive or whatever) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlikiCQACgkQgItw+93Q 3WX6hAgAuyK8CaSqPvZ+t9CalxC1fxmKomxDl5CIzRBuij4SPjjCEGryLRN0Z/mR J5ATXJrTO7vfoBvBbqZB97D+D354sfoqH/neCZJOzsHElyDZyho69IUDCeINJ0Kr 41Syfd4IuGpTSM6yArgKyfwBJPaENbHviJASH97UgaEFBNuclc0E0LEQCRFegIFT irJZttjakm4Tqw/1HPMfj+johf2HKldBPeZWGQXZ66JDH6UjIeeG0OPUvgM+bA9a ctifuyppM9mVz41nl5CGw1bWW4yDGNWBDQefulQr7jwIPPqWDef932TzavfNkrk9 vZenyapHS3xPutAK8C7NIWW4z9avmQ== =SKbm -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 15 09:11:07 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B205D129AFC; Wed, 15 Feb 2017 09:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X6zwkXrTqIJ; Wed, 15 Feb 2017 09:11:04 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 3509E129AFA; Wed, 15 Feb 2017 09:11:04 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id r18so9220095wmd.3; Wed, 15 Feb 2017 09:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ExoZLQAuYIuBVQySgUowlqwDiWNi/q63S1fFvNCkGoY=; b=OVaNcUu9E5qqXwdX0miU4WkKr0U5sJWpcPqk8Ng54RUuvtGoWH5Six2JmOHM61PYmW DEYbTDiydmJMqb2/vg13udbG2+F4l0sMaldi9dNSAhOdOzLnlLi9ErpVi4Y1OyTgIm/4 Oc/qrDQfeT7TF7RMvzwYW5+kem7v/4d9m12+rQnLNDbG2bTEhdANfth+DeT4J1bcePPe wjgzdnPxKqkpU1UIAWZD26NiCCszfpjFWuI+zTuh+3uauMyuAg8Bq/9hdBQfW2bJGsuM 7XUcJwWSDzOwiOYhKWuseO/LEMdv6dyxFsuOZ5YLJRVvCKkfFAxvqGyniiAfP3Drx7pZ GRTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ExoZLQAuYIuBVQySgUowlqwDiWNi/q63S1fFvNCkGoY=; b=s67MFKvZsulovNbaS1O0zEIxB5XH/BEthar1x5iJNs7sWP5oBxpA+wmXNjwVuw9dju vYHScKZK5m3hVsxp3f16OdCycjhZpGU3lfT80ITaPE6oivdqspqghAXlNOJZKU2qJfmn gtxp+IujoZ/+T+feBzW2V1WUhfjpygXpUSWORW24qCSgRlCC0g4D9uG3RJ3m3ntXUWv5 mJ+rAyAr6yGNOtqZz+kJnXtfWnVH+3GpZDM7zQpfGipG/qVzFjc8/dP+pTrB+cf/PCdn CYBuKYw6BgEGbF6TQJQuj0K3dAuMDk+31oz0NCp5Fm938Dpc9NnMBH8JRK8EkUBmPqhg o58w== X-Gm-Message-State: AMke39ksXQ4P+HpPHRXnx6eXm/Lew7q331VuhLguUMsPzUWPbcoor/i01ziEHN3FzSgwPw== X-Received: by 10.28.189.195 with SMTP id n186mr8392736wmf.77.1487178662731; Wed, 15 Feb 2017 09:11:02 -0800 (PST) Received: from [192.168.137.219] ([176.13.243.119]) by smtp.gmail.com with ESMTPSA id w204sm77151wmd.17.2017.02.15.09.11.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:11:01 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FD888076-C499-4DA5-A43F-F543E4AE32C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Feb 2017 19:10:58 +0200 In-Reply-To: <0aa4a488-6762-9f8c-02c3-8718d3becf8f@redhat.com> To: Paul Wouters References: <41B74159-1141-4ED0-B389-2C1B6452F39A@gmail.com> <0aa4a488-6762-9f8c-02c3-8718d3becf8f@redhat.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ipsec@ietf.org, Eric Rescorla , draft-ietf-ipsecme-rfc4307bis@ietf.org, IESG Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:11:05 -0000 --Apple-Mail=_FD888076-C499-4DA5-A43F-F543E4AE32C7 Content-Type: multipart/alternative; boundary="Apple-Mail=_5AE1F913-6F80-4203-A768-201F90F4306C" --Apple-Mail=_5AE1F913-6F80-4203-A768-201F90F4306C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One correction > On 15 Feb 2017, at 19:05, Paul Wouters wrote: >=20 >>> Nit: You need only one of the public values and the complementary >>> private value from the other side. >>=20 >> Right. >=20 >=20 Instead of this: > exchange provides keys for the session. If an attacker can = retrieve > one of the private numbers (a, or b) with the corresponding public = values (g**a, or g**b), > then the attacker can compute the secret and the keys used and I suggest this: > exchange provides keys for the session. If an attacker can = retrieve > one of the private numbers (a or b) with the corresponding public = values (g**b or g**a), > then the attacker can compute the secret and the keys used and This way it=E2=80=99s more corresponding (and without the comma) Yoav --Apple-Mail=_5AE1F913-6F80-4203-A768-201F90F4306C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One correction

On 15 Feb 2017, at 19:05, Paul = Wouters <pwouters@redhat.com> wrote:

Nit: You need only one of the public values and the = complementary
private value from the other side.

Right.



Instead of this:

   exchange provides keys for the session. =  If an attacker can retrieve
   one of the private = numbers (a, or b) with the = corresponding public values (g**a, or g**b),
   then the attacker can = compute the secret and the keys used and

I suggest = this:

   exchange provides keys for the session. =  If an attacker can retrieve
   one = of the private numbers (a or b) with the corresponding public values = (g**b or g**a),
   then the attacker can compute the secret = and the keys used and

This way it=E2=80=99s more corresponding = (and without the comma)

Yoav


= --Apple-Mail=_5AE1F913-6F80-4203-A768-201F90F4306C-- --Apple-Mail=_FD888076-C499-4DA5-A43F-F543E4AE32C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYpIuiAAoJELhJCxUKWMyZH2QH/jomkRLrkfgr1HVCTJzDstVT PdjiSfLE8BFr1FUq8DCftjC4+awgHPvU4jfAGzmIVs3sv1f9C1YW0fC1cyNzYOp1 1D8LLinJ5kW8nDbBzYRFvwFiKc9VrzZZAn2RSw1eVLPiBb0JLCB5UkyInRSjN8By 7il6N261n9D2bSe49JhTeWYJh7PxFs95hvZLr8C+j1m1GkgLYbgc6TKnHTNc/dgF 5N7x+LzCCSnPzXYAWCeXLcmoYLO6FFrb1Er8UpPlKFS/OdrEU0pv+JWvuqTVEn83 I2xYE+gCmUbrYLqMuYKsfjBkhKEfT4FcMZmtTOt6bAFVCyoe5/uyz2ieNrxVX00= =5HKU -----END PGP SIGNATURE----- --Apple-Mail=_FD888076-C499-4DA5-A43F-F543E4AE32C7-- From nobody Wed Feb 15 09:12:30 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F851296AA for ; Wed, 15 Feb 2017 09:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcRRFVwHeN4z for ; Wed, 15 Feb 2017 09:12:25 -0800 (PST) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::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 42277129459 for ; Wed, 15 Feb 2017 09:12:25 -0800 (PST) Received: by mail-yb0-x230.google.com with SMTP id 123so46548800ybe.3 for ; Wed, 15 Feb 2017 09:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EYdEumqpYKMX3ZMqoZ+P10qPNfE5bVjWTeW4AURFJ2w=; b=rDXm4Oahy17y1HYz+dbrWB1UWNjoLeU8sjm8DVWcEJR2Xf5gaJuYpHlZiW4OiBRA7u vWQYULaCmj+5o0xIZHh5xYSo57Q1at0iPmkbCpph+5EfA39FnjeIVRwZeZci4f8a1xOo 4TJ4mGWuPTmuHqdkZycCdOS80MZK9wN4IjQI0ag9nuLfKFCxVC4Gf5nwfkZ+sz3/nQs4 S0Ootp3O86tzUh5+oww8TcjSqXNYXqrUKctl1uAfeJ5Aghu5PuwS4kqDRLa/D6iaZlHK CQZ9Cf+l/OcuNiXGPzTjAPzvQkr2NQzgUxgVCmbxOP9VqmLG10yth+WfG0OoEENIBS+S f47w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EYdEumqpYKMX3ZMqoZ+P10qPNfE5bVjWTeW4AURFJ2w=; b=hU545ViECJvIs/X40gg3hV5xeZpbEIGY8IC+xX1+6CSDWMjpKJDnZQQmpCfF742ypT jSWzPnG8613kaMtleZmE03ig0PLyVC6L+gsQSVPCP7454nv39A+BZTJp5Dzu9QAngB+Q ZLuw1iiscLt90OVV6mp8B0B6KAYhCrVgD51hiBSP9alGTYhm7BbNyaY2XCqeC7FmbAZV /QfX4Z2EXu3lKu5yvG4GUvDvxbxr/kWAKWd/dDpjzfRItfxJCJqufmloZjljfrx8WEBU q8jWJNHK944Ju+QGqczBQ/qsItdEZok/mu7mY6rBS8t9w5XVUJEHYV5ntcKhz6m2UkBi ACoQ== X-Gm-Message-State: AMke39nL4KSR/RInhcaf5ReZlxCgQiUqwLoAq1xXTLelldRfbwQixuaEWNW6c0/IWnSSl7mH9PtIFdd+0zZ1Gg== X-Received: by 10.37.124.195 with SMTP id x186mr25177052ybc.105.1487178744524; Wed, 15 Feb 2017 09:12:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Wed, 15 Feb 2017 09:11:44 -0800 (PST) In-Reply-To: References: <41B74159-1141-4ED0-B389-2C1B6452F39A@gmail.com> <0aa4a488-6762-9f8c-02c3-8718d3becf8f@redhat.com> From: Eric Rescorla Date: Wed, 15 Feb 2017 09:11:44 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a114bc396c92dec054894c89b Archived-At: Cc: ipsec@ietf.org, Paul Wouters , draft-ietf-ipsecme-rfc4307bis@ietf.org, IESG Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:12:27 -0000 --001a114bc396c92dec054894c89b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would use "complementary" rather than corresponding. -Ekr On Wed, Feb 15, 2017 at 9:10 AM, Yoav Nir wrote: > One correction > > On 15 Feb 2017, at 19:05, Paul Wouters wrote: > > Nit: You need only one of the public values and the complementary > private value from the other side. > > > Right. > > > > > Instead of this: > > exchange provides keys for the session. If an attacker can retrieve > one of the private numbers (a, or b) with the corresponding public > values (g***a**,* or g***b*), > then the attacker can compute the secret and the keys used and > > > I suggest this: > > exchange provides keys for the session. If an attacker can retrieve > one of the private numbers (a or b) with the corresponding public > values (g***b* or g***a*), > > then the attacker can compute the secret and the keys used and > > > This way it=E2=80=99s more corresponding (and without the comma) > > Yoav > > > --001a114bc396c92dec054894c89b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would use "complementary" rather than correspo= nding.

-Ekr


On Wed, Feb 15, 2017 at 9:10 AM, Yo= av Nir <ynir.ietf@gmail.com> wrote:
One correction

On 15 Feb 2017, at 19:05= , Paul Wouters <pwouters@redhat.com> wrote:

Nit: You need only one of the public values and the complementary
p= rivate value from the other side.

Right.


=

Instead of this:

=C2=A0=C2=A0=C2=A0exchange provides keys for the session.=C2=A0 If = an attacker can retrieve
=C2=A0= =C2=A0=C2=A0one of the private numbers (a, o= r b) with the corresponding public values (g**<= font color=3D"#ff2600">a, or g*= *b),
=C2=A0=C2=A0=C2=A0then the attacker can compute the secret and the keys= used and

I suggest this:

=C2=A0 =C2=A0exchange provid= es keys for the session.=C2=A0 If an attacker can retrieve
=C2=A0=C2=A0=C2=A0one = of the private numbers (a or b) with the corresponding public values (g**b=C2=A0or g**a),
=C2=A0=C2=A0=C2=A0th= en the attacker can compute the secret and the keys used and

This way it=E2=80=99s more correspondi= ng (and without the comma)

Yoav



--001a114bc396c92dec054894c89b-- From nobody Wed Feb 15 09:22:57 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9128A129627; Wed, 15 Feb 2017 09:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4-9Cz8zhw0j; Wed, 15 Feb 2017 09:22:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6804612966D; Wed, 15 Feb 2017 09:22:51 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 34EA135A81D; Wed, 15 Feb 2017 17:05:27 +0000 (UTC) Received: from bofh7.nohats.ca (vpn-234-54.phx2.redhat.com [10.3.234.54]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1FH5Qrw008986; Wed, 15 Feb 2017 12:05:26 -0500 To: Yoav Nir , Eric Rescorla References: <41B74159-1141-4ED0-B389-2C1B6452F39A@gmail.com> From: Paul Wouters Message-ID: <0aa4a488-6762-9f8c-02c3-8718d3becf8f@redhat.com> Date: Wed, 15 Feb 2017 12:05:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <41B74159-1141-4ED0-B389-2C1B6452F39A@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 15 Feb 2017 17:05:27 +0000 (UTC) Archived-At: Cc: ipsec@ietf.org, draft-ietf-ipsecme-rfc4307bis@ietf.org, IESG Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:22:52 -0000 On 02/15/2017 02:35 AM, Yoav Nir wrote: > Hi, Ekr. > > Thanks for the review. Comments inline. > > On 15 Feb 2017, at 3:15, Eric Rescorla wrote: > >> I had a few comments on this document >> >> S 3.1. >> ENCR_AES_GCM_16 was not considered in RFC4307. At the time RFC4307 >> was written, AES-GCM was not defined in an IETF document. AES-GCM >> was defined for ESP in [RFC4106] and later for IKEv2 in [RFC5282]. >> The main motivation for adopting AES-GCM for ESP is encryption >> performance and key longevity compared to AES-CBC. This resulted in >> >> It's not clear that GCM actually offers greater key longevity. Note that TLS is >> recommending that far fewer than 2^{64} blocks of AES-GCM be encrypted >> before changing keys. > > When GCM was adopted for the first time (in both ESP and TLS) it was thought that it would offer greater key longevity than CBC. By now this has changed. I guess we can remove those three words. I agree with removing the key longevity part. >> S 3.4. >> exchange provides keys for the session. If an attacker can retrieve >> the private numbers (a, or b) and the public values (g**a, and g**b), >> then the attacker can compute the secret and the keys used and >> >> Nit: You need only one of the public values and the complementary >> private value from the other side. > > Right. I agree with rewriting this. How about: exchange provides keys for the session. If an attacker can retrieve one of the private numbers (a, or b) with the corresponding public values (g**a, or g**b), then the attacker can compute the secret and the keys used and And David noticed the reference for RFC7634 should be changed from normative to informative. I'll do a new release with these changes if no one objects in the next day or so :) Paul From nobody Wed Feb 15 10:19:32 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E498E129B1A; Wed, 15 Feb 2017 10:19:26 -0800 (PST) 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.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148718276693.28169.12567668145423867480.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 10:19:26 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:19:27 -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 of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Daniel Migault John Mattsson Paul Wouters Yoav Nir Tero Kivinen Filename : draft-ietf-ipsecme-rfc7321bis-04.txt Pages : 14 Date : 2017-02-15 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-04 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 Thu Feb 16 10:32:04 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C24B1294F8; Thu, 16 Feb 2017 10:32:03 -0800 (PST) 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.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148726992363.1011.1624468258017505370.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 10:32:03 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:32:03 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-16.txt Pages : 18 Date : 2017-02-16 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). 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-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-16 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 Thu Feb 16 10:35:19 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB158129615 for ; Thu, 16 Feb 2017 10:35:17 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQJjCdnyAV9h for ; Thu, 16 Feb 2017 10:35:15 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4560A129636 for ; Thu, 16 Feb 2017 10:35:15 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vPPwK204BzD47 for ; Thu, 16 Feb 2017 19:35:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487270113; bh=Avu0K37s2nhRhg5YbZEFQMorY3dyjAyeE1qChI6KPxs=; h=Date:From:To:Subject:In-Reply-To:References; b=BhVbmp8kvLsjjGQcUJ05OHnT14DM8IKLKpEw2ZCkGQ4+mdhL1pNKfxpdfQ8VCZ7Kd ho5T8JeBOMM49/B/yToSZC2/xzW8+524eYr5xCnxpVK8rRvDh3022bgooOUxf6WqSR xOcAh85FGkrdGu1Hm66/WmmIfoiRGEDjIcy4uTZc= 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 56CF7zYi0ycr for ; Thu, 16 Feb 2017 19:35:11 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 16 Feb 2017 19:35:11 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 484352DEFF3; Thu, 16 Feb 2017 13:35:10 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 484352DEFF3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 35A1E41D926D for ; Thu, 16 Feb 2017 13:35:10 -0500 (EST) Date: Thu, 16 Feb 2017 13:35:10 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <148726992363.1011.1624468258017505370.idtracker@ietfa.amsl.com> Message-ID: References: <148726992363.1011.1624468258017505370.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:35:18 -0000 On Thu, 16 Feb 2017, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-16 This version incorporates the suggestions of ekr/yoav to remove the claim that AES-GCM has better key longevity and rewrites the DH attack line as suggested by them. Paul From nobody Thu Feb 16 12:11:41 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC05128E18 for ; Thu, 16 Feb 2017 12:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWuyzVMubh4r for ; Thu, 16 Feb 2017 12:11:39 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 76E0B1293EB for ; Thu, 16 Feb 2017 12:11:39 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id v186so75274369wmd.0 for ; Thu, 16 Feb 2017 12:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Z8OiRNSCFAIxTa1E0Oqfpt3GSMBQyuVHRC7U7wzh+bg=; b=gN/q5Dk8y/1H7u6Nqj0INV0FKv9sbTWTZPXCj4XWHpT3trX9sbazxRnN/NV6OVZPDn noFHPyXqwVHd+HfqJDlbMSIEgfGtCB40qH8xQjQ0RKSL82a/qwWQWWmy6v4aDnKXeraK wAe58JOVLfzaNfIkbcrVdI9nJ/CZAn6O6PzKmwOML4nsUsGzT3yV8QXnU8m5+oQHewCK 2NiukGI7mLpJLmo77I83//GNpJUSRs974XKZ57tB/A9DOUEVAr2M3eQ7r08h/IithGxm QS8HkrWLubUwGaUg/Y9/N6aM/SrP5SNxLXGvqNAJ7nScny1IvMxWNQKrceTOL8O+q2fA ujoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Z8OiRNSCFAIxTa1E0Oqfpt3GSMBQyuVHRC7U7wzh+bg=; b=uP+FZtbd0JgckrPxUpL+K6VOPFCoOPQCsy4nofqq0gpLn8RT4XDFN7nrb5MBxYhvjl 1lSVFJvXLq0QorhHn6OBwtDoS+HCeZVbZupum2trw++A8YM4/Zh6NQ6RBhlBnNyHXdJy 6w4XthtMQKVg8oPrTAi/7eHlDxzbKtbSoqNmHa5bZDaYMI303yn1eWYuBEbEZS5Dl66X Fwf28+MGW35H2026Ld1mjGysoLPzNoWYaLyWQbUuFB5U21TUqhXfU6iW8NuqD8hvHzFz nN0KpkPEkbvrZG8t5AJogAh0lCdD19ezaWoUd71FvJxcaH45u7qwyvgwyKloz8W25VJT MSqA== X-Gm-Message-State: AMke39mdAE4DWIoniwXDxxhzmqWVXLPtLjh6dHpjTYaCoLVzeu2ApWkvhCE2sMdLfHt2IA== X-Received: by 10.28.135.82 with SMTP id j79mr13650559wmd.19.1487275897964; Thu, 16 Feb 2017 12:11:37 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p62sm1466179wmb.25.2017.02.16.12.11.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 12:11:37 -0800 (PST) From: Yoav Nir Message-Id: <67136360-A026-42D5-9171-111DC9C2A5C1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AD470999-4F2B-45DE-B68E-5159611D0BC2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Feb 2017 22:11:34 +0200 In-Reply-To: To: Paul Wouters References: <148726992363.1011.1624468258017505370.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:11:41 -0000 --Apple-Mail=_AD470999-4F2B-45DE-B68E-5159611D0BC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Almost there. You didn=E2=80=99t reverse the complementary public keys = (g**b or g**a) instead of (g**a or g**b) > On 16 Feb 2017, at 20:35, Paul Wouters wrote: >=20 > On Thu, 16 Feb 2017, internet-drafts@ietf.org wrote: >=20 >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt >=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-rfc4307bis-16 >=20 > This version incorporates the suggestions of ekr/yoav to remove the > claim that AES-GCM has better key longevity and rewrites the DH attack > line as suggested by them. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_AD470999-4F2B-45DE-B68E-5159611D0BC2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYpgd3AAoJELhJCxUKWMyZVPUH/0PFOMUfz/6HXtTFeyCQmg74 vsQNa3VvP8DUsT/NPBInIdFf4HmypGbCxRxMF+4+qjb0tfepluq63vPkg2ZthRLR Wl+XoN69ZiRV6N9JfDf6uiNS8cPn9RHHzoS5Bv2KJy2AOaU2OybgbCcUZStd6VMm wOJzsBCEaZPRj8ARDiQBef3FXE30L6iov4pGK8+8ckHfAp1be7R8TfEd4F4T44pz WTksF3lp67uUIz5qKA/yx8NAqBy/i3DJ11mb6pIWmI/KrC+s51pQBpB8ngrgMJOP voTV5iHAsB0aPZkR8xvQE7zMb+32Y0EX3SrI/zOk1dvj4/kw0jr4bpt3N8B+UI8= =YuAQ -----END PGP SIGNATURE----- --Apple-Mail=_AD470999-4F2B-45DE-B68E-5159611D0BC2-- From nobody Thu Feb 16 18:01:17 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54897129461; Thu, 16 Feb 2017 18:01:16 -0800 (PST) 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.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148729687633.21886.13208794224238871615.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 18:01:16 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 02:01:16 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-17.txt Pages : 18 Date : 2017-02-16 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). 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-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-17 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 Thu Feb 16 18:10:02 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D89129559 for ; Thu, 16 Feb 2017 18:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JYQWy4MLBDD for ; Thu, 16 Feb 2017 18:09:58 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EEE12946E for ; Thu, 16 Feb 2017 18:09:58 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vPc0z5LY1zD4K for ; Fri, 17 Feb 2017 03:09:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487297395; bh=VDbawKiDe1SRjB7IT65k+OTS0ZCGkMcZUUr9oiYD/Os=; h=Date:From:To:Subject:In-Reply-To:References; b=jxDKTWd8b55mr+pwJaY1Baa9cacdT2YJuCnQT2fGdLoV1OVCByIz2McGn5RPPDhuP DRQzTemnzmyuPEmOE1OE60fI31E9fQD1X/tgQnmzzkEURhMRk6KJGiH70l705DfASE 8zph9aVSZjp8RaVN9KNHjAP5R+zs6FyJnsScoSzA= 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 9WLweqWRc1_b for ; Fri, 17 Feb 2017 03:09:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 17 Feb 2017 03:09:53 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 223A52DEFF3; Thu, 16 Feb 2017 21:09:52 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 223A52DEFF3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0BE1641DA420 for ; Thu, 16 Feb 2017 21:09:51 -0500 (EST) Date: Thu, 16 Feb 2017 21:09:51 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <148729687633.21886.13208794224238871615.idtracker@ietfa.amsl.com> Message-ID: References: <148729687633.21886.13208794224238871615.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 02:10:01 -0000 On Thu, 16 Feb 2017, internet-drafts@ietf.org wrote: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-17 This version only has textual changes for clarity: - Moved Section as per Pete Resnick's suggestion - Incorporated grammar and typo fixes suggested by Pete Resnick - Complete the g**a and g**b swap that Yoav noticed. - A few of my own grammar fixes (eg remove the use of "we") I did wonder if the introduction of these 4307bis and 7321bis should perhaps reference each other in the Introduction section instead of just saying "does not apply to [the other doc stuff] Paul From nobody Fri Feb 17 07:36:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38D12962A for ; Fri, 17 Feb 2017 07:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrlLtzp5VNxv for ; Fri, 17 Feb 2017 07:36:36 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 55C0A1296E1 for ; Fri, 17 Feb 2017 07:36:36 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id k15so43202164qtg.3 for ; Fri, 17 Feb 2017 07:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SG4xAjg3Q21GMeOrImVpbVqX1qmDiDm4PpQUhJInWpQ=; b=YEvr1rLoL6s2l/rx05E0U7KE+GiSrUw5P0PHM1KkDA2+HQQLq58dIP/WIKl56WleXb 6p1pWpf3XNKcu0DW5LFCFAHgmBA/gexKEb5aYgKJ2d1u4Ze5hA6LNK3oRM57xpgIhRNY PFpQSOzL6A0LCZzSNpkQDeD5cMzLfixXjfZx3t8bqQv6MWOBrnAqS5CDCZANZoWM3Imc 79Im4KeK1SGLOGOMLp9bOIn/ACKjEu8kWmUeQe043GnH70yA7j0BxEIdGFvOjGjSIWkS MCNP+AAjBhDc5O12O8kFk43M2UO7zZ6eDk0ThUcYlL+vU1VkMmzh2D137zAW6yHlTdA5 F0WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SG4xAjg3Q21GMeOrImVpbVqX1qmDiDm4PpQUhJInWpQ=; b=sYh8DrI1qknG8rfJG/q4f8BdJSJt477D59bXVO6rHBUYwGKv2n6cm6tIoHdafxbhfw blGT2Fa4pGvrJlQ6iT1shctKrI6tgbSJO07JfwC40qvnjR5EflU4yU/M7bCjdRWIKSjS 1kWGSPmIYTIeyjcVomAmJOnnYX3+pIjOUuVZFmkySbfLjc8PmsOj0bikWKbuagH9eQy9 vMQDa0HslknvVQ4NUhPDrA1L2Q/zuePWy8tYCgrRopcVVpe9cShffoEvh2ABGEKfoojN rXg409pzX58AaYzxl4Rh0NDzpkJiM7c/HDlF8mfKB+eId2smqtYehyPdKZjnM+anBtrO x8UQ== X-Gm-Message-State: AMke39nRG2vYJZ7KwZMYPQag6Q2mZ/lGrRIlh4EI1/O6qLylIfYeyOB2kkME8tklCjyZM/YiTC2Uma/wyhP2Aw== X-Received: by 10.200.2.66 with SMTP id o2mr8577710qtg.244.1487345795048; Fri, 17 Feb 2017 07:36:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Fri, 17 Feb 2017 07:36:34 -0800 (PST) From: Kathleen Moriarty Date: Fri, 17 Feb 2017 10:36:34 -0500 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 15:36:38 -0000 Hello, Thanks for your work on draft-ietf-ipsecme-rfc7321bis. I just have one big question and a nit to point out. Questions: I see this: 5. ESP and AH Authentication Algorithms Encryption without authentication MUST NOT be used. This is a big change from RFC7321 without much explanation. What about the case of opportunistic security? Can you explain the change and justification? Nits: Section 4, third paragraph: s/theses/these/ Usually, the use of theses algorithms is limited to specific cases, and the absence of specification makes interoperability difficult for IPsec communications. -- Best regards, Kathleen From nobody Fri Feb 17 09:18:04 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C5A1294FB for ; Fri, 17 Feb 2017 09:18:02 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zKelfAAqaGO for ; Fri, 17 Feb 2017 09:18:01 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A9E129488 for ; Fri, 17 Feb 2017 09:18:01 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vQ08k6sSqz7q; Fri, 17 Feb 2017 18:17:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487351879; bh=1OB/SYL0W1BuFVRTjYjJhjRKn7MNGkCI8X7cNMU+ypM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DL9gr2hxeQpe7s910bIx+TxPCiC3FTSD2y1LILs6yveXXsFFSbqZMpCRwuA3sh1SI wGyBkMFd5aLetavodmWmVwEG84J3S4MraY8EhnuDW5Hnw+h9iE7zCwyQBv04RbsDom 0/ghicXIwnr9D3t9uKNb0swviYjKcokcs5hu8BzM= 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 ErqihB4joTpE; Fri, 17 Feb 2017 18:17:35 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 17 Feb 2017 18:17:35 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 72B8B2DEFF2; Fri, 17 Feb 2017 12:17:34 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 72B8B2DEFF2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 59DC941D9278; Fri, 17 Feb 2017 12:17:34 -0500 (EST) Date: Fri, 17 Feb 2017 12:17:34 -0500 (EST) From: Paul Wouters To: Kathleen Moriarty In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:18:03 -0000 On Fri, 17 Feb 2017, Kathleen Moriarty wrote: > Thanks for your work on draft-ietf-ipsecme-rfc7321bis. I just have > one big question and a nit to point out. > > Questions: I see this: > 5. ESP and AH Authentication Algorithms > > Encryption without authentication MUST NOT be used. > > This is a big change from RFC7321 without much explanation. What about > the case of opportunistic security? Can you explain the change and > justification? It is actually not much a change. If you look at 7321 Section 3, it states: Confidentiality without authentication is not effective [DP07] and therefore SHOULD NOT be used. Encryption without authentication is vulnerable to manipulation that can cause an oracle attack to compromise the encryption key as well. The 7321 document was a bit unclear with respect to encryption algos versus AEAD algos which might look like it allows a wider acceptance of encryption without authentication, but really does not intend to. > Nits: > Section 4, third paragraph: s/theses/these/ > > Usually, the use of theses algorithms is limited to > specific cases, and the absence of specification makes > interoperability difficult for IPsec communications. I'll keep this in mind to correct at the RFC Editor round, unless we do another draft round if we need to change anything else. Thanks, Paul From nobody Fri Feb 17 12:02:45 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168F412951B for ; Fri, 17 Feb 2017 12:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll0vnbl-5Q05 for ; Fri, 17 Feb 2017 12:02:43 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 9F7AC1294C6 for ; Fri, 17 Feb 2017 12:02:43 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id w20so49194564qtb.1 for ; Fri, 17 Feb 2017 12:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LfDHf5IihafyrG4BGKTLLIszS+OlJvblZYziG92UYBA=; b=TwZl+/9ElyaH8lHs6zIMFAFqMXJXKQkZt3SI2FmTlFL/BYyZS9WtCphCKAKplQlpxX ClVMWE06dLNBmNzDqUALGqyN+1mtOp3iiG0uvfi265VMkXqRrsup4xtNGrCtJyQE0/Ca c3KOAUM3hQGY9UjeF3Fh7uGGCEXtbMU2IRVkChQFCCZRuyHFZ3M46DX5o4AnuGPrQvzB y2TfeQ8jlGSDrRciIa2lJmI6136zFERy4DS8CzpgVLjhoVF9ccYDHlxOXeM7oBL3vSBb oM9N+kF4yH7Ha7tDCiQbQeChAFczPL4xKMgQTFn/QCsNjjAjMICspKURo8Yq7e41nmx3 2/Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LfDHf5IihafyrG4BGKTLLIszS+OlJvblZYziG92UYBA=; b=bNGEeWeTQoUTJzyO70GSZrZTieS+wSKIqtuMKzbxcJDa1QPX3AkMYXaRCmm68fWNCl Jr6ISzLwONj2xHjeMJmnQu8GWPw1XdN7980+zRTYt47IQ7BS+6/6Fv3eeHCW9ERA7syG ill55+gHRhSX4f7DDYcaGrgTRrffv30BzVdIbWq/m9yfFqQy3TnIFRXNepeZOuQpH08H eJpwmVo89UKt59KKcTBFgrhS5+3QlAL25BTM7GoVT7EaFYhxeutPMosBc880FW6nyjR8 auu6u+EWQhMnHtlpqtjZtBy3z6Se0DDwVZcsh5O5QJox9Lw9JUMPG4PuO77jwhwntooA a1bw== X-Gm-Message-State: AMke39lHH96Hthul7WosWJ5Qv8FcLwSIQgSivhJ627oMzi5UYoIIdk3y5VeBEhFIRDgpDJt9NPx07d+Pn0taLg== X-Received: by 10.200.40.109 with SMTP id 42mr1582422qtr.257.1487361762671; Fri, 17 Feb 2017 12:02:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Fri, 17 Feb 2017 12:02:42 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Fri, 17 Feb 2017 15:02:42 -0500 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 20:02:45 -0000 Hi Paul, On Fri, Feb 17, 2017 at 12:17 PM, Paul Wouters wrote: > On Fri, 17 Feb 2017, Kathleen Moriarty wrote: > >> Thanks for your work on draft-ietf-ipsecme-rfc7321bis. I just have >> one big question and a nit to point out. >> >> Questions: I see this: >> 5. ESP and AH Authentication Algorithms >> >> Encryption without authentication MUST NOT be used. >> >> This is a big change from RFC7321 without much explanation. What about >> the case of opportunistic security? Can you explain the change and >> justification? > > > It is actually not much a change. If you look at 7321 Section 3, it states: > > Confidentiality without authentication is not effective [DP07] > and therefore SHOULD NOT be used. Yes, I saw that and agree security-wise that this is a bad practice. But 7321 say a lot more on both ESP and AH authentication than that one sentence. What I am saying is that the change in this document requires more text to explain it. You also have the following text in that section: To provide both confidentiality and authentication, an authenticated encryption transform from Section 2.1 SHOULD be used in ESP, in conjunction with NULL authentication. It's fine again with the following text: Alternatively, an ESP encryption transform and ESP authentication transform MAY be used together. It is NOT RECOMMENDED to use ESP with NULL authentication in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10]. Then at the end of the next paragraph: Therefore, an encryption transform MUST NOT be used with a NULL authentication transform (unless the encryption transform is an authenticated encryption transform from Section 2.1). > > Encryption without authentication is vulnerable to manipulation that can > cause an oracle attack to compromise the encryption key as well. yes. > > The 7321 document was a bit unclear with respect to encryption algos > versus AEAD algos which might look like it allows a wider acceptance > of encryption without authentication, but really does not intend to. What I am saying is that it would be helpful to provide text to explain the change. > > >> Nits: >> Section 4, third paragraph: s/theses/these/ >> >> Usually, the use of theses algorithms is limited to >> specific cases, and the absence of specification makes >> interoperability difficult for IPsec communications. > > > I'll keep this in mind to correct at the RFC Editor round, unless we do > another draft round if we need to change anything else. Thanks. I'd want it updated before IESG review, especially adding text for the above changes. > > Thanks, > > Paul -- Best regards, Kathleen From nobody Tue Feb 21 08:35:46 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3D5129517; Tue, 21 Feb 2017 08:35:45 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nHRwFrbeaAA; Tue, 21 Feb 2017 08:35:42 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E45712952C; Tue, 21 Feb 2017 08:35:39 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vSR1y1Xvzz37r; Tue, 21 Feb 2017 17:35:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487694934; bh=KwiAus06/FG4BYMjPgN27bbab3cqYcvqtA9j7ko2lyU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bSXKU6pEQMpFOU8ncoacFdLVDhIJzQraVqeuWXSAbBgMLvdSvy4DJmBnAT9oaU8n3 tSyndbymtN9HeKlX4JlEQ/8vB8gd8zhQvci5GLaKcn6CoaYB0rMzdUKS9FyyINRBYT MYNpnAPQ4JEmADGYo5gDF8oUISpta81uZyvkiatI= 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 KSu4McKPCPTm; Tue, 21 Feb 2017 17:35:32 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 21 Feb 2017 17:35:31 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1179574454; Tue, 21 Feb 2017 11:35:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1179574454 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E4FB2407E824; Tue, 21 Feb 2017 11:35:30 -0500 (EST) Date: Tue, 21 Feb 2017 11:35:30 -0500 (EST) From: Paul Wouters To: Kathleen Moriarty In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , draft-ietf-ipsecme-rfc7321bis@ietf.org Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 16:35:45 -0000 On Fri, 17 Feb 2017, Kathleen Moriarty wrote: >> It is actually not much a change. If you look at 7321 Section 3, it states: >> >> Confidentiality without authentication is not effective [DP07] >> and therefore SHOULD NOT be used. > > Yes, I saw that and agree security-wise that this is a bad practice. > But 7321 say a lot more on both ESP and AH authentication than that > one sentence. What I am saying is that the change in this document > requires more text to explain it. > > You also have the following text in that section: > > To provide both confidentiality and authentication, an authenticated > encryption transform from Section 2.1 SHOULD be used in ESP, in > conjunction with NULL authentication. The way I read that section is that it tries to explain AEAD ciphers versus separate ENCR+INTEG ciphers. It is not making claims about using encryption without authentication, just that when using an AEAD, you do not use a separate authentication algorithm and when not using an AEAD you do use a separate authentication. > It's fine again with the following text: > > Alternatively, an ESP > encryption transform and ESP authentication transform MAY be used > together. It is NOT RECOMMENDED to use ESP with NULL authentication > in conjunction with AH; some configurations of this combination of > services have been shown to be insecure [PD10]. Again, the way I read it is that it (not too clearly) is trying to explain AEAD vs non-AEAD. > Then at the end of the next paragraph: > > Therefore, an encryption > transform MUST NOT be used with a NULL authentication transform > (unless the encryption transform is an authenticated encryption > transform from Section 2.1). And again. They probably should have cut all the text and just left this one paragraph in :P Note that this MUST NOT conflicts with the SHOULD NOT quoted above that we promoted to MUST NOT that we are talking about here. >> The 7321 document was a bit unclear with respect to encryption algos >> versus AEAD algos which might look like it allows a wider acceptance >> of encryption without authentication, but really does not intend to. > > What I am saying is that it would be helpful to provide text to > explain the change. I'm unsure what to write? 7321 should have used MUST NOT instead of SHOULD NOT for the exact same unchanged reasons provided in 7321. And as I pointed out above, it kind of does outside that one silly paragraph. If really needed, I can do something like: Encryption without authentication MUST NOT be used. [RFC7321] erroneously stated in Section 3 that this insecure practise is a SHOULD NOT, where elsewhere in [RFC7321] it properly stated this as MUST NOT. Perhaps one of my co-authors can come up with a better suggestion? Paul From nobody Tue Feb 21 21:10:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254DB1295E9 for ; Tue, 21 Feb 2017 21:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHdDAds59u6k for ; Tue, 21 Feb 2017 21:10:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D921295E4 for ; Tue, 21 Feb 2017 21:10:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBM54648; Wed, 22 Feb 2017 05:10:34 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 22 Feb 2017 05:10:32 +0000 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by NKGEML413-HUB.china.huawei.com (10.98.56.74) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Feb 2017 13:10:30 +0800 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.95]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 22 Feb 2017 13:10:21 +0800 From: Sandeep Kampati To: "ipsec@ietf.org" Thread-Topic: [IPsec] Regarding max limit of payloads to avoid unwanted processing. Thread-Index: AQHSjMn3cqwouRlWyECVJ83F0SMVQA== Date: Wed, 22 Feb 2017 05:10:20 +0000 Message-ID: <2DA788A5A7D91747AEA54B502558D738269FA622@DGGEMM506-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58AD1D4A.0170, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.95, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 10468aeab4737b451d6261d0c17f8a25 Archived-At: Cc: "kivinen@iki.fi" , "ynir.ietf@gmail.com" Subject: [IPsec] Regarding max limit of payloads to avoid unwanted processing. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 05:10:38 -0000 RFC 7296 3.5. Identification Payloads ID_IPV4_ADDR 1 A single four (4) octet IPv4 address. Questions: do we need to consider "single four (4) octet IPv4 address" as= MUST point and reject the packet if we receive more length for it. For security reason we want to add restriction the payloads what we receive= d, and reject packet if we receive more length=20 Ex: Identification Payloads ID Type : 1) ID_IPV4_ADDR ->A single four (4) = octet 2) ID_IPV6_ADDR-> A single sixteen (16) octet It will be good if have some MAX limit for number of Proposal, CERT, So on = ..., So that we can avoid unwanted processing=20 Best regards, Sandeep kampati From nobody Wed Feb 22 06:30:42 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546F8129979 for ; Wed, 22 Feb 2017 06:30:40 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKTrbUguNFrX for ; Wed, 22 Feb 2017 06:30:38 -0800 (PST) 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 6276912999C for ; Wed, 22 Feb 2017 06:30:38 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1MEUOgP008905 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Feb 2017 16:30:24 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1MEUNTY014246; Wed, 22 Feb 2017 16:30:23 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22701.41087.295109.746640@fireball.acr.fi> Date: Wed, 22 Feb 2017 16:30:23 +0200 From: Tero Kivinen To: Sandeep Kampati In-Reply-To: <2DA788A5A7D91747AEA54B502558D738269FA622@DGGEMM506-MBS.china.huawei.com> References: <2DA788A5A7D91747AEA54B502558D738269FA622@DGGEMM506-MBS.china.huawei.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 8 min Archived-At: Cc: "ipsec@ietf.org" , "ynir.ietf@gmail.com" Subject: [IPsec] Regarding max limit of payloads to avoid unwanted processing. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:30:40 -0000 Sandeep Kampati writes: > 3.5. Identification Payloads > > ID_IPV4_ADDR 1 > A single four (4) octet IPv4 address. > > Questions: do we need to consider "single four (4) octet IPv4 > address" as MUST point and reject the packet if we receive more > length for it. > > For security reason we want to add restriction the payloads what we > received, and reject packet if we receive more length > > Ex: Identification Payloads ID Type : 1) ID_IPV4_ADDR ->A single > four (4) octet 2) ID_IPV6_ADDR-> A single sixteen (16) octet The Identification Payload ID is used to search the matching policy from the PAD, and as your PAD most likely will not add any other lengths for the IP-addresses than 4 and 16 octets, then you can immediately know that the matching policy will not be found from the policy so you can reject it immediately. The proper error code would most likely be INVALID_SYNTAX (as the ID payload does not match the specified syntax, and if someone sends 5 octets for IPv4 address there is clearly a bug in their implementation, and changing policy will not help)... -- kivinen@iki.fi From nobody Wed Feb 22 06:54:17 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87711299ED; Wed, 22 Feb 2017 06:54:00 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w6n3a4F0hAY; Wed, 22 Feb 2017 06:53:59 -0800 (PST) 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 13E651299E6; Wed, 22 Feb 2017 06:53:58 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1MEruY2004564 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Feb 2017 16:53:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1MEruec007932; Wed, 22 Feb 2017 16:53:56 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22701.42500.198298.440746@fireball.acr.fi> Date: Wed, 22 Feb 2017 16:53:56 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 22 min X-Total-Time: 23 min Archived-At: Cc: "ipsec@ietf.org" , draft-ietf-ipsecme-rfc7321bis@ietf.org, Kathleen Moriarty Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:54:01 -0000 Paul Wouters writes: > On Fri, 17 Feb 2017, Kathleen Moriarty wrote: > > >> It is actually not much a change. If you look at 7321 Section 3, it states: > >> > >> Confidentiality without authentication is not effective [DP07] > >> and therefore SHOULD NOT be used. > > > > Yes, I saw that and agree security-wise that this is a bad practice. > > But 7321 say a lot more on both ESP and AH authentication than that > > one sentence. What I am saying is that the change in this document > > requires more text to explain it. > > > > You also have the following text in that section: > > > > To provide both confidentiality and authentication, an authenticated > > encryption transform from Section 2.1 SHOULD be used in ESP, in > > conjunction with NULL authentication. > > The way I read that section is that it tries to explain AEAD ciphers > versus separate ENCR+INTEG ciphers. It is not making claims about > using encryption without authentication, just that when using an AEAD, > you do not use a separate authentication algorithm and when not using > an AEAD you do use a separate authentication. There is 3 ways of provide both confidentiality and authentication in IPsec: 1) ESP with AEAD cipher 2) ESP with non-AEAD cipher + authentication 3) ESP with non-AEAD cipher + no authentication combined with AH with authentication I.e., 1) Use combined mode cipher, i.e. AEAD cipher. In that case the AEAD ciphers is set for the encryption algorithm, and the authentication algorithm is not sent. Example of this is ENCR_AES_GCM_16 or ENCR_CHACHA20_POLY1305. 2) Use ESP with both encryption and authentication algorithm. In this case we are still using only ESP, but we have separate algorithms, for example ENCR_AES_CBC combined with AUTH_HMAC_SHA2_256_128. 3) Use ESP for confidentiality and AH for authentication. In that case the ESP is used with encryption algorithm like ENCR_AES_CBC, and without authentication algorithm, and then there is second IPsec protocol AH that will provide authentication with algorithm like AUTH_HMAC_SHA2_256_128. The first one is preferred, i.e., RFC7321 said SHOULD for AEAD algorithms, and did say MAY for 2nd option (ESP with both encryption and authentication algorithms), and said NOT RECOMMENDED for the last option. > > It's fine again with the following text: > > > > Alternatively, an ESP > > encryption transform and ESP authentication transform MAY be used > > together. It is NOT RECOMMENDED to use ESP with NULL authentication > > in conjunction with AH; some configurations of this combination of > > services have been shown to be insecure [PD10]. > > Again, the way I read it is that it (not too clearly) is trying to > explain AEAD vs non-AEAD. Again all of the above was explaining those 3 different ways of doing confidentiality + authentication. > > Then at the end of the next paragraph: > > > > Therefore, an encryption > > transform MUST NOT be used with a NULL authentication transform > > (unless the encryption transform is an authenticated encryption > > transform from Section 2.1). > > And again. They probably should have cut all the text and just left > this one paragraph in :P > > Note that this MUST NOT conflicts with the SHOULD NOT quoted above > that we promoted to MUST NOT that we are talking about here. Yes, the 7321 did say MUST NOT for confidentility only, after saying SHOULD NOT for it earlier... In the section 3 of the 7321 the second last paragraph then moves to explain other cases, i.e. where we only want to provide authentication without confidentiality, where it prefers the ESP with NULL encryption over AH, and then it says that encryption without authentication is MUST NOT, although it should point out that in addition to the AEAD case the ESP + AH is another exception to that rule... > >> The 7321 document was a bit unclear with respect to encryption algos > >> versus AEAD algos which might look like it allows a wider acceptance > >> of encryption without authentication, but really does not intend to. > > > > What I am saying is that it would be helpful to provide text to > > explain the change. > > I'm unsure what to write? 7321 should have used MUST NOT instead of > SHOULD NOT for the exact same unchanged reasons provided in 7321. > And as I pointed out above, it kind of does outside that one silly > paragraph. > > If really needed, I can do something like: > > Encryption without authentication MUST NOT be used. [RFC7321] > erroneously stated in Section 3 that this insecure practise > is a SHOULD NOT, where elsewhere in [RFC7321] it properly > stated this as MUST NOT. > > Perhaps one of my co-authors can come up with a better suggestion? Perhaps we should add bit similar text like I did earlier, i.e., explain that there is 3 ways of doing confidentiality + authentication and add some more text about them. -- kivinen@iki.fi From nobody Wed Feb 22 10:24:10 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B1312967C; Wed, 22 Feb 2017 10:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtK0rEKNWCMX; Wed, 22 Feb 2017 10:24:06 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 EBA801296B4; Wed, 22 Feb 2017 10:24:05 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id x71so10725868qkb.3; Wed, 22 Feb 2017 10:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JOZPz2+Y5CY8zSAZeT5b0CaTRr4MJLt0i0PeQM5jXm0=; b=Qppyl72vBy5XHg7I5SL/CZvy520Jqu/zYEhb3efP27+5aWC1m1dWUsQ5Bp/nuXleRo Q9TmHVa6QINp3c/9qj7kcPodhbTWOwfEjTipHp+WwXzx0ukKVUu83yGs1jp+eXrBOx7n 9r+n/lcUgWAcrgLFFJnNKmlleT9jOb6yKOVF8NFQ1+9slhyP5Q1/ig8QS53sxkrSoqjG DsWaP1GKazY2XFMkQDVXuOeJVRbVMRsHjvnhKDxr3rIzNDlJKxhS3ADz988/1NYtzovR wX8TaNSwMVkJOJ4pY4gOXalGmgIEdT/GhNRfgruHSvxr7x80K4nYtPGYJ3bGxHDQhBC1 1G9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JOZPz2+Y5CY8zSAZeT5b0CaTRr4MJLt0i0PeQM5jXm0=; b=MAhfS0n75z3lZqD1uyhtJfBhQuOedOsWxwobewH2TxmZvgNEH+dwktxHiaAes92yvp GXxN5+UVZZpiA1ckQNi/xvM+UDq8CHXAUssEQt9tbfjsDSr1KG4XJyxzrFfsMzMYcmnd 5tJmwX48QXsouIc5c1HrjLg7kB3OVDbXZulWeDTIjSXapFWQCAqLjiKvbMdRvB6Mm5ED o64SlW5aCcQWBWK3Js/kTSkgckIB+gPXmTPAxQsbDGGZBoBpu0KaiK9S7pXACqMEz3eU IosTwNPgPNV/T1vsoZUXwr4lBjm4TauO6TETwuw732yknx6BVrjziiOdv66Vd5ruPs/f V6pQ== X-Gm-Message-State: AMke39n6ALQhnkUNZ6jfnkAODK2rxY/Jyi1ywt3dt4noamEzHePTSEDA6XOx0S58o6mACAM6qxKEvdAnq0EI6g== X-Received: by 10.55.89.196 with SMTP id n187mr31303632qkb.17.1487787845009; Wed, 22 Feb 2017 10:24:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.77 with HTTP; Wed, 22 Feb 2017 10:24:04 -0800 (PST) In-Reply-To: <22701.42500.198298.440746@fireball.acr.fi> References: <22701.42500.198298.440746@fireball.acr.fi> From: Kathleen Moriarty Date: Wed, 22 Feb 2017 13:24:04 -0500 Message-ID: To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" , draft-ietf-ipsecme-rfc7321bis@ietf.org, Paul Wouters Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:24:08 -0000 On Wed, Feb 22, 2017 at 9:53 AM, Tero Kivinen wrote: > Paul Wouters writes: >> On Fri, 17 Feb 2017, Kathleen Moriarty wrote: >> >> >> It is actually not much a change. If you look at 7321 Section 3, it states: >> >> >> >> Confidentiality without authentication is not effective [DP07] >> >> and therefore SHOULD NOT be used. >> > >> > Yes, I saw that and agree security-wise that this is a bad practice. >> > But 7321 say a lot more on both ESP and AH authentication than that >> > one sentence. What I am saying is that the change in this document >> > requires more text to explain it. >> > >> > You also have the following text in that section: >> > >> > To provide both confidentiality and authentication, an authenticated >> > encryption transform from Section 2.1 SHOULD be used in ESP, in >> > conjunction with NULL authentication. >> >> The way I read that section is that it tries to explain AEAD ciphers >> versus separate ENCR+INTEG ciphers. It is not making claims about >> using encryption without authentication, just that when using an AEAD, >> you do not use a separate authentication algorithm and when not using >> an AEAD you do use a separate authentication. > > There is 3 ways of provide both confidentiality and authentication in > IPsec: > > 1) ESP with AEAD cipher > 2) ESP with non-AEAD cipher + authentication > 3) ESP with non-AEAD cipher + no authentication combined with AH with > authentication > > I.e., > > 1) Use combined mode cipher, i.e. AEAD cipher. In that case the AEAD > ciphers is set for the encryption algorithm, and the authentication > algorithm is not sent. Example of this is ENCR_AES_GCM_16 or > ENCR_CHACHA20_POLY1305. > > 2) Use ESP with both encryption and authentication algorithm. In this > case we are still using only ESP, but we have separate algorithms, for > example ENCR_AES_CBC combined with AUTH_HMAC_SHA2_256_128. > > 3) Use ESP for confidentiality and AH for authentication. In that case > the ESP is used with encryption algorithm like ENCR_AES_CBC, and > without authentication algorithm, and then there is second IPsec > protocol AH that will provide authentication with algorithm like > AUTH_HMAC_SHA2_256_128. > > The first one is preferred, i.e., RFC7321 said SHOULD for AEAD > algorithms, and did say MAY for 2nd option (ESP with both encryption > and authentication algorithms), and said NOT RECOMMENDED for the last > option. > >> > It's fine again with the following text: >> > >> > Alternatively, an ESP >> > encryption transform and ESP authentication transform MAY be used >> > together. It is NOT RECOMMENDED to use ESP with NULL authentication >> > in conjunction with AH; some configurations of this combination of >> > services have been shown to be insecure [PD10]. >> >> Again, the way I read it is that it (not too clearly) is trying to >> explain AEAD vs non-AEAD. > > Again all of the above was explaining those 3 different ways of doing > confidentiality + authentication. > >> > Then at the end of the next paragraph: >> > >> > Therefore, an encryption >> > transform MUST NOT be used with a NULL authentication transform >> > (unless the encryption transform is an authenticated encryption >> > transform from Section 2.1). >> >> And again. They probably should have cut all the text and just left >> this one paragraph in :P >> >> Note that this MUST NOT conflicts with the SHOULD NOT quoted above >> that we promoted to MUST NOT that we are talking about here. > > Yes, the 7321 did say MUST NOT for confidentility only, after saying > SHOULD NOT for it earlier... > > In the section 3 of the 7321 the second last paragraph then moves to > explain other cases, i.e. where we only want to provide authentication > without confidentiality, where it prefers the ESP with NULL encryption > over AH, and then it says that encryption without authentication is > MUST NOT, although it should point out that in addition to the AEAD > case the ESP + AH is another exception to that rule... > >> >> The 7321 document was a bit unclear with respect to encryption algos >> >> versus AEAD algos which might look like it allows a wider acceptance >> >> of encryption without authentication, but really does not intend to. >> > >> > What I am saying is that it would be helpful to provide text to >> > explain the change. >> >> I'm unsure what to write? 7321 should have used MUST NOT instead of >> SHOULD NOT for the exact same unchanged reasons provided in 7321. >> And as I pointed out above, it kind of does outside that one silly >> paragraph. >> >> If really needed, I can do something like: >> >> Encryption without authentication MUST NOT be used. [RFC7321] >> erroneously stated in Section 3 that this insecure practise >> is a SHOULD NOT, where elsewhere in [RFC7321] it properly >> stated this as MUST NOT. >> >> Perhaps one of my co-authors can come up with a better suggestion? > > Perhaps we should add bit similar text like I did earlier, i.e., > explain that there is 3 ways of doing confidentiality + authentication > and add some more text about them. I think that may help head off questions in last call and IESG review if anyone else looks back at 7321. Thank you. > -- > kivinen@iki.fi -- Best regards, Kathleen From nobody Mon Feb 27 08:00:16 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E17C512A189; Mon, 27 Feb 2017 08:00:14 -0800 (PST) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148821121491.21138.10115068054308299629.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 08:00:14 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 16:00:15 -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 of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-08.txt Pages : 22 Date : 2017-02-27 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-08 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 Mon Feb 27 11:13:51 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1D212956F; Mon, 27 Feb 2017 11:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNe2X3UFCw9S; Mon, 27 Feb 2017 11:13:48 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 AF439126BF7; Mon, 27 Feb 2017 11:13:48 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n127so112978672qkf.0; Mon, 27 Feb 2017 11:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=za/zZxpq5WY+SOvMQoHEEZdXE54mKS4bCTyuh87VDc4=; b=mE/AGNPgtIvdNjhA0WgVC0H5WsJ6MI7WAwjJ2aGbOH7yEZma4RN0HELpfwH6RkLarB wiyOJ4Oa0kWP10TtJFlPQNrCPXD93OFj/ZUhiEm5vnj95kz/gIlT95WbMEx9AJ/WtULP 4rc2SLBquWrN/w5+mK2YLg9y7qqk3IOPPyvfVTepWg9GRxlRUDXwW6XhToQC7kZpAg0K pYAFs9oagqbIuYAH1VHPMI5uYDIQi6KklbYjvkYOweaND/kL5UYhRdEMzGtyz/CiuCcu wq1SUJjJ7BW19RhjU9ocf3zPz+I92TF6d/4W+fK8kXhhacJnqC5VluZ6xDXM9LpYGBs7 D8Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=za/zZxpq5WY+SOvMQoHEEZdXE54mKS4bCTyuh87VDc4=; b=o6PutuGeLm/GFoQ+bT5SVSLc8oYc2z94MBHVakzcIsffeqIdFz7rSutVIEV5rqv8Z4 rbDbZbIAgLigd1wPrua+EavtI4U/YutzXt5SggJ/+TPlOCAgRo95XiRAtAO0NSZ/Nbeq blLz6L2Pwzwo/LNBPFKYi6ZAVp8sdaMIBNhY5CSXg4zjNARoZxbbGyvrun/ix4ZZzYVJ UbAiFlvlZXK5IZOl5t+LHOwHXFjhPdzZ9SpbgUmU+g4DGzoog2cnZ6olSMUE9qpxeBzD bFx/mFzXiCRKgWh2xP/3d6V7fZBOZLlpJjSJcSkWtcpdHpHSBy1P+/T2ZN3JI99yZZ4o DbqQ== X-Gm-Message-State: AMke39k9X5AMB0sUP4lh5Q8ozrhavQsiXsSoRYJx7MDyDSucbyhST/scMAyPZ2tcFb2GAunlb8NUptljoDyXAA== X-Received: by 10.200.42.213 with SMTP id c21mr14463366qta.257.1488222827618; Mon, 27 Feb 2017 11:13:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.140.78 with HTTP; Mon, 27 Feb 2017 11:13:47 -0800 (PST) In-Reply-To: References: <22701.42500.198298.440746@fireball.acr.fi> From: Kathleen Moriarty Date: Mon, 27 Feb 2017 14:13:47 -0500 Message-ID: To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" , draft-ietf-ipsecme-rfc7321bis@ietf.org, Paul Wouters Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:13:50 -0000 On Wed, Feb 22, 2017 at 1:24 PM, Kathleen Moriarty wrote: > On Wed, Feb 22, 2017 at 9:53 AM, Tero Kivinen wrote: >> Paul Wouters writes: >>> On Fri, 17 Feb 2017, Kathleen Moriarty wrote: >>> >>> >> It is actually not much a change. If you look at 7321 Section 3, it states: >>> >> >>> >> Confidentiality without authentication is not effective [DP07] >>> >> and therefore SHOULD NOT be used. >>> > >>> > Yes, I saw that and agree security-wise that this is a bad practice. >>> > But 7321 say a lot more on both ESP and AH authentication than that >>> > one sentence. What I am saying is that the change in this document >>> > requires more text to explain it. >>> > >>> > You also have the following text in that section: >>> > >>> > To provide both confidentiality and authentication, an authenticated >>> > encryption transform from Section 2.1 SHOULD be used in ESP, in >>> > conjunction with NULL authentication. >>> >>> The way I read that section is that it tries to explain AEAD ciphers >>> versus separate ENCR+INTEG ciphers. It is not making claims about >>> using encryption without authentication, just that when using an AEAD, >>> you do not use a separate authentication algorithm and when not using >>> an AEAD you do use a separate authentication. >> >> There is 3 ways of provide both confidentiality and authentication in >> IPsec: >> >> 1) ESP with AEAD cipher >> 2) ESP with non-AEAD cipher + authentication >> 3) ESP with non-AEAD cipher + no authentication combined with AH with >> authentication >> >> I.e., >> >> 1) Use combined mode cipher, i.e. AEAD cipher. In that case the AEAD >> ciphers is set for the encryption algorithm, and the authentication >> algorithm is not sent. Example of this is ENCR_AES_GCM_16 or >> ENCR_CHACHA20_POLY1305. >> >> 2) Use ESP with both encryption and authentication algorithm. In this >> case we are still using only ESP, but we have separate algorithms, for >> example ENCR_AES_CBC combined with AUTH_HMAC_SHA2_256_128. >> >> 3) Use ESP for confidentiality and AH for authentication. In that case >> the ESP is used with encryption algorithm like ENCR_AES_CBC, and >> without authentication algorithm, and then there is second IPsec >> protocol AH that will provide authentication with algorithm like >> AUTH_HMAC_SHA2_256_128. >> >> The first one is preferred, i.e., RFC7321 said SHOULD for AEAD >> algorithms, and did say MAY for 2nd option (ESP with both encryption >> and authentication algorithms), and said NOT RECOMMENDED for the last >> option. >> >>> > It's fine again with the following text: >>> > >>> > Alternatively, an ESP >>> > encryption transform and ESP authentication transform MAY be used >>> > together. It is NOT RECOMMENDED to use ESP with NULL authentication >>> > in conjunction with AH; some configurations of this combination of >>> > services have been shown to be insecure [PD10]. >>> >>> Again, the way I read it is that it (not too clearly) is trying to >>> explain AEAD vs non-AEAD. >> >> Again all of the above was explaining those 3 different ways of doing >> confidentiality + authentication. >> >>> > Then at the end of the next paragraph: >>> > >>> > Therefore, an encryption >>> > transform MUST NOT be used with a NULL authentication transform >>> > (unless the encryption transform is an authenticated encryption >>> > transform from Section 2.1). >>> >>> And again. They probably should have cut all the text and just left >>> this one paragraph in :P >>> >>> Note that this MUST NOT conflicts with the SHOULD NOT quoted above >>> that we promoted to MUST NOT that we are talking about here. >> >> Yes, the 7321 did say MUST NOT for confidentility only, after saying >> SHOULD NOT for it earlier... >> >> In the section 3 of the 7321 the second last paragraph then moves to >> explain other cases, i.e. where we only want to provide authentication >> without confidentiality, where it prefers the ESP with NULL encryption >> over AH, and then it says that encryption without authentication is >> MUST NOT, although it should point out that in addition to the AEAD >> case the ESP + AH is another exception to that rule... >> >>> >> The 7321 document was a bit unclear with respect to encryption algos >>> >> versus AEAD algos which might look like it allows a wider acceptance >>> >> of encryption without authentication, but really does not intend to. >>> > >>> > What I am saying is that it would be helpful to provide text to >>> > explain the change. >>> >>> I'm unsure what to write? 7321 should have used MUST NOT instead of >>> SHOULD NOT for the exact same unchanged reasons provided in 7321. >>> And as I pointed out above, it kind of does outside that one silly >>> paragraph. >>> >>> If really needed, I can do something like: >>> >>> Encryption without authentication MUST NOT be used. [RFC7321] >>> erroneously stated in Section 3 that this insecure practise >>> is a SHOULD NOT, where elsewhere in [RFC7321] it properly >>> stated this as MUST NOT. >>> >>> Perhaps one of my co-authors can come up with a better suggestion? >> >> Perhaps we should add bit similar text like I did earlier, i.e., >> explain that there is 3 ways of doing confidentiality + authentication >> and add some more text about them. > > I think that may help head off questions in last call and IESG review > if anyone else looks back at 7321. Is there any chance this update could happen today so I can start last call? I'd like ot keep this on the 3/16 telechat with the other IPsecme draft if possible. > > Thank you. > >> -- >> kivinen@iki.fi > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Mon Feb 27 11:31:35 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF73129F03; Mon, 27 Feb 2017 11:31:33 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOBuyLEWpz3S; Mon, 27 Feb 2017 11:31:32 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581041270B4; Mon, 27 Feb 2017 11:31:32 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vXBf84mrHzCqQ; Mon, 27 Feb 2017 20:31:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488223888; bh=fl70q39sEf4SEtIdaCddw5sLjRkDQ5KuYV1DuNC+eXk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=a5Ud1eWhna8PKARlYUdaxbAEgt5hE5bpuc06JCYV15oXR+D/ti9WIzlKZa2TAkwZ/ IFJtQOAdqB7pyoG7CZkJPbZZvQL5bHj9iDMw4SVsSZ24+Mnh3XuZgI21bo9oydNiYd 1pUyE0Me6P3JBzjT1OXrAbIvkeKlcuSurcx5u82A= 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 NukbuWlrEI48; Mon, 27 Feb 2017 20:31:26 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 27 Feb 2017 20:31:26 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9F7963F2854; Mon, 27 Feb 2017 14:31:25 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9F7963F2854 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8864E4168D4D; Mon, 27 Feb 2017 14:31:25 -0500 (EST) Date: Mon, 27 Feb 2017 14:31:25 -0500 (EST) From: Paul Wouters To: Kathleen Moriarty In-Reply-To: Message-ID: References: <22701.42500.198298.440746@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , draft-ietf-ipsecme-rfc7321bis@ietf.org, Tero Kivinen Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:31:33 -0000 On Mon, 27 Feb 2017, Kathleen Moriarty wrote: >> I think that may help head off questions in last call and IESG review >> if anyone else looks back at 7321. > > Is there any chance this update could happen today so I can start last > call? I'd like ot keep this on the 3/16 telechat with the other > IPsecme draft if possible. Yes, I'll push out an update today that includes what Tero and I said to replace that one liner you pointed at. Paul From nobody Mon Feb 27 12:55:17 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757A912A328; Mon, 27 Feb 2017 12:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsQxvRy7lIWQ; Mon, 27 Feb 2017 12:55:14 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 4AC8512A31A; Mon, 27 Feb 2017 12:55:14 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id n127so117473003qkf.0; Mon, 27 Feb 2017 12:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oGFYizl//dYnfHkFd7E3XxNJKIEg+DVtI8kqdkbSQaU=; b=ijr6CpGoROHSYtBjRtrQwqjNWvNhZTPNA36uX86KFulUiQIc/v8TsErvr1mb//8WgD lSX5irgcpi8rsaTpURcRLVFJ8R6OlX6R2Xk75khk79bNKXR4qE0e7W1iPbQBbwhEC65H ArtPF2qIMqk9TrJyxv4+ZbQmuRFH/0zKUVSWBanynz7y4R0UhdO7qSklCghkpYxUCqJr DG11MSTUrE6uv17KrGrPvo6CCtc61ZOTcpHL2q+dU1C/L2jpFEfZv8gj+N3mRgkYNacY +HxLwHHu1Ot6Joo2MLzE7Uugn6/XWXDjaLz4KjQLjd1J4WvYWfHJtczsCYS91bd5Yd/n JByw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oGFYizl//dYnfHkFd7E3XxNJKIEg+DVtI8kqdkbSQaU=; b=JlaoAyqjGp/3JvWpThau1D+S1Tour1uJ0FFmY9bQB4BWRg+rEo+RDKt/wlrq9+gXvK Gxs7fV100wjzAUe+JHdf1Pwx+JnyzoZ70nUw0iB2H0Vl25+7QNfj1EQnonASrqg+yQH1 fNOiXQ0Oe8xmiQ1pF2bXXoH7P9KD5i9xnQaw1/I1umWRbdEm+Y8zxz/AK/DZZrmv0OY7 MAsp0sMoS7hQxuw6XSeD5uiIbxzjQXgbFhv5iAN4LlZ7pibfhMzQUHs6O/W6ZiBV7ZyK +zWekdSLAvofSzE+jAwaGGwO8U+ncpfvLPm1Fuw/T2laRRTspG5ezIqFPxPoWvfDBwzY WbxQ== X-Gm-Message-State: AMke39nntr1Pw2s/f3htJUlUhaUtLhV0s8d1kXJswAYxL0gLRP4yKSViir0Bzexxo8X3U6FCdtt3sISFBdPcEQ== X-Received: by 10.200.39.130 with SMTP id w2mr17488756qtw.280.1488228913446; Mon, 27 Feb 2017 12:55:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.140.78 with HTTP; Mon, 27 Feb 2017 12:55:13 -0800 (PST) In-Reply-To: References: <22701.42500.198298.440746@fireball.acr.fi> From: Kathleen Moriarty Date: Mon, 27 Feb 2017 15:55:13 -0500 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" , draft-ietf-ipsecme-rfc7321bis@ietf.org, Tero Kivinen Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:55:15 -0000 On Mon, Feb 27, 2017 at 2:31 PM, Paul Wouters wrote: > On Mon, 27 Feb 2017, Kathleen Moriarty wrote: > >>> I think that may help head off questions in last call and IESG review >>> if anyone else looks back at 7321. >> >> >> Is there any chance this update could happen today so I can start last >> call? I'd like ot keep this on the 3/16 telechat with the other >> IPsecme draft if possible. > > > Yes, I'll push out an update today that includes what Tero and I said to > replace that one liner you pointed at. Great, thank you! > > Paul -- Best regards, Kathleen From nobody Mon Feb 27 13:13:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C051293D9; Mon, 27 Feb 2017 13:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtJFPwZSYh8K; Mon, 27 Feb 2017 13:13:07 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0092.outbound.protection.outlook.com [23.103.201.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D440128B37; Mon, 27 Feb 2017 13:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XIEbQ40mJ4CYbKswz/5Tv9jEEjlY3u5opwm/Lz2mcYA=; b=NERumeami03kD6V7/EUnrgeLxVDHemdK05cIFDborvdz7+uY+ZAxyxKdhYVcBQrD/vZBz9w3VKJhi0dSENaF9VWHMnmBFytnQMBs9T23jBEHRofP1bAvZS9tBBFBvxIUVSl0Tz8c5kexBjS6vI40hS8YSPRJYKuWNXrtkeXAjZw= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Mon, 27 Feb 2017 21:04:18 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0933.016; Mon, 27 Feb 2017 21:04:18 +0000 From: "Waltermire, David A. (Fed)" To: Kathleen Moriarty , "paul@nohats.ca" Thread-Topic: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis Thread-Index: AQHSiTOnhiUcmRSO+k6fzNHsWURsW6FtcQ0AgAAuIwCABg9vAIABdfUAgAA6tgCAB+mMgIAABO2AgAAXaoCAAAJy8A== Date: Mon, 27 Feb 2017 21:04:18 +0000 Message-ID: References: <22701.42500.198298.440746@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 6b89cd85-0ee9-448c-419e-08d45f5431f8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:MWHPR09MB1438; x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 7:agMpWDG2aDKSOXAxwT81uLGGMtAGDqFegmjj8E51WhkyaC/43m3n36KrN5v3zLGXyEVEr2GKvFZ8asBWKwtaVsDp0jR6e7xcYUZh9arT4gaJjyDU/7GyQ5JLMyMtBmPEistFEbzt5XSn/a+y6hO6xgKJU3NZAzE6sbV2HfflBFME568bl8TOiCxCHhunBVqwZnEhVZsQGdn8ee9Cfh5pZNxGetwYox/BYCv1TphEjG5FlSl3nZ6luxQ/ejc4uOy8PvVcullQ2Aotu9AGI7A2DQQZu0Qm/QqADE0kj6rpUM6kpDL57SZJIGt1n0dIWMiez2EuQZLfo0G8BlpJS2oaBw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(6072148); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(24454002)(189002)(199003)(13464003)(377454003)(51444003)(2950100002)(8936002)(7696004)(81166006)(81156014)(68736007)(86362001)(229853002)(5660300001)(101416001)(2906002)(54356999)(77096006)(8676002)(6506006)(76176999)(6436002)(92566002)(105586002)(106116001)(4326007)(106356001)(2900100001)(122556002)(6306002)(50986999)(9686003)(55016002)(54906002)(6246003)(99286003)(33656002)(39060400002)(230783001)(97736004)(53546006)(66066001)(102836003)(53936002)(3846002)(74316002)(25786008)(2501003)(38730400002)(93886004)(305945005)(3660700001)(189998001)(7736002)(3280700002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2017 21:04:18.3545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Cc: "ipsec@ietf.org" , "draft-ietf-ipsecme-rfc7321bis@ietf.org" , Tero Kivinen Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:13:09 -0000 Thanks Paul! Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Kathleen Moriart= y > Sent: Monday, February 27, 2017 3:55 PM > To: paul@nohats.ca > Cc: ipsec@ietf.org; draft-ietf-ipsecme-rfc7321bis@ietf.org; Tero Kivinen > > Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc7321bis >=20 > On Mon, Feb 27, 2017 at 2:31 PM, Paul Wouters wrote: > > On Mon, 27 Feb 2017, Kathleen Moriarty wrote: > > > >>> I think that may help head off questions in last call and IESG > >>> review if anyone else looks back at 7321. > >> > >> > >> Is there any chance this update could happen today so I can start > >> last call? I'd like ot keep this on the 3/16 telechat with the other > >> IPsecme draft if possible. > > > > > > Yes, I'll push out an update today that includes what Tero and I said > > to replace that one liner you pointed at. >=20 > Great, thank you! > > > > Paul >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Feb 27 14:32:08 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EE7129426; Mon, 27 Feb 2017 14:32:07 -0800 (PST) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148823472729.13811.12936997744870463220.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 14:32:07 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:32:07 -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 of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Daniel Migault John Mattsson Paul Wouters Yoav Nir Tero Kivinen Filename : draft-ietf-ipsecme-rfc7321bis-05.txt Pages : 14 Date : 2017-02-27 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-05 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/