From nobody Sun Nov 3 13:44:36 2019 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 E5AAB120024 for ; Sun, 3 Nov 2019 13:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrAuDrDlXoru for ; Sun, 3 Nov 2019 13:44:31 -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 A088212001E for ; Sun, 3 Nov 2019 13:44:31 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 475qFm3lJYzFhL for ; Sun, 3 Nov 2019 22:44:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572817468; bh=wma2x2FYUT2WlfiCSzSPX2W/335g/HHSt89LnsORgpg=; h=Date:From:To:Subject; b=swPBaJAPqUT/ZWAvL6yjYGfXjmAqzdvXjhKX9SHkzCNKaKcKpjnAlJREqmsNlz7mN 0Iwq+HPfL1/kteUMsSS1bzCHD2hN1wYCfbCj9+U4IuWGN7zzJZCwnvbY8jME8mPeJs adG4LufxbVhRlsKSe+zp4Isl5B2jssy32ONp5HI4= 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 SnIaid3od3Ch for ; Sun, 3 Nov 2019 22:44:27 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 3 Nov 2019 22:44:26 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B24DA607CB78; Sun, 3 Nov 2019 16:44:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AE6E1CB854 for ; Sun, 3 Nov 2019 16:44:25 -0500 (EST) Date: Sun, 3 Nov 2019 16:44:25 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] updated draft-pwouters-ikev1-ipsec-graveyard-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 21:44:34 -0000 Hi, I've updated the graveyard draft. Changes are: - Extended Updates: to include 8221,8247 - Updated boilerplate to RFC-8174 language - Do not obsolete anything we mentioned in RFC 8247 as 8247bis should do that. (eg no longer deprecate DH 2,5,23,24) - Clarify listed entries (deprecated for obsoleteness or because unspecified) - List either [RFC 8247] or [this document] as the deprecator for IANA - Consistently add entries of UNSPECIFIED algorithms to DEPRECATED status for IANA - Updated references new version: https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-01 diff: https://tools.ietf.org/rfcdiff?url2=draft-pwouters-ikev1-ipsec-graveyard-01.txt That said, I do wish we would do a 8247bis that changes DH 2,5,23,24 and prf/integ SHA1 to MUST NOT as every IKEv2 stack supports better minimal algorithms for these. Paul From nobody Sun Nov 3 14:39:55 2019 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 865D01200F3; Sun, 3 Nov 2019 14:39:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157282079254.13233.13977227788010190084.idtracker@ietfa.amsl.com> Date: Sun, 03 Nov 2019 14:39:52 -0800 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-tjhai-ipsecme-hybrid-qske-ikev2 in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 22:39:53 -0000 The IPSECME WG has placed draft-tjhai-ipsecme-hybrid-qske-ikev2 in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hybrid-qske-ikev2/ From nobody Sun Nov 3 14:42:13 2019 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 142721200F5 for ; Sun, 3 Nov 2019 14:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 UnJMikyE3lxq for ; Sun, 3 Nov 2019 14:42:09 -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 4C8B7120090 for ; Sun, 3 Nov 2019 14:42:09 -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 xA3Mg7M5023569 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Nov 2019 00:42:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id xA3Mg74s020249; Mon, 4 Nov 2019 00:42:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23999.22463.132733.702468@fireball.acr.fi> Date: Mon, 4 Nov 2019 00:42:07 +0200 From: Tero Kivinen To: ipsec@ietf.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: Subject: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 22:42:11 -0000 This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2 draft to be accepted to be WG Document. This draft has been around for some time, and we have been discussing it in the meetings. If you support adopting this document as WG Document, then send email indicating your support to the ipsec@ietf.org mailing-list. If you have any comments or reservations send them to the list too. This adoption call finishes 2019-11-11. -- kivinen@iki.fi From nobody Sun Nov 3 14:43:17 2019 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 3968A1200FD; Sun, 3 Nov 2019 14:43:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157282099623.13452.2727393632311286847.idtracker@ietfa.amsl.com> Date: Sun, 03 Nov 2019 14:43:16 -0800 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-yeung-g-ikev2 in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 22:43:16 -0000 The IPSECME WG has placed draft-yeung-g-ikev2 in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/ From nobody Sun Nov 3 14:48:38 2019 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 4BB2F120090 for ; Sun, 3 Nov 2019 14:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 q1h1sS2_dXAs for ; Sun, 3 Nov 2019 14:48:34 -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 1ECA01200F5 for ; Sun, 3 Nov 2019 14:48:33 -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 xA3MmVRO018583 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Nov 2019 00:48:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id xA3MmVep028687; Mon, 4 Nov 2019 00:48:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23999.22847.102427.234841@fireball.acr.fi> Date: Mon, 4 Nov 2019 00:48:31 +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: 5 min Archived-At: Subject: [IPsec] Adoption call for draft-yeung-g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 22:48:36 -0000 This is a adoption call for the draft-yeung-g-ikev2 draft to be WG document. This document has been around for long time, and we inherited it from the msec WG when it closed down. We have already decided to take this as an chater item so making this WG document should be ok. If you support adopting this document as WG Document, then send email indicating your support to the ipsec@ietf.org mailing-list. If you have any comments or reservations send them to the list too. As this document is longer, and has new exchanges for IKEv2, this is two week long adoption call, allowing more time to read the document through. This adoption call finishes 2019-11-16. -- kivinen@iki.fi From nobody Mon Nov 4 03:40:14 2019 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 147EC1200DF for ; Mon, 4 Nov 2019 03:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l97uFO_ksj2 for ; Mon, 4 Nov 2019 03:40:10 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 D29581200D7 for ; Mon, 4 Nov 2019 03:40:09 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id g3so11080788ljl.11 for ; Mon, 04 Nov 2019 03:40:09 -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:content-language:thread-index; bh=UfvX/n4p85x4TEdc1+5SEyWFn78BTvhrMMZpJARgqAY=; b=Tb516Ws056oZWWew9RRlEitBo2yzD+8LMO/r6z9WQjuxWc119VLBm5a1pETlkRonKP Qj7RJD6HNT49jb4lcET2fvNJ9E/ItmI5SUAjRo4tOurIz9nWY0XUzlM12n+dfznfkYGN oNSBof+DqrgC6EA8Q/x+otexdtYh/DbG/+tj2QzRD7+ohAHTQ57OA8ZGCafASGBejwPq y9bC0t/pIutzg29mimi1Jetec0fo6BFinA+APEE5hsz+ijDsYktbGGMle9I4lEUBgDKK VXyPxFh8lfcXExDbfKnj9xXBctARplnTprORJPNpNkKo5n/hfvdr88vH3cIsiVC2xfoZ oFEg== 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:content-language :thread-index; bh=UfvX/n4p85x4TEdc1+5SEyWFn78BTvhrMMZpJARgqAY=; b=qQZg2o79neL68ah0+/M7HF7oB+Th+agClrP2Sl5jgWcOto4a/NWe0XONEfUM0ZuwfY uyODB9sIbuJAwbTVP1S0UKafK31Yq4XHRf+qYA2qjI9G91YvIByrbefnLY9XGExKd9Xx FcMzKGG1y5j+jkXFTUQggy7Bz+wgK2jSU1xLEJQorxD8lgbnFJbx5h4DeJASQLLrkcTs 6IYYDHUXId+27B9dQ9w+IPw/kvoibgD/x0jrT2w0fozWOsRksuikUqXcu39YENJIZin7 R7DPx7lRyWY2gO71oId8TIahAr8bXyeobkMZ+jsnezn1DSYtJEu7IDBceuJPD3UZBowy pEQg== X-Gm-Message-State: APjAAAUs/oodMMyt4EaF5FtaeOFcKrwQ9IrWk9b6Zcd2LYzvhZ4nc39O iCkhu6tO99tc46EWBG4d+npbymDv X-Google-Smtp-Source: APXvYqzwttq/WFivrbDFMjJCzOf9tU3XI/u59hXOiLBMAMZ7GpraGZBLBYWb2ZYxXjF9Q/kr3VZ7Dg== X-Received: by 2002:a2e:8e88:: with SMTP id z8mr18201716ljk.56.1572867607820; Mon, 04 Nov 2019 03:40:07 -0800 (PST) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id a11sm6706935ljp.97.2019.11.04.03.40.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Nov 2019 03:40:07 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <23999.22463.132733.702468@fireball.acr.fi> In-Reply-To: <23999.22463.132733.702468@fireball.acr.fi> Date: Mon, 4 Nov 2019 14:39:47 +0300 Message-ID: <009601d59304$90081a20$b0184e60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJIzRedXI2okcVeVQLJ6iDp5b4brqaUbP9g Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 11:40:12 -0000 Hi, I support adoption of this draft (not a surprise, I'm a co-author). I think the draft is of interest from various vendors and I know that some vendors have already implemented it (or one of its earlier versions), so making it a WG document will help achieve interoperability. Regards, Valery. > This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2 > draft to be accepted to be WG Document. This draft has been around for > some time, and we have been discussing it in the meetings. > > If you support adopting this document as WG Document, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to the list too. > > This adoption call finishes 2019-11-11. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 4 03:52:14 2019 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 01D2B1200B3 for ; Mon, 4 Nov 2019 03:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scsJZ1KBYJVQ for ; Mon, 4 Nov 2019 03:52:09 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 8EA7312004C for ; Mon, 4 Nov 2019 03:52:09 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id j14so12011724lfb.8 for ; Mon, 04 Nov 2019 03:52:09 -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:content-language:thread-index; bh=AXt4SeghjYxRmzrhyIRug1VQ8QQNANWjH56QYgejNXM=; b=bENGe+hEFaYOI/uWR2lvcWqx3XUqdSU7ghXvGDoYmYIGdooz/a3vur3BqanOCP5zP0 S0ynE+8w9kfv3uQzuDrYn56ZBbDmsx2KX65zmVrzeJuDXgT5syTkO4Q7dzVSTvM5fVMM QJvjUbBCbp767A18He7FQfzTJnaQuygcn0QblY0pIZJXeL413z7LvR0AMxBcj96A2pWb l1DekbKBs5ofJqnYPUAS1prC5tA5nVu8KfOWGpo9u6Bue48e9LYuw3LAqWyZP0fmQ/9P shil2QpWJZGvU/CSMiVVRi2csqJGvBr0GJEzaTDThNAaQPCg7n5FOFzJteKVTklOnWtE 9jVg== 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:content-language :thread-index; bh=AXt4SeghjYxRmzrhyIRug1VQ8QQNANWjH56QYgejNXM=; b=Y/p6Ywxr44JYTgTBuqKnNrUhsTeu8NvZVEy4g6XdmBpv+5EO4C+knoJdycuOp3Uzzi vHDDiteEZpiNoffVV6btPaROZ66xrBg8HkIGZLyVjEcwTzyGb2fHZckJneB8WZ+FEscH mJ1JTka1K5Bv/ksAO1zGqtjS3vEoD2ZiVNZtTicxcevLCwui05Mx9ociKBZ46f9eGU0M CH/CaBG+kRuDPJV+OqD4Z6uZR5E4RjWQEpbkAauTrheworNEMLT3nbuP+36qQIFPqS1U /Uzg+oOA2UTj3v/HsTlqIttKLUkIFAlCCwIJ9ESzndPFKTHwrw4q1NSlb8kc6t4B121D VwhA== X-Gm-Message-State: APjAAAUwqY5IpU4pPf3aJdvUOjY+3SpDqrtQtUKKxfOPtxz8TYbFLRja JABH8HoMe7F0kj5LDBvWkrAc1qED X-Google-Smtp-Source: APXvYqxVqm9slTWNS61H58YEptDtqk62nDJfxOt+H7Tm6PfPkslmxv5Eo3BTylZCSvGNpeihTxHUWQ== X-Received: by 2002:ac2:523c:: with SMTP id i28mr16131053lfl.165.1572868327484; Mon, 04 Nov 2019 03:52:07 -0800 (PST) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id n11sm9505679lfd.88.2019.11.04.03.52.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Nov 2019 03:52:06 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <23999.22847.102427.234841@fireball.acr.fi> In-Reply-To: <23999.22847.102427.234841@fireball.acr.fi> Date: Mon, 4 Nov 2019 14:51:47 +0300 Message-ID: <009701d59306$3d12d970$b7388c50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQHmmpYbY/qPzBSEOojZw6yx8i1rlqdY0/rA Archived-At: Subject: Re: [IPsec] Adoption call for draft-yeung-g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 11:52:12 -0000 Hi, I support adoption of this draft (again, not a surprise, I'm a co-author). The draft is around for quite a long time and there are several implementations of earlier versions of the draft. I think that the draft addresses an important problem of key management for securing multicast traffic using up-to-date protocol, and thus should be adopted. Regards, Valery. > This is a adoption call for the draft-yeung-g-ikev2 draft to be WG > document. This document has been around for long time, and we > inherited it from the msec WG when it closed down. We have already > decided to take this as an chater item so making this WG document > should be ok. > > If you support adopting this document as WG Document, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to the list too. > > As this document is longer, and has new exchanges for IKEv2, this is > two week long adoption call, allowing more time to read the document > through. This adoption call finishes 2019-11-16. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 4 04:45:50 2019 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 3F8C91200C3 for ; Mon, 4 Nov 2019 04:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NMS4wAZ5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Kgr7LgKW 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 2byVtsSqGPi2 for ; Mon, 4 Nov 2019 04:45:45 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F48A1200E5 for ; Mon, 4 Nov 2019 04:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2300; q=dns/txt; s=iport; t=1572871545; x=1574081145; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=m1tS91OhzrlD0G4jpdvHvCyIQrNHUn5TAPjT3cHdVM0=; b=NMS4wAZ5XsBRjdt5Ydu/L71H+V0nLxwagJL6XmZ/cBu7KSRSybfpRS0h yrURI0NGaHaV9z3t8bs2C9i2z5Vzrq4YD9R5U75RYV0AFh1Y/uGQCjcKe f8oj4N96LFgJCYND1YfT348Du8n12MBcN1Rv1RHNWZpX/fze3g9r41qHS Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AzYSlbhC17/LTmu2rXlHuUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuI+TgZjYmGMlqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAADwHMBd/4wNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkHAQELAYFKUAVsWCAECyoKhB+DRgOEWoYaToIQgzuGG44ngS4?= =?us-ascii?q?UgRADVAkBAQEMAQEYCwoCAQGEQAIXg3YkNAkOAgMBAwIDAgEBBAEBAQIBBQR?= =?us-ascii?q?thTcMhVIBAQECAQEBEAsGEQwBASwMDwIBCBoCJgICAh8GCxUQAgQBEiKDAAG?= =?us-ascii?q?CRgMOIAEOpiUCgTiIYHWBMoJ+AQEFgkmCTA0LghcDBoEOKAGMEhiBQD+BOB+?= =?us-ascii?q?CTD6CG0cBAYEuARIBHxeCeTKCLI9+nTdBCoIkkSaEEBuZZY5Cij+PGAIEAgQ?= =?us-ascii?q?FAg4BAQWBUjkqPXFwFTsqAYJBUBEUgwaDc4UUhT90gSiLFYEiAYENAQE?= X-IronPort-AV: E=Sophos;i="5.68,267,1569283200"; d="scan'208";a="372231372" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2019 12:45:44 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xA4CjiJJ007310 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Nov 2019 12:45:44 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 06:45:43 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 07:45:43 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 4 Nov 2019 06:45:43 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b1tsEWj+303bVfgSJHw3e+VTNHEQfNOvWWPoLumafdVXxxu6r/+YJQeAKuG5oLxVZOg5NTzahxW2+p4GHl0qK7s5RlDA7zwkgcO3kAtKKjCBznEA08NaDkuocmyLBE03dEopERCJ7IuI1j+EXiiaasUt0M8cyScsmo3BrFgvdEjeNhz0NwUavnb4VcJDbZdvx3k38xpE3eiBzm0txilUOT1HEXAlVuS+LC2v1ek648WLj3utvK5MB9TS6lybmJaXtscxUTYjloF4RKJfBYxS2wmX+1+VWRYZyCwPNcQ2kWgCwxIMcNz1lSHZ6JkvXcehIwB0kVJScKIy1PVzBvdN2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m1tS91OhzrlD0G4jpdvHvCyIQrNHUn5TAPjT3cHdVM0=; b=ZkrT7B1mIRpgM0FjbBk8dkiNcXaq8ZDgaP0uBuj8GXNxSVYUYdaoJEqk2Npgfgm1aI0RPsForlycSC2VZXHpLqO8vaA4Wg5rUX4TzehthbWsrDLoBjMxoKh7cC41jMmPnpSWAtzXfyyDVlxiRHuFR1xy0yyy73M7COtZ9ND5LxskMK4xGE9BSHQbGtHhFS6Ivlj0YHHfM98ADbKYwi0R4On72V+oL7SNZx5vGhqYbjnnDfpezu/x4MyKwCN3ucrHbQ/ao7kkhNW95/GbBGdWchfLIlJ4VHbLnOZ6nAh/VmqnplDsDkTu6kaGRzL5k07dUpWTRl8t6r6rtIewT8YNbg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m1tS91OhzrlD0G4jpdvHvCyIQrNHUn5TAPjT3cHdVM0=; b=Kgr7LgKWu7x5jY7giX9DviKQ3dMIdW339t2YiuEW7m/kQIMS0xfOMUtMDERlhCyhvs94ONsL5vx4Z2ImUML3nMI1Rue0xo6+AC5MYlxBG/UD6kNiocrrdkFfelt0mOyNVrKkOR3DEyJXrt8wqVOy0vvdQm6S5e8FQ+OXZSM++6U= Received: from DM5PR11MB1691.namprd11.prod.outlook.com (10.168.103.148) by DM5PR11MB1979.namprd11.prod.outlook.com (10.175.87.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Mon, 4 Nov 2019 12:45:40 +0000 Received: from DM5PR11MB1691.namprd11.prod.outlook.com ([fe80::11a6:7b55:9bcc:e4ab]) by DM5PR11MB1691.namprd11.prod.outlook.com ([fe80::11a6:7b55:9bcc:e4ab%7]) with mapi id 15.20.2408.024; Mon, 4 Nov 2019 12:45:40 +0000 From: "Graham Bartlett (grbartle)" To: "'Tero Kivinen'" , "ipsec@ietf.org" Thread-Topic: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 Thread-Index: AQHVkpgBcr2Q0NPmgkOKFoyADlTdtqd64+6AgAASaAA= Date: Mon, 4 Nov 2019 12:45:40 +0000 Message-ID: References: <23999.22463.132733.702468@fireball.acr.fi> <009601d59304$90081a20$b0184e60$@gmail.com> In-Reply-To: <009601d59304$90081a20$b0184e60$@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=grbartle@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ee5f8a7a-cd8d-4767-58b6-08d76124e66b x-ms-traffictypediagnostic: DM5PR11MB1979: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(376002)(366004)(346002)(189003)(199004)(14454004)(8936002)(81156014)(66066001)(66946007)(91956017)(66476007)(66556008)(66446008)(64756008)(71190400001)(6246003)(8676002)(81166006)(99286004)(86362001)(71200400001)(6436002)(6486002)(76116006)(5660300002)(4001150100001)(446003)(11346002)(229853002)(7736002)(305945005)(2906002)(476003)(486006)(2616005)(478600001)(966005)(25786009)(26005)(186003)(33656002)(256004)(6306002)(36756003)(14444005)(6116002)(3846002)(2501003)(102836004)(6506007)(58126008)(110136005)(6512007)(316002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1979; H:DM5PR11MB1691.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R1lKkHZWVTniNrfHShy02VQOWNHk2aZ8KM6caffvEN5fiAPtYjjU44fxmoOxIuTkteQQpl62mamG2om4RT5yd/rfZI9C9Zk4RfVQ91UY4LVE/dKzfrAwYk5NRj+PZ63uMe5zi1GmO+ATdumkAumt3lETkQfP7d6G/4MRkgVtmTJveY+CAUPzquCRIkCul4LtYrfnz7flZgE9we1pP2GW4NAbqKadB8qqC1bPsuGG0QJdmTcNm+iQXqM8CyvcaUede1IOE+Z8Es60pNWGStu7pI5eUQ7ZVRbXdf4i3t9hJcPqPj1w4IDgtgKd/nNpOnvIbNn/JSNSSdmq0fDagrq8CRnAKqAA5TlfQ0ISut2B6NyrkTgqJLxDwR8vbK6DfD1RVo1xbzXnwZsuUEpnaKObhqnBOpZ3Eg7dehlk2z2LmZDa2LrDY8t9XLlWm//rSqmimjuwjlOAeRXtak2sZfml6R77fCJk2qBKzlsNu+R9KDk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <471BA88CB9859D4A986C3E9B232D9207@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ee5f8a7a-cd8d-4767-58b6-08d76124e66b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 12:45:40.6367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MgTSfFK18bcv+G0gH9SzYksPGQGv7lBxSlrdWEr1oUpdtU8dJzMJkQUEMLvLeBD87E/a78aYeCSh4avSC8vNpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1979 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 12:45:49 -0000 SGkNCg0KTGlrZSBWYWxlcnksIEknbSBhIGNvLWF1dGhvciBhbmQgc3VwcG9ydCBhZG9wdGlvbi4N Cg0KSSBoYXZlIHNlZW4gYSBsb3Qgb2YgY3VzdG9tZXIgaW50ZXJlc3QgaW4gdGhpcyBkcmFmdCBh cyBpdCB3aWxsIGFsbG93IG9yZ2FuaXNhdGlvbnMgdG8gaW1wbGVtZW50IHN0YW5kYXJkIGJhc2Vk IFBRQyBhdCBzY2FsZS4gT25lIG1haW4gZHJpdmVyIGJlaW5nIHJlZHVjdGlvbiBvZiBidXNpbmVz cyByaXNrLg0KDQpUaGlzIHdpbGwgcHJvdmlkZSB1c2VycyBvZiBJS0V2MiB0byBwcm90ZWN0IHRo ZW1zZWx2ZXMgd2hlbiBtaWdyYXRpbmcgdG8gYSBQUSB3b3JsZC4NCg0KY2hlZXJzDQoNCu+7v09u IDA0LzExLzIwMTksIDExOjQwLCAiSVBzZWMgb24gYmVoYWxmIG9mIFZhbGVyeSBTbXlzbG92IiA8 aXBzZWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc215c2xvdi5pZXRmQGdtYWlsLmNv bT4gd3JvdGU6DQoNCiAgICBIaSwNCiAgICANCiAgICBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhp cyBkcmFmdCAobm90IGEgc3VycHJpc2UsIEknbSBhIGNvLWF1dGhvcikuDQogICAgSSB0aGluayB0 aGUgZHJhZnQgaXMgb2YgaW50ZXJlc3QgZnJvbSB2YXJpb3VzIHZlbmRvcnMgYW5kIEkga25vdw0K ICAgIHRoYXQgc29tZSB2ZW5kb3JzIGhhdmUgYWxyZWFkeSBpbXBsZW1lbnRlZCBpdCAob3Igb25l IG9mIGl0cyBlYXJsaWVyDQogICAgdmVyc2lvbnMpLA0KICAgIHNvIG1ha2luZyBpdCBhIFdHIGRv Y3VtZW50IHdpbGwgaGVscCBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkuDQogICAgDQogICAgUmVn YXJkcywNCiAgICBWYWxlcnkuDQogICAgDQogICAgPiBUaGlzIGlzIGFkb3B0aW9uIGNhbGwgZm9y IHRoZSBkcmFmdC10amhhaS1pcHNlY21lLWh5YnJpZC1xc2tlLWlrZXYyDQogICAgPiBkcmFmdCB0 byBiZSBhY2NlcHRlZCB0byBiZSBXRyBEb2N1bWVudC4gVGhpcyBkcmFmdCBoYXMgYmVlbiBhcm91 bmQgZm9yDQogICAgPiBzb21lIHRpbWUsIGFuZCB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBpdCBp biB0aGUgbWVldGluZ3MuDQogICAgPiANCiAgICA+IElmIHlvdSBzdXBwb3J0IGFkb3B0aW5nIHRo aXMgZG9jdW1lbnQgYXMgV0cgRG9jdW1lbnQsIHRoZW4gc2VuZCBlbWFpbA0KICAgID4gaW5kaWNh dGluZyB5b3VyIHN1cHBvcnQgdG8gdGhlIGlwc2VjQGlldGYub3JnIG1haWxpbmctbGlzdC4gSWYg eW91DQogICAgPiBoYXZlIGFueSBjb21tZW50cyBvciByZXNlcnZhdGlvbnMgc2VuZCB0aGVtIHRv IHRoZSBsaXN0IHRvby4NCiAgICA+IA0KICAgID4gVGhpcyBhZG9wdGlvbiBjYWxsIGZpbmlzaGVz IDIwMTktMTEtMTEuDQogICAgPiAtLQ0KICAgID4ga2l2aW5lbkBpa2kuZmkNCiAgICA+IA0KICAg ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ IElQc2VjIG1haWxpbmcgbGlzdA0KICAgID4gSVBzZWNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCiAgICANCiAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIElQc2VjIG1haWxpbmcg bGlzdA0KICAgIElQc2VjQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHNlYw0KICAgIA0KDQo= From nobody Mon Nov 4 06:42:34 2019 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 D481C1200A4 for ; Mon, 4 Nov 2019 06:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCTPUqhH-sRZ for ; Mon, 4 Nov 2019 06:42:31 -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 79F9112002E for ; Mon, 4 Nov 2019 06:42:31 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 476FrM60ZVzFfH; Mon, 4 Nov 2019 15:42:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572878547; bh=HY5KpVa94J7Ye86PA5Y7vG/yqlwbB/Tz6UHQJ4KwEbs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=arEKCQx9AWs02bqTWti78k/GtNZXxfpLnc4t/YUntHgHLFBNlFPqx4ixOmdFrngbZ T53LLT97dOkNSVXSLPYtqMs62HoZ+aKv7IFZ+/32w0ouVu5Gmy0imh+Ps1TBBEE85n HLJXAzFv40sLgJEEVsMp60vLB8CZq2MQk8DiOkGo= 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 vrBTpizsZ4Z7; Mon, 4 Nov 2019 15:42:26 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 Nov 2019 15:42:26 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 02F086007C4D; Mon, 4 Nov 2019 09:42:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3A6923D09D; Mon, 4 Nov 2019 09:42:24 -0500 (EST) Date: Mon, 4 Nov 2019 09:42:24 -0500 (EST) From: Paul Wouters To: "Graham Bartlett (grbartle)" cc: 'Tero Kivinen' , "ipsec@ietf.org" In-Reply-To: Message-ID: References: <23999.22463.132733.702468@fireball.acr.fi> <009601d59304$90081a20$b0184e60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 14:42:33 -0000 On Mon, 4 Nov 2019, Graham Bartlett (grbartle) wrote: > Like Valery, I'm a co-author and support adoption. > > I have seen a lot of customer interest in this draft as it will allow organisations to implement standard based PQC at scale. One main driver being reduction of business risk. > > This will provide users of IKEv2 to protect themselves when migrating to a PQ world. Agreed, please adopt. And libreswan plans to implement this. Paul From nobody Mon Nov 4 06:45:11 2019 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 B02CA1200A4 for ; Mon, 4 Nov 2019 06:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHqhJ5Do3_0T for ; Mon, 4 Nov 2019 06:45:07 -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 EEAC1120099 for ; Mon, 4 Nov 2019 06:45:06 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 476FvP50sLzFfH; Mon, 4 Nov 2019 15:45:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572878705; bh=8sp5ipZ9nasNg7FTQrxOUX/X3e/xhbcehOzD/Hyyrx8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qu+TQkPHQQWkszt4UzDIUm70XcNfoZPJceKHLbHzfdxpA3lj68eFafQdq2boPnISf IhkR7ax7z+C99046WN57zVCGkC+LBxZOUAH8Rzg2RamnPmsDqVv3jcrCI3bT9mWokP yhna949UyEmrQOLbme+gmqmoqBPfv2fAccoOi8qk= 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 7qnZ05ZyTj8T; Mon, 4 Nov 2019 15:45:04 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 Nov 2019 15:45:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7E4696007C4D; Mon, 4 Nov 2019 09:45:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7AAC623D09D; Mon, 4 Nov 2019 09:45:03 -0500 (EST) Date: Mon, 4 Nov 2019 09:45:03 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23999.22847.102427.234841@fireball.acr.fi> Message-ID: References: <23999.22847.102427.234841@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Adoption call for draft-yeung-g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 14:45:10 -0000 On Mon, 4 Nov 2019, Tero Kivinen wrote: > This is a adoption call for the draft-yeung-g-ikev2 draft to be WG > document. This document has been around for long time, and we > inherited it from the msec WG when it closed down. We have already > decided to take this as an chater item so making this WG document > should be ok. > > If you support adopting this document as WG Document, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to the list too. > > As this document is longer, and has new exchanges for IKEv2, this is > two week long adoption call, allowing more time to read the document > through. This adoption call finishes 2019-11-16. I'm in favour of adoption. As a vendor, I was waiting on implementing the document until a rewrite that would use more IKEv2/IPsec terminology, something Tero as chair had strongly suggested the authors do. I hope that would still be the plan after adoption. Paul From nobody Mon Nov 4 11:43:48 2019 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 ED82E1208A7; Mon, 4 Nov 2019 11:43:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157289661291.13968.246480223926543325@ietfa.amsl.com> Date: Mon, 04 Nov 2019 11:43:32 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 19:43:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Labeled IPsec Traffic Selector support for IKEv2 Authors : Paul Wouters Sahana Prasad Filename : draft-ietf-ipsecme-labeled-ipsec-02.txt Pages : 8 Date : 2019-11-04 Abstract: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-02 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 Nov 4 13:29:50 2019 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 174E71209F7 for ; Mon, 4 Nov 2019 13:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=post-quantum-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 3cyJ_Iy5nQFi for ; Mon, 4 Nov 2019 13:29:39 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 E3313120A60 for ; Mon, 4 Nov 2019 13:29:38 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id u13so15784900ote.0 for ; Mon, 04 Nov 2019 13:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=KYVqdB0w5HuXBn3S8lu2iKXhEDUdvkKUY/Ps9f+qDUA=; b=Fd2I7tOcYrs4FS5/AjuCr8sO102pW55LjYg1o5lzqAJ7AzacOzd50rMuQgsfArLbwD BpX1zDNF7jVVLvStMoHcTKFfOp3F+S7xtmJhK3W1Qj5Lva/HXqTKw3o8B6TGXhtFGcLV 7UkBR5TsiQfcAx27g33PivCYXfSAIUJskRYGl9wIRg9p22CK+6PvnG6ZR7n8ZhSva1mz eVEwCjp71ntQJRNSh7LS2mH1KjsyGL1k3elRqALEh91oIQNqwaDcEGxmnFpaCMrHYBm0 /JWmBBSUmgS5S0bAXCFAntjDzovV2XrrgHMMVmapuEhi4xUeP2gavK0Kx5JluS7fp8LC pAIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=KYVqdB0w5HuXBn3S8lu2iKXhEDUdvkKUY/Ps9f+qDUA=; b=mknAo2vfmurvIC5Nhfh34kBCBar3d7T0s8AqSuMK02bcYrTrcYVL390lytHiSdsWgP jQqaEFCb1G1SMv8WkSaz5bJbhBPfhFEETpcf3tan5TRX8/bWJdBqWK25LBh+EgzLQ+65 f78Pb65M2M9ctk6Jy5BrJrcFOJz5QPX2EGSVAOM5bN3Tjh6aNxMmon/qvVaIUm0pb2mR jzSCFsya17bOvPPyL22EktpJj+nyDg3VP8CQBhZzji9Gaoeh1TD97zsim6t9SYva3NNy Mc4V464ODl6D+WhZbqnh3rDjy7znVMeNUziGM6D69GywDGDr0unS57lEwe5sjSmznRNG pUcg== X-Gm-Message-State: APjAAAVBVJ6nxiSeLpRBvxCqdSbp8pSYIY3In0+FixyAO6XG1PTB4Znm b3jkBnxASF9iSD/4iyL23UXHevK4Nv6vwdq7Ax1B+Y0mrY+OWJ3STNuA6fgJkTjVoG2qEHkkAKx XTjYRl61opdzEH9w= X-Google-Smtp-Source: APXvYqxKF4e2cz09DsVdC1hItMYr34Y4IaqwGkROibkKQgYOxaU700r2ltZBipK3EekZuB0aGfrqc2yO/sHw6wwkAEk= X-Received: by 2002:a05:6830:1386:: with SMTP id d6mr4179288otq.135.1572902978159; Mon, 04 Nov 2019 13:29:38 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Nov 2019 22:29:37 +0100 From: CJ Tjhai Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Mon, 4 Nov 2019 22:29:37 +0100 Message-ID: To: Paul Wouters Cc: "Graham Bartlett (grbartle)" , "ipsec@ietf.org" , Tero Kivinen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 21:29:49 -0000 Not sure my vote as a co-author will count, but I also support the adoption= . There are interests in the community on this and I believe there is an interoperability test based on the current version of the draft. CJ > On 4 Nov 2019, at 14:42, Paul Wouters wrote: > > =EF=BB=BFOn Mon, 4 Nov 2019, Graham Bartlett (grbartle) wrote: > >> Like Valery, I'm a co-author and support adoption. >> >> I have seen a lot of customer interest in this draft as it will allow or= ganisations to implement standard based PQC at scale. One main driver being= reduction of business risk. >> >> This will provide users of IKEv2 to protect themselves when migrating to= a PQ world. > > Agreed, please adopt. And libreswan plans to implement this. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=20 PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) is a priva= te limited=20 company incorporated in England and Wales with=C2=A0registered number 06808= 505. =C2=A0 This email is meant only for the intended recipient. If you have received= =20 this email in error, any review, use, dissemination,=C2=A0distribution, or= =20 copying of this email is strictly prohibited. Please notify us immediately= =20 of the error by return email and please=C2=A0delete this message from your= =20 system. Thank you in advance for your cooperation. For more information=20 about Post-Quantum, please visit www.post-quantum.com=20 . In the course of our business relationship,=20 we may collect, store and transfer information about you. Please see our=20 privacy=C2=A0notice at www.post-quantum.com/privacy-notice=20 to learn about how we use this= =20 information. From nobody Mon Nov 4 18:10:44 2019 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 E592B12003E for ; Mon, 4 Nov 2019 18:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 xIfgsn8zr2Is for ; Mon, 4 Nov 2019 18:10:39 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BEAA912000F for ; Mon, 4 Nov 2019 18:10:39 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DF30587A8AD256CED5B0 for ; Tue, 5 Nov 2019 02:10:36 +0000 (GMT) Received: from nkgeml702-chm.china.huawei.com (10.98.57.155) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Nov 2019 02:10:36 +0000 Received: from nkgeml703-chm.china.huawei.com (10.98.57.159) by nkgeml702-chm.china.huawei.com (10.98.57.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 5 Nov 2019 10:10:33 +0800 Received: from nkgeml703-chm.china.huawei.com ([10.98.57.159]) by nkgeml703-chm.china.huawei.com ([10.98.57.159]) with mapi id 15.01.1713.004; Tue, 5 Nov 2019 10:10:33 +0800 From: "Panwei (William)" To: "ipsec@ietf.org" Thread-Topic: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-02.txt Thread-Index: AQHVkvY/Gt+FIsNTKEq64eozZ5NSe6d7zHZw Date: Tue, 5 Nov 2019 02:10:33 +0000 Message-ID: <41dd4078faf7438ca0051968486b65a6@huawei.com> References: <157286141508.16609.5825213440537485887@ietfa.amsl.com> In-Reply-To: <157286141508.16609.5825213440537485887@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.152] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 02:10:42 -0000 SGksDQoNCkkndmUgdXBkYXRlZCB0aGUgSUtFdjIgcmVrZXlpbmcgb3B0aW1pemF0aW9uIGRyYWZ0 Lg0KSW4gdGhlIG5ldyB2ZXJzaW9uLCBJS0UgU0FzIHJla2V5aW5nIG9wdGltaXphdGlvbiBpcyBv cHRpb25hbCBub3cuIEl0J3MgdXAgdG8gdGhlIGltcGxlbWVudGVyIHRvIG9wdGltaXplIHRoZSBJ S0UgU0FzIHJla2V5aW5nIG9yIG5vdC4NCkFuZCB0aGUgb3B0aW1pemF0aW9uIHByb2Nlc3NlcyBh cmUgYWxzbyBzaW1wbGlmaWVkIHRvIHR3byBjYXNlcyAoYmVmb3JlIHdhcyB0aHJlZSBjYXNlcyk6 DQotIFRoZSBpbml0aWF0b3Igc2VuZHMgdGhlIG9wdGltaXplZCByZWtleWluZyByZXF1ZXN0IG1l c3NhZ2UsIHRoZSByZXNwb25kZXIgYWNjZXB0cyBpdCBhbmQgcmVwbGllcyB0aGUgb3B0aW1pemVk IHJla2V5aW5nIHJlc3BvbnNlIG1lc3NhZ2UuDQotIFRoZSBpbml0aWF0b3Igc2VuZHMgdGhlIG9w dGltaXplZCByZWtleWluZyByZXF1ZXN0IG1lc3NhZ2UsIHRoZSByZXNwb25kZXIgcmVmdXNlcyBp dCBhbmQgcmVwbGllcyBOT19QUk9QT0FTTF9DSE9TRU4uDQoNClJldmlldyBhbmQgY29tbWVudHMg YXJlIG1vcmUgdGhhbiB3ZWxjb21lLg0KDQpSZWdhcmRzICYgVGhhbmtzIQ0KxcvOsCBXZWkgUGFu DQq7qs6qvLzK9dPQz965q8u+IEh1YXdlIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmkt ZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnDQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgNCwgMjAxOSA1OjU3IFBNDQo+ IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQt a2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdC0wMi50eHQNCj4gDQo+IA0K PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+IA0KPiANCj4gICAgICAgICBUaXRsZSAgICAg ICAgICAgOiBJS0V2MiBPcHRpb25hbCBTQSZUUyBQYXlsb2FkcyBpbiBDaGlsZA0KPiBFeGNoYW5n ZQ0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFNhbmRlZXAgS2FtcGF0aQ0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgIE1lZHVyaSBTIFMgQmhhcmF0aA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIFdlaSBQYW4NCj4gCUZpbGVuYW1lICAgICAgICA6DQo+IGRyYWZ0LWthbXBhdGkt aXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDIudHh0DQo+IAlQYWdlcyAgICAgICAg ICAgOiAxMg0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxOS0xMS0wNA0KPiANCj4gQWJzdHJhY3Q6 DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZvciByZWR1Y2luZyB0aGUg c2l6ZSBvZiB0aGUNCj4gICAgSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIHZlcnNpb24gMiAoSUtFdjIp IGV4Y2hhbmdlcyBhdCB0aW1lIG9mIHJla2V5aW5nDQo+ICAgIElLRSBTQXMgYW5kIENoaWxkIFNB cyBieSByZW1vdmluZyBvciBtYWtpbmcgb3B0aW9uYWwgb2YgU0EgJiBUUw0KPiAgICBwYXlsb2Fk cy4gIFJlZHVjaW5nIHNpemUgb2YgSUtFdjIgZXhjaGFuZ2VzIGlzIGRlc2lyYWJsZSBmb3IgbG93 DQo+ICAgIHBvd2VyIGNvbnN1bXB0aW9uIGJhdHRlcnkgcG93ZXJlZCBkZXZpY2VzLiAgSXQgYWxz byBoZWxwcyB0byBhdm9pZCBJUA0KPiAgICBmcmFnbWVudGF0aW9uIG9mIElLRXYyIG1lc3NhZ2Vz Lg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rYW1wYXRp LWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hDQo+IGRzLW9wdC8NCj4gDQo+IFRoZXJlIGFyZSBh bHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQN Cj4gLTAyDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQta2Ft cGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXANCj4gYXlsb2Fkcy1vcHQtMDINCj4gDQo+IEEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10 cy1wYXlsbw0KPiBhZHMtb3B0LTAyDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g SS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJu ZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IN Cj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg== From nobody Mon Nov 4 18:38:43 2019 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 D8B0612004D; Mon, 4 Nov 2019 18:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pOPSm9d7y6j; Mon, 4 Nov 2019 18:38:40 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9F1120033; Mon, 4 Nov 2019 18:38:36 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA52cWGb003305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Nov 2019 21:38:34 -0500 Date: Mon, 4 Nov 2019 18:38:31 -0800 From: Benjamin Kaduk To: draft-ietf-ipsecme-qr-ikev2.all@ietf.org Cc: ipsec@ietf.org Message-ID: <20191105023831.GH55993@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 02:38:43 -0000 Hi all, Thanks for this document -- it's pretty readable (once I did my background reading on RFC 7296) and is an interim measure that we're seeing some demand for already. Sorry to have been sitting on this for so long; my backlog is taking longer to clear than planned. There are a few substantitve comments mixed in with the nits -- the IANA Considerations in particular will probably need a bit more attention to get fleshed out with what we need. Anyway, here are the section-by-section notes. Abstract The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example nit: singular/plural mismatch "possibility"/"pose". maybe-nit: s/cryptography/cryptographic/? Section 1 It is an open question whether or not it is feasible to build a Quantum Computer (and if so, when one might be implemented), but if Feasibility of some quantum computer is becoming much less of an open question; perhaps we want some qualifiers about efficiency, scale, and/or general-purpose-nature. would be compromised. IKEv1 [RFC2409], when used with strong preshared keys, is not vulnerable to quantum attacks, because those keys are one of the inputs to the key derivation function. If the preshared key has sufficient entropy and the PRF, encryption and authentication transforms are postquantum secure, then the resulting system is believed to be quantum resistant, that is, invulnerable to an attacker with a Quantum Computer. Do we have a reference for this "it is believed", or is it just the outcome of the WG discussions? The general idea is that we add an additional secret that is shared between the initiator and the responder; this secret is in addition to the authentication method that is already provided within IKEv2. We stir this secret into the SK_d value, which is used to generate the key material (KEYMAT) and the SKEYSEED for the child SAs; this secret provides quantum resistance to the IPsec SAs (and any child IKE SAs). We also stir the secret into the SK_pi, SK_pr values; this allows both sides to detect a secret mismatch cleanly. With apologies for the pedanticism, let's be careful what wording we use, as just mixing into SK_d is not necessarily enough to get quantum resitsance for the parent IPsec SA. [need to check this some more] Section 1.2 Every directorate reviewer and IESG member is going to suggest that we use the RFC 8174 version of the boilerplate, if we don't preemptively do so :) Section 2 We assume that each IKE peer has a list of Postquantum Preshared Keys (PPK) along with their identifiers (PPK_ID), and any potential IKE initiator has a selection of which PPK to use with any specific responder. In addition, implementations have a configurable flag nit: I'm not sure what "has a selection of" is intended to mean. Is it more about making a choice of which PPK to use or about having a list to choose from? This PPK is independent of the preshared key (if any) that the IKEv2 I expect us to get a few questions about why we need a separate PPK in cases when an authentication psk is also available; a short note here might forestall such questions. (It's needed because PSK for auth does not feed into any of the other key derivations, right?) protocol uses to perform authentication. The PPK specific configuration that is assumed on each peer consists of the following tuple: Peer, PPK, PPK_ID, mandatory_or_not nit: we use "peer" twice here, and the context suggests that they refer to different parties in the different places. Section 3 N(USE_PPK) is a status notification payload with the type 16435; it has a protocol ID of 0, no SPI and no notification data associated with it. [check the IANA status of the value] If the responder does not support this specification or does not have any PPK configured, then she ignores the received notification and continues with the IKEv2 protocol as normal. Otherwise the responder checks if she has a PPK configured, and if she does, then the nit: we probably don't need to mention "if [...] PPK configured" twice. responder included the USE_PPK notification. If the responder did not and the flag mandatory_or_not indicates that using PPKs is mandatory for communication with this responder, then the initiator MUST abort the exchange. This situation may happen in case of We might get some directorate questions about what it means to "abort the exchange"; I note that RFC 7296 does not use that terminology, though I'm perfectly happy to leave this as-is and see if we get any ADs that are concerned about it. If the responder did not include the USE_PPK notification and using a PPK for this particular responder is optional, then the initiator continues with the IKEv2 protocol as normal, without using PPKs. Do we want to say anything about logging or notifications for this case, in case someone is concerned about the level of quantum-resistance in use? If the responder did include the USE_PPK notification, then the initiator selects a PPK, along with its identifier PPK_ID. Then, she computes this modification of the standard IKEv2 key derivation: Just to double-check: the responder's USE_PPK is just a boolean "I'm willing to do PPK", right? So we don't really hae a signal as to which PPK_IDs the peer thinks are valid? That is, we use the standard IKEv2 key derivation process except that the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again, this time using the PPK as the key. Using prf+ construction ensures Do we want to say anything about why only these three values need the PPK mixed in to them? (I guess the idea is that the parent SA is "short-lived" on the timescale of a quantum computer and the messages protected directly by it are not of interest to an attacker years in the future. This does mean that this scheme does not provide much value when a quantum computer is available at the time of the exchange, though, right? If the PPK_IDENTITY notification contains PPK_ID that is not known to nit: "a PPK_ID" the responder or is not configured for use for the identity from IDi payload, then the responder checks whether using PPKs for this initiator is mandatory and whether the initiator included NO_PPK_AUTH notification in the message. If using PPKs is mandatory or no NO_PPK_AUTH notification found, then then the responder MUST send nit: "is found" The responder then continues with the IKE_AUTH exchange (validating the AUTH payload that the initiator included) as usual and sends back a response, which includes the PPK_IDENTITY notification with no data to indicate that the PPK is used in the exchange: Why does the responder not need to transmit an explicit PPK_ID? (I see that the following paragraph says that the initiatore MUST ignore any content to that notification, but why?) not yet known to the responder. Once the IKE_AUTH request message containing PPK_IDENTITY notification is received, the responder follows rules described above for non-EAP authentication case. nits: (missing "the"s) "the PPK_IDENTITY notification", "the rules described above", "the non-EAP authentication case" Initiator Responder ---------------------------------------------------------------- HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP} HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH, N(PPK_IDENTITY, PPK_ID) [, N(NO_PPK_AUTH)]} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr [, N(PPK_IDENTITY)]} Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as optional here in the EAP case but not in the previous diagram for the non-EAP case? Section 4 With this configuration, the node will continue to operate with nodes that have not yet been upgraded. This is due to the USE_PPK notify and the NO_PPK_AUTH notify; if the initiator has not been upgraded, he will not send the USE_PPK notify (and so the responder will know nit: I think we should be consistent about using either "notification" or "Notify payload"/"Notify message", avoiding just the bare "notify". (Also occurs in subsequent locations that I won't quote/mention individually.) NO_PPK_AUTH notification. If both the responder and initiator have been upgraded and properly configured, they will both realize it, and in that case, the link will be quantum secure. I think that "the link will be quantum secure" is probably overselling things a little bit; for one, the confidentiality protection we provide is only for the child SAs, and the discussion earlier in the document is about providing protection for current connections against future development of a quantum computer, while most people probably think of full "quantum secure" as being protection even against a current quantum computer. As an optional second step, after all nodes have been upgraded, then the administrator should then go back through the nodes, and mark the use of PPK as mandatory. This will not affect the strength against a passive attacker; it would mean that an attacker with a Quantum Computer (which is sufficiently fast to be able to break the (EC)DH in real time) would not be able to perform a downgrade attack. It seems like (given the current lack of advice for logging/reporting, as noted above) changing the use of PPK to mandatory also serves to provide notification if any future misconfiguration changes regarding the use of PPK, to give a more robust indication of when the desired protection is not being applied. Section 5.1 initiator and the responder. The responder can use to do a look up the passed PPK_ID value to determine the corresponding PPK value. Not all implementations are able to configure arbitrary nit: this sentence is hard to follow; I suggest % The responder can use the PPK_ID to look up the corresponding PPK % value. value. Not all implementations are able to configure arbitrary octet strings; to improve the potential interoperability, it is recommended that, in the PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 characters 0-9, A-Z, a-z, + and /. I don't have much experience with the conventions in this space; does it make sense to distinguish between the PPK representation as configured (which would use the base64 alphabet) and the "actual PPK" that could be binary after, e.g., a base64-decoding step? I guess it could be reasonable to rely on the ability of the PRF to take an arbitrary-length input and just have sufficient entropy even while limiting the PPK value to the base64 alphabet. The PPK_ID type value 0 is reserved; values 3-127 are reserved for IANA; values 128-255 are for private use among mutually consenting parties. I guess that anything done in the 128-255 range could also be done under the PPK_ID_OPAQUE space (at the cost of an extra octet), but I don't object to this breakdown. Section 5.2.1 I'm kind of confused by the PSKC reference, especially the implication ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the PIN") that a fixed string is to be used as a PIN. (I also think it's better to discuss what it does as "key transport" than "key exchange", noting that the latter string does not appear in RFC 6030.) Section 5.2.2 It is possible to use a single PPK for a group of users. Since each peer uses classical public key cryptography in addition to PPK for key exchange and authentication, members of the group can neither impersonate each other nor read other's traffic, unless they use Quantum Computers to break public key operations. However group members can record other members' traffic and decrypt it later, when they get access to a Quantum Computer. nit: I suggest "can record any traffic they have access to that comes from other group members and decrypt it later", since just being a group member does not grant one a universal network tap. In addition, the fact that the PPK is known to a (potentially large) group of users makes it more susceptible to theft. When an attacker equipped with a Quantum Computer got access to a group PPK, all communications inside the group are revealed. nit: s/got/gets/ Section 5.2.3 PPK-only authentication can be achieved in IKEv2 if NULL Authentication method [RFC7619] is employed. Without PPK the NULL nit: "the NULL Authentication method" (the next/trimmed sentence gets it right already). Section 6 We should document the privacy considerations of the PPK_ID both in the face of an attacker with a quantum computer (now or in the future) and in the face of a classical attacker. The latter would, IIUC, need to be an active MITM in order to see anything other than N(USE_PPK), and who would also get IDi along with the PPK_ID value, so there's not much of a change in the privacy stance. Quantum computers are able to perform Grover's algorithm; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the postquantum preshared key used has at least 256 bits of entropy, in order to provide 128-bit security level. nit: missing article (maybe "provide a 128-bit security level"?) Section 3 requires the initiator to abort the initial exchange if using PPKs is mandatory for it, but the responder might not include the USE_PPK notification in the response. In this situation when the nit: I suggest s/, but the responder might not include/but the responder does not include/ initiator aborts negotiation he leaves half-open IKE SA on the responder (because IKE_SA_INIT completes successfully from the responder's point of view). This half-open SA will eventually expire nits: comma after "In this situation", and s/half-open/a half-open/ [RFC8019] for more detail). It is RECOMMENDED that implementations in this situation cache the negative result of negotiation for some time and don't make attempts to create it again for some time, because this is a result of misconfiguration and probably some re- configuration of the peers is needed. Is this "implementations" as initiators, responders, or both? removing USE_PPK notification from the IKE_SA_INIT and forging digital signatures in the subsequent exchange. If using PPKs is mandatory for at least one of the peers or PSK is used for authentication, then the attack will be detected and the SA won't be created. side note(?): Up in Section 5.2.3 we talk about PPK-only authentication, but here we talk about PSK authentication. I believe those are distinct things (and thus that there's nothing to change in the text), but am checking just to be sure. If using PPKs is mandatory for the initiator, then an attacker capable to eavesdrop and to inject packets into the network can prevent creating IKE SA by mounting the following attack. The attacker intercepts the initial request containing the USE_PPK notification and injects the forget response containing no USE_PPK. nits: s/capable to/able to/, s/creating IKE SA/creating an IKE SA/, s/the forget response/a forged response/ (note both the->a and t->d in the last one). If the attacker manages to inject this packet before the responder sends a genuine response, then the initiator would abort the exchange. To thwart this kind of attack it is RECOMMENDED, that if using PPKs is mandatory for the initiator and the received response doesn't contain the USE_PPK notification, then the initiator doesn't abort the exchange immediately, but instead waits some time for more responses (possibly retransmitting the request). If all the received I expect that some reviewer is going to note that this recommendation only occurs in the security considerations section and suggest moving it to the body of the document, and also that we will be asked to give more concrete guidance about "some time". I don't think either change is critical to make, but consider yourself forewarned... Section 7 We should have a registration template for what information new registration requests should include. (In particular, since we allow changing entries, a "change controller" and contact information will be needed.) I suggest including a column for "reference to specification (if available)", even though the "Expert Review" policy does not strictly require one. We could also provide some guidance to the DEs as to what criteria they may or may not want to apply in deciding whether to approve or reject a registration request. Appendix A The idea behind this document is that while a Quantum Computer can easily reconstruct the shared secret of an (EC)DH exchange, they cannot as easily recover a secret from a symmetric exchange. This makes the SK_d, and hence the IPsec KEYMAT and any child SA's SKEYSEED, depend on both the symmetric PPK, and also the Diffie- Hellman exchange. If we assume that the attacker knows everything nit: I think we need to say "This document [makes the SK_D...]", since otherwise the pronoun seems to refer back to the property of the QC. O(2^(n/2)) time to recover the PPK. So, even if the (EC)DH can be trivially solved, the attacker still can't recover any key material (except for the SK_ei, SK_er, SK_ai, SK_ar values for the initial IKE exchange) unless they can find the PPK, which is too difficult if the PPK has enough entropy (for example, 256 bits). Note that we do nit: closing "and" for the list of SK_* values. Another goal of this protocol is to minimize the number of changes within the IKEv2 protocol, and in particular, within the cryptography of IKEv2. By limiting our changes to notifications, and adjusting the SK_d, SK_pi, SK_pr, it is hoped that this would be implementable, even on systems that perform most of the IKEv2 processing in hardware. nit: I suggest s/adjusting/only adjusting/ A fourth goal was to avoid violating any of the security goals of IKEv2. nit: It is sometimes considered good style to avoid using the same word too much in close succession (here, "goal"); would it change the meaning to say "the security properties provided by IKEv2"? Thanks, Ben From nobody Mon Nov 4 19:39:58 2019 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 0CDEB12003F; Mon, 4 Nov 2019 19:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-sDThe3r2oW; Mon, 4 Nov 2019 19:39: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 47A03120020; Mon, 4 Nov 2019 19:39:53 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 476b5L30yxz398; Tue, 5 Nov 2019 04:39:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572925190; bh=0KTCHzKSh8aILH71LqSm61Ywi3RI/iXj0IzA/0nT6JQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tcNOiqyJn+n1u7NNOiRFHow+Rj/r9PzYG76AS9ypH7bUp5AqCaKPGwkhbxQIT2TGs iZd3nQxqPMeHT+6tzK5KJeFMh3QoIE9JQnIzvsSW8qb5YNVYbl8fgf4X+X3pRipL8J PrwPPcY42oT32/QgRlHYSQsdD1uM3kHNZipAo2GI= 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 T1Kj9cY6q2Ue; Tue, 5 Nov 2019 04:39:47 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 5 Nov 2019 04:39:47 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 51B2E6007C4D; Mon, 4 Nov 2019 22:39:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4DFC323D09D; Mon, 4 Nov 2019 22:39:46 -0500 (EST) Date: Mon, 4 Nov 2019 22:39:46 -0500 (EST) From: Paul Wouters To: Benjamin Kaduk cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org, ipsec@ietf.org In-Reply-To: <20191105023831.GH55993@kduck.mit.edu> Message-ID: References: <20191105023831.GH55993@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 03:39:57 -0000 On Mon, 4 Nov 2019, Benjamin Kaduk wrote: [ignoring the nits and leaving that to the authors, although reading it again I would like to see "he" and "she" replaced by "it" everwhere] > It is an open question whether or not it is feasible to build a > Quantum Computer (and if so, when one might be implemented), but if > > Feasibility of some quantum computer is becoming much less of an open > question; perhaps we want some qualifiers about efficiency, scale, > and/or general-purpose-nature. It all depends on the algorithms these machines support as well as their key size. It's hard to read the the quantum marketing to know what to believe :) > would be compromised. IKEv1 [RFC2409], when used with strong > preshared keys, is not vulnerable to quantum attacks, because those > keys are one of the inputs to the key derivation function. If the > preshared key has sufficient entropy and the PRF, encryption and > authentication transforms are postquantum secure, then the resulting > system is believed to be quantum resistant, that is, invulnerable to > an attacker with a Quantum Computer. > > Do we have a reference for this "it is believed", or is it just the > outcome of the WG discussions? These are one-way functions with unknown input. There is no way to reverse that using any known quantum algorithm. > The general idea is that we add an additional secret that is shared > between the initiator and the responder; this secret is in addition > to the authentication method that is already provided within IKEv2. > We stir this secret into the SK_d value, which is used to generate > the key material (KEYMAT) and the SKEYSEED for the child SAs; this > secret provides quantum resistance to the IPsec SAs (and any child > IKE SAs). We also stir the secret into the SK_pi, SK_pr values; this > allows both sides to detect a secret mismatch cleanly. > > With apologies for the pedanticism, let's be careful what wording we > use, as just mixing into SK_d is not necessarily enough to get quantum > resitsance for the parent IPsec SA. > [need to check this some more] It is not, but none of the above thanks about the Parent SA. It only talks about the Child SA (AKA IPsec SA) > Every directorate reviewer and IESG member is going to suggest that we > use the RFC 8174 version of the boilerplate, if we don't preemptively do > so :) To be fair, I had to check the publication date of 8174 to see which was older - the RFC of the latest version of this draft waiting for the AD :) > This PPK is independent of the preshared key (if any) that the IKEv2 > > I expect us to get a few questions about why we need a separate PPK in > cases when an authentication psk is also available; a short note here > might forestall such questions. (It's needed because PSK for auth does > not feed into any of the other key derivations, right?) Correct, the PSK is only used in the AUTH payload calculation. In IKEv1, it was also mixed into the SKEYSEED, and so a mismatched PSK lead to a garbled unreadable IKE packet which was not nice for administrators to debug. In IKEv2 this was changed so we can provide proper error messages on a wrong PSK. But we did lose the post-quantum protection. > N(USE_PPK) is a status notification payload with the type 16435; it > has a protocol ID of 0, no SPI and no notification data associated > with it. > > [check the IANA status of the value] Those values have been used already for interoperability tests between libreswan, strongswan, elvis+, cisco and apple :) > responder included the USE_PPK notification. If the responder did > not and the flag mandatory_or_not indicates that using PPKs is > mandatory for communication with this responder, then the initiator > MUST abort the exchange. This situation may happen in case of > > We might get some directorate questions about what it means to "abort > the exchange"; I note that RFC 7296 does not use that terminology, > though I'm perfectly happy to leave this as-is and see if we get any ADs > that are concerned about it. It could be rephased as "abort the exchange by sending an AUTHENTICATION_FAILED error notify message back to the initiator". > If the responder did not include the USE_PPK notification and using a > PPK for this particular responder is optional, then the initiator > continues with the IKEv2 protocol as normal, without using PPKs. > > Do we want to say anything about logging or notifications for this case, > in case someone is concerned about the level of quantum-resistance in > use? That could be done. I just checked our implementation, and we seem to not be tracking informational notifies, only error notifies (as can be seen here: https://vpn.nohats.ca/munin/vpn-month.html on a test server) and indeed we should add it to our implementation. And having a line of text here would have cause implementors to do so :) > If the responder did include the USE_PPK notification, then the > initiator selects a PPK, along with its identifier PPK_ID. Then, she > computes this modification of the standard IKEv2 key derivation: > > Just to double-check: the responder's USE_PPK is just a boolean "I'm > willing to do PPK", right? So we don't really hae a signal as to which > PPK_IDs the peer thinks are valid? Right. You would not want to tell an unauthenticated peer which IDs are valid. In the case of a remote access VPN, you would have too many valid IDs to share. Also in case of using ephemeral or pseudo-random IDs, you couldn't have a complete list of these. > That is, we use the standard IKEv2 key derivation process except that > the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again, > this time using the PPK as the key. Using prf+ construction ensures > > Do we want to say anything about why only these three values need the > PPK mixed in to them? (I guess the idea is that the parent SA is > "short-lived" on the timescale of a quantum computer and the messages > protected directly by it are not of interest to an attacker years in the > future. This does mean that this scheme does not provide much value > when a quantum computer is available at the time of the exchange, > though, right? Practically all information that is in the parent can be learned by an active attacker that has no valid credentials, that MITMs a connection. The exception to this are the traffic selectors of the IPsec SA. Additionally, if you care about this, you can first establish a childless Parent SA, then do a Parent SA rekey that uses the PPK, and only when you are quantum-safe, do a create_child_sa for the IPsec SA. That way, no traffic selectors are available even if the initial Parent SA is compromised by a quantum computer. Similarly, if you believe a quantum computer would be fast enough to do real time attacks on the Parent SA, this trick prevents someone with such a quantum computer from sending valid IKE packets. Although even there, the damage that can be done is very limited - send a keepalive probe, a delete request, or a rekey or create request. Note that a compromised Parent SA does _not_ lead to compromised Child SA (IPsec SA) because the PPK is not known to the attacker even after cracking the Parent SA encryption. > The responder then continues with the IKE_AUTH exchange (validating > the AUTH payload that the initiator included) as usual and sends back > a response, which includes the PPK_IDENTITY notification with no data > to indicate that the PPK is used in the exchange: > > Why does the responder not need to transmit an explicit PPK_ID? (I see > that the following paragraph says that the initiatore MUST ignore any > content to that notification, but why?) The identity of the responder is always known to the initiator. It is the responder they set out to reach. They already know which PPK to use with that. The responder however, might not know which of the many valid initiators out there is trying to reach them, so they need to be told. > Initiator Responder > ---------------------------------------------------------------- > HDR, SK {IDi, [CERTREQ,] > [IDr,] SAi2, > TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP} > HDR, SK {EAP} --> > <-- HDR, SK {EAP (success)} > HDR, SK {AUTH, > N(PPK_IDENTITY, PPK_ID) > [, N(NO_PPK_AUTH)]} --> > <-- HDR, SK {AUTH, SAr2, TSi, TSr > [, N(PPK_IDENTITY)]} > > Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as > optional here in the EAP case but not in the previous diagram for the > non-EAP case? You found a real bug :) > > NO_PPK_AUTH notification. If both the responder and initiator have > been upgraded and properly configured, they will both realize it, and > in that case, the link will be quantum secure. > > I think that "the link will be quantum secure" is probably overselling > things a little bit; for one, the confidentiality protection we provide > is only for the child SAs, and the discussion earlier in the document is > about providing protection for current connections against future > development of a quantum computer, while most people probably think of > full "quantum secure" as being protection even against a current quantum > computer. Instead of the "link", it should probably talk about the IPsec SA being quantum secure. A disclaimer like "based on current academic knowledge" could be added :P > value. Not all implementations are able to configure arbitrary > octet strings; to improve the potential interoperability, it is > recommended that, in the PPK_ID_FIXED case, both the PPK and the > PPK_ID strings be limited to the base64 character set, namely the > 64 characters 0-9, A-Z, a-z, + and /. > > I don't have much experience with the conventions in this space; does it > make sense to distinguish between the PPK representation as configured > (which would use the base64 alphabet) and the "actual PPK" that could be > binary after, e.g., a base64-decoding step? I guess it could be > reasonable to rely on the ability of the PRF to take an arbitrary-length > input and just have sufficient entropy even while limiting the PPK value > to the base64 alphabet. Based on operational experience, anything not following the above will run into interoperability problems. Often people cannot even input a hex PSK, so we felt it better to just avoid the PSK issues we know about with the new PPK. Similarly, ID_KEY_ID is an ID type that is mostly useless in IKE because it is configured differently on each implementation. > The PPK_ID type value 0 is reserved; values 3-127 are reserved for > IANA; values 128-255 are for private use among mutually consenting > parties. > > I guess that anything done in the 128-255 range could also be done under > the PPK_ID_OPAQUE space (at the cost of an extra octet), but I don't > object to this breakdown. Yes. It was mostly done because implementers like something easy to compare, and do not like "sub-typing" :) > Section 5.2.1 > > I'm kind of confused by the PSKC reference, especially the implication > ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the > PIN") that a fixed string is to be used as a PIN. (I also think it's > better to discuss what it does as "key transport" than "key exchange", > noting that the latter string does not appear in RFC 6030.) I'm pretty confused about that too actually. > Section 6 > > We should document the privacy considerations of the PPK_ID both in the > face of an attacker with a quantum computer (now or in the future) and > in the face of a classical attacker. The latter would, IIUC, need to be > an active MITM in order to see anything other than N(USE_PPK), and who > would also get IDi along with the PPK_ID value, so there's not much of a > change in the privacy stance. I don't think the attack differs whether you have a quantum computer or not. Just by relaying as MITM, you can learn IDs. It is inevitable. > > [RFC8019] for more detail). It is RECOMMENDED that implementations > in this situation cache the negative result of negotiation for some > time and don't make attempts to create it again for some time, > because this is a result of misconfiguration and probably some re- > configuration of the peers is needed. > > Is this "implementations" as initiators, responders, or both? Initiators. In IKEv2, responders always only respond once per received initiator packet. > removing USE_PPK notification from the IKE_SA_INIT and forging > digital signatures in the subsequent exchange. If using PPKs is > mandatory for at least one of the peers or PSK is used for > authentication, then the attack will be detected and the SA won't be > created. > > side note(?): Up in Section 5.2.3 we talk about PPK-only authentication, > but here we talk about PSK authentication. I believe those are distinct > things (and thus that there's nothing to change in the text), but am > checking just to be sure. Yes there are distinct things. > If the attacker manages to inject this packet before the responder > sends a genuine response, then the initiator would abort the > exchange. To thwart this kind of attack it is RECOMMENDED, that if > using PPKs is mandatory for the initiator and the received response > doesn't contain the USE_PPK notification, then the initiator doesn't > abort the exchange immediately, but instead waits some time for more > responses (possibly retransmitting the request). If all the received > > I expect that some reviewer is going to note that this recommendation > only occurs in the security considerations section and suggest moving it > to the body of the document, and also that we will be asked to give more > concrete guidance about "some time". I don't think either change is > critical to make, but consider yourself forewarned... Sounds fair. Timing advise would be similar to how long the implemention keeps half-open SA's around in general. > Section 7 > > We should have a registration template for what information new > registration requests should include. (In particular, since we allow > changing entries, a "change controller" and contact information will be > needed.) I suggest including a column for "reference to specification > (if available)", even though the "Expert Review" policy does not > strictly require one. We could also provide some guidance to the DEs as > to what criteria they may or may not want to apply in deciding whether > to approve or reject a registration request. Sounds fair. Paul From nobody Mon Nov 4 19:50:19 2019 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 BC236120071 for ; Mon, 4 Nov 2019 19:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttNL9OIzQ_C5 for ; Mon, 4 Nov 2019 19:50:16 -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 548DB12002F for ; Mon, 4 Nov 2019 19:50:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 476bKM0LlBz3D7; Tue, 5 Nov 2019 04:50:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572925815; bh=BXAhjqnIApUtLYvTiS2Jeo3G5Ac0Fba74y6/nGPhbJI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cGV8XzjbpFAJKi+aj64/WpHf3/vUVISDkyeCjwWcjIz+dygDpT70tK1otACVVlAcX kJZB9wO/4g4OHDTkrUapn+q9NzEHyr1oRAjl6vQvEI4W99OkGlrUg6q39OHPF70BTX w3sBEY/z0iPPcUAhvBrvAjiyuIQzKtCw+vgdbwgw= 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 2ZK4e88ioY5R; Tue, 5 Nov 2019 04:50:14 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 5 Nov 2019 04:50:14 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 01D7B6007C4D; Mon, 4 Nov 2019 22:50:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 00CDB23D09D; Mon, 4 Nov 2019 22:50:12 -0500 (EST) Date: Mon, 4 Nov 2019 22:50:12 -0500 (EST) From: Paul Wouters To: "Panwei (William)" cc: "ipsec@ietf.org" In-Reply-To: <41dd4078faf7438ca0051968486b65a6@huawei.com> Message-ID: References: <157286141508.16609.5825213440537485887@ietfa.amsl.com> <41dd4078faf7438ca0051968486b65a6@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 03:50:18 -0000 On Tue, 5 Nov 2019, Panwei (William) wrote: > I've updated the IKEv2 rekeying optimization draft. > In the new version, IKE SAs rekeying optimization is optional now. It's up to the implementer to optimize the IKE SAs rekeying or not. > And the optimization processes are also simplified to two cases (before was three cases): > - The initiator sends the optimized rekeying request message, the responder accepts it and replies the optimized rekeying response message. > - The initiator sends the optimized rekeying request message, the responder refuses it and replies NO_PROPOASL_CHOSEN. Great! I will read it and maybe try to implement this during the hackathon. Paul From nobody Tue Nov 5 01:47:45 2019 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 48694120863; Tue, 5 Nov 2019 01:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 1U0_UIG1_5lc; Tue, 5 Nov 2019 01:47:40 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2494D120137; Tue, 5 Nov 2019 01:47:39 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA59lZ4G032560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Nov 2019 04:47:37 -0500 Date: Tue, 5 Nov 2019 01:47:34 -0800 From: Benjamin Kaduk To: Paul Wouters Cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org, ipsec@ietf.org Message-ID: <20191105094734.GB61969@kduck.mit.edu> References: <20191105023831.GH55993@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 09:47:43 -0000 On Mon, Nov 04, 2019 at 10:39:46PM -0500, Paul Wouters wrote: > On Mon, 4 Nov 2019, Benjamin Kaduk wrote: > > [ignoring the nits and leaving that to the authors, although reading it > again I would like to see "he" and "she" replaced by "it" everwhere] Thanks for chiming in (and quickly)! I think the "he"/"she" thing has come up recently in another context, and was left to author discretion, but perhaps there is a broader conversation to have. > > It is an open question whether or not it is feasible to build a > > Quantum Computer (and if so, when one might be implemented), but if > > > > Feasibility of some quantum computer is becoming much less of an open > > question; perhaps we want some qualifiers about efficiency, scale, > > and/or general-purpose-nature. > > It all depends on the algorithms these machines support as well as their > key size. It's hard to read the the quantum marketing to know what to > believe :) Indeed :) > > would be compromised. IKEv1 [RFC2409], when used with strong > > preshared keys, is not vulnerable to quantum attacks, because those > > keys are one of the inputs to the key derivation function. If the > > preshared key has sufficient entropy and the PRF, encryption and > > authentication transforms are postquantum secure, then the resulting > > system is believed to be quantum resistant, that is, invulnerable to > > an attacker with a Quantum Computer. > > > > Do we have a reference for this "it is believed", or is it just the > > outcome of the WG discussions? > > These are one-way functions with unknown input. There is no way to > reverse that using any known quantum algorithm. > > > The general idea is that we add an additional secret that is shared > > between the initiator and the responder; this secret is in addition > > to the authentication method that is already provided within IKEv2. > > We stir this secret into the SK_d value, which is used to generate > > the key material (KEYMAT) and the SKEYSEED for the child SAs; this > > secret provides quantum resistance to the IPsec SAs (and any child > > IKE SAs). We also stir the secret into the SK_pi, SK_pr values; this > > allows both sides to detect a secret mismatch cleanly. > > > > With apologies for the pedanticism, let's be careful what wording we > > use, as just mixing into SK_d is not necessarily enough to get quantum > > resitsance for the parent IPsec SA. > > [need to check this some more] > > It is not, but none of the above thanks about the Parent SA. It only > talks about the Child SA (AKA IPsec SA) Whoops, the square brackets were notes to myself that escaped prematurely (I had a long interruption mid-review of this one, which presumably made me forget they were there.) I think I'm just complaining about "this secret provides quantum resistance to the IPsec SAs". Perhaps I'm not parting the terminology properly, but I thought that meant (or included?) the parent SA. > > Every directorate reviewer and IESG member is going to suggest that we > > use the RFC 8174 version of the boilerplate, if we don't preemptively do > > so :) > > To be fair, I had to check the publication date of 8174 to see which was > older - the RFC of the latest version of this draft waiting for the AD :) I think the line "it's funny because it's true" comes to mind. I am trying to do better. > > This PPK is independent of the preshared key (if any) that the IKEv2 > > > > I expect us to get a few questions about why we need a separate PPK in > > cases when an authentication psk is also available; a short note here > > might forestall such questions. (It's needed because PSK for auth does > > not feed into any of the other key derivations, right?) > > Correct, the PSK is only used in the AUTH payload calculation. In IKEv1, it > was also mixed into the SKEYSEED, and so a mismatched PSK lead to a > garbled unreadable IKE packet which was not nice for administrators to > debug. In IKEv2 this was changed so we can provide proper error messages > on a wrong PSK. But we did lose the post-quantum protection. > > > N(USE_PPK) is a status notification payload with the type 16435; it > > has a protocol ID of 0, no SPI and no notification data associated > > with it. > > > > [check the IANA status of the value] > > Those values have been used already for interoperability tests between > libreswan, strongswan, elvis+, cisco and apple :) Cool! I had just left a note to myself to check that the specific value is in fact allocated, so we don't write a document that "squats" on a codepoint. I even did the check before I sent the review; I just failed to remove this note to myself! > > responder included the USE_PPK notification. If the responder did > > not and the flag mandatory_or_not indicates that using PPKs is > > mandatory for communication with this responder, then the initiator > > MUST abort the exchange. This situation may happen in case of > > > > We might get some directorate questions about what it means to "abort > > the exchange"; I note that RFC 7296 does not use that terminology, > > though I'm perfectly happy to leave this as-is and see if we get any ADs > > that are concerned about it. > > It could be rephased as "abort the exchange by sending an AUTHENTICATION_FAILED > error notify message back to the initiator". > > > If the responder did not include the USE_PPK notification and using a > > PPK for this particular responder is optional, then the initiator > > continues with the IKEv2 protocol as normal, without using PPKs. > > > > Do we want to say anything about logging or notifications for this case, > > in case someone is concerned about the level of quantum-resistance in > > use? > > That could be done. I just checked our implementation, and we seem to > not be tracking informational notifies, only error notifies (as can be > seen here: https://vpn.nohats.ca/munin/vpn-month.html on a test server) > and indeed we should add it to our implementation. And having a line of > text here would have cause implementors to do so :) > > > If the responder did include the USE_PPK notification, then the > > initiator selects a PPK, along with its identifier PPK_ID. Then, she > > computes this modification of the standard IKEv2 key derivation: > > > > Just to double-check: the responder's USE_PPK is just a boolean "I'm > > willing to do PPK", right? So we don't really hae a signal as to which > > PPK_IDs the peer thinks are valid? > > Right. You would not want to tell an unauthenticated peer which IDs are > valid. In the case of a remote access VPN, you would have too many valid > IDs to share. Also in case of using ephemeral or pseudo-random IDs, you > couldn't have a complete list of these. > > > That is, we use the standard IKEv2 key derivation process except that > > the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again, > > this time using the PPK as the key. Using prf+ construction ensures > > > > Do we want to say anything about why only these three values need the > > PPK mixed in to them? (I guess the idea is that the parent SA is > > "short-lived" on the timescale of a quantum computer and the messages > > protected directly by it are not of interest to an attacker years in the > > future. This does mean that this scheme does not provide much value > > when a quantum computer is available at the time of the exchange, > > though, right? > > Practically all information that is in the parent can be learned by an > active attacker that has no valid credentials, that MITMs a connection. > The exception to this are the traffic selectors of the IPsec SA. > > Additionally, if you care about this, you can first establish a > childless Parent SA, then do a Parent SA rekey that uses the PPK, and > only when you are quantum-safe, do a create_child_sa for the IPsec SA. > That way, no traffic selectors are available even if the initial Parent > SA is compromised by a quantum computer. Similarly, if you believe a > quantum computer would be fast enough to do real time attacks on the > Parent SA, this trick prevents someone with such a quantum computer from > sending valid IKE packets. Although even there, the damage that can be > done is very limited - send a keepalive probe, a delete request, or a > rekey or create request. Note that a compromised Parent SA does _not_ > lead to compromised Child SA (IPsec SA) because the PPK is not known > to the attacker even after cracking the Parent SA encryption. Thanks for the extra discussion (which confirms my understanding of things). It is sounding like more text is not really going to be needed here, then. > > > The responder then continues with the IKE_AUTH exchange (validating > > the AUTH payload that the initiator included) as usual and sends back > > a response, which includes the PPK_IDENTITY notification with no data > > to indicate that the PPK is used in the exchange: > > > > Why does the responder not need to transmit an explicit PPK_ID? (I see > > that the following paragraph says that the initiatore MUST ignore any > > content to that notification, but why?) > > The identity of the responder is always known to the initiator. It is > the responder they set out to reach. They already know which PPK to > use with that. The responder however, might not know which of the many > valid initiators out there is trying to reach them, so they need to be > told. Sure ... I'm mostly coming at this from the perspective of the generic class of (identity) misbinding, that leads us to have each party sign the other's nonce, etc.. I don't have a concrete attack in this case (and one seems like it would probably require a misbehaving peer?), so it was just a question on general principles. > > Initiator Responder > > ---------------------------------------------------------------- > > HDR, SK {IDi, [CERTREQ,] > > [IDr,] SAi2, > > TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > > EAP} > > HDR, SK {EAP} --> > > <-- HDR, SK {EAP (success)} > > HDR, SK {AUTH, > > N(PPK_IDENTITY, PPK_ID) > > [, N(NO_PPK_AUTH)]} --> > > <-- HDR, SK {AUTH, SAr2, TSi, TSr > > [, N(PPK_IDENTITY)]} > > > > Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as > > optional here in the EAP case but not in the previous diagram for the > > non-EAP case? > > You found a real bug :) (Which version is correct?) > > > > NO_PPK_AUTH notification. If both the responder and initiator have > > been upgraded and properly configured, they will both realize it, and > > in that case, the link will be quantum secure. > > > > I think that "the link will be quantum secure" is probably overselling > > things a little bit; for one, the confidentiality protection we provide > > is only for the child SAs, and the discussion earlier in the document is > > about providing protection for current connections against future > > development of a quantum computer, while most people probably think of > > full "quantum secure" as being protection even against a current quantum > > computer. > > Instead of the "link", it should probably talk about the IPsec SA being > quantum secure. A disclaimer like "based on current academic knowledge" > could be added :P I won't insist on the extra disclaimer :) > > value. Not all implementations are able to configure arbitrary > > octet strings; to improve the potential interoperability, it is > > recommended that, in the PPK_ID_FIXED case, both the PPK and the > > PPK_ID strings be limited to the base64 character set, namely the > > 64 characters 0-9, A-Z, a-z, + and /. > > > > I don't have much experience with the conventions in this space; does it > > make sense to distinguish between the PPK representation as configured > > (which would use the base64 alphabet) and the "actual PPK" that could be > > binary after, e.g., a base64-decoding step? I guess it could be > > reasonable to rely on the ability of the PRF to take an arbitrary-length > > input and just have sufficient entropy even while limiting the PPK value > > to the base64 alphabet. > > Based on operational experience, anything not following the above will > run into interoperability problems. Often people cannot even input a hex > PSK, so we felt it better to just avoid the PSK issues we know about > with the new PPK. Similarly, ID_KEY_ID is an ID type that is mostly > useless in IKE because it is configured differently on each > implementation. > > > The PPK_ID type value 0 is reserved; values 3-127 are reserved for > > IANA; values 128-255 are for private use among mutually consenting > > parties. > > > > I guess that anything done in the 128-255 range could also be done under > > the PPK_ID_OPAQUE space (at the cost of an extra octet), but I don't > > object to this breakdown. > > Yes. It was mostly done because implementers like something easy to > compare, and do not like "sub-typing" :) > > > Section 5.2.1 > > > > I'm kind of confused by the PSKC reference, especially the implication > > ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the > > PIN") that a fixed string is to be used as a PIN. (I also think it's > > better to discuss what it does as "key transport" than "key exchange", > > noting that the latter string does not appear in RFC 6030.) > > I'm pretty confused about that too actually. > > > Section 6 > > > > We should document the privacy considerations of the PPK_ID both in the > > face of an attacker with a quantum computer (now or in the future) and > > in the face of a classical attacker. The latter would, IIUC, need to be > > an active MITM in order to see anything other than N(USE_PPK), and who > > would also get IDi along with the PPK_ID value, so there's not much of a > > change in the privacy stance. > > I don't think the attack differs whether you have a quantum computer or > not. Just by relaying as MITM, you can learn IDs. It is inevitable. > > > > > [RFC8019] for more detail). It is RECOMMENDED that implementations > > in this situation cache the negative result of negotiation for some > > time and don't make attempts to create it again for some time, > > because this is a result of misconfiguration and probably some re- > > configuration of the peers is needed. > > > > Is this "implementations" as initiators, responders, or both? > > Initiators. In IKEv2, responders always only respond once per > received initiator packet. > > > removing USE_PPK notification from the IKE_SA_INIT and forging > > digital signatures in the subsequent exchange. If using PPKs is > > mandatory for at least one of the peers or PSK is used for > > authentication, then the attack will be detected and the SA won't be > > created. > > > > side note(?): Up in Section 5.2.3 we talk about PPK-only authentication, > > but here we talk about PSK authentication. I believe those are distinct > > things (and thus that there's nothing to change in the text), but am > > checking just to be sure. > > Yes there are distinct things. > > > If the attacker manages to inject this packet before the responder > > sends a genuine response, then the initiator would abort the > > exchange. To thwart this kind of attack it is RECOMMENDED, that if > > using PPKs is mandatory for the initiator and the received response > > doesn't contain the USE_PPK notification, then the initiator doesn't > > abort the exchange immediately, but instead waits some time for more > > responses (possibly retransmitting the request). If all the received > > > > I expect that some reviewer is going to note that this recommendation > > only occurs in the security considerations section and suggest moving it > > to the body of the document, and also that we will be asked to give more > > concrete guidance about "some time". I don't think either change is > > critical to make, but consider yourself forewarned... > > Sounds fair. Timing advise would be similar to how long the implemention > keeps half-open SA's around in general. > > > Section 7 > > > > We should have a registration template for what information new > > registration requests should include. (In particular, since we allow > > changing entries, a "change controller" and contact information will be > > needed.) I suggest including a column for "reference to specification > > (if available)", even though the "Expert Review" policy does not > > strictly require one. We could also provide some guidance to the DEs as > > to what criteria they may or may not want to apply in deciding whether > > to approve or reject a registration request. > > Sounds fair. Thanks again, Ben From nobody Tue Nov 5 02:46:30 2019 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 DA1EC1208D2 for ; Tue, 5 Nov 2019 02:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 cwJWi5sYoscr for ; Tue, 5 Nov 2019 02:46:25 -0800 (PST) Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [129.187.255.137]) (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 88B151208C8 for ; Tue, 5 Nov 2019 02:46:25 -0800 (PST) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 476mYW3zbhzyWX; Tue, 5 Nov 2019 11:46:23 +0100 (CET) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id dW9Q8hIIIokf; Tue, 5 Nov 2019 11:46:23 +0100 (CET) Received: from BADWLRZ-SWMBX06.ads.mwn.de (BADWLRZ-SWMBX06.ads.mwn.de [IPv6:2001:4ca0:0:108::162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX06", Issuer "BADWLRZ-SWMBX06" (not verified)) by postout1.mail.lrz.de (Postfix) with ESMTPS id 476mYV6xdyzyWQ; Tue, 5 Nov 2019 11:46:22 +0100 (CET) Received: from BADWLRZ-SWMBX05.ads.mwn.de (2001:4ca0:0:108::161) by BADWLRZ-SWMBX06.ads.mwn.de (2001:4ca0:0:108::162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 5 Nov 2019 11:46:21 +0100 Received: from BADWLRZ-SWMBX05.ads.mwn.de ([fe80::4095:4fb3:50be:d2bd]) by BADWLRZ-SWMBX05.ads.mwn.de ([fe80::4095:4fb3:50be:d2bd%12]) with mapi id 15.01.1713.009; Tue, 5 Nov 2019 11:46:21 +0100 From: "Guggemos, Tobias" To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Adoption call for draft-yeung-g-ikev2 Thread-Index: AQHVkpjczcn4t5VOeEuOXZsHvCamd6d8Zxcw Date: Tue, 5 Nov 2019 10:46:21 +0000 Message-ID: References: <23999.22847.102427.234841@fireball.acr.fi> In-Reply-To: <23999.22847.102427.234841@fireball.acr.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: BADWLRZ-SWMBX05.ads.mwn.de X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [141.84.218.130] Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=0FTYoOL1FgZ9Xn=-=" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Adoption call for draft-yeung-g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 10:46:29 -0000 --=-=0FTYoOL1FgZ9Xn=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, I also strongly support adoption.=20 Regards Tobias > -----Urspr=C3=BCngliche Nachricht----- > Von: IPsec Im Auftrag von Tero Kivinen > Gesendet: Sonntag, 3. November 2019 23:49 > An: ipsec@ietf.org > Betreff: [IPsec] Adoption call for draft-yeung-g-ikev2 >=20 > This is a adoption call for the draft-yeung-g-ikev2 draft to be WG docume= nt. > This document has been around for long time, and we inherited it from the > msec WG when it closed down. We have already decided to take this as an > chater item so making this WG document should be ok. >=20 > If you support adopting this document as WG Document, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you have a= ny > comments or reservations send them to the list too. >=20 > As this document is longer, and has new exchanges for IKEv2, this is two > week long adoption call, allowing more time to read the document through. > This adoption call finishes 2019-11-16. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=-=0FTYoOL1FgZ9Xn=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAl3BUvUACgkQyEcVbMgz VZ8GXwf/RBzZb7z88M7EHPm83QwaP3Gqairm1SMD0LRTF4s1hCFVUiMn7PJBZ/er pJ4JU2TbKfuh5N9Z3AlleC7pUOvVH/4QIP2RSqmNAKKcyjEVax/A3WdpM/X9yCKo IaTxv6xvoQlxivW03LGV/Q4HT6m9AKB32Dzjh1vFmtbUww+h2bgHa9aqQ8DmAnmh Q69N7SqUD/iRYEWDlQOAPSWm+hLCA7ScFevJk9uX1nJXhTlANWqDZ3G3hKAG5u1V YUsWes5w3l/hPcF7LdKTkwXu4Vz1ObesMTft4qH1EMuaQy7wYrhIYIX/vwdySN2h wFXENgkM534sbHfX0k1hUyNBl8uMpQ== =5cg9 -----END PGP SIGNATURE----- --=-=0FTYoOL1FgZ9Xn=-=-- From nobody Tue Nov 5 04:03:30 2019 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 CFCA51208F4 for ; Tue, 5 Nov 2019 04:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 XKCHRdN7Vjn8 for ; Tue, 5 Nov 2019 04:03:27 -0800 (PST) Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (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 C278C1208F3 for ; Tue, 5 Nov 2019 04:03:26 -0800 (PST) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 476pGN4T92zyYk; Tue, 5 Nov 2019 13:03:24 +0100 (CET) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id rEzXk3xnd2Cq; Tue, 5 Nov 2019 13:03:23 +0100 (CET) Received: from BADWLRZ-SWMBX06.ads.mwn.de (BADWLRZ-SWMBX06.ads.mwn.de [IPv6:2001:4ca0:0:108::162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX06", Issuer "BADWLRZ-SWMBX06" (not verified)) by postout1.mail.lrz.de (Postfix) with ESMTPS id 476pGK5m3GzyYS; Tue, 5 Nov 2019 13:03:21 +0100 (CET) Received: from BADWLRZ-SWMBX05.ads.mwn.de (2001:4ca0:0:108::161) by BADWLRZ-SWMBX06.ads.mwn.de (2001:4ca0:0:108::162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 5 Nov 2019 13:03:21 +0100 Received: from BADWLRZ-SWMBX05.ads.mwn.de ([fe80::4095:4fb3:50be:d2bd]) by BADWLRZ-SWMBX05.ads.mwn.de ([fe80::4095:4fb3:50be:d2bd%12]) with mapi id 15.01.1713.009; Tue, 5 Nov 2019 13:03:21 +0100 From: "Guggemos, Tobias" To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 Thread-Index: AQHVkpf4LbesLWJPLEWHHEzSwUaKnKd8ajfw Date: Tue, 5 Nov 2019 12:03:21 +0000 Message-ID: References: <23999.22463.132733.702468@fireball.acr.fi> In-Reply-To: <23999.22463.132733.702468@fireball.acr.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: BADWLRZ-SWMBX05.ads.mwn.de X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.84.218.130] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 12:03:29 -0000 Hey, I also strongly support adoption. > It is an open question whether or not it is feasible to build a > Quantum Computer (and if so, when one might be implemented), but if > > Feasibility of some quantum computer is becoming much less of an open=20 > question; perhaps we want some qualifiers about efficiency, scale,=20 > and/or general-purpose-nature. > Do we have a reference for this "it is believed", or is it just the=20 > outcome of the WG discussions? Regarding this discussion (and sorry if this was discussed before and I did= n't realize). Do we really need the term post-quantum in the title (and maybe even in the= abstract)? The draft tells how to do multiple/hybrid key-exchanges in IKEv2, PQ is the= major motivation but not the only use case. As far as I'm familiar with the draft, you could easily do DH + ECDH with i= t (and if not I'd really like it be like that). Regards Tobias > -----Urspr=FCngliche Nachricht----- > Von: IPsec Im Auftrag von Tero Kivinen > Gesendet: Sonntag, 3. November 2019 23:42 > An: ipsec@ietf.org > Betreff: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 >=20 > This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2 > draft to be accepted to be WG Document. This draft has been around for > some time, and we have been discussing it in the meetings. >=20 > If you support adopting this document as WG Document, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you have a= ny > comments or reservations send them to the list too. >=20 > This adoption call finishes 2019-11-11. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Nov 5 04:09:07 2019 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 351B21208ED for ; Tue, 5 Nov 2019 04:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ZuOcyZVeZ0 for ; Tue, 5 Nov 2019 04:09:03 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 6431F1208A9 for ; Tue, 5 Nov 2019 04:09:03 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id r7so12843555ljg.2 for ; Tue, 05 Nov 2019 04:09:03 -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=LuzybouTMhtHxrw4nkvckvwKuUnntlPkZhx/ylK1wW4=; b=TmK6nalNbiit7PEKj/cHpoOOoNScv4kcUL71ubOi6rW5u6+gGQXXVQPQTGFCeji0nS 5JW6Z7GWu4no1iLL7LR/bq1MuvzsmogO3aaYQWRgWo5LLZUdh7wmrgN7aTc8rAsp4VoA BAMPaeEPVd5XdKi7l6ijqoDSlfFft4zpmLqU+pNtOtQnYBMu1hoP+p/1Nxi6ttsfANJ2 eluxKxUbnmFFXW9iSMcWxD8nwF+YNdpuXpA/i1DvgHQzV6X4wFpXyHwepSZmhqhWtNPn YdDzFc34FM9jHk45cR+AaOpMAi8MwhhWCtU78yVs5YlF9XrvBX2lm9n+nvX65r7v4az0 LhLw== 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=LuzybouTMhtHxrw4nkvckvwKuUnntlPkZhx/ylK1wW4=; b=VciFcoz/uGpYlEBJC6LDPt8ohYaUFe48oer8kLTLwc3HQBp4Yofi0FSBcJFcUJ7LDG Go9QjTeM+qBndTsHSBOblAxPjMAAMM3YdzjWCgZ5VmBHYMyJKFD/LKTJhZ5eS3G5g1E5 mbDGc9HNM/DltCqDyLoPj3ZQAOhgVevUqyCpdGg6bgEggCwYDB0fmx1upstqvFTwbpsD J5nnnkxEM4VBTJBVfH4IXYXUsZGzevWk5cVo8nW22JLysGCIl7N8wK+7Xfzx8uqmYZic rOdMVG6Vt8mgJjmqjqLvNoHW7V/nERfZ/zo8eZRlPmy2BIB75jha4QaxF24/2EgSrWYo UEcg== X-Gm-Message-State: APjAAAWADrwvcXbu3pZblCyXlXEPAuKSllXsybiVv8Rtw7YUSMGlH3Wu c/V2O6S1vBOOax4ui31u3B4= X-Google-Smtp-Source: APXvYqyiOr3azGHLosMwQHVwgQjCSXDh7XzwsLYVDeKRsoHdFvvfzPyj+R0AdV3IoN3FjJ9pRqpCvw== X-Received: by 2002:a05:651c:209:: with SMTP id y9mr13747956ljn.65.1572955741469; Tue, 05 Nov 2019 04:09:01 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u67sm12126172lja.78.2019.11.05.04.09.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Nov 2019 04:09:00 -0800 (PST) From: "Valery Smyslov" To: "'Guggemos, Tobias'" , "'Tero Kivinen'" , References: <23999.22463.132733.702468@fireball.acr.fi> In-Reply-To: Date: Tue, 5 Nov 2019 15:09:02 +0300 Message-ID: <058801d593d1$d0a945e0$71fbd1a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJIzRedXI2okcVeVQLJ6iDp5b4brgGAZyYWpooFY0A= Content-Language: ru Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 12:09:05 -0000 Hi Tobias, > Hey, > I also strongly support adoption. >=20 > > It is an open question whether or not it is feasible to build a > > Quantum Computer (and if so, when one might be implemented), but = if > > > > Feasibility of some quantum computer is becoming much less of an = open > > question; perhaps we want some qualifiers about efficiency, scale, > > and/or general-purpose-nature. > > Do we have a reference for this "it is believed", or is it just the > > outcome of the WG discussions? >=20 > Regarding this discussion (and sorry if this was discussed before and = I didn't realize). > Do we really need the term post-quantum in the title (and maybe even = in the abstract)? > The draft tells how to do multiple/hybrid key-exchanges in IKEv2, PQ = is the major motivation but not the only > use case. > As far as I'm familiar with the draft, you could easily do DH + ECDH = with it (and if not I'd really like it be like > that). The title is inherited from the early versions of the draft :-) I agree that in the current form the draft is far less restrictive in combining KE methods and the title could (and I think should) be modified to reflect this. Regards, Valery. >=20 > Regards > Tobias >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: IPsec Im Auftrag von Tero Kivinen > > Gesendet: Sonntag, 3. November 2019 23:42 > > An: ipsec@ietf.org > > Betreff: [IPsec] Adoption call for = draft-tjhai-ipsecme-hybrid-qske-ikev2 > > > > This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2 > > draft to be accepted to be WG Document. This draft has been around = for > > some time, and we have been discussing it in the meetings. > > > > If you support adopting this document as WG Document, then send = email > > indicating your support to the ipsec@ietf.org mailing-list. If you = have any > > comments or reservations send them to the list too. > > > > This adoption call finishes 2019-11-11. > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > 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 Tue Nov 5 07:11:28 2019 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 616201200D6; Tue, 5 Nov 2019 07:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srDdMLOpZzfb; Tue, 5 Nov 2019 07:11:22 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D9A120977; Tue, 5 Nov 2019 07:11:17 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iRzn7-0004sY-4B; Tue, 05 Nov 2019 17:26:41 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iRzn6-0005Gg-Lg; Tue, 05 Nov 2019 17:26:41 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 5 Nov 2019 17:26:40 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Tue, 5 Nov 2019 17:26:40 +0300 From: Valery Smyslov To: 'Benjamin Kaduk' , CC: References: <20191105023831.GH55993@kduck.mit.edu> In-Reply-To: <20191105023831.GH55993@kduck.mit.edu> Date: Tue, 5 Nov 2019 17:26:43 +0300 Message-ID: <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL0a9Ttu9PudiK014soS4Z/m3iG4aU+ymWQ Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/11/05 13:58:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/11/05 09:45:00 #14312595 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 15:11:26 -0000 Hi Ben, many thanks for the very thorough review. Please, see inline. > Hi all, > > Thanks for this document -- it's pretty readable (once I did my background > reading on RFC 7296) and is an interim measure that we're seeing some > demand for already. Sorry to have been sitting on this for so long; my > backlog is taking longer to clear than planned. > > There are a few substantitve comments mixed in with the nits -- the IANA > Considerations in particular will probably need a bit more attention to get > fleshed out with what we need. > > Anyway, here are the section-by-section notes. In an attempt to make the message more readable I removed all the nits that are silently accepted (thanks for catching them). > Section 1 > > It is an open question whether or not it is feasible to build a > Quantum Computer (and if so, when one might be implemented), but if > > Feasibility of some quantum computer is becoming much less of an open > question; perhaps we want some qualifiers about efficiency, scale, > and/or general-purpose-nature. Do you have any data or pointers? > would be compromised. IKEv1 [RFC2409], when used with strong > preshared keys, is not vulnerable to quantum attacks, because those > keys are one of the inputs to the key derivation function. If the > preshared key has sufficient entropy and the PRF, encryption and > authentication transforms are postquantum secure, then the resulting > system is believed to be quantum resistant, that is, invulnerable to > an attacker with a Quantum Computer. > > Do we have a reference for this "it is believed", or is it just the > outcome of the WG discussions? I'll let my co-authors comment on this, but I think it is meant that according to our best current knowledge nothing better than Grover's algorithm can be used to break symmetric key cryptosystem with QC. And Grover's algorithm only halves an effective key length, so if longer PSK is used, we're safe (we believe we are). > The general idea is that we add an additional secret that is shared > between the initiator and the responder; this secret is in addition > to the authentication method that is already provided within IKEv2. > We stir this secret into the SK_d value, which is used to generate > the key material (KEYMAT) and the SKEYSEED for the child SAs; this > secret provides quantum resistance to the IPsec SAs (and any child > IKE SAs). We also stir the secret into the SK_pi, SK_pr values; this > allows both sides to detect a secret mismatch cleanly. > > With apologies for the pedanticism, let's be careful what wording we > use, as just mixing into SK_d is not necessarily enough to get quantum > resitsance for the parent IPsec SA. > [need to check this some more] Well, there is no "parent IPsec SA" in IKEv2, all the IPsec SAs are children of an IKE SA. They are created using SK_d as a key, so if PPK is mixed into SK_d, then all Child IIPsec) SAs are protected. Moreover, the SK_d is used when IKE SA is rekeyed as one of the inputs for computation of new keys, so once IKE SA is rekeyed, the new IKE SA will be QC-resistant too. > Section 1.2 > > Every directorate reviewer and IESG member is going to suggest that we > use the RFC 8174 version of the boilerplate, if we don't preemptively do > so :) Haven't we added it yet? Oh, my bad, the draft is so old, that it doesn't even reference 8174 :-) Fixed. > Section 2 > > We assume that each IKE peer has a list of Postquantum Preshared Keys > (PPK) along with their identifiers (PPK_ID), and any potential IKE > initiator has a selection of which PPK to use with any specific > responder. In addition, implementations have a configurable flag > > nit: I'm not sure what "has a selection of" is intended to mean. Is it > more about making a choice of which PPK to use or about having a list to > choose from? The former - making a choice of which PPK to use with any specific responder. Do you think it should be rephrased? > This PPK is independent of the preshared key (if any) that the IKEv2 > > I expect us to get a few questions about why we need a separate PPK in > cases when an authentication psk is also available; a short note here > might forestall such questions. (It's needed because PSK for auth does > not feed into any of the other key derivations, right?) Exactly. I've added short explanation: This PPK is independent of the preshared key (if any) that the IKEv2 protocol uses to perform authentication (because preshared key in IKEv2 is not used for any key derivation, and thus doesn't protect against Quantum Computers). Is it OK? > protocol uses to perform authentication. The PPK specific > configuration that is assumed on each peer consists of the following > tuple: > > Peer, PPK, PPK_ID, mandatory_or_not > > nit: we use "peer" twice here, and the context suggests that they refer > to different parties in the different places. If we change it to: "The PPK specific configuration that is assumed on each node consists of the following tuple:" does it eliminate the possible confusion? > Section 3 > > N(USE_PPK) is a status notification payload with the type 16435; it > has a protocol ID of 0, no SPI and no notification data associated > with it. > > [check the IANA status of the value] These values have been allocated by IANA as a result of early allocation request. > If the responder does not support this specification or does not have > any PPK configured, then she ignores the received notification and > continues with the IKEv2 protocol as normal. Otherwise the responder > checks if she has a PPK configured, and if she does, then the > > nit: we probably don't need to mention "if [...] PPK configured" twice. Removed second instance of the phrase. > responder included the USE_PPK notification. If the responder did > not and the flag mandatory_or_not indicates that using PPKs is > mandatory for communication with this responder, then the initiator > MUST abort the exchange. This situation may happen in case of > > We might get some directorate questions about what it means to "abort > the exchange"; I note that RFC 7296 does not use that terminology, > though I'm perfectly happy to leave this as-is and see if we get any ADs > that are concerned about it. In this context "abort the exchange" means that the initiator just stops any activity related to this exchange (but see Security Considerations for some hints). > If the responder did not include the USE_PPK notification and using a > PPK for this particular responder is optional, then the initiator > continues with the IKEv2 protocol as normal, without using PPKs. > > Do we want to say anything about logging or notifications for this case, > in case someone is concerned about the level of quantum-resistance in > use? Hmmm. I think that we follow RFC 7296 tradition that leaves all logging (and the like) up to implementations... > If the responder did include the USE_PPK notification, then the > initiator selects a PPK, along with its identifier PPK_ID. Then, she > computes this modification of the standard IKEv2 key derivation: > > Just to double-check: the responder's USE_PPK is just a boolean "I'm > willing to do PPK", right? So we don't really hae a signal as to which > PPK_IDs the peer thinks are valid? Yes. The PPK_ID is sent by the initiator in the IKE_AUTH request, the IKE_SA_INIT only negotiate using PPK without specifying which PPK to use. > That is, we use the standard IKEv2 key derivation process except that > the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again, > this time using the PPK as the key. Using prf+ construction ensures > > Do we want to say anything about why only these three values need the > PPK mixed in to them? (I guess the idea is that the parent SA is > "short-lived" on the timescale of a quantum computer and the messages > protected directly by it are not of interest to an attacker years in the > future. This does mean that this scheme does not provide much value > when a quantum computer is available at the time of the exchange, > though, right? No, the reason is different. The PPK_ID is sent in the IKE_AUTH, that is protected by the SK_ei/er/ai/ar keys. If these keys were dependent on PPK, then in case of PPK mismatch the responder would not be able to decrypt the message and thus cannot handle this situation properly. We ran into this problem with IKEv1, when PSK was stirred into key computation and in case of PSK mismatch the responder received garbage, and wasn't able to recover gracefully. For this reason it was decided by the WG to only mix PPK into SK_d and SK_pi/pr, leaving it out from SK_ei/er/ai/ar. This leaves initial IKE SA not protected against QC, but allows the protocol to handle PPK mismatch gracefully. > The responder then continues with the IKE_AUTH exchange (validating > the AUTH payload that the initiator included) as usual and sends back > a response, which includes the PPK_IDENTITY notification with no data > to indicate that the PPK is used in the exchange: > > Why does the responder not need to transmit an explicit PPK_ID? (I see > that the following paragraph says that the initiatore MUST ignore any > content to that notification, but why?) Because we use a single PPK for both (unlike PSKs, which can be different for initiator and responder). So, the purpose of the PPK_IDENTITY in this case is just to confirm that the responder agrees to use the PPK, which the initiator selected. There is no need to return it back - the responder cannot change it, so an empty notification does the job and saves some space. > not yet known to the responder. Once the IKE_AUTH request message > containing PPK_IDENTITY notification is received, the responder > follows rules described above for non-EAP authentication case. > > nits: (missing "the"s) "the PPK_IDENTITY notification", "the rules > described above", "the non-EAP authentication case" Oh, it's my text, I've been always having problems with articles :-) > Initiator Responder > ---------------------------------------------------------------- > HDR, SK {IDi, [CERTREQ,] > [IDr,] SAi2, > TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP} > HDR, SK {EAP} --> > <-- HDR, SK {EAP (success)} > HDR, SK {AUTH, > N(PPK_IDENTITY, PPK_ID) > [, N(NO_PPK_AUTH)]} --> > <-- HDR, SK {AUTH, SAr2, TSi, TSr > [, N(PPK_IDENTITY)]} > > Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as > optional here in the EAP case but not in the previous diagram for the > non-EAP case? In the previous diagram we consider only the case when using PPK is agreed upon, so N(PPK_IDENTITY) is not optional. We leave out the case when using PPK is optional for both and the responder doesn't have the PPK the initiator has selected, in which case the normal IKE_AUTH takes place (which is not depicted and is only spelled out). With EAP a single diagram shows all possible scenarios, thus N(PPK_IDENTITY) becomes optional here. > Section 4 > > With this configuration, the node will continue to operate with nodes > that have not yet been upgraded. This is due to the USE_PPK notify > and the NO_PPK_AUTH notify; if the initiator has not been upgraded, > he will not send the USE_PPK notify (and so the responder will know > > nit: I think we should be consistent about using either "notification" > or "Notify payload"/"Notify message", avoiding just the bare "notify". > (Also occurs in subsequent locations that I won't quote/mention > individually.) Changed to "notification" in all places. > NO_PPK_AUTH notification. If both the responder and initiator have > been upgraded and properly configured, they will both realize it, and > in that case, the link will be quantum secure. > > I think that "the link will be quantum secure" is probably overselling > things a little bit; for one, the confidentiality protection we provide > is only for the child SAs, and the discussion earlier in the document is > about providing protection for current connections against future > development of a quantum computer, while most people probably think of > full "quantum secure" as being protection even against a current quantum > computer. Changed to "Child SAs". > As an optional second step, after all nodes have been upgraded, then > the administrator should then go back through the nodes, and mark the > use of PPK as mandatory. This will not affect the strength against a > passive attacker; it would mean that an attacker with a Quantum > Computer (which is sufficiently fast to be able to break the (EC)DH > in real time) would not be able to perform a downgrade attack. > > It seems like (given the current lack of advice for logging/reporting, > as noted above) changing the use of PPK to mandatory also serves to > provide notification if any future misconfiguration changes regarding > the use of PPK, to give a more robust indication of when the desired > protection is not being applied. Implicitly. However, even if we don't mandate any logging, wise implementations would log all the important information anyway. > Section 5.1 > > initiator and the responder. The responder can use to do a look > up the passed PPK_ID value to determine the corresponding PPK > value. Not all implementations are able to configure arbitrary > > nit: this sentence is hard to follow; I suggest > > % The responder can use the PPK_ID to look up the corresponding PPK > % value. OK. > value. Not all implementations are able to configure arbitrary > octet strings; to improve the potential interoperability, it is > recommended that, in the PPK_ID_FIXED case, both the PPK and the > PPK_ID strings be limited to the base64 character set, namely the > 64 characters 0-9, A-Z, a-z, + and /. > > I don't have much experience with the conventions in this space; does it > make sense to distinguish between the PPK representation as configured > (which would use the base64 alphabet) and the "actual PPK" that could be > binary after, e.g., a base64-decoding step? I guess it could be > reasonable to rely on the ability of the PRF to take an arbitrary-length > input and just have sufficient entropy even while limiting the PPK value > to the base64 alphabet. I recall it was requested by somebody during discussion in the WG. I tend to agree with you, but I'd rather to wait for some input from others. > The PPK_ID type value 0 is reserved; values 3-127 are reserved for > IANA; values 128-255 are for private use among mutually consenting > parties. > > I guess that anything done in the 128-255 range could also be done under > the PPK_ID_OPAQUE space (at the cost of an extra octet), but I don't > object to this breakdown. We think that for some use cases new PPK_ID types may be needed. > Section 5.2.1 > > I'm kind of confused by the PSKC reference, especially the implication > ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the > PIN") that a fixed string is to be used as a PIN. (I also think it's > better to discuss what it does as "key transport" than "key exchange", > noting that the latter string does not appear in RFC 6030.) I recall it was requested by somebody during discussion in the WG... > Section 5.2.2 > > It is possible to use a single PPK for a group of users. Since each > peer uses classical public key cryptography in addition to PPK for > key exchange and authentication, members of the group can neither > impersonate each other nor read other's traffic, unless they use > Quantum Computers to break public key operations. However group > members can record other members' traffic and decrypt it later, when > they get access to a Quantum Computer. > > nit: I suggest "can record any traffic they have access to that comes > from other group members and decrypt it later", since just being a group > member does not grant one a universal network tap. OK. > Section 6 > > We should document the privacy considerations of the PPK_ID both in the > face of an attacker with a quantum computer (now or in the future) and > in the face of a classical attacker. The latter would, IIUC, need to be > an active MITM in order to see anything other than N(USE_PPK), and who > would also get IDi along with the PPK_ID value, so there's not much of a > change in the privacy stance. OK, we'll think how to do it right. > [RFC8019] for more detail). It is RECOMMENDED that implementations > in this situation cache the negative result of negotiation for some > time and don't make attempts to create it again for some time, > because this is a result of misconfiguration and probably some re- > configuration of the peers is needed. > > Is this "implementations" as initiators, responders, or both? Initiator. Changed to "the initiator". > removing USE_PPK notification from the IKE_SA_INIT and forging > digital signatures in the subsequent exchange. If using PPKs is > mandatory for at least one of the peers or PSK is used for > authentication, then the attack will be detected and the SA won't be > created. > > side note(?): Up in Section 5.2.3 we talk about PPK-only authentication, > but here we talk about PSK authentication. I believe those are distinct > things (and thus that there's nothing to change in the text), but am > checking just to be sure. Those are distinct things. PPK-only authentication is in fact the NULL authentication method used with PPK, so if using PPK is optional for both peers, then the described attack works even without QC, the attacker just removes all PPK related stuff from the messages. Note, that 5.2.3 requires that PPK is mandatory for both peers for PPK-only authentication to work. > If the attacker manages to inject this packet before the responder > sends a genuine response, then the initiator would abort the > exchange. To thwart this kind of attack it is RECOMMENDED, that if > using PPKs is mandatory for the initiator and the received response > doesn't contain the USE_PPK notification, then the initiator doesn't > abort the exchange immediately, but instead waits some time for more > responses (possibly retransmitting the request). If all the received > > I expect that some reviewer is going to note that this recommendation > only occurs in the security considerations section and suggest moving it > to the body of the document, and also that we will be asked to give more > concrete guidance about "some time". I don't think either change is > critical to make, but consider yourself forewarned... OK, we'll consider :-) > Section 7 > > We should have a registration template for what information new > registration requests should include. (In particular, since we allow > changing entries, a "change controller" and contact information will be > needed.) I suggest including a column for "reference to specification > (if available)", even though the "Expert Review" policy does not > strictly require one. We could also provide some guidance to the DEs as > to what criteria they may or may not want to apply in deciding whether > to approve or reject a registration request. Adding a reference column makes a lot of sense, thanks. > Appendix A > > A fourth goal was to avoid violating any of the security goals of > IKEv2. > > nit: It is sometimes considered good style to avoid using the same word > too much in close succession (here, "goal"); would it change the meaning > to say "the security properties provided by IKEv2"? OK, thanks. Thank you, Valery. > Thanks, > > Ben From nobody Tue Nov 5 11:59:58 2019 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 00E32120AF9; Tue, 5 Nov 2019 11:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60x1GqXVDhbw; Tue, 5 Nov 2019 11:59:47 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE0B120B07; Tue, 5 Nov 2019 11:59:47 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA5Jxd7S019128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Nov 2019 14:59:42 -0500 Date: Tue, 5 Nov 2019 11:59:39 -0800 From: Benjamin Kaduk To: Valery Smyslov Cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org, ipsec@ietf.org Message-ID: <20191105195939.GH61969@kduck.mit.edu> References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 19:59:57 -0000 On Tue, Nov 05, 2019 at 05:26:43PM +0300, Valery Smyslov wrote: > Hi Ben, > > many thanks for the very thorough review. Please, see inline. > > > Hi all, > > > > Thanks for this document -- it's pretty readable (once I did my background > > reading on RFC 7296) and is an interim measure that we're seeing some > > demand for already. Sorry to have been sitting on this for so long; my > > backlog is taking longer to clear than planned. > > > > There are a few substantitve comments mixed in with the nits -- the IANA > > Considerations in particular will probably need a bit more attention to get > > fleshed out with what we need. > > > > Anyway, here are the section-by-section notes. > > In an attempt to make the message more readable I removed all the nits > that are silently accepted (thanks for catching them). Thanks for that; I don't have a great workflow to split them out into a separate section/document yet. > > Section 1 > > > > It is an open question whether or not it is feasible to build a > > Quantum Computer (and if so, when one might be implemented), but if > > > > Feasibility of some quantum computer is becoming much less of an open > > question; perhaps we want some qualifiers about efficiency, scale, > > and/or general-purpose-nature. > > Do you have any data or pointers? I'm mostly just thinking about press releases from D-WAVE and Google that get turned into articles in the technology press. We see headlines about 60+ q-bit machines, that more likely than not are doing *something*. So in my mind it becomes a question of whether what these machines (that exist and are being sold) are doing is useful for the problems relevant to a given technology, rather than whether a quantum computer exists. (I'm not even sure that there's a generally accepted definition for what "quantum computer" means -- some people seem to use it for just annealing-based stuff.) > > would be compromised. IKEv1 [RFC2409], when used with strong > > preshared keys, is not vulnerable to quantum attacks, because those > > keys are one of the inputs to the key derivation function. If the > > preshared key has sufficient entropy and the PRF, encryption and > > authentication transforms are postquantum secure, then the resulting > > system is believed to be quantum resistant, that is, invulnerable to > > an attacker with a Quantum Computer. > > > > Do we have a reference for this "it is believed", or is it just the > > outcome of the WG discussions? > > I'll let my co-authors comment on this, but I think it is meant > that according to our best current knowledge nothing > better than Grover's algorithm can be used to break symmetric > key cryptosystem with QC. And Grover's algorithm only > halves an effective key length, so if longer PSK is used, we're safe > (we believe we are). To be clear: I share this belief! :) I am just asking if it is sufficiently well-known/widespread that no reference is needed; that may well be the case. > > The general idea is that we add an additional secret that is shared > > between the initiator and the responder; this secret is in addition > > to the authentication method that is already provided within IKEv2. > > We stir this secret into the SK_d value, which is used to generate > > the key material (KEYMAT) and the SKEYSEED for the child SAs; this > > secret provides quantum resistance to the IPsec SAs (and any child > > IKE SAs). We also stir the secret into the SK_pi, SK_pr values; this > > allows both sides to detect a secret mismatch cleanly. > > > > With apologies for the pedanticism, let's be careful what wording we > > use, as just mixing into SK_d is not necessarily enough to get quantum > > resitsance for the parent IPsec SA. > > [need to check this some more] > > Well, there is no "parent IPsec SA" in IKEv2, all the IPsec SAs > are children of an IKE SA. They are created using SK_d as a key, > so if PPK is mixed into SK_d, then all Child IIPsec) SAs are protected. > Moreover, the SK_d is used when IKE SA is rekeyed as one of the inputs > for computation of new keys, so once IKE SA is rekeyed, the new > IKE SA will be QC-resistant too. Oh, this is probably the key part of my confusion/misunderstanding with the terminology (which also shows up later on, IIRC). Namely, that the initial exchange generates an IKE SA, and the other SAs ("children" for ESP/AH usage) are called IPsec SAs (not IKE SAs). In that case this text is fine as-is and there's nothing to change, so sorry for the noise. > > Section 1.2 > > > > Every directorate reviewer and IESG member is going to suggest that we > > use the RFC 8174 version of the boilerplate, if we don't preemptively do > > so :) > > Haven't we added it yet? Oh, my bad, the draft is so old, that > it doesn't even reference 8174 :-) Fixed. > > > Section 2 > > > > We assume that each IKE peer has a list of Postquantum Preshared Keys > > (PPK) along with their identifiers (PPK_ID), and any potential IKE > > initiator has a selection of which PPK to use with any specific > > responder. In addition, implementations have a configurable flag > > > > nit: I'm not sure what "has a selection of" is intended to mean. Is it > > more about making a choice of which PPK to use or about having a list to > > choose from? > > The former - making a choice of which PPK to use with any > specific responder. Do you think it should be rephrased? I'd suggest "any potential IKE initiator selects which PPK to use with any specific responder". (The other case involves the word "selection" in the sense of "this restaurant has a large selection of wines", but we want the verb form of "selection".) > > This PPK is independent of the preshared key (if any) that the IKEv2 > > > > I expect us to get a few questions about why we need a separate PPK in > > cases when an authentication psk is also available; a short note here > > might forestall such questions. (It's needed because PSK for auth does > > not feed into any of the other key derivations, right?) > > Exactly. I've added short explanation: > > This PPK is independent of the preshared key (if any) that the IKEv2 protocol uses to perform authentication > (because preshared key in IKEv2 is not used for any key derivation, and thus doesn't protect against Quantum Computers). > > Is it OK? That's the right level of detail/length, thanks. (nit: "the preshared key") > > protocol uses to perform authentication. The PPK specific > > configuration that is assumed on each peer consists of the following > > tuple: > > > > Peer, PPK, PPK_ID, mandatory_or_not > > > > nit: we use "peer" twice here, and the context suggests that they refer > > to different parties in the different places. > > If we change it to: > > "The PPK specific configuration that is assumed on each node consists of the following tuple:" > > does it eliminate the possible confusion? Yes! > > Section 3 > > > > N(USE_PPK) is a status notification payload with the type 16435; it > > has a protocol ID of 0, no SPI and no notification data associated > > with it. > > > > [check the IANA status of the value] > > These values have been allocated by IANA as a result of early allocation request. > > > If the responder does not support this specification or does not have > > any PPK configured, then she ignores the received notification and > > continues with the IKEv2 protocol as normal. Otherwise the responder > > checks if she has a PPK configured, and if she does, then the > > > > nit: we probably don't need to mention "if [...] PPK configured" twice. > > Removed second instance of the phrase. > > > responder included the USE_PPK notification. If the responder did > > not and the flag mandatory_or_not indicates that using PPKs is > > mandatory for communication with this responder, then the initiator > > MUST abort the exchange. This situation may happen in case of > > > > We might get some directorate questions about what it means to "abort > > the exchange"; I note that RFC 7296 does not use that terminology, > > though I'm perfectly happy to leave this as-is and see if we get any ADs > > that are concerned about it. > > In this context "abort the exchange" means that the initiator > just stops any activity related to this exchange (but > see Security Considerations for some hints). > > > If the responder did not include the USE_PPK notification and using a > > PPK for this particular responder is optional, then the initiator > > continues with the IKEv2 protocol as normal, without using PPKs. > > > > Do we want to say anything about logging or notifications for this case, > > in case someone is concerned about the level of quantum-resistance in > > use? > > Hmmm. I think that we follow RFC 7296 tradition that leaves > all logging (and the like) up to implementations... If we do that, I'd suggest a little more exposition in the security considerations about how operational misconfiguration or similar could result in PPKs not being used, unless the "PPK is mandatory" knob is switched on. > > If the responder did include the USE_PPK notification, then the > > initiator selects a PPK, along with its identifier PPK_ID. Then, she > > computes this modification of the standard IKEv2 key derivation: > > > > Just to double-check: the responder's USE_PPK is just a boolean "I'm > > willing to do PPK", right? So we don't really hae a signal as to which > > PPK_IDs the peer thinks are valid? > > Yes. The PPK_ID is sent by the initiator in the IKE_AUTH request, > the IKE_SA_INIT only negotiate using PPK without specifying > which PPK to use. > > > That is, we use the standard IKEv2 key derivation process except that > > the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again, > > this time using the PPK as the key. Using prf+ construction ensures > > > > Do we want to say anything about why only these three values need the > > PPK mixed in to them? (I guess the idea is that the parent SA is > > "short-lived" on the timescale of a quantum computer and the messages > > protected directly by it are not of interest to an attacker years in the > > future. This does mean that this scheme does not provide much value > > when a quantum computer is available at the time of the exchange, > > though, right? > > No, the reason is different. The PPK_ID is sent in the IKE_AUTH, > that is protected by the SK_ei/er/ai/ar keys. If these keys were > dependent on PPK, then in case of PPK mismatch the responder > would not be able to decrypt the message and thus cannot handle > this situation properly. We ran into this problem with IKEv1, > when PSK was stirred into key computation and in case of PSK mismatch > the responder received garbage, and wasn't able to recover gracefully. > > For this reason it was decided by the WG to only mix PPK into SK_d > and SK_pi/pr, leaving it out from SK_ei/er/ai/ar. This leaves > initial IKE SA not protected against QC, but allows the protocol to > handle PPK mismatch gracefully. Ah, okay. (I think this is discussed adequately later on in the document, so don't feel obligated to add any new text here if you don't want to.) > > The responder then continues with the IKE_AUTH exchange (validating > > the AUTH payload that the initiator included) as usual and sends back > > a response, which includes the PPK_IDENTITY notification with no data > > to indicate that the PPK is used in the exchange: > > > > Why does the responder not need to transmit an explicit PPK_ID? (I see > > that the following paragraph says that the initiatore MUST ignore any > > content to that notification, but why?) > > Because we use a single PPK for both (unlike PSKs, which can be different > for initiator and responder). So, the purpose of the PPK_IDENTITY > in this case is just to confirm that the responder agrees to use the PPK, > which the initiator selected. There is no need to return it back - > the responder cannot change it, so an empty notification > does the job and saves some space. > > > not yet known to the responder. Once the IKE_AUTH request message > > containing PPK_IDENTITY notification is received, the responder > > follows rules described above for non-EAP authentication case. > > > > nits: (missing "the"s) "the PPK_IDENTITY notification", "the rules > > described above", "the non-EAP authentication case" > > Oh, it's my text, I've been always having problems with articles :-) English is a pretty silly language in this way (and many others) :) > > Initiator Responder > > ---------------------------------------------------------------- > > HDR, SK {IDi, [CERTREQ,] > > [IDr,] SAi2, > > TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > > EAP} > > HDR, SK {EAP} --> > > <-- HDR, SK {EAP (success)} > > HDR, SK {AUTH, > > N(PPK_IDENTITY, PPK_ID) > > [, N(NO_PPK_AUTH)]} --> > > <-- HDR, SK {AUTH, SAr2, TSi, TSr > > [, N(PPK_IDENTITY)]} > > > > Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as > > optional here in the EAP case but not in the previous diagram for the > > non-EAP case? > > In the previous diagram we consider only the case when using > PPK is agreed upon, so N(PPK_IDENTITY) is not optional. > We leave out the case when using PPK is optional > for both and the responder doesn't have the PPK the initiator > has selected, in which case the normal IKE_AUTH takes place > (which is not depicted and is only spelled out). > > With EAP a single diagram shows all possible scenarios, > thus N(PPK_IDENTITY) becomes optional here. Ah, I see, since in the other case we split up each step of the exchange into a separate diagram, so they had narrower focus. > > Section 4 > > > > With this configuration, the node will continue to operate with nodes > > that have not yet been upgraded. This is due to the USE_PPK notify > > and the NO_PPK_AUTH notify; if the initiator has not been upgraded, > > he will not send the USE_PPK notify (and so the responder will know > > > > nit: I think we should be consistent about using either "notification" > > or "Notify payload"/"Notify message", avoiding just the bare "notify". > > (Also occurs in subsequent locations that I won't quote/mention > > individually.) > > Changed to "notification" in all places. > > > NO_PPK_AUTH notification. If both the responder and initiator have > > been upgraded and properly configured, they will both realize it, and > > in that case, the link will be quantum secure. > > > > I think that "the link will be quantum secure" is probably overselling > > things a little bit; for one, the confidentiality protection we provide > > is only for the child SAs, and the discussion earlier in the document is > > about providing protection for current connections against future > > development of a quantum computer, while most people probably think of > > full "quantum secure" as being protection even against a current quantum > > computer. > > Changed to "Child SAs". > > > As an optional second step, after all nodes have been upgraded, then > > the administrator should then go back through the nodes, and mark the > > use of PPK as mandatory. This will not affect the strength against a > > passive attacker; it would mean that an attacker with a Quantum > > Computer (which is sufficiently fast to be able to break the (EC)DH > > in real time) would not be able to perform a downgrade attack. > > > > It seems like (given the current lack of advice for logging/reporting, > > as noted above) changing the use of PPK to mandatory also serves to > > provide notification if any future misconfiguration changes regarding > > the use of PPK, to give a more robust indication of when the desired > > protection is not being applied. > > Implicitly. However, even if we don't mandate any logging, > wise implementations would log all the important information > anyway. > > > Section 5.1 > > > > initiator and the responder. The responder can use to do a look > > up the passed PPK_ID value to determine the corresponding PPK > > value. Not all implementations are able to configure arbitrary > > > > nit: this sentence is hard to follow; I suggest > > > > % The responder can use the PPK_ID to look up the corresponding PPK > > % value. > > OK. > > > value. Not all implementations are able to configure arbitrary > > octet strings; to improve the potential interoperability, it is > > recommended that, in the PPK_ID_FIXED case, both the PPK and the > > PPK_ID strings be limited to the base64 character set, namely the > > 64 characters 0-9, A-Z, a-z, + and /. > > > > I don't have much experience with the conventions in this space; does it > > make sense to distinguish between the PPK representation as configured > > (which would use the base64 alphabet) and the "actual PPK" that could be > > binary after, e.g., a base64-decoding step? I guess it could be > > reasonable to rely on the ability of the PRF to take an arbitrary-length > > input and just have sufficient entropy even while limiting the PPK value > > to the base64 alphabet. > > I recall it was requested by somebody during discussion in the WG. > I tend to agree with you, but I'd rather to wait for some input > from others. > > > The PPK_ID type value 0 is reserved; values 3-127 are reserved for > > IANA; values 128-255 are for private use among mutually consenting > > parties. > > > > I guess that anything done in the 128-255 range could also be done under > > the PPK_ID_OPAQUE space (at the cost of an extra octet), but I don't > > object to this breakdown. > > We think that for some use cases new PPK_ID types may be needed. > > > Section 5.2.1 > > > > I'm kind of confused by the PSKC reference, especially the implication > > ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the > > PIN") that a fixed string is to be used as a PIN. (I also think it's > > better to discuss what it does as "key transport" than "key exchange", > > noting that the latter string does not appear in RFC 6030.) > > I recall it was requested by somebody during discussion in the WG... To be clear, unless someone can explain to me how I'm misunderstanding the current text (and thus that the current text makes sense), I object to the current description. It doesn't give me a clear picture of what I'd need to do to use it, and what it seems to describe sounds insecure based on my preconceptions of the terminology used. (I have no prior experience with PSKC, to be clear.) > > Section 5.2.2 > > > > It is possible to use a single PPK for a group of users. Since each > > peer uses classical public key cryptography in addition to PPK for > > key exchange and authentication, members of the group can neither > > impersonate each other nor read other's traffic, unless they use > > Quantum Computers to break public key operations. However group > > members can record other members' traffic and decrypt it later, when > > they get access to a Quantum Computer. > > > > nit: I suggest "can record any traffic they have access to that comes > > from other group members and decrypt it later", since just being a group > > member does not grant one a universal network tap. > > OK. > > > Section 6 > > > > We should document the privacy considerations of the PPK_ID both in the > > face of an attacker with a quantum computer (now or in the future) and > > in the face of a classical attacker. The latter would, IIUC, need to be > > an active MITM in order to see anything other than N(USE_PPK), and who > > would also get IDi along with the PPK_ID value, so there's not much of a > > change in the privacy stance. > > OK, we'll think how to do it right. > > > [RFC8019] for more detail). It is RECOMMENDED that implementations > > in this situation cache the negative result of negotiation for some > > time and don't make attempts to create it again for some time, > > because this is a result of misconfiguration and probably some re- > > configuration of the peers is needed. > > > > Is this "implementations" as initiators, responders, or both? > > Initiator. Changed to "the initiator". Thanks! > > removing USE_PPK notification from the IKE_SA_INIT and forging > > digital signatures in the subsequent exchange. If using PPKs is > > mandatory for at least one of the peers or PSK is used for > > authentication, then the attack will be detected and the SA won't be > > created. > > > > side note(?): Up in Section 5.2.3 we talk about PPK-only authentication, > > but here we talk about PSK authentication. I believe those are distinct > > things (and thus that there's nothing to change in the text), but am > > checking just to be sure. > > Those are distinct things. > > PPK-only authentication is in fact the NULL authentication > method used with PPK, so if using PPK is optional for both peers, > then the described attack works even without QC, the attacker > just removes all PPK related stuff from the messages. > > Note, that 5.2.3 requires that PPK is mandatory for both peers > for PPK-only authentication to work. Yes, I do remember that, and am happy to see that requirement. > > If the attacker manages to inject this packet before the responder > > sends a genuine response, then the initiator would abort the > > exchange. To thwart this kind of attack it is RECOMMENDED, that if > > using PPKs is mandatory for the initiator and the received response > > doesn't contain the USE_PPK notification, then the initiator doesn't > > abort the exchange immediately, but instead waits some time for more > > responses (possibly retransmitting the request). If all the received > > > > I expect that some reviewer is going to note that this recommendation > > only occurs in the security considerations section and suggest moving it > > to the body of the document, and also that we will be asked to give more > > concrete guidance about "some time". I don't think either change is > > critical to make, but consider yourself forewarned... > > OK, we'll consider :-) > > > Section 7 > > > > We should have a registration template for what information new > > registration requests should include. (In particular, since we allow > > changing entries, a "change controller" and contact information will be > > needed.) I suggest including a column for "reference to specification > > (if available)", even though the "Expert Review" policy does not > > strictly require one. We could also provide some guidance to the DEs as > > to what criteria they may or may not want to apply in deciding whether > > to approve or reject a registration request. > > Adding a reference column makes a lot of sense, thanks. > > > Appendix A > > > > A fourth goal was to avoid violating any of the security goals of > > IKEv2. > > > > nit: It is sometimes considered good style to avoid using the same word > > too much in close succession (here, "goal"); would it change the meaning > > to say "the security properties provided by IKEv2"? > > OK, thanks. Thanks, Ben From nobody Tue Nov 5 14:44:51 2019 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 1B662120025; Tue, 5 Nov 2019 14:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cucmqs5MX0Ly; Tue, 5 Nov 2019 14:44:48 -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 59AFF120018; Tue, 5 Nov 2019 14:44:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4774VQ1FbQzFk4; Tue, 5 Nov 2019 23:44:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572993886; bh=6e0rwcTYJDTjZpkwyjbQY0oqsyaJZiBUqtaT6gyzZm0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rEzpI2Xm0f8OtZ7IsLG5GaLZpHwFF1+ZL2QudbxZrnGRpFUIPXYxwkpvs6fb/SRT2 XJbrZhVXnWHCCTK+Q2fEbS+lxszhY+YpCEM+nMpSX17E0HB6fGnar6PbZ8yfoYnJGC kpqodiKyWELMY7wQ3p0+jFgZsKr6ENKyJivE5eyQ= 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 cluyVpZcIK8y; Tue, 5 Nov 2019 23:44:43 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 5 Nov 2019 23:44:43 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 045BB607CBF4; Tue, 5 Nov 2019 17:44:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 031C223D09C; Tue, 5 Nov 2019 17:44:42 -0500 (EST) Date: Tue, 5 Nov 2019 17:44:41 -0500 (EST) From: Paul Wouters To: Benjamin Kaduk cc: Valery Smyslov , ipsec@ietf.org, draft-ietf-ipsecme-qr-ikev2.all@ietf.org In-Reply-To: <20191105195939.GH61969@kduck.mit.edu> Message-ID: References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 22:44:50 -0000 On Tue, 5 Nov 2019, Benjamin Kaduk wrote: > Oh, this is probably the key part of my confusion/misunderstanding with the > terminology (which also shows up later on, IIRC). > Namely, that the initial exchange generates an IKE SA, and the other SAs > ("children" for ESP/AH usage) are called IPsec SAs (not IKE SAs). > In that case this text is fine as-is and there's nothing to change, so > sorry for the noise. Sorry, I do want to clarify this to be sure you got it completely right: In IKEv1, you first setup an IKE SA (then called ISAKMP SA) using eiher the Main or Aggress Mode Exchange, and then you do one or more Quick Mode Exchanges to setup the first and subsequent IPsec SA's. In IKEv2, the Initial Exchanges (1 IKE_SA_INIT plus 1 IKE_AUTH exchange) create one IKE SA (now called Parent SA) nd one IPsec SA (now also called Child SA) at the same time. Additional IPsec SA's can be created using the CREATE_CHILD_SA exchange. In IKEv2, we don't talk about ISAKMP SA anymore. I think people hoped that in IKEv2 we would not talk about IKE SA and IPsec SA anymore (but only talk about Parent SA and Child SA) but I don't think in reality that is happening. I know our developers continue to disagree about what to call certain things in code and documentation :) This all does make it a little confusing. I can recommend the new NIST Guide to IPsec VPNs SP800-77r1 document where I explain all these terms as well :) >>> <-- HDR, SK {AUTH, SAr2, TSi, TSr >>> [, N(PPK_IDENTITY)]} >>> >>> Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as >>> optional here in the EAP case but not in the previous diagram for the >>> non-EAP case? >> >> In the previous diagram we consider only the case when using >> PPK is agreed upon, so N(PPK_IDENTITY) is not optional. This btw, is a little weird. I think it is better to have the "generic" exchange documented, and in the text write specific examples of when payloads are or aren't t there. I think the figures/diagrams should be drawn to represent the generic case, where it should be optional because if it does not know the right PPK_ID, it will not send the notify. That is, the diagrams should represent the state machine, not an example of the state machine. Paul From nobody Tue Nov 5 23:49:48 2019 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 DFB15120C01; Tue, 5 Nov 2019 23:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q4lDvhfsSGU; Tue, 5 Nov 2019 23:49:43 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D43120BFF; Tue, 5 Nov 2019 23:49:43 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iSG4P-0005T5-Ue; Wed, 06 Nov 2019 10:49:38 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iSG4P-0005m1-Ga; Wed, 06 Nov 2019 10:49:37 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 6 Nov 2019 10:49:37 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 6 Nov 2019 10:49:37 +0300 From: Valery Smyslov To: 'Benjamin Kaduk' CC: , References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> In-Reply-To: <20191105195939.GH61969@kduck.mit.edu> Date: Wed, 6 Nov 2019 10:49:40 +0300 Message-ID: <06dd01d59476$befb9c30$3cf2d490$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL0a9Ttu9PudiK014soS4Z/m3iG4QIy6txqAr5BIRClGHn0MA== Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/11/06 06:20:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/11/06 05:19:00 #14339377 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 07:49:47 -0000 Hi Ben, please see inline (I removed those parts of the message that seem to be resolved). > > > It is an open question whether or not it is feasible to build a > > > Quantum Computer (and if so, when one might be implemented), but if > > > > > > Feasibility of some quantum computer is becoming much less of an open > > > question; perhaps we want some qualifiers about efficiency, scale, > > > and/or general-purpose-nature. > > > > Do you have any data or pointers? > > I'm mostly just thinking about press releases from D-WAVE and Google that > get turned into articles in the technology press. We see headlines about > 60+ q-bit machines, that more likely than not are doing *something*. So in > my mind it becomes a question of whether what these machines (that exist and > are being sold) are doing is useful for the problems relevant to a given > technology, rather than whether a quantum computer exists. (I'm not even > sure that there's a generally accepted definition for what "quantum > computer" means -- some people seem to use it for just annealing-based > stuff.) Probably, if we add a qualifier "full-scale Quantum Computer" then the text will become less questionable? Something like this: It is an open question whether or not it is feasible to build a large-scale Quantum Computer (and if so, when one might be implemented), but if it is, many of the cryptographic algorithms and protocols currently in use would be insecure. Or are you suggesting to rephrase the sentence completely? E.g.: Recent achievements in developing Quantum Computers (QC) demonstrate that it is probably feasible to build a large scale QC. If such a QC is implemented, many of the cryptographic algorithms and protocols currently in use would be insecure. > > > would be compromised. IKEv1 [RFC2409], when used with strong > > > preshared keys, is not vulnerable to quantum attacks, because those > > > keys are one of the inputs to the key derivation function. If the > > > preshared key has sufficient entropy and the PRF, encryption and > > > authentication transforms are postquantum secure, then the resulting > > > system is believed to be quantum resistant, that is, invulnerable to > > > an attacker with a Quantum Computer. > > > > > > Do we have a reference for this "it is believed", or is it just the > > > outcome of the WG discussions? > > > > I'll let my co-authors comment on this, but I think it is meant > > that according to our best current knowledge nothing > > better than Grover's algorithm can be used to break symmetric > > key cryptosystem with QC. And Grover's algorithm only > > halves an effective key length, so if longer PSK is used, we're safe > > (we believe we are). > > To be clear: I share this belief! :) > I am just asking if it is sufficiently well-known/widespread that no > reference is needed; that may well be the case. I believe it is, but I again prefer someone more knowledgeable in QC than myself to comment. > > > The general idea is that we add an additional secret that is shared > > > between the initiator and the responder; this secret is in addition > > > to the authentication method that is already provided within IKEv2. > > > We stir this secret into the SK_d value, which is used to generate > > > the key material (KEYMAT) and the SKEYSEED for the child SAs; this > > > secret provides quantum resistance to the IPsec SAs (and any child > > > IKE SAs). We also stir the secret into the SK_pi, SK_pr values; this > > > allows both sides to detect a secret mismatch cleanly. > > > > > > With apologies for the pedanticism, let's be careful what wording we > > > use, as just mixing into SK_d is not necessarily enough to get quantum > > > resitsance for the parent IPsec SA. > > > [need to check this some more] > > > > Well, there is no "parent IPsec SA" in IKEv2, all the IPsec SAs > > are children of an IKE SA. They are created using SK_d as a key, > > so if PPK is mixed into SK_d, then all Child IIPsec) SAs are protected. > > Moreover, the SK_d is used when IKE SA is rekeyed as one of the inputs > > for computation of new keys, so once IKE SA is rekeyed, the new > > IKE SA will be QC-resistant too. > > Oh, this is probably the key part of my confusion/misunderstanding with the > terminology (which also shows up later on, IIRC). > Namely, that the initial exchange generates an IKE SA, and the other SAs > ("children" for ESP/AH usage) are called IPsec SAs (not IKE SAs). > In that case this text is fine as-is and there's nothing to change, so > sorry for the noise. Almost true. The initial pair of exchanges (IKE_SA_INIT & IKE_AUTH) generate an IKE SA and a single (to be exact - a single pair of) IPsec SA, which in RFC7296 is called Child SA. This initial IKE SA can be used later to create as many additional IPsec (Child) SAs, as peers want (with CREATE_CHILD_SA exchange). At some point of time the initial IKE SA can be rekeyed (again with CREATE_CHILD_SA) and after this point is deleted. The newly created IKE SA replaces it and is used for creating additional IPsec (Child) SAs. With QR draft all these SAs (both IKE SAs and Child SAs) except for the initial IKE SA are protected with PPK. The initial IKE SA (those created with IKE_SA_INIT and IKE_AUTH) doesn't have this protection. > > > Section 2 > > > > > > We assume that each IKE peer has a list of Postquantum Preshared Keys > > > (PPK) along with their identifiers (PPK_ID), and any potential IKE > > > initiator has a selection of which PPK to use with any specific > > > responder. In addition, implementations have a configurable flag > > > > > > nit: I'm not sure what "has a selection of" is intended to mean. Is it > > > more about making a choice of which PPK to use or about having a list to > > > choose from? > > > > The former - making a choice of which PPK to use with any > > specific responder. Do you think it should be rephrased? > > I'd suggest "any potential IKE initiator selects which PPK to use with any > specific responder". (The other case involves the word "selection" in the > sense of "this restaurant has a large selection of wines", but we want the > verb form of "selection".) OK, thanks. > > > If the responder did not include the USE_PPK notification and using a > > > PPK for this particular responder is optional, then the initiator > > > continues with the IKEv2 protocol as normal, without using PPKs. > > > > > > Do we want to say anything about logging or notifications for this case, > > > in case someone is concerned about the level of quantum-resistance in > > > use? > > > > Hmmm. I think that we follow RFC 7296 tradition that leaves > > all logging (and the like) up to implementations... > > If we do that, I'd suggest a little more exposition in the security > considerations about how operational misconfiguration or similar could > result in PPKs not being used, unless the "PPK is mandatory" knob is > switched on. OK. > > > That is, we use the standard IKEv2 key derivation process except that > > > the three subkeys SK_d, SK_pi, SK_pr are run through the prf+ again, > > > this time using the PPK as the key. Using prf+ construction ensures > > > > > > Do we want to say anything about why only these three values need the > > > PPK mixed in to them? (I guess the idea is that the parent SA is > > > "short-lived" on the timescale of a quantum computer and the messages > > > protected directly by it are not of interest to an attacker years in the > > > future. This does mean that this scheme does not provide much value > > > when a quantum computer is available at the time of the exchange, > > > though, right? > > > > No, the reason is different. The PPK_ID is sent in the IKE_AUTH, > > that is protected by the SK_ei/er/ai/ar keys. If these keys were > > dependent on PPK, then in case of PPK mismatch the responder > > would not be able to decrypt the message and thus cannot handle > > this situation properly. We ran into this problem with IKEv1, > > when PSK was stirred into key computation and in case of PSK mismatch > > the responder received garbage, and wasn't able to recover gracefully. I must correct myself here - one more (and even more important) reason not to stir PPK into SK_ei/er keys is that the PPK identity is sent in IKE_AUTH request that is encrypted using SK_ei. If we mix PPK into it, then the responder must select the right PPK to decrypt the message without knowing its ID, that it gets only after decryption. Chicken and eggs problem. > > For this reason it was decided by the WG to only mix PPK into SK_d > > and SK_pi/pr, leaving it out from SK_ei/er/ai/ar. This leaves > > initial IKE SA not protected against QC, but allows the protocol to > > handle PPK mismatch gracefully. > > Ah, okay. (I think this is discussed adequately later on in the document, > so don't feel obligated to add any new text here if you don't want to.) OK. > > > Section 5.2.1 > > > > > > I'm kind of confused by the PSKC reference, especially the implication > > > ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the > > > PIN") that a fixed string is to be used as a PIN. (I also think it's > > > better to discuss what it does as "key transport" than "key exchange", > > > noting that the latter string does not appear in RFC 6030.) > > > > I recall it was requested by somebody during discussion in the WG... > > To be clear, unless someone can explain to me how I'm misunderstanding the > current text (and thus that the current text makes sense), I object to the > current description. It doesn't give me a clear picture of what I'd need > to do to use it, and what it seems to describe sounds insecure based on my > preconceptions of the terminology used. (I have no prior experience with > PSKC, to be clear.) I tend to agree with you here, but I hope someone in the WG who asked for this text will chime in :-) Thank you, Valery. > Thanks, > > Ben From nobody Tue Nov 5 23:55:47 2019 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 3E20B120C01; Tue, 5 Nov 2019 23:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cElYVfTmeBTL; Tue, 5 Nov 2019 23:55:45 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6D0120BFF; Tue, 5 Nov 2019 23:55:44 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iSGAH-0005YO-S9; Wed, 06 Nov 2019 10:55:41 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iSGAH-0005qi-FL; Wed, 06 Nov 2019 10:55:41 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 6 Nov 2019 10:55:41 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 6 Nov 2019 10:55:41 +0300 From: Valery Smyslov To: 'Paul Wouters' , 'Benjamin Kaduk' CC: , References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> In-Reply-To: Date: Wed, 6 Nov 2019 10:55:44 +0300 Message-ID: <06de01d59477$97f347e0$c7d9d7a0$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL0a9Ttu9PudiK014soS4Z/m3iG4QIy6txqAr5BIRAB8BMI8aUJC/Jw Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/11/06 06:20:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/11/06 05:19:00 #14339377 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 07:55:46 -0000 Hi Paul, > >>> <-- HDR, SK {AUTH, SAr2, TSi, TSr > >>> [, N(PPK_IDENTITY)]} > >>> > >>> Am I missing something subtle as to why N(PPK_IDENTIFY) is listed as > >>> optional here in the EAP case but not in the previous diagram for the > >>> non-EAP case? > >> > >> In the previous diagram we consider only the case when using > >> PPK is agreed upon, so N(PPK_IDENTITY) is not optional. > > This btw, is a little weird. I think it is better to have the "generic" > exchange documented, and in the text write specific examples of when > payloads are or aren't t there. I think the figures/diagrams should be > drawn to represent the generic case, where it should be optional because > if it does not know the right PPK_ID, it will not send the notify. Do you think the current diagrams are confusing? > That is, the diagrams should represent the state machine, not an > example of the state machine. Hmmmm... It's an open question :-) Aa a counter-example, the EAP and non-EAP case of IKEv2 are not shown on the same diagrams - these are different diagrams, however the state machine for IKE_AUTH is the same. I think diagrams (at least in IKE) don't replace state machine description and are mostly used for clarity. Regards, Valery. > > Paul From nobody Wed Nov 6 00:05:53 2019 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 AF832120BFF; Wed, 6 Nov 2019 00:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGBKpHldaMml; Wed, 6 Nov 2019 00:05:45 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C042A120C01; Wed, 6 Nov 2019 00:05:44 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iSGJx-0005fR-RO; Wed, 06 Nov 2019 11:05:41 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iSGJx-0005zL-FV; Wed, 06 Nov 2019 11:05:41 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 6 Nov 2019 11:05:41 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 6 Nov 2019 11:05:41 +0300 From: Valery Smyslov To: 'Paul Wouters' , 'Benjamin Kaduk' CC: , References: <20191105023831.GH55993@kduck.mit.edu> In-Reply-To: Date: Wed, 6 Nov 2019 11:05:44 +0300 Message-ID: <06f101d59478$fd95b190$f8c114b0$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL0a9Ttu9PudiK014soS4Z/m3iG4QClFWPTpTru93A= Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/11/06 06:20:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/11/06 05:19:00 #14339377 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 08:05:47 -0000 Hi Paul, > [ignoring the nits and leaving that to the authors, although reading it > again I would like to see "he" and "she" replaced by "it" everwhere] Is it your strong preference? For me it's easier to use "it" everywhere, but I'd like to see some advice from native speakers... Regards, Valery. > Paul From nobody Wed Nov 6 06:42:58 2019 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 4B7451208B6 for ; Wed, 6 Nov 2019 06:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpBYB1FaL8mM for ; Wed, 6 Nov 2019 06:42:55 -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 E3CF51200F9 for ; Wed, 6 Nov 2019 06:42:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 477Tlx5CH0zFby; Wed, 6 Nov 2019 15:42:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1573051373; bh=lDAXHi5FUcnox3VtYQyBr7ROnwuQ4RUNGTqRTmEO41Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cqs5vOw9V/VkY+ZVt28Oy3lDPycarJvqCwzwq4fQIuCxsPIl9W765foX48MD/F7KQ hOsjeyPC1FVCs63ees6n59tX3TzfqdEPM8ctC7Di42yEkbhjs3I07Gix4GdDEAXrCJ e260O14qDL/YuMNTdtUV8BoJ5N8vQ0XHse/Tutyg= 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 floLxigcrcqx; Wed, 6 Nov 2019 15:42:52 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 6 Nov 2019 15:42:52 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 964DF6001610; Wed, 6 Nov 2019 09:42:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 92B5423D09A; Wed, 6 Nov 2019 09:42:51 -0500 (EST) Date: Wed, 6 Nov 2019 09:42:51 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" In-Reply-To: <06de01d59477$97f347e0$c7d9d7a0$@elvis.ru> Message-ID: References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> <06de01d59477$97f347e0$c7d9d7a0$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 14:42:56 -0000 On Wed, 6 Nov 2019, Valery Smyslov wrote: > Do you think the current diagrams are confusing? Yes. Because often I go back to RFCs and only look at the diagrams expecting it to be what I need to implement. So for optional/required payloads, I would mostly look at the diagram, and perhaps read a bit of text. >> That is, the diagrams should represent the state machine, not an >> example of the state machine. > > Hmmmm... It's an open question :-) Aa a counter-example, > the EAP and non-EAP case of IKEv2 are not shown > on the same diagrams - these are different diagrams, > however the state machine for IKE_AUTH is the same. Sure. > I think diagrams (at least in IKE) don't replace state machine > description and are mostly used for clarity. We even put the diagrams in some of our code comments. It's used for more than just clarity by us :) Paul From nobody Wed Nov 6 08:42:35 2019 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 4BB87120089; Wed, 6 Nov 2019 08:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=W+0wtzUl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qR+H7Nv1 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 Os8iGPmkclvC; Wed, 6 Nov 2019 08:42:31 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23BB8120071; Wed, 6 Nov 2019 08:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4850; q=dns/txt; s=iport; t=1573058551; x=1574268151; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=78N1WwIyOwPjrXMdn+cELaAQN1WfGnTJ2kZo6yyYhkI=; b=W+0wtzUln9v79LCRf17/p7SA6Q2p8q6rJr/fvSMeDJ4pE80xPZLxjG0T PQeGcsTHMTvB9SwP4Cvz4/DtN5+3CT9NFonQSuGrekBbUjEZ3KJQ+7zI0 rLHlMneLRfmgTZsA/zW9U87gMIBlaEC+yyzw3p7rY2RUJuiwSTPo8WgLM 0=; IronPort-PHdr: =?us-ascii?q?9a23=3ACTJ0mxTP1xqznb2r3th6aTuFqdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjc0GNlCTlJ/13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAABf98Jd/4sNJK1lDg0BAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgWoGAQEBCwGBSlAFgUQgBAsqh28DhFqGJIJel36BLhS?= =?us-ascii?q?BEANUCQEBAQwBAS0CAQGEQAKEDiQ0CQ4CAwsBAQQBAQECAQUEbYU3DIVRAQE?= =?us-ascii?q?BAQMSKAYBATcBCwQCAQgOAwQBAR8QMh0IAgQBDQUIEAqFRwMuAQKmXQKBOIh?= =?us-ascii?q?ggieCfgEBBYUFGIIXCYE2AYlKdoFTGIFAP4ERRoFOfj6ELRqDQIIsrgQKgiS?= =?us-ascii?q?VV4I8h12PU45DmWQCBAIEBQIOAQEFgVI5N4EhcBWDJ1ARFIMGg3OKGDt0gSi?= =?us-ascii?q?QYgEB?= X-IronPort-AV: E=Sophos;i="5.68,275,1569283200"; d="scan'208";a="365186525" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Nov 2019 16:42:30 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xA6GgUEJ030939 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Nov 2019 16:42:30 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Nov 2019 10:42:29 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Nov 2019 11:42:29 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 6 Nov 2019 10:42:28 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ImyIEnPMbAzIch90N1qHR7tqITqa7Ba/WYNO7XtbyP4FBA5gCz8grPqR6BG6LPAThOSxa72OGWvHPdvw1OTnGn14pJbS/8QKyZoRkLEXaIeezmqJ4U9iDQGCxP4BbO+jwWlExJZ10BfFDlC0nYhCCZbm51RcHeWYRxb1XVkk2dNVKSFAOasDXk0Xahlm/esAPRhKOhquroJaq8kxGfZGYV3d/653/GMc6hEBDQqp361bYbznFCF/AwQWijYicYPsptyBlGRIRFfvRcZD9xrjTfz3iESDV+8RVyvqTgaDQzOnIaa+L5v5pxqWyyz+/yj2ZE0vLHltrbX4+D7Fcr5WUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VM907wVLO0mtQq7uWxVdDDwbyavaSYFVnzsEhr4L9Tw=; b=mJl7l22qeMUb4eM93cdwZoAK/Qn+ue6IL9jWxm18gmBXyYx+ImwPfldOpWaOm453SkhJvcUh4fTAmEm9CBqG0bhxEGJdBrvpiFHfmSPUhGskZZm0AHKGlxK6vmbyryfDBADjNb/zoLI8gUteZTCnDLT4yY69nwPv9WHrQU7v4d2rBJyDTO7XG69X3nSNdQLq1Snqa9GJF7Eb75EEbRU/BCaoZBkvsohVIb0FpOp5rxjoSV7IiJeAyvHlH9NwihLCx0spWw4FqD3FLoKO8fmbFM9LaEsh5mSSaTDRl8QWM5CuG61rJI2wQr1XOOl3FDUtQ8G8VoZTXmxQHUVzskH16g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VM907wVLO0mtQq7uWxVdDDwbyavaSYFVnzsEhr4L9Tw=; b=qR+H7Nv1quRHLA7Fzw2+JleH56+4K03snV9cBDfq/sjhAvSAHjmteAYcbT+nQDL0EDtCP7NELy9Iec9LGalYY0VsXdl5LKbJf/iaFqiPdfL/uasGpH71cmdnl1zzQHpCwDXCspD4se0o4JEF4q6MhEQtq+1ktW8qtOyHKO4qRos= Received: from BN8PR11MB3666.namprd11.prod.outlook.com (20.178.221.19) by BN8PR11MB3681.namprd11.prod.outlook.com (20.178.219.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Wed, 6 Nov 2019 16:42:27 +0000 Received: from BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b]) by BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b%7]) with mapi id 15.20.2408.024; Wed, 6 Nov 2019 16:42:27 +0000 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , "'Benjamin Kaduk'" CC: "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , "ipsec@ietf.org" Thread-Topic: AD review of draft-ietf-ipsecme-qr-ikev2-08 Thread-Index: AQHVk4InqawYRzoDUUa9kWZivMLdT6d8oxOAgABdBYCAAMZgAIAAkWJw Date: Wed, 6 Nov 2019 16:42:27 +0000 Message-ID: References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> <06dd01d59476$befb9c30$3cf2d490$@elvis.ru> In-Reply-To: <06dd01d59476$befb9c30$3cf2d490$@elvis.ru> 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=sfluhrer@cisco.com; x-originating-ip: [2001:420:c0c8:1004::762] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b29431c-20a2-4efa-73a6-08d762d84f18 x-ms-traffictypediagnostic: BN8PR11MB3681: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(366004)(376002)(136003)(13464003)(199004)(189003)(40154002)(66556008)(66946007)(5660300002)(6246003)(66476007)(305945005)(71190400001)(71200400001)(66446008)(64756008)(76116006)(54906003)(478600001)(99286004)(14444005)(316002)(256004)(52536014)(110136005)(14454004)(7736002)(25786009)(2906002)(446003)(6116002)(102836004)(8936002)(6436002)(46003)(81156014)(81166006)(7696005)(6506007)(53546011)(76176011)(33656002)(486006)(8676002)(476003)(55016002)(4326008)(11346002)(2171002)(74316002)(229853002)(86362001)(186003)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3681; H:BN8PR11MB3666.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eIG7EmCGPJ0Qdfr85iNf7bL2TUwhXkUw8AnCVFk/xICBr98x33fSeUifSY6hX+hP4SPiZAQjYIyzJOb0bV/MRZfAQ/eVHXIUO+Q3Sv9XelvcZb1v7bA0cpecw4RlNoF0VLs2YAOGGKRnWRNaVhnPNL2+RLj2iVkfkTQ1oFz1D6Hqeka1j8zqmMI+Iat4omIvrrBizDldm49Pq53AYWmSK9iDaYMDywDsTThqT2HzSIv4cf0CKds1fJsn/MT2WcMjo9/Q+fAHMuZvP2wePVAvLVEN5fauh0RHPe1LEnN83SYDmHxu7FoigFii7LZhRz8G2zCxbKlSUqWBABy19J8JT2nLXI/es5kwk3jHWO8U9Jxf0wYufF3tWqx37Msz/HpPqHFeFMFWsbuS8HiyxnLZVv75mZXLyYyyvS4IuWsGtM5z9s6PWaYYkaA+BbaZXjqc x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0b29431c-20a2-4efa-73a6-08d762d84f18 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 16:42:27.3666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bxxoTW9jW1OLsXfQcx1IMlPG2D5FUbRdAN6HgyeEM80lRjrG10VoQuNLMW79jIlrXf90w0eG2aPHHIWCnrczIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3681 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 16:42:33 -0000 > -----Original Message----- > From: Valery Smyslov > Sent: Wednesday, November 06, 2019 2:50 AM > To: 'Benjamin Kaduk' > Cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org; ipsec@ietf.org > Subject: RE: AD review of draft-ietf-ipsecme-qr-ikev2-08 >=20 > Hi Ben, >=20 > please see inline (I removed those parts of the message that seem to be > resolved). >=20 > > > > It is an open question whether or not it is feasible to build a > > > > Quantum Computer (and if so, when one might be implemented), > > > > but if > > > > > > > > Feasibility of some quantum computer is becoming much less of an > > > > open question; perhaps we want some qualifiers about efficiency, > > > > scale, and/or general-purpose-nature. > > > > > > Do you have any data or pointers? > > > > I'm mostly just thinking about press releases from D-WAVE and Google > > that get turned into articles in the technology press. We see > > headlines about > > 60+ q-bit machines, that more likely than not are doing *something*. > > 60+ So in > > my mind it becomes a question of whether what these machines (that > > exist and are being sold) are doing is useful for the problems > > relevant to a given technology, rather than whether a quantum computer > > exists. (I'm not even sure that there's a generally accepted > > definition for what "quantum computer" means -- some people seem to > > use it for just annealing-based > > stuff.) >=20 > Probably, if we add a qualifier "full-scale Quantum Computer" then the te= xt > will become less questionable? Something like this: >=20 > It is an open question whether or not it is feasible to build a larg= e-scale > Quantum Computer > (and if so, when one might be implemented), but if it is, many of t= he > cryptographic algorithms > and protocols currently in use would be insecure. >=20 > Or are you suggesting to rephrase the sentence completely? E.g.: >=20 > Recent achievements in developing Quantum Computers (QC) > demonstrate that > it is probably feasible to build a large scale QC. If such a QC is im= plemented, > many of the cryptographic algorithms and protocols currently in use w= ould > be insecure. I'd suggest using the phrase "cryptographically significant Quantum Compute= r". The problems that you find in cryptography do need more qubits than cu= rrent Quantum Computers possess; however they also need to perform millions= of operations without significant error, and that would appear to be a mor= e serious hurdle. >=20 > > > > would be compromised. IKEv1 [RFC2409], when used with strong > > > > preshared keys, is not vulnerable to quantum attacks, because th= ose > > > > keys are one of the inputs to the key derivation function. If t= he > > > > preshared key has sufficient entropy and the PRF, encryption and > > > > authentication transforms are postquantum secure, then the resul= ting > > > > system is believed to be quantum resistant, that is, invulnerabl= e to > > > > an attacker with a Quantum Computer. > > > > > > > > Do we have a reference for this "it is believed", or is it just > > > > the outcome of the WG discussions? > > > > > > I'll let my co-authors comment on this, but I think it is meant that > > > according to our best current knowledge nothing better than Grover's > > > algorithm can be used to break symmetric key cryptosystem with QC. > > > And Grover's algorithm only halves an effective key length, so if > > > longer PSK is used, we're safe (we believe we are). > > > > To be clear: I share this belief! :) > > I am just asking if it is sufficiently well-known/widespread that no > > reference is needed; that may well be the case. >=20 > I believe it is, but I again prefer someone more knowledgeable in QC than > myself to comment. Breaking it down, we come up with four propositions: - Grover's attack would require a huge number of operations against a suffi= ciently long secret. - This huge number of operations is infeasible against any plausible operat= ion. - Any attack better than Grovers would require attacking the function at a = lower level than a black box - No such insight is known. The first can easily be cited (e.g. the original Grover paper). The second= one is generally believed, but the exact length of the secret would depend= on the eventual speed/scale of a quantum computer, which is somewhat unkno= wn. The third is also citable (again, the original Grover paper). The fourth i= s problematic, because it is essentially an argument from a lack of knowled= ge. Personally, I believe that this sort of argument is well known enough (at l= east, to the people who know postquantum cryptography) that it would not be= required. From nobody Wed Nov 6 09:41:25 2019 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 EFA42120112 for ; Wed, 6 Nov 2019 09:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1gkyLYtvfRc for ; Wed, 6 Nov 2019 09:41:22 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7D1200B4 for ; Wed, 6 Nov 2019 09:41:22 -0800 (PST) Received: from stubbs.int.chopps.org (172-222-100-236.res.spectrum.com [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 80EED60195; Wed, 6 Nov 2019 17:41:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Christian Hopps In-Reply-To: <23988.25468.681313.594115@fireball.acr.fi> Date: Wed, 6 Nov 2019 12:41:20 -0500 Cc: Christian Hopps , ipsec@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <5EDD9B9B-D43C-4B43-9A16-A0A917BB6854@chopps.org> References: <23988.25468.681313.594115@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 17:41:24 -0000 Hi, So did the adoption poll succeed? :) Thanks, Chris. > On Oct 26, 2019, at 11:17 AM, Tero Kivinen wrote: > > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did have quite positive feedback in last IETF meeting and the charter > item is being worked on in parallel to this call. > > If you support adopting this document as WG document and as a starting > place for the charter item proposed for the WG, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to list too. > > This adoption call finishes at 2019-11-04. > > ---------------------------------------------------------------------- > The demand for Traffic Flow Confidentiality has been increasing in the user > community; however, the current method defined in RFC4303 (i.e., add null > padding to each ESP payload) is very inefficient in it's use of network > resources. The working group will develop an alternative TFC solution that > provides for efficient use of network resources. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Nov 7 08:51:03 2019 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 9269B120113; Thu, 7 Nov 2019 08:50:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.110.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , kivinen@iki.fi, ipsec@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157314545559.2171.3514721523687797841.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2019 08:50:55 -0800 Archived-At: Subject: [IPsec] Protocol Action: 'Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)' to Proposed Standard (draft-ietf-ipsecme-implicit-iv-11.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 16:50:56 -0000 The IESG has approved the following document: - 'Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)' (draft-ietf-ipsecme-implicit-iv-11.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Alexey Melnikov, Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ Technical Summary This document defines a way to omit the nonce from ESP packets when using algorithms for which the nonce is entirely predictable and calculable from the packet counter. This reduces per-packet overhead by 8 octets. Working Group Summary The document has been highly reviewed and discussed and presented during meetings and through the mailing list. The implicit iv draft was first expressed in [draft-mglt-ipsecme-diet-esp] { 00: March 2014, 01 Jul 2014 } and presented during the IETF89 in London on March 2014 at the ipsecme session [1]. The discussions lead to the following draft focusing on implicit IV within the ipsecme WG : [draft-mglt-ipsecme-diet-esp-iv-generation ] { 00 : Jul 2014 }. We were suggested then to move this work in 6lo with lead to the following draft [draft-mglt-6lo-aes-implicit-iv] { 00 : Dec 2014, 01 : Feb 2015} that have been presented in the IETF 92 ipsecme session [2]. Implicit IV as well as diet-esp has been presented in the IETF96 in Berlin [3] in July 2016, where 6lo chairs and ipsecme chairs agree that the right place to host this work was ipsecme. [draft-mglt-ipsecme-implicit-iv] was then release in June 2016 and adopted as a WG document in November 2017. This draft extended the work from AES to ChaCha20Poly1305. The document has been presented to the ipsecme WG during the IETF89 [1], IETF92[2], IETF96[3], IETF97[5], IETF98[6], IETF99[7]. [draft-mglt-ipsecme-diet-esp] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ [draft-mglt-ipsecme-implicit-iv] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ [1] https://www.ietf.org/proceedings/89/slides/slides-89-ipsecme-3.pdf [2] https://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-3.pdf [3] https://www.ietf.org/proceedings/96/slides/slides-96-6lo-9.pdf [4] https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf [5] https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-draft-ietf-ipsecme-eddsa-draft-mglt-ipsecme-implicit-iv-00.pdf [6] https://www.ietf.org/proceedings/98/slides/slides-98-ipsecme-implicit-iv-00.pdf [7] https://datatracker.ietf.org/meeting/99/materials/slides-99-ipsecme-implicit-iv-00 Document Quality Apple has reported to have a kernel implementation. During the DevNet conference in Montreal, the IPsec maintainer of Linux mentioned that he is he waiting to have this as an RFC before implementing it. This does not necessarily means that will be its highest priority. There are implementations based in C/Python scripts as well as ongoing implementations on Riot. Personnel Tero Kivinen is the document shepherd and Alexey Melnikov is the responsible AD. From nobody Thu Nov 7 16:32:12 2019 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 237B4120147 for ; Thu, 7 Nov 2019 16:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 Lp-FvbSEJg96 for ; Thu, 7 Nov 2019 16:32:08 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3E8120018 for ; Thu, 7 Nov 2019 16:32:08 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id 6DD8525C177A; Fri, 8 Nov 2019 02:32:04 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24004.46980.388821.533535@fireball.acr.fi> Date: Fri, 8 Nov 2019 02:32:04 +0200 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org In-Reply-To: <5EDD9B9B-D43C-4B43-9A16-A0A917BB6854@chopps.org> References: <23988.25468.681313.594115@fireball.acr.fi> <5EDD9B9B-D43C-4B43-9A16-A0A917BB6854@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 00:32:11 -0000 Christian Hopps writes: > So did the adoption poll succeed? :) Yes. I did not see anybody objecting to it and there was all usual suspects supporting it. The problem why I could not mark it as done is that I had some problems with my firewall/mailserver/www-server etc and I reinstalled the whole thing trying to verify whether it is hardware or software issues, and this operation took several days instead of few hours it was supposed to do... > Thanks, > Chris. > > > On Oct 26, 2019, at 11:17 AM, Tero Kivinen wrote: > > > > So this is fast (one week) adoption call for the > > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > > did have quite positive feedback in last IETF meeting and the charter > > item is being worked on in parallel to this call. > > > > If you support adopting this document as WG document and as a starting > > place for the charter item proposed for the WG, then send email > > indicating your support to the ipsec@ietf.org mailing-list. If you > > have any comments or reservations send them to list too. > > > > This adoption call finishes at 2019-11-04. > > > > ---------------------------------------------------------------------- > > The demand for Traffic Flow Confidentiality has been increasing in the user > > community; however, the current method defined in RFC4303 (i.e., add null > > padding to each ESP payload) is very inefficient in it's use of network > > resources. The working group will develop an alternative TFC solution that > > provides for efficient use of network resources. > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > -- kivinen@iki.fi From nobody Thu Nov 7 16:36:40 2019 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 B36C61201B7 for ; Thu, 7 Nov 2019 16:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 Xw1C7iOJI3yf for ; Thu, 7 Nov 2019 16:36:35 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B62120018 for ; Thu, 7 Nov 2019 16:36:35 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id CACE725C177B; Fri, 8 Nov 2019 02:36:32 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24004.47248.804169.798841@fireball.acr.fi> Date: Fri, 8 Nov 2019 02:36:32 +0200 From: Tero Kivinen To: Paul Wouters Cc: Valery Smyslov , "ipsec\@ietf.org WG" In-Reply-To: References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> <06de01d59477$97f347e0$c7d9d7a0$@elvis.ru> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 00:36:37 -0000 Paul Wouters writes: > On Wed, 6 Nov 2019, Valery Smyslov wrote: > > > Do you think the current diagrams are confusing? > > Yes. Because often I go back to RFCs and only look at the diagrams > expecting it to be what I need to implement. So for optional/required > payloads, I would mostly look at the diagram, and perhaps read a bit > of text. That is the reason we added Appendix C in the IKEv2. So my proposal is to leave the exchanges inside the text as they are, but add new Appendix that has the different exchanges including the optional payloads. > >> That is, the diagrams should represent the state machine, not an > >> example of the state machine. > > > > Hmmmm... It's an open question :-) Aa a counter-example, > > the EAP and non-EAP case of IKEv2 are not shown > > on the same diagrams - these are different diagrams, > > however the state machine for IKE_AUTH is the same. > > Sure. In RFC7296 Appendix C we do have C.2 IKE_AUTH Exchange without EAP, and C.3 IKE_AUTH Exchange with EAP. And I would say that the state machine for IKE_AUTH for them are different, the state machine for IKE_SA_INIT is same for both and is not included in C.2, or C.3, both of them use the IKE_SA_INIT from C.1 -- kivinen@iki.fi From nobody Thu Nov 7 17:00:45 2019 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 A6DE51201B7; Thu, 7 Nov 2019 17:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 PelsRTpAVfam; Thu, 7 Nov 2019 17:00:41 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3C2120018; Thu, 7 Nov 2019 17:00:40 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id 9086A25C178C; Fri, 8 Nov 2019 03:00:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24004.48693.528411.949232@fireball.acr.fi> Date: Fri, 8 Nov 2019 03:00:37 +0200 From: Tero Kivinen To: Benjamin Kaduk Cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org, ipsec@ietf.org In-Reply-To: <20191105023831.GH55993@kduck.mit.edu> References: <20191105023831.GH55993@kduck.mit.edu> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 24 min X-Total-Time: 24 min Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 01:00:44 -0000 Benjamin Kaduk writes: > Section 3 > > N(USE_PPK) is a status notification payload with the type 16435; it > has a protocol ID of 0, no SPI and no notification data associated > with it. > > [check the IANA status of the value] As others already commented I as an IANA Expert for those registries did do an assignment for those notification values, as they were stable enough already in 2018 February... Creating new registry could not be done as expert review, so that creation PPK_ID type registry was left to this document. Of course there was no problem with using the numbers, as there is nobody else who can allocate things from that registry as that registry does not yet exists. > value. Not all implementations are able to configure arbitrary > octet strings; to improve the potential interoperability, it is > recommended that, in the PPK_ID_FIXED case, both the PPK and the > PPK_ID strings be limited to the base64 character set, namely the > 64 characters 0-9, A-Z, a-z, + and /. > > I don't have much experience with the conventions in this space; does it > make sense to distinguish between the PPK representation as configured > (which would use the base64 alphabet) and the "actual PPK" that could be > binary after, e.g., a base64-decoding step? I guess it could be > reasonable to rely on the ability of the PRF to take an arbitrary-length > input and just have sufficient entropy even while limiting the PPK value > to the base64 alphabet. We had long discussion this in one of the meetings some time ago, and I think the problem is that some implementations use configuration files where they write the keys directly, some use config files pointing to the file on the disk, and some use some database backend, and then there are the ones that use GUI to enter the key. When you have key "makemetastygoat" that is easy. When you have key which contains NULs, newlines, 8-bit characters etc., there are several cases where you cannot enter such key to configuration of implementation. We decided that base64 is good enough, i.e., the keys do not get too much longer, but every single system should be able to configure key using that charset. As the keys are feed in to the PRF anyways there is no need to require them to be binary, only thing that should matter is how much entropy there is in the key, and with base64 it is easy to calculate. > Section 6 > > We should document the privacy considerations of the PPK_ID both in the > face of an attacker with a quantum computer (now or in the future) and > in the face of a classical attacker. The latter would, IIUC, need to be > an active MITM in order to see anything other than N(USE_PPK), and who > would also get IDi along with the PPK_ID value, so there's not much of a > change in the privacy stance. We did discuss this and decided that it would be possible to protect the identity (IDi, and IDr) using pseudonyms if such thing is needed. I.e., instead of using real IDi and IDr, we use some random identity string. After the IKE SA creation we can do IKE SA rekey to gain QR protection for the IKE SA traffic too, and after that we can agree on the next ID to be used for next connection. This way the identities will be always different and completely random. The PPK_ID does not need to have meaning outside the fact that it identifies the PPK we are going to be using. So it can be random from the beginning, and you can either use similar agreeing on next PPK_IDs after rekey than for IDi/IDr, or you can simply use each PPK only once and generate lots of them before you even start. None of this is written in the draft, as we kept the focus on making IKEv2 quantum resistant and keeping the original properties of the IKEv2 intact otherwise. Adding better identity protection is something that can be done separately and can also be used with or without QR. > Section 7 > > We should have a registration template for what information new > registration requests should include. (In particular, since we allow > changing entries, a "change controller" and contact information will be > needed.) I suggest including a column for "reference to specification > (if available)", even though the "Expert Review" policy does not > strictly require one. We could also provide some guidance to the DEs as > to what criteria they may or may not want to apply in deciding whether > to approve or reject a registration request. As an IANA expert and most likely a candidate for expert for this registry too, I do not think such templates or rules for expert are needed. I hope people will trust experts enough to make smart decisions. In this case I do not think there will be too many new registrations to this registry and in many cases vendors might be using just private use numbers for their internal cases. Some vendor might defined something like PPK_ID_FILE_AND_INDEX where there is first 32-bit index and then filename indicating which one time pad file is used and the index tells you which key inside the file is used. To be able to transmit that file from one device to another both ends needs to understand the file format etc, and if that file format is proprietary then there is no point of using standard PPK_ID type either. -- kivinen@iki.fi From nobody Fri Nov 8 02:09:37 2019 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 E09EE120088 for ; Fri, 8 Nov 2019 02:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDoAhxVq1xKB for ; Fri, 8 Nov 2019 02:09:33 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 56657120077 for ; Fri, 8 Nov 2019 02:09:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 59B57205AE; Fri, 8 Nov 2019 11:09:30 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91KVc6J9OWLO; Fri, 8 Nov 2019 11:09:27 +0100 (CET) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id ECB1A20422; Fri, 8 Nov 2019 11:09:27 +0100 (CET) Received: from MAIL-ESSEN-02.secunet.de ([fe80::4431:e661:14d0:41ce]) by mail-essen-01.secunet.de ([fe80::1c79:38b7:821e:46b4%16]) with mapi id 14.03.0439.000; Fri, 8 Nov 2019 11:09:27 +0100 From: "Bruckert, Leonie" To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 Thread-Index: AQHVkpf3/gT88/YtD06p05DKyCtIRKd8bBWAgASiAQA= Date: Fri, 8 Nov 2019 10:09:27 +0000 Message-ID: References: <23999.22463.132733.702468@fireball.acr.fi> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 10:09:36 -0000 We think that it's very important to add post quantum key exchange to IKEv2= and therefore strongly support adoption. However, there are still some thi= ngs that could be improved further, e.g. transmission of pq keys/cipher te= xts for Child SAs. BTW, we performed an interop test. Valery will present the results at the u= pcoming meeting. Regards Leonie >=20 > Hey, > I also strongly support adoption. >=20 > > It is an open question whether or not it is feasible to build a > > Quantum Computer (and if so, when one might be implemented), but if > > > > Feasibility of some quantum computer is becoming much less of an open > > question; perhaps we want some qualifiers about efficiency, scale, > > and/or general-purpose-nature. > > Do we have a reference for this "it is believed", or is it just the > > outcome of the WG discussions? >=20 > Regarding this discussion (and sorry if this was discussed before and I d= idn't > realize). > Do we really need the term post-quantum in the title (and maybe even in > the abstract)? > The draft tells how to do multiple/hybrid key-exchanges in IKEv2, PQ is t= he > major motivation but not the only use case. > As far as I'm familiar with the draft, you could easily do DH + ECDH with= it (and > if not I'd really like it be like that). >=20 > Regards > Tobias >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: IPsec Im Auftrag von Tero Kivinen > > Gesendet: Sonntag, 3. November 2019 23:42 > > An: ipsec@ietf.org > > Betreff: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev= 2 > > > > This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2 > > draft to be accepted to be WG Document. This draft has been around for > > some time, and we have been discussing it in the meetings. > > > > If you support adopting this document as WG Document, then send email > > indicating your support to the ipsec@ietf.org mailing-list. If you have= any > > comments or reservations send them to the list too. > > > > This adoption call finishes 2019-11-11. > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > 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 Fri Nov 8 12:51:21 2019 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 0A4001208C2; Fri, 8 Nov 2019 12:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iACVDvb75hcF; Fri, 8 Nov 2019 12:51:16 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D8D120871; Fri, 8 Nov 2019 12:51:15 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA8KpBvM020956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Nov 2019 15:51:13 -0500 Date: Fri, 8 Nov 2019 12:51:10 -0800 From: Benjamin Kaduk To: Tero Kivinen Cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org, ipsec@ietf.org Message-ID: <20191108205110.GK47216@kduck.mit.edu> References: <20191105023831.GH55993@kduck.mit.edu> <24004.48693.528411.949232@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24004.48693.528411.949232@fireball.acr.fi> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 20:51:19 -0000 Hi Tero, On Fri, Nov 08, 2019 at 03:00:37AM +0200, Tero Kivinen wrote: > Benjamin Kaduk writes: > > Section 3 > > > > N(USE_PPK) is a status notification payload with the type 16435; it > > has a protocol ID of 0, no SPI and no notification data associated > > with it. > > > > [check the IANA status of the value] > > As others already commented I as an IANA Expert for those registries > did do an assignment for those notification values, as they were > stable enough already in 2018 February... > > Creating new registry could not be done as expert review, so that > creation PPK_ID type registry was left to this document. Of course > there was no problem with using the numbers, as there is nobody else > who can allocate things from that registry as that registry does not > yet exists. > > > value. Not all implementations are able to configure arbitrary > > octet strings; to improve the potential interoperability, it is > > recommended that, in the PPK_ID_FIXED case, both the PPK and the > > PPK_ID strings be limited to the base64 character set, namely the > > 64 characters 0-9, A-Z, a-z, + and /. > > > > I don't have much experience with the conventions in this space; does it > > make sense to distinguish between the PPK representation as configured > > (which would use the base64 alphabet) and the "actual PPK" that could be > > binary after, e.g., a base64-decoding step? I guess it could be > > reasonable to rely on the ability of the PRF to take an arbitrary-length > > input and just have sufficient entropy even while limiting the PPK value > > to the base64 alphabet. > > We had long discussion this in one of the meetings some time ago, and > I think the problem is that some implementations use configuration > files where they write the keys directly, some use config files > pointing to the file on the disk, and some use some database backend, > and then there are the ones that use GUI to enter the key. > > When you have key "makemetastygoat" that is easy. When you have key > which contains NULs, newlines, 8-bit characters etc., there are > several cases where you cannot enter such key to configuration of > implementation. > > We decided that base64 is good enough, i.e., the keys do not get too > much longer, but every single system should be able to configure key > using that charset. > > As the keys are feed in to the PRF anyways there is no need to require > them to be binary, only thing that should matter is how much entropy > there is in the key, and with base64 it is easy to calculate. That's roughly where I ended up after thinking about it, so I'm glad we're all on the same page. (And my apologies for having everyone spend more words on it.) > > Section 6 > > > > We should document the privacy considerations of the PPK_ID both in the > > face of an attacker with a quantum computer (now or in the future) and > > in the face of a classical attacker. The latter would, IIUC, need to be > > an active MITM in order to see anything other than N(USE_PPK), and who > > would also get IDi along with the PPK_ID value, so there's not much of a > > change in the privacy stance. > > We did discuss this and decided that it would be possible to protect > the identity (IDi, and IDr) using pseudonyms if such thing is needed. > I.e., instead of using real IDi and IDr, we use some random identity > string. After the IKE SA creation we can do IKE SA rekey to gain QR > protection for the IKE SA traffic too, and after that we can agree on > the next ID to be used for next connection. This way the identities > will be always different and completely random. > > The PPK_ID does not need to have meaning outside the fact that it > identifies the PPK we are going to be using. So it can be random from > the beginning, and you can either use similar agreeing on next PPK_IDs > after rekey than for IDi/IDr, or you can simply use each PPK only once > and generate lots of them before you even start. > > None of this is written in the draft, as we kept the focus on making > IKEv2 quantum resistant and keeping the original properties of the > IKEv2 intact otherwise. Adding better identity protection is something > that can be done separately and can also be used with or without QR. Okay. > > Section 7 > > > > We should have a registration template for what information new > > registration requests should include. (In particular, since we allow > > changing entries, a "change controller" and contact information will be > > needed.) I suggest including a column for "reference to specification > > (if available)", even though the "Expert Review" policy does not > > strictly require one. We could also provide some guidance to the DEs as > > to what criteria they may or may not want to apply in deciding whether > > to approve or reject a registration request. > > As an IANA expert and most likely a candidate for expert for this > registry too, I do not think such templates or rules for expert are > needed. I hope people will trust experts enough to make smart > decisions. Okay, I'll put that down as "we considered providing guidance but decided not to", which is fine. > In this case I do not think there will be too many new registrations Indeed, I cannot think of many possibilities there. Thanks, Ben From nobody Fri Nov 8 12:53:10 2019 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 51BB4120D34; Fri, 8 Nov 2019 12:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mwcoNxqVgLc; Fri, 8 Nov 2019 12:53:00 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F323120D37; Fri, 8 Nov 2019 12:53:00 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA8KqofA022081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Nov 2019 15:52:52 -0500 Date: Fri, 8 Nov 2019 12:52:49 -0800 From: Benjamin Kaduk To: "Scott Fluhrer (sfluhrer)" Cc: Valery Smyslov , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , "ipsec@ietf.org" Message-ID: <20191108205249.GL47216@kduck.mit.edu> References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> <06dd01d59476$befb9c30$3cf2d490$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 20:53:09 -0000 On Wed, Nov 06, 2019 at 04:42:27PM +0000, Scott Fluhrer (sfluhrer) wrote: > > -----Original Message----- > > From: Valery Smyslov > > Sent: Wednesday, November 06, 2019 2:50 AM > > To: 'Benjamin Kaduk' > > Cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org; ipsec@ietf.org > > Subject: RE: AD review of draft-ietf-ipsecme-qr-ikev2-08 > > > > > > > > > It is an open question whether or not it is feasible to build a > > > > > Quantum Computer (and if so, when one might be implemented), > > > > > but if > > > > > > > > > > Feasibility of some quantum computer is becoming much less of an > > > > > open question; perhaps we want some qualifiers about efficiency, > > > > > scale, and/or general-purpose-nature. > > > > > > > > Do you have any data or pointers? > > > > > > I'm mostly just thinking about press releases from D-WAVE and Google > > > that get turned into articles in the technology press. We see > > > headlines about > > > 60+ q-bit machines, that more likely than not are doing *something*. > > > 60+ So in > > > my mind it becomes a question of whether what these machines (that > > > exist and are being sold) are doing is useful for the problems > > > relevant to a given technology, rather than whether a quantum computer > > > exists. (I'm not even sure that there's a generally accepted > > > definition for what "quantum computer" means -- some people seem to > > > use it for just annealing-based > > > stuff.) > > > > Probably, if we add a qualifier "full-scale Quantum Computer" then the text > > will become less questionable? Something like this: > > > > It is an open question whether or not it is feasible to build a large-scale > > Quantum Computer > > (and if so, when one might be implemented), but if it is, many of the > > cryptographic algorithms > > and protocols currently in use would be insecure. > > > > Or are you suggesting to rephrase the sentence completely? E.g.: > > > > Recent achievements in developing Quantum Computers (QC) > > demonstrate that > > it is probably feasible to build a large scale QC. If such a QC is implemented, > > many of the cryptographic algorithms and protocols currently in use would > > be insecure. > > I'd suggest using the phrase "cryptographically significant Quantum Computer". The problems that you find in cryptography do need more qubits than current Quantum Computers possess; however they also need to perform millions of operations without significant error, and that would appear to be a more serious hurdle. This is the best suggestion I've heard so far, thanks. > > > > > > > would be compromised. IKEv1 [RFC2409], when used with strong > > > > > preshared keys, is not vulnerable to quantum attacks, because those > > > > > keys are one of the inputs to the key derivation function. If the > > > > > preshared key has sufficient entropy and the PRF, encryption and > > > > > authentication transforms are postquantum secure, then the resulting > > > > > system is believed to be quantum resistant, that is, invulnerable to > > > > > an attacker with a Quantum Computer. > > > > > > > > > > Do we have a reference for this "it is believed", or is it just > > > > > the outcome of the WG discussions? > > > > > > > > I'll let my co-authors comment on this, but I think it is meant that > > > > according to our best current knowledge nothing better than Grover's > > > > algorithm can be used to break symmetric key cryptosystem with QC. > > > > And Grover's algorithm only halves an effective key length, so if > > > > longer PSK is used, we're safe (we believe we are). > > > > > > To be clear: I share this belief! :) > > > I am just asking if it is sufficiently well-known/widespread that no > > > reference is needed; that may well be the case. > > > > I believe it is, but I again prefer someone more knowledgeable in QC than > > myself to comment. > > Breaking it down, we come up with four propositions: > - Grover's attack would require a huge number of operations against a sufficiently long secret. > - This huge number of operations is infeasible against any plausible operation. > - Any attack better than Grovers would require attacking the function at a lower level than a black box > - No such insight is known. > > The first can easily be cited (e.g. the original Grover paper). The second one is generally believed, but the exact length of the secret would depend on the eventual speed/scale of a quantum computer, which is somewhat unknown. > The third is also citable (again, the original Grover paper). The fourth is problematic, because it is essentially an argument from a lack of knowledge. > > Personally, I believe that this sort of argument is well known enough (at least, to the people who know postquantum cryptography) that it would not be required. I've heard enough people say this that I'm convinced. Thanks for having the discussion! -Ben From nobody Sun Nov 10 16:51:32 2019 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 21F5A12001A for ; Sun, 10 Nov 2019 16:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nQ0RDYqequhC for ; Sun, 10 Nov 2019 16:51:29 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 6651F1200E5 for ; Sun, 10 Nov 2019 16:51:29 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id i15so5635599ybq.0 for ; Sun, 10 Nov 2019 16:51:29 -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=9+TMXXbVSxQPATPO/BBCCi31lWIu9+KJOHABClzX/Eo=; b=O6vFrNp6zsXv539Dc2HzM9KIGUdane03MOznHAT71jiOX3r2WB+KQ0qe48QOE/e5jz yg7BAiyCAFZN12c327NFJMlv3ZFYD+1H4X4daOJGL5KITthHOQeVdA4N6kHW6+f0GiHh 95ydtlUYx2jU2489Uiz/cVB9YoTKxSLJcTfUeoIAvSdA1RyXTW9cgmRPqJvxuLvWX3F1 25IfIsrOZLA66y+gz9J59jr/u3dAJzHXpuNTg/yOd0hoew95fAfpcV0PEqVLkkOKCKpv PV4kthlKrmonZwEHbMZtsSWP8dP+XwJXdeQdpZX0CKm0a1aWI0g5QIAOpGWEl5ss1Xuh kpOw== 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=9+TMXXbVSxQPATPO/BBCCi31lWIu9+KJOHABClzX/Eo=; b=a79ES12QRom2pDu0ONnb9VTCr0hZWQNo5dBw4p4HaeGE+qGw4ZieU2fIBmDwQR99p9 qrg3+bzLHBvnnrhE1qrr1M1KW4gFQG2qgUadxoim/xVIchWJk7P3wqJ2PhwyKoLzcYIZ VQWdS2dqwkgnRjlt4899L6c2SJDojpca3CJzZ4ZImc/EuKP3X8etQnBRrM9aQWBCqUi8 Qx9fGFmeCfzhoqLyJu3NcZXtcnFFD/lmhgCYYUEl6W7ByK11dgZqiFsy9F6GQPS5KZ6P SLzalpesBe1cKj75yIQrf0ZnW3X5FCsMd61x2qud8vnl6xc2sKQYEd8IUTgTrtHTzbLM C8mA== X-Gm-Message-State: APjAAAVO5Okb5vZt/7S+D3l+qnYo28/KLXYmZU/skZ2CVvaKk/8mwMcN EFM2L43T31YGwUr7CI2DZvWlM6csKUsDrSjwkXSEXw== X-Google-Smtp-Source: APXvYqzaHdrplBll0IVr9BRM/M1pOlfzNndLV0T1DjzqY3wWkL+6/HdXKoEEsVS73aX2MjmusfwbwhUbJBrQ7FEBZwg= X-Received: by 2002:a25:7a47:: with SMTP id v68mr18367215ybc.438.1573433488429; Sun, 10 Nov 2019 16:51:28 -0800 (PST) MIME-Version: 1.0 From: Jonathan Hammell Date: Sun, 10 Nov 2019 19:51:12 -0500 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="00000000000027d8180597078843" Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 00:51:31 -0000 --00000000000027d8180597078843 Content-Type: text/plain; charset="UTF-8" I support adoption of this draft. Like others have said, there is a desire to have support of post-quantum key establishment in protocols such as IKEv2 so implementations are ready when the NIST process for algorithm standardization completes. Jonathan Tero Kivinen Sun, 03 November 2019 22:42 UTCShow header This is adoption call for the draft-tjhai-ipsecme-hybrid-qske-ikev2 draft to be accepted to be WG Document. This draft has been around for some time, and we have been discussing it in the meetings. If you support adopting this document as WG Document, then send email indicating your support to the ipsec@ietf.org mailing-list. If you have any comments or reservations send them to the list too. This adoption call finishes 2019-11-11. -- --00000000000027d8180597078843 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this draft. Like = others have said, there is a desire to have support of post-quantum key est= ablishment in protocols such as IKEv2 so implementations are ready when the= NIST process for algorithm standardization completes.

Jonathan=C2=A0

Tero Kivinen <ki= vinen@iki.fi> Sun, 03 November 2019 22:42 UTCShow header

This is adoption call for the draft= -tjhai-ipsecme-hybrid-qske-ikev2
draft to be accepte= d to be WG Document. This draft has been around for
= some time, and we have been discussing it in the meetings.

If you support adopting this document as= WG Document, then send email
indicating your suppor= t to the ipsec@ietf.org mailing-list.= If you
have any comments or reservations send them = to the list too.

This ad= option call finishes 2019-11-11.
--=C2=A0
--00000000000027d8180597078843-- From nobody Wed Nov 13 00:36:34 2019 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 776041201B7 for ; Wed, 13 Nov 2019 00:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtBtwFO8pV8a for ; Wed, 13 Nov 2019 00:36:30 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341811201AA for ; Wed, 13 Nov 2019 00:36:29 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iUo8X-0002rz-Vi; Wed, 13 Nov 2019 11:36:26 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1iUo8X-0007qr-JI; Wed, 13 Nov 2019 11:36:25 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 13 Nov 2019 11:36:25 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 13 Nov 2019 11:36:25 +0300 From: Valery Smyslov To: 'Tero Kivinen' , 'Paul Wouters' CC: References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> <06de01d59477$97f347e0$c7d9d7a0$@elvis.ru> <24004.47248.804169.798841@fireball.acr.fi> In-Reply-To: <24004.47248.804169.798841@fireball.acr.fi> Date: Wed, 13 Nov 2019 11:36:27 +0300 Message-ID: <000d01d599fd$70e15990$52a40cb0$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL0a9Ttu9PudiK014soS4Z/m3iG4QIy6txqAr5BIRAB8BMI8QEJHLRsAbI4xq8CDFVCBqTt2tww Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/11/13 07:44:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/11/13 03:35:00 #14467573 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 08:36:32 -0000 Hi Tero, > > > Do you think the current diagrams are confusing? > > > > Yes. Because often I go back to RFCs and only look at the diagrams > > expecting it to be what I need to implement. So for optional/required > > payloads, I would mostly look at the diagram, and perhaps read a bit > > of text. > > That is the reason we added Appendix C in the IKEv2. > > So my proposal is to leave the exchanges inside the text as they are, > but add new Appendix that has the different exchanges including the > optional payloads. I don't think it's justified for such small changes in IKE exchanges (a couple new notifications). Instead, I suggest to add the following short clarification after the picture: Initiator Responder ---------------------------------------------------------------- HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP} HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH, N(PPK_IDENTITY, PPK_ID) [, N(NO_PPK_AUTH)]} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr [, N(PPK_IDENTITY)]} Note, that the diagram above shows both the cases when the responder uses PPK and when it chooses not to do it (provided the initiator has included NO_PPK_AUTH notification), so the responder's PPK_IDENTITY notification is marked as optional. Is it OK? Paul? Regards, Valery. From nobody Wed Nov 13 01:47:43 2019 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 B06FA120801 for ; Wed, 13 Nov 2019 01:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89dtVStuwwaQ for ; Wed, 13 Nov 2019 01:47:41 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169761201AA for ; Wed, 13 Nov 2019 01:47:41 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id CD80C25C1657; Wed, 13 Nov 2019 11:47:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24011.53562.807241.59712@fireball.acr.fi> Date: Wed, 13 Nov 2019 11:47:38 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: Subject: [IPsec] IETF 106 Agenda has been uploaded X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 09:47:43 -0000 I have now done the agenda for the IETF 106 meeting. If I omitted something or there is something else that needs to be discussed send me email. ---------------------------------------------------------------------- # IPsecME WG ## IETF 106, Singapore * Date: 2019-11-21 * Time: 15:50-17:20 (90 min) * Room: Olivia * Chair: Tero Kivinen * Chair: David Waltermire --- ## Agenda ### Adminstrivia (5 min) * Agenda bashing, Logistics -- Chairs (5 min) ### Draft status -- Chairs (10 min) * draft-ietf-ipsecme-implicit-iv - Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) * draft-ietf-ipsecme-ipv6-ipv4-codes - IKEv2 Notification Status Types for IPv4/IPv6 Coexistence * draft-ietf-ipsecme-qr-ikev2 - Postquantum Preshared Keys for IKEv2 * draft-ietf-ipsecme-ikev2-intermediate - Intermediate Exchange in the IKEv2 Protocol * draft-hopps-ipsecme-ipft - IP Traffic Flow Security * draft-ietf-ipsecme-labeled-ipsec - Labeled IPsec Traffic Selector support for IKEv2 * draft-tjhai-ipsecme-hybrid-qske-ikev2 - Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) ### Work Items (15 min) * draft-tjhai-ipsecme-hybrid-qske-ikev2 Interop -- Valery Smyslov (5 min) - Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) * draft-hopps-ipsecme-ipft -- Christian Hopps (10 min) - IP Traffic Flow Security ### Other presentations (25 min) * draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt -- Wei Pan (10 min) - IKEv2 Optional SA&TS Payloads in Child Exchange * draft-pwouters-ikev1-ipsec-graveyard -- Paul Wouters (5 min) - Deprecation of IKEv1 and obsoleted algorithms * draft-smyslov-ipsecme-ikev2-qr-alt -- Valery Smyslov (15 min) An Alternative Approach for Postquantum Preshared Keys in IKEv2 -- kivinen@iki.fi From nobody Wed Nov 13 11:59:11 2019 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 2E7AF120942 for ; Wed, 13 Nov 2019 11:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZro4fmCI7bH for ; Wed, 13 Nov 2019 11:59:08 -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 47FA8120885 for ; Wed, 13 Nov 2019 11:59:05 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47CwRW1rl9zFkj; Wed, 13 Nov 2019 20:59:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1573675143; bh=NjPijLi6OHfBXEmPmE04j5j/tvLUxA2VPUzah1vpzag=; h=Date:From:To:Subject; b=nGak8WXffs04da1u3RrzGFStdZ65S1twQ8hc4y8Imo3eLOIUIM6hpnC1NVZQsD939 esdGwvgP6iejHYhURb1SArWuLg2iSTwS84Ha/tzuwVi7ItQ+zso4RBDF0U3QfOAlUv 5c0PzmHrOpEOn7B8bouXJbK7QFhA21rEvesPZS5g= 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 KNXi8CAUZrqD; Wed, 13 Nov 2019 20:59:01 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 13 Nov 2019 20:59:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C7A31602980B; Wed, 13 Nov 2019 14:58:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C6723CB854; Wed, 13 Nov 2019 14:58:59 -0500 (EST) Date: Wed, 13 Nov 2019 14:58:59 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [IPsec] [Cryptography] Why RSA-PSS is much less secure than PKCS #1 v1.5 (fwd) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 19:59:10 -0000 Interesting, since we basically said to do only PSS for RFC 7427 .... Paul ---------- Forwarded message ---------- Date: Sun, 10 Nov 2019 23:34:28 From: Peter Gutmann To: Cryptography Mailing List Subject: [Cryptography] Why RSA-PSS is much less secure than PKCS #1 v1.5 There is a view that RSA-PSS (henceforth referred to as PSS) is more secure than PKCS #1 v1.5 (henceforth PKCS #1), presumably because PSS has the words "provable" and "secure" in its description (the abbreviation PSS stands for Probabilistic Signature Scheme, it's the scheme itself which has "provable" in it). In practice however PSS is much less secure and vastly more brittle than PKCS #1, despite its "provable security". Here's why. To understand the problem, you need to look at PKCS #1 vs. PSS. PKCS #1 has the following external, unauthenticated parameters: The PKCS #1 verification operation, following the RSA operation that both PSS and PKCS #1 require, is as follows. Given a hash of the data being signed, perform the following: fixed_sig_data[ hash_offset ] = hash; result = memcmp fixed_sig_data, recovered_sig_data; In other words, copy the hash onto the end of the fixed-format PKCS #1 signature data and compare it with the recovered signature data. The fixed- format PKCS #1 signature data encodes the hash algorithm, parameters, signature type, and anything else that's required to verify the signature. PSS in contrast has the following external, unauthenticated parameters: RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] { SEQUENCE { algorithm OBJECT IDENTIFER, parameters ANY DEFINED BY algorithm OPTIONAL }, maskGenAlgorithm [1] { SEQUENCE { algorithm OBJECT IDENTIFER DEFAULT mgf1SHA1, parameters SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }, } saltLength [2] { length INTEGER DEFAULT 20 }, trailerField [3] { trailer INTEGER DEFAULT trailerFieldBC } } The PSS verification operation, again following the common RSA operation, is as follows... Actually I won't post it here. No matter how much I try and condense it, I can't get it down to less than four solid pages of pseudocode. In addition, I have no idea whether it's actually correct or not, meaning whether it captures all of the boundless corner cases and conditions that it's required to handle. Just to help with the explanation that follows, here's a diagram of what's going on. mHash is the hash of the message as for PKCS #1 (this diagram requires a fixed-width font to see): +-----------------------------------+------+---+ EM = |# maskedDB | mHash|xDB| +-----------------------------------+------+---+ | | v | xor <------- MGF() ------+---+ | | v | +---------------------------+-------+ | DB = | 00 ... 00 01 | salt | | +---------------------------+-------+ | | | | | v | +-------------------+-------+-------+ | M' = | 00 x 8 | hash | salt |---+ | +-------------------+-------+-------+ | | v | Hash() | | | v v Compare Now let's look at what an attacker can do with the above. The immediately obvious, trivial attack is a hash-substitution attack. Unlike PKCS #1, PSS doesn't encode the hash algorithm used anywhere in the signature. This encoding, known as a hash function firewall ("On Hash Function Firewalls in Signature Schemes", CT-RSA 2002) was ironically not added to PSS because it would have caused problems with the security proof. By changing hashAlgorithm to whatever you like, for example an algorithm of the same size that you know how to break, you can forge the signature. Change the hash from SHA-2/256 to Streebog, Blake2, Keccak, CRC-256, XOR256, whatever you like, PSS won't detect the change, making it only as strong as the weakest hash algorithm of the same bit width that the victim will accept. There's a lot more fun you can have with this. Remember that you've got a huge pile of external parameters, all controllable by the attacker. For example look at the way MGF() is applied, it's a simple stream cipher, meaning that you can flip any bit in DB by flipping the corresponding bit in EM. Note that there's just a single bit in DB that tells you where the salt starts, so if you can flip a bit in EM it'll set the corresponding bit in DB to 1. In theory you then run into a problem with the salt, but since the salt length is another attacker-controlled parameter you just extend it to cover the extra data that's been added by the bit flip. Then there's M', which is assembled by the victim under the attacker's control since they can set the salt length and hash algorithm to anything they want, which PSS again won't detect. There's quite a large pile of problems present here: * There's no internal structure to the data so you can't see what's what, and in particular where one field ends and another begins. Specifically, it violates Abadi and Needham's Principle #1, "Every message should say what it means" ("Prudent Engineering Practice for Cryptographic Protocols", Security and Privacy 1994). * There's a ton of external, attacker-controlled parameters that allow an attacker excessive control over every step of the verification process (see also the previous point). * The algorithm is ridiculously over-parameterised (why would you want to use a different hash algorithm for the message hash and mask generation hash, or a salt of a different length than the hash, or ...), all of which helps the attacker. * It uses a stream cipher (XOR-mask) that allows you to make easily predictable changes to the data. * The victim has to assemble the data block M' using attacker-controlled parameters rather than recovering it from the signature. * The high level of complexity and special-case checks and operations make it pretty much impossible to implement in a side-channel-free manner. It's almost a textbook example of what not to do when designing a signature, or more generally crypto, mechanism. (In its defence, PSS was very much a product of the times, with building blocks like the hash function and MGF and parameters values subject to change, so that parameter-combinatorial-explosion ended up being a frequent design pattern, with the expectation being that usage profiles would address some of the issues that arose. Unfortunately none were ever really created beyond de facto usage patterns, there's a suggested one at the end of this writeup. For a great introduction to the early history of RSA signature mechanism design, see Burt Kaliski's talk from ZKProof 2019, https://www.youtube.com/watch?v=sqsDKjPaJVg). At the moment there isn't an obvious attack that takes advantage of this beyond the obvious hash-substitution, but it gives the attacker an awful lot of control over the internals of the PSS verification operation. Contrast this with PKCS #1, where there's only one fixed-format string possible for each hash algorithm, and no ambiguity or manipulation by the attacker is possible. In terms of the unauthenticated parameters, in theory there is sort-of protection against these in both X.509 and S/MIME / CMS, but in practice there isn't. X.509 includes the signature algorithm parameters in the certificate in the form of the badly-named 'signature' field, which doesn't contain the signature at all but the algorithm parameters. Support for this is hit-and- miss, with some implementations skipping it (which is perfectly justifiable, since there's never been a need for it if you're not using PSS), some implementations checking basic parameters but not the mass of optional and situation-specific values used in PSS, and some meticulously checking every parameter. CMS in theory has a means of protecting the parameters by signing them into the SignedAttributes as an RFC 6211 Algorithm Identifier Protection Attribute, but I know of only one implementation that supports that, and in any case if you've got a hash function that you can create collisions with you can rewrite the CMS signature to remove the SignedAttributes. Note that this problem is specific to PSS, it doesn't affect PKCS #1 which encodes the algorithm information into the signature. So for the vanishingly small number of users of PSS, I'd recommend switching to something more secure like PKCS #1, and disabling the PSS code before someone attacks you through it. If you must use PSS then hardcode in one, and only one, signature scheme, say { hashAlgorithm = SHA-256, maskGenAlgorithm = mgf1 with SHA-256, saltLength = 32, trailerField = trailerFieldBC } and don't allow any substitutions. "Beware of bugs in the above signature scheme; I have only proved it secure, not implemented it" - Apologies to Donald Knuth. Thanks to various members of the cryptography community who commented on early drafts of this writeup. My opinions, not theirs. Peter. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com https://www.metzdowd.com/mailman/listinfo/cryptography From nobody Wed Nov 13 13:08:33 2019 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 221BF120046 for ; Wed, 13 Nov 2019 13:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XO7sgGIz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=R/REhzDG 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 OTmvht1SZIOJ for ; Wed, 13 Nov 2019 13:08:29 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED13D12003E for ; Wed, 13 Nov 2019 13:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8170; q=dns/txt; s=iport; t=1573679308; x=1574888908; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=C/bw7VKcrdYcnAzici7AAqu7FB/rbn8LxKPO1BXA8mw=; b=XO7sgGIz8j7wIqOJ7AfLNk8mdP4ZP+dh08aE/hpNvkXZVF61KQVcIaGU 2TemKnxfzszQ0Zy5nvYyQ+K0imKqslhpTT/yOMVzaJNbqtjQ5nAxVpNcR DD5W0DIgp2EiPHLiliFXXfoi6UaB4O80lBccOMyDT9UOD5UIBV28JHva9 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AwFMwKxcXw8WhcPJNYg5kD8WplGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dy8zGdxLUlZN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAQDQb8xd/4kNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYFqCAELAYEbL1AFbFggBAsqhCmDRgOEWoYeToIQkx6EYoEuFIEQA1QJAQE?= =?us-ascii?q?BDAEBLQIBAYRAAheCCSQ0CQ4CAwsBAQQBAQECAQUEbYU3AQuFUQEBAQEDEgs?= =?us-ascii?q?GChMBASwMDwIBCBEEAQEoAwICAjAUCQgCBBMIGoMBgXlNAy4BAqZOAoE4iGB?= =?us-ascii?q?1gTKCfgEBBYURGIIXCYE2AYwTGIFAP4ERRoJMPoQSARIBITSCWjKCLJANhUO?= =?us-ascii?q?YSQqCKJVimX6OR5l8AgQCBAUCDgEBBYFSOWdxcBU7gmxQERSRGgwXg1CKU3S?= =?us-ascii?q?BKI4JgjEBAQ?= X-IronPort-AV: E=Sophos;i="5.68,301,1569283200"; d="scan'208,217";a="664445550" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Nov 2019 21:08:27 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xADL8RaW017134 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Nov 2019 21:08:27 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 13 Nov 2019 15:08:26 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 13 Nov 2019 16:08:25 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 13 Nov 2019 15:08:25 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SS7NH1Zi56NKr96psgiNt6L+yJbw96uh0z4gMti7L1dJXEPRXU4qXpWwRCc6eksCqzvcyPcffKfT2jw0igY7sejJagx73E90mCKOSvUtAtYjzjOLY77tRRzFhHGwdfB8Rz5lcOBjLF95PDWF8kHNfFT9/5oWQ6jezL3vInq76G9CiBTnVchnfKGjBNDY/4O/eZH6B537h8szvc2Zsu/zCFDS8fEmaRN3rN+6ZESuhy5HNbKCAUbgvY3NduOn5tA3a/qaLBBCrcvjYXt7oj+kQM9lMuweTnmj36XgAj636a4LaF+FlLHDovqQYCUn2ugPz7K7rIIYp1LDGWkLwvBQ7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C/bw7VKcrdYcnAzici7AAqu7FB/rbn8LxKPO1BXA8mw=; b=kf0PMfEnhpcrx0Yu+UfdpKuVaFIYsotRrzbG/ZrHwFTtaprsqfa5w9YYd6Ibwr46nO2OtUHXeaiNHqJGKUcfAsUo/mNcfbG0xoGhoaZ03glEvNFFDF5p0pDhxVT5DcSgm1dyfxIjeEHATb7tegNSVqNQjwgJj7QJGajcCKlWcvuuZFdwhwKcC6G4ydF/40rFuEjkB5pPNHFa7xjsrvf9Dxvz0lwHCXLSkDegVKskefMQ5Nv5tn2+VZSHavmNNHrmUQVFUeiOklH1el2J8byCV2c0P6f/pFZxKNwcUCMaMa6PhuZJdt6lUZPIGeFRwJftnXlw1I9chjowFzvM8BY7DQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C/bw7VKcrdYcnAzici7AAqu7FB/rbn8LxKPO1BXA8mw=; b=R/REhzDG/v+uP0TXw+bChss5WrPnbX0f7d0qlUo+xr/D/fxJPjLVHmXfW073yudWiT8kvYBNps8MdkCLMx3tTFfaw3cqQRH8ZXLyj88orkxY+c9p5XUxLiUmzAC/MUTvhzjVVpXpD3lFU7O5w8YpocLHfynorSDTJf+c7cAximw= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2642.namprd11.prod.outlook.com (52.135.253.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.23; Wed, 13 Nov 2019 21:08:22 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2451.023; Wed, 13 Nov 2019 21:08:22 +0000 From: "Panos Kampanakis (pkampana)" To: "ipsec@ietf.org" Thread-Topic: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 Thread-Index: AQHVmCo4K+WE0cMsd0OFMxwflEEgo6eJnEdQ Date: Wed, 13 Nov 2019 21:08:22 +0000 Message-ID: References: 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=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:3865:316d:15f:b08e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 00d0e003-f5eb-456d-187b-08d7687d9e06 x-ms-traffictypediagnostic: BN7PR11MB2642: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(376002)(396003)(366004)(136003)(189003)(199004)(11346002)(446003)(476003)(46003)(7696005)(486006)(186003)(102836004)(33656002)(53546011)(6506007)(76176011)(5640700003)(55016002)(6306002)(54896002)(66476007)(66556008)(64756008)(66446008)(9686003)(236005)(1730700003)(81156014)(81166006)(66946007)(8676002)(76116006)(6246003)(71200400001)(71190400001)(8936002)(256004)(790700001)(6116002)(2351001)(229853002)(6436002)(2906002)(25786009)(6916009)(52536014)(4001150100001)(7736002)(5660300002)(2501003)(74316002)(478600001)(316002)(99286004)(14454004)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2642; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YJHa2Kdi3Ibu0JxiNvRcVPknSwJ+53f4pXINausu/p9T9vxTrTX9cVZ2wLWbgvc/01Z1lWx4Vn+I95f1W1K1Z1C0l17ysu22oxu0rPlj24QdHMQubuU4zM2sGvw1j1Qjb3sy1fWM9sCzqBNU31ASCX4N/7UrpuAFDwsAzNtILcO2uMjAAQXgC5/Fu1kchWwlRM9XbCBhabN0yeZI+HnDsubH/gAESlPcL5CJDPSbmWNtMU5t7AXnb4eFblcBp6FhS6Pwy0TcxqghNE9H+ieG9JcEB4pzuPVXuMdtmQHXQlK4e+2lg+TxzT/x1070pgRJ2u3MGiX/qlQCNMZwJP285kfx4kylvU27alQ1ubSL7SoTRhUUb+kte0yqEpO70MHwAA2kTtdlcHCNe/PuEb8QywqX81vYDqxqXQ6KMj1BGyOYiQ2vXMunSUe19I8xrT6S x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB254752E5C25E3DAB3A8BD1FCC9760BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 00d0e003-f5eb-456d-187b-08d7687d9e06 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 21:08:22.6645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hXiL3NMQPRtWbyoXn2sMHmiXac8ZNYIRH9j2D59k7zQp1rsxQyls0Z9jqjj2LYM19lvlcU12ggYqsSVHkNsupA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2642 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [IPsec] Adoption call for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 21:08:31 -0000 --_000_BN7PR11MB254752E5C25E3DAB3A8BD1FCC9760BN7PR11MB2547namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gYWRvcHRpbmcgZHJhZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2Mg0KZHJh ZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2MiBhbmQgZHJhZnQtaWV0Zi1pcHNlY21l LWlrZXYyLWludGVybWVkaWF0ZSBhcmUgZXNzZW50aWFsIGZvciBlbmFibGluZyBQUSBLZXkgRXhj aGFuZ2UgaW4gSUtFdjIuDQoNCg0KRnJvbTogSVBzZWMgPGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBKb25hdGhhbiBIYW1tZWxsDQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDEw LCAyMDE5IDc6NTEgUE0NClRvOiBpcHNlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJUHNlY10g QWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2Mg0K DQpJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4gTGlrZSBvdGhlcnMgaGF2ZSBzYWlk LCB0aGVyZSBpcyBhIGRlc2lyZSB0byBoYXZlIHN1cHBvcnQgb2YgcG9zdC1xdWFudHVtIGtleSBl c3RhYmxpc2htZW50IGluIHByb3RvY29scyBzdWNoIGFzIElLRXYyIHNvIGltcGxlbWVudGF0aW9u cyBhcmUgcmVhZHkgd2hlbiB0aGUgTklTVCBwcm9jZXNzIGZvciBhbGdvcml0aG0gc3RhbmRhcmRp emF0aW9uIGNvbXBsZXRlcy4NCg0KSm9uYXRoYW4NCg0KVGVybyBLaXZpbmVuIDxraXZpbmVuQGlr aS5maTxtYWlsdG86a2l2aW5lbkBpa2kuZmk+PiBTdW4sIDAzIE5vdmVtYmVyIDIwMTkgMjI6NDIg VVRDU2hvdyBoZWFkZXINCg0KVGhpcyBpcyBhZG9wdGlvbiBjYWxsIGZvciB0aGUgZHJhZnQtdGpo YWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2Mg0KZHJhZnQgdG8gYmUgYWNjZXB0ZWQgdG8gYmUg V0cgRG9jdW1lbnQuIFRoaXMgZHJhZnQgaGFzIGJlZW4gYXJvdW5kIGZvcg0Kc29tZSB0aW1lLCBh bmQgd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgaXQgaW4gdGhlIG1lZXRpbmdzLg0KDQpJZiB5b3Ug c3VwcG9ydCBhZG9wdGluZyB0aGlzIGRvY3VtZW50IGFzIFdHIERvY3VtZW50LCB0aGVuIHNlbmQg ZW1haWwNCmluZGljYXRpbmcgeW91ciBzdXBwb3J0IHRvIHRoZSBpcHNlY0BpZXRmLm9yZzxtYWls dG86aXBzZWNAaWV0Zi5vcmc+IG1haWxpbmctbGlzdC4gSWYgeW91DQpoYXZlIGFueSBjb21tZW50 cyBvciByZXNlcnZhdGlvbnMgc2VuZCB0aGVtIHRvIHRoZSBsaXN0IHRvby4NCg0KVGhpcyBhZG9w dGlvbiBjYWxsIGZpbmlzaGVzIDIwMTktMTEtMTEuDQotLQ0K --_000_BN7PR11MB254752E5C25E3DAB3A8BD1FCC9760BN7PR11MB2547namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+JiM0MzsxIG9uIGFkb3B0aW5n IGRyYWZ0LXRqaGFpLWlwc2VjbWUtaHlicmlkLXFza2UtaWtldjI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ZHJh ZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2MiBhbmQgZHJhZnQtaWV0Zi1pcHNlY21l LWlrZXYyLWludGVybWVkaWF0ZSBhcmUgZXNzZW50aWFsIGZvciBlbmFibGluZyBQUSBLZXkgRXhj aGFuZ2UgaW4gSUtFdjIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBJUHNlYyAmbHQ7aXBzZWMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9m IDwvYj4NCkpvbmF0aGFuIEhhbW1lbGw8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBOb3ZlbWJl ciAxMCwgMjAxOSA3OjUxIFBNPGJyPg0KPGI+VG86PC9iPiBpcHNlY0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW0lQc2VjXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC10amhhaS1p cHNlY21lLWh5YnJpZC1xc2tlLWlrZXYyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuIExpa2Ugb3RoZXJzIGhhdmUg c2FpZCwgdGhlcmUgaXMgYSBkZXNpcmUgdG8gaGF2ZSBzdXBwb3J0IG9mIHBvc3QtcXVhbnR1bSBr ZXkgZXN0YWJsaXNobWVudCBpbiBwcm90b2NvbHMgc3VjaCBhcyBJS0V2MiBzbyBpbXBsZW1lbnRh dGlvbnMgYXJlIHJlYWR5IHdoZW4gdGhlIE5JU1QgcHJvY2VzcyBmb3IgYWxnb3JpdGhtIHN0YW5k YXJkaXphdGlvbiBjb21wbGV0ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkpvbmF0aGFuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlcm8gS2l2aW5lbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtpdmluZW5AaWtpLmZpIj5raXZpbmVuQGlraS5maTwvYT4mZ3Q7IFN1biwgMDMgTm92 ZW1iZXIgMjAxOSAyMjo0MiBVVENTaG93IGhlYWRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFkb3B0aW9uIGNhbGwgZm9yIHRo ZSBkcmFmdC10amhhaS1pcHNlY21lLWh5YnJpZC1xc2tlLWlrZXYyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdCB0byBiZSBhY2NlcHRlZCB0 byBiZSBXRyBEb2N1bWVudC4gVGhpcyBkcmFmdCBoYXMgYmVlbiBhcm91bmQgZm9yPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zb21lIHRpbWUsIGFu ZCB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBpdCBpbiB0aGUgbWVldGluZ3MuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBzdXBwb3J0 IGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgV0cgRG9jdW1lbnQsIHRoZW4gc2VuZCBlbWFpbDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW5kaWNh dGluZyB5b3VyIHN1cHBvcnQgdG8gdGhlIDxhIGhyZWY9Im1haWx0bzppcHNlY0BpZXRmLm9yZyI+ DQppcHNlY0BpZXRmLm9yZzwvYT4gbWFpbGluZy1saXN0LiBJZiB5b3U8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhhdmUgYW55IGNvbW1lbnRzIG9y IHJlc2VydmF0aW9ucyBzZW5kIHRoZW0gdG8gdGhlIGxpc3QgdG9vLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFkb3B0aW9uIGNhbGwg ZmluaXNoZXMgMjAxOS0xMS0xMS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN7PR11MB254752E5C25E3DAB3A8BD1FCC9760BN7PR11MB2547namp_-- From nobody Thu Nov 21 01:13:05 2019 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 C2EEB1209C8 for ; Thu, 21 Nov 2019 01:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6ydyWD8Y3Pa for ; Thu, 21 Nov 2019 01:13:02 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FA51209CD for ; Thu, 21 Nov 2019 01:13:02 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAL9CxRE010644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Nov 2019 04:13:01 -0500 Date: Thu, 21 Nov 2019 01:12:58 -0800 From: Benjamin Kaduk To: ipsec@ietf.org Message-ID: <20191121091258.GO32847@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [IPsec] On internet protocol number assignment requests and draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 09:13:04 -0000 Hi all, I know that we are going to try to explore options for draft-hopps-ipsecme-iptfs that do not require a protocol number, but if we do find ourselves pressing forward with that approach, we should be sure to have a discussion about the usage in INTAREA, which in some sense represent the guardians of the resource. -Ben From nobody Thu Nov 21 21:12:21 2019 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 96675120115 for ; Thu, 21 Nov 2019 21:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAA7nbKvEm1M for ; Thu, 21 Nov 2019 21:12:17 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E7612004E for ; Thu, 21 Nov 2019 21:12:16 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id A84AE25C0BEC; Fri, 22 Nov 2019 07:12:12 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24023.28204.496361.587128@fireball.acr.fi> Date: Fri, 22 Nov 2019 07:12:12 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] Preliminary IPsecME minutes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 05:12:20 -0000 Here are (bit) cleaned up minutes from the etherpad. Thanks to Sean for taking them. If you have any fixes, clarifications or additions please send before 1st of December. ---------------------------------------------------------------------- IPsecME WG - IETF 106, Singapore Date: 2019-11-21 15:50-17:20 (90 min) Room: Olivia Chairs: Tero Kivinen , David Waltermire Scribe: Sean Turner Agenda ====== * Adminstrivia (5 min) * Agenda bashing, Logistics -- Chairs (5 min) * Draft status -- Chairs (10 min) * Work Items (25 min) * draft-tjhai-ipsecme-hybrid-qske-ikev2 Interop * draft-hopps-ipsecme-ipft * draft-ietf-ipsecme-labeled-ipsec * Other presentations (40 min) * draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt * draft-pwouters-ikev1-ipsec-graveyard * draft-smyslov-ipsecme-ikev2-qr-alt * draft-mglt-ipsecme-multiple-child-sas ------------------------------------------------------------------------------ Adminstrivia ============ (chairs) https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-chair-slides-02.pdf No agenda bash Draft status ============ (chairs) https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-chair-slides-02.pdf No comments. See slide 5-6. Work Items ========== QSKE Hybrid Interop =================== (Valery Smyslov) draft-tjhai-ipsecme-hybrid-qske-ikev2 https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-hybrid-qske-for-ikev2-interoperability-testing-event-01 S Turner: Consider: publishing to https://ietf.org/how/runningcode/implementation-reports/ Jonathan Hammell: Did you test child rekey? VS: No. David Waltermire: Plans to do so? VS: Yes once draft is adopted. Needs more list discussion. David Waltermire: Please post the feedback to the list, IP Traffic Flow Security ======================== (Christian Hopps) draft-hopps-ipsecme-ipft https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ip-traffic-flow-security-00 VS: You seem to leave out transport mode? Any reason? CH: We only tunnel. We need to encsapsulte and shrink it and grow it. VS: Do you see a need for transport mode? CH: Transport Mode is the least secure because you give away souce and deestination. You are gicing away so much already why bother. VS: You want to allocate an IP protocol number? Is it only use on ? next protocol. Do you need it? CH: It's the scope of how the next header field. It's easier to get a new protocol number than redoing ESP registry. Ben Kaduk: IP # is kind of a big deal, the IESG give each other a heads-up when there's potential for allocating one. My second point is about the alignment question -- the general sense I get from the IETF as a whole is that if we have to be adding new protocol machinery for things like variable length paddding then there's not much interest in the rest of the IETF. Just adding a byte of padding so our fields are internally consistent is generally reasonable, if we can spare the space. CH: We would probably align on 32. Tero: For the protocol # since we only need it in inner esp trailer. We could just say there are multiple buckets inside. The other option is to use WRAP ESP. Third option is that since we negotiate in IKE we can say the final protocol is ignored becaue it has no meaning. Michael Richardson: If we use WRAP ESP that would be the protocol number of the outer or the next header within ESP? Tero: I would put it as the outer. Michael Richardon: When we do ESP ove UDP doesn't the outer say it's ESP so we don't know the protocol. Tero: WRAP ESP does explain how to do it over UDP. CH: We shouldn't be so freaked out about asking for an early allocation. Michael Richardson: I am supportive of making use of WRAP ESP. David Watermire: Tero please send some examples of how this might work. Chair: There is some consensus in the room to invistigate options that would not require a new IP # assignment. Options should be explored first before requesting assignment. Labeled IPsec Traffic Selector support for IKEv2 ================================================ (Paul Wouters) draft-ietf-ipsecme-labeled-ipsec https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-labeled-ipsec-00 VS: I think the second one is not really an option. Traffic selectors are a logical or. The third option is the most right from a formal point of view. It will lead to an explosition of types. Hu Jun: Don't like 3 one. Notify is a new rype to a tunnel not the child SA. PW: This would work for a child SA. Michael Richardson: Consider two things: 1 how would an implementation that doesn't support it respond, 2 is it useful for an endpoint will negotiate and end point that doesn't have? PW: It would be a failure - no tunnel would result. Michael Richardson: Not sure it matters which choice you make then. PW: Do that into account that I have a specific use, but other might want to support it. Michael Richardson: Unless these others complain just do you what you want. Tero: Prefer option 3. Ben Kaduk: Relaying Yoav from jabber: The notify payload seems better because nobody has ever defined new traffic selector types, but we have done notify types. Implementations might choke on a new TS type Daniel Migualt: Where is the label going to be used. Chair: Sounds like the 3rd option? PW: In theory 3rd option is nice, but 1st option is practially better. VS: It might be discussd on the list. Tero: Notify is bad because you know have to do tear downs if you don't need it. SPT: I agree with Paul -- 3 is what you'd do if you were perfect world, but 1 is the practical option that we have to do. We could hum for option 1 and confirm on the list. Tero: problem with option 1 is that it's not in any drafts. Postpone hum until we have something in writing. Michael Richardson: Just do humm for objection? Chair: If you understand what we're asking for in Option 1. [some hums, pretty quiet] Chair: any concerns with option 1? [one from jabber but none apparent in room] Chair: Write up what option 1 would like and go from there. Other presentations =================== IKEv2 Optional SA&TS Payloads in Child Exchange =============================================== (Wei Pan) draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ikev2-optional-sats-payloads-in-child-exchange-00 Paul Wouters: What i do not like is that initiator can send the notify, but the responder can reject it. Because now I have a failed rekey. Does you responder dynmically decide to do this or not? WP: We think that for some products we will give the confurations on the responder side and this will occur immediately. Some products may not do this immediately. Paul Wouters: So now what you're saying you negotiate what you are willing to do, buyt soimewhat in the middle don't do it. Michael Richardson: Take the initial is AES-256, AES-128 but responder has only AES-128. They agree on AES-128. Now if responder policy changes to allow AES-256 (in addition to AES-128) then they can rekey and switch to AES-256. PW: It's not allowed you have to do the exact same parameters. You need to use the same parameters throughout. VS: I do not think this draft gives us enough optimization. For child SA it is slightly different beause you need pull traffic selector and it can be quite long. WP: It is their aim and we implemented it. Christian Hopps: Isn't it just possible that this is over engineered. Just tear the SA down so you can avoid the issues. What you chances of screwing it up. Paul Wouters: For the Child SA it is really useful. Tero: I don't like because it's just more options because it increases that chances of mistakes. Ben Kaduk (Yoav Nir): Why not just have one? Chair: There is some IPR. Sean Turner: It says reasonable and non-discriminatory, with possibility for royalty-free. Tero: having to talk to IPR holder before implementing is annoying. Ben Kaduk: Need to update/review charter before adopting. Paul Wouters: We thought about the minor charter updates - this is minor extension WG and this is minor. Deprecation of IKEv1 and obsoleted algorithms ============================================= (Paul Wouters) draft-pwouters-ikev1-ipsec-graveyard https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ikev1-graveyard-01 Dan: It says IKEv1 MUST NOT be deployed. Can't really say that. Tero: We closed the registry anyway programatically. Dan: Who did you tell? Tero: We sent a liaison. Ben Kaduk: We should send a liaison before we close them. Dan: we're doing the same kind of thing in TLS. Ben Kaduk: IESG will send it. Sean Turner: Will send some text about historic. An Alternative Approach for Postquantum Preshared Keys in IKEv2 =============================================================== (Valery Smyslov) draft-smyslov-ipsecme-ikev2-qr-alt https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-an-alternative-approach-for-postquantum-preshared-keys-in-ikev2-00 Daniel: This draft has been presented many times we should adopt it. VS: This is the first time. Tero: Who read it: 3. WP: Easy to understand and should be done. David Walertmine: Daniel and Paul volunteered to read the draft. Multiple SAs in one create child SA exchange ============================================ (Daniel Migault) draft-mglt-ipsecme-multiple-child-sas https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-draft-mglt-ipsecme-multiple-child-sa-00 Tero: I don't think we can do this with SPi nubmers. We had this in IKEv1, but only one person implemented and nobody wanted it. Need use case before implementing Daniel: You can extend SPI as long as you like. The use case is when you have multiple cores. Michael Richardson: Replay counter impacts. Ben Kaduk: All the Child SAs get the same traffic selectors. Daniel Migualt: Yes. VS: Remember there is an indiviation of # keying material because there is a counter so you can't interate on SP+ more than #. ... Daniel: .... Paul Wouters: I also thought about this a while ago. There are three use cases: 1) brigin up many Childs SAs with PFS for each one - Tero came up with a better solution, 2) To do more processing on CPU - you can do this on demand when a new CPU comes online, 3) For QoS you can just bring them up on demand. So this optimiztion is not really that I understand. Daniel: What to exchange 24 cores. Paul Wouters: At that point you got Gigs so why bother. Open Discussion =============== -- kivinen@iki.fi From nobody Mon Nov 25 16:54:32 2019 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 1DC2D120FCE for ; Mon, 25 Nov 2019 16:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97ihOMI-IoSo for ; Mon, 25 Nov 2019 16:54:29 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968F9120104 for ; Mon, 25 Nov 2019 16:54:29 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAQ0sPWq004751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 25 Nov 2019 19:54:28 -0500 Date: Mon, 25 Nov 2019 16:54:25 -0800 From: Benjamin Kaduk To: ipsec@ietf.org Message-ID: <20191126005425.GR32847@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [IPsec] IPSECME chair transition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 00:54:31 -0000 Hi all, Please join me in thanking David Waltermire for his many years of service as IPSECME co-chair; Dave is stepping down to leave more time for his other projects. Thank you, Dave! Taking over from Dave will be Yoav Nir -- welcome Yoav! Thanks to you both, Ben From nobody Wed Nov 27 00:40:33 2019 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 537E812080C; Wed, 27 Nov 2019 00:40:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157484402528.21913.4728906227364823734@ietfa.amsl.com> Date: Wed, 27 Nov 2019 00:40:25 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 08:40:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-09.txt Pages : 19 Date : 2019-11-27 Abstract: The possibility of Quantum Computers poses a serious challenge to cryptographic algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-09 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 27 00:50:22 2019 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 3CC8112080A; Wed, 27 Nov 2019 00:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 58GEFWyhvs1k; Wed, 27 Nov 2019 00:50:20 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 D9E7212003F; Wed, 27 Nov 2019 00:50:19 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id a15so25652221wrf.9; Wed, 27 Nov 2019 00:50:19 -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=sqPdvKR5fHzEVoem0XDxvpdo26d2z3JXUvHsPHuNnY0=; b=cu+/aJoPOoVk1jJczcjQiuB+6XhsFqHC+2u37UJ+uIG7UDdzozrDBiAS9ExeAnjkrF 4/Cw+6J98RrkUtgNdrNM2af8u2DSlzrueRWqwTItie9rMPTcKc3sOE+dhL8Psd2sNvFs +w5nSdxtEYem4GmSQncKgeitPBx0Nsb5jELUV/JPet5B/7PdAoH5jW7CG6rIy8Km/Zd0 gmw2jY9VwXmHsFkDDHQgMshW7kdFHWj956BnCrCrhU4TnsWSLUQvLFIayKVzmrbxUypy LmK3b1UvoFEB0kmeWQx5ITbDKZRrMpvuJufGo4q9TwmYsqrS43DiCXb8sBwL/6G6c7Eb dBpQ== 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=sqPdvKR5fHzEVoem0XDxvpdo26d2z3JXUvHsPHuNnY0=; b=eEsnyIjBr6J/PIcAXayuaMvsSoAOZM/ljY6daUlTpQQl8TMNZJFj6jJzjQ5EGkVKuL /fB56ZF+m5T0EoKXESEjJ973rhgV/5NUiRVi1iyZcnQVNmgniGzbPcBfK+vywShlBh/W QC/1tCFsXjRnWkCOBulF1mk2L09v0mVdfx+FWGivost+p7gQOzB5EpnHpi7tH218TZlF SjG701kgeyz6MUtOndZscdowkdKxNS0wFg+D7uT2Ik3S31yPuJh8cSF2YLHbM+mRPBrM D65r7U8pzGb2z1s2VGNNRGl8KoYi+D4gfWTB9eGpNW/bkUPGO46mDlu6fU+nJTgiyB7P ilWg== X-Gm-Message-State: APjAAAWtJJJElZbLUfjcNNvcnY2NxZTqlhpvb95p+7IzglsQfLXzfXVi 4kA1OYjW1mdP8hZv/l4c6fY7RVH/ X-Google-Smtp-Source: APXvYqwpChkEsqAlbodIuo7x+F2e8r+BJujladUxWU+073lQ+SYbLogdypLYAjbE8ZBia/u51UYwGA== X-Received: by 2002:a5d:4445:: with SMTP id x5mr43122952wrr.341.1574844617997; Wed, 27 Nov 2019 00:50:17 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u187sm6271873wme.15.2019.11.27.00.50.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Nov 2019 00:50:17 -0800 (PST) From: "Valery Smyslov" To: Cc: , References: <157484402528.21913.4728906227364823734@ietfa.amsl.com> In-Reply-To: <157484402528.21913.4728906227364823734@ietfa.amsl.com> Date: Wed, 27 Nov 2019 11:50:16 +0300 Message-ID: <025501d5a4ff$b16d6550$14482ff0$@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: AQFnWHSxdi+9LPdGeXwiA6UAHb0Gd6h7S/xg Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 08:50:21 -0000 Hi, I've posted a new version of "Postquantum Preshared Keys for IKEv2" draft. This version addresses issues raised by AD review of the draft: https://mailarchive.ietf.org/arch/msg/ipsec/G1yO6oGFtfr-1EMjkT5cprDyMuU We believe that all the issues are resolved. One note regarding the following issue (as its resolution wasn't discussed on the list): > Section 5.2.1 > > I'm kind of confused by the PSKC reference, especially the implication > ("algorithm ("Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin") as the > PIN") that a fixed string is to be used as a PIN. (I also think it's > better to discuss what it does as "key transport" than "key exchange", > noting that the latter string does not appear in RFC 6030.) I slightly changed the text, so that the text suggests to re-use "PIN" profile defined in Section 10.2 of RFC6030 with no implication of any fixed PIN. I believe it was the original intent. Regards, Valery. > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, November 27, 2019 11:40 AM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Valery Smyslov > Filename : draft-ietf-ipsecme-qr-ikev2-09.txt > Pages : 19 > Date : 2019-11-27 > > Abstract: > The possibility of Quantum Computers poses a serious challenge to > cryptographic algorithms deployed widely today. IKEv2 is one example > of a cryptosystem that could be broken; someone storing VPN > communications today could decrypt them at a later time when a > Quantum Computer is available. It is anticipated that IKEv2 will be > extended to support quantum-secure key exchange algorithms; however > that is not likely to happen in the near term. To address this > problem before then, this document describes an extension of IKEv2 to > allow it to be resistant to a Quantum Computer, by using preshared > keys. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-09 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Nov 27 05:55:22 2019 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 71FB8120123 for ; Wed, 27 Nov 2019 05:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 P3BkzF89gjxI for ; Wed, 27 Nov 2019 05:55:20 -0800 (PST) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 1CD901201DC for ; Wed, 27 Nov 2019 05:55:20 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id j42so935615wrj.12 for ; Wed, 27 Nov 2019 05:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=ihVk7r+Noj61RRWkaB18eF9mfFYcBv0iTs0lUQ0yqC0=; b=D28mF70HCRnjU3skbPVN4QTLYnp+xZL7E8Hp8XagaHHvGGmVHhrR7OI8fXry7eVxDj s1PSkefRcAe6/Z69ozBceAag4MnxxfaMdNoZ7pRSjFspi0huYUG3uwHRKfe+3Bb1NdaO 90aVP7fL/Vq+4pQr8yZvn8qB5Y6YAG02Zg9aV8LmBY6wACnksZfraycNx/xA31kPUcxz BIHD4dj4FpRYQnsCrHoAphGvhEHMJClI85aZCP05/Wv84Pq/bV6+C2uXgQA8r2IMuDeN BmfGLwHQgKDJG7qH/irhUYrQUDRLON8OCLEkkYetPIbmV/Tswu2Zza5t/B5zoOqH5pxL uB0g== 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:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=ihVk7r+Noj61RRWkaB18eF9mfFYcBv0iTs0lUQ0yqC0=; b=QVvK7O484oU/CeKDfOz9Tv5Om6/lTgUO5C9yMYdK/QVPS+bEXgOOQq9/IwpCKhWy9s RqrZ0iKDIgxq9taEKJHLgQ4W3DGisXIJll2Hyp27D9ocx1UzcGY8wE6nB4pH0bSyAFAq GFXeC8kRuz5kmgGEiUeKU5ElRG1qobFWhXUrME7UNCJwC19s/JvAigYt/nreMRIOEvHq 2AMR4lfKd0fJMIfxmRsNxPb2F5y3Is30D1wwu+pG7cxoyQJCnWWJZjrM2Ytk1neNxn22 3eNK4hAqxBvEBITOUIOkAroWqLpn8uTP1Mm4uDp0B5z6bBfToWCY9yAHyM9AOVrNY/A6 Z/mw== X-Gm-Message-State: APjAAAVCGCHTvQyCd+jhdLZQAFEfpSAGjEp5SX/1OhUvqTXGULQn0PLg ML840G+r6MH1iXX4BZKglP0= X-Google-Smtp-Source: APXvYqyHNTr5SwJra1ruBF5W1+ITpyWPQjFL0ZAtUS1QYpIuOVX4yLloueD847MNV1VuXGDFnFEg1g== X-Received: by 2002:a05:6000:12ce:: with SMTP id l14mr29480389wrx.342.1574862918756; Wed, 27 Nov 2019 05:55:18 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id j12sm5288165wrw.54.2019.11.27.05.55.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Nov 2019 05:55:18 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" Cc: "'Bruckert, Leonie'" , "'Andreas Steffen'" , "'Tobias Brunner'" , "'Stefan-Lukas Gazdag'" , , "'Egerer, Thomas'" , "'Guggemos, Tobias'" , , , , , , "'Klassert, Steffen'" , "'Martius, Kai'" Date: Wed, 27 Nov 2019 16:55:17 +0300 Message-ID: <02a501d5a52a$4dacaff0$e9060fd0$@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: AdWlKg7zsNSKULn2RH+J/hlJYJwuSQ== Content-Language: ru Archived-At: Subject: [IPsec] Feedback on November 7 QSKE interop testing event X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 13:55:21 -0000 Hi, at the ipsecme meeting at IETF106 I was asked by the chairs to send feedback to the list on QSKE interoperability testing event that took place on November 7. The slides about this event are available here: https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-hybrid-qske-for-ikev2-interoperability-testing-event-01 The event was organized by Secunet. There were 3 active participants (strongSwan, QuaSiModO and ELVIS-PLUS) and few observers. We tested initial IKE SA setup using multiple key exchanges according to draft-tjhai-ipsecme-hybrid-qske-ikev2-04. Rekeying wasn't tested since only one implementation supported it. The results are: - strongSwan and ELVIS+ were able to establish SA using three classical DH exchanges. - strongSwan and QuaSiModO performed hybrid key exchange with classical DH + post-quantum KE (newHope); the key exchange itself was successful, but SA wasn't established due to incorrect AUTH calculation. There was some discussion about the draft and its possible implementations. First, the stable code points are badly needed, at least for IKE_INTERMEDIATE. I've already requested early code points assignments for IKE_INTERMEDIATE, so hopefully this issue will soon be resolved. Then, there were some discussion on how rekey must be done. The conclusion was that using a new dedicated exchange for follow-up key exchanges is much better than re-using INFORMATIONAL. This was already discussed among the draft authors and we agree that it's a right way to go. Some concerns were also expressed about using nonces in each additional KE instead of re-using a pair of nonces from IKE_SA_INIT (or CREATE_CHILD_SA). I think it's a good idea and we probably follow this way after we discuss the security implications of it among the authos. Some vendors that haven't yet implemented the draft expressed an intent to do it once the specification becomes more stable (preferably - becomes an RFC). Event participants are in CC of this message, so they can correct me if I was inaccurate in its description or forgot to mention something important. Regards, Valery. From nobody Thu Nov 28 00:28:38 2019 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 7F319120048 for ; Thu, 28 Nov 2019 00:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9go73--u8M3M for ; Thu, 28 Nov 2019 00:28:36 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9472120019 for ; Thu, 28 Nov 2019 00:28:35 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id e10so18329032ljj.6 for ; Thu, 28 Nov 2019 00:28:35 -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=j+fb7rbObpmBClleSqqpL6RhQ5tIV3fgpOuS//eS0og=; b=sTmSZ5H3oMmpm1PX9q2174yFzU2DVafrClltqUC1daU1xrO8XL29fsZ9PP53PFKjV0 N4XEPiGBF/CSQaroXaUBpMshc6kzFrfL4WdApM+Fy31nfk/e5mD5BO8La127e8XdphMf oDmVUJRvi7qgOFm2NvemLL2keGT0tQ5mlRwFsLiYmg4C4rM2ANYNDwlgxqDImf9F9cMv X0125iSL1nTOQMEO38asOTJlfPm0FC//08HRN2H/5DrLslTJoF7Fql1jj6UOOtILEn6N Ld4mu7pSSOTLXzWsotdD2sjPA5YL+qvn73YFqUtMd/aEwweNGh1w2ZSGCK/hCrRoS/tY 24uw== 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=j+fb7rbObpmBClleSqqpL6RhQ5tIV3fgpOuS//eS0og=; b=SNTAfxYIRtxnl5Jt2j4gGXif9Tl059rC+4LCeU4WY6/ZgXoobaUAiXs6Jrw9Mn/yGj yhYGNYDgVLc6+bmEfKd5GrA7MtgxfdypLbM+GB+Wu/CWbs0AyXbvQqqM5NrE6yWtkiGr uxsiPht7vBpSDAFyGczKqPFnCt+M1fr96sGuA5r9qMGAOgEXj/QpZjZdRhoIfBddNb44 jYfuGx8QWGUbPqDYADMP3bp+JtzKoZy2FgbqLSk+0KofnI1cVt6o0VwhKcGb+tweyC88 qmFfgpIe1mKWVC9sx9A3oIAovg6rNl65Vqa9n+W/Z4+j8d4govQqSadsX3q2Mb6/7FG5 n5Aw== X-Gm-Message-State: APjAAAUWVvT8wuyFtwsYJoC5q1IIJ2w8k5zgyqSYsTz+3KM/ii7DoEbo 5KynPmbSHppu16j8lMG+A5jnf9mFFgg= X-Google-Smtp-Source: APXvYqylXfW9yrcV9f513LzWQv3/+7Sqxdryl/83BV2Up91H7ixpeaGQcqIL+zvFuLwMxfIwuPGWQA== X-Received: by 2002:a2e:84d0:: with SMTP id q16mr22540923ljh.48.1574929713755; Thu, 28 Nov 2019 00:28:33 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k25sm8200163ljg.22.2019.11.28.00.28.32 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Nov 2019 00:28:33 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" Date: Thu, 28 Nov 2019 11:28:33 +0300 Message-ID: <036d01d5a5c5$d301f980$7905ec80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdWlwYYtE8QceRTzSW6790pXFByOkQ== Content-Language: ru Archived-At: Subject: [IPsec] Alternative Approach for Postquantum Preshared Keys in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 08:28:37 -0000 Hi, some time ago I've posted a new draft "An Alternative Approach for = Postquantum Preshared Keys in IKEv2". The draft was presented at IETF106: (https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-an= -alternative-approach-for-postquantum-preshared-keys-in-ikev2-00) But it seemed that few people have read it so far. So, here are some = words what is this draft about. AS you all know we have "Postquantum Preshared Keys for IKEv2" = (draft-ietf-ipsecme-qr-ikev2) draft=20 that is already in Publication Requested state. This draft defines a = mechanism to achieve PQ security by means of additional Preshared Key (PPK) that is mixed up in IKE SA = keys calculation. This approach is believed to be a temporary solution until new PK KE = primitives are standardized. One of the features of how PPK is used in draft-ietf-ipsecme-qr-ikev2 is = that an initial IKE SA, that is created as result of IKE_SA_INIT+IKE_AUTH is not quantum secure = itself. This was a WG decision to minimize changes to IKEv2. The idea was that if someone = needs IKE SA to be quantum secure, he/she will immediately do a rekey. The problem is that in the "Group Key Management using IKEv2" = (draft-yeung-g-ikev2), that is just adopted as a WG document, the responder (Group Controller / = Key Server) transfers session keys to the initiator (Group Member) immediately once = IKE SA between them is created. Obviously, keys are sensitive information and they are = not protected by PPK in this case. The workaround suggested in draft-yeung-g-ikev2-16 = is to perform quite long series of exchanges (consuming more resources) to postpone = session keys transfer until the initial SA is rekeyed. The draft "An Alternative Approach for Postquantum Preshared Keys in = IKEv2" proposes an alternative approach for using PPK by utilizing the IKE_INTERMEDIATE = exchange, in which PPK IDs are exchanged. This allows an initial IKE SA to be = secure against QC, that would substantially simplify G-IKEv2 implementation if = PQ security using PPK is needed. This alternative approach can also be used in regular IKEv2. Compared with draft-ietf-ipsecme-qr-ikev2 it has few advantages and a single drawback - it requires an additional exchange for IKE SA to set up. However, if IKE_INTERMEDIATE is used for some other (not yet defined) purposes too, the PPK IDs can be piggybacked and thus having no such = penalty as an extra exchange. Comments, reviews, opinions are very welcome. Is it worth to adopt this draft as a WG document? Regards, Valery. > A new version of I-D, draft-smyslov-ipsecme-ikev2-qr-alt-00.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. >=20 > Name: draft-smyslov-ipsecme-ikev2-qr-alt > Revision: 00 > Title: An Alternative Approach for Postquantum Preshared Keys in = IKEv2 > Document date: 2019-10-17 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-qr-alt-0= 0.txt > Status: = https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-qr-alt/ > Htmlized: = https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-qr-alt-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-ikev2-qr-alt >=20 >=20 > Abstract: > An IKEv2 extension defined in [I-D.ietf-ipsecme-qr-ikev2] allows > IPsec traffic to be protected against someone storing VPN > communications today and decrypting it later, when (and if) Quantum > Computers are available. However, this protection doesn't cover an > initial IKEv2 SA, which might be unacceptable in some scenarios. > This specification defines an alternative way get the same = protection > against Quantum Computers, which allows to extend it on the initial > IKEv2 SA. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Thu Nov 28 05:49:41 2019 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 685CC12016E for ; Thu, 28 Nov 2019 05:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 BROoLAq9Lx1H for ; Thu, 28 Nov 2019 05:49:38 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 1F9081200C4 for ; Thu, 28 Nov 2019 05:49:38 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id f16so20123261lfm.3 for ; Thu, 28 Nov 2019 05:49:37 -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=/r+oPSWt/74KKN7jHysWCoBdmOz1uZhha7OQhx2kosc=; b=ecqVJ6j1ksrJ4/77+MOmvcGfZmkegqjzcjLsx9G+SVRqfjTjYJdb3Kw4KOdjmxgIB3 l2esOezNy358O6GgegjMjGS5Lmq9KZl/CaZn+LkJGaSp08fBD+vkMBcH5fz5EbdArkW0 rtwDIyt+FnInEMT3lmjjXob8Ia3o1mGySoPeNpx0Hyv4Hg3LtzhpblU/3VdHPDDr+RSB 2/at+qEfc88Pq7IcxeaUrhW67l/4yZzXkBPBwtSjkpBs6aefIIxGEEe/WYlb2Kpro6Eu wES642si+biV09tvWfiLPnYwXuYyU3vYv4hmoh4JOByKUsAFn9D/UnYc0nykL8Gej8Ts qeMw== 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=/r+oPSWt/74KKN7jHysWCoBdmOz1uZhha7OQhx2kosc=; b=q3J8T5uz5y6xSoq/5qT0kCM9j7aJZtMXRlZYH84Tz4LNWjyrwZI5+0yt3uFcOHr1QQ 30RGsQ9O4qfXZsPT0BNOqcuPHfhaSJiqdBc6JCR+K9viOapKNdm/BaXbOXTU6WcQ2CQd /QEufvfnmTFZ2e9puwPOLvRF6a0CDEqudIGRDnhU1p1f+VDcnQx4wrGw+zKZ2CVijAkP Z+kVInez0kxZIku4/sPhB/fz79UXM3O/o+Ya15byT27US3TPF+AsmGTsfPOfTpYD2MvK TVDuWi56bOyiowAQ/6vtMlGh+O5dYWI1TRDRjBRvri2Xd2rUkQAEFI/LVdDPOaYJvrRA kvfg== X-Gm-Message-State: APjAAAU1MGcmr3/hA7IZ9BDPKjx5zmRlxZ8Tn6CCKQRqF8Or74NmenPw YWyLb84vXYZ/z7+cIPQDaqOlyHAc+v8= X-Google-Smtp-Source: APXvYqw4SPHtsupm1OGhz+r430GzctYzbHo9/bTOqyfteVvd7yCE1PUTeyGBGt/vZ+aYcCbVxyjNoQ== X-Received: by 2002:a19:7602:: with SMTP id c2mr32179805lff.118.1574948975927; Thu, 28 Nov 2019 05:49:35 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 2sm1392495ljq.38.2019.11.28.05.49.34 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Nov 2019 05:49:35 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" Date: Thu, 28 Nov 2019 16:49:36 +0300 Message-ID: <039e01d5a5f2$ac51d350$04f579f0$@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: AdWl6BVXLZeHvtaQS+eCdMt9oD2tCQ== Content-Language: ru Archived-At: Subject: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 13:49:39 -0000 Hi, after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts. 1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS for transport mode ESP is equally important because one of the widely used scenario is to combine general purpose tunneling (like GRE) with transport mode ESP. In this case traffic flowing over such SA will in fact be tunnel traffic from several hosts, but the SA is created in transport mode. For this reason I think that IP-TFS must support transport mode SA either. 2. I don't think new IP protocol number is needed at all. Since SA is created with IKEv2, it is always known whether it is IPTFS SA or ordinary SA, so "Next Protocol" field in ESP trailer is redundant and can be filled in with arbitrary value (say zero). If a new protocol number is allocated, it will never appear in any network header except for encrypted ESP trailer, still it will occupy a codepoint and some middle-box vendors will probably try to figure out what to do with it (nothing), adding some confusion. Moreover, I suspect that an idea to allocate a codepoint from rather limited resource (only 255 are available and more than half of them is already allocated), that will never appear in any network header and in reality is not needed, will meet a negative reaction from INT area guys. So, I think we should not go this way and just use zero (or other value) as a filler for "Next Header" field. 3. I think that using new Transform Type for IP-TFS negotiation is a bad idea. Transforms are best thing when combination of them matters. I don't think that it is the case - negotiation of using IP-TFS is orthogonal to negotiation of algorithms to use. I cannot imagine that one wants to use IPTFS with say AES-GCM and doesn't want to do it with say Chacha+Poly. So I believe it is better to negotiate IPTFS by means of notifications, as it is done with transport mode or WESP. So, a new notification (let call it USE_IPTFS) should be introduced, which will contain data regarding whether congestion control is needed and whether fragmentation is allowed. If the responder supports IPTFS it will return back this notification with the data reflecting its choice of IPTFS features. In this case IPTFS_REQUIREMENTS notification is not needed. 4. I'd like to see more text in the draft regarding reassembling of incoming packets. It seems to me that it can be done pretty easy by linking the reassembly logic with replay protection window. Note, that this won't work in case of multicast SA with several senders. 5. In general it seems to me that multicast case must be discussed in more details, since in this case neither congestion control nor fragmentation are possible. 6. I think that having inner IP packets properly aligned is a good idea. 7. I don't think that late-enabling of IP-TFS described in section 2.4 is really needed. It adds unnecessary complexity and somewhat contradicts to what is stated in section 2.3. Regards, Valery. From nobody Fri Nov 29 03:41:34 2019 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 32990120128 for ; Fri, 29 Nov 2019 03:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aytbqVSjCC7y for ; Fri, 29 Nov 2019 03:41:30 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 96339120124 for ; Fri, 29 Nov 2019 03:41:30 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 115576094B; Fri, 29 Nov 2019 11:41:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> Date: Fri, 29 Nov 2019 06:41:28 -0500 Cc: Christian Hopps , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 11:41:32 -0000 Transforms aren't just about the encryption algorithm though (e.g., the = extended sequence number transform). In the IP-TFS case it's not about = whether one would enable TFS with a given encryption algorithm. Consider = supporting and/or selecting from the set of IP-TFS with congestion = control, IP-TFS without congestion control, no-IP-TFS, or even another = future-defined TFS algorithm. Being able to easy negotiate these = different selections was what drove me to the current design. :) After coding this I will say using transforms feels like a very natural = fit. Thanks, Chris. > On Nov 28, 2019, at 8:49 AM, Valery Smyslov = wrote: >=20 > 3. I think that using new Transform Type for IP-TFS negotiation is a = bad idea. > Transforms are best thing when combination of them matters. I don't = think > that it is the case - negotiation of using IP-TFS is orthogonal to = negotiation > of algorithms to use. I cannot imagine that one wants to use IPTFS = with=20 > say AES-GCM and doesn't want to do it with say Chacha+Poly.=20 > So I believe it is better to negotiate IPTFS by means of = notifications, as it is done=20 > with transport mode or WESP. So, a new notification (let call it = USE_IPTFS) should be=20 > introduced, which will contain data regarding whether congestion = control > is needed and whether fragmentation is allowed. If the responder = supports > IPTFS it will return back this notification with the data = reflecting its choice > of IPTFS features. In this case IPTFS_REQUIREMENTS notification is = not needed. From nobody Fri Nov 29 04:09:58 2019 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 E5A33120180 for ; Fri, 29 Nov 2019 04:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 NAlyeYCTxgXu for ; Fri, 29 Nov 2019 04:09:55 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 76841120128 for ; Fri, 29 Nov 2019 04:09:55 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id 21so113566ljr.0 for ; Fri, 29 Nov 2019 04:09:55 -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=8e2odWK1vDQ8IyKnV0//yCUSTCxAjN9Yizle/FGFPXY=; b=Mt53V3N2llW6hnPr1ak/umMyAa25AOpKCNkwFouWGt/4/IAK0PXRTrh8LAw3H4vwAe BIgLbVeWQ1aTKKrTzwXvon9zmedElWOhE0VVycNs5LD5DPiADikWhqRlqKmyrpNQbsNR QpS3aLEN7XNzA+ndR/IAn+mFmJxXvjR5Ps+CfRaW+ZrZgNbFw/LS/AsYoV3kaSApDik0 KpucJIn5cLAWKq8nxTm+rNTu0QhEJ/ZwvTWVD5VYVmUAzPbWH7+WdyxdSLxnSQvOqC1w j6p9WJ4JZsyn/V25czdEw01cY8vpfjEW9XjcofnfXbm73f7F1WFgO9p90RMt9RyLN6gP tgPg== 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=8e2odWK1vDQ8IyKnV0//yCUSTCxAjN9Yizle/FGFPXY=; b=WcE75JvLDjq8WQKq+TIVjKPWEjGYDGzQzl48YC5lUHHWjeaZjiZDP6ksKT8ckrFRKK DXbCwgJYFp2b5uDvo1D7DMlXKQkMCZFN8Acwab8qKLw9EBQjVkT8loFldldlV4ANmymE Ph3d4kiy4y6QWr1RHOUuybBg1M9b1T+wkKzxvvEARQccCb4TjFNCc9Szp4zxy7pZw5ZF rnNUMnkB/gNpJgLft3XdAOeJosxElMi5cKZO9Xx8P52+CigVo19U3cvLYTBByJhgrLj6 +7Yra1Y9UKjA6NqwnAIQv0fvKcMPKZ8nsJnKzpnY+y9TSoWOeZdlDrXzFlrfh/ZaD5kA owzA== X-Gm-Message-State: APjAAAV+EwJhDqzq4Bw2j2P4wZuka3HU9nYFXEqYviHgUwqWXrLIHufT 4Y1bX8zmOKSo30S0QHwGKM3MaYj/ X-Google-Smtp-Source: APXvYqw+8yuXV/afNveIQ/2x2kmMlcPMtWCG3g90WeEPliqpb4EMAqP5yGvnHfRZDa/s52/58ePWwQ== X-Received: by 2002:a2e:99c5:: with SMTP id l5mr30302714ljj.229.1575029393614; Fri, 29 Nov 2019 04:09:53 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d24sm10005534ljg.73.2019.11.29.04.09.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Nov 2019 04:09:52 -0800 (PST) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'IPsecME WG'" References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> In-Reply-To: Date: Fri, 29 Nov 2019 15:09:54 +0300 Message-ID: <041b01d5a6ad$e9621550$bc263ff0$@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: AQHtQTffgHTNPTWByX2TyLtNjmyTVQN9yArOp1bk6YA= Content-Language: ru Archived-At: Subject: Re: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 12:09:57 -0000 Hi Chris, > Transforms aren't just about the encryption algorithm though (e.g., the extended sequence number > transform). Whether you want to use ESN or not can depend on selected cryptographic algorithms (there is no point to use ESN unless algorithm allows to encrypt a large amount of data with a single key). > In the IP-TFS case it's not about whether one would enable TFS with a given encryption algorithm. Exactly. That's why I think it's better to decouple the negotiation of IP-TFS from the negotiation of cryptographic algorithms. In your current proposal they are coupled, and this will lead to some problems. For example, if using IP-TFS congestion control is optional for the initiator, then it must include two IP-TFS transforms in every proposal. If using IP-TFS itself is optional, then all the proposals must be duplicated (with and w/o IP-TFS transforms), because legacy implementations will ignore the whole proposal when they see an unknown transform type in it. This will lead to SA payload explosion. And things will get worse with QSKE, since additional key exchanges must be negotiated using new transforms (they are crypto-related). > Consider supporting and/or selecting from the set of IP-TFS with congestion control, IP-TFS without > congestion control, no-IP-TFS, or even another future-defined TFS algorithm. Being able to easy negotiate > these different selections was what drove me to the current design. :) It can easily be done with a single notification containing the proposed features. The responder would send back the notification indicating the features it agrees to use. > After coding this I will say using transforms feels like a very natural fit. And notifications is even more natural fit :-) Regards, Valery. > Thanks, > Chris. > > > On Nov 28, 2019, at 8:49 AM, Valery Smyslov wrote: > > > > 3. I think that using new Transform Type for IP-TFS negotiation is a bad idea. > > Transforms are best thing when combination of them matters. I don't think > > that it is the case - negotiation of using IP-TFS is orthogonal to negotiation > > of algorithms to use. I cannot imagine that one wants to use IPTFS with > > say AES-GCM and doesn't want to do it with say Chacha+Poly. > > So I believe it is better to negotiate IPTFS by means of notifications, as it is done > > with transport mode or WESP. So, a new notification (let call it USE_IPTFS) should be > > introduced, which will contain data regarding whether congestion control > > is needed and whether fragmentation is allowed. If the responder supports > > IPTFS it will return back this notification with the data reflecting its choice > > of IPTFS features. In this case IPTFS_REQUIREMENTS notification is not needed. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Nov 29 04:47:34 2019 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 54A08120273 for ; Fri, 29 Nov 2019 04:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n99K7wkKISPv for ; Fri, 29 Nov 2019 04:47:30 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B233F12026E for ; Fri, 29 Nov 2019 04:47:30 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2DC916094B; Fri, 29 Nov 2019 12:47:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> Date: Fri, 29 Nov 2019 07:47:29 -0500 Cc: Christian Hopps , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 12:47:32 -0000 > On Nov 28, 2019, at 8:49 AM, Valery Smyslov = wrote: >=20 > 2. I don't think new IP protocol number is needed at all. Since SA is = created with IKEv2, > it is always known whether it is IPTFS SA or ordinary SA, so "Next = Protocol" > field in ESP trailer is redundant and can be filled in with = arbitrary value (say zero).=20 > If a new protocol number is allocated, it will never appear in any = network header=20 > except for encrypted ESP trailer, still it will occupy a codepoint = and some middle-box=20 > vendors will probably try to figure out what to do with it = (nothing), adding some confusion.=20 > Moreover, I suspect that an idea to allocate a codepoint from = rather limited resource > (only 255 are available and more than half of them is already = allocated), that will never > appear in any network header and in reality is not needed, will = meet a negative reaction from=20 > INT area guys. So, I think we should not go this way and just use = zero (or other value) > as a filler for "Next Header" field. I read part of the above as more an argument for decoupling the ESP next = header number from IP protocol number space, and not so much as a lack = of need for a unique payload identifier for the ESP next header field. = This might work if we really want to do this (i.e., create an ESP = payload registry separate from the IP protocol numbers), but honestly I = think it may be overkill given there are plenty of IP protocol numbers = available, and we only need 1 protocol number which we can re-use later = if need be. You may be right that 1/2 of the numbers are allocated; = however, at least one is deprecated and others could be deprecated = (i.e., there's so little pressure on this registry that deprecating = unused numbers just hasn't been something worth doing AFAICT). With all = that this represents 38 years of allocations. I think we just need to = make a clear case for the use, and that we wont keep coming back for = more is all. Additionally, I'm not sure that we should be so quick to say that the = IP-TFS payload would never be used outside of ESP; as was pointed out by = Michael using this payload does solve the PMTU issue with (IPsec) = tunnels, it could be re-used for this purpose outside of ESP as well. The next-header value is not always redundant, the use case where IP-TFS = is enabled in only one direction with congestion control enabled = requires being able to differentiate IPv[46] packets from IP-TFS CC = information which is now sent in-band in the return direction. The CC = information was moved in-band out of IKEv2 from the original -00 = document based on comments from the WG (and I agree is a much better = solution :) So, I think we need to stick with explicitly identifying the payload = inside ESP. Using the next-header field feels like the correct way of = doing this; however, I haven't looked at ESP wrap yet. I do have = concerns (which Tero also mentioned at the mic) that it might not be = widely implemented. Possibly re-using the payload type outside of ESP someday is an = additional argument for doing the least-disruptive thing and just = allocating an IP number. We don't even need a *new* IP protocol number, = we could re-use a deprecated IP protocol number. This seems like a nice = option to look into. > 7. I don't think that late-enabling of IP-TFS described in section 2.4 > is really needed. It adds unnecessary complexity and somewhat = contradicts=20 > to what is stated in section 2.3. Having the late-enable could be useful for debugging tunnels during = bring-up. This does rely on having a way to identify the payload, but as = mentioned above this isn't the only thing that relies on that. It didn't = add much complexity to my code, but I'm certainly curious on other = opinions on this. Thanks, Chris.= From nobody Fri Nov 29 05:13:09 2019 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 6FD2D120289 for ; Fri, 29 Nov 2019 05:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 0IDS7J6PLeUJ for ; Fri, 29 Nov 2019 05:13:05 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 2D68B1200E9 for ; Fri, 29 Nov 2019 05:13:05 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id a15so35142837wrf.9 for ; Fri, 29 Nov 2019 05:13:05 -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=qNhhFKdcNoWaZLKrq/56BHv6aDptxkAjN0OsPmvam2g=; b=TM/1gKWmdBpUL2Qd11vsOrtrivlaB952amHHyjPCcdhG9GyFiFzrRj4rUG6xsZxjNj lGJoYSPEhb7fMkwv9Aw9qoER3aT//sOR9PMKAn7WBtYNOD7DDSbgOyDCDoePXDmp7ia/ 2l2RsdnYyveNyoMH5QtP6NJsxjG31z2MP5PxzmZm7oFXvHjeQna/XA6i7xUNXX6kYban QPaGwDbFRrNAGBGI9i/gljPf+reJqpS96LirOqwO0DKYIQ4JEdN0npUm4Mel10O6t7W0 NFuwoRGXrBIPPoWP4P9YgBaBUtp5Z7ZEWwW4aviEB6+D7od42vt1BUN5AorMkRlo7Y4F i7tg== 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=qNhhFKdcNoWaZLKrq/56BHv6aDptxkAjN0OsPmvam2g=; b=ENZt/uNoBM22Wos7kJ5u0XvJOjz2ImwME/+TEodztGKXwkBCV/DmhqU++ut05Ldbb3 +Y81LOKjK3kBFs2dJTrxgWFbEeaDGhIPcqUS8z/sagwchNyWO9PS3fClGdhy9X3YkC4G AhNpoxZqbCoN2Z3DngMFwHle9Cjrq069YrK8UOYU323kbhP8nfASl0S9xPTYcSlplWcL /lI5Rg0bXmz5OAMH2h4fXayt7vB2jXCJsuyNsA/8y6Hbgvo1rwokM6q/A1ZE2iiYDLpZ vOjIvj226pCcy3CQr/EAzLuI4MfSniQZGoay/gqw1/dfYbUK4fVB5QJVaaN8vcDR+ixR eCog== X-Gm-Message-State: APjAAAW2THMGlc+xZaQTZM7GcBZOtqM+3tfRWCC33jdutYB9jE2okSBn /OgITF4rlvFvq+CpL15i4HA= X-Google-Smtp-Source: APXvYqy5noiZOc/qbDs7QIWpLgsCw0P3g9j01h5vvz1Vzy8GHwnDAUU2iJnkGkE4A2jcnoilPZP5KA== X-Received: by 2002:adf:83c7:: with SMTP id 65mr8879260wre.368.1575033183499; Fri, 29 Nov 2019 05:13:03 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d14sm14792216wru.9.2019.11.29.05.13.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Nov 2019 05:13:03 -0800 (PST) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'IPsecME WG'" References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> In-Reply-To: Date: Fri, 29 Nov 2019 16:13:04 +0300 Message-ID: <042301d5a6b6$bc8e9fe0$35abdfa0$@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: AQHtQTffgHTNPTWByX2TyLtNjmyTVQIQFEdcp2Jl0AA= Content-Language: ru Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 13:13:07 -0000 Hi Chris, > > 2. I don't think new IP protocol number is needed at all. Since SA is created with IKEv2, > > it is always known whether it is IPTFS SA or ordinary SA, so "Next Protocol" > > field in ESP trailer is redundant and can be filled in with arbitrary value (say zero). > > If a new protocol number is allocated, it will never appear in any network header > > except for encrypted ESP trailer, still it will occupy a codepoint and some middle-box > > vendors will probably try to figure out what to do with it (nothing), adding some confusion. > > Moreover, I suspect that an idea to allocate a codepoint from rather limited resource > > (only 255 are available and more than half of them is already allocated), that will never > > appear in any network header and in reality is not needed, will meet a negative reaction from > > INT area guys. So, I think we should not go this way and just use zero (or other value) > > as a filler for "Next Header" field. > > > I read part of the above as more an argument for decoupling the ESP next header number from IP protocol > number space, and not so much as a lack of need for a unique payload identifier for the ESP next header field. > This might work if we really want to do this (i.e., create an ESP payload registry separate from the IP protocol > numbers), but honestly I think it may be overkill given there are plenty of IP protocol numbers available, and > we only need 1 protocol number which we can re-use later if need be. You may be right that 1/2 of the > numbers are allocated; however, at least one is deprecated and others could be deprecated (i.e., there's so > little pressure on this registry that deprecating unused numbers just hasn't been something worth doing > AFAICT). With all that this represents 38 years of allocations. I think we just need to make a clear case for the > use, and that we wont keep coming back for more is all. I envision a lively discussion with INT folks if we ask them for a "fake" protocol number :-) > Additionally, I'm not sure that we should be so quick to say that the IP-TFS payload would never be used > outside of ESP; as was pointed out by Michael using this payload does solve the PMTU issue with (IPsec) > tunnels, it could be re-used for this purpose outside of ESP as well. Please, elaborate. > The next-header value is not always redundant, the use case where IP-TFS is enabled in only one direction > with congestion control enabled requires being able to differentiate IPv[46] packets from IP-TFS CC > information which is now sent in-band in the return direction. The CC information was moved in-band out of > IKEv2 from the original -00 document based on comments from the WG (and I agree is a much better solution > :) It's a strange use case. Both peers must support IP-TFS, but it is used only in one direction, so its usefulness is limited (you can gain quite a lot information from timing of return packets). Do we really need to complicate things to allow such asymmetric use case? BTW, you cannot negotiate it with your current spec :-) > So, I think we need to stick with explicitly identifying the payload inside ESP. Using the next-header field feels > like the correct way of doing this; however, I haven't looked at ESP wrap yet. I do have concerns (which Tero > also mentioned at the mic) that it might not be widely implemented. > > Possibly re-using the payload type outside of ESP someday is an additional argument for doing the least- > disruptive thing and just allocating an IP number. We don't even need a *new* IP protocol number, we could > re-use a deprecated IP protocol number. This seems like a nice option to look into. I'm still not sure that it's really needed. > > 7. I don't think that late-enabling of IP-TFS described in section 2.4 > > is really needed. It adds unnecessary complexity and somewhat contradicts > > to what is stated in section 2.3. > > Having the late-enable could be useful for debugging tunnels during bring-up. This does rely on having a way > to identify the payload, but as mentioned above this isn't the only thing that relies on that. It didn't add much > complexity to my code, but I'm certainly curious on other opinions on this. Color me unconvinced. Debugging is a local matter and should not be reflected in the spec. Regards, Valery. > Thanks, > Chris.= From nobody Fri Nov 29 05:48:53 2019 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 1887C120220 for ; Fri, 29 Nov 2019 05:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdUvoWBvkPIm for ; Fri, 29 Nov 2019 05:48:50 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 398D81200E9 for ; Fri, 29 Nov 2019 05:48:50 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9C4406094B; Fri, 29 Nov 2019 13:48:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <041b01d5a6ad$e9621550$bc263ff0$@gmail.com> Date: Fri, 29 Nov 2019 08:48:48 -0500 Cc: Christian Hopps , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: <3B82404F-3121-444F-97A0-6E18258DAC04@chopps.org> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <041b01d5a6ad$e9621550$bc263ff0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 13:48:52 -0000 > On Nov 29, 2019, at 7:09 AM, Valery Smyslov = wrote: >=20 > Hi Chris, >=20 >> Transforms aren't just about the encryption algorithm though (e.g., = the extended sequence number >> transform).=20 >=20 > Whether you want to use ESN or not can depend on selected = cryptographic algorithms > (there is no point to use ESN unless algorithm allows to encrypt a = large amount of data with a single key). >=20 >> In the IP-TFS case it's not about whether one would enable TFS with a = given encryption algorithm. >=20 > Exactly. That's why I think it's better to decouple the negotiation of = IP-TFS from the negotiation=20 > of cryptographic algorithms. >=20 > In your current proposal they are coupled, and this will lead to some = problems. > For example, if using IP-TFS congestion control is optional for the = initiator, then it must include > two IP-TFS transforms in every proposal. If using IP-TFS itself is = optional, then > all the proposals must be duplicated (with and w/o IP-TFS transforms), = because > legacy implementations will ignore the whole proposal when they see > an unknown transform type in it. This will lead to SA payload = explosion. > And things will get worse with QSKE, since additional key exchanges = must > be negotiated using new transforms (they are crypto-related). >=20 >> Consider supporting and/or selecting from the set of IP-TFS with = congestion control, IP-TFS without >> congestion control, no-IP-TFS, or even another future-defined TFS = algorithm. Being able to easy negotiate >> these different selections was what drove me to the current design. = :) >=20 > It can easily be done with a single notification containing the = proposed features. > The responder would send back the notification indicating the features = it agrees to use. >=20 I have some doubts about calling this "easy". This sounds a lot like the = already existing transform mechanism. Are there other deployed examples = of negotiating the required features of an SA using notifications in = parallel with the transforms? It seems to me there's a lot of standard = text, experience, and deployed code written getting the transform = negotiation mechanism working correctly. Duplicating this rather than = re-using it worries me. Thanks, Chris. >> After coding this I will say using transforms feels like a very = natural fit. >=20 > And notifications is even more natural fit :-) >=20 > Regards, > Valery. >=20 >> Thanks, >> Chris. >>=20 >>> On Nov 28, 2019, at 8:49 AM, Valery Smyslov = wrote: >>>=20 >>> 3. I think that using new Transform Type for IP-TFS negotiation is a = bad idea. >>> Transforms are best thing when combination of them matters. I don't = think >>> that it is the case - negotiation of using IP-TFS is orthogonal to = negotiation >>> of algorithms to use. I cannot imagine that one wants to use IPTFS = with >>> say AES-GCM and doesn't want to do it with say Chacha+Poly. >>> So I believe it is better to negotiate IPTFS by means of = notifications, as it is done >>> with transport mode or WESP. So, a new notification (let call it = USE_IPTFS) should be >>> introduced, which will contain data regarding whether congestion = control >>> is needed and whether fragmentation is allowed. If the responder = supports >>> IPTFS it will return back this notification with the data = reflecting its choice >>> of IPTFS features. In this case IPTFS_REQUIREMENTS notification is = not needed. >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Fri Nov 29 06:01:35 2019 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 6A00712011D for ; Fri, 29 Nov 2019 06:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 jusA15vYpOPj for ; Fri, 29 Nov 2019 06:01:32 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B28C11200E9 for ; Fri, 29 Nov 2019 06:01:31 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id 203so22698283lfa.12 for ; Fri, 29 Nov 2019 06:01:31 -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=WlfgzzoEdaXlF78diQFKQrwHsdyXrKsappzTaCW91bo=; b=nDFLlyXHIsRhk3uTC8fnn9dJMbGdb+4dKROaU0CEJ8rfg4jhTLQJDQVnFml5TeBLjx yMp9tUE5JHHapZRdyGyvK/0lpTAcPET+3Tc5PXNSnB29ryJMe0B7AdSmqUNEm1q1h3b0 botdhzMGPbqhngZMZ3YO000H4oRAjRQVxZiuHxKvTYyjP46utEHAP92TmVuzmtsAG45s Jq3gd78S7oGAmWp7tGoEBPX9AvXFQqmIC9GwDD1TIjhqW5Jj+4lt2C+FS54/IQm52HWK chejQAsUGjHauG3X86wKFc7DpxHiG/lM1XawCNR0APcLWp/3OfvArWI1IPqviN9dMDRz K+1g== 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=WlfgzzoEdaXlF78diQFKQrwHsdyXrKsappzTaCW91bo=; b=j70SZnjc6HPnlcF8lAFb4EPJso749H/+G+vgbq3MI0ChwkFbjKh0wFCRWdg0fenC5Q R0vP2N8Tzto7GAu8V1KATGfPDWMb9bJRpTNCtZgaf4wAXoamS6RQZxul89dTdcmA6Usq CaNRYa6SFywtrh3TDby3cTiU+dTzRoOJB7KWaWoJqvFwaKlZPbBOyUC6rvucxePU9EOl FDv/zyQjiKlcb2k5REYnGpNdSc0ZCRA7gGyUbaA+GCpXcTevvfqnARY853Xp6+64ti8D 9RWVPiuUtaUdgkQOpf1BhwyvnjjXyv5XC28FMi8G+eC/FPAv6khB7yDJfXQESU7iBamM wztQ== X-Gm-Message-State: APjAAAWK/BavyGmfO8OwcDWuWFbbLgUL2uOfkWsAByFdqh1P60WY1y9K ldc/PvRvqWOnS6bmZrhNLXqLxe4S X-Google-Smtp-Source: APXvYqzqVY/Wm56FgPGR6A+RjVQSkv4UjBXNaNXNILw7yHq3eSj93Ga/ktV/K1rKnvDkQn1wDPy8qg== X-Received: by 2002:a05:6512:20e:: with SMTP id a14mr16007856lfo.63.1575036089657; Fri, 29 Nov 2019 06:01:29 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k24sm381703ljj.27.2019.11.29.06.01.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Nov 2019 06:01:29 -0800 (PST) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'IPsecME WG'" References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <041b01d5a6ad$e9621550$bc263ff0$@gmail.com> <3B82404F-3121-444F-97A0-6E18258DAC04@chopps.org> In-Reply-To: <3B82404F-3121-444F-97A0-6E18258DAC04@chopps.org> Date: Fri, 29 Nov 2019 17:01:31 +0300 Message-ID: <043801d5a6bd$80cd8500$82688f00$@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: AQHtQTffgHTNPTWByX2TyLtNjmyTVQN9yArOAgpNmd0Cf/zk2KcyteMg Content-Language: ru Archived-At: Subject: Re: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 14:01:33 -0000 > > It can easily be done with a single notification containing the proposed features. > > The responder would send back the notification indicating the features it agrees to use. > > > > I have some doubts about calling this "easy". This sounds a lot like the already existing transform mechanism. > Are there other deployed examples of negotiating the required features of an SA using notifications in parallel > with the transforms? It seems to me there's a lot of standard text, experience, and deployed code written > getting the transform negotiation mechanism working correctly. Duplicating this rather than re-using it > worries me. A lot of things in IKEv2 is negotiated by using notifications. With regard to child SA they are - using transport mode, using IPcomp, using WESP, using ROHC. IP-TFC looks to me like a natural continuation of this line. Regards, Valery. > Thanks, > Chris. > > >> After coding this I will say using transforms feels like a very natural fit. > > > > And notifications is even more natural fit :-) > > > > > > Regards, > > Valery. > > > >> Thanks, > >> Chris. > >> > >>> On Nov 28, 2019, at 8:49 AM, Valery Smyslov wrote: > >>> > >>> 3. I think that using new Transform Type for IP-TFS negotiation is a bad idea. > >>> Transforms are best thing when combination of them matters. I don't think > >>> that it is the case - negotiation of using IP-TFS is orthogonal to negotiation > >>> of algorithms to use. I cannot imagine that one wants to use IPTFS with > >>> say AES-GCM and doesn't want to do it with say Chacha+Poly. > >>> So I believe it is better to negotiate IPTFS by means of notifications, as it is done > >>> with transport mode or WESP. So, a new notification (let call it USE_IPTFS) should be > >>> introduced, which will contain data regarding whether congestion control > >>> is needed and whether fragmentation is allowed. If the responder supports > >>> IPTFS it will return back this notification with the data reflecting its choice > >>> of IPTFS features. In this case IPTFS_REQUIREMENTS notification is not needed. > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Fri Nov 29 07:38:22 2019 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 31A871200F3 for ; Fri, 29 Nov 2019 07:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTN-WM7kZyUg for ; Fri, 29 Nov 2019 07:38:18 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 568E212004E for ; Fri, 29 Nov 2019 07:38:18 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 759626094B; Fri, 29 Nov 2019 15:38:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> Date: Fri, 29 Nov 2019 10:38:16 -0500 Cc: Christian Hopps , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 15:38:21 -0000 > On Nov 29, 2019, at 8:13 AM, Valery Smyslov = wrote: >=20 > Hi Chris, >=20 >>> 2. I don't think new IP protocol number is needed at all. Since SA = is created with IKEv2, >>> it is always known whether it is IPTFS SA or ordinary SA, so = "Next Protocol" >>> field in ESP trailer is redundant and can be filled in with = arbitrary value (say zero). >>> If a new protocol number is allocated, it will never appear in any = network header >>> except for encrypted ESP trailer, still it will occupy a codepoint = and some middle-box >>> vendors will probably try to figure out what to do with it = (nothing), adding some confusion. >>> Moreover, I suspect that an idea to allocate a codepoint from = rather limited resource >>> (only 255 are available and more than half of them is already = allocated), that will never >>> appear in any network header and in reality is not needed, will = meet a negative reaction from >>> INT area guys. So, I think we should not go this way and just use = zero (or other value) >>> as a filler for "Next Header" field. >>=20 >>=20 >> I read part of the above as more an argument for decoupling the ESP = next header number from IP protocol >> number space, and not so much as a lack of need for a unique payload = identifier for the ESP next header field. >> This might work if we really want to do this (i.e., create an ESP = payload registry separate from the IP protocol >> numbers), but honestly I think it may be overkill given there are = plenty of IP protocol numbers available, and >> we only need 1 protocol number which we can re-use later if need be. = You may be right that 1/2 of the >> numbers are allocated; however, at least one is deprecated and others = could be deprecated (i.e., there's so >> little pressure on this registry that deprecating unused numbers just = hasn't been something worth doing >> AFAICT). With all that this represents 38 years of allocations. I = think we just need to make a clear case for the >> use, and that we wont keep coming back for more is all. >=20 > I envision a lively discussion with INT folks if we ask them for a = "fake" protocol number :-) I would not choose to refer to it as a fake protocol. The field is = defined as an IPv4 or IPv6 protocol value to identify the ESP payload. = IPsec/ESP is *the* standard for encrypting IP traffic so this field has = a valid claim to make on that number space. Just b/c it may not (but see = next point) be used outside of IPsec/ESP doesn't mean that IPsec should = not be able to allocate a number from it. >=20 >> Additionally, I'm not sure that we should be so quick to say that the = IP-TFS payload would never be used >> outside of ESP; as was pointed out by Michael using this payload does = solve the PMTU issue with (IPsec) >> tunnels, it could be re-used for this purpose outside of ESP as well. >=20 > Please, elaborate. The IP-TFS payload format allows for any-sized IP packet to be = encapsulated inside an MTU sized outer header. Thus something like a GRE = tunnel (with sequence numbers) with PMTU size-limited packets would not = limit the inner payload packet size to the PMTU of the GRE tunnel. I'm = not proposing this right now, but it's not hard to envision this use in = the future, especially if IP-TFS is widely adopted by vendors. >=20 >> The next-header value is not always redundant, the use case where = IP-TFS is enabled in only one direction >> with congestion control enabled requires being able to differentiate = IPv[46] packets from IP-TFS CC >> information which is now sent in-band in the return direction. The CC = information was moved in-band out of >> IKEv2 from the original -00 document based on comments from the WG = (and I agree is a much better solution >> :) >=20 > It's a strange use case. Both peers must support IP-TFS, but it is = used only in one direction, so its usefulness=20 > is limited (you can gain quite a lot information from timing of return = packets). Do we really need to complicate > things to allow such asymmetric use case? BTW, you cannot negotiate it = with your current spec :-) I do not think this is strange, consider uni-directional data streams, = e.g., telemetry. >> So, I think we need to stick with explicitly identifying the payload = inside ESP. Using the next-header field feels >> like the correct way of doing this; however, I haven't looked at ESP = wrap yet. I do have concerns (which Tero >> also mentioned at the mic) that it might not be widely implemented. >>=20 >> Possibly re-using the payload type outside of ESP someday is an = additional argument for doing the least- >> disruptive thing and just allocating an IP number. We don't even need = a *new* IP protocol number, we could >> re-use a deprecated IP protocol number. This seems like a nice option = to look into. >=20 > I'm still not sure that it's really needed. >=20 >>> 7. I don't think that late-enabling of IP-TFS described in section = 2.4 >>> is really needed. It adds unnecessary complexity and somewhat = contradicts >>> to what is stated in section 2.3. >>=20 >> Having the late-enable could be useful for debugging tunnels during = bring-up. This does rely on having a way >> to identify the payload, but as mentioned above this isn't the only = thing that relies on that. It didn't add much >> complexity to my code, but I'm certainly curious on other opinions on = this. >=20 > Color me unconvinced. Debugging is a local matter and should not be = reflected in the spec. ICMP echo request/reply? :) More apropos, adding things to a protocol to make it easier to = deploy/debug is not uncommon, we certainly have examples of this in = routing (e.g., host identifier TLV in IS-IS etc)... If this were the only reason for using the next header field I'd say the = case is not strong for keeping it, but we still have the uni-directional = CC case, so this second use doesn't cost much IMO. Thanks, Chris. >=20 > Regards, > Valery. >=20 >> Thanks, >> Chris.=3D >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Fri Nov 29 08:14:05 2019 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 3A5E512099D for ; Fri, 29 Nov 2019 08:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 GDv9H9upSsFU for ; Fri, 29 Nov 2019 08:14:02 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 27D16120998 for ; Fri, 29 Nov 2019 08:14:01 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id r15so20092598lff.2 for ; Fri, 29 Nov 2019 08:14:01 -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=Jsm889FrPL/JKO1ja69edkOWk1ywr/MAOrZrW5t5IZE=; b=cyWHBN/7P9LMJ95Ucq/TUPEbIyLpuWBT4ESnn4YSPQ0HjDZif5DABpyr4Pk3SV8hJY MMGcaoKFMF1cZXgf9ag4PD0xFcMNa8cF99w1pOgJQR6269AKibXg13DUIgDRnbkAFm9R oLVtRxOB1lxcaqCMHuKAMVcOd4G4SIczM/9v7RCZqHWrlDdFeQsi7ex5u1ktuhJRfIXs ScRwDnYLyGmKD0of6fuUmfroYPLY4YHXJz4hCeqluLPo2HizKir97cMwuKDUCIqIRnFP ErNes6GqPGNTkF75Flf0+wKNdRMPQoOJuqV6eXHnHY0a+1fQPg+elhjNuuC+qnY+lE+7 7ovw== 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=Jsm889FrPL/JKO1ja69edkOWk1ywr/MAOrZrW5t5IZE=; b=nhZhgo0vpt6lAg3/N+KGsz65mDGQmEBOpwEkN8Cn+/ot4dTrj4qRWDNovz/HHmXryA Cyosk64TWvyIiUkRDdB97FKcCdyvmlpPb1fuRQAerXjfn1/ELHPIoPNeUsL40PBPCmEl A8YEGnwkCvHBqFciz4/4utomwaoIt2N8WQrRlR9sgg0tju7O4SJ82fhKHm9ewiJHKFgy hnaHC7MccNkJP/yCr5UFP2wB/ghAUzYLpvmKvJXJMze5HhYSi4AjGSQN0wwfstSUWNto efHgW7EAbeiqlAwheVYxXtADF1RX5Cntjm6gFsIi+LucP3dRToDN9XN9SeohRkj30cx2 wCew== X-Gm-Message-State: APjAAAU+GCM1NmowgSRvkbP///FEYRqHQLWxdU9lFxpkMk9OrU/yraMN VskL4Rx9o2SsMHL4py4VCO4= X-Google-Smtp-Source: APXvYqyngNeuJ8z6dgaBG4PejD96t5LkbBQxgWTaCDfWxukki85nQ5krcOHvEaiWEHg/kB+uba7ylA== X-Received: by 2002:ac2:410a:: with SMTP id b10mr9108135lfi.135.1575044039282; Fri, 29 Nov 2019 08:13:59 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r20sm9792593lfi.91.2019.11.29.08.13.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Nov 2019 08:13:58 -0800 (PST) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'IPsecME WG'" References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> In-Reply-To: Date: Fri, 29 Nov 2019 19:14:00 +0300 Message-ID: <044701d5a6d0$032d5a90$09880fb0$@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: AQHtQTffgHTNPTWByX2TyLtNjmyTVQIQFEdcAazHshQCpl+r0qc//eow Content-Language: ru Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 16:14:04 -0000 > > I envision a lively discussion with INT folks if we ask them for a "fake" protocol number :-) > > I would not choose to refer to it as a fake protocol. The field is defined as an IPv4 or IPv6 protocol value to > identify the ESP payload. IPsec/ESP is *the* standard for encrypting IP traffic so this field has a valid claim to > make on that number space. Just b/c it may not (but see next point) be used outside of IPsec/ESP doesn't > mean that IPsec should not be able to allocate a number from it. I meant that this IP protocol number will never be seen (and used) outside ESP. So, it's an ESP-only protocol number, thus for INT folks it's a "fake" one. > >> Additionally, I'm not sure that we should be so quick to say that the IP-TFS payload would never be used > >> outside of ESP; as was pointed out by Michael using this payload does solve the PMTU issue with (IPsec) > >> tunnels, it could be re-used for this purpose outside of ESP as well. > > > > Please, elaborate. > > The IP-TFS payload format allows for any-sized IP packet to be encapsulated inside an MTU sized outer > header. Thus something like a GRE tunnel (with sequence numbers) with PMTU size-limited packets would not > limit the inner payload packet size to the PMTU of the GRE tunnel. I'm not proposing this right now, but it's > not hard to envision this use in the future, especially if IP-TFS is widely adopted by vendors. Ah, I see - you want to use the same technique inside some other tunneling protocol. This is doable, but in my opinion you should have control layer to set up such a tunnel (like IKEv2 does for ESP), and you'll probably have this tunnel dedicated to IP-TFS traffic only, and the peers would negotiate this feature over the control layer. So, new protocol number seems redundant in this case too. I can't buy this argument. > >> The next-header value is not always redundant, the use case where IP-TFS is enabled in only one direction > >> with congestion control enabled requires being able to differentiate IPv[46] packets from IP-TFS CC > >> information which is now sent in-band in the return direction. The CC information was moved in-band out > of > >> IKEv2 from the original -00 document based on comments from the WG (and I agree is a much better > solution > >> :) > > > > It's a strange use case. Both peers must support IP-TFS, but it is used only in one direction, so its usefulness > > is limited (you can gain quite a lot information from timing of return packets). Do we really need to > complicate > > things to allow such asymmetric use case? BTW, you cannot negotiate it with your current spec :-) > > I do not think this is strange, consider uni-directional data streams, e.g., telemetry. ESP SAs are always created in pairs. And whether IP-TFS is enabled or not is common for both SAs. Even if you use only one SA for IP-TFS traffic, the other will have IP-TFS enabled too. How are you going with your spec to create a pair of SAs where IP-TFS is enabled in one direction and disabled in the other? Am I missing something? Even if you are able to create such a pair of SAs, is it justified? > >>> 7. I don't think that late-enabling of IP-TFS described in section 2.4 > >>> is really needed. It adds unnecessary complexity and somewhat contradicts > >>> to what is stated in section 2.3. > >> > >> Having the late-enable could be useful for debugging tunnels during bring-up. This does rely on having a > way > >> to identify the payload, but as mentioned above this isn't the only thing that relies on that. It didn't add > much > >> complexity to my code, but I'm certainly curious on other opinions on this. > > > > Color me unconvinced. Debugging is a local matter and should not be reflected in the spec. > > ICMP echo request/reply? :) It's not for debugging, it's for testing network connectivity. >From what's written in you draft I made a conclusion that you want to help debugging implementations, that's completely different thing. > More apropos, adding things to a protocol to make it easier to deploy/debug is not uncommon, we certainly > have examples of this in routing (e.g., host identifier TLV in IS-IS etc)... > > If this were the only reason for using the next header field I'd say the case is not strong for keeping it, but we > still have the uni-directional CC case, so this second use doesn't cost much IMO. Hmm, see above about uni-directional CC. Regards, Valery. > Thanks, > Chris. > > > > > Regards, > > Valery. > > > >> Thanks, > >> Chris.= > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Fri Nov 29 09:38:56 2019 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 C54F112089E for ; Fri, 29 Nov 2019 09:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJC6rEjYhXqT for ; Fri, 29 Nov 2019 09:38:53 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5E61912089A for ; Fri, 29 Nov 2019 09:38:53 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id C701760927; Fri, 29 Nov 2019 17:38:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <044701d5a6d0$032d5a90$09880fb0$@gmail.com> Date: Fri, 29 Nov 2019 12:38:51 -0500 Cc: Christian Hopps , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: <5CAB559D-595E-4503-AC72-31E88B6F53AA@chopps.org> References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> <044701d5a6d0$032d5a90$09880fb0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 17:38:55 -0000 > On Nov 29, 2019, at 11:14 AM, Valery Smyslov = wrote: >=20 >>> I envision a lively discussion with INT folks if we ask them for a = "fake" protocol number :-) >>=20 >> I would not choose to refer to it as a fake protocol. The field is = defined as an IPv4 or IPv6 protocol value to >> identify the ESP payload. IPsec/ESP is *the* standard for encrypting = IP traffic so this field has a valid claim to >> make on that number space. Just b/c it may not (but see next point) = be used outside of IPsec/ESP doesn't >> mean that IPsec should not be able to allocate a number from it. >=20 > I meant that this IP protocol number will never be seen (and used) = outside ESP.=20 > So, it's an ESP-only protocol number, thus for INT folks it's a "fake" = one. What I'm saying is that IPsec/ESP is *the* standard for encrypted IP = even in the context of INT, so the next header field in the ESP payload = is a valid IP protocol payload in that context, it's not fake in the INT = context just b/c it might not be used outside of encrypted IP packets. [...] >>>> The next-header value is not always redundant, the use case where = IP-TFS is enabled in only one direction >>>> with congestion control enabled requires being able to = differentiate IPv[46] packets from IP-TFS CC >>>> information which is now sent in-band in the return direction. The = CC information was moved in-band out >> of >>>> IKEv2 from the original -00 document based on comments from the WG = (and I agree is a much better >> solution >>>> :) >>>=20 >>> It's a strange use case. Both peers must support IP-TFS, but it is = used only in one direction, so its usefulness >>> is limited (you can gain quite a lot information from timing of = return packets). Do we really need to >> complicate >>> things to allow such asymmetric use case? BTW, you cannot negotiate = it with your current spec :-) >>=20 >> I do not think this is strange, consider uni-directional data = streams, e.g., telemetry. >=20 > ESP SAs are always created in pairs. And whether IP-TFS is enabled or = not is common for both SAs. > Even if you use only one SA for IP-TFS traffic, the other will have = IP-TFS enabled too. > How are you going with your spec to create a pair of SAs where IP-TFS = is enabled in one direction and=20 > disabled in the other? Am I missing something? Even if you are able to = create such a pair of SAs, is it justified? Understood that SAs are created in pairs. The intent here (and = throughout the draft) is not to unnecessarily restrict possible uses. = Having IP-TFS enabled on only one of a pair of SAs can make sense when = you're only trying to protect traffic sent in one direction from traffic = analysis (again e.g., telemetry). The use of IP-TFS does involve the = allocation of a fixed amount of bandwidth so the justification for not = enabling it in one direction is to save that bandwidth. The spec is (trying to be) very careful in not restricting the = unidirectional TFS use case b/c there's no reason to do so, and so there = should not be anything in the document that restricts having only one of = the SA pairs used by IPsec/ESP running with IP-TFS. Setting up such an SA pair is orthogonal to being able to run with that = configuration. While the vast majority of IPsec utilizes IKEv2 for SA = creation/management, this is not a requirement of IPsec/ESP. The = unidirectional case can be covered with local configuration (along with = IKEv2), or by using another method entirely for the SA management. The intent in the end is to specify what we need to for IP-TFS = operation, but not too over-specify and unnecessarily restrict possible = future (or outside) uses. IOW, less is more. FWIW, I did explore adding machinery to IKEv2 to allow setting = up/negotiating unidirectional use cases, but it adds a lot of = complexity, and so we decided that while unidirectional TFS protection = is useful it will still be a relatively uncommon configuration and was = best left for local configuration for now. If in the future we see a = large call for on-demand/negotiated (vs local config) uni-directional = TFS we can always come back and add it to IKEv2. What's important in the = context of the IKEv2 changes for now is that we don't do anything to = block doing this in the future. Thanks, Chris. From nobody Fri Nov 29 11:18:06 2019 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 BE5C712013A for ; Fri, 29 Nov 2019 11:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgGL7h4IZhfJ for ; Fri, 29 Nov 2019 11:18:03 -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 418D2120105 for ; Fri, 29 Nov 2019 11:18:03 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C218B3897B; Fri, 29 Nov 2019 14:14:31 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9C4BC66D; Fri, 29 Nov 2019 14:18:01 -0500 (EST) To: Christian Hopps , IPsecME WG In-Reply-To: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> From: Michael Richardson X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 19:18:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable As I understand it, the question is: ESP(np=3D??)[IP-fragment, .., IP-fragment, padding] IPvX(np=3DESP) L2 What will the ?? be. I agree that it makes no sense to mark this as IPIP. I see that we could re-use TF-ESP's number here if we got push-back. a) It would make no sense to put a TF-ESP inside an ESP in "transport" mod= e. b) nobody uses TF-ESP, we should just deprecate it :-) But, before we do this, we should just ask for a number. I don't see a reason to support transport inside of this formulation, I'd have to go back the document to see why it might be difficult to do, but if it's not hard to do, then don't forbid it. (We also shouldn't forbid transporting Elephants in small clown cars, but I don't recommend that either) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3hbukACgkQgItw+93Q 3WXrBAgAvVVRAZ6tkh8JNKQlDNcJYOe/yNbDVs2+q1bCX4KOmrdsNZQ1RV+7n+q7 U31bQnCp64wqJvFUw341af9L+r6xGAMsh2Tf4+sWu8c7nocuvNgpLcLc+jq8MHv8 PS/i1XsPbFwTlF5SG6Tv5dEJeDgDaKJprW8fKLcGuLreEZDBA3p2FBO/A+VhJgg8 dkLnFm+jzJ5Mrm5gjMui3ttx28UrrgmXYKobjzxy8L0SiMMKkMqWMw6k6sXF8JWI JQGdTTDkD3kG3QvrVpC9ajsgOv/IYuBr07CdW3IEsJFzidKaV98KW1qO463zl/+o KeEx4l6j7a4TmM/QE/J1RlalnIhMIw== =ZHJM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 29 11:23:16 2019 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 C0F5B120154 for ; Fri, 29 Nov 2019 11:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwya3sWkX6bK for ; Fri, 29 Nov 2019 11:23:12 -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 07FC812013A for ; Fri, 29 Nov 2019 11:23:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 66E133897B; Fri, 29 Nov 2019 14:19:41 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4902066D; Fri, 29 Nov 2019 14:23:11 -0500 (EST) From: Michael Richardson To: Christian Hopps cc: Valery Smyslov , IPsecME WG In-Reply-To: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 19:23:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: > Additionally, I'm not sure that we should be so quick to say that the > IP-TFS payload would never be used outside of ESP; as was pointed out > by Michael using this payload does solve the PMTU issue with (IPsec) > tunnels, it could be re-used for this purpose outside of ESP as well. I think that I was mis-interpreted. I wasn't saying that this protocol would get used outside of ESP. I'm saying that this protocol (with ESP) will solve the PMTU problem, and so make IPsec more popular. Maybe that also means that being able to use it with transport mode could be interesting, but I think that BEET mode is more likely. I think that having a proper IP protocol number will simplify kernel implem= entations. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3hcB8ACgkQgItw+93Q 3WU6sQf+NdVHso9KAa0NW8At6U35CZpGdWSrI7hLpQ1jXwy6gsAbzYCOw0DAzKwl jAwNZ87fopulg5yjaF1ObSrymyQORfq9egtWLLLQUpPn8MfgRYoj2/ZcnhpVeobr QEqlDZ2Pz1hceagpPKHA4vNCQxj7gD4mjCPy8hV/2KP9fuMngHLGkwdUUb5EYAHO C1T+OA8SAeK66PgSuvr7SXmGZep7NeQA/eCWUeC/HZBVd5vsOYrkm5V11AxH1Oog B447kxgP3WF5LG5lh/hd5IzmxjzLbyn0cyuq6vNVV7qAvE2gc0k4nR5WSMKljuxx e2Lhoy0feOdKJG5kabwcleduQ0JAFA== =nvJf -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 29 11:30:26 2019 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 E12D71201AA for ; Fri, 29 Nov 2019 11:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq6wriKm6LBK for ; Fri, 29 Nov 2019 11:30:23 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A6EB4120154 for ; Fri, 29 Nov 2019 11:30:04 -0800 (PST) Received: from stubbs.int.chopps.org (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1CFD760178; Fri, 29 Nov 2019 19:30:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Christian Hopps In-Reply-To: <3047.1575055391@localhost> Date: Fri, 29 Nov 2019 14:30:01 -0500 Cc: Christian Hopps , IPsecME WG , Valery Smyslov Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <3047.1575055391@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 19:30:25 -0000 > On Nov 29, 2019, at 2:23 PM, Michael Richardson = wrote: >=20 >=20 > Christian Hopps wrote: >> Additionally, I'm not sure that we should be so quick to say that the >> IP-TFS payload would never be used outside of ESP; as was pointed out >> by Michael using this payload does solve the PMTU issue with (IPsec) >> tunnels, it could be re-used for this purpose outside of ESP as well. >=20 > I think that I was mis-interpreted. > I wasn't saying that this protocol would get used outside of ESP. > I'm saying that this protocol (with ESP) will solve the PMTU problem, = and so > make IPsec more popular. Right, sorry, I put your meaning in parens "(Ipsec)", and I probably = shouldn't have been trying to also point out, in the same overloaded = sentence, that this same logic would apply to any IP-in-IP tunnel = context as well. :) Thanks, Chris. > Maybe that also means that being able to use it with transport mode = could be > interesting, but I think that BEET mode is more likely. >=20 > I think that having a proper IP protocol number will simplify kernel = implementations. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Nov 29 22:35:38 2019 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 89C8B12010F for ; Fri, 29 Nov 2019 22:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUAEyBHluWHr for ; Fri, 29 Nov 2019 22:35:36 -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 E3FAF12001E for ; Fri, 29 Nov 2019 22:35:35 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47Q1pY2gvBz4x6; Sat, 30 Nov 2019 07:35:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1575095733; bh=YYf/BqT378REbJstuN8NjWNZiYr2A4Joh3Tfqa1qi/Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YV5n+8bgfxRqEfbBDCZgqDEPoqbW1UDOyE4kX9QbysW7Ea7b23skU9S+3DgC24gpQ kO1SGdR8VnkSG32UwR575trSR+KC/1tV51tQEK1IZgPmCGqh0oC09YIB3pipmo4Grz iqtxe5tFuZKECcXo7x8Qs83gUXPIphWByGIRfcfA= 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 O5hxHqthqxnF; Sat, 30 Nov 2019 07:35:31 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 30 Nov 2019 07:35:31 +0100 (CET) Received: from [10.198.170.117] (unknown [45.126.96.211]) (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 956416001610; Sat, 30 Nov 2019 01:35:30 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: <043801d5a6bd$80cd8500$82688f00$@gmail.com> Date: Sat, 30 Nov 2019 13:35:22 +0700 Cc: Christian Hopps , IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <041b01d5a6ad$e9621550$bc263ff0$@gmail.com> <3B82404F-3121-444F-97A0-6E18258DAC04@chopps.org> <043801d5a6bd$80cd8500$82688f00$@gmail.com> To: Valery Smyslov Archived-At: Subject: Re: [IPsec] IKEv2 IPTFS transform [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2019 06:35:37 -0000 On Nov 29, 2019, at 21:01, Valery Smyslov wrote: > A lot of things in IKEv2 is negotiated by using notifications. With regard= to child SA they are -=20 > using transport mode, using IPcomp, using WESP, using ROHC.=20 > IP-TFC looks to me like a natural continuation of this line. I agree. This is easier to implement than using traffic selectors and seems m= ore appropriate as it is an =E2=80=9Coptional=E2=80=9D thing to enable - sim= ilar to transport mode and compression. Paul From nobody Sat Nov 30 23:41:48 2019 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 C1D6212006D for ; Sat, 30 Nov 2019 23:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B21wYm5Kv6Rv for ; Sat, 30 Nov 2019 23:41:45 -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 E9BBA120048 for ; Sat, 30 Nov 2019 23:41:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47QgDN2WX3zFPM; Sun, 1 Dec 2019 08:41:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1575186100; bh=n94IaFK16sAyHJkjS2f81fOLi4E3lbgNz54gQCkcP/Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PueycOyibcV0kdChC/REAtMgxabNGHmkhBfGDRqzQ7rugCNHF63pIFzxhDV4rFABA jXS4Lc5rJUTEI0S5C2OIWugF6ol5+PvEDz9cc0prD2AmzACcKg+PqmhlHz8uHS5uyN +BhKzkxDRL6QjjClJ/0giqyX3dI+fd82TDzcpynU= 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 4rGNUiJbpqHR; Sun, 1 Dec 2019 08:41:39 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 1 Dec 2019 08:41:39 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 23577600119F; Sun, 1 Dec 2019 02:41:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1F6E066AA9; Sun, 1 Dec 2019 02:41:38 -0500 (EST) Date: Sun, 1 Dec 2019 02:41:38 -0500 (EST) From: Paul Wouters To: Christian Hopps cc: Valery Smyslov , IPsecME WG In-Reply-To: <5CAB559D-595E-4503-AC72-31E88B6F53AA@chopps.org> Message-ID: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> <044701d5a6d0$032d5a90$09880fb0$@gmail.com> <5CAB559D-595E-4503-AC72-31E88B6F53AA@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 07:41:47 -0000 On Fri, 29 Nov 2019, Christian Hopps wrote: >> ESP SAs are always created in pairs. And whether IP-TFS is enabled or not is common for both SAs. >> Even if you use only one SA for IP-TFS traffic, the other will have IP-TFS enabled too. >> How are you going with your spec to create a pair of SAs where IP-TFS is enabled in one direction and >> disabled in the other? Am I missing something? Even if you are able to create such a pair of SAs, is it justified? > > Understood that SAs are created in pairs. The intent here (and throughout the draft) is not to unnecessarily restrict possible uses. Having IP-TFS enabled on only one of a pair of SAs can make sense when you're only trying to protect traffic sent in one direction from traffic analysis (again e.g., telemetry). The use of IP-TFS does involve the allocation of a fixed amount of bandwidth so the justification for not enabling it in one direction is to save that bandwidth. It seems unwise to protect traffic one way but not the other way. Are endusers really able to make the right decision based on their generated traffic? If you are that hungry for resources, perhaps this isn't an option for you to use? Also, if an inbound or outbound SA is not using IP-TFS, couldn't the memory be deallocated, or the memory allocation could be postponed until the first IP-TFS type packet arrives? The architecture is really symmetrical for in/out bound SA's, so I would prefer we do not change that. > The spec is (trying to be) very careful in not restricting the unidirectional TFS use case b/c there's no reason to do so, and so there should not be anything in the document that restricts having only one of the SA pairs used by IPsec/ESP running with IP-TFS. The question is, does it need to be negotiated or not or can a well implemented implementation postpone all memory requirements if this feature is unused in one direction? > Setting up such an SA pair is orthogonal to being able to run with that configuration. While the vast majority of IPsec utilizes IKEv2 for SA creation/management, this is not a requirement of IPsec/ESP. The unidirectional case can be covered with local configuration (along with IKEv2), or by using another method entirely for the SA management. Non-IKE can negotiate whatever it want and hack in custom IPsec SA's that we would find completely illegal. That's out of scope of this WG, but we should also not bring it into scope as "others might want that". > The intent in the end is to specify what we need to for IP-TFS operation, but not too over-specify and unnecessarily restrict possible future (or outside) uses. IOW, less is more. But I am still not convinced endusers can make these decisions of bidirectional vs unidirectional and whther or not their traffic becomes more susceptible to traffic analyses attacks. > FWIW, I did explore adding machinery to IKEv2 to allow setting up/negotiating unidirectional use cases, but it adds a lot of complexity, and so we decided that while unidirectional TFS protection is useful it will still be a relatively uncommon configuration and was best left for local configuration for now. If in the future we see a large call for on-demand/negotiated (vs local config) uni-directional TFS we can always come back and add it to IKEv2. What's important in the context of the IKEv2 changes for now is that we don't do anything to block doing this in the future. I have not yet been convinced of this. Paul From nobody Sat Nov 30 23:52:56 2019 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 0DD17120048 for ; Sat, 30 Nov 2019 23:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmsVLd6sYDu0 for ; Sat, 30 Nov 2019 23:52: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 99150120044 for ; Sat, 30 Nov 2019 23:52:53 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47QgTH6kTxzFPM; Sun, 1 Dec 2019 08:52:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1575186771; bh=KCFKodR5vwIFQgy9b4OgUeWqM2XZzM+b+7PHdvWlsIY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b9ZM3NeaQmIBnk0hcTiGDLiKiDy9vioW4Npqp4SGOvJARRBYyx7kT62ftWo6Y/wvH LFWfIJBUO65qRKclxPfQlJFR+/eD5leSaPbxNQRyaZ+rAQ0XvfkLiaLIupUwe3wqI2 PUv9smd1D2s38x4cc2VydY2X4tqsrqY3Hc7NrbM4= 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 aP3r8y0VMqZt; Sun, 1 Dec 2019 08:52:50 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 1 Dec 2019 08:52:50 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AE0AB600119F; Sun, 1 Dec 2019 02:52:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA3D866AA9; Sun, 1 Dec 2019 02:52:49 -0500 (EST) Date: Sun, 1 Dec 2019 02:52:49 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: IPsecME WG In-Reply-To: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> Message-ID: References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 07:52:55 -0000 On Thu, 28 Nov 2019, Valery Smyslov wrote: > after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts. > > 1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS for transport mode ESP > is equally important because one of the widely used scenario is to combine general purpose > tunneling (like GRE) with transport mode ESP. In this case traffic flowing over such SA > will in fact be tunnel traffic from several hosts, but the SA is created in transport mode. > For this reason I think that IP-TFS must support transport mode SA either. I sadly agree. I was quite shocked to recently learn that Cisco prefers GRE over Transport Mode for _all_ of their subnet to subnet configurations and they consider their policy based VPN configs using cryptomap "obsolete". > 3. I think that using new Transform Type for IP-TFS negotiation is a bad idea. I also prefer to see a USE_IPTFS notify similar to USE_TRANSPORT and USE_COMPRESS. > 7. I don't think that late-enabling of IP-TFS described in section 2.4 > is really needed. It adds unnecessary complexity and somewhat contradicts > to what is stated in section 2.3. I agree. It would also have to specify a PF_KEY/NETLINK type message because the userland IKE daemon must know this has happened, to be able to reject/accept or at least log this event. If the only goal is debugging, then we should just not allow this. The same could be achieved by rekeying the child sa with the USE_IPTFS notify (which would be another reason not to use a transform, because those must not change during rekey) Paul