From nobody Fri Feb 1 07:20:08 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007A1126DBF for ; Fri, 1 Feb 2019 07:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 DpknkuswGNwa for ; Fri, 1 Feb 2019 07:20:01 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B4112426A for ; Fri, 1 Feb 2019 07:20:01 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43rgl2350VzCqQ; Fri, 1 Feb 2019 16:19:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1549034398; bh=dodM3jfMaIunlmzudpQSG87yYq8jYnXuFWN1Q7aXg+0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QAcscHl4exsKQa0IbBUExNO7hLn4z3OLXg88slHQAxBKU5ec1bNbFNZWUPY0PQm2h OYc5D3W0dNKjU8cGeDAPWKgOHiltgee7vs9PmIRnHaX4wfQiyr+e7vyMY+1YWMyiI2 KnynzV2hHJ2Ay3JCbGj4fJQBkR2DPi3zvIVhgJo4= 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 F4Pag0OnrjuZ; Fri, 1 Feb 2019 16:19:57 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 1 Feb 2019 16:19:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3C9682FCE6; Fri, 1 Feb 2019 10:19:55 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3C9682FCE6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 333BE40D358A; Fri, 1 Feb 2019 10:19:55 -0500 (EST) Date: Fri, 1 Feb 2019 10:19:55 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23634.4035.789424.105343@fireball.acr.fi> Message-ID: References: <23632.25995.122235.479522@fireball.acr.fi> <23632.41405.35211.261763@fireball.acr.fi> <23634.2033.574105.617057@fireball.acr.fi> <23634.4035.789424.105343@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 15:20:05 -0000 On Wed, 30 Jan 2019, Tero Kivinen wrote: > No. Only change the reference to the document that says those > algorithms are MUST NOT. You wanted clickable link to document that > will tell the status. This results in what you asked for.... > > Having obsolete or deprecated in reference column in addition to the > RFC8221/8247 reference would be bigger change, and then I think > die-die-die document would be better reference and that document could > ask IANA to make the changes. Shouldn't that be a 8221bis / 8247bis document ? I'm happy to write a separate diediedie document, but it would sort of break the cycle of our IKE and ESP/AH document updates? Paul From nobody Sat Feb 2 09:05:20 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA8126BED for ; Sat, 2 Feb 2019 09:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 agvCFJfuKTTB for ; Sat, 2 Feb 2019 09:05:16 -0800 (PST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (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 0082B124C04 for ; Sat, 2 Feb 2019 09:05:15 -0800 (PST) Received: by mail-lj1-f177.google.com with SMTP id t18-v6so8442629ljd.4 for ; Sat, 02 Feb 2019 09:05:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vhn3+M+me4LFp8kaL9D5Mo5XSP44SnNybuaRcmeYk9w=; b=hquyB7FxmznCw6hs50lwhhMAEdmmQtRiG45F6T7fQkYQXOR3AJg9g3eAib9Fxqtt7S u0dFMAJa+I0qWQ+7xcJDY2megLsLSEAY4stXO0dbSe6utTDY/HstnjGqbBtcmfbhMEHx amuLu3LBBr45i3AQyBIhuFfygAj4jwBPJ46CgNl8aFgY38/6nsEMBBkT1vWb74CgD321 XFJrGJJhA/JcBxjKjCZE6aLIRsmC+prXkpaCysFWBdbrSXe2hzjbg7VOO8H0pkkbGdmH fUs3Laow368704jAGzbznX8n/iFw/UGzZgxdHC/zU6vgmX5gzWDcbsVPoOVwZj1LdYY+ HmWQ== X-Gm-Message-State: AJcUukdc8zWxxeeZZTDoMSsWaCSvv4rrm0jRV6MD+LNoMzXBJVOquCIe 06qWBbp2oLkgxgp8L+s4kdADel5uRCnDP/WcUM0= X-Google-Smtp-Source: ALg8bN7ddhpaNDKEF88b/IHf54tOQwW6Bmp3o8eFS0jkhiX8TEGSEYB9tP6GF+PNq7Oo26X9Mz/WLLDTw6SWOqdof2g= X-Received: by 2002:a2e:45d:: with SMTP id 90-v6mr36014910lje.110.1549127113976; Sat, 02 Feb 2019 09:05:13 -0800 (PST) MIME-Version: 1.0 References: <23632.25995.122235.479522@fireball.acr.fi> <23632.41405.35211.261763@fireball.acr.fi> <23634.2033.574105.617057@fireball.acr.fi> <23634.4035.789424.105343@fireball.acr.fi> In-Reply-To: From: Daniel Migault Date: Sat, 2 Feb 2019 12:05:01 -0500 Message-ID: To: Paul Wouters Cc: Tero Kivinen , IPsecME WG Content-Type: multipart/alternative; boundary="00000000000057306b0580ec4365" Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 17:05:19 -0000 --00000000000057306b0580ec4365 Content-Type: text/plain; charset="UTF-8" For now, I am fine either ways (reference or note) as long as the up-to date recommendations documents are "obviously" visible on the IANA page. If we want to have further changes, I believe we should have a sort of policy document that clarify / define the IANA page. In curdle we have long being confronted to the issue what reference should be placed in the IANA page as well as what information should be placed as a reference: the document creating the registry, document updating this document, the document describing the algorithm, the document obsoleting... There is no one single rule! I also believe that is an important document to have and we should keep that simple. In a future version of the IANA page, I am personally, I am in favor of having clearly deprecated/obsolete/historic in the column. Yours, Daniel On Fri, Feb 1, 2019 at 10:20 AM Paul Wouters wrote: > On Wed, 30 Jan 2019, Tero Kivinen wrote: > > > No. Only change the reference to the document that says those > > algorithms are MUST NOT. You wanted clickable link to document that > > will tell the status. This results in what you asked for.... > > > > Having obsolete or deprecated in reference column in addition to the > > RFC8221/8247 reference would be bigger change, and then I think > > die-die-die document would be better reference and that document could > > ask IANA to make the changes. > > Shouldn't that be a 8221bis / 8247bis document ? > > I'm happy to write a separate diediedie document, but it would sort of > break the cycle of our IKE and ESP/AH document updates? > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --00000000000057306b0580ec4365 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For now, I am fine either ways (reference or note) as= long as the up-to date recommendations documents are "obviously"= visible on the IANA page. If we want to have further changes, I believe we= should have a sort of policy document that clarify / define the IANA page.=
In curdle we have long being confronted to the issue what r= eference should be placed in the IANA page as well as what information shou= ld be placed as a reference: the document creating the registry, document u= pdating this document, the document describing the algorithm, the document = obsoleting...=C2=A0 There is no one single rule!=C2=A0 I also believe that = is an important document to have and we should keep that simple.
<= div>In a future version of the IANA page, I am personally, I am in favor of= having clearly deprecated/obsolete/historic in the column.
=
Yours,
Daniel

On Fri, Feb 1, 2019 = at 10:20 AM Paul Wouters <paul@nohats.= ca> wrote:
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--00000000000057306b0580ec4365-- From nobody Sat Feb 2 10:48:43 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861441277CC for ; Sat, 2 Feb 2019 10:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lbr3yKyBwsxE for ; Sat, 2 Feb 2019 10:48:39 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DAC126C7E for ; Sat, 2 Feb 2019 10:48:39 -0800 (PST) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [99.249.53.27]) by relay.sandelman.ca (Postfix) with ESMTPS id D56601F42E; Sat, 2 Feb 2019 18:48:37 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8E94C1101; Sat, 2 Feb 2019 13:48:14 -0500 (EST) From: Michael Richardson To: Paul Wouters cc: "ipsec\@ietf.org WG" In-reply-to: References: <22096.1548970581@localhost> Comments: In-reply-to Paul Wouters message dated "Thu, 31 Jan 2019 23:05:22 -0500." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sat, 02 Feb 2019 13:48:14 -0500 Message-ID: <13775.1549133294@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] RFC 4945 IPsec profiles and foot^W text bullets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 18:48:42 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > It's entertaining to see WireGuard go through the same. Certificates > are too complex and annoying, lets only support raw keys. We tried that > 25 years ago :) "Entertaining" is definitely a word. As if the ESP part of security was ever the problem. > And the other issue is that if you want to use a certificate for IKE > and TLS (eg an SSL VPN), then you have two PKIX profiles that might > actually have contractory constrains or requirements. Exactly. > Additionally, > whether you like it or not such a combined certificate will be forced > to comply to CAB/forum. As an expale, loading your LetsEncrypt > certificate into IKE to use it for SSL-VPN and IPsec VPNs. I think that it should be possible to use LE certificate as part of a pinned-down certificate for IKE. It's way better than PSK. > I think actual deployment, and what is specified in RFCs, at least in > RFC 4945, has diverted quite a bit. I think 4945 needs to be updated. > But that update would almost have to be "TLS compliant", so it > basically comes down to "ignore all the 4945 stuff". I would go for replacing 4945. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlxV5e4ACgkQlUzhVv38 QpD8cgf8CQLVfm4bfGJwIN7LDXi7dasQOEec2GB1pHJSKNkfWFltrOS3wSnGH49Y hJwCecBUaCBqNCdqQuC/25j+o5n3ajRBknzH4kCvgdiTn1tXoPdinKACOzfjKvh2 JlohOcvjHhhl9p3YOzdgEL8bxPAzB2P+VxV/FZhLyj+n9/qAS0XVxQ7BwHrD8ybm jaidxSV24y/dJR3y1Kelfnj8vNZZb6/8U5MsTbRMa/e0jMWs0qVY7dZW3TdIlbHR TKyDb/zRuirzND5wCuI/1trCR4vSPkifSm7giGuN1THU17x3iyo6ctWNSr9tIYKC KUvVe7cltVE5ect7CmhZ3IUhPSmUTg== =XuuZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 4 09:39:48 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15A6130EB1 for ; Mon, 4 Feb 2019 09:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Eklr2E8qr5D for ; Mon, 4 Feb 2019 09:39:44 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48BF1130EB2 for ; Mon, 4 Feb 2019 09:39:43 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x14Hdd4l000405 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Feb 2019 19:39:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x14HddcH003472; Mon, 4 Feb 2019 19:39:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23640.30939.242479.305295@fireball.acr.fi> Date: Mon, 4 Feb 2019 19:39:39 +0200 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 22 min Archived-At: Subject: [IPsec] RFC 4945 IPsec profiles and foot^W text bullets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 17:39:47 -0000 Paul Wouters writes: > 5.1.3. X.509 Certificate Extensions > > Conforming IKE implementations MUST recognize extensions that must or > may be marked critical according to this specification. These > extensions are: KeyUsage, SubjectAltName, and BasicConstraints. > > [...] > > With respect to > compliance with the PKIX certificate profile, IKE implementations > processing certificates MAY ignore the value of the criticality bit > for extensions that are supported by that implementation, but MUST > support the criticality bit for extensions that are not supported by > that implementation. That is, a relying party SHOULD processes all > the extensions it is aware of whether the bit is true or false -- the > bit says what happens when a relying party cannot process an > extension. This is the important part for you. I.e., critical bit DOES NOT affect the processing of the extension if it is understood and is can be parsed. If implementation does not understand some extension then critical bit is inspecteded, and if it is TRUE the validation fails. If it is FALSE, then extension can safely be ignored. Or as rfc5280 puts it: (o) Recognize and process any other critical extension present in the certificate. Process any other recognized non-critical extension present in the certificate that is relevant to path processing. If it marked as critical, you must recognize and process it. The contents of the extension is then policy matter. > So what should a crypto library do? > > - Ignore all EKU's in IPsec profile mode? It can do that, as long as that is policy decicion that is done by the code. I.e., if it understands what EKU is and has a policy that is configured to allow all extended key usage values always, then from outside it is just same as ignoring the whole EKU. > - Ignore the critical flag in all EKU's in IPsec profile mode? It can ignore the critical bit as long as it supports EKU. This means if there is any code that understands how to parse EKU and compare it against the configured policy, then it can ignore the critical bit. What the policy is then defined to do, is complete outside the matter of critical bit. If it does not understand what EKU is then it can never find EKU that has critical bit on, it will find unknown extension it does not know about that has critical bit on, and then it needs to fail the validation. > - Consider serverAuth as "supported" or "unsupported" for the IPsec > profile? As I said in most cases IPsec profile for crypto library can just parse the EKU and ignore the contents of it unless there is policy that requires a way to differentiate for example TLS and IPsec certificates. I.e., the default configuration should be that any value of EKU or missing EKU is ok for IPsec profile (i.e., effectively ignore it, except than check that it is formatted correctly). It may also be possible to configure the policy checks so that it does require either id-kp-ipsecIKE or anyExtendedKeyUsage to be present (and it might also require EKU to be present always, or assume certificate is ok even if no EKU is present). > - If "supported", should it ignore the critical flag in IPsec > profile mode? There is no supported or unsupported for values inside the EKU. If the code knows how to parse extended key usage extension then the critical bit does not matter. Critical bit DOES NOT affect for anything that is inside the extension itself (unless it is something that it cannot process, for example there is formatting error inside critical extension, i.e., the contents of the extended key usage exteions is not sequence of object ids). > - Should it consider the above differently depending on id-kp-ipsecIKE > or anyExtendedKeyUsage being present? Depends on the policy. > As for the last question, that is theoretical. This usage is simply > not used in the wild and requiring it is not going to help anyone at > this point. But that is the policy decision code, not the actual certificate parsing part, so that does not depend on the certificate processing library, it depends on the required policy. > Chairs: I think this is a topic worth discussing, because it might make > sense to update 4945 to reflect the reality of dual use certificates > that only have the serverAuth EKU. I think the problem is mostly in the last o Otherwise, reject cert. as that is only needed if "certificate is intended to be used with both IKE and other applications". If certificate is only inteded to be used with IKE, then CAs SHOULD NOT include EKU, but validation can also accept the certificate regardless of the EKU contents. -- kivinen@iki.fi From nobody Mon Feb 4 09:48:13 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC4130EB4 for ; Mon, 4 Feb 2019 09:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RJeaLii5Fh2 for ; Mon, 4 Feb 2019 09:48:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A3F130EB5 for ; Mon, 4 Feb 2019 09:48:09 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x14Hm7N0018650 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Feb 2019 19:48:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x14Hm609028587; Mon, 4 Feb 2019 19:48:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23640.31446.854870.376152@fireball.acr.fi> Date: Mon, 4 Feb 2019 19:48:06 +0200 From: Tero Kivinen To: Paul Wouters Cc: ipsec@ietf.org In-Reply-To: References: <23632.25995.122235.479522@fireball.acr.fi> <23632.41405.35211.261763@fireball.acr.fi> <23634.2033.574105.617057@fireball.acr.fi> <23634.4035.789424.105343@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 17:48:11 -0000 Paul Wouters writes: > On Wed, 30 Jan 2019, Tero Kivinen wrote: > > > No. Only change the reference to the document that says those > > algorithms are MUST NOT. You wanted clickable link to document that > > will tell the status. This results in what you asked for.... > > > > Having obsolete or deprecated in reference column in addition to the > > RFC8221/8247 reference would be bigger change, and then I think > > die-die-die document would be better reference and that document could > > ask IANA to make the changes. > > Shouldn't that be a 8221bis / 8247bis document ? Could be. > I'm happy to write a separate diediedie document, but it would sort of > break the cycle of our IKE and ESP/AH document updates? Writing separate die-die-die document would be faster, and I do not think we have yet any pending changes for the algorithms we have in 8221 and 8247 waiting to be done. -- kivinen@iki.fi From nobody Fri Feb 15 01:26:13 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E76130F28; Fri, 15 Feb 2019 01:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQH47mxYF-6a; Fri, 15 Feb 2019 01:26:08 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8870F130F5F; Fri, 15 Feb 2019 01:26:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 5CBF42025C; Fri, 15 Feb 2019 10:26:06 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPy90gbyYmmj; Fri, 15 Feb 2019 10:26:04 +0100 (CET) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 1D0BD201AE; Fri, 15 Feb 2019 10:26:04 +0100 (CET) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0435.000; Fri, 15 Feb 2019 10:26:03 +0100 From: "Bruckert, Leonie" To: IPsecME WG CC: "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" Thread-Topic: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvn6V9+0SAgC9OHDA= Date: Fri, 15 Feb 2019 09:26:03 +0000 Message-ID: References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> In-Reply-To: <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-guid: 819A69B7-B2DA-4243-A1B3-09EC8CC35D3B x-g-data-mailsecurity-for-exchange-processedonrouted: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 09:26:12 -0000 Hi, The draft specifies how to use additional key exchanges for Child SAs. It s= tates that if several key exchanges are negotiated in CREATE_CHILD_SA, key = shares are transmitted in a series of INFORMATIONAL exchanges. So I was wo= ndering if keys are updated after each INFORMATIONAL exchange, similar as i= ts done with the INTERMEDIATE exchange?=20 Besides, has anybody experiences with fragmenting INFORMATIONAL exchange? I= =92m not aware that INFORMATIONAL exchange has been used to transmit such l= arge payloads before. Regards, Leonie > -----Urspr=FCngliche Nachricht----- > Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Valery Smyslov > Gesendet: Mittwoch, 16. Januar 2019 08:16 > An: IPsecME WG > Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org > Betreff: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hyb= rid- > qske-ikev2-03.txt >=20 > Hi, >=20 > a new version (-03) of the QSKE draft is published. It contains quite a l= ot of > changes from the -02 version: >=20 > 1. Negotiation method is changed to standard (via new Transform Types in > SA payload) > 2. Using multiple key exchanges in the CREATE_CHILD_SA exchange is > addressed > 3. "IKE_AUX" is changed to "INTERMEDIATE" (to align with the draft-smyslo= v- > ipsecme-ikev2-aux-02) > 4. IANA considerations section is added > 5. Temporary IDs for PQ KE methods (using VendorID) are removed >=20 > Please, review the draft. Some issues have already been discussed and the > changes reflect the WG consensus, > some are new and the text reflects only the authors' current opinion. >=20 > Regards, > Valery (for the authors) >=20 > > A new version of I-D, draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > > has been successfully submitted by C. Tjhai and posted to the > > IETF repository. > > > > Name: draft-tjhai-ipsecme-hybrid-qske-ikev2 > > Revision: 03 > > Title: Framework to Integrate Post-quantum Key Exchanges into > Internet Key Exchange Protocol > > Version 2 (IKEv2) > > Document date: 2019-01-14 > > Group: Individual Submission > > Pages: 19 > > URL: https://www.ietf.org/internet-drafts/draft-tjhai-ipsecm= e- > hybrid-qske-ikev2-03.txt > > Status: https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hy= brid- > qske-ikev2/ > > Htmlized: https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-= qske- > ikev2-03 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-tjhai-ipsec= me- > hybrid-qske-ikev2 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tjhai-ipsecme= -hybrid- > qske-ikev2-03 > > > > Abstract: > > This document describes how to extend Internet Key Exchange Protocol > > Version 2 (IKEv2) so that the shared secret exchanged between peers > > has resistance against quantum computer attacks. The basic idea is > > to exchange one or more post-quantum key exchange payloads in > > conjunction with the existing (Elliptic Curve) Diffie-Hellman > > payload. > > > > > > > > > > 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. > > > > The IETF Secretariat >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Feb 15 04:14:22 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085B3130DC9; Fri, 15 Feb 2019 04:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBt8Qfv6Gyq5; Fri, 15 Feb 2019 04:14:18 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 C5DB4124408; Fri, 15 Feb 2019 04:14:17 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id q11so7019738lfd.3; Fri, 15 Feb 2019 04:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=k7CofPUc9UzvayeJXOAVpxIqxcmeTSI6w5Y5H3m7B5M=; b=rsQaNyEl6FpdTC1lu9vtHBbm1GNIkcGgbkM/QnT6xyUvbMSlu1urtTv7ZjOHodhWQK jmhvHfHowQpPxNh5eDl4MrU8nETDrN84IVEbbCneFBpTKEFRFjEORRVzmispERkCSJeW CL6ak2Ya9DVE/8hYdQFP66LN9AvEyqI/yVtLOXQoM1pfw0rFY5d8NK5AfDCh099eAvR7 qfMPRzLvFEU2XV/39Nm/YTPeaqvM6ZEwva2MTBLhJzmcLBXxHXGQ7AxejBt2Hp/4uUww hHOvAYZlBgpZ8xWEOAO0JOPEybcmBiVH3PiXFUpgnDTKHVYb7+SJ3IQol8CYaDuk5Sdr A6zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=k7CofPUc9UzvayeJXOAVpxIqxcmeTSI6w5Y5H3m7B5M=; b=clZIZyYWfZ4XT3MvB/pPl5ZE86Zt37G12idtVbz6V5T7gz7XvL4x9vc3g7uJmgkLNp wDi0c2UZg6xGoG1qM9qCj8s0HkilvyevtkHukEy6BhjqIdYaDDOv5d4kPFx4Yhz9bgw9 Let6GVy0KknLgra2FPK/vcI74FAhuN2MmsK0BFC/3lhyP5/5ixu5J2xB53NZisFevpIL 5ManEHncEalBfWkcn/ZyHTXZPw4gm/VngJJpP1+LrwxfeGhpiF/AlvQwGbk3c/XQin6R q4aQ8c+iwxW3UMwx39CXXCpAGmU7WQam+tmtUy4HLOHnlGGEdIiI/c0tOTXjdyYSr4+Z A0Qw== X-Gm-Message-State: AHQUAuafqqeU4Qd0kRfR4Iies5eEWfKaDLsdOQ1BIyO0oN+jIw/RPy7i HdKqWUf3aWTc5thmOK6bjOhR5Wke X-Google-Smtp-Source: AHgI3IYoqnzrKxqG0WU/t9E3B/d63CETmIXrdUHN52Aw3/a8qNN1lnPGHPWnFwakSY1IBkEEt1lQGw== X-Received: by 2002:a19:4f03:: with SMTP id d3mr4867710lfb.52.1550232855521; Fri, 15 Feb 2019 04:14:15 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r11sm1241286ljb.29.2019.02.15.04.14.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Feb 2019 04:14:14 -0800 (PST) From: "Valery Smyslov" To: "'Bruckert, Leonie'" , "'IPsecME WG'" Cc: References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> In-Reply-To: Date: Fri, 15 Feb 2019 15:14:03 +0300 Message-ID: <012501d4c527$f1400c90$d3c025b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvnwHW2sz0Axgd5xilhfEUYA== Content-Language: ru Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 12:14:20 -0000 Hi Leonie, > Hi, >=20 > The draft specifies how to use additional key exchanges for Child SAs. = It states that if several key exchanges > are negotiated in CREATE_CHILD_SA, key shares are transmitted in a = series of INFORMATIONAL exchanges. > So I was wondering if keys are updated after each INFORMATIONAL = exchange, similar as its done with the > INTERMEDIATE exchange? It's a good question. We haven't discuss this issue yet among authors, = but I think there is no reason=20 (and I believe no reliable way) to update the keys used to protect the = current IKE SA. Instead, we can just use subsequent Key Exchanges as additional inputs = into prf as follows: For IKE SA rekey: SKEYSEED =3D prf(SK_d_current, KE1 | Ni1 | Nr1 | KE2 | Ni2 | Nr2 ... = KEn | Nin | Nrn) For new Child SA or its rekey: KEYMAT =3D prf+(SK_d_current, KE1 | Ni1 | Nr1 | KE2 | Ni2 | Nr2 ... = KEn | Nin | Nrn) where KE1, Ni|r1 - from CREATE_CHILD_SA, other KE and Ni|r - fron = subsequent INFORMATIONAL. But I'd rather let cryptographers comment on this and probably suggest = better ways to do it. And in any case this should definitely be clarified in the draft, as = well as some other things=20 (e.g. how collisions would be handled in this case etc.) > Besides, has anybody experiences with fragmenting INFORMATIONAL = exchange? I=92m not aware that > INFORMATIONAL exchange has been used to transmit such large payloads = before. RFC 7383 explicitly says that if IKE fragmentation was negotiated, then = any subsequent protected=20 exchange may be sent in fragmented form. It's true that so far IKE = fragmentation was=20 primarily used in the IKE_AUTH exchange, however any compliant = implementation must be able to use it in any exchange containing Encrypted payload. Regards, Valery. > Regards, > Leonie >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Valery = Smyslov > > Gesendet: Mittwoch, 16. Januar 2019 08:16 > > An: IPsecME WG > > Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org > > Betreff: Re: [IPsec] New Version Notification for = draft-tjhai-ipsecme-hybrid- > > qske-ikev2-03.txt > > > > Hi, > > > > a new version (-03) of the QSKE draft is published. It contains = quite a lot of > > changes from the -02 version: > > > > 1. Negotiation method is changed to standard (via new Transform = Types in > > SA payload) > > 2. Using multiple key exchanges in the CREATE_CHILD_SA exchange is > > addressed > > 3. "IKE_AUX" is changed to "INTERMEDIATE" (to align with the = draft-smyslov- > > ipsecme-ikev2-aux-02) > > 4. IANA considerations section is added > > 5. Temporary IDs for PQ KE methods (using VendorID) are removed > > > > Please, review the draft. Some issues have already been discussed = and the > > changes reflect the WG consensus, > > some are new and the text reflects only the authors' current = opinion. > > > > Regards, > > Valery (for the authors) > > > > > A new version of I-D, draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > > > has been successfully submitted by C. Tjhai and posted to the > > > IETF repository. > > > > > > Name: draft-tjhai-ipsecme-hybrid-qske-ikev2 > > > Revision: 03 > > > Title: Framework to Integrate Post-quantum Key Exchanges into > > Internet Key Exchange Protocol > > > Version 2 (IKEv2) > > > Document date: 2019-01-14 > > > Group: Individual Submission > > > Pages: 19 > > > URL: = https://www.ietf.org/internet-drafts/draft-tjhai-ipsecme- > > hybrid-qske-ikev2-03.txt > > > Status: = https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hybrid- > > qske-ikev2/ > > > Htmlized: = https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske- > > ikev2-03 > > > Htmlized: = https://datatracker.ietf.org/doc/html/draft-tjhai-ipsecme- > > hybrid-qske-ikev2 > > > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-tjhai-ipsecme-hybrid- > > qske-ikev2-03 > > > > > > Abstract: > > > This document describes how to extend Internet Key Exchange = Protocol > > > Version 2 (IKEv2) so that the shared secret exchanged between = peers > > > has resistance against quantum computer attacks. The basic = idea is > > > to exchange one or more post-quantum key exchange payloads in > > > conjunction with the existing (Elliptic Curve) Diffie-Hellman > > > payload. > > > > > > > > > > > > > > > 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. > > > > > > The IETF Secretariat > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Feb 16 07:48:12 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4CE130EF9; Sat, 16 Feb 2019 07:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mWv4_k17F0T; Sat, 16 Feb 2019 07:48:02 -0800 (PST) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (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 5BEDF1275F3; Sat, 16 Feb 2019 07:48:02 -0800 (PST) Received: by mail-lj1-f174.google.com with SMTP id z25so3028546ljk.8; Sat, 16 Feb 2019 07:48:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fjM90OsfjVfZcKva1VBJ7ZCVovtil0kJiZnlpMYkzSc=; b=aNM6sPcNw1BJi/dPnUu+spBnayGBVVyPlh1Xi8WOBEm/G3fbasIYMUFF7+qTpU3yRb +2dRtZO8I5qJl5CDu98JnvErJk4UTEV+ewGzGnXhOu2+alTGoHPNTKD57bcSdEKNfDj0 azAf096WbDYiP1dThqZcPrQ0IdNXTpnBKX7lkgi/vlR0hSebcRCwW7dp+cwSYd9g5uZN F/QxurovDVKVuHH2bmRY4M/YljU9I3W+i/PP0Dk4Uv5zb2+kK2WYFFJdJ1hrvG0McNOw pKB8hub+d18MFJx0sxvT7D/mrr7Int9uHhZZByP1jfEVfMf5f97GI26p5SMlyawjhV1d S4oA== X-Gm-Message-State: AHQUAuYth/C+iXlXl8Ihx2JQj+6LuLzMKoI4o4uKwQeFCNEdeQfdVCL8 g/FXI42hDh+UGurxeurLZ6OOSniWaMLvoTajxUaWVNWU X-Google-Smtp-Source: AHgI3IYWU738Zm0AxQrUky2fQHoe0kn2kE0Xl0R+ytlv5W56dYdQozHkNO7agwKz054zFLAZqiFhW2+bAeEdANOx8pI= X-Received: by 2002:a2e:6505:: with SMTP id z5mr3413640ljb.180.1550332079900; Sat, 16 Feb 2019 07:47:59 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Sat, 16 Feb 2019 10:47:48 -0500 Message-ID: To: tls , IPsecME WG , saag@ietf.org, nvo3@ietf.org, sfc@ietf.org, quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000e80cf2058204d014" Archived-At: Subject: [IPsec] netdev0x13 - ietf related topics X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 15:48:05 -0000 --000000000000e80cf2058204d014 Content-Type: text/plain; charset="UTF-8" Hi, Please find among many others some IETF related topics [1] that will be discussed at netdev0x13 just before the IETF meeting in Pragues. Early bird registration is open until February 20. !!!! Netdev 0x13 will be held at Hotel Grandium in Prague, this spring March 20th - 22th, 2019 Yours, Daniel [1] https://www.netdevconf.org/0x13/IETF-relevant-talks.html --000000000000e80cf2058204d014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

Please find among many others some IET= F related topics [1] that will be discussed at netdev0x13 just before the IETF meeting in Pragues.

=C2=A0

Early bird registration is open until= =C2=A0February 20.=C2=A0!!!!

=C2=A0

Netdev 0x13 will be held at Hotel Grandium in Prague, this spring March 2= 0th - 22th, 2019=C2=A0


=

Yours,

Daniel

=C2=A0

[1] https://www.netdevconf.org/0x13/IETF-relevant-talks.html


--000000000000e80cf2058204d014-- From nobody Tue Feb 19 21:49:42 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE802130DBE for ; Tue, 19 Feb 2019 21:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v8o7l1UZQu0 for ; Tue, 19 Feb 2019 21:49:38 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64879129619 for ; Tue, 19 Feb 2019 21:49:38 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 08095BEB8EEE91B51F5E for ; Wed, 20 Feb 2019 05:49:36 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 20 Feb 2019 05:49:35 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.82]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0415.000; Wed, 20 Feb 2019 13:48:36 +0800 From: Sandeep Kampati To: "ipsec@ietf.org" CC: "kivinen@iki.fi" , Paul Wouters , "david.waltermire@nist.gov" Thread-Topic: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt Thread-Index: AdTI2h9uvoJc3SMyS6i7jO/S6jdxwA== Date: Wed, 20 Feb 2019 05:48:36 +0000 Message-ID: <2DA788A5A7D91747AEA54B502558D738277E66D1@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.152.117] Content-Type: multipart/alternative; boundary="_000_2DA788A5A7D91747AEA54B502558D738277E66D1DGGEMM506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 05:49:41 -0000 --_000_2DA788A5A7D91747AEA54B502558D738277E66D1DGGEMM506MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I posted the following draft: URL: https://www.ietf.org/id/draft-kampati-ipsecme-ikev2-sa-ts-paylo= ads-opt-00.txt Htmlized: https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-p= ayloads-opt-00 Htmlized: https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa= -ts-payloads-opt/ We would appreciate any discussion and feedback. In 4G network security gateways/ePDG and in 5G networks cRAN/Cloud will sup= port more than 100000 IKE/IPSEC tunnels. So on an average, for every second= we encounter many rekeys. This takes huge amount of bandwidth, packet frag= mentation and more processing. This can be solved by introducing this draft= . This is also useful in Internet of Things (IoT) devices which utilizing low= er power consumption technology. Thanks, Sandeep kampati Email: sandeepkampati@huawei.com --_000_2DA788A5A7D91747AEA54B502558D738277E66D1DGGEMM506MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I posted the following draft:

 

URL:        https://www.ietf.org/id/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.t= xt 

Htmlized:   https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-= 00  

Htmlized:   https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloads= -opt/

 

 

We would appreciate any discussion and feedback.

 

In 4G network security gateways/ePDG and in 5G networks cRAN/Cl= oud will support more than 100000 IKE/IPSEC tunnels. So on an average, for = every second we encounter many rekeys. This takes huge amount of bandwidth, packet fragmentation and more process= ing. This can be solved by introducing this draft.

 

This is also useful in Internet of Things (IoT) devices which u= tilizing lower power consumption technology.

 

 

Thanks,

Sandeep kampati

Email: sandeepkampati@huawei.com

--_000_2DA788A5A7D91747AEA54B502558D738277E66D1DGGEMM506MBXchi_-- From nobody Wed Feb 20 12:40:23 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE64129B88 for ; Wed, 20 Feb 2019 12:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 w1z0SypFFwED for ; Wed, 20 Feb 2019 12:40:18 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F6112950A for ; Wed, 20 Feb 2019 12:40:17 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 444Txp5L2QzHXB; Wed, 20 Feb 2019 21:40:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550695214; bh=evuFSJIO8B0LUmppC6uSHKfNY2CMx+2q+3sesBCcCUk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ze4J6OKPWarMg2bdWJIrtAYWY5jdKiQfCmBmE/BwTCUj2oYH3IItaWv8Vyh5AKIzj JUZT+3IIgaFr8Z9QcaNDwXpdk2hA26PJAfA3ZxS5arIks7upFOLgVh96YicYR4Ts+q vi6S1eSJ7vvsy30fpWEtTVxcNOCU321bibINafJ0= 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 ly2JzuCG6VUJ; Wed, 20 Feb 2019 21:40:12 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Feb 2019 21:40:12 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3772F5C859; Wed, 20 Feb 2019 15:40:11 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3772F5C859 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2FC7640D358A; Wed, 20 Feb 2019 15:40:11 -0500 (EST) Date: Wed, 20 Feb 2019 15:40:11 -0500 (EST) From: Paul Wouters To: Sandeep Kampati cc: "ipsec@ietf.org" In-Reply-To: <2DA788A5A7D91747AEA54B502558D738277E66D1@DGGEMM506-MBX.china.huawei.com> Message-ID: References: <2DA788A5A7D91747AEA54B502558D738277E66D1@DGGEMM506-MBX.china.huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 20:40:21 -0000 On Wed, 20 Feb 2019, Sandeep Kampati wrote: > Htmlized:   https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00   I read the draft and I think it has some good ideas, and a few things I don't like as much :) The idea of not including the SA when rekeying for the identical IPsec or IKE SA looks good to me. Omitting the TS payload in ESP transport mode for rekeying seems okay as well, but does seem to be a bit of a corner case to optimize for. But I can't come up with a strong reason not to do it. There is an issue when there are multiple IPsec SA's - you need the TS to see which one is being rekeyed. So when omitted, you need to send the old SPI? Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in IKE_INIT, it should be send in IKE_AUTH because we can fragment in IKE_AUTH and not in IKE_INIT. It also reduces what a passive attacker can see and fingerprint users/implementations on. I'd also prefer a shorter name than IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED, perhaps call it MINIMAL_REKEY_SUPPORTED ? (we don't prefix with IKEV2 in https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16 Section 3.1 should clarify the payload length is 0? It should clarify the setting of the Critical flag (off) Some clarification should be needed on whether sending the notify means the rekeys MAY or MUST use this new feature. The NEW_SPI should probably have the critical flag set? The example talks about there being a KEi payload, but if there is no PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only covers ike rekey, so then this is right. maybe clarify :) the text states "initiator will send initiator IKE SPI" but that is only true for IKE rekey, not IPsec rekey where it needs to send the IPsec SPI. If there is more than one IPsec SA, then omiting the TS would lead to the responder no longer knowing which IPsec SA is being rekeyed. So perhaps sending the old SPI would be needed. Or if we decide this is too much of a corner case, perhaps we should not allow omittig the TS? I think 3.2.1 should named better, eg "IKE SA rekey without SA" and 3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 is a bit odd. (i misread 3.2.1 making assumptions about child sa) I think a more clear split between ike/child rekey is needed. Currently 3.2.1 is about IKE, 3.2.2. about both? 3.3 again ensure to tell critical flag must be set. I think an OLD_SPI() payload is needed here too. Section 4 needs work :) But in a way it is more secure agains accidental downgrade of cryptographic strength. But also it prevents upgrade of cryptographic strength. Paul