From nobody Mon Oct 2 05:25:51 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234B1345E9 for ; Mon, 2 Oct 2017 05:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8781leHt_jZP for ; Mon, 2 Oct 2017 05:25:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 A136B13219E for ; Mon, 2 Oct 2017 05:25:48 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v92CPiMa014905 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Oct 2017 15:25:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v92CPhQA008393; Mon, 2 Oct 2017 15:25:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22994.12359.883934.697141@fireball.acr.fi> Date: Mon, 2 Oct 2017 15:25:43 +0300 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: <734.1506105616@obiwan.sandelman.ca> <22988.20795.994513.729963@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Subject: Re: [IPsec] IANA IKEv2 parameters, encryption type=17 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 12:25:50 -0000 Paul Wouters writes: > > for 8, 12, 16 octet versions came to be 18, 19, and 20, and the number > > 17 which was most likely allocated for the 4 octet ICV was marked as > > reserved. > > Except it is marked unassigned, not reserved. So one could use this > number in the future. I for sure have never seen it in the wild on > the wire or in source code. And if it is too weak, I guess we don't > mind breaking implementations who mistakenly still support it :) It is marked as unassigned, as it was never officially assigned to that purpose. It can be safely reused, as nobody could not have implementation supporting that number, as there never was a draft listing that number for that use. I.e., the allocation was done inside the iana, and removed inside the iana, so nobody outside iana and authors of the draft will not even know about that. And as I am not part of iana, and not an author of that draft, that reasoning was my guessing what happened, I am not sure wheter that is what really happened, but evidence points to that way... -- kivinen@iki.fi From nobody Mon Oct 2 18:58:00 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A82134234; Mon, 2 Oct 2017 18:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 MbKjxguHUBjW; Mon, 2 Oct 2017 18:57:56 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0559E134220; Mon, 2 Oct 2017 18:57:56 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id o52so10439764qtc.9; Mon, 02 Oct 2017 18:57:55 -0700 (PDT) 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=OLMwhpoM0BDL0RIVIUgFJ9YEjoSExHC+fSeABrCXts4=; b=A4VOBmotYm7+/BLYoAaflfW49i1EkxSS79T+3s81sqH1gf3L8ev/xXHu6ZCUvGza5A ASggYEpgK8zlp7pan4SJd6tLfn7UwYRPzG2ghkAQhmffGgPPFna8xsP37FM6Oc3SqHfz lv9F+l9Ce9543pBFWMj7zqX/QMKvgC5nJXrGhgRxVlez44oUb+UlxJDUlsVdo0vs+Mk9 VvG+gohwmzwjp+tYrQ4hiWlMjdLAids4aiQA73zYckEsQVXp0wOcvVyIpC5Ze/t/n7jS dvRhoemb5uJHDtTglvpbOY+oOc5uAw7KMx0sZjr9Fc91MYWnZXKyyVyN+c0a75DzTHYM /7lw== 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=OLMwhpoM0BDL0RIVIUgFJ9YEjoSExHC+fSeABrCXts4=; b=SiMQ3ZwfZEkhH58IdagstyaPLfnPNqqYCVMuXO/OrXtezlnhmg7sZyXnXXYPxR/TXb 67s08Qvt/se5PCGBBD2WD9g01QNEWWmIPWmUIksGk5LPYIPIayqgp6SxLt3chACrlbIG Mqjh4aceVx0RwxLyv0BKj05azKHmFs750kLzsiC6DiyQ5smY4i//DYNdDaofbnvI8fVO e3vlW+EmQPiz9Ep2alpP3sLT+6KUAfcLGMRxWUYV04mnThZYSoWszeMP8vOFOmWrLKAz KO9urfpRuv4zMiy7W5dwuTG2D/rrnkMm26E44onmfAJwQceRA9/b8+TYcDGdlrPcWzzp +SHA== X-Gm-Message-State: AMCzsaUV3gBHRUXHD4mZ6BPop+twgqGoCKHzjHFdRYfmJsmjOFmXIGzD AW1D0fOLTZexr8eOhrigslk= X-Google-Smtp-Source: AOwi7QAqYrRrhIjSC7uxF/J+LkKgEZCPDpxkHgU7ZbeS1HUn6uu7h2hzDVRsKR/rEjy9EUKRKM3FKA== X-Received: by 10.200.15.218 with SMTP id f26mr1647778qtk.236.1506995875153; Mon, 02 Oct 2017 18:57:55 -0700 (PDT) Received: from SantoshBrain (pool-173-73-191-59.washdc.fios.verizon.net. [173.73.191.59]) by smtp.gmail.com with ESMTPSA id t3sm7848888qtd.8.2017.10.02.18.57.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 18:57:54 -0700 (PDT) From: "Santosh Chokhani" To: "'Liaison Statement Management Tool'" , "'David Waltermire'" , "'Tero Kivinen'" , "'Russ Housley'" Cc: "'Limited Additional Mechanisms for PKIX and SMIME Discussion List'" , "'Eric Rescorla'" , "'Russ Housley'" , "'Tero Kivinen'" , "'Scott Mansfield'" , "'IP Security Maintenance and Extensions Discussion List'" , "'Kathleen Moriarty'" , "'David Waltermire'" , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> In-Reply-To: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> Date: Mon, 2 Oct 2017 21:57:56 -0400 Message-ID: <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKqSaa+8g Content-Language: en-us Archived-At: Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 01:57:58 -0000 I am not sure I understand what is being said below. The link to the PDF does not add to the message body. If there is a concern about what signature algorithm is used for what type of subject key, X.509 already has that flexibility. If there is a concern about using multiple signatures on an X.509 certificate, one can use the single signature algorithm identifier to define multiple algorithms, parameters, and signatures. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott Mansfield ; IP Security Maintenance and Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date: 2017-09-13 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1541/ From: Jean-Paul Lemaire To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security Maintenance and Extensions Discussion List ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott Mansfield ,Kathleen Moriarty ,Tero Kivinen ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts: Purpose: For information Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the inclusion of a proposal to include optional support for multiple public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. The industry is preparing ICT systems to be resistant to attacks by large-scale quantum computers in addition to more sophisticated attacks by conventional computing resources. Proposed was an optional feature to the X.509 certificate that provides a seamless migration capability to existing PKI systems, and is completely backwardly compatible with existing systems. While public-key key establishment algorithms are typically negotiated between peers and are generally fairly simple to update, the authentication systems typically rely on a single digital signature algorithm which are more difficult to update. This is because of the circular dependency between PKI-based identity systems and the dependent communication protocols. In order to update a PKI system, one would typically need to create a duplicate PKI system that utilizes a new digital signature algorithm and then migrate all the dependent systems one by one. This proposal eliminates the need to create such duplicate PKI systems by adding optional extensions to contain alternate public key and alternate signature, and a method for the CA to sign certificates using a layered approach to ensure that every attribute is authenticated by both signatures. The resulting certificate, while containing new quantum safe public key and signature, can still be used by existing systems relying on the classic public key and signature. Attachments: sp16-sg17-oLS-00068 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg-17 -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Oct 3 13:48:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A15134212; Tue, 3 Oct 2017 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8OT959wCdl8; Tue, 3 Oct 2017 13:48:35 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB203133073; Tue, 3 Oct 2017 13:48:34 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d67so6171491qkg.5; Tue, 03 Oct 2017 13:48:34 -0700 (PDT) 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=oxvyfpIYVsvKNGw3dY43IsIQw9gG1Ghxsu1Qxu6oGkc=; b=Ks0RQRz+xbWEvUYJyeiEVItYa9GWPP+HggW9+gUiKKGJ+yNRhIYYIl7CtzbiyUrilI WIrIM0pvemx7ncs4FKjDr5Cph4zei8r2oOM+eLquPEhWqldw9hcsD9Tv+IUfxbZju5Dk 4jCBXO98LqGAnM30N5YEGrr/RumC/oJW4T/J47wFd0PZvMY+kOYFgrhPGBOEPiekhp77 +iVoStLBQp71kjCk9Kz4NbGHsEmmeBk7tmu/CCcBkYDKW8gQJfGdVbkctRmFeJ2d4uwz ssvykPCyOyqGOiU3wekjBWZ1Ncj8P8HXBWcOmbZLeSWl92k4VNlos3QUoQUhYrJERz6E dCNQ== 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=oxvyfpIYVsvKNGw3dY43IsIQw9gG1Ghxsu1Qxu6oGkc=; b=r36YJlukQyuAQExLoXD8zMwN/FPt8Mahm7+RdXYjgCrc74rqu5uJaGQyJMdru7n4e6 g01PvQKw3zADW+RJGc8zVxexbv59sePuWtHK6dOoS4G1KWYdzAL4KKNfO3SxEaYn15ZD xD3h5FnCGvkj2btl72WCOdNyLGRyOBCIGEb5s6F5PRQ7WwPBY+Q1iN/6ZGveFU12jRJS BuInWx8CusFo8NyJglAQlP7LlgZ4vpOKGHrZy+eAskaL7ww6Qd7UjQK8OZxBCY4Tk2DB bbz1K1kO1jB3jXt4d1svYM5P9ovfrXmzWclj01PDOfDNuvGj2mf2dqrEx45GCWdPUSgY FJMw== X-Gm-Message-State: AMCzsaWuoT8eDBp4yTVV8SFxx7ZNbSyyAZcN+qhUpAzn23shKFWU3R05 8qTybjV/wURZHFY857rfvIw= X-Google-Smtp-Source: AOwi7QDllFl4Jn4EVEIZ0cQr+OGLfpiMT3oaGgWJToLVJErI/lKuTVy4EpZLtAmcAq+OWz1eVGPGMg== X-Received: by 10.55.21.30 with SMTP id f30mr23097809qkh.335.1507063713412; Tue, 03 Oct 2017 13:48:33 -0700 (PDT) Received: from SantoshBrain (pool-173-73-191-59.washdc.fios.verizon.net. [173.73.191.59]) by smtp.gmail.com with ESMTPSA id 49sm9414815qtq.1.2017.10.03.13.48.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 13:48:32 -0700 (PDT) From: "Santosh Chokhani" To: "'Alexander Truskovsky'" , , , Cc: , , , , , , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> Date: Tue, 3 Oct 2017 16:48:33 -0400 Message-ID: <079001d33c88$fab856c0$f0290440$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKgI84QjmAbyZK6EBM7nHTKRyPsZA Content-Language: en-us Archived-At: Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 20:48:37 -0000 Multiple public keys as well as signatures can be accommodated using the = respective algorithm OIDs in Signature and SPKI fields. Have you considered that in place of using an extension. -----Original Message----- From: Alexander Truskovsky [mailto:Alexander.Truskovsky@isara.com]=20 Sent: Tuesday, October 3, 2017 4:38 PM To: santosh.chokhani@gmail.com; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: spasm@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; ipsec@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" This allows X.509 certificates to contain two (or more) public keys and = issuer signatures. The goal would be to ease the migration of PKI and = dependent protocols to new digital signature algorithms. The motivation = was to make the X.509 more cryptographically agile and simplify the = migration to quantum-safe algorithms, but it is algorithm agnostic. The = main benefit of this proposal is that current systems will be able to = use these newer X.509 certificates as they do today without any = modifications, while systems that were updated to support quantum-safe = algorithms can also be updated to understand the newer X.509 format and = use quantum-safe algorithm instead. We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few partners and will publish it for review soon. Alex =20 =20 On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" = wrote: =20 I am not sure I understand what is being said below. The link = to the PDF does not add to the message body. =20 If there is a concern about what signature algorithm is used for = what type of subject key, X.509 already has that flexibility. =20 If there is a concern about using multiple signatures on an = X.509 certificate, one can use the single signature algorithm = identifier to define multiple algorithms, parameters, and signatures. =20 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison = Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion = List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott = Mansfield ; IP Security Maintenance and = Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" =20 Title: LS on ITU-T SG17 work on quantum-safe PKI Submission = Date: 2017-09-13 URL of the IETF Web page: = https://datatracker.ietf.org/liaison/1541/ =20 From: Jean-Paul Lemaire = To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security = Maintenance and Extensions Discussion List = ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott = Mansfield ,Kathleen Moriarty ,Tero Kivinen = ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts:=20 Purpose: For information =20 Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the = inclusion of a proposal to include optional support for multiple public-key = algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. =20 The industry is preparing ICT systems to be resistant to attacks = by large-scale quantum computers in addition to more sophisticated = attacks by conventional computing resources. Proposed was an optional = feature to the X.509 certificate that provides a seamless migration capability = to existing PKI systems, and is completely backwardly compatible with = existing systems. =20 While public-key key establishment algorithms are typically = negotiated between peers and are generally fairly simple to update, the = authentication systems typically rely on a single digital signature algorithm = which are more difficult to update. This is because of the circular = dependency between PKI-based identity systems and the dependent communication = protocols. In order to update a PKI system, one would typically need to create = a duplicate PKI system that utilizes a new digital signature algorithm and = then migrate all the dependent systems one by one. =20 This proposal eliminates the need to create such duplicate PKI = systems by adding optional extensions to contain alternate public key and = alternate signature, and a method for the CA to sign certificates using a = layered approach to ensure that every attribute is authenticated by both = signatures. The resulting certificate, while containing new quantum safe = public key and signature, can still be used by existing systems relying on the = classic public key and signature. Attachments: =20 sp16-sg17-oLS-00068 =20 = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg= -17 = -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 =20 From nobody Tue Oct 3 14:35:16 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523C013219B; Tue, 3 Oct 2017 14:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8wl1ew-kmftw; Tue, 3 Oct 2017 14:35:12 -0700 (PDT) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) by ietfa.amsl.com (Postfix) with ESMTP id DA7FA1331DC; Tue, 3 Oct 2017 14:35:11 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip1.isaracorp.com with ESMTP; 03 Oct 2017 21:40:49 +0000 Received: from mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) by mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 3 Oct 2017 17:35:04 -0400 Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Tue, 3 Oct 2017 17:35:04 -0400 From: Alexander Truskovsky To: Santosh Chokhani , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" CC: "spasm@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "ipsec@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" Thread-Topic: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" Thread-Index: AQHTO+sV5+bpPT0iyE2onk66kRVilaLSoMOAgAA5gICAAALogIAADP8A Date: Tue, 3 Oct 2017 21:35:04 +0000 Message-ID: <070920B4-ED3D-44F1-BC72-60FDB74D78EA@isara.com> References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> <079001d33c88$fab856c0$f0290440$@gmail.com> In-Reply-To: <079001d33c88$fab856c0$f0290440$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.25.5.208] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 21:35:15 -0000 VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnQuDQoNCldlIHdhbnQgdG8gZW5zdXJlIHRoZSBleGlz dGluZyBzeXN0ZW1zIGNhbiB1c2UgdGhlc2UgbmV3ZXIgY2VydGlmaWNhdGVzIGFzIGlmIG5vdGhp bmcgY2hhbmdlZC4gIFRoYXTigJlzIHRoZSBrZXkgcmVxdWlyZW1lbnQuICBJZiB0aGUgU2lnbmF0 dXJlIGZpZWxkIGlzIG1vZGlmaWVkLCB0aGUgc3lzdGVtcyB0aGF0IGhhdmUgbm90IGJlZW4gdXBk YXRlZCB3aWxsIG5vdCBiZSBhYmxlIHRvIHVzZSBjbGFzc2ljIGFsZ29yaXRobXMgYXMgdGhleSBk byB0b2RheS4gIFBsYWNpbmcgc2lnbmF0dXJlcyBpbiB0aGUgbm9uLWNyaXRpY2FsIGV4dGVuc2lv bnMgbGVhdmVzIHRoZSBTaWduYXR1cmUgZmllbGQgdW50b3VjaGVkLg0KDQpBbGV4DQoNCk9uIDIw MTctMTAtMDMsIDQ6NDggUE0sICJTYW50b3NoIENob2toYW5pIiA8c2FudG9zaC5jaG9raGFuaUBn bWFpbC5jb20+IHdyb3RlOg0KDQogICAgTXVsdGlwbGUgcHVibGljIGtleXMgYXMgd2VsbCBhcyBz aWduYXR1cmVzIGNhbiBiZSBhY2NvbW1vZGF0ZWQgdXNpbmcgdGhlIHJlc3BlY3RpdmUgYWxnb3Jp dGhtIE9JRHMgaW4gU2lnbmF0dXJlIGFuZCBTUEtJIGZpZWxkcy4NCiAgICANCiAgICBIYXZlIHlv dSBjb25zaWRlcmVkIHRoYXQgaW4gcGxhY2Ugb2YgdXNpbmcgYW4gZXh0ZW5zaW9uLg0KICAgIA0K ICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogQWxleGFuZGVyIFRydXNr b3Zza3kgW21haWx0bzpBbGV4YW5kZXIuVHJ1c2tvdnNreUBpc2FyYS5jb21dIA0KICAgIFNlbnQ6 IFR1ZXNkYXksIE9jdG9iZXIgMywgMjAxNyA0OjM4IFBNDQogICAgVG86IHNhbnRvc2guY2hva2hh bmlAZ21haWwuY29tOyBkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292OyBraXZpbmVuQGlraS5maTsg aG91c2xleUB2aWdpbHNlYy5jb20NCiAgICBDYzogc3Bhc21AaWV0Zi5vcmc7IGVrckBydGZtLmNv bTsgaG91c2xleUB2aWdpbHNlYy5jb207IFNjb3R0Lk1hbnNmaWVsZEBFcmljc3Nvbi5jb207IGlw c2VjQGlldGYub3JnOyBLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTsgaXR1LXQtbGlh aXNvbkBpYWIub3JnOyBqZWFuLXBhdWwubGVtYWlyZUB1bml2LXBhcmlzLWRpZGVyb3QuZnINCiAg ICBTdWJqZWN0OiBSZTogW0lQc2VjXSBbbGFtcHNdIE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkxT IG9uIElUVS1UIFNHMTcgd29yayBvbiBxdWFudHVtLXNhZmUgUEtJIg0KICAgIA0KICAgIFRoaXMg YWxsb3dzIFguNTA5IGNlcnRpZmljYXRlcyB0byBjb250YWluIHR3byAob3IgbW9yZSkgcHVibGlj IGtleXMgYW5kIGlzc3VlciBzaWduYXR1cmVzLiAgVGhlIGdvYWwgd291bGQgYmUgdG8gZWFzZSB0 aGUgbWlncmF0aW9uIG9mIFBLSSBhbmQgZGVwZW5kZW50IHByb3RvY29scyB0byBuZXcgZGlnaXRh bCBzaWduYXR1cmUgYWxnb3JpdGhtcy4gIFRoZSBtb3RpdmF0aW9uIHdhcyB0byBtYWtlIHRoZSBY LjUwOSBtb3JlIGNyeXB0b2dyYXBoaWNhbGx5IGFnaWxlIGFuZCBzaW1wbGlmeSB0aGUgbWlncmF0 aW9uIHRvIHF1YW50dW0tc2FmZSBhbGdvcml0aG1zLCBidXQgaXQgaXMgYWxnb3JpdGhtIGFnbm9z dGljLiAgVGhlIG1haW4gYmVuZWZpdCBvZiB0aGlzIHByb3Bvc2FsIGlzIHRoYXQgY3VycmVudCBz eXN0ZW1zIHdpbGwgYmUgYWJsZSB0byB1c2UgdGhlc2UgbmV3ZXIgWC41MDkgY2VydGlmaWNhdGVz IGFzIHRoZXkgZG8gdG9kYXkgd2l0aG91dCBhbnkgbW9kaWZpY2F0aW9ucywgd2hpbGUgc3lzdGVt cyB0aGF0IHdlcmUgdXBkYXRlZCB0byBzdXBwb3J0IHF1YW50dW0tc2FmZSBhbGdvcml0aG1zIGNh biBhbHNvIGJlIHVwZGF0ZWQgdG8gdW5kZXJzdGFuZCB0aGUgbmV3ZXIgWC41MDkgZm9ybWF0IGFu ZCB1c2UgcXVhbnR1bS1zYWZlIGFsZ29yaXRobSBpbnN0ZWFkLg0KICAgIA0KICAgIFdlIGFyZSB3 b3JraW5nIG9uIGEgZHJhZnQgdGhhdCBtaXJyb3JzIHRoZSBJVFUtVOKAmXMgd29yayB3aXRoIGEg ZmV3IHBhcnRuZXJzIGFuZCB3aWxsIHB1Ymxpc2ggaXQgZm9yIHJldmlldyBzb29uLg0KICAgIA0K ICAgIEFsZXgNCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICBPbiAyMDE3LTEwLTAyLCA5OjU4 IFBNLCAiSVBzZWMgb24gYmVoYWxmIG9mIFNhbnRvc2ggQ2hva2hhbmkiIDxpcHNlYy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBzYW50b3NoLmNob2toYW5pQGdtYWlsLmNvbT4gd3JvdGU6 DQogICAgICAgIA0KICAgICAgICAgICAgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCBp cyBiZWluZyBzYWlkIGJlbG93LiAgVGhlIGxpbmsgdG8gdGhlIFBERg0KICAgICAgICAgICAgZG9l cyBub3QgYWRkIHRvIHRoZSBtZXNzYWdlIGJvZHkuDQogICAgICAgICAgICANCiAgICAgICAgICAg IElmIHRoZXJlIGlzIGEgY29uY2VybiBhYm91dCB3aGF0IHNpZ25hdHVyZSBhbGdvcml0aG0gaXMg dXNlZCBmb3Igd2hhdCB0eXBlDQogICAgICAgICAgICBvZiBzdWJqZWN0IGtleSwgWC41MDkgYWxy ZWFkeSBoYXMgdGhhdCBmbGV4aWJpbGl0eS4NCiAgICAgICAgICAgIA0KICAgICAgICAgICAgSWYg dGhlcmUgaXMgYSBjb25jZXJuIGFib3V0IHVzaW5nIG11bHRpcGxlIHNpZ25hdHVyZXMgb24gYW4g WC41MDkNCiAgICAgICAgICAgIGNlcnRpZmljYXRlLCBvbmUgY2FuIHVzZSB0aGUgc2luZ2xlIHNp Z25hdHVyZSBhbGdvcml0aG0gaWRlbnRpZmllciB0byBkZWZpbmUNCiAgICAgICAgICAgIG11bHRp cGxlIGFsZ29yaXRobXMsIHBhcmFtZXRlcnMsIGFuZCBzaWduYXR1cmVzLg0KICAgICAgICAgICAg DQogICAgICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAgICAgICAgRnJv bTogU3Bhc20gW21haWx0bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGlh aXNvbiBTdGF0ZW1lbnQNCiAgICAgICAgICAgIE1hbmFnZW1lbnQgVG9vbA0KICAgICAgICAgICAg U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTcgMTE6MjUgQU0NCiAgICAgICAgICAg IFRvOiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PjsgVGVybyBL aXZpbmVuDQogICAgICAgICAgICA8a2l2aW5lbkBpa2kuZmk+OyBSdXNzIEhvdXNsZXkgPGhvdXNs ZXlAdmlnaWxzZWMuY29tPg0KICAgICAgICAgICAgQ2M6IExpbWl0ZWQgQWRkaXRpb25hbCBNZWNo YW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSBEaXNjdXNzaW9uIExpc3QNCiAgICAgICAgICAgIDxz cGFzbUBpZXRmLm9yZz47IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT47IFJ1c3MgSG91c2xl eQ0KICAgICAgICAgICAgPGhvdXNsZXlAdmlnaWxzZWMuY29tPjsgVGVybyBLaXZpbmVuIDxraXZp bmVuQGlraS5maT47IFNjb3R0IE1hbnNmaWVsZA0KICAgICAgICAgICAgPFNjb3R0Lk1hbnNmaWVs ZEBFcmljc3Nvbi5jb20+OyBJUCBTZWN1cml0eSBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucw0K ICAgICAgICAgICAgRGlzY3Vzc2lvbiBMaXN0IDxpcHNlY0BpZXRmLm9yZz47IEthdGhsZWVuIE1v cmlhcnR5DQogICAgICAgICAgICA8S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+OyBE YXZpZCBXYWx0ZXJtaXJlDQogICAgICAgICAgICA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj47 IGl0dS10LWxpYWlzb25AaWFiLm9yZzsNCiAgICAgICAgICAgIGplYW4tcGF1bC5sZW1haXJlQHVu aXYtcGFyaXMtZGlkZXJvdC5mcg0KICAgICAgICAgICAgU3ViamVjdDogW2xhbXBzXSBOZXcgTGlh aXNvbiBTdGF0ZW1lbnQsICJMUyBvbiBJVFUtVCBTRzE3IHdvcmsgb24NCiAgICAgICAgICAgIHF1 YW50dW0tc2FmZSBQS0kiDQogICAgICAgICAgICANCiAgICAgICAgICAgIFRpdGxlOiBMUyBvbiBJ VFUtVCBTRzE3IHdvcmsgb24gcXVhbnR1bS1zYWZlIFBLSSBTdWJtaXNzaW9uIERhdGU6IDIwMTct MDktMTMNCiAgICAgICAgICAgIFVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTogaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE1NDEvDQogICAgICAgICAgICANCiAgICAgICAgICAg IEZyb206IEplYW4tUGF1bCBMZW1haXJlIDxqZWFuLXBhdWwubGVtYWlyZUB1bml2LXBhcmlzLWRp ZGVyb3QuZnI+DQogICAgICAgICAgICBUbzogRGF2aWQgV2FsdGVybWlyZSA8ZGF2aWQud2FsdGVy bWlyZUBuaXN0Lmdvdj4sVGVybyBLaXZpbmVuDQogICAgICAgICAgICA8a2l2aW5lbkBpa2kuZmk+ LFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQogICAgICAgICAgICBDYzogRGF2 aWQgV2FsdGVybWlyZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4sSVAgU2VjdXJpdHkgTWFp bnRlbmFuY2UgYW5kDQogICAgICAgICAgICBFeHRlbnNpb25zIERpc2N1c3Npb24gTGlzdCA8aXBz ZWNAaWV0Zi5vcmc+LGl0dS10LWxpYWlzb25AaWFiLm9yZyxMaW1pdGVkDQogICAgICAgICAgICBB ZGRpdGlvbmFsIE1lY2hhbmlzbXMgZm9yIFBLSVggYW5kIFNNSU1FIERpc2N1c3Npb24gTGlzdA0K ICAgICAgICAgICAgPHNwYXNtQGlldGYub3JnPixSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxz ZWMuY29tPixTY290dCBNYW5zZmllbGQNCiAgICAgICAgICAgIDxTY290dC5NYW5zZmllbGRARXJp Y3Nzb24uY29tPixLYXRobGVlbiBNb3JpYXJ0eQ0KICAgICAgICAgICAgPEthdGhsZWVuLk1vcmlh cnR5LmlldGZAZ21haWwuY29tPixUZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPixFcmljDQog ICAgICAgICAgICBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPiBSZXNwb25zZSBDb250YWN0czoNCiAg ICAgICAgICAgIGplYW4tcGF1bC5sZW1haXJlQHVuaXYtcGFyaXMtZGlkZXJvdC5mcg0KICAgICAg ICAgICAgVGVjaG5pY2FsIENvbnRhY3RzOiANCiAgICAgICAgICAgIFB1cnBvc2U6IEZvciBpbmZv cm1hdGlvbg0KICAgICAgICAgICAgDQogICAgICAgICAgICBCb2R5OiBJVFUtVCBTdHVkeSBHcm91 cCAxNyBpcyBwbGVhc2VkIHRvIGluZm9ybSB5b3UgdGhhdCBpbiBvdXINCiAgICAgICAgICAgIEF1 Z3VzdC9TZXB0ZW1iZXIgMjAxNyBtZWV0aW5nIHdlIGFncmVlZCB0byBzdGFydCB3b3JrIG9uIHRo ZSBpbmNsdXNpb24gb2YgYQ0KICAgICAgICAgICAgcHJvcG9zYWwgdG8gaW5jbHVkZSBvcHRpb25h bCBzdXBwb3J0IGZvciBtdWx0aXBsZSBwdWJsaWMta2V5IGFsZ29yaXRobXMgaW4NCiAgICAgICAg ICAgIFJlY29tbWVuZGF0aW9uIElUVS1UIFg1MDkgfCBJU08vSUVDIDk1OTQtOC4NCiAgICAgICAg ICAgIA0KICAgICAgICAgICAgVGhlIGluZHVzdHJ5IGlzIHByZXBhcmluZyBJQ1Qgc3lzdGVtcyB0 byBiZSByZXNpc3RhbnQgdG8gYXR0YWNrcyBieQ0KICAgICAgICAgICAgbGFyZ2Utc2NhbGUgcXVh bnR1bSBjb21wdXRlcnMgaW4gYWRkaXRpb24gdG8gbW9yZSBzb3BoaXN0aWNhdGVkIGF0dGFja3Mg YnkNCiAgICAgICAgICAgIGNvbnZlbnRpb25hbCBjb21wdXRpbmcgcmVzb3VyY2VzLiBQcm9wb3Nl ZCB3YXMgYW4gb3B0aW9uYWwgZmVhdHVyZSB0byB0aGUNCiAgICAgICAgICAgIFguNTA5IGNlcnRp ZmljYXRlIHRoYXQgcHJvdmlkZXMgYSBzZWFtbGVzcyBtaWdyYXRpb24gY2FwYWJpbGl0eSB0byBl eGlzdGluZw0KICAgICAgICAgICAgUEtJIHN5c3RlbXMsIGFuZCBpcyBjb21wbGV0ZWx5IGJhY2t3 YXJkbHkgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIHN5c3RlbXMuDQogICAgICAgICAgICANCiAg ICAgICAgICAgIFdoaWxlIHB1YmxpYy1rZXkga2V5IGVzdGFibGlzaG1lbnQgYWxnb3JpdGhtcyBh cmUgdHlwaWNhbGx5IG5lZ290aWF0ZWQNCiAgICAgICAgICAgIGJldHdlZW4gcGVlcnMgYW5kIGFy ZSBnZW5lcmFsbHkgZmFpcmx5IHNpbXBsZSB0byB1cGRhdGUsIHRoZSBhdXRoZW50aWNhdGlvbg0K ICAgICAgICAgICAgc3lzdGVtcyB0eXBpY2FsbHkgcmVseSBvbiBhIHNpbmdsZSBkaWdpdGFsIHNp Z25hdHVyZSBhbGdvcml0aG0gd2hpY2ggYXJlDQogICAgICAgICAgICBtb3JlIGRpZmZpY3VsdCB0 byB1cGRhdGUuIFRoaXMgaXMgYmVjYXVzZSBvZiB0aGUgY2lyY3VsYXIgZGVwZW5kZW5jeSBiZXR3 ZWVuDQogICAgICAgICAgICBQS0ktYmFzZWQgaWRlbnRpdHkgc3lzdGVtcyBhbmQgdGhlIGRlcGVu ZGVudCBjb21tdW5pY2F0aW9uIHByb3RvY29scy4gSW4NCiAgICAgICAgICAgIG9yZGVyIHRvIHVw ZGF0ZSBhIFBLSSBzeXN0ZW0sIG9uZSB3b3VsZCB0eXBpY2FsbHkgbmVlZCB0byBjcmVhdGUgYSBk dXBsaWNhdGUNCiAgICAgICAgICAgIFBLSSBzeXN0ZW0gdGhhdCB1dGlsaXplcyBhIG5ldyBkaWdp dGFsIHNpZ25hdHVyZSBhbGdvcml0aG0gYW5kIHRoZW4gbWlncmF0ZQ0KICAgICAgICAgICAgYWxs IHRoZSBkZXBlbmRlbnQgc3lzdGVtcyBvbmUgYnkgb25lLg0KICAgICAgICAgICAgDQogICAgICAg ICAgICBUaGlzIHByb3Bvc2FsIGVsaW1pbmF0ZXMgdGhlIG5lZWQgdG8gY3JlYXRlIHN1Y2ggZHVw bGljYXRlIFBLSSBzeXN0ZW1zIGJ5DQogICAgICAgICAgICBhZGRpbmcgb3B0aW9uYWwgZXh0ZW5z aW9ucyB0byBjb250YWluIGFsdGVybmF0ZSBwdWJsaWMga2V5IGFuZCBhbHRlcm5hdGUNCiAgICAg ICAgICAgIHNpZ25hdHVyZSwgYW5kIGEgbWV0aG9kIGZvciB0aGUgQ0EgdG8gc2lnbiBjZXJ0aWZp Y2F0ZXMgdXNpbmcgYSBsYXllcmVkDQogICAgICAgICAgICBhcHByb2FjaCB0byBlbnN1cmUgdGhh dCBldmVyeSBhdHRyaWJ1dGUgaXMgYXV0aGVudGljYXRlZCBieSBib3RoIHNpZ25hdHVyZXMuDQog ICAgICAgICAgICBUaGUgcmVzdWx0aW5nIGNlcnRpZmljYXRlLCB3aGlsZSBjb250YWluaW5nIG5l dyBxdWFudHVtIHNhZmUgcHVibGljIGtleSBhbmQNCiAgICAgICAgICAgIHNpZ25hdHVyZSwgY2Fu IHN0aWxsIGJlIHVzZWQgYnkgZXhpc3Rpbmcgc3lzdGVtcyByZWx5aW5nIG9uIHRoZSBjbGFzc2lj DQogICAgICAgICAgICBwdWJsaWMga2V5IGFuZCBzaWduYXR1cmUuDQogICAgICAgICAgICBBdHRh Y2htZW50czoNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIHNwMTYtc2cxNy1vTFMtMDAw NjgNCiAgICAgICAgICAgICANCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9k dC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTctMDktMTMtaXR1LXQtc2ctMTcNCiAgICAg ICAgICAgIC1pcHNlY21lLWxhbXBzLWxzLW9uLWl0dS10LXNnMTctd29yay1vbi1xdWFudHVtLXNh ZmUtcGtpLWF0dGFjaG1lbnQtMS5wZGYNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgIFNw YXNtIG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgU3Bhc21AaWV0Zi5vcmcNCiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc20NCiAgICAgICAgICAg IA0KICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICAgICAgICAgIElQc2VjIG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgSVBzZWNA aWV0Zi5vcmcNCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBzZWMNCiAgICAgICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQog ICAgDQoNCg== From nobody Tue Oct 3 17:58:46 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA64132EC4; Tue, 3 Oct 2017 17:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 hpPG2IxATimV; Tue, 3 Oct 2017 17:58:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8B513321F; Tue, 3 Oct 2017 17:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE8C1BEC3; Wed, 4 Oct 2017 01:58:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNnCjuny-IVc; Wed, 4 Oct 2017 01:58:35 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8F70BEBB; Wed, 4 Oct 2017 01:58:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507078715; bh=VjmvQIbLooq3i7B2aINor9IfW/RvgUTOxCH87LSh7Nw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HxAZHb6RryHvZk2BMHAAqaW7lRFdvZ8JDprkbfd7sPfG8j2+3JGnXsHSiFZhuao8X h1AFY1D9TrM+vutygMROLHiEND723gedUMpiPWFqEZ/03haa6fqlqVdJykOCNrk9Rt ht6RhMOYoBRfJsqbeF/AhgaYsiTPUuop5CDhsiOI= To: Alexander Truskovsky , "santosh.chokhani@gmail.com" , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" Cc: "ipsec@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "spasm@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 4 Oct 2017 01:58:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7" Archived-At: Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 00:58:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7 Content-Type: multipart/mixed; boundary="guJvfXQfx2dWRPA7xDWnBkvH3Ti7VwlsS"; protected-headers="v1" From: Stephen Farrell To: Alexander Truskovsky , "santosh.chokhani@gmail.com" , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" Cc: "ipsec@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "spasm@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" Message-ID: Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> --guJvfXQfx2dWRPA7xDWnBkvH3Ti7VwlsS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 03/10/17 21:38, Alexander Truskovsky wrote: > This allows X.509 certificates to contain two (or more) public keys > and issuer signatures. The goal would be to ease the migration of > PKI and dependent protocols to new digital signature algorithms. The > motivation was to make the X.509 more cryptographically agile and > simplify the migration to quantum-safe algorithms, but it is > algorithm agnostic. The main benefit of this proposal is that > current systems will be able to use these newer X.509 certificates as > they do today without any modifications, while systems that were > updated to support quantum-safe algorithms can also be updated to > understand the newer X.509 format and use quantum-safe algorithm > instead. I don't believe the "without any modifications" claim. If that were true, then the additional (hopefully) quantum-safe keys or signatures would be mere chaff. I do wonder though if it could be that the advent of a desire for post-quantum signatures is the straw that breaks the X.509 camel's back. For example, with a view to making X.509-based PKI evolution end up sufficiently more expensive compared to displacing X.509 entirely. It'll be fun to see what happens as things pan out. One reason that that might be the case is that the S. >=20 > We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few > partners and will publish it for review soon. >=20 > Alex >=20 >=20 > On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" > > wrote: >=20 > I am not sure I understand what is being said below. The link to the > PDF does not add to the message body. >=20 > If there is a concern about what signature algorithm is used for what > type of subject key, X.509 already has that flexibility. >=20 > If there is a concern about using multiple signatures on an X.509=20 > certificate, one can use the single signature algorithm identifier to > define multiple algorithms, parameters, and signatures. >=20 > -----Original Message----- From: Spasm > [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison Statement=20 > Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: > David Waltermire ; Tero Kivinen=20 > ; Russ Housley Cc: Limited > Additional Mechanisms for PKIX and SMIME Discussion List=20 > ; Eric Rescorla ; Russ Housley=20 > ; Tero Kivinen ; Scott > Mansfield ; IP Security Maintenance and > Extensions Discussion List ; Kathleen Moriarty=20 > ; David Waltermire=20 > ; itu-t-liaison@iab.org;=20 > jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison > Statement, "LS on ITU-T SG17 work on quantum-safe PKI" >=20 > Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date: > 2017-09-13 URL of the IETF Web page: > https://datatracker.ietf.org/liaison/1541/ >=20 > From: Jean-Paul Lemaire To: > David Waltermire ,Tero Kivinen=20 > ,Russ Housley Cc: David > Waltermire ,IP Security Maintenance and=20 > Extensions Discussion List > ,itu-t-liaison@iab.org,Limited Additional Mechanisms > for PKIX and SMIME Discussion List ,Russ Housley > ,Scott Mansfield=20 > ,Kathleen Moriarty=20 > ,Tero Kivinen > ,Eric Rescorla Response Contacts:=20 > jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts: Purpose: > For information >=20 > Body: ITU-T Study Group 17 is pleased to inform you that in our=20 > August/September 2017 meeting we agreed to start work on the > inclusion of a proposal to include optional support for multiple > public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. >=20 > The industry is preparing ICT systems to be resistant to attacks by=20 > large-scale quantum computers in addition to more sophisticated > attacks by conventional computing resources. Proposed was an optional > feature to the X.509 certificate that provides a seamless migration > capability to existing PKI systems, and is completely backwardly > compatible with existing systems. >=20 > While public-key key establishment algorithms are typically > negotiated between peers and are generally fairly simple to update, > the authentication systems typically rely on a single digital > signature algorithm which are more difficult to update. This is > because of the circular dependency between PKI-based identity systems > and the dependent communication protocols. In order to update a PKI > system, one would typically need to create a duplicate PKI system > that utilizes a new digital signature algorithm and then migrate all > the dependent systems one by one. >=20 > This proposal eliminates the need to create such duplicate PKI > systems by adding optional extensions to contain alternate public key > and alternate signature, and a method for the CA to sign certificates > using a layered approach to ensure that every attribute is > authenticated by both signatures. The resulting certificate, while > containing new quantum safe public key and signature, can still be > used by existing systems relying on the classic public key and > signature. Attachments: >=20 > sp16-sg17-oLS-00068 >=20 > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-= sg-17 > >=20 -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= >=20 > _______________________________________________ Spasm mailing list=20 > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ IPsec mailing list=20 > IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 > _______________________________________________ Spasm mailing list=20 > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm >=20 --guJvfXQfx2dWRPA7xDWnBkvH3Ti7VwlsS-- --ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ1DI6AAoJEC88hzaAX42iL9gH/R/aYEHSmUoQLMmvh/lV1HUU mwPMzXad/e83gwoXcD5jGevr/FSCtKirlcf/4k/MNsThOn9bUr4VBLRcGrNbfFbj tKEJPvRCKXQcMaLfRT8R8fRdFwwfQdxD6wYR8DlX89ZzB7VC8cgXinOVlYpjUjL4 Ufr6+EFyXgAZW27+yt4lvrZzGRKJzFiKVqnZb52v8xPBhiHPPUhbBib61ePqyqtS evY/OcX4FDK6G5zIaGnvwFIgFI9CDXAv6uGaNOcPCNRIeDTv7A0Fp5Vf51NkuEhl YSzad3TVrUHUcx6EudY3UHozvPTlV88lQDm9f5ztC7KpUbnnxZVsKBAlgcscjDM= =uvKt -----END PGP SIGNATURE----- --ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7-- From nobody Wed Oct 4 07:17:14 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B7F132332; Wed, 4 Oct 2017 07:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable 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 yIGLZWJbPHNc; Wed, 4 Oct 2017 07:17:09 -0700 (PDT) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) by ietfa.amsl.com (Postfix) with ESMTP id D516F132403; Wed, 4 Oct 2017 07:17:08 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip1.isaracorp.com with ESMTP; 04 Oct 2017 14:22:47 +0000 Received: from mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) by mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 4 Oct 2017 10:17:02 -0400 Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Wed, 4 Oct 2017 10:17:02 -0400 From: Alexander Truskovsky To: Stephen Farrell , "santosh.chokhani@gmail.com" , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" CC: "ipsec@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "spasm@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" Thread-Topic: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" Thread-Index: AQHTPKv1s08bHgbKA0itrmKJRnAPCqLUAJqA Date: Wed, 4 Oct 2017 14:17:02 +0000 Message-ID: <679DF703-35EF-4D67-A0FD-EFA75F755A8C@isara.com> References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.25.5.208] Content-Type: text/plain; charset="utf-8" Content-ID: <445D1031F11C694C9C28A4941F1A37F2@isaracorp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 14:17:12 -0000 VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnQuIA0KDQpXZSB0cmllZCBpdCBvbiB1bm1vZGlmaWVk IEZpcmVmb3gvQ2hyb21lL1NhZmFyaSBvbiB0aGUgZnJvbnQgZW5kIGFuZCB1bm1vZGlmaWVkIEFw YWNoZSAoT3BlblNTTC9OU1MpIG9uIHRoZSBiYWNrIGVuZCB1c2luZyBhIGNlcnRpZmljYXRlIGNo YWluIGNvbnRhaW5pbmcgUlNBK0xNUyBrZXlzL3NpZ25hdHVyZXMuICBJbiBhbGwgY2FzZXMgYSBj aXBoZXJzdWl0ZWQgdXNpbmcgUlNBIGZvciBhdXRoZW50aWNhdGlvbiB3YXMgbmVnb3RpYXRlZCBh bmQgdGhlIGNvbm5lY3Rpb24gd2FzIHN1Y2Nlc3NmdWxseSBlc3RhYmxpc2hlZCwgZXZlbiBpbiB0 aGUgY2FzZSBvZiBDaHJvbWUvU2FmYXJpIHdoZXJlIHdlIGhhZCB0byBpbmplY3QgdGhlIHJvb3Qg Y2VydGlmaWNhdGUgaW4gdG8gdGhlIE9T4oCZcyB0cnVzdGVkIGtleSBzdG9yZSAoQXBwbGUgS2V5 Y2hhaW4gaW4gdGhpcyBjYXNlKS4gIEluIHRoZSBjbGFzc2ljIHVzZSBjYXNlLCB0aGUgZXh0cmEg a2V5IGFuZCBzaWduYXR1cmUgaXMgbm90IHVzZWQuDQoNCkluIHRoZSB1cGRhdGVkIHNlcnZlciBj YXNlLCB1cG9uIHN0YXJ0dXAgdGhlIHNlcnZlciBjaGVja3MgdGhlIGNlcnRpZmljYXRlIGFuZCBl bmFibGVzIHh4X1JTQV94eCBhbmQgeHhfTE1TX3h4IGNpcGhlciBzdWl0ZXMuICBJdCBuZWdvdGlh dGVzIHh4X1JTQV94eCBjaXBoZXIgc3VpdGUgd2l0aCBhbiB1bm1vZGlmaWVkIGNsaWVudCBhbmQg cHJvY2VlZHMganVzdCBsaWtlIGluIHRoZSB1bm1vZGlmaWVkIGNhc2UgYWJvdmUuICBXaXRoIGEg bW9kaWZpZWQgY2xpZW50LCBpdCBuZWdvdGlhdGVzIHh4X0xNU194eCBjaXBoZXIgc3VpdGUsIHNl bmRzIHRoZSBzYW1lIGNlcnRpZmljYXRlIGNoYWluIGJ1dCBzaWducyB0aGUgREgga2V5cyB1c2lu ZyBMTVMgcHJpdmF0ZSBrZXkgaW5zdGVhZCBvZiBSU0EuICBUaGUgbW9kaWZpZWQgY2xpZW50IOKA nHBlZWxzIHRoZSBvdXRlciBjbGFzc2ljIHNpZ25hdHVyZSBvZmbigJ0gYW5kIHZlcmlmaWVkIHRo ZSBpbm5lciBxdWFudHVtLXNhZmUgc2lnbmF0dXJlIChvbiBhbGwgdGhlIGNlcnRpZmljYXRlIGZp ZWxkcyBtaW51cyB0aGUgY2xhc3NpYyBzaWduYXR1cmUgZmllbGQpIGFsbCB0aGUgd2F5IHVwIHRo ZSBjaGFpbi4gIEl0IHRoZW4gdXNlcyB0aGUgcXVhbnR1bS1zYWZlIHB1YmxpYyBrZXkgdG8gdmVy aWZ5IHRoZSBzaWduYXR1cmUgb24gdGhlIERIIGtleXMuDQoNCkFsZXgNCg0KDQpPbiAyMDE3LTEw LTAzLCA4OjU4IFBNLCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZT4gd3JvdGU6DQoNCiAgICANCiAgICBIaXlhLA0KICAgIA0KICAgIE9uIDAzLzEwLzE3IDIxOjM4 LCBBbGV4YW5kZXIgVHJ1c2tvdnNreSB3cm90ZToNCiAgICA+IFRoaXMgYWxsb3dzIFguNTA5IGNl cnRpZmljYXRlcyB0byBjb250YWluIHR3byAob3IgbW9yZSkgcHVibGljIGtleXMNCiAgICA+IGFu ZCBpc3N1ZXIgc2lnbmF0dXJlcy4gIFRoZSBnb2FsIHdvdWxkIGJlIHRvIGVhc2UgdGhlIG1pZ3Jh dGlvbiBvZg0KICAgID4gUEtJIGFuZCBkZXBlbmRlbnQgcHJvdG9jb2xzIHRvIG5ldyBkaWdpdGFs IHNpZ25hdHVyZSBhbGdvcml0aG1zLiAgVGhlDQogICAgPiBtb3RpdmF0aW9uIHdhcyB0byBtYWtl IHRoZSBYLjUwOSBtb3JlIGNyeXB0b2dyYXBoaWNhbGx5IGFnaWxlIGFuZA0KICAgID4gc2ltcGxp ZnkgdGhlIG1pZ3JhdGlvbiB0byBxdWFudHVtLXNhZmUgYWxnb3JpdGhtcywgYnV0IGl0IGlzDQog ICAgPiBhbGdvcml0aG0gYWdub3N0aWMuICBUaGUgbWFpbiBiZW5lZml0IG9mIHRoaXMgcHJvcG9z YWwgaXMgdGhhdA0KICAgID4gY3VycmVudCBzeXN0ZW1zIHdpbGwgYmUgYWJsZSB0byB1c2UgdGhl c2UgbmV3ZXIgWC41MDkgY2VydGlmaWNhdGVzIGFzDQogICAgPiB0aGV5IGRvIHRvZGF5IHdpdGhv dXQgYW55IG1vZGlmaWNhdGlvbnMsIHdoaWxlIHN5c3RlbXMgdGhhdCB3ZXJlDQogICAgPiB1cGRh dGVkIHRvIHN1cHBvcnQgcXVhbnR1bS1zYWZlIGFsZ29yaXRobXMgY2FuIGFsc28gYmUgdXBkYXRl ZCB0bw0KICAgID4gdW5kZXJzdGFuZCB0aGUgbmV3ZXIgWC41MDkgZm9ybWF0IGFuZCB1c2UgcXVh bnR1bS1zYWZlIGFsZ29yaXRobQ0KICAgID4gaW5zdGVhZC4NCiAgICANCiAgICBJIGRvbid0IGJl bGlldmUgdGhlICJ3aXRob3V0IGFueSBtb2RpZmljYXRpb25zIiBjbGFpbS4gSWYgdGhhdA0KICAg IHdlcmUgdHJ1ZSwgdGhlbiB0aGUgYWRkaXRpb25hbCAoaG9wZWZ1bGx5KSBxdWFudHVtLXNhZmUg a2V5cyBvcg0KICAgIHNpZ25hdHVyZXMgd291bGQgYmUgbWVyZSBjaGFmZi4NCiAgICANCiAgICBJ IGRvIHdvbmRlciB0aG91Z2ggaWYgaXQgY291bGQgYmUgdGhhdCB0aGUgYWR2ZW50IG9mIGEgZGVz aXJlDQogICAgZm9yIHBvc3QtcXVhbnR1bSBzaWduYXR1cmVzIGlzIHRoZSBzdHJhdyB0aGF0IGJy ZWFrcyB0aGUgWC41MDkNCiAgICBjYW1lbCdzIGJhY2suIEZvciBleGFtcGxlLCB3aXRoIGEgdmll dyB0byBtYWtpbmcgWC41MDktYmFzZWQNCiAgICBQS0kgZXZvbHV0aW9uIGVuZCB1cCBzdWZmaWNp ZW50bHkgbW9yZSBleHBlbnNpdmUgY29tcGFyZWQgdG8NCiAgICBkaXNwbGFjaW5nIFguNTA5IGVu dGlyZWx5LiBJdCdsbCBiZSBmdW4gdG8gc2VlIHdoYXQgaGFwcGVucw0KICAgIGFzIHRoaW5ncyBw YW4gb3V0Lg0KICAgIA0KICAgIE9uZSByZWFzb24gdGhhdCB0aGF0IG1pZ2h0IGJlIHRoZSBjYXNl IGlzIHRoYXQgdGhlDQogICAgDQogICAgUy4NCiAgICANCiAgICANCiAgICA+IA0KICAgID4gV2Ug YXJlIHdvcmtpbmcgb24gYSBkcmFmdCB0aGF0IG1pcnJvcnMgdGhlIElUVS1U4oCZcyB3b3JrIHdp dGggYSBmZXcNCiAgICA+IHBhcnRuZXJzIGFuZCB3aWxsIHB1Ymxpc2ggaXQgZm9yIHJldmlldyBz b29uLg0KICAgID4gDQogICAgPiBBbGV4DQogICAgPiANCiAgICA+IA0KICAgID4gT24gMjAxNy0x MC0wMiwgOTo1OCBQTSwgIklQc2VjIG9uIGJlaGFsZiBvZiBTYW50b3NoIENob2toYW5pIg0KICAg ID4gPGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNhbnRvc2guY2hva2hhbmlA Z21haWwuY29tPg0KICAgID4gd3JvdGU6DQogICAgPiANCiAgICA+IEkgYW0gbm90IHN1cmUgSSB1 bmRlcnN0YW5kIHdoYXQgaXMgYmVpbmcgc2FpZCBiZWxvdy4gIFRoZSBsaW5rIHRvIHRoZQ0KICAg ID4gUERGIGRvZXMgbm90IGFkZCB0byB0aGUgbWVzc2FnZSBib2R5Lg0KICAgID4gDQogICAgPiBJ ZiB0aGVyZSBpcyBhIGNvbmNlcm4gYWJvdXQgd2hhdCBzaWduYXR1cmUgYWxnb3JpdGhtIGlzIHVz ZWQgZm9yIHdoYXQNCiAgICA+IHR5cGUgb2Ygc3ViamVjdCBrZXksIFguNTA5IGFscmVhZHkgaGFz IHRoYXQgZmxleGliaWxpdHkuDQogICAgPiANCiAgICA+IElmIHRoZXJlIGlzIGEgY29uY2VybiBh Ym91dCB1c2luZyBtdWx0aXBsZSBzaWduYXR1cmVzIG9uIGFuIFguNTA5IA0KICAgID4gY2VydGlm aWNhdGUsIG9uZSBjYW4gdXNlIHRoZSBzaW5nbGUgc2lnbmF0dXJlIGFsZ29yaXRobSBpZGVudGlm aWVyIHRvDQogICAgPiBkZWZpbmUgbXVsdGlwbGUgYWxnb3JpdGhtcywgcGFyYW1ldGVycywgYW5k IHNpZ25hdHVyZXMuDQogICAgPiANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZy b206IFNwYXNtDQogICAgPiBbbWFpbHRvOnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMaWFpc29uIFN0YXRlbWVudCANCiAgICA+IE1hbmFnZW1lbnQgVG9vbCBTZW50OiBXZWRu ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNyAxMToyNSBBTSBUbzoNCiAgICA+IERhdmlkIFdhbHRl cm1pcmUgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBUZXJvIEtpdmluZW4gDQogICAgPiA8 a2l2aW5lbkBpa2kuZmk+OyBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPiBDYzog TGltaXRlZA0KICAgID4gQWRkaXRpb25hbCBNZWNoYW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSBE aXNjdXNzaW9uIExpc3QgDQogICAgPiA8c3Bhc21AaWV0Zi5vcmc+OyBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb20+OyBSdXNzIEhvdXNsZXkgDQogICAgPiA8aG91c2xleUB2aWdpbHNlYy5jb20+ OyBUZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPjsgU2NvdHQNCiAgICA+IE1hbnNmaWVsZCA8 U2NvdHQuTWFuc2ZpZWxkQEVyaWNzc29uLmNvbT47IElQIFNlY3VyaXR5IE1haW50ZW5hbmNlIGFu ZA0KICAgID4gRXh0ZW5zaW9ucyBEaXNjdXNzaW9uIExpc3QgPGlwc2VjQGlldGYub3JnPjsgS2F0 aGxlZW4gTW9yaWFydHkgDQogICAgPiA8S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+ OyBEYXZpZCBXYWx0ZXJtaXJlIA0KICAgID4gPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBp dHUtdC1saWFpc29uQGlhYi5vcmc7IA0KICAgID4gamVhbi1wYXVsLmxlbWFpcmVAdW5pdi1wYXJp cy1kaWRlcm90LmZyIFN1YmplY3Q6IFtsYW1wc10gTmV3IExpYWlzb24NCiAgICA+IFN0YXRlbWVu dCwgIkxTIG9uIElUVS1UIFNHMTcgd29yayBvbiBxdWFudHVtLXNhZmUgUEtJIg0KICAgID4gDQog ICAgPiBUaXRsZTogTFMgb24gSVRVLVQgU0cxNyB3b3JrIG9uIHF1YW50dW0tc2FmZSBQS0kgU3Vi bWlzc2lvbiBEYXRlOg0KICAgID4gMjAxNy0wOS0xMyBVUkwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6 DQogICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTU0MS8NCiAgICA+ IA0KICAgID4gRnJvbTogSmVhbi1QYXVsIExlbWFpcmUgPGplYW4tcGF1bC5sZW1haXJlQHVuaXYt cGFyaXMtZGlkZXJvdC5mcj4gVG86DQogICAgPiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0 ZXJtaXJlQG5pc3QuZ292PixUZXJvIEtpdmluZW4gDQogICAgPiA8a2l2aW5lbkBpa2kuZmk+LFJ1 c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+IENjOiBEYXZpZA0KICAgID4gV2FsdGVy bWlyZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4sSVAgU2VjdXJpdHkgTWFpbnRlbmFuY2Ug YW5kIA0KICAgID4gRXh0ZW5zaW9ucyBEaXNjdXNzaW9uIExpc3QNCiAgICA+IDxpcHNlY0BpZXRm Lm9yZz4saXR1LXQtbGlhaXNvbkBpYWIub3JnLExpbWl0ZWQgQWRkaXRpb25hbCBNZWNoYW5pc21z DQogICAgPiBmb3IgUEtJWCBhbmQgU01JTUUgRGlzY3Vzc2lvbiBMaXN0IDxzcGFzbUBpZXRmLm9y Zz4sUnVzcyBIb3VzbGV5DQogICAgPiA8aG91c2xleUB2aWdpbHNlYy5jb20+LFNjb3R0IE1hbnNm aWVsZCANCiAgICA+IDxTY290dC5NYW5zZmllbGRARXJpY3Nzb24uY29tPixLYXRobGVlbiBNb3Jp YXJ0eSANCiAgICA+IDxLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4sVGVybyBLaXZp bmVuDQogICAgPiA8a2l2aW5lbkBpa2kuZmk+LEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4g UmVzcG9uc2UgQ29udGFjdHM6IA0KICAgID4gamVhbi1wYXVsLmxlbWFpcmVAdW5pdi1wYXJpcy1k aWRlcm90LmZyIFRlY2huaWNhbCBDb250YWN0czogUHVycG9zZToNCiAgICA+IEZvciBpbmZvcm1h dGlvbg0KICAgID4gDQogICAgPiBCb2R5OiBJVFUtVCBTdHVkeSBHcm91cCAxNyBpcyBwbGVhc2Vk IHRvIGluZm9ybSB5b3UgdGhhdCBpbiBvdXIgDQogICAgPiBBdWd1c3QvU2VwdGVtYmVyIDIwMTcg bWVldGluZyB3ZSBhZ3JlZWQgdG8gc3RhcnQgd29yayBvbiB0aGUNCiAgICA+IGluY2x1c2lvbiBv ZiBhIHByb3Bvc2FsIHRvIGluY2x1ZGUgb3B0aW9uYWwgc3VwcG9ydCBmb3IgbXVsdGlwbGUNCiAg ICA+IHB1YmxpYy1rZXkgYWxnb3JpdGhtcyBpbiBSZWNvbW1lbmRhdGlvbiBJVFUtVCBYNTA5IHwg SVNPL0lFQyA5NTk0LTguDQogICAgPiANCiAgICA+IFRoZSBpbmR1c3RyeSBpcyBwcmVwYXJpbmcg SUNUIHN5c3RlbXMgdG8gYmUgcmVzaXN0YW50IHRvIGF0dGFja3MgYnkgDQogICAgPiBsYXJnZS1z Y2FsZSBxdWFudHVtIGNvbXB1dGVycyBpbiBhZGRpdGlvbiB0byBtb3JlIHNvcGhpc3RpY2F0ZWQN CiAgICA+IGF0dGFja3MgYnkgY29udmVudGlvbmFsIGNvbXB1dGluZyByZXNvdXJjZXMuIFByb3Bv c2VkIHdhcyBhbiBvcHRpb25hbA0KICAgID4gZmVhdHVyZSB0byB0aGUgWC41MDkgY2VydGlmaWNh dGUgdGhhdCBwcm92aWRlcyBhIHNlYW1sZXNzIG1pZ3JhdGlvbg0KICAgID4gY2FwYWJpbGl0eSB0 byBleGlzdGluZyBQS0kgc3lzdGVtcywgYW5kIGlzIGNvbXBsZXRlbHkgYmFja3dhcmRseQ0KICAg ID4gY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIHN5c3RlbXMuDQogICAgPiANCiAgICA+IFdoaWxl IHB1YmxpYy1rZXkga2V5IGVzdGFibGlzaG1lbnQgYWxnb3JpdGhtcyBhcmUgdHlwaWNhbGx5DQog ICAgPiBuZWdvdGlhdGVkIGJldHdlZW4gcGVlcnMgYW5kIGFyZSBnZW5lcmFsbHkgZmFpcmx5IHNp bXBsZSB0byB1cGRhdGUsDQogICAgPiB0aGUgYXV0aGVudGljYXRpb24gc3lzdGVtcyB0eXBpY2Fs bHkgcmVseSBvbiBhIHNpbmdsZSBkaWdpdGFsDQogICAgPiBzaWduYXR1cmUgYWxnb3JpdGhtIHdo aWNoIGFyZSBtb3JlIGRpZmZpY3VsdCB0byB1cGRhdGUuIFRoaXMgaXMNCiAgICA+IGJlY2F1c2Ug b2YgdGhlIGNpcmN1bGFyIGRlcGVuZGVuY3kgYmV0d2VlbiBQS0ktYmFzZWQgaWRlbnRpdHkgc3lz dGVtcw0KICAgID4gYW5kIHRoZSBkZXBlbmRlbnQgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMuIElu IG9yZGVyIHRvIHVwZGF0ZSBhIFBLSQ0KICAgID4gc3lzdGVtLCBvbmUgd291bGQgdHlwaWNhbGx5 IG5lZWQgdG8gY3JlYXRlIGEgZHVwbGljYXRlIFBLSSBzeXN0ZW0NCiAgICA+IHRoYXQgdXRpbGl6 ZXMgYSBuZXcgZGlnaXRhbCBzaWduYXR1cmUgYWxnb3JpdGhtIGFuZCB0aGVuIG1pZ3JhdGUgYWxs DQogICAgPiB0aGUgZGVwZW5kZW50IHN5c3RlbXMgb25lIGJ5IG9uZS4NCiAgICA+IA0KICAgID4g VGhpcyBwcm9wb3NhbCBlbGltaW5hdGVzIHRoZSBuZWVkIHRvIGNyZWF0ZSBzdWNoIGR1cGxpY2F0 ZSBQS0kNCiAgICA+IHN5c3RlbXMgYnkgYWRkaW5nIG9wdGlvbmFsIGV4dGVuc2lvbnMgdG8gY29u dGFpbiBhbHRlcm5hdGUgcHVibGljIGtleQ0KICAgID4gYW5kIGFsdGVybmF0ZSBzaWduYXR1cmUs IGFuZCBhIG1ldGhvZCBmb3IgdGhlIENBIHRvIHNpZ24gY2VydGlmaWNhdGVzDQogICAgPiB1c2lu ZyBhIGxheWVyZWQgYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgZXZlcnkgYXR0cmlidXRlIGlzDQog ICAgPiBhdXRoZW50aWNhdGVkIGJ5IGJvdGggc2lnbmF0dXJlcy4gVGhlIHJlc3VsdGluZyBjZXJ0 aWZpY2F0ZSwgd2hpbGUNCiAgICA+IGNvbnRhaW5pbmcgbmV3IHF1YW50dW0gc2FmZSBwdWJsaWMg a2V5IGFuZCBzaWduYXR1cmUsIGNhbiBzdGlsbCBiZQ0KICAgID4gdXNlZCBieSBleGlzdGluZyBz eXN0ZW1zIHJlbHlpbmcgb24gdGhlIGNsYXNzaWMgcHVibGljIGtleSBhbmQNCiAgICA+IHNpZ25h dHVyZS4gQXR0YWNobWVudHM6DQogICAgPiANCiAgICA+IHNwMTYtc2cxNy1vTFMtMDAwNjgNCiAg ICA+IA0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09O L2xpYWlzb24tMjAxNy0wOS0xMy1pdHUtdC1zZy0xNw0KICAgID4NCiAgICA+IA0KICAgIC1pcHNl Y21lLWxhbXBzLWxzLW9uLWl0dS10LXNnMTctd29yay1vbi1xdWFudHVtLXNhZmUtcGtpLWF0dGFj aG1lbnQtMS5wZGYNCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gU3Bhc20gbWFpbGluZyBsaXN0IA0KICAgID4gU3Bhc21AaWV0Zi5v cmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0KICAgID4gDQog ICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBJUHNl YyBtYWlsaW5nIGxpc3QgDQogICAgPiBJUHNlY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiAN CiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFNw YXNtIG1haWxpbmcgbGlzdCANCiAgICA+IFNwYXNtQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc20NCiAgICA+IA0KICAgIA0KICAgIA0KDQo= From nobody Wed Oct 4 15:19:55 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E2120724 for ; Wed, 4 Oct 2017 15:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc1QckwzcILa for ; Wed, 4 Oct 2017 15:19:50 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) (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 209D4133229 for ; Wed, 4 Oct 2017 15:19:49 -0700 (PDT) Received: from Morten ([192.174.57.204]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201710050019445429; Thu, 05 Oct 2017 00:19:44 +0200 From: "Erik Andersen" To: "'Santosh Chokhani'" , "'Alexander Truskovsky'" , , , Cc: , , , , , , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> <079001d33c88$fab856c0$f0290440$@gmail.com> In-Reply-To: <079001d33c88$fab856c0$f0290440$@gmail.com> Date: Thu, 5 Oct 2017 00:19:41 +0200 Message-ID: <000001d33d5e$e1ad7da0$a50878e0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKgI84QjmAbyZK6EBM7nHTAHWhZmZpGU2+AA= Content-Language: en-gb Archived-At: Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:19:53 -0000 Hi Santosh, I do not understand your claim that you can have multiple public keys = and signatures within the base structure of a certificate. Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Santosh = Chokhani Sendt: 03 October 2017 22:49 Til: 'Alexander Truskovsky' ; = david.waltermire@nist.gov; kivinen@iki.fi; housley@vigilsec.com Cc: ipsec@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; spasm@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Emne: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" Multiple public keys as well as signatures can be accommodated using the = respective algorithm OIDs in Signature and SPKI fields. Have you considered that in place of using an extension. -----Original Message----- From: Alexander Truskovsky [mailto:Alexander.Truskovsky@isara.com]=20 Sent: Tuesday, October 3, 2017 4:38 PM To: santosh.chokhani@gmail.com; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: spasm@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; ipsec@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" This allows X.509 certificates to contain two (or more) public keys and = issuer signatures. The goal would be to ease the migration of PKI and = dependent protocols to new digital signature algorithms. The motivation = was to make the X.509 more cryptographically agile and simplify the = migration to quantum-safe algorithms, but it is algorithm agnostic. The = main benefit of this proposal is that current systems will be able to = use these newer X.509 certificates as they do today without any = modifications, while systems that were updated to support quantum-safe = algorithms can also be updated to understand the newer X.509 format and = use quantum-safe algorithm instead. We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few partners and will publish it for review soon. Alex =20 =20 On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" = wrote: =20 I am not sure I understand what is being said below. The link = to the PDF does not add to the message body. =20 If there is a concern about what signature algorithm is used for = what type of subject key, X.509 already has that flexibility. =20 If there is a concern about using multiple signatures on an = X.509 certificate, one can use the single signature algorithm = identifier to define multiple algorithms, parameters, and signatures. =20 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison = Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion = List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott = Mansfield ; IP Security Maintenance and = Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" =20 Title: LS on ITU-T SG17 work on quantum-safe PKI Submission = Date: 2017-09-13 URL of the IETF Web page: = https://datatracker.ietf.org/liaison/1541/ =20 From: Jean-Paul Lemaire = To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security = Maintenance and Extensions Discussion List = ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott = Mansfield ,Kathleen Moriarty ,Tero Kivinen = ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts:=20 Purpose: For information =20 Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the = inclusion of a proposal to include optional support for multiple public-key = algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. =20 The industry is preparing ICT systems to be resistant to attacks = by large-scale quantum computers in addition to more sophisticated = attacks by conventional computing resources. Proposed was an optional = feature to the X.509 certificate that provides a seamless migration capability = to existing PKI systems, and is completely backwardly compatible with = existing systems. =20 While public-key key establishment algorithms are typically = negotiated between peers and are generally fairly simple to update, the = authentication systems typically rely on a single digital signature algorithm = which are more difficult to update. This is because of the circular = dependency between PKI-based identity systems and the dependent communication = protocols. In order to update a PKI system, one would typically need to create = a duplicate PKI system that utilizes a new digital signature algorithm and = then migrate all the dependent systems one by one. =20 This proposal eliminates the need to create such duplicate PKI = systems by adding optional extensions to contain alternate public key and = alternate signature, and a method for the CA to sign certificates using a = layered approach to ensure that every attribute is authenticated by both = signatures. The resulting certificate, while containing new quantum safe = public key and signature, can still be used by existing systems relying on the = classic public key and signature. Attachments: =20 sp16-sg17-oLS-00068 =20 = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg= -17 = -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Oct 5 11:21:48 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60076134317; Thu, 5 Oct 2017 11:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nxPQ9UtryKY; Thu, 5 Oct 2017 11:21:43 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F57513433C; Thu, 5 Oct 2017 11:21:43 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id r64so15365297qkc.1; Thu, 05 Oct 2017 11:21:43 -0700 (PDT) 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=RGveqHok1dBhk8/aN3gCEbk8bggqFEpkh16Qu7tw8dY=; b=vdE7qlZ0jlopezac69IbEnU434MlrfW1L5DYFkOHBr22Fvtj8V794ZFPTAPGeM3dpg 8uIzdpNufuxLoGHwJTQMUeifWYhc17cY82LCb787MdUS9qaLz/FWaaNyR5agzzku/Tt8 r6BVaN+8HUz7nBXtzqp5ka6e9AT3hLutDOhZtPSWndNNn2kEEcWNh6v7jR+uZWBMGmxt 6XgrA42xwZ2DmI34W+6FKJGiXtDZiFJYvSseeKS2G3+2t1JHbP5Xt5F0dOvLcHdUzXJ3 rIyIH3SuqeQnO38XEXd0A1YDSyMBbzGoJw9wPzmnl7c/ehvW+tuchMN6f7cdmZbTJY1G MbCg== 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=RGveqHok1dBhk8/aN3gCEbk8bggqFEpkh16Qu7tw8dY=; b=GyHNofSbRu/KbQj8mZ/IDV4GR3yo/b3rR5nADz/30Q1weBdd1uPZVpD7NciLDqjtjh +2kHiJnWiBb1E9cqqfoDmiujOlZWZzgCwfZMuG+MM0kfb8TEP9Ga6sWo5gssoi2fD0zR ZSDiBkkN98bJaVLxCqu6WwSlj8OQ4799nOHuhvDTZ1Snf/AonDTINp+PmoYZyR/E8RqO 88AgXS4rGkzkgWY3+XRlgvYOFhMichB6ShgOYm7RpoXSGAHCZYMEmjW5qsurenO3eUTR UtYdTzLMOjTI7SxFPgmZy99yFv1YXMoQBqJcNYw4Ozq8cQcdBiqrcH0eYc1lv4XzA6IH gtNg== X-Gm-Message-State: AMCzsaWWLfbnRMbh9FBH/2gQLD0qm3i9H/+Ebqmi8yhYhC9vPfdmJOYt 8tGcY8PRajsabY5CS1Uqld8= X-Google-Smtp-Source: AOwi7QCmCo2mTOBX52uAlcecYfK285sQere07XJZf79zqAG3/0dBlul9bTKCY+WD0Nazi3lmzAhR1w== X-Received: by 10.55.22.146 with SMTP id 18mr31857385qkw.281.1507227702239; Thu, 05 Oct 2017 11:21:42 -0700 (PDT) Received: from SantoshBrain (pool-173-73-191-59.washdc.fios.verizon.net. [173.73.191.59]) by smtp.gmail.com with ESMTPSA id f64sm11884233qka.6.2017.10.05.11.21.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 11:21:41 -0700 (PDT) From: "Santosh Chokhani" To: "'Erik Andersen'" , "'Alexander Truskovsky'" , , , Cc: , , , , , , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> <079001d33c88$fab856c0$f0290440$@gmail.com> <000001d33d5e$e1ad7da0$a50878e0$@x500.eu> In-Reply-To: <000001d33d5e$e1ad7da0$a50878e0$@x500.eu> Date: Thu, 5 Oct 2017 14:21:43 -0400 Message-ID: <0e9001d33e06$cc837710$658a6530$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKgI84QjmAbyZK6EBM7nHTAHWhZmZAneO7UukUsiEIA== Content-Language: en-us Archived-At: Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 18:21:46 -0000 Hello Erik, Since the parameters syntax and semantics for the AlgorithmIdentifier = are defined by the OID, that flexibility can be used to encode multiple = SPKI and signatures. There are several ways to do it. One example is for the parameters to = be SEQUENCE OF AlgorithmIdentifier for the various algorithms covered by = the SPKI and/or signature where you want multiple values. There is more = to it of course. -----Original Message----- From: Erik Andersen [mailto:era@x500.eu]=20 Sent: Wednesday, October 4, 2017 6:20 PM To: 'Santosh Chokhani' ; 'Alexander = Truskovsky' ; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: ipsec@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; spasm@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: SV: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" Hi Santosh, I do not understand your claim that you can have multiple public keys = and signatures within the base structure of a certificate. Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Santosh = Chokhani Sendt: 03 October 2017 22:49 Til: 'Alexander Truskovsky' ; = david.waltermire@nist.gov; kivinen@iki.fi; housley@vigilsec.com Cc: ipsec@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; spasm@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Emne: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" Multiple public keys as well as signatures can be accommodated using the = respective algorithm OIDs in Signature and SPKI fields. Have you considered that in place of using an extension. -----Original Message----- From: Alexander Truskovsky [mailto:Alexander.Truskovsky@isara.com]=20 Sent: Tuesday, October 3, 2017 4:38 PM To: santosh.chokhani@gmail.com; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: spasm@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; ipsec@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" This allows X.509 certificates to contain two (or more) public keys and = issuer signatures. The goal would be to ease the migration of PKI and = dependent protocols to new digital signature algorithms. The motivation = was to make the X.509 more cryptographically agile and simplify the = migration to quantum-safe algorithms, but it is algorithm agnostic. The = main benefit of this proposal is that current systems will be able to = use these newer X.509 certificates as they do today without any = modifications, while systems that were updated to support quantum-safe = algorithms can also be updated to understand the newer X.509 format and = use quantum-safe algorithm instead. We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few partners and will publish it for review soon. Alex =20 =20 On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" = wrote: =20 I am not sure I understand what is being said below. The link = to the PDF does not add to the message body. =20 If there is a concern about what signature algorithm is used for = what type of subject key, X.509 already has that flexibility. =20 If there is a concern about using multiple signatures on an = X.509 certificate, one can use the single signature algorithm = identifier to define multiple algorithms, parameters, and signatures. =20 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison = Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion = List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott = Mansfield ; IP Security Maintenance and = Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" =20 Title: LS on ITU-T SG17 work on quantum-safe PKI Submission = Date: 2017-09-13 URL of the IETF Web page: = https://datatracker.ietf.org/liaison/1541/ =20 From: Jean-Paul Lemaire = To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security = Maintenance and Extensions Discussion List = ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott = Mansfield ,Kathleen Moriarty ,Tero Kivinen = ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts:=20 Purpose: For information =20 Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the = inclusion of a proposal to include optional support for multiple public-key = algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. =20 The industry is preparing ICT systems to be resistant to attacks = by large-scale quantum computers in addition to more sophisticated = attacks by conventional computing resources. Proposed was an optional = feature to the X.509 certificate that provides a seamless migration capability = to existing PKI systems, and is completely backwardly compatible with = existing systems. =20 While public-key key establishment algorithms are typically = negotiated between peers and are generally fairly simple to update, the = authentication systems typically rely on a single digital signature algorithm = which are more difficult to update. This is because of the circular = dependency between PKI-based identity systems and the dependent communication = protocols. In order to update a PKI system, one would typically need to create = a duplicate PKI system that utilizes a new digital signature algorithm and = then migrate all the dependent systems one by one. =20 This proposal eliminates the need to create such duplicate PKI = systems by adding optional extensions to contain alternate public key and = alternate signature, and a method for the CA to sign certificates using a = layered approach to ensure that every attribute is authenticated by both = signatures. The resulting certificate, while containing new quantum safe = public key and signature, can still be used by existing systems relying on the = classic public key and signature. Attachments: =20 sp16-sg17-oLS-00068 =20 = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg= -17 = -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Oct 17 16:28:09 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3C013300C; Tue, 17 Oct 2017 16:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 xXoCpkSMfK5f; Tue, 17 Oct 2017 16:28:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55824132620; Tue, 17 Oct 2017 16:28:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 32B4CB812D8; Tue, 17 Oct 2017 16:27:45 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipsec@ietf.org Message-Id: <20171017232745.32B4CB812D8@rfc-editor.org> Date: Tue, 17 Oct 2017 16:27:45 -0700 (PDT) Archived-At: Subject: [IPsec] RFC 8221 on Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 23:28:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8221 Title: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Author: P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen Status: Standards Track Stream: IETF Date: October 2017 Mailbox: pwouters@redhat.com, daniel.migault@ericsson.com, john.mattsson@ericsson.com, ynir.ietf@gmail.com, kivinen@iki.fi Pages: 15 Characters: 33610 Obsoletes: RFC 7321 I-D Tag: draft-ietf-ipsecme-rfc7321bis-06.txt URL: https://www.rfc-editor.org/info/rfc8221 DOI: 10.17487/RFC8221 This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Oct 19 14:59:45 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DAF134303; Thu, 19 Oct 2017 14:59:37 -0700 (PDT) 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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150845037772.24326.8071096536697029807@ietfa.amsl.com> Date: Thu, 19 Oct 2017 14:59:37 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 21:59:38 -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-00.txt Pages : 16 Date : 2017-10-16 Abstract: The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 19 16:48:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B871320DC for ; Thu, 19 Oct 2017 16:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 AeaUMnDjZVGR for ; Thu, 19 Oct 2017 16:48:06 -0700 (PDT) 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 0B7F3126B7E for ; Thu, 19 Oct 2017 16:48:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yJ5GC1Z2Cz34r for ; Fri, 20 Oct 2017 01:48:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1508456883; bh=+RMuVG2EcqHTPZ0O+5DIdmNxTMvE9tbdd1QD7ZrhirI=; h=From:Date:Subject:References:In-Reply-To:To; b=tPpQsJo6QxYAkyFCoYGuDvqUZWKNEhFk7ANBV3HuZ1Zr6PwYw3e2RMZyiLBuKz3pv /pJ8oYkFpdWJvl1b5+h+sciRu6nHWBpzsJ2TQI7DAuR5Vih9UYnQbzpxAwsUzKKJ/f HaKpT2QigpBHxG9HDow8k1r1TV0em2KVm5cAE+i8= 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 5Au_jxX6mchG for ; Fri, 20 Oct 2017 01:47:58 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 20 Oct 2017 01:47:58 +0200 (CEST) Received: from [10.94.105.158] (unknown [206.108.148.90]) (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 7EFC94282F7 for ; Thu, 19 Oct 2017 19:47:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7EFC94282F7 From: Paul Wouters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 19 Oct 2017 19:47:53 -0400 Message-Id: References: <150845037772.24326.8071096536697029807@ietfa.amsl.com> In-Reply-To: <150845037772.24326.8071096536697029807@ietfa.amsl.com> To: ipsec@ietf.org X-Mailer: iPhone Mail (14G60) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 23:48:09 -0000 Did it not get marked as replacing the fluhrer draft ? Now there is no diff a= vailable. Can that still be fixed? Sent from my iPhone > On Oct 19, 2017, at 17:59, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the IP Security Maintenance and Extensions WG= of the IETF. >=20 > Title : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Valery Smyslov > Filename : draft-ietf-ipsecme-qr-ikev2-00.txt > Pages : 16 > Date : 2017-10-16 >=20 > Abstract: > The possibility of Quantum Computers pose a serious challenge to > cryptography algorithms deployed widely today. IKEv2 is one example > of a cryptosystem that could be broken; someone storing VPN > communications today could decrypt them at a later time when a > Quantum Computer is available. It is anticipated that IKEv2 will be > extended to support quantum secure key exchange algorithms; however > that is not likely to happen in the near term. To address this > problem before then, this document describes an extension of IKEv2 to > allow it to be resistant to a Quantum Computer, by using preshared > keys. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-00 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 19 19:06:35 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7972126BF0 for ; Thu, 19 Oct 2017 19:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 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 lsKfl76OrdBY for ; Thu, 19 Oct 2017 19:06:31 -0700 (PDT) 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 9DDE6126B6E for ; Thu, 19 Oct 2017 19:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3091; q=dns/txt; s=iport; t=1508465191; x=1509674791; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Rw6/yBf56aV14hHJ8otgDNGi1fy3jKMEbQUIKajzYf4=; b=aNC/lC+KTjZrau95LvV2SBReCKqte7kyf4mlxDMzUkDJzOUAuy22ztym 93uBfLIk5aINe7QuwNEJ/rBBNfG01a0zIsHdko+XlcaRBmF9Adu1tVrr6 p4mXJMn//pA9FECD181lnhr4tjfezCCQRBaRTusqN5xeGllSvGEhGCUpQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAAArWelZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHjhKPPoF6ljOCFAoYC4UYAoULPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?dAQEBAQIBAQE4NBAHBAIBCBEEAQEBHgkHJwsUCQgCBAESCIoQCBCtHosiAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYMvggeBUYUYinoFmGmIagKHX40Fgh1dhRmLD5V?= =?us-ascii?q?HAhEZAYE4AR84gVt6FR8qgmQJglMFF4FndolIgREBAQE?= X-IronPort-AV: E=Sophos;i="5.43,404,1503360000"; d="scan'208";a="19585486" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2017 02:06:30 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v9K26UVA012715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Oct 2017 02:06:30 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Oct 2017 21:06:29 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Thu, 19 Oct 2017 21:06:29 -0500 From: "Panos Kampanakis (pkampana)" To: Paul Wouters , "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt Thread-Index: AQHTSSWjPH8yZg4gFkSz1z1DoCfdfaLsKuKA///NvCA= Date: Fri, 20 Oct 2017 02:06:29 +0000 Message-ID: <60364e6514a143c184d83856d8335903@XCH-ALN-010.cisco.com> References: <150845037772.24326.8071096536697029807@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 02:06:34 -0000 Hi Paul, This draft merges all suggestions and addresses all issues brought up for t= he previously draft-fluhrer-qr-ikev2 draft. It includes many changes for re= adability and some new insightful Security Considerations. It does include = the optional NO_PPK_AUTH Valery brought up to solve the cases where a PPK_= ID is not configured for a responder. For more details Check out the -05 c= hanges in the Changes section.=20 We think it is more complete now and closer to finalization.=20 Further feedback appreciated. Rgs,=20 Panos -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters Sent: Thursday, October 19, 2017 7:48 PM To: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt Did it not get marked as replacing the fluhrer draft ? Now there is no diff= available. Can that still be fixed? Sent from my iPhone > On Oct 19, 2017, at 17:59, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IP Security Maintenance and Extensions W= G of the IETF. >=20 > Title : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Valery Smyslov > Filename : draft-ietf-ipsecme-qr-ikev2-00.txt > Pages : 16 > Date : 2017-10-16 >=20 > Abstract: > The possibility of Quantum Computers pose a serious challenge to > cryptography algorithms deployed widely today. IKEv2 is one example > of a cryptosystem that could be broken; someone storing VPN > communications today could decrypt them at a later time when a > Quantum Computer is available. It is anticipated that IKEv2 will be > extended to support quantum secure key exchange algorithms; however > that is not likely to happen in the near term. To address this > problem before then, this document describes an extension of IKEv2 to > allow it to be resistant to a Quantum Computer, by using preshared > keys. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-00 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Oct 20 17:28:24 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B28134476; Fri, 20 Oct 2017 17:24:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546247.20809.774172160421432971.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:22 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:22 -0000 Dear David Waltermire, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30:00) Monday, Morning Session I 0930-1200 Room Name: Orchard size: 50 --------------------------------------------- Special Note: 0930-1100 Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: David Waltermire Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf fud Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 23 07:46:30 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF541390EE for ; Mon, 23 Oct 2017 07:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjwHz3pSI35o for ; Mon, 23 Oct 2017 07:46:27 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 0CB9A138F9C for ; Mon, 23 Oct 2017 07:46:26 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v9NEkOjH001312 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Oct 2017 17:46:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v9NEkNK1029512; Mon, 23 Oct 2017 17:46:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23022.191.599773.817204@fireball.acr.fi> Date: Mon, 23 Oct 2017 17:46:23 +0300 From: Tero Kivinen To: Paul Wouters Cc: ipsec@ietf.org In-Reply-To: References: <150845037772.24326.8071096536697029807@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 26 min Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 14:46:29 -0000 Paul Wouters writes: > Did it not get marked as replacing the fluhrer draft ? Now there is > no diff available. Can that still be fixed? Not automatically, and I was in progress of doing that, but it took me few minutes to find out how to do it properly... It should be marked as replacing it now. -- kivinen@iki.fi From nobody Thu Oct 26 12:23:28 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A913F5E8 for ; Thu, 26 Oct 2017 12:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDHK5Yf2v6dO for ; Thu, 26 Oct 2017 12:23:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 7BDE013955E for ; Thu, 26 Oct 2017 12:23:19 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v9QJNEZF013436 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 Oct 2017 22:23:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v9QJNELv007606; Thu, 26 Oct 2017 22:23:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23026.13858.483048.716056@fireball.acr.fi> Date: Thu, 26 Oct 2017 22:23:14 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Subject: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 19:23:22 -0000 We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our main agenda item will be the rechartering text, i.e., our charter will expire by the end of year, and we have most of our chartered work already completed, or almost finished, so we need to decide what new items (if any) we take to our charter, or wheter we shut down the WG. In last IETF we had people with items which we could add to charter, so I want those people wanting to add things to charter to send an email to the mailing list about what items they would like to propose to the charter, and preliminary charter text for the item. If we do not receive any proposed charter texts, then I assume we do not have any more work to do after we finish our current charter... Also if there is people wanting to present anything in the next IPsecME IETF session, send email to wg chairs ipsecme-chairs@ietf.org. -- kivinen@iki.fi From nobody Thu Oct 26 12:47:38 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C9D13871A for ; Thu, 26 Oct 2017 12:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evmImOn0aEga for ; Thu, 26 Oct 2017 12:47:35 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B95613836A for ; Thu, 26 Oct 2017 12:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZwNMw1TuDVgBCL5yz7+45vqpa0iKPKMKhE2TbITHMMU=; b=jw4B+iKiVNnSOrG2IHjBlFugw1bRYXq8Xm3XSDbb1ATeAMOfoenyWQHiPN55Ptc9Ikjwh4UeJBX8NgqqgcNivP1tawWAIN0t9SAA6FFigzDwiBvZO4zUtfnZXwjr8wsQ0rf7b0rPReki/6v1Vwq2zhPbPrVVFdk3ZeNXG27mN34= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1494.namprd09.prod.outlook.com (10.173.191.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 26 Oct 2017 19:47:33 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) by CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) with mapi id 15.20.0156.006; Thu, 26 Oct 2017 19:47:33 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-mglt-ipsecme-implicit-iv-04 Thread-Index: AdNOkzriDYsiRD0mRZq28+jyA1X4JA== Date: Thu, 26 Oct 2017 19:47:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1494; 6:rcqdVOI2qK0tHSkQPKiKSSq2Uo58Jzp15Ae7bv3CxEUhcEqqpQp9uwA8ao2KKx0EcfJA3vJNeO/z+utguv4VHWjbl+Kz9P7HR9PEe1lj85jswyt/DMpt4umzAIvnhw8dYawrjE4AjD+2cubIlIYnPyu0L9+a7N4X4w0FadrwU6jzJ9v0O5a3RmiTOTHGodEc0anGabEk2DyT6ZKATtAftzpEsmUFsesn495MKPJZotoXtiCHAcIUVv99jtSlr3wbQRiRP9sSfFrw5WE+oinMe1j3fqwT4gq8zGN1ppJ6nSq0vCPcEde9XSNheBNAe5drle00XMiZy+HpCwBNw3CSH8dLUuc9XRBjarqkJSlKas8=; 5:rp1LY2vqWPoPmJuirAqPa+Vs+Ao9h/sVkqxIhKoeSMbcp5ltQg1A7o3yfub6OOWz0nKTmjqy0kBBPexa7NrmQ5NOSBzxY9gJpZId03nHqdLOCp0xpHiXm5CkBHIL7SUSBf+eQ8589IxBlIRxxixAsnMnw11xi2jjMarlVfJ6WHI=; 24:gZwhD9zQ7TKeXgLn+g8j4H++mFeHqMOVNPhl6rsGFe4F3nxm6OIP+xJHep7XUbR9tgRVnegfZFECitT5NKbmthEPhFp6DSl2IcPzCUqncQI=; 7:LkP3Zl8efJ4wjvKuwp38Pc/vH4FLLWJ9NC/z3qL4ww1kheAWmmwzH67zvRa5HAmyQ82JdtVP35P9j97/8CTtteuBuzFI9FmRQhSDqidubie2PpXfc9KME08Mn9TfkUDwny05ux+YM+pthFeUJoMHHaPSpIsnIWbY81TIO2bLs3zvxueKzhzLlopmNVUU79aGxQUSoTGXMb5NlcxolZPsnValIakzPfCI6UBxE18tHluASOdx899qNBUXTN7WG9rP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d99aed3a-da40-4d51-8dd3-08d51caa66b6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1494; x-ms-traffictypediagnostic: CY4PR09MB1494: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1494; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1494; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(77096006)(6436002)(101416001)(6916009)(2906002)(316002)(8936002)(14454004)(9686003)(8676002)(5660300001)(53936002)(7696004)(99286003)(68736007)(81166006)(86362001)(478600001)(55016002)(6506006)(6306002)(189998001)(50986999)(54356999)(25786009)(6116002)(66066001)(74316002)(305945005)(7736002)(102836003)(230783001)(966005)(81156014)(33656002)(3846002)(3280700002)(106356001)(2900100001)(3660700001)(97736004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1494; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: d99aed3a-da40-4d51-8dd3-08d51caa66b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 19:47:33.4332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1494 Archived-At: Subject: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 19:47:37 -0000 All, This message starts a Working Group Last Call (WGLC) for draft-mglt-ipsecme= -implicit-iv-04. The version to be reviewed can be found here: https://www.ietf.org/id/draft= -mglt-ipsecme-implicit-iv-04.txt. Please send your comments, questions, and edit proposals to the WG mail lis= t until November 9th, 2017. If you believe that the document is ready to b= e submitted to the IESG for consideration as a Standards Track RFC please s= end a short message stating this. Best Regards, Dave and Tero From nobody Thu Oct 26 13:13:47 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4F13875A for ; Thu, 26 Oct 2017 13:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHbJ0h4h2oMW for ; Thu, 26 Oct 2017 13:13:43 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB1E13871A for ; Thu, 26 Oct 2017 13:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JFSKybwxYuAbq99P8/I5lhOGdWRCrFQP/fTHbfyA0uE=; b=j0LAP27zuiFxB4g4QawXsYu855mA2Alutv8ZV4lnc+xVgsSkMyTxRl2xAt7QzeBZnBJ1ruVVGzyWooW6U8LDIJtG29K3GYAuKWUAS7O0X9NEKeoptRL6O1oLmLGs1O66GwAIWodzMUpv3UWu7cD1AAUpQifx++A+tJmBTenP5Ro= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 20:13:41 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) by CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) with mapi id 15.20.0156.006; Thu, 26 Oct 2017 20:13:41 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-split-dns-02 Thread-Index: AdNOlrkMorSbSNbRSaqPxtt3gqYzBQ== Date: Thu, 26 Oct 2017 20:13:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1495; 6:lUwUe3qITFCjMYvQ6Aa9yBp1beiDxC7j9kJ6tuXEqAKSHVX7iP6c4qlcUHvoeVGIAMQwFw0YDH8K3SjZZIHpBK15QbcafKMEu+DzWPzE+Vz0hdC6w2vTTcLlxxUP6uSqALrBM89k2tRkexYqSny374UsemBo+l8pNe1igr27lAKCmisiSaAamefM/lwmaVqXadZTidBnYMZQ5tYwsF8ZZUj9stNhL5ELsuHjMo9c7x87mgs+8sqS7ESFT+DdtF6CpLc/v+3MfOjAqG7yMGKXPOjEPconWSVe+K70ITQTzgZzan+dHI8MDfqkxsPBOBnEdcfZYOUgBKFmQFrAe/gnww==; 5:Ty2ImKeevK7LdwUQzjewJkBhnkmcP3ybzUhCs5XR20pg4ckNVTGRhK1irbVTje4/5UUWNw353YMn+P3sYeLCbRS/0in5H2X/He/hkivOGqjZLQuZcaOlWzVWL4JkPc0oobhCwnSEoAvVRI29SKduhA==; 24:KYRIX2mWZtc7cTlG3COeOfHFCqkeVciKdxlGCpnrMEDcQqaLXvh8rBIeGhynhGVrgg5xMKzf/zTz1cnm5SHpnIGgN7sxDQivL2VR/Ff1cNA=; 7:zT4xFp4X4rqqLUzHXRqQfJefbeLZS1CSfSH8WYVrJam4RrNRol2deusUn58S5Qc4su1cNmd7UWUd5yUSZFxeMJiR8a7GxbQ/x4tFFJ+JnQUYTGKbi6Hs+csFy0wTAhlL3r3Puww4Ut9lolQnAunp7XDqHZCqohK1t92UCO9cEtHNaurEaL6Nx9B/6u2Dr68GgsyPlbklijGA2g/+dUs7QFwyuWcIQAo49/CGcdSybRw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 926be24b-8e05-46dd-fbe3-08d51cae0d13 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:CY4PR09MB1495; x-ms-traffictypediagnostic: CY4PR09MB1495: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1495; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1495; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(189002)(199003)(14454004)(99286003)(74316002)(50986999)(2906002)(5660300001)(7696004)(81166006)(33656002)(6916009)(230783001)(81156014)(8676002)(3660700001)(105586002)(25786009)(7736002)(66066001)(54356999)(189998001)(101416001)(8936002)(305945005)(3280700002)(106356001)(6306002)(6116002)(3846002)(102836003)(966005)(2900100001)(6506006)(97736004)(478600001)(6436002)(68736007)(9686003)(77096006)(316002)(55016002)(86362001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1495; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 926be24b-8e05-46dd-fbe3-08d51cae0d13 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 20:13:41.0531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1495 Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 20:13:45 -0000 All, This message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme= -split-dns-02. The version to be reviewed can be found here: https://www.ietf.org/id/draft= -ietf-ipsecme-split-dns-02.txt. Please send your comments, questions, and edit proposals to the WG mail lis= t until November 9th, 2017. If you believe that the document is ready to b= e submitted to the IESG for consideration as a Standards Track RFC please s= end a short message stating this. Best Regards, Dave and Tero From nobody Thu Oct 26 13:58:37 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EA313F603 for ; Thu, 26 Oct 2017 13:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J5_ih1TI3v6 for ; Thu, 26 Oct 2017 13:58:33 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 6FCA413899A for ; Thu, 26 Oct 2017 13:58:33 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 196so553889wma.1 for ; Thu, 26 Oct 2017 13:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NuAcaeIjeqKhpqkWjDP3LufmmKpTinsyI30Q/bt0bDM=; b=Rti5k+QGCjOFshsIWsmjl2i1cI+MX8TT8GWSmXKgkGqj5jCaS81xsZvxlB+7DzPxoQ WBowm4GcAApeyIvVesWx8DpncDr4AmXZd+wg+ENvJuUHod2TmuJqNPmDg47llWhbMGw5 GA/qQP9CfTsMp2kaXXrMZ57NA2N9FFAlX2x/FXMz/xozj01M8fnd3UcFPuIMcUIuw1zP 82HUifkORVtjZiyH+NPD7VCiWFvjjNJlqqlW44Ruzg72K1tqcJK0E4s+oX1t5IBG/jSi AlE4msITIGwsMukLDGfaC+c5eGylG6809Sq+VDZ+8lc4COZIH7zyD8wxxY4GqxEUFGVp kb0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NuAcaeIjeqKhpqkWjDP3LufmmKpTinsyI30Q/bt0bDM=; b=tXi6N7EMbs4oIx3I+udpnfw+S9JI+3gRDr9EUSb9D1nj23p4f3+BVrh4Au54uqPY+K M3Lns4u7n9gyhSqOJXX8Y1sPHYerLc6b41z6kmkbJ19KBvjnQo+CjEZuxLz4eic4GTcp LUc5hio+IJkegy/mDyK0wvdma0Ud0qtJENJVwy9RslWbzxqct6ovGH0GaE31J9StWkYm 5XTNoKKptt9GTeGPmB5+ZdQEt5sKv/Mg2c4VvbTlP27ULLqRtGKwHCWhM2L3OxNKck0z KXZiBFIJgaBjgA3e3Lf7Qo4D4J2pKQ5FH3v7xTE7RJu7Oxzo0isnUhLRGBfKIdvLWYbw ftKA== X-Gm-Message-State: AMCzsaWLMCbu8xmd/iyM5P4k0MjOGNdTpRck7tm8s92zL7jkQo3Z9b+z N27uw0iBPDK0xwrSCkOHBew= X-Google-Smtp-Source: ABhQp+SD0CpHdqYIxw/aRap7BGSuff9lEf7+K63mCtsvn4ul3Zqbg18ZPpgW1EbopvjDgwCAZ16MMQ== X-Received: by 10.28.95.70 with SMTP id t67mr175688wmb.86.1509051512018; Thu, 26 Oct 2017 13:58:32 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y29sm5402200wrd.3.2017.10.26.13.58.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 13:58:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Yoav Nir In-Reply-To: <23026.13858.483048.716056@fireball.acr.fi> Date: Thu, 26 Oct 2017 23:58:29 +0300 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <23026.13858.483048.716056@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 20:58:35 -0000 There used to be a special working group for multicast security. That = has closed, so IPsecME is the natural home for this work: The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based=20= protocol for negotiating group keys for both multicast and unicast uses. = The=20 Working Group will develop an IKEv2-based alternative that will include=20= cryptographic updates. A possible starting point is draft-yeung-g-ikev2 Brian, Valery, and Yoav > On 26 Oct 2017, at 22:23, Tero Kivinen wrote: >=20 > We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our > main agenda item will be the rechartering text, i.e., our charter will > expire by the end of year, and we have most of our chartered work > already completed, or almost finished, so we need to decide what new > items (if any) we take to our charter, or wheter we shut down the WG. >=20 > In last IETF we had people with items which we could add to charter, > so I want those people wanting to add things to charter to send an > email to the mailing list about what items they would like to propose > to the charter, and preliminary charter text for the item. >=20 > If we do not receive any proposed charter texts, then I assume we do > not have any more work to do after we finish our current charter... >=20 > Also if there is people wanting to present anything in the next > IPsecME IETF session, send email to wg chairs ipsecme-chairs@ietf.org.=20= > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Oct 27 06:56:53 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E74413F565 for ; Fri, 27 Oct 2017 06:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ku7A1Okuit8k for ; Fri, 27 Oct 2017 06:56:49 -0700 (PDT) Received: from mo5.mail.sc.edu (mo5.mail.sc.edu [129.252.158.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8874613F516 for ; Fri, 27 Oct 2017 06:56:49 -0700 (PDT) Received: from mo5.mail.sc.edu (127.0.0.1) id hucti20171sl for ; Fri, 27 Oct 2017 09:56:48 -0400 (envelope-from ) Received: from CAE145HUBP01.ds.sc.edu ([172.27.7.168]) by mo5.mail.sc.edu (SonicWALL 8.2.1.4973) with ESMTPS (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256) id 201710271356480408383; Fri, 27 Oct 2017 09:56:48 -0400 Received: from CAE145EMBP02.ds.sc.edu ([fe80::bc67:c4b6:7a3c:50a0]) by CAE145HUBP01.ds.sc.edu ([::1]) with mapi id 14.03.0339.000; Fri, 27 Oct 2017 09:56:41 -0400 From: "LUO, LANNAN" To: "ipsec@ietf.org" Thread-Topic: IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) Thread-Index: AQHTTN4tHq1UdrQ9G0Gy7sJzFTVFw6LzIt5DgAAA0teAAABrVIAAAMAzgABdBVeAAABc4YAAAEBfgAAAIq+AAAD044AAABahgAAAJyuAAAAr+4AAAFE3gAAAR1eAAABgz4AAAJSRgAABVYuAAAItpYAAAEH7gAAA1m2AAAQOAYAAAC0BgAAAWg2AAADW4YAAAD8FgAAANaeAAC1EMoAD+M0lgAAD3ZyAAAMbjw== Date: Fri, 27 Oct 2017 13:56:40 +0000 Message-ID: References: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.7.4] Content-Type: multipart/alternative; boundary="_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA12CDCAE145EMBP02dss_" MIME-Version: 1.0 X-Mlf-Version: 8.2.1.4973 X-Mlf-UniqueId: o201710271356480408383 Archived-At: Subject: [IPsec] IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:56:52 -0000 --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA12CDCAE145EMBP02dss_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable CALL FOR PAPERS IEEE CNS 2018 IEEE Conference on Communications and Network Security Beijing, China, May 30-June 1, 2018 URL: http://cns2018.ieee-cns.org/ IEEE Communications Society Core Conference PAPER SUBMISSION DEADLINE December 20, 2017 ***************************************************************************= ********* IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, polic= y makers, and users to exchange ideas, techniques and tools, raise awarenes= s, and share experience related to all practical and theoretical aspects of= cybersecurity. Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the= network layer to the variety of applications reliant on a secure communica= tion substrate. TOPICS OF INTERESTS -------------------------------- * Anonymity and privacy technologies * Computer and network forensics * Cyber deterrence strategies * Game-theoretic security technologies * Implementation and evaluation of networked security systems * Information-theoretic security * Intrusion detection, prevention, and response * Key management, public key infrastructures, certification, revocation, an= d authentication * Malware detection and mitigation * Security metrics and models * Physical-layer and cross-layer security technologies * Security and privacy for big data * Security and privacy for data and network outsourcing services * Security and privacy for mobile and wearable devices * Security and privacy in cellular networks * Security and privacy in cloud and edge computing * Security and privacy in crowdsourcing * Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) * Security and privacy in peer-to-peer and overlay networks * Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks * Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems * Security for critical infrastructures (smart grids, transportation system= s, etc.) * Security for future Internet architectures and designs * Security for software-defined and data center networks * Social, economic, and policy issues of trust, security, and privacy * Traffic analysis * Usable security and privacy * Web, e-commerce, m-commerce, and e-mail security IMPORTANT DATES --------------------------- Paper Submission Deadline: December 20, 2017 Notification of Acceptance: February 27, 2018 Final Paper Submission: March 19, 2018 CONFERENCE CHAIRS ------------------------------- General Chair: Jiwu Jing (Chinese Academy of Sciences, PR China) Program Chairs: Loukas Lazos (University of Arizona, USA) Peng Liu (Pennsylvania State University, USA) TECHNICAL PROGRAM COMMITTEE ---------------------------------------------------- See: http://cns2018.ieee-cns.org/ --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA12CDCAE145EMBP02dss_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
          =                CALL FOR PAPERS &nbs= p;
 
            &nb= sp;            =   IEEE CNS 2018          =
 
           IEEE Conferenc= e on Communications and Network Security 
            &nb= sp;         Beijing, China, May 30-= June 1, 2018 
            &nb= sp;         URL: http://cns2018.ieee-cns= .org/ 
            &nb= sp;            =     
            &nb= sp;     IEEE Communications Society Core Conference&nbs= p;
 
            &nb= sp;     PAPER SUBMISSION DEADLINE December 20, 2017&nbs= p;
 
***************************************************************************= ********* 
IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, policy makers, and users to exchange = ideas, techniques and tools, raise awareness, and share experience related = to all practical and theoretical aspects of cybersecurity. 
 
Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the network layer to the variety of a= pplications reliant on a secure communication substrate.  
 
TOPICS OF INTERESTS 
-------------------------------- 
* Anonymity and privacy technologies 
* Computer and network forensics 
* Cyber deterrence strategies 
* Game-theoretic security technologies 
* Implementation and evaluation of networked security systems 
* Information-theoretic security 
* Intrusion detection, prevention, and response 
* Key management, public key infrastructures, certification, revocation, an= d authentication 
* Malware detection and mitigation 
* Security metrics and models 
* Physical-layer and cross-layer security technologies 
* Security and privacy for big data 
* Security and privacy for data and network outsourcing services 
* Security and privacy for mobile and wearable devices 
* Security and privacy in cellular networks 
* Security and privacy in cloud and edge computing 
* Security and privacy in crowdsourcing 
* Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) 
* Security and privacy in peer-to-peer and overlay networks 
* Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks 
* Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems 
* Security for critical infrastructures (smart grids, transportation system= s, etc.) 
* Security for future Internet architectures and designs 
* Security for software-defined and data center networks 
* Social, economic, and policy issues of trust, security, and privacy =  
* Traffic analysis  
* Usable security and privacy  
* Web, e-commerce, m-commerce, and e-mail security   
 
 
IMPORTANT DATES 
--------------------------- 
Paper Submission Deadline: December 20, 2017 
Notification of Acceptance: February 27, 2018 
Final Paper Submission: March 19, 2018  
 
 
CONFERENCE CHAIRS  
------------------------------- 
General Chair:  
Jiwu Jing (Chinese Academy of Sciences, PR China)  
 
Program Chairs:  
Loukas Lazos (University of Arizona, USA) 
Peng Liu (Pennsylvania State University, USA) 
 
 
TECHNICAL PROGRAM COMMITTEE 
---------------------------------------------------- 
See: http://cns2018.ieee-cns.org/
 
--_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA12CDCAE145EMBP02dss_-- From nobody Fri Oct 27 07:51:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A43313F579 for ; Fri, 27 Oct 2017 07:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 L_3M7NLOhBjb for ; Fri, 27 Oct 2017 07:51:35 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2A513F562 for ; Fri, 27 Oct 2017 07:51:35 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id k40so7708281lfi.4 for ; Fri, 27 Oct 2017 07:51:35 -0700 (PDT) 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=cERKbfDMdOkZxm+4cV4ye1DBwaxj7q6Y4p+GhBvnAHo=; b=ptiR2h/dQb8z2ojHKMVFeE8pxfHNwhNtF9tzGcNYJSeikgcPSOIn0DWiCVYcJIcxGG bukKi8hiJaD7ve0WYzZnxlZQLegN1eLgV+AXFB9Sz+uvJMZnuwJzVprN7+qN7Tc291Ax CN/6n4ahPisszw2Cpg4CHM9tD1IXmqlS+vFoCTXm+6IdAffOal4dtqHDuddYMBAALimn a7J350XVIdJH8r8j3Suj6TNB/GI+P005Hjh0FGC9z5qVjiKKDh0dqtYurnhwFl09ycKC Z/bivWhShjSa/GNwIXsK54mM1/nntY4T6naOQG6B15RZVLsgfZXRKNxokfZaayzLIKVU klvQ== 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=cERKbfDMdOkZxm+4cV4ye1DBwaxj7q6Y4p+GhBvnAHo=; b=SIQCfl8+w5doBHudK5cwKskwz0GWMGlkFfSOJO7FWyLn4qeOx7N2eJZUb7r0cTLSBJ Qy4AD/D5DI6VZs5bz8oVEAzEAbjtfWPFluAQu6+g527NXzOjLz+NsrCetkmh4wvsH+o+ sIB6dpOYFMEcbJHw1VL4hV722twM2FP5kGxOFjuv2Ue0UEXOY7QFggPOEahojqw570tu g1Nw7PH/2K0zjjAPgQo0a4xwXCCWfH5F8fnrKzSPeB+0x6abBN2pzNAU2cHnVcJs2QLk 0d19kX3yCkLP73yI/1XG2PZJW1OXzxOTlxwVEe4tjRziGjJGtOrTgIkhIM8rAyDc9Qp1 AArw== X-Gm-Message-State: AMCzsaVvXH99c64wr6HorNoLYU50n0e720ffcSla/xZKcmv4eAz3HqZc sQzVWcbaT2JHbdDbrT1jx2kXoA== X-Google-Smtp-Source: ABhQp+ScgznldTItCBOicBZPOiG1UYuujPGrmy7RRRRvcQW1HopV7GGapO5A7JRnSlWKEusXFp4yJA== X-Received: by 10.25.213.12 with SMTP id m12mr210615lfg.201.1509115893438; Fri, 27 Oct 2017 07:51:33 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h86sm1636466lfl.59.2017.10.27.07.51.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 27 Oct 2017 07:51:32 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <23026.13858.483048.716056@fireball.acr.fi> In-Reply-To: <23026.13858.483048.716056@fireball.acr.fi> Date: Fri, 27 Oct 2017 17:51:34 +0300 Message-ID: <0fda01d34f33$1600bd70$42023850$@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: AQMw1niW9yk+rAP08ubSySOCJGyjxKA8qWXA Content-Language: ru Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 14:51:37 -0000 Hi, I think that the following items can be considered for the new charter. 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter text: MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from one IP address to another. However, in MOBIKE it is the initiator of the IKE SA (i.e. remote access client) that controls this process. If there are several responders each having own IP address and acting together as a load sharing cluster, then it is desirable for them to have ability to request initiator to switch to a particular member. The working group will analyze the possibility to extend MOBIKE protocol or to develop new IKE extension that will allow to build load sharing clusters in an interoperable way. 2. Make IKEv2 Postquantum Cryptography ready. In particular - make it able to transfer large payloads in initial exchange without having IP fragmentation issues. The possible charter text: Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Direct using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. Regards, Valery. > We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our > main agenda item will be the rechartering text, i.e., our charter will > expire by the end of year, and we have most of our chartered work > already completed, or almost finished, so we need to decide what new > items (if any) we take to our charter, or wheter we shut down the WG. > > In last IETF we had people with items which we could add to charter, > so I want those people wanting to add things to charter to send an > email to the mailing list about what items they would like to propose > to the charter, and preliminary charter text for the item. > > If we do not receive any proposed charter texts, then I assume we do > not have any more work to do after we finish our current charter... > > Also if there is people wanting to present anything in the next > IPsecME IETF session, send email to wg chairs ipsecme-chairs@ietf.org. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Oct 27 08:30:47 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68013F5A8 for ; Fri, 27 Oct 2017 08:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 eW-gdogAEICp for ; Fri, 27 Oct 2017 08:30:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 905FD13F5A0 for ; Fri, 27 Oct 2017 08:30:39 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v9RFUbNe008007 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Oct 2017 18:30:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v9RFUbID027925; Fri, 27 Oct 2017 18:30:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23027.20765.436882.134002@fireball.acr.fi> Date: Fri, 27 Oct 2017 18:30:37 +0300 From: Tero Kivinen To: "Waltermire\, David A. \(Fed\)" Cc: IPsecME WG In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Subject: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 15:30:45 -0000 Waltermire, David A. (Fed) writes: > This message starts a Working Group Last Call (WGLC) for > draft-mglt-ipsecme-implicit-iv-04. > > The version to be reviewed can be found here: > https://www.ietf.org/id/draft-mglt-ipsecme-implicit-iv-04.txt. > > Please send your comments, questions, and edit proposals to the WG > mail list until November 9th, 2017. If you believe that the > document is ready to be submitted to the IESG for consideration as a > Standards Track RFC please send a short message stating this. In section 8, fix the spelling of the ENCR_AES-CCM_8_IIV and similar so that they do not use "-", but only "_" (or otherwise be ready to face the wrath of the angry implementor in next IETF). I.e. - ENCR_AES_CCM_8_IIV - ENCR_AES_GCM_16_IIV - ENCR_CHACHA20_POLY1305_IIV -- kivinen@iki.fi From nobody Fri Oct 27 09:33:07 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B9E13F5AB for ; Fri, 27 Oct 2017 09:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEI9maUGa-5i for ; Fri, 27 Oct 2017 09:33:04 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF36F1389E6 for ; Fri, 27 Oct 2017 09:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1509121984; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jdMhNZx+eE5bSl54wIWXYwKywVJ3Qd2kYlnwfjccsXY=; b=fN9mmY4vvP9C3JZ24qZn+j0ua6CGO9TZVJHDuDRCd9YA5aoX6kamw3McjxPIlpKL DAiQJ/3BTPeLB8F8IfT5xSTV+r8SZy4PlsHt050NF/9TRJWjl/yatGGE9Q68BKeD GCjYyfJrGaYMbVU5HQ/SGu0UCxsdVNQI9RutysPilu+R0/zlqoyenyNdVc3pJOzX zHmnFofxV8PJCLImOqA9oSYzmxP02Y/L2lnU+Mhg7GhU/FZyhg6xnidq4fxMP4+k 0C1QuNDlwrrLDdZOLk7NcynahfdrmMvOxbLNtjg47n8sQxD277/B78/WYnLhp5Ym vbUBIdWtYmVIEhvdrsq9UA==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 4C.B8.11795.0CF53F95; Fri, 27 Oct 2017 09:33:04 -0700 (PDT) X-AuditID: 11973e16-496299c000002e13-0b-59f35fc0bfb2 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay4.apple.com (Apple SCV relay) with SMTP id D5.59.31187.0CF53F95; Fri, 27 Oct 2017 09:33:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from da0602a-dhcp185.apple.com ([17.226.23.185]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OYH00GEKPZ4BE80@nwk-mmpp-sz10.apple.com>; Fri, 27 Oct 2017 09:33:04 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Date: Fri, 27 Oct 2017 09:33:03 -0700 References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> To: Valery Smyslov , IPsecME WG , Tero Kivinen In-reply-to: <0fda01d34f33$1600bd70$42023850$@gmail.com> Message-id: <32759AD8-5A82-4218-AED7-9A2EE7F6B252@apple.com> X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUi2FAYrnsg/nOkwfoTKhb7t7xgszh6/jmb xY0PM9kcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZTy5N4m1oEGq4sjLTawN jG9Euhg5OCQETCQunWLpYuTiEBJYzSSxc8IZti5GTrB4y5l1jBCJQ4wS67uvMoIkeAUEJX5M vscC0swsIC9x8LwsSJhZQEvi+6NWqEGTmSSaNz1iAqkRFpCQ2LwnEaSGTUBF4vi3DcwQYQ2J W5+iQcIsAqoS3zc/YQaxhQRSJSZNfMUIUiIikCxx9EkJSJhTwEKi788UVogDbCTOrl3CDnGl osTDTV2sIFslBBrZJP5/bmOZwCg0C8mhsxAOnYXk0AWMzKsYhXITM3N0M/PM9RILCnJS9ZLz czcxgsJ5up3YDsaHq6wOMQpwMCrx8K7Q/BQpxJpYVlyZe4hRmoNFSZz3dRFQSCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUAyN7X8brrVxTpBKZ9vCWXrFbrSEtUq4uy7ao9tDr7fMt1ttzCbn2 G3/nkHv9ly1Ytrl3zpO1505y3zN7a/AkbNUks5BNEbulj+r+jHEyaHd/+j7oZfb/hhWJ7YIp CY+reY7ND7aXmbh54u7znxY9c1rMsXxZY6aG5Ie+OrVDOea3uF/VbfNUW6rEUpyRaKjFXFSc CAB5v/wWSAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUi2FBcpXsg/nOkwYz7ihb7t7xgszh6/jmb xY0PM9kcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZTy5N4m1oEGq4sjLTawN jG9Euhg5OSQETCRazqxj7GLk4hASOMQosb77KiNIgldAUOLH5HssXYwcHMwC8hIHz8uChJkF tCS+P2plgaifzCTRvOkRE0iNsICExOY9iSA1bAIqEse/bWCGCGtI3PoUDRJmEVCV+L75CTOI LSSQKjFp4itGkBIRgWSJo09KQMKcAhYSfX+msEIcYCNxdu0SdogrFSUebupincDIPwvJbbMQ bpuF5LYFjMyrGAWKUnMSK030EgsKclL1kvNzNzGCA7AwfAfjv2VWhxgFOBiVeHhXaH6KFGJN LCuuzAV6noNZSYTXIOJzpBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe5VFAKYH0xJLU7NTUgtQi mCwTB6dUA6PlnD8V1vM6jx0rTuBQjdPg/eZYM01B0nPusn3dih/Ebs9JffuvM+pk2Gw9/cat xp8MA98xeWW+EGy67NcmUf3MR3jam10fd/KX30navpDjbLvHjxcdsVb3osx/f/1rcNgvzb0o UVHlQPWVmquSKVUVPvMqDF4xfKth8ena8vDRoor5HT15gkosxRmJhlrMRcWJAAZjphY8AgAA Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 16:33:06 -0000 + 1 to these proposals I'd also like to see the work on drafts like DIET-ESP (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have some growing use cases for IPsec in constrained networks, and as that develops, extensions and modifications to the protocol to make IKEv2 and ESP work efficiently in those conditions will be necessary. (These would likely fall into the host-to-host use case described in the charter.) Thanks, Tommy > On Oct 27, 2017, at 7:51 AM, Valery Smyslov wrote: > > Hi, > > I think that the following items can be considered for the new charter. > > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter text: > > MOBIKE protocol [RFC4555] is used to move existing > IKE/IPsec SA from one IP address to another. However, > in MOBIKE it is the initiator of the IKE SA (i.e. remote access client) > that controls this process. If there are several responders > each having own IP address and acting together as a load sharing cluster, > then it is desirable for them to have ability to request initiator to switch to > a particular member. The working group will analyze the possibility > to extend MOBIKE protocol or to develop new IKE extension > that will allow to build load sharing clusters in an interoperable way. > > 2. Make IKEv2 Postquantum Cryptography ready. In particular - make it > able to transfer large payloads in initial exchange without having > IP fragmentation issues. The possible charter text: > > Postquantum Cryptography brings new key exchange methods. > Most of these methods that are known to date have much larger public > keys then conventional Diffie-Hellman public keys. Direct using > these methods in IKEv2 might lead to a number of problems > due to the increased size of initial IKEv2 messages. The working group will > analyze the possible problems and develop a solution, that will > make adding Postquantum key exchange methods more easy. > > Regards, > Valery. > > >> We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our >> main agenda item will be the rechartering text, i.e., our charter will >> expire by the end of year, and we have most of our chartered work >> already completed, or almost finished, so we need to decide what new >> items (if any) we take to our charter, or wheter we shut down the WG. >> >> In last IETF we had people with items which we could add to charter, >> so I want those people wanting to add things to charter to send an >> email to the mailing list about what items they would like to propose >> to the charter, and preliminary charter text for the item. >> >> If we do not receive any proposed charter texts, then I assume we do >> not have any more work to do after we finish our current charter... >> >> Also if there is people wanting to present anything in the next >> IPsecME IETF session, send email to wg chairs ipsecme-chairs@ietf.org. >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Oct 27 09:36:49 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4074E13F3FF for ; Fri, 27 Oct 2017 09:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPnH_-Ehockz for ; Fri, 27 Oct 2017 09:36:44 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC64213F3EF for ; Fri, 27 Oct 2017 09:36:43 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id 75so8059228lfx.1 for ; Fri, 27 Oct 2017 09:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=t3Y3nhbjp60b3xak1J69x/rxh9IRwPHQ0E31C6d8PAI=; b=YZkDUoAeO8cgGLSbtc7lKINBhSB9/SVVnmGV80GHEb2U6DT8KahZ88CcqHOB/GOwTI CbzLEM8zN5M0eDyPAN8r8cnDxhSklG9mrRmFJ8B3hkV0MOy8pXH1HrhVn4jrn4Cwedpg nvXbRltSQUmcF581ARs+FWhSTkz0mZmFlC6XfVuVE61rEboyXCJ3ERnG0rGbFn9QRTyZ 0nXC40oZu2vWE0oAX32O3uF9W3Mqy884OjfLEYX15QgT+3Zd4I3lHM6PXRM+cTXa6FFz o04piDlR8Xh1a7MzFiq9Eb/3kioOh8ysmWEriox2RzxH5pQ9rYZtzcHdOr9UyCdGheii 3kIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=t3Y3nhbjp60b3xak1J69x/rxh9IRwPHQ0E31C6d8PAI=; b=GXS2lAslOy7JuGq3i2M9AObgentszG3p9RGT/TWYNIUzah8dydh+75JDKKpcBTehrC GMhtxvzasBfEde+k7xgRqqHgPngaR0FKRbuABI6/Lm+Jsv1f/C4rozOMBxQZzgS29k8y n2MyiIL5oWUvx1Yrk+xZX2ZvYHwld1ejCBy8PyjypfZEJDfNCeOBN0UBLaPWBD9h+Dhq K7YchOvpNciyfsOGjAD0zsGl+VtCyOOT/uxIuVn75F47wtnp6MFV7qDzMHYSFH2m+0nD K21OxigGX7wQL9N0/rk7plc2Z26E0t5LSz9CjvAbBuQB2ldCa3Aj38nXlFWGKUxf2dAD rwXA== X-Gm-Message-State: AMCzsaXdisrsaNW5CvqdkTsK7RsdSCbt1vJkjBYSerZX/+g5N9uFgzzA LT+WuEmHvBkk2YKlDkHlJTFtuMsrHYTfBWOdAis= X-Google-Smtp-Source: ABhQp+Ri48VypQWNodGsmpOq6ihg8iYuwixryJOxHTKCa/mD/lLRw+6SzJ0HXvS/Lo0MMImOFVXL1s1Syr6yvgzmJ+Y= X-Received: by 10.25.170.138 with SMTP id t132mr389269lfe.88.1509122202046; Fri, 27 Oct 2017 09:36:42 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.68.29 with HTTP; Fri, 27 Oct 2017 09:36:41 -0700 (PDT) In-Reply-To: <23027.20765.436882.134002@fireball.acr.fi> References: <23027.20765.436882.134002@fireball.acr.fi> From: Daniel Migault Date: Fri, 27 Oct 2017 12:36:41 -0400 X-Google-Sender-Auth: LcVV2dF8ipRVwlhWBPPUzQ4vEoM Message-ID: To: Tero Kivinen Cc: "Waltermire, David A. (Fed)" , IPsecME WG Content-Type: multipart/alternative; boundary="001a11411c3cc696e1055c89e469" Archived-At: Subject: Re: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 16:36:46 -0000 --001a11411c3cc696e1055c89e469 Content-Type: text/plain; charset="UTF-8" Hi Tero, Thanks for the review, It should be easy to fix. Yours, Daniel On Fri, Oct 27, 2017 at 11:30 AM, Tero Kivinen wrote: > Waltermire, David A. (Fed) writes: > > This message starts a Working Group Last Call (WGLC) for > > draft-mglt-ipsecme-implicit-iv-04. > > > > The version to be reviewed can be found here: > > https://www.ietf.org/id/draft-mglt-ipsecme-implicit-iv-04.txt. > > > > Please send your comments, questions, and edit proposals to the WG > > mail list until November 9th, 2017. If you believe that the > > document is ready to be submitted to the IESG for consideration as a > > Standards Track RFC please send a short message stating this. > > > > > In section 8, fix the spelling of the ENCR_AES-CCM_8_IIV and similar > so that they do not use "-", but only "_" (or otherwise be ready to > face the wrath of the angry implementor in next IETF). I.e. > > - ENCR_AES_CCM_8_IIV > > - ENCR_AES_GCM_16_IIV > > - ENCR_CHACHA20_POLY1305_IIV > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a11411c3cc696e1055c89e469 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tero,

Thanks fo= r the review, It should be easy to fix.
Yours,
Daniel

On Fri, O= ct 27, 2017 at 11:30 AM, Tero Kivinen <kivinen@iki.fi> wrote:
Waltermire, David A. (Fed= ) writes:
> This message starts a Working Group Last Call (WGLC) for
> draft-mglt-ipsecme-implicit-iv-04.
>
> The version to be reviewed can be found here:
> https://www.ietf.org/id/draft-mglt-ipsecme-implicit-iv-04.txt.
>
> Please send your comments, questions, and edit proposals to the WG
> mail list until November 9th, 2017.=C2=A0 If you believe that the
> document is ready to be submitted to the IESG for consideration as a > Standards Track RFC please send a short message stating this.

<chair hat off>
<iana expert hat on>

In section 8, fix the spelling of the ENCR_AES-CCM_8_IIV and similar
so that they do not use "-", but only "_" (or otherwise= be ready to
face the wrath of the angry implementor in next IETF). I.e.

=C2=A0 =C2=A0-=C2=A0 ENCR_AES_CCM_8_IIV

=C2=A0 =C2=A0-=C2=A0 ENCR_AES_GCM_16_IIV

=C2=A0 =C2=A0-=C2=A0 ENCR_CHACHA20_POLY1305_IIV
--
kivinen@iki.fi

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

--001a11411c3cc696e1055c89e469-- From nobody Fri Oct 27 12:44:45 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA5B139553; Fri, 27 Oct 2017 12:44:44 -0700 (PDT) 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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150913348413.22291.2458443283789570152@ietfa.amsl.com> Date: Fri, 27 Oct 2017 12:44:44 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 19:44:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) Author : Yoav Nir Filename : draft-ietf-ipsecme-eddsa-04.txt Pages : 5 Date : 2017-10-27 Abstract: This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-eddsa-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-eddsa-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 27 13:59:43 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF413836A for ; Fri, 27 Oct 2017 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 VjnKL9imJuhu for ; Fri, 27 Oct 2017 13:59:39 -0700 (PDT) Received: from mo6.mail.sc.edu (mo6.mail.sc.edu [129.252.158.30]) (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 4D25F13871A for ; Fri, 27 Oct 2017 13:59:39 -0700 (PDT) Received: from mo6.mail.sc.edu (127.0.0.1) id huef3m0171s0 for ; Fri, 27 Oct 2017 16:59:38 -0400 (envelope-from ) Received: from CAE145HUBP01.ds.sc.edu ([172.27.7.168]) by mo6.mail.sc.edu (SonicWALL 8.2.1.4973) with ESMTPS (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256) id 201710272059380522926; Fri, 27 Oct 2017 16:59:38 -0400 Received: from CAE145EMBP02.ds.sc.edu ([fe80::bc67:c4b6:7a3c:50a0]) by CAE145HUBP01.ds.sc.edu ([::1]) with mapi id 14.03.0339.000; Fri, 27 Oct 2017 16:59:22 -0400 From: "LUO, LANNAN" To: "ipsec@ietf.org" Thread-Topic: IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) Thread-Index: AQHTTN4tHq1UdrQ9G0Gy7sJzFTVFw6LzIt5DgAAA0teAAABrVIAAAMAzgABdBVeAAABc4YAAAEBfgAAAIq+AAAD044AAABahgAAAJyuAAAAr+4AAAFE3gAAAR1eAAABgz4AAAJSRgAABVYuAAAItpYAAAEH7gAAA1m2AAAQOAYAAAC0BgAAAWg2AAADW4YAAAD8FgAAANaeAAC1EMoAD+M0lgAAD3ZyAAAMbj4AAAurmgAAEig6AAATnpoAAAB98gAAIx8WAAAHMFIAAJon2gAA4f1I= Date: Fri, 27 Oct 2017 20:59:20 +0000 Message-ID: References: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.7.4] Content-Type: multipart/alternative; boundary="_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA15B5CAE145EMBP02dss_" MIME-Version: 1.0 X-Mlf-Version: 8.2.1.4973 X-Mlf-UniqueId: o201710272059380522926 Archived-At: Subject: [IPsec] IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:59:42 -0000 --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA15B5CAE145EMBP02dss_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [Apologies, if you receive multiple copies of this CFP] CALL FOR PAPERS IEEE CNS 2018 IEEE Conference on Communications and Network Security Beijing, China, May 30-June 1, 2018 URL: http://cns2018.ieee-cns.org/ IEEE Communications Society Core Conference PAPER SUBMISSION DEADLINE December 20, 2017 ***************************************************************************= ********* IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, polic= y makers, and users to exchange ideas, techniques and tools, raise awarenes= s, and share experience related to all practical and theoretical aspects of= cybersecurity. Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the= network layer to the variety of applications reliant on a secure communica= tion substrate. TOPICS OF INTERESTS -------------------------------- * Anonymity and privacy technologies * Computer and network forensics * Cyber deterrence strategies * Game-theoretic security technologies * Implementation and evaluation of networked security systems * Information-theoretic security * Intrusion detection, prevention, and response * Key management, public key infrastructures, certification, revocation, an= d authentication * Malware detection and mitigation * Security metrics and models * Physical-layer and cross-layer security technologies * Security and privacy for big data * Security and privacy for data and network outsourcing services * Security and privacy for mobile and wearable devices * Security and privacy in cellular networks * Security and privacy in cloud and edge computing * Security and privacy in crowdsourcing * Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) * Security and privacy in peer-to-peer and overlay networks * Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks * Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems * Security for critical infrastructures (smart grids, transportation system= s, etc.) * Security for future Internet architectures and designs * Security for software-defined and data center networks * Social, economic, and policy issues of trust, security, and privacy * Traffic analysis * Usable security and privacy * Web, e-commerce, m-commerce, and e-mail security IMPORTANT DATES --------------------------- Paper Submission Deadline: December 20, 2017 Notification of Acceptance: February 27, 2018 Final Paper Submission: March 19, 2018 CONFERENCE CHAIRS ------------------------------- General Chair: Jiwu Jing (Chinese Academy of Sciences, PR China) Program Chairs: Loukas Lazos (University of Arizona, USA) Peng Liu (Pennsylvania State University, USA) TECHNICAL PROGRAM COMMITTEE ---------------------------------------------------- See: http://cns2018.ieee-cns.org/ --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA15B5CAE145EMBP02dss_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
[Apologies, if you receive multipl= e copies of this CFP]

          &nbs= p;               CALL FOR PAPERS  <= /span>
 
            &nb= sp;            =   IEEE CNS 2018          =
 
           IEEE Conferenc= e on Communications and Network Security 
            &nb= sp;         Beijing, China, May 30-= June 1, 2018 
            &nb= sp;         URL: http://cns2018.ieee-cns= .org/ 
            &nb= sp;            =     
            &nb= sp;     IEEE Communications Society Core Conference&nbs= p;
 
            &nb= sp;     PAPER SUBMISSION DEADLINE December 20, 2017&nbs= p;
 
***************************************************************************= ********* 
IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, policy makers, and users to exchange = ideas, techniques and tools, raise awareness, and share experience related = to all practical and theoretical aspects of cybersecurity. 
 
Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the network layer to the variety of a= pplications reliant on a secure communication substrate.  
 
TOPICS OF INTERESTS 
-------------------------------- 
* Anonymity and privacy technologies 
* Computer and network forensics 
* Cyber deterrence strategies 
* Game-theoretic security technologies 
* Implementation and evaluation of networked security systems 
* Information-theoretic security 
* Intrusion detection, prevention, and response 
* Key management, public key infrastructures, certification, revocation, an= d authentication 
* Malware detection and mitigation 
* Security metrics and models 
* Physical-layer and cross-layer security technologies 
* Security and privacy for big data 
* Security and privacy for data and network outsourcing services 
* Security and privacy for mobile and wearable devices 
* Security and privacy in cellular networks 
* Security and privacy in cloud and edge computing 
* Security and privacy in crowdsourcing 
* Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) 
* Security and privacy in peer-to-peer and overlay networks 
* Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks 
* Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems 
* Security for critical infrastructures (smart grids, transportation system= s, etc.) 
* Security for future Internet architectures and designs 
* Security for software-defined and data center networks 
* Social, economic, and policy issues of trust, security, and privacy =  
* Traffic analysis  
* Usable security and privacy  
* Web, e-commerce, m-commerce, and e-mail security   
 
 
IMPORTANT DATES 
--------------------------- 
Paper Submission Deadline: December 20, 2017 
Notification of Acceptance: February 27, 2018 
Final Paper Submission: March 19, 2018  
 
 
CONFERENCE CHAIRS  
------------------------------- 
General Chair:  
Jiwu Jing (Chinese Academy of Sciences, PR China)  
 
Program Chairs:  
Loukas Lazos (University of Arizona, USA) 
Peng Liu (Pennsylvania State University, USA) 
 
 
TECHNICAL PROGRAM COMMITTEE 
---------------------------------------------------- 
See: http://cns2018.ieee-cns.org/
 
--_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA15B5CAE145EMBP02dss_-- From nobody Fri Oct 27 15:13:45 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524AC13F5A9 for ; Fri, 27 Oct 2017 15:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7GNzd1HEW-G for ; Fri, 27 Oct 2017 15:13:41 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193E413F5EA for ; Fri, 27 Oct 2017 15:13:41 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id a69so8849377lfe.5 for ; Fri, 27 Oct 2017 15:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jJXLVM+IQfzeBZNrDW/x0eoauDifim+R5pnq15AwRls=; b=Ig99tyJxSP1wPC31KEdpJW6tdH2xHZMW4BsxHSwAQUP8XZ9yTws5t1/STksO1NftkF nA9noxexbCaELuRDBnqEtiD7DPmGc9i8vAk7Viwmaz0wVAGBOsF4m68cDYjS6n2JXB5+ dulaetrGwUTl/T8HyeuKsTbZwGvPrgWdbrCD3ZGC//kv6R1l4JYqx7rVgiZ/7p/JoygB JcSCFibSZBIm9tt2TXNM+G6aEsPL7K3p/2ttxJXTgAF+lx/HSoNZ7xaD0FNEag+bAkDY V1xaRS5wnz4lmXn0I9OD6KfPhJJUbsJ+uyq6J+X0pWY3Kdt9qyuKTMMfqhat8FLLnlKx BBBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jJXLVM+IQfzeBZNrDW/x0eoauDifim+R5pnq15AwRls=; b=Ud+gERmIKGZjjLy31BeiQN+InUjM/xUaNXCfl3wTSw3ojhZlsjOCrxe59W6YS8PO1C XgWKDyCBCXR2cZsNd6BTbpIP0LI3d+MYifI7sGUpO+ch1UUZ2KE4Ce+XRAEuagBdZo3f krfEduUVl9effjuxxa8gXRVtHUz5FNh7ZA0rgKvaQHk9cEL/brC02d8La+Nzdd2mUqEM XjrOdg3KM/M0Z20G5X9JAK5r70FvOarCEIsOjY4+wrM2mwMERF1MQKTylrGdmUJvXNCy WuSPawb8QXsT2zeQlp14CvnimJHsppBx0CpVHXxx2V4A2GAcAsLngOJRuh8Tns4+FMMJ ObaA== X-Gm-Message-State: AMCzsaUIolhWUGIRP/2BwEdToM2KttQXfqqACaua8a+2XMWLRgA4Eb7Q QL/8xKehoHgoFqTb0eIh3Mpi5aQCjXUlg1ZAMrY= X-Google-Smtp-Source: ABhQp+QG1IqsIIDxxNhUG3xW1KUEl/E+cxH/v8lGSRGIAVSyKakBHcoGQ/USMVnCBi0byv9xmmmba6IkIqmtYI7wMA0= X-Received: by 10.46.86.139 with SMTP id k11mr802035lje.103.1509142419412; Fri, 27 Oct 2017 15:13:39 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.68.29 with HTTP; Fri, 27 Oct 2017 15:13:38 -0700 (PDT) In-Reply-To: <32759AD8-5A82-4218-AED7-9A2EE7F6B252@apple.com> References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <32759AD8-5A82-4218-AED7-9A2EE7F6B252@apple.com> From: Daniel Migault Date: Fri, 27 Oct 2017 18:13:38 -0400 X-Google-Sender-Auth: yLkLtOoFQQ-oSB__Mhir2RMR_kc Message-ID: To: Tommy Pauly Cc: Valery Smyslov , IPsecME WG , Tero Kivinen Content-Type: multipart/alternative; boundary="94eb2c1a6802d31bd2055c8e995b" Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 22:13:44 -0000 --94eb2c1a6802d31bd2055c8e995b Content-Type: text/plain; charset="UTF-8" We support the proposals and will publish updated the documents regarding diet-esp and its associated IKEv2 extension. We believe draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a good starting point. The proposed text for the charter could be: A growing number of use cases for constraint network - but not limited to - have shown interest in reducing ESP overhead by compressing ESP fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-extention are expected to be good starting points. Yours, Daniel On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly wrote: > + 1 to these proposals > > I'd also like to see the work on drafts like DIET-ESP > (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have some > growing use cases for IPsec in constrained networks, and as that develops, > extensions and modifications to the protocol to make IKEv2 and ESP work > efficiently in those conditions will be necessary. (These would likely fall > into the host-to-host use case described in the charter.) > > Thanks, > Tommy > > > On Oct 27, 2017, at 7:51 AM, Valery Smyslov wrote: > > > > Hi, > > > > I think that the following items can be considered for the new charter. > > > > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible > charter text: > > > > MOBIKE protocol [RFC4555] is used to move existing > > IKE/IPsec SA from one IP address to another. However, > > in MOBIKE it is the initiator of the IKE SA (i.e. remote access > client) > > that controls this process. If there are several responders > > each having own IP address and acting together as a load sharing > cluster, > > then it is desirable for them to have ability to request initiator > to switch to > > a particular member. The working group will analyze the > possibility > > to extend MOBIKE protocol or to develop new IKE extension > > that will allow to build load sharing clusters in an interoperable > way. > > > > 2. Make IKEv2 Postquantum Cryptography ready. In particular - make it > > able to transfer large payloads in initial exchange without having > > IP fragmentation issues. The possible charter text: > > > > Postquantum Cryptography brings new key exchange methods. > > Most of these methods that are known to date have much larger > public > > keys then conventional Diffie-Hellman public keys. Direct using > > these methods in IKEv2 might lead to a number of problems > > due to the increased size of initial IKEv2 messages. The working > group will > > analyze the possible problems and develop a solution, that will > > make adding Postquantum key exchange methods more easy. > > > > Regards, > > Valery. > > > > > >> We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our > >> main agenda item will be the rechartering text, i.e., our charter will > >> expire by the end of year, and we have most of our chartered work > >> already completed, or almost finished, so we need to decide what new > >> items (if any) we take to our charter, or wheter we shut down the WG. > >> > >> In last IETF we had people with items which we could add to charter, > >> so I want those people wanting to add things to charter to send an > >> email to the mailing list about what items they would like to propose > >> to the charter, and preliminary charter text for the item. > >> > >> If we do not receive any proposed charter texts, then I assume we do > >> not have any more work to do after we finish our current charter... > >> > >> Also if there is people wanting to present anything in the next > >> IPsecME IETF session, send email to wg chairs ipsecme-chairs@ietf.org. > >> -- > >> kivinen@iki.fi > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --94eb2c1a6802d31bd2055c8e995b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We support the proposals and will publ= ish updated the documents regarding diet-esp and its associated IKEv2 exten= sion. We believe=C2=A0 draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-= extention could be a good starting point.

The proposed text f= or the charter could be:
A growing number of use cases for constra= int network - but not limited to - have shown interest in reducing ESP over= head by compressing =20 =20 ESP fields. The WG will define extensions of ESP and IKEv2 to enabl= e ESP header compression.=C2=A0

draft-mglt-ipsecme-diet-esp and dra= ft-mglt-ipsecme-ikev2-extention are expected to be good starting points.
Yours,
Daniel



On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly <tpauly@apple.com>= ; wrote:
+ 1 to these proposals
I'd also like to see the work on drafts like DIET-ESP (draft-mglt-ipsec= me-diet-esp-04) be incorporated. I think we'll have some growing u= se cases for IPsec in constrained networks, and as that develops, extension= s and modifications to the protocol to make IKEv2 and ESP work efficiently = in those conditions will be necessary. (These would likely fall into the ho= st-to-host use case described in the charter.)

Thanks,
Tommy

> On Oct 27, 2017, at 7:51 AM, Valery Smyslov <svanru@gmail.com> wrote:
>
> Hi,
>
> I think that the following items can be considered for the new charter= .
>
> 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible= charter text:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MOBIKE protocol [RFC4555] is used to move ex= isting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0IKE/IPsec SA from one IP address to another.= However,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in MOBIKE it is the initiator of the IKE SA = (i.e. remote access client)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that controls this process. If there are sev= eral responders
>=C2=A0 =C2=A0 =C2=A0 =C2=A0each having own IP address and acting togeth= er as a load sharing cluster,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0then it is desirable for them to have abilit= y to request initiator to switch to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a particular=C2=A0 =C2=A0 member. The workin= g group will analyze the possibility
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to extend MOBIKE protocol or to develop new = IKE extension
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that will allow to build load sharing cluste= rs in an interoperable way.
>
> 2. Make IKEv2 Postquantum Cryptography ready. In particular - make it<= br> >=C2=A0 =C2=A0 able to transfer large payloads in initial exchange witho= ut having
>=C2=A0 =C2=A0 IP fragmentation issues. The possible charter text:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Postquantum Cryptography brings new key exch= ange methods.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Most of these methods that are known to date= have much larger public
>=C2=A0 =C2=A0 =C2=A0 =C2=A0keys then conventional Diffie-Hellman public= keys. Direct using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0these methods in IKEv2 might lead to a numbe= r of problems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0due to the increased size of initial IKEv2 m= essages. The working group will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0analyze the possible problems and develop a = solution, that will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0make adding Postquantum key exchange methods= more easy.
>
> Regards,
> Valery.
>
>
>> We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Ou= r
>> main agenda item will be the rechartering text, i.e., our charter = will
>> expire by the end of year, and we have most of our chartered work<= br> >> already completed, or almost finished, so we need to decide what n= ew
>> items (if any) we take to our charter, or wheter we shut down the = WG.
>>
>> In last IETF we had people with items which we could add to charte= r,
>> so I want those people wanting to add things to charter to send an=
>> email to the mailing list about what items they would like to prop= ose
>> to the charter, and preliminary charter text for the item.
>>
>> If we do not receive any proposed charter texts, then I assume we = do
>> not have any more work to do after we finish our current charter..= .
>>
>> Also if there is people wanting to present anything in the next >> IPsecME IETF session, send email to wg chairs ipsecme-chairs@ietf.org.
>> --
>> kivinen@iki.fi
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec=
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec=

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

--94eb2c1a6802d31bd2055c8e995b-- From nobody Fri Oct 27 16:05:09 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323AB1397F3 for ; Fri, 27 Oct 2017 16:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYJiWLHNNBY5 for ; Fri, 27 Oct 2017 16:05:06 -0700 (PDT) Received: from sleekfreak.ath.cx (rrcs-67-79-182-226.se.biz.rr.com [67.79.182.226]) (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 29D4613F46E for ; Fri, 27 Oct 2017 16:05:06 -0700 (PDT) Received: from shogunx (helo=localhost) by sleekfreak.ath.cx with local-esmtp (Exim 4.89) (envelope-from ) id 1e8DgV-0002SP-SA for ipsec@ietf.org; Fri, 27 Oct 2017 19:05:04 -0400 Date: Fri, 27 Oct 2017 19:05:03 -0400 (EDT) From: shogunx@sleekfreak.ath.cx To: IPsecME WG In-Reply-To: Message-ID: References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <32759AD8-5A82-4218-AED7-9A2EE7F6B252@apple.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1329849014-1663553120-1509145504=:22001" Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 23:05:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1329849014-1663553120-1509145504=:22001 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Don't forget to add this as a BoF: https://www.youtube.com/watch?v=FoUWHfh733Y :) X On Fri, 27 Oct 2017, Daniel Migault wrote: > We support the proposals and will publish updated the documents regarding > diet-esp and its associated IKEv2 extension. We believe  > draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a > good starting point. > > The proposed text for the charter could be: > A growing number of use cases for constraint network - but not limited to - > have shown interest in reducing ESP overhead by compressing ESP fields. The > WG will define extensions of ESP and IKEv2 to enable ESP header > compression.  > > draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-extention are > expected to be good starting points. > > Yours, > Daniel > > > > On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly wrote: > + 1 to these proposals > > I'd also like to see the work on drafts like DIET-ESP > (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll > have some growing use cases for IPsec in constrained networks, > and as that develops, extensions and modifications to the > protocol to make IKEv2 and ESP work efficiently in those > conditions will be necessary. (These would likely fall into the > host-to-host use case described in the charter.) > > Thanks, > Tommy > > > On Oct 27, 2017, at 7:51 AM, Valery Smyslov > wrote: > > > > Hi, > > > > I think that the following items can be considered for the new > charter. > > > > 1. Develop load sharing cluster solution for IKEv2/IPsec. The > possible charter text: > > > >       MOBIKE protocol [RFC4555] is used to move existing > >       IKE/IPsec SA from one IP address to another. However, > >       in MOBIKE it is the initiator of the IKE SA (i.e. remote > access client) > >       that controls this process. If there are several > responders > >       each having own IP address and acting together as a load > sharing cluster, > >       then it is desirable for them to have ability to request > initiator to switch to > >       a particular    member. The working group will analyze > the possibility > >       to extend MOBIKE protocol or to develop new IKE > extension > >       that will allow to build load sharing clusters in an > interoperable way. > > > > 2. Make IKEv2 Postquantum Cryptography ready. In particular - > make it > >    able to transfer large payloads in initial exchange without > having > >    IP fragmentation issues. The possible charter text: > > > >       Postquantum Cryptography brings new key exchange > methods. > >       Most of these methods that are known to date have much > larger public > >       keys then conventional Diffie-Hellman public keys. > Direct using > >       these methods in IKEv2 might lead to a number of > problems > >       due to the increased size of initial IKEv2 messages. The > working group will > >       analyze the possible problems and develop a solution, > that will > >       make adding Postquantum key exchange methods more easy. > > > > Regards, > > Valery. > > > > > >> We will be meeting at Monday morning 09:30-11:00 for 1.5 > hours. Our > >> main agenda item will be the rechartering text, i.e., our > charter will > >> expire by the end of year, and we have most of our chartered > work > >> already completed, or almost finished, so we need to decide > what new > >> items (if any) we take to our charter, or wheter we shut down > the WG. > >> > >> In last IETF we had people with items which we could add to > charter, > >> so I want those people wanting to add things to charter to > send an > >> email to the mailing list about what items they would like to > propose > >> to the charter, and preliminary charter text for the item. > >> > >> If we do not receive any proposed charter texts, then I > assume we do > >> not have any more work to do after we finish our current > charter... > >> > >> Also if there is people wanting to present anything in the > next > >> IPsecME IETF session, send email to wg chairs > ipsecme-chairs@ietf.org. > >> -- > >> kivinen@iki.fi > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > --1329849014-1663553120-1509145504=:22001-- From nobody Sat Oct 28 02:07:55 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8CA13F738 for ; Sat, 28 Oct 2017 02:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 qsSRDO1vi6Dm for ; Sat, 28 Oct 2017 02:07:53 -0700 (PDT) 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 72F05138FA0 for ; Sat, 28 Oct 2017 02:07:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yPFJQ2LhWz3JT; Sat, 28 Oct 2017 11:07:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509181670; bh=o6YzAVp6/X3ulaqJ3DRG0gXV/CN3Quya2wNrYgy9Ta0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RbZWCVokmGITjjsJ6w/z9Aa8ykV00cx1vTx8/nVByh2HVxMjjMJQE/6K0IMnAzCC1 GXwINj3JsCZo6A+UoGdqwTGAOqJXCstQITWkyEZv69NGCxRnOJqHvdetuQFKlGOv24 7Ac/oYryn9365b+Ggk9HJGcmZrA/b1waODL6Xct8= 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 t0eCH95JUEkp; Sat, 28 Oct 2017 11:07:49 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Oct 2017 11:07:49 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 64D5462D29; Sat, 28 Oct 2017 05:07:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 64D5462D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4DD0E40D35AF; Sat, 28 Oct 2017 05:07:48 -0400 (EDT) Date: Sat, 28 Oct 2017 05:07:48 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23026.13858.483048.716056@fireball.acr.fi> Message-ID: References: <23026.13858.483048.716056@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 09:07:54 -0000 On Thu, 26 Oct 2017, Tero Kivinen wrote: > In last IETF we had people with items which we could add to charter, > so I want those people wanting to add things to charter to send an > email to the mailing list about what items they would like to propose > to the charter, and preliminary charter text for the item. In IKEv1, we have support for Labeled IPsec, which can be used to mark traffic with labels (secret, top secret, etc) across an IPsec connection. Libreswan implements this supporting SElinux labels using a private allocation (after an allocation was stolen and then asisgned to ECN :) We have a need to have an IKEv2 version of Labeled IPsec. Paul From nobody Sat Oct 28 06:14:15 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55131394F5 for ; Sat, 28 Oct 2017 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 7R486dN4rulG for ; Sat, 28 Oct 2017 06:14:10 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2076513AF04 for ; Sat, 28 Oct 2017 06:14:10 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id r129so10073656lff.8 for ; Sat, 28 Oct 2017 06:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:importance; bh=ombgz8/hJPCdjLt5UodrectFvYY6jT9wA+Slo2ZFFXA=; b=rMRgyVlQHNFbRhYKJGK5lTCCRJFQB5aLdRtYfdgQg+RnK7MjhJhIHTfpJdTwbNg7YC OAhj1sMMF+ifgNdwSLMvCirqBVCp4RDTKG7IkBwPDksNO8+a3sf+rUUKAY9kV0ybh401 y8zMSkMNTP9n8HQI6fCk4mUQfeakpcQ7mb69qVcADYGLtNZcFzgUhO58yqepg9TWLhjG +FEQnNZ/GHh4iO1ja3TiFfThMDJuTqxpSzbjB1UVQCQZSZUb0ZrVRNlWn74Zr+hQe4v2 wRNBh7mQZzhOOPBlKdCwWtKTbwh4U/qaIPyah2LVjMPSTgTDPVtnRvO4D0RIQJSZQSEU 1h6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:importance; bh=ombgz8/hJPCdjLt5UodrectFvYY6jT9wA+Slo2ZFFXA=; b=GVER42AGPrFE9VcWQ56S9pxt8plv2Gj4IAoGB/MwEuI+xVPlVTaC5o4MnQ/TzHBjJM gAmKsJypX8PNca7VlpvZXLmHTcXh5KfoU30YE4mh3TSyVbLHaZ9bNOEWmwq3QWCglUtA LRWOnm3bIBZSXRquPWC/3+zl1goAYtywGEVIeyRFxGvbI4uQeE7LFhePiRhtGKIphekj wfEdJGA6DVQ1/ACJJxTqhpfdP/nYB+pFOytbfCWBaM0EuNqNMVffO/xENAsWUk+RBwNH 7YWag8pYItJPHcHvrTSDUajL09ApdeWdTqRadgU7g9Ljx5WFUxoznK2hdWZBNCj2z1bF WjRg== X-Gm-Message-State: AMCzsaU4zENh4MRCAttSA86wkFEGzKkr4z4hd5kEKh2eTXGhAuCpVm79 7BTFStPv2LFZxnhnVNS6cfs= X-Google-Smtp-Source: ABhQp+SUlvdc0j25qAkcT0CqU+/b4gPB/i+n7VtdCwP5nZvYVJ0Ep3sk/jfcuuI5DerowTaLgPrlag== X-Received: by 10.46.65.14 with SMTP id o14mr1451000lja.172.1509196448412; Sat, 28 Oct 2017 06:14:08 -0700 (PDT) Received: from chichi (ppp83-237-172-195.pppoe.mtu-net.ru. [83.237.172.195]) by smtp.gmail.com with ESMTPSA id w9sm2478519ljw.49.2017.10.28.06.14.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 Oct 2017 06:14:07 -0700 (PDT) Message-ID: <02D4DFF8799748AC8F38AC0947673B46@chichi> From: "Valery Smyslov" To: "Daniel Migault" , "Tommy Pauly" Cc: "IPsecME WG" , "Tero Kivinen" References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <32759AD8-5A82-4218-AED7-9A2EE7F6B252@apple.com> In-Reply-To: Date: Sat, 28 Oct 2017 16:13:57 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01D35007.C21C8B00" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 13:14:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0053_01D35007.C21C8B00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, probably we need to consider Diet-IKE too? Aa companion for Diet-ESP. And what is draft-ipsecme-ikev2-extention? I cannot find such a draft... Regards, Valery. =20 We support the proposals and will publish updated the documents = regarding diet-esp and its associated IKEv2 extension. We believe = draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a = good starting point.=20 The proposed text for the charter could be: A growing number of use cases for constraint network - but not limited = to - have shown interest in reducing ESP overhead by compressing ESP = fields. The WG will define extensions of ESP and IKEv2 to enable ESP = header compression. =20 draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-extention are = expected to be good starting points.=20 Yours,=20 Daniel On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly wrote: + 1 to these proposals I'd also like to see the work on drafts like DIET-ESP = (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have = some growing use cases for IPsec in constrained networks, and as that = develops, extensions and modifications to the protocol to make IKEv2 and = ESP work efficiently in those conditions will be necessary. (These would = likely fall into the host-to-host use case described in the charter.) Thanks, Tommy > On Oct 27, 2017, at 7:51 AM, Valery Smyslov = wrote: > > Hi, > > I think that the following items can be considered for the new = charter. > > 1. Develop load sharing cluster solution for IKEv2/IPsec. The = possible charter text: > > MOBIKE protocol [RFC4555] is used to move existing > IKE/IPsec SA from one IP address to another. However, > in MOBIKE it is the initiator of the IKE SA (i.e. remote = access client) > that controls this process. If there are several responders > each having own IP address and acting together as a load = sharing cluster, > then it is desirable for them to have ability to request = initiator to switch to > a particular member. The working group will analyze the = possibility > to extend MOBIKE protocol or to develop new IKE extension > that will allow to build load sharing clusters in an = interoperable way. > > 2. Make IKEv2 Postquantum Cryptography ready. In particular - make = it > able to transfer large payloads in initial exchange without = having > IP fragmentation issues. The possible charter text: > > Postquantum Cryptography brings new key exchange methods. > Most of these methods that are known to date have much larger = public > keys then conventional Diffie-Hellman public keys. Direct = using > these methods in IKEv2 might lead to a number of problems > due to the increased size of initial IKEv2 messages. The = working group will > analyze the possible problems and develop a solution, that = will > make adding Postquantum key exchange methods more easy. > > Regards, > Valery. > > >> We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our >> main agenda item will be the rechartering text, i.e., our charter = will >> expire by the end of year, and we have most of our chartered work >> already completed, or almost finished, so we need to decide what = new >> items (if any) we take to our charter, or wheter we shut down the = WG. >> >> In last IETF we had people with items which we could add to = charter, >> so I want those people wanting to add things to charter to send an >> email to the mailing list about what items they would like to = propose >> to the charter, and preliminary charter text for the item. >> >> If we do not receive any proposed charter texts, then I assume we = do >> not have any more work to do after we finish our current charter... >> >> Also if there is people wanting to present anything in the next >> IPsecME IETF session, send email to wg chairs = ipsecme-chairs@ietf.org. >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0053_01D35007.C21C8B00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi=20 Daniel,
 
probably=20 we need to consider Diet-IKE too? Aa companion for Diet-ESP.
 
And=20 what is draft-ipsecme-ikev2-extention? I cannot find such a = draft...
 
Regards,
Valery.
 
We support the proposals and will publish updated the documents = regarding=20 diet-esp and its associated IKEv2 extension. We believe =20 draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a = good=20 starting point.

The proposed text for the charter could=20 be:
A growing number of use cases for constraint network - but = not=20 limited to - have shown interest in reducing ESP overhead by compressing = ESP=20 fields. The WG will define extensions of ESP and IKEv2 to enable ESP = header=20 compression. 

draft-mglt-ipsecme-diet-esp and=20 draft-mglt-ipsecme-ikev2-extention are expected to be good starting = points.=20

Yours,
Daniel


 
On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly = <tpauly@apple.com> wrote:
+=20 1 to these proposals

I'd also like to see the work on drafts = like=20 DIET-ESP (draft-mglt-ipsecme-diet-esp-04) be incorporated. I = think we'll=20 have some growing use cases for IPsec in constrained networks, and as = that=20 develops, extensions and modifications to the protocol to make IKEv2 = and ESP=20 work efficiently in those conditions will be necessary. (These would = likely=20 fall into the host-to-host use case described in the=20 charter.)

Thanks,
Tommy

> On Oct 27, 2017, at 7:51 AM, Valery Smyslov = <svanru@gmail.com> = wrote:
>
>=20 Hi,
>
> I think that the following items can be considered = for the=20 new charter.
>
> 1. Develop load sharing cluster solution = for=20 IKEv2/IPsec. The possible charter=20 text:
>
>       MOBIKE = protocol=20 [RFC4555] is used to move = existing
>      =20 IKE/IPsec SA from one IP address to another.=20 However,
>       in MOBIKE it is = the=20 initiator of the IKE SA (i.e. remote access=20 client)
>       that controls this = process. If there are several=20 responders
>       each having own = IP=20 address and acting together as a load sharing=20 cluster,
>       then it is = desirable for=20 them to have ability to request initiator to switch=20 to
>       a = particular   =20 member. The working group will analyze the=20 possibility
>       to extend = MOBIKE=20 protocol or to develop new IKE=20 extension
>       that will allow = to build=20 load sharing clusters in an interoperable way.
>
> 2. Make = IKEv2=20 Postquantum Cryptography ready. In particular - make=20 it
>    able to transfer large payloads in = initial=20 exchange without having
>    IP fragmentation = issues. The=20 possible charter = text:
>
>      =20 Postquantum Cryptography brings new key exchange=20 methods.
>       Most of these = methods=20 that are known to date have much larger=20 public
>       keys then = conventional=20 Diffie-Hellman public keys. Direct=20 using
>       these methods in = IKEv2 might=20 lead to a number of = problems
>       due=20 to the increased size of initial IKEv2 messages. The working group=20 will
>       analyze the possible = problems=20 and develop a solution, that = will
>      =20 make adding Postquantum key exchange methods more = easy.
>
>=20 Regards,
> Valery.
>
>
>> We will be = meeting at=20 Monday morning 09:30-11:00 for 1.5 hours. Our
>> main agenda = item=20 will be the rechartering text, i.e., our charter will
>> = expire by=20 the end of year, and we have most of our chartered work
>> = already=20 completed, or almost finished, so we need to decide what = new
>> items=20 (if any) we take to our charter, or wheter we shut down the=20 WG.
>>
>> In last IETF we had people with items = which we=20 could add to charter,
>> so I want those people wanting to = add things=20 to charter to send an
>> email to the mailing list about what = items=20 they would like to propose
>> to the charter, and preliminary = charter=20 text for the item.
>>
>> If we do not receive any = proposed=20 charter texts, then I assume we do
>> not have any more work = to do=20 after we finish our current charter...
>>
>> Also if = there=20 is people wanting to present anything in the next
>> IPsecME = IETF=20 session, send email to wg chairs ipsecme-chairs@ietf.org.
&= gt;>=20 --
>> kivinen@iki.fi
>>
>>= =20 _______________________________________________
>> IPsec = mailing=20 list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
&= gt;
>=20 _______________________________________________
> IPsec = mailing=20 list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
<= BR>_______________________________________________
IPsec=20 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<= /DIV>
 
------=_NextPart_000_0053_01D35007.C21C8B00-- From nobody Sat Oct 28 09:00:26 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6965F13F609 for ; Sat, 28 Oct 2017 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ozi2XLcD1vH for ; Sat, 28 Oct 2017 09:00:21 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B878F13F58F for ; Sat, 28 Oct 2017 09:00:14 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id a16so10370504lfk.0 for ; Sat, 28 Oct 2017 09:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=j5NuW0REst79TPLSN2+xrAl+9eAIvDK/f0TWqwZHUSA=; b=JMz35PizGH+rQpBCtmDdZg/6R7GWqfeG6/YH0INfNQZJEs4hu/EXbX6SEHhQtmw1OY LaYI9myQkA8FtEeUTvp8iPnv+C85zeZW3PtMHNPaPcY2Cx0dtLdd1fVt3C2r05SFk35F 5phxCioIKG31ktwCHe+Sij1m0lHgLzt8VTOuQ0sEBra4Uq0BGcIaqvIDNWCJnUNavnzq 6NlIGibOyXG3NFO709NETUfeuIDJ7DIKLy/uT1wrgqStScYHiT9XifEUC1rE4ENsvAGJ RcXKseQSVbpdWzYe/EKQgirBgvmUPgYxndded2ZKJe3jT9GzcySDjwSnWf2dpYVI3FA4 jBTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=j5NuW0REst79TPLSN2+xrAl+9eAIvDK/f0TWqwZHUSA=; b=Kq6Dra/wbXjVLv1UnrV0BEP0rgMvxR/XF2EcTShY4RZfkQ7EWyL866APVaDLpPxnlz kYAKCIV42JMrkmb4gICIBU30sWiYEGgg08uTtDnFxEwg9Lo7+T/d7MAdmb7Q0oS+wl4D LWYpaRqNj64dDFU78W6B5gxUV1gisyFudwD79Uv5SXIkmd9pvX9WvGCkPGRm+04AlPWD PeTXe1vQJaLmPjygZVmc9VDYvw+AijlyRnsgFXxIVylUcRcMY7SW4cQs1/vluIroCKJP nV6AJwSjMfWdndv3/anMXb2d1mrkIGsjApIc0ZvKegZ8uFutS47RmOxFwKpdwsTX1L23 Oc6g== X-Gm-Message-State: AMCzsaVkV8J6ifc2roKi8ImNvSrf8+XM38dj6f9opSLzpGpX47c1AwCd lRzy2S1JkXq9ddCDX0QXIpQHVHhsP4FYhBvmd44= X-Google-Smtp-Source: ABhQp+S3LuWsdBXtYVIga2M4VpMZmGzFRHlR+WhckhMO09ftnWxwa9FF2GWJnoC7yya9dWUspoAp2qSbmuaTrwmpaE0= X-Received: by 10.46.22.83 with SMTP id 19mr1447028ljw.147.1509206413037; Sat, 28 Oct 2017 09:00:13 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.68.29 with HTTP; Sat, 28 Oct 2017 09:00:12 -0700 (PDT) In-Reply-To: <02D4DFF8799748AC8F38AC0947673B46@chichi> References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <32759AD8-5A82-4218-AED7-9A2EE7F6B252@apple.com> <02D4DFF8799748AC8F38AC0947673B46@chichi> From: Daniel Migault Date: Sat, 28 Oct 2017 12:00:12 -0400 X-Google-Sender-Auth: I93ysWvGKnmEVVhvN3auovaPSFA Message-ID: To: Valery Smyslov Cc: Tommy Pauly , IPsecME WG , Tero Kivinen Content-Type: multipart/alternative; boundary="f403045fc03e245241055c9d80c4" Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 16:00:25 -0000 --f403045fc03e245241055c9d80c4 Content-Type: text/plain; charset="UTF-8" Hi Valery, Absolutely, Diet-IKE would be a nice item have in the charter as well, but this is a different item. Currently the work on compressing esp has two items: * draft-mglt-ipsecme-diet-esp defines how to esp. * draft-mglt-ipsecme-ikev2-diet-esp-extension defines how peers agree on using diet-esp I see draft-smyslov-ipsecme-ikev2-compression [3] and draft-smyslov-ipsecme-ikev2-compact [4] focused on the compression of ikev2 itself. draft-ipsecme-ikev2-extention was a misspelt name for draft-mglt-ipsecme-ikev2-diet-esp-extension [2]. If we are adding this item the text for the charter should be updated around: OLD: A growing number of use cases for constraint network - but not limited to - have shown interest in reducing ESP overhead by compressing ESP fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points. NEW: A growing number of use cases for constraint network - but not limited to - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression. draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 compression. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/ [3] https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compression/ [4] https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compact/ On Sat, Oct 28, 2017 at 9:13 AM, Valery Smyslov wrote: > Hi Daniel, > > probably we need to consider Diet-IKE too? Aa companion for Diet-ESP. > > And what is draft-ipsecme-ikev2-extention? I cannot find such a draft... > > Regards, > Valery. > > We support the proposals and will publish updated the documents regarding > diet-esp and its associated IKEv2 extension. We believe > draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a > good starting point. > > The proposed text for the charter could be: > A growing number of use cases for constraint network - but not limited to > - have shown interest in reducing ESP overhead by compressing ESP fields. > The WG will define extensions of ESP and IKEv2 to enable ESP header > compression. > > draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-extention are > expected to be good starting points. > > Yours, > Daniel > > > > On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly wrote: > >> + 1 to these proposals >> >> I'd also like to see the work on drafts like DIET-ESP >> (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have >> some growing use cases for IPsec in constrained networks, and as that >> develops, extensions and modifications to the protocol to make IKEv2 and >> ESP work efficiently in those conditions will be necessary. (These would >> likely fall into the host-to-host use case described in the charter.) >> >> Thanks, >> Tommy >> >> > On Oct 27, 2017, at 7:51 AM, Valery Smyslov wrote: >> > >> > Hi, >> > >> > I think that the following items can be considered for the new charter. >> > >> > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible >> charter text: >> > >> > MOBIKE protocol [RFC4555] is used to move existing >> > IKE/IPsec SA from one IP address to another. However, >> > in MOBIKE it is the initiator of the IKE SA (i.e. remote access >> client) >> > that controls this process. If there are several responders >> > each having own IP address and acting together as a load sharing >> cluster, >> > then it is desirable for them to have ability to request >> initiator to switch to >> > a particular member. The working group will analyze the >> possibility >> > to extend MOBIKE protocol or to develop new IKE extension >> > that will allow to build load sharing clusters in an >> interoperable way. >> > >> > 2. Make IKEv2 Postquantum Cryptography ready. In particular - make it >> > able to transfer large payloads in initial exchange without having >> > IP fragmentation issues. The possible charter text: >> > >> > Postquantum Cryptography brings new key exchange methods. >> > Most of these methods that are known to date have much larger >> public >> > keys then conventional Diffie-Hellman public keys. Direct using >> > these methods in IKEv2 might lead to a number of problems >> > due to the increased size of initial IKEv2 messages. The working >> group will >> > analyze the possible problems and develop a solution, that will >> > make adding Postquantum key exchange methods more easy. >> > >> > Regards, >> > Valery. >> > >> > >> >> We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our >> >> main agenda item will be the rechartering text, i.e., our charter will >> >> expire by the end of year, and we have most of our chartered work >> >> already completed, or almost finished, so we need to decide what new >> >> items (if any) we take to our charter, or wheter we shut down the WG. >> >> >> >> In last IETF we had people with items which we could add to charter, >> >> so I want those people wanting to add things to charter to send an >> >> email to the mailing list about what items they would like to propose >> >> to the charter, and preliminary charter text for the item. >> >> >> >> If we do not receive any proposed charter texts, then I assume we do >> >> not have any more work to do after we finish our current charter... >> >> >> >> Also if there is people wanting to present anything in the next >> >> IPsecME IETF session, send email to wg chairs ipsecme-chairs@ietf.org. >> >> -- >> >> kivinen@iki.fi >> >> >> >> _______________________________________________ >> >> IPsec mailing list >> >> IPsec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ipsec >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --f403045fc03e245241055c9d80c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Valery,

Absolutely, Diet-I= KE would be a nice item have in the charter as well, but this is a differen= t item.

Currently the work on compressing esp has two items:
* d= raft-mglt-ipsecme-diet-esp defines how to esp.
* draft-mglt-ipsecme-ikev= 2-diet-esp-extension defines how peers agree on using diet-esp

I see= draft-smyslov-ipsecme-ikev2-compression [3] and draft-smyslov-ipsecme-ikev= 2-compact [4] focused on the compression of ikev2 itself.

draft-ipse= cme-ikev2-extention was a misspelt name for draft-mglt-ipsecme-ikev2-diet-e= sp-extension [2].

If we are adding this item the text for the chart= er should be updated around:

OLD:
A growing number of use cases f= or constraint network - but not limited=20 to - have shown interest in reducing ESP overhead by compressing =20 =20 ESP fields. The WG will define extensions of ESP and IKEv2 to=20 enable ESP header compression.=C2=A0

draft-mglt-ipsecme-diet-esp an= d draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good start= ing points.

NEW:
A growing number of use cases for constraint ne= twork - but not limited=20 to - have shown interest in reducing ESP (resp. IKEv2) overhead by=20 compressing ESP (resp IKEv2) fields. The WG will define extensions of=20 ESP and IKEv2 to enable ESP header compression.

draft-mglt-ipsecme-= diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression.=20 draft-smyslov-ipsecme-ikev2-compression and=20 draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2=20 compression.

Yours,
Daniel
=

On Sat, Oct 28, 2= 017 at 9:13 AM, Valery Smyslov <svanru@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
= Hi=20 Daniel,
= =C2=A0
= probably=20 we need to consider Diet-IKE too? Aa companion for Diet-ESP.
= =C2=A0
= And=20 what is draft-ipsecme-ikev2-extention? I cannot find such a draft...
<= /div>
= =C2=A0
= Regards,
= Valery.
=
=C2=A0
We support the proposals and will publish updated the documents regard= ing=20 diet-esp and its associated IKEv2 extension. We believe=C2=A0=20 draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a go= od=20 starting point.

The proposed text for the charter could=20 be:
A growing number of use cases for constraint network - but not= =20 limited to - have shown interest in reducing ESP overhead by compressing ES= P=20 fields. The WG will define extensions of ESP and IKEv2 to enable ESP header= =20 compression.=C2=A0

draft-mglt-ipsecme-diet-esp and=20 draft-mglt-ipsecme-ikev2-extention are expected to be good starting po= ints.=20

Yours,
Daniel


=C2=A0
On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly <t= pauly@apple.com> wrote:
+=20 1 to these proposals

I'd also like to see the work on drafts l= ike=20 DIET-ESP (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think w= e'll=20 have some growing use cases for IPsec in constrained networks, and as tha= t=20 develops, extensions and modifications to the protocol to make IKEv2 and = ESP=20 work efficiently in those conditions will be necessary. (These would like= ly=20 fall into the host-to-host use case described in the=20 charter.)

Thanks,
Tommy

> On Oct 27, 2017, at 7:51 = AM, Valery Smyslov <svanru@gmail.com> wrote:
>
>=20 Hi,
>
> I think that the following items can be considered fo= r the=20 new charter.
>
> 1. Develop load sharing cluster solution for= =20 IKEv2/IPsec. The possible charter=20 text:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MOBIKE protocol= =20 [RFC4555] is used to move existing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=20 IKE/IPsec SA from one IP address to another.=20 However,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in MOBIKE it is the= =20 initiator of the IKE SA (i.e. remote access=20 client)
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that controls this=20 process. If there are several=20 responders
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 each having own IP= =20 address and acting together as a load sharing=20 cluster,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then it is desirable= for=20 them to have ability to request initiator to switch=20 to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a particular=C2=A0=C2=A0= =C2=A0=20 member. The working group will analyze the=20 possibility
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to extend MOBIKE= =20 protocol or to develop new IKE=20 extension
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that will allow to = build=20 load sharing clusters in an interoperable way.
>
> 2. Make IK= Ev2=20 Postquantum Cryptography ready. In particular - make=20 it
>=C2=A0=C2=A0=C2=A0 able to transfer large payloads in initial= =20 exchange without having
>=C2=A0=C2=A0=C2=A0 IP fragmentation issues= . The=20 possible charter text:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=20 Postquantum Cryptography brings new key exchange=20 methods.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Most of these method= s=20 that are known to date have much larger=20 public
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 keys then conventional= =20 Diffie-Hellman public keys. Direct=20 using
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 these methods in IKEv2 = might=20 lead to a number of problems
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = due=20 to the increased size of initial IKEv2 messages. The working group=20 will
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 analyze the possible pro= blems=20 and develop a solution, that will
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=20 make adding Postquantum key exchange methods more easy.
>
>= =20 Regards,
> Valery.
>
>
>> We will be meeting a= t=20 Monday morning 09:30-11:00 for 1.5 hours. Our
>> main agenda ite= m=20 will be the rechartering text, i.e., our charter will
>> expire = by=20 the end of year, and we have most of our chartered work
>> alrea= dy=20 completed, or almost finished, so we need to decide what new
>> = items=20 (if any) we take to our charter, or wheter we shut down the=20 WG.
>>
>> In last IETF we had people with items which w= e=20 could add to charter,
>> so I want those people wanting to add t= hings=20 to charter to send an
>> email to the mailing list about what it= ems=20 they would like to propose
>> to the charter, and preliminary ch= arter=20 text for the item.
>>
>> If we do not receive any propo= sed=20 charter texts, then I assume we do
>> not have any more work to = do=20 after we finish our current charter...
>>
>> Also if th= ere=20 is people wanting to present anything in the next
>> IPsecME IET= F=20 session, send email to wg chairs ipsecme-chairs@ietf.org.
>>=20 --
>> kivine= n@iki.fi
>>
>>=20 _______________________________________________
>> IPsec ma= iling=20 list
>> IPse= c@ietf.org
>> https://www.ietf.org/mailman/l= istinfo/ipsec
>
>=20 _______________________________________________
> IPsec mailin= g=20 list
> IPsec@ie= tf.org
> https://www.ietf.org/mailman/list= info/ipsec

_______________________________________________<= br>IPsec=20 mailing list
IPsec= @ietf.org
https://www.ietf.org/mailman/listin= fo/ipsec
=C2=A0

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


--f403045fc03e245241055c9d80c4-- From nobody Sat Oct 28 11:53:41 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC413FD25 for ; Sat, 28 Oct 2017 11:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pnmviNTQmTg for ; Sat, 28 Oct 2017 11:53:38 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0133.outbound.protection.outlook.com [104.47.1.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC50D13F55D for ; Sat, 28 Oct 2017 11:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zhq7a+CF88oCI2PU4pzkeksxFYUmFIIdGgYDOYO6jbQ=; b=DlrY96IvUa+JNvekBMcW/CZf0yWTS4l0DeF9jir4kVP+lmieMvMCYlV1rbOcDsGZQS8t2H7n9k4boGaAe3WiyWUYc+SH/bc0TiXmIyyRCy9ef0gNwt42r/39uOXomteAEx41S5jXkAvjTPs6NRJ1sPXvk8zFmDxaLU+dQd5EAgk= Received: from HE1PR07MB1417.eurprd07.prod.outlook.com (10.169.122.15) by HE1PR07MB1419.eurprd07.prod.outlook.com (10.169.122.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Sat, 28 Oct 2017 18:53:35 +0000 Received: from HE1PR07MB1417.eurprd07.prod.outlook.com ([fe80::20fc:57e7:e4ce:cc59]) by HE1PR07MB1417.eurprd07.prod.outlook.com ([fe80::20fc:57e7:e4ce:cc59%14]) with mapi id 15.20.0197.007; Sat, 28 Oct 2017 18:53:34 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Valery Smyslov , 'Tero Kivinen' , "ipsec@ietf.org" Thread-Topic: [IPsec] Agenda for IETF 100 Thread-Index: AQMw1niW9yk+rAP08ubSySOCJGyjxKA8qWXAgAHk+AA= Date: Sat, 28 Oct 2017 18:53:34 +0000 Message-ID: References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> In-Reply-To: <0fda01d34f33$1600bd70$42023850$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.210.180.51] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1419; 6:uSH+Il4WFt/kXsCYI0LGOK65ftfQsqX3DSNpdMmLUOXNjWbn9/2jd+whfaZXrxgdit6Ow7kLtOxnq4nbfPCcVIEvbOWtA0xAfr/AsKgwdRCyJ8QMP5tUTZ1uYC5HRDUg8KjsoX4CqBOyWMtVxC+Rrw5Ljk1EE68ruqNsTy9qYfskFyM5619Hh3UnaZ14nUFTfQawlRoC7PZrWSggbSzRy/+ByDfU80y1qtSMzLBzbv/7cfPHjhaj7gLf4lR1d4ReuGnpS9d3XX04okWA6FEbZ/9Hi8J5JYDmA5L3MZWF00sNmRUV+MczUa9jk/+XnOtFXSThsiMJFbCPwG1QHOFKsGZLrXTSJCxNPkXNz4L1WkU=; 5:IySFLNzH5PPb+vQLrIT7UfhJdd+VqyNsOmPsyXu+0d3It2YyYuVs/oK6Z2S+ZSBLFkYqxTzFsyoBLMrozZGDYgG3vWElienFeXms7PnBxmqwAP9o+4dq/4FXMDm31SF7bCL0rHpWvDlqaizSDchyrra2KQibDUok1RboleyQUL0=; 24:/Wh1CuVBg3Rcg2Ah9ix14rSbJdjMbXuhEubigXSVp8lYjIya6bp8bMTbXKYA2LhWzzylVYKjgnZh3wnr0GCRpuP6Ucma0GADX88u9gz9ih0=; 7:YT51+h9MyZGWnGEO5/TtFpZF6eJHyAOY1wkeaY05l5i4k6/tYC/U7wY/qgJHt7mBztd8gPD09MzJ6jgfHromm9ieLJCHwzDqtUMOVK1jTN5YVIWdfLW/vnEsSm9BkTRb7bGCN3rdEz333TEdE0AmKty52mbYN+kFlAdtg940ZTZy+rLYSu4iDrerNt0W/iEhrtRBGZ2iY0z+Em5OIHqu3ChWTQ7iLgSaDNnmMqR2u5HT5/EnY+Tu6vvWpHUfYzzr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bda6f9a1-5439-4761-f66e-08d51e353122 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:HE1PR07MB1419; x-ms-traffictypediagnostic: HE1PR07MB1419: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1419; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1419; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(189002)(3280700002)(6436002)(2900100001)(189998001)(25786009)(14454004)(6506006)(478600001)(8676002)(81166006)(81156014)(33656002)(8936002)(74316002)(101416001)(7736002)(50986999)(305945005)(66066001)(7696004)(76176999)(54356999)(5660300001)(229853002)(2950100002)(106356001)(105586002)(68736007)(316002)(53936002)(5250100002)(97736004)(110136005)(2501003)(9686003)(102836003)(6116002)(3846002)(3660700001)(55016002)(39060400002)(2906002)(6246003)(99286003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1419; H:HE1PR07MB1417.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: bda6f9a1-5439-4761-f66e-08d51e353122 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2017 18:53:34.8330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1419 Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 18:53:40 -0000 > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible ch= arter > text: >=20 > MOBIKE protocol [RFC4555] is used to move existing > IKE/IPsec SA from one IP address to another. However, > in MOBIKE it is the initiator of the IKE SA (i.e. remote access client) > that controls this process. If there are several responders > each having own IP address and acting together as a load sharing > cluster, > then it is desirable for them to have ability to request initiator to > switch to > a particular member. The working group will analyze the possibility > to extend MOBIKE protocol or to develop new IKE extension > that will allow to build load sharing clusters in an interoperable way. [HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange Protoco= l Version 2 (IKEv2)) can't be used for this purpose? =20 From nobody Sat Oct 28 12:42:34 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FEF13F423 for ; Sat, 28 Oct 2017 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 aQj-BWDasEZe for ; Sat, 28 Oct 2017 12:42:31 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60512137C2E for ; Sat, 28 Oct 2017 12:42:31 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id a2so10676238lfh.11 for ; Sat, 28 Oct 2017 12:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-transfer-encoding:importance; bh=sM5GIXHD8ZtR/UgqcsaWxC7z102Yfg3nc6H19rM/npw=; b=Iik+MB3/MqH1iVQcrnvT2FaVteXI4QsKcW/T3NZcQPrIv9XDpbHwV4v4poV8FQs/cI Zu03S/t37Z1F30xttJv0Vz7YPJqzYMVOH/3G5c0Jb56uUYu8t4PYnhjGfNYsRLc+xFxe 8egdORGUjXZpW9QR5oPdbhDO14vl4yLqZtcQXUK//mJpZFKKJ0yrCN1DKc5ZD8ge9KkO gg/mJ4vSl+a7QmnAcqKjQ7nUvBpC+L5sOJR+K+JQiYDkYAYmJ3DSRiyHTvawNkdv+83S WPx16enFgiBKPbn14IcfDaartkSm+nasjYhkU+9LsnFPhjEO3XXXcvSsEaEjZIcDcY3X +WIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=sM5GIXHD8ZtR/UgqcsaWxC7z102Yfg3nc6H19rM/npw=; b=uKduADLro0vVgtw3bAYhy666fQm0y78UKNbhz8tleQI9EAqNn9DvuhoW+HDuaV7Pg2 4M/fdGL8y7gEmDkwHGuVug2WVY3V16sSS1SE4MXyyM3NyLQLRKbPP2cJQ1QvglBk5swP 6634YdvTWo2mqGH8TeNYh1L38WQSMtWfzuFMLy3sBHYdnBp6DbHjrHbBHrx0dvJfoGZw q4hf1PnDNC1boYNMLlUhCOi6d0NCqRvmD5mhgnp+fhPh2gsSr70Rc77nrn6P3HqsFNqz RA96FKwr24FU0b+1c5DPsghJt+S0NFkBZVI3FhvfdKiL+fSpl20tSZCI23KE+ggwDKhv +2eA== X-Gm-Message-State: AMCzsaU0OqDK7GCDO53TogUTaUM5WBmv9yDFuBizHNUuHiIAlIAS0/zX OCtRMbgCbS10DfEfyqwozqo= X-Google-Smtp-Source: ABhQp+QevglcOZdTQcEyH9mwt7+Q90sxdwHt9NGG0N58Ly9cnbDn9mwMzZpPnhW7AKhbEnqxqgnmYA== X-Received: by 10.25.23.90 with SMTP id n87mr1580102lfi.146.1509219749697; Sat, 28 Oct 2017 12:42:29 -0700 (PDT) Received: from chichi (ppp83-237-164-110.pppoe.mtu-net.ru. [83.237.164.110]) by smtp.gmail.com with ESMTPSA id s16sm2498682ljd.77.2017.10.28.12.42.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 Oct 2017 12:42:29 -0700 (PDT) Message-ID: <8BB6B1152F22407784D0AFDF777FB982@chichi> From: "Valery Smyslov" To: "Hu, Jun \(Nokia - US/Mountain View\)" , "'Tero Kivinen'" , References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> In-Reply-To: Date: Sat, 28 Oct 2017 22:42:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 19:42:33 -0000 Hi Jun, > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter > text: > > MOBIKE protocol [RFC4555] is used to move existing > IKE/IPsec SA from one IP address to another. However, > in MOBIKE it is the initiator of the IKE SA (i.e. remote access client) > that controls this process. If there are several responders > each having own IP address and acting together as a load sharing > cluster, > then it is desirable for them to have ability to request initiator to > switch to > a particular member. The working group will analyze the possibility > to extend MOBIKE protocol or to develop new IKE extension > that will allow to build load sharing clusters in an interoperable way. [HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)) can't be used for this purpose? The problem with IKE Redirect is that it requires IKE SA to be re-established from scratch. It consumes quite a lot of resources and takes noticeable amount of time. Moreover, in some cases it could require human interaction (in case of some EAP methods or if access to client's credentials requires entering PIN), so it may be inappropriate. The idea is to have a solution that utilizes already established IKE SA and moves it (along with its Child SAs) from one cluster member to another without creating new IKE SA. Regards, Valery. From nobody Sat Oct 28 12:57:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706AE13FD4C for ; Sat, 28 Oct 2017 12:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pUP3xQrggtG for ; Sat, 28 Oct 2017 12:57:07 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0118.outbound.protection.outlook.com [104.47.2.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B57137C2E for ; Sat, 28 Oct 2017 12:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K5YjTdNo94FnrsZTpeD+Rv5qoXVKXz9+jePdZUSVUoI=; b=T+LsQv++SMwsfs/K3Y5LcwHrggTs4BOZ/gWaMv2O2sR5AKJDstc8ZckotX5o5n/T55bA38VL6V58YQm6lA+O2t8ijFOEmbYdv6GhMDrTZYHS+8o96BgeXT45cKFchXVTFu+2MRdADgQWe28GsGoFOEHTFMlRl4vOeDtdZ7J+WdQ= Received: from HE1PR07MB1417.eurprd07.prod.outlook.com (10.169.122.15) by HE1PR07MB1419.eurprd07.prod.outlook.com (10.169.122.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Sat, 28 Oct 2017 19:57:03 +0000 Received: from HE1PR07MB1417.eurprd07.prod.outlook.com ([fe80::20fc:57e7:e4ce:cc59]) by HE1PR07MB1417.eurprd07.prod.outlook.com ([fe80::20fc:57e7:e4ce:cc59%14]) with mapi id 15.20.0197.007; Sat, 28 Oct 2017 19:57:03 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Valery Smyslov , 'Tero Kivinen' , "ipsec@ietf.org" Thread-Topic: [IPsec] Agenda for IETF 100 Thread-Index: AQMw1niW9yk+rAP08ubSySOCJGyjxKA8qWXAgAHk+ACAAA5vgIAAAJHQ Date: Sat, 28 Oct 2017 19:57:03 +0000 Message-ID: References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <8BB6B1152F22407784D0AFDF777FB982@chichi> In-Reply-To: <8BB6B1152F22407784D0AFDF777FB982@chichi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.210.180.51] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1419; 6:sKx3m8jHjwenfqIag2VOIG52b2aiMF6QcoYEXwx7CLJzJcBrPRBXplRAKewnaNLSeDIDc0bAMhdqICHAneyaKVzuzS4NczRVpzCz58FENvjWqMMNcfcSi+5dvYN4wezRqSXVo9iy9Bym6oZx3zU462lBN7YA89Ij7MEjQYdrO20ihydd+5qMcArVaIgZYMb+UPpGbK/n0ZhjoubEVg8ssy5ufwMsj2sMwAyKf61Vm61aaVacJrsNUPNUcy3ACWD0JSdn8BitWcbRA2n2KAsl7DgsgwkhvJ1FVfUTJuPWW5vna2DL2r6mwdHM3uHniPBtsGV53Rp/ky/9IO4Eu9SHiha6KujWPvrMTY1x7rLECB4=; 5:Dyzr858vCLV1WAf+7Srun/azp5P5x3seJUrNEEUcr99WbImz+XN5gS36GCR4y0XeQF2qcAzYTuWmmrYpS/BFqbMZRrGCIIrtTFalG9MJL+r2IF8HlhmOnK7JVcLnz8gMe8gt9qKd0Zn+qZkpofFmPBaiTfiLvzN3VJonxbPMA5s=; 24:csCu1agX2s9giq1Wy22KC2k2vmDboK8SLwuXz/QLgTfsfDPAFb34XNL1tGX+JOVBJblynTa+sHGpeg14rceqpmeq6ILffmqmL17h2uT2bOI=; 7:u18SU8SEYECkjH+z6D6ZrUWnffrIM1mY71aLkkW9XfxxMxenH0FBeoCpwkS2prVMU/l9LjS88BlFFrKqUFkYzq5Xw21kdH8wUzEsA1i6vRfbd6eC9n0v6hYmhOodt7tcseVMgvaw4OeXzDEBsyeF4l82SpfB9I0NwmkpC/d2Tt6BNF9Ocy9mxz7lYBymgjepwgO23euB04Jpa3YJieuXwnvM3GRy/mRUUxOEXryXVA6K90FnV45pUpHJ46q9SVAF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0ed984a0-06d9-4ac3-08bf-08d51e3e0f0c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:HE1PR07MB1419; x-ms-traffictypediagnostic: HE1PR07MB1419: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231020)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1419; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1419; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(13464003)(3280700002)(6436002)(2900100001)(189998001)(25786009)(14454004)(6506006)(478600001)(8676002)(81166006)(81156014)(33656002)(8936002)(101416001)(74316002)(7736002)(50986999)(305945005)(66066001)(7696004)(76176999)(54356999)(5660300001)(229853002)(2950100002)(106356001)(105586002)(68736007)(316002)(53936002)(5250100002)(97736004)(110136005)(2501003)(93886005)(102836003)(6116002)(9686003)(3846002)(3660700001)(55016002)(39060400002)(6246003)(2906002)(99286003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1419; H:HE1PR07MB1417.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ed984a0-06d9-4ac3-08bf-08d51e3e0f0c X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2017 19:57:03.0483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1419 Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 19:57:09 -0000 > -----Original Message----- > From: Valery Smyslov [mailto:svanru@gmail.com] > > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible > > charter > > text: > > > > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from > > one IP address to another. However, in MOBIKE it is the initiator of > > the IKE SA (i.e. remote access client) that controls this process. If > > there are several responders each having own IP address and acting > > together as a load sharing cluster, then it is desirable for them to > > have ability to request initiator to switch to a particular member. > > The working group will analyze the possibility to extend MOBIKE > > protocol or to develop new IKE extension that will allow to build load > > sharing clusters in an interoperable way. >=20 > [HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange > Protocol Version 2 (IKEv2)) can't be used for this purpose? >=20 > The problem with IKE Redirect is that it requires IKE SA to be re-establi= shed > from scratch. > It consumes quite a lot of resources and takes noticeable amount of time. > Moreover, in some cases it could require human interaction (in case of so= me > EAP methods or if access to client's credentials requires entering PIN), = so it > may be inappropriate. > The idea is to have a solution that utilizes already established IKE SA a= nd > moves it (along with its Child SAs) from one cluster member to another > without creating new IKE SA. [HJ] two questions: 1. this sound interesting, however how to do it securely is the most import= ant question, do you already have draft? 2. if the use case is load-balance, then wouldn't it be better off to make= a selection right upon client connects (e.g. redirect during IKE_AUTH) tha= n move SA around after tunnel is established ?=20 From nobody Sat Oct 28 22:28:03 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BB813F666 for ; Sat, 28 Oct 2017 22:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 1zvsHKWCZJgg for ; Sat, 28 Oct 2017 22:28:01 -0700 (PDT) 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 DE10513F63B for ; Sat, 28 Oct 2017 22:28:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yPmNF3QxXz1L5; Sun, 29 Oct 2017 06:27:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509254877; bh=LutCa812LmiN7RPMKxfbYQFSzBFs+su90VSOpzIC1FI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iSVP3gG3UDpV4YvoTq3iZHI6kztweTyjv4FlqXHFhi8T7CIpLWQRcBd1EtgDzeSyG X2+Exatins4f+Y4reUn+91iS1w/CbS2AXUzFgba2LqRmNs7vzwSDBr+4d8bRGnuHaz TDZOTVvGC+g5tGNflLV/WzrERdBjAYGW6HnZw/xo= 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 JWK_5Z8jzEsl; Sun, 29 Oct 2017 06:27:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 29 Oct 2017 06:27:52 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5ADBA62D29; Sun, 29 Oct 2017 01:27:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5ADBA62D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4991240D35AF; Sun, 29 Oct 2017 01:27:51 -0400 (EDT) Date: Sun, 29 Oct 2017 01:27:51 -0400 (EDT) From: Paul Wouters To: "Hu, Jun (Nokia - US/Mountain View)" cc: Valery Smyslov , 'Tero Kivinen' , "ipsec@ietf.org" In-Reply-To: Message-ID: References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <8BB6B1152F22407784D0AFDF777FB982@chichi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 05:28:02 -0000 On Sat, 28 Oct 2017, Hu, Jun (Nokia - US/Mountain View) wrote: >> [HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange >> Protocol Version 2 (IKEv2)) can't be used for this purpose? >> >> The problem with IKE Redirect is that it requires IKE SA to be re-established >> from scratch. >> It consumes quite a lot of resources and takes noticeable amount of time. >> Moreover, in some cases it could require human interaction (in case of some >> EAP methods or if access to client's credentials requires entering PIN), so it >> may be inappropriate. >> The idea is to have a solution that utilizes already established IKE SA and >> moves it (along with its Child SAs) from one cluster member to another >> without creating new IKE SA. > > [HJ] two questions: > 1. this sound interesting, however how to do it securely is the most important question, do you already have draft? > > 2. if the use case is load-balance, then wouldn't it be better off to make a selection right upon client connects (e.g. redirect during IKE_AUTH) than move SA around after tunnel is established ? I think a document describing how best to load load balancing AND failover support for IPsec would be useful, irrespective of the existing RFC's or existing/future drafts which we would use. For example, a document listing: - Client behaviour to Access VPN failover - Net-to-Net failover over different uplinks - Hardware pair failover with state within a datacenter - Crypto Mesh migration - Maybe some IPsec/NHRP advise? Another thing we might want to reconsider is something to talk about mesh encryption / auto-vpn in general. While earlier work to come up with a single solution failed, there is still a market need, and I'm a little fearful of SDN removing IKE from the setup. Paul Paul From nobody Sat Oct 28 23:55:49 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F2113F6B4 for ; Sat, 28 Oct 2017 23:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 9uZK5qDuzL-n for ; Sat, 28 Oct 2017 23:55:46 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588AF13F6B0 for ; Sat, 28 Oct 2017 23:55:46 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 90so11374526lfs.13 for ; Sat, 28 Oct 2017 23:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-transfer-encoding:importance; bh=N96hcG53HVzKcCsJxJL8t39NYrXlfvr/c+NallmjQUw=; b=hbuvdqVbDjM9RdaFmoeoqcvuL9cSZlJDK4DZZsiX+Y1emxQ2TaZaFn9vVQBFikOLbU 1h/R3kGMQnmgI/oRc31xwPh6fC2xpOPsJ6cvupsYscCdW0mmoNa+U99ARNjn2UrGXUul 0hJFobBHWmJXJ3h6a5zNVJcKcT9Uu4QqmzBdrXBof78ys4SixPbhrKtsFuyII+ALq9CZ CIBa9efNJWjgNf7tzY5TAyyQGhvCpdWf/LsL5K1L/k/HNA0oYbtfilBK1VbXdlFcO0po O3kMJ+9LYNLOI5ayWrodtNo9Zmc2XP09SH24eso7aCs0OccsjtwmLh72R7csNuZtBjWZ 1Vpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=N96hcG53HVzKcCsJxJL8t39NYrXlfvr/c+NallmjQUw=; b=UnQ0CD4Iv1tejuZD+M2gh8uRWEKey2LPrSdxCvQQ3Y5lVeyQ8/Z3z1XtngJ6G+yuRz zAr6ypCdh4DZd5jCUVJKPee6hb2x/wWZTcQn30ifA+h//8oq9DQloeG2fhb1g2wXXcDm uVHu+4ZWDA7RIhKSilRCH9XjjK7Q+bos0RtJbWUN4Y7alVGYaqW9F7vVmc62z7fTVPnd GQ/4kNx6Xo/LkXefdEnQWSeSezB1REgjV+tE/vUl0MSSytZhRDoVnsHMAlOk4lfPiNz0 0rjLS/oDwBa5xRM9/0RyxThWV/4eYfCKzJ54Lt/tzdeH3vunTq7x0hDPdMB5kGkF90yY shcg== X-Gm-Message-State: AMCzsaXPwE0ZhZQNfAgW0XZHgrJA+lW7lUy9GEM7dxw8KkOyGvZy0Xbm lwYKVfl+GG2zMY2UonEJwz0= X-Google-Smtp-Source: ABhQp+S8SD+mRj7KelSF2wPLRIPOTdV6sJtZj758kn1n4wCR9+NRNHrLmg8xAW6wI8jVocCu/Letig== X-Received: by 10.46.89.146 with SMTP id g18mr2014831ljf.53.1509260144678; Sat, 28 Oct 2017 23:55:44 -0700 (PDT) Received: from chichi (ppp83-237-164-110.pppoe.mtu-net.ru. [83.237.164.110]) by smtp.gmail.com with ESMTPSA id h86sm2191577lfl.59.2017.10.28.23.55.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 Oct 2017 23:55:44 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Hu, Jun \(Nokia - US/Mountain View\)" , "'Tero Kivinen'" , References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <8BB6B1152F22407784D0AFDF777FB982@chichi> In-Reply-To: Date: Sun, 29 Oct 2017 09:55:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 06:55:48 -0000 Hi, >> The problem with IKE Redirect is that it requires IKE SA to be re-established >> from scratch. >> It consumes quite a lot of resources and takes noticeable amount of time. >> Moreover, in some cases it could require human interaction (in case of some >> EAP methods or if access to client's credentials requires entering PIN), so it >> may be inappropriate. >> The idea is to have a solution that utilizes already established IKE SA and >> moves it (along with its Child SAs) from one cluster member to another >> without creating new IKE SA. > > [HJ] two questions: > 1. this sound interesting, however how to do it securely is the most important question, do you already have draft? draft-smyslov-ipsecme-ikev2-r-mobike > 2. if the use case is load-balance, then wouldn't it be better off to make a selection right upon client connects > (e.g. redirect during IKE_AUTH) than move SA around after tunnel is established ? This is definitely an option (ant even can be achieved with IKE redirect). However, once client is connected you cannot move it to another member, so depending on clients' activity members load can become very uneven and you cannot balance it without forcing clients to reconnet. The desire is to be able to dynamically balance members load. Regards, Valery. From nobody Sun Oct 29 18:38:24 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD0B13FD25 for ; Sun, 29 Oct 2017 18:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMpBXteVf3es for ; Sun, 29 Oct 2017 18:38:21 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 C9E5A13F605 for ; Sun, 29 Oct 2017 18:38:20 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id a132so13073847lfa.7 for ; Sun, 29 Oct 2017 18:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zC57nu0HsQo7RGdk8wa/lXQEyrp6OA5pp8z7ggBI2x8=; b=lJP6ht/7LrWYOjsh3SIMgDT8g2Y/Ov6T52m0BTh4jqQepA9/Vmv465czOxXIGlYNW/ raFq9p+KS5AC2/DBjpRCL9x2u1xAzedLzsxKRJ6BwVgVe4YYZV+/pLHnwMEf7KtTPzDV Z/WvHK/7PoNSamc9UkDn7PifVLdutblWlTMm3De4DEquCazRNiSv88p0ZjvROEHgZV6a QaISK70V0CA0YVqSHIVAryCv3T8s6dTnjcUb17qyvEg1SYAxAw2ih25fjDMtWN8S95MJ smpWy2OVnpuXSg/mAi+5F1QF9OymrPJvR9Y/h6KiE5KZzGLMutaIlPW8qDTBLtj4GUw9 TnYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zC57nu0HsQo7RGdk8wa/lXQEyrp6OA5pp8z7ggBI2x8=; b=Z8oJhf8NN1AvEHuGWE7S/gJhc+k8/QxJdEvd+Jir9lp0x1qCmdqScB6KkBTVwYyaw0 cJFvtcDJMljHUtv9tCVyIaYIOQf87lf1pY5pDJme0U9jmMnQRY0ldyG9N9aMZSviPS2e h605qpgfJfLo7wl2OyNindgJ8yZjCHIuU3E68TimBNDDnIFikjzndnaBEo6O/T+EndUz tW02A6luKVwduPy2N0aIWZ7ajvRRu4nfSY7ZS8pCWQaYl5H9JWm0oYsrsClduofnehPx HNGaqFPYZEoxIcg5dE/JgRrpIHMAuSDmSjpIPH84+IZyDgyOewWyrYgFJRLh6oGp6IJp zT4g== X-Gm-Message-State: AMCzsaVJ1EfwXqdqVadBtLwl+NADrgp/V0573G+OuiFeRQrT5gjRifqp C/CbMNAFtW2IBaUvLb+kYs8xSLJh2HJyPExH4UE= X-Google-Smtp-Source: ABhQp+Rp60SYQ8Kmms+qR2lxlqR/2IPwoRkyO+pIN/OEy79MKJAZ8ETU/ge45i+MqoCuE957pdMOolXuJAFdM7CIFKc= X-Received: by 10.25.84.134 with SMTP id b6mr2265262lfl.168.1509327499014; Sun, 29 Oct 2017 18:38:19 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.68.29 with HTTP; Sun, 29 Oct 2017 18:38:18 -0700 (PDT) In-Reply-To: References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <8BB6B1152F22407784D0AFDF777FB982@chichi> From: Daniel Migault Date: Sun, 29 Oct 2017 21:38:18 -0400 X-Google-Sender-Auth: 1ra3nnzFaPymwKkGoZnQcXoR1jk Message-ID: To: Valery Smyslov Cc: "Hu, Jun (Nokia - US/Mountain View)" , Tero Kivinen , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cdec06db7bd055cb9b19c" Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 01:38:23 -0000 --94eb2c1cdec06db7bd055cb9b19c Content-Type: text/plain; charset="UTF-8" Hi, A few years ago, we worked on fail-over, load balancing.. [1] and would be happy to help. Yours, Daniel [1] https://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 On Sun, Oct 29, 2017 at 2:55 AM, Valery Smyslov wrote: > Hi, > > The problem with IKE Redirect is that it requires IKE SA to be >>> re-established >>> from scratch. >>> It consumes quite a lot of resources and takes noticeable amount of time. >>> Moreover, in some cases it could require human interaction (in case of >>> some >>> EAP methods or if access to client's credentials requires entering PIN), >>> so it >>> may be inappropriate. >>> The idea is to have a solution that utilizes already established IKE SA >>> and >>> moves it (along with its Child SAs) from one cluster member to another >>> without creating new IKE SA. >>> >> >> [HJ] two questions: >> 1. this sound interesting, however how to do it securely is the most >> important question, do you already have draft? >> > > draft-smyslov-ipsecme-ikev2-r-mobike > > 2. if the use case is load-balance, then wouldn't it be better off to >> make a selection right upon client connects (e.g. redirect during IKE_AUTH) >> than move SA around after tunnel is established ? >> > > This is definitely an option (ant even can be achieved with IKE redirect). > However, once client is connected you cannot move it to another member, > so depending on clients' activity members load can become very uneven and > you cannot balance it without forcing clients to reconnet. The desire is > to be able to dynamically balance members load. > > Regards, > Valery. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --94eb2c1cdec06db7bd055cb9b19c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A few years ago, we worked on fail-over, load = balancing.. [1] and would be happy to help.

Yours,
Daniel
[1] https://tools.ietf.org/html/draft-plmrs-ipsecme-ips= ec-ikev2-context-definition-01

=
On Sun, Oct 29, 2017 at 2:55 AM, Valery Smyslov = <svanru@gmail.com> wrote:
H= i,

The problem with IKE Redirect is that it requires IKE SA to be re-establish= ed
from scratch.
It consumes quite a lot of resources and takes noticeable amount of time. Moreover, in some cases it could require human interaction (in case of some=
EAP methods or if access to client's credentials requires entering PIN)= , so it
may be inappropriate.
The idea is to have a solution that utilizes already established IKE SA and=
moves it (along with its Child SAs) from one cluster member to another
without creating new IKE SA.

[HJ] two questions:
1. this sound interesting, however how to do it securely is the most import= ant question, do you already have draft?

 draft-smyslov-ipsecme-ikev2-r-mobike

2. if the use case is load-balance, then=C2=A0 wouldn't it be better of= f to make a selection right upon client connects (e.g. redirect during IKE_= AUTH) than move SA around after tunnel is established=C2=A0 ?

This is definitely an option (ant even can be achieved with IKE redirect).<= br> However, once client is connected you cannot move it to another member,
so depending on clients' activity members load can become very uneven a= nd
you cannot balance it without forcing clients to reconnet. The desire is to= be able to dynamically balance members load.

Regards,
Valery.


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

--94eb2c1cdec06db7bd055cb9b19c-- From nobody Sun Oct 29 20:47:02 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFD013F655 for ; Sun, 29 Oct 2017 20:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qepYAtELFuUL for ; Sun, 29 Oct 2017 20:46:59 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01E513F56E for ; Sun, 29 Oct 2017 20:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4QVf22OpoVcl5snQjdvL3ogmBz4R1itcqSFO+qKaUE8=; b=TGDRrPSI9ssaMLHII2Th8g3BMxrgavTn1W1b2onFA2OwpZinF3fQuHWUzYr7tH7JBmkTjAK2Um6FK7Q3v99FjjDUhxaGbK8j7/2wpwyCIa7+yulB4FDlqsSxLQvHeB6+q1luBqTrfXBCSbJSYEBfc5QcgrbJJNT4scvZ+bge32Y= Received: from HE1PR07MB1417.eurprd07.prod.outlook.com (10.169.122.15) by HE1PR07MB1418.eurprd07.prod.outlook.com (10.169.122.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Mon, 30 Oct 2017 03:46:56 +0000 Received: from HE1PR07MB1417.eurprd07.prod.outlook.com ([fe80::20fc:57e7:e4ce:cc59]) by HE1PR07MB1417.eurprd07.prod.outlook.com ([fe80::20fc:57e7:e4ce:cc59%14]) with mapi id 15.20.0197.011; Mon, 30 Oct 2017 03:46:56 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters CC: Valery Smyslov , 'Tero Kivinen' , "ipsec@ietf.org" Thread-Topic: [IPsec] Agenda for IETF 100 Thread-Index: AQMw1niW9yk+rAP08ubSySOCJGyjxKA8qWXAgAHk+ACAAA5vgIAAAJHQgACjBYCAAQpEYA== Date: Mon, 30 Oct 2017 03:46:56 +0000 Message-ID: References: <23026.13858.483048.716056@fireball.acr.fi> <0fda01d34f33$1600bd70$42023850$@gmail.com> <8BB6B1152F22407784D0AFDF777FB982@chichi> 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=jun.hu@nokia.com; x-originating-ip: [98.210.180.51] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1418; 6:AY3/RQtQVwQl5PV0q0nHjSJSOzE0/v/UIO1dEK16upW8dXqRL+VUg8k0IeKOvIUl6/vEyJmLufYVVbT6aJPydvYxwJsOI7xwdETHE6pH1yp0t6EHY6xVYr9lJjBQo+KFscDFlw9tIY+q/Nyibz+zuyIXAoGyKd/yOwOIXNlt7KW7n5oUZePNRfkZICRawTzA14jd0FmWWMix9C92MLiJdT4Rg2BGUQGEvArCzdNP8MbgZ/JKLYFq9AbY4pyIHEoEgPTvnheZ1etjQvLeOIKNoHZ2T9jdK4DEn1pnX18O9ofoEudqkKQ1+o28lrnUFZ3pO4PAa7yjTm5ypReEay6yz+EJsZvAzWsLTo7ljo88I30=; 5:JifQXcrNVPrtFnbG69ucGLu35MjPJrbkz5/WgBoH8lkG7nPu3EsqWcgA+zKMTVJMlgZOKpmSkGEizknAIXNekNhXkHa0BPrnP3gZluCSOXK+eiAk54nLCiBtHzDXJIzZpIxxSRm7mn+nNHicB65sd2QIWdulNrMe28koPHL+j10=; 24:2tBJ61wjPl9eCwSoSNejCGddXMDTaVfJGyy8XIpJndbI1rRebYmk270g/8V+YC3/4eHKST9ZDyq+JupV0QcNOERgDdxLgFrKttlW1fMrzck=; 7:LmrGSzdx8QtC0h5FYDaNCkr27AjIpWPbTAMohO1uP7SU1zZlMyeTKTv5/5mtn0ztpevrt/zpt/xXKqFxhApFZ56USYZe7Ow8OIoS60tt/z6w7Y9aG/kQvCSu1t/Al012su3J3OPJ6SvrcCpPnknKBMpTjF9ktebxT2CvOkZIk0cOyMhpCLY9ncnV1RNpud4N0p4zDr4pWAJc5qfQFwBjaW/Mnsis/ePUiCvdTb2l8zvu4yldHfan3b8GWPLMo0Yf x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2ba12bd2-85d7-4905-b71e-08d51f48ddec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603199); SRVR:HE1PR07MB1418; x-ms-traffictypediagnostic: HE1PR07MB1418: x-exchange-antispam-report-test: UriScan:(82608151540597)(21532816269658); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231020)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1418; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1418; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(24454002)(13464003)(478600001)(7696004)(189998001)(81156014)(93886005)(54906003)(25786009)(105586002)(106356001)(5250100002)(8936002)(229853002)(99286003)(3846002)(97736004)(68736007)(53936002)(6116002)(102836003)(86362001)(55016002)(6246003)(81166006)(305945005)(9686003)(66066001)(4326008)(3280700002)(3660700001)(39060400002)(7736002)(74316002)(6506006)(2900100001)(76176999)(50986999)(54356999)(53546010)(6436002)(2950100002)(6916009)(33656002)(316002)(14454004)(5660300001)(101416001)(8676002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1418; H:HE1PR07MB1417.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ba12bd2-85d7-4905-b71e-08d51f48ddec X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 03:46:56.2771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1418 Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 03:47:01 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Saturday, October 28, 2017 10:28 PM > To: Hu, Jun (Nokia - US/Mountain View) > Cc: Valery Smyslov ; 'Tero Kivinen' ; > ipsec@ietf.org > Subject: Re: [IPsec] Agenda for IETF 100 >=20 > On Sat, 28 Oct 2017, Hu, Jun (Nokia - US/Mountain View) wrote: >=20 > >> [HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange > >> Protocol Version 2 (IKEv2)) can't be used for this purpose? > >> > >> The problem with IKE Redirect is that it requires IKE SA to be > >> re-established from scratch. > >> It consumes quite a lot of resources and takes noticeable amount of ti= me. > >> Moreover, in some cases it could require human interaction (in case > >> of some EAP methods or if access to client's credentials requires > >> entering PIN), so it may be inappropriate. > >> The idea is to have a solution that utilizes already established IKE > >> SA and moves it (along with its Child SAs) from one cluster member to > >> another without creating new IKE SA. > > > > [HJ] two questions: > > 1. this sound interesting, however how to do it securely is the most > important question, do you already have draft? > > > > 2. if the use case is load-balance, then wouldn't it be better off to = make a > selection right upon client connects (e.g. redirect during IKE_AUTH) than= move > SA around after tunnel is established ? >=20 > I think a document describing how best to load load balancing AND failove= r > support for IPsec would be useful, irrespective of the existing RFC's or > existing/future drafts which we would use. For example, a document listin= g: >=20 > - Client behaviour to Access VPN failover > - Net-to-Net failover over different uplinks > - Hardware pair failover with state within a datacenter > - Crypto Mesh migration > - Maybe some IPsec/NHRP advise? [HJ] I think it would be good to have use case/requirement defined first, = because different use cases has different requirements, which might leads t= o different solution; e.g. remote-access client (e.g. road warrior) connect= to one cluster of GWs (ad hoc) is different from a branch router connects= to HQ (always on); where latter could just use routing/ecmp to achieve loa= d balancing, doesn't need anything new; > Another thing we might want to reconsider is something to talk about mesh > encryption / auto-vpn in general. While earlier work to come up with a si= ngle > solution failed, there is still a market need, and I'm a little fearful o= f SDN > removing IKE from the setup. [HJ] there is clear market requirement for an auto-discover encryption VPN,= however again depends on the use case, the solution might not need to exte= nd IPsec; for example, for router interconnection , I could see extending B= GP (e.g. tunnel encaps attr) to carry gw address or other ipsec profiles in= fo along with routes be a solution =20 > Paul > Paul From nobody Mon Oct 30 00:43:03 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF7C13FC1F for ; Mon, 30 Oct 2017 00:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 EMvc52xCFq8V for ; Mon, 30 Oct 2017 00:42:57 -0700 (PDT) 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 943F913FF89 for ; Mon, 30 Oct 2017 00:42:50 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yQRKM2FtZzB5; Mon, 30 Oct 2017 08:42:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509349367; bh=6mRQqql4duCA/dPjbA6cakl1MAliNWyNa/GIz9t6zDU=; h=Date:From:To:cc:Subject; b=gZLzT5gb2/bISlZJuPNaHNlZhE3KE6ojEDUvQFRw/0dMMBVXArvv/IBC/o1twwe1+ 3+rwAGpw/guhWNyHiS0KzKiQ/xGbIp4+Nucuwqu8a4tUTAaf1yGPjysqOR5mwWLOPV Xe4/67tr16Gp31Ol0FW7+RV2EJD9xUu0UZLHj7U8= 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 OUUz6sC3gn41; Mon, 30 Oct 2017 08:42:45 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 30 Oct 2017 08:42:44 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6FFFD62D29; Mon, 30 Oct 2017 03:42:43 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6FFFD62D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 58A4840D35AF; Mon, 30 Oct 2017 03:42:43 -0400 (EDT) Date: Mon, 30 Oct 2017 03:42:43 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: "'Panos Kampanakis (pkampana)'" , "'Scott Fluhrer (sfluhrer)'" , ipsec@ietf.org, 'Vukasin Karadzic' Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [IPsec] draft-ietf-ipsecme-qr-ikev2-00 complexity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:42:59 -0000 On Wed, 23 Aug 2017, Valery Smyslov wrote: >> It is a good idea. A new optional notification that includes the auth_data as it would be calculated without the >> PPK would work. With that, the corner case of ' PPK_id configured on initiator but missing on the responder' is >> addressed. There is an additional cost of the extra notification message for every initiator that has no- >> mandatory ppk configured for the responder. > > Yes, and there is also an extra cost for initiator of performing AUTH calculation (e.g. digital signature) > twice - one with SK_p' and the other with SK_p. Good news are is that it is > a) is performed by initiator only, so there is no risk of DoS attack on responder > b) is needed only if initiator is configured in "permissive" mode - when its policy allows both PPK and non-PPK > SAs with the particular responder I've seen this in the -04 draft, and I'm not sure I like it. What attacks are we opening up by providing two AUTH payloads to a MITM attacker? When they receive AUTH payloads with and without PPK, can they use this as an oracle for the PPK somehow? The attacker in this scenario of course has a quantum computer to perform the attack :) We also need to keep around two sets of SK_* payloads, which is also pretty ugly. Second, since the PPK notify is in the IKE_INIT, couldn't an attack perform a downgrade attack by stripping this out of the IKE_INIT before forwarding the packet? >> My concerns is that we might be making it too complicated by potentially introducing two separate SK_p's. >> From an ops perspective, if we stated the rule that when we want to go postquantum a PPK should be >> populated on the responder first as Graham and others suggested, then the extra complication of a new >> notification can be avoided. Violation of that rule would lead to IKE_AUTH failure for that initiator only. > > In general I think that if protocol allows more flexible operational conditions, then it is a good thing. I am not sure. For example, libreswan allows configurations to be IKEv1only, IKEv2only, or Either. This causes us a lot of weird code now, eg when someone configures MOBIKE or AES_GCM for IKE, both of which are not valid for IKEv1 but are for IKEv2. Also, almost no one else implemented this v1 to v2 migration support, and required administrators to configure two separate connections for these two cases during the migration. We are now in the process of removing this support to make our code a lot simpler again. I think that PPK can be handled with seperate configurations as well. Note also that the use case for this feature is very limited. For access VPNs you would have the responder work with or without PPK, and it can just respond to non-updated initiators without PPK and to updated initiators with PPK. Initiators only need to have one configuration and stick to it. The only use case is a set of gateways, for example for site-to-site connections, where some gateways are updated and others are not. Due to PPK support signaling being in the IKE_INIT packet, the gateway cannot know whether or not it should use PPK or not. But in the real world, almost all those kind of gateways are on static IPs, and the responding gateway can actually know for which configuration the IKE_INIT packet is. Gateways on dynamic IPs is basically the same use case as the access vpn clients described above - you must update the responding gateway first and then there is no issue. In summary, I'm not convinced we need as much complexity as the draft now brings in. I would really like to go back to something simpler. Paul From nobody Mon Oct 30 01:29:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5F813F817 for ; Mon, 30 Oct 2017 01:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 x5p5aBmm-v04 for ; Mon, 30 Oct 2017 01:29:36 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 3AFFA13F821 for ; Mon, 30 Oct 2017 01:29:32 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id 75so13945819lfx.1 for ; Mon, 30 Oct 2017 01:29:32 -0700 (PDT) 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=Og5+plvDjtL6VBWn3M5ZB6PrUCZbCkdEBbib+aoAyzE=; b=LPA24BV2SC8+yPmeTMUjejKbaHajMwN5pVLkEBpX1creqB2QvA8QqJPFFJR5okN77x DKBE3pAGkC/KYXfPdlWve+f71S5l+sN+2u+VXElHpVvwYq0PJjBLkmsOQ2mJDrg1cDeA FynuyAuiOrt1II9N6cfGo3NXF3W2G1NlysDhZ1xZwUbh3msIi08luPwe77DAALgXeYUF ImHNDOjPePP1aZwWN2YWH68svlBdipgH+qhEuhm6wfAiHXFALM3v8lR1Cqq8XoeC64Tp nOM9FLI+ZOrp054OTQyj3NtD7YCoEsyViAqSEnRh11oXyjS+Ac/bBktSXovzbWAFlkUY iDWw== 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=Og5+plvDjtL6VBWn3M5ZB6PrUCZbCkdEBbib+aoAyzE=; b=QL5wlW53d/83YN9Hb9RC29iGquiooyxucz9OIqM0ufvVLxxLzdaGThvnwGOYtQpNdY njpb5m+wfU5lrTlqJuoIsVzlOuaGPF6Oh906NRAMO++mdHYwCiG8x/z2y0zQrIvrqwdm hnHAcJr7KWHrDiRMo3JKVRAh8I6lBEIbn3II28apjQ73DT4QtNf+boCKXUXglkGXfJz+ 7brS4+uyF33r1izNwXCvCrxjnvSrxt3E3ETaBpmBpcAHbfiv8u6b5adqXdxuvrfAeoT9 pWQlMOOkf9KOHxdc/ssQaPXfwZzPt//GD4/aHmnCLYzxP+ZvA6e62SXq5OJI/VOttlTu wIyw== X-Gm-Message-State: AMCzsaUzfwTrjn8RTdL8W6G/SRD7W685FMrymMchX4IIQicPejsuZSfq GpYfT3eB3CB0N6mCI25UYsqezw== X-Google-Smtp-Source: ABhQp+TJ2+waarOb8DNWd4G6g+LjBwemUZN/iMDFyZ3jwQTvP+KtWouxz7uIw3sKkKDI+NaOoHNFaA== X-Received: by 10.25.74.206 with SMTP id x197mr2545500lfa.239.1509352170161; Mon, 30 Oct 2017 01:29:30 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id z66sm3312870ljb.75.2017.10.30.01.29.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Oct 2017 01:29:29 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Panos Kampanakis \(pkampana\)'" , "'Scott Fluhrer \(sfluhrer\)'" , , "'Vukasin Karadzic'" References: In-Reply-To: Date: Mon, 30 Oct 2017 11:29:28 +0300 Message-ID: <114901d35159$34560c30$9d022490$@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: AQJwNDEFibELmmJadQhBKL/k0Jq7jKHCPvGQ Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-qr-ikev2-00 complexity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 08:29:37 -0000 Hi Paul, > I've seen this in the -04 draft, and I'm not sure I like it. > > What attacks are we opening up by providing two AUTH payloads to > a MITM attacker? When they receive AUTH payloads with and without > PPK, can they use this as an oracle for the PPK somehow? The > attacker in this scenario of course has a quantum computer to > perform the attack :) My guess is that if strong crypto primitives are used, then this attack is infeasible, but I definitely let more competent in cryptography people comment on this. > We also need to keep around two sets of SK_* payloads, which is > also pretty ugly. I guess by SK_* payloads you mean SK_* keys? Yes, this extension has its cost (and you forgot to mention that the initiator needs to compute AUTH content twice, that is costly). However, it is optional for both initiator and responder. If initiator's policy is strict and it is OK for him/her to fail communication in case the responder is not (yet) configured with proper PPK, then he/she won't use this extension. However, in a transient period, when not all hosts in the network are configured with proper PPKs, this extension allows the network to continue operate without disruption. > Second, since the PPK notify is in the IKE_INIT, couldn't an > attack perform a downgrade attack by stripping this out of > the IKE_INIT before forwarding the packet? Surely, if she can forge the AUTH payload in real time (since IKE_SA_INIT is authenticated). So basically you need QC for that. And this attack is mentioned in the Security Considerations. > > In general I think that if protocol allows more flexible operational conditions, then it is a good thing. > > I am not sure. For example, libreswan allows configurations to be > IKEv1only, IKEv2only, or Either. This causes us a lot of weird code > now, eg when someone configures MOBIKE or AES_GCM for IKE, both of > which are not valid for IKEv1 but are for IKEv2. Also, almost > no one else implemented this v1 to v2 migration support, We did :-) Those things in our configuration that are not valid for IKEv1 are just sorted out when it is used. > and required > administrators to configure two separate connections for these two > cases during the migration. We are now in the process of removing this > support to make our code a lot simpler again. I think this is a pure implementation problem. Get rid of IKEv1 :-) > Note also that the use case for this feature is very limited. For > access VPNs you would have the responder work with or without PPK, > and it can just respond to non-updated initiators without PPK and > to updated initiators with PPK. Initiators only need to have one > configuration and stick to it. The only use case is a set of > gateways, for example for site-to-site connections, where some > gateways are updated and others are not. Due to PPK support signaling > being in the IKE_INIT packet, the gateway cannot know whether or not > it should use PPK or not. But in the real world, almost all those > kind of gateways are on static IPs, and the responding gateway > can actually know for which configuration the IKE_INIT packet is. > Gateways on dynamic IPs is basically the same use case as the > access vpn clients described above - you must update the responding > gateway first and then there is no issue. What about full mesh? > In summary, I'm not convinced we need as much complexity as the > draft now brings in. I would really like to go back to something > simpler. This feature is optional. You are not required to implement it. However, if implemented, it allows the transient period to go more smoothly in some use cases. > Paul Regards, Valery. From nobody Mon Oct 30 05:19:34 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D2E13F7B7 for ; Mon, 30 Oct 2017 05:19:32 -0700 (PDT) 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_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 6fdbAK7zLNi5 for ; Mon, 30 Oct 2017 05:19:31 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC35913AB12 for ; Mon, 30 Oct 2017 05:19:30 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id a2so14674680lfh.11 for ; Mon, 30 Oct 2017 05:19:30 -0700 (PDT) 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=BIrVuowlUyZ9tIG22OaWCgFIUge+xalMwtVOEl4hjzU=; b=baQwgureC8/AusdFi72q/fZt6bxX9SNByhbMO/B0ZuFl/aNNppqyw2hLnvAwn+YKFR k+Y4slT8xqDSqxfj4FisYnRoyIe5gH4/1SLGFO1h3ZthlWqDym8qj3y9tc2shU8s6J5g q8UK1mftvcxdnmGGdBssJehTk3IjShSyqAQi/sCsvgHbd2IvpFoL8KPa3YJZwJKv/A8y ZsSp9Vf5QsL/8EwCGMnB9PAGoJdj/aQ5E4L5kNCY0u651W/kZbB/KZ4TJis2p0N4oIXD ZV+xGGTdpMBnmTPP2tPpjxBLB1dBq2hxpbayeBQQV6PdiAUVdazIZLaEsy4N7IdenXdR tG8g== 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=BIrVuowlUyZ9tIG22OaWCgFIUge+xalMwtVOEl4hjzU=; b=EHJyXXkeIbSj33JJY7ceFaI9fp6b3QoIXPlxIsd9LAxBNxQHKHQue7AMqaehKVIBgx +afKHTFuRCYFV+c7fb6jKosccr1tOsDemDBLEraiMmrdwuvE9DvFHH7YGEnv2BayFvLO ltzTVO5dSLopa93MF9ZjrZ3QLTOZiBSrZnxdAAj2bJvj4eB6bqIkXe0yhQod0n5Bq+eZ 5QjMFA4uKWuYFAm/kcj28Zci+CGCfCCSuSpcGy0JD3r7NsN6szggxFNFehlNdLsPfau1 nyma8MMdTcg/XW3XTOTKjStWBZVnG79g/JE0hAfohtLhvYh+uxtfbZcVN4OCwQkMDHT2 q4Iw== X-Gm-Message-State: AMCzsaVRmpZf2xkpHwcdn82qDWCvjW8ulWUbutGP5/gEudGBI512bxIX GBw6pSGOjQ8ysDvS7A3xLmADzQ== X-Google-Smtp-Source: ABhQp+QnTQJ2iEhOd9O+0AOkGS3ccMkyounUfziPuD1iu93j54Js+6alGCS5Jxbt+zCvNVSO0973Kw== X-Received: by 10.46.41.6 with SMTP id u6mr4071209lje.130.1509365969145; Mon, 30 Oct 2017 05:19:29 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s8sm2546293lfk.50.2017.10.30.05.19.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Oct 2017 05:19:28 -0700 (PDT) From: "Valery Smyslov" To: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: In-Reply-To: Date: Mon, 30 Oct 2017 15:19:27 +0300 Message-ID: <116b01d35179$5545b240$ffd116c0$@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: AQJvoYhNuzlFapr5r+XuB80i/J+14aHDdjPg Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 12:19:33 -0000 Hi, > All, > > This message starts a Working Group Last Call (WGLC) for draft-mglt-ipsecme-implicit-iv-04. > > The version to be reviewed can be found here: https://www.ietf.org/id/draft-mglt-ipsecme-implicit-iv-04.txt. > > Please send your comments, questions, and edit proposals to the WG mail list until November 9th, 2017. If > you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track > RFC please send a short message stating this. > > Best Regards, > Dave and Tero I found document almost ready. There are a couple of issues that should be addressed: 1. Abstract IPsec ESP sends an initialization vector (IV) or nonce in each packet, adding 8 or 16 octets. This assertion needs some clarification. The size of IV is generally variable, 8 or 16 octets are relevant only for the currently defined transforms. I suggest to rephrase this sentence: IPsec ESP sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. (or something like that) 2. IANA Considerations AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. This section limits assignment of new code points to the recommended suites provided in [I-D.ietf-ipsecme-rfc4307bis] and [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 - Encryption Algorithm Transform IDs are as defined below: The newly defined IIV transforms are not applicable for IKEv2 (because there is no unique per message field; Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). So, [I-D.ietf-ipsecme-rfc7321bis] (now RFC8247) must not be referenced here. Moreover, I'd like to express this prohibition more explicitly in IANA registry, instructing IANA to put "Not allowed" in the column "IKEv2 Reference" for these transforms: AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. This section limits assignment of new code points to the recommended suites provided in [I-D.ietf-ipsecme-rfc4307bis]. Note, that using implicit IV for these algorithms is defined for ESP only and is not allowed for protecting IKEv2 messages. IANA is requested to add the following transforms to the Transform Type 1 - Encryption Algorithm Transform IDs registry for IKEv2, setting "ESP Reference" to this document and marking "IKEv2 Reference" as "Not allowed": 3. Please, update references: [I-D.ietf-ipsecme-rfc7321bis] is now RFC8221 [I-D.yeung-g-ikev2] is now draft-yeung-g-ikev2-12 Regards, Valery. From nobody Mon Oct 30 05:28:48 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5313F665 for ; Mon, 30 Oct 2017 05:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 5gT2w4dkbSzt for ; Mon, 30 Oct 2017 05:28:46 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6603A13ACE5 for ; Mon, 30 Oct 2017 05:28:46 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id a69so14734213lfe.5 for ; Mon, 30 Oct 2017 05:28:46 -0700 (PDT) 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=ieAy6qKH+c+ZJej7T3VAO9942hQDU1VXfQ8YbUfwrBE=; b=Nk4jCP0pqVkIc4pB38qL7xrWJ0oIPVaf8HsnD5DuDW63Zv1uCJpmeSDEzvD8u25W1m 2aa+pKEDYUVUgBspdVxdVvDyckG7N/pB4DuEz7ftgXxu819Re3k/9Gl0DDaDZoROAvU9 BwXgXTsNJVrkrQ9zODm2Rwz0H/2j9Sp7q9dSOZEwi9nN3ooaDUj2lQfZU69aPG6BIIPX lFBongjYzee7mGPvvAhbpaydtBZm1OqmTbszXMkcaayKlOjsctMH20MN4AHOigYyVKGc TvPWNTJSJb1KOsVx5cSwi38eXC/i4kD0fIPsAJ4rk/kKnnCxGzEGijxvsrcVZ+iXFGQy b6sg== 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=ieAy6qKH+c+ZJej7T3VAO9942hQDU1VXfQ8YbUfwrBE=; b=QyZFz07X8/7kPZsweNRVFbol0YF/mcNUbkzsbcsNvyS7m1cMHP9PF63B/LAr8qPrfR mi6YRaohDQN7kvG1pAt9oYDHcMhpp+X+MaBALXz1K6fyMbfvVAkc1Rh2mvvchfzNx+TB JcwSm29EpoLE/ofvUGexOSt1saIHpaUmqNsqlLHEWcWLCB7bFDNiXlziGSnJk4jQZZ71 l7179UukOCbNNPWrxnxZGpoww3HPz53Sx1k0Jb8TV5n/pHEL/zp72SpOcbydLHb+JdW9 VqDazM0hpINs8jMVBYA4tpGjJiVIlmZVsCaKE9bmZRQjlsOICcpJuqCmy8Xd9OwlfEV7 AnhA== X-Gm-Message-State: AMCzsaXVOhkabzcUOZVxn7dYgJACKNCiC8ZRKzMGLYQ/uRO995151bEu QMzBKQjB4s4YnTHAA8tiCvDjRg== X-Google-Smtp-Source: ABhQp+QdLDl6TjPBTThh+2LpC06n4cR1FKZegMp5b7vvuv5cShjNRQfN2RXAqwSyrDixt1jADD9YGg== X-Received: by 10.46.22.83 with SMTP id 19mr3479861ljw.147.1509366524669; Mon, 30 Oct 2017 05:28:44 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q192sm3362025ljb.5.2017.10.30.05.28.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Oct 2017 05:28:44 -0700 (PDT) From: "Valery Smyslov" To: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: <116b01d35179$5545b240$ffd116c0$@gmail.com> In-Reply-To: <116b01d35179$5545b240$ffd116c0$@gmail.com> Date: Mon, 30 Oct 2017 15:28:43 +0300 Message-ID: <116c01d3517a$a071f840$e155e8c0$@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: AQJvoYhNuzlFapr5r+XuB80i/J+14QJ2Ejuaoa//diA= Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 12:28:47 -0000 Sorry, I made a typo (see below): > 2. IANA Considerations > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. This section > limits assignment of new code points to the recommended suites > provided in [I-D.ietf-ipsecme-rfc4307bis] and > [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 - > Encryption Algorithm Transform IDs are as defined below: > > The newly defined IIV transforms are not applicable for IKEv2 (because there is no unique per message field; > Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). So, [I-D.ietf-ipsecme-rfc7321bis] [I-D.ietf-ipsecme-rfc4307bis] of course. > (now RFC8247) must not be referenced here. Moreover, I'd like to express this prohibition > more explicitly in IANA registry, instructing IANA to put "Not allowed" in the column "IKEv2 Reference" > for these transforms: So, the correct text is: AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. This section limits assignment of new code points to the recommended suites provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using implicit IV for these algorithms is defined for ESP only and is not allowed for protecting IKEv2 messages. IANA is requested to add the following transforms to the Transform Type 1 - Encryption Algorithm Transform IDs registry for IKEv2, setting "ESP Reference" to this document and marking "IKEv2 Reference" as "Not allowed": Regards, Valery. From nobody Mon Oct 30 06:25:13 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D2813F44D for ; Mon, 30 Oct 2017 06:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 9qAxrKvDg0YC for ; Mon, 30 Oct 2017 06:25:10 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3999213F9D9 for ; Mon, 30 Oct 2017 06:25:06 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id l23so14921539lfk.10 for ; Mon, 30 Oct 2017 06:25:06 -0700 (PDT) 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=t9oCaXYGIcVTL23S/8kMECjQdtgrjGBNoz9Rm7GpqNc=; b=L3PRAYifEK1AQmRlGsA4hXQG4A8b4eQ+7Np2JozsNQ0g/Vg0EpYonXKoyEKXT2IyuZ 8jEqJpC3CzfB5/WzF9IGCjQ06ZKxrm9Zjnn4hO5s2owi1Vgq/1gaUXCME6knVGzfcg2x sXOaxEzOQbI9e5dFQ6+zr14uWR6QHDhve76qZY8HPDWHl698D3irUbTdlMdECZVwyhWO Of6Ew0sO3+frwPJg2EgyQqQ84SH6yrqs7VLziKNhFbW/qSJyjgHUsbGmqe9i8hjU4T3i 2kmNIGHrMuXo35/Tb0FwfWl4AHqZEGm2yYilTnj/IQjOkLFmnTTjx71kX0BmxUssQ8+Z Jcsw== 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=t9oCaXYGIcVTL23S/8kMECjQdtgrjGBNoz9Rm7GpqNc=; b=cvbOQm4z52yTcQly/a8I/BC9IJVJJjRSnEma03g6vGNpNtyWem4gFRm/6S8K28qStU K6LEkoDqs7qVNMoF2LB1/e295+RZSXl2Z8VxGizmyHGN1dddt26vDtyT+4EQ6Rwc8hFW NSS9z5HIl1WohxBu31AXbznTZ7eV5mMu9skCt7PcivTZfU3MpqHcpvYSipMaf/h32Gs7 2Fsxv0QWzOV9RvKawYXmuZYL7hydJtyjeCE9hB0HXqnZtP1rJiFr9D4OWf/SZpmwBKRp 5KDhElByDhuB3fIwZenpWCocNQr9MpyFCiVa0F+1btz2hHOrUa9MoD8ysMzSouPuZC/n pDKA== X-Gm-Message-State: AMCzsaWpOKTv5zEnm8c0v9uShziAsds/sIIiIJUhQB7zZAAFL2+PsbVn 69L6zT6nJCgf+k6gfCXWTF56/g== X-Google-Smtp-Source: ABhQp+S/yIvnrl2ndDR6C02spY9JfvkVZejAUwmHB1/xZ+/vrFWcIo5OmxpbNZtAHizexPjZU/kWHQ== X-Received: by 10.25.27.148 with SMTP id b142mr2900815lfb.130.1509369904334; Mon, 30 Oct 2017 06:25:04 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t9sm3502655ljb.91.2017.10.30.06.25.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Oct 2017 06:25:03 -0700 (PDT) From: "Valery Smyslov" To: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: In-Reply-To: Date: Mon, 30 Oct 2017 16:25:03 +0300 Message-ID: <119401d35182$7eef32c0$7ccd9840$@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: AQHfAf9nRx08DA9GljW2v1LJX/RcOKLk96SQ Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:25:11 -0000 Hi, > All, > > This message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme-split-dns-02. > > The version to be reviewed can be found here: https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-02.txt. > > Please send your comments, questions, and edit proposals to the WG mail list until November 9th, 2017. If > you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track > RFC please send a short message stating this. > > Best Regards, > Dave and Tero I found the document almost ready. A few editorial issues should be resolved. 1. Throughout the document attribute INTERNAL_DNSSEC_TA is often called INTERNAL_DNS_TA. Please, choose a single name :-) 2. Section 3.1 To indicate support for Split DNS, an initiator includes one more more INTERNAL_DNS_DOMAIN attributes as defined in Section 4 as part of the CFG_REQUEST payload. s/one more more/one or more 3. Section 4.1 o Domain Name (0 or more octets) - A Fully Qualified Domain Name used for Split DNS rules, such as example.com, in DNS presentation format and optionally using IDNA [RFC5890] for Internationalized Domain Names. The value is NOT null-terminated. Why NOT is in uppercase? It is not a RFC2119 word, I guess... 4. Section 4.2 o DNSKEY algorithm (0 or 1 octet) - Value from the IANA DNS Security Algorithm Numbers Registry o DS algorithm (0 or 1 octet) - Value from the IANA Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms Registry There are no such fields in the picture above. There are fields Algorithm and Digest Type. Please, make the names match those in the picture. 5. Section 6 INTERNAL_DNSSEC_TA directives MUST immediately follow an INTERNAL_DNS_DOMAIN directive. As the INTERNAL_DNSSEC_TA format itself does not contain the domain name, it relies on the preceding INTERNAL_DNS_DOMAIN to provide the domain for which it specifies the trust anchor. s/directives/attributes s/directive/attribute Regards, Valery. From nobody Tue Oct 31 07:50:22 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA11013F6BF for ; Tue, 31 Oct 2017 07:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 r1aV3dWYBSV1 for ; Tue, 31 Oct 2017 07:50:14 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EF213F654 for ; Tue, 31 Oct 2017 07:50:10 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id EFFDF1C0953 for ; Tue, 31 Oct 2017 15:50:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id D340518006C for ; Tue, 31 Oct 2017 15:50:08 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 15:50:08 +0100 From: To: "ipsec@ietf.org" Thread-Topic: draft-boucadair-ipsecme-ipv6-ipv4-codes Thread-Index: AdNSV4kHi0D1kj0WS2KalqWhxj42+A== Date: Tue, 31 Oct 2017 14:50:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0634FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0634FAOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:50:18 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0634FAOPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, As per a suggestion from Tero, I'm sending this message to the list to ask = for more feedback on this short draft: https://tools.ietf.org/html/draft-bo= ucadair-ipsecme-ipv6-ipv4-codes-00 FWIW, the draft includes an "update" header because I thought this can be g= eneralized to other use cases than the 3GPP case I'm interested in. Comments and guidance to get early codepoint assignments is more than welco= me. Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0634FAOPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

As per a suggestion from Tero, I’m se= nding this message to the list to ask for more feedback on this short draft= : https://tools.ietf.org/html/draft-boucadair-ipsecme-ipv6-ipv4-codes-00 =  

 

FWIW, the draft includes an “update&#= 8221; header because I thought this can be generalized to other use cases t= han the 3GPP case I’m interested in.

 

Comments and guidance to get early codepoin= t assignments is more than welcome.

 

Thank you.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A0634FAOPEXCLILMA3corp_-- From nobody Tue Oct 31 13:09:48 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8016913F66F for ; Tue, 31 Oct 2017 13:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Uw6GwpxpNHPv for ; Tue, 31 Oct 2017 13:09:46 -0700 (PDT) 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 E0E4113F602 for ; Tue, 31 Oct 2017 13:09:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yRMrm0Pb7zFBL; Tue, 31 Oct 2017 21:09:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509480584; bh=wd9bqGlX0aoHTX4FjQfPEJuKnUXVLxsMyhMgq+1qeU4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ugHJ2PiSBbNDWMTVXCkap0/7HbxB+3RzzdS4DJ5WhW2i7G99CXKt9jVhQp+m4KZNn EDiRfR8r+xgXbgv9NND5EldlS9bemJms6f38Vc0UtU2LC56IRDWR+q2GgQFdF5XZF5 l3EtTP7Z3Ocni77P37mWhg3KOhXpx2nYfKG/3JTM= 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 QR9nhkK2-CLv; Tue, 31 Oct 2017 21:09:42 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Oct 2017 21:09:42 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8B98062D29; Tue, 31 Oct 2017 16:09:41 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8B98062D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 827DF40D35AF; Tue, 31 Oct 2017 16:09:41 -0400 (EDT) Date: Tue, 31 Oct 2017 16:09:41 -0400 (EDT) From: Paul Wouters To: mohamed.boucadair@orange.com cc: "ipsec@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0634FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0634FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 20:09:47 -0000 On Tue, 31 Oct 2017, mohamed.boucadair@orange.com wrote: > As per a suggestion from Tero, I’m sending this message to the list to ask for more feedback on this short draft: https://tools.ietf.org/html/draft-boucadair-ipsecme-ipv6-ipv4-codes-00   > > FWIW, the draft includes an “update” header because I thought this can be generalized to other use cases than the 3GPP case I’m interested in. > > Comments and guidance to get early codepoint assignments is more than welcome. It seems okay to return some more information in the errors on obtaining an internal IP address. I'm not sure I understand the meaning of SINGLE_AF_SUPPORTED. Does that imply the family must be the same as the IKE address family used? Or does it just mean you can only request v4 or v6 but not both _and_ it is independent of the address family used for this IKE exchange? That is, are you expecting 4in6 and 6in4 items if the IKE peer address family is one, and the INTERNAL_IP family is the other family? Maybe this is getting too combinatory, and the notify should be just a FAMILY_RESTRICTION type with a value that can be various things, so you can say v4only, v6only, internal=external, 4in6allowed, 6in4allowed ? Paul