From nobody Wed Aug 1 04:54:56 2018 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 24FBB130E71 for ; Wed, 1 Aug 2018 04:54:54 -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 4SFn6zlXETx7 for ; Wed, 1 Aug 2018 04:54:53 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 ADB39130E6A for ; Wed, 1 Aug 2018 04:54:52 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id 203-v6so16581889ljj.13 for ; Wed, 01 Aug 2018 04:54:52 -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=VgTVxAFb1eKizONfaQubtl8mdk7gD6w2Q41xsqlx7pM=; b=PG4u4BEaemqPSZZ5n+HHZoP/1ei99J0kDfpNHUb6DPkGdbW+oiDkRPXRr6FHmV270P Rd8ee3VbuC7w3zaoAzizowqkH4nYav47Awo2B1jACSy1RxDXoTTUeF9FC1AtO+tfhwYJ iRPvOGr6YVTf2HUcaZ5lemIofGU8Q+Qa5zPPlihR7t62Wm8irRKU0PQ8ORHlVgq6vD9C kNxt80YJH1U71YDvndJIc9tFKvbhyYR/jb5RR5BBwzEAzK1Ixur31zSmmQ1QTjVwkcnE 4OLeUl7Bx8kFcc7yKrQQxWTPn3j0J2/m+H720ptnXcaPlFuHUlnCA/RpXYy+hPD9LDK7 J6SA== 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=VgTVxAFb1eKizONfaQubtl8mdk7gD6w2Q41xsqlx7pM=; b=FsOrYoVsuQMLQzDIOVgkHR2oppB9Pxo0FDGudxIvDISYeTnQ+8bXu+8qRu4OWiiHXp 2dxqvJFAavxj+hJ1cY+KvjIZ3KmKl1M2iWC9irnuWO+gjZE3V9pheEXenwHj/Xid59FN p2xBVSGQmJZv/kIH/a7Ib1lgr6dUpXfgv66OLTnT1v8mD07kZS/xU1yHE8Mge2KTP9oJ PYyHFrAieXD1oz/2+WBS2ic8KeAA1E/lpEtHDaXmN5wCU0HowsLiEcCh6A1qDqZ1bfgg NqFlf/dDBMUCxNxL/fXrEEnX3KL8TwP2W1vEEXSFP6zxiAe++kNNLxldRdO7dmgfwDtq hecA== X-Gm-Message-State: AOUpUlE73JooJ6+LIoL3ZX8RA05Ny2gfrwgVxwCI2PDXmYLDhrIOR8R6 /wu0NI/VyGxCmjoyX+55AdZsL0sj X-Google-Smtp-Source: AAOMgpd1XSr6TdLYIU4k7Pr1J0Z6V0chs0IObR+DOUjqwWrLijoSH3aHZCTvXfeo6paOc2nOwxFBzg== X-Received: by 2002:a2e:8950:: with SMTP id b16-v6mr407263ljk.111.1533124490646; Wed, 01 Aug 2018 04:54:50 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m129-v6sm2358229lfe.50.2018.08.01.04.54.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Aug 2018 04:54:49 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , Cc: "'Vukasin Karadzic'" References: In-Reply-To: Date: Wed, 1 Aug 2018 14:54:44 +0300 Message-ID: <045601d4298e$711f5280$535df780$@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: AQF0EBBfQcHLbaz6ha/F+LhxM5/lOqVq9dfg Content-Language: ru Archived-At: Subject: Re: [IPsec] Mutual authnull to mutual authenticated upgrade X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 11:54:54 -0000 Hi, sorry for late reply. > We had to support the following deployment. > > A large group of nodes is deployed with mutual authnull. This > offers passive attack protection on the network. At a later > stage, nodes are given their certificate for authentication. > > The goal was to go from mutual authnull to mutual RSA. If either > node does not yet support authentication, both nodes use auth null. > > So we have the following possibilities: > > 1) authby=authnull -> authby=authnull > 2) authby=authnull,cert -> authby=authnull > 3) authby=authnull,cert -> authby=authnull,cert (must yield real authentication) > 4) authby=authnull -> authby=authnull,cert > > When all nodes have gotten a cert, you can remove authnull so end up with: > > 5) authby=cert -> authby=cert > > 1 and 5 are existing known working deployments. > > 2-4 have a scenario where you have to pick an IKE_AUTH method. Depending > on the responder you got it right or wrong. If wrong, you have to > restart IKE_INIT to try the other method. We wanted to do this IKE_AUTH > in 1 roundtrip without a restart of IKE_INIT. > > Note all these scenarions yield a symmetric authentication. It will be > either authnull or mutual "real" authentication (eg RSA or DigitalSignature) > > So what we ended up doing is similar to the NO_PPK_AUTH trick. We added > sending a notify N(AUTHNULL) (40960 private use number) to the IKE_AUTH > exchange on the initiator which is a notify containing an AUTH payload > using authnull. So this becomes: > > request --> IDi, [CERT+,] > [N(INITIAL_CONTACT),] > [N(AUTHNULL)] <----- New item > [[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,] > [IDr,] > AUTH, > [CP(CFG_REQUEST),] > [N(IPCOMP_SUPPORTED)+,] > [N(USE_TRANSPORT_MODE),] > [N(ESP_TFC_PADDING_NOT_SUPPORTED),] > [N(NON_FIRST_FRAGMENTS_ALSO),] > SA, TSi, TSr, > [V+][N+] > > > The IKE_AUTH response is unmodified. > > If the responder supports this payload, AND local policy can do > authentication, it will ignore this payload and use the regular AUTH > payload. If it only has a configuration for authnull, it will use the > N(AUTHNULL) as the received AUTH payload instead or the actual AUTH > payload. The responder will send back only a real AUTH payload. If the > initiator had N(AUTHNULL) but the responder can do regular authentication, > it will just send back an real authentication AUTH payload. If the > responder can only do authnull, it will send an authnull based AUTH > payload. The responder never sends a N(AUTHNULL) payload as we did > not need/want to support asymmetrical authentication where one part > is authnull and the other is not, as we either have a CA+EE cert for > ourselves AND the peer, or we only have authnull for everything. > > See our test cases: > > http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-03-authanon-anon/ > http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-02-anon-authanon/ > http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-01-authanon-authanon/ > > > My questions are: > > 1) Is this useful enough to write up as RFC ? I still believe that sending additional AUTH information in N(AUTHNULL) (as well as in N(NO_PPK_AUTH)) is a protocol hack. The proper way is to add a generic mechanism that would allow peers to announce authentication algorithms they support. Note that no negotiation is needed - it is sufficient to announce a list of auth methods, as it is currently takes place with hash functions. The N(NO_PPK_AUTH) is a bit different, since it is not a new authentication method, it is a modification of existing methods, so the hack in this case is forgivable :-) That said, I agree with Tero that if you allow AUTH_NULL, then announcing in addition any other (real) auth methods can be done on attacker's mercy only, as she can always remove them and downgrade IKE SA to AUTH_NULL. > 2) Are we correct with our assumption that you either end up on mutual > authnull or with mutual authentication, or do people believe there > is a use case for asymmetric authentication as well, in which case > the responder could also send AUTH plus N(AUTHNULL) I believe such use cases do have a right to exist. Regards, Valery. > Paul and Vukasin From nobody Fri Aug 3 11:20:24 2018 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 04FBB130DD2 for ; Fri, 3 Aug 2018 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcJiY3B5w95q for ; Fri, 3 Aug 2018 11:20:20 -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 0D1DD1292F1 for ; Fri, 3 Aug 2018 11:20:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41hwM35XHvz5Bd for ; Fri, 3 Aug 2018 20:20:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1533320415; bh=b69Ck6y8+X/2ubXEhN5wyG9j4OV7NMcj7EVrwYiU3E4=; h=From:Date:Subject:To; b=onRXz5AAVActC21oCmh2dIeEX2EG1S/lT65mmj2zwTsYkhmo2pZg1+plx10R0LOD/ VEVnrrgNk/ZY5/quLbkOpnSMxwJ8clrNebbymJa/wbgUCw/WHh2o9X9lAf5CpRSoku RGun1yTGnnABYvVVqzwBWbe4BNNlTr5HFmlWMM4c= 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 i5S-T6yAjU26 for ; Fri, 3 Aug 2018 20:20:08 +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, 3 Aug 2018 20:20:07 +0200 (CEST) Received: from [192.168.1.116] (23-118-109-227.lightspeed.sntcca.sbcglobal.net [23.118.109.227]) (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 5BFC7940 for ; Fri, 3 Aug 2018 14:20:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5BFC7940 Content-Type: multipart/alternative; boundary=Apple-Mail-46A43F9D-EB55-45F6-8FB4-8C8E40F5338C Content-Transfer-Encoding: 7bit From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Fri, 3 Aug 2018 11:20:00 -0700 Message-Id: To: ipsec@ietf.org X-Mailer: iPhone Mail (15G77) Archived-At: Subject: [IPsec] draft-annu-t2trg-ike-for-wsn-security-00 - ike for wsn security X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 18:20:22 -0000 --Apple-Mail-46A43F9D-EB55-45F6-8FB4-8C8E40F5338C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just ran into this, probably this group should have a look at it (I haven=E2= =80=99t yet myself) https://tools.ietf.org/html/draft-annu-t2trg-ike-for-wsn-security-00 ike for wsn security INTERNET-DRAFT Annu Intended Status: Standards Track NIT Delhi Expires: January 30, 2019 K.Verma NIT Delhi August 3, 2018 =20 =20 draft-annu-t2trg-ike-for-wsn-security-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Annu, K.Verma Expires January 30,2019 [Page 1] Sent from my phone= --Apple-Mail-46A43F9D-EB55-45F6-8FB4-8C8E40F5338C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
draft-annu-t2trg-ike-for-wsn-security-00 - ike for wsn se= curity
Just ran into this, probably this g= roup should have a look at it (I haven=E2=80=99t yet myself)



https://tools.ietf.org/html/draft-annu-t2trg-ike-= for-wsn-security-00

ik= e for wsn security

INTERNET-DRAFT          =
                                  Annu
Intended Status: Standards Track                          NIT Delhi
Expires: January 30, 2019                                 K.Verma
                                                          NIT Delhi

                                                       August 3, 2018

                             
                   
draft-annu-t2trg-ike-for-wsn-security-00.txt





Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.o=
rg/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shado=
w.html


Copyright and License Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the I=
ETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.iet=
f.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Annu, K.Verma  Expires January 30,2019     =
            [Page 1]


Sent from my phone
= --Apple-Mail-46A43F9D-EB55-45F6-8FB4-8C8E40F5338C-- From nobody Mon Aug 6 10:53:02 2018 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 C4A8F130E3B; Mon, 6 Aug 2018 10:52:53 -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.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <153357797373.26688.4125924694017213783@ietfa.amsl.com> Date: Mon, 06 Aug 2018 10:52:53 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-12.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:52:54 -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 : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-12.txt Pages : 13 Date : 2018-08-06 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-12 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-12 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 Aug 10 07:18:36 2018 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 6AFC1130DF7 for ; Fri, 10 Aug 2018 07:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 o5S66tlJnIlv for ; Fri, 10 Aug 2018 07:18:32 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 081AE129C6A for ; Fri, 10 Aug 2018 07:18:32 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id v14-v6so8458234wro.5 for ; Fri, 10 Aug 2018 07:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hdNj6mIjEQcI7jExW/3/hb2aOWbeoEpxDJhdxK/xvT4=; b=E1at8asutzzF5dhy/Crdbe4UymBriOG6LzTZ5j2nS7hxKFgwyx5Um6Peu0BJl8/Orn c7XUXVu7uSwo2aQY/mTyqFwl/YInBu0xtBLrAxuEyNsK6alOy2YfVIwt+VUdZqZjedDb xbrD/0tQlB0IOLJQ1IxKZszaHuV69PQLhcZA6dEXOtxgZ/J82lDQnFG7ODxoTMQ03y5D con62ZTEdtZD5Ci8HFw45IxtroDL4HlAPkBLFKfpIEDBQ/a8WneK/XIws35H44Euj08I DDZCk5OfA2KTWdZvHG9/Ku5VsTbiOC2wX45V3hGsWg2m8oYLfjLxQ8GfiEMo29W4mV6V 71EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=hdNj6mIjEQcI7jExW/3/hb2aOWbeoEpxDJhdxK/xvT4=; b=NFZaNiVY/4xPrg3VwLMGU0ss4IVFaIJeoaIyjgm5wxm0lShf2/oWlxfHjnpmE/P85o Hkl3WMPlV11EwiNUyc+LqE4UPgTdcAgxMLi+sHaFfrlg7DLQIzPsyBPydD+8WnELf+3P WezPkZuRTEMqL/QHKXREZZy5DGLpzrgfmUzoucFUyhHTddNVY9LUMnUub+y2PAZho0c5 iccEO1WnoGfPXXDM0XV/5NcmuvAZVx8n6LrvjSTBFBSYFtEYxuU3f9hafHRo57feO4od GDrxW0m77SRcB3Uuj1d56jGT7tPkiUvIJsawvtPpuhYlxfDH25mm7Zl+pU5CN/M4sqjr WkWw== X-Gm-Message-State: AOUpUlFSeKJdQC+u6Be3bGNd/uB2ITkvjCKN0ac6cgxNB5fkJgxXAt8Y j8hHYlYI2UhBuX613U+7+9BicI0phqt3rAZrV5hlhA== X-Google-Smtp-Source: AA+uWPzXEmfVu3GOV+lvjqSELEFABuFjD7cEQFo7b4INPcd4Cm0RTZZuBRT8ifCDVKzmjXKNOA505iYUfS1Jr4HDSqE= X-Received: by 2002:a5d:694e:: with SMTP id r14-v6mr4222243wrw.278.1533910710392; Fri, 10 Aug 2018 07:18:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:ef8f:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 07:18:29 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <153272356261.413.16107362846124064304.idtracker@ietfa.amsl.com> References: <153272356261.413.16107362846124064304.idtracker@ietfa.amsl.com> From: Behcet Sarikaya Date: Fri, 10 Aug 2018 09:18:29 -0500 Message-ID: To: ipsec@ietf.org Cc: Dirk.von-Hugo@telekom.de Content-Type: multipart/alternative; boundary="000000000000029bde0573156b53" Archived-At: Subject: [IPsec] Fwd: New Non-WG Mailing List: PidLoc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 14:18:33 -0000 --000000000000029bde0573156b53 Content-Type: text/plain; charset="UTF-8" IPSEC chairs: please approve this non-member post. A new IETF non-working group email list has been created. List address: PIdLoc@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/pidloc/ To subscribe: https://www.ietf.org/mailman/listinfo/pidloc Purpose: In IdLoc protocols like LISP, ILA, etc. separation between (fixed) Identifier and (dynamic) Location is proposed to find optimum path for data packets to/from moving devices The threats against privacy in IdLoc protocols include location privacy where if a third party can at any time determine the IP location of some identifier, then the device can at one point be IP geolocated and movement privacy where if a third party can determine that an identifier has changed locator(s) at time T, then even without knowing the particular locators before and after, it can correlate this movement event with other information to create a binding between the identifier and a person. Privacy and security work is needed both in control and data plane There is an existing draft https://www.ietf.org/id/ draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a starting point. The work is expected to clear the way for a wider acceptance/deployment of IdLoc protocol. This may open new application areas such as in future mobile networks. In future mobile networks more efficient differentiation of packet handling according to specific service demands (QoS) are expected. Traditional tunneling and encapsulation between IP addresses (= Id and/or Loc) have disadvantages --000000000000029bde0573156b53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IPSEC chairs: please approve this non-member post.


A new IETF non-working group email list has = been created.

List address: PIdLoc@ietf.org
Archive: https://mailarchive.ietf.org/arch/br= owse/pidloc/
To subscribe: https://www.ietf.org/mailman/listinf= o/pidloc

Purpose:
=C2=A0In IdLoc protocols like LISP, ILA, etc.=C2=A0 separation between (fix= ed)
Identifier and (dynamic) Location is proposed to find optimum path for data=
packets to/from moving devices

The threats against privacy in IdLoc protocols include

location privacy where if a third party can at any time determine the IP location of some identifier, then the device can at one point be IP
geolocated and

movement privacy where if a third party can determine that an identifier has changed locator(s) at time T, then even without knowing the
particular locators
before and after, it can correlate this movement event with other
information to create a binding between the identifier and a person.

Privacy and security work is needed both in control and data plane

There is an existing draft https://www.ietf.org/id/
draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a starting point.

The work is expected to clear the way for a wider acceptance/deployment
of IdLoc protocol. This may open new application areas such as in future mobile networks.

In future mobile networks more efficient differentiation of packet
handling according to specific service demands (QoS) are expected. Traditio= nal
tunneling and encapsulation between IP addresses (=3D Id and/or Loc) have disadvantages

--000000000000029bde0573156b53-- From nobody Fri Aug 10 08:10:05 2018 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 C49BB130E53 for ; Fri, 10 Aug 2018 08:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x72E0tLJGv4 for ; Fri, 10 Aug 2018 08:09:56 -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 C24AB130E14 for ; Fri, 10 Aug 2018 08:09:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41n7p90KNqzDRM; Fri, 10 Aug 2018 17:09:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1533913793; bh=E/1Nt204hCj1iaN8v3mygSAkZp6ataV7WS89sy2M3XY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=VhMj8qpdYYOpXAlYUiEV2NHahnrPJvBZ2IS8gQKrPtakHqP0U9R/0TiDKqsbU+Inq KPNMeKRgbiPXr+YCwQ/RQzb68wd9ruurAXzYMKcd+aF+PRvaEs4/GS+Ky4vC0w1CNW w3kj1lNwq7QLheP0ADmzmlEno63fAlh1JxRSs8wY= 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 pQele622bVjL; Fri, 10 Aug 2018 17:09:51 +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; Fri, 10 Aug 2018 17:09:49 +0200 (CEST) Received: from [193.111.228.72] (unknown [193.111.228.72]) (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 146D431C855; Fri, 10 Aug 2018 11:09:49 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 146D431C855 Content-Type: multipart/alternative; boundary=Apple-Mail-2D9BED09-5FC8-41E5-8559-9AC89BFA88DD Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Fri, 10 Aug 2018 11:09:48 -0400 Cc: ipsec@ietf.org, Dirk.von-Hugo@telekom.de Content-Transfer-Encoding: 7bit Message-Id: <67F39E63-D308-4FA2-9CC1-1BB3FF07D28D@nohats.ca> References: <153272356261.413.16107362846124064304.idtracker@ietfa.amsl.com> To: sarikaya@ieee.org Archived-At: Subject: Re: [IPsec] Fwd: New Non-WG Mailing List: PidLoc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 15:09:59 -0000 --Apple-Mail-2D9BED09-5FC8-41E5-8559-9AC89BFA88DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable None of this seems related to ipsec and things should be discussed elsewhere= . If there is a component related to IKE or IPsec, please clarify as your list= archive or the draft you link to provide information showing this to be on t= opic here. =20 Paul Sent from my phone > On Aug 10, 2018, at 10:18, Behcet Sarikaya wrote:= >=20 > IPSEC chairs: please approve this non-member post. >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: PIdLoc@ietf.org > Archive: https://mailarchive.ietf.org/arch/browse/pidloc/ > To subscribe: https://www.ietf.org/mailman/listinfo/pidloc >=20 > Purpose: > In IdLoc protocols like LISP, ILA, etc. separation between (fixed) > Identifier and (dynamic) Location is proposed to find optimum path for dat= a > packets to/from moving devices >=20 > The threats against privacy in IdLoc protocols include >=20 > location privacy where if a third party can at any time determine the IP > location of some identifier, then the device can at one point be IP > geolocated and >=20 > movement privacy where if a third party can determine that an identifier > has changed locator(s) at time T, then even without knowing the > particular locators > before and after, it can correlate this movement event with other > information to create a binding between the identifier and a person. >=20 > Privacy and security work is needed both in control and data plane >=20 > There is an existing draft https://www.ietf.org/id/ > draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a > starting point. >=20 > The work is expected to clear the way for a wider acceptance/deployment > of IdLoc protocol. This may open new application areas such as in future > mobile networks. >=20 > In future mobile networks more efficient differentiation of packet > handling according to specific service demands (QoS) are expected. Traditi= onal > tunneling and encapsulation between IP addresses (=3D Id and/or Loc) have > disadvantages >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-2D9BED09-5FC8-41E5-8559-9AC89BFA88DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit None of this seems related to ipsec and things should be discussed elsewhere.

If there is a component related to IKE or IPsec, please clarify as your list archive or the draft you link to provide information showing this to be on topic here.
 
Paul

Sent from my phone

On Aug 10, 2018, at 10:18, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

IPSEC chairs: please approve this non-member post.


A new IETF non-working group email list has been created.

List address: PIdLoc@ietf.org
Archive: https://mailarchive.ietf.org/arch/browse/pidloc/
To subscribe: https://www.ietf.org/mailman/listinfo/pidloc

Purpose:
 In IdLoc protocols like LISP, ILA, etc.  separation between (fixed)
Identifier and (dynamic) Location is proposed to find optimum path for data
packets to/from moving devices

The threats against privacy in IdLoc protocols include

location privacy where if a third party can at any time determine the IP
location of some identifier, then the device can at one point be IP
geolocated and

movement privacy where if a third party can determine that an identifier
has changed locator(s) at time T, then even without knowing the
particular locators
before and after, it can correlate this movement event with other
information to create a binding between the identifier and a person.

Privacy and security work is needed both in control and data plane

There is an existing draft https://www.ietf.org/id/
draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a
starting point.

The work is expected to clear the way for a wider acceptance/deployment
of IdLoc protocol. This may open new application areas such as in future
mobile networks.

In future mobile networks more efficient differentiation of packet
handling according to specific service demands (QoS) are expected. Traditional
tunneling and encapsulation between IP addresses (= Id and/or Loc) have
disadvantages

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--Apple-Mail-2D9BED09-5FC8-41E5-8559-9AC89BFA88DD-- From nobody Fri Aug 10 11:31:02 2018 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 47372130DF9; Fri, 10 Aug 2018 11:31:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk CC: David Waltermire , ipsecme-chairs@ietf.org, ekr@rtfm.com, ipsec@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-split-dns@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153392586021.25509.12754944357644196057.idtracker@ietfa.amsl.com> Date: Fri, 10 Aug 2018 11:31:00 -0700 Archived-At: Subject: [IPsec] Last Call: (Split DNS Configuration for IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 18:31:01 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Split DNS Configuration for IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Aug 10 11:46:28 2018 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 913EC130E9C for ; Fri, 10 Aug 2018 11:46:26 -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 OEXmGKM3HdLf for ; Fri, 10 Aug 2018 11:46:25 -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 4CABD130E99 for ; Fri, 10 Aug 2018 11:46:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41nDbx6sFbzDk8 for ; Fri, 10 Aug 2018 20:46:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1533926781; bh=hI7EUvIgCWk5ld0zSLL2uBpwziuCMxq1ndn28DTTmvY=; h=Date:From:To:Subject:In-Reply-To:References; b=Sirg6xGmz5LFeymK60JWCuFpNDjcFTBYuQoDZeylnlxC0eRIjLebd3ihT+iwV+M4i ojnY+bXLdoyerkL5zwlZKwLQJq61IvnNYQJTjltFFBsWI4DK7ARYhL3HZMbq8ZbUUY bI7gVhFSR/Yc1chHP88XU3WfL9AfdR7kjXeGFQZY= 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 iQIW75GvrjRv for ; Fri, 10 Aug 2018 20:46:20 +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, 10 Aug 2018 20:46:20 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7DF0731C855; Fri, 10 Aug 2018 14:46:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7DF0731C855 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 77A82409E30B for ; Fri, 10 Aug 2018 14:46:19 -0400 (EDT) Date: Fri, 10 Aug 2018 14:46:19 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <038701d41375$4a5bab50$df1301f0$@gmail.com> <4ce0380da4d147bb98d80dbc71315a68@XCH-RTP-006.cisco.com> <002201d4145d$cdd13160$69739420$@gmail.com> <055c01d41f6a$dc6e7d50$954b77f0$@gmail.com> <094A8A21-D156-460E-B011-910F1BFC756F@isara.com> <0ac101d42417$d8f83560$8ae8a020$@gmail.com> <3cdc26c904714c7ca907cea8bca99aab@XCH-RTP-006.cisco.com> 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] IKE_AUX comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 18:46:27 -0000 On Thu, 26 Jul 2018, Daniel Van Geest wrote: > I do have one issue I’ve been pondering, though; we do an IKE_AUX exchange, and then follow it up with an IKE_AUTH I agree, the name is not the best for verbal language. > I have the same issue when discussing the draft.  Off the top of my head, IKE_PRE_AUTH could work. I think IKE_PRE_AUTH is indeed better. Other name could be: IKE_SUPP[LEMENT] or IKE_INIT_SUPP[LEMENT] Paul From nobody Mon Aug 13 07:27:50 2018 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 80843130F3A for ; Mon, 13 Aug 2018 07:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 IXDdoMMYoQfn for ; Mon, 13 Aug 2018 07:27:46 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 30CEA130EDC for ; Mon, 13 Aug 2018 07:27:46 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id g1-v6so14475187wru.2 for ; Mon, 13 Aug 2018 07:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eDujQVSSvlLUriH93DrSWSKeKoHpgPCmAbfGuAJOWwU=; b=YlseoXWWjAqcWktxYGQWjKHncFksKnz5gYOjJOP7Moqx9gUrb98LSx64QQvGNhm1bE G2pdOCujBEp21oZ4DtwdjNWl0zME8jdPXyd1pli87n0i8/qt9Yf6kAMTSUYSUPGCuEhV 4iQMcONOgnymedHM0a4KStob5sSE6m4cNXm7nGTo9xsh2Np3Exl+Wvt4lZHqsVlokP5G RsjRL5GRbmLRY7klqwkTJKd50Y2jTHC7xTRW38ckoQx5/6a6hk4gQKTkJrHL2LWNykJg ZVZGZu3HDrinw+ER4d0hRPW4Gpv4RUqaodS7/YAOb/HBVTTuCvHbigKTMQ5cMsOFFLCe KCUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=eDujQVSSvlLUriH93DrSWSKeKoHpgPCmAbfGuAJOWwU=; b=L4hCtEnfuCbZqiVuwVG68JvWNr59NWzJBQ+QydFQel8zwtF8539jbR35ewCkjZgy0G HeeSHe0YnNHkJTbhLs5AiUNrtBG0GgZ7Qap45hB6eZcmkFHyXF+FLRThv7IJHaJ3lcqd uF/2E4p+dNgQEeG8khFCEmfXMUSbzwdgQOgUTWDNPUFX1w70syPYyYd/QOLDDb5Y+eQF 3FVLz76z81xG35fbcev5SSay8RFSjCFb9CQITnyQdTpdeCQjX6IxxR4Gz26+q8vkPhQK H300zRaL4VMIi56m21vzpkAkA/rM/u0qrGH0OVlZf/LBP0itnZk6BhKxSwuZD3xazfuA 38tw== X-Gm-Message-State: AOUpUlHHr3N80ol5h2bRlz4U+hkyXettprZdM7GNhDmfe26IG/YU6Tkc KS85+rqtQmBwy25iufoh4gB+8tPwIjhFxBWpuCk= X-Google-Smtp-Source: AA+uWPyEoJeEvchwQG5Aqh9pWrosMGfydk6y5KfU+gSnxQbJ2AdNArk7Mn/qWtXva9N4K7mtqS/8DY6vshowqVhFK7Q= X-Received: by 2002:adf:c5c5:: with SMTP id v5-v6mr10916347wrg.30.1534170464702; Mon, 13 Aug 2018 07:27:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:ef8f:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 07:27:43 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <67F39E63-D308-4FA2-9CC1-1BB3FF07D28D@nohats.ca> References: <153272356261.413.16107362846124064304.idtracker@ietfa.amsl.com> <67F39E63-D308-4FA2-9CC1-1BB3FF07D28D@nohats.ca> From: Behcet Sarikaya Date: Mon, 13 Aug 2018 09:27:43 -0500 Message-ID: To: Paul Wouters Cc: ipsec@ietf.org, Dirk.von-Hugo@telekom.de Content-Type: multipart/alternative; boundary="00000000000092d8e7057351e5b6" Archived-At: Subject: Re: [IPsec] Fwd: New Non-WG Mailing List: PidLoc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 14:27:49 -0000 --00000000000092d8e7057351e5b6 Content-Type: text/plain; charset="UTF-8" Hi Paull, pidloc is a new non-WG list, we are looking for mainly privacy and also security experts to join the list. Whether or not IKE/ipsec related we will see, right now we just have sort-of Problem Statement document and we will go from there. We encourage all interested parties to subscribe. Behcet On Fri, Aug 10, 2018 at 10:09 AM, Paul Wouters wrote: > None of this seems related to ipsec and things should be discussed > elsewhere. > > If there is a component related to IKE or IPsec, please clarify as your > list archive or the draft you link to provide information showing this to > be on topic here. > > Paul > > Sent from my phone > > On Aug 10, 2018, at 10:18, Behcet Sarikaya wrote: > > IPSEC chairs: please approve this non-member post. > > > A new IETF non-working group email list has been created. > > List address: PIdLoc@ietf.org > Archive: https://mailarchive.ietf.org/arch/browse/pidloc/ > To subscribe: https://www.ietf.org/mailman/listinfo/pidloc > > Purpose: > In IdLoc protocols like LISP, ILA, etc. separation between (fixed) > Identifier and (dynamic) Location is proposed to find optimum path for data > packets to/from moving devices > > The threats against privacy in IdLoc protocols include > > location privacy where if a third party can at any time determine the IP > location of some identifier, then the device can at one point be IP > geolocated and > > movement privacy where if a third party can determine that an identifier > has changed locator(s) at time T, then even without knowing the > particular locators > before and after, it can correlate this movement event with other > information to create a binding between the identifier and a person. > > Privacy and security work is needed both in control and data plane > > There is an existing draft https://www.ietf.org/id/ > draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a > starting point. > > The work is expected to clear the way for a wider acceptance/deployment > of IdLoc protocol. This may open new application areas such as in future > mobile networks. > > In future mobile networks more efficient differentiation of packet > handling according to specific service demands (QoS) are expected. > Traditional > tunneling and encapsulation between IP addresses (= Id and/or Loc) have > disadvantages > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --00000000000092d8e7057351e5b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paull,

pidloc is a n= ew non-WG list, we are looking for mainly privacy and also security experts= to join the list.
Whether or not IKE/ipsec= related we will see, right now we just have sort-of Problem Statement docu= ment and we will go from there.

<= div class=3D"gmail_extra">We encourage all interested parties to subscribe.=

Behce= t
On Fri, Aug 10, 2018 at 10:09 AM, Paul Wout= ers <paul@nohats.ca> wrote:
<= div dir=3D"auto">None of this seems related to ipsec and things should be d= iscussed elsewhere.

If there is a component related to I= KE or IPsec, please clarify as your list archive or the draft you link to p= rovide information showing this to be on topic here.
=C2=A0
=
Paul

= Sent from my phone

On Aug 10, 2018, at= 10:18, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

IPSEC chairs: please approve this non-= member post.


A new IETF non-working g= roup email list has been created.

List address: PIdLoc@i= etf.org
Archive: https://mailarchive.ietf.org/arch/br= owse/pidloc/
To subscribe: https://www.ietf.org/mailman/listinf= o/pidloc

Purpose:
=C2=A0In IdLoc protocols like LISP, ILA, etc.=C2=A0 separation between (fix= ed)
Identifier and (dynamic) Location is proposed to find optimum path for data=
packets to/from moving devices

The threats against privacy in IdLoc protocols include

location privacy where if a third party can at any time determine the IP location of some identifier, then the device can at one point be IP
geolocated and

movement privacy where if a third party can determine that an identifier has changed locator(s) at time T, then even without knowing the
particular locators
before and after, it can correlate this movement event with other
information to create a binding between the identifier and a person.

Privacy and security work is needed both in control and data plane

There is an existing draft https://www.ietf.org/id/
draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a starting point.

The work is expected to clear the way for a wider acceptance/deployment
of IdLoc protocol. This may open new application areas such as in future mobile networks.

In future mobile networks more efficient differentiation of packet
handling according to specific service demands (QoS) are expected. Traditio= nal
tunneling and encapsulation between IP addresses (=3D Id and/or Loc) have disadvantages

_______= ________________________________________
IPsec mailing= list
I= Psec@ietf.org
https://www.ietf.org/mailman/listinfo= /ipsec

--00000000000092d8e7057351e5b6-- From nobody Mon Aug 13 10:18:41 2018 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 A2884130FA2; Mon, 13 Aug 2018 10:18:39 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj-8_HcJA1iS; Mon, 13 Aug 2018 10:18:38 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC17130FA6; Mon, 13 Aug 2018 10:18:37 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BC2CB91A2FC3; Mon, 13 Aug 2018 18:18:32 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 13 Aug 2018 18:18:34 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML702-CHM.china.huawei.com ([169.254.4.45]) with mapi id 14.03.0399.000; Mon, 13 Aug 2018 10:18:27 -0700 From: Linda Dunbar To: IPsecME WG , "i2nsf@ietf.org" , "David Carrel (carrel)" , "Brian Weis (bew)" Thread-Topic: questions and comments to drat-carrel-ipsecme-controller-ike-00 Thread-Index: AdQzJnFoUIG14rlySeOdz3p0yhsQ5A== Date: Mon, 13 Aug 2018 17:18:25 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0DADDC@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.180.231] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0DADDCsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] questions and comments to drat-carrel-ipsecme-controller-ike-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 17:18:40 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B0DADDCsjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David and Brian, In your draft, you assumed that Devices (e.g. A or B) sends its Public key = to the Controller. In some SD-WAN deployment, Controller manages & distributes the "Public key= " and "nonce" to each device to achieve Zero Touch Provisioning. Can you u= pdate the Figure 2 to reflect "Controller" sending "public key to devices"? Since this document is about Controller managed IKE, can we have a section = on recommendation of which attributes of IPsec are suitable to be distribut= ed by Controller? For example, - PAD (Peer Authentication Database) can be maintained by Controller= for deployment of devices with constraint resource - Public key & nonce managed by Controller The Rekey process in Section 4 describes some occasions with a device havin= g 2 or 4 SAs for each Peer (Section 4.2). Does it mean the receiving node h= as to use two different decryption keys? How does the receiving node know w= hich one the sender actually used? The entire Section 4 description is no different from scenario of two peers= ' direct communication (i.e. without Controller being present), is it corre= ct? Thank you very much Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F66B0DADDCsjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David and Brian,

 

In your draft, you assumed that Devices (e.g. A or B= ) sends its Public key to the Controller.

 

In some SD-WAN deployment, Controller manages & = distributes the “Public key” and “nonce” to each de= vice to achieve Zero Touch Provisioning.  Can you update the Figure 2 = to reflect “Controller” sending “public key to devices= 221;?

 

Since this document is about Controller managed IKE,= can we have a section on recommendation of which attributes of IPsec are s= uitable to be distributed by Controller? For example,

-     &= nbsp;  PAD (Peer Authentication Database) can be maintaine= d by Controller for deployment of devices with constraint resource

-     &= nbsp;  Public key & nonce managed by Controller

 

The Rekey process in Section 4 describes some occasi= ons with a device having 2 or 4 SAs for each Peer (Section 4.2). Does it me= an the receiving node has to use two different decryption keys? How does th= e receiving node know which one the sender actually used?

 

The entire Section 4 description is no different fro= m scenario of two peers’ direct communication (i.e. without Controlle= r being present), is it correct?

 

Thank you very much

 

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DADDCsjceml521mbxchi_-- From nobody Mon Aug 13 15:20:50 2018 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 58360130DFE for ; Mon, 13 Aug 2018 15:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFpCFvQlaEwp for ; Mon, 13 Aug 2018 15:20: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 3AA73126F72 for ; Mon, 13 Aug 2018 15:20:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41q9Ct6ZGlzK9S for ; Tue, 14 Aug 2018 00:20:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1534198842; bh=e2NaSxnqdHyMkvkatFHKwgyTm6W7sXwW/OuyRuIjc5k=; h=From:Date:Subject:References:To; b=otRlC2m7XNPuUDH+ISh64pZi7U2rC0VpWn2kLwiqTfy9E+OAgVejpWw+Rzz0Aau6f LycFPGyNBPjafDKdYmjo8kzMc9F7z87EL7MhopfAUuj5hJFtXxyBhFXPjRpoQ0pCKy h2Rn3lK91j94E62LLY/7YwVUyxaSfjAX833DhfO8= 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 QNvMWhgDo3C1 for ; Tue, 14 Aug 2018 00:20:40 +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 ; Tue, 14 Aug 2018 00:20:40 +0200 (CEST) Received: from [10.196.221.228] (unknown [206.108.148.91]) (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 EC515940 for ; Mon, 13 Aug 2018 18:20:38 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EC515940 From: Paul Wouters Content-Type: multipart/alternative; boundary=Apple-Mail-E7FBE005-5389-4E93-928A-70CB53305F80 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 13 Aug 2018 18:20:37 -0400 Message-Id: References: To: ipsec@ietf.org X-Mailer: iPhone Mail (15G77) Archived-At: Subject: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 22:20:49 -0000 --Apple-Mail-E7FBE005-5389-4E93-928A-70CB53305F80 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI, https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.= pdf Sent from my phone Begin forwarded message: >=20 > https://www.bleepingcomputer.com/news/security/cisco-patches-its-operating= -systems-against-new-ike-crypto-attack/ >=20 > Cisco Patches Its Operating Systems Against New IKE Crypto Attack > Catalin Cimpanu >=20 >=20 > Cisco, one of the world's largest vendor of networking equipment, released= security updates today to patch a vulnerability in the IOS and IOS XE opera= ting systems that run the vast majority of its devices. >=20 > The vulnerability is tracked as CVE-2018-0131 and is one of four CVE ident= ifiers for a new Bleichenbacher oracle cryptographic attack against the IKE (= Internet Key Exchange) protocol. >=20 > Patches address new cryptographic attack >=20 > This new attack is described is a recently published research paper entitl= ed "The Dan=C2=ADgers of Key Reuse: Prac=C2=ADtical At=C2=ADtacks on IPsec I= KE," set to be presented at the 27th Usenix Security Symposium later this we= ek in Baltimore, USA. =46rom the paper's abstract: >=20 > In this paper, we show that reusing a key pair across different versions a= nd modes of IKE can lead to cross-protocol authentication bypasses, enabling= the impersonation of a victim host or network by attackers. We exploit a Bl= eichenbacher oracle in an IKEv1 mode, where RSA encrypted nonces are used fo= r authentication. Using this exploit, we break these RSA encryption based mo= des, and in addition break RSA signature based authentication in both IKEv1 a= nd IKEv2. Additionally, we describe an offline dictionary attack against the= PSK (Pre-Shared Key) based IKE modes, thus covering all available authentic= ation mechanisms of IKE. >=20 > Researchers say their attack works against the IKEv1 implementations of Ci= sco (CVE-2018-0131), Hua=C2=ADwei (CVE-2017-17305), Cla=C2=ADvis=C2=ADter (C= VE-2018-8753), and ZyXEL (CVE-2018-9129). >=20 > The research team, made up of three academics from the Ruhr-University Boc= hum, Germany and two from the University of Opole, Poland, say they notified= vendors that had products vulnerable to this attack. >=20 > "All ven=C2=ADdors pu=C2=ADblis=C2=ADhed fixes or re=C2=ADmo=C2=ADved the p= ar=C2=ADti=C2=ADcu=C2=ADlar au=C2=ADthen=C2=ADti=C2=ADca=C2=ADti=C2=ADon me=C2= =ADthod from their de=C2=ADvices=E2=80=99 firm=C2=ADwares in re=C2=ADs=C2=AD= pon=C2=ADse to our re=C2=ADports," researchers said. >=20 > Cisco IOS and IOS XE affected, but not IOS XR >=20 > Cisco was by far the biggest vendor affected by this flaw, and the hardest= hit. CVE-2018-0131 affects the company's main product, the IOS (Internetwor= king Operating System), and its Linux-based offshoot, IOS XE. >=20 > The IOS XR operating system, which runs on a different codebase and is use= d mainly for carrier-grade routers, is not affected. >=20 > Cisco released patches today for both OSes. The company says that any IOS a= nd IOS XE device that's configured with the "authentication rsa-encr" option= is vulnerable. >=20 > Attackers can recover VPN sessions >=20 > According to Cisco, this flaw "could allow an unauthenticated, remote atta= cker to obtain the encrypted nonces of an Internet Key Exchange Version 1 (I= KEv1) session." >=20 > "The vulnerability exists because the affected software responds incorrect= ly to decryption failures. An attacker could exploit this vulnerability send= ing crafted ciphertexts to a device configured with IKEv1 that uses RSA-encr= ypted nonces," Cisco said in a security advisory. >=20 > An attacker that has the ability to recover IKEv1 nonces can recover data s= ent via IPsec, the protocol at the base of most VPN traffic. With this in mi= nd, applying the Cisco patches is highly recommended. >=20 > Related Articles: >=20 > Get 66% off ProtonVPN Plus Subscriptions Deal >=20 > DNS Leak Fixed in Kaspersky VPN App for Android >=20 > Study: Law Enforcement Need Technical Skills, Not Backdoors >=20 > DOD to Move All Websites to HTTPS by the End of the Year >=20 > Many Bluetooth Implementations and OS Drivers Affected by Crypto Bug >=20 >=20 >=20 > Sent from my phone > _______________________________________________ > Security mailing list > Security@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/security --Apple-Mail-E7FBE005-5389-4E93-928A-70CB53305F80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI,

htt= ps://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf=

Sent from my phone

= Begin forwarded message:

Ci= sco Patches Its Operating Systems Against New IKE Crypto Attack

3D"Cisco

Cisco, one of the world's largest vendor of ne= tworking equipment, released security updates today to patch a vulnerability= in the IOS and IOS XE operating systems that run the vast majority of its d= evices.

The vulnerability is tracked as CVE-2018-0131 a= nd is one of four CVE identifiers for a new Bleichenbacher oracle cryptograp= hic attack against the IKE (Internet  Key E= xchange) protocol.

Patches= address new cryptographic attack

This new attack is described is a recently pub= lished research paper entitled "The Dan=C2=ADgers of Key Reuse: Prac=C2=ADtical At=C2=ADtacks on I= Psec IKE," set to be presented at the 27th Usenix Security Symposium lat= er this week in Baltimore, USA. =46rom the paper's abstract:

In this paper, we show that reusing a key pair= across different versions and modes of IKE can lead to cross-protocol authe= ntication bypasses, enabling the impersonation of a victim host or network b= y attackers. We exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA e= ncrypted nonces are used for authentication. Using this exploit, we break th= ese RSA encryption based modes, and in addition break RSA signature based au= thentication in both IKEv1 and IKEv2. Additionally, we describe an offline d= ictionary attack against the PSK (Pre-Shared Key) based IKE modes, thus cove= ring all available authentication mechanisms of IKE.

Researchers say their attack works against the= IKEv1 implementations of Cisco (CVE-2018-0131), Hua=C2=ADwei (CVE-2017-1730= 5), Cla=C2=ADvis=C2=ADter (CVE-2018-8753), and ZyXEL (CVE-2018-9129).

The research team, made up of three academics f= rom the Ruhr-University Bochum, Germany and two from the University of Opole= , Poland, say they notified vendors that had products vulnerable to this att= ack.

"All ven=C2=ADdors pu=C2=ADblis=C2=ADhed fixes= or re=C2=ADmo=C2=ADved the par=C2=ADti=C2=ADcu=C2=ADlar au=C2=ADthen=C2=ADt= i=C2=ADca=C2=ADti=C2=ADon me=C2=ADthod from their de=C2=ADvices=E2=80=99 fir= m=C2=ADwares in re=C2=ADs=C2=ADpon=C2=ADse to our re=C2=ADports," researcher= s said.

Cisco I= OS and IOS XE affected, but not IOS XR

Cisco was by far the biggest vendor affected b= y this flaw, and the hardest hit. CVE-2018-0131 affects the company's main p= roduct, the IOS (Internetworking Operating System), and its Linux-based offs= hoot, IOS XE.

The IOS XR operating system, which runs on a d= ifferent codebase and is used mainly for carrier-grade routers, is not affec= ted.

Cisco released patches today for both OSes. Th= e company says that any IOS and IOS XE device that's configured with the "au= thentication rsa-encr" option is vulnerable.

Attacke= rs can recover VPN sessions

According to Cisco, this flaw "could allow an u= nauthenticated, remote attacker to obtain the encrypted nonces of an Interne= t Key Exchange Version 1 (IKEv1) session."

"The vulnerability exists because the affected= software responds incorrectly to decryption failures. An attacker could exp= loit this vulnerability sending crafted ciphertexts to a device configured w= ith IKEv1 that uses RSA-encrypted nonces," Cisco said in a security advisory.

An attacker that has the ability to recover IK= Ev1 nonces can recover data sent via IPsec, the protocol at t= he base of most VPN traffic. With this in mind, applying the Cisco patches i= s highly recommended.



Sent from my phone<= /div>
_____________________= __________________________
Security mailing list
<= span>Security@lists.libreswa= n.org
https://lists.libreswan.org/mailman/listinfo/security
= --Apple-Mail-E7FBE005-5389-4E93-928A-70CB53305F80-- From nobody Tue Aug 14 01:13:26 2018 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 265C8130E47 for ; Tue, 14 Aug 2018 01:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DMmGFJn8r36j for ; Tue, 14 Aug 2018 01:13:22 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 8F377130E17 for ; Tue, 14 Aug 2018 01:13:21 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id u7-v6so14694596lji.3 for ; Tue, 14 Aug 2018 01:13:21 -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 :thread-index:content-language; bh=l3O7qaJMoJBiW5vDVfnNvOmwOMEMndeaRNsz5e56nkc=; b=EqTSr9F6Lf0TmiLZwlGFfXQD4J/1KL2XygiwEa4ccmcVDiCcSXOxJS4WhZvqil7m63 stLdh5BKInuzbvSCTKRWPeM1yfPuudGWdlgB9etdjjyt/1qbKDPy1XtDkk0MWDi78H9c 3NuIEEa2by/X9TU2O8VM77qQM1gp60xJfHA0+SrYnVPJXSDc6J9kLIVkEBoqumWVXfND Kv6vjQkDJl0PacxWH6nOmOsDQX9sLzc9IcSB/VLdI+r60f2ERyPLwsUTqCydWSuJ4jwv U0OidiAhJtFuipo6l97/BJpcnzSxfK+s8Cz0vRdkjipW45+HKO6QMxFMZhyi+1/YHs+U 0IJw== 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:thread-index:content-language; bh=l3O7qaJMoJBiW5vDVfnNvOmwOMEMndeaRNsz5e56nkc=; b=GMxEWddLGaLfEtfkhjuE02xjoT5+JdOtgx23sPDGoQAvH+VorTdkMGPw1EGyYNwSm/ E9PZALI9Z24lXzhWIp/PYSMr2n2NUL6ooRZoSra5hvXgFEfrcv7qJQjqMwF5GkcvZAIN QKTfRQCpVJ9h/VMbSIgfd5nOGnhO+j+QlW/YbgG6iGE5TlH7Ve/F/ze8YEqCf8NQ7ZLa M7D8T37Ql2/hSUJaI0r+UCIRu1ejc+01yAbNPxOE4VgFf582RaR/hCu30X7LbafZp68B qC4YLCv+q0aOx90yV42Qr+9LWSppmhbyZg+JOEiTqalF0UIM0wzeSmqHK+NQIbmasII5 ZrtQ== X-Gm-Message-State: AOUpUlE5dHk35/9n5BmTweQC9xJQbcjbJsiN603twDyX10GIGKRoOjCI 0wBmk4rv1KxD8u2Ef/zX7m3m1W4m X-Google-Smtp-Source: AA+uWPz6KxkZ4vcq4OPYNKMMmjrEcZfp+K6pMknlz25CFpwr+/dwrCa5PiO+MORYahW0eom4ewT6cQ== X-Received: by 2002:a2e:8:: with SMTP id 8-v6mr14299873lja.112.1534234399209; Tue, 14 Aug 2018 01:13:19 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 66-v6sm3468625ljz.8.2018.08.14.01.13.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Aug 2018 01:13:18 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , References: In-Reply-To: Date: Tue, 14 Aug 2018 11:13:16 +0300 Message-ID: <009a01d433a6$a7b63170$f7229450$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01D433BF.CD0F9E70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLaC5wLXsIP4wFI4Y7uPFPQ8k1oyQI2UR/BoqF/qBA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 08:13:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009B_01D433BF.CD0F9E70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 after reading the paper I still don=E2=80=99t understand why authors = mentioned IKEv2 there. Their example attack in Section 4.4 on (allegedly) IKEv2 in fact uses = secondary responder=20 supporting IKEv1 Public Key Encryption mode, without which the attack is = impossible (as far as=20 I understand). So, in my opinion, the authors are at least not accurate = in claiming that IKEv2 itself is susceptible. Or am I missing something? =20 Regards, Valery. =20 =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters Sent: Tuesday, August 14, 2018 1:21 AM To: ipsec@ietf.org Subject: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems = Against New IKE Crypto Attack =20 FYI, =20 https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-fels= ch.pdf Sent from my phone Begin forwarded message: https://www.bleepingcomputer.com/news/security/cisco-patches-its-operatin= g-systems-against-new-ike-crypto-attack/ Cisco Patches Its Operating Systems Against New IKE Crypto Attack Catalin = Cimpanu Cisco logo = = =20 Cisco, one of the world's largest vendor of networking equipment, = released security updates today to patch a vulnerability in the IOS and = IOS XE operating systems that run the vast majority of its devices. The vulnerability is tracked as CVE-2018-0131 and is one of four CVE = identifiers for a new Bleichenbacher oracle cryptographic attack against = the IKE (Internet = Key Exchange) protocol. Patches address new cryptographic attack This new attack is described is a recently published research paper = entitled " = The Dan=C2=ADgers of Key Reuse: Prac=C2=ADtical At=C2=ADtacks = on IPsec IKE," set to be presented at the 27th Usenix Security Symposium = later this week in Baltimore, USA. From the paper's abstract: In this paper, we show that reusing a key pair across different versions = and modes of IKE can lead to cross-protocol authentication bypasses, = enabling the impersonation of a victim host or network by attackers. We = exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA encrypted = nonces are used for authentication. Using this exploit, we break these = RSA encryption based modes, and in addition break RSA signature based = authentication in both IKEv1 and IKEv2. Additionally, we describe an = offline dictionary attack against the PSK (Pre-Shared Key) based IKE = modes, thus covering all available authentication mechanisms of IKE. Researchers say their attack works against the IKEv1 implementations of = Cisco (CVE-2018-0131), Hua=C2=ADwei (CVE-2017-17305), = Cla=C2=ADvis=C2=ADter (CVE-2018-8753), and ZyXEL (CVE-2018-9129). The research team, made up of three academics from the Ruhr-University = Bochum, Germany and two from the University of Opole, Poland, say they = notified vendors that had products vulnerable to this attack. "All ven=C2=ADdors pu=C2=ADblis=C2=ADhed fixes or re=C2=ADmo=C2=ADved = the par=C2=ADti=C2=ADcu=C2=ADlar = au=C2=ADthen=C2=ADti=C2=ADca=C2=ADti=C2=ADon me=C2=ADthod from their = de=C2=ADvices=E2=80=99 firm=C2=ADwares in re=C2=ADs=C2=ADpon=C2=ADse to = our re=C2=ADports," researchers said. Cisco IOS and IOS XE affected, but not IOS XR Cisco was by far the biggest vendor affected by this flaw, and the = hardest hit. CVE-2018-0131 affects the company's main product, the IOS = (Internetworking Operating System), and its Linux-based offshoot, IOS = XE. The IOS XR operating system, which runs on a different codebase and is = used mainly for carrier-grade routers, is not affected. Cisco released patches today for both OSes. The company says that any = IOS and IOS XE device that's configured with the "authentication = rsa-encr" option is vulnerable. Attackers can recover VPN sessions According to Cisco, this flaw "could allow an unauthenticated, remote = attacker to obtain the encrypted nonces of an Internet Key Exchange = Version 1 (IKEv1) session." "The vulnerability exists because the affected software responds = incorrectly to decryption failures. An attacker could exploit this = vulnerability sending crafted ciphertexts to a device configured with = IKEv1 that uses RSA-encrypted nonces," Cisco said in a = security advisory. An attacker that has the ability to recover IKEv1 nonces can recover = data sent via IPsec, the protocol = at the base of most VPN traffic. With this in mind, applying the Cisco = patches is highly recommended. Related Articles: = Get 66% off ProtonVPN Plus Subscriptions = Deal = DNS Leak Fixed in Kaspersky VPN App for Android = Study: Law Enforcement Need = Technical Skills, Not Backdoors = DOD to Move All Websites to HTTPS by = the End of the Year = Many Bluetooth = Implementations and OS Drivers Affected by Crypto Bug =20 Sent from my phone _______________________________________________ Security mailing list Security@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/security ------=_NextPart_000_009B_01D433BF.CD0F9E70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

after reading the paper I still don=E2=80=99t understand why authors = mentioned IKEv2 there.

Their example attack in Section 4.4 on (allegedly) IKEv2 in fact uses = secondary responder

supporting IKEv1 Public Key Encryption mode, without which the attack = is impossible (as far as

I understand). So, in my opinion, the authors are at least not = accurate in claiming

that IKEv2 itself is susceptible. Or am I missing = something?

 

Regards,

Valery.

 

 

From:= IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul = Wouters
Sent: Tuesday, August 14, 2018 1:21 AM
To: = ipsec@ietf.org
Subject: [IPsec] Fwd: [Security] Cisco Patches = Its Operating Systems Against New IKE Crypto = Attack

 

FYI,

 

https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/= 08/13/sec18-felsch.pdf

Sent from my phone


Begin forwarded = message:

Cisco Patches Its = Operating Systems Against New IKE Crypto = Attack

3D"Cisco

Cisco= , one of the world's largest vendor of networking equipment, released = security updates today to patch a vulnerability in the IOS and IOS XE = operating systems that run the vast majority of its = devices.

The = vulnerability is tracked as CVE-2018-0131 and is one of four CVE = identifiers for a new Bleichenbacher oracle cryptographic attack against = the IKE (Internet  Key = Exchange) protocol.

Patch= es address new cryptographic attack

This = new attack is described is a recently published research paper entitled = "The = Dan=C2=ADgers of Key Reuse: Prac=C2=ADtical At=C2=ADtacks on IPsec = IKE," set to be presented at the 27th Usenix Security = Symposium later this week in Baltimore, USA. From the paper's = abstract:

In = this paper, we show that reusing a key pair across different versions = and modes of IKE can lead to cross-protocol authentication bypasses, = enabling the impersonation of a victim host or network by attackers. We = exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA encrypted = nonces are used for authentication. Using this exploit, we break these = RSA encryption based modes, and in addition break RSA signature based = authentication in both IKEv1 and IKEv2. Additionally, we describe an = offline dictionary attack against the PSK (Pre-Shared Key) based IKE = modes, thus covering all available authentication mechanisms of = IKE.

Resea= rchers say their attack works against the IKEv1 implementations of Cisco = (CVE-2018-0131), Hua=C2=ADwei (CVE-2017-17305), Cla=C2=ADvis=C2=ADter = (CVE-2018-8753), and ZyXEL (CVE-2018-9129).

The = research team, made up of three academics from the Ruhr-University = Bochum, Germany and two from the University of Opole, Poland, say they = notified vendors that had products vulnerable to this = attack.

"= ;All ven=C2=ADdors pu=C2=ADblis=C2=ADhed fixes or re=C2=ADmo=C2=ADved = the par=C2=ADti=C2=ADcu=C2=ADlar = au=C2=ADthen=C2=ADti=C2=ADca=C2=ADti=C2=ADon me=C2=ADthod from their = de=C2=ADvices=E2=80=99 firm=C2=ADwares in re=C2=ADs=C2=ADpon=C2=ADse to = our re=C2=ADports," researchers said.

Cisco= IOS and IOS XE affected, but not IOS XR

Cisco= was by far the biggest vendor affected by this flaw, and the hardest = hit. CVE-2018-0131 affects the company's main product, the IOS = (Internetworking Operating System), and its Linux-based offshoot, IOS = XE.

The = IOS XR operating system, which runs on a different codebase and is used = mainly for carrier-grade routers, is not = affected.

Cisco= released patches today for both OSes. The company says that any IOS and = IOS XE device that's configured with the "authentication = rsa-encr" option is vulnerable.

Attac= kers can recover VPN sessions

Accor= ding to Cisco, this flaw "could allow an unauthenticated, remote = attacker to obtain the encrypted nonces of an Internet Key Exchange = Version 1 (IKEv1) session."

"= ;The vulnerability exists because the affected software responds = incorrectly to decryption failures. An attacker could exploit this = vulnerability sending crafted ciphertexts to a device configured with = IKEv1 that uses RSA-encrypted nonces," Cisco said in a security = advisory.

An = attacker that has the ability to recover IKEv1 nonces can recover data = sent via IPsec, the = protocol at the base of most VPN traffic. With this in mind, applying = the Cisco patches is highly recommended.

 

Sent from my = phone

_______________________________________________
Secu= rity mailing list
Security@lists.libreswan.org=
https://li= sts.libreswan.org/mailman/listinfo/security

------=_NextPart_000_009B_01D433BF.CD0F9E70-- From nobody Tue Aug 14 07:48:25 2018 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 1B7CB130DC8 for ; Tue, 14 Aug 2018 07:48:24 -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 lWJwQYlaMjb5 for ; Tue, 14 Aug 2018 07:48:21 -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 B989C12426A for ; Tue, 14 Aug 2018 07:48:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41qb7Q1nb2z36f; Tue, 14 Aug 2018 16:48:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1534258098; bh=8CZpOhX0+WEly+TICua0lz3Q4wlLNZyoHvALTEwsLcE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gu42zTYGKj+mtpzIPju7eiirKE75g/wMgvDgaAsLt1Lguhrfkvxq5hY0yd4E8lxaO mc00lK679Nlsnzv77REoPDDj7HrW4h+pUxYA2DyWqjNhsa/GOi1YfULO3jBv4gvACm bmlFOQAO1IlWMcZUEAA6qntIu0oAk1adLXCjWwoI= 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 2XEkA3XwxXId; Tue, 14 Aug 2018 16:48:15 +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; Tue, 14 Aug 2018 16:48:14 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4956A3797AF; Tue, 14 Aug 2018 10:48:13 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4956A3797AF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3FED74109296; Tue, 14 Aug 2018 10:48:13 -0400 (EDT) Date: Tue, 14 Aug 2018 10:48:13 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: ipsec@ietf.org In-Reply-To: <009a01d433a6$a7b63170$f7229450$@gmail.com> Message-ID: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> 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] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 14:48:24 -0000 On Tue, 14 Aug 2018, Valery Smyslov wrote: > after reading the paper I still don’t understand why authors mentioned IKEv2 there. > > Their example attack in Section 4.4 on (allegedly) IKEv2 in fact uses secondary responder > > supporting IKEv1 Public Key Encryption mode, without which the attack is impossible (as far as > > I understand). So, in my opinion, the authors are at least not accurate in claiming > > that IKEv2 itself is susceptible. Or am I missing something? I agree. I got limited information before publication (only about the weak PSK parts, not the RSA parts) and also voiced concerns about their IKEv2 claims. While in IKEv1 you have an oracle when the message can be decrypted only with the right PSK, in IKEv2 there is no such oracle, and you can only do this online and check for a response or failure on sending a packet. For the RSA case, it does depend on (Revised or not) Public Key Encryption mode instead of (RSA or ECDSA) Digital Signatures and the authors do state that IKEv2 is only 'vulnerable' if the RSA key is shared between IKEv1 and IKEv2. They also do some number games about how many packets you need to send and how fast, and I found their description confusing. I think they change SPI (cookies) and so these would be "new" exchanges so this has to be the DH component, but even if you break DH in IKEv2, you haven't broken the AUTH payload (or done anything to determine the PSK?). And we all have rate-limits in place so getting even 50,000 packets (and thus 50,000 half-open SA's) tested before a connection is aborted is not really feasable (although I guess it was for the vendors mentioned?) And finally, this is all about RSA v1.5 and does not work with RSA-PSS which is used when using RFC 7427 ? Paul From nobody Tue Aug 14 08:07:51 2018 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 31D28128CF3 for ; Tue, 14 Aug 2018 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 oBwkZYNWJvZb for ; Tue, 14 Aug 2018 08:07:47 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502D712426A for ; Tue, 14 Aug 2018 08:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4492; q=dns/txt; s=iport; t=1534259267; x=1535468867; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tPJ9mugfs3G9nktoukTmL8yL0t9h+PgYEUNR8Xrl01s=; b=OTZOeIz96PeQpd5vL+JfU2FOI6gNsPvYhHbmKaCbsUqNzpcoU7op7jAd Kp7drkhh2A9Q1EutyDkCCkZOUZ3TLY+jGUQ2HmBOUDTF54jEZu99xR0my 0t2CdM2ABjrAu39IJvU5N8V5R9DUNtk+Vl/QSsKmHA1Z1HvXBwD9ebQ6a s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgCd73Jb/5hdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPY38oCoNjiAqMO4INgz2FEY0/gXoLGAuESQIXgwAhNBg?= =?us-ascii?q?BAgEBAgEBAm0cDIU3AQEBAwEBASEROgsFBwQCAQgRBAEBAQICJgICAh8GCxU?= =?us-ascii?q?ICAIEAQ0FCIMbgWkDDQgPrjyBLocoDYMcBYELhUKBBoFBF4FBP4ESgmQugUE?= =?us-ascii?q?BgRRFAQGBOj6CaoJVAodghlSMCCsJAoxGgwiORYthhxECERSBJB04gVJwFTu?= =?us-ascii?q?CaYJNiEiFPm+JeYEugRsBAQ?= X-IronPort-AV: E=Sophos;i="5.53,238,1531785600"; d="scan'208";a="157375374" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2018 15:07:46 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w7EF7jvq000449 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2018 15:07:46 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Aug 2018 11:07:45 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Tue, 14 Aug 2018 11:07:45 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters , Valery Smyslov CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack Thread-Index: AQHUM1PtaqE/7gKyr02BcOTbC1BLP6S/KbQAgABuWYD//72LwA== Date: Tue, 14 Aug 2018 15:07:45 +0000 Message-ID: <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.com> References: <009a01d433a6$a7b63170$f7229450$@gmail.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.98.2.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.150, xch-rtp-010.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 15:07:49 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQc2VjIDxpcHNlYy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUGF1bCBXb3V0ZXJzDQo+IFNlbnQ6IFR1ZXNkYXks IEF1Z3VzdCAxNCwgMjAxOCAxMDo0OCBBTQ0KPiBUbzogVmFsZXJ5IFNteXNsb3YgPHNteXNsb3Yu aWV0ZkBnbWFpbC5jb20+DQo+IENjOiBpcHNlY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0lQ c2VjXSBGd2Q6IFtTZWN1cml0eV0gQ2lzY28gUGF0Y2hlcyBJdHMgT3BlcmF0aW5nIFN5c3RlbXMN Cj4gQWdhaW5zdCBOZXcgSUtFIENyeXB0byBBdHRhY2sNCj4gDQo+IE9uIFR1ZSwgMTQgQXVnIDIw MTgsIFZhbGVyeSBTbXlzbG92IHdyb3RlOg0KPiANCj4gPiBhZnRlciByZWFkaW5nIHRoZSBwYXBl ciBJIHN0aWxsIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYXV0aG9ycyBtZW50aW9uZWQNCj4gSUtF djIgdGhlcmUuDQo+ID4NCj4gPiBUaGVpciBleGFtcGxlIGF0dGFjayBpbiBTZWN0aW9uIDQuNCBv biAoYWxsZWdlZGx5KSBJS0V2MiBpbiBmYWN0IHVzZXMNCj4gPiBzZWNvbmRhcnkgcmVzcG9uZGVy DQo+ID4NCj4gPiBzdXBwb3J0aW5nIElLRXYxIFB1YmxpYyBLZXkgRW5jcnlwdGlvbiBtb2RlLCB3 aXRob3V0IHdoaWNoIHRoZSBhdHRhY2sNCj4gPiBpcyBpbXBvc3NpYmxlIChhcyBmYXIgYXMNCj4g Pg0KPiA+IEkgdW5kZXJzdGFuZCkuIFNvLCBpbiBteSBvcGluaW9uLCB0aGUgYXV0aG9ycyBhcmUg YXQgbGVhc3Qgbm90DQo+ID4gYWNjdXJhdGUgaW4gY2xhaW1pbmcNCj4gPg0KPiA+IHRoYXQgSUtF djIgaXRzZWxmIGlzIHN1c2NlcHRpYmxlLiBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPiAN Cj4gSSBhZ3JlZS4gSSBnb3QgbGltaXRlZCBpbmZvcm1hdGlvbiBiZWZvcmUgcHVibGljYXRpb24g KG9ubHkgYWJvdXQgdGhlIHdlYWsgUFNLDQo+IHBhcnRzLCBub3QgdGhlIFJTQSBwYXJ0cykgYW5k IGFsc28gdm9pY2VkIGNvbmNlcm5zIGFib3V0IHRoZWlyDQo+IElLRXYyIGNsYWltcy4NCg0KVGhl aXIgYXJndW1lbnQgaXMgJ2lmIHlvdSB1c2UgdGhlIHNhbWUgUlNBIGtleSBmb3IgSUtFdjEgUEtF IGF1dGhlbnRpY2F0aW9uLCAqYW5kKiBJS0V2MiBhdXRoZW50aWNhdGlvbiwgdGhlbiB5b3UgY2Fu IHVzZSB0aGUgQmxlaWNoZW5iYWNoZXIgT3JhY2xlIHdpdGhpbiBJS0V2MSB0byBhdHRhY2sgYSBj dXJyZW50IElLRXYyIGV4Y2hhbmdlJyAoc2VlIHNlY3Rpb24gNC40IG9mIHRoZSBwYXBlcikuDQoN Cj4gDQo+IFdoaWxlIGluIElLRXYxIHlvdSBoYXZlIGFuIG9yYWNsZSB3aGVuIHRoZSBtZXNzYWdl IGNhbiBiZSBkZWNyeXB0ZWQgb25seQ0KPiB3aXRoIHRoZSByaWdodCBQU0ssIGluIElLRXYyIHRo ZXJlIGlzIG5vIHN1Y2ggb3JhY2xlLCBhbmQgeW91IGNhbiBvbmx5IGRvIHRoaXMNCj4gb25saW5l IGFuZCBjaGVjayBmb3IgYSByZXNwb25zZSBvciBmYWlsdXJlIG9uIHNlbmRpbmcgYSBwYWNrZXQu DQo+IA0KPiBGb3IgdGhlIFJTQSBjYXNlLCBpdCBkb2VzIGRlcGVuZCBvbiAoUmV2aXNlZCBvciBu b3QpIFB1YmxpYyBLZXkgRW5jcnlwdGlvbg0KPiBtb2RlIGluc3RlYWQgb2YgKFJTQSBvciBFQ0RT QSkgRGlnaXRhbCBTaWduYXR1cmVzIGFuZCB0aGUgYXV0aG9ycyBkbyBzdGF0ZQ0KPiB0aGF0IElL RXYyIGlzIG9ubHkgJ3Z1bG5lcmFibGUnIGlmIHRoZSBSU0Ega2V5IGlzIHNoYXJlZCBiZXR3ZWVu DQo+IElLRXYxIGFuZCBJS0V2Mi4NCj4gDQo+IFRoZXkgYWxzbyBkbyBzb21lIG51bWJlciBnYW1l cyBhYm91dCBob3cgbWFueSBwYWNrZXRzIHlvdSBuZWVkIHRvDQo+IHNlbmQgYW5kIGhvdyBmYXN0 LCBhbmQgSSBmb3VuZCB0aGVpciBkZXNjcmlwdGlvbiBjb25mdXNpbmcuIEkgdGhpbmsgdGhleQ0K PiBjaGFuZ2UgU1BJIChjb29raWVzKSBhbmQgc28gdGhlc2Ugd291bGQgYmUgIm5ldyIgZXhjaGFu Z2VzIHNvIHRoaXMgaGFzIHRvDQo+IGJlIHRoZSBESCBjb21wb25lbnQsIGJ1dCBldmVuIGlmIHlv dSBicmVhayBESCBpbiBJS0V2Mix5b3UgaGF2ZW4ndCBicm9rZW4NCj4gdGhlIEFVVEggcGF5bG9h ZA0KDQpUaGlzIGlzIG5vdCBhIE1JVE0gYXR0YWNrLCB0aGlzIGlzIGFuIGltcGVyc29uYXRpb24g YXR0YWNrLg0KDQo+IChvciBkb25lIGFueXRoaW5nIHRvIGRldGVybWluZSB0aGUgUFNLPykuDQoN CkFjdHVhbGx5LCB0aGUgQmxlaWNoZW5iYWNoZXIgcGFydCBvZiB0aGUgcGFwZXIgaXMgYWRkcmVz c2luZyBzaWduYXR1cmUgYXV0aGVudGljYXRpb24gKGNlcnRpZmljYXRlcykuIA0KDQpUaGV5IGRv IG1lbnRpb24gYW4gb2ZmLWxpbmUgZGljdGlvbmFyeSBhdHRhY2sgYWdhaW5zdCBQU0sncywgaG93 ZXZlciB0aGF0J3MganVzdCBhIGNpdGUgb2YgcHJldmlvdXMgd29yay4NCg0KPiBBbmQgd2UgYWxs IGhhdmUgcmF0ZS1saW1pdHMgaW4gcGxhY2Ugc28gZ2V0dGluZyBldmVuIDUwLDAwMCBwYWNrZXRz IChhbmQgdGh1cw0KPiA1MCwwMDAgaGFsZi1vcGVuIFNBJ3MpIHRlc3RlZCBiZWZvcmUgYSBjb25u ZWN0aW9uIGlzIGFib3J0ZWQgaXMgbm90IHJlYWxseQ0KPiBmZWFzYWJsZSAoYWx0aG91Z2ggSSBn dWVzcyBpdCB3YXMgZm9yIHRoZSB2ZW5kb3JzIG1lbnRpb25lZD8pDQoNCklmIHRoZSBJS0V2MSBl eGNoYW5nZXMgZXJyb3Igb3V0LCBhbmQgaGVuY2UgYXJlIGNsb3NlZCwgdGhleSB3b3VsZG7igJl0 IGNvdW50IGFzIGhhbGYtb3BlbjsgdGhhdCB3b3VsZCBtYWtlIHRoZSBhdHRhY2sgbW9yZSBmZWFz aWJsZS4gIEkgZG9uJ3Qga25vdyBob3cgcmVhbCBJS0V2MSBpbXBsZW1lbnRhdGlvbnMgZGVhbCB3 aXRoIGl0Li4uDQoNCj4gDQo+IEFuZCBmaW5hbGx5LCB0aGlzIGlzIGFsbCBhYm91dCBSU0EgdjEu NSBhbmQgZG9lcyBub3Qgd29yayB3aXRoIFJTQS1QU1Mgd2hpY2ggaXMNCj4gdXNlZCB3aGVuIHVz aW5nIFJGQyA3NDI3ID8NCg0KQWN0dWFsbHksIGdvaW5nIHRvIGFuIGFsdGVybmF0ZSBSU0Egc2ln bmF0dXJlIG1ldGhvZCBkb2Vzbid0IHByb3RlY3QgeW91OyBpdCdzIHRoZSBwdWJsaWMga2V5IGVu Y3J5cHRpb24gaW4gSUtFdjEgdGhhdCBpcyB3aGF0J3MgY3JpdGljYWwgZm9yIHRoZSBhdHRhY2sg KGFuZCB0aGF0IHlvdSB1c2UgdGhlIHNhbWUgUlNBIGtleXMgZm9yIGJvdGgpLg0KDQo+IA0KPiBQ YXVsDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gSVBzZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K From nobody Tue Aug 14 08:33:35 2018 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 7B0EA130DD6 for ; Tue, 14 Aug 2018 08:33:31 -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=unavailable 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 6GK4XtwqJwtp for ; Tue, 14 Aug 2018 08:33:30 -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 16811130DD1 for ; Tue, 14 Aug 2018 08:33:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41qc7W0NFdzKJs; Tue, 14 Aug 2018 17:33:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1534260807; bh=2i2b5b2m6hVX1EAwPvS4PvLUeZU7Mz+ancL+wMLfSGM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B5dPW2LXwd3BIVYUdItGepy1O36t2G7fAbipuK3hOewFPIj+ZhYOBPCQNzS4VLmjP 24bwOdOcRz9UKUYg+kI29L4UEwavYC6DDdfmMHveSIruMXQ5pthlANXFc26Y8s5QVT XUr2BN+5+o1S0ES0Ka6tC1S0+CWzJVpfxcg6YcZc= 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 BoNYJF2-8AMj; Tue, 14 Aug 2018 17:33:26 +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; Tue, 14 Aug 2018 17:33:25 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EA3A33797AF; Tue, 14 Aug 2018 11:33:23 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EA3A33797AF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E29614009E6C; Tue, 14 Aug 2018 11:33:23 -0400 (EDT) Date: Tue, 14 Aug 2018 11:33:23 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: Valery Smyslov , "ipsec@ietf.org" In-Reply-To: <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.com> Message-ID: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.com> 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] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 15:33:32 -0000 On Tue, 14 Aug 2018, Scott Fluhrer (sfluhrer) wrote: >> They also do some number games about how many packets you need to >> send and how fast, and I found their description confusing. I think they >> change SPI (cookies) and so these would be "new" exchanges so this has to >> be the DH component, but even if you break DH in IKEv2,you haven't broken >> the AUTH payload > > This is not a MITM attack, this is an impersonation attack. If it is not a MITM, then the original connection will establish. If they then send packets with non-matching SPI's, the packets would simply be dropped or receive an INVALID_(_IKE_)SPI answer which would not give them any kind of oracle at all ? If they use the same IKE SPIs then what would they be attacking? They cannot send IKE_AUTH (or non-Quick Mode) packets? I mean they can, but any sane state machine will just drop them or send them an error that is completely independent of the content of their packet other then the Exchange Type. So I don't understand how they can learn anything from that. >> And we all have rate-limits in place so getting even 50,000 packets (and thus >> 50,000 half-open SA's) tested before a connection is aborted is not really >> feasable (although I guess it was for the vendors mentioned?) > > If the IKEv1 exchanges error out, and hence are closed, they wouldn’t count as half-open; that would make the attack more feasible. I don't know how real IKEv1 implementations deal with it... On the first packet sure, but not on a subsequent packet. That is why I find the paper confusing. Messing up SPI's shouldn't get you anything meaningful. It seems to conflate injecting the DH exchange and injecting after the DH exchange? >> And finally, this is all about RSA v1.5 and does not work with RSA-PSS which is >> used when using RFC 7427 ? > > Actually, going to an alternate RSA signature method doesn't protect you; it's the public key encryption in IKEv1 that is what's critical for the attack (and that you use the same RSA keys for both). Yes, but everyone already knew now to use the same keypair for different (v1.5 vs PSS) encryption types. Paul From nobody Tue Aug 14 08:35:35 2018 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 074B6130DD8 for ; Tue, 14 Aug 2018 08:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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] 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 zP9P899ad1UB for ; Tue, 14 Aug 2018 08:35:33 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5F4130DD1 for ; Tue, 14 Aug 2018 08:35:32 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id r13-v6so15706336ljg.10 for ; Tue, 14 Aug 2018 08:35: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=OFPUEHCD2H+ZgYxNWQLmB4ID4orJt5Uwiv05RBgOtuU=; b=o3xBbZ1sd2vqkuVwwtbaykxbiQNEqkdgV77bBlLOfW0fCClDHZIooPv/j9FpGetKAg 8A38lT1TdkL/cCWv9XR+wNMnDYZdRvUnKAI14/VUjlnRz+BntRycv/7DearLh3Z8/Pol G/WQTf50ksfk3DhVeXpKnyaZYOXHzIsLZStErAR2pc9i+A1DYQrNU6DXsX3OAdjCLoww Xe23fWrqL7+3h1U+frJoi0G+OxvnAvbYVv5jFSqYyyQ2ZhJ25vJ7NcpxhD6rk2rpNC42 IRxHUg+LjoEjiY4MlMC30LOC0CWb/1cXSuoam8iW0tIH7s2ztjNLY+ukvPMFBwCNQBjJ 3n3g== 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=OFPUEHCD2H+ZgYxNWQLmB4ID4orJt5Uwiv05RBgOtuU=; b=ocptMb5uOfFBLWFpvkqAEWWNqTHBDtyE1B6qf7eQB9xaQEWmY1iotcFagUr8imb1Z/ vCGwbq9Ru11rvRhs3EEC0aSso7GZScAuccVB+mPiDaIxKFeCjWzXxgFCzxxQUwLIszL8 IXtcC8/3JaOowIR5t2eKHKWQWB06M4kaYfgayo8NhK2QdBN5XNorxgHcqkRtrmXxzlXP VH+K1Lt/vkRrrV0jvqfQkADr0BTKwmgqC3DzUAm0RZxb8ZGQe7AgNgBCENvFvhqYvdb/ +yRKstu9/cZQpfGGofRCwM+adGhwqqMszTtjOVbeDeVHCQuTcXke6vpqe9R6mGqlbJdq jQBg== X-Gm-Message-State: AOUpUlG1V2veGFr8hjKc3PbN88ROHX40saern4NZgTwESHCYvF5WliiK u+S3RoiBuPNpw2jPLHzPkGZfYmqV X-Google-Smtp-Source: AA+uWPyw9hAmqR5WuTBqj5ZG8UkNnzUgitmgvZSST2mXtZmZI1WERgEE3SClmxYeCpJtz8/YWd9SeA== X-Received: by 2002:a2e:800e:: with SMTP id j14-v6mr13070226ljg.114.1534260930762; Tue, 14 Aug 2018 08:35:30 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n17-v6sm3592026ljb.82.2018.08.14.08.35.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Aug 2018 08:35:30 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'Paul Wouters'" Cc: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.com> In-Reply-To: <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.com> Date: Tue, 14 Aug 2018 18:35:28 +0300 Message-ID: <00fa01d433e4$6e09e7d0$4a1db770$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLaC5wLXsIP4wFI4Y7uPFPQ8k1oyQI2UR/BAmvxyUMBu6HI2wE7KLv1onbivrA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 15:35:34 -0000 Hi Scott, > Their argument is 'if you use the same RSA key for IKEv1 PKE authentication, *and* IKEv2 authentication, then > you can use the Bleichenbacher Oracle within IKEv1 to attack a current IKEv2 exchange' (see section 4.4 of the > paper). So, this is not an attack against IKEv2 per se. Without running IKEv1 code with enabled (R)PKE the attack is impossible. So in my opinion the authors are not accurate claiming that this is attack against IKEv2 - after breaking RSA with Bleichenbacher Oracle in IKEv1 PKE mode they can use the results against *any* protocol that reuses broken key, can't they? Is there any weakness in IKEv2 as a protocol except that its RSA key is usually the same as in IKEv1? I believe the authors didn't demonstrate such a weakness... Regards, Valery. From nobody Tue Aug 14 08:43:47 2018 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 8AD38130DD1 for ; Tue, 14 Aug 2018 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 g3xalAR0Xr5Y for ; Tue, 14 Aug 2018 08:43:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C72130DC8 for ; Tue, 14 Aug 2018 08:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1856; q=dns/txt; s=iport; t=1534261421; x=1535471021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RCa8T10qFNBIDsYy90BugVl6d2eq7ZxqjBU/mvFtBYI=; b=X+NdQSu0KLLjhltMz3m3SndRXMDBbw9qA3jPe8O3HnkpNkYbGg2fCpwf zaNdf1FnJIfcetiAu0g3BePe1DqNwpxQy4Z45ZmoLlzEZjnAti/Si99EQ T29ViUsBFjTCcshP+8xTEqAvMhBqt3yvtU60xu7r2i1uonlgIuPuCtudc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3BQDa93Jb/4ENJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgWIoCoNjlEaCDYM9hRGNP4F6C4RsAheDAyE1FwECAQE?= =?us-ascii?q?CAQECbSiFNwEBAQQjEUUMBAIBCBEEAQEBAgImAgICHxEVCAgCBA4FCIUEAxW?= =?us-ascii?q?udoEuhyYNgyGBC4VCgQaBQReBQT+BEoJkLoFBAYEUgj+CaoJVApo8KwkCjEa?= =?us-ascii?q?DCI5Fi2GHEQIRFIEkHwI0gVJwFYMkgk2OBm+LJ4EbAQE?= X-IronPort-AV: E=Sophos;i="5.53,238,1531785600"; d="scan'208";a="427613784" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2018 15:43:40 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w7EFheFK003035 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2018 15:43:41 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Aug 2018 11:43:40 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Tue, 14 Aug 2018 11:43:40 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters CC: Valery Smyslov , "ipsec@ietf.org" Thread-Topic: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack Thread-Index: AQHUM1PtaqE/7gKyr02BcOTbC1BLP6S/KbQAgABuWYD//72LwIAATxOA//+92TA= Date: Tue, 14 Aug 2018 15:43:40 +0000 Message-ID: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.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.98.2.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.146, xch-rtp-006.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 15:43:44 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBhdWwgV291dGVycyA8cGF1 bEBub2hhdHMuY2E+DQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxNCwgMjAxOCAxMTozMyBBTQ0K PiBUbzogU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpIDxzZmx1aHJlckBjaXNjby5jb20+DQo+IENj OiBWYWxlcnkgU215c2xvdiA8c215c2xvdi5pZXRmQGdtYWlsLmNvbT47IGlwc2VjQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIEZ3ZDogW1NlY3VyaXR5XSBDaXNjbyBQYXRjaGVzIEl0 cyBPcGVyYXRpbmcgU3lzdGVtcw0KPiBBZ2FpbnN0IE5ldyBJS0UgQ3J5cHRvIEF0dGFjaw0KPiAN Cj4gT24gVHVlLCAxNCBBdWcgMjAxOCwgU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpIHdyb3RlOg0K PiANCj4gPj4gVGhleSBhbHNvIGRvIHNvbWUgbnVtYmVyIGdhbWVzIGFib3V0IGhvdyBtYW55IHBh Y2tldHMgeW91IG5lZWQgdG8NCj4gPj4gc2VuZCBhbmQgaG93IGZhc3QsIGFuZCBJIGZvdW5kIHRo ZWlyIGRlc2NyaXB0aW9uIGNvbmZ1c2luZy4gSSB0aGluaw0KPiA+PiB0aGV5IGNoYW5nZSBTUEkg KGNvb2tpZXMpIGFuZCBzbyB0aGVzZSB3b3VsZCBiZSAibmV3IiBleGNoYW5nZXMgc28NCj4gPj4g dGhpcyBoYXMgdG8gYmUgdGhlIERIIGNvbXBvbmVudCwgYnV0IGV2ZW4gaWYgeW91IGJyZWFrIERI IGluDQo+ID4+IElLRXYyLHlvdSBoYXZlbid0IGJyb2tlbiB0aGUgQVVUSCBwYXlsb2FkDQo+ID4N Cj4gPiBUaGlzIGlzIG5vdCBhIE1JVE0gYXR0YWNrLCB0aGlzIGlzIGFuIGltcGVyc29uYXRpb24g YXR0YWNrLg0KPiANCj4gSWYgaXQgaXMgbm90IGEgTUlUTSwgdGhlbiB0aGUgb3JpZ2luYWwgY29u bmVjdGlvbiB3aWxsIGVzdGFibGlzaC4NCg0KV2hhdCBvcmlnaW5hbCBjb25uZWN0aW9uPyAgTWFs bGV0ICh0aGUgYXR0YWNrZXIpIGNsYWltcyB0byBiZSBBbGljZSAoYSB2YWxpZCBub2RlKSwgYW5k IGluaXRpYXRlcyB0byBCb2IuICBXaGVuIE1hbGxldCBuZWVkcyB0byBpbmNsdWRlIEFsaWNlJ3Mg c2lnbmF0dXJlIGluIHRoZSBleGNoYW5nZSwgaGUgcGVyZm9ybXMgYSBCbGVpdGNoZW5iYWNoZXIg YXR0YWNrIGFnYWluc3QgdGhlIHJlYWwgQWxpY2UsIHRvIGNvbXB1dGUgd2hhdCB0aGUgc2lnbmF0 dXJlIG5lZWRzIHRvIGJlLiAgVGhlbiwgTWFsbGV0IHVzZXMgdGhhdCBzaWduYXR1cmUgdG8gZm9v bCBCb2IgaW50byB0aGlua2luZyBoZSBpcyB0YWxraW5nIHRvIEFsaWNlLiAgU2luY2UgQWxpY2Ug bmV2ZXIgaGFkIGFueSBpZGVhIHNoZSB3YXMgc3VwcG9zZWQgdG8gYmUgdGFsa2luZyB0byBCb2Is IHNoZSdsbCBuZXZlciBzZW5kIGFueSBwYWNrZXRzIGhpcyB3YXkuLi4NCg0K From nobody Tue Aug 14 08:55:49 2018 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 3AF42130DC8 for ; Tue, 14 Aug 2018 08:55:48 -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=unavailable 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 wDSLwFIb0dYY for ; Tue, 14 Aug 2018 08:55:46 -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 BBB54130DE2 for ; Tue, 14 Aug 2018 08:55:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41qcdC1kKxzKLr; Tue, 14 Aug 2018 17:55:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1534262143; bh=DW5PrXXu3KQFWJ/kpZQBIgM7SE1Z1/0EJMtrkIuC+vg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GqKVABjDi+TX5ArlSVfkRsw1DwKlS41TIkfhJrhIaQx2ldiCQS8QfPG2YfMnPnO3/ 1tTDecjU5FavlsGF9868T5bQBD60+7Cqcf+sllwBUtFj/PCityA9XmGL5/bTnELxRH MGFGQvw46TIfGwn3KVTeD0tM5eIcDhg3Oxu7YrxE= 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 d5DTw2bMW3dC; Tue, 14 Aug 2018 17:55:42 +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; Tue, 14 Aug 2018 17:55:41 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B5CB835D63A; Tue, 14 Aug 2018 11:55:40 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B5CB835D63A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9CEE54023321; Tue, 14 Aug 2018 11:55:40 -0400 (EDT) Date: Tue, 14 Aug 2018 11:55:40 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: "ipsec@ietf.org" , Valery Smyslov In-Reply-To: Message-ID: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.com> 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] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 15:55:48 -0000 On Tue, 14 Aug 2018, Scott Fluhrer (sfluhrer) wrote: >>> This is not a MITM attack, this is an impersonation attack. >> >> If it is not a MITM, then the original connection will establish. > > What original connection? Mallet (the attacker) claims to be Alice (a valid node), and initiates to Bob. When Mallet needs to include Alice's signature in the exchange, he performs a Bleitchenbacher attack against the real Alice, to compute what the signature needs to be. Then, Mallet uses that signature to fool Bob into thinking he is talking to Alice. Since Alice never had any idea she was supposed to be talking to Bob, she'll never send any packets his way... How does Mallet get both Bob and Alice to use the same IKE SPI's ? AUTH is computed over: InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload) Note it contains SPIi and SPIr. Paul From nobody Tue Aug 14 10:31:23 2018 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 B22111277C8 for ; Tue, 14 Aug 2018 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 TlcfRBnZg6gx for ; Tue, 14 Aug 2018 10:31:19 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10674130E92 for ; Tue, 14 Aug 2018 10:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2843; q=dns/txt; s=iport; t=1534267879; x=1535477479; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t3K61HNCD1EJsdpVuopJB83sKjEj2fSb4Kx563I0fuw=; b=C+kLaxAZZpf0TS7vkXV7M2E/MkUgyFwLz9WZS/r4784PWq0JSfXLYotR 1qosj3E/R5zUB0z8kewFZmAFYEdHDJ2CJRW1d/hK+nk64WUGUSb8kUdmy I+hfF9WK2arEElPj/5fKkKndA7afVLzuo//iKbHptmHbaFxHJB3HnC5dQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AQC/EXNb/4sNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgWIoCpgpgg2ITo0/gXoLhGwCgxshNhYBAgEBAgEBAm0?= =?us-ascii?q?ohTcBAQEEOj8MBAIBCBEEAQEBHhAhER0IAgQOBQiFBAMVsDeHJQ2DIYZNgQa?= =?us-ascii?q?BQReBQT+BEoJkLoFBAYEUh34CkjiIBCsJAoxGgwiORYthhxECERSBJCQNJIF?= =?us-ascii?q?ScBWDJIJNjgZvizqBGwEB?= X-IronPort-AV: E=Sophos;i="5.53,239,1531785600"; d="scan'208";a="157446683" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2018 17:30:57 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w7EHUuxK003383 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2018 17:30:57 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Aug 2018 13:30:56 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Tue, 14 Aug 2018 13:30:56 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters CC: "ipsec@ietf.org" , Valery Smyslov Thread-Topic: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack Thread-Index: AQHUM1PtaqE/7gKyr02BcOTbC1BLP6S/KbQAgABuWYD//72LwIAATxOA//+92TCAAEhhAP//0Cww Date: Tue, 14 Aug 2018 17:30:56 +0000 Message-ID: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.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.98.2.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.149, xch-rtp-009.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 17:31:21 -0000 > -----Original Message----- > From: Paul Wouters > Sent: Tuesday, August 14, 2018 11:56 AM > To: Scott Fluhrer (sfluhrer) > Cc: ipsec@ietf.org; Valery Smyslov > Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems > Against New IKE Crypto Attack >=20 > On Tue, 14 Aug 2018, Scott Fluhrer (sfluhrer) wrote: >=20 > >>> This is not a MITM attack, this is an impersonation attack. > >> > >> If it is not a MITM, then the original connection will establish. > > > > What original connection? Mallet (the attacker) claims to be Alice (a = valid > node), and initiates to Bob. When Mallet needs to include Alice's signat= ure in > the exchange, he performs a Bleitchenbacher attack against the real Alice= , to > compute what the signature needs to be. Then, Mallet uses that signature > to fool Bob into thinking he is talking to Alice. Since Alice never had = any idea > she was supposed to be talking to Bob, she'll never send any packets his > way... >=20 > How does Mallet get both Bob and Alice to use the same IKE SPI's ? >=20 > AUTH is computed over: >=20 > InitiatorSignedOctets =3D RealMessage1 | NonceRData | MACedIDForI > GenIKEHDR =3D [ four octets 0 if using port 4500 ] | RealIKEHDR > RealIKEHDR =3D SPIi | SPIr | . . . | Length > RealMessage1 =3D RealIKEHDR | RestOfMessage1 > NonceRPayload =3D PayloadHeader | NonceRData > InitiatorIDPayload =3D PayloadHeader | RestOfInitIDPayload > RestOfInitIDPayload =3D IDType | RESERVED | InitIDData > MACedIDForI =3D prf(SK_pi, RestOfInitIDPayload) >=20 > Note it contains SPIi and SPIr. One of us is missing something. I believe that the attack under discussion was one where the attacker initi= ates the exchange with Bob, and follows the protocol faithfully with Bob (e= xcept where he gets the signature from). He needs to get the signature of = the above InitiatorSignedOctets; he knows what the string 'InitiatorSignedO= ctets' is; the only thing he can't do easily is generating that signature. He doesn't try to fool Alice into generating that signature directly; as yo= u point out, that would be difficult. Instead, what Bleichenbacher's attac= k does is allow him to compute what the signature would be, given an Oracle= that will tell him whether a specific ciphertext will decrypt into a valid= PKCS #1 padded plaintext (and making a large number of queries to the Orac= le). That is what he uses the connection with Alice for, to act as that Or= acle. It doesn't matter what SPI's he and Alice is using; the only thing h= e cares about in the Alice exchanges is whether certain carefully crafted R= SA ciphertexts decrypt to plausible RSA plaintexts, or generate errors duri= ng decryption. From nobody Tue Aug 14 11:17:03 2018 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 8EC6E130E9D for ; Tue, 14 Aug 2018 11:17:01 -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 KoyLSrftJOKq for ; Tue, 14 Aug 2018 11:16:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C821E130DE6 for ; Tue, 14 Aug 2018 11:16:56 -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 w7EIGcWX024523 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Aug 2018 21:16:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w7EIGcXp020866; Tue, 14 Aug 2018 21:16:38 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23411.7302.128219.423902@fireball.acr.fi> Date: Tue, 14 Aug 2018 21:16:38 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Paul Wouters'" , In-Reply-To: <009a01d433a6$a7b63170$f7229450$@gmail.com> References: <009a01d433a6$a7b63170$f7229450$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 71 min X-Total-Time: 251 min Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 18:17:02 -0000 Valery Smyslov writes: > after reading the paper I still don=E2=80=99t understand why authors > mentioned IKEv2 there. Of course they mention, just to get more exposure... > Their example attack in Section 4.4 on (allegedly) IKEv2 in fact > uses secondary responder supporting IKEv1 Public Key Encryption > mode, without which the attack is impossible (as far as I > understand). So, in my opinion, the authors are at least not > accurate in claiming that IKEv2 itself is susceptible. Or am I > missing something=3F That is my understanding also. On the other hand breaking signature method of the IKEv2 using IKEv1 oracle for the same RSA key is quite clever, and just points out that we must not use same key pair with different protocols / modes etc. We had this dicussion in when writing RFC8247 and recommending RFC7427 Digital Signatures using RSASSA-PSS. Some implementors used same key pair for both RSASSA-PKCS1-v1=5F5 and RSASSA-PSS. This paper just point= s you that you must not do that kind of things. The text about the IKEv2 pre-shared keys is just already known fact, and the RFC7296 warns about that several times, i.e., it does say use EAP for those, and for EAP you should not use the weak EAP methods, but instead you should use key generating methods. Also because it is known fact that IKEv2 shared secret authentication is vulnerable to the off-line dictionary attacks, we created RFC6467 for secure password methods. I.e., PACE (RFC6631), AugPAKE (RFC6628), abd Secure PSK Authentication (RFC6617) should all be protected against offline dictionary attacks. Anyways, I think proper fix would be to disable IKEv1 support completely, not to just disable RSA encryption mode... --=20 kivinen@iki.fi From nobody Tue Aug 14 11:40:08 2018 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 09823130DD2 for ; Tue, 14 Aug 2018 11:40:07 -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 Vkz8VAJiOmFt for ; Tue, 14 Aug 2018 11:40:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D43012785F for ; Tue, 14 Aug 2018 11:40:05 -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 w7EIdptJ001397 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Aug 2018 21:39:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w7EIdo0v002820; Tue, 14 Aug 2018 21:39:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23411.8694.960970.596609@fireball.acr.fi> Date: Tue, 14 Aug 2018 21:39:50 +0300 From: Tero Kivinen To: Paul Wouters Cc: Valery Smyslov , ipsec@ietf.org In-Reply-To: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 42 min X-Total-Time: 7 min Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 18:40:07 -0000 Paul Wouters writes: > I agree. I got limited information before publication (only about the > weak PSK parts, not the RSA parts) and also voiced concerns about their > IKEv2 claims. > > While in IKEv1 you have an oracle when the message can be decrypted only > with the right PSK, in IKEv2 there is no such oracle, and you can only > do this online and check for a response or failure on sending a packet. Not true. In IKEv2 you can do active attack to do offline dictionary attack. When Alice is trying to connect Bob, the Mallery will take those packets and respond to them, without forwarding anything to Bob. When Alice will send her IKE_AUTH payload, you can decrypt it as you were party in the IKE_SA_INIT, i.e., you know the Diffie-Hellman secrets. Then you simply calculate the InitiatorSignedOctets (you know everything needed there), and do for every "Shared Secret" in dictionary calculate prf( prf(Shared Secret, "Key Pad for IKEv2"), ) if that matches the AUTH payload Alice send you know the Shared Secret You can do that offline without any problems. That is why RFC7296 says the Shared Secret needs to be secure, deriving it from weak password etc is not secure (this is mentioned several times in RFC7296). Because this is known fact we did create Secure Password Framework RFC6467 to allow us to make secure password methods for IKEv2. From the Introduction: The IPsecME working group was chartered to provide for IKEv2 ([RFC5996]) a symmetric secure password authentication protocol that supports the use of low-entropy shared secrets, and to protect against off-line dictionary attacks without requiring the use of certificates or the Extensible Authentication Protocol (EAP). -- kivinen@iki.fi From nobody Tue Aug 14 11:50:58 2018 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 D9E44124BE5 for ; Tue, 14 Aug 2018 11:50:56 -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 YPOw-Hi2rwWg for ; Tue, 14 Aug 2018 11:50:55 -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 229CE12785F for ; Tue, 14 Aug 2018 11:50:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41qhWH5FQwzKLw; Tue, 14 Aug 2018 20:50:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1534272651; bh=MfmMyfPlEJjmhNTRDe7r3vHqImT80SL6c5M+XYGrt18=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jAr7vGTMeiSH1S8AZicgsK3r8owJs3acKoCZivsZU3dxIk/wIAS8wRgsL+/iED5fK +MlbFJgJaU3588A4cxi+Wmm/BOp2kuDonjxVwFQu/8hwUGaGE/cgmwNVZ1N609cz82 q7A/f+xFInIqy8dk4eow1ze8VBnuUcRK/T9z1l2U= 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 2wGyRKCmQLXc; Tue, 14 Aug 2018 20:50: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; Tue, 14 Aug 2018 20:50:48 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 83E4C35D63A; Tue, 14 Aug 2018 14:50:47 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 83E4C35D63A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 77A6F409598D; Tue, 14 Aug 2018 14:50:47 -0400 (EDT) Date: Tue, 14 Aug 2018 14:50:47 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: Valery Smyslov , ipsec@ietf.org In-Reply-To: <23411.8694.960970.596609@fireball.acr.fi> Message-ID: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <23411.8694.960970.596609@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] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 18:50:57 -0000 On Tue, 14 Aug 2018, Tero Kivinen wrote: > In IKEv2 you can do active attack to do offline dictionary attack. > When Alice is trying to connect Bob, the Mallery will take those > packets and respond to them, without forwarding anything to Bob. When > Alice will send her IKE_AUTH payload, you can decrypt it as you were > party in the IKE_SA_INIT, i.e., you know the Diffie-Hellman secrets. > Then you simply calculate the InitiatorSignedOctets (you know > everything needed there), and do > > for every "Shared Secret" in dictionary > calculate prf( prf(Shared Secret, "Key Pad for IKEv2"), > ) > if that matches the AUTH payload Alice send you know the Shared Secret > > You can do that offline without any problems. Ah yes, thanks. Paul From nobody Tue Aug 14 12:26:11 2018 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 A0423130E12 for ; Tue, 14 Aug 2018 12:26:09 -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 szOXM5GrI3Zf for ; Tue, 14 Aug 2018 12:26:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE11124BE5 for ; Tue, 14 Aug 2018 12:26:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A8D1220008; Tue, 14 Aug 2018 15:43:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2A6A510E7; Tue, 14 Aug 2018 15:26:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 283D4F0B; Tue, 14 Aug 2018 15:26:06 -0400 (EDT) From: Michael Richardson To: "Valery Smyslov" cc: "'Scott Fluhrer \(sfluhrer\)'" , "'Paul Wouters'" , ipsec@ietf.org In-Reply-To: <00fa01d433e4$6e09e7d0$4a1db770$@gmail.com> References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <4f2a35c542904311b2b189c33de69f85@XCH-RTP-006.cisco.com> <00fa01d433e4$6e09e7d0$4a1db770$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 19:26:10 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > So, this is not an attack against IKEv2 per se. Without running IKEv1 > code with enabled (R)PKE the attack is impossible. So in my opinion > the authors are not accurate claiming that this is attack against IKEv2 Agreed. They use IKEv1 RPKE to generate signatures, and then use them. We use the same keys for IKEv1 and IKEv2 because we want to transition to IKEv2 in as seamless a way as possible. Clearly, we could recommend replacing keys when a node has only IKEv2 neighbours, but at that point, we can turn off IKEv1 anyway, and the attack isn't possible anymore. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAltzLM0ACgkQgItw+93Q 3WUm4QgAnprGDgTyraWqPi4bIE0kLvcOcIhpX2m/klGtxhgFuxhhAf9LwS33bGTH RXGGPyjzc272ydb/1Ef87AP3/1mWKqU4lhHS9YwIDMneedNpfd5Ns/dEwnGJUSVE 78dfgAWSVK2HGbiZ5Tz0kNiASwVLVTFVDYTPtWHP20YqG1HpCJAUHQV0NC5Z49gm BRcs5CM9dlN9tmWAqLjNbuihWbS/a8Aoi46a69LvlnhQg7XCHuS3SObbh2F/acTa wl7GZex4m6COZzt98YM73Fry3YJq5VnF2sCmEhQLh6hstdnpwJD0DfkZw9Qt4BKQ 5lW98vijAnm5qq9krT1uA5viwZgM8A== =vYKV -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 14 12:27:03 2018 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 67E29130E14 for ; Tue, 14 Aug 2018 12:27:01 -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 7seY_MAhMx86 for ; Tue, 14 Aug 2018 12:27:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7C5130E12 for ; Tue, 14 Aug 2018 12:26:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AE62D20072; Tue, 14 Aug 2018 15:44:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 35A6210E7; Tue, 14 Aug 2018 15:26:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 34F75F0B; Tue, 14 Aug 2018 15:26:59 -0400 (EDT) From: Michael Richardson To: Tero Kivinen cc: "Valery Smyslov" , ipsec@ietf.org, "'Paul Wouters'" In-Reply-To: <23411.7302.128219.423902@fireball.acr.fi> References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <23411.7302.128219.423902@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 19:27:01 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > Anyways, I think proper fix would be to disable IKEv1 support > completely, not to just disable RSA encryption mode... +1 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAltzLQIACgkQgItw+93Q 3WU3aggAq7QrKNEzibcknzFc+F9+I4oGRzmNKAX7g5WHA5c5mDGCofTSvxk1pdSZ p0W7Ter1BH2ZsVePdJZTzO+NeysnTqOB78Wtvcvnr/Ur+dnADLuMm7JZvx8Y8FnP 5oBNWSlsQArI4tj15fhQrX3VT0VP+tIdrmYiJT2OASoeftixJpRnPvYSufoK85l8 1QQ8rxaJGT+SZPiGiN+LK5LgaII4HAuZdheC26E+RuobTVgAFCSscYvppyfeXwLD jhOYobgZU2FmTHAt0RGAroDqXQmdkeO4tnOuexBeMvQ1SBZUq3Lonr8mVLy+/+ks UvUYV+TdlJ7etk9Z5Dh46UGnFXybLQ== =IV5t -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 14 12:29:20 2018 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 D4DB0130EF0 for ; Tue, 14 Aug 2018 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 6EvgfGQWIHvU for ; Tue, 14 Aug 2018 12:29:09 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 A1161130F04 for ; Tue, 14 Aug 2018 12:29:09 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id n18-v6so19379095ioa.9 for ; Tue, 14 Aug 2018 12:29:09 -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=eyv2fv/vhAGBCDRPFlg5uZOTU29PsAViMP/jPDRsf14=; b=Q/koa/WLI0k+ENnzD53k54GJnPMcGXoXJris6GEO3OZlvpAoK0HzAAP09HFXNT5Eu9 PyUEh08ajqEK5jDgy2UhGI5aOXPbnNuOAC/TQdQCu9/BWL+xF8sB0p1R+/JBC1xkc/B/ tEfjij/V5sBWXO67pQB2/UwJJ4BvvVlHP0fJ+amGBxpHei/uk3V5pglr52ywoOHMeqTx vNc5ZanCje3nhmAz0DJeu3ncRPZ0u+xQa7s2RnzKjo5p06JdLHFJZHPMgWADpylHf90R wFErffXdo6SFBPMFaClf4lU5ncTzpU/3LDeVd0r0izjIw61KWt1XwhVhMQehLao1LYZl 3zgA== 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=eyv2fv/vhAGBCDRPFlg5uZOTU29PsAViMP/jPDRsf14=; b=kr0ohbK27lQxbk5jlBOBUaoJ+RVvMxa2TMnhUmM/bXxhaf83E2wwGcbggyQyVSWGSW mHqnB/kEpomUE8VqGO3un2Y4KB4I9p88Sv2Cco5Ua6jKIabCPR0zb+ASlkJqT2n4uGIb uq8Ac5NoM23hyFRffJq2o6i2wPxePhYNk1Bb/zn+/VLWVlwNKoWos20s1z9owcmhHtbP GQHglDjqolDrW2MnvyWDoRLD+xzaYnAkrtOW/T2bC0BtVOa53hCzpmSNVZGedaMvZl8W 34byaWY/JlrJYS5pzY1v0lAAERvkV8LlA3m6LW+NQXOeDeeqVZf01xxPKp0socJ7oBru lj1A== X-Gm-Message-State: AOUpUlHkLGtpsb/OQKaD/MIQPfn9RadxdgxTGUhGZGqU9BGchPM1MTuo kpfhNb23DCV08DxGYSc2Qd5YC/9Yg3wb2rltPeYE+t+CUkY= X-Google-Smtp-Source: AA+uWPzKy1gpY+lo/lH0fAULMoPEf+Lboe6Bcss48L5oL7kPjpISRmnibwuupsmfvR/W2MCY5c7KBFbQuDZCFGC7T4I= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr19154086ioa.299.1534274948762; Tue, 14 Aug 2018 12:29:08 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 2002:a02:c502:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 12:28:37 -0700 (PDT) In-Reply-To: <23411.7302.128219.423902@fireball.acr.fi> References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <23411.7302.128219.423902@fireball.acr.fi> From: Hugo Krawczyk Date: Tue, 14 Aug 2018 15:28:37 -0400 X-Google-Sender-Auth: agUcpgoI1KfoEgv8M4ckE0HeROw Message-ID: To: Tero Kivinen Cc: Valery Smyslov , IPsecme WG , Paul Wouters Content-Type: multipart/alternative; boundary="0000000000004f107405736a39af" Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 19:29:19 -0000 --0000000000004f107405736a39af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why aren't these IKEv1 implementation defending against Bleichenbacher by hiding the nature of error (decryption error or authentication error) like what TLS 1.2 does [1]? Is this option documented in any of the IPsec/IKE documents? Is there a reason why it would not work in IKEv1 as it worked for TLS? [1] RFC 5246 Sec 7.4.7.1 Hugo On Tue, Aug 14, 2018 at 2:16 PM, Tero Kivinen wrote: > Valery Smyslov writes: > > after reading the paper I still don=E2=80=99t understand why authors > > mentioned IKEv2 there. > > Of course they mention, just to get more exposure... > > > Their example attack in Section 4.4 on (allegedly) IKEv2 in fact > > uses secondary responder supporting IKEv1 Public Key Encryption > > mode, without which the attack is impossible (as far as I > > understand). So, in my opinion, the authors are at least not > > accurate in claiming that IKEv2 itself is susceptible. Or am I > > missing something? > > That is my understanding also. > > On the other hand breaking signature method of the IKEv2 using IKEv1 > oracle for the same RSA key is quite clever, and just points out that > we must not use same key pair with different protocols / modes etc. > > We had this dicussion in when writing RFC8247 and recommending RFC7427 > Digital Signatures using RSASSA-PSS. Some implementors used same key > pair for both RSASSA-PKCS1-v1_5 and RSASSA-PSS. This paper just points > you that you must not do that kind of things. > > The text about the IKEv2 pre-shared keys is just already known fact, > and the RFC7296 warns about that several times, i.e., it does say use > EAP for those, and for EAP you should not use the weak EAP methods, > but instead you should use key generating methods. Also because it is > known fact that IKEv2 shared secret authentication is vulnerable to > the off-line dictionary attacks, we created RFC6467 for secure > password methods. I.e., PACE (RFC6631), AugPAKE (RFC6628), abd Secure > PSK Authentication (RFC6617) should all be protected against offline > dictionary attacks. > > Anyways, I think proper fix would be to disable IKEv1 support > completely, not to just disable RSA encryption mode... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000004f107405736a39af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why aren't these IKEv1 implementati= on defending against Bleichenbacher by hiding the nature of error (decrypti= on error or authentication error) like what TLS 1.2 does [1]? Is this optio= n documented in any of the IPsec/IKE documents? Is there a reason why it wo= uld not work in IKEv1 as it worked for TLS?

[1] RFC 5246 Sec 7.4.7.1=C2=A0

Hugo


On Tu= e, Aug 14, 2018 at 2:16 PM, Tero Kivinen <kivinen@iki.fi> wrote= :
Valery Smyslov writes:=
> after reading the paper I still don=E2=80=99t understand why authors > mentioned IKEv2 there.

Of course they mention, just to get more exposure...

> Their example attack in Section 4.4 on (allegedly) IKEv2 in fact
> uses secondary responder supporting IKEv1 Public Key Encryption
> mode, without which the attack is impossible (as far as I
> understand). So, in my opinion, the authors are at least not
> accurate in claiming that IKEv2 itself is susceptible. Or am I
> missing something?

That is my understanding also.

On the other hand breaking signature method of the IKEv2 using IKEv1
oracle for the same RSA key is quite clever, and just points out that
we must not use same key pair with different protocols / modes etc.

We had this dicussion in when writing RFC8247 and recommending RFC7427
Digital Signatures using RSASSA-PSS. Some implementors used same key
pair for both RSASSA-PKCS1-v1_5 and RSASSA-PSS. This paper just points
you that you must not do that kind of things.

The text about the IKEv2 pre-shared keys is just already known fact,
and the RFC7296 warns about that several times, i.e., it does say use
EAP for those, and for EAP you should not use the weak EAP methods,
but instead you should use key generating methods. Also because it is
known fact that IKEv2 shared secret authentication is vulnerable to
the off-line dictionary attacks, we created RFC6467 for secure
password methods. I.e., PACE (RFC6631), AugPAKE (RFC6628), abd Secure
PSK Authentication (RFC6617) should all be protected against offline
dictionary attacks.

Anyways, I think proper fix would be to disable IKEv1 support
completely, not to just disable RSA encryption mode...
--
kivinen@iki.fi

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

--0000000000004f107405736a39af-- From nobody Tue Aug 14 13:37:39 2018 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 CEC4E130DF4 for ; Tue, 14 Aug 2018 13:37:35 -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 l8qD3UDXGL9f for ; Tue, 14 Aug 2018 13:37:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FD4130DD1 for ; Tue, 14 Aug 2018 13:37:32 -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 w7EKb5tB021587 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Aug 2018 23:37:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w7EKb5WT017275; Tue, 14 Aug 2018 23:37:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23411.15729.458107.12902@fireball.acr.fi> Date: Tue, 14 Aug 2018 23:37:05 +0300 From: Tero Kivinen To: Hugo Krawczyk Cc: Valery Smyslov , IPsecme WG , Paul Wouters In-Reply-To: References: <009a01d433a6$a7b63170$f7229450$@gmail.com> <23411.7302.128219.423902@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 104 min X-Total-Time: 50 min Archived-At: Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 20:37:36 -0000 Hugo Krawczyk writes: > Why aren't these IKEv1 implementation defending against Bleichenbacher by > hiding the nature of error (decryption error or authentication error) like > what TLS 1.2 does [1]? Is this option documented in any of the IPsec/IKE > documents? Is there a reason why it would not work in IKEv1 as it worked for > TLS? Mostly as those implementations are old, and have not been touched in last 15 years. IKEv2 obsoleted IKEv1 in 2005, and instead of removing IKEv1 most of the vendors just put IKEv1 on "low maintenance mode", meaning they will fix fatal bugs (crashes etc) but will not do any real development for it. Also when this was big news in TLS few years back, where this "19 year old bug" [1] hits servers again, IKEv2 had already moved on. We had RFC 7427 [2] which allows using RSASSA-PSS and RFC8247 [3] which said RSASSA-PKCS1-v1.5 is no longer recommended. I think there was discussion about this attack in IPsec list 15-20 years ago, but could not find the discussion from my archives now. The IKEv1 uses RSA encryption to encrypt few specific payloads on the exchange, and there is no text in RFC2409 or other places to tell what should you do if the encryption fails, but yes similar thing than what was done for TLS could be done for IKEv1, except IKEv1 is obsoleted, and there is no point of fix issues in obsoleted protocol (I do not think we provide fixes for SSL 3.0 anymore either). I think there is no point of beating the dead horse anymore. I think we should really have the draft-ietf-ipsecme-ikev1-die-die-die-die-die-die-die-die-die-die-die-die-die-00.txt... [1] https://robotattack.org/ [2] https://datatracker.ietf.org/doc/rfc7427/ [3] https://datatracker.ietf.org/doc/rfc8247/ -- kivinen@iki.fi From nobody Wed Aug 15 02:05:49 2018 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 A5DE5130F1A for ; Wed, 15 Aug 2018 02:05:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cW43pTewcZeq for ; Wed, 15 Aug 2018 02:05:45 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D44130E17 for ; Wed, 15 Aug 2018 02:05:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CAE7F201D1 for ; Wed, 15 Aug 2018 13:05:26 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylltby8hzuuk for ; Wed, 15 Aug 2018 13:05:26 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 3354D201C4 for ; Wed, 15 Aug 2018 13:05:26 +0200 (CEST) Received: from MAIL-ESSEN-02.secunet.de ([fe80::4431:e661:14d0:41ce]) by mail-essen-01.secunet.de ([fe80::1c79:38b7:821e:46b4%16]) with mapi id 14.03.0399.000; Wed, 15 Aug 2018 11:05:41 +0200 From: "Bruckert, Leonie" To: "ipsec@ietf.org" Thread-Topic: draft-tjhai-ipsecme-hybrid-qske-ikev2-02: PFS for CHild SAs? Thread-Index: AdQ0dyLql/R+JSY+S4avOrwPpAdd6Q== Date: Wed, 15 Aug 2018 09:05:40 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: d65e63f7-5c15-413f-8f63-c0d707471c93 x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-guid: 8BB5A0FD-C282-4AD5-81AE-B74BECF6FED7 Content-Type: multipart/alternative; boundary="_000_DE8E4C1F24911E469CC24DD4819274AA2C1C200Amailessen02secu_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-02: PFS for CHild SAs? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 09:05:48 -0000 --_000_DE8E4C1F24911E469CC24DD4819274AA2C1C200Amailessen02secu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd like to put the topic PFS up for discussion, since section 3.5 Child SA= s contains some (to cite Scott) weasel words. Obviously, in order to achieve PFS in the sense of PQ security, we need to= perform at least one PQ key exchange for Child SAs. At this point of the p= rotocol, the peers already know if both of them support PQ algorithms, so b= ackwards compatibility should not be an issue. Furthermore, as the CREATE_C= HILD_SA exchange is already encrypted and IKE fragmentation could be used, = you could simply include further (PQ) KE payloads in the message. I don't think that it is necessary to negotiate the PQ key exchange algorit= hms again. This would introduce more complexity. Instead you could restrict= the PQ algorithms to the ones already negotiated in the IKE_AUX exchange. Any thoughts? Leonie --_000_DE8E4C1F24911E469CC24DD4819274AA2C1C200Amailessen02secu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’d like to put the topic= PFS up for discussion, since section 3.5 Child SAs contains some (to cite = Scott) weasel words.

 

Obviously, in order to  ac= hieve PFS in the sense of PQ security, we need to perform at least one PQ k= ey exchange for Child SAs. At this point of the protocol, the peers already= know if both of them support PQ algorithms, so backwards compatibility should not be an issue. Furthermore, as the CRE= ATE_CHILD_SA exchange is already encrypted and IKE fragmentation could be u= sed, you could simply include further (PQ) KE payloads in the message. &nbs= p;

I don’t think that it is = necessary to negotiate the PQ key exchange algorithms again. This would int= roduce more complexity. Instead you could restrict the PQ algorithms to the= ones already negotiated in the IKE_AUX exchange.

 

Any thoughts?=

 

Leonie

 

--_000_DE8E4C1F24911E469CC24DD4819274AA2C1C200Amailessen02secu_-- From nobody Thu Aug 16 23:26:03 2018 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 C2C01130E2E; Thu, 16 Aug 2018 23:25:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-split-dns.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153448715569.12184.4843735916628840351@ietfa.amsl.com> Date: Thu, 16 Aug 2018 23:25:55 -0700 Archived-At: Subject: [IPsec] Genart last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 06:25:56 -0000 Reviewer: Christer Holmberg Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipsecme-split-dns-12 Reviewer: Christer Holmberg Review Date: 2018-08-16 IETF LC End Date: 2018-08-24 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and almost ready for publication. I have a couple of questions that I would like the authors to address. Major issues: N/A Minor issues: Q1: Section 3.1 contains some SHOULD-do statements, e.g.,: "the initiator SHOULD also include one or more INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REQUEST" "the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST." Is there a reason for not using MUST instead of SHOULD? Q2: Section 3.2 says: "the initiator SHOULD behave as if Split DNS configurations are not supported by the server." Again, is there a reason for not using MUST? Nits/editorial comments: Q3: Is there a need for the "Background" section? Since the text is related to what is described in the "Introduction", could the the text be moved there? From nobody Fri Aug 17 07:54:37 2018 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 9434D130F52; Fri, 17 Aug 2018 07:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkSRIvPAnAtA; Fri, 17 Aug 2018 07:54:10 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 3BBB0130F80; Fri, 17 Aug 2018 07:54:07 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id w7HEksl8016720; Fri, 17 Aug 2018 07:54:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=YC0fRsqbDQ+8VZXnD/nt1QmOiOvpoKILuFq3YaoeNRw=; b=qrSL9Hq5PkUk3AIemmpNFp3cmpXHV0MWo822Vv6Rk06agDFawZwnh7kXojCIHPEx3Ln1 rEJUf3r7O1uKzW96XhvOb4BK3I6ro4bYmb3SqUZaCCLjxY9DzffF7P2j0RsceDN9Fsq/ kS1IfOcvbBm9oDQxb6Ym7TRZ7SshoJXFWWLXFxx3i9JPVo0g9/DnH/RCaI49HgypTM/M JyIPrS8QV0QB+2apTMsP6JUrVVtDv5A1FBOlt6meqFQOoaVUHT50vOyX2YbvSfA4iYio JvoOjPKFiq5NaLzpYhlvFI56nBuzCxf46o2tnh+h/1VHcGeruXKDT6ceoAnmWZIges5Q VQ== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2ksxf82h8a-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 17 Aug 2018 07:54:04 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_P9lfeRUkhqf3Xiq3901Ogw)" Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PDM002QI1E3ZW80@ma1-mtap-s02.corp.apple.com>; Fri, 17 Aug 2018 07:54:04 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PDM00H001CJN500@nwk-mmpp-sz11.apple.com>; Fri, 17 Aug 2018 07:54:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 4872e25be6e630dbcadfff6081c6c948 X-Va-E-CD: c2b8930c6ab4a651d1441d92483deb69 X-Va-R-CD: 941d76882d4051faa38891808138997d X-Va-CD: 0 X-Va-ID: 972acdd2-4297-4db6-b71e-2e64e0c67adf X-V-A: X-V-T-CD: 4872e25be6e630dbcadfff6081c6c948 X-V-E-CD: c2b8930c6ab4a651d1441d92483deb69 X-V-R-CD: 941d76882d4051faa38891808138997d X-V-CD: 0 X-V-ID: 88df2550-80d8-48f9-a4dd-a3972e34af4a Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PDM00C0010BIP00@nwk-mmpp-sz11.apple.com>; Fri, 17 Aug 2018 07:54:00 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-17_04:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from [17.234.86.115] (unknown [17.234.86.115]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PDM001HI1D0QQ60@nwk-mmpp-sz11.apple.com>; Fri, 17 Aug 2018 07:53:26 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <220503CD-69AA-4015-A954-DF48D071D522@apple.com> Date: Fri, 17 Aug 2018 07:53:23 -0700 In-reply-to: <153448715569.12184.4843735916628840351@ietfa.amsl.com> Cc: gen-art@ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-split-dns.all@ietf.org, ietf@ietf.org To: Christer Holmberg References: <153448715569.12184.4843735916628840351@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-17_04:, , signatures=0 Archived-At: Subject: Re: [IPsec] Genart last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 14:54:22 -0000 --Boundary_(ID_P9lfeRUkhqf3Xiq3901Ogw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Christer, Thanks for the review! Some responses inline. Best, Tommy > On Aug 16, 2018, at 11:25 PM, Christer Holmberg = wrote: >=20 > Reviewer: Christer Holmberg > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ipsecme-split-dns-12 > Reviewer: Christer Holmberg > Review Date: 2018-08-16 > IETF LC End Date: 2018-08-24 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: The document is well written, and almost ready for = publication. I have > a couple of questions that I would like the authors to address. >=20 > Major issues: N/A >=20 > Minor issues: >=20 > Q1: >=20 > Section 3.1 contains some SHOULD-do statements, e.g.,: >=20 > "the initiator SHOULD also include one or more INTERNAL_IP4_DNS and > INTERNAL_IP6_DNS attributes in the CFG_REQUEST" >=20 > "the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN = attributes > in the CFG_REQUEST." >=20 > Is there a reason for not using MUST instead of SHOULD? In general, the CFG_REQUEST attributes are a bit loose=E2=80=94they're = hints more than requirements. =46rom section 3.15.1 of RFC7296: The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request information from its peer. If an attribute in the CFG_REQUEST Configuration payload is not zero-length, it is taken as a suggestion for that attribute. The CFG_REPLY Configuration payload MAY return that value, or a new one. It MAY also add new attributes and not include some requested ones. Unrecognized or unsupported attributes MUST be ignored in both requests and responses. So, the CFG_REPLY MUST have a DNS server to go along with the DNS = domain, but I left the SHOULD in spirit of the fact that the CFG_REQUEST = is more of a suggestion. That being said, if others in the WG would like to see this be a MUST, = I'm fine with that as well. I don't think we should have the responder = error out if it doesn't see both, however. >=20 > Q2: >=20 > Section 3.2 says: >=20 > "the initiator SHOULD behave as if Split DNS configurations are not = supported > by the server." >=20 > Again, is there a reason for not using MUST? This one could be a MUST. The one exception I could see is if the = initiator was statically configured with some split DNS domains to use = as split domains In case the responder didn't provide any in the CFG_REPLY, it should = still use those and not send all DNS queries inside the tunnel. I = wouldn't want this MUST to disable the static configuration workarounds that = implementations have done prior to allowing split DNS to be negotiated. >=20 > Nits/editorial comments: >=20 > Q3: >=20 > Is there a need for the "Background" section? Since the text is = related to what > is described in the "Introduction", could the the text be moved there? The main new points that the Background section adds on top of the = Introduction are: - The prior art for split DNS in IKEv1 - The fact that this is currently mainly seen in enterprise VPN = deployments These points could indeed be moved to the introduction. I had felt they = fit better as "background" since they're not essential to the = description of the protocol, but give context that is relevant now (and = may be less so in the future). >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_P9lfeRUkhqf3Xiq3901Ogw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Christer,

Thanks for = the review! Some responses inline.

Best,
Tommy

On Aug 16, 2018, at 11:25 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Reviewer: Christer Holmberg
Review result: = Ready with Nits

I am the assigned Gen-ART = reviewer for this draft. The General Area
Review Team = (Gen-ART) reviews all IETF documents being processed
by = the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ipsecme-split-dns-12
Reviewer: Christer Holmberg
Review Date: = 2018-08-16
IETF LC End Date: 2018-08-24
IESG = Telechat date: Not scheduled for a telechat

Summary: The document is well written, and almost ready for = publication. I have
a couple of questions that I would = like the authors to address.

Major issues: = N/A

Minor issues:

Q1:

Section 3.1 contains some = SHOULD-do statements, e.g.,:

"the initiator = SHOULD also include one or more INTERNAL_IP4_DNS and
INTERNAL_IP6_DNS attributes in the CFG_REQUEST"

"the initiator SHOULD also include one or more = INTERNAL_DNS_DOMAIN attributes
in the CFG_REQUEST."

Is there a reason for not using MUST instead = of SHOULD?

In general, the CFG_REQUEST attributes are a bit = loose=E2=80=94they're hints more than requirements.

=46rom section 3.15.1 of RFC7296:

   The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to =
request
   information from its peer.  If an attribute in the CFG_REQUEST
   Configuration payload is not zero-length, it is taken as a suggestion
   for that attribute.  The CFG_REPLY Configuration payload MAY return
   that value, or a new one.  It MAY also add new attributes and not
   include some requested ones.  Unrecognized or unsupported attributes
   MUST be ignored in both requests and responses.

So, the =
CFG_REPLY MUST have a DNS server to go along with the DNS domain, but I =
left the SHOULD in spirit of the fact that the CFG_REQUEST is more of a =
suggestion.

That being =
said, if others in the WG would like to see this be a MUST, I'm fine =
with that as well. I don't think we should have the responder error out =
if it doesn't see both, however.



Q2:

Section 3.2 says:

"the initiator SHOULD behave as if Split DNS configurations = are not supported
by the server."

Again, is there a reason for not using MUST?

This = one could be a MUST. The one exception I could see is if the initiator = was statically configured with some split DNS domains to use as split = domains
In case the responder didn't provide any in the = CFG_REPLY, it should still use those and not send all DNS queries inside = the tunnel. I wouldn't want this
MUST to disable the static = configuration workarounds that implementations have done prior to = allowing split DNS to be negotiated.


Nits/editorial comments:

Q3:

Is there a need for the "Background" section? = Since the text is related to what
is described in the = "Introduction", could the the text be moved there?

The main = new points that the Background section adds on top of the Introduction = are:
- The prior art for split DNS in IKEv1
- The = fact that this is currently mainly seen in enterprise VPN = deployments

These points could = indeed be moved to the introduction. I had felt they fit better as = "background" since they're not essential to the description of the = protocol, but give context that is relevant now (and may be less so in = the future).



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

= --Boundary_(ID_P9lfeRUkhqf3Xiq3901Ogw)-- From nobody Sun Aug 19 10:59:44 2018 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 63C39130E91; Sun, 19 Aug 2018 10:59:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-split-dns.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153470157533.21344.975291793985145087@ietfa.amsl.com> Date: Sun, 19 Aug 2018 10:59:35 -0700 Archived-At: Subject: [IPsec] Secdir last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 17:59:36 -0000 Reviewer: Stefan Santesson Review result: Has Nits In agreement with nit comments in the Gen-Art review. 1) Section 2. Background seems to be a duplication with the introduction section and could probably be merged with this section. 2) In general I wander wether the requirement level "SHOULD" is to week in some places. The concern (and question) here is whether this may lead to uncertainty whether a Split-DNS configuration always will provide the expected level of security (or fail), or wether such configuration may lead to successful communication without the expected level of security ( in compliance with this specification). From nobody Sun Aug 19 12:09:04 2018 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 C06D9130E97; Sun, 19 Aug 2018 12:08:56 -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 P2C2BuA2D8ZK; Sun, 19 Aug 2018 12:08:55 -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 2772A130DD6; Sun, 19 Aug 2018 12:08:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41tmgk1QYYzF1G; Sun, 19 Aug 2018 21:08:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1534705730; bh=cLlHkqbI0WvWvX5IUJF8tor+t4io2iTwxqE7LMxce74=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Mma7pO1PDuCZX2xO0clW99DXLJLJJ5hWJzfhKqSBKJ6ovqFa4NDWnMZxj4V0awl4y /LR8O1Ss3BAu+Llb61grqeDxdM1gYYcSaXtIPYmqq03N/1hfhrO/RfPIx+EWajpWTu gXCwb6TOXJVjkW2NGUw/7BjrRU8ZrJzV2I0O1hLI= 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 q7TQHIh6Kjxe; Sun, 19 Aug 2018 21:08:48 +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; Sun, 19 Aug 2018 21:08:47 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 71F9EB379D; Sun, 19 Aug 2018 15:08:46 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 71F9EB379D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6779340D6EB6; Sun, 19 Aug 2018 15:08:46 -0400 (EDT) Date: Sun, 19 Aug 2018 15:08:46 -0400 (EDT) From: Paul Wouters To: Stefan Santesson cc: secdir@ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-split-dns.all@ietf.org, ietf@ietf.org In-Reply-To: <153470157533.21344.975291793985145087@ietfa.amsl.com> Message-ID: References: <153470157533.21344.975291793985145087@ietfa.amsl.com> 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] Secdir last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 19:08:57 -0000 On Sun, 19 Aug 2018, Stefan Santesson wrote: > Reviewer: Stefan Santesson > Review result: Has Nits Thanks for your review. > In agreement with nit comments in the Gen-Art review. > > 1) Section 2. Background seems to be a duplication with the introduction > section and could probably be merged with this section. I agree. It is so small we can pull it into the Introduction. > 2) In general I wander wether the requirement level "SHOULD" is to week in some > places. The concern (and question) here is whether this may lead to uncertainty > whether a Split-DNS configuration always will provide the expected level of > security (or fail), or wether such configuration may lead to successful > communication without the expected level of security ( in compliance with this > specification). Unfortunately, this is the case because of the original text regarding CFG requests and replies that basically allow each party to omit or send these completely ignoring which of these CFG's the other party decided to include. We actually had to loosen up the language or otherwise we would be modifying the behaviour specified in 5996/7296. Paul From nobody Sun Aug 19 12:15:57 2018 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 2B5B4130E98 for ; Sun, 19 Aug 2018 12:15:56 -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 KXhwuEe3YaaB for ; Sun, 19 Aug 2018 12:15:55 -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 D6D92130DD6 for ; Sun, 19 Aug 2018 12:15:54 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41tmqs1MmLzD26; Sun, 19 Aug 2018 21:15:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1534706153; bh=DkYML5skkb5qU4LeqUNAnufhktxie2ZhpQeptUx1mVo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Z5G7du5sT+31mssiwvNIoYJed5UyXbwruE+QX8+3Xpbu0K7HpT7IB/KxcT7fJgKon oprftTRcW/z7E65EmYaa5VoX6Vbh7bpuomvoSLacKD0IGqJsItWcYKhMdVrEkCO62k c6kBcrWiy9klqCItD8iGfx/A3OcQ7cf56BefnBag= 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 rBszrC2k2k9J; Sun, 19 Aug 2018 21:15:52 +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; Sun, 19 Aug 2018 21:15:52 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5AD7BB379D; Sun, 19 Aug 2018 15:15:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5AD7BB379D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 50CB840D6EB6; Sun, 19 Aug 2018 15:15:51 -0400 (EDT) Date: Sun, 19 Aug 2018 15:15:51 -0400 (EDT) From: Paul Wouters To: "Bruckert, Leonie" cc: "ipsec@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-02: PFS for CHild SAs? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 19:15:56 -0000 On Wed, 15 Aug 2018, Bruckert, Leonie wrote: > Obviously, in order to  achieve PFS in the sense of PQ security, we need to perform at least one PQ key exchange for Child SAs. At this point > of the protocol, the peers already know if both of them support PQ algorithms, so backwards compatibility should not be an issue. > Furthermore, as the CREATE_CHILD_SA exchange is already encrypted and IKE fragmentation could be used, you could simply include further (PQ) > KE payloads in the message.   > > I don¢t think that it is necessary to negotiate the PQ key exchange algorithms again. This would introduce more complexity. Instead you could > restrict the PQ algorithms to the ones already negotiated in the IKE_AUX exchange. That makes sense to me. Paul From nobody Sun Aug 19 13:39:55 2018 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 54E11130E5C for ; Sun, 19 Aug 2018 13:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Eoh6SH4pQxnD for ; Sun, 19 Aug 2018 13:39:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 489FD130DC7 for ; Sun, 19 Aug 2018 13:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534711187; 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=Hc93WPhMIP/tpjnFDhBw3F0ccFJZmBbf6cq1qnIKwCs=; b=XH9WRNc9VwR7vcTwcDUImlsQext3uHn3eY16pLu9KSfs75ZR20N9FRX4fpgFAuXI 28Anh6iW17Sldb6OJ0MLZIizD+3plxk1ld52Obrmq1tfcgmFvWo/Cpehvl2YQLDt HsukqPSwtiRg8u0Xs1oNH7yRXrfBKwI4IQml7lEZKQ0=; X-AuditID: c1b4fb3a-7ebff7000000680b-4f-5b79d59378a1 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.46.26635.395D97B5; Sun, 19 Aug 2018 22:39:47 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 19 Aug 2018 22:39:47 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Sun, 19 Aug 2018 22:39:47 +0200 From: Christer Holmberg To: "tpauly@apple.com" CC: "gen-art@ietf.org" , "ipsec@ietf.org" , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "ietf@ietf.org" Thread-Topic: [IPsec] Genart last call review of draft-ietf-ipsecme-split-dns-12 Thread-Index: AQHUNjolgLrW6dFm9kmq3YLzoaV+xKTHiUzQ Date: Sun, 19 Aug 2018 20:39:47 +0000 Message-ID: References: <153448715569.12184.4843735916628840351@ietfa.amsl.com> <220503CD-69AA-4015-A954-DF48D071D522@apple.com> In-Reply-To: <220503CD-69AA-4015-A954-DF48D071D522@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7ke7kq5XRBhdalS2O9jtbXH31mcXi 2cb5LBb7t7xgs5h44iCrA6vH1pM/2DyWLPnJFMAUxWWTkpqTWZZapG+XwJWx78xXxoJfWhXL etYxNjC+0exi5OSQEDCReH5tNmMXIxeHkMBRRon5y/+zgiSEBL4xSlw8VAKRWMYo8XnrVqAE BwebgIVE9z9tkBoRAU2JK7v3gzUzC5xilNjf/pYdpEZYIFDi1isdiJogibXNLUwQtpHEkW3n wWwWAVWJhbeesYDYvALWEsvazzOCtAoJlElMagoFCXMK2Ep83TIH7BxGATGJ76fWgLUyC4hL 3HoynwnifgGJJXvOM0PYohIvH/9jhbCVJPYeu84CMpIZ6Mz1u/QhWhUlpnQ/ZIfYKihxcuYT lgmMYrOQTJ2F0DELSccsJB0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG1cEtv612 MB587niIUYCDUYmHd+G5ymgh1sSy4srcQ4wSHMxKIrytC4FCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEeZ3SLKKEBNITS1KzU1MLUotgskwcnFINjNbcNjuWHFtpM1Vhl83b9wevrXny5J5q5LcU zuk/Ti88F3vMe6mLslv5mZj7h5VWdPdMPLvtV+pss51CXhd2uYk7Xn334KPWKfP33Ul8NYdu rCm/yrUnw3bS/Iw9p3bIHXj3VfyP2h52/hO3z8zY13e+cML1ffv/P9r0zkciK7CRw8905unO bee3KrEUZyQaajEXFScCAOqK4WGmAgAA Archived-At: Subject: Re: [IPsec] Genart last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 20:39:53 -0000 SGkgVG9tbXksDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQoNCk1pbm9yIGlzc3VlczoNCg0KUTE6 DQoNCj4+IFNlY3Rpb24gMy4xIGNvbnRhaW5zIHNvbWUgU0hPVUxELWRvIHN0YXRlbWVudHMsIGUu Zy4sOg0KPj4NCj4+ICJ0aGUgaW5pdGlhdG9yIFNIT1VMRCBhbHNvIGluY2x1ZGUgb25lIG9yIG1v cmUgSU5URVJOQUxfSVA0X0ROUyBhbmQNCj4+IElOVEVSTkFMX0lQNl9ETlMgYXR0cmlidXRlcyBp biB0aGUgQ0ZHX1JFUVVFU1QiDQo+Pg0KPj4gInRoZSBpbml0aWF0b3IgU0hPVUxEIGFsc28gaW5j bHVkZSBvbmUgb3IgbW9yZSBJTlRFUk5BTF9ETlNfRE9NQUlOIGF0dHJpYnV0ZXMNCj4+IGluIHRo ZSBDRkdfUkVRVUVTVC4iDQo+Pg0KPj4gSXMgdGhlcmUgYSByZWFzb24gZm9yIG5vdCB1c2luZyBN VVNUIGluc3RlYWQgb2YgU0hPVUxEPw0KPg0KPiBJbiBnZW5lcmFsLCB0aGUgQ0ZHX1JFUVVFU1Qg YXR0cmlidXRlcyBhcmUgYSBiaXQgbG9vc2XigJR0aGV5J3JlIGhpbnRzIG1vcmUgdGhhbiByZXF1 aXJlbWVudHMuDQo+DQo+IEZyb20gc2VjdGlvbiAzLjE1LjEgb2YgUkZDNzI5NjoNCj4NCj4gICBU aGUgQ0ZHX1JFUVVFU1QgYW5kIENGR19SRVBMWSBwYWlyIGFsbG93cyBhbiBJS0UgZW5kcG9pbnQg dG8gcmVxdWVzdA0KPiAgIGluZm9ybWF0aW9uIGZyb20gaXRzIHBlZXIuICBJZiBhbiBhdHRyaWJ1 dGUgaW4gdGhlIENGR19SRVFVRVNUDQo+ICAgQ29uZmlndXJhdGlvbiBwYXlsb2FkIGlzIG5vdCB6 ZXJvLWxlbmd0aCwgaXQgaXMgdGFrZW4gYXMgYSBzdWdnZXN0aW9uDQo+ICAgZm9yIHRoYXQgYXR0 cmlidXRlLiAgVGhlIENGR19SRVBMWSBDb25maWd1cmF0aW9uIHBheWxvYWQgTUFZIHJldHVybg0K PiAgIHRoYXQgdmFsdWUsIG9yIGEgbmV3IG9uZS4gIEl0IE1BWSBhbHNvIGFkZCBuZXcgYXR0cmli dXRlcyBhbmQgbm90DQo+ICAgaW5jbHVkZSBzb21lIHJlcXVlc3RlZCBvbmVzLiAgVW5yZWNvZ25p emVkIG9yIHVuc3VwcG9ydGVkIGF0dHJpYnV0ZXMNCj4gICBNVVNUIGJlIGlnbm9yZWQgaW4gYm90 aCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLg0KPg0KPiBTbywgdGhlIENGR19SRVBMWSBNVVNUIGhh dmUgYSBETlMgc2VydmVyIHRvIGdvIGFsb25nIHdpdGggdGhlIEROUyBkb21haW4sIGJ1dCBJIGxl ZnQgdGhlIFNIT1VMRCBpbiBzcGlyaXQgDQo+IG9mIHRoZSBmYWN0IHRoYXQgdGhlIENGR19SRVFV RVNUIGlzIG1vcmUgb2YgYSBzdWdnZXN0aW9uLg0KPg0KPiBUaGF0IGJlaW5nIHNhaWQsIGlmIG90 aGVycyBpbiB0aGUgV0cgd291bGQgbGlrZSB0byBzZWUgdGhpcyBiZSBhIE1VU1QsIEknbSBmaW5l IHdpdGggdGhhdCBhcyB3ZWxsLiBJIGRvbid0IHRoaW5rIHdlIA0KPiBzaG91bGQgaGF2ZSB0aGUg cmVzcG9uZGVyIGVycm9yIG91dCBpZiBpdCBkb2Vzbid0IHNlZSBib3RoLCBob3dldmVyLg0KDQpX ZWxsLCBpZiBpdCBpcyBvbmx5IGEgc3VnZ2VzdGlvbiwgdGhlbiBJIGd1ZXNzIG15IHF1ZXN0aW9u IGlzIHdoeSB1c2Ugc29tZXRoaW5nIGFzIHN0cm9uZyBhcyBTSE9VTEQgOikgU0hPVUxEIGJhc2lj YWxseSBtZWFucyBNVVNULXVubGVzcy15b3UtaGF2ZS1hLWdvb2QtcmVhc29uIHRvLg0KDQpJbiBn ZW5lcmFsLCBpcyBwcm92aWRpbmcgc3VnZ2VzdGlvbnMgYSBTSE9VTEQsIG9yIGlzIGl0IG9ubHkg Zm9yIHRoZSBhdHRyaWJ1dGVzIGFib3ZlPw0KDQpBbnl3YXksIGlmIHlvdSB3YW50IHRvIGhhdmUg YSBTSE9VTEQgKG9yIGV2ZW4gYSBNVVNUKSBJIHdvbid0IG9iamVjdC4gQnV0LCB3aGVuIEkgc2Vl IGEgU0hPVUxELCBJIGFsd2F5cyBhc2sgYWJvdXQgdGhlIGJhY2tncm91bmQgOikNCg0KDQpRMjoN Cg0KPj4gU2VjdGlvbiAzLjIgc2F5czoNCj4+DQo+PiAidGhlIGluaXRpYXRvciBTSE9VTEQgYmVo YXZlIGFzIGlmIFNwbGl0IEROUyBjb25maWd1cmF0aW9ucyBhcmUgbm90IHN1cHBvcnRlZA0KPj4g YnkgdGhlIHNlcnZlci4iDQo+Pg0KPj4gQWdhaW4sIGlzIHRoZXJlIGEgcmVhc29uIGZvciBub3Qg dXNpbmcgTVVTVD8NCj4NCj4gVGhpcyBvbmUgY291bGQgYmUgYSBNVVNULiBUaGUgb25lIGV4Y2Vw dGlvbiBJIGNvdWxkIHNlZSBpcyBpZiB0aGUgaW5pdGlhdG9yIHdhcyBzdGF0aWNhbGx5IGNvbmZp Z3VyZWQgd2l0aCBzb21lIHNwbGl0IEROUyBkb21haW5zIHRvIHVzZSBhcyBzcGxpdCBkb21haW5z DQo+IEluIGNhc2UgdGhlIHJlc3BvbmRlciBkaWRuJ3QgcHJvdmlkZSBhbnkgaW4gdGhlIENGR19S RVBMWSwgaXQgc2hvdWxkIHN0aWxsIHVzZSB0aG9zZSBhbmQgbm90IHNlbmQgYWxsIEROUyBxdWVy aWVzIGluc2lkZSB0aGUgdHVubmVsLiBJIHdvdWxkbid0IHdhbnQgdGhpcw0KPiBNVVNUIHRvIGRp c2FibGUgdGhlIHN0YXRpYyBjb25maWd1cmF0aW9uIHdvcmthcm91bmRzIHRoYXQgaW1wbGVtZW50 YXRpb25zIGhhdmUgZG9uZSBwcmlvciB0byBhbGxvd2luZyBzcGxpdCBETlMgdG8gYmUgbmVnb3Rp YXRlZC4NCg0KQ291bGQgeW91IHNheToNCg0KInRoZSBpbml0aWF0b3IgTVVTVCBiZWhhdmUgYXMg aWYgYSBTcGxpdCBETlMgY29uZmlndXJhdGlvbnMgYXJlIG5vdCBzdXBwb3J0ZWQsIHVubGVzcyA8 aW5zZXJ0IHRleHQgYWJvdmUgdGhlIHN0YXRpY2FsbHkgY29uZmlndXJhdGlvbiBjYXNlIGFib3Zl PiINCg0KDQoNCk5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOg0KDQpRMzoNCg0KPj4gSXMgdGhlcmUg YSBuZWVkIGZvciB0aGUgIkJhY2tncm91bmQiIHNlY3Rpb24/IFNpbmNlIHRoZSB0ZXh0IGlzIHJl bGF0ZWQgdG8gd2hhdA0KPj4gaXMgZGVzY3JpYmVkIGluIHRoZSAiSW50cm9kdWN0aW9uIiwgY291 bGQgdGhlIHRoZSB0ZXh0IGJlIG1vdmVkIHRoZXJlPw0KPg0KPiBUaGUgbWFpbiBuZXcgcG9pbnRz IHRoYXQgdGhlIEJhY2tncm91bmQgc2VjdGlvbiBhZGRzIG9uIHRvcCBvZiB0aGUgSW50cm9kdWN0 aW9uIGFyZToNCj4gLSBUaGUgcHJpb3IgYXJ0IGZvciBzcGxpdCBETlMgaW4gSUtFdjENCj4gLSBU aGUgZmFjdCB0aGF0IHRoaXMgaXMgY3VycmVudGx5IG1haW5seSBzZWVuIGluIGVudGVycHJpc2Ug VlBOIGRlcGxveW1lbnRzDQo+DQo+IFRoZXNlIHBvaW50cyBjb3VsZCBpbmRlZWQgYmUgbW92ZWQg dG8gdGhlIGludHJvZHVjdGlvbi4gSSBoYWQgZmVsdCB0aGV5IGZpdCBiZXR0ZXIgYXMgImJhY2tn cm91bmQiIHNpbmNlIHRoZXkncmUgDQo+IG5vdCBlc3NlbnRpYWwgdG8gdGhlIGRlc2NyaXB0aW9u IG9mIHRoZSBwcm90b2NvbCwgYnV0IGdpdmUgY29udGV4dCB0aGF0IGlzIHJlbGV2YW50IG5vdyAo YW5kIG1heSBiZSBsZXNzIHNvIGluIHRoZSBmdXR1cmUpLg0KDQpUaGUgZmlyc3Qgc2VjdGlvbnMg b2YgYm90aCB0aGUgSW50cm9kdWN0aW9uIGFuZCB0aGUgQmFja2dyb3VuZCBzZWN0aW9ucyB0YWxr IGFib3V0IHNwbGl0IEROUzoNCg0KICAgIlNwbGl0IEROUyBpcyBhIGNvbW1vbiBjb25maWd1cmF0 aW9uIGZvciBzZWN1cmUgdHVubmVscywgc3VjaCBhcw0KICAgVmlydHVhbCBQcml2YXRlIE5ldHdv cmtzIGluIHdoaWNoIGhvc3QgbWFjaGluZXMgcHJpdmF0ZSB0byBhbg0KICAgb3JnYW5pemF0aW9u IGNhbiBvbmx5IGJlIHJlc29sdmVkIHVzaW5nIGludGVybmFsIEROUyByZXNvbHZlcnMiDQoNCiAg ICJTcGxpdCBETlMgaXMgYSBjb21tb24gY29uZmlndXJhdGlvbiBmb3IgZW50ZXJwcmlzZSBWUE4g ZGVwbG95bWVudHMsDQogICBpbiB3aGljaCBvbmUgb3IgbW9yZSBwcml2YXRlIEROUyBkb21haW5z IGFyZSBvbmx5IGFjY2Vzc2libGUgYW5kDQogICByZXNvbHZhYmxlIHZpYSBhbiBJUHNlYyBiYXNl ZCBWUE4gY29ubmVjdGlvbi4iDQoNClNvLCBpc24ndCBTcGxpdCBETlMgYWxyZWFkeSBjb3ZlcmVk IGJ5IHRoZSBJbnRyb2R1Y3Rpb24/IFdoYXQgZXh0cmEgZG9lcyB0aGUgQmFja2dyb3VuZCB0ZXh0 IGJyaW5nPw0KDQpUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiB0aGUgQmFja2dyb3VuZCBjb3VsZCBi ZSBwbGFjZWQgYXQgdGhlIGVuZCBvZiB0aGUgSW50cm9kdWN0aW9uLCBpbiBteSBvcGluaW9uLg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Mon Aug 20 06:09:55 2018 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 C9AC1128C65; Mon, 20 Aug 2018 06:09:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, ekr@rtfm.com, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153477059379.23139.2454042217882150307.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2018 06:09:53 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 103 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 13:09:54 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf 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 Aug 20 15:30:04 2018 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 31898130DF5; Mon, 20 Aug 2018 15:30:02 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9FwCf54yDga; Mon, 20 Aug 2018 15:30:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB24F130DF0; Mon, 20 Aug 2018 15:29:59 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 00A5CAA863B5B; Mon, 20 Aug 2018 23:29:55 +0100 (IST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 20 Aug 2018 23:29:56 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.176]) by SJCEML701-CHM.china.huawei.com ([169.254.3.96]) with mapi id 14.03.0399.000; Mon, 20 Aug 2018 15:29:54 -0700 From: Linda Dunbar To: IPsecME WG , "i2nsf@ietf.org" , "David Carrel (carrel)" , "Brian Weis (bew)" Thread-Topic: questions and comments to drat-carrel-ipsecme-controller-ike-00 Thread-Index: AdQzJnFoUIG14rlySeOdz3p0yhsQ5AFrsixg Date: Mon, 20 Aug 2018 22:29:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0F878E@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.118] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0F878Esjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] questions and comments to drat-carrel-ipsecme-controller-ike-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 22:30:02 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B0F878Esjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David and Brian, In case you missed this email, can you answer those questions? Thank you very much. Linda From: Linda Dunbar Sent: Monday, August 13, 2018 12:18 PM To: IPsecME WG ; i2nsf@ietf.org; 'David Carrel (carrel)' ; 'Brian Weis (bew)' Subject: questions and comments to drat-carrel-ipsecme-controller-ike-00 David and Brian, In your draft, you assumed that Devices (e.g. A or B) sends its Public key = to the Controller. In some SD-WAN deployment, Controller manages & distributes the "Public key= " and "nonce" to each device to achieve Zero Touch Provisioning. Can you u= pdate the Figure 2 to reflect "Controller" sending "public key to devices"? Since this document is about Controller managed IKE, can we have a section = on recommendation of which attributes of IPsec are suitable to be distribut= ed by Controller? For example, - PAD (Peer Authentication Database) can be maintained by Controller= for deployment of devices with constraint resource - Public key & nonce managed by Controller The Rekey process in Section 4 describes some occasions with a device havin= g 2 or 4 SAs for each Peer (Section 4.2). Does it mean the receiving node h= as to use two different decryption keys? How does the receiving node know w= hich one the sender actually used? The entire Section 4 description is no different from scenario of two peers= ' direct communication (i.e. without Controller being present), is it corre= ct? Thank you very much Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F66B0F878Esjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David and Brian, =

 

In case you missed thi= s email, can you answer those questions?

 

Thank you very much. <= o:p>

 

Linda

 

From: Linda Dunbar
Sent: Monday, August 13, 2018 12:18 PM
To: IPsecME WG <ipsec@ietf.org>; i2nsf@ietf.org; 'David Carrel= (carrel)' <carrel@cisco.com>; 'Brian Weis (bew)' <bew@cisco.com&g= t;
Subject: questions and comments to drat-carrel-ipsecme-controller-ik= e-00

 

David and Brian,

 

In your draft, you assumed that Devices (e.g. A or B= ) sends its Public key to the Controller.

 

In some SD-WAN deployment, Controller manages & = distributes the “Public key” and “nonce” to each de= vice to achieve Zero Touch Provisioning.  Can you update the Figure 2 = to reflect “Controller” sending “public key to devices= 221;?

 

 

Since this document is about Controller managed IKE,= can we have a section on recommendation of which attributes of IPsec are s= uitable to be distributed by Controller? For example,

-     &= nbsp;  PAD (Peer Authentication Database) can be maintaine= d by Controller for deployment of devices with constraint resource

-     &= nbsp;  Public key & nonce managed by Controller

 

The Rekey process in Section 4 describes some occasi= ons with a device having 2 or 4 SAs for each Peer (Section 4.2). Does it me= an the receiving node has to use two different decryption keys? How does th= e receiving node know which one the sender actually used?

 

The entire Section 4 description is no different fro= m scenario of two peers’ direct communication (i.e. without Controlle= r being present), is it correct?

 

Thank you very much

 

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0F878Esjceml521mbxchi_-- From nobody Mon Aug 20 16:56:41 2018 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 97430130E06; Mon, 20 Aug 2018 16:56:33 -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 Hv_WuBaXabjQ; Mon, 20 Aug 2018 16:56:31 -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 D9337130DF7; Mon, 20 Aug 2018 16:56:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0986AB804DA; Mon, 20 Aug 2018 16:56:19 -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 Content-type: text/plain; charset=UTF-8 Message-Id: <20180820235619.0986AB804DA@rfc-editor.org> Date: Mon, 20 Aug 2018 16:56:19 -0700 (PDT) Archived-At: Subject: [IPsec] =?utf-8?q?RFC_8420_on_Using_the_Edwards-Curve_Digital_Si?= =?utf-8?q?gnature_Algorithm_=28EdDSA=29_in_the_Internet_Key_Exchange_Prot?= =?utf-8?q?ocol_Version_2_=28IKEv2=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 23:56:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8420 Title: Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) Author: Y. Nir Status: Standards Track Stream: IETF Date: August 2018 Mailbox: ynir.ietf@gmail.com Pages: 5 Characters: 9023 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-eddsa-04.txt URL: https://www.rfc-editor.org/info/rfc8420 DOI: 10.17487/RFC8420 This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2). 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 Wed Aug 22 22:32:04 2018 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 2274E129619 for ; Wed, 22 Aug 2018 22:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=G1xf5du9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Xq76d5PE 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 cICkipmS94yc for ; Wed, 22 Aug 2018 22:31:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 DA4F4124C04 for ; Wed, 22 Aug 2018 22:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1535002317; 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=99BQ2HPmY9c1VXSKdAUegcT9+8qsAG5Wgenq1wFLFLE=; b=G1xf5du94IaUrTOmsLvtcPXXks9sLtTEc5rL7l4sXOKpL82YT8ULpAcTNiKJu2GQ MTyv+8Ds6AkuqBTw6PFnQGbg3h+VkIRiJH2YUVuaVMlThX9vuWEmmbqthfahB/ZH AIy1wsug/pxb+IctV+vVGJkxWu8ghwZNmHVgoWr+3lg=; X-AuditID: c1b4fb30-3cd869c0000055da-fc-5b7e46cd43cf Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.36.21978.DC64E7B5; Thu, 23 Aug 2018 07:31:57 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 23 Aug 2018 07:31:57 +0200 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 23 Aug 2018 07:31:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6nFrnHUI/ZowY4Tz2gRAt52GM7clsnOcKvwJIP4AKO4=; b=Xq76d5PEjAhSNFY2cMb5kWBojyGhQ+7mC8/HKsL5bNzN7wm64sbdBmtFqc/L15xbmhRq3s3xdsKbtQ8LeYNwn+9Fm+iK/6G/S0ho8xzWRt8H5vGdK9gIljK3qZw7cZS1oGPhTPHwbBj26oRgh0lBNDez1EE9ZgrETDz+YviZCSE= Received: from AM6PR07MB4599.eurprd07.prod.outlook.com (20.177.38.205) by AM6PR07MB4533.eurprd07.prod.outlook.com (20.177.37.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.19; Thu, 23 Aug 2018 05:31:55 +0000 Received: from AM6PR07MB4599.eurprd07.prod.outlook.com ([fe80::990a:e4ff:850e:b2a9]) by AM6PR07MB4599.eurprd07.prod.outlook.com ([fe80::990a:e4ff:850e:b2a9%3]) with mapi id 15.20.1080.015; Thu, 23 Aug 2018 05:31:55 +0000 From: Ivo Sedlacek To: "Liu, Jennifer (Nokia - US/Plano)" , "ipsec@ietf.org" CC: Paul Hoffman , "charliekaufman@outlook.com" Thread-Topic: RFC7296 (IKEv2) IKE SA creation question Thread-Index: AdQ6OecOPyO0NuAnSD+STsevEk2hQwAZ8yHg Date: Thu, 23 Aug 2018 05:31:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [64.134.181.123] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB4533; 6:qn1mWrVeNB37DsV9Ns/nPLvp39FnXcQgO7R81PmgewVhR/GUZW/NAxamS004AZuhnYiX7gFHAmrSLidOM1mSXsoEPF7961l9hS0pCQzMamvtGiVLpdPx2YbAzLKNxthdvIHlVEtnRaFl3tp1JXCIJ68JuffV/zNVI+n08R8mYhwBOgRj0xc01HEadHyp+ij69WBnmIiy+SVfK8rTehdJSrjvmyd/jR6OJ2ufh5J9Jwwdlc96vy632WHmbx9ppyKpahi9t+FFYdUNlvrSYQ+CHnN4cAPbXHn4O7Sr1Sq/+qBjugxjIeIWdpnSDBvHim/Fy9uc66QGsK+xiGIZTaW1mjcgY5AzDjVZVmR5GJceTroJiPY60510gXFc5CDbWcM6nQ06FByVtS9XbDczDs0+k7qu/bU/oa1me7obDT4uqMKC4b/Oupp9nyHNy7Plve72KJEhpNDt65HNJADnkYgoSA==; 5:7EQoWPv9PdcrivuVa4fW5aGcstJQH4Pq/emh3ZGr1h0u1YFuEBbqD6B0OLpeclv8U+M/BNZtw335QZ6j3VVNoqEeMHV0ETMFVlM+KdDNhE/TsL1zdluc1zQs04nP6A4F7U/4X2oybceq4tfxUi5hLwtg7pJ7sBkByYzYA2TRblg=; 7:Fs20q3MeBvF1XV/TRcvxsxla7QdChg5MdCmDC4CjmX6xLkOEzDVXShB8GJBgKEfQQ+b+GfzZk78z1CHqxp2SKpTS+RnLN26KBkrVV05+rqATubOGWhYAB/ZG59GQp6BZMT5e+qrrev4nsuDJJ+GSb2ghN00BnaDoOFzZNK407sh98MBAFk0wK8epCXLS7tN/4m+Yr1Hd1uzF9XAWkDzHW11/fKp55tRInCaF+GmPzYYEa7HUfbcBeCbcKDBO3fB4 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1ff34657-7f10-4b6f-e4c5-08d608b9bd2f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB4533; x-ms-traffictypediagnostic: AM6PR07MB4533: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(189930954265078)(82608151540597)(109105607167333)(195916259791689)(21748063052155)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699016); SRVR:AM6PR07MB4533; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB4533; x-forefront-prvs: 0773BB46AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(376002)(346002)(136003)(199004)(189003)(14444005)(54896002)(6436002)(6506007)(53546011)(53936002)(97736004)(5660300001)(256004)(6246003)(9686003)(236005)(25786009)(2906002)(486006)(2900100001)(2501003)(68736007)(5250100002)(39060400002)(6306002)(76176011)(4326008)(102836004)(86362001)(8936002)(296002)(316002)(54906003)(99286004)(110136005)(7736002)(3846002)(7696005)(66066001)(478600001)(106356001)(6116002)(790700001)(26005)(81166006)(11346002)(81156014)(446003)(14454004)(74316002)(8676002)(55016002)(229853002)(45080400002)(186003)(476003)(105586002)(33656002)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4533; H:AM6PR07MB4599.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: rVMZ5HTV6GC6t2f4Gs0MUNqO9Xx1fikyjaEDHvi2+lasHFs4XCZAPoVRNwvZlPV6P58sbMQ343v5qBkb33Vit3Aehk/iS95Ps/DknoKXu/couymWtv97cliCKWRuhjMpBALzuJX3MV4xbSwwDgfDia2QqUX2xS5xOz7SYN0dU2My55ZAQAoZEv6OOFt1YTyOwCOmooih7gn+17nJFPw+sNQRgxn+5QW79UnNZ1m9FtL6musLJX5rieldKzBqyM0czD009x6u19MBw2MfM9NtNDQ3gBqwdI6WGJVoYvW39O+FT1GJl29nVVt5y+KoNddwDbnhUeSurtdXPsELtpn5HprKyRbPkW9dkgk1P19f6QY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM6PR07MB4599003526DAFDBB37478B09E5370AM6PR07MB4599eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1ff34657-7f10-4b6f-e4c5-08d608b9bd2f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2018 05:31:55.4570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4533 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85247S4jhdPilGrIRYbplUjgjJEJlQUoJSKujSg4rTyY6a Stg+JJWX0rzQ1NJwxZCV1ETDay7LFE1bZTGyvIWKpZKSpKK1vRP89nue//99brw0KerkedEp 6ZmsNl2llvBdKf3F1iuyodD8GP9hE6moWn9LKbqbZ/kKU9teha1phXeaUhoMfwnlmM1KKM3z s6RyueYTeZ6Kdj2VyKpTslntkaB412Rz5Q9+xqwm5+uYEelQZWIhcqGBOQYbr9YFhciVFjGv EfTeaUI4+INgtayDwIGBANOIlbI/oZhSEmrHPLBQTsDizByyCyJmEkG1TmpnPiOHsuZenp09 mEQYHB9yMMmwULJQx7ezO3Mc7q9ZSOw5ATfLlxHmALDWVglwM1+w9T5z+IVMLNz6VU/iXvGw WFvsGMiFUUF74bDDj5g9sDpgInAvT7BN1xF4TwYMHcMkZjHMTW3ysD8WtoqWeTgvAVubDmH2 AWtdkeMUwHQJoG/jrlOQwVJlpbPQOVgxWkls6kPQ0lPCx4IUKm53Ok2p0F9sclZ6imCytU+A hX3QWDJBlSL/6h3TYtbAzwd1vGrH1m7Qr5+mcN4P6tt/8zEfhscP58ltHnw5RezM1yNBIxJz LHc5LSkgQM5qUxI4TpMuT2czn6P/n6qned3/BZqbCbYghkaSXUJ5YH6MiKfK5nLTLAhoUuIh nDFfjREJE1W5eaxWE6fNUrOcBXnTlMRTqAg3R4uYJFUmm8qyGax2WyVoFy8dijx4QH8vK6w5 KYKV7f9erzG8CfosTm655CNU9vk1zERWLE+4hRFduogzhvAojv22lZcQ8cFr+svme8X4Wpr5 QnCRPCF4Ikn2JGMhx1gzGjOgH1E2uKlDCkIDbnSPe6c9Mo6mSE8GHvqoyXe7HlfAuZvCxWd3 +15bjzKGvFtSjUooLll1VEpqOdU/SJo7/FADAAA= Archived-At: Subject: Re: [IPsec] RFC7296 (IKEv2) IKE SA creation question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 05:32:02 -0000 --_000_AM6PR07MB4599003526DAFDBB37478B09E5370AM6PR07MB4599eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, RFC7296 states: ---------------- >>The first two exchanges of messages establishing an IKE SA are called the IKE_SA_INIT exchange and the IKE_AUTH exchange<<; subsequent IKE exchanges are called either CREATE_CHILD_SA exchanges or INFORMATIONAL exchanges. ---------------- and ---------------- If the failure is related to creating the IKE SA (for example, an AUTHENTICATION_FAILED Notify error message is returned), >>the IKE SA is not created<<. ---------------- and ---------------- In >>an IKE_AUTH exchange<<, or in the INFORMATIONAL exchange immediatel= y following it (in case an error happened when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or >>not created<<, without a Delete payload. ---------------- I interpret the above to mean that IKE SA is created only after completion = of IKE_AUTH exchange. Kind regards Ivo Sedlacek From: Liu, Jennifer (Nokia - US/Plano) Sent: Wednesday, August 22, 2018 1:10 PM To: ipsec@ietf.org Cc: Paul Hoffman ; charliekaufman@outlook.com; Ivo S= edlacek Subject: RFC7296 (IKEv2) IKE SA creation question Hi, All, 3GPP CT1 workgroup is currently working on developing 5G related standards = and we have some questions related to RFC7296 regarding IKE SA creation tim= e. Paul suggested me to post the questions to IPsecME mailing list. Your f= eedback/clarification would be very much appreciated. According RFC7296, after IKE_SA_INIT exchange, session key is established a= fter Diffie-Hellman exchange, which means all subsequent messages are prote= cted. This seems to mean that IKE SA is already created after IKE_SA_INIT, = then first child SA is established after IKE_AUTH exchange. Is this unders= tanding correct? i.e. Is IKE SA created after IKE_SA_INIT exchange or after= IKE_AUTH exchange? ------------------------------- The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH]. The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first Child SA. Regards, Jennifer --_000_AM6PR07MB4599003526DAFDBB37478B09E5370AM6PR07MB4599eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

RFC7296 states:

----------------

>>The first two exchanges of messages<= /span>

   establishing an IKE SA are called the IKE_= SA_INIT exchange and the

   IKE_AUTH exchange<<; subsequent IKE = exchanges are called either

   CREATE_CHILD_SA exchanges or INFORMATIONAL= exchanges.

----------------

and

----------------

   If the failure is related to creating the = IKE SA (for example, an

   AUTHENTICATION_FAILED Notify error message= is returned), >>the IKE SA

   is not created<<.

----------------

and

----------------

   In >>an IKE_AUTH exchange<<, o= r in the INFORMATIONAL exchange immediately

   following it (in case an error happened wh= en processing a response to

   IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOA= D, INVALID_SYNTAX, and

   AUTHENTICATION_FAILED notifications are th= e only ones to cause the

   IKE SA to be deleted or >>not create= d<<, without a Delete payload.

----------------

 

I interpret the above to mean that IKE SA is created on= ly after completion of IKE_AUTH exchange.

 

Kind regards

 

Ivo Sedlacek

 

From: Liu, Jennifer (Nokia - US/Plano) <jennifer.liu@nokia.com>
Sent: Wednesday, August 22, 2018 1:10 PM
To: ipsec@ietf.org
Cc: Paul Hoffman <paul.hoffman@vpnc.org>; charliekaufman@outlo= ok.com; Ivo Sedlacek <ivo.sedlacek@ericsson.com>
Subject: RFC7296 (IKEv2) IKE SA creation question<= /p>

 

Hi, All,

 =

3GPP CT1 workgroup is= currently working on developing 5G related standards and we have some ques= tions related to RFC7296 regarding IKE SA creation time. Paul suggested me to post the questions to IPsecME mailing list.  Your feedback/clarification would = be very much appreciated.

 =

According RFC7296, after= IKE_SA_INIT exchange, session key is established after Diffie-Hellman exch= ange, which means all subsequent messages are protected. This seems to mean that IKE SA is already created after IKE_SA_INIT, then = first child SA is established after IKE_AUTH exchange.  Is this unders= tanding correct? i.e. Is IKE SA created after IKE_SA_INIT exchange or after= IKE_AUTH exchange?

 =

-------<snip>-----= -------------------

The first pair of messages (IKE_SA_INIT) negotiate
cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
exchange [DH].

The second pair of messages (IKE_AUTH) authenticate the previous
messages, exchange identities and certificates, and establish the
first Child SA.

 

 =

Regards,

Jennifer

 =

--_000_AM6PR07MB4599003526DAFDBB37478B09E5370AM6PR07MB4599eurp_-- From nobody Thu Aug 23 05:18:30 2018 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 050FC129C6A for ; Thu, 23 Aug 2018 05:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXzbWl-0alhO for ; Thu, 23 Aug 2018 05:18:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57398120049 for ; Thu, 23 Aug 2018 05:18: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 w7NCII4C012861 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Aug 2018 15:18:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w7NCIH4Q011028; Thu, 23 Aug 2018 15:18:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23422.42505.91060.558242@fireball.acr.fi> Date: Thu, 23 Aug 2018 15:18:17 +0300 From: Tero Kivinen To: Ivo Sedlacek Cc: "Liu\, Jennifer \(Nokia - US\/Plano\)" , "ipsec\@ietf.org" , Paul Hoffman , "charliekaufman\@outlook.com" In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] RFC7296 (IKEv2) IKE SA creation question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 12:18:29 -0000 Ivo Sedlacek writes: > RFC7296 states: > > ---------------- > >>The first two exchanges of messages > establishing an IKE SA are called the IKE_SA_INIT exchange and the > IKE_AUTH exchange<<; subsequent IKE exchanges are called either > CREATE_CHILD_SA exchanges or INFORMATIONAL exchanges. > ---------------- > > and > > ---------------- > If the failure is related to creating the IKE SA (for example, an > AUTHENTICATION_FAILED Notify error message is returned), >>the IKE SA > is not created<<. > ---------------- > > and > > ---------------- > In >>an IKE_AUTH exchange<<, or in the INFORMATIONAL exchange immediately > following it (in case an error happened when processing a response to > IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and > AUTHENTICATION_FAILED notifications are the only ones to cause the > IKE SA to be deleted or >>not created<<, without a Delete payload. > ---------------- > > I interpret the above to mean that IKE SA is created only after completion of > IKE_AUTH exchange. Your understanding is correct. IKE SA is created only after successfull IKE_AUTH exchange. > From: Liu, Jennifer (Nokia - US/Plano) > Sent: Wednesday, August 22, 2018 1:10 PM > To: ipsec@ietf.org > Cc: Paul Hoffman ; charliekaufman@outlook.com; Ivo > Sedlacek > Subject: RFC7296 (IKEv2) IKE SA creation question > > Hi, All, > > 3GPP CT1 workgroup is currently working on developing 5G related standards and > we have some questions related to RFC7296 regarding IKE SA creation time. Paul > suggested me to post the questions to IPsecME mailing list. Your feedback/ > clarification would be very much appreciated. > > According RFC7296, after IKE_SA_INIT exchange, session key is established > after Diffie-Hellman exchange, which means all subsequent messages are > protected. Session keys are established and messages are protected, but the whole SA is not yet authenticated. I.e., even if we know that the messages are encrypted and MACed, we do not know if they are coming from the node we think they are coming from. > This seems to mean that IKE SA is already created after IKE_SA_INIT, > then first child SA is established after IKE_AUTH exchange. Is this > understanding correct? i.e. Is IKE SA created after IKE_SA_INIT > exchange or after IKE_AUTH exchange? IKE_AUTH as the name says, authenticates the peers. I.e., only after that we actually know who is on the other end of the IKE SA, and we know that there cannot be man-in-the-middle attacker there. IKE_AUTH is required part for making IKE SA, and in addition to that it can also optionally create first Child SA. Note, that the first Child SA creation can fail, but still the IKE SA will be created, and also using Childless Inititiation of IKEv2 (RFC6023) the Child SA creation is not even tried, but IKE_AUTH is still needed to create the IKE SA. > ------------------------------- > > The first pair of messages (IKE_SA_INIT) negotiate > cryptographic algorithms, exchange nonces, and do a Diffie-Hellman > exchange [DH]. > > The second pair of messages (IKE_AUTH) authenticate the previous > messages, exchange identities and certificates, and establish the > first Child SA. -- kivinen@iki.fi From heinrich.ietf@gmail.com Thu Aug 23 11:32:20 2018 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 088D0130EE5; Thu, 23 Aug 2018 11:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 POMPwucDFoGY; Thu, 23 Aug 2018 11:32:16 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10853130EE9; Thu, 23 Aug 2018 11:32:16 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id h20-v6so8835105itf.2; Thu, 23 Aug 2018 11:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/ks7z4XxLgOMJ/Hf2g3TEOqYRBhpXAIjkzJ9YAmwDmc=; b=uDgJ2dx8W94h++YA97mF2P2Mg791oKLrRfFYRpEc6L3i2d4PRMIMiz/HxYotMGlfTq bZ6y5KReAPF8hJUTIaPTnwPYAwZp8co1O5OeXa/f+IptPijD7UkTplrHO5HoTU6mfcOi ZBbkhCBIunKaQnClrG4rOOO2ciczVA9VhRy07DCVxJaBX7FZoPkV31aVyRFp21PNX+hE whIT0I1TZYsfaK7K4EoXj3VwLv7ssa9Kz0lIdFjxZX6jGtnU2H1uz8eMsrqlaZc8nN9X 5tAgpDrxcFS5nloLN1dbuMQ3hYhE8WqOhEAu17ZlSBG3+ILdZaIj+sv8Px7bU37Pg9Bz fjoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/ks7z4XxLgOMJ/Hf2g3TEOqYRBhpXAIjkzJ9YAmwDmc=; b=izp4AozIDP4vU9aIxESMW+uLl/IbiUyusdqo7VWZPvXYBfHY8xJkiw7YrpScHeZ1/V yuJrJZ9+l2glN+R07JBGbPuQ4/mQ8oUxcv6ic30txRf/h72fwKW/YqMPcTzgttf3jiv1 PxeIQIvLwLEri8LxPHAz1FThyREhWTy0pfMftIqHFhrB6Se/BzQFYkTKAA+6ZLKidWF4 pJT+b62eypL77jSnZiKBKBxEFZSxW8EuiThnch+2DiA7TjOzSk2GjUE/uly5Ut9CzK5m BefUfo8H3joY1Emsk3v2sH6A/Sd7Iw6dbFCLKp4Q3Q0HQ4JQQ//m8ahB0rDTGp7i5Kbe igrg== X-Gm-Message-State: APzg51D8to9kl1hZzUyTqgHAMu80Trw1bp/47G1IFhfdED/jKcaP6LdB +ZoVQprjPDLwwWf24CDIz53wd/3/QCi15+A6NlEVBhSpFpYtlQ== X-Google-Smtp-Source: ANB0VdYL4h1+bY+PxuzfvJnonRS5oxuWVfdjwAKmtfUnKBUEuUiMDIg53/9b72zinKVjVAII8lZwbYkfoKLVbICcudQ= X-Received: by 2002:a24:282:: with SMTP id 124-v6mr7184305itu.151.1535049135209; Thu, 23 Aug 2018 11:32:15 -0700 (PDT) MIME-Version: 1.0 From: Heinrich Singh Date: Thu, 23 Aug 2018 21:32:03 +0300 Message-ID: To: lwip@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary="0000000000006ac41c05741e7aa7" Archived-At: Subject: [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 04:22:32 -0000 --0000000000006ac41c05741e7aa7 Content-Type: text/plain; charset="UTF-8" Hello IETF, I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my summary: 1. Don't use random SPI because getting randomness on small devices is expensive. This will of course leak privacy. If a vendor/app uses fixed SPI for his devices, then someone on the network can find out info of vendor/app. Also, why a device can generate random number for doing IKEv2, nonces etc. but not for generating SPI? 2. Storing sequence numbers is difficult so devices can use time. Getting time on small devices is actually much harder. Also is there some hard info that reading time is cheaper than reading sequence number from memory? I can also look at packets much later and tell when you sent a packet. 3. Don't use Traffic Flow Confidentiality again loosing privacy. 4. Don't use dummy packets again loosing privacy. 5. Reference rfc 8221 for IoT related crypto suites. I don't know why IETF would publish this document when they have rfc 6973. I want to see some actual performance from a real ESP implementation where privacy is protected and energy is saved by tweaking the TFC and how often dummy packet is sent. Ciao Heinrich --0000000000006ac41c05741e7aa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello IETF,

I am new to LWIP= /IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my summary:
<= br>
  1. Don't use random SPI because getting randomness o= n small devices is expensive. This will of course leak privacy. If a vendor= /app uses fixed SPI for his devices, then someone on the network can find o= ut info of vendor/app. Also, why a device can generate random number for do= ing IKEv2, nonces etc. but not for generating SPI?
  2. Storing sequence= numbers is difficult so devices can use time. Getting time on small device= s is actually much harder. Also is there some hard info that reading time i= s cheaper than reading sequence number from memory? I can also look at pack= ets much later and tell when you sent a packet.
  3. Don't use Traff= ic Flow Confidentiality again loosing privacy.
  4. Don't use dummy = packets again loosing privacy.
  5. Reference rfc 8221 for IoT related c= rypto suites.
I don't know why IETF would publ= ish this document when they have rfc 6973. I want to see some actual perfor= mance from a real ESP implementation where privacy is protected and energy = is saved by tweaking the TFC and how often dummy packet is sent.
=

Ciao
Heinrich
--0000000000006ac41c05741e7aa7-- From nobody Mon Aug 27 08:59:01 2018 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 DAF40130E07; Mon, 27 Aug 2018 08:58:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153538553181.29963.3384099063483005643.idtracker@ietfa.amsl.com> Date: Mon, 27 Aug 2018 08:58:51 -0700 Archived-At: Subject: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 15:58:52 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-09-06. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Eric Rescorla Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar quantum resistant properties to those of IKEv1. Split-DNS is a common configuration for VPN deployments in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS, however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. Non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. Milestones: Apr 2018 - IETF Last Call on Split-DNS Configuration for IKEv2 Apr 2018 - IETF Last Call on Implicit IV in IPsec May 2018 - IETF Last Call on partially quantum resistant IKEv2 Oct 2018 - The internal address failure indication in IKEv2 to IESG Dec 2018 - The ESP on contrained network to IESG Dec 2018 - G-DOI for IKEv2 to IESG Jan 2019 - The security labels support for IKEv2 to IESG Mar 2019 - Signature algorithm negotiation for IKEv2 to IESG May 2019 - Postquantum cryptography document for IKEv2 to IESG From nobody Wed Aug 29 09:17:33 2018 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 13437130DE6; Wed, 29 Aug 2018 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 Fs_4iWQWwvMY; Wed, 29 Aug 2018 09:17:23 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 00412130DD9; Wed, 29 Aug 2018 09:17:22 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id f1-v6so4856236ljc.9; Wed, 29 Aug 2018 09:17:22 -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=6uEuJrESKcyzCwWv4Xim7lLPRa9Ekn35MFR2g0llsIQ=; b=XM3HmsGoIWMc4EBipSUUePLijDnce3sONzxEWx6C8PuSlo+0+J4UJILF5jaLaUSEzo JW9vuYqqrJ5snAvNVjpAo25OIMR/IHB/f8fap1SLi4BCqm1DKcJUem+mKvLy0zRd90BC xAfWoB+UzzSdnomePu203DFoPP6Nlgd1TzHpfrKJ+YrTqG1nwFRCWD8426aBHAZyd++/ +0SrLbmiL0KSsM8bAeDAsqekqr2PYfntxQRQ6Wg+/mBT8kT9/kMvUDwgnd2WEH0x5FyD tTQ+JqEw5RZ+kOD2n2zcs+ZQq79GKqxejUoMg818wJ+Q3zfIxuWER7OWX5ax8lPSN5Yy 0yjw== 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=6uEuJrESKcyzCwWv4Xim7lLPRa9Ekn35MFR2g0llsIQ=; b=nCVq0cSxllsjUfH56MYDOx97gaInaN/sR57xSqZJx1jdxWGrGKwn0ZZwOkGjJYB8F6 dGV3xn+x3YnHHJO6hOp1kChQJufF+4N9scfGPh49mAvRqKB74Y2MlCXT6h+xM8z/GtE7 qHVVVvR4d5hYJfCnGOhPLO8adpV5rj/yb81CuPwCSnuPs57GBG59iGonXYTWv8sW/Ivc CUuNP4Va7w4pM4h616csGlreSyxKBsXbEXKbeDto/4ZZ0JtvHvq0vMyUA+Hq8hfM7x62 fe9a0PFZ6pGDOG2z7eTUqYDrMKCp1x6uqRsZ56z3WYthY5sKSbdv1CJlNDwuoVZd1tqx Rubw== X-Gm-Message-State: APzg51B4tIRZmhHEVCM3LZtz/bFcxweF5GDoTO9TLyInEkQtgkYFf1zJ U+GsLkAa1L2+m3pVThk7mhM3/uB3n1xCyIrmuPQ= X-Google-Smtp-Source: ANB0VdZQF6OYPiyYKBjdR6f0Qj1lh5ScD8Tfm64YqcS66YRx3/JZSz5Y2JmEinQ+BLhxBBfMHH3qH027WoeYeKcgNCY= X-Received: by 2002:a2e:5d57:: with SMTP id r84-v6mr4647576ljb.89.1535559441038; Wed, 29 Aug 2018 09:17:21 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:912:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 09:17:20 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Wed, 29 Aug 2018 12:17:20 -0400 X-Google-Sender-Auth: ufcMMfKfA_w2Xrd0A027IfbgMXM Message-ID: To: Heinrich Singh Cc: lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="00000000000003c1000574954bb0" Archived-At: Subject: Re: [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 16:17:27 -0000 --00000000000003c1000574954bb0 Content-Type: text/plain; charset="UTF-8" Hi Heinrich, Thank you for reviewing the draft. Please find my response inline. I believe your concerns are addressed in the draft within the scope of the draft. The work you are mostly looking at would be an efficient TFC / dummy packet policy. This would more probably be in scope of ipsecme WG. Yours, Daniel On Thu, Aug 23, 2018 at 2:32 PM, Heinrich Singh wrote: > Hello IETF, > > I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my > summary: > > > 1. Don't use random SPI because getting randomness on small devices is > expensive. This will of course leak privacy. If a vendor/app uses fixed SPI > for his devices, then someone on the network can find out info of > vendor/app. > > This is correct and I believe this statement is provided in the draft. Is there, in your opinion, anything we should add in the text below: The use of a limited number of fix SPI also come with security or privacy drawbacks. Typically, a passive attacker may derive information such as the number of constrained devices connecting the remote peer, and in conjunction with data rate, the attacker may eventually determine the application the constrained device is associated to. In addition, if the fix value SPI is fixed by a manufacturer or by some software application, the SPI may leak in an obvious way the type of sensor, the application involved or the model of the constrained device. As a result, the use of a unpredictable SPI is preferred to provide better privacy. As far as security is concerned, revealing the type of application or model of the constrained device could be used to identify the vulnerabilities the constrained device is subject to. This is especially sensitive for constrained device where patches or software updates will be challenging to operate. As a result, these devices may remain vulnerable for relatively long period. In addition, predictable SPI enable an attacker to forge packets with a valid SPI. Such packet will not be rejected due to an SPI mismatch, but instead after the signature check which requires more resource and thus make DoS more efficient, especially for devices powered by batteries. Also, why a device can generate random number for doing IKEv2, nonces etc. but not for generating SPI? I am reading your text as if the draft were recommending the use of non random SPI, while you would expect the draft to recommend a random generation of the SPI. I think the draft address your comment by recommending a random generation of the SPI with the text below: It is RECOMMENDED to randomly generate the SPI indexing each inbound session. A random generation provides a stateless way to generate the SPIs, while keeping the probability of collision between SPIs relatively low. In case of collision, the SPI is simply re- generated. We could have hardly go further for example by saying SPI MUST be randomly generated as this is not required by RFC4303. Such requirement woudl have been out of scope of the draft as the purpose of the draft is not to update the standard ESP and become a replacement of RFC4303. instead, its purpose is to implement a minimal version of RFC 4303. SPI randomness is not required by RFC4303, so this document cannot mandate SPI generation to be random. The draft also clearly stated that non compromise on random generator should mad for random used for cryptographic purpose. This is not the case for SPI, and some device may, when necessary, use this to save cycles. > > 1. Storing sequence numbers is difficult so devices can use time. > Getting time on small devices is actually much harder. Also is there some > hard info that reading time is cheaper than reading sequence number from > memory? I can also look at packets much later and tell when you sent a > packet. > > We received this example from people following IEEE802.15. It would be good you share your information why reading time is much harder, so the discussion can happen on the mailing list. From my perspective the main idea was to explain that you could take advantage of an already existing "always increasing" function set on your device. Typically, the time is shared across the device and can be used by ALL session, instead of having multiple Sequence numbers. As a side note, if your cases does not fit this, you do not necessarily need to follow this implementation ;-). However, I am happy if your are proposing text to make this more accurate. > > 1. Don't use Traffic Flow Confidentiality again loosing privacy. > > I believe this is what the current version of the draft says. However, as mentioned before, this draft is not updating RFC4303 and as such cannot make this feature mandatory. In addition, TFC is *really* not the kind of feature we expect for a minimal implementation in constrint devices. Typically it consists in adding extra bytes while this is precisely the tasks that consumes the more resource for most of the constraint devices. In addition, managing TFC to avoid creating a new pattern is neither trivial, nor widely used. It woudl be mostly based on statistics, and such functionalities are not expected to be found on constraint device. It is not obvious also that such option could introduce specific patterns which could also loose privacy. Again if you find the text misleading, I am happy you propose text to improve it. ESP [RFC4303 ] also provides Traffic Flow Confidentiality (TFC) as a way to perform padding to hide traffic characteristics, which differs from respecting a 32 bit alignment. TFC is not mandatory and MUST be negotiated with the SA management protocol. As a result, TFC is not expected to be supported by a minimal ESP implementation. On the other hand, disabling TFC should be carefully measured and understood as it exposes the node to traffic shaping. This could expose the application as well as the devices used to a passive monitoring attacker. Such information could be used by the attacker in case a vulnerability is disclosed on the specific device. In addition, some application use - such as health applications - may also reveal important privacy oriented informations. Some constrained nodes that have limited battery life time may also prefer avoiding sending extra padding bytes. However the same nodes may also be very specific to an application and device. As a result, they are also likely to be the main target for traffic shaping. In most cases, the payload carried by these nodes is quite small, and the standard padding mechanism may also be used as an alternative to TFC, with a sufficient trade off between the require energy to send additional payload and the exposure to traffic shaping attacks. > > 1. Don't use dummy packets again loosing privacy. > > The draft does not prevent the use of dummy packets. Instead implementation must be able to discard received dummy packet.. I believe the issue you are raising is that RECOMMEND be changed in MUST. Thanks for raising this I will update the draft. What the draft says is rather setting a widely used policies for generating dummy packets, i.e. that is generating none. I do not think we expect more from a minimal implementation. Similarly, handling dummy packet is not obvious, and maybe not expected to be treated correctly by constrained devices. The draft also mention the privacy issues associated to not generating dummy packets. Is there any text you woudl like to propose ? The ability to generate and receive dummy packet is required by [RFC4303 ]. For interoperability, it is RECOMMENDED a minimal ESP implementation discards dummy packets. Note that such recommendation only applies for nodes receiving packets, and that nodes designed to only send data may not implement this capability. As the generation of dummy packets is subject to local management and based on a per-SA basis, a minimal ESP implementation may not generate such dummy packet. More especially, in constrained environments sending dummy packets may have too much impact on the device life time, and so may be avoided. On the other hand, constrained nodes may be dedicated to specific applications, in which case, traffic pattern may expose the application or the type of node. For these nodes, not sending dummy packet may have some privacy implication that needs to be measured. > > 1. Reference rfc 8221 for IoT related crypto suites. > > The draft provide the reference at least 5 times. > > 1. > > I don't know why IETF would publish this document when they have rfc 6973. > I want to see some actual performance from a real ESP implementation where privacy is protected and energy is saved by tweaking the TFC and how often dummy packet is sent. I agree that would be an interesting topic, but outside teh scope of defining a minimal implementation for the current ESP. I believe the work you are expecting is the definition of an efficient TFC / dummy packet policies. This is currently more a research project. This may be a link of interest: https://www.researchgate.net/publication/224720331_Traffic_masking_in_IPsec_architecture_and_implementation > > Ciao > Heinrich > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --00000000000003c1000574954bb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Heinrich,

Thank you = for reviewing the draft. Please find my response inline. I believe your con= cerns are addressed in the draft within the scope of the draft. The work yo= u are mostly looking at would be an efficient TFC / dummy packet policy. Th= is would more probably be in scope of ipsecme WG.

=
Yours,
Daniel



On Thu, Aug 23= , 2018 at 2:32 PM, Heinrich Singh <heinrich.ietf@gmail.com> wrote:
Hello IETF,

I am new to LWIP/IPSEC. = I read draft-mglt-lwig-minimal-esp. Here is my summary:

  1. Don't use random SPI because getting randomness on small = devices is expensive. This will of course leak privacy. If a vendor/app use= s fixed SPI for his devices, then someone on the network can find out info = of vendor/app.
<mglt>
This is correct and I believe this statement is provided in the draft. I= s there, in your opinion, anything we should add in the text below:

   The use of a limited =
number of fix SPI also come with security or
   privacy drawbacks.  Typically, a passive attacker may derive
   information such as the number of constrained devices connecting the
   remote peer, and in conjunction with data rate, the attacker may
   eventually determine the application the constrained device is
   associated to.  In addition, if the fix value SPI is fixed by a
   manufacturer or by some software application, the SPI may leak in an
   obvious way the type of sensor, the application involved or the model
   of the constrained device.  As a result, the use of a unpredictable
   SPI is preferred to provide better privacy.

   As far as security is concerned, revealing the type of application or
   model of the constrained device could be used to identify the
   vulnerabilities the constrained device is subject to.  This is
   especially sensitive for constrained device where patches or software
   updates will be challenging to operate.  As a result, these devices
   may remain vulnerable for relatively long period.  In addition,
   predictable SPI enable an attacker to forge packets with a valid SPI.
   Such packet will not be rejected due to an SPI mismatch, but instead
   after the signature check which requires more resource and thus make
   DoS more efficient, especially for devices powered by batteries.
</mglt>
=C2=A0Also, why a device can gener= ate random number for doing IKEv2, nonces etc. but not for generating SPI?<= /div>

<mglt>

I am reading= your text as if the draft were recommending the use of non random SPI, whi= le you would expect the draft to recommend a random generation of the SPI. = I think the draft address your comment by recommending a random generation = of the SPI with the text below:

   It is RECOMMENDED to randomly generate the SPI indexing each =
inbound
   session.  A random generation provides a stateless way to generate
   the SPIs, while keeping the probability of collision between SPIs
   relatively low.  In case of collision, the SPI is simply re-
   generated.

We could have hardly go further for example by saying = SPI MUST be randomly generated as this is not required by RFC4303. Such req= uirement woudl have been out of scope of the draft as the purpose of the dr= aft is not to update the standard ESP and become a replacement of RFC4303. = instead, its purpose is to implement a minimal version of RFC 4303. SPI ran= domness is not required by RFC4303, so this document cannot mandate SPI gen= eration to be random.=C2=A0

The draft also clearly stated that non compromise on random generator= should mad for random used for cryptographic purpose. This is not the case= for SPI, and some device may, when necessary, use this to save cycles.
</mglt>
  1. Storing s= equence numbers is difficult so devices can use time. Getting time on small= devices is actually much harder. Also is there some hard info that reading= time is cheaper than reading sequence number from memory? I can also look = at packets much later and tell when you sent a packet.
<mglt>
We received this example from peo= ple following IEEE802.15. It would be good you share your information why r= eading time is much harder, so the discussion can happen on the mailing lis= t. From my perspective the main idea was to explain that you could take adv= antage of an already existing "always increasing" function set on= your device. Typically, the time is shared across the device and can be us= ed by ALL session, instead of having multiple Sequence numbers.
<= div>
As a side note, if your cases does not fit this, you do = not necessarily need to follow this implementation ;-). However, I am happy= if your are proposing text to make this more accurate.=C2=A0
</mglt>
=
  1. Don't use Traffic Flow Confidentiality ag= ain loosing privacy.
<mglt>
I believe this is what the current version of the draft says. Howev= er, as mentioned before, this draft is not updating RFC4303 and as such can= not make this feature mandatory.

In addition= , TFC is *really* not the kind of feature we expect for a minimal implement= ation in constrint devices. Typically it consists in adding extra bytes whi= le this is precisely the tasks that consumes the more resource for most of = the constraint devices. In addition, managing TFC to avoid creating a new p= attern is neither trivial, nor widely used. It woudl be mostly based on sta= tistics, and such functionalities are not expected to be found on constrain= t device. It is not obvious also that such option could introduce specific = patterns which could also loose privacy. =C2=A0

Again if you find the text misleading, I am happy you propose text to im= prove it.

   ESP [RFC4303] also provides Traffic Flow Co=
nfidentiality (TFC) as a
   way to perform padding to hide traffic characteristics, which differs
   from respecting a 32 bit alignment.  TFC is not mandatory and MUST be
   negotiated with the SA management protocol.  As a result, TFC is not
   expected to be supported by a minimal ESP implementation.  On the
   other hand, disabling TFC should be carefully measured and understood
   as it exposes the node to traffic shaping.  This could expose the
   application as well as the devices used to a passive monitoring
   attacker.  Such information could be used by the attacker in case a
   vulnerability is disclosed on the specific device.  In addition, some
   application use - such as health applications - may also reveal
   important privacy oriented informations.

   Some constrained nodes that have limited battery life time may also
   prefer avoiding sending extra padding bytes.  However the same nodes
   may also be very specific to an application and device.  As a result,
   they are also likely to be the main target for traffic shaping.  In
   most cases, the payload carried by these nodes is quite small, and
   the standard padding mechanism may also be used as an alternative to
   TFC, with a sufficient trade off between the require energy to send
   additional payload and the exposure to traffic shaping attacks.
</mglt>
  1. Don't use dummy packets again = loosing privacy.
<mglt>
<= div>The draft does not prevent the use of dummy packets. Instead implementa= tion must be able to discard received dummy packet.. I believe the issue yo= u are raising is that RECOMMEND be changed in MUST. Thanks for raising this= I will update the draft. What the draft says is rather setting a widely us= ed policies for generating dummy packets, i.e. that is generating none. I d= o not think we expect more from a minimal implementation.
Similarly, handling dummy packet is not obvious, and maybe not= expected to be treated correctly by constrained devices.=C2=A0 The draft a= lso mention the privacy issues associated to not generating dummy packets. = Is there any text you woudl like to propose ?

The ability to generate and receive dummy packe= t is required by [RFC4303]. For interoperability,= it is RECOMMENDED a minimal ESP implementation discards dummy packets. Note that such recommendation only applies for nodes receiving packets, and that nodes designed to only send data may not implement this capability. As the generation of dummy packets is subject to local management and based on a per-SA basis, a minimal ESP implementation may not generate such dummy packet. More especially, in constrained environments sending dummy packets may have too much impact on the device life time, and so may be avoided. On the other hand, constrained nodes may be dedicated to specific applications, in which case, traffic pattern may expose the application or the type of node. For these nodes, not sending dummy packet may have some privacy implication that needs to be measured.
=C2=A0
</mglt>
  1. Ref= erence rfc 8221 for IoT related crypto suites.
<mglt>
The draft provide the reference at least = 5 times.
</mglt>
=C2=A0

  1. <= /li>
I don't know why IETF would publish this document w= hen they have rfc 6973.
I want to see some actual = performance from a real ESP implementation where privacy is protected and e= nergy is saved by tweaking the TFC and how often dummy packet is sent.
=

<m= glt>
I agree that would be an interestin= g topic, but outside teh scope of defining a minimal implementation for the= current ESP. I believe the work you are expecting is the definition of an = efficient TFC / dummy packet policies. This is currently more a research pr= oject. This may be a link of interest:
https://www.researchgate.net/publi= cation/224720331_Traffic_masking_in_IPsec_architecture_and_implementation

</mglt>

--00000000000003c1000574954bb0-- From nobody Thu Aug 30 10:17:41 2018 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 591D1130ECB; Thu, 30 Aug 2018 10:17:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Chown To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-split-dns.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153564945232.3185.2788662815270412102@ietfa.amsl.com> Date: Thu, 30 Aug 2018 10:17:32 -0700 Archived-At: Subject: [IPsec] Opsdir last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 17:17:32 -0000 Reviewer: Tim Chown Review result: Has Issues Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The document is well-written and clear to follow, and addresses an existing problem. Overall, the document is close to being ready for publication. I have a couple of clarification questions, and a couple of minor nits. Firstly, I am a little confused by the apparent discrepancy in Sections 1 (Introduction) and 5 (INTERNAL_DNS_DOMAIN Configuration Guidelines). In Section 1, paragraph 3 it says: " The INTERNAL_DNS_DOMAIN attribute type is used to convey one or more DNS domains that SHOULD be resolved only using the provided DNS nameserver IP addresses, causing these requests to use the IPsec connection." But in Section 5 it says: "For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not prohibited by local policy, the client MUST use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only resolvers for the listed domains and its sub-domains and it MUST NOT attempt to resolve the provided DNS domains using its external DNS servers. " So is it a SHOULD or a MUST, or is there a contextual difference I've overlooked here? Secondly, should the case of a client in a dual-stack environment only getting an INTERNAL_IP4_DNS in the response be explicitly mentioned, in that in such cases presumably the client should then not do any DNS resolution over IPv6 transport to any other IPv6-enabled resolvers it has learnt? There are various related issues discussed in RFC 7359. First nit: In Section 3.4.1 perhaps it would be better to move the explanation paragraph(s) to after the example, to improve the flow of the text. Similarly in 3.4.2, move the explanation after the example configuration. Second nit: Is the Background section needed given the Introduction? The Background text would for example be a good start to the Introduction section. From nobody Fri Aug 31 00:12:24 2018 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 DF9DF130E13; Fri, 31 Aug 2018 00:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 8p3gI-4nZxVX; Fri, 31 Aug 2018 00:12:19 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 4D351128CF2; Fri, 31 Aug 2018 00:12:19 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id g33-v6so10215621wrd.1; Fri, 31 Aug 2018 00:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8+/VKTA2QWDz+rWR0n/7++R0YNWeVN+rFvRzxm+djEk=; b=lHaNJDP5iub2DeAfjelPLspvbnGwWZ8+wKsrRT52eDfJR4YPwnVPWmjFfqLYKSivAq x43nO+BHVPdoCjrTaWbgA/OIaTDOmxpw2FyhNZfAWO5KrzBl+/M7hINzsTVkV1yxBlmG LjbnstiLKsh6+ntjfTx3CJgoEox2dUfWg40RlD6Cm0aAPynaIgshiJD9jQsnA/OQ+cCr V9kYZsCJK0lbluiILe1bX/hasqu0TsQwF3cM7iz/HyZuLUTRtysnnIMKA9MCEQEid/+q mU7ldhuiw8FEn2ZLDUiDIb/LF8QPYIFj1b/Nv4tZ51YTaFN0kM45TAM0RDzRaaYRslOO h9Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8+/VKTA2QWDz+rWR0n/7++R0YNWeVN+rFvRzxm+djEk=; b=uVq0D/FLNyn8iDTIehKF4LPoekyGrqAyKbqYZiprUr4x9Dz9G2J9kEEl4Om4ut51V+ S/1vTIPSphxyAUkYCC8XAnysPO2fjSzLB4eRxgVs13xNv7HH7AfkqaQ0wW0/gY7Yov+V 8+RXnLm9viJy11yUYjEUlcaAbbRIiwohY8TY8fhB2Yj/kmPVaDgCd5d2yBB7DJLN2DLG NsyKiYSV1wqltqzj61nf0qKjgyukya7sNaOkfuxUy6ZuIqjD0SFHP1DKoCQu4t47upZR tE5229X9wC5HwEu/VIfRTz1uUxpcglHEdcSbOkMTLuujwJ4R5lDGR2UkdIaZ+oB/+DAL IWIA== X-Gm-Message-State: APzg51CKYcsv/p5gREbgkuOiTBC/NKBzrBlcJWyW/WYvxV52qgQpC8uV S0G2rMQ3n97e6Wo2FuJHHxAYEUWRT8ziWEZbvRY= X-Google-Smtp-Source: ANB0Vdb6iJ/rI3uD+YAfJVqaUykQHHHhPKZ7k+/JCEAqI5fji5F9o7yATFQ0QAcoFlP671pkjJog91/wsAL6HyLfbss= X-Received: by 2002:adf:b726:: with SMTP id l38-v6mr9370541wre.115.1535699537763; Fri, 31 Aug 2018 00:12:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Heinrich Singh Date: Fri, 31 Aug 2018 10:12:05 +0300 Message-ID: To: daniel.migault@ericsson.com Cc: lwip@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary="0000000000006e22990574b5e958" Archived-At: Subject: Re: [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 07:12:23 -0000 --0000000000006e22990574b5e958 Content-Type: text/plain; charset="UTF-8" Hello Daniel, Text saying that you would loose some privacy by using fixed number of SPI does not absolve your responsibility. It should not recommend that. I do not know 802.15. Others can also say what they feel but from my experience simple monotonic sequence numbers are more easier than having a clocks. This I think is a not a good idea. Sender and receiver can easily get out of sync because your rate of sending packets is not proportional to time. The receiver would need to allow very large window. The sender would still need to store time to flash in-case there is need for sync after device reset. What you mean implementations must discard dummy packets? Even non-constrained implementations must discard dummy packets so what is new here? Okay. the paper you send me is for linux kernel, not for constrained device. Ciao Heinrich On Wed, 29 Aug 2018 at 19:17, Daniel Migault wrote: > Hi Heinrich, > > Thank you for reviewing the draft. Please find my response inline. I > believe your concerns are addressed in the draft within the scope of the > draft. The work you are mostly looking at would be an efficient TFC / dummy > packet policy. This would more probably be in scope of ipsecme WG. > > Yours, > Daniel > > > > On Thu, Aug 23, 2018 at 2:32 PM, Heinrich Singh > wrote: > >> Hello IETF, >> >> I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my >> summary: >> >> >> 1. Don't use random SPI because getting randomness on small devices >> is expensive. This will of course leak privacy. If a vendor/app uses fixed >> SPI for his devices, then someone on the network can find out info of >> vendor/app. >> >> > This is correct and I believe this statement is provided in the draft. Is > there, in your opinion, anything we should add in the text below: > > The use of a limited number of fix SPI also come with security or > privacy drawbacks. Typically, a passive attacker may derive > information such as the number of constrained devices connecting the > remote peer, and in conjunction with data rate, the attacker may > eventually determine the application the constrained device is > associated to. In addition, if the fix value SPI is fixed by a > manufacturer or by some software application, the SPI may leak in an > obvious way the type of sensor, the application involved or the model > of the constrained device. As a result, the use of a unpredictable > SPI is preferred to provide better privacy. > > As far as security is concerned, revealing the type of application or > model of the constrained device could be used to identify the > vulnerabilities the constrained device is subject to. This is > especially sensitive for constrained device where patches or software > updates will be challenging to operate. As a result, these devices > may remain vulnerable for relatively long period. In addition, > predictable SPI enable an attacker to forge packets with a valid SPI. > Such packet will not be rejected due to an SPI mismatch, but instead > after the signature check which requires more resource and thus make > DoS more efficient, especially for devices powered by batteries. > > > > Also, why a device can generate random number for doing IKEv2, nonces > etc. but not for generating SPI? > > > > I am reading your text as if the draft were recommending the use of non > random SPI, while you would expect the draft to recommend a random > generation of the SPI. I think the draft address your comment by > recommending a random generation of the SPI with the text below: > > It is RECOMMENDED to randomly generate the SPI indexing each inbound > session. A random generation provides a stateless way to generate > the SPIs, while keeping the probability of collision between SPIs > relatively low. In case of collision, the SPI is simply re- > generated. > > > We could have hardly go further for example by saying SPI MUST be randomly > generated as this is not required by RFC4303. Such requirement woudl have > been out of scope of the draft as the purpose of the draft is not to update > the standard ESP and become a replacement of RFC4303. instead, its purpose > is to implement a minimal version of RFC 4303. SPI randomness is not > required by RFC4303, so this document cannot mandate SPI generation to be > random. > > The draft also clearly stated that non compromise on random generator > should mad for random used for cryptographic purpose. This is not the case > for SPI, and some device may, when necessary, use this to save cycles. > > > >> >> 1. Storing sequence numbers is difficult so devices can use time. >> Getting time on small devices is actually much harder. Also is there some >> hard info that reading time is cheaper than reading sequence number from >> memory? I can also look at packets much later and tell when you sent a >> packet. >> >> > We received this example from people following IEEE802.15. It would be > good you share your information why reading time is much harder, so the > discussion can happen on the mailing list. From my perspective the main > idea was to explain that you could take advantage of an already existing > "always increasing" function set on your device. Typically, the time is > shared across the device and can be used by ALL session, instead of having > multiple Sequence numbers. > > As a side note, if your cases does not fit this, you do not necessarily > need to follow this implementation ;-). However, I am happy if your are > proposing text to make this more accurate. > > >> >> 1. Don't use Traffic Flow Confidentiality again loosing privacy. >> >> > I believe this is what the current version of the draft says. However, as > mentioned before, this draft is not updating RFC4303 and as such cannot > make this feature mandatory. > > In addition, TFC is *really* not the kind of feature we expect for a > minimal implementation in constrint devices. Typically it consists in > adding extra bytes while this is precisely the tasks that consumes the more > resource for most of the constraint devices. In addition, managing TFC to > avoid creating a new pattern is neither trivial, nor widely used. It woudl > be mostly based on statistics, and such functionalities are not expected to > be found on constraint device. It is not obvious also that such option > could introduce specific patterns which could also loose privacy. > > Again if you find the text misleading, I am happy you propose text to > improve it. > > ESP [RFC4303 ] also provides Traffic Flow Confidentiality (TFC) as a > way to perform padding to hide traffic characteristics, which differs > from respecting a 32 bit alignment. TFC is not mandatory and MUST be > negotiated with the SA management protocol. As a result, TFC is not > expected to be supported by a minimal ESP implementation. On the > other hand, disabling TFC should be carefully measured and understood > as it exposes the node to traffic shaping. This could expose the > application as well as the devices used to a passive monitoring > attacker. Such information could be used by the attacker in case a > vulnerability is disclosed on the specific device. In addition, some > application use - such as health applications - may also reveal > important privacy oriented informations. > > Some constrained nodes that have limited battery life time may also > prefer avoiding sending extra padding bytes. However the same nodes > may also be very specific to an application and device. As a result, > they are also likely to be the main target for traffic shaping. In > most cases, the payload carried by these nodes is quite small, and > the standard padding mechanism may also be used as an alternative to > TFC, with a sufficient trade off between the require energy to send > additional payload and the exposure to traffic shaping attacks. > > > > >> >> 1. Don't use dummy packets again loosing privacy. >> >> > The draft does not prevent the use of dummy packets. Instead > implementation must be able to discard received dummy packet.. I believe > the issue you are raising is that RECOMMEND be changed in MUST. Thanks for > raising this I will update the draft. What the draft says is rather setting > a widely used policies for generating dummy packets, i.e. that is > generating none. I do not think we expect more from a minimal > implementation. > > Similarly, handling dummy packet is not obvious, and maybe not expected to > be treated correctly by constrained devices. The draft also mention the > privacy issues associated to not generating dummy packets. Is there any > text you woudl like to propose ? > > The ability to generate and receive dummy packet is required by > [RFC4303 ]. For interoperability, it is RECOMMENDED a minimal ESP > implementation discards dummy packets. Note that such recommendation > only applies for nodes receiving packets, and that nodes designed to > only send data may not implement this capability. > > As the generation of dummy packets is subject to local management and > based on a per-SA basis, a minimal ESP implementation may not > generate such dummy packet. More especially, in constrained > environments sending dummy packets may have too much impact on the > device life time, and so may be avoided. On the other hand, > constrained nodes may be dedicated to specific applications, in which > case, traffic pattern may expose the application or the type of node. > For these nodes, not sending dummy packet may have some privacy > implication that needs to be measured. > > > > > > >> >> 1. Reference rfc 8221 for IoT related crypto suites. >> >> > The draft provide the reference at least 5 times. > > > >> >> 1. >> >> I don't know why IETF would publish this document when they have rfc >> 6973. >> > I want to see some actual performance from a real ESP implementation where > privacy is protected and energy is saved by tweaking the TFC and how often > dummy packet is sent. > > > I agree that would be an interesting topic, but outside teh scope of > defining a minimal implementation for the current ESP. I believe the work > you are expecting is the definition of an efficient TFC / dummy packet > policies. This is currently more a research project. This may be a link of > interest: > > https://www.researchgate.net/publication/224720331_Traffic_masking_in_IPsec_architecture_and_implementation > > > >> >> Ciao >> Heinrich >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --0000000000006e22990574b5e958 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Daniel,

Text saying th= at you would=20 loose some privacy by using fixed number of SPI does not absolve your=20 responsibility. It should not recommend that.

I do not know 802.15. Others can also say what they feel but from my=20 experience simple monotonic sequence numbers are more easier than having a clocks. This I think is a not a good idea. Sender and receiver can=20 easily get out of sync because your rate of sending packets is not=20 proportional to time. The receiver would need to allow very large=20 window. The sender would still need to store time to flash in-case there is need for sync after device reset.

What you mean implementations must discard dummy packets? Even=20 non-constrained implementations must discard dummy packets so what is=20 new here?

Okay. the paper you send me is for linux= kernel, not for constrained device.

Ciao
Heinrich

O= n Wed, 29 Aug 2018 at 19:17, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Heinrich,

Thank you for reviewing the draft. Please find my respons= e inline. I believe your concerns are addressed in the draft within the sco= pe of the draft. The work you are mostly looking at would be an efficient T= FC / dummy packet policy. This would more probably be in scope of ipsecme W= G.

Yours,
Daniel



On Thu, Aug 23, 2018 at 2:32 PM, Heinrich Singh <heinr= ich.ietf@gmail.com> wrote:
Hello IETF,

I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my s= ummary:

  1. Don't use random SPI because g= etting randomness on small devices is expensive. This will of course leak p= rivacy. If a vendor/app uses fixed SPI for his devices, then someone on the= network can find out info of vendor/app.
<mglt>
This is correct and I believe this statement = is provided in the draft. Is there, in your opinion, anything we should add= in the text below:

   The use of a limited number of fix SPI also com=
e with security or
   privacy drawbacks.  Typically, a passive attacker may derive
   information such as the number of constrained devices connecting the
   remote peer, and in conjunction with data rate, the attacker may
   eventually determine the application the constrained device is
   associated to.  In addition, if the fix value SPI is fixed by a
   manufacturer or by some software application, the SPI may leak in an
   obvious way the type of sensor, the application involved or the model
   of the constrained device.  As a result, the use of a unpredictable
   SPI is preferred to provide better privacy.

   As far as security is concerned, revealing the type of application or
   model of the constrained device could be used to identify the
   vulnerabilities the constrained device is subject to.  This is
   especially sensitive for constrained device where patches or software
   updates will be challenging to operate.  As a result, these devices
   may remain vulnerable for relatively long period.  In addition,
   predictable SPI enable an attacker to forge packets with a valid SPI.
   Such packet will not be rejected due to an SPI mismatch, but instead
   after the signature check which requires more resource and thus make
   DoS more efficient, especially for devices powered by batteries.
</mglt>
=C2=A0Also, why a device can gener= ate random number for doing IKEv2, nonces etc. but not for generating SPI?<= /div>

<mglt>

I am reading= your text as if the draft were recommending the use of non random SPI, whi= le you would expect the draft to recommend a random generation of the SPI. = I think the draft address your comment by recommending a random generation = of the SPI with the text below:

   It is RECOMMENDED to randomly generate =
the SPI indexing each inbound
   session.  A random generation provides a stateless way to generate
   the SPIs, while keeping the probability of collision between SPIs
   relatively low.  In case of collision, the SPI is simply re-
   generated.

We could have hardly go further for example by saying = SPI MUST be randomly generated as this is not required by RFC4303. Such req= uirement woudl have been out of scope of the draft as the purpose of the dr= aft is not to update the standard ESP and become a replacement of RFC4303. = instead, its purpose is to implement a minimal version of RFC 4303. SPI ran= domness is not required by RFC4303, so this document cannot mandate SPI gen= eration to be random.=C2=A0

The draft also clearly stated that non compromise on random generator= should mad for random used for cryptographic purpose. This is not the case= for SPI, and some device may, when necessary, use this to save cycles.
</mglt>
  1. Storing s= equence numbers is difficult so devices can use time. Getting time on small= devices is actually much harder. Also is there some hard info that reading= time is cheaper than reading sequence number from memory? I can also look = at packets much later and tell when you sent a packet.
<mglt>
We received this example from peo= ple following IEEE802.15. It would be good you share your information why r= eading time is much harder, so the discussion can happen on the mailing lis= t. From my perspective the main idea was to explain that you could take adv= antage of an already existing "always increasing" function set on= your device. Typically, the time is shared across the device and can be us= ed by ALL session, instead of having multiple Sequence numbers.
<= div>
As a side note, if your cases does not fit this, you do = not necessarily need to follow this implementation ;-). However, I am happy= if your are proposing text to make this more accurate.=C2=A0
</mglt>
=
  1. Don't use Traffic Flow Confidentiality ag= ain loosing privacy.
<mglt>
I believe this is what the current version of the draft says. Howev= er, as mentioned before, this draft is not updating RFC4303 and as such can= not make this feature mandatory.

In addition= , TFC is *really* not the kind of feature we expect for a minimal implement= ation in constrint devices. Typically it consists in adding extra bytes whi= le this is precisely the tasks that consumes the more resource for most of = the constraint devices. In addition, managing TFC to avoid creating a new p= attern is neither trivial, nor widely used. It woudl be mostly based on sta= tistics, and such functionalities are not expected to be found on constrain= t device. It is not obvious also that such option could introduce specific = patterns which could also loose privacy. =C2=A0

Again if you find the text misleading, I am happy you propose text to im= prove it.

   ESP [=
RFC4303] also provides Traffic Flow Confidentiality (TFC) as a
   way to perform padding to hide traffic characteristics, which differs
   from respecting a 32 bit alignment.  TFC is not mandatory and MUST be
   negotiated with the SA management protocol.  As a result, TFC is not
   expected to be supported by a minimal ESP implementation.  On the
   other hand, disabling TFC should be carefully measured and understood
   as it exposes the node to traffic shaping.  This could expose the
   application as well as the devices used to a passive monitoring
   attacker.  Such information could be used by the attacker in case a
   vulnerability is disclosed on the specific device.  In addition, some
   application use - such as health applications - may also reveal
   important privacy oriented informations.

   Some constrained nodes that have limited battery life time may also
   prefer avoiding sending extra padding bytes.  However the same nodes
   may also be very specific to an application and device.  As a result,
   they are also likely to be the main target for traffic shaping.  In
   most cases, the payload carried by these nodes is quite small, and
   the standard padding mechanism may also be used as an alternative to
   TFC, with a sufficient trade off between the require energy to send
   additional payload and the exposure to traffic shaping attacks.
</mglt>
  1. Don't use dummy packets again = loosing privacy.
<mglt>
<= div>The draft does not prevent the use of dummy packets. Instead implementa= tion must be able to discard received dummy packet.. I believe the issue yo= u are raising is that RECOMMEND be changed in MUST. Thanks for raising this= I will update the draft. What the draft says is rather setting a widely us= ed policies for generating dummy packets, i.e. that is generating none. I d= o not think we expect more from a minimal implementation.
Similarly, handling dummy packet is not obvious, and maybe not= expected to be treated correctly by constrained devices.=C2=A0 The draft a= lso mention the privacy issues associated to not generating dummy packets. = Is there any text you woudl like to propose ?

The ability to generate a= nd receive dummy packet is required by [RFC4303]. For= interoperability, it is RECOMMENDED a minimal ESP implementation discards dummy packets. Note that such recommendation only applies for nodes receiving packets, and that nodes designed to only send data may not implement this capability. As the generation of dummy packets is subject to local management and based on a per-SA basis, a minimal ESP implementation may not generate such dummy packet. More especially, in constrained environments sending dummy packets may have too much impact on the device life time, and so may be avoided. On the other hand, constrained nodes may be dedicated to specific applications, in which case, traffic pattern may expose the application or the type of node. For these nodes, not sending dummy packet may have some privacy implication that needs to be measured.
=C2=A0
</mglt>
  1. Ref= erence rfc 8221 for IoT related crypto suites.
<mglt>
The draft provide the reference at least = 5 times.
</mglt>
=C2=A0

  1. <= /li>
I don't know why IETF would publish this document w= hen they have rfc 6973.
I want to see some actual = performance from a real ESP implementation where privacy is protected and e= nergy is saved by tweaking the TFC and how often dummy packet is sent.
=

<m= glt>
I agree that would be an interestin= g topic, but outside teh scope of defining a minimal implementation for the= current ESP. I believe the work you are expecting is the definition of an = efficient TFC / dummy packet policies. This is currently more a research pr= oject. This may be a link of interest:
https://www.rese= archgate.net/publication/224720331_Traffic_masking_in_IPsec_architecture_an= d_implementation

</mglt><= br>

Ciao
Heinrich
=

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


--0000000000006e22990574b5e958-- From nobody Fri Aug 31 06:41:55 2018 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 D61CC129AB8; Fri, 31 Aug 2018 06:41: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 Qg9gBWO-AjXR; Fri, 31 Aug 2018 06:41:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9FB127AC2; Fri, 31 Aug 2018 06:41:42 -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 w7VDfNW8009527 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Aug 2018 16:41:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w7VDfNKH002213; Fri, 31 Aug 2018 16:41:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23433.17795.580382.531001@fireball.acr.fi> Date: Fri, 31 Aug 2018 16:41:23 +0300 From: Tero Kivinen To: Heinrich Singh Cc: daniel.migault@ericsson.com, ipsec@ietf.org, lwip@ietf.org In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 27 min Archived-At: Subject: Re: [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 13:41:46 -0000 Heinrich Singh writes: > Text saying that you would loose some privacy by using fixed number > of SPI does not absolve your responsibility. It should not recommend > that. There is no requirement for SPI to be random and originally it was written that way so implementations can use whatever method to allocate SPIs they like. For example they can use index to the SPI table or whatever instead of allocating random SPI, or they could even use pointer to the SPI structure in memory as SPI value (would of course need some kind of checks that address is in area allocated for SPIs and is aligned properly). Adding requirement that SPI needs to be random would be modifying the base ESP, and is not in the scope of draft trying to define minimal ESP. Saying that in contrained devices which have very few SPIs the SPIs can be allocated using some other method than random is in scope of the this draft. Also most of the constrained devices do not care about privacy as they have fixed hardware address, stable IPv6 address and are not associated with any person. Sensor sending wind speed, or temperature to the cloud service does not have privacy requirements, sensors sending temperature inside your house might have (as it might leak out information whether you are home or not), but even in that case the fact that it is your sensor sending information every 60 seconds does not, only the data inside. Privacy requirements are not something that are always there, they always depend heavily about what you do with the protocol. I.e., in some cases the IP addresses, hardware addresses, SPIs etc need to be protected against tracking, but in many cases they do not need to be. This document gives recommendation that in some cases it might be good idea to use fixed SPI as it might make implementations smaller. I.e., if the option is either not to use IPsec at all, as it is too big, or to use IPsec with fixed SPI and other limitations that make it small, I think the option with IPsec is better. > I do not know 802.15. Others can also say what they feel but from my > experience simple monotonic sequence numbers are more easier than > having a clocks. True. But for example 802.15.4 TSCH (i.e., the protocol over which 6TiSCH is working) does have globally shared clock which is kept in sync with everybody. So in that kind of situations using clock as monotonically incrementing counter and using that as sequence number might save resources in constrained device. > This I think is a not a good idea. Sender and receiver can easily > get out of sync because your rate of sending packets is not > proportional to time. The receiver would need to allow very large > window. The sender would still need to store time to flash in-case > there is need for sync after device reset. Sequence numbers are in one direction, i.e., I need to use monotonically incrementing sequence number when I send, but that sequence number does not have anything to do with other ends sequence number. Also window size is need only if you have out of order packets, and you care about replay protection. Both of them are something that might not be something that constrained device cares. For example it might have internal replay protection for the messages it sends, so it does not need to care whether there is replays on the IPsec level, thus it can drop the whole replay protection checks completely. Or it might work on the environment where out of order deliver is not possible, thus it can just keep window size to 1. Also recipient cannot know which method other end is using when generating sequence numbers, so it needs to do the replay protection checking using whatever method it wants. It might need to store the last received sequence number to the flash if it cares about replay protections, or it can simply drop replay protection completely. On the other hand sender is REQUIRED to send sequence numbers in such way they are monotonically incrementing (not necessarely by one), and if it has any kind of other monotonically incrementing counter like clock, it can use that to generate the sequence numbers and get rid of the requirement to store outgoing sequence number to the flash. > What you mean implementations must discard dummy packets? Even > non-constrained implementations must discard dummy packets so what > is new here? Yes. And that quite often happens automatically as there is nobody in the device that wants to get packets with that protocol number. I have not actually never seen anybody sending dummy packets or TFC padding packets in any implementations. I guess most of them know how to ignore them, but sending them is not something people do. And I am not even sure which implementation support for sending dummy packets. TFC is most likely supported in some implementations (libreswan at least seems to support it) as it is much easier to configure, just pad all packets to fixed length. When sending dummy packets configuration is much more complicated, as you need to configure what kind of traffic pattern you want to maintain. So as those are not really used in non-constrained devices, I do not think there is that big different in constrained devices. Again all of this depends on the environment. For example some kind of door sensor might want to keep sending packets every n seconds just not to leak out when the door was opened and closed, but it might just use real packets instead of dummy packets. I.e., it might be configured to send the door status every 30 seconds, and in that packet it tells whether door is now open or closed, and whether what transitions happened during last 30 seconds. Privacy is so hard topic to solve that it always requires you to check out the actual environment and use case where the protocol is used before you can decide what kind of protections are needed. There is no this thing solves all issues solution there. -- kivinen@iki.fi From nobody Fri Aug 31 06:47:37 2018 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 34986130E48; Fri, 31 Aug 2018 06:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0TxoA55l4qR; Fri, 31 Aug 2018 06:47:32 -0700 (PDT) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 F02A5127AC2; Fri, 31 Aug 2018 06:47:31 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id i7-v6so10027262lfh.5; Fri, 31 Aug 2018 06:47:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RmkCWlykSE4YRXPEs61YgwU3EokdYwy/6HK2HeEIl+M=; b=fqHcAWvmCpSjJ23bBYGa2iuCIRAX1+upyOltCWgyBiobrKrMnKEU6OZydnLRMa2ON1 AEoEwDLOlGRFohrW3jGh7cfNr2Ghcb8RTkt6XtaWen2w81JnvUeYy9Gi3ER4nm9N2W8a X0D2E3siwrRRAPzKmcrZh0ztH8YGp3yqzhvXKzxSovRvDOnNPXnTB2633HVdEQz0uGCg Vcsot10EekvnkZAA2RjPIbo/6nPXpkmBKtNhgM0kSJ9B3KHsdb9SvCADgwr1Y//Qzj1V aIctwDCp/UaKvXP46e0KIE+O30zvOWvOftqqu9e+rUY+eBYqY0Yq9MDjXYwHv3obp6Rs Dkng== X-Gm-Message-State: APzg51Bh0h+snPH+uEvTZXSx8p/GcZnwVj3BUObQcMtO+dIfvEXVYsNN duhpiLxoLbmUgnL9fZp6Ct4NKyHO9wsoeQUKLSpoZqOH X-Google-Smtp-Source: ANB0VdadGjiP76cHbqsDCyJ+YvVUgeVQV5rYqm49b9Id31p7he67cEasmAdJ+QA4234UEGc4WTsyrIq7YkYhQ/1zeBA= X-Received: by 2002:a19:73c5:: with SMTP id h66-v6mr10375506lfk.22.1535723249983; Fri, 31 Aug 2018 06:47:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Fri, 31 Aug 2018 09:47:17 -0400 Message-ID: To: Heinrich Singh Cc: IPsecME WG , lwip@ietf.org Content-Type: multipart/alternative; boundary="000000000000c9e2410574bb6eab" Archived-At: Subject: Re: [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 13:47:36 -0000 --000000000000c9e2410574bb6eab Content-Type: text/plain; charset="UTF-8" Hi Heinrich, Thanks for your responses, please see my comments inline. Yours, Daniel On Fri, Aug 31, 2018 at 3:12 AM Heinrich Singh wrote: > Hello Daniel, > > Text saying that you would loose some privacy by using fixed number of SPI > does not absolve your responsibility. It should not recommend that. > > I got your point. Thanks. While fix SPI is permitted by RFC4303, and the document implicitly described it as an non recommended alternative, you would like the guidance to be more explicit. We can add text stating that because of privacy, fix SPI is not recommended for generic purpose implementations. I believe that the point fo this document is to provide some implementation guidance for specific implementation to implement ESP optimized for specific use cases while remaining compatible to the standard ESP. As a result, guidance may go beyond the once fits all use cases. Of course the document should clarify the limitations. > I do not know 802.15. Others can also say what they feel but from my > experience simple monotonic sequence numbers are more easier than having a > clocks. This I think is a not a good idea. Sender and receiver can easily > get out of sync because your rate of sending packets is not proportional to > time. The receiver would need to allow very large window. The sender would > still need to store time to flash in-case there is need for sync after > device reset. > First all of all, the draft clearly stated that the use of time is an alternative ways which is not the most usual implemented mechanism. I believe that similarly as the previous section, we could explicitly mention that the recommended way to generate SSN is to increment it. We can also add text the explicit text regarding the additional constraints, and specify that such way is not recommended for a generic purpose implementation. Similarly we should clarify, the limitations for this specific mechanism, so the mechanism could be chosen only when appropriated. Again, constraint device have different constraints, and there specificities may allo one or the other mechanisms to be used. There are many use cases where devices sends informations are regular time interval and that the lost of a packet will have a limited impact. However I am happy you raises the discussion that can continue on the list. Thank you. > > What you mean implementations must discard dummy packets? Even > non-constrained implementations must discard dummy packets so what is new > here? > > I meant packet with next header value set to 59. Okay. the paper you send me is for linux kernel, not for constrained device. > > Thisis correct. I mentioned it as maybe a starting point for the specific topic your mentioned. > Ciao > Heinrich > > On Wed, 29 Aug 2018 at 19:17, Daniel Migault > wrote: > >> Hi Heinrich, >> >> Thank you for reviewing the draft. Please find my response inline. I >> believe your concerns are addressed in the draft within the scope of the >> draft. The work you are mostly looking at would be an efficient TFC / dummy >> packet policy. This would more probably be in scope of ipsecme WG. >> >> Yours, >> Daniel >> >> >> >> On Thu, Aug 23, 2018 at 2:32 PM, Heinrich Singh >> wrote: >> >>> Hello IETF, >>> >>> I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my >>> summary: >>> >>> >>> 1. Don't use random SPI because getting randomness on small devices >>> is expensive. This will of course leak privacy. If a vendor/app uses fixed >>> SPI for his devices, then someone on the network can find out info of >>> vendor/app. >>> >>> >> This is correct and I believe this statement is provided in the draft. Is >> there, in your opinion, anything we should add in the text below: >> >> The use of a limited number of fix SPI also come with security or >> privacy drawbacks. Typically, a passive attacker may derive >> information such as the number of constrained devices connecting the >> remote peer, and in conjunction with data rate, the attacker may >> eventually determine the application the constrained device is >> associated to. In addition, if the fix value SPI is fixed by a >> manufacturer or by some software application, the SPI may leak in an >> obvious way the type of sensor, the application involved or the model >> of the constrained device. As a result, the use of a unpredictable >> SPI is preferred to provide better privacy. >> >> As far as security is concerned, revealing the type of application or >> model of the constrained device could be used to identify the >> vulnerabilities the constrained device is subject to. This is >> especially sensitive for constrained device where patches or software >> updates will be challenging to operate. As a result, these devices >> may remain vulnerable for relatively long period. In addition, >> predictable SPI enable an attacker to forge packets with a valid SPI. >> Such packet will not be rejected due to an SPI mismatch, but instead >> after the signature check which requires more resource and thus make >> DoS more efficient, especially for devices powered by batteries. >> >> >> >> Also, why a device can generate random number for doing IKEv2, nonces >> etc. but not for generating SPI? >> >> >> >> I am reading your text as if the draft were recommending the use of non >> random SPI, while you would expect the draft to recommend a random >> generation of the SPI. I think the draft address your comment by >> recommending a random generation of the SPI with the text below: >> >> It is RECOMMENDED to randomly generate the SPI indexing each inbound >> session. A random generation provides a stateless way to generate >> the SPIs, while keeping the probability of collision between SPIs >> relatively low. In case of collision, the SPI is simply re- >> generated. >> >> >> We could have hardly go further for example by saying SPI MUST be >> randomly generated as this is not required by RFC4303. Such requirement >> woudl have been out of scope of the draft as the purpose of the draft is >> not to update the standard ESP and become a replacement of RFC4303. >> instead, its purpose is to implement a minimal version of RFC 4303. SPI >> randomness is not required by RFC4303, so this document cannot mandate SPI >> generation to be random. >> >> The draft also clearly stated that non compromise on random generator >> should mad for random used for cryptographic purpose. This is not the case >> for SPI, and some device may, when necessary, use this to save cycles. >> >> >> >>> >>> 1. Storing sequence numbers is difficult so devices can use time. >>> Getting time on small devices is actually much harder. Also is there some >>> hard info that reading time is cheaper than reading sequence number from >>> memory? I can also look at packets much later and tell when you sent a >>> packet. >>> >>> >> We received this example from people following IEEE802.15. It would be >> good you share your information why reading time is much harder, so the >> discussion can happen on the mailing list. From my perspective the main >> idea was to explain that you could take advantage of an already existing >> "always increasing" function set on your device. Typically, the time is >> shared across the device and can be used by ALL session, instead of having >> multiple Sequence numbers. >> >> As a side note, if your cases does not fit this, you do not necessarily >> need to follow this implementation ;-). However, I am happy if your are >> proposing text to make this more accurate. >> >> >>> >>> 1. Don't use Traffic Flow Confidentiality again loosing privacy. >>> >>> >> I believe this is what the current version of the draft says. However, as >> mentioned before, this draft is not updating RFC4303 and as such cannot >> make this feature mandatory. >> >> In addition, TFC is *really* not the kind of feature we expect for a >> minimal implementation in constrint devices. Typically it consists in >> adding extra bytes while this is precisely the tasks that consumes the more >> resource for most of the constraint devices. In addition, managing TFC to >> avoid creating a new pattern is neither trivial, nor widely used. It woudl >> be mostly based on statistics, and such functionalities are not expected to >> be found on constraint device. It is not obvious also that such option >> could introduce specific patterns which could also loose privacy. >> >> Again if you find the text misleading, I am happy you propose text to >> improve it. >> >> ESP [RFC4303 ] also provides Traffic Flow Confidentiality (TFC) as a >> way to perform padding to hide traffic characteristics, which differs >> from respecting a 32 bit alignment. TFC is not mandatory and MUST be >> negotiated with the SA management protocol. As a result, TFC is not >> expected to be supported by a minimal ESP implementation. On the >> other hand, disabling TFC should be carefully measured and understood >> as it exposes the node to traffic shaping. This could expose the >> application as well as the devices used to a passive monitoring >> attacker. Such information could be used by the attacker in case a >> vulnerability is disclosed on the specific device. In addition, some >> application use - such as health applications - may also reveal >> important privacy oriented informations. >> >> Some constrained nodes that have limited battery life time may also >> prefer avoiding sending extra padding bytes. However the same nodes >> may also be very specific to an application and device. As a result, >> they are also likely to be the main target for traffic shaping. In >> most cases, the payload carried by these nodes is quite small, and >> the standard padding mechanism may also be used as an alternative to >> TFC, with a sufficient trade off between the require energy to send >> additional payload and the exposure to traffic shaping attacks. >> >> >> >> >>> >>> 1. Don't use dummy packets again loosing privacy. >>> >>> >> The draft does not prevent the use of dummy packets. Instead >> implementation must be able to discard received dummy packet.. I believe >> the issue you are raising is that RECOMMEND be changed in MUST. Thanks for >> raising this I will update the draft. What the draft says is rather setting >> a widely used policies for generating dummy packets, i.e. that is >> generating none. I do not think we expect more from a minimal >> implementation. >> >> Similarly, handling dummy packet is not obvious, and maybe not expected >> to be treated correctly by constrained devices. The draft also mention the >> privacy issues associated to not generating dummy packets. Is there any >> text you woudl like to propose ? >> >> The ability to generate and receive dummy packet is required by >> [RFC4303 ]. For interoperability, it is RECOMMENDED a minimal ESP >> implementation discards dummy packets. Note that such recommendation >> only applies for nodes receiving packets, and that nodes designed to >> only send data may not implement this capability. >> >> As the generation of dummy packets is subject to local management and >> based on a per-SA basis, a minimal ESP implementation may not >> generate such dummy packet. More especially, in constrained >> environments sending dummy packets may have too much impact on the >> device life time, and so may be avoided. On the other hand, >> constrained nodes may be dedicated to specific applications, in which >> case, traffic pattern may expose the application or the type of node. >> For these nodes, not sending dummy packet may have some privacy >> implication that needs to be measured. >> >> >> >> >> >> >>> >>> 1. Reference rfc 8221 for IoT related crypto suites. >>> >>> >> The draft provide the reference at least 5 times. >> >> >> >>> >>> 1. >>> >>> I don't know why IETF would publish this document when they have rfc >>> 6973. >>> >> I want to see some actual performance from a real ESP implementation >> where privacy is protected and energy is saved by tweaking the TFC and how >> often dummy packet is sent. >> >> >> I agree that would be an interesting topic, but outside teh scope of >> defining a minimal implementation for the current ESP. I believe the work >> you are expecting is the definition of an efficient TFC / dummy packet >> policies. This is currently more a research project. This may be a link of >> interest: >> >> https://www.researchgate.net/publication/224720331_Traffic_masking_in_IPsec_architecture_and_implementation >> >> >> >>> >>> Ciao >>> Heinrich >>> >>> _______________________________________________ >>> 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 > --000000000000c9e2410574bb6eab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Heinrich,

Thanks for= your responses, please see my comments inline.

Yours,
Daniel

=C2=A0

On Fri, Aug 31, 2018 at 3:12 AM Hei= nrich Singh <heinrich.ietf@gm= ail.com> wrote:
Hello Daniel,

Text saying that you would= =20 loose some privacy by using fixed number of SPI does not absolve your=20 responsibility. It should not recommend that.

<mglt>
I got your point. Thanks. While fix S= PI is permitted by=C2=A0 RFC4303, and the document implicitly described it = as an non recommended alternative, you would like the guidance to be more e= xplicit.=C2=A0 We can add text stating that because of privacy, fix SPI is = not recommended for generic purpose implementations.=C2=A0

I believe that the point fo this document is to provide some implem= entation guidance for specific implementation to implement ESP optimized fo= r specific use cases while remaining compatible to the standard ESP. As a r= esult, guidance may go beyond the once fits all use cases. Of course the do= cument should clarify the limitations. =C2=A0 =C2=A0=C2=A0
&= lt;/mglt>

=C2=A0
I do not know 802.15. Others can also say what they feel but from my=20 experience simple monotonic sequence numbers are more easier than having a clocks. This I think is a not a good idea. Sender and receiver can=20 easily get out of sync because your rate of sending packets is not=20 proportional to time. The receiver would need to allow very large=20 window. The sender would still need to store time to flash in-case there is need for sync after device reset.
<= ;mglt>
First all of all, the draft clearly stated that the use= of time is an alternative ways which is not the most usual implemented mec= hanism. I believe that similarly as the previous section, we could explicit= ly mention that the recommended way to generate SSN is to increment it. We = can also add text the explicit text regarding the additional constraints, a= nd specify that such way is not recommended for a generic purpose implement= ation.

Similarly we should clarify, the limitations for this specific = mechanism, so the mechanism could be chosen only when appropriated. Again, = constraint device have different constraints, and there specificities may a= llo one or the other mechanisms to be used. There are many use cases where = devices sends informations are regular time interval and that the lost of a= packet will have a limited impact. =C2=A0 =C2=A0

However I am happy you raises the discussio= n that can continue on the list. Thank you.
</mglt>

=
What you mean implementations must discard dummy packets? Even=20 non-constrained implementations must discard dummy packets so what is=20 new here?

<mglt>
I meant packet with next header value set to 59.
</mglt><= /div>

Okay. the paper you send me is for linux kernel, not for constrain= ed device.

<mglt>
Thisis correct. I mentioned it as maybe a starting point for the specifi= c topic your mentioned.
</mglt>
Ciao
Heinrich<= br>

On Wed, 29 A= ug 2018 at 19:17, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Heinrich,
<= /div>

Thank you for reviewing the draft. Please find my = response inline. I believe your concerns are addressed in the draft within = the scope of the draft. The work you are mostly looking at would be an effi= cient TFC / dummy packet policy. This would more probably be in scope of ip= secme WG.

Yours,
Daniel



On Thu, Aug 23, 2018 at 2:32 PM, Heinrich Singh <heinrich.ietf@gmail.com> wrote:
Hello IETF,

<= /div>
I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here = is my summary:

  1. Don't use random SPI be= cause getting randomness on small devices is expensive. This will of course= leak privacy. If a vendor/app uses fixed SPI for his devices, then someone= on the network can find out info of vendor/app.
<mglt>
This is correct and I believe this sta= tement is provided in the draft. Is there, in your opinion, anything we sho= uld add in the text below:

   The use of a limit=
ed number of fix SPI also come with security or
   privacy drawbacks.  Typically, a passive attacker may derive
   information such as the number of constrained devices connecting the
   remote peer, and in conjunction with data rate, the attacker may
   eventually determine the application the constrained device is
   associated to.  In addition, if the fix value SPI is fixed by a
   manufacturer or by some software application, the SPI may leak in an
   obvious way the type of sensor, the application involved or the model
   of the constrained device.  As a result, the use of a unpredictable
   SPI is preferred to provide better privacy.

   As far as security is concerned, revealing the type of application or
   model of the constrained device could be used to identify the
   vulnerabilities the constrained device is subject to.  This is
   especially sensitive for constrained device where patches or software
   updates will be challenging to operate.  As a result, these devices
   may remain vulnerable for relatively long period.  In addition,
   predictable SPI enable an attacker to forge packets with a valid SPI.
   Such packet will not be rejected due to an SPI mismatch, but instead
   after the signature check which requires more resource and thus make
   DoS more efficient, especially for devices powered by batteries.
</mglt>
=C2=A0Also, why a device can gener= ate random number for doing IKEv2, nonces etc. but not for generating SPI?<= /div>

<mglt>

I am reading= your text as if the draft were recommending the use of non random SPI, whi= le you would expect the draft to recommend a random generation of the SPI. = I think the draft address your comment by recommending a random generation = of the SPI with the text below:

   It is RECOMMENDED=
 to randomly generate the SPI indexing each inbound
   session.  A random generation provides a stateless way to generate
   the SPIs, while keeping the probability of collision between SPIs
   relatively low.  In case of collision, the SPI is simply re-
   generated.

We could have hardly go further for example by saying = SPI MUST be randomly generated as this is not required by RFC4303. Such req= uirement woudl have been out of scope of the draft as the purpose of the dr= aft is not to update the standard ESP and become a replacement of RFC4303. = instead, its purpose is to implement a minimal version of RFC 4303. SPI ran= domness is not required by RFC4303, so this document cannot mandate SPI gen= eration to be random.=C2=A0

The draft also clearly stated that non compromise on random generator= should mad for random used for cryptographic purpose. This is not the case= for SPI, and some device may, when necessary, use this to save cycles.
</mglt>
  1. Storing s= equence numbers is difficult so devices can use time. Getting time on small= devices is actually much harder. Also is there some hard info that reading= time is cheaper than reading sequence number from memory? I can also look = at packets much later and tell when you sent a packet.
<mglt>
We received this example from peo= ple following IEEE802.15. It would be good you share your information why r= eading time is much harder, so the discussion can happen on the mailing lis= t. From my perspective the main idea was to explain that you could take adv= antage of an already existing "always increasing" function set on= your device. Typically, the time is shared across the device and can be us= ed by ALL session, instead of having multiple Sequence numbers.
<= div>
As a side note, if your cases does not fit this, you do = not necessarily need to follow this implementation ;-). However, I am happy= if your are proposing text to make this more accurate.=C2=A0
</mglt>
=
  1. Don't use Traffic Flow Confidentiality ag= ain loosing privacy.
<mglt>
I believe this is what the current version of the draft says. Howev= er, as mentioned before, this draft is not updating RFC4303 and as such can= not make this feature mandatory.

In addition= , TFC is *really* not the kind of feature we expect for a minimal implement= ation in constrint devices. Typically it consists in adding extra bytes whi= le this is precisely the tasks that consumes the more resource for most of = the constraint devices. In addition, managing TFC to avoid creating a new p= attern is neither trivial, nor widely used. It woudl be mostly based on sta= tistics, and such functionalities are not expected to be found on constrain= t device. It is not obvious also that such option could introduce specific = patterns which could also loose privacy. =C2=A0

Again if you find the text misleading, I am happy you propose text to im= prove it.

   ESP [RFC4303] also provides Traffic Flow Confidentiality=
 (TFC) as a
   way to perform padding to hide traffic characteristics, which differs
   from respecting a 32 bit alignment.  TFC is not mandatory and MUST be
   negotiated with the SA management protocol.  As a result, TFC is not
   expected to be supported by a minimal ESP implementation.  On the
   other hand, disabling TFC should be carefully measured and understood
   as it exposes the node to traffic shaping.  This could expose the
   application as well as the devices used to a passive monitoring
   attacker.  Such information could be used by the attacker in case a
   vulnerability is disclosed on the specific device.  In addition, some
   application use - such as health applications - may also reveal
   important privacy oriented informations.

   Some constrained nodes that have limited battery life time may also
   prefer avoiding sending extra padding bytes.  However the same nodes
   may also be very specific to an application and device.  As a result,
   they are also likely to be the main target for traffic shaping.  In
   most cases, the payload carried by these nodes is quite small, and
   the standard padding mechanism may also be used as an alternative to
   TFC, with a sufficient trade off between the require energy to send
   additional payload and the exposure to traffic shaping attacks.
</mglt>
  1. Don't use dummy packets again = loosing privacy.
<mglt>
<= div>The draft does not prevent the use of dummy packets. Instead implementa= tion must be able to discard received dummy packet.. I believe the issue yo= u are raising is that RECOMMEND be changed in MUST. Thanks for raising this= I will update the draft. What the draft says is rather setting a widely us= ed policies for generating dummy packets, i.e. that is generating none. I d= o not think we expect more from a minimal implementation.
Similarly, handling dummy packet is not obvious, and maybe not= expected to be treated correctly by constrained devices.=C2=A0 The draft a= lso mention the privacy issues associated to not generating dummy packets. = Is there any text you woudl like to propose ?

The= ability to generate and receive dummy packet is required by [RFC4303]. For= interoperability, it is RECOMMENDED a minimal ESP implementation discards dummy packets. Note that such recommendation only applies for nodes receiving packets, and that nodes designed to only send data may not implement this capability. As the generation of dummy packets is subject to local management and based on a per-SA basis, a minimal ESP implementation may not generate such dummy packet. More especially, in constrained environments sending dummy packets may have too much impact on the device life time, and so may be avoided. On the other hand, constrained nodes may be dedicated to specific applications, in which case, traffic pattern may expose the application or the type of node. For these nodes, not sending dummy packet may have some privacy implication that needs to be measured.
=C2=A0
</mglt>
  1. Ref= erence rfc 8221 for IoT related crypto suites.
<mglt>
The draft provide the reference at least = 5 times.
</mglt>
=C2=A0

  1. <= /li>
I don't know why IETF would publish this document w= hen they have rfc 6973.
I want to see some actual = performance from a real ESP implementation where privacy is protected and e= nergy is saved by tweaking the TFC and how often dummy packet is sent.
=

<m= glt>
I agree that would be an interestin= g topic, but outside teh scope of defining a minimal implementation for the= current ESP. I believe the work you are expecting is the definition of an = efficient TFC / dummy packet policies. This is currently more a research pr= oject. This may be a link of interest:
https://www.rese= archgate.net/publication/224720331_Traffic_masking_in_IPsec_architecture_an= d_implementation

</mglt><= br>

Ciao
Heinrich

_______________________________________________
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
--000000000000c9e2410574bb6eab-- From nobody Fri Aug 31 08:50:28 2018 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 5F16B130E20; Fri, 31 Aug 2018 08:50:26 -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 OHT8y9P02_3i; Fri, 31 Aug 2018 08:50:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6EC130DD1; Fri, 31 Aug 2018 08:50:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7170220496; Fri, 31 Aug 2018 12:08:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2FF871723; Fri, 31 Aug 2018 11:50:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2D2BC1221; Fri, 31 Aug 2018 11:50:21 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org, lwip@ietf.org cc: Heinrich Singh In-Reply-To: <23433.17795.580382.531001@fireball.acr.fi> References: <23433.17795.580382.531001@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] [Lwip] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 15:50:26 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > number. Also window size is need only if you have out of order packets, > and you care about replay protection. Both of them are something that > might not be something that constrained device cares. > For example it might have internal replay protection for the messages > it sends, so it does not need to care whether there is replays on the > IPsec level, thus it can drop the whole replay protection checks > completely. Or it might work on the environment where out of order > deliver is not possible, thus it can just keep window size to 1. For instance, if one has a single CoAP session active, then there will be in essence only one packet in flight in either direction, so maybe there is no re-ordering possible. (Yes, there can be retransmits) > On the other hand sender is REQUIRED to send sequence numbers in such > way they are monotonically incrementing (not necessarely by one), and > if it has any kind of other monotonically incrementing counter like > clock, it can use that to generate the sequence numbers and get rid of > the requirement to store outgoing sequence number to the flash. I agree that this would work well. > So as those are not really used in non-constrained devices, I do not > think there is that big different in constrained devices. Again all of > this depends on the environment. For example some kind of door sensor > might want to keep sending packets every n seconds just not to leak out > when the door was opened and closed, but it might just use real packets > instead of dummy packets. I.e., it might be configured to send the door > status every 30 seconds, and in that packet it tells whether door is > now open or closed, and whether what transitions happened during last > 30 seconds. Good point, and this makes the packet the same size as well, and uses less code. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluJY7wACgkQgItw+93Q 3WUA8AgAgx1rThKSxBmme6zHFyTqHp25YShWso8P/+F39Ed9IImXghmIOMedj0cK +QnIzcCEbbIcVdQHY2gA3c+TIhgbH6pDLIGyJVkfUnRFm6GuMHCN5WQFvHblQ0gA Xci6Z3AKLcBUaG0yNSaydJlTmtebaUxER4Kq7EAGNTGVRtQA1DI3FnEX9Ur4JGBN p/tDNLT+9WVBTpRdDyIGtZkK0YKI4R7KSjmfvLx51Y3W+SJErMYzOHt80hcHbHNk i/QQIn66J91BfbOB4M5dkH7WGYgQwTaZNDT9kjWSLw22WCG7pUfgF4IFWPOKOfpw v8xwHNRQMT6J9NyRJZQ+w2zE7ZhYYA== =d6qe -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 31 09:50:50 2018 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 85342130E51; Fri, 31 Aug 2018 09:50:42 -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 wnLc9ZiROry8; Fri, 31 Aug 2018 09:50:40 -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 10535127148; Fri, 31 Aug 2018 09:50:40 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42252h59VBz5C2; Fri, 31 Aug 2018 18:50:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1535734236; bh=kVf1RGFe62atPlwVa03ej8ICMiNALTOG0TF2HGoPX1Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KPxrkoUH8+wAXfkxz9b/ezY4qUhdTuhFR15YloewiZD8vEhvBMrpZ6nxaXP+p5JIh PV/VK9YwQdBLUvNt83ZQLxgV3blpEox0eM/vlHkuaqwiQtbGcCMDVZVPoD91wkLiqa 5VZ19qNhsN5mduWKSAoBTOclneQoJuUqIgmjlbyM= 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 GeGC4v1GYg76; Fri, 31 Aug 2018 18:50:33 +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; Fri, 31 Aug 2018 18:50:32 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 594F95E2A5B; Fri, 31 Aug 2018 12:50:31 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 594F95E2A5B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4D0FF402E52A; Fri, 31 Aug 2018 12:50:31 -0400 (EDT) Date: Fri, 31 Aug 2018 12:50:31 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: Heinrich Singh , ipsec@ietf.org, lwip@ietf.org, daniel.migault@ericsson.com In-Reply-To: <23433.17795.580382.531001@fireball.acr.fi> Message-ID: References: <23433.17795.580382.531001@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] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 16:50:43 -0000 On Fri, 31 Aug 2018, Tero Kivinen wrote: > There is no requirement for SPI to be random and originally it was > written that way so implementations can use whatever method to > allocate SPIs they like. However, the randomized SPIs does give us some security, as we saw in the SLOTH attack, that was only stopped because of the effort of 2^77 to break. If we used predictable SPIs for IKE, then IKE would have fallen to the SLOTH attack as well. https://access.redhat.com/blogs/product-security/posts/sloth Although in this case, I guess we are talking about ESP/AH SPIs. There is still benefits in randomness, even if it is not cryptographically random. Just to ensure the same SPIs aren't re-used too quickly and get confused. The document does correctly point out not to use SPIs below 256. > Adding requirement that SPI needs to be random would be modifying the > base ESP, and is not in the scope of draft trying to define minimal > ESP. Saying that in contrained devices which have very few SPIs the > SPIs can be allocated using some other method than random is in scope > of the this draft. Agreed. > On the other hand sender is REQUIRED to send sequence numbers in such > way they are monotonically incrementing (not necessarely by one), and > if it has any kind of other monotonically incrementing counter like > clock, it can use that to generate the sequence numbers and get rid of > the requirement to store outgoing sequence number to the flash. Wouldn't not incrementing by one screw up the windoz sizes of receiving ends? Eg if they received #64, they might accept 65-128 so receiving 300 might just make them do more work or effectively have no window? > I have not actually never seen anybody sending dummy packets or TFC > padding packets in any implementations. Yup. Linux supports it. With libreswan you can configure tfc= with a value of zero meaning pad to MTU. We haven't yet enabled this by default, since there are reasons for and against it. It's much better for privacy obviusly, but if this is going of mobile data, you are paying for the padding. > not even sure which implementation support for sending dummy packets. That I don't know either. although there are already so many "dumb" DPD packets, we sort of have this already over port 4500 :) > So as those are not really used in non-constrained devices Hmm, I guess the Lantronix Xport Pro does not count as constrained? Because it does run Linux and libreswan in 8MB SDRAM with NOMMU :) I still have to read the full document before I decide if I am in favour of adopting or not. Paul