From nobody Fri Jul 1 05:34:11 2016 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 646F912D593 for ; Fri, 1 Jul 2016 05:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iRPLhI9EfFq for ; Fri, 1 Jul 2016 05:34:07 -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 5041312B063 for ; Fri, 1 Jul 2016 05:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8697; q=dns/txt; s=iport; t=1467376447; x=1468586047; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zS+AgESxaN4NO2PXQxRWELs3u4q7db2He7MKAqF0sYU=; b=coWXGcE+VNpZ8ZvK6BrsowW8aKSl4/bKIau9TvTpLbrtqnd3XtkZJpyV QcCAv52HFUjPpuhhTC/zw3oU7ipNXxknng+BhMgxTACTlANUx2NtHiKlx 0NFVnei0n8aqjwWH1ziBUbn6LXnEZzoa8Uj6XmhcTGUkyPsJaJu7SGvhG Y=; X-IronPort-AV: E=Sophos;i="5.26,556,1459814400"; d="scan'208";a="292517524" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2016 12:34:06 +0000 Received: from rtp-mcgrew-8917.cisco.com (rtp-mcgrew-8917.cisco.com [10.117.10.232]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u61CY5lm011881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jul 2016 12:34:06 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David McGrew In-Reply-To: Date: Fri, 1 Jul 2016 08:34:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13D79424-BA6E-4E9A-AD82-8FEEA03B51D8@cisco.com> References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , "paul@nohats.ca" , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 12:34:10 -0000 Hi Dave, > On Jun 28, 2016, at 2:12 PM, Waltermire, David A. (Fed) = wrote: >=20 > This has been a good discussion so far. There is work to be done to = address the issues raised. >=20 > Getting back to the call for adoption, I'd like to see feedback on the = following questions to better understand where consensus is on this = issue. >=20 thanks for framing the questions; let me chime in with some specific = responses, speaking as a WG member. =20 > 1) Previous WG discussions have indicated interest in this problem. = Does the working group think that there is a problem here that we need = to address? Yes; the problem is that IKEv2 does not have the same postquantum = security as IKEv1. This is an immediate practical need, because the = difference between versions has motivated some users to have a = preference for the obsolete version, and on the flip side, users of the = current version cannot benefit from postquantum security of preshared = keys. =20 > 2) Should we do this work in the IPsecME working group? If not, where? Yes, the problem being addressed is an important one for the IKEv2 = standard, and the solution should be broadly available to the IPSec = community. =20 > 3) Can we use draft-fluhrer-qr-ikev2 as a starting point for = developing a WG solution to this problem? If not, what is a suitable = starting point instead? >=20 Yes; that draft is a good starting point. The goal should be to develop = an RFC that updates RFC 7383 and specifies how Postquantum Preshared = Keys (PPKs) can be used, in a manner that is operationally similar to = IKE preshared keys, to achieve postquantum security. The WG should = decide whether identity protection is needed, or whether it can be = traded for simplicity. Other approaches, such as QKD or using a long stream of shared secret = key material obtained from an arbitrary source, should be addressed = through separate documents, because they are not needed to address the = above problem, and because they do not meet the requirement of = operational similarity with current practice. A sequence of key = material intended for one-time use is not the same as a PPK, and the = logic needed to handle indexing and sequencing should not be imposed on = the RFC that addresses the immediate need. =20 Going a little further off topic, with any technology (like QKD or a = one-time pad) that is predicated on the idea that computational = cryptography cannot be fully trusted, there should be a detailed = security analysis of how it is integrated into IPsec/IKE, which shows = how to use the technology along with other IPSec mechanisms in a way = that is consistent with its security assumptions. In short, the usage = of technologies that are only interesting in scenarios that include = major advances in cryptanalysis should be specifically crafted to = minimize the risk of those advances. No such analysis has yet been put = forward. The analysis of key renewal rates in the SECOQC White Paper on = Quantum Key Distribution and Cryptography [Section 3.2 of = http://www.secoqc.net/downloads/secoqc_crypto_wp.pdf], for instance, = neglects to consider the risk of a key collision attack, and does not = attempt any formal/provable security framework. The IPSec WG should = expect this analysis before any standards are developed that support = these new technologies, and those standards should clearly state what = advantages the new technologies have, and in what scenarios they should = be used, and what sort of other IPSec algorithms and options are = consistent with good security. Please note that I am not objecting to = the IPSec WG taking up this work; I am pointing out that there is a lot = of work involved, which underscores the importance of dealing with it in = a way that is separate from the immediate need of parity between IKE = versions. best, David > Regards, > Dave >=20 >> -----Original Message----- >> From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com] >> Sent: Friday, June 24, 2016 11:26 AM >> To: paul@nohats.ca; David McGrew >> Cc: Waltermire, David A. (Fed) ; IPsecME = WG >> ; Panos Kampanakis (pkampana) >> Subject: RE: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as = an IPSecME >> WG document >>=20 >>=20 >>> -----Original Message----- >>> From: Paul Wouters [mailto:paul@nohats.ca] >>> Sent: Friday, June 24, 2016 9:43 AM >>> To: David McGrew (mcgrew) >>> Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer = (sfluhrer); >>> Panos Kampanakis (pkampana) >>> Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as = an >>> IPSecME WG document >>>=20 >>> On Fri, 24 Jun 2016, David McGrew wrote: >>>=20 >>> Hi David, >>>=20 >>>> Because QKD is not a practical system for Internet security. It = has serious >>> security issues/challenges and operational limitations on bitrate, = range, and >>> physical media. It requires a point to point optical link, which = is typically >>> dedicated fiber, which must be shorter than 60 miles. There are >>> security issues with QKD because it relies on a physical interaction >>> across the line between the encrypter and decrypter, thus giving an >>> attacker the opportunity to perform an attack on the physical = process >> anywhere on that >>> line. See for instance Brassard et. al. Security Aspects of = Practical Quantum >>> Cryptography, Lydersen et. al., Hacking commercial quantum >>> cryptography systems by tailored bright illumination, or Gerhardt = et. >>> al., Full-field implementation of a perfect eavesdropper on a = quantum >> cryptography >>> system. Another major security problem is the range limitation; it = has >> been >>> proposed to extend the range of QKD by using a chain of trusted >>> repeaters, each connected by a QKD sy stem. These repeaters would >>> greatly increase the attack surface, and require the end user to = trust >>> the infrastructure provider(s); in contrast, the Internet community >>> wants end to end encryption, as described in RFC3365 and RFC7624. >>>>=20 >>>> In contrast, QR-IKEv2 can be used to add postquantum security >>>> between >>> any two points on the globe, without requiring dedicated fiber, and >> without >>> requiring physical layer security assumptions. It has *fewer* = security >>> assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that = draft >>> relies on the security of symmetric cryptography and the physical >>> layer, whereas QR-IKEv2 relies only on the former. >>>=20 >>> For a postquantum IKEv2 extension, does it matter which underlying >>> mechanism is used to provide the extra bits to mix into the = SKEYSEED? >>>=20 >>> I think what is needed is: >>>=20 >>> - A NOTIFY message that signals an identifier of where the extra = bits >>> should be taken/generated from. Both endpoints have previous >>> knowledge >>> of what tjos identifier refers to. Be it a hardware device or an >>> offset in a onetime pad, etc, etc. >>=20 >> One possible concern is whether such a notify message would = compromise >> the anonymity properties of IKE; if someone in the middle sees the = same >> identifier in multiple exchanges, would they be able to conclude that = those >> are the same individuals negotiating? If the NOTIFY messages are >> anonymized, how is that done? >>=20 >> Now, it might be that the WG would decide to compromise on such >> anonymization concerns; this would simplify things a lot, however = it's very >> much something we need WG agreement on. >>=20 >>>=20 >>> - A specification on how to mix in these extra bits into SKEYSEED = generation >>> to gain postquantum security. >>=20 >> The reason we specify modifying the public nonces (rather than doing = a more >> fundamental change to the skeyseed computation) was to minimize = changes >> to the IKE implementation itself (and in particular, the crypto = parts). Is there >> a reason why we wouldn't continue with this approach? >>=20 >>>=20 >>> - Any additional counter meassures (such as increased minimum >>> keysizes) >>=20 >> And what algorithms are suggested (e.g. XCBC and CMAC both don't = work, as >> the standard IKE versions are fixed to 128 bit keys) >>=20 >>>=20 >>> Do we need to know if these bits came from a QKD link, a QR link, or = a >>> mutually shared onetime pad? If not, then these specifics should not >>> go into such an ikev2 extension. >>>=20 >>> Paul From nobody Fri Jul 1 06:39:57 2016 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 C7E7E12D620 for ; Fri, 1 Jul 2016 06:39:55 -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 5PRp7qqpK2zR for ; Fri, 1 Jul 2016 06:39:53 -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 5607412D1DC for ; Fri, 1 Jul 2016 06:39:53 -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 u61Ddl5r018197 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Jul 2016 16:39:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u61DdlL4019492; Fri, 1 Jul 2016 16:39:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22390.29347.800290.864427@fireball.acr.fi> Date: Fri, 1 Jul 2016 16:39:47 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <4200F5373D5542C985F3D4C51609213C@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 15 min Archived-At: Cc: ipsec@ietf.org, Paul Wouters , Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 13:39:56 -0000 Valery Smyslov writes: > > I think this document should update 7296 due to adding non-encrypted > > payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that > > is not allowed. Someone implementing 7296 should be aware of it to allow > > it in their implementation. > > Hmmm... Not sure it is needed. As you said RFC 7296 doesn't > explicitely prohibit that (so we don't violate its requirements) and > there is a clear negotiation mechanism with puzzles, so that old > implementations won't be affected. > > I think we should be consitent in our policy whether to update core RFC or not. > For example, RFC 5723 (Resumption) defines new exchange IKE_SA_RESUME > that can be used in conjunction with IKE_AUTH instead of IKE_SA_INIT. > RFC 7296 tells only about IKE_SA_INIT + IKE_AUTH, however > RFC 5723 doesn't update IKEv2 RFC. Is our situation much > different? I don't think so. > > To be clear - I'm not against updating RFC 7296, I just think it is > not needed. I think the rules are All documents which do change IKEv2 core behavior are marked as updates 4306/5996/7296. Currently those are: 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol. (PROPOSED STANDARD) Changes the format of the existing IKEv2 encrypted payload format. 5998 An Extension for EAP-Only Authentication in IKEv2. (PROPOSED STANDARD) Changes the core component of IKEv2, i.e. how the authentication is done. 6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) (PROPOSED STANDARD) Changes the mandated behaviro of 5996, by adding new tests. 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) (PROPOSED STANDARD) Adds new authentication method, but there is negotiaton for it, but as this affects how the authentication (core IKEv2 component) works, this was considered to be something that updates 7296. 7670 Generic Raw Public-Key Support for IKEv2 (PROPOSED STANDARD) Adds new certificate encoding value, and there is no negotiation for it, except that implementations can ignore cert payloads they do not understand. Note, that RFC4718 IKEv2 Clarifications and Implementation Guidelines did not update 4306 as it did not change anything, it just clarified things. Childless initiation, high availability, secure password methods, EAP re-authnetication, fragmentation, null authentication, chacha20/poly1305, cloning etc did not update IKEv2, as in most cases the extensions are something that do not change the existing behavior, but adds new things, and on the other hand some of those are experimental, and it was not clear whether they are going to be used widely or not. If there is negotiation of this feature before the IKEv2 behavior changes I think it does not need to update 7296. If this changes normal behavior of the IKEv2 (timers, mandatory to implement protection mechanisms) then it needs to update 7296. I have not yet read any of the latests drafts, so I cannot say if this is true... -- kivinen@iki.fi From nobody Fri Jul 1 06:51:46 2016 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 F2E9312D636 for ; Fri, 1 Jul 2016 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26OCc0td2daR for ; Fri, 1 Jul 2016 06:51:43 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 2FB2A12D61C for ; Fri, 1 Jul 2016 06:51:43 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id h129so77762870lfh.1 for ; Fri, 01 Jul 2016 06:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=7yJWvBK3XlzAVppsNqqrgjgFAmXCFuE4jpzHii9L6T4=; b=Rw/tgXP5rJsg28r06rwNYHbPGGz+JmV2Gf569h1DjVhF3Oy6Ft2WPTtdCeqb577qie W3x4yTzVrtLRfW3+1LGdoTkzQknR9OM/DFwQ4mBm4VzhFzCvQNZtOJ282WJGiuGi5IiG +m77kYiymRe5xx/Nf9PM4xWy2/Kn/Hhy/ZVrzep3ro+jSZPeQyo6qkn4uMf7C3yNJjb0 wJQUOKOsH7fMtE3mlbFAV0gI4j/yklvwrz5IH29ANwPBYCzzPt7hkfonT6zr2AL8aCdi 15+06SQhM7ZGuR+4Hw5Uv2Kq55r9l7iNPyvNZ4e6Q9NbP/P8UEKKTs1U3ifHKtGYUp0h fQyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=7yJWvBK3XlzAVppsNqqrgjgFAmXCFuE4jpzHii9L6T4=; b=Ln1pgtJUS/80VRZT4694N/fuR/8VQN4W6GCulUKbM9qQys6mrTT3TFKYVuZYaMW6IP IWHoMYtWy/JeNw/JSOQtjCWhGPHpoBXPFMZo94hpEXfUsFiEAcF/jdx2oG9ffQ7cGURq y4mxVkFvwidMc843a+0BEAM6v9pc48UWFJqagfPIZHs9JLKjKiqreJ4drPVp8gS1Btd2 JYL0O74sOo5X2k95rzOg+nLXSsOHVrR9DWqjnrxUQmVEkZuE5oUaQxyQmCW0Acrd3H7l JyHeufzPJem3Pe7xUvtDWEeNDy2HQlAsNYELJ2OFlzH5qwiCH2cZeXiFreZV9SeCKFYh 1bPw== X-Gm-Message-State: ALyK8tItn58qot9gLClaXiGxskUv3KqUznzBEJeO5OY9okY/7maMCxzg53dJPY5aHLKGcw== X-Received: by 10.25.17.92 with SMTP id g89mr5706670lfi.119.1467381101414; Fri, 01 Jul 2016 06:51:41 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g79sm2347034ljg.26.2016.07.01.06.51.40 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Fri, 01 Jul 2016 06:51:40 -0700 (PDT) Message-ID: <31378E46EA0C43DAB3F34B81E2BCCEE0@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <4200F5373D5542C985F3D4C51609213C@buildpc> <22390.29347.800290.864427@fireball.acr.fi> Date: Fri, 1 Jul 2016 16:51:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Paul Wouters , Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 13:51:45 -0000 Hi Tero, >> To be clear - I'm not against updating RFC 7296, I just think it is >> not needed. > > I think the rules are > > All documents which do change IKEv2 core behavior are marked as > updates 4306/5996/7296. Currently those are: > > ... > > If there is negotiation of this feature before the IKEv2 behavior > changes I think it does not need to update 7296. If this changes > normal behavior of the IKEv2 (timers, mandatory to implement > protection mechanisms) then it needs to update 7296. There really is a negotiation of this feature. That's why I don't think this document needs to update RFC 7296. Regards, Valery. > I have not yet read any of the latests drafts, so I cannot say if this > is true... > -- > kivinen@iki.fi From nobody Fri Jul 1 07:54:03 2016 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 4ED8F12B061 for ; Fri, 1 Jul 2016 07:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.914 X-Spam-Level: X-Spam-Status: No, score=0.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LONGWORDS=2.035, 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 N9mEwUP_Ou4D for ; Fri, 1 Jul 2016 07:53:59 -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 3B8F012D146 for ; Fri, 1 Jul 2016 07:53:59 -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 u61Erk38012624 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Jul 2016 17:53:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u61Erj25015688; Fri, 1 Jul 2016 17:53:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22390.33785.830861.274015@fireball.acr.fi> Date: Fri, 1 Jul 2016 17:53:45 +0300 From: Tero Kivinen To: David McGrew In-Reply-To: <13D79424-BA6E-4E9A-AD82-8FEEA03B51D8@cisco.com> References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> <13D79424-BA6E-4E9A-AD82-8FEEA03B51D8@cisco.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 48 min X-Total-Time: 47 min Archived-At: Cc: IPsecME WG , "Scott Fluhrer \(sfluhrer\)" , "paul@nohats.ca" , "Waltermire, David A. \(Fed\)" , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 14:54:02 -0000 [This replies to emails other people also sent to list, but I just picked the last email to list some points, and I am talking here as an implementor not as a chair]. David McGrew writes: > Yes; that draft is a good starting point. The goal should be to > develop an RFC that updates RFC 7383 and specifies how Postquantum > Preshared Keys (PPKs) can be used, in a manner that is operationally > similar to IKE preshared keys, to achieve postquantum security. > The WG should decide whether identity protection is needed, or > whether it can be traded for simplicity. One note you should remember that IKEv1 does not have any identity protection when using shared keys with main mode. The responder MUST know from the IP address alone who the other end is, thus the whole world will know that this identity is same identity than the last one coming from the same IP... I.e. as the shared key is used to derive the encryption key for the IKE message protecting the ID payload you need to know the shared key before you can decrypt the message containing ID to find who the other is, thus the ID you get is useless for you as you must have already picked up one shared key before getting that far. People who say that IKEv1 is quantum computing resistant because it does exactly this (i.e. the pre shared key is used to derive keys) clearly do not care about identity protection. Because of that I think the limited identity protection should be ok, i.e., identity protection for the initiator can be broken by active attacker (like in IKEv2 now), and it should be ok even if it broken for both parties if Diffie-Hellman done in the IKE is broken. The identity protection against the responder has always been bit vague, as normally responders identity is always known because he has fixed ip-address or that ip-address is advertised somewhere etc. We had long discussions about these when we were doing IKEv2, and we ended up with the current compromise, i.e. IKEv2 identity protection protects identities against passive attacker provided attacker cannot break Diffie-Hellman, but does not protect identity protection against active attacker. Also note that the way shared keys were used in the IKEv1 also caused the fact that main mode with pre shared keys cannot really be used for mobile users, or devices coming from behind nat, etc. This has really limited the identity protection offered by IKEv1 in real use as users use aggressive mode which do not have identity protection at all. Also even if the IP-numbers are static it caused all kind of wierd errors, as mistyped shared key caused decryption errors in the IKE packet handling, causing the detecting such situation hard (usually when you have decryption error you simply silently ignore the message, but for authentication failures, it would be nicer to return the error saying authentication failed so the user experience would be better, IKEv1 cannot do that). Because of this I think it is better to just stick with the current identity protection method, i.e., do not derive IKE SA encryption keys from the shared secret, i.e., active attacker can still get the IDi... > Other approaches, such as QKD or using a long stream of shared > secret key material obtained from an arbitrary source, should be > addressed through separate documents, because they are not needed to > address the above problem, and because they do not meet the > requirement of operational similarity with current practice. A > sequence of key material intended for one-time use is not the same > as a PPK, and the logic needed to handle indexing and sequencing > should not be imposed on the RFC that addresses the immediate need. Earlier I have proposed very simple method where the IKE_SA_INIT contains just some kind of notification messages identifying the "oob-key" to be use. This identification information is completely opaque, and fully depends on the implementation. It could be fixed random string, which would immediately leak out the identity of the users, just like IKEv1 IP-address did. It could just random identifier, which identifies the one-time-use shared secret from big table (which is shared between the end nodes), it could be some kind of encrypted blob, which is encrypted with some kind of system wide group shared key (i.e., everybody in the group know it, but outsiders do not, so it protects identities for outsiders, but not for insiders), or it could be something more complicated like what current draft proposes. For the IKEv2 protocol point of view it is just opaque binary object which is given to the subsystem which will then return a shared key to be used for him. In all cases both ends must share the same shared key or table of shared keys or access to the QKD subsystem, so this code that knows how this blob is interpreted can be left to the implementations. We do not need to standardize it, we can leave it open, just like we leave cookie or the IKEv2 session resumption ticket format. We could include some proposals in the appendix, and we might want to add 16-bit "format identifier" in the beginning just in case people want mix multiple methods in same implementations. This means that the level of shared key identity protection is left to implementation and to it depends on the policy settings. When IKEv2 then has the shared secret then it needs to mix that to some parts of the cryptographic protection to provide quantum resistant IKEv2. There are multiple levels on that: 1) Include it only in KEYMAT. This will protect all IPsec SAs, i.e. the actual traffic transmitted over IPsec is protected from attackers able to break the Diffie-Hellman of the IKEv2. I.e., replace SK_d in there with (SK_d | OOB_secret). Note, this have also the side effect that after the first IKEv2 rekey also the IKEv2 SA traffic is protected, as new keying material after the IKEv2 rekey depends on the SK_d. 2) In addition to the 1, include it also in the SK_pi and SK_pr. This will mean that even if the attacker is able to break Diffie-Hellman and the Signature method, he will not be able to authenticate as user, as he cannot calculate the MACedIDforI/MACedIDforR for authentication. I.e. replace SK_pi and SK_pr with (SK_pi | OOB_secret) and (SK_pr | OOB_secret). 3) Include it in the SKEYSEED calculation. This will has the side effect that we are no longer able to get meaningfull error messages in case something goes wrong in the OOB key identification process, i.e., in case the OOB_secrets do not matchi, we just drop the frame and wait for next one, thus we cause timeout if OOB_secret is wrong. This is bad for user experience, but this will also protect the IKEv2 SA traffic with the OOB_secret. And, no please do not propose that we make this negotiated... Lets pick one and use it. I am in favor of 2, because it offers most, but does not cause problems. And if someone wants to protect traffic selectors and future traffic in IKEv2, they can simply do IKE_SA_INIT + IKE_AUTH with childless initiation, and then immediately do IKE SA rekey, and then CREATE_CHILD_SA to create Child SAs. > Going a little further off topic, with any technology (like QKD or a > one-time pad) that is predicated on the idea that computational > cryptography cannot be fully trusted, there should be a detailed > security analysis of how it is integrated into IPsec/IKE, which > shows how to use the technology along with other IPSec mechanisms in > a way that is consistent with its security assumptions. In short, > the usage of technologies that are only interesting in scenarios > that include major advances in cryptanalysis should be specifically > crafted to minimize the risk of those advances. No such analysis has > yet been put forward. The analysis of key renewal rates in the > SECOQC White Paper on Quantum Key Distribution and Cryptography > [Section 3.2 of > http://www.secoqc.net/downloads/secoqc_crypto_wp.pdf], for instance, > neglects to consider the risk of a key collision attack, and does > not attempt any formal/provable security framework. The IPSec WG > should expect this analysis before any standards are developed that > support these new technologies, and those standards should clearly > state what advantages the new technologies have, and in what > scenarios they should be used, and what sort of other IPSec > algorithms and options are consistent with good security. Please > note that I am not objecting to the IPSec WG taking up this work; I > am pointing out that there is a lot of work involved, which > underscores the importance of dealing with it in a way that is > separate from the immediate need of parity between IKE versions. I do not think that is reasonable for the IPsecME WG. We do not have security analysis on the use of ChaCha20/Poly1305 on IPsec/IKE. We do not have security analysis on most of the other things either. We should simply provide requirements for the OOB_secret provided by the subsystem and that should be enough. I.e., it should be enough to say that OOB_secret MUST be longer than 16 octets, and MUST NOT be longer than 64 octets, and to provide protection against attackers able to break Diffe-Hellman in IKEv2 it must be something that attackers cannot guess or know... That should be enough to make it secure for IKEv2 use. That was one of the reasons why I was so much against the QKD draft originally getting rid of the whole Diffie-Hellman in IKEv2, and only using the OOB_secret. I want the failure model of the OOB_secret to be so that the IKEv2 still as safe as it is now (yes, there might be some leak on the ID part in the OOB key identification process, but the IPsec traffic is still safe). Anyways, either one of those draft is good starting point for this work. It does not really matter which one we pick, we then just need to change it to what WG things is approriate for this protocol (i.e., which compromizes we take, and which we do not take). Ps. And now back to my vacation, so I most likely will not reply back until I get back from my last week of vacation. -- kivinen@iki.fi From nobody Fri Jul 1 08:23:40 2016 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 0029712D144; Fri, 1 Jul 2016 08:23:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160701152339.24678.80773.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2016 08:23:39 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:23:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-07.txt Pages : 29 Date : 2016-07-01 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 1 08:37:23 2016 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 78BAF12D6B9 for ; Fri, 1 Jul 2016 08:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR-DktvVRY3H for ; Fri, 1 Jul 2016 08:37:11 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7BF12D738 for ; Fri, 1 Jul 2016 08:37:03 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h129so79779200lfh.1 for ; Fri, 01 Jul 2016 08:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=PUZC+4rkq566+GD2piJ1Bkq2/PC+ZDzWV9Y2Z4cV09k=; b=dJsl4GJjvKQ7eDQUe1d2Dia9zysJo3lKCr5uobe8q3Lt41maAUh1Iwvk/JEjnVYVj9 ACMH6cbwnS30qfL3Ouqi6V3ISVBTSEjwAUrAk9YVpielUqYvYi2xc2L5ZgeYLwdEtJP9 653QmqhOeTb+G+e4MeW94ARjfiKD/pftsF8wBSi6nPoVkid0Pjd0rclhw9mDFMfR8Pbk vzVAzeDtSYEcjL7fjITOxscoZbt0uBxYueWf/GiAOdjUPf2RwhuCNwlphBoetXIebG5h tylo64iocdZ8A9+V1r+nsaLJNdpTgecAnREclfQ2yDiC/YhkfRQRBf7o4PceqjgOuB1S p+WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=PUZC+4rkq566+GD2piJ1Bkq2/PC+ZDzWV9Y2Z4cV09k=; b=a0+pnIIYvRY1PJuLqDXCi7pLZiCSfVWCsmxqOhFXo/S0NfYSaiQIoTnvndhj9avViy 7jEDPb7gsLPCSmFuDSHFUZ0aCzFRmPM3LPCAD11+AVYPxnhTIY+RSf4YBiVloT1aTDMB gBS44A9lbgovanuuhi5TkLAFlj9hqcJLDnIcgQFxtakS0Sn83rtg06JgPgwlK+VKFMw6 kPNpPL1wEkFYgPsSgzzxlk+EpRRJsiXZhc1QjEcZ3yGT6lBhfwg/BFVzkVO+wNeGMQ+2 PBWvqLlPtaWfe+eWxd1kxv7G+0Vw2b68rVbbKwTI//uumF54GKRGqskhK73AskqnlPL+ ZvWw== X-Gm-Message-State: ALyK8tJBwYvQhe2ct/XTdwWZE2sd7AIpmh09O1vJDSYy+dA0v5I+t4aelJ659idnQV2eFQ== X-Received: by 10.25.25.137 with SMTP id 131mr7806108lfz.149.1467387421078; Fri, 01 Jul 2016 08:37:01 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e17sm2405627lji.32.2016.07.01.08.37.00 for (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Fri, 01 Jul 2016 08:37:00 -0700 (PDT) Message-ID: <0DB038DC6E3144FDB03ED5789BCC7607@buildpc> From: "Valery Smyslov" To: References: <20160701152339.24678.80773.idtracker@ietfa.amsl.com> Date: Fri, 1 Jul 2016 18:37:00 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:37:22 -0000 Hi, new version of the draft is published. It addresses issues from latest reviews by David Waltermire and Paul Wouters. Regards, Yoav & Valery. ----- Original Message ----- From: To: Cc: Sent: Friday, July 01, 2016 6:23 PM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions of the IETF. > > Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed > Denial of Service Attacks > Authors : Yoav Nir > Valery Smyslov > Filename : draft-ietf-ipsecme-ddos-protection-07.txt > Pages : 29 > Date : 2016-07-01 > > Abstract: > This document recommends implementation and configuration best > practices for Internet Key Exchange Protocol version 2 (IKEv2) > Responders, to allow them to resist Denial of Service and Distributed > Denial of Service attacks. Additionally, the document introduces a > new mechanism called "Client Puzzles" that help accomplish this task. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Jul 3 11:08:28 2016 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 0A8DD12B05B for ; Sun, 3 Jul 2016 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 Pg5X4VK05mdB for ; Sun, 3 Jul 2016 11:08:24 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.117]) (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 F07A412B04C for ; Sun, 3 Jul 2016 11:08:23 -0700 (PDT) Received: from [85.158.140.115] by server-13.bemta-14.messagelabs.com id 40/B2-09524-69459775; Sun, 03 Jul 2016 18:08:22 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRWlGSWpSXmKPExsUSee7UI92pIZX hBv03+C32b3nB5sDosWTJT6YAxijWzLyk/IoE1ox7q28xFjTWVnycvpi9gXFxdRcjF4eQwBJG iYWN05i6GDk52AR0JX4f6mEGsUUEVCVOLZvOCmKzCKhIrFq2Hsjm4BAW8JX4fU8OoiRY4ub5K awQtp7EltbdbCAlvAK2Ej1va0DCjAKyEo9W/mIHsZkFxCVuPZkPtklCQEBiyZ7zzBC2qMTLx/ 9YIeplJH7vusACUR8vcbv5Flgvr4CgxMmZT1gmMPLPQjJqFpKyWUjKZgFdwSygKbF+lz5EiaL ElO6H7BC2hkTrnLnsyOILGNlXMWoUpxaVpRbpGhvoJRVlpmeU5CZm5ugaGpro5aYWFyemp+Yk JhXrJefnbmIEBng9AwPjDsb9l/wOMUpyMCmJ8nI5l4cL8SXlp1RmJBZnxBeV5qQWH2KU4eBQk uAtDq4MFxIsSk1PrUjLzAHGGkxagoNHSYS3GiTNW1yQmFucmQ6ROsWoKCXO6wSSEABJZJTmwb XB4vsSo6yUMC8jAwODEE9BalFuZgmq/CtGcQ5GJWHeDJApPJl5JXDTXwEtZgJazBpbDrK4JBE hJdXAqJf8f/6r6uX918NUim6tehexTUGqNCMzyu38eW4+D8l/ZpePqc7ddTPgXlWS2HxHfqF1 +lf9cyecyeyvWPypJJph7/PY4/M/f95WtPnu5m1fLGzY32tMnyCw6A4rW3v7ml63nIlvsl6yn r18eapCl+idL+3LXy+XcCwWXbwvRbuD5/k735InvEosxRmJhlrMRcWJAPKTj9jqAgAA X-Env-Sender: MarkMcFadden@icc-uk.com X-Msg-Ref: server-3.tower-17.messagelabs.com!1467569298!6847741!1 X-Originating-IP: [89.206.202.226] X-StarScan-Received: X-StarScan-Version: 8.46; banners=icc-uk.com,-,- X-VirusChecked: Checked Received: (qmail 42271 invoked from network); 3 Jul 2016 18:08:21 -0000 Received: from unallocated.star.net.uk (HELO remote.icc-uk.com) (89.206.202.226) by server-3.tower-17.messagelabs.com with AES128-SHA encrypted SMTP; 3 Jul 2016 18:08:21 -0000 Received: from ELROND.icc-uk.local ([fe80::20d7:3eb9:e46c:dacb]) by ELROND.icc-uk.local ([fe80::20d7:3eb9:e46c:dacb%10]) with mapi; Sun, 3 Jul 2016 19:08:18 +0100 From: Mark McFadden To: "ipsec@ietf.org" Date: Sun, 3 Jul 2016 19:08:16 +0100 Thread-Topic: Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document Thread-Index: AdHVVd/PUTO/l+vhTAq49nb2ZIOwPA== Message-ID: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_94FBAD9AC67D4B42BD1BB6DBACC945C5iccukcom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 18:08:27 -0000 --_000_94FBAD9AC67D4B42BD1BB6DBACC945C5iccukcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uc2lkZXJpbmc6IGRyYWZ0LWZsdWhyZXItcXItaWtldjIKCkZvciBjb250ZXh0IGFuZCBhIHJl bWluZGVyLCBhbm90aGVyIGRyYWZ0IHByb3Bvc2luZyB0aGUgdXNlIG9mIFF1YW50dW0gS2V5IERp c3RyaWJ1dGlvbiAoUUtEKSBpbiBJUFNlYyB3YXMgcHJldmlvdXNseSByZWplY3RlZCBieSB0aGUg Z3JvdXA6Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uYWdheWFtYS1pcHNlY21l LWlwc2VjLXdpdGgtcWtkLTAxCgpUaGUgZHJhZnQgdW5kZXIgY29uc2lkZXJhdGlvbiB3YXMgcHJv bXB0ZWQgYnkgYW4gaW50ZXJlc3QgaW4gdGhlIGdyb3VwIGluIGludHJvZHVjaW5nIHF1YW50dW0t cmVzaXN0YW50IGFsZ29yaXRobXMgdG8gdGhlIElLRXYyIHByb3RvY29sIG9mIHRoZSBJUFNlYyBz dGFuZGFyZC4gSXQgbWFrZXMgc2Vuc2UgdG8gc3VwcG9ydCB0aGUgbW92ZSB0byBRUiBhbGdvcml0 aG1zIGJ1dCBpdCBzZWVtcyBwb3NzaWJsZSB0aGF0IHRoZSBhcHByb2FjaCAgb3V0bGluZWQgaW4g dGhlIGN1cnJlbnQgZHJhZnQgd2lsbCBub3QgbGVhZCB0byB0aGUgYmVzdCBvdXRjb21lIGZvciBz ZWN1cml0eSBvciB1c2FiaWxpdHkuIEkgd291bGQgcHJvcG9zZSB0aGF0IHRoZSBXRyB0YWtlIGEg ZGlmZmVyZW50IGFwcHJvYWNoIGFuZCBub3QgYWRvcHQgdGhlIGN1cnJlbnQgZHJhZnQgYnV0IGlu c3RlYWQgd29yayB0b3dhcmRzIGFuIGFsdGVybmF0ZSBkcmFmdCBiYXNlZCBhcm91bmQgcXVhbnR1 bS1yZXNpc3RhbnQgYXN5bW1ldHJpYyBjcnlwdG9ncmFwaGljIGZ1bmN0aW9ucy4KCkVhcmxpZXIs IHdlIGhhZCBEYXZpZCBXYWx0ZXJtaXJlIG9mIE5JU1QgYXNrIGZvciBmZWVkYmFjayBmcm9tIHRo ZSBncm91cCBvbiB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczoKCjEpIFByZXZpb3VzIFdHIGRpc2N1 c3Npb25zIGhhdmUgaW5kaWNhdGVkIGludGVyZXN0IGluIHRoaXMgcHJvYmxlbS4gRG9lcyB0aGUg d29ya2luZyBncm91cCB0aGluayB0aGF0IHRoZXJlIGlzIGEgcHJvYmxlbSBoZXJlIHRoYXQgd2Ug bmVlZCB0byBhZGRyZXNzPwoKMikgU2hvdWxkIHdlIGRvIHRoaXMgd29yayBpbiB0aGUgSVBzZWNN RSB3b3JraW5nIGdyb3VwPyBJZiBub3QsIHdoZXJlPwoKMykgQ2FuIHdlIHVzZSBkcmFmdC1mbHVo cmVyLXFyLWlrZXYyIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGRldmVsb3BpbmcgYSBXRyBzb2x1 dGlvbiB0byB0aGlzIHByb2JsZW0/IElmIG5vdCwgd2hhdCBpcyBhIHN1aXRhYmxlIHN0YXJ0aW5n IHBvaW50IGluc3RlYWQ/CgpJ4oCZZCBwcm9wb3NlIGFuc3dlcmluZyB0aGVzZSBhcyBmb2xsb3dz OgoKMSkgWWVzLCB0aGVyZSBpcyBhIHJlYWwgdGhyZWF0IGhlcmUgYXMgcmVjb2duaXplZCBieSBO SVNULCBOU0EsIEVUU0kgZXRjLiBJS0V2MiBrZXkgZXhjaGFuZ2VzIGNvdWxkIGJlIHJlY29yZGVk IG5vdyBhbmQgYXR0YWNrZWQgaW4gZnV0dXJlIHdoZW4gYSBxdWFudHVtIGNvbXB1dGVyIGlzIGF2 YWlsYWJsZSB0byByZWNvdmVyIHRoZSBJUFNlYyBzZXNzaW9uIGtleXMuCgoyKSBJdCBpcyBjb21w bGV0ZWx5IGFwcHJvcHJpYXRlIGZvciB0aGUgaXBzZWNtZSB3b3JraW5nIGdyb3VwIHRvIHN0YW5k YXJkaXplIHRoZSBJUFNlYyBwcm90b2NvbCBtb2RpZmljYXRpb25zIGFuZCBleHRlbnNpb25zIHJl cXVpcmVkIHRvIHByb3ZpZGUgcXVhbnR1bSByZXNpc3RhbmNlLiBUaGUgY2hvaWNlIG9mIHF1YW50 dW0tcmVzaXN0YW50IGNyeXB0b2dyYXBoaWMgcHJpbWl0aXZlcyBzaG91bGQgYmUgZGVjaWRlZCBi eSB0aGUgQ0ZSRywgTklTVCwgRVRTSSBvciBvdGhlciBjb21wZXRlbnQgYm9keS4KCjMpIFRoZSBJ bnRlcm5ldCBEcmFmdCBDdXJyZW50bHkgdW5kZXIgY29uc2lkZXJhdGlvbiBpcyBub3QgdGhlIGJl c3Qgc3RhcnRpbmcgcG9pbnQgYXMgaXQgYXNzdW1lcyB0aGF0IHBvc3QtcXVhbnR1bSBwcmUtc2hh cmVkIGtleXMgYXJlIHRoZSBwcmVmZXJyZWQgc29sdXRpb24gZm9yIHF1YW50dW0gcmVzaXN0YW5j ZS4gVGhpcyBpcyBub3Qgb2J2aW91c2x5IHRoZSBjYXNlOyB0aGVyZSBhcmUgYSBudW1iZXIgb2Yg ZHJhd2JhY2tzIHdpdGggdGhlIHN1Z2dlc3RlZCBzeXN0ZW06CgphKSBQUEtzIGRvIG5vdCBwcm92 aWRlIFBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5IC0gZ2l2ZW4gYSBxdWFudHVtIGNvbXB1dGVyIHRv IHJlY292ZXIgdGhlIERpZmZpZS1IZWxsbWFuIHNoYXJlZCBzZWNyZXQsIGEgc3VjY2Vzc2Z1bCBh dHRhY2sgb24gdGhlIFBQSyBmb3Igb25lIHNlc3Npb24gY29tcHJvbWlzZXMgYWxsIG90aGVyIHNl c3Npb25zIHVzaW5nIHRoZSBzYW1lIFBQSwoKYikgVGhlIFJlc3BvbmRlciBoYXMgdG8gc2NhbiB0 aHJvdWdoIGEgbGlzdCBvZiBQUEtzLCBtYWtpbmcgYW4gQUVTL0hNQUNfU0hBMjU2IGNvbXB1dGF0 aW9uIGZvciBlYWNoLCBjb21wYXJpbmcgdGhlIHJlc3VsdCBhZ2FpbnN0IHRoZSBJbmRpY2F0b3Ig c2VudCBpbiB0aGUgSW5pdGlhdG9yJ3MgcGF5bG9hZC4gU2luY2UgdGhlcmUgaXMgbm8gaW50cmlu c2ljIGxpbWl0IHRvIHRoZSBzaXplIG9mIHRoZSBSZXNwb25kZXIncyBQUEsgbGlzdCwgdGhpcyBp cyBhIGxpbmVhciBhbW91bnQgb2Ygd29yayB0aGF0IGNvdWxkIHJlc3VsdCBpbiBwb3RlbnRpYWxs eSB1bmJvdW5kZWQgcmVzcG9uc2UgdGltZXMuCgpjKSBBbiBhZGRpdGlvbmFsIHJvdW5kLXRyaXAg aXMgaW50cm9kdWNlZCBvdmVyIGFuZCBhYm92ZSB0aGUgbm9ybWFsIElLRXYyIGtleSBuZWdvdGlh dGlvbjsgdGhpcyB3aWxsIGluY3JlYXNlIHRoZSBsYXRlbmN5IG9mIHNldHRpbmcgdXAgdGhlIFNB LgoKZCkgS2V5IGRpc3RyaWJ1dGlvbiBmb3IgcHJlLXNoYXJlZC1rZXkgYmFzZWQgY3J5cHRvc3lz dGVtcyBjYW4gYmUgcHJvYmxlbWF0aWMuIEEgc2VwYXJhdGUgUFBLIHdpbGwgbm9ybWFsbHkgYmUg cmVxdWlyZWQgZm9yIGVhY2ggcGFpciBvZiBjb3JyZXNwb25kZW50cywgc28gdGhlIG51bWJlciBv ZiBrZXlzIGNhbiBiZSBxdWFkcmF0aWMsIHVubGVzcyBncm91cCBQUEtzIGFyZSB1c2VkIHdoaWNo IGluY3JlYXNlcyB0aGUgcmlzayB0byBjb25maWRlbnRpYWxpdHkuIEhvdyB3aWxsIFBQS3MgYmUg Z2VuZXJhdGVkLCB3aWxsIGJvdGggY29ycmVzcG9uZGVudHMgY29udHJpYnV0ZSBlbnRyb3B5IHRv IHRoZW0sIG9yIHdpbGwgdGhleSBiZSBzdXBwbGllZCBieSBhIHRydXN0ZWQgdGhpcmQgcGFydHk/ CgpBIG51bWJlciBvZiBxdWFudHVtLXJlc2lzdGFudCBhc3ltbWV0cmljIHB1YmxpYyBrZXkgYWxn b3JpdGhtcyBoYXZlIGJlZW4gcHJvcG9zZWQsIGUuZy4gTlRSVSwgTmV3SG9wZSwgTWNFbGllY2Us IFN1cGVyLXNpbmd1bGFyIGlzb2dlbnkgRGlmZmllLUhlbGxtYW4uIFNvbWUgb2YgdGhlc2UgaGF2 ZSBlcGhlbWVyYWwga2V5cyB0aGF0IHdpbGwgYWxsb3cgZm9yIFBlcmZlY3QgRm9yd2FyZCBTZWNy ZWN5LCBoYXZlIHNlY3VyaXR5IHByb29mcywgZG9uJ3QgcmVxdWlyZSBhbiBhZGRpdGlvbmFsIHJv dW5kLXRyaXAsIGFuZCB3b3VsZCBieXBhc3MgdGhlIFBQSyBrZXkgZGlzdHJpYnV0aW9uIHByb2Js ZW0uIFdpdGhvdXQgd2FudGluZyB0byBtYWtlIGEgZGVjaXNpb24gYmV0d2VlbiB0aGVtIHVudGls IHRoZXkgaGF2ZSBiZWVuIHByb3Blcmx5IGV2YWx1YXRlZCwgSSB0aGluayB0aGUgd29ya2luZyBn cm91cCBzaG91bGQgZGV2aXNlIGEgcHJvdG9jb2wgdGhhdCBhbGxvd3MgZm9yIHRoZSB1c2Ugb2Yg YSBxdWFudHVtLXJlc2lzdGFudCBhc3ltbWV0cmljIGFsZ29yaXRobS4KCk1hcmsKCk1hcmsgTWNG YWRkZW4KUHJpbmNpcGFsIENvbnN1bHRhbnQsIEludGVybmV0IEluZnJhc3RydWN0dXJlIGFuZCBH b3Zlcm5hbmNlCkludGVyQ29ubmVjdCBDb21tdW5pY2F0aW9ucwoKTW9iaWxlOiArNDQgKDApIDc3 OTIgMjc2IDkwNDx0ZWw6KzQ0JTIwNzc5MiUyMDI3NiUyMDkwND4KU2t5cGU6IE1jRWxtc2lkZSBv ciArNDQgKDApIDIwIDc1NTggODEwNTx0ZWw6KzQ0JTIwMjAlMjA3NTU4JTIwODEwNT4KRW1haWw6 IE1hcmtNY0ZhZGRlbkBpY2MtdWsuY29tPG1haWx0bzpNYXJrTWNGYWRkZW5AaWNjLXVrLmNvbT4K V2ViOiBodHRwOi8vd3d3LmljYy11ay5jb208aHR0cDovL3d3dy5pY2MtdWsuY29tLz4KCkludGVy Q29ubmVjdCBDb21tdW5pY2F0aW9ucyBMdGQsIE1lcmxpbiBIb3VzZSwgU3RhdGlvbiBSb2FkLCBD aGVwc3RvdywgTlAxNiA1UEIsIFVuaXRlZCBLaW5nZG9tLgpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg YW5kIFdhbGVzLCBjb21wYW55IHJlZ2lzdHJhdGlvbiBuby4gMTgyODY3My4KCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpUaGlzIGUtbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciBhbGwgdmlydXNlcyBieSBTdGFy IEludGVybmV0LiAgSG93ZXZlciwgSW50ZXJDb25uZWN0IG1ha2VzIG5vIHdhcnJhbnR5IHRoYXQg dGhpcyBlbWFpbCBpcyB2aXJ1cy1mcmVlLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K --_000_94FBAD9AC67D4B42BD1BB6DBACC945C5iccukcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PGRpdiBp ZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5Db25zaWRlcmluZzogZHJhZnQtZmx1aHJlci1xci1pa2V2 MjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2PjxkaXYgaWQ9IkFw cGxlTWFpbFNpZ25hdHVyZSI+Rm9yIGNvbnRleHQgYW5kIGEgcmVtaW5kZXIsIGFub3RoZXIgZHJh ZnQgcHJvcG9zaW5nIHRoZSB1c2Ugb2YgUXVhbnR1bSBLZXkgRGlzdHJpYnV0aW9uIChRS0QpIGlu IElQU2VjIHdhcyBwcmV2aW91c2x5IHJlamVjdGVkIGJ5IHRoZSBncm91cDo8L2Rpdj48ZGl2IGlk PSJBcHBsZU1haWxTaWduYXR1cmUiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1uYWdheWFtYS1pcHNlY21lLWlwc2VjLXdpdGgtcWtkLTAxIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbmFnYXlhbWEtaXBzZWNtZS1pcHNlYy13aXRoLXFrZC0wMTwv YT48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj48L2Rpdj48ZGl2IGlkPSJB cHBsZU1haWxTaWduYXR1cmUiPlRoZSBkcmFmdCB1bmRlciBjb25zaWRlcmF0aW9uIHdhcyBwcm9t cHRlZCBieSBhbiBpbnRlcmVzdCBpbiB0aGUgZ3JvdXAgaW4gaW50cm9kdWNpbmcgcXVhbnR1bS1y ZXNpc3RhbnQgYWxnb3JpdGhtcyB0byB0aGUgSUtFdjIgcHJvdG9jb2wgb2YgdGhlIElQU2VjIHN0 YW5kYXJkLiBJdCBtYWtlcyBzZW5zZSB0byBzdXBwb3J0IHRoZSBtb3ZlIHRvIFFSIGFsZ29yaXRo bXMgYnV0IGl0IHNlZW1zIHBvc3NpYmxlIHRoYXQgdGhlIGFwcHJvYWNoICZuYnNwO291dGxpbmVk IGluIHRoZSBjdXJyZW50IGRyYWZ0IHdpbGwgbm90IGxlYWQgdG8gdGhlIGJlc3Qgb3V0Y29tZSBm b3Igc2VjdXJpdHkgb3IgdXNhYmlsaXR5LiBJIHdvdWxkIHByb3Bvc2UgdGhhdCB0aGUgV0cgdGFr ZSBhIGRpZmZlcmVudCBhcHByb2FjaCBhbmQgbm90IGFkb3B0IHRoZSBjdXJyZW50IGRyYWZ0IGJ1 dCBpbnN0ZWFkIHdvcmsgdG93YXJkcyBhbiBhbHRlcm5hdGUgZHJhZnQgYmFzZWQgYXJvdW5kIHF1 YW50dW0tcmVzaXN0YW50IGFzeW1tZXRyaWMgY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbnMuPC9kaXY+ PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWls U2lnbmF0dXJlIj5FYXJsaWVyLCB3ZSBoYWQgRGF2aWQgV2FsdGVybWlyZSBvZiBOSVNUIGFzayBm b3IgZmVlZGJhY2sgZnJvbSB0aGUgZ3JvdXAgb24gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6PC9k aXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVN YWlsU2lnbmF0dXJlIj4xKSBQcmV2aW91cyBXRyBkaXNjdXNzaW9ucyBoYXZlIGluZGljYXRlZCBp bnRlcmVzdCBpbiB0aGlzIHByb2JsZW0uIERvZXMgdGhlIHdvcmtpbmcgZ3JvdXAgdGhpbmsgdGhh dCB0aGVyZSBpcyBhIHByb2JsZW0gaGVyZSB0aGF0IHdlIG5lZWQgdG8gYWRkcmVzcz88L2Rpdj48 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPjIpIFNob3VsZCB3ZSBkbyB0aGlzIHdvcmsgaW4gdGhlIElQc2VjTUUgd29ya2lu ZyBncm91cD8gSWYgbm90LCB3aGVyZT88L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUi Pjxicj48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjMpIENhbiB3ZSB1c2UgZHJh ZnQtZmx1aHJlci1xci1pa2V2MiBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciBkZXZlbG9waW5nIGEg V0cgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtPyBJZiBub3QsIHdoYXQgaXMgYSBzdWl0YWJsZSBz dGFydGluZyBwb2ludCBpbnN0ZWFkPzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ PGJyPjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+SeKAmWQgcHJvcG9zZSBhbnN3 ZXJpbmcgdGhlc2UgYXMgZm9sbG93czo8L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUi Pjxicj48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjEpIFllcywgdGhlcmUgaXMg YSByZWFsIHRocmVhdCBoZXJlIGFzIHJlY29nbml6ZWQgYnkgTklTVCwgTlNBLCBFVFNJIGV0Yy4g SUtFdjIga2V5IGV4Y2hhbmdlcyBjb3VsZCBiZSByZWNvcmRlZCBub3cgYW5kIGF0dGFja2VkIGlu IGZ1dHVyZSB3aGVuIGEgcXVhbnR1bSBjb21wdXRlciBpcyBhdmFpbGFibGUgdG8gcmVjb3ZlciB0 aGUgSVBTZWMgc2Vzc2lvbiBrZXlzLjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ PGJyPjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+MikgSXQgaXMgY29tcGxldGVs eSBhcHByb3ByaWF0ZSBmb3IgdGhlIGlwc2VjbWUgd29ya2luZyBncm91cCB0byBzdGFuZGFyZGl6 ZSB0aGUgSVBTZWMgcHJvdG9jb2wgbW9kaWZpY2F0aW9ucyBhbmQgZXh0ZW5zaW9ucyByZXF1aXJl ZCB0byBwcm92aWRlIHF1YW50dW0gcmVzaXN0YW5jZS4gVGhlIGNob2ljZSBvZiBxdWFudHVtLXJl c2lzdGFudCBjcnlwdG9ncmFwaGljIHByaW1pdGl2ZXMgc2hvdWxkIGJlIGRlY2lkZWQgYnkgdGhl IENGUkcsIE5JU1QsIEVUU0kgb3Igb3RoZXIgY29tcGV0ZW50IGJvZHkuPC9kaXY+PGRpdiBpZD0i QXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJl Ij4zKSBUaGUgSW50ZXJuZXQgRHJhZnQgQ3VycmVudGx5IHVuZGVyIGNvbnNpZGVyYXRpb24gaXMg bm90IHRoZSBiZXN0IHN0YXJ0aW5nIHBvaW50IGFzIGl0IGFzc3VtZXMgdGhhdCBwb3N0LXF1YW50 dW0gcHJlLXNoYXJlZCBrZXlzIGFyZSB0aGUgcHJlZmVycmVkIHNvbHV0aW9uIGZvciBxdWFudHVt IHJlc2lzdGFuY2UuIFRoaXMgaXMgbm90IG9idmlvdXNseSB0aGUgY2FzZTsgdGhlcmUgYXJlIGEg bnVtYmVyIG9mIGRyYXdiYWNrcyB3aXRoIHRoZSBzdWdnZXN0ZWQgc3lzdGVtOjwvZGl2PjxkaXYg aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h dHVyZSI+YSkgUFBLcyBkbyBub3QgcHJvdmlkZSBQZXJmZWN0IEZvcndhcmQgU2VjcmVjeSAtIGdp dmVuIGEgcXVhbnR1bSBjb21wdXRlciB0byByZWNvdmVyIHRoZSBEaWZmaWUtSGVsbG1hbiBzaGFy ZWQgc2VjcmV0LCBhIHN1Y2Nlc3NmdWwgYXR0YWNrIG9uIHRoZSBQUEsgZm9yIG9uZSBzZXNzaW9u IGNvbXByb21pc2VzIGFsbCBvdGhlciBzZXNzaW9ucyB1c2luZyB0aGUgc2FtZSBQUEs8L2Rpdj48 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPmIpIFRoZSBSZXNwb25kZXIgaGFzIHRvIHNjYW4gdGhyb3VnaCBhIGxpc3Qgb2Yg UFBLcywgbWFraW5nIGFuIEFFUy9ITUFDX1NIQTI1NiBjb21wdXRhdGlvbiBmb3IgZWFjaCwgY29t cGFyaW5nIHRoZSByZXN1bHQgYWdhaW5zdCB0aGUgSW5kaWNhdG9yIHNlbnQgaW4gdGhlIEluaXRp YXRvcidzIHBheWxvYWQuIFNpbmNlIHRoZXJlIGlzIG5vIGludHJpbnNpYyBsaW1pdCB0byB0aGUg c2l6ZSBvZiB0aGUgUmVzcG9uZGVyJ3MgUFBLIGxpc3QsIHRoaXMgaXMgYSBsaW5lYXIgYW1vdW50 IG9mIHdvcmsgdGhhdCBjb3VsZCByZXN1bHQgaW4gcG90ZW50aWFsbHkgdW5ib3VuZGVkIHJlc3Bv bnNlIHRpbWVzLjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2Pjxk aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+YykgQW4gYWRkaXRpb25hbCByb3VuZC10cmlwIGlz IGludHJvZHVjZWQgb3ZlciBhbmQgYWJvdmUgdGhlIG5vcm1hbCBJS0V2MiBrZXkgbmVnb3RpYXRp b247IHRoaXMgd2lsbCBpbmNyZWFzZSB0aGUgbGF0ZW5jeSBvZiBzZXR0aW5nIHVwIHRoZSBTQS48 L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj48L2Rpdj48ZGl2IGlkPSJBcHBs ZU1haWxTaWduYXR1cmUiPmQpIEtleSBkaXN0cmlidXRpb24gZm9yIHByZS1zaGFyZWQta2V5IGJh c2VkIGNyeXB0b3N5c3RlbXMgY2FuIGJlIHByb2JsZW1hdGljLiBBIHNlcGFyYXRlIFBQSyB3aWxs IG5vcm1hbGx5IGJlIHJlcXVpcmVkIGZvciBlYWNoIHBhaXIgb2YgY29ycmVzcG9uZGVudHMsIHNv IHRoZSBudW1iZXIgb2Yga2V5cyBjYW4gYmUgcXVhZHJhdGljLCB1bmxlc3MgZ3JvdXAgUFBLcyBh cmUgdXNlZCB3aGljaCBpbmNyZWFzZXMgdGhlIHJpc2sgdG8gY29uZmlkZW50aWFsaXR5LiBIb3cg d2lsbCBQUEtzIGJlIGdlbmVyYXRlZCwgd2lsbCBib3RoIGNvcnJlc3BvbmRlbnRzIGNvbnRyaWJ1 dGUgZW50cm9weSB0byB0aGVtLCBvciB3aWxsIHRoZXkgYmUgc3VwcGxpZWQgYnkgYSB0cnVzdGVk IHRoaXJkIHBhcnR5PzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2 PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+QSBudW1iZXIgb2YgcXVhbnR1bS1yZXNpc3Rh bnQgYXN5bW1ldHJpYyBwdWJsaWMga2V5IGFsZ29yaXRobXMgaGF2ZSBiZWVuIHByb3Bvc2VkLCBl LmcuIE5UUlUsIE5ld0hvcGUsIE1jRWxpZWNlLCBTdXBlci1zaW5ndWxhciBpc29nZW55IERpZmZp ZS1IZWxsbWFuLiBTb21lIG9mIHRoZXNlIGhhdmUgZXBoZW1lcmFsIGtleXMgdGhhdCB3aWxsIGFs bG93IGZvciBQZXJmZWN0IEZvcndhcmQgU2VjcmVjeSwgaGF2ZSBzZWN1cml0eSBwcm9vZnMsIGRv bid0IHJlcXVpcmUgYW4gYWRkaXRpb25hbCByb3VuZC10cmlwLCBhbmQgd291bGQgYnlwYXNzIHRo ZSBQUEsga2V5IGRpc3RyaWJ1dGlvbiBwcm9ibGVtLiBXaXRob3V0IHdhbnRpbmcgdG8gbWFrZSBh IGRlY2lzaW9uIGJldHdlZW4gdGhlbSB1bnRpbCB0aGV5IGhhdmUgYmVlbiBwcm9wZXJseSBldmFs dWF0ZWQsIEkgdGhpbmsgdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGRldmlzZSBhIHByb3RvY29s IHRoYXQgYWxsb3dzIGZvciB0aGUgdXNlIG9mIGEgcXVhbnR1bS1yZXNpc3RhbnQgYXN5bW1ldHJp YyBhbGdvcml0aG0uPC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+ PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5NYXJrPC9kaXY+PGJyPjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5NYXJr IE1jRmFkZGVuPGJyPlByaW5jaXBhbCBDb25zdWx0YW50LCBJbnRlcm5ldCBJbmZyYXN0cnVjdHVy ZSBhbmQgR292ZXJuYW5jZTxicj48Yj5JbnRlckNvbm5lY3QgQ29tbXVuaWNhdGlvbnM8bzpwPjwv bzpwPjwvYj48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImJhY2tncm91bmQtY29s b3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4mbmJzcDs8L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5N b2JpbGU6Jm5ic3A7PGEgZGlyPSJsdHIiIGhyZWY9InRlbDorNDQlMjA3NzkyJTIwMjc2JTIwOTA0 IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5 cGU9InRlbGVwaG9uZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjQvMCI+KzQ0ICgw KSA3NzkyIDI3NiA5MDQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iYmFja2dy b3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxzcGFuIGxhbmc9IkVOLUdCIj5T a3lwZTogTWNFbG1zaWRlIG9yJm5ic3A7PGEgZGlyPSJsdHIiIGhyZWY9InRlbDorNDQlMjAyMCUy MDc1NTglMjA4MTA1IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEt ZGV0ZWN0b3JzLXR5cGU9InRlbGVwaG9uZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9 IjQvMSI+KzQ0ICgwKSAyMCA3NTU4IDgxMDU8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 YnI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj5FbWFpbDombmJzcDs8dT48YSBocmVmPSJtYWls dG86TWFya01jRmFkZGVuQGljYy11ay5jb20iPk1hcmtNY0ZhZGRlbkBpY2MtdWsuY29tPC9hPjwv dT48YnI+V2ViOjwvc3Bhbj48dT48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjwvdT48 dT48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cDovL3d3dy5pY2MtdWsuY29tLyIgdGFy Z2V0PSJfYmxhbmsiIHRpdGxlPSJibG9ja2VkOjovZXhjaHdlYi9iaW4vcmVkaXIuYXNwP1VSTD1o dHRwOi8vd3d3LmljYy11ay5jb20iPmh0dHA6Ly93d3cuaWNjLXVrLmNvbTwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3U+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dy b3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkludGVyQ29ubmVjdCBDb21tdW5p Y2F0aW9ucyBMdGQsIE1lcmxpbiBIb3VzZSwgU3RhdGlvbiBSb2FkLCBDaGVwc3RvdywgTlAxNiA1 UEIsIFVuaXRlZCBLaW5nZG9tLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPlJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2Fs ZXMsIGNvbXBhbnkgcmVnaXN0cmF0aW9uIG5vLiAxODI4NjczLjwvc3Bhbj48L3A+PC9kaXY+PGJy IGNsZWFyPSJib3RoIj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPgpUaGlzIGUtbWFpbCBoYXMgYmVlbiBz Y2FubmVkIGZvciBhbGwgdmlydXNlcyBieSBTdGFyIEludGVybmV0LiAgSG93ZXZlciwgSW50ZXJD b25uZWN0IG1ha2VzIG5vIHdhcnJhbnR5IHRoYXQgdGhpcyBlbWFpbCBpcyB2aXJ1cy1mcmVlLjxC Uj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPEJSPgo8L2JvZHk+PC9odG1sPgo= --_000_94FBAD9AC67D4B42BD1BB6DBACC945C5iccukcom_-- From nobody Sun Jul 3 11:32:33 2016 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 ADFF112B05B for ; Sun, 3 Jul 2016 11:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] 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 VG-GwJIRvxgs for ; Sun, 3 Jul 2016 11:32:31 -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 46D3312B04C for ; Sun, 3 Jul 2016 11:32:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rjJfN61VNz3P0; Sun, 3 Jul 2016 20:32:28 +0200 (CEST) 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 uRy-5jQbDfVn; Sun, 3 Jul 2016 20:32:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 3 Jul 2016 20:32:27 +0200 (CEST) Received: from [172.24.24.221] (nbl-foo-gw.foobar.fi [213.157.89.53]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 8A96745C471; Sun, 3 Jul 2016 14:32:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 8A96745C471 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (13F69) In-Reply-To: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> Date: Sun, 3 Jul 2016 21:32:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <985E4A9D-D5BD-430B-BCCC-BE64F804E2AA@nohats.ca> References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> To: Mark McFadden Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 18:32:33 -0000 > On Jul 3, 2016, at 21:08, Mark McFadden wrote: >=20 > A number of quantum-resistant asymmetric public key algorithms have been p= roposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny Diffie-Hellman= . I thought NTRU was patent encumbered? Is that still the case? How about the o= thers you mention? I agree asking CFRG for help would be a wise decision. Paul= From nobody Sun Jul 3 12:59:59 2016 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 23DB7127071 for ; Sun, 3 Jul 2016 12:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 SsqHd3FwxBRY for ; Sun, 3 Jul 2016 12:59:56 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C0E126B6D for ; Sun, 3 Jul 2016 12:59:56 -0700 (PDT) Received: from [10.32.60.33] (142-254-101-201.dsl.dynamic.fusionbroadband.com [142.254.101.201]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u63JxmlE039362 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jul 2016 12:59:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-201.dsl.dynamic.fusionbroadband.com [142.254.101.201] claimed to be [10.32.60.33] From: "Paul Hoffman" To: "Paul Wouters" Date: Sun, 03 Jul 2016 12:59:47 -0700 Message-ID: <8D922896-8B9D-4A8C-A2E9-81646D620715@vpnc.org> In-Reply-To: <985E4A9D-D5BD-430B-BCCC-BE64F804E2AA@nohats.ca> References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> <985E4A9D-D5BD-430B-BCCC-BE64F804E2AA@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "ipsec@ietf.org" , Mark McFadden Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 19:59:58 -0000 On 3 Jul 2016, at 11:32, Paul Wouters wrote: >> On Jul 3, 2016, at 21:08, Mark McFadden >> wrote: >> >> A number of quantum-resistant asymmetric public key algorithms have >> been proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny >> Diffie-Hellman. > > I thought NTRU was patent encumbered? Is that still the case? How > about the others you mention? > > I agree asking CFRG for help would be a wise decision. Isn't this kinda off-topic for the thread? I though we were first considering "create an IKEv2 extension that mixes in the PSK" as the simplest way to get around the "go back to IKEv1" guidance. --Paul Hoffman From nobody Sun Jul 3 13:30:47 2016 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 D1FF312B028 for ; Sun, 3 Jul 2016 13:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ucMVplZt3Km for ; Sun, 3 Jul 2016 13:30:45 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CA912B00C for ; Sun, 3 Jul 2016 13:30:44 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id a66so91722918wme.0 for ; Sun, 03 Jul 2016 13:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B4l7Iy4/OJP+5zhh3C4Nl/V3umtPEJbYeWba/rQ3Sr4=; b=FZuX6LsstNlhV05nkNoWpBwR/CptU1nqdT61t1dpd9z/fRQcRkwPlV6B2c5EOxFBrj O0flj6q1dAi4yzDSfA22cx3RD8dQ4JNI4VadeDvjuJL9nl230aMoETsMLCc5K5jGhUDH 7ZZmwV/8t8NlPDyp04dFpzWUcAjH+Cou3uTEckgYxM2vUzWhHzHTsHdJJJpBcyjXHOnY zHlYj2Kkuh2FnrHYdbaMYH4hox4rZ88MsWFtSSauVrK0RgqxPFG8rtF62n1mCbxiD3KR BgHD4SvMiaxsphGHHDQUivO3TPQndRBA88PY1qSW/tIzKgkyaolQkzW4/ihcyMfLykCV TpAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B4l7Iy4/OJP+5zhh3C4Nl/V3umtPEJbYeWba/rQ3Sr4=; b=IcrZJfWg7VapMCs3JEiM0vPcQcAMcDECYJ7AdcrcUWkWIqXF+WBTP+9A/IMqmjq9eq MGaAPJ5f6l+LL7T6ODyB8tgG8/rutB06lsdl3CQtsIEPxcKThIn0632tMo6UM6iSwlcu zrRQUBsTu2+NsnjO6Mw2YOIL5oPdL6ayhKa2ZladMfdBC5kkvY6ySF7lEPAvARREbRCw TWE6jQ65Jz3iTd3edQPOqM4xjiAYLwSe61aJIKJtk1SyfsfjVk9hd8FZa83z3cZW1964 K2h/ZOq3tSFBBj4cxO8KsqTffSaxdo6lRNaweRscqNIENtZGc7jW8fdIrPCk1ALJaX8l MuwA== X-Gm-Message-State: ALyK8tJwYYayVNCOOUTxV8vFiaSSn29eeyZZF9cyjS85j4AqjitIDlagLbpG3RnUTM1hKA== X-Received: by 10.194.234.103 with SMTP id ud7mr7155977wjc.39.1467577842996; Sun, 03 Jul 2016 13:30:42 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id j2sm1236500wjz.15.2016.07.03.13.30.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Jul 2016 13:30:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> Date: Sun, 3 Jul 2016 23:30:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> To: Mark McFadden X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 20:30:47 -0000 Hi, Mark > On 3 Jul 2016, at 9:08 PM, Mark McFadden = wrote: > 3) The Internet Draft Currently under consideration is not the best = starting point as it assumes that post-quantum pre-shared keys are the = preferred solution for quantum resistance. This is not obviously the = case; there are a number of drawbacks with the suggested system: I think this misstates the problem that the draft is trying to solve. = The draft is not a solution to the problem of authenticating peers in a = world where adversaries have quantum computers. The draft is a solution = to the problem of authenticating peers *using pre-shared keys* in such a = world. There may be different solutions for authenticating peers with = other credentials.=20 In general, someone deploying an IKE/IPsec solution can choose what = credentials to deploy. So the system administrator for the Elbonian = foreign office may decide to deploy NTRU keys to each embassy. Or ECDSA = keys. Or pre-shared secrets. Or short passwords. As implementers, we don=E2=80=99t get to decide this. Our = implementations are required to support whatever credentials the users = either already have or wish to deploy. If quantum resistance becomes a = requirement, implementers like me will need to support pre-shared keys = in a quantum safe way, and it is up to this working group to provide a = method of doing just that. Of course, I as an implementer may decide that I don=E2=80=99t want to = solve this because maybe I think quantum resistance is not an important = requirement, or because I don=E2=80=99t believe people are actually = using pre-shared keys. Similarly, the WG may decide that solving the = quantum resistant PSK method is not important enough to work on. Or that = this particular solution to this problem is not the right one. However, with my vendor hat on, I know that PSKs are used extensively = (and nobody=E2=80=99s asking me whether this is a good idea or not), and = I have heard that some users are beginning to ask questions about = quantum resistance.So I believe that there is a problem to solve here.=20= Yoav From nobody Mon Jul 4 02:44:39 2016 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 9F10212B040 for ; Mon, 4 Jul 2016 02:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] 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 a1LzyjPl74Og for ; Mon, 4 Jul 2016 02:44:35 -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 C6B3B12D0C2 for ; Mon, 4 Jul 2016 02:44:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rjhtk6NbVz1Hs; Mon, 4 Jul 2016 11:44:30 +0200 (CEST) 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 XqtAnlbq9IvG; Mon, 4 Jul 2016 11:44:29 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 Jul 2016 11:44:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0625E45C46F; Mon, 4 Jul 2016 05:44:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0625E45C46F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E3E88406B152; Mon, 4 Jul 2016 05:44:27 -0400 (EDT) Date: Mon, 4 Jul 2016 05:44:27 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" , Mark McFadden Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 09:44:38 -0000 On Sun, 3 Jul 2016, Yoav Nir wrote: >> 3) The Internet Draft Currently under consideration is not the best starting point as it assumes that post-quantum pre-shared keys are the preferred solution for quantum resistance. This is not obviously the case; there are a number of drawbacks with the suggested system: > > I think this misstates the problem that the draft is trying to solve. The draft is not a solution to the problem of authenticating peers in a world where adversaries have quantum computers. The draft is a solution to the problem of authenticating peers *using pre-shared keys* in such a world. There may be different solutions for authenticating peers with other credentials. That was not clear to me when we were asking for adoption of the document. In one way, I have less issues with it if the document can clearly state that is the scope of it. On the other hand, we might want to have a discussion about the security of PSK in general, and whether the method deserves to be obsoleted completely because of its continued weak deployments (eg see Snowden leaks) > However, with my vendor hat on, I know that PSKs are used extensively (and nobody’s asking me whether this is a good idea or not), and I have heard that some users are beginning to ask questions about quantum resistance.So I believe that there is a problem to solve here. I can see that point. As vendor it is hard to tell people not to do a certain deployment because it is seen as "easiest". However with our IETF protocol designer hats on, this should not be a strong argument. Paul From nobody Mon Jul 4 02:48:49 2016 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 B8D0012B040 for ; Mon, 4 Jul 2016 02:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] 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 P2RK9ViiLs6C for ; Mon, 4 Jul 2016 02:48: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 EC02212B03A for ; Mon, 4 Jul 2016 02:48:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rjhzc4fppz1Hs; Mon, 4 Jul 2016 11:48:44 +0200 (CEST) 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 2WX9gdOfxqNH; Mon, 4 Jul 2016 11:48:43 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 Jul 2016 11:48:43 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 51CDD45C46F; Mon, 4 Jul 2016 05:48:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 51CDD45C46F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2F697406B152; Mon, 4 Jul 2016 05:48:42 -0400 (EDT) Date: Mon, 4 Jul 2016 05:48:41 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <8D922896-8B9D-4A8C-A2E9-81646D620715@vpnc.org> Message-ID: References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> <985E4A9D-D5BD-430B-BCCC-BE64F804E2AA@nohats.ca> <8D922896-8B9D-4A8C-A2E9-81646D620715@vpnc.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: "ipsec@ietf.org" , Mark McFadden Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 09:48:48 -0000 On Sun, 3 Jul 2016, Paul Hoffman wrote: > On 3 Jul 2016, at 11:32, Paul Wouters wrote: > >> > On Jul 3, 2016, at 21:08, Mark McFadden wrote: >> > >> > A number of quantum-resistant asymmetric public key algorithms have been >> > proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny >> > Diffie-Hellman. >> >> I thought NTRU was patent encumbered? Is that still the case? How about >> the others you mention? >> >> I agree asking CFRG for help would be a wise decision. > > Isn't this kinda off-topic for the thread? I though we were first considering > "create an IKEv2 extension that mixes in the PSK" as the simplest way to get > around the "go back to IKEv1" guidance. So that was not entire clear to me from the title, but it seems you are right. Perhaps we can change the title from: Postquantum Preshared Keys for IKEv2 to: Postquantum protection for IKEv2 Preshared Keys SA's The original title to me reads like a "new feature" instead of like a "fix for old feature". Paul From nobody Mon Jul 4 03:22:42 2016 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 B08E612B059 for ; Mon, 4 Jul 2016 03:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh53nyAxc1NJ for ; Mon, 4 Jul 2016 03:22:39 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91AE12B058 for ; Mon, 4 Jul 2016 03:22:38 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a66so109212158wme.0 for ; Mon, 04 Jul 2016 03:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v2BlMe2vQqHitEJEJ6sGo10namN29cEidVVDM92z4AE=; b=GTWBUU7TAuJ1Jze8LUjMEYS5nmnaAkwqlGRUfYAyddkqzuDWoAkgjpTq3Nb04O+szJ RJ3YPkRF6exWGPi2QTqu70zWTqTyurw2FuNnca8EbP49G7CWc90sJ5lPZBzV/ilRxdwa HkgNjYGDlFgCRXClQ/CssEhJhsd23xpDHuHumqoK4OPXhewe2E/RDvXNMIW1qLCb0jQ1 +KCePLAlDtVBsE66Goya5uDDGbTioRMH7ZVeZNhJbLmVICLHcbzWi6L9Pm/wrlzUC64Y 3KI0+8ouorA1A+LKkPuLKxXIthyoH6VWVUAXeCC3Uj/FIX2K78PgSDlKRMYR89squNqO AzdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v2BlMe2vQqHitEJEJ6sGo10namN29cEidVVDM92z4AE=; b=eLZ++lElCJlRfAx6CA5Qd0fl/0SqNzcARwp1VhNGPLEBPFS/aUWOTXk0BsWdh5+bBL wvCJVOprIRIv/F0F5Z7sBt5XNW86hjscK3RD8abu1YHEGBQOK59Ca1QZN74x+9INT3c1 /TKfvxyAMzw3kBakClYPp4SYsJ44REvWyd7ImD51DDBiyuAAEBFjND7KKTywGcNCOKiH fZkbeltu8SE7iwmu8j/ktrEJWozrI3egvSwyeIU354InbijV+uoJ5PBZKb4tgC9HacJZ LC5AD6yi1mWAs9cxqpyo+NWozj9s1CmyRErEQZDAXQHfkqwcAl1RihJ7Zm9mKWE2BofF h4Qg== X-Gm-Message-State: ALyK8tJjQd3ivt3gpRWsw0sloF4MDMY67ZemZAFvvFmHJG+DI5NyY8ppTYsJVt1sXa6jbw== X-Received: by 10.28.229.13 with SMTP id c13mr9634765wmh.43.1467627757330; Mon, 04 Jul 2016 03:22:37 -0700 (PDT) Received: from [172.24.249.249] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id q203sm8862695wmd.24.2016.07.04.03.22.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jul 2016 03:22:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Mon, 4 Jul 2016 13:22:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1B08FC7D-9CD1-4998-B160-C030EB8C8FCF@gmail.com> References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org" , Mark McFadden Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 10:22:41 -0000 On 4 Jul 2016, at 12:44 PM, Paul Wouters wrote: > On Sun, 3 Jul 2016, Yoav Nir wrote: >=20 >>> 3) The Internet Draft Currently under consideration is not the best = starting point as it assumes that post-quantum pre-shared keys are the = preferred solution for quantum resistance. This is not obviously the = case; there are a number of drawbacks with the suggested system: >>=20 >> I think this misstates the problem that the draft is trying to solve. = The draft is not a solution to the problem of authenticating peers in a = world where adversaries have quantum computers. The draft is a solution = to the problem of authenticating peers *using pre-shared keys* in such a = world. There may be different solutions for authenticating peers with = other credentials. >=20 > That was not clear to me when we were asking for adoption of the > document. In one way, I have less issues with it if the document > can clearly state that is the scope of it. On the other hand, we > might want to have a discussion about the security of PSK in general, > and whether the method deserves to be obsoleted completely because > of its continued weak deployments (eg see Snowden leaks) We can have that discussion. Or we can resign ourselves to designing = protocols to fill requirements imposed by other people. Yoav From nobody Mon Jul 4 05:35:27 2016 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 4E32912B032 for ; Mon, 4 Jul 2016 05:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 J24iL2PQRGlT for ; Mon, 4 Jul 2016 05:35:24 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 F103D12D0C4 for ; Mon, 4 Jul 2016 05:35:23 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id h129so116473543lfh.1 for ; Mon, 04 Jul 2016 05:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=t/7utEO0TzyovOoiprwtB9ROqpIyEyOMZx1fL5uS/qE=; b=Oy24DcWk1cmPAMGsj6bAiQb3k1NAmLmyXjtxkQxmZdCEpv30WaWTj2J7nXuFS2wvZP rj/jSND2gu8c+6+CCoioU6WUkB9ItADRHczsiWHCHGeaJuh5S50RB83ro9dmj1nrAnN1 LUb5x9pJFj/Jem2rEDsgrPmMPKVYSy+J1LPegUTPxH1kzFf3UVXjGZlLGwhiDBzyRVqV AIWfx06UAdbMU3EqIwD4CWltMGKk+fLRDs/YcrMVlJFEBfC16Wl/6PZEAxXfnfASQ4NV mwKG/mzW8FZArL5x/dcIqWmAdTw+QWkIYReVjv4QKfdT49CoxqiWWEAR7cPvrPHXNMIt Lo8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=t/7utEO0TzyovOoiprwtB9ROqpIyEyOMZx1fL5uS/qE=; b=mToz6aOckyH7ZXR3PHRCAK96YeOGJpBXrCZ/x9rQYDEXiUytWraQzwF92lY3YKS3gu Z2ozneJAA4Uy+bsq2V47jC2/y0mS9bHBLGLOGYDIzCj60lWfaCKrsY+76+mX74JRBKNQ +wy/M9RE0sL5YGsS4/4np2w0U2Pdojd6qia0my8kdS6Q3AYhst8Kvq/FsLyHO3+DdE/o DtMGZRdk0pcVei3TDOMS/j45pUjzNALSgVPwFwasoSUVil7kVfe+qwcB6GdElDFknifS roGa3ZeetI4obf0FG+iXIU9REK0Cwad0ZIUaTbEqEcdWmKqEV9ngeeosFoJ25aANk3wH krHQ== X-Gm-Message-State: ALyK8tJ6NTihoRCJLbabGFe5sqJzcrg5RmYN5NMW7jGAn6Rjt7QsoI4GHoWZA1CUtSNHjw== X-Received: by 10.25.153.18 with SMTP id b18mr2190812lfe.227.1467635722230; Mon, 04 Jul 2016 05:35:22 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 10sm4667932ljf.5.2016.07.04.05.35.21 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Mon, 04 Jul 2016 05:35:21 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , "Paul Hoffman" References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> <985E4A9D-D5BD-430B-BCCC-BE64F804E2AA@nohats.ca> <8D922896-8B9D-4A8C-A2E9-81646D620715@vpnc.org> Date: Mon, 4 Jul 2016 15:35:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Mark McFadden Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 12:35:26 -0000 Hi Paul, >> Isn't this kinda off-topic for the thread? I though we were first considering >> "create an IKEv2 extension that mixes in the PSK" as the simplest way to get >> around the "go back to IKEv1" guidance. > > So that was not entire clear to me from the title, but it seems you are > right. > > Perhaps we can change the title from: > > Postquantum Preshared Keys for IKEv2 > > to: > > Postquantum protection for IKEv2 Preshared Keys SA's That's incorrect title. The original title is correct. The draft provides postquantum protection to any SA, regardless of the authentication methods used. In other words, PPKs (as specified in the draft) don't replace preshred keys authentication in IKEv2, they augment any authentication method to provide postquantum security. > The original title to me reads like a "new feature" instead of like a > "fix for old feature". I think it is more like a new feature. Regards, Valery. > Paul From nobody Mon Jul 4 06:17:48 2016 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 0661912D0EB for ; Mon, 4 Jul 2016 06:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] 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 DliONMbaVCzV for ; Mon, 4 Jul 2016 06:17:45 -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 A9B3812D0A1 for ; Mon, 4 Jul 2016 06:17:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rjnck4g85z3Bw; Mon, 4 Jul 2016 15:17:42 +0200 (CEST) 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 rffmKGeMDRzd; Mon, 4 Jul 2016 15:17:41 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 Jul 2016 15:17:41 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DCB7845C476; Mon, 4 Jul 2016 09:17:40 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca DCB7845C476 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C3A0D406B15C; Mon, 4 Jul 2016 09:17:40 -0400 (EDT) Date: Mon, 4 Jul 2016 09:17:40 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> <985E4A9D-D5BD-430B-BCCC-BE64F804E2AA@nohats.ca> <8D922896-8B9D-4A8C-A2E9-81646D620715@vpnc.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" , Mark McFadden , Paul Hoffman Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 13:17:47 -0000 On Mon, 4 Jul 2016, Valery Smyslov wrote: >> > Isn't this kinda off-topic for the thread? I though we were first >> > considering "create an IKEv2 extension that mixes in the PSK" as the >> > simplest way to get around the "go back to IKEv1" guidance. >> >> So that was not entire clear to me from the title, but it seems you are >> right. >> >> Perhaps we can change the title from: >> >> Postquantum Preshared Keys for IKEv2 >> >> to: >> >> Postquantum protection for IKEv2 Preshared Keys SA's > > That's incorrect title. The original title is correct. > > The draft provides postquantum protection to any SA, regardless > of the authentication methods used. In other words, PPKs (as specified in the > draft) > don't replace preshred keys authentication in IKEv2, they augment > any authentication method to provide postquantum security. > >> The original title to me reads like a "new feature" instead of like a >> "fix for old feature". But then PaulH is wrong and this draft is a lot more then fixing just IKEv2 PSK for postquantum. Paul From nobody Mon Jul 4 06:29:51 2016 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 DE99A12D122 for ; Mon, 4 Jul 2016 06:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 jNN7XXV79EEq for ; Mon, 4 Jul 2016 06:29:48 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB82812D124 for ; Mon, 4 Jul 2016 06:29:47 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id q132so117273110lfe.3 for ; Mon, 04 Jul 2016 06:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=ll74e5FKIn00UbMcj5DFgpK7PvljtCHbX55PTF/m4p4=; b=LDsWC7FnvBDRw3K3mt2DyrQK2Jj2kZRCs+GaK2/WrBsfbbWqZxpEJn2n4NKBZjj+Y/ UUmhaxyFJfgCS+gC2N7ELlnRHHECeq+Bqq8Rt07t6q8eOaKeepEfwzuzDANBvUSOpscv JIYoeu4Lqick1TnB8GGYUNfrR0vxwBFFzbL0Y0n6PNPhKBQPbsgTTicDaumGcgrxa0MT Zr+YEdKnql4SHfbf9eICPJFZAdzrCbwQgUlDd3v5kRA+lYQjAIuiFDKac9+TXS7g7zxg /tW0wi3c8DyFdOmh11mUw+WuKuE31hW03SuQdsE48RhPb4NljR6tJK+dWm36huE8klks hcEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=ll74e5FKIn00UbMcj5DFgpK7PvljtCHbX55PTF/m4p4=; b=W0LXnENM/xYqiQvjpfiREqNLejFpVA75Z30BXS9ypw+xDGBAe15HG6Mt/jJKx8LrjM vJc1fHUdMMuw2Y3obAXhkzaOWBxXPXnaEQEN4msOZ/IBFmS6gadI5DQDVYZp20n5f4Ob Chcz2p6SXgaU8AxclU4abC+pH4TxBzb4yOh93O5ZKJm1vNBId6RU0tnQy7bH2M5mVtXf WRNGUh+TQ+WQVwQ1mfsbSlqCKCfVtVKgdFLRRIuBIgzGJW1xbJVdPOsjY1GD4MKTdnMZ 1rzb/DaGE+KmCUn6SyO5hk6/Q+BOgc5/8tiW6gHYQ5fuR9boG0fwBz2MjXtti45N8HTB TkkQ== X-Gm-Message-State: ALyK8tJLm/RmKVkqn9F0ZPZ2oBOPAjIEp/5ME14OaU3d/tkXMDj2jI9pJJXnGYJQmBVVxA== X-Received: by 10.25.148.200 with SMTP id w191mr2340448lfd.2.1467638986063; Mon, 04 Jul 2016 06:29:46 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 12sm4675528ljf.17.2016.07.04.06.29.44 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Mon, 04 Jul 2016 06:29:44 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> <985E4A9D-D5BD-430B-BCCC-BE64F804E2AA@nohats.ca> <8D922896-8B9D-4A8C-A2E9-81646D620715@vpnc.org> Date: Mon, 4 Jul 2016 16:29:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Mark McFadden , Paul Hoffman Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 13:29:50 -0000 >> The draft provides postquantum protection to any SA, regardless >> of the authentication methods used. In other words, PPKs (as specified in the >> draft) >> don't replace preshred keys authentication in IKEv2, they augment >> any authentication method to provide postquantum security. >> >>> The original title to me reads like a "new feature" instead of like a >>> "fix for old feature". > > > But then PaulH is wrong and this draft is a lot more then fixing just > IKEv2 PSK for postquantum. Doesn't this new feature fixes IKEv2 preshared key auth? I don't think PaulH is wrong, this draft just offers a bit more. > Paul Valery. From nobody Mon Jul 4 09:09:21 2016 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 286AD12D1AE for ; Mon, 4 Jul 2016 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-zTxRXnbCNs for ; Mon, 4 Jul 2016 09:09:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D65012D193 for ; Mon, 4 Jul 2016 09:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6552; q=dns/txt; s=iport; t=1467648556; x=1468858156; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QjTNgS+47KO/5dhEoCa9kK3RRWY3hpKfATHnvCGvq+Y=; b=bPEldZ4wR5+7EnhHLhuGXlIIGZQxpTMmqvAij27dPh3EOg+CYX7RX7hc DpwYoq9OqEUwDg5r1RL5b3Bnq0HxdTfzLyolZRM+XveUHqh4UNDagRRc6 6Ys5V9BooP5dKk2InswNVJsAAlqbRgl7GpdBgeGQ76XKwniC0iEFThfEh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgA6iXpX/5NdJa1bgz5WfAa5MIF5G?= =?us-ascii?q?oV+AhyBHTgUAQEBAQEBAWUnhEwBAQQBIxFFDAQCAQgRBAEBAQICIwMCAgIwFAE?= =?us-ascii?q?ICAIEAQ0FCBOIDQipao8/AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSeETYQRg?= =?us-ascii?q?zCCPR0FmRMBhgiIN4I/jHKQCQEeNoI7gTVuiA1/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,575,1459814400"; d="scan'208";a="120265505" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2016 16:09:15 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u64G9Fs9022058 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jul 2016 16:09:15 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 4 Jul 2016 12:09:14 -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.1210.000; Mon, 4 Jul 2016 12:09:14 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters , Yoav Nir Thread-Topic: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document Thread-Index: AQHR1WnM8vuQFTejNEm8utmRPiD7sKAISYmAgAAAhnA= Date: Mon, 4 Jul 2016 16:09:14 +0000 Message-ID: <7ce9c68f77d84a97bb16cc7b67617f78@XCH-RTP-006.cisco.com> References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.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.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Mark McFadden Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 16:09:19 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSVBzZWMgW21haWx0bzpp cHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBXb3V0ZXJzDQo+IFNlbnQ6 IE1vbmRheSwgSnVseSAwNCwgMjAxNiA1OjQ0IEFNDQo+IFRvOiBZb2F2IE5pcg0KPiBDYzogaXBz ZWNAaWV0Zi5vcmc7IE1hcmsgTWNGYWRkZW4NCj4gU3ViamVjdDogUmU6IFtJUHNlY10gRnVydGhl ciB0aG91Z2h0cyBvbiBkcmFmdC1mbHV0dGVyLXFyLWlrZXYyIGFzIGFuIElQc2VjTUUNCj4gV0cg ZG9jdW1lbnQNCj4gDQo+IE9uIFN1biwgMyBKdWwgMjAxNiwgWW9hdiBOaXIgd3JvdGU6DQo+IA0K PiA+PiAzKSBUaGUgSW50ZXJuZXQgRHJhZnQgQ3VycmVudGx5IHVuZGVyIGNvbnNpZGVyYXRpb24g aXMgbm90IHRoZSBiZXN0IHN0YXJ0aW5nDQo+IHBvaW50IGFzIGl0IGFzc3VtZXMgdGhhdCBwb3N0 LXF1YW50dW0gcHJlLXNoYXJlZCBrZXlzIGFyZSB0aGUgcHJlZmVycmVkDQo+IHNvbHV0aW9uIGZv ciBxdWFudHVtIHJlc2lzdGFuY2UuIFRoaXMgaXMgbm90IG9idmlvdXNseSB0aGUgY2FzZTsgdGhl cmUgYXJlIGENCj4gbnVtYmVyIG9mIGRyYXdiYWNrcyB3aXRoIHRoZSBzdWdnZXN0ZWQgc3lzdGVt Og0KPiA+DQo+ID4gSSB0aGluayB0aGlzIG1pc3N0YXRlcyB0aGUgcHJvYmxlbSB0aGF0IHRoZSBk cmFmdCBpcyB0cnlpbmcgdG8gc29sdmUuIFRoZSBkcmFmdA0KPiBpcyBub3QgYSBzb2x1dGlvbiB0 byB0aGUgcHJvYmxlbSBvZiBhdXRoZW50aWNhdGluZyBwZWVycyBpbiBhIHdvcmxkIHdoZXJlDQo+ IGFkdmVyc2FyaWVzIGhhdmUgcXVhbnR1bSBjb21wdXRlcnMuIFRoZSBkcmFmdCBpcyBhIHNvbHV0 aW9uIHRvIHRoZSBwcm9ibGVtDQo+IG9mIGF1dGhlbnRpY2F0aW5nIHBlZXJzICp1c2luZyBwcmUt c2hhcmVkIGtleXMqIGluIHN1Y2ggYSB3b3JsZC4gVGhlcmUgbWF5DQo+IGJlIGRpZmZlcmVudCBz b2x1dGlvbnMgZm9yIGF1dGhlbnRpY2F0aW5nIHBlZXJzIHdpdGggb3RoZXIgY3JlZGVudGlhbHMu DQoNCkFjdHVhbGx5LCB0aGUgZHJhZnQgaXMgYSBib2x0LW9uIHRvIGV4aXN0aW5nIGF1dGhlbnRp Y2F0aW9uIG1ldGhvZHM7IHRoZSBhdXRoZW50aWNhdGlvbiBtZXRob2QgdXNlcyBpcyB0aGUgbmV3 ICdwb3N0cXVhbnR1bSBwcmVzaGFyZWQga2V5cycgcGx1cyB3aGF0ZXZlciBJS0V2MiBhdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20gdGhhdCB0aGUgcGVlcnMgdXNlLiAgRm9yIGV4YW1wbGUsIHlvdSBj YW4gdXNlIGNlcnRpZmljYXRlcyB0byBhdXRoZW50aWNhdGU7IHRoZSBkcmFmdCBhc3N1bWVzIHRo ZXJlJ3MgYWxzbyBhIHNoYXJlZCBzZWNyZXQgdGhhdCB0aGUgcGVlcnMgaGF2ZS4NCg0KWW91IG1p Z2h0IG9iamVjdCAiaG93IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gYSBoYXZpbmcgYSBwb3NzaWJs eSBnbG9iYWwgYXV0aGVudGljYXRpb24ga2V5IjsgdGhlIGFuc3dlciBoZXJlIGlzIHRoYXQgdGhp cyBwb3N0cXVhbnR1bSBwcmVzaGFyZWQga2V5IGlzbid0IG1ha2luZyBhbnl0aGluZyB3b3JzZTsg aWYgdGhlIGFkdmVyc2FyeSBsZWFybnMgdGhlIHBwaywgdGhleSBzdGlsbCBjYW4ndCBicmVhayBp biAodW5sZXNzIHRoZXkgYWxzbyBicmVhayB0aGUgZXhpc3RpbmcgSUtFdjIgYXV0aGVudGljYXRp b24gbWVjaGFuaXNtKS4NCg0KU286DQotIEFuIGFkdmVyc2FyeSBjYW4ndCBicmVhayBjb25maWRl bnRpYWxpdHkgdW5sZXNzIHRoZXkgbGVhcm4gdGhlIHBwayBBTkQgdGhleSBjYW4gYnJlYWsgdGhl IElLRXYyIGtleSBleGNoYW5nZSAoc3VjaCBhcyB3aXRoIGEgUXVhbnR1bSBDb21wdXRlcikuDQot IEFuIGFkdmVyc2FyeSBjYW4ndCBicmVhayBhdXRoZW50aWNhdGlvbiB1bmxlc3MgdGhleSBsZWFy biB0aGUgcHBrIEFORCB0aGV5IGNhbiBicmVhayB0aGUgZXhpc3RpbmcgSUtFdjIgYXV0aGVudGlj YXRpb24gbWVjaGFuaXNtLg0KDQoNCkdvaW5nIHRvIHRoZSBicm9hZGVyIHRvcGljLCBJIGFncmVl IHRoYXQgaXQgd291bGQgYmUgcHJlZmVyYWJsZSB0byBoYXZlIGEgcG9zdHF1YW50dW0gc29sdXRp b24gdGhhdCB3b3VsZCB3b3JrIGluIGFsbCBjYXNlcywgd2l0aG91dCBhc3N1bWluZyBhIGRpc3Ry aWJ1dGVkIHNlY3JldC4gIEhvd2V2ZXIsIGluIGdlbmVyYWwsIHRoaXMgd291bGQgcmVxdWlyZSBh IHBvc3RxdWFudHVtIGtleSBleGNoYW5nZSwgYW5kIHRoYXQncyB0aGUgcnViOyB3ZSdyZSBub3Qg dGhlcmUgeWV0LiAgV2UgaGF2ZSBNY0VsaWVjZSAod2hpY2ggcmVxdWlyZXMgaHVnZSBrZXlzOyBr ZXkgc2hhcmVzIGlmIHdlIHVzZSBpdCB0byBkbyBrZXkgZXhjaGFuZ2UpLCB3ZSBoYXZlIE5UUlUg KHdoaWNoIHNvbWUgcGVvcGxlIGRvbid0IHRydXN0KSwgYW5kIHRoZXkgd2UgaGF2ZSBhIGxhcmdl IG51bWJlciBvZiBtb3JlIHJlY2VudCBzY2hlbWVzIGRpc2NvdmVyZWQgaW4gdGhlIGxhc3QgNSB5 ZWFycyBvciBzbyAoYW5kIHNvIGhhdmVuJ3QgaGFkIGVub3VnaCB0aW1lIHRvIGJlIGNyeXB0b2dy YXBoaWNhbGx5IHZldHRlZCkuDQoNCk5vdywgZXZlbnR1YWxseSB3ZSdsbCBjb21lIHVwIHdpdGgg YSBzY2hlbWUgd2hpY2ggaXMgYm90aCBkZXBsb3lhYmxlIGFuZCBoYXMgYSByZWFzb25hYmxlIGFt b3VudCBvZiB0cnVzdDsgaG93ZXZlciB0aGF0J2xsIGJlIGEgZmV3IHllYXJzIGZyb20gbm93Lg0K DQpPbiB0aGUgb3RoZXIgc2lkZSwgd2UgY2FuIGxvb2sgYXQgdGhlIG5lZWQ7IG5vIG9uZSByZWFs bHkga25vd3Mgd2hlbiBhIHZpYWJsZSBxdWFudHVtIGNvbXB1dGVyICh3aGljaCBjYW4gYnJlYWsg dGhlIERIIGFuZCBFQ0RIIGdyb3VwcyB0aGF0IHdlIHVzZSkgd2lsbCBiZSBidWlsdDsgdGhlIGd1 ZXNzZXMgdGhhdCBJJ3ZlIGhlYXJkIGlzIHRoYXQgaXQgbWlnaHQgYmUgaW4gMTAtMTUgeWVhcnMg KG1heWJlKS4gIFRoYXQgd291bGQgbWFrZSBpdCBzb3VuZCBsaWtlIHdlIGhhdmUgdGltZSwgZXhj ZXB0IHRoYXQgd2hlbiBhIHF1YW50dW0gY29tcHV0ZXIgZG9lcyBiZWNvbWUgYXZhaWxhYmxlLCB0 aGVuIHNvbWVvbmUgd2lsbCBiZSBhYmxlIHRvIGRlY3J5cHQgcHJldmlvdXNseSByZWNvcmRlZCBz ZXNzaW9uczsgdGhpcyBtaWdodCBtZWFuIHRoYXQsIGluIDEwIHllYXJzLCBzb21lb25lIG1pZ2h0 IGJlIGFibGUgdG8gZGVjcnlwdCBlbmNyeXB0ZWQgdHJhZmZpYyBmcm9tIHRvZGF5Lg0KDQpCZWNh dXNlIG9mIHRoaXMsIGl0IHdvdWxkbid0IGFwcGVhciB0byBiZSBhZHZpc2FibGUgdG8gd2FpdCBm b3IgdGhlIGZ1bGwgc29sdXRpb247IGZvciBwZW9wbGUgd2hvIGFyZSBjb25jZXJuZWQgYWJvdXQg UXVhbnR1bSBDb21wdXRlcnMsIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGhhdmUgYSBzaG9y dCB0ZXJtIHNvbHV0aW9uLiAgSW4gbXkgbWluZCwgaXQncyBPSyBpZiB0aGUgc2hvcnQgdGVybSBz b2x1dGlvbiBkb2Vzbid0IGFkZHJlc3MgYWxsIHBvc3NpYmxlIHNjZW5hcmlvczsgaXQncyBzdWZm aWNpZW50IGlmIGl0IHByb3ZpZGVzIGEgd2F5IHRvIGFkZHJlc3MgdGhlIGltbWVkaWF0ZSBuZWVk IGZvciB0aG9zZSBwZW9wbGUgd2hvIGFyZSBjb25jZXJuZWQuDQoNCg0KPiANCj4gVGhhdCB3YXMg bm90IGNsZWFyIHRvIG1lIHdoZW4gd2Ugd2VyZSBhc2tpbmcgZm9yIGFkb3B0aW9uIG9mIHRoZQ0K PiBkb2N1bWVudC4gSW4gb25lIHdheSwgSSBoYXZlIGxlc3MgaXNzdWVzIHdpdGggaXQgaWYgdGhl IGRvY3VtZW50IGNhbiBjbGVhcmx5DQo+IHN0YXRlIHRoYXQgaXMgdGhlIHNjb3BlIG9mIGl0LiBP biB0aGUgb3RoZXIgaGFuZCwgd2UgbWlnaHQgd2FudCB0byBoYXZlIGENCj4gZGlzY3Vzc2lvbiBh Ym91dCB0aGUgc2VjdXJpdHkgb2YgUFNLIGluIGdlbmVyYWwsIGFuZCB3aGV0aGVyIHRoZSBtZXRo b2QNCj4gZGVzZXJ2ZXMgdG8gYmUgb2Jzb2xldGVkIGNvbXBsZXRlbHkgYmVjYXVzZSBvZiBpdHMg Y29udGludWVkIHdlYWsNCj4gZGVwbG95bWVudHMgKGVnIHNlZSBTbm93ZGVuIGxlYWtzKQ0KPiAN Cj4gPiBIb3dldmVyLCB3aXRoIG15IHZlbmRvciBoYXQgb24sIEkga25vdyB0aGF0IFBTS3MgYXJl IHVzZWQgZXh0ZW5zaXZlbHkNCj4gKGFuZCBub2JvZHnigJlzIGFza2luZyBtZSB3aGV0aGVyIHRo aXMgaXMgYSBnb29kIGlkZWEgb3Igbm90KSwgYW5kIEkgaGF2ZQ0KPiBoZWFyZCB0aGF0IHNvbWUg dXNlcnMgYXJlIGJlZ2lubmluZyB0byBhc2sgcXVlc3Rpb25zIGFib3V0IHF1YW50dW0NCj4gcmVz aXN0YW5jZS5TbyBJIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBhIHByb2JsZW0gdG8gc29sdmUgaGVy ZS4NCj4gDQo+IEkgY2FuIHNlZSB0aGF0IHBvaW50LiBBcyB2ZW5kb3IgaXQgaXMgaGFyZCB0byB0 ZWxsIHBlb3BsZSBub3QgdG8gZG8gYSBjZXJ0YWluDQo+IGRlcGxveW1lbnQgYmVjYXVzZSBpdCBp cyBzZWVuIGFzICJlYXNpZXN0Ii4gSG93ZXZlciB3aXRoIG91ciBJRVRGIHByb3RvY29sDQo+IGRl c2lnbmVyIGhhdHMgb24sIHRoaXMgc2hvdWxkIG5vdCBiZSBhIHN0cm9uZyBhcmd1bWVudC4NCg0K SWYgd2UgdGhpbmsgdGhhdCB0aGlzIFdHIHNob3VsZCBoYXZlIGEgbG9uZyB0ZXJtIGdvYWwgb2Yg ZGVzaWduaW5nIGEgcHJvdG9jb2wgdGhhdCBpcyBlYXN5IHRvIHVzZSBzZWN1cmVseSwgYW5kIGlz IHBvc3RxdWFudHVtIHNlY3VyZSwgSSB3b3VsZCBhZ3JlZSB0aGF0J3MgYSBmaW5lIGlkZWEuICBI b3dldmVyLCB0aGF0J3MgYSBsb25nIHRlcm0gZ29hbDsgSSB3b3VsZCBjbGFpbSB0aGF0IHdlIHNo b3VsZG4ndCBpZ25vcmUgdGhlIHNob3J0IHRlcm0gcmVxdWlyZW1lbnRzIGFzIHdlbGwuDQoNCg0K From nobody Mon Jul 4 09:40:10 2016 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 AD44C12D1AF for ; Mon, 4 Jul 2016 09:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] 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 g-s0mNoWk4S6 for ; Mon, 4 Jul 2016 09:40:08 -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 5B55812D12B for ; Mon, 4 Jul 2016 09:40:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rjt6D6LFmz5x; Mon, 4 Jul 2016 18:40:04 +0200 (CEST) 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 PdXFhYa8CHFz; Mon, 4 Jul 2016 18:40:04 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 4 Jul 2016 18:40:03 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0F8D545C47A; Mon, 4 Jul 2016 12:40:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0F8D545C47A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EC0D2406B6F0; Mon, 4 Jul 2016 12:40:02 -0400 (EDT) Date: Mon, 4 Jul 2016 12:40:02 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" In-Reply-To: <7ce9c68f77d84a97bb16cc7b67617f78@XCH-RTP-006.cisco.com> Message-ID: References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> <7ce9c68f77d84a97bb16cc7b67617f78@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Mark McFadden , Yoav Nir Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 16:40:10 -0000 On Mon, 4 Jul 2016, Scott Fluhrer (sfluhrer) wrote: > Actually, the draft is a bolt-on to existing authentication methods; > You might object "how is this different from a having a possibly global authentication key"; > Because of this, it wouldn't appear to be advisable to wait for the full solution; for people who are concerned about Quantum Computers, it would be appropriate to have a short term solution. In my mind, it's OK if the short term solution doesn't address all possible scenarios; it's sufficient if it provides a way to address the immediate need for those people who are concerned. In that case, I feel we are back at making a much simpler solution of providing a key identifier that leads to an additional mixing in of SKEYSEED generation. And not add methods of ID hiding. And have something that can be tested by implementations using a shared OTP. If the people discussing this will be in Berlin, perhaps we should put this on the agenda to discuss? Paul From nobody Tue Jul 5 02:16:18 2016 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 7FC4A12D17B for ; Tue, 5 Jul 2016 02:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKeCQa35ExhE for ; Tue, 5 Jul 2016 02:16:15 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DFE12D0B7 for ; Tue, 5 Jul 2016 02:16:15 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id f6so130553843lfg.0 for ; Tue, 05 Jul 2016 02:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=h6nEC1W6vdop86okFMj5E9JiMSWUWNyW3au3G/5sGMU=; b=ZGYrUuGnu7gi6XqHd2QH+fuFZiXyhtVvtw7Uj3+1HSvvrAlUz16M/bVfcNHTZfthxp GSvMEQhk45UjkSuIEN3/VvVTemSSzk7R1Rsz1gZNILjv2M4Z5plQ3j7yEUi1aJw+0zKf f6uPq0kaBTXuGlGAQeYIz1MhwE9o3c1wZD1ehN4xPBX7e14aJIeKmkxw1H8fdGhgbctO 8KbpVWXueGl51WwXUYfOnITEF3P2Z1dmq1xOgAGCSbNG8ULa156PVQgsPuGCaed4IJ5m b8tu4t7Lr1Y/oZSbKoNsVuuHFytxWrXz3cPyC942zbZw1Yv6n9G0St+cuFUifn2uOhgs pn3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=h6nEC1W6vdop86okFMj5E9JiMSWUWNyW3au3G/5sGMU=; b=Vt+Bv8mdTXDYU+zRsULWeprzg9bAEz0bKMMrhGj9wZUph5uKdiXPiuuWDtVs1Q9PGG rWF/k5JsuwQ4+snnsvT7KSJ58aMxpqSrXK2J8HPvGa5B6quuTeDEvAk805DuyL6xFW3D QvwpKEQQXA7Kz7jAwHCHVs8bvMquAfHKTKrDt18b4ain2ZIWjuaDMNis9H/INg+hpdgm YMoKDCS21EE+kdpfpEPTAzbh4k2IY2vAfz/FvSm9WrT7jvxE0YGVVR15agIkVP8HwnfE FoLJuUH+NnNL8uEHH1du5RHZwMYzLoEe5UWlSS8xVYXBrY3s661YInITkWPLEc4PpgU/ L5dw== X-Gm-Message-State: ALyK8tIR67dMkU7VtcYgBMBhllM3LWp9OXZWfm+kXw0ctHZDVbDEdavMyDbrNtAGaapEFw== X-Received: by 10.25.142.143 with SMTP id q137mr3320175lfd.53.1467710173518; Tue, 05 Jul 2016 02:16:13 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 39sm4050550lja.37.2016.07.05.02.16.12 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 05 Jul 2016 02:16:12 -0700 (PDT) Message-ID: <899D4330398A487881399DF50ED04E34@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "David McGrew" References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> <13D79424-BA6E-4E9A-AD82-8FEEA03B51D8@cisco.com> <22390.33785.830861.274015@fireball.acr.fi> Date: Tue, 5 Jul 2016 12:16:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , paul@nohats.ca, "Panos Kampanakis \(pkampana\)" , "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 09:16:17 -0000 Hi Tero, I think it is a bit early to discuss particular approaches, before the WG makes a decision to adopt the document. However, just for the record (see below). > Earlier I have proposed very simple method where the IKE_SA_INIT > contains just some kind of notification messages identifying the > "oob-key" to be use. This identification information is completely > opaque, and fully depends on the implementation. > > It could be fixed random string, which would immediately leak out the > identity of the users, just like IKEv1 IP-address did. It could just > random identifier, which identifies the one-time-use shared secret > from big table (which is shared between the end nodes), it could be > some kind of encrypted blob, which is encrypted with some kind of > system wide group shared key (i.e., everybody in the group know it, > but outsiders do not, so it protects identities for outsiders, but not > for insiders), or it could be something more complicated like what > current draft proposes. > > For the IKEv2 protocol point of view it is just opaque binary object > which is given to the subsystem which will then return a shared key to > be used for him. > > In all cases both ends must share the same shared key or table of > shared keys or access to the QKD subsystem, so this code that knows > how this blob is interpreted can be left to the implementations. We do > not need to standardize it, we can leave it open, just like we leave > cookie or the IKEv2 session resumption ticket format. We could include > some proposals in the appendix, and we might want to add 16-bit > "format identifier" in the beginning just in case people want mix > multiple methods in same implementations. > > This means that the level of shared key identity protection is left to > implementation and to it depends on the policy settings. > > When IKEv2 then has the shared secret then it needs to mix that to > some parts of the cryptographic protection to provide quantum > resistant IKEv2. > > There are multiple levels on that: > > 1) Include it only in KEYMAT. This will protect all IPsec SAs, i.e. > the actual traffic transmitted over IPsec is protected from > attackers able to break the Diffie-Hellman of the IKEv2. I.e., > replace SK_d in there with (SK_d | OOB_secret). Note, this have > also the side effect that after the first IKEv2 rekey also the > IKEv2 SA traffic is protected, as new keying material after the > IKEv2 rekey depends on the SK_d. > > 2) In addition to the 1, include it also in the SK_pi and SK_pr. This > will mean that even if the attacker is able to break Diffie-Hellman > and the Signature method, he will not be able to authenticate as > user, as he cannot calculate the MACedIDforI/MACedIDforR for > authentication. I.e. replace SK_pi and SK_pr with (SK_pi | > OOB_secret) and (SK_pr | OOB_secret). > > 3) Include it in the SKEYSEED calculation. This will has the side > effect that we are no longer able to get meaningfull error messages > in case something goes wrong in the OOB key identification process, > i.e., in case the OOB_secrets do not matchi, we just drop the frame > and wait for next one, thus we cause timeout if OOB_secret is > wrong. This is bad for user experience, but this will also protect > the IKEv2 SA traffic with the OOB_secret. Not necessary. In particular, the current draft allows to detect OOB key mismatch and to act gracefully in this situation. And I don't think it is far too complicated. Regards, Valery. From nobody Tue Jul 5 02:20:14 2016 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 9CAA812D0A5 for ; Tue, 5 Jul 2016 02:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yynUfleFBOFu for ; Tue, 5 Jul 2016 02:20:08 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 14B7912D0BA for ; Tue, 5 Jul 2016 02:20:08 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id q132so130619712lfe.3 for ; Tue, 05 Jul 2016 02:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=eL107AODKQcM6qJINY7/QnOZIxkfL4N9uA+S4cnsXxw=; b=DLk1VahA3UwdUCcmXvFaO96O9yfloio0x1pRFrs4zbYU3gApPmLCbVYcD6EtLTIXdI +Nvu+nL/HEM76D/rbKAr0qyg0HGD3uFcZ63HCbNSos1MQeKx29Z+5/Aq/CpXTx65pX0W rYcUH72Re5obbsUAGOAvu5dS5jkiUwBvKZ3WwoVg+8ANoCYyKhLKKdV0BzfFdob6S198 9rw3zhbHC2ELJUkkMIzahXlGmDXKLFtgsTiCWJ6h34CGyFovtQn9VhwM4z0eLxpwCuH7 jUeCdWoEY4wo7GBgFYdVL3HbVsnzkxiKxfsQJFcL1XI6alNQusR/DBGQKJxh6Tk0OdzG ayjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=eL107AODKQcM6qJINY7/QnOZIxkfL4N9uA+S4cnsXxw=; b=LDGbJ0wzCJCZVZI88EN4USyZDY3zibkAsYIxWwLlI9du/+oeqdVCSQXRvYkG+6ouOj +gtwC+6Jze2yKbcBb5Ew8sV12xaj3mL/KXGxfNRdcmwUis1yMtZO3sS1F88V+h2xXgys 76nPROp2GxArHJ4XXNmo1eBYZFV4rd9rxxoNHdT5H2WVAU7brYHKPCDAalA2aLayeAQB HA1g2dgSradD6ZCRwUMr32f8p4T9L9v4KQ/+bw95XSSDA6BsKe+TuH5oVQQfr6vL0RW5 XB0eJsAjyK6wG6fxFdwEUdXp2XY2MTXEv/kd22+FXFw4bLfAGOy9QRs3qrq6yFeoc2UR 93Tg== X-Gm-Message-State: ALyK8tIZrG3lLHbt1nSO3vKO/vFSGTXqN78wmfVQYPzPJ9be35cbwolLf36+PS58SDfgBg== X-Received: by 10.25.169.195 with SMTP id s186mr3302743lfe.84.1467710406165; Tue, 05 Jul 2016 02:20:06 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u193sm5278744lfd.36.2016.07.05.02.20.04 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 05 Jul 2016 02:20:05 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" , , "David McGrew" References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> Date: Tue, 5 Jul 2016 12:20:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 09:20:12 -0000 Hi, just to reiterate my position in light of this questionnaire: > This has been a good discussion so far. There is work to be done to address the issues raised. > > Getting back to the call for adoption, I'd like to see feedback on the following questions to better understand where > consensus is on this issue. > > 1) Previous WG discussions have indicated interest in this problem. Does the working group think that there is a > problem here that we need to address? Yes. > 2) Should we do this work in the IPsecME working group? If not, where? Here. > 3) Can we use draft-fluhrer-qr-ikev2 as a starting point for developing a WG solution to this problem? If not, what is > a suitable starting point instead? We can. Regards, Valery. > Regards, > Dave > >> -----Original Message----- >> From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com] >> Sent: Friday, June 24, 2016 11:26 AM >> To: paul@nohats.ca; David McGrew >> Cc: Waltermire, David A. (Fed) ; IPsecME WG >> ; Panos Kampanakis (pkampana) >> Subject: RE: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME >> WG document >> >> >> > -----Original Message----- >> > From: Paul Wouters [mailto:paul@nohats.ca] >> > Sent: Friday, June 24, 2016 9:43 AM >> > To: David McGrew (mcgrew) >> > Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer); >> > Panos Kampanakis (pkampana) >> > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an >> > IPSecME WG document >> > >> > On Fri, 24 Jun 2016, David McGrew wrote: >> > >> > Hi David, >> > >> > > Because QKD is not a practical system for Internet security. It has serious >> > security issues/challenges and operational limitations on bitrate, range, and >> > physical media. It requires a point to point optical link, which is typically >> > dedicated fiber, which must be shorter than 60 miles. There are >> > security issues with QKD because it relies on a physical interaction >> > across the line between the encrypter and decrypter, thus giving an >> > attacker the opportunity to perform an attack on the physical process >> anywhere on that >> > line. See for instance Brassard et. al. Security Aspects of Practical Quantum >> > Cryptography, Lydersen et. al., Hacking commercial quantum >> > cryptography systems by tailored bright illumination, or Gerhardt et. >> > al., Full-field implementation of a perfect eavesdropper on a quantum >> cryptography >> > system. Another major security problem is the range limitation; it has >> been >> > proposed to extend the range of QKD by using a chain of trusted >> > repeaters, each connected by a QKD sy stem. These repeaters would >> > greatly increase the attack surface, and require the end user to trust >> > the infrastructure provider(s); in contrast, the Internet community >> > wants end to end encryption, as described in RFC3365 and RFC7624. >> > > >> > > In contrast, QR-IKEv2 can be used to add postquantum security >> > > between >> > any two points on the globe, without requiring dedicated fiber, and >> without >> > requiring physical layer security assumptions. It has *fewer* security >> > assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft >> > relies on the security of symmetric cryptography and the physical >> > layer, whereas QR-IKEv2 relies only on the former. >> > >> > For a postquantum IKEv2 extension, does it matter which underlying >> > mechanism is used to provide the extra bits to mix into the SKEYSEED? >> > >> > I think what is needed is: >> > >> > - A NOTIFY message that signals an identifier of where the extra bits >> > should be taken/generated from. Both endpoints have previous >> > knowledge >> > of what tjos identifier refers to. Be it a hardware device or an >> > offset in a onetime pad, etc, etc. >> >> One possible concern is whether such a notify message would compromise >> the anonymity properties of IKE; if someone in the middle sees the same >> identifier in multiple exchanges, would they be able to conclude that those >> are the same individuals negotiating? If the NOTIFY messages are >> anonymized, how is that done? >> >> Now, it might be that the WG would decide to compromise on such >> anonymization concerns; this would simplify things a lot, however it's very >> much something we need WG agreement on. >> >> > >> > - A specification on how to mix in these extra bits into SKEYSEED generation >> > to gain postquantum security. >> >> The reason we specify modifying the public nonces (rather than doing a more >> fundamental change to the skeyseed computation) was to minimize changes >> to the IKE implementation itself (and in particular, the crypto parts). Is there >> a reason why we wouldn't continue with this approach? >> >> > >> > - Any additional counter meassures (such as increased minimum >> > keysizes) >> >> And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as >> the standard IKE versions are fixed to 128 bit keys) >> >> > >> > Do we need to know if these bits came from a QKD link, a QR link, or a >> > mutually shared onetime pad? If not, then these specifics should not >> > go into such an ikev2 extension. >> > >> > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jul 5 05:44:30 2016 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 52AFD12D50E for ; Tue, 5 Jul 2016 05:44:29 -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 YHE37DtrbrOT for ; Tue, 5 Jul 2016 05:44:27 -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 C133112D0F8 for ; Tue, 5 Jul 2016 05:44:25 -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 u65CiCg8008127 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Jul 2016 15:44:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u65CiBVh024079; Tue, 5 Jul 2016 15:44:11 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22395.43931.364995.728462@fireball.acr.fi> Date: Tue, 5 Jul 2016 15:44:11 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <899D4330398A487881399DF50ED04E34@buildpc> References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> <13D79424-BA6E-4E9A-AD82-8FEEA03B51D8@cisco.com> <22390.33785.830861.274015@fireball.acr.fi> <899D4330398A487881399DF50ED04E34@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 20 min Archived-At: Cc: IPsecME WG , David McGrew , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" , paul@nohats.ca, "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 12:44:29 -0000 [chair hat off] Valery Smyslov writes: > I think it is a bit early to discuss particular approaches, > before the WG makes a decision to adopt the document. Yes and no. It is too early to think about actual protocol decisions, but we need to know whether current draft is suitable for protocol selections we are going to be doing, and we need to think about what kind of compromizes we want to do. I.e., I think it is important to think even in this phase, whether we care about the identity hiding against passive attackers who can break Diffie-Hellman or not. And do we care about identity protection against active attackers. If we do want to protect against one of those kinds of attackers, our solutions are going to be more complicated. If we do not care (i.e., keep the current level of protection in IKEv2 meaning no identity protection against active attackers or attackers who can break Diffie-Hellman) then our solutions are simplier. These requirements and compromizes are the important things we need to decide on the WG before we can make decisions on the actual protocol solutions. > Not necessary. In particular, the current draft allows to detect > OOB key mismatch and to act gracefully in this situation. > And I don't think it is far too complicated. Current draft does, but there has been other proposals which did not. The current draft is also very costly and allows very easy denial of service attacks, as responder needs to linear search of all possible configured PPKs. If we for example use some kind of one time password system, where each user has 1000 pre-distributed PPKs and we have 1000 users, responder needs to do million operations every time someone sends him a packet or same thing if we have million users configured and each have one PPK. Thats why I do not like the current approach and I think trying to hide the identity for the active attacker is just opening other attacks which are worse than the attack where attactive attacker can learn the ID of the initiator... Anyways I think we should work on this problem, and I think we do want to think about the requirements for the solution we are going to do before we can start writing actual protocol specification. And the protocol specification can be based on either one of the drafts, there is not that big difference in them, and depending on the requirements things needs to be added or removed from the drafts. -- kivinen@iki.fi From nobody Tue Jul 5 06:07:07 2016 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 C67B612D567 for ; Tue, 5 Jul 2016 06:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXoZ5ReWUjyZ for ; Tue, 5 Jul 2016 06:07:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242CE12D561 for ; Tue, 5 Jul 2016 06:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4015; q=dns/txt; s=iport; t=1467724020; x=1468933620; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Vq0HgKk/nsZNBPFhAEKb1HZYAFOs7MYvtXtDFv+6Z4E=; b=byEnoDwc2PD3aop0Fiy1OU+nQN687k58IiNAaUynGe5j1ArrWRn2N5V/ hg6bcvb08gbOwDtO5IGanG+pHz7ZYFSEUQF/Kh76iC1F1CiaskFgNFACJ DnqFlWB1p54iP1ShK0PTwfLjQqLAFYMGbFGzST+OglI2LWm2ezOigRvzR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAgD0r3tX/4sNJK1TCYM+gVIGuT6Bd?= =?us-ascii?q?4YYAoExOBQBAQEBAQEBZSeETAEBBAEdHT8FBwQCAQgRBAEBGQYJBzIUCQgCBAE?= =?us-ascii?q?NBQgTiA0IuiYBAQEBAQEBAQEBAQEBAQEBAQEBAQEchieETYQZdYRwHQWTRIVPA?= =?us-ascii?q?Yg+hgGKcIRBkAkBHjaCCBwXgTVuh3p/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,579,1459814400"; d="scan'208";a="122332356" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2016 13:07:00 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u65D70Y5007410 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 13:07:00 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 09:06:59 -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.1210.000; Tue, 5 Jul 2016 09:06:59 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , Valery Smyslov Thread-Topic: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document Thread-Index: AQHRzL5IGlp/kxuNuk2jW8rWXL/+i5/37jCAgAC7ZQCAADyqgP//1znQgAa9egCABFhVgIAAJwWAgAWn/sKAAH0igP//voUA Date: Tue, 5 Jul 2016 13:06:59 +0000 Message-ID: <8a05346931b2459cbbd27f18c0e58fb3@XCH-RTP-006.cisco.com> References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> <13D79424-BA6E-4E9A-AD82-8FEEA03B51D8@cisco.com> <22390.33785.830861.274015@fireball.acr.fi> <899D4330398A487881399DF50ED04E34@buildpc> <22395.43931.364995.728462@fireball.acr.fi> In-Reply-To: <22395.43931.364995.728462@fireball.acr.fi> 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.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , "David McGrew \(mcgrew\)" , "paul@nohats.ca" , "Waltermire, David A. \(Fed\)" , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 13:07:05 -0000 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, July 05, 2016 8:44 AM > To: Valery Smyslov > Cc: David McGrew (mcgrew); IPsecME WG; Scott Fluhrer (sfluhrer); > paul@nohats.ca; Waltermire, David A. (Fed); Panos Kampanakis (pkampana) > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IP= SecME > WG document >=20 > [chair hat off] >=20 > Valery Smyslov writes: > > I think it is a bit early to discuss particular approaches, before the > > WG makes a decision to adopt the document. >=20 > Yes and no. >=20 > It is too early to think about actual protocol decisions, but we need to = know > whether current draft is suitable for protocol selections we are going to= be > doing, and we need to think about what kind of compromizes we want to do. >=20 > I.e., I think it is important to think even in this phase, whether we car= e about > the identity hiding against passive attackers who can break Diffie-Hellma= n or > not. And do we care about identity protection against active attackers. I= f we > do want to protect against one of those kinds of attackers, our solutions= are > going to be more complicated. >=20 > If we do not care (i.e., keep the current level of protection in IKEv2 me= aning > no identity protection against active attackers or attackers who can brea= k > Diffie-Hellman) then our solutions are simplier. >=20 > These requirements and compromizes are the important things we need to > decide on the WG before we can make decisions on the actual protocol > solutions. >=20 > > Not necessary. In particular, the current draft allows to detect OOB > > key mismatch and to act gracefully in this situation. > > And I don't think it is far too complicated. >=20 > Current draft does, but there has been other proposals which did not. >=20 > The current draft is also very costly and allows very easy denial of serv= ice > attacks, as responder needs to linear search of all possible configured P= PKs. If > we for example use some kind of one time password system, where each > user has 1000 pre-distributed PPKs and we have 1000 users, responder > needs to do million operations every time someone sends him a packet or > same thing if we have million users configured and each have one PPK. Actually, the current draft allows the responder to make a trade-off betwee= n identity protection and cost of lookup. In the exchange, the responder selects a "PPK Indicator Input" and the init= iator responds with a value that's a function of the PPK and the PPK Indica= tor input that the responder selected. If the responder always selects a r= andom PPK Indicator Input, you get identity hiding (at the cost of having t= he responder doing the search). If the responder always selects a fixed va= lue, then the initiator's response is a fixed function of the PPK (and so t= he responder can precompute all the PPK's he knows about, and then do a sim= ple lookup at negotiation time), you get a fast negotiation (at the cost of= identity hiding). > Thats > why I do not like the current approach and I think trying to hide the ide= ntity > for the active attacker is just opening other attacks which are worse tha= n the > attack where attactive attacker can learn the ID of the initiator... Actually, the identity weakness would be a passive attacker being able to d= educe whether two negotiations used the same PPK (and if they did, they're = likely from the same entity). >=20 > Anyways I think we should work on this problem, and I think we do want to > think about the requirements for the solution we are going to do before w= e > can start writing actual protocol specification. And the protocol specifi= cation > can be based on either one of the drafts, there is not that big differenc= e in > them, and depending on the requirements things needs to be added or > removed from the drafts. > -- > kivinen@iki.fi From nobody Tue Jul 5 06:08:29 2016 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 BE78B12D534 for ; Tue, 5 Jul 2016 06:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPD9dId0Jc6A for ; Tue, 5 Jul 2016 06:08:22 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8812512D1EB for ; Tue, 5 Jul 2016 06:08:22 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id h129so134456318lfh.1 for ; Tue, 05 Jul 2016 06:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=ykAksL/dq5/G2Tk6YR82X/8x9f/q+pI4CHb/10qTNjw=; b=KGBKudceV/kjDrZBwmg7DCJQaVtzNI922U6tBVtBJhyzEKMcEAvoiFETUv8aGUeUKm cWc4ZaWEmmRzBUZDfd0rE0xpHwFsY/V5qh08LJAvoC1tqxPtRWG2BTTGERxCBQzsWWPL 4oZPpWuFwUnK1ih+ZSjk8tKME3yLoJ1rzpyHQQxk5RK+I1fX8nmMajYw4wfzsHfOwCRL G2jf11rlGxlTBgL1LhjIrJKYZi2HlHv/c6qdcOLzuvuxiIfBccUDt1BWqcbtsC7Aa7wE Z/l7W6lv9E3+qnAvaGvQ3BaD9QRl1X0MZOJSXMzt1hB0F9vHN2NCPX7HzsaWEhF8d7U7 rYOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=ykAksL/dq5/G2Tk6YR82X/8x9f/q+pI4CHb/10qTNjw=; b=fnFwNj/e3dSPBUDMwJ1ugneIn3dyYT1Vat4gqmMFWWIzrLrOY1QVKGOGAfQNtAoqGC 4NRXi9QGZjOhGDNigfKWk41/3RyW/HP48NKwE4derTvFtpXudPYPTD+/ntm9IjJXAQpz wGuLKj4lAXdz6WqnuPW3RPXDlCHMdkBj8i0ElcpQ7H3UZgGTQA5ySieDEOy/vowpAmsx XCy0BeOE6MUazVwzRfcaS7DJ+sIIMaasKaXTigXkJPL+sRbyPxA6S2ajrTzGzBNwkV6O le7xHubCMz23QCnb+19TnJnDFfOS/2m2HfQAfsZq8Kk0857QXl1PlBV79UiNiLtvxZpD 3R3w== X-Gm-Message-State: ALyK8tIMKQlkAnjsIfX1hflLAhTZ8Fo9u+352EQLsXGCOVUSlphwBNDB71ImTbEIIWaWTw== X-Received: by 10.25.142.2 with SMTP id q2mr3626834lfd.11.1467724100754; Tue, 05 Jul 2016 06:08:20 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r132sm5546849lfr.17.2016.07.05.06.08.19 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 05 Jul 2016 06:08:20 -0700 (PDT) Message-ID: <4D12A818248248D18B03690F8B984209@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com><13D79424-BA6E-4E9A-AD82-8FEEA03B51D8@cisco.com><22390.33785.830861.274015@fireball.acr.fi><899D4330398A487881399DF50ED04E34@buildpc> <22395.43931.364995.728462@fireball.acr.fi> Date: Tue, 5 Jul 2016 16:08:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , David McGrew , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" , paul@nohats.ca, "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 13:08:28 -0000 Hi, >> Not necessary. In particular, the current draft allows to detect >> OOB key mismatch and to act gracefully in this situation. >> And I don't think it is far too complicated. > > Current draft does, but there has been other proposals which did not. > > The current draft is also very costly and allows very easy denial of > service attacks, as responder needs to linear search of all possible > configured PPKs. If we for example use some kind of one time password > system, where each user has 1000 pre-distributed PPKs and we have 1000 > users, responder needs to do million operations every time someone > sends him a packet or same thing if we have million users configured > and each have one PPK. Not exactly true. The current draft allows the responder to balance between initiator's identity hiding and responder's load. For example, it can choose to always give to initiators the same PPK Indicator Input and precalculate the results for all the keys it has. In this case there is no identity hiding, however it will take a log2(n) to find the key (literally nothing with million keys). In the other corner case the responder can behave as you described, providing full identity hiding at the cost of additional resource consumption. And the responder can always choose a proper balance between these extreme cases, even dynamically. From nobody Tue Jul 5 10:57:12 2016 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 72FE412D68A for ; Tue, 5 Jul 2016 10:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NIbdV5iMhlq for ; Tue, 5 Jul 2016 10:56:52 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E338512D6B1 for ; Tue, 5 Jul 2016 10:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1467741384; x=2331654984; 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=EH1fWIc8ru8lCrTwrs6mgtMqfyD01GzW/1ykNM1R4pE=; b=vdHXSARltNOgtfwq2aqv3sQfUQsImN6a4SP3mxIEKnzfT6HD1r3KSqRCllwJe447 /sO0ZUKxQvMYdnhGo/5mErF33VbS34wKAGAH1TmNgf8S2KP6A20llsXVc+IXfDpR nrxLMxMHpFZADHuIDnzSgn3OIo3fwwkYIl+85Yd5BC1qWBDysNuY/C6VsK8HVL0F tY0QeZFQdA/ojv9uox4GJQaSQYnuPp+n/lyfi/Tw/4nDT4hZX2J9lOL6E/NjK0Op uwNktlTgs//MGmfNN0/RApLFbzJFrA4IaE0y7Bhf8Deoccn1xdiKN5Vgd+yHnN0O 3rhGPfiGKy72n2h/Y5d0/Q==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 29.11.09353.8C4FB775; Tue, 5 Jul 2016 10:56:24 -0700 (PDT) X-AuditID: 11973e16-f797a6d000002489-6e-577bf4c83b1e Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 78.99.31551.8C4FB775; Tue, 5 Jul 2016 10:56:24 -0700 (PDT) Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O9U00K1MSHZHT60@nwk-mmpp-sz07.apple.com> for ipsec@ietf.org; Tue, 05 Jul 2016 10:56:24 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3199\)) From: Tommy Pauly In-reply-to: Date: Tue, 05 Jul 2016 10:56:23 -0700 Content-transfer-encoding: quoted-printable Message-id: <3E82F541-2618-4FD6-9E8A-72D03FA1FF87@apple.com> References: <94FBAD9A-C67D-4B42-BD1B-B6DBACC945C5@icc-uk.com> <7ce9c68f77d84a97bb16cc7b67617f78@XCH-RTP-006.cisco.com> To: Paul Wouters X-Mailer: Apple Mail (2.3199) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FAYpXviS3W4wfd/mhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoOV05kKNvBVzNrxkrmB8Sh3FyMnh4SAicSKuTNYIWwxiQv3 1rN1MXJxCAnsZZTYcOEoE0xR66nnjBCJ5UwSZ9/8YoZw5jBJnPnxiqWLkYNDWEBCYvOeRJAG ZgEtifU7j4M18wroS9zasQHMFhaIlji46z4ziM0moCJx/NsGMJtTwFGi/80RFhCbRUBVovnn SWaIOYsZJeb98oewtSWevLvACjHTRuLx8fcsEDfMZJLoP3EbrFlEQFFi0plHYPdICMhKbPwh DVIjIbCETWLqvQ/sExhFZiG5bxaS+2Yh2bGAkXkVo1BuYmaObmaeuV5iQUFOql5yfu4mRlCA T7cT28H4cJXVIUYBDkYlHt4Jz6vDhVgTy4orcw8xSnOwKInzlm+uChcSSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAWOWTsXHVBE0hw8CNbVf41b+nBRUdfvrHIfrXg9+Jvg8jvHdzCpgz7Vx3 8G9Q8L3ZFpcM3lo0MCpylbpGrUmexqG8dLrB5uNWSQsM8g4J2fWFSzSesnj60KJ7/12rr5fF nuxknKVY6Ctp1V3uM8FRZX1t24aq3/uVlm6y7HPLudsh/XkuA/cPJZbijERDLeai4kQAyChh zlECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUi2FD8QffEl+pwg4+96hb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoOV05kKNvBVzNrxkrmB8Sh3FyMnh4SAiUTrqeeMELaYxIV7 69m6GLk4hASWM0mcffOLGcKZwyRx5scrli5GDg5hAQmJzXsSQRqYBbQk1u88zgRi8wroS9za sQHMFhaIlji46z4ziM0moCJx/NsGMJtTwFGi/80RFhCbRUBVovnnSWaIOYsZJeb98oewtSWe vLvACjHTRuLx8fcsEDfMZJLoP3EbrFlEQFFi0plHYPdICMhKbPwhPYFRcBaSk2YhOWkWkrEL GJlXMQoUpeYkVprpJRYU5KTqJefnbmIEB2Rh1A7GhuVWhxgFOBiVeHgnPq8OF2JNLCuuzD3E KMHBrCTC++4TUIg3JbGyKrUoP76oNCe1+BBjMtAzE5mlRJPzgdGSVxJvaGJiYGJsbGZsbG5i Tpqwkjgv56KycCGB9MSS1OzU1ILUIpgtTBycUg2M3op/Jc7UpL6ZsSLdSmmi4b28c438T/9I ubQLxM14K6aXL+TN99DWeZeZgkJjBeNX8Z+FqkJzHkpx7FwZeTkxSi5T8PDj1ZdPXglhko0o eBRw0FS1rD18mrHos7dXH0d9cl3gUVUmy/lyQtXk27uMpq9n2TiBfdJ2d+ueVVd+ivb1BK9p 0+tTYinOSDTUYi4qTgQA3L5BXowCAAA= Archived-At: Cc: "ipsec@ietf.org" , Mark McFadden , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 17:57:06 -0000 I think we should definitely add a discussion around this to the Berlin = agenda. =46rom our end, we definitely want to see some measures to add quantum = resistance into IKEv2 to promote the adoption of IKEv2 over IKEv1 for = clients that are concerned. I think draft-fluhrer-qr-ikev2 provides a = good starting point for a WG document to do that. I agree that we can = defer some of the complexities around ID hiding to later solutions, in = the interest of simplicity and providing basic QR in the short term. Thanks, Tommy Pauly Apple > On Jul 4, 2016, at 9:40 AM, Paul Wouters wrote: >=20 > On Mon, 4 Jul 2016, Scott Fluhrer (sfluhrer) wrote: >=20 >> Actually, the draft is a bolt-on to existing authentication methods; >=20 >> You might object "how is this different from a having a possibly = global authentication key"; >=20 >> Because of this, it wouldn't appear to be advisable to wait for the = full solution; for people who are concerned about Quantum Computers, it = would be appropriate to have a short term solution. In my mind, it's OK = if the short term solution doesn't address all possible scenarios; it's = sufficient if it provides a way to address the immediate need for those = people who are concerned. >=20 > In that case, I feel we are back at making a much simpler solution of > providing a key identifier that leads to an additional mixing in of > SKEYSEED generation. And not add methods of ID hiding. And have > something that can be tested by implementations using a shared OTP. >=20 > If the people discussing this will be in Berlin, perhaps we should put > this on the agenda to discuss? >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jul 7 11:57:53 2016 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 16C5F12D855 for ; Thu, 7 Jul 2016 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTZi6vddkwm2 for ; Thu, 7 Jul 2016 11:57:49 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0095.outbound.protection.outlook.com [23.103.201.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A10F12D81C for ; Thu, 7 Jul 2016 11:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tHNZxREPWBnN0++ZC7jYm/bOUavci1LyIxXJVckQnH4=; b=KWGUGEm+XUrHjtkYKBZXgKoGV9lrv/Xgkp+TIk8uMhlWIOcSFZsGv/U3abTuiUAgZ5jk/HrtCUBScQLZBZpfjW8rg1AecQNcXUjuwvgoq2/F7Ys6ZfARUz9r4eFHuKeFYpmTtY4hXiJISPNTl90DPuZKrDDuFU7HUTqejmE9A2M= Received: from DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) by DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) with Microsoft SMTP Server (TLS) id 15.1.534.14; Thu, 7 Jul 2016 18:57:48 +0000 Received: from DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) by DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) with mapi id 15.01.0534.020; Thu, 7 Jul 2016 18:57:48 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: IETF 96 IPsecME Agenda Thread-Index: AdHYfKwEKhVveBgsTmOLLfgSuxW09w== Date: Thu, 7 Jul 2016 18:57:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 58f29a97-e792-433e-c88a-08d3a69896b6 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0665; 6:68SMXv2FDhNiajJfN/5kPlkHCqoBqYcwCKsrsx7l1HfE/szPvJB+NWPHxDctH/vZfm3d/GbjEc8mbevMhlvOu3Yq2vu2BXPogLPMuv13lhoYh6NWOaJYZcYklv34glRhczf4VgyzRNyC6QdNGBTNpG+SEKxPx8LGMQKpmcRU5Z2Ap0ecZpfYaPr9BLzkWr1bC6ILth3M1srFHDfvQW64j/j+9v5MT33AFlavc1yGgwAFBSJIQ/ewDMDwS4bsUk75jThRDpc31tdngqbkfJr4dsdS/XN5ecKQq6x9UDK5UsvZsDihl0p3y54/9sFbEFjq2K5V4qfPKla2R/0T6UcQ5A==; 5:jwDE8DQ104UYTWJRH0e3F60iBHKSXyKkWx3WmaJool/I0MvweIdTtEYE9bu9kUm926Up42EAkwZtolVH3kQZNLz03sjYk9jnwwmFypJWsKjKyZg5h3xobvEBh/4ZNt3S/7ZKlGC3RIvo/QVBHnE46g==; 24:og/ANB/L+uhIjE9p2P1/E885mC+U9cOcG/odDmel9MRHkGLAIT90h3rNLAcnWAJBC3q3IDh2eZRkwkbz++GysYATUMyoLgZNJEBUEB93V5w=; 7:Fx3MwoD+U8mivwv0t9HKXs0MwEcWYG+LC0qwR74OuMaiYxMiG+H19dVGL7ZaX0Sr2g2DnRNNs7zoAGAkGeUftSlVvDT7Oej4RZKAHVrP28eYAqN77mmOGqLJCNtcbY9HrJ/c7r6VAKA2yoouQWgEMVqiHZW2vazIauTg9n51vZpCsOZt7NzVGcY5c5lEDXmSSe77uvBx3KrE+YV/3pba+VmiTUYM89ywHqNXNAmaOaLB/7Z2Sy4rynvNW8ZtDBnA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0665; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0665; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0665; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(229853001)(68736007)(86362001)(106356001)(8936002)(11100500001)(189998001)(74316002)(107886002)(101416001)(87936001)(110136002)(305945005)(7846002)(7736002)(5003600100003)(7696003)(97736004)(8676002)(99286002)(81156014)(3660700001)(5002640100001)(81166006)(54356999)(50986999)(76576001)(105586002)(10400500002)(3280700002)(33656002)(9686002)(450100001)(2906002)(2900100001)(92566002)(122556002)(77096005)(102836003)(586003)(6116002)(66066001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0665; H:DM2PR09MB0665.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 18:57:48.0781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0665 Archived-At: Subject: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 18:57:52 -0000 We are scheduled for 2pm - 4pm CEST on Tuesday, July 19th. The chairs need= to pull together an agenda for this meeting. Here is an early draft to get= us started: 10 minutes: agenda, WG status The following drafts are near done. Are the authors able to give a short st= atus? 5 minutes: status of draft-ietf-ipsecme-ddos-protection-07 - Ready to send = to the IESG? 5 minutes: status of draft-ietf-ipsecme-rfc4307bis-09 - Ready for WGLC? 5 minutes: status of draft-ietf-ipsecme-safecurves-01 - Ready for WGLC? 20 minutes: discussion of draft-ietf-ipsecme-tcp-encaps-00 - Newly adopted.= More discussion needed? Ready for WGLC? 30 minutes: discussion of draft-fluhrer-qr-ikev2-01 - The adoption call on = draft-fluhrer-qr-ikev2-01 indicated strong interest in doing something in t= his space. We need to wrap up our adoption discussion and determine a path = forward for WG activities in this space. 20 minutes: charter text review - The chairs will send out revised charter = text before the meeting for review prior to discussion. This leaves 25 minutes extra. Are there any additional topics to discuss? E= SP? Yang? Others? Regards, Dave From nobody Thu Jul 7 12:09:26 2016 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 CE35012D863 for ; Thu, 7 Jul 2016 12:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] 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 hyQQAga_W79T for ; Thu, 7 Jul 2016 12:09:18 -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 A404E12D865 for ; Thu, 7 Jul 2016 12:09:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rlnGv33hZzCM3; Thu, 7 Jul 2016 21:09:11 +0200 (CEST) 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 pzJU7dz2KdsO; Thu, 7 Jul 2016 21:09:10 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 7 Jul 2016 21:09:10 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BCA4245C47E; Thu, 7 Jul 2016 15:09:09 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca BCA4245C47E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B532C415FC83; Thu, 7 Jul 2016 15:09:09 -0400 (EDT) Date: Thu, 7 Jul 2016 15:09:09 -0400 (EDT) From: Paul Wouters To: "Waltermire, David A. (Fed)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:09:22 -0000 On Thu, 7 Jul 2016, Waltermire, David A. (Fed) wrote: > > 10 minutes: agenda, WG status > > The following drafts are near done. Are the authors able to give a short status? > > 5 minutes: status of draft-ietf-ipsecme-ddos-protection-07 - Ready to send to the IESG? > 5 minutes: status of draft-ietf-ipsecme-rfc4307bis-09 - Ready for WGLC? > 5 minutes: status of draft-ietf-ipsecme-safecurves-01 - Ready for WGLC? > > 20 minutes: discussion of draft-ietf-ipsecme-tcp-encaps-00 - Newly adopted. More discussion needed? Ready for WGLC? > > 30 minutes: discussion of draft-fluhrer-qr-ikev2-01 - The adoption call on draft-fluhrer-qr-ikev2-01 indicated strong interest in doing something in this space. We need to wrap up our adoption discussion and determine a path forward for WG activities in this space. > > 20 minutes: charter text review - The chairs will send out revised charter text before the meeting for review prior to discussion. > > This leaves 25 minutes extra. Are there any additional topics to discuss? ESP? Yang? Others? There is draft-pauly-ipsecme-split-dns and draft-mglt-ipsecme-rfc7321bis as well we could briefly talk about. Paul From nobody Thu Jul 7 12:17:08 2016 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 CA76C12D7ED for ; Thu, 7 Jul 2016 12:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gkEVKxEdGG3 for ; Thu, 7 Jul 2016 12:17:06 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0107.outbound.protection.outlook.com [23.103.200.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D8E12D1CB for ; Thu, 7 Jul 2016 12:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=10J5w8T/jq2KnWBj+gAZCORLvXlY5a6jt8EjR5IAdhA=; b=GbLmM1GZp5gai+wSf+XT+cQD+sPEMKxubwRMjEovWDLk8zlsB6+VxMvNpg1VUyceQfvQzMSRRbTiLerlE1MUGG+5RXo4Tjpfe/wK9PxYEa3vBgKneHvaV6KSrc2PYYIBCBMlVGzmeiRvIkUwzaWvbka7HHMqWyBm/URXZJL19vw= Received: from DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) by DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) with Microsoft SMTP Server (TLS) id 15.1.534.14; Thu, 7 Jul 2016 19:17:05 +0000 Received: from DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) by DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) with mapi id 15.01.0534.020; Thu, 7 Jul 2016 19:17:05 +0000 From: "Waltermire, David A. (Fed)" To: "paul@nohats.ca" Thread-Topic: [IPsec] IETF 96 IPsecME Agenda Thread-Index: AdHYfKwEKhVveBgsTmOLLfgSuxW09wABl3yAAAA1utA= Date: Thu, 7 Jul 2016 19:17:04 +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=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: 2e0fc447-d56a-43df-7c9f-08d3a69b4832 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0665; 6:ZY2ubZnok+FposSV4WV+Y8t5Xw2fCcExgI5lnKFnVvgA1cPxq1UpoAWFPxlUbR7CAlcaHik9WD7lKa1DRS0pje03UJyWb1lSHUNCHnC/h6nKMifhyBjIqKB53ctMGfV6c/QHeQqfRBK1vCjuQsoFACODSSH4SuLz3VNMHE3E/yxzzsLska1dKa1jbgeRoCNdudSUv2na74lWmoLCKtKm44BS+Nh7bf4WmkAtkk9hs/XDW3YqYKZHoUG5q8o2YpMmoHVox0M8jmvmJMTuYs/9ox/f5jOEx10i0770t/w21bAXdW8Db3HO5vWgcafp2OHd4FZOqKZ6nQQUPZQ4qe/OPA==; 5:XL/t8l9smrFI1ATqe7Yn2th5w3kXdzMKgZggOBVLRtzSyZ31xcCl8RF3N5U5l5Iet2iFnG2mVYMLCn+wYTVrMnyT1b3lFQ/r9jK9IS3e791Mbdvqzje7k6s0D4JFMJcrkrjbSd5WU1Ic3Fgre9A9sg==; 24:gwriAW/qDs6g2ljWEJ+/ZKrfhnlEj5IzcgjV4XV8lnocFHE9/Lm3OJCbzWUgHldwjpHpb7iYPHhr/Cp/6dLmGxSoXz9Oh3yPlvIP9nkLW58=; 7:mWQeHgDF3dakFcDFDDdj2I7Dvl828W5vaio3UlIBh4kBNCCm1CUmXyl3YUwV2vYMbR17T1PGeTQklLUfVCqR+mWIS/0ryeA4I9zMX8wxQAkXXIL+zBVpsWtAVG+FdsQGNaypXAkBvJ9yAg3tGr8OTIBWdyUjnDGwjIIz8ymNW9FNXeR5JVzFXovE71worZFEjx/KSCn2HSw50C4f5zZRIpjG+kKiJGQLYCPpLdhSiyt2G2uWAbE09vrTBydejNfh x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0665; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0665; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0665; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(9686002)(4326007)(2906002)(10400500002)(76576001)(105586002)(33656002)(3280700002)(2900100001)(5640700001)(66066001)(3846002)(2501003)(2950100001)(92566002)(586003)(6116002)(102836003)(122556002)(77096005)(74316002)(189998001)(87936001)(110136002)(305945005)(101416001)(68736007)(8936002)(11100500001)(2351001)(86362001)(106356001)(3660700001)(81156014)(5002640100001)(81166006)(99286002)(50986999)(76176999)(54356999)(1730700003)(7736002)(5003600100003)(7846002)(97736004)(7696003)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0665; H:DM2PR09MB0665.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 19:17:04.7879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0665 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:17:08 -0000 Paul, > > This leaves 25 minutes extra. Are there any additional topics to discus= s? > ESP? Yang? Others? Are you or one of the other authors available to discuss these drafts? If s= o, how much time do you need? > There is draft-pauly-ipsecme-split-dns and draft-mglt-ipsecme-rfc7321bis = as > well we could briefly talk about. Thanks, Dave From nobody Thu Jul 7 12:23:27 2016 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 0677712D1DC for ; Thu, 7 Jul 2016 12:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426] 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 ZjIJITuJQAKm for ; Thu, 7 Jul 2016 12:23:23 -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 9B74712B068 for ; Thu, 7 Jul 2016 12:23:23 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rlnbG2TPnzCNC; Thu, 7 Jul 2016 21:23:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1467919402; bh=8u8MMNfsaCv2Ic5cmzHVB9MzZ1rwRBxVvErKhYfudMI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SCR1yye+wdb940Qdw0iwtTmUoK5sMqjxSdVuT5RwXJEz11GmpWiaeUm3yF1ywHawY Wh16RhDwTCNix+LajXoNBRQYLMNw2VqKDft6Rc3x9Jl+o7JDxNZSK9Fwe61op+bCgz i19UqcH6cLPzLYQaEpao2kh62dBcvQmEC8LZSvEs= 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 WZopPRTTSb-Z; Thu, 7 Jul 2016 21:23:21 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 7 Jul 2016 21:23:21 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8858245C47A; Thu, 7 Jul 2016 15:23:20 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 8858245C47A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 71DC0415FC87; Thu, 7 Jul 2016 15:23:20 -0400 (EDT) Date: Thu, 7 Jul 2016 15:23:20 -0400 (EDT) From: Paul Wouters To: "Waltermire, David A. (Fed)" , Daniel Migault , Tommy Pauly In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:23:25 -0000 On Thu, 7 Jul 2016, Waltermire, David A. (Fed) wrote: >>> This leaves 25 minutes extra. Are there any additional topics to discuss? >> ESP? Yang? Others? > > Are you or one of the other authors available to discuss these drafts? If so, how much time do you need? > >> There is draft-pauly-ipsecme-split-dns and draft-mglt-ipsecme-rfc7321bis as >> well we could briefly talk about. Yes. Tommy and I will be there and we can remind the WG about how useful our draft is for adoption, and I think Daniel is also there to talk about 7321bis which is pretty similar to 4307bis, but if he is not I can talk about it too. Paul From nobody Thu Jul 7 12:46:27 2016 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 81CCD12D119 for ; Thu, 7 Jul 2016 12:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOFL4HP2udzw for ; Thu, 7 Jul 2016 12:46:23 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A96512D58A for ; Thu, 7 Jul 2016 12:46:15 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n127so28535062wme.1 for ; Thu, 07 Jul 2016 12:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3c0IT8+mkRh2cCHoBrwQTWs7o3kGLdT+ndj2b4Okk/A=; b=QWeXKYNTvWS2fiCMsD3VQluNhlofEn0vKicDen1gCTxg12wGw1/WPyPejWWm3M3Ufu r3CIz0TO2tcgJV0JA6bf9ZE2nS8jTKt6yMB7uV86wKGvg9+bMhaPSrmLGnpjY9Ci4G1h sq3MR/cT74mGbz33YivlzoOVdWrPzuOEXmlMFsMRx0iKb2EcKpn4TtsUH3t1le3jcNYt EHMpr6QBNjpyMbBeWpUWLLJU/bUB+xNa+HZLkH1V8epjqT5hoD/mH8x275eORHnw7xR0 GnAMgha7KxpxDeMBK6ksdtCKwf64PGeV8uLww4KJLv2EgUpIxHos4yHecF211/0rbTW1 O5MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3c0IT8+mkRh2cCHoBrwQTWs7o3kGLdT+ndj2b4Okk/A=; b=C76CIPnkT+0PKSClk8b1/9Y1Y496Ti/f3l6k5UXVAGDRrYWNySYcxxCTNKlgwPjz70 5WmcPNuUkdthGqRLHrzsxeEaYHeWzgbXsZ4pb2N08zt6q2qRkHpXZC8H2O6sBpJKJ6XY nyWVl7/bVcja79gJgCBhMk5u5/LeCtsrfp+XdtS8W5jbWojqIL2Gsqh+m0ISAJDUP+9e 8auaR/zQA9E74rF0kKJqvBSVT9LgCX0cHkwhx60hRavMajY8t8SwGvYOp77rvESDQF0s HmYOTu7DT7oMd63THz9qmUVQSNUun5wVpUTljd54k5wVA63MqvetLHrZ3dlFNSmoiX3v hAVg== X-Gm-Message-State: ALyK8tK+chYbTVyKzEzKZX/ArTDhdrb8g5uMyDGDwJbA3r88qARUGa8zDY5UtKhCqa/ojw== X-Received: by 10.28.207.13 with SMTP id f13mr29030367wmg.53.1467920773568; Thu, 07 Jul 2016 12:46:13 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c74sm53359wme.1.2016.07.07.12.46.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 12:46:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Thu, 7 Jul 2016 22:46:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <74649517-AD27-465E-AA29-CF069F618CC9@gmail.com> References: To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:46:25 -0000 > On 7 Jul 2016, at 9:57 PM, Waltermire, David A. (Fed) = wrote: >=20 > We are scheduled for 2pm - 4pm CEST on Tuesday, July 19th. The chairs = need to pull together an agenda for this meeting. Here is an early draft = to get us started: >=20 > 10 minutes: agenda, WG status >=20 > The following drafts are near done. Are the authors able to give a = short status? >=20 > 5 minutes: status of draft-ietf-ipsecme-ddos-protection-07 - Ready to = send to the IESG? > 5 minutes: status of draft-ietf-ipsecme-rfc4307bis-09 - Ready for = WGLC? > 5 minutes: status of draft-ietf-ipsecme-safecurves-01 - Ready for = WGLC? I can give a short status for them, but I think either Tero or Paul = should give the status for rfc4307bis. > 20 minutes: discussion of draft-ietf-ipsecme-tcp-encaps-00 - Newly = adopted. More discussion needed? Ready for WGLC? >=20 > 30 minutes: discussion of draft-fluhrer-qr-ikev2-01 - The adoption = call on draft-fluhrer-qr-ikev2-01 indicated strong interest in doing = something in this space. We need to wrap up our adoption discussion and = determine a path forward for WG activities in this space. >=20 > 20 minutes: charter text review - The chairs will send out revised = charter text before the meeting for review prior to discussion. >=20 > This leaves 25 minutes extra. Are there any additional topics to = discuss? ESP? Yang? Others? I can talk about the EdDSA draft (draft-nir-ipsecme-eddsa).=20 Yoav From nobody Thu Jul 7 14:52:16 2016 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 EC04212D67F for ; Thu, 7 Jul 2016 14:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbIzPJeA1rwS for ; Thu, 7 Jul 2016 14:52:13 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F6E12D532 for ; Thu, 7 Jul 2016 14:52:12 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id k123so6775446wme.0 for ; Thu, 07 Jul 2016 14:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LUigfeWg3KJ2Qz08d8ScnQYwDzvnep1Gn+1oxmgUcEQ=; b=Sk3wj+a0+TYCWnmssjVl9Rl5AQXKcahamiKlOlEwOLtjBdtE+b1yZWWGVfcwp9qdGo 97Y/8KpOMfZA/TlSbP8PMii/9QppF83PsW4kwi6p0nce0mtzb38Mrh0dc0fxu0kYPfWq aCe5PMAquBJR7ejUFzMbSl7nDEqc7V0519kWlSxs1yrkcD+gLDQCCjmQR88+pCGHWoZo FUVDksVWk3+ZDpRK/9K6BJiQs+MXngRLu0o091PbM6dKcx2rgNziHZU00vJr63QT5rXx ViGe6lpOZRgACEg76BDTUh+IIHRQ1gENWu0VaXZBzVYxvtRxxolZ71BIvMcW7kje4IIS Bpaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LUigfeWg3KJ2Qz08d8ScnQYwDzvnep1Gn+1oxmgUcEQ=; b=TfXF28SFefzcXFzaxcsqNghYAWNv+mwHf5vIF3/cw0sEMD8SiK0e8qAvDxMK7xEQ+z E0SQNdJ1dzEVcYBUowiK1dhXkPM5fX4vYCh7DM5DgN195l7jQ3vh29QdN9JRlD/I9EBr XIlHtcDASkIVjL2Tf+wFELXHO3GJxuDY2tIZ5J7s5owx0ozw9EEZz2hIb14QOTyWXQsk NrQrzTi2KjuxGHPG8H7dTLbHy5UMu+2oomCrZaV1Al3uGFWI01WYtJqAdfZbyTTArtDK ksU6KxnTxpCrVeUoVJH1Vb9b10MdMYS310TWCbIfI1bRRzyahEqxnN4NGN+XBI0RQl3o tVkA== X-Gm-Message-State: ALyK8tIiRXGkqIg4oGG7eVph64ANuJrs0iJQVd8jcKLfGZ2Yz5NkA5coHqamun5iUxTQIWHZnve7j7s45YMbDA== X-Received: by 10.28.213.145 with SMTP id m139mr37279wmg.81.1467928331015; Thu, 07 Jul 2016 14:52:11 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.34.99 with HTTP; Thu, 7 Jul 2016 14:52:10 -0700 (PDT) In-Reply-To: <74649517-AD27-465E-AA29-CF069F618CC9@gmail.com> References: <74649517-AD27-465E-AA29-CF069F618CC9@gmail.com> From: Daniel Migault Date: Thu, 7 Jul 2016 17:52:10 -0400 X-Google-Sender-Auth: E5-STHo_duAwKptmWVp_r5V1N0M Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11469c16b9da91053712b2f7 Archived-At: Cc: IPsecME WG , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 21:52:15 -0000 --001a11469c16b9da91053712b2f7 Content-Type: text/plain; charset=UTF-8 Please also add:draft-mglt-ipsecme-implicit-iv. I (or Yoav) can also present about draft-mglt-ipsecme-implicit-iv. In addition draft-mglt-ipsecme-rfc7321bis can be presented by either of the co-authors (Tero, Yoav, Paul or me). BR, Daniel On Thu, Jul 7, 2016 at 3:46 PM, Yoav Nir wrote: > > > On 7 Jul 2016, at 9:57 PM, Waltermire, David A. (Fed) < > david.waltermire@nist.gov> wrote: > > > > We are scheduled for 2pm - 4pm CEST on Tuesday, July 19th. The chairs > need to pull together an agenda for this meeting. Here is an early draft to > get us started: > > > > 10 minutes: agenda, WG status > > > > The following drafts are near done. Are the authors able to give a short > status? > > > > 5 minutes: status of draft-ietf-ipsecme-ddos-protection-07 - Ready to > send to the IESG? > > 5 minutes: status of draft-ietf-ipsecme-rfc4307bis-09 - Ready for WGLC? > > 5 minutes: status of draft-ietf-ipsecme-safecurves-01 - Ready for WGLC? > > I can give a short status for them, but I think either Tero or Paul should > give the status for rfc4307bis. > > > 20 minutes: discussion of draft-ietf-ipsecme-tcp-encaps-00 - Newly > adopted. More discussion needed? Ready for WGLC? > > > > 30 minutes: discussion of draft-fluhrer-qr-ikev2-01 - The adoption call > on draft-fluhrer-qr-ikev2-01 indicated strong interest in doing something > in this space. We need to wrap up our adoption discussion and determine a > path forward for WG activities in this space. > > > > 20 minutes: charter text review - The chairs will send out revised > charter text before the meeting for review prior to discussion. > > > > This leaves 25 minutes extra. Are there any additional topics to > discuss? ESP? Yang? Others? > > I can talk about the EdDSA draft (draft-nir-ipsecme-eddsa). > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a11469c16b9da91053712b2f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In addition draft-mgl= t-ipsecme-rfc7321bis can be presented by either of the co-authors (Tero, Yo= av, Paul or me).

BR,
Daniel

On T= hu, Jul 7, 2016 at 3:46 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

> On 7 Jul 2016, at 9:57 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote: >
> We are scheduled for 2pm - 4pm CEST on Tuesday, July 19th.=C2=A0 The c= hairs need to pull together an agenda for this meeting. Here is an early dr= aft to get us started:
>
> 10 minutes: agenda, WG status
>
> The following drafts are near done. Are the authors able to give a sho= rt status?
>
> 5 minutes: status of draft-ietf-ipsecme-ddos-protection-07 - Ready to = send to the IESG?
> 5 minutes: status of draft-ietf-ipsecme-rfc4307bis-09 - Ready for WGLC= ?
> 5 minutes: status of draft-ietf-ipsecme-safecurves-01 - Ready for WGLC= ?

I can give a short status for them, but I think either Tero or Paul = should give the status for rfc4307bis.

> 20 minutes: discussion of draft-ietf-ipsecme-tcp-encaps-00 - Newly ado= pted. More discussion needed? Ready for WGLC?
>
> 30 minutes: discussion of draft-fluhrer-qr-ikev2-01 - The adoption cal= l on draft-fluhrer-qr-ikev2-01 indicated strong interest in doing something= in this space. We need to wrap up our adoption discussion and determine a = path forward for WG activities in this space.
>
> 20 minutes: charter text review - The chairs will send out revised cha= rter text before the meeting for review prior to discussion.
>
> This leaves 25 minutes extra. Are there any additional topics to discu= ss? ESP? Yang? Others?

I can talk about the EdDSA draft (draft-nir-ipsecme-eddsa).

Yoav

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

--001a11469c16b9da91053712b2f7-- From nobody Thu Jul 7 15:18:11 2016 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 9BCE312D635 for ; Thu, 7 Jul 2016 15:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 zB8N5DYmAYrV for ; Thu, 7 Jul 2016 15:18:08 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D72612D0AE for ; Thu, 7 Jul 2016 15:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1467929888; x=2331843488; 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=QIWb262Aeb9f4os+awlyy4Wsh6wsa3EvHqsyfahgS2k=; b=Y5UPX38v+HTYyduAc5o/OZCfxORK07P68x5PVwTXjCfldYTyMZUuZn/NPSy4QgtU K5rezZVrYpEX1d4lF4Jw4wfW3hJ/Xf3XyRARpaWFL/xyZpt2kSx53w86SesKPa7W o9lChGbqkgeZC/0dYI37g/M6jz/DIzL5MtW96Jzti5JIa4c1X766d26LX3tvCioP j3dQTFJLBmoSlDstkGfsPA07rHuJr4eNb7b6pRfxnAxxi0XoLXyYLE7SKhr524Yd oHGsYWJMS9eLKWeKgOdXguReeCHYtoKhfwQKXVeCOZVT5t1O0cZZPAfv9VkHfLKd 0llhgvkcMeIjtEHB1HtdHA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id F0.8A.10360.025DE775; Thu, 7 Jul 2016 15:18:08 -0700 (PDT) X-AuditID: 11973e11-f79e76d000002878-e4-577ed520ed29 Received: from nwk-mmpp-sz06.apple.com (nwk-mmpp-sz06.apple.com [17.128.115.234]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 6C.10.22020.025DE775; Thu, 7 Jul 2016 15:18:08 -0700 (PDT) Received: from [17.153.41.136] (unknown [17.153.41.136]) by nwk-mmpp-sz06.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O9Y00MFITY7E000@nwk-mmpp-sz06.apple.com> for ipsec@ietf.org; Thu, 07 Jul 2016 15:18:07 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3195\)) From: Tommy Pauly In-reply-to: Date: Thu, 07 Jul 2016 15:18:07 -0700 Content-transfer-encoding: quoted-printable Message-id: <2EE8C4D6-1A6C-4875-8298-EC62E58CED26@apple.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3195) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYoatwtS7cYN4vXov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48mOyawFCzkqHrQtZGtgPM3WxcjJISFgIrHr1yVWCFtM4sK9 9UBxLg4hgb2MEhOOtjLBFP3//xasQUhgOZPEgb8sEEXzmCQ2XmgGSnBwCAtISGzekwhSwyyg JbF+53EmkDCvgL7E7J9mIGFhAW2JGRuOgO1iE1CROP5tAzOIzSngKNH97AuYzSKgKvGv+Tsr yHhmgU5GiTWd/1khZmpLPHl3AczmFbCRWHLnARPEDfOZJCbtOAjWLSKgKDHpzCMWiKNlJeb+ ecMIUiQhsIRNYvm7L0wTGEVmITlwFsKBs5DsWMDIvIpRKDcxM0c3M89IL7GgICdVLzk/dxMj KLyn2wnuYDy+yuoQowAHoxIP74Kc2nAh1sSy4srcQ4zSHCxK4rx5u+vChQTSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTCmcrV2HbjMbDxRYHvGFKm9Vxv7NQ/PD+oKVunRSn0vdfbQ/P/8Clrb GvVzlqT2f95/k88jju1TWsG0hveHG1ZMerOM5fClmESe+wKhXnXF4pmsIZYcNluDDp/1faSl PVkzmTU/sjbCjNF//UJpE+PwOxz//dwPOH02POYQ7m0f9kjvV1jndCWW4oxEQy3mouJEAMA4 dCxQAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FD8Slfhal24wdOZXBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpMdk1kLFnJUPGhbyNbAeJqti5GTQ0LAROL//7dQtpjEhXvr wWwhgeVMEgf+snQxcgHZ85gkNl5oBkpwcAgLSEhs3pMIUsMsoCWxfudxJpAwr4C+xOyfZiBh YQFtiRkbjrCC2GwCKhLHv21gBrE5BRwlup99AbNZBFQl/jV/ZwUZzyzQySixpvM/K8RMbYkn 7y6A2bwCNhJL7jxggrhhPpPEpB0HwbpFBBQlJp15xAJxtKzE3D9vGCcwCs5CctMshJtmIRm7 gJF5FaNAUWpOYqWpXmJBQU6qXnJ+7iZGcDgWRuxg/L/M6hCjAAejEg/vgpzacCHWxLLiytxD jBIczEoivDkX68KFeFMSK6tSi/Lji0pzUosPMSYDfTORWUo0OR8YK3kl8YYmJgYmxsZmxsbm JuakCSuJ8746CbRCID2xJDU7NbUgtQhmCxMHp1QDY4uiwHqp4KI2VZ17V8/dnNWcfjq08PHx 0+xX2LVkN546PtNFIVWkSUNP9fiDYv2redt6uErd7R+xcsdxWYv23Pg78UjO2YP/z0o81wiT PpDJlbperO/Kw+yd51mTXl7b8vx0sdufZee3PPimmzf9lOj6E9wviuKXmhga6R928BaeJitV 5aFbp8RSnJFoqMVcVJwIAEAstdqLAgAA Archived-At: Cc: IPsecME WG , Daniel Migault , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 22:18:10 -0000 > On Jul 7, 2016, at 12:23 PM, Paul Wouters wrote: >=20 > On Thu, 7 Jul 2016, Waltermire, David A. (Fed) wrote: >=20 >>>> This leaves 25 minutes extra. Are there any additional topics to = discuss? >>> ESP? Yang? Others? >>=20 >> Are you or one of the other authors available to discuss these = drafts? If so, how much time do you need? >>=20 >>> There is draft-pauly-ipsecme-split-dns and = draft-mglt-ipsecme-rfc7321bis as >>> well we could briefly talk about. >=20 > Yes. Tommy and I will be there and we can remind the WG about how = useful > our draft is for adoption, and I think Daniel is also there to talk > about 7321bis which is pretty similar to 4307bis, but if he is not I > can talk about it too. I agree that we should have a short discussion around = draft-pauly-ipsecme-split-dns, and I will be there to talk about it. Thanks, Tommy >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jul 7 17:04:04 2016 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 954AD12D125; Thu, 7 Jul 2016 17:03:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708000358.18749.70897.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 17:03:58 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 00:03:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : TCP Encapsulation of IKE and IPSec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-01.txt Pages : 20 Date : 2016-07-07 Abstract: This document describes a method to transport IKE and IPSec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending all packets for tunnel establishment as well as tunneled packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-01 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 Jul 8 07:43:50 2016 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 0DC9A12B063 for ; Fri, 8 Jul 2016 07:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzfH9H6Ho_46 for ; Fri, 8 Jul 2016 07:43:46 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (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 B643912B02D for ; Fri, 8 Jul 2016 07:43:46 -0700 (PDT) Received: by mail-pa0-x243.google.com with SMTP id ts6so7581430pac.0 for ; Fri, 08 Jul 2016 07:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Z2Tv5fQzcdxIK+nZ61q9B+JDIO2NzFG1Y7Sa+5krJ2M=; b=J4l6e4Xnu3uirZX2sVcXRefrUbWPjnic1IDb/zgCH/lZtWNvGfi7tuHYUVvwcNcle5 CYqeTS02fFXnazddKa+L/TKgBrL/UxwKJZ5uhvaq2tykd+xGvyFlrluZ2F1GJgtWEsjq zRm739z1kSW/LY9OBfxNNlfGnhV2A3HXC8d06bU/CvzTVDnkFj2A7WYgIm1GB/uRyY5C XeNV0NZsGchPBmZe60nLxHQ2exNELjnBMFoC29H30thLgz0qss8Fjeb3FofyzKeA7ROg qRxEmq82KnWtLWq196AYpI5qXGdfyWOxzJlwhpaAMFCRYc7hnh0GmBvn2PiMkt5a44IS 3q5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Z2Tv5fQzcdxIK+nZ61q9B+JDIO2NzFG1Y7Sa+5krJ2M=; b=hDSx5Qmp+baTQ5JzQs2BrHdIBk9QXaaT+I8WHaw5kFs43+e0CEW0QnZCb8QyoeHzKo KRI0q/GzODaMCWRIby64TxqjacndThetaiavjMq5e53D70whGk3ObBNiZ1YkRBRLtTUm ACTO5xnGYW2+xHFKIPfxw/BIsEc1+N1ABm+ZZDiHbxCWV/5E0AiJ7rncMqoQVbDh5DVT uy01PebsEYk/i7XuAdSwmMcoqZxjiNjLSRuPki3LJ7+vNUjjiS/JeXaPEP909RWwQq0S bO4ao45+KbMTSlAt0YRXzK/OLnhDOSkuy7xOYNXEzkeoOe/hRWMNYfvCfK+gpFsz9fUj PTLA== X-Gm-Message-State: ALyK8tJ9+FFk8XQdqJak5QIEj+JrZ/B8PjP7ecji3nnQKBM9ChY5Qhj5nKHrb402et+XOCGRbeiRMpyFKvM4BA== X-Received: by 10.194.173.230 with SMTP id bn6mr5618500wjc.8.1467989026303; Fri, 08 Jul 2016 07:43:46 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.143.101 with HTTP; Fri, 8 Jul 2016 07:43:45 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Fri, 8 Jul 2016 10:43:45 -0400 X-Google-Sender-Auth: l5zeYseKvMY-QO-FvB9sATmQKIE Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=089e0122f4ac727552053720d4a8 Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Chairs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:43:49 -0000 --089e0122f4ac727552053720d4a8 Content-Type: text/plain; charset=UTF-8 Thanks Paul David and Tero for serving ipsecme WG ! On Tue, May 31, 2016 at 11:14 AM, Paul Wouters wrote: > On Tue, 31 May 2016, Kathleen Moriarty wrote: > > I'd like to thank Paul for his many years chairing IPSecMe! We look >> forward to your continued participation. >> >> Tero Kivinen has volunteered to co-chair the working group and still >> be active as a individual as not to impact the working group. >> > > Thanks to PaulH for his many years as chair. And thanks for Tero to > filling in the gap! > > Looking forward to David and Tero putting some documents into working > group adoption calls :) > > Paul > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --089e0122f4ac727552053720d4a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Paul David and Tero for serving ipsecme WG !
<= div class=3D"gmail_extra">
On Tue, May 31, 20= 16 at 11:14 AM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 31 May 2016, Kathleen Mori= arty wrote:

I'd like to thank Paul for his many years chairing IPSecMe!=C2=A0 We lo= ok
forward to your continued participation.

Tero Kivinen has volunteered to co-chair the working group and still
be active as a individual as not to impact the working group.

 Thanks to PaulH for his many years as chair. And thanks for Tero to
filling in the gap!

Looking forward to David and Tero putting some documents into working
group adoption calls :)

Paul


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

--089e0122f4ac727552053720d4a8-- From nobody Fri Jul 8 07:52:34 2016 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 C671B12D59D for ; Fri, 8 Jul 2016 07:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCfhaz_5PH4Q for ; Fri, 8 Jul 2016 07:52:26 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C832312D1A1 for ; Fri, 8 Jul 2016 07:52:25 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id x83so6910453wma.3 for ; Fri, 08 Jul 2016 07:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zs15bGU4gShrVaVE0M2+IhLwfcCalH9WyeEgxFd963k=; b=DFacpVq000ITatqQ9GEx6sdj7+3B3tX0xQ8fOC0SI07DeizjemSVqfc1DnYaHJ6qtv gcbxAY1Lu0zJhV5Z2TQJq9o11bu8FHYpPFy2dcIVhc7iD7yShuFzNpjX74n3Tz/6oMKg jvZ7frbC3unD2USQqnMDKVvAZiaQ+Hf0SD5gVW55UUHZU4s3o3PJaApWGA6LWt0HSMYr KvHETn37kAQuJlcXZ8olZhRq/Lz/NlAy/ZsTOxHHvi0DHyAK70t/nVIyuQa+TlFThE3/ z+inG1kn4tN1Z9FAYBnRfpN71BwHR1ww4ip6rpb/+am/MN+RrQ45/V5Ytuo1FVRInhPH wkeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zs15bGU4gShrVaVE0M2+IhLwfcCalH9WyeEgxFd963k=; b=SfiWxfcpjt/E15NUJ+WI9IMXHJJTD9Tj3WnGIfM6twty3GX4vLZNthD4Qp0wr4Zu1X qG/cja+lj/dEwi1Oe67/nHYWY7OS6y/WqFCCMzJP4XW5byLvb57j31eL1Lcdko8td2Sn 1P1Ib/KchiC/XOoOEhf0r/qEztFejRAOA/uNmMcwmbG6RFeEbwVpYLoPZOWWCpVOQ+qA 9XJdhvXq0Z2ACO7b7D0CIFg0eX1oaoADteIe7WzLHuXln7Oi8BXRwl8yIlw3aPMsjAEu BPC9eo9ckbt49tKcRj8BSKXRwXH4hLVnounQkhZyx7RNYzKD4Dn0QkwIqURDjGhx38MM 55Vw== X-Gm-Message-State: ALyK8tLU8lN/EobUYQG1iSLllFwhuZhm8X5SYOFl8HoIDOOxb5Hy0n88ZaO+Y6/3khZuVBmgIV3HW48C6k1DdA== X-Received: by 10.194.173.230 with SMTP id bn6mr5653328wjc.8.1467989544338; Fri, 08 Jul 2016 07:52:24 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.143.101 with HTTP; Fri, 8 Jul 2016 07:52:23 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Fri, 8 Jul 2016 10:52:23 -0400 X-Google-Sender-Auth: 4TGz9w3E9VP-sfVcuZpKCbBA9bE Message-ID: To: "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary=089e0122f4ac5313f1053720f3a2 Archived-At: Cc: IPsecME WG , "paul@nohats.ca" Subject: Re: [IPsec] IETF 96 IPsecME Agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:52:33 -0000 --089e0122f4ac5313f1053720f3a2 Content-Type: text/plain; charset=UTF-8 Hi David, We should be presenting Diet-ESP in 6lo and mostly presenting the use cases, so we might also willing to have a short update on Diet-ESP in ipsecme. I could also do that shortly in Berlin. Yang model drafts have not been updated since BA, so I do not think we are ready yet to present it in Berlin. BR, Daniel On Thu, Jul 7, 2016 at 3:17 PM, Waltermire, David A. (Fed) < david.waltermire@nist.gov> wrote: > Paul, > > > > This leaves 25 minutes extra. Are there any additional topics to > discuss? > > ESP? Yang? Others? > > Are you or one of the other authors available to discuss these drafts? If > so, how much time do you need? > > > There is draft-pauly-ipsecme-split-dns and draft-mglt-ipsecme-rfc7321bis > as > > well we could briefly talk about. > > Thanks, > Dave > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --089e0122f4ac5313f1053720f3a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,

We should be presen= ting Diet-ESP in 6lo and mostly presenting the use cases, so we might also = willing to have a short update on
Diet-ESP in ipsecme. I could also do = that shortly in Berlin.

Yang model drafts have not been u= pdated since BA, so I do not think we are ready yet to present it in Berlin= .

BR,
Daniel

On Thu, Jul 7, 2016 at 3:17 PM, Walt= ermire, David A. (Fed) <david.waltermire@nist.gov> w= rote:
Paul,

> > This leaves 25 minutes extra. Are there any additional topics to = discuss?
> ESP? Yang? Others?

Are you or one of the other authors available to discuss these draft= s? If so, how much time do you need?

> There is draft-pauly-ipsecme-split-dns and draft-mglt-ipsecme-rfc7321b= is as
> well we could briefly talk about.

Thanks,
Dave

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

--089e0122f4ac5313f1053720f3a2-- From nobody Fri Jul 8 07:56:14 2016 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 0D71212D1A1 for ; Fri, 8 Jul 2016 07:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-_FxWfJvOno for ; Fri, 8 Jul 2016 07:56:08 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (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 C8F8D12D793 for ; Fri, 8 Jul 2016 07:56:03 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id ts6so7711208pac.0 for ; Fri, 08 Jul 2016 07:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qLNAUZ5R2PH1ZyjVK5oZtG7Kkv4QL2VyQgV/JdmNMRU=; b=eYG3ZONaHGFZrdIersCg9vlt1eW8E+LvW8I51VI39PZRU0EXas64V5qvxVEx/NMcyF TAZroWuwUvymz1LaqTt1d/cF7KNCwzd/6QNIbxlYYNcFdIRUAqyu4D2UtYN2oPa8e3Ws WwC2BDM6+2Alb76uZJRwAWETZ39Z20f4WpvHQXblZy3TZZE47oauCvD+E7IGNq++L8le uN/7HVdfkQ6clRCTmjPH2OKWmwue8T9+6MNs/6alwDeQdBLhRM6++jewxr35YStWOKE2 pT1RF9HeEDjYtQdSYOj5VHZ8eDIrb94yLMYUWWlBqBnttIPidcO0A7OkKBf9S8886gpc GeTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qLNAUZ5R2PH1ZyjVK5oZtG7Kkv4QL2VyQgV/JdmNMRU=; b=G97sVVpqhBsxF6wiw/5ZRe0s/jr8ru2V3RrVSQAVyV8/6b2jPa1bV8ndVHZUhRNM/5 59s3HWoh+Wv4bMlTLSL5Axv+X7Cu8cxGYGWI8gYbka3UXg5RStlxMn1qfZkTmhCraeBx qKiVohHGehP31nXHZXQLAByCT3s93sXvCFawAQGoOgbtTyxRYRuTi/2G1cvSVw6MyS/M r7oTKGx2YIqsGwvGQbn3cVVqFcnwJHCjI8znKrO/1MebuzK9GGdQHg1C8dgsDdPDynB5 X58ZqTxekLjzdMqk1Oenlnaz/EWs/Jm+5J9e5FM3jLVrrDFgDDjobnUeIatcMiDQYg/a hq8g== X-Gm-Message-State: ALyK8tLgV2aPjUKzfggZV3eU2TIN5YEH1JVTh1zo7NMwMpL2dSZlzysO+jdSwUm+k40jIhiPdU0kNH/iKTah0g== X-Received: by 10.194.173.230 with SMTP id bn6mr5668358wjc.8.1467989763400; Fri, 08 Jul 2016 07:56:03 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.143.101 with HTTP; Fri, 8 Jul 2016 07:56:02 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Fri, 8 Jul 2016 10:56:02 -0400 X-Google-Sender-Auth: s3hI9XVnuksdh5y7m_kbA8D_4LM Message-ID: To: Samy Touati Content-Type: multipart/alternative; boundary=089e0122f4ac61ad310537210004 Archived-At: Cc: "ipsec@ietf.org WG" , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:56:11 -0000 --089e0122f4ac61ad310537210004 Content-Type: text/plain; charset=UTF-8 Apology for the late support, - but I already mentioned my support for the draft adoption. I will review the document. BR, Daniel On Mon, Jun 6, 2016 at 11:03 PM, Samy Touati wrote: > Hi, > > I do support the adoption of this draft by the WG. > Ericsson is implementing the IPSEC TCP encapsulation as described in this > draft in the Wireless Mobile Gateway (WMG) node. > We would like to engage with device vendors for conducting > interoperability testing. > > Thanks > Samy. > > On 6/6/16, 10:37 PM, "IPsec on behalf of Ravi Shankar Mantha (ramantha)" < > ipsec-bounces@ietf.org on behalf of ramantha@cisco.com> wrote: > > >I am in favour of this adoption. We are planning to implement this draft > >in cisco mobility gateway products. > >We also want to work with other mobile device implementation for > >interoperability. > > > >Thanks, > >Ravi Mantha > > > > > > > >> > >>On 05/06/2016 17:02, "IPsec on behalf of Waltermire, David A. (Fed)" > >> wrote: > >> > >>>This is the official call for adoption of > >>>https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an > >>>IPSecME working group (WG) document. > >>> > >>>By adopting this draft the WG is agreeing to take this on as an official > >>>WG item to continue work on the draft. Please reply with any comments > >>>supporting or concerns against adopting to the mailing list. This call > >>>will run until Friday, June 17th UTC 23:59. > >>> > >>>Thanks, > >>>Dave and Tero > > > >_______________________________________________ > >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 > > --089e0122f4ac61ad310537210004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apology for the late support, - but I already me= ntioned my support for the draft adoption. I will review the document.
<= br>
BR,
Daniel

On Mon, Jun 6, 2016 at 11:03 PM, Samy Touati <samy.touati@ericsson.com> wrote:
Hi,

I do support the adoption of this draft by the WG.
Ericsson is implementing the IPSEC TCP encapsulation as described in this d= raft in the Wireless Mobile Gateway (WMG) node.
We would like to engage with device vendors for conducting interoperability= testing.

Thanks
Samy.

On 6/6/16, 10:37 PM, "IPsec on behalf of Ravi Shankar Mantha (ramantha= )" <ipsec-bounces@ietf.or= g on behalf of ramantha@cisco.com= > wrote:

>I am in favour of this adoption. We are planning to implement this draf= t
>in cisco mobility gateway products.
>We also want to work with other mobile device implementation for
>interoperability.
>
>Thanks,
>Ravi Mantha
>
>
>
>>
>>On 05/06/2016 17:02, "IPsec on behalf of Waltermire, David A. = (Fed)"
>><ipsec-bounces@ietf.or= g on behalf of david.walte= rmire@nist.gov> wrote:
>>
>>>This is the official call for adoption of
>>>https://datatracker.ietf= .org/doc/draft-pauly-ipsecme-tcp-encaps/ as an
>>>IPSecME working group (WG) document.
>>>
>>>By adopting this draft the WG is agreeing to take this on as an= official
>>>WG item to continue work on the draft. Please reply with any co= mments
>>>supporting or concerns against adopting to the mailing list. Th= is call
>>>will run until Friday, June 17th UTC 23:59.
>>>
>>>Thanks,
>>>Dave and Tero
>
>_______________________________________________
>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


--089e0122f4ac61ad310537210004-- From nobody Fri Jul 8 14:58:21 2016 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 E5D1012D630; Fri, 8 Jul 2016 14:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 b3VfRfUOp6WF; Fri, 8 Jul 2016 14:58:00 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 8637E12D8A6; Fri, 8 Jul 2016 14:58:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 619AE3DDA; Fri, 8 Jul 2016 23:57:59 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6LwrTJI80Dlk; Fri, 8 Jul 2016 23:57:59 +0200 (CEST) Received: from [192.168.1.38] (109.red-83-42-242.dynamicip.rima-tde.net [83.42.242.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id CD76C242A; Fri, 8 Jul 2016 23:57:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <20160630162615.GA32734@oracle.com> Date: Fri, 8 Jul 2016 23:57:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> <20160630162615.GA32734@oracle.com> To: Sowmini Varadhan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , Gabriel Lopez , Linda Dunbar , "IPsec@ietf.org" , Rafa Marin Lopez , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:58:06 -0000 Hi Sowmini: Also sorry for the delay, Gabi and I have been preparing the revised = I-D.=20 = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-00 We hope it clarifies some of your questions. In any case, please see inline my comments. > El 30 jun 2016, a las 18:26, Sowmini Varadhan = escribi=C3=B3: >=20 >=20 >=20 > Hi, sorry for the delay in response, needed some time to go over > the draft carefully. Here are some comments. >=20 >> 1. Introduction > : >> .. In this sense, it will provision the required >> parameters to create valid entries in the Security Association >> Database (SAD), which we assumed to be in the data plane. =20 >=20 > That definition was a bit unusual (at least from a network-stack = perspective) > and threw me off. The SAD is security assoction database, thus it is = not > "data plane" as such, but rather, a database configured by the > control-plane that is looked up by the network stack's dataplane. > (In the same way, the SPD is also just a security policy database, > so the decision to call one "control plane", while the other as "data = plane" > is also quite confusing). [Rafa] To avoid any confusion we have removed the part of =E2=80=9Cdata = plane=E2=80=9D and "control plane=E2=80=9D. We have just explained two = cases: Case 1: IKE/IPsec in the NSF Case 2: IPsec (no IKE) in the NSF >=20 >> Therefore, >> the data plane will have only support for IPsec while SPD and IKE >> functionality is moved to the control plane. In both cases, to = carry >> out this provisioning, an interface/protocol will be required = between >> the SDN controller and the data plane to send: the policies to be >=20 > Again, perhaps my notion of "data plane" does not match the intention, > but the SDN controller has to interface with the control=20 > plane (i.e, the IKE implementation in the network resource) in case 1.=20= [Rafa] As mentioned, we think that removing the concept of =E2=80=9Cdata = plane=E2=80=9D and =E2=80=9Ccontrol plane=E2=80=9D and focusing on the = cases make things clearer. >=20 > Seems to me like case-1 vs case-2 is basically a split-IKE > model (where IKE is split between the network-resource and the = controller) > and a model where the network resource implements IPsec only, with > IKE exclusively managed by the controller. [Rafa] Not really. IPsec stack is always in the NSF. As you may know, = according to RFC 4301, there are three IPsec databases that needs to be = handled: SPD, SAD and PAD.=20 Additionally IKE is just the default automated key management protocol. = But IPsec architecture allows other key management protocols. SDN-based = key management is a possibility as we show in our I-D. >=20 >> 5. Case 1: IKE/IPsec in the network resource > : >> Advantages: It is simple since network resources typically have and >> IKE/IPsec implementations. >>=20 >> Disadvantages: 1) IKE implementations needs to renegotiate IPsec = SAs >> upon SPD entries changes without restarting IKE daemon. 2) Data = plane >> more complex. >=20 > How does the data-plane become any more complex than a non-SDN env > where there would be no controller? The only change introduced > by the controller is that the IKE/IPsec SAs and policies are now > orchestrated via the controller. [Rafa] In this case, we were referring to the fact that the gateway does = not need to deploy an IKE implementation. This has been stated in the = next version of the I-D. >=20 > I do agree that this results in a split-IKE model, which may > need to be thought through. >=20 >=20 >> 6. Case 2: IKE and SPD in the SDN Controller > : >> Advantages: 1) There is clear separation of data plane (IPsec >> protection per flow) and control plane (IKE and SPD policies). >> Hence, it allows less complex data planes. 2) IKE does not need to = be >> run in gateway-to-gateway scenario with a single controller (see >> Section 8.1). >=20 > Moving IKE into the controller will result in a fairly complex=20 > controller implementation, making the control plane extremely complex > (we need to now worry about interop, compat with config options > supported by existing IKE impelementations etc) [Rafa] We understand that the current text may lead to some confusion. = Actually, IKE may not be implemented in the controller at all. Do we = really need to implement IKE in the controller when we have only one = controller and the gateways have only the IPsec stack? We don=E2=80=99t = think so. The controller just needs to perform key management and = distribute key material and information to fill the SPD SAD and PAD. And = PAD may not even be required when IKE is not in the NSF. We hope this has been clarified in the new version of the I-D. >=20 > Section 8.1 underlines this somewhat- essentially the controller is = now > doing everything that a standard IKE implementation would do. Trying > to get this to work with a stock TCP/IP stack implmentation would be > quite complex (whereas stock TCP/IP stack implementations already=20 > deal correctly with stock IPsec/IKE implementations). [Rafa] I guess you were referring to section 8.2 because in section 8.1 = there is no need to have an IKE implementation in the controller. As = mentioned, the controller would do just key management, which we believe = is not a very demanding task after all (not more than other tasks that = the security controller has to do). Even in section 8.2, IKE is = considered as potential east/west interface. But, of course, that needs = to be discussed. >=20 > There may also be other complications, if the IKE-enabled-controller > has to negotiate IKE on behalf of some other entity (network resource) > with a peer that thinks it is negotiating iwth the network-resource > itself. I dont know if the current IKE specs would have some issues > with that. [Rafa] This what you describe is more related with OLD section 8.3 (OLD = Figure 10) and I agree. In fact, we already had this discussion = internally with the old version of the I-D. This definitely needs = further analysis. In fact, I personally prefer option in Figure 9 for = section 8.3 We would like to really thank your comments. We think the new version of = the I-D provides a clearer view of our design, more evolved where some = of your questions raised here may find an answer. In any case, please = let us know what you think now. Best Regards. >=20 > --Sowmini >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Mon Jul 11 04:13:39 2016 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 C7B6A12B04D; Mon, 11 Jul 2016 04:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uw8IxhPJ_EXj; Mon, 11 Jul 2016 04:13:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 4D9E1127078; Mon, 11 Jul 2016 04:13:36 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6BBDSTT017271 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Jul 2016 11:13:28 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u6BBDR6p019484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 11:13:27 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u6BBDNYJ013661; Mon, 11 Jul 2016 11:13:25 GMT Received: from oracle.com (/10.175.165.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Jul 2016 04:13:23 -0700 Date: Mon, 11 Jul 2016 07:13:17 -0400 From: Sowmini Varadhan To: Rafa Marin Lopez Message-ID: <20160711111317.GA5361@oracle.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> <20160630162615.GA32734@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Gabriel Lopez , Sowmini Varadhan , Linda Dunbar Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 11:13:38 -0000 On (07/08/16 23:57), Rafa Marin Lopez wrote: > We would like to really thank your comments. We think the new version > of the I-D provides a clearer view of our design, more evolved where > some of your questions raised here may find an answer. In any case, > please let us know what you think now. Hi, I took a look at this doc, some comments: > 1. Introduction : > policies and SAs to handle is high. With the grow of SDN-based nit s/grow/growth > 1) The network resource (or Network Security Function, NSF) > implements the Internet Key Exchange (IKE) protocol and the IPsec > databases: the Security Policy Database (SPD), the Security > Association Database (SAD) and the Peer Authorization Database > (PAD). The controller is in charge of provisioning the NSF with > the required information about IKE, the SPD and the PAD. > > 2) The NSF only implements the IPsec databases (no IKE > implementation). The controller will provide the required > parameters to create valid entries in the PAD, the SPD and the > SAD in the NSF. Therefore, the NSF will have only support for > IPsec while automated key management functionality is moved to > the controller. I found the above description a bit confusing - in both cases, the sad, spd, pad have to be in the NSF, whereas the real distinction between the 2 cases is based on whether IKE is implemented in the NSF or in the controller. It might help to make that clearer. : > 5. Case 1: IKE/IPsec in the NSF : > Disadvantages: IKE implementations need to renegotiate IPsec SAs upon > SPD entries changes without restarting IKE daemon. but you would need to deal with this even if IKE was implemented in the controller, right? > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPsec Management/Orchestration Application| Client or > | I2NSF Client | App Gateway > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Client Facing Interface > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Vendor | Application Support | > Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security > Interface | IKE Credential and SPD Policies Distribution| Controller > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NSF Facing Interface > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | I2NSF Agent | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network > | IKE | IPsec(SPD,SAD,PAD) | Security > +-------------------------------------------- + Function (NSF) > | Data Protection and Forwarding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > One question about the block diagram above (and also applies to Case 2)- will the "Security Controller" and NSF both use the same src IP address for the purposes of IKE negotiation? > 5.1. Requirements : > o A southbound protocol MUST support sending these SPD and PAD > entries, and IKE credentials to the NSF. I think the intentended northbound direction here is from the controller to the NSF, might help to make that clear. > o It requires an (northbound) application interface in the security > controller allowing the management of IPsec SAs. > > o In scenarios where multiple controllers are implicated, SDN-based > flow protection service may require a mechanism to discover which > security controller is managing a specific NSF. > Multiple controllers are an area of complexity that will likely need a discovery mechanism (for both case 1 and case 2) as the draft points out. Also, esp if IKE is implemented in the controller there needs to be a secure channel between the controller and the NSF itself. Another area that might need some discussion is the case of NSF migration- there may be some performance considerations when IKE is implemented outside the NSF, and there is NSF migration. --Sowmini From nobody Tue Jul 12 03:45:26 2016 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 CB70A12D7A3; Tue, 12 Jul 2016 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 434aGflti345; Tue, 12 Jul 2016 03:45:21 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id C28B312D798; Tue, 12 Jul 2016 03:45:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 871DC1CAD; Tue, 12 Jul 2016 12:45:19 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8un2mg4vgrLu; Tue, 12 Jul 2016 12:45:19 +0200 (CEST) Received: from eduroam_um-6-22.inf.um.es (eduroam_um-6-22.inf.um.es [155.54.6.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon24.um.es (Postfix) with ESMTPSA id D19EE1C1; Tue, 12 Jul 2016 12:45:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <20160711111317.GA5361@oracle.com> Date: Tue, 12 Jul 2016 12:45:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> <20160630162615.GA32734@oracle.com> <20160711111317.GA5361@oracle.com> To: Sowmini Varadhan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , Gabriel Lopez , Linda Dunbar , "IPsec@ietf.org" , Rafa Marin Lopez , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 10:45:24 -0000 Hi Sowmini: > El 11 jul 2016, a las 13:13, Sowmini Varadhan = escribi=C3=B3: >=20 > On (07/08/16 23:57), Rafa Marin Lopez wrote: >> We would like to really thank your comments. We think the new version >> of the I-D provides a clearer view of our design, more evolved where >> some of your questions raised here may find an answer. In any case, >> please let us know what you think now. >=20 > Hi, I took a look at this doc, some comments: [Rafa] Thank you. Please see my comments inline. >=20 >> 1. Introduction > : >> policies and SAs to handle is high. With the grow of SDN-based >=20 > nit s/grow/growth [Rafa] Fixed. >=20 >> 1) The network resource (or Network Security Function, NSF) >> implements the Internet Key Exchange (IKE) protocol and the = IPsec >> databases: the Security Policy Database (SPD), the Security >> Association Database (SAD) and the Peer Authorization Database >> (PAD). The controller is in charge of provisioning the NSF = with >> the required information about IKE, the SPD and the PAD. >>=20 >> 2) The NSF only implements the IPsec databases (no IKE >> implementation). The controller will provide the required >> parameters to create valid entries in the PAD, the SPD and the >> SAD in the NSF. Therefore, the NSF will have only support for >> IPsec while automated key management functionality is moved to >> the controller. >=20 > I found the above description a bit confusing - in both cases, > the sad, spd, pad have to be in the NSF, whereas the real distinction > between the 2 cases is based on whether IKE is implemented in the > NSF or in the controller. It might help to make that clearer. [Rafa] I think this needs clarification and we understand the confusion. However, the distinction we have made in the I-D is still valid. The = reason is the following:=20 In case 2) the NSF only implements SAD, PAD and SPD, that is correct, = =E2=80=A6 BUT in general the controller DOES NOT implement IKE in case = 2) either. Yes, the controller needs to provide information for SPD, SA = in the NSF but the controller DOES NOT perform an IKE negotiation for = that (e.g. look Fig.=20 In fact, as you can see in Fig. 2, IKE is not written in the box. That = is intentional to denote that IKE protocol is not implemented and run in = the controller. However the controller needs to distribute information = about SPD, SAD and PAD. So the controller is doing key management = operations but it does not mean IKE. =20 Having said that, it is true there is only one corner case where IKE is = implemented in the controller, which is depicted in Fig. 8. But this = case may need further discussion. Personally, I would opt for the = scenario in Fig. 7. Also we still have to decide if IKE might be used as east/west interface = with the controller (most probably it won=E2=80=99t be used as = east/west) >=20 > : >> 5. Case 1: IKE/IPsec in the NSF > : >> Disadvantages: IKE implementations need to renegotiate IPsec SAs = upon >> SPD entries changes without restarting IKE daemon. >=20 > but you would need to deal with this even if IKE was implemented > in the controller, right? The only case would be Fig.8, which as I mentioned is a corner case. In = any case, the IKE implementation should be a little special in the = controller=20 >=20 >>=20 >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IPsec Management/Orchestration Application| Client = or >> | I2NSF Client | App = Gateway >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Client Facing Interface >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Vendor | Application Support | >> Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = Security >> Interface | IKE Credential and SPD Policies Distribution| = Controller >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | NSF Facing = Interface >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | I2NSF Agent | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = Network >> | IKE | IPsec(SPD,SAD,PAD) | = Security >> +-------------------------------------------- + = Function (NSF) >> | Data Protection and Forwarding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >=20 >=20 > One question about the block diagram above (and also applies to > Case 2)- will the "Security Controller" and NSF both use the same > src IP address for the purposes of IKE negotiation? In general, there won >=20 >=20 >> 5.1. Requirements > : >> o A southbound protocol MUST support sending these SPD and PAD >> entries, and IKE credentials to the NSF. >=20 > I think the intentended northbound direction here is from the = controller > to the NSF, might help to make that clear. >=20 >> o It requires an (northbound) application interface in the = security >> controller allowing the management of IPsec SAs. >>=20 >> o In scenarios where multiple controllers are implicated, = SDN-based >> flow protection service may require a mechanism to discover = which >> security controller is managing a specific NSF. >>=20 >=20 > Multiple controllers are an area of complexity that will > likely need a discovery mechanism (for both case 1 and case 2) > as the draft points out. Also, esp if IKE is implemented in the > controller there needs to be a secure channel between the controller > and the NSF itself. >=20 > Another area that might need some discussion is the case of > NSF migration- there may be some performance considerations=20 > when IKE is implemented outside the NSF, and there is NSF migration. >=20 > --Sowmini >=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Tue Jul 12 04:09:32 2016 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 15B3512D7AF; Tue, 12 Jul 2016 04:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 x01DXhxFEsk5; Tue, 12 Jul 2016 04:09:24 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC9C12D0FB; Tue, 12 Jul 2016 04:09:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 796D0A1F9; Tue, 12 Jul 2016 13:09:23 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1CueRRijkKNI; Tue, 12 Jul 2016 13:09:23 +0200 (CEST) Received: from eduroam_um-6-22.inf.um.es (eduroam_um-6-22.inf.um.es [155.54.6.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon22.um.es (Postfix) with ESMTPSA id 1214E583; Tue, 12 Jul 2016 13:09:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: Date: Tue, 12 Jul 2016 13:09:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D2F958E-8CE6-4B50-8906-4E2F0061F2DB@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> <20160630162615.GA32734@oracle.com> <20160711111317.GA5361@oracle.com> To: Sowmini Varadhan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , Gabriel Lopez , Linda Dunbar , "IPsec@ietf.org" , Rafa Marin Lopez , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 11:09:27 -0000 Hi Sowmini (again)=20 I sent an (uncomplete) e-mail by mistake. Please consider this one and = see the complete answer inline. > El 12 jul 2016, a las 12:45, Rafa Marin Lopez escribi=C3=B3= : >=20 > Hi Sowmini: >=20 >> El 11 jul 2016, a las 13:13, Sowmini Varadhan = escribi=C3=B3: >>=20 >> On (07/08/16 23:57), Rafa Marin Lopez wrote: >>> We would like to really thank your comments. We think the new = version >>> of the I-D provides a clearer view of our design, more evolved where >>> some of your questions raised here may find an answer. In any case, >>> please let us know what you think now. >>=20 >> Hi, I took a look at this doc, some comments: >=20 >=20 [Rafa] Thank you.=20 >=20 >>=20 >>> 1. Introduction >> : >>> policies and SAs to handle is high. With the grow of SDN-based >>=20 >> nit s/grow/growth [Rafa] Fixed. >=20 >>=20 >>> 1) The network resource (or Network Security Function, NSF) >>> implements the Internet Key Exchange (IKE) protocol and the = IPsec >>> databases: the Security Policy Database (SPD), the Security >>> Association Database (SAD) and the Peer Authorization Database >>> (PAD). The controller is in charge of provisioning the NSF = with >>> the required information about IKE, the SPD and the PAD. >>>=20 >>> 2) The NSF only implements the IPsec databases (no IKE >>> implementation). The controller will provide the required >>> parameters to create valid entries in the PAD, the SPD and the >>> SAD in the NSF. Therefore, the NSF will have only support for >>> IPsec while automated key management functionality is moved to >>> the controller. >>=20 >> I found the above description a bit confusing - in both cases, >> the sad, spd, pad have to be in the NSF, whereas the real distinction >> between the 2 cases is based on whether IKE is implemented in the >> NSF or in the controller. It might help to make that clearer. >=20 >=20 [Rafa] I think this needs clarification and we understand the confusion. However, the distinction we have made in the I-D is still valid. The = reason is the following:=20 In case 2) the NSF only implements SAD, PAD and SPD, that is correct, = =E2=80=A6 BUT in general the controller DOES NOT implement IKE in case = 2) either. Yes, the controller needs to provide information for SPD, = SAD, PAD in the NSF but the controller DOES NOT perform an IKE = negotiation for that (e.g. look Fig. 4)=20 In fact, as you can see in Fig. 2, IKE is not written in the box. That = is intentional to denote that IKE protocol is not implemented and run in = the controller. However the controller needs to distribute information = about SPD, SAD and PAD. So the controller is doing key management = operations but it does not mean running IKE. What do you think? Having said that, it is true there is a corner case where IKE is = implemented in the controller, which is depicted in Fig. 8. But this = case may need further discussion. Personally, I would opt for the = scenario in Fig. 7. Also we still have to decide if IKE might be used as east/west interface = with the controller (most probably it won=E2=80=99t be used as east/west = interface at all) >>=20 >> : >>> 5. Case 1: IKE/IPsec in the NSF >> : >>> Disadvantages: IKE implementations need to renegotiate IPsec SAs = upon >>> SPD entries changes without restarting IKE daemon. >>=20 >> but you would need to deal with this even if IKE was implemented >> in the controller, right? >=20 >=20 [Rafa] The only case would be Fig. 8, which as I mentioned is a corner = case. In any case, if the IKE implementation is deployed in Fig. 8, a = change in the Flow Security Policies provided by the admin would provoke = starting an IKE negotiation with the end-user (let us assume the end = user has also changed its SPD). =20 >=20 >>=20 >>>=20 >>>=20 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IPsec Management/Orchestration Application| Client = or >>> | I2NSF Client | App = Gateway >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Client Facing Interface >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Vendor | Application Support | >>> Facing <--->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = Security >>> Interface | IKE Credential and SPD Policies Distribution| = Controller >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | NSF Facing = Interface >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | I2NSF Agent | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = Network >>> | IKE | IPsec(SPD,SAD,PAD) | = Security >>> +-------------------------------------------- + = Function (NSF) >>> | Data Protection and Forwarding | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>=20 >>=20 >> One question about the block diagram above (and also applies to >> Case 2)- will the "Security Controller" and NSF both use the same >> src IP address for the purposes of IKE negotiation? [Rafa] In general, there won=E2=80=99t be IKE negotiation except in Fig. = 8. So focusing in Fig. 8, I think they may use same IP address. Also = that possibility may be considered if IKE is used as west/east = interface. In the block diagram above this is the case (1) we have: NSF1 = (IKE/IPsec) <=E2=80=94=E2=80=94> NSF2(IKE/IPsec) . Therefore they do not = use the same IP address.=20 In case 2) : NSF1 (IPsec) <=E2=80=94> NSF2 (IPsec) =E2=80=A6 no IKE is = performed neither in the NSFs nor in the controller. The controller just = provides information for the SPD, SAD and PAD. It implies that = controller generate key material but it does not mean to run IKE at all. >=20 >=20 >=20 >>=20 >>=20 >>> 5.1. Requirements >> : >>> o A southbound protocol MUST support sending these SPD and PAD >>> entries, and IKE credentials to the NSF. >>=20 >> I think the intentended northbound direction here is from the = controller >> to the NSF, might help to make that clear. [Rafa] Agree. >>=20 >>> o It requires an (northbound) application interface in the = security >>> controller allowing the management of IPsec SAs. >>>=20 >>> o In scenarios where multiple controllers are implicated, = SDN-based >>> flow protection service may require a mechanism to discover = which >>> security controller is managing a specific NSF. >>>=20 >>=20 >> Multiple controllers are an area of complexity that will >> likely need a discovery mechanism (for both case 1 and case 2) >> as the draft points out. Also, esp if IKE is implemented in the >> controller there needs to be a secure channel between the controller >> and the NSF itself. [Rafa] I think that secure channel is always required in both cases: = sensitive information needs to be exchanged. >>=20 >> Another area that might need some discussion is the case of >> NSF migration- there may be some performance considerations=20 >> when IKE is implemented outside the NSF, and there is NSF migration. [Rafa] This is an interesting scenario we can explore. In the migration = =E2=80=A6 you consider the case where the NSF is migrated under another = controller, no? Best Regards and thanks. >>=20 >> --Sowmini >>=20 >>=20 >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Tue Jul 12 10:03:16 2016 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 8F3D612D590 for ; Tue, 12 Jul 2016 10:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAQ4QCxpaL99 for ; Tue, 12 Jul 2016 10:03:13 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6600D12D5B0 for ; Tue, 12 Jul 2016 10:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WKv+VJ3M323+OzBC1jFtCcIxHc0qF8yQQCQWWQ1os7Q=; b=aGT+9IOj1siava2AvsHEHaxNCg1nno420RNSmr1wz+pAKQj9HnLP64K/tN038eiMmDZSacbiG4k9M6CzRRDuUlJ3OTJJgfxUfXHG5sBjmQdhWVws3aEn0bKVg6L8JmZflHD5CqLSX+fxEZrV7UnvWWyRhtLZZf7Pjh37s05b0Kc= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 12 Jul 2016 17:03:06 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0528.026; Tue, 12 Jul 2016 17:03:06 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: IPsecME Agenda Posted Thread-Index: AdHcXrjyPEMU6168SImMrhjm1CrjvQ== Date: Tue, 12 Jul 2016 17:03:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: f050a7f7-d24f-4cd7-7706-08d3aa766515 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 6:lecD4p56be6Ww9T24fuqrmvUG7If/PFXdFrPO6Yltp14bLGvJYS9YgSSgxNhH+wgzPrQf6iK4wrYminkYTKSvtaOrGOaqdBZoQPb0caw4wLGYiyVFo9x69bynHGCZJLbD/SoOOpUGn1fwRtZbJYJO5CiyXwftVmplINXYeLvqoc5qEmyFSkAYNB6MnOtv06qyfeiobo+/EpiaGBdDpX1NH2s6yN7rXu0XIKhA847DWQmarbpNj5ODiSel4/lgSjbG0wByW4eIY7kh9tuA2q4nDsW525uEAA0Q+DrpHorA0ee1loJWFuuxibnIEDaA0enjb3PWGxhgoBWXRE6z50STg==; 5:65p6Ci3PaA+rhvYRxo2mZro6fruqaTU3MyJEqsdSULKn3DdWyrxz/YGGmisq2tE5Zojo6Z6AK2n2aLNovvQldaQfHA/RSOJnQkWLHngnw8aGO41OM7mpNVqqQh+z8TmkhPqGPTyuwgJyY5sssn49Vg==; 24:y3AXANxHo+oQ5madA3yt/8mbw42qPeWpkkl1S6rxAxbKki6kDOttOnnAtKzJ9Mn1r7BRbrYYU+ZG/PA4yxYkp2byWPjjgrXA1x8UDO3Nvu0=; 7:3kY/+5fKRcDpoyydDs5KbkbNupsrWol1BDwLpUXvOOlkTfwTwpOmcdoi3ZNAu3sAljviCnhES2WWxpadIcFBLeF/qYvRt7pX/VQGHmIm2zzAefJJeXguhZMvnv1US8SNMW89y2aWVM+8dRVMJ+r9SeyZMmhjRVrX+N1xN2avSmssa3M6g1y0WEGYnXXjTBvUa0EQ4jYm5/W2Kq28Z+b7XCyK24Glcd/Z/xUYQraEohm/ZaiDY30QrDD3krLzfDZc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(19580395003)(77096005)(450100001)(305945005)(10400500002)(3660700001)(8936002)(105586002)(2900100001)(106356001)(33656002)(101416001)(15975445007)(5003600100003)(7736002)(229853001)(9686002)(586003)(87936001)(6116002)(76576001)(3846002)(92566002)(5002640100001)(7846002)(68736007)(3280700002)(107886002)(97736004)(3480700004)(11100500001)(7696003)(54356999)(50986999)(81156014)(81166006)(8676002)(2906002)(86362001)(99286002)(189998001)(66066001)(122556002)(74316002)(102836003)(110136002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:03:06.0844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: [IPsec] IPsecME Agenda Posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 17:03:14 -0000 I just posted a draft agenda for the IPsecME meeting at IETF 96 with timesl= ots and presenters assigned. Please let me know if you need less time or if= another speaker should be used instead. https://www.ietf.org/proceedings/96/agenda/agenda-96-ipsecme Please send your slides to the chairs by no later than noon CEST Monday, Ju= ne 17. Thanks, Dave From nobody Thu Jul 14 06:24:47 2016 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 1E44212DA66; Thu, 14 Jul 2016 06:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1ptbQq2nlTI; Thu, 14 Jul 2016 06:24:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 E682412DA65; Thu, 14 Jul 2016 06:24:41 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6EDOTv9012741 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jul 2016 13:24:30 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u6EDOTKf019660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 13:24:29 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6EDONt4006251; Thu, 14 Jul 2016 13:24:28 GMT Received: from oracle.com (/10.175.174.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Jul 2016 06:24:22 -0700 Date: Thu, 14 Jul 2016 09:24:19 -0400 From: Sowmini Varadhan To: Rafa Marin Lopez Message-ID: <20160714132419.GB15368@oracle.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> <20160630162615.GA32734@oracle.com> <20160711111317.GA5361@oracle.com> <6D2F958E-8CE6-4B50-8906-4E2F0061F2DB@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6D2F958E-8CE6-4B50-8906-4E2F0061F2DB@um.es> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Gabriel Lopez , Sowmini Varadhan , Linda Dunbar Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 13:24:43 -0000 On (07/12/16 13:09), Rafa Marin Lopez wrote: > > What do you think? The distinction between "case 1" and "case 2" seems to be about whether IKE is done in the NSF, or not. In all cases the sad/spd etc has to be in the NSF. Might help to make that clear (and then elaborate on the various permutations of the "or not" bit). > >> One question about the block diagram above (and also applies to > >> Case 2)- will the "Security Controller" and NSF both use the same > >> src IP address for the purposes of IKE negotiation? > > [Rafa] In general, there won’t be IKE negotiation except in Fig. 8. So > focusing in Fig. 8, I think they may use same IP address. Also that > possibility may be considered if IKE is used as west/east interface. Reason that I asked this question is that if IKE is done outside the NSF, then the entity doing IKE may be constrained to use the same src addr as the NSF (I havent checked into all the requirements around IKE here) and this may be something that needs some care. > >> Another area that might need some discussion is the case of > >> NSF migration- there may be some performance considerations > >> when IKE is implemented outside the NSF, and there is NSF migration. > > [Rafa] This is an interesting scenario we can explore. In the > migration … you consider the case where the NSF is migrated under > another controller, no? correct. --Sowmini From nobody Thu Jul 14 09:26:36 2016 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 4099D12B04D; Thu, 14 Jul 2016 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 kmVCTjnjY7aM; Thu, 14 Jul 2016 09:26:31 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 8535112B00E; Thu, 14 Jul 2016 09:26:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 0E0E41C12; Thu, 14 Jul 2016 18:26:30 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K5mawclcZzl9; Thu, 14 Jul 2016 18:26:29 +0200 (CEST) Received: from eduroam_um-6-134.inf.um.es (eduroam_um-6-134.inf.um.es [155.54.6.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon24.um.es (Postfix) with ESMTPSA id BF7723F39; Thu, 14 Jul 2016 18:26:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <20160714132419.GB15368@oracle.com> Date: Thu, 14 Jul 2016 18:26:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> <20160630162615.GA32734@oracle.com> <20160711111317.GA5361@oracle.com> <6D2F958E-8CE6-4B50-8906-4E2F0061F2DB@um.es> <20160714132419.GB15368@oracle.com> To: Sowmini Varadhan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , Gabriel Lopez , Linda Dunbar , "IPsec@ietf.org" , Rafa Marin Lopez , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:26:34 -0000 Hi Sowmini: > El 14 jul 2016, a las 15:24, Sowmini Varadhan = escribi=C3=B3: >=20 > On (07/12/16 13:09), Rafa Marin Lopez wrote: >>=20 >> What do you think? >=20 > The distinction between "case 1" and "case 2" seems to be about = whether > IKE is done in the NSF, or not. [Rafa] Correct. > In all cases the sad/spd etc has > to be in the NSF. [Rafa] Correct. > Might help to make that clear (and then elaborate > on the various permutations of the "or not" bit). [Rafa] Thanks for the suggestion. >=20 >>>> One question about the block diagram above (and also applies to >>>> Case 2)- will the "Security Controller" and NSF both use the same >>>> src IP address for the purposes of IKE negotiation? >>=20 >> [Rafa] In general, there won=E2=80=99t be IKE negotiation except in = Fig. 8. So >> focusing in Fig. 8, I think they may use same IP address. Also that >> possibility may be considered if IKE is used as west/east interface. >=20 > Reason that I asked this question is that if IKE is done outside > the NSF, then the entity doing IKE may be constrained to use the > same src addr as the NSF (I havent checked into all the requirements > around IKE here) and this may be something that needs some care. [Rafa] Ah, ok. It seems reasonable to think that the end user will = require to see the IKE packet coming from the same IP address (same IKE = responder). In a typical scenario involving a controller I do not see a = real problem here. The controller could build a UDP packet with the IKE = message from the information sent by the NSF and pass that to the NSF so = it can forward it to the end user. In any case, I agree with you that = this is one of the most complicated scenarios and needs some care. >=20 >>>> Another area that might need some discussion is the case of >>>> NSF migration- there may be some performance considerations=20 >>>> when IKE is implemented outside the NSF, and there is NSF = migration. >>=20 >> [Rafa] This is an interesting scenario we can explore. In the >> migration =E2=80=A6 you consider the case where the NSF is migrated = under >> another controller, no? >=20 > correct. [Rafa] Understood. We can definitely discuss about this scenario (even a = simpler case when the NSF is migrated under another network (so change = of IP address) even under the same controller.=20 Thank you for the comments. We will try to reflect them in the next = revision of the I-D. >=20 > --Sowmini >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Jul 20 03:30:30 2016 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 D6E6F12D178; Wed, 20 Jul 2016 03:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160720103025.22546.85479.idtracker@ietfa.amsl.com> Date: Wed, 20 Jul 2016 03:30:25 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:30:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-10.txt Pages : 17 Date : 2016-07-20 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2 and does minor cleaning up of IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 20 04:16:47 2016 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 0ED1112DB85 for ; Wed, 20 Jul 2016 04:16:46 -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 XVdD-oMHZ40g for ; Wed, 20 Jul 2016 04:16:44 -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 07AE712DBA9 for ; Wed, 20 Jul 2016 04:16:21 -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 u6KBGIcV004506 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Jul 2016 14:16:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6KBGIom013277; Wed, 20 Jul 2016 14:16:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22415.23937.984081.304898@fireball.acr.fi> Date: Wed, 20 Jul 2016 14:16:17 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 9 min Archived-At: Subject: [IPsec] New version of draft-ietf-ipsecme-rfc4307bis-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:16:46 -0000 I submitted new version of the rfc4307bis draft, which includes following changes: Changed ENCR_AES_CBC from MUST- to MUST. The WG meeting was in favor of doing this change, and if you are against this change, say so now... Added the IANA considerations section to rename the AES-GCM with an/a x octet ICV to ENCR_AES_GCM_x, and ENCR_CAMELLIA_CCM with an/a x-octet ICV with ENCR_CAMELLIA_CCM_x. This includes also renaming them in the actual text (ENCR_AES_GCM_16) and adding piece to the abstract. In the meeting there was brought up a point how do new implementors know that ENCR_AES_GCM_x in the IANA registry maps to the name in the RFC4106 when they do not match exactly. I talked to IANA about this and gave few options: 1) Change reference to this document, and this document would then refer to the original. 2) Add both references to the references field, instead replacing the reference. 3) Adding new column saying formely known as 4) Adding footnotes saying this was renamed in RFCxxxx etc... In the end I think the best option would be to just include both RFCs in the references column, i.e. make the final table to be something like this: Number Name ESP Reference IKEv2 Reference ... 18 ENCR_AES_GCM_8 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] 19 ENCR_AES_GCM_12 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] 20 ENCR_AES_GCM_16 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] ... 25 ENCR_CAMELLIA_CCM_8 [RFC5529][RFCXXXX] - 26 ENCR_CAMELLIA_CCM_12 [RFC5529][RFCXXXX] - 27 ENCR_CAMELLIA_CCM_16 [RFC5529][RFCXXXX] - where the RFCXXX would be this RFC. Check out the IANA considerations section and comment if there is something you are not happy about. I will myself talk to the IANA about this, and verify that we included everything they want us to include... Luckily the IANA expert for the registry most likely will not object :-) -- kivinen@iki.fi From nobody Wed Jul 20 04:40:47 2016 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 40F8312B01B for ; Wed, 20 Jul 2016 04:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] 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 xaqVhdJBa1gq for ; Wed, 20 Jul 2016 04:40:43 -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 69C5812B008 for ; Wed, 20 Jul 2016 04:40:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rvZjP24S1z3SR; Wed, 20 Jul 2016 13:40:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1469014841; bh=XUdB4dOoihJpflMYIgtvzmdffcJjrv2/qRBaGyy0M2M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RQvxmLxlB3mjNqGcpd8uc2wAe88Y+RrKnuUWG8YdKbT4/1LQYIMB2x7pvkqKlM65Q 6RhtayjO0iXtBswaA6aJ9trps45S0Fm9i1s8DIazUkaJDp0fthQdMoG/T6J3uQ/IoD 6PCtZW68xHICp3IQDOWpLnHI4Za8B8g3vC0vqGw0= 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 8wjVHkWiMmNr; Wed, 20 Jul 2016 13:40:40 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jul 2016 13:40:40 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9A5A9393D81; Wed, 20 Jul 2016 07:40:38 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 9A5A9393D81 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 85FDE40D6F5B; Wed, 20 Jul 2016 07:40:38 -0400 (EDT) Date: Wed, 20 Jul 2016 07:40:38 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22415.23937.984081.304898@fireball.acr.fi> Message-ID: References: <22415.23937.984081.304898@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New version of draft-ietf-ipsecme-rfc4307bis-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:40:45 -0000 On Wed, 20 Jul 2016, Tero Kivinen wrote: > In the end I think the best option would be to just include both RFCs > in the references column, i.e. make the final table to be something > like this: > > Number Name ESP Reference IKEv2 Reference > ... > 18 ENCR_AES_GCM_8 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] > 19 ENCR_AES_GCM_12 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] > 20 ENCR_AES_GCM_16 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] > ... > 25 ENCR_CAMELLIA_CCM_8 [RFC5529][RFCXXXX] - > 26 ENCR_CAMELLIA_CCM_12 [RFC5529][RFCXXXX] - > 27 ENCR_CAMELLIA_CCM_16 [RFC5529][RFCXXXX] - > > where the RFCXXX would be this RFC. Works for me. > Check out the IANA considerations section and comment if there is > something you are not happy about. Looks good. (the word "does" is a little weird but the RFC Editor can reword it) I believe this document is ready for WGLC, Paul From nobody Wed Jul 20 05:29:16 2016 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 42B3D12D532 for ; Wed, 20 Jul 2016 05:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDxX-Mf59CBw for ; Wed, 20 Jul 2016 05:29:13 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in2.euro.apple.com [17.72.148.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F3F12D1D1 for ; Wed, 20 Jul 2016 05:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1469017750; x=2332931350; 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=DYsIKokxhi5bBes5XYCUa6I+4s9y6qldIeSLgqQrOCA=; b=HSm8PcWy+ZPLYZ2lBLSBveJX8k/E2x5wwGCrvh1ytH0qQBDonYMM/EI0skli0+hP JGptiq8FS8FSKXxcYCFsq9EvZJsADfthbAvuwO7dSyHAVAgKCo3VZdMWetLMcv/S VNShqGdxx5v+ElcgncId8oOndXhUF0UWHEsGCi75/SlS+GPU/402nAzatfpoKKxQ ekyUh0ipDdx1iZ0dnHtHFGlGia+VKhEK4hXNupK1LhILlUsEfCzc338w80XkZTJz Mls/G83mlBW8OG/53KxnrBsn50MO9jGJGJBU/dQrJ4Yer1bRGQFKqBgKPa8aSsPJ 8IRqcTGtkC3v1+86kktWug==; Received: from relay1.euro.apple.com (relay1.euro.apple.com [17.66.55.11]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id 93.36.09044.69E6F875; Wed, 20 Jul 2016 13:29:10 +0100 (BST) X-AuditID: 1148940c-f798c6d000002354-87-578f6e966885 Received: from crk-mmpp-sz02 (crk-mmpp-sz02.euro.apple.com [17.66.12.155]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id C0.80.05444.69E6F875; Wed, 20 Jul 2016 13:29:10 +0100 (BST) Received: from nlams2-asavpn-l2tp-17-78-245-184.euro.apple.com (nlams2-asavpn-l2tp-17-78-245-184.euro.apple.com [17.78.245.184]) by crk-mmpp-sz02.euro.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0OAM00C7B5CK2180@crk-mmpp-sz02.euro.apple.com> for ipsec@ietf.org; Wed, 20 Jul 2016 13:29:10 +0100 (IST) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3203\)) From: Tommy Pauly In-reply-to: Date: Wed, 20 Jul 2016 14:29:08 +0200 Content-transfer-encoding: quoted-printable Message-id: References: <22415.23937.984081.304898@fireball.acr.fi> To: Paul Wouters X-Mailer: Apple Mail (2.3203) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi6GTOrTstrz/coO+jlsX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0dK4la3gKVfF1ROdbA2M8zi6GDk5JARMJO4vO8MIYYtJXLi3 ng3EFhJYxyQx6UApTM2bVTdZuhi5gOJrmCQa5u1mhXA+MUlcuHaHvYuRg0NYQEJi855EkAZm AS2J9TuPM4HYvAL6EpOvT2UHsYUFPCS2nWpnBbHZBFQkjn/bwAxicwo4Slyct4cFZAyLgKrE uVliEGMMJfqW/GCEsLUlnry7wAox0kZi/umrzBB35kn8/dAFViMioCgx6cwjFoibZSXajj1g hrA72CTe9AlMYBSZheS6WUium4VkxQJG5lWM4rmJmTm6mXlGeqmlRfl6iQUFOal6yfm5mxhB Qe4xhWcH48WDhocYBTgYlXh4O2L6w4VYE8uKK3MPMUpwMCuJ8M7JAQrxpiRWVqUW5ccXleak Fh9ilOZgURLnbThUFC4kkJ5YkpqdmlqQWgSTZeLglGpgbC+uevF+Hld26iaVOPd1d3i26X4q /3/WkPuUWMPMD9fumuo1F2/JWsAdM3tbo5eT/nv/iIep5el6fXlXNFravTRfyWdeVpPxubej qLrFzq3n8wqNh+vPb3ALuci9JjbnYUjxtqUZQkEJ8bVr2Q3PreTo2zx/ld2DPd4fpny6+/es ye65yTlPlFiKMxINtZiLihMBsjMKCG4CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUi6MQzW3daXn+4wd1Jmhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRkvjVraCp1wVV090sjUwzuPoYuTkkBAwkXiz6iYLhC0mceHe erYuRi4OIYE1TBIN83azQjifmCQuXLvD3sXIwSEsICGxeU8iSAOzgJbE+p3HmUBsXgF9icnX p7KD2MICHhLbTrWzgthsAioSx79tYAaxOQUcJS7O28MCMoZFQFXi3CwxiDGGEn1LfjBC2NoS T95dYIUYaSMx//RVsFYhgTyJvx+6wGpEBBQlJp15BHWzrETbsQfMExgFZyG5aBaSi2YhGbuA kXkVo2hRak5ipaFeamlRvl5iQUFOql5yfu4mRnBgmnPvYDy+2/AQowAHoxIPr25cf7gQa2JZ cWXuIUYJDmYlEd60XKAQb0piZVVqUX58UWlOavEhRmkOFiVxXv8D2uFCAumJJanZqakFqUUw WSYOTqkGxm7l5xfNNGP+/3i57PULF8OYJXfNqpcZ/5g17fyOR1lH+k0vRv2WsyuR3tn9L+z5 u8hu95cW6j3njpce/Xz0ltXuxbmTj6gEbgt+7mUbOV3X11Ho6G3jnVYRN5wP/ZgkzpHhOCv0 wuTOO7XLVuyzvZwf/OuDl8yuguj7K5iMOr57lBtMPG2yQUmJpTgj0VCLuag4EQCVaKX8SAIA AA== Archived-At: Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] New version of draft-ietf-ipsecme-rfc4307bis-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:29:15 -0000 Yes, this looks good! I think both RFCs in the columns makes sense. I = agree that this looks ready for WGLC. Tommy > On Jul 20, 2016, at 1:40 PM, Paul Wouters wrote: >=20 > On Wed, 20 Jul 2016, Tero Kivinen wrote: >=20 >> In the end I think the best option would be to just include both RFCs >> in the references column, i.e. make the final table to be something >> like this: >>=20 >> Number Name ESP Reference IKEv2 Reference >> ... >> 18 ENCR_AES_GCM_8 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] >> 19 ENCR_AES_GCM_12 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] >> 20 ENCR_AES_GCM_16 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX] >> ... >> 25 ENCR_CAMELLIA_CCM_8 [RFC5529][RFCXXXX] - >> 26 ENCR_CAMELLIA_CCM_12 [RFC5529][RFCXXXX] - >> 27 ENCR_CAMELLIA_CCM_16 [RFC5529][RFCXXXX] - >>=20 >> where the RFCXXX would be this RFC. >=20 > Works for me. >=20 >> Check out the IANA considerations section and comment if there is >> something you are not happy about. >=20 > Looks good. (the word "does" is a little weird but the RFC Editor can > reword it) >=20 > I believe this document is ready for WGLC, >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 20 05:41:40 2016 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 DE8BD12D59B for ; Wed, 20 Jul 2016 05:41:39 -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 LJIMtywr4eqM for ; Wed, 20 Jul 2016 05:41:38 -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 AEE2F12D58A for ; Wed, 20 Jul 2016 05:41:37 -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 u6KCfZLt001439 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Jul 2016 15:41:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6KCfZGe011026; Wed, 20 Jul 2016 15:41:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22415.29055.598874.831419@fireball.acr.fi> Date: Wed, 20 Jul 2016 15:41:35 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] Minutes of the IPsecME in IETF 96 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:41:40 -0000 Here is the meeting minutes from the IETF 96 session. Thanks for the Adam for taking the minutes, and Yoav for the jabber scribing. ---------------------------------------------------------------------- Getting started. Notetaker (Adam Montville). Jabber: Yoav Nir. IPSECME DDOS Protection - Yoav Should there be a WGLC or should we just progress this draft? Dave indicates processing makes sense. Yoav is asked to do the shepherd write-up, but chairs will actually shepherd. RFC4307bis - Tero Yoav comment on renaming algorithms to align. Not sure all the people implementing will understand. Paul W.: Are we moving this to WGLC? Dave: Do we believe the doc is ready Daniel Migault: within the document, do we talk about AES GCM or in a table. Tero: We use the same form that is used in the registry. Sheila Frankel: We don't have any MUST algorithms here. Tero: Yes. We do have AES CBC. Sheila: If you take certain algorithms away without making them MUST, then we're going to end up with no MUST algorithms not part of USG's likes. Paul Hoffman: No algorithms that USG currently supports. If IETF choses to do this, then USG can be out of line with IETF or inline with IETF. It's not incumbent upon IETF to keep national governments happy. We're giving folks plenty of warning. Yaron Shafer: I think the "minus" causes confusion. Tero having a hum for MUST vs. MUST- -> Seems that MUST has it, but by a slight margin. Tommy Pauly: A MUST- is still a MUST, so it's clear from an implementer's perspective. D. Migault: If we don't go to MUST-, we won't have a smooth transition RFC7321bis - Daniel Migault Paul W.: Here we're using AES GCM as a MAY, but this is different than elsewhere, so should they be the same? Tero: This is not yet aligned, but it will be. Yoav: The issue with CHACHA is that there are no implementations out there. It's hard to recommend something we didn't do ourselves. Migault: Hope to have implementations soon. Yoav: Hopefully in the next year. Tommy Pauly: Also hope in the next year. GCM are noted in text as MAY but not show up in the table. P. Hoffman: You don't define MAY+ in the document. Yoav: In previous document we listed some algorithms from the registry, and we chose to ignore them as though they never existed, but we might feel differently. Daniel M + Tero: Notice that untruncated SHA1 will be MUST NOT or not for IPsec Paul W.: The one odd issue is that you don't have SHA2, which is really tainted (they have bad truncation). Daniel M.: What do people think about that? Deb: Can you just fix it? Paul W.: Not really - they won't change the default. If you have more clout, please do it. Tim: We've seen that everyone does it the wrong way the first time around, and fix it as they are told. SHA2_256 almost never works out of the box. Tero: Propose that we put this in the text. Compression Daniel: Compression isn't found in too many implementations. Is MUST NOT for one and three MAYs fine? Safe Curves - Yoav Nothing new since February, probably done, ready for WGLC. Chairs: We should start WGLC. No objection from the room. TCP Encap - Tommy Pauly Stream Prefix Discussion Teddy Hogeborn: Regarding prefix, this is inbound signal so problematic typically. Any packet with these six bytes in them would have issues. Pauly: We haven't seen this as an issue. A configuration issues. You have to make sure this doesn't conflict with any of the other protocols you have running Tero: Normally server has one port, normally. But, the idea here is that if a random connection were made, it shouldn't be an issue. Dan Harkins: The other port that goes through FW is DNS and captive portals. If this string is in, it allows identification which prevents getting away captive portals. Teddy Hogeborn: I still think this is a good idea, but say in the document it shouldn't be used in a middle-box to identify. Paul W: Could we make this optional? Tero: No. Brian W.: If you want to make it less likely, we can make it longer. Yoav: Target for this string is the server. We want to tell them to have the server decide based on these six bytes. Cisco and Apple are working on interoperability testing. Invitation for others to do such testing with them. When should we target WGLC? Chairs: Is it ready for WGLC? Tommy: There's not much left to do (no major issues). Tero: How many have reviewed? 4-5 hands (not very many here). Generally the others in the room believe WGLC is probably in order. IPsecME Quantum Resistance Dan Harkins: Chicken/egg problem was resolved with shared group PSKs. People are already comfortable with shared PSKs, and use those to key-wrap identity. Tero: Yes, this could work. But there are trade offs. There are many trades we could do here. Brian W.: This is depressing. Trying to get away from PSK, and now to resist quantum we're saying PSK? The only thing that seems to work otherwise is OOB. Scott Fluhrer: I see PSK as a short term issue that we can replace later. We're not ready for the next steps, so this is a reasonable short-term answer. Brian: That's a very fair point. I still think we should back away from it for a short-term solution. The hooking in other out of band methods to share PPKs is, consequently, important work. Dan H.: Don't want to talk about solutions before requirements, but...there is ASN.1 symmetric key blogs already defined. That could be part of the solution, or a path to take. Deb: If you symmetric key via asymmetric you still have a problem right? So, you'd want to pass PSK by another mechanism. Distribution of PSK is a problem. So you're not walking all the way back to your group keys... Mark Orzechowski: I think there's room for both symmetric and asymmetric solutions, because there are different users with different needs. It shouldn't be beyond our wit to do this. Paul W.: Regarding PPK and authentication, now you're creating an oracle for that. Tero: They already have an oracle. It's going to be this way anyway if the PPK isn't strong enough. Clint McKay: I have DOD customers that would use this, and it would decrease desire for v1. The real issue is back traffic and not that folks are going to be breaking authentication. Paul H.: We did design IKEv2 and went through all these discussions. The most important thing we did was say let's not worry about ID protection. It became a rathole. If we take that off the plate, we have a much smaller problem space. Let's do simplest without redesigning IKEv2. Paul W.: It's probably simple enough to map to an ephemeral ID, so why not do that? Tero: Next step is to discuss this on the mailing list to further discuss the requirements. Tommy: It feels that this should be split up into two different things. Charter Discussion Charter new work items (2 of 2 slides): Yaron S.: Last paragraph appears to be ceremonial text and we should remove it. Kathleen M.: I think the IESG would be happier to see that text (e.g. remember how long PKIX lasted). Kenny Paterson: Post-quantum key exchange discussion is probably going to go a lot longer than December 2017. Tero: If that's the case, then we'll have to recharter. Paul H.: I'm not feeling that we'll have any idea by December 2017. You can actually start up a WG without IPSECME (a la curdle). It's probably a good idea to try and shut down by that date. Split DNS - Paul W. Tero: In a couple of cases you can only get a couple of responses back, is this going to be the same way? Tommy: If the client says anything that it doesn't support it, then they can send as many domains as they want. Then response can include more. Tero: I would rather use DNSSEC format. Paul H.: I haven't read the draft. Is this to give a new trust anchor or to point at which pre-configured keys? Paul W.: No. You can give the DS record, and that would be followed by a lookup. Tero: Are DNS servers expected to respond to this. Paul W.: Yes, but you should run a DNS server that servs all of your internal domains. Tommy: Enterprise customers and Apple, when they do split DNS, this would be awesome to get people to switch. Tero: How many have read the draft? Not many (none?) Tero: How many people this is a problem we should solve? Quite a few hums in favor, no hums agains. Yes, something should be put into the charter about this. Tero: We want more review before taking this in as a WG draft, so that question will be delayed. Implicit IV - Yoav Tero: The new transform type is the big one here, because IIV cannot be used for all cipher types. The new transform attribute could work. But, I think the New Transform ID is the best way (i.e. AES-GCM_16_IIV). The question is: This hasn't been the first time this has been proposed...the IV is part of the crypto boundary, so there's this layer of people complaining about violating crypto boundaries. Tommy: I agree. I see where you're going with the transform ID. Is there any reason, when both sides support IIV, is there any reason to do this? Can't we, if agree that we do IIV, just switch to using anything with IIV. Tero: I think it has the same problem as the new transform type, because not all ciphers support. Tommy: Then we could support the same idea with transform attribute. Paul W.: I would prefer the transform attribute. Also, please don't double the registry. Brian: I suggest that we address AAED. Tero: That's one of the reasons I like new transform ID, because it is more like a new cipher. Brian: What's the motivation for this? Small devices? Will this automatically be put in browsers? Yoav: TLS 1.3 does all the same things. Tero: Adopt yes or no? Light hums in favor, no hums against. Tero: How many have read the draft - a few (double the previous!) Tero: This is something we should think about Diet-ESP - D. Migault Ran out of time during presentation. Slides are up, and questions should go to the list. -- kivinen@iki.fi From nobody Wed Jul 20 05:46:05 2016 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 73C9212DB9B for ; Wed, 20 Jul 2016 05:45:59 -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 H0VT80R8OjEX for ; Wed, 20 Jul 2016 05:45:58 -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 1154312D640 for ; Wed, 20 Jul 2016 05:45: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 u6KCjsuI004309 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Jul 2016 15:45:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6KCjslf005841; Wed, 20 Jul 2016 15:45:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22415.29314.948450.114362@fireball.acr.fi> Date: Wed, 20 Jul 2016 15:45:54 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:45:59 -0000 As we discussed in the meeting yesterday, we need to update the charter and we are making following changes to it: - Removing the opportunistic use case as null authentication has already been published as RFC7619. - Keep the DDoS case, but change the milestone from Mar 2016 to Aug 2016 for IETF LC. - Add Mandatory to implement algorithms RFCs (4307bis, 7321bis) with milestone as Sep 2016 for IETF LC. - Add new algorithm drafts (curve25519, curve448) with milestone as Sep 2016 for IETF LC of Diffie-Hellman, and Dec 2016 for EdDSA. - Add Quantum Resistance for IKEv2 as new work item with milestone as Feb 2017 for IETF LC. - Add TCP Encapsulation for IKEv2 as new work item with milestone as Dec 2016 for IETF LC. - Add Split DNS as new work item with milestone as Dec 2016 for IETF LC. - Add Implicit IV as new work item with milestone as Dec 2016 for IETF LC. Here is the new proposed charter. Note, that I did edit and clean up some of the charter items from the ones we had on slides in meeting, and there is two new items we agreed in the meeting (split dns and implicit IV). ---------------------------------------------------------------------- The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), 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 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: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to-implement (MTI) algorithms are defined in RFC4307 for IKEv2 and in RFC7321 for ESP/AH. There is interest in updating the MTIs in RFC4307 and RFC7321 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 and RFC7321 proposing updates to the MIT algorithms used by IKEv2 and IPsec to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange and EdDSA for authentication in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their related functions. IKEv1 using shared secret authentication was partially resistance 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 IKEv2 to have similar quantum resistant properties than IKEv1 had. There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE packets need to be encapsulated in a TCP tunnel. The group will define a mechanism to tunnel IKE and IPsec over a TCP-based connection. This method is intended to be used as a fallback when IKE cannot be negotiated over UDP. The group will create a method where IKEv2 and IPsec packets can be encapsulated in the TCP connection. 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 ESP sequence number and the IV in form of counter, and as they are very commonly same there has been interest to work on document that will compress the packet and derive IV from the sequnce 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. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. -- kivinen@iki.fi From nobody Wed Jul 20 05:53:01 2016 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 C9E9D12D5D1 for ; Wed, 20 Jul 2016 05:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] 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 noQYuFmhBG7Z for ; Wed, 20 Jul 2016 05:52:55 -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 1827412D5BF for ; Wed, 20 Jul 2016 05:52:54 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rvcJg00zjz3Tb; Wed, 20 Jul 2016 14:52:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1469019171; bh=E6HhQbark+RoZ4d7Cl5hSs9KDZ1nheA3sQaeoUpGUug=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=HSUFpuis19K3FcqhATgOMFtXshmmY9Z6LddbsZCgtd3Ywxe1q1QpXO5ydagoRUkAu xrt3dyk623UM6QjP+FuAGJb3TwtdsDmwahEq3rsHf0rU0FGhPEIYZjP0ZOo4lUNQMr aBIz7BdCWqP/VMpDojK2WoWN9pE56EFJGaoQeTtY= 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 GnQUPyUljskM; Wed, 20 Jul 2016 14:52:50 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jul 2016 14:52:49 +0200 (CEST) Received: from [31.133.160.155] (dhcp-a09b.meeting.ietf.org [31.133.160.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 70ED6393D81; Wed, 20 Jul 2016 08:52:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 70ED6393D81 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (13F69) In-Reply-To: <22415.29314.948450.114362@fireball.acr.fi> Date: Wed, 20 Jul 2016 14:52:46 +0200 Content-Transfer-Encoding: 7bit Message-Id: <14D79106-820C-43E6-B58B-BEFECD0A6A31@nohats.ca> References: <22415.29314.948450.114362@fireball.acr.fi> To: Tero Kivinen Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:52:57 -0000 Sent from my iPhone > On Jul 20, 2016, at 2:45 PM, Tero Kivinen wrote: > > As we discussed in the meeting yesterday, we need to update the > charter and we are making following changes to it: Looks good Paul From nobody Wed Jul 20 08:06:51 2016 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 DD8F712D81F for ; Wed, 20 Jul 2016 08:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.606 X-Spam-Level: X-Spam-Status: No, score=-5.606 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYHnNFbO81ck for ; Wed, 20 Jul 2016 08:06:47 -0700 (PDT) Received: from mail-in3.euro.apple.com (mail-in3.euro.apple.com [17.72.148.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D08D12D7D4 for ; Wed, 20 Jul 2016 08:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1469027204; x=2332940804; 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=87306ZxUBRnudyau7GuxiGk/wtHEpxznsLTRtH/nY3w=; b=YryYbkE5m2pAv0jj3Wt2JcCRbW8oI63VZnKymcsjFJ4fXY+pIuff6b/lSSIgdfNm mYtk8FAElhD8VKmwUwr/PTv5wLGUKR3R/oZIYjLqAC3UpyaKckqDhzDNp0rVKcRt Q36TLsSZhQSJjBAf6GulRELZy3afC2ToN+iMAwSSHVB44pYP0pimwJ0jJaVZcG7v 9UIHYnMjbXpyRSnEm/vflKcAn/zPCBOhSGQ3Ck5Ih0pgZhlaUMtUdnTDcI/ssGPB WEeIZnoj8S0eUGDPiScorhxQyC7XSO/GyLIbnC+17dOvmaPZfvNkWuhIdKZslgIs xKCZQ/WkACN1rTXu4u9/xQ==; Received: from relay1.euro.apple.com ( [17.66.55.11]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id C8.9D.16926.4839F875; Wed, 20 Jul 2016 16:06:44 +0100 (BST) X-AuditID: 1148940d-f791b6d00000421e-07-578f9384a7b8 Received: from crk-mmpp-sz01 (crk-mmpp-sz01.euro.apple.com [17.66.12.154]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id 39.26.05444.4839F875; Wed, 20 Jul 2016 16:06:44 +0100 (BST) Received: from [17.78.208.164] (uklon5-asavpn-l2tp-17-78-208-164.euro.apple.com [17.78.208.164]) by crk-mmpp-sz01.euro.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0OAM00F8WCN62N40@crk-mmpp-sz01.euro.apple.com> for ipsec@ietf.org; Wed, 20 Jul 2016 16:06:44 +0100 (IST) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary=Apple-Mail-78C65524-1817-4DF3-ABAA-CA26EC7B1391 MIME-version: 1.0 (1.0) From: Tommy Pauly X-Mailer: iPhone Mail (14A5309d) In-reply-to: <14D79106-820C-43E6-B58B-BEFECD0A6A31@nohats.ca> Date: Wed, 20 Jul 2016 17:06:42 +0200 Content-transfer-encoding: 7bit Message-id: <7460DEB6-01BB-4EC1-925B-332B30FD0C92@apple.com> References: <22415.29314.948450.114362@fireball.acr.fi> <14D79106-820C-43E6-B58B-BEFECD0A6A31@nohats.ca> To: Paul Wouters X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRdDLn1m2Z3B9ucLhN2mL/lhdsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuNZxm7Vgu1BFc/tt9gbGtQJdjBwcEgImEo0vCrsYOYFMMYkL 99azdTFycQgJzGSSeL/oNxtEwkRiw98JLBCJNUwSCztXM0M4l5gkGtvuMYFMEhaQkNi8JxGk gVkgXmL59V6wZl4BcYnXR6cwQpRoSqydFQoSZhNQkTj+bQMzxHwFifNTloHZnAK2Em/eHGcH sVkEVCX+bV7PCjHSUKJvyQ9GCFteYvOat8wQ420kOlf9AbOFBLIkTm/tAasXEVCUmHTmEdjN EgJr2ICaJ7BOYBSZheS8WUjOm4Vk7iygU5kFdCQmL4QLb387hxnC1pDo/DaRFcLWlli28DXz Akb2VYziuYmZObqZecZ6qaVF+XqJBQU5qXrJ+bmbGEFR5DGFdwfj9YOGhxgFOBiVeHiFe/rD hVgTy4orcw8xSnAwK4nwOkwECvGmJFZWpRblxxeV5qQWH2KU5mBREudtOFQULiSQnliSmp2a WpBaBJNl4uCUamBs0znBvuX6440TDHcHLj8p+nVq3BouEa/IJ9dag5QtayNOb6oKdVWrTUlY frZKaecdIc+3/f9nB/6Limha/t7T8eq5Dmevzo6fV3fbRvtoXDcWNyrL4P7KWzZ7wZm3b56G eUafuhyj4FvPHrMvW5Zd5PHk5N2akf9unPx7d+4PyZ8Vr1rvC9gpsRRnJBpqMRcVJwIA77/j /p4CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUi6MQzS7dlcn+4wZcLEhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrWO26wF24UqmttvszcwrhXoYuTkkBAwkdjwdwILhC0mceHe erYuRi4OIYE1TBILO1czQziXmCQa2+4xdTFycAgLSEhs3pMI0sAsEC+x/HovG4jNKyAu8fro FEaIEk2JtbNCQcJsAioSx79tYIaYryBxfsoyMJtTwFbizZvj7CA2i4CqxL/N61khRhpK9C35 wQhhy0tsXvOWGWK8jUTnqj9gtpBAlsTprT1g9SICihKTzjximcAoOAvJRbOQXDQLyahZQNcx C+hITF4IF97+dg4zhK0h0fltIiuErS2xbOFr5gWM7KsYRYtScxIrDfVSS4vy9RILCnJS9ZLz czcxgsPenHsH4/HdhocYBTgYlXh4z3b1hwuxJpYVV+YeYpTgYFYS4XWYCBTiTUmsrEotyo8v Ks1JLT7EKM3BoiTO639AO1xIID2xJDU7NbUgtQgmy8TBKdXAKOD4xTX6QhtnU0lcomfg7v85 VupBzzcUhzeeWb9od4Jr60m+bonZLN0TZhcev3vIU4T1lrXfbf8ZZnzXE8/6uX5QDfZ8GSFt sPDOuYkm3qZL1Sueavz49X9/AmPymc5M3f2uHJve9fExzrhzevPM7PuWV0sf7/md//3v4mNH WgUe+Pnq2v3wUmIpzkg01GIuKk4EAKwvOFh3AgAA Archived-At: Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:06:51 -0000 --Apple-Mail-78C65524-1817-4DF3-ABAA-CA26EC7B1391 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Looks good to me as well. Thanks! Tommy Sent from my iPhone > On Jul 20, 2016, at 2:52 PM, Paul Wouters wrote: > > > > Sent from my iPhone > >> On Jul 20, 2016, at 2:45 PM, Tero Kivinen wrote: >> >> As we discussed in the meeting yesterday, we need to update the >> charter and we are making following changes to it: > > Looks good > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-78C65524-1817-4DF3-ABAA-CA26EC7B1391 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Loo= ks good to me as well. Thanks!

<= /div>
Tommy

Sent from my iPhone

On Jul 20, 2016, at 2:52 PM, Paul Wouters <paul@nohats.ca> wrote:



Sent from my iPhone

On Jul 20, 2016, a= t 2:45 PM, Tero Kivinen <kivinen@iki.fi= > wrote:

As we discussed in the me= eting yesterday, we need to update the
charter and we are making following changes to it:<= br>

Looks good
Paul

_______________________________= ________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo= /ipsec
= --Apple-Mail-78C65524-1817-4DF3-ABAA-CA26EC7B1391-- From nobody Wed Jul 20 08:12:54 2016 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 94C0812D7E5 for ; Wed, 20 Jul 2016 08:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmzZpfkqZSTk for ; Wed, 20 Jul 2016 08:12:47 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4646A12D7DB for ; Wed, 20 Jul 2016 08:12:47 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id g62so40550000lfe.3 for ; Wed, 20 Jul 2016 08:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=+Qf+mLMfHbIhGMqvksvUNaPMS6oGjd30R0d6r79mZio=; b=mW8yBFUSsCIzH+iSLJ2RlaTlqE6l3jEKcUaddKzz7Q7qpXhTXTQ8gBBdC43SzvGl5b aC0WF94OrRrof1uMqKlVQsqMlQ69GM90KQa/C4MgGCX5wz37ts9komX6mMp/DG74Fgk0 s82ag1VMb7lmTRJuVkI6J7d/OrEZt5t9ZXGfWS75nNcRElAzx4YbwVr3Ls1i+e93IXOw ej940cNLN0Z7EbItJ8q0VbTDVo259cKgSDpPtzgYjuGkUpmzDrCazf0bhPTBafKIPQWk SwIaq+3GE1bunh6mPoya8pObPhUIU/ZQenp9xSF782cHto1fBcM97SD9Xo53g4bYDyZ7 g0Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=+Qf+mLMfHbIhGMqvksvUNaPMS6oGjd30R0d6r79mZio=; b=jz4l/KRhxjelNgFHVzYO7yBIZ8Ts1KUxXZ47PsyTsrW88jPCjNzn7jD4/KKwEP7j8M eYsGFKAseKxQoelWhsSLuVnV3X2qum5BnLcDP8xZE/DhANWVsWjLpVsCH1SBseHmlU4K dcIg2MVKTwcj1rXbDt96h5iNx8cNox3PNsuK6OTxEzAbKrA6jECFMdFsUHS7ts02ofeY Fkzt5tZbGRuMovmyQGiqlreRWpSriCxPxhuI0CySIPxGpEjsDJ7I4Uy1ipo/tMvLPWT3 IzTh7qsxyxO3ha3Nb7T/syOgvq7GoD0EWJfw1QsKswlJX/SRWv7Q0jqOfboP4vOvCwwB zwFA== X-Gm-Message-State: ALyK8tKGtU152ctHCYmsvhwFbBLFUxvTITn/irgSPhmhYxOIp4HeLuH5OsYjKWUgNWtkzQ== X-Received: by 10.25.161.76 with SMTP id k73mr16420763lfe.26.1469027565511; Wed, 20 Jul 2016 08:12:45 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 205sm682402ljj.47.2016.07.20.08.12.44 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 20 Jul 2016 08:12:44 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , References: <22415.29314.948450.114362@fireball.acr.fi> Date: Wed, 20 Jul 2016 18:12:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:12:53 -0000 Hi, > - Add Quantum Resistance for IKEv2 as new work item with milestone as > Feb 2017 for IETF LC. This milestone looks a bit optimistic for me. Otherwise the updated chapter looks good. Regards, Valery. From nobody Wed Jul 20 09:25:35 2016 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 97EA112D528 for ; Wed, 20 Jul 2016 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6gTnEnaiKOc for ; Wed, 20 Jul 2016 09:25:32 -0700 (PDT) Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3DE12D195 for ; Wed, 20 Jul 2016 09:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1469031929; x=2332945529; 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=x0rpJbPu7OOwYWv87daLtCTrRkcTEodEpkfJZjY2MuM=; b=nwbjS+ISuEObnSM5/921frjHxtHU2aXrP2gWMvmeHA+9HZZQ0M9A2N59KUmDhcDu O+TPHIkuEiQtRgsX+zx1x3x58cC8o0YwFXmbK4SzKx607ywkxqyJY0dlwxOiBFj0 uRn02EVHa+vK28eK+ctlm/VcOA1l1zZsylLxvqEL5BEOV7R+6gVynxLuY35jVOvF ctR52TmoAQPdEkL6qBf0yS8hfhUnhz4RqMQwVXHRTl1H5Qn1gETMVflyXiOtcKkU 3F7QkE3v6KwL0DhJaEWOTWxQU0EftpRsnX+DFt9NFP17QPkBf+YnOAuwYE3AnQhi rdYsMRjQuK/kHgUQ63p84A==; Received: from relay1.euro.apple.com ( [17.66.55.11]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id DF.3F.16926.9F5AF875; Wed, 20 Jul 2016 17:25:29 +0100 (BST) X-AuditID: 1148940d-f791b6d00000421e-f3-578fa5f9930d Received: from crk-mmpp-sz02 (crk-mmpp-sz02.euro.apple.com [17.66.12.155]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id E4.20.05444.9F5AF875; Wed, 20 Jul 2016 17:25:29 +0100 (BST) Received: from nlams2-asavpn-l2tp-17-78-245-184.euro.apple.com (nlams2-asavpn-l2tp-17-78-245-184.euro.apple.com [17.78.245.184]) by crk-mmpp-sz02.euro.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0OAM007O4GAF3X40@crk-mmpp-sz02.euro.apple.com> for ipsec@ietf.org; Wed, 20 Jul 2016 17:25:29 +0100 (IST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.0 \(3203\)) From: Tommy Pauly X-Priority: 3 In-reply-to: Date: Wed, 20 Jul 2016 18:25:27 +0200 Content-transfer-encoding: quoted-printable Message-id: <2A67B45A-AD26-4828-A000-062F52041789@apple.com> References: <22415.29314.948450.114362@fireball.acr.fi> To: Valery Smyslov X-Mailer: Apple Mail (2.3203) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUi6GTOrftzaX+4wYcr+hb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvZj39kLNrFV/LuxirGBcTJrFyMnh4SAicTUiUdZIGwxiQv3 1rN1MXJxCAnMZJL4/v86C0zRvNvTmSASa5gk5rT3QTmfmCSWPJrK3sXIwSEsICGxeU8iiMks oC4xZUouSC+vgL7E5OswFZoSa2eFgoTZBFQkjn/bwAwxnldiRvtTsFWcAuYSx+a8YexiZOdg EVCVWCoEEmUWMJToW/KDEcLWlnjy7gIryEBeARuJo299QMJCAikS0369BSsRAWq8ue0n1HBZ ibZjD5hBzpUQmMAm8WfbctYJjKKzEM6cheTMWUg2LGBkXsUonpuYmaObmWesl1palK+XWFCQ k6qXnJ+7iREU9h5TeHcwXj9oeIhRgINRiYdXuKc/XIg1say4MvcQowQHs5IIr/xioBBvSmJl VWpRfnxRaU5q8SFGaQ4WJXHehkNF4UIC6YklqdmpqQWpRTBZJg5OqQbGFZGxPy93JIcfXf1+ fu/hX3+tXR8cuVCZvXaiyMMP3B+afqeKX1pz6kxCdyDTQXm/L1HC/Cp3/ZN1TUp+rLhQe316 b6q9Kn+S221rve0LZFhvvkyvOzNb2TdOSnZytuOO9sSGFH6u18uOORR//fkiXNXLfd6a7yop JRWTf3d52yfzxF+83b9ciaU4I9FQi7moOBEAqtnyI3cCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi6MQzW/fn0v5wg46ZWhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvZj39kLNrFV/LuxirGBcTJrFyMnh4SAicS829OZIGwxiQv3 1rN1MXJxCAmsYZKY097HBOF8YpJY8mgqexcjB4ewgITE5j2JICazgLrElCm5IL28AvoSk6/D VGhKrJ0VChJmE1CROP5tAzPEeF6JGe1PWUBsTgFziWNz3jB2MbJzsAioSiwVAokyCxhK9C35 wQhha0s8eXeBFWQgr4CNxNG3PiBhIYEUiWm/3oKViAA13tz2E2q4rETbsQfMExiFZiFcNgvJ ZbOQDF3AyLyKUbQoNSex0lAvtbQoXy+xoCAnVS85P3cTIzhMzbl3MB7fbXiIUYCDUYmH92xX f7gQa2JZcWXuIUYJDmYlEV75xUAh3pTEyqrUovz4otKc1OJDjNIcLErivP4HtMOFBNITS1Kz U1MLUotgskwcnFINjGqqLx6/qa6NW7UwwO6y0eYJ3Wv7bKQvhdjNXCBY6jC3e4rrnrmGFUu5 Fc8u+u0oflN9+xTrnXlz3pvxPouUW9Qq/9C3afWlOWEnExwOy7I0zdM6M+FspUnRmsjti9NO 89davkjpv1zxc40ER/CP3D2Suw4/P8PlItV/Sp7le8vhrX0b2+XinymxFGckGmoxFxUnAgDJ 6py1TwIAAA== Archived-At: Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:25:33 -0000 > On Jul 20, 2016, at 5:12 PM, Valery Smyslov wrote: >=20 > Hi,=20 >> - Add Quantum Resistance for IKEv2 as new work item with milestone as >> Feb 2017 for IETF LC. >=20 > This milestone looks a bit optimistic for me. Otherwise the updated = chapter looks good. The issue seems fairly urgent in people=E2=80=99s minds right now, and = the initial goal was expressed to be a fairly minimal level of changes = to get basic QR properties (add support for a PPK to protect ESP = traffic). The goal is optimistic, but hopefully achievable! There will = probably be more ongoing QR work after that time. Tommy >=20 > Regards, > Valery. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 20 09:44:38 2016 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 E65FC12D786 for ; Wed, 20 Jul 2016 09:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0HEPo-n20ge for ; Wed, 20 Jul 2016 09:43:37 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AC012D778 for ; Wed, 20 Jul 2016 09:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3208; q=dns/txt; s=iport; t=1469033017; x=1470242617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=v826CR3WRZzBclwbOHSnWiZc3pztjQE5IQ5/mELiv6c=; b=OfqwS/z9XiaGRRxy83q45MkpgYvR/zqdjRzlxu66LApgFMjxDWSpAcFR r9J5wZWHWnLZanJE5lKaB1xR5QrsM5VEHyA2sikVPO3bTBLBfP6pYA3YU 5bS/b511YLMzcSoqiUzeK+CyfDFu4w8NttFF6cPQVDotum5Ho3LkHGbP7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgD+qI9X/4QNJK1dgz9WfAasO4wbg?= =?us-ascii?q?XoihXgCHIEXOBQBAQEBAQEBZSeEXAEBBAEBASEROgsFBwQCAQgOAgEEAQEBAgI?= =?us-ascii?q?jAwICAh8GCxQBCAgCBAENBQgTh3sDDwgOr06JTA2ECAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARcFgQGFKYRNgkOCFIJqgloFmHI0AYxDghePQIglh3oBHjaDc26GKH8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.28,395,1464652800"; d="scan'208";a="300145859" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 16:43:36 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6KGhadU020517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 16:43:36 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.1210.3; Wed, 20 Jul 2016 12:43:35 -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.1210.000; Wed, 20 Jul 2016 12:43:35 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tommy Pauly , Valery Smyslov Thread-Topic: [IPsec] New charter proposal Thread-Index: AQHR4oSy2B7jRVE0YkaKjHnL2/bydKAhbWRvgABXRoD//70zMA== Date: Wed, 20 Jul 2016 16:43:35 +0000 Message-ID: <8a316a8903134bbeb0ea4e78f5543764@XCH-RTP-006.cisco.com> References: <22415.29314.948450.114362@fireball.acr.fi> <2A67B45A-AD26-4828-A000-062F52041789@apple.com> In-Reply-To: <2A67B45A-AD26-4828-A000-062F52041789@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:43:47 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQc2VjIFttYWlsdG86aXBz ZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbW15IFBhdWx5DQo+IFNlbnQ6IFdl ZG5lc2RheSwgSnVseSAyMCwgMjAxNiAxMjoyNSBQTQ0KPiBUbzogVmFsZXJ5IFNteXNsb3YNCj4g Q2M6IGlwc2VjQGlldGYub3JnOyBUZXJvIEtpdmluZW4NCj4gU3ViamVjdDogUmU6IFtJUHNlY10g TmV3IGNoYXJ0ZXIgcHJvcG9zYWwNCj4gDQo+IA0KPiA+IE9uIEp1bCAyMCwgMjAxNiwgYXQgNTox MiBQTSwgVmFsZXJ5IFNteXNsb3YgPHN2YW5ydUBnbWFpbC5jb20+IHdyb3RlOg0KPiA+DQo+ID4g SGksDQo+ID4+IC0gQWRkIFF1YW50dW0gUmVzaXN0YW5jZSBmb3IgSUtFdjIgYXMgbmV3IHdvcmsg aXRlbSB3aXRoIG1pbGVzdG9uZSBhcw0KPiA+PiBGZWIgMjAxNyBmb3IgSUVURiBMQy4NCj4gPg0K PiA+IFRoaXMgbWlsZXN0b25lIGxvb2tzIGEgYml0IG9wdGltaXN0aWMgZm9yIG1lLiBPdGhlcndp c2UgdGhlIHVwZGF0ZWQgY2hhcHRlcg0KPiBsb29rcyBnb29kLg0KPiANCj4gVGhlIGlzc3VlIHNl ZW1zIGZhaXJseSB1cmdlbnQgaW4gcGVvcGxl4oCZcyBtaW5kcyByaWdodCBub3csIGFuZCB0aGUg aW5pdGlhbCBnb2FsDQo+IHdhcyBleHByZXNzZWQgdG8gYmUgYSBmYWlybHkgbWluaW1hbCBsZXZl bCBvZiBjaGFuZ2VzIHRvIGdldCBiYXNpYyBRUg0KPiBwcm9wZXJ0aWVzIChhZGQgc3VwcG9ydCBm b3IgYSBQUEsgdG8gcHJvdGVjdCBFU1AgdHJhZmZpYykuIFRoZSBnb2FsIGlzDQo+IG9wdGltaXN0 aWMsIGJ1dCBob3BlZnVsbHkgYWNoaWV2YWJsZSENCg0KSG93IHF1aWNrbHkgYWNoaWV2YWJsZSBp dCBpcyB3b3VsZCBkZXBlbmQgb24gdGhlIHJlcXVpcmVtZW50cyB0aGF0IHRoZSBXRyBhZ3JlZXMg dXBvbi4gIElmIHdlIGFzc3VtZSBtaW5pbWFsIHJlcXVpcmVtZW50cyAoc3VjaCBhcyAid2UgbmVl ZCB0byBwcm90ZWN0IG9ubHkgSVBzZWMgdHJhZmZpYyBmcm9tIGEgUUMiIGFuZCAiYSBzdGF0aWMg c2hhcmVkIHNlY3JldCAoUFBLKSBpcyBzdWZmaWNpZW50IiksIHRoZW4gaXQncyBzdHJhaWdodGZv cndhcmQgKHRoZSBjdXJyZW50IGRyYWZ0IGlzIG92ZXJraWxsIGZvciB0aG9zZSByZXF1aXJlbWVu dHM7IElJUkMsIFRlcm8gb3V0bGluZWQgb25lIHN1Y2ggc29sdXRpb24gYSB3aGlsZSBiYWNrKS4g IElmIHdlIGluc2lzdCBvbiBtYXhpbWFsIHJlcXVpcmVtZW50cyAoc3VjaCBhcyAid2UgbmVlZCBj b21wbGV0ZSBhbm9ueW1pdHksIGV2ZW4gaWYgdGhlIGF0dGFja2VyIGhhcyBhIFFDIiwgYW5kICJ3 ZSBuZWVkIGEgY29tcGxldGUgUFBLIG1hbmFnZW1lbnQgc29sdXRpb24iKSwgd2VsbCwgRmViIDIw MTcgd291bGQgYmUgYSBiaXQgb24gdGhlIG9wdGltaXN0aWMgc2lkZS4NCg0KPiBUaGVyZSB3aWxs IHByb2JhYmx5IGJlIG1vcmUgb25nb2luZyBRUg0KPiB3b3JrIGFmdGVyIHRoYXQgdGltZS4NCg0K SSB3b3VsZCBjZXJ0YWlubHkgaG9wZSBzbzsgdGhlIGN1cnJlbnQgd29yayBhc3N1bWVzIHRoYXQg dGhlcmUgaXMgc29tZSBvdXQtb2YtYmFuZCBxdWFudHVtIHJlc2lzdGFudCBtZWNoYW5pc20gZm9y IGRpc3RyaWJ1dGluZyAocG9zc2libHkgc3RhdGljKSBzZWNyZXRzIHRvIHRoZSBJS0UgZW5kcG9p bnRzOyB0aGF0J3MgYW4gYWNjZXB0YWJsZSBzb2x1dGlvbiBpbiBzb21lIHNpdHVhdGlvbnMsIGJ1 dCBub3QgaW4gb3RoZXJzLiAgRXZlbnR1YWxseSwgd2UnbGwgbmVlZCBhIHJlcGxhY2VtZW50IHRo YXQnbGwgd29yayBldmVyeXdoZXJlOyBpdCdzIGp1c3QgdGhhdCBjdXJyZW50bHkgdGhlIGNyeXB0 byB0ZWNobm9sb2d5IGlzbuKAmXQgdGhlcmUgcXVpdGUgeWV0IChhcyBNY0VsaWVjZSBoYXMgaW1w cmFjdGljYWxseSBsYXJnZSBwdWJsaWMga2V5cywgTlRSVSBpc24ndCB1bml2ZXJzYWxseSB0cnVz dGVkLCBhbmQgZXZlcnl0aGluZyBlbHNlIGlzIHRvbyBuZXcgdG8gYmV0IHRoZSBmYXJtIG9uLi4u KQ0KDQo+IA0KPiBUb21teQ0KPiANCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gVmFsZXJ5Lg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPiBJUHNlY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJ UHNlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw c2VjDQo= From nobody Wed Jul 20 09:45:29 2016 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 8C43012D7AF for ; Wed, 20 Jul 2016 09:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_NH8f7v8bmM for ; Wed, 20 Jul 2016 09:45:15 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0112.outbound.protection.outlook.com [23.103.201.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1657F12D4FB for ; Wed, 20 Jul 2016 09:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iW18WdZF8pX7Ge4VxEysnpTuzTXHB0MmL1GFG3z26j8=; b=no/L4x48lHvl37oyB5bXANMuCRezghjArvv0ptfPG5yb0lGJfdP0NcwfQDd0K6I5cmkHhFvySDGJcBuP1L53KGVGtL2c15EeNOyp5mclrWcPkx8zYUr9ZFiBKhzPAqkELJvHGMhClJN9iIdBURqnQ787V//ww+q1dT5M51MH5K8= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Wed, 20 Jul 2016 16:45:03 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0544.014; Wed, 20 Jul 2016 16:45:03 +0000 From: "Waltermire, David A. (Fed)" To: Tommy Pauly , Valery Smyslov Thread-Topic: [IPsec] New charter proposal Thread-Index: AQHR4oSzJSLDZsoXHEqY5sHqY6/FRKAhbWw+gAAUMICAAAV6MQ== Date: Wed, 20 Jul 2016 16:45:02 +0000 Message-ID: References: <22415.29314.948450.114362@fireball.acr.fi> , <2A67B45A-AD26-4828-A000-062F52041789@apple.com> In-Reply-To: <2A67B45A-AD26-4828-A000-062F52041789@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [70.196.37.71] x-ms-office365-filtering-correlation-id: b9e1ee24-13bd-48c8-1306-08d3b0bd32d2 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 6:UyxyM3HYAP8EIgpkj4F1mvYkj4wTli2+mhozcn8WqBAE6tuQ4pYMDgH9+iJWaDOSPFjtoEbWe26omZYaQ8E20iehgHLUoDaNEw9buvLNoFWZ+oDEVJDPhH+0XBI859S242JlkXcHkRrFyXBvDLwKnwQ5I7SwJkXx8JqNqANnwYrJewA3LNfiRhEEs+QbJRRGIYOUxLrILzlOkeDQPNo9Him2VY+5FapM5KvDA11NRxcHvye4Et4lz/xohxbgUqA7ftioBp4e80jPRlYnlkSrw95eysYRBzfuLG9GFzW5VybXMqPDPLbLKLqwHecJFk8jkZ2xMUcHpLoDWVFruWFidw==; 5:R5L1cg4/hLAXj4MGQOy6dRSs61tZdnYV1gG3vecfq7tz9pP6UwnHUTk3APDMlwzh5T3jWryGmwLvYVXSwgJAmfJabfO+ETfXgqLE0ZU7P+/RLuGzn5NFWryV+i+Dutid2XR5x3Et9SFjQkRBnpJmRA==; 24:0yyMyh3mM1QVXA7qO3ZL1tXKxZQCU2KuLLtvCDse/hoKjdwoc/TMtNaWjthAidmGRMuvymdTaKRBvkwo3tC/J6O3MrXTUbAgCqjpsL9gHZg=; 7:nKJ8AJn6qGC7MbLqOJH37ZXIFM67P5jEYVyhlyqP8UBkhoEmRyfTGAd3rBKYXT4tyRKx8fTusZagZs8ztz7haPiFoHvzcaTWm5JyZ8sKaW3CQpDqq8QYUNwI0C1uTMP23roo/1GfJeYFAjbB+DCG4Xo3qkUlEldeFJxrW2pTQvWVjsjRKUfEGx2uHkuYFa1Lyc4jp9yP+nPTpVUzqUnYjflwhsiVpAT4h2QJ4IbNdrhF8XGP9T2mZU03EcVZqXpX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(13464003)(189002)(199003)(377454003)(122556002)(189998001)(77096005)(5001770100001)(15975445007)(8666005)(7736002)(99286002)(9686002)(586003)(3280700002)(2906002)(7846002)(3846002)(102836003)(97736004)(6116002)(87936001)(3660700001)(305945005)(105586002)(63666004)(81166006)(81156014)(5002640100001)(33646002)(19580405001)(19580395003)(8676002)(50986999)(106356001)(4326007)(68736007)(76176999)(54356999)(8936002)(66066001)(86362001)(95246002)(92566002)(561944003)(101416001)(2900100001)(10400500002)(2950100001)(11100500001)(106116001)(51650200001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 16:45:02.9991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:45:17 -0000 If needed we could have some virtual meetings between IETF 96, 97, and 98 t= o work through issues. This could help increase bandwidth to make these mil= estones. Dave -------- Original Message -------- From: Tommy Pauly Date: Wed, July 20, 2016 6:25 PM +0200 To: Valery Smyslov CC: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] New charter proposal > On Jul 20, 2016, at 5:12 PM, Valery Smyslov wrote: > > Hi, >> - Add Quantum Resistance for IKEv2 as new work item with milestone as >> Feb 2017 for IETF LC. > > This milestone looks a bit optimistic for me. Otherwise the updated chapt= er looks good. The issue seems fairly urgent in people=92s minds right now, and the initia= l goal was expressed to be a fairly minimal level of changes to get basic Q= R properties (add support for a PPK to protect ESP traffic). The goal is op= timistic, but hopefully achievable! There will probably be more ongoing QR = work after that time. Tommy > > Regards, > Valery. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 20 09:56:21 2016 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 47C2612B051 for ; Wed, 20 Jul 2016 09:56:20 -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 IcvojNmWmYt7 for ; Wed, 20 Jul 2016 09:56:18 -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 27E5312D104 for ; Wed, 20 Jul 2016 09:56:17 -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 u6KGuDmT018263 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Jul 2016 19:56:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6KGuDOA024800; Wed, 20 Jul 2016 19:56:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22415.44333.533967.662318@fireball.acr.fi> Date: Wed, 20 Jul 2016 19:56:13 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <22415.29314.948450.114362@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 3 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:56:20 -0000 Valery Smyslov writes: > > - Add Quantum Resistance for IKEv2 as new work item with milestone as > > Feb 2017 for IETF LC. > > This milestone looks a bit optimistic for me. > Otherwise the updated chapter looks good. The limited resistance we are talking about is in the same level of protection which IKEv1 has, i.e., PPK. We are not yet talking about doing using any quantum resistant protocols to generate the PPK, we just assume that the PPK comes through some out of band method and we can want to make sure we use it in the protocol in the way that makes IKEv2 quantum resistant in a way that traffic stored now using this extension cannot be decrypted after the quantum computers are there, and attackers can break Diffie-Hellman done in IKEv2. I.e., the actual work item is: IKEv1 using shared secret authentication was partially resistance 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 IKEv2 to have similar quantum resistant properties than IKEv1 had. and I think we should be able to finish that in WG in the next 6 months. -- kivinen@iki.fi From nobody Wed Jul 20 14:59:04 2016 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 1C1B212D0C4 for ; Wed, 20 Jul 2016 14:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv5N6gdn7UqQ for ; Wed, 20 Jul 2016 14:59:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4603612B015 for ; Wed, 20 Jul 2016 14:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1742; q=dns/txt; s=iport; t=1469051941; x=1470261541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=piOGDIZlPA7EbRQuk9QMpZRf6dOBc+xiFf7/2DHESsQ=; b=nIT+QZ6HmumWN8ImhE0mcrzRUeCsLHvYdBjaYrk9RmTzZveYcUYXLIrs pCmYggVXLEfi6Ias9WYbIt/3jY96RMPbla0uQ73bHi8Q4nwT4u0Dc6ROb hYTzuxOEWDiTAC9961TYl0epd783Wvddy1Z/WZQjp32uCCXSoFhxlVVUY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCA849X/4oNJK1dgz9WfAasPowbg?= =?us-ascii?q?XsihXgCgTU4FAEBAQEBAQFlJ4RcAQEFAQE4NAsMBAIBCBEEAQEfCQchBgsUCQg?= =?us-ascii?q?CBA4FCIgOAxcOuRUNhAkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2CQ4FZh?= =?us-ascii?q?X8FmHI0AYxDghePQIglh3oBHjaDc26FY0V/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,396,1464652800"; d="scan'208";a="131812283" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 21:59:00 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6KLx0pq009238 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 21:59:00 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 16:58:59 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 16:58:59 -0500 From: "Panos Kampanakis (pkampana)" To: Tero Kivinen Thread-Topic: [IPsec] New charter proposal Thread-Index: AQHR4qef2B7jRVE0YkaKjHnL2/bydKAh237Q Date: Wed, 20 Jul 2016 21:58:59 +0000 Message-ID: <666ce618684e447691503a66c4fcd8c9@XCH-ALN-010.cisco.com> References: <22415.29314.948450.114362@fireball.acr.fi> <22415.44333.533967.662318@fireball.acr.fi> In-Reply-To: <22415.44333.533967.662318@fireball.acr.fi> 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.116.108.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 21:59:03 -0000 +1=20 Tero,=20 Waiting for your IKEv2 quantum resistance slides to become available, as a = great summary of the potential requirements. -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Wednesday, July 20, 2016 12:56 PM To: Valery Smyslov Cc: ipsec@ietf.org Subject: Re: [IPsec] New charter proposal Valery Smyslov writes: > > - Add Quantum Resistance for IKEv2 as new work item with milestone=20 > > as Feb 2017 for IETF LC. >=20 > This milestone looks a bit optimistic for me.=20 > Otherwise the updated chapter looks good. The limited resistance we are talking about is in the same level of protect= ion which IKEv1 has, i.e., PPK. We are not yet talking about doing using an= y quantum resistant protocols to generate the PPK, we just assume that the = PPK comes through some out of band method and we can want to make sure we u= se it in the protocol in the way that makes IKEv2 quantum resistant in a way that traffic stored now using this extensi= on cannot be decrypted after the quantum computers are there, and attackers= can break Diffie-Hellman done in IKEv2. I.e., the actual work item is: IKEv1 using shared secret authentication was partially resistance to quantu= m computers. IKEv2 removed this feature to make the protocol more usable. T= he working group will add a mode to IKEv2 or otherwise modify IKEv2 to have= similar quantum resistant properties than IKEv1 had. and I think we should be able to finish that in WG in the next 6 months. =20 -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 20 16:28:36 2016 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 9170712D103 for ; Wed, 20 Jul 2016 16:28:34 -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 98xqB_lCC616 for ; Wed, 20 Jul 2016 16:28:32 -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 164BF12D5C7 for ; Wed, 20 Jul 2016 16:28:31 -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 u6KNSFrT011529 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Jul 2016 02:28:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6KNSFuD029682; Thu, 21 Jul 2016 02:28:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22416.2319.858946.887114@fireball.acr.fi> Date: Thu, 21 Jul 2016 02:28:15 +0300 From: Tero Kivinen To: "Panos Kampanakis \(pkampana\)" In-Reply-To: <666ce618684e447691503a66c4fcd8c9@XCH-ALN-010.cisco.com> References: <22415.29314.948450.114362@fireball.acr.fi> <22415.44333.533967.662318@fireball.acr.fi> <666ce618684e447691503a66c4fcd8c9@XCH-ALN-010.cisco.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 8 min Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 23:28:34 -0000 Panos Kampanakis (pkampana) writes: > Waiting for your IKEv2 quantum resistance slides to become > available, as a great summary of the potential requirements. All the slides we presented in the IPsecME meeting was uploaded to the meeting materials site before the meeting started, i.e., https://datatracker.ietf.org/meeting/96/materials/#ipsecme contains ipsecme slides, minutes etc, and my slides can be found from following url: https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-1.pdf We will most likely make start talking about requirements on the mailing list and then collect list of the final requirements somewhere (not sure if we need draft for that, we might use wiki page to keep track of them, or just collect the feedback from the list, and send summary of them to the mailint list). I think I will wait until next week before starting that process, so we can get the charter discussion out before that. -- kivinen@iki.fi From nobody Fri Jul 22 00:35:45 2016 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 6719112DC13 for ; Fri, 22 Jul 2016 00:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 W-a4sVKasw3M for ; Fri, 22 Jul 2016 00:35:43 -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 11CD812D5EB for ; Fri, 22 Jul 2016 00:35:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D70B200A5; Fri, 22 Jul 2016 03:45:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F07AC638BE; Fri, 22 Jul 2016 03:35:41 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22415.29314.948450.114362@fireball.acr.fi> References: <22415.29314.948450.114362@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:35:44 -0000 --=-=-= Content-Type: text/plain New charter seems fine. (I am pessimistic about the milestones, but I suggest changing them as needed rather than planning to take longer.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5HMy4CLcPvd0N1lAQK8/gf/YRzKn7IYJQcbbo3p5YCX49O7xaLFUKD4 XhnTLwlNaTZsGml5A8lQH0HbEnrmAiBNrD0amc+zoUf86lsYP9TFpFQ/9GfRP9tX IOVBzVX5L80DvWuW2Yqbt8WZlpKaDF91X2Pu1MyfSmtenGsTZ8VErDvU8NoenS0H 1J58H9IRuxO3Cy5Sz1lPZVCwNjfa2PdajB4ytYfboqBnjZO/57ynfjvpkbv48Zcv oEJXzpVxGY26jDku+4rHrVTtgw0vH2FOVD69QF/7Yn7Pazt4uI1pBuozuX8CcA4M sucIOje9r9hOKNRjw7JbbIm2t7J+RLtESfSh/w3gjhupRX2inlus3w== =AVN9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 22 00:59:23 2016 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 3671B12D626 for ; Fri, 22 Jul 2016 00:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NgAi6MR54PP for ; Fri, 22 Jul 2016 00:59:17 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2FA12D61F for ; Fri, 22 Jul 2016 00:59:17 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id q128so46409568wma.1 for ; Fri, 22 Jul 2016 00:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=qEjJNkfNu21NureOv9iqthiSlSmthZ2sn1812XaIYe4=; b=Af+G/k/s8TyHUcnBbGf6+Bz2yHbJhiD5UI0/xfD26ivm9mZqYgftFt//EJZXMG8sPx wM0rSo/wwD6dONNWZeRsMZmmujejl+OH1tF6g8g9FEYFkQuR2LhDXb7pq7Uq4bWZDqSP Wf6JeMdhoNzjCcmY42+WSah4OkKAqMhQ1gcEjx1kqoMEIzNM//6NSbpGAQHrUosAvbmm jJD5pacv7jZRRAB8Pyy5USs/pav6YcDjI8zQT4RkNj8WEG2GaeuSiS2bnGuu/ckMuRrJ 1Y5J+vpRYeX2PN5jTqP5z8WST+qqNqxoP+cDM6Do6r/GJG5RcW9rUbZ8/bGGbqIzksm/ 3F2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=qEjJNkfNu21NureOv9iqthiSlSmthZ2sn1812XaIYe4=; b=XayZO0Lhmq1gEs0NofqSfo9id4xjOVIMNfyhEIz7NjUKAk2AnLNXrUQs+LK3p5iLl9 PSLaQ6dldEk2qjQ0G+HYswLguDsxAPUNygYBGRMQ+VEpBHMPhALWFYgrhCMukDhfBnkh hT6gWXKjzOSPIHeUrP+zZrqDogT8kfaJuLd8DESRWe3JVgF9lL29gsDck/ZJTGD1tojO u0p2Zi7tYaE2NejWem78tJK7hC1++em5D1uBU7k2bwnS+TmSeUftb7YW/Sp0r6WCAeTy KYU/AuBMfVcmFdf8rEU2L0OKLGpLqCPqVTk8r7vxhn6XdRXjWDO8DrlIR4FMlf/sHNO+ UxPg== X-Gm-Message-State: ALyK8tJc8/SI+rHS/oTD7z/fofJCtXKCBKqicGcha0Zf9JdCUL7DaF6Hugvd2TqBApelJQ== X-Received: by 10.28.126.195 with SMTP id z186mr24299921wmc.95.1469174355307; Fri, 22 Jul 2016 00:59:15 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:8836:6cb3:dcf6:48d8? ([2001:67c:370:176:8836:6cb3:dcf6:48d8]) by smtp.gmail.com with ESMTPSA id m127sm11016133wmm.21.2016.07.22.00.59.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jul 2016 00:59:14 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4C8D75B9-6198-47AA-B65E-69FF3F573FDF"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Yoav Nir In-Reply-To: <24922.1469172941@obiwan.sandelman.ca> Date: Fri, 22 Jul 2016 09:59:12 +0200 Message-Id: References: <22415.29314.948450.114362@fireball.acr.fi> <24922.1469172941@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] New charter proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:59:20 -0000 --Apple-Mail=_4C8D75B9-6198-47AA-B65E-69FF3F573FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 > On 22 Jul 2016, at 9:35 AM, Michael Richardson = wrote: >=20 >=20 > New charter seems fine. >=20 > (I am pessimistic about the milestones, but I suggest changing them as = needed > rather than planning to take longer.) >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- --Apple-Mail=_4C8D75B9-6198-47AA-B65E-69FF3F573FDF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXkdJRAAoJECXR4BOacZZUqVEH/3xFtejshs1EbLib96Y3wfQ7 sis0COsBMp58r5YUERtLBL36tSzF7pe51DvHDtNK8h+4lf3SRuyvlCeqnDM6a511 8Ct+KrICkdO5uG8mspIvbutIdGx33NbKAjl0VxyRJ9m+AqhcNonZ/5tMJl2yGTMK cqUbPXPyCOQF46mpkqMRWUlBTHjoADoHGKa/5Gg8YR0qv2Au9qhpCN1+wFK1M3fT JQs0M/vNB42rF6oZOhgnFL6gd3hjYfoizllssYLKIJp13EFcKrhCa0yMP8ZXESq9 LpjIRFDRLQA9LTJZOsYCWcmRxFatlveh3bN1VJjWIyr/bUAAGm5mxV6spwR/cLg= =qT/A -----END PGP SIGNATURE----- --Apple-Mail=_4C8D75B9-6198-47AA-B65E-69FF3F573FDF-- From nobody Fri Jul 22 10:46:44 2016 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 EB98E12D795 for ; Fri, 22 Jul 2016 10:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2GH58eNoaaJ7 for ; Fri, 22 Jul 2016 10:46:41 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02BA12D7C8 for ; Fri, 22 Jul 2016 10:46:39 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-c5-57925bfd0538 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.3F.12926.EFB52975; Fri, 22 Jul 2016 19:46:38 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.230]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 19:46:37 +0200 From: John Mattsson To: "ipsec@ietf.org" Thread-Topic: 3GPP question about ECDSA support Thread-Index: AQHR5ED+306jOD0JnUCeakq0IA++QQ== Date: Fri, 22 Jul 2016 17:46:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <87F7006CFF7A0840855B03D514CF1FA8@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbHdUvdf9KRwgzdreCz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGdfnjEXrOOq2NV3nrGBsYeri5GTQ0LARKLx+DFGCFtM4sK9 9WxdjFwcQgJHGCUaP61mhHCWMEq0v/0MVsUmYCAxd08DG4gtIqAqcWrZdFYQm1kgQWL5tJ9g cWEBLYlrXRMZIWr0JZ58/ApVryex+/VkMJsFqHfpvOtANRwcvALmEudeCoOEGYGO+H5qDRPE SHGJW0/mM0EcJyCxZM95ZghbVOLl439ga0WBRt7uWMsOEVeSaFzyhBVkJLOApsT6XfoQY6wl Wg9+ghqpKDGl+yFYOa+AoMTJmU9YJjCKzUKybRZC9ywk3bOQdM9C0r2AkXUVo2hxanFSbrqR sV5qUWZycXF+nl5easkmRmD8HNzyW3UH4+U3jocYBTgYlXh4F/BODBdiTSwrrsw9xCjBwawk wjsvclK4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBkaz lfyiV92FxH6mfA5UfyW3mrNPbCJj1cukc57CJXJHr29b43dJ543mzMaixPdLGKZdi92eHWl5 3//x1nVvF31527e/z/8u57oz5idn5hlWXepeJtsumHysYiWP5feVHA73pO27UoN2/q3Qty+Q k+TcclZgZXBcrP6kz0dflRz+tnWeqce5eD0lluKMREMt5qLiRADE7VlWmwIAAA== Archived-At: Cc: Vesa Torvinen , Vesa Lehtovirta Subject: [IPsec] 3GPP question about ECDSA support X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 17:46:44 -0000 M0dQUCBpcyBjdXJyZW50bHkgYXBvcHRpbmcgRUNEU0EgZm9yIGFsbCB1c2VzIG9mIElLRXYyIChv bGRlciByZWxlYXNlcw0KdXNlZCBSU0EpLiBNeSAzR1BQIFNBMyBjb2xsZWFndWVzIChjYykgaGF2 ZSBhc2tlZCBtZSB0byBmb3J3YXJkIHRoZQ0KcXVlc3Rpb24gYmVsb3cgdG8gdGhlIElQU2VjIHdn LiBBcyBkaXNjdXNzZWQgaW4gQnVlbm9zIEFpcmVzLCAzR1BQIGFuZA0KSUVURiBzaG91bGQgY29v cmRpbmF0ZSBtb3JlLCBJIGhvcGUgdGhlIElQU2VjIHdnIGNhbiBwcm92aWRlIHZhbHVhYmxlDQpm ZWVkYmFjay4NCg0KQ2hlZXJzLA0KSm9obg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpIaSBhbGwsDQoNCiANCkkgaGF2ZSBhIHF1ZXN0aW9u IHJlZ2FyZGluZyBzdXBwb3J0IG9mIEVDRFNBIGFuZCBJIGhvcGUgdG8gZ2V0IHNvbWUgdmlld3MN Cm9uIHRoaXMgbGlzdC4NCiANCg0KM0dQUCBoYXMgaW50cm9kdWNlZCBFQ0RTQSBmb3IgSUtFdjIg aW4gM0dQUCBzcGVjaWZpY2F0aW9uIFRTIDMzLjMxMCBhbmQgaXMNCm5vdyBjb25zaWRlcmluZywg d2hpY2ggUkZDIHNob3VsZCBiZSBhZG9wdGVkIHJlZ2FyZGluZyBFQ0RTQSwgUkZDIDQ3NTQgb3IN ClJGQyA3NDI3Pw0KDQpXZSBiYXNpY2FsbHkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGJldHRl ciB3aGF0IGlzIHRoZSBmdXR1cmUgZm9yIEVDRFNBDQphbmQgUlNBIGF1dGhlbnRpY2F0aW9uIGFu ZCBlc3BlY2lhbGx5IGlmIHRoZXJlIGlzIGluZm9ybWF0aW9uIG9uIHdoYXQgaXMNCnRoZSBkZXBs b3ltZW50IHN0YXR1cyBvZiBSRkM0NzU0IGFuZCBSRkM3NDI3Lg0KIA0KDQpBbnkgdmlld3Mgb24g dGhpcyB3b3VsZCBiZSBhcHByZWNpYXRlZC4NCiANCg0KQnIsIFZlc2EgTGVodG92aXJ0YQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Fri Jul 22 10:56:43 2016 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 1FA3712D7AD for ; Fri, 22 Jul 2016 10:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] 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 J3eypusF8R3I for ; Fri, 22 Jul 2016 10:56: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 32FEC12D16F for ; Fri, 22 Jul 2016 10:56:40 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rwyyG1pLnz2Gq; Fri, 22 Jul 2016 19:56:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1469210198; bh=sWD5ipDuTZ852VaIQau3jx+krL0mEPJjKy76aa0BKmo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SbOnxzRKo9ULMmchOQ5oQfa5pHaLPbi2Ep7LpXlbzUfay1YvuTZASoMtTfvwUhRJT NOLjXIVgXNYcQLVWXQiFIXOTjMxdvEiF+ZaHDbCUt5XfnsdnZQkr5kkySxFzjffDls Ciu8AkxHDFxxursFOTkDBhxciW7DWg4acZjmDviI= 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 mgZxSlxNnpDf; Fri, 22 Jul 2016 19:56:36 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 22 Jul 2016 19:56:36 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D11C3393D67; Fri, 22 Jul 2016 13:56:35 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D11C3393D67 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BBD5D40D6F5B; Fri, 22 Jul 2016 13:56:35 -0400 (EDT) Date: Fri, 22 Jul 2016 13:56:35 -0400 (EDT) From: Paul Wouters To: John Mattsson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Vesa Torvinen , Vesa Lehtovirta Subject: Re: [IPsec] 3GPP question about ECDSA support X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 17:56:42 -0000 On Fri, 22 Jul 2016, John Mattsson wrote: > Subject: [IPsec] 3GPP question about ECDSA support > > 3GPP is currently apopting ECDSA for all uses of IKEv2 (older releases > used RSA). My 3GPP SA3 colleagues (cc) have asked me to forward the > question below to the IPSec wg. As discussed in Buenos Aires, 3GPP and > IETF should coordinate more, I hope the IPSec wg can provide valuable > feedback. See https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-4 While the old style "auth by IKE algorithm number" are still at SHOULD, they will be demoted in the near future because we are promoting using Digital Signatures as per RFC 7427 instead. https://tools.ietf.org/html/rfc7427 As the draft states: RSA authentication, as well as other specific Authentication Methods, are expected to be replaced with the generic Digital Signature method of [RFC7427]. [...] ECDSA based Authentication Methods are also expected to be downgraded as it does not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. The advantage is that the AUTH algorithm will be negotiated by OID and be independent of any IKE/IPsec RFC's. New standards should really only use 7427 for authentication. ECDSA should be supported via RFC-7427 and not via the legacy IKE algorithm numbers. Paul From nobody Sun Jul 24 15:59:51 2016 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 78C6912B016 for ; Sun, 24 Jul 2016 15:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1_CN57wO2ll5 for ; Sun, 24 Jul 2016 15:59:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 08BDE12B026 for ; Sun, 24 Jul 2016 15:59:45 -0700 (PDT) X-AuditID: c1b4fb25-6efff70000000bbb-74-5795485d7c5d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id F1.A8.03003.D5845975; Mon, 25 Jul 2016 00:59:43 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.230]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Mon, 25 Jul 2016 00:59:41 +0200 From: John Mattsson To: "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-10.txt Thread-Index: AQHR4nHKq+FzSr2QGE2w/440lOndQqAoOTmA Date: Sun, 24 Jul 2016 22:59:40 +0000 Message-ID: References: <20160720103025.22546.85479.idtracker@ietfa.amsl.com> In-Reply-To: <20160720103025.22546.85479.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <439788CD3EC0F84E95C75E9A65572583@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdUTfeY2q4wbzDxhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq6n+9kLLilV7H8xk72B8YFiFyMnh4SAicSa/lVMILaQwHpG iduHXLoYuYDsJYwSC1/tYwNJsAkYSMzd0wBmiwioSpxaNp21i5GDQ1jAVWLJ1UKIsJvEsgfP WSFsI4lJP/+A2SxA5Z9uPwGbzytgLtH06RIrxC5HifsXDjKD2JwCThIP18wHG88oICbx/dQa sHpmAXGJW0/mM0HcKSCxZM95ZghbVOLl439gc0QF9CRud6xlh4grSaw9vJ0F5DRmAU2J9bv0 IcZYS/z+1sIKYStKTOl+yA5xjqDEyZlPWCYwis1Csm0WQvcsJN2zkHTPQtK9gJF1FaNocWpx Um66kbFealFmcnFxfp5eXmrJJkZg9Bzc8lt1B+PlN46HGAU4GJV4eBWYpoYLsSaWFVfmHmKU 4GBWEuFd7AwU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnV wJjqHsEdwBKiwmxzgaNTjsdjk+PUnqVRAi8Cnp04OUtF9Yo8Q7M0362Vtdan61dnOf4Rm7W9 I7sp7J+2WIPctZWaE2aXTOB8/3TP3TkHGUL+PWphXlrRFLC64fUKGY2GgnRDVZVlrBuKNzp6 etutmHp739V1PwS3rtdXvGCo8KrvVcKztI31P5VYijMSDbWYi4oTATLAPGeaAgAA Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 22:59:49 -0000 SGksDQoNCkkgcmVyZWFkICBkcmFmdC1pZXRmLWlwc2VjbWUtcmZjNDMwN2Jpcy0xMCwgSSB0aGlu ayB0aGlzIGlzIHZlcnkgd2VsbA0Kd3JpdHRlbiBhbmQgZGVmaW5hdGx5IHJlYWR5IGZvciBXR0xD Lg0KDQoNClNvbWUgY29tbWVudHM6DQoNCi0gU2VjdGlvbiA0LjENCkdpdmVuIHRoZSBleGlzdGlu ZyB0ZXh0IOKAnERpZ2l0YWwgU2lnbmF0dXJlIFtSRkM3NDI3XSBpcyBleHBlY3RlZCB0byBiZQ0K cHJvbW90ZWTigJ0sIEkgdGhpbmsgYXV0aGVudGljYXRpb24gbWV0aG9kIG51bWJlciAxNCBzaG91 bGQgYmUg4oCcU0hPVUxEK+KAnQ0KDQotIFNlY3Rpb24gNC4xDQpHaXZlbiB0aGUgZXhpc3Rpbmcg dGV4dCDigJxJdCBpcyBleHBlY3RlZCB0byBiZSBkb3duZ3JhZGVk4oCdLCBJIHRoaW5rDQphdXRo ZW50aWNhdGlvbiBtZXRob2QgbnVtYmVyIDEgc2hvdWxkIGJlIOKAnE1VU1Qt4oCdLg0KDQotIFNl Y3Rpb24gNA0KQW55IHJlYXNvbiB0aGF0IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCAxMCAoRUNEU0Eg d2l0aCBTSEEtMzg0IG9uIHRoZSBQLTM4NA0KY3VydmUpIGFuZCAxMSAoRUNEU0Egd2l0aCBTSEEt NTEyIG9uIHRoZSBQLTUyMSBjdXJ2ZSkgYXJlIFNIT1VMRCB3aGlsZQ0KYXV0aGVudGljYXRpb24g bWV0aG9kIDE0IChEaWdpdGFsIFNpZ25hdHVyZSkgd2l0aCBlY2RzYS13aXRoLXNoYTM4NCBhbmQN CmVjZHNhLXdpdGgtc2hhNTEyIGFyZSBNQVk/DQoNCg0KDQpDYXBpdGFsaXNhdGlvbjoNCg0KLSBT ZWN0aW9uIDINCuKAnElvVCAgICAgICBzdGFuZHPigJ0gLT4g4oCcSW9UCVN0YW5kc+KAnQ0KDQot IFNlY3Rpb24gNC4xLjENCuKAnFJlY29tbWVuZGF0aW9ucyBmb3IgUlNBIGtleSBsZW5ndGjigJ0g LT4gUmVjb21tZW5kYXRpb25zIGZvciBSU0EgS2V5IExlbmd0aA0KDQoNCg0KQ2hlZXJzLA0KSm9o bg0KDQoNCg0KDQoNCg0KDQpPbiAyMC8wNy8xNiAxMjozMCwgIklQc2VjIG9uIGJlaGFsZiBvZiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo8aXBzZWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0K PmRpcmVjdG9yaWVzLg0KPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQIFNlY3Vy aXR5IE1haW50ZW5hbmNlIGFuZCBFeHRlbnNpb25zDQo+b2YgdGhlIElFVEYuDQo+DQo+ICAgICAg ICBUaXRsZSAgICAgICAgICAgOiBBbGdvcml0aG0gSW1wbGVtZW50YXRpb24gUmVxdWlyZW1lbnRz IGFuZCBVc2FnZQ0KPkd1aWRhbmNlIGZvciBJS0V2Mg0KPiAgICAgICAgQXV0aG9ycyAgICAgICAg IDogWW9hdiBOaXINCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFRlcm8gS2l2aW5lbg0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBXb3V0ZXJzDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICBEYW5pZWwgTWlnYXVsdA0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlw c2VjbWUtcmZjNDMwN2Jpcy0xMC50eHQNCj4JUGFnZXMgICAgICAgICAgIDogMTcNCj4JRGF0ZSAg ICAgICAgICAgIDogMjAxNi0wNy0yMA0KPg0KPkFic3RyYWN0Og0KPiAgIFRoZSBJUHNlYyBzZXJp ZXMgb2YgcHJvdG9jb2xzIG1ha2VzIHVzZSBvZiB2YXJpb3VzIGNyeXB0b2dyYXBoaWMNCj4gICBh bGdvcml0aG1zIGluIG9yZGVyIHRvIHByb3ZpZGUgc2VjdXJpdHkgc2VydmljZXMuICBUaGUgSW50 ZXJuZXQgS2V5DQo+ICAgRXhjaGFuZ2UgKElLRSkgcHJvdG9jb2wgaXMgdXNlZCB0byBuZWdvdGlh dGUgdGhlIElQc2VjIFNlY3VyaXR5DQo+ICAgQXNzb2NpYXRpb24gKElQc2VjIFNBKSBwYXJhbWV0 ZXJzLCBzdWNoIGFzIHdoaWNoIGFsZ29yaXRobXMgc2hvdWxkIGJlDQo+ICAgdXNlZC4gIFRvIGVu c3VyZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucywN Cj4gICBpdCBpcyBuZWNlc3NhcnkgdG8gc3BlY2lmeSBhIHNldCBvZiBhbGdvcml0aG0gaW1wbGVt ZW50YXRpb24NCj4gICByZXF1aXJlbWVudHMgYW5kIHVzYWdlIGd1aWRhbmNlIHRvIGVuc3VyZSB0 aGF0IHRoZXJlIGlzIGF0IGxlYXN0IG9uZQ0KPiAgIGFsZ29yaXRobSB0aGF0IGFsbCBpbXBsZW1l bnRhdGlvbnMgc3VwcG9ydC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcw0KPiAgIHRoZSBjdXJyZW50 IGFsZ29yaXRobSBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudHMgYW5kIHVzYWdlIGd1aWRhbmNl DQo+ICAgZm9yIElLRXYyIGFuZCBkb2VzIG1pbm9yIGNsZWFuaW5nIHVwIG9mIElLRXYyIElBTkEg cmVnaXN0cnkuICBUaGlzDQo+ICAgZG9jdW1lbnQgZG9lcyBub3QgdXBkYXRlIHRoZSBhbGdvcml0 aG1zIHVzZWQgZm9yIHBhY2tldCBlbmNyeXB0aW9uDQo+ICAgdXNpbmcgSVBzZWMgRW5jYXBzdWxh dGVkIFNlY3VyaXR5IFBheWxvYWQgKEVTUCkuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLXJmYzQzMDdiaXMvDQo+DQo+VGhlcmUncyBhbHNv IGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaXBzZWNtZS1yZmM0MzA3YmlzLTEwDQo+DQo+QSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlwc2VjbWUtcmZjNDMwN2Jpcy0xMA0KPg0KPg0K PlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5JUHNlYyBtYWlsaW5nIGxpc3QNCj5JUHNlY0BpZXRmLm9yZw0K Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0K From nobody Mon Jul 25 01:07:35 2016 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 4E7D412D106 for ; Mon, 25 Jul 2016 01:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] 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 sA3ujLOtw1tq for ; Mon, 25 Jul 2016 01:07:32 -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 12A8112D09C for ; Mon, 25 Jul 2016 01:07:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ryYl42sgDz36S; Mon, 25 Jul 2016 10:07:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1469434048; bh=2k/ry9HJxVmnivWFuTfRNhtW+cdcr8BvLGOodBd4Y+4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XH3PsMznUxCDJTeibGc5fs/PtikySKE9RLGxNWVKUmWp94OL7wLwd6SWtOGZJyYvh b5vvH1EtCVtrMRKkw1L+k7sAC0NbRRzNSWuSk7ShfaVzaAnt2lp/15oL7poXKieosU f7eOFQ435ogvTit2vnYapjUQqDvgnz4Ilt56UlKE= 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 kdz512lLe0DH; Mon, 25 Jul 2016 10:07:26 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 25 Jul 2016 10:07:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E85D4393D89; Mon, 25 Jul 2016 04:07:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E85D4393D89 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D0DC340D6F5B; Mon, 25 Jul 2016 04:07:25 -0400 (EDT) Date: Mon, 25 Jul 2016 04:07:25 -0400 (EDT) From: Paul Wouters To: John Mattsson In-Reply-To: Message-ID: References: <20160720103025.22546.85479.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:07:34 -0000 On Sun, 24 Jul 2016, John Mattsson wrote: > I reread draft-ietf-ipsecme-rfc4307bis-10, I think this is very well > written and definatly ready for WGLC. > > Some comments: > > - Section 4.1 > Given the existing text “Digital Signature [RFC7427] is expected to be > promoted”, I think authentication method number 14 should be “SHOULD+” It should be, but since RFC7427 was not widely adopted yet, we refrained from doing so. We are hopeful it will see more adoption and for it to go that way. But we feel a plus should signify a move that is already visible, and for RFC7427 it is not visible yet. > - Section 4.1 > Given the existing text “It is expected to be downgraded”, I think > authentication method number 1 should be “MUST-”. I agree, but some people at ietf96 felt that we must always have an unqualified MUST in there. I also think a MUST- would be better because it still signifies a MUST but indicates we want to very slowly start deprecating it. I expect in the next version that will go to SHOULD- regardless of whether it is a MUST or MUST- one. > - Section 4 > Any reason that authentication method 10 (ECDSA with SHA-384 on the P-384 > curve) and 11 (ECDSA with SHA-512 on the P-521 curve) are SHOULD while > authentication method 14 (Digital Signature) with ecdsa-with-sha384 and > ecdsa-with-sha512 are MAY? I believe this was due to ECDSA being considered an older variant of ECC and if you do the shint new stuff of RFC7427, you can and should use better ECC algorithms too (like EdDSA) > Capitalisation: > > - Section 2 > “IoT stands” -> “IoT Stands” > > - Section 4.1.1 > “Recommendations for RSA key length” -> Recommendations for RSA Key Length We will pull these two changes into the next version. Paul From nobody Tue Jul 26 07:07:06 2016 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 AFDFE12DB49 for ; Tue, 26 Jul 2016 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] 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 YPXL9P9VDLCH for ; Tue, 26 Jul 2016 07:07:00 -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 AB66A12DD2A for ; Tue, 26 Jul 2016 06:53:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rzKNC47SBzC2h for ; Tue, 26 Jul 2016 15:53:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1469541227; bh=5WLfLj+CSuHUgZD3fWEGJgF+2CRqv2mLIJuR7hh6K9o=; h=Date:From:To:Subject; b=PHS6OrAXoWVX86NeOKRrTqg1KaWqQRTM+YGE5t5LCHsNc96fkRlJqsfL+yPt8wI1/ 5taF433csiW9z8f1ElcVh7EBu1RspBtOA5/Y8gBXjpFg3txovBw6cIsz4nAp7C+0b2 f6iZG4MH4Lm5BQzPXUR/kz0cDrRUZJTV+3Iiyk2s= 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 A7ztONK0SSzi for ; Tue, 26 Jul 2016 15:53:46 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 26 Jul 2016 15:53:46 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 36360393BF1; Tue, 26 Jul 2016 09:53:45 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 36360393BF1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 22026406A908 for ; Tue, 26 Jul 2016 09:53:45 -0400 (EDT) Date: Tue, 26 Jul 2016 09:53:44 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] draft-pauly-ipsecme-split-dns-01 discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 14:07:04 -0000 At the last IETF, we discussed draft-pauly-ipsecme-split-dns-01. The authors had one question, related to whether we should use the DNSKEY or DS record format for the INTERNAL_DNSSEC_TA CP payload. I talked to the bind, knot and unbound people about this. Bind cannot perform a runtime trust anchor reconfiguration via its rndc tool. So you need to create trust anchor files to read in. These files use the DNS presentation format and currently support only the DNSKEY format, not the DS format. This makes sense because this is not a runtime operation where you send the information of ( IP of nameserver, trust anchor, domain name). The unbound developers at the last IETF were not sure about the capabilities of unbound-control. The man page lists that you can configure trust anchors via DNSKEY or DS record. Running a test command via: sudo unbound-control set_option trust-anchor: "" with or without an unbound-control forward_add domain 1.2.3.4 (to a real recursive nameserver) did not seem to properly pickup the trust anchor and still returned data as insecure. The knot developers weren't sure what was supported, but said they would support whichever option we needed. I did not yet test sysatemd-resolved. It seems the software still needs work, so probably those vendors can adapt based on our requirements. So I think we can pick the option we prefer the most. In my opinion, that would be the DS record, because it is not as bulkt as DNSKEY records. A second discusion item that came up was the danger of using strings for this option, where people could possibly put evil items in the string, such as "IN DS `cat /etc/passwd`". If the DNS wire format is used, this attack would be prevented. My issue with that is that I would still need to convert the wire format to presentation format to present it to the on-the-fly reconfiguration tools of the DNS server. So I don't see much value in this additional conversion from a security point of view. If I missed anything else from discussions at the last IETF, please let me know. I think the important part was for more people to read the draft and give us feedback, so we can move on with the draft. As Tommy said, a standarized option for DNS handling is badly needed for IKEv2. Paul From nobody Wed Jul 27 08:11:51 2016 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 03B2112DBCD for ; Wed, 27 Jul 2016 08:11:50 -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 bBF-iAsqv94x for ; Wed, 27 Jul 2016 08:11:46 -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 30C3F12DBBC for ; Wed, 27 Jul 2016 08:11:46 -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 u6RFBghv029006 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jul 2016 18:11:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6RFBe0X003746; Wed, 27 Jul 2016 18:11:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22424.53036.785641.697837@fireball.acr.fi> Date: Wed, 27 Jul 2016 18:11:40 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: Cc: "ipsec@ietf.org WG" Subject: [IPsec] draft-pauly-ipsecme-split-dns-01 discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 15:11:50 -0000 [not wearing chair hat] Paul Wouters writes: > It seems the software still needs work, so probably those vendors can > adapt based on our requirements. So I think we can pick the option we > prefer the most. In my opinion, that would be the DS record, because it > is not as bulkt as DNSKEY records. I think DS records are fine. They are smaller, which is always benefit, and if software needs to be changed anyways, then I assume it is no matter which we pick... > A second discusion item that came up was the danger of using strings for > this option, where people could possibly put evil items in the string, > such as "IN DS `cat /etc/passwd`". If the DNS wire format is used, > this attack would be prevented. My issue with that is that I would still > need to convert the wire format to presentation format to present it to > the on-the-fly reconfiguration tools of the DNS server. So I don't see > much value in this additional conversion from a security point of view. I think we do need to add some kind of warning for implementors in the security considerations section saying do not just put that string and give it to the resolver, verify that it is in correct format before giving it out. I mean the textual representation have all kind of other things you can do so you really want to make sure there is nothing extra in the value. Perhaps even include regex to match that value does not have anything extra or dangerous... We also do not want to allow server to feed in any other ds records than what it is supposed to serve, and we do not want allow it to feed in any other records like "www.facebook.com. IN CNAME evil.com". -- kivinen@iki.fi From nobody Wed Jul 27 11:24:13 2016 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 A847312D176 for ; Wed, 27 Jul 2016 11:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 QkLDYVH6GXrs for ; Wed, 27 Jul 2016 11:24:10 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F11F12D1CB for ; Wed, 27 Jul 2016 11:24:10 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id q128so223085974wma.1 for ; Wed, 27 Jul 2016 11:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=Z2lWX/m8+nMG+9OyCseiBv4RRWG+rSxyRRy1zb9o4cw=; b=jWOobdjoepKW6GBblCaRcjrdhbcttGERkhgL5smYfz4m8VzaOUPOOpDtSjPdWqNda/ 0J7i3vQ2OyaTIct7igQzi7Oxro0cEpWvv/APIc5Z0Bjart+h3S25tse3wV83/TdXwKtY C/IWPZrR99e3pHQTXnz4mG1A79COZ37oC8Sg95BpZXtY4h8+PaDa8oEgIpl+CCnMeXo+ Xs2RfJdzOUeTpHIiTxquLj5WwQ05ijRt4kDtWJIq46En6u9NJEvAzJdFZeDpw3TGBCtD udpLFG4s1U+uDJhWewAwypptynDbOYz9eVln41PCGZqjJtvWcd9zLAbfIxmWDTfaBdrS HFhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Z2lWX/m8+nMG+9OyCseiBv4RRWG+rSxyRRy1zb9o4cw=; b=EOkXpK+cfT3gTKqZTA025uikuh8h//gSgOM/Hn1ovP6Sg2n30SNh6s4ihrOvgFWeg/ f/mst78WUMX0xmzYo4JT7GsO+298r7alYUnZ0AIg4M9tn47i0OcMr9sk7pGLymtIoL/D gW70fNf5DaoAVB6nYWNfgoxGwxr5ieoZGveFap+ECHtHDQMqG9d8oKkljvsNEP5SvaC1 YvYVOzvflFGJgzDWS0eaK4hMbl4jT6apqzyinhrohQ1pcP34Ftg0oR+HVxrjGihKTFTZ /2Rl6K82Ui7JsizVONbYeW/qY9/5QUfjaqFIpctri13swQQBFn6ABhlu60DqZVubZSBc iLTQ== X-Gm-Message-State: AEkoouu93KAdytkwdxBdP22gh8sxY2YUsGlY8lbuNPRYuhOiQoGdbcx1ss4kV+SKkl9zYLxwpbtyCzzA+EgWHA== X-Received: by 10.28.17.138 with SMTP id 132mr33066204wmr.81.1469643848542; Wed, 27 Jul 2016 11:24:08 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.152.130 with HTTP; Wed, 27 Jul 2016 11:24:07 -0700 (PDT) From: Daniel Migault Date: Wed, 27 Jul 2016 14:24:07 -0400 X-Google-Sender-Auth: 0jltzE4jkpbdzkj1o8B03NHoOuY Message-ID: To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a1147218a89eed80538a21f3a Archived-At: Subject: [IPsec] review for draft-ietf-ipsecme-tcp-encaps-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 18:24:12 -0000 --001a1147218a89eed80538a21f3a Content-Type: text/plain; charset=UTF-8 Hi, I reviewed draft-ietf-ipsecme-tcp-encaps-01 as my understanding is that we are doing a pre-WGLC. I think the draft is in pretty good shape for a WGLC. Please see my comments below. BR, Daniel TCP Encapsulation of IKE and IPSec Packets draft-ietf-ipsecme-tcp-encaps-01 Abstract This document describes a method to transport IKE and IPSec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending all packets for tunnel establishment >MGLT: Maybe that would be clearer to have: >OLD: >This method, referred to as TCP >encapsulation, involves sending all packets for tunnel establishment >as well as tunneled packets over a TCP connection. > >NEW: >This method, referred to as TCP >encapsulation, involves both sending all IKE packets for tunnel establishment >as well as tunneled packets with ESP over a TCP connection. as well as tunneled packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. 1. Introduction IKEv2 [RFC7296] is a protocol for establishing IPSec tunnels, using >MGLT: I think IPSec should be replaced by IPsec. Direct use of ESP or UDP Encapsulation should be preferred by IKE implementations due to performance concerns when using TCP Encapsulation Section 12. >MGLT: This looks a bit strange to have Section 12 at the end of the >sentence. Maye it would be preferred something like "More details >are provided in Section 12" Most implementations should use TCP Encapsulation only on networks where negotiation over UDP has been attempted without receiving responses from the peer, or if a network is known to not support UDP. 1.1. Prior Work and Motivation Some previous solutions include: >MGLT: I would prefer "alternatives" then "solutions" as solutions > imply there is not anymore a problem to solve.. In addition, we >can add some justification for this document. The justifications for >me are 1) defining a standard that provides interoperability as well >as 2) reduce the additional overhead over some tof the solutions. I >do not know if that is easier to have a sentence to position the >document toward each alternative or if it can be summed up in the >beginning. 2. Configuration One of the main reasons to use TCP encapsulation is that UDP traffic may be entirely blocked on a network. Because of this, support for TCP encapsulation is not specifically negotiated in the IKE exchange. Instead, support for TCP encapsulation must be pre-configured on both the initiator and the responder. The configuration defined on each peer should include the following parameters: o One or more TCP ports on which the responder will listen for incoming connections. Note that the initiator may initiate TCP connections to the responder from any local port. >MGLT: I would also add a note that the port the responder >may listen to may be limited as such networks may only let >a very limited set of outgoing ports over TCP. Obviously ports >could be 80 or 443. On the other hand on an IPsec point of >view port 4500 seems also a natural cnadidate. 3. TCP-Encapsulated Header Formats >MGLT: Maybe it would help to specify in the begining of the section >something like : >"TCP encapsulation follows >the UDP encapsulation marking to differentaite ESP to IKE. >In addition, TCP stream also require the length to be specified." > In order to encapsulate IKE and ESP messages within a TCP stream, a 16-bit length field precedes every message. If the first 32-bits of the message are zeros (a Non-ESP Marker), then the contents comprise an IKE message. Otherwise, the contents comprise an ESP message. Authentication Header (AH) messages are not supported for TCP encapsulation. > MGLT: I think the restriction to ESP should be mentioned earlier in > the document. (Abstract or introduction) 3.1. TCP-Encapsulated IKE Header Format The IKE header is preceded by a 16-bit length field in network byte order that specifies the length of the IKE packet within the TCP stream. > MGLT: Reading the text it looks that length does not include the Non-ESP > Marker. This is specified later, but maybe we coudl replace: > > OLD: > The IKE header is preceded by a 16-bit length field in network byte > order that specifies the length of the IKE packet within the TCP > stream. > NEW: > The IKE header is preceded by a 16-bit length field in network byte > order that specifies the length of the encapsulated IKE packet within the TCP > stream. 4. TCP-Encapsulated Stream Prefix >MGLT: Maybe that would be helpful for te reader to provide motivations >for these "IKETCP" stream. I would have something like this at the >beginign of the section: >"TCP encapsulation has not been assigned any specific port, as > this port may not be allowed in a network. As a result, TCP > encapsulation may not be announced with a specific port. In > addition, port allowed by the network for TCP may happen to be > well known port used by other applications such as port 80, or 443. > When such port are used, peers should signal that the TCP connection > is not associated to the well known port but instead for TCP > encapsulation. In addition, such signaling needs to be performed > at the TCP layer to make TCP encapsulation as generic as possible. > For example, the used of ALPN for such signalling would restrict > the signaling to TLS. TCP could use TCP options, but these options > are unlikely to go through most networks. As a result, this document > uses in-band signaling." Each stream of bytes used for IKE and IPSec encapsulation MUST begin with a fixed sequence of six bytes as a magic value, containing the characters "IKETCP" as ASCII values. This allows peers to differentiate this protocol from other protocols that may be run over TCP streams, since the bytes do not overlap with the valid start of any other known stream protocol. This value is only sent once, by the Initiator only, at the beginning of any stream of IKE and ESP messages. >MGLT: Maybe that will be in the security considerations, but I think >we should explain that we hope there is not matching with an existing packet. 5. Applicability If TCP encapsulation is being used for a specific IKE SA, all messages for that IKE SA and its Child SAs MUST be sent over a TCP connection until the SA is deleted or MOBIKE is used to change the SA endpoints and/or encapsulation protocol. >MGLT: The sentence below looks to me redundant with the first sentence. > I would also add a reference to section below where intercations with > MOBIKE is provided in more details. No packets should be sent over UDP or direct ESP for the IKE SA or its Child SAs while using TCP encapsulation. 8. Using MOBIKE with TCP encapsulation > MGLT: From this section my understanding is that MOBIKE message > from the new interface uses first a UDP encapsulation. If that > does not work, it switches to TCP encapsulation. In other work > there is no fall back from TCP to NO encapsulation. Shouldn't we > use the NAT detection to determine whether UDP encapsulation or > no encapsulation be used? > My understanding is that ESP is UDP encapsulated or not depending > if NAT has been detected on the initial interface. In other words, > if the new network has no NAT, the mobile is likely to perform > encapsulation on this network. Am I correct ? 13. Security Considerations > MGLT: I think we should also add some text regarding the matching with the IKETCP string. --001a1147218a89eed80538a21f3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I reviewed draft-ietf-ips= ecme-tcp-encaps-01 as my understanding is that we are doing a pre-WGLC.=C2= =A0 I think the draft is in pretty good shape for a WGLC. Please see my com= ments below.


BR,
Daniel

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP E= ncapsulation of IKE and IPSec Packets
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 draft-ietf-ipsecme-tcp-encaps-01

Abstract

=C2=A0=C2=A0= This document describes a method to transport IKE and IPSec packets
=C2= =A0=C2=A0 over a TCP connection for traversing network middleboxes that may=
=C2=A0=C2=A0 block IKE negotiation over UDP.=C2=A0 This method, referre= d to as TCP
=C2=A0=C2=A0 encapsulation, involves sending all packets for= tunnel establishment
=C2=A0
>MGLT: Maybe that would be clearer to= have:
>OLD:
>This method, referred to as TCP
>encapsulat= ion, involves sending all packets for tunnel establishment
>as well a= s tunneled packets over a TCP connection.
>
>NEW:
>This = method, referred to as TCP
>encapsulation, involves both sending all = IKE packets for tunnel establishment
>as well as tunneled packets wit= h ESP over a TCP connection.

=C2=A0=C2=A0
=C2=A0=C2=A0 as well = as tunneled packets over a TCP connection.=C2=A0 This method is
=C2=A0= =C2=A0 intended to be used as a fallback option when IKE cannot be
=C2= =A0=C2=A0 negotiated over UDP.


1.=C2=A0 Introduction

=C2= =A0=C2=A0 IKEv2 [RFC7296] is a protocol for establishing IPSec tunnels, usi= ng
=C2=A0=C2=A0
>MGLT: I think IPSec should be replaced by IPsec.=
=C2=A0
=C2=A0=C2=A0 Direct use of ESP or UDP Encapsulation should be= preferred by IKE
=C2=A0=C2=A0 implementations due to performance concer= ns when using TCP
=C2=A0=C2=A0 Encapsulation Section 12.
=C2=A0=C2=A0=
>MGLT: This looks a bit strange to have Section 12 at the end of th= e
>sentence. Maye it would be preferred something like "More de= tails
>are provided in Section 12"

=C2=A0=C2=A0 Most im= plementations should use TCP
=C2=A0=C2=A0 Encapsulation only on networks= where negotiation over UDP has been
=C2=A0=C2=A0 attempted without rece= iving responses from the peer, or if a network
=C2=A0=C2=A0 is known to = not support UDP.

1.1.=C2=A0 Prior Work and Motivation


=C2= =A0=C2=A0 Some previous solutions include:

>MGLT: I would prefer = "alternatives" then "solutions" as solutions
> i= mply there is not anymore a problem to solve.. In addition, we
>can = add some justification for this document. The justifications for
>me= are 1) defining a standard that provides interoperability as well
>= as 2) reduce the additional overhead over some tof the solutions. I
>= ;do not know if that is easier to have a sentence to position the
>d= ocument toward each alternative or if it can be summed up in the
=C2=A0&= gt;beginning.
=C2=A0


2.=C2=A0 Configuration

=C2=A0=C2= =A0 One of the main reasons to use TCP encapsulation is that UDP traffic=C2=A0=C2=A0 may be entirely blocked on a network.=C2=A0 Because of this, = support for
=C2=A0=C2=A0 TCP encapsulation is not specifically negotiate= d in the IKE exchange.
=C2=A0=C2=A0 Instead, support for TCP encapsulati= on must be pre-configured on both
=C2=A0=C2=A0 the initiator and the res= ponder.

=C2=A0=C2=A0 The configuration defined on each peer should i= nclude the following
=C2=A0=C2=A0 parameters:

=C2=A0=C2=A0 o=C2= =A0 One or more TCP ports on which the responder will listen for
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 incoming connections.=C2=A0 Note that the initiato= r may initiate TCP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connections to the res= ponder from any local port.

>MGLT: I would also add a note that t= he port the responder
>may listen to may be limited as such networks = may only let
=C2=A0>a very limited set of outgoing ports over TCP. Ob= viously ports
=C2=A0>could be 80 or 443. On the other hand on an IPs= ec point of
=C2=A0>view port 4500 seems also a natural cnadidate. =C2=A0=C2=A0=C2=A0 =C2=A0

=C2=A0
3.=C2=A0 TCP-Encapsulated Hea= der Formats

>MGLT: Maybe it would help to specify in the begining= of the section
>something like :
>"TCP encapsulation fol= lows
>the UDP encapsulation marking to differentaite ESP to IKE.
= >In addition, TCP stream also require the length to be specified."= =C2=A0
>
=C2=A0 In order to encapsulate IKE and ESP messages with= in a TCP stream, a
=C2=A0=C2=A0 16-bit length field precedes every messa= ge.=C2=A0 If the first 32-bits of
=C2=A0=C2=A0 the message are zeros (a = Non-ESP Marker), then the contents comprise
=C2=A0=C2=A0 an IKE message.= =C2=A0 Otherwise, the contents comprise an ESP message.
=C2=A0=C2=A0 Aut= hentication Header (AH) messages are not supported for TCP
=C2=A0=C2=A0 = encapsulation.

=C2=A0> MGLT: I think the restriction to ESP shoul= d be mentioned earlier in
=C2=A0> the document. (Abstract or introdu= ction)=C2=A0
=C2=A0=C2=A0
=C2=A0
3.1.=C2=A0 TCP-Encapsulated IKE= Header Format

=C2=A0
=C2=A0=C2=A0 The IKE header is preceded by = a 16-bit length field in network byte
=C2=A0=C2=A0 order that specifies = the length of the IKE packet within the TCP
=C2=A0=C2=A0 stream.

= > MGLT: Reading the text it looks that length does not include the Non-E= SP
> Marker. This is specified later, but maybe we coudl replace:
= >
> OLD:
=C2=A0> =C2=A0 The IKE header is preceded by a 16-= bit length field in network byte
=C2=A0>=C2=A0 order that specifies t= he length of the IKE packet within the TCP
=C2=A0>=C2=A0 stream.
&= gt; NEW:
>=C2=A0=C2=A0=C2=A0 The IKE header is preceded by a 16-bit l= ength field in network byte
>=C2=A0=C2=A0 order that specifies the le= ngth of the encapsulated IKE packet within the TCP
>=C2=A0=C2=A0 stre= am.

=C2=A0=C2=A0
=C2=A0

4.=C2=A0 TCP-Encapsulated Stream = Prefix

>MGLT: Maybe that would be helpful for te reader to provid= e motivations
>for these "IKETCP" stream. I would have some= thing like this at the
>beginign of the section:

>"TC= P encapsulation has not been assigned any specific port, as
> this po= rt may not be allowed in a network. As a result, TCP
> encapsulation= may not be announced with a specific port. In
> addition, port allo= wed by the network for TCP may happen to be
> well known port used by= other applications such as port 80, or 443.
> When such port are us= ed, peers should signal that the TCP connection
> is not associated t= o the well known port but instead for TCP
> encapsulation. In additio= n, such signaling needs to be performed
> at the TCP layer to make T= CP encapsulation as generic as possible.
> For example, the used of A= LPN for such signalling would restrict
> the signaling to TLS. TCP c= ould use TCP options, but these options
> are unlikely to go through = most networks. As a result, this document
> uses in-band signaling.&q= uot;

=C2=A0=C2=A0 Each stream of bytes used for IKE and IPSec encaps= ulation MUST begin
=C2=A0=C2=A0 with a fixed sequence of six bytes as a = magic value, containing the
=C2=A0=C2=A0 characters "IKETCP" a= s ASCII values.=C2=A0 This allows peers to
=C2=A0=C2=A0 differentiate th= is protocol from other protocols that may be run over
=C2=A0=C2=A0 TCP s= treams, since the bytes do not overlap with the valid start of
=C2=A0=C2= =A0 any other known stream protocol.=C2=A0 This value is only sent once, by=
=C2=A0=C2=A0 the Initiator only, at the beginning of any stream of IKE = and ESP
=C2=A0=C2=A0 messages.


>MGLT: Maybe that will be i= n the security considerations, but I think
>we should explain that w= e hope there is not matching with an existing packet.




5= .=C2=A0 Applicability


=C2=A0=C2=A0 If TCP encapsulation is being= used for a specific IKE SA, all
=C2=A0=C2=A0 messages for that IKE SA a= nd its Child SAs MUST be sent over a TCP
=C2=A0=C2=A0 connection until t= he SA is deleted or MOBIKE is used to change the SA
=C2=A0=C2=A0 endpoin= ts and/or encapsulation protocol.

>MGLT: The sentence below look= s to me redundant with the first sentence.
>=C2=A0 I would also add a= reference to section below where intercations with
>=C2=A0 MOBIKE is= provided in more details.


=C2=A0=C2=A0 No packets should be sen= t
=C2=A0=C2=A0 over UDP or direct ESP for the IKE SA or its Child SAs wh= ile using
=C2=A0=C2=A0 TCP encapsulation.


8.=C2=A0 Using MOBI= KE with TCP encapsulation


>=C2=A0=C2=A0 MGLT: From this secti= on my understanding is that MOBIKE message
>=C2=A0=C2=A0 from the ne= w interface uses first a UDP encapsulation. If that
>=C2=A0 does not= work, it switches to TCP encapsulation. In other work
>=C2=A0=C2=A0= there is no fall back from TCP to NO encapsulation. Shouldn't we
&g= t;=C2=A0=C2=A0 use the NAT detection to determine whether UDP encapsulation= or
>=C2=A0=C2=A0 no encapsulation be used?=C2=A0=C2=A0
>=C2= =A0=C2=A0 My understanding is that ESP is UDP encapsulated or not depending=
>=C2=A0=C2=A0 if NAT has been detected on the initial interface. In = other words,
>=C2=A0=C2=A0 if the new network has no NAT, the mobile= is likely to perform
>=C2=A0=C2=A0 encapsulation on this network. A= m I correct ?
=C2=A0=C2=A0

13.=C2=A0 Security Considerations
=
=C2=A0
> MGLT: I think we should also add some text regarding the= matching with the IKETCP string.


--001a1147218a89eed80538a21f3a-- From nobody Wed Jul 27 12:31:28 2016 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 0E81D12D8DD for ; Wed, 27 Jul 2016 12:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1jbCbBf0Ew0R for ; Wed, 27 Jul 2016 12:31:23 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 AD37812D8DB for ; Wed, 27 Jul 2016 12:31:22 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id i5so76964852wmg.0 for ; Wed, 27 Jul 2016 12:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=YgzANgKkktF2z33fO5w1aclF9AL7Yct9wDBzuIMLJDA=; b=FTomBORWCqCBWoCkMbSBsG0KTdeO4yk/nZN0Ni9mLtXqpghn8L6xokJMfKbsEEIBy4 vYtaywtNpzcSIOLu3nnXfrjPuPFvflGqI4VDgK/zpYL3mxQGel70I8Llets1CmDSfH3I dxpO5QT3Efn2oK0TMj4onmbeybVEieTRk0D+Msd232hxal/vowob7J+8f6xo6Z/tHDPQ aY0Yoif557r5MDfrMQ4QkEwh90gZaSR3jC+veXGk1mz/7dX2tv/zus+r978nbczeut23 TMpksJrWOnW035pWwoRzc+htWMaz3IlPb8BjE49iA/y5++qSjXkDexgM3Ph/Ytl8ixly 3qhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=YgzANgKkktF2z33fO5w1aclF9AL7Yct9wDBzuIMLJDA=; b=GbaRaWhj1Kd1kxv4pyTuRUAZlVfJF12xHowOGJhLLxAVq3nQuZSWETD+J/3knVZPQU apMwSmBMDdUb7D8lEizeaj61AnHq48ntvfhsBrr40RDwXNvUZNLpA3FHUIuCXza60RTt 0zjRio5MSA0oV/LF0PJNuBxVAlncDqQPr7kf36NmnfrB5Ivbw/8eiDhQ3wwN+he9t4MM SRvJGeNhvV9bei67ZqM/khMaAwbT39+/m/O+sDaVn2gz9Yrnek11uCrt8TtuuHuuLoLt G0jRxp3JJzvoT8WhLSUnRK7TdF3YoaG4mFca+ojEk/YExRqsMaNuNVNuUiPrlDvPYHko P6fA== X-Gm-Message-State: AEkoousLRKuuEeqD1/jKXWBPbKzisIBoyOtnDQgsLdg+S+qpQ+FDrKhen4xqf1LnbzqHszltpw6WStWeb0R21A== X-Received: by 10.28.17.138 with SMTP id 132mr33310081wmr.81.1469647880838; Wed, 27 Jul 2016 12:31:20 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.152.130 with HTTP; Wed, 27 Jul 2016 12:31:20 -0700 (PDT) From: Daniel Migault Date: Wed, 27 Jul 2016 15:31:20 -0400 X-Google-Sender-Auth: qMDZfdQhGIIqznjmX3PNxj4Wvas Message-ID: To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a1147218ae1e49a0538a30f21 Archived-At: Subject: [IPsec] review of draft-pauly-ipsecme-split-dns-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 19:31:27 -0000 --001a1147218ae1e49a0538a30f21 Content-Type: text/plain; charset=UTF-8 Hi, Please find my review for draft-pauly-ipsecme-split-dns-01. The comments and reviews provided does not prevent the draft to be accepted as WG document. I think the document should be accepted as WG document. BR, Daniel Split-DNS Configuration for IKEv2 draft-pauly-ipsecme-split-dns-01 Abstract This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that define sets of private DNS domains which should be resolved by DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. > MGLT: "define" is repeated and the sentence is quite long.... 1. Introduction The Internet Key Exchange protocol version 2 [RFC7296] negotiates configuration parameters using Configuration Payload Attribute Types. This document defines two Configuration Payload Attribute Types that add support for trusted split-DNS domains. 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. The INTERNAL_DNSSEC_TA attribute type is used to convey DNSSEC trust anchors for those domains. When only a subset of traffic is routed into a private network using an IPSec SA, this Configuration Payload option can be used to define which private domains should be resolved through the IPSec connection without affecting the client's global DNS resolution. For the purposes of this document, DNS servers accessible through an IPsec connection will be referred to as "internal DNS servers", and other DNS servers will be referred to as "external DNS servers". > MGLT: Maybe that would be helpful to clarify if the DNS server is a resolution or > authoritative DNS server. Maybe "internal DNS resolver" would > be more appropriated. > I think that the paragraph "When...." defines the problem statement > and the first "The Internet..." defines the solution. It might > be clearer to invert the two paragraphs. > I think the motivation should be better exposed. The reason > you need the options are: > - 1) When you have multiple interface to be able to define > for which domain name the DNS query MUST be sent to internal resolver. > - 2) When DNSSEC resolution is activated, you need the TA to > validate internal resolutions. > Note, that the architecture implies that my resolution goes through > the internal resolver. In other words, the mobile cannot have a > resolver that directly queries the authoritative servers. Maybe that > would be good the NS are also provided by a INTERNAL_NS_DOMAIN 3. Protocol Exchange > MGLT: I think the section is missing text that provides an > overview of the protocol. > The purpose of the information exchanged between the VPN > client and the gateway are expected to provide the necessary > information so the VPN client be informed properly of the > domains that resolve differently internally than externally. > In addition, some extra material should be provided so the > resolution can appropriately be performed. > > The purpose of the INTERNAL_DNS_DOMAIN attribute is to > inform the client of domains whose internal resolution > defers from the external resolution. When the > INTERNAL_DNS_DOMAIN the client is expected to receive all > domains whose private resolution differs for external > resolution. In addition, the client can also restrict the > request for a list of FQDN, in which case an optional domain > is associated to INTERNAL_DNS_DOMAIN. In this case, the > response will mostly indicate whether the specified domain > has a private resolution that differs from the external > resolution. In case the client wants to submit a list, > multiple INTERNAL_DNS_DOMAIN attributes will be > provided in the request. > In order to enable the client to perform the proivate > resolution, the private network should provide some > entry points the queries should be sent to. This could > include internal resolver INTERNAL_IP*_DNS or the > authoritative servers IP addresses INTERNAL_IP*_NS. > In addition, when DNSSEC is used, information of the > private trust anchor should be provided INTERNAL_DNSSEC_TA. 3.1. Configuration Request To indicate support for split-DNS, an initiator sending a CFG_REQUEST payload MAY include one or more INTERNAL_DNS_DOMAIN attributes as defined in Section 4. If an INTERNAL_DNS_DOMAIN attribute is included in the CFG_REQUEST, the initiator SHOULD also include one or both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in its CFG_REQUEST. > MGLT: My understanding is that INTERNAL_IP4_DNS and INTERNAL_IP6_DNS > only concerns the resolution. As resolution could be performed through > the resolvers as well as by the client I would treat this aspect and > the recommendations a separate section. The resolution could be for > example performed by a resolver on the client in which case NS > records may be requested by the client. 3.2. Configuration Reply > MGLT: this is a recommendation I would dissociate > it from the normative description. If an INTERNAL_DNS_DOMAIN attribute is included in the CFG_REPLY, the responder SHOULD also include one or both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in its CFG_REPLY. For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute, an INTERNAL_DNSSEC_TA attribute may be included by the responder. This attribute lists the corresponding DSSNEC trust anchor in the presentation format of a DS record as specified in [RFC4034]. > MGLT: Maybe that would be good to have a INTERNAL_NS attribute. > Also one domain name may have multiple TA, I think it would be > wiser to be able to have multiple TA payload associated to one > domain. 4. Payload Formats 4.2. INTERNAL_DNSSEC_TA Configuration Attribute 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ DNSSEC TRUST ANCHOR ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA. o Length (2 octets, unsigned integer) - Length of DNSSEC Trust Anchor data. o DNSSEC Trust anchor (multiple octets) - The presentation format of one DS record as specified in [RFC4034]. The TTL value MAY be omited and when present MUST be ignored. The domain name is specified as a Fully Qualified Domain Name (FQDN) - irrespective of the presence of a trailing dot, and consits of a string of ASCII characters with labels separated by dots and uses IDNA [RFC5890] for non-ASCII DNS domains. The value is NOT null- terminated. > MGLT: I think that is better to use the wire format than the string format. > I do not understand why the TTL is ignored. I also think that > would be important in case of KSK roll-over. > Maybe some text could mention that multiple TA can be added > especially during the key roll over. > In addition, I think additional text shoudl be provided to clarify > what ar ethe advanatges of using a DS reccord. In fact providing > the KSK in stead of the DS prevent teh client to request the KSK.... > so it seems the KSK will anyway be transmitted. 5. Split-DNS Usage Guidelines If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes, the client MAY use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS servers as the default DNS server(s) for all queries. For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client SHOULD 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 SHOULD NOT attempt to resolve the provided DNS domains using its external DNS servers. > MGLT: This may come with some privacy issues. So I would rather > let the client chose if the domain is in relation with an internal > resolution. If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes, the client SHOULD configure its DNS resolver to resolve those domains and all their subdomains using only the DNS resolver(s) listed in that CFG_REPLY message. If those resolvers fail, those names SHOULD NOT be resolved using any other DNS resolvers. All other domain names MUST be resolved using some other external DNS resolver(s), configured independently, and SHOULD NOT be sent to the internal DNS resolver(s) listed in that CFG_REPLY message. For example, if the INTERNAL_DNS_DOMAIN attribute specifies "example.com", then "example.com", "www.example.com" and "mail.eng.example.com" MUST be resolved using the internal DNS resolver(s), but "anotherexample.com" and "ample.com" MUST be resolved using the system's external DNS resolver(s). > MGLT: Unless i am missing some point I would rather mention this as a > SHOULD. This appears to me more a policy. --001a1147218ae1e49a0538a30f21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find my revie= w for draft-pauly-ipsecme-split-dns-01. The comments and reviews provided d= oes not prevent the draft to be accepted as WG document. I think the docume= nt should be accepted as WG document.

BR,
Dan= iel



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Split-DNS Configurat= ion for IKEv2
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-pauly-ipsec= me-split-dns-01

Abstract

=C2=A0=C2=A0 This document defines t= wo Configuration Payload Attribute Types for
=C2=A0=C2=A0 the IKEv2 prot= ocol that define sets of private DNS domains which
=C2=A0=C2=A0 should b= e resolved by DNS servers reachable through an IPsec
=C2=A0=C2=A0 connec= tion, while leaving all other DNS resolution unchanged.

> MGLT: &= quot;define" is repeated and the sentence is quite long....
=C2=A0<= br>
1.=C2=A0 Introduction

=C2=A0=C2=A0 The Internet Key Exchange = protocol version 2 [RFC7296] negotiates
=C2=A0=C2=A0 configuration param= eters using Configuration Payload Attribute Types.
=C2=A0=C2=A0 This doc= ument defines two Configuration Payload Attribute Types that
=C2=A0=C2= =A0 add support for trusted split-DNS domains.=C2=A0 The INTERNAL_DNS_DOMAI= N
=C2=A0=C2=A0 attribute type is used to convey one or more DNS domains = that should
=C2=A0=C2=A0 be resolved only using the provided DNS nameser= ver IP addresses,
=C2=A0=C2=A0 causing these requests to use the IPSec c= onnection.=C2=A0 The
=C2=A0=C2=A0 INTERNAL_DNSSEC_TA attribute type is u= sed to convey DNSSEC trust
=C2=A0=C2=A0 anchors for those domains.=C2=A0= When only a subset of traffic is routed
=C2=A0=C2=A0 into a private net= work using an IPSec SA, this Configuration Payload
=C2=A0=C2=A0 option c= an be used to define which private domains should be resolved
=C2=A0=C2= =A0 through the IPSec connection without affecting the client's global<= br>=C2=A0=C2=A0 DNS resolution.=C2=A0 For the purposes of this document, DN= S servers
=C2=A0=C2=A0 accessible through an IPsec connection will be re= ferred to as
=C2=A0=C2=A0 "internal DNS servers", and other DN= S servers will be referred to as
=C2=A0=C2=A0 "external DNS servers= ".

> MGLT: Maybe that would be helpful to clarify if the DNS= server is a resolution or
> authoritative DNS server. Maybe "in= ternal DNS resolver" would
> be more appropriated.
> I thi= nk that the paragraph "When...." defines the problem statement> and the first "The Internet..." defines the solution. It mi= ght
> be clearer to invert the two paragraphs.

> I think th= e motivation should be better exposed. The reason
> you need the opti= ons are:
>=C2=A0=C2=A0=C2=A0 - 1) When you have multiple interface to= be able to define
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = for which domain name the DNS query MUST be sent to internal resolver.
= >=C2=A0=C2=A0=C2=A0 - 2) When DNSSEC resolution is activated, you need t= he TA to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 validate = internal resolutions.
> Note, that the architecture implies that my r= esolution goes through
> the internal resolver. In other words, the m= obile cannot have a
>=C2=A0 resolver that directly queries the author= itative servers. Maybe that
> would be good the NS are also provided = by a INTERNAL_NS_DOMAIN
=C2=A0=C2=A0=C2=A0=C2=A0


3.=C2=A0 Pr= otocol Exchange

> MGLT: I think the section is missing text that = provides an
> overview of the protocol.
> The purpose of the in= formation exchanged between the VPN
> client and the gateway are exp= ected to provide the necessary
> information so the VPN client be inf= ormed properly of the
> domains that resolve differently internally t= han externally.
> In addition, some extra material should be provided= so the
> resolution can appropriately be performed.
>
>= The purpose of the INTERNAL_DNS_DOMAIN attribute is to
> inform the= client of domains whose internal resolution
> defers from the extern= al resolution. When the
> INTERNAL_DNS_DOMAIN the client is expected= to receive all
> domains whose private resolution differs=C2=A0 for= external
> resolution. In addition, the client can also restrict th= e
> request for a list of FQDN, in which case an optional domain
= > is associated to INTERNAL_DNS_DOMAIN. In this case, the
> respo= nse will mostly indicate whether the specified domain
> has a private= resolution that differs from the external
> resolution. In case the= client wants to submit a list,
> multiple INTERNAL_DNS_DOMAIN attrib= utes will be
> provided in the request.

> In order to enab= le the client to perform the proivate
> resolution, the private netwo= rk should provide some
> entry points the queries should be sent to. = This could
> include internal resolver INTERNAL_IP*_DNS or the
&= gt; authoritative servers IP addresses INTERNAL_IP*_NS.
> In additio= n, when DNSSEC is used, information of the
> private trust anchor sh= ould be provided INTERNAL_DNSSEC_TA.

=C2=A0

3.1.=C2=A0 Config= uration Request

=C2=A0=C2=A0 To indicate support for split-DNS, an i= nitiator sending a CFG_REQUEST
=C2=A0=C2=A0 payload MAY include one or m= ore INTERNAL_DNS_DOMAIN attributes as
=C2=A0=C2=A0 defined in Section 4.=



=C2=A0=C2=A0 If an INTERNAL_DNS_DOMAIN attribute is
=C2= =A0=C2=A0 included in the CFG_REQUEST, the initiator SHOULD also include on= e or
=C2=A0=C2=A0 both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attr= ibutes in its
=C2=A0=C2=A0 CFG_REQUEST.
=C2=A0=C2=A0
> MGLT: M= y understanding is that INTERNAL_IP4_DNS and INTERNAL_IP6_DNS
> only = concerns the resolution. As resolution could be performed through
> t= he resolvers as well as by the client I would treat this aspect and
>= ; the recommendations a separate section. The resolution could be for
&g= t; example performed by a resolver on the client in which case NS
> = records may be requested by the client.
=C2=A0=C2=A0
=C2=A0
3.2.= =C2=A0 Configuration Reply

=C2=A0
=C2=A0=C2=A0
=C2=A0> MGL= T: this is a recommendation I would dissociate
=C2=A0> it from the n= ormative description.

=C2=A0If an
=C2=A0=C2=A0 INTERNAL_DNS_DOMA= IN attribute is included in the CFG_REPLY, the
=C2=A0=C2=A0 responder SH= OULD also include one or both of the INTERNAL_IP4_DNS and
=C2=A0=C2=A0 I= NTERNAL_IP6_DNS attributes in its CFG_REPLY.

=C2=A0

=C2=A0= =C2=A0 For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute, a= n
=C2=A0=C2=A0 INTERNAL_DNSSEC_TA attribute may be included by the respo= nder.=C2=A0 This
=C2=A0=C2=A0 attribute lists the corresponding DSSNEC t= rust anchor in the
=C2=A0=C2=A0 presentation format of a DS record as sp= ecified in [RFC4034].

> MGLT: Maybe that would be good to have a = INTERNAL_NS attribute.
> Also one domain name may have multiple TA, = I think it would be
> wiser to be able to have multiple TA payload a= ssociated to one
> domain.
=C2=A0


4.=C2=A0 Payload Fo= rmats



4.2.=C2=A0 INTERNAL_DNSSEC_TA Configuration Attribute<= br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3
=C2= =A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0=C2=A0 |R|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A= ttribute Type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2= =A0=C2=A0 ~=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DNSSEC TRUST ANCH= OR=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~
=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+

=C2=A0=C2=A0 o=C2=A0 Reserved (1 bit) - Defined in IKEv= 2 RFC [RFC7296].

=C2=A0=C2=A0 o=C2=A0 Attribute Type (15 bits) [TBD = IANA] - INTERNAL_DNSSEC_TA.

=C2=A0=C2=A0 o=C2=A0 Length (2 octets, u= nsigned integer) - Length of DNSSEC Trust
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Anchor data.

=C2=A0=C2=A0 o=C2=A0 DNSSEC Trust anchor (multiple oct= ets) - The presentation format of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 one DS = record as specified in [RFC4034].=C2=A0 The TTL value MAY be
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 omited and when present MUST be ignored.=C2=A0 The do= main name is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specified as a Fully Qualifi= ed Domain Name (FQDN) - irrespective
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of t= he presence of a trailing dot, and consits of a string of
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ASCII characters with labels separated by dots and uses = IDNA
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC5890] for non-ASCII DNS domains.= =C2=A0 The value is NOT null-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 terminated.=

> MGLT: I think that is better to use the wire format than the s= tring format.
> I do not understand why the TTL is ignored. I also t= hink that
> would be important in case of KSK roll-over.
> Ma= ybe some text could mention that multiple TA can be added
> especiall= y during the key roll over.
> In addition, I think additional text s= houdl be provided to clarify
> what ar ethe advanatges of using a DS = reccord. In fact providing
> the KSK in stead of the DS prevent teh c= lient to request the KSK....
> so it seems the KSK will anyway be tr= ansmitted.

=C2=A0=C2=A0=C2=A0 =C2=A0
5.=C2=A0 Split-DNS Usage G= uidelines

=C2=A0=C2=A0 If a CFG_REPLY payload contains no INTERNAL_D= NS_DOMAIN attributes,
=C2=A0=C2=A0 the client MAY use the provided INTER= NAL_IP4_DNS or INTERNAL_IP6_DNS
=C2=A0=C2=A0 servers as the default DNS = server(s) for all queries.

=C2=A0=C2=A0 For each INTERNAL_DNS_DOMAIN= entry in a CFG_REPLY payload, the client
=C2=A0=C2=A0 SHOULD use the pr= ovided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS
=C2=A0=C2=A0 servers as = the only resolvers for the listed domains and its sub-
=C2=A0=C2=A0 doma= ins and it SHOULD NOT attempt to resolve the provided DNS domains
=C2=A0= =C2=A0 using its external DNS servers.
=C2=A0=C2=A0
> MGLT: This = may come with some privacy issues. So I would rather
> let the client= chose if the domain is in relation with an internal
> resolution.

=C2=A0=C2=A0 If a CFG_REPLY contains one or more INTERNAL_DNS_DOMA= IN attributes,
=C2=A0=C2=A0 the client SHOULD configure its DNS resolver= to resolve those domains
=C2=A0=C2=A0 and all their subdomains using on= ly the DNS resolver(s) listed in
=C2=A0=C2=A0 that CFG_REPLY message.=C2= =A0 If those resolvers fail, those names SHOULD
=C2=A0=C2=A0 NOT be reso= lved using any other DNS resolvers.=C2=A0 All other domain

=C2=A0=C2= =A0 names MUST be resolved using some other external DNS resolver(s),
= =C2=A0=C2=A0 configured independently, and SHOULD NOT be sent to the intern= al DNS
=C2=A0=C2=A0 resolver(s) listed in that CFG_REPLY message.=C2=A0 = For example, if the
=C2=A0=C2=A0 INTERNAL_DNS_DOMAIN attribute specifies= "example.com", then
=C2=A0= =C2=A0 "example.com", "www.example.com" and "mail.eng.example.com" MUST be=C2=A0=C2=A0 resolved using the internal DNS resolver(s), but "anotherexample.com"
=C2=A0=C2= =A0 and "ample.com" MUST be reso= lved using the system's external DNS
=C2=A0=C2=A0 resolver(s).
> MGLT: Unless i am missing some point I would rather mention this as = a
> SHOULD. This appears to me more a policy.
=C2=A0=C2=A0

--001a1147218ae1e49a0538a30f21-- From nobody Fri Jul 29 06:59:59 2016 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 0970312D587 for ; Fri, 29 Jul 2016 06:59:59 -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 A5MfY9FVeb5s for ; Fri, 29 Jul 2016 06:59:56 -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 D4EDC12D14A for ; Fri, 29 Jul 2016 06:59:55 -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 u6TDxpb2004537 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 29 Jul 2016 16:59:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6TDxoNL003897; Fri, 29 Jul 2016 16:59:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22427.24918.927984.329978@fireball.acr.fi> Date: Fri, 29 Jul 2016 16:59:50 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 14 min Archived-At: Subject: [IPsec] Some comments to the draft-ietf-ipsecme-safecurves-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:59:59 -0000 I was checking this document to see if it is ready for WGLC, and here are some nits I found: In the introduction there is text like : [RFCxxx] describes two elliptic curves... where [RFCxxx] is the reference. I would be better to rewrite this in form of: The "Elliptic Curves for Security" document [RFCxxxx] describes two elliptic curves. I.e., make the text understandable for even those who do not remember which RFC number matchi which document. -- Also change "xx" and "yy" to TBA1 and TBA2 in section 3, and remove the "Both are TBA by IANA" at the end of that section, this will be part of the IANA Considerations section. -- Also to same change in 3.1. -- For the IANA considerations section it is better to put also the table format of the allocations, and exactly specify the registry. Registry is "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry of the "Internet Key Exchange Version 2 (IKEv2) Parameters", and the entries will look like this: Number Name Recipient Tests Reference ------ ---- --------------- --------- TBA1 Curve25519 [RFCxxxx], Sec 3.2 [RFCxxxx] TBA2 Curve448 [RFCxxxx], Sec 3.2 [RFCxxxx] -- It would be really good to have appendix with test vectors and example payloads. -- I think the current document is good enough to start WGLC, but as it is going to expire in 5 days, I think it would be better to get new version out and start WGLC after that. -- kivinen@iki.fi From nobody Sat Jul 30 09:48:33 2016 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 B8CB612D105 for ; Sat, 30 Jul 2016 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 2q-NKqHIlXrn for ; Sat, 30 Jul 2016 09:48:30 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C2F12B018 for ; Sat, 30 Jul 2016 09:48:30 -0700 (PDT) Received: from [10.32.60.46] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u6UGmS51062309 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 30 Jul 2016 09:48:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.46] From: "Paul Hoffman" To: "ipsec@ietf.org WG" Date: Sat, 30 Jul 2016 09:48:27 -0700 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [IPsec] draft-pauly-ipsecme-split-dns-01 discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 16:48:32 -0000 Greetings. I support the adoption of this draft as a WG document. I have a minor editorial quibble (it should be "split DNS" instead of "Split-DNS"), and would like a reference to RFC 2775, but those can be dealt with as the WG discusses the document. --Paul Hoffman