From nobody Sun Jan 3 17:23:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F611AD36E for ; Sun, 3 Jan 2016 17:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EDEcNcM6luZo for ; Sun, 3 Jan 2016 17:23:20 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDECF1AD36A for ; Sun, 3 Jan 2016 17:23:20 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EA0E203B5; Sun, 3 Jan 2016 20:30:24 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1F106636BD; Sun, 3 Jan 2016 20:23:19 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22121.34160.710157.289114@fireball.acr.fi> References: <22121.34160.710157.289114@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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] RFC4307bis and authentication methods X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 01:23:22 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > And he pointed out that this asks for mandatory to implemented key > size for RSA to be 1024 or 2048-bits. So, an implementation could support 1024 and 2048 bit key lengths, but not 1536 bit ones? > I.e. should we modify this also while updating the RFC4307? We could > add section about the mandatory to implement authentication methods, > and specify which methods are to be used, for example require RSA key > lengths of 2048 bits, and perhaps say that implementations SHOULD > support RSA key lengths up to 4096 bits. So, this is different than "2048" and "4096". This text would support a key length of 2304, for instance. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVonJhICLcPvd0N1lAQKioggAvvNlsdM2U2TRa+77w9scqdWasM2X6S23 TqqR8TqHetcoZ0JSBHg1ry8Q1EuejtvpFhg32R9TG0CttGcJBg3NO0Nn1Q5zNUOa c6wFTLmqt4eZbhJci/GP58prNUJP8uehhr1s8LiVLXrjedQyLoiIJQLV78O6xH13 l3pDXIGFbGY4j213eDHKisZLsk2vQZAl6Ywa+ghf0gbgiTCKx8p6UkAWJXIUOEoF wLl2mH4lJP/9Nxof7FDg6I/kXFJ7hEfcxXSRCmSDsgOGGl2dg8rWTRotInSqAkdF l/FAX5yUoybHIhiNByyaiY5YbgebL8oN0tbKYEz0ji9GXO3oYyPWfQ== =CSNI -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 4 13:31:03 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2861AC3B5 for ; Mon, 4 Jan 2016 13:31:01 -0800 (PST) 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 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 XyN5DcI7ASM9 for ; Mon, 4 Jan 2016 13:31:00 -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 A58A91AC3B4 for ; Mon, 4 Jan 2016 13:30:58 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id u04LUrqh021399 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Jan 2016 23:30:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id u04LUrM9018897; Mon, 4 Jan 2016 23:30:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22154.58509.470767.951158@fireball.acr.fi> Date: Mon, 4 Jan 2016 23:30:53 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <24576.1451870599@obiwan.sandelman.ca> References: <22121.34160.710157.289114@fireball.acr.fi> <24576.1451870599@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4307bis and authentication methods X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:31:01 -0000 Michael Richardson writes: > > Tero Kivinen wrote: > > And he pointed out that this asks for mandatory to implemented key > > size for RSA to be 1024 or 2048-bits. > > So, an implementation could support 1024 and 2048 bit key lengths, but not > 1536 bit ones? This is for the PKIX certificates in the authentication, and RFC7296 says that implementations MUST support RSA key sizes of 1024 and 2048 bits. People do not use PKIX certificates with key lengths of 1536 that much... For the Diffie-Hellman implementations do use group 5, which is 1536-bit Diffie-Hellman group, but that is completely separate discussion. > > > I.e. should we modify this also while updating the RFC4307? We could > > add section about the mandatory to implement authentication methods, > > and specify which methods are to be used, for example require RSA key > > lengths of 2048 bits, and perhaps say that implementations SHOULD > > support RSA key lengths up to 4096 bits. > > So, this is different than "2048" and "4096". > This text would support a key length of 2304, for instance. Yes. When you go over 2048 bits, people do not necessarely go to the 4096 bits. Some people do use other sizes too (3072 etc). I think saying that 2048 bits MUST be supported is something we want to specify if we add text about authentication key lengths. Adding text that anything up 4096 bits SHOULD be supported is also useful... -- kivinen@iki.fi From nobody Mon Jan 4 17:31:05 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 BC0711ACE2E; Mon, 4 Jan 2016 17:31:03 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105013103.23315.96954.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 17:31:03 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:31:04 -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 Working Group 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-02.txt Pages : 13 Date : 2016-01-04 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange protocol provides a mechanism to negotiate which algorithms should be used in any given Security Association. 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 will have available. This document defines the current algorithm implementation requirements and usage guidance of IKEv2. 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 5 02:58:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4D01B2A6B for ; Tue, 5 Jan 2016 02:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, SPF_PASS=-0.001] autolearn=ham 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 m8wNDvTc8dEg for ; Tue, 5 Jan 2016 02:58:45 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA461A873A for ; Tue, 5 Jan 2016 02:58:45 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id p203so293999135lfa.0 for ; Tue, 05 Jan 2016 02:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=qsCri0FoYQ1zRQbOpRufId3rsq57ohR+OW3jtQ4muxY=; b=RrQVOoaC360S0GJ8p9RrV1Fr012KycgsMscIPv6Nk6PR7ytc+/ayzXJ96tvK7F74nD 467ypkyp26mZnuYC0bdDkqz1081hCu98cUm5yEmHHXOsuBRVR2l7LgpTJCfo0+6/X21E niOsByAtZqOahGr3SdzQeTFWRG73F3H8SKeyvlhDMWWR7PDU5pRNXFb1PdI1Jjx8/Ksl 8snzG+awpUGdZKQzTwaIfzSgeEmBVMb0nGhnmMQNqCymyeDStuCV5kVgxzfJWgsbcCRe sWKy4j09QcTV/m1IiVaafodI0x7yafjgCcGqa6pGh+oXWhNHEeA1NK5SmbSiE8TlDocq VTlQ== X-Received: by 10.25.152.133 with SMTP id a127mr33039251lfe.152.1451991523232; Tue, 05 Jan 2016 02:58:43 -0800 (PST) Received: from chichi (ppp83-237-42-110.pppoe.mtu-net.ru. [83.237.42.110]) by smtp.gmail.com with ESMTPSA id i192sm4880412lfb.14.2016.01.05.02.58.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jan 2016 02:58:42 -0800 (PST) Message-ID: <747DE08D84C548F3BD34B561352F7146@chichi> From: "Valery Smyslov" To: "Paul Wouters" References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> In-Reply-To: Date: Tue, 5 Jan 2016 13:58:39 +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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 10:58:46 -0000 Hi Paul, thank you for your comments. > This draft makes me nervous, as compression has been removed from > encryption specifications in the last few years. As far as I know IPcomp isn't deprecated, is it? If you mean TLS, then as far as I understand the compression-related attacks on TLS rely on an ability for an attacker to insert specific data into the encrypted (and compressed) stream that contains secret information (e.g. password). I don't think it's relevant to IKE and it is discussed in the Security Considerations section. > I find the security > considerations also weak on this. It basically says "if you think > compression might be security issue, don't use it". Which isn't helpful > at all to implementors. Not really. It says that basically using compression in IKE should be safe. However, IF you transfer secret information inside an IKE SA and IF some part of the IKE messages originates outside IKE, then you are probably at risk. This could happen in case of EAP authentication using weak EAP methods that transfer passwords in clear. Note, that RFC 7296 strongly discourage using such methods. Note, that this is -00 draft and the security considerations are currently very basic. What do you think should be added there? > I am also worried about the security of maliciously compressed payloads, > eg a zillion 0's, and other corner cases such as AUTH-NULL clients. In this case either the decompressor or the message parser will return an error. Note that malicious peer could send zillion 0's even without using compression. A robust implementation should handle such cases. But I think it's a good idea to mention this in the security considerations. > I'm also not yet very convinced about the use case. For instance, the > mentioned explosion of algorithms supported causing big IKE_INIT packets > seems very unlikely for IoT devices which most likely only support 1 or > 2 algorithms anyway. These are two different use cases. For IoT devices the primary benefit is the decrease of the power consumption. For the others the primary benefit is avoiding of an IP fragmentation of the IKE_SA_INIT messages and making IKE Fragmentation less likeky for the rest messages. > Note I'm not strongly against it. I just need more convincing. I'm trying to convince :-) > Paul Regards, Valery. From nobody Tue Jan 5 09:16:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52D91A8A6A for ; Tue, 5 Jan 2016 09:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 jeoW6q_OzAd1 for ; Tue, 5 Jan 2016 09:16:38 -0800 (PST) Received: from hoffman.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 EF3251A874E for ; Tue, 5 Jan 2016 09:16:37 -0800 (PST) Received: from [10.32.60.15] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u05HGX8H084395 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2016 10:16:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.15] From: "Paul Hoffman" To: "Valery Smyslov" Date: Tue, 05 Jan 2016 09:16:53 -0800 Message-ID: In-Reply-To: <747DE08D84C548F3BD34B561352F7146@chichi> References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <747DE08D84C548F3BD34B561352F7146@chichi> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 17:16:38 -0000 On 5 Jan 2016, at 2:58, Valery Smyslov wrote: > Hi Paul, > thank you for your comments. > >> This draft makes me nervous, as compression has been removed from >> encryption specifications in the last few years. > > As far as I know IPcomp isn't deprecated, is it? No, but that's not what PaulW said. > If you mean TLS, then as far as I understand the compression-related > attacks > on TLS rely on an ability for an attacker to insert specific data into > the > encrypted (and compressed) stream that contains secret information > (e.g. password). I don't think it's relevant to IKE and it is > discussed > in the Security Considerations section. No one considered it relevant to TLS until researchers discovered the problems there. I think that's PaulW's point, and one that I agree with. > >> I find the security >> considerations also weak on this. It basically says "if you think >> compression might be security issue, don't use it". Which isn't >> helpful >> at all to implementors. > > Not really. It says that basically using compression in IKE should be > safe. > However, IF you transfer secret information inside an IKE SA and IF > some part of the IKE messages originates outside IKE, > then you are probably at risk. This could happen in case of EAP > authentication using weak EAP methods that transfer passwords in > clear. Note, that RFC 7296 strongly discourage > using such methods. > > Note, that this is -00 draft and the security considerations > are currently very basic. What do you think should be added there? That seems like a premature question. We haven't even decided if the idea of compressing IKE would give the benefits listed, whether the computational cost match the space benefits, and thus should be considered at all. --Paul Hoffman From nobody Tue Jan 5 09:48:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F279D1ACEDC for ; Tue, 5 Jan 2016 09:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=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 a-zgDHX029Yc for ; Tue, 5 Jan 2016 09:48:13 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499CF1ACEA6 for ; Tue, 5 Jan 2016 09:48:13 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pZhBL2Nz0z3FT for ; Tue, 5 Jan 2016 18:48:10 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 w9HchAIDqnVc for ; Tue, 5 Jan 2016 18:48:09 +0100 (CET) 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, 5 Jan 2016 18:48:09 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 46226614A489; Tue, 5 Jan 2016 12:48:07 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 46226614A489 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 415E22608C for ; Tue, 5 Jan 2016 12:48:07 -0500 (EST) Date: Tue, 5 Jan 2016 12:48:07 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <747DE08D84C548F3BD34B561352F7146@chichi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 17:48:19 -0000 On Tue, 5 Jan 2016, Paul Hoffman wrote: >> As far as I know IPcomp isn't deprecated, is it? > > No, but that's not what PaulW said. Indeed, although I would like to deprecate it. It is basically never used by our users that I'm aware of and it adds code complexity. > No one considered it relevant to TLS until researchers discovered the > problems there. I think that's PaulW's point, and one that I agree with. Yes. Which is why I wanted to hear more convincing arguments to justify it. Paul From nobody Tue Jan 5 12:08:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E91A90AC for ; Tue, 5 Jan 2016 12:08:09 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 809xLmGeEVPI for ; Tue, 5 Jan 2016 12:08:08 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD141A90AA for ; Tue, 5 Jan 2016 12:08:07 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id f206so46116900wmf.0 for ; Tue, 05 Jan 2016 12:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9EroIQCCtXUylswe2X/KUUJ4bmQ6PJknoT6cJeL7CT8=; b=MgF21L8+91rB9pnFQ9bGF1/243bK/blPxThvDKUSQn1e/BOvkWrKT+vVTPsFUv4KSn btYTv62fsU1WsRBouP2RtXAWwZ05lusP9xMrp9iB6PTqoMnuK+7XnkAhM/S0FAWX9mPl w0zv6y1i51/eCQ1OT4mz/33vSGMIDw9S6AOXwdmfD9u+WF/22VxAX2gLeygusVAUOWAW 1YhzDB++blSzdXorqGvAizToFDFLdEUkPVnkVbloLOlDHlgB/xr7TrG2DTitQL6+5fw1 yn2e4mlvEkQiT825IFeoF0W8IO3hsqZ7EnJb17X+f6Ee4/88K3a1CUw6f3mC684dBdQH CpaA== X-Received: by 10.194.175.170 with SMTP id cb10mr121967740wjc.36.1452024486333; Tue, 05 Jan 2016 12:08:06 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id q75sm5142424wmd.6.2016.01.05.12.08.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jan 2016 12:08:04 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> Date: Tue, 5 Jan 2016 22:08:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 20:08:10 -0000 Hi, Valery. Thank you for this draft. Having read it, I have some comments. First, the problem of IKE having too large packets in certain = environments is a real problem. We=E2=80=99ve already addressed it with = fragmentation, and the TCP encapsulation draft proposes yet another way. = I think either of those can solve most of the bad router and noisy line = issues. I also think that IKE is quite low-volume so the savings in = number of bytes sent from, say, a mobile phone are not an issue. So the = only scenario where compression may have value is for an IoT device = working on a battery and/or using a particularly slow network. Second, as I understand it, those battery-powered devices tend to use = 802.15.4 networks with 127-byte frames. There=E2=80=99s 6LoWPAN to = provide fragmentation support, but that=E2=80=99s similar to using = IKE=E2=80=99s fragmentation for the same issue. Can anything be done at = all with 127-byte frames, that include the (IPv6?) headers, the 8-byte = UDP header, the 20-byte IKEv2 header in addition to all the payload = headers? If we need fragmentation anyway, I don=E2=80=99t know if = compression matters. Third, I haven=E2=80=99t tested this myself, so I may be all wrong here, = but I question the value of compression on IKE. IKE is a binary protocol = with mostly compact binary payloads. Even the list of supported CAs is a = list of hashes in IKEv2. How much can compression help? Yoav > On 25 Dec 2015, at 2:18 PM, Valery Smyslov wrote: >=20 > Hi, >=20 > I've posted a new draft on using compression in IKEv2. > Comments, thoughts, criticism are very very welcome. >=20 > Regards, > Valery Smyslov. >=20 >=20 >> A new version of I-D, draft-smyslov-ipsecme-ikev2-compression-00.txt >> has been successfully submitted by Valery Smyslov and posted to the >> IETF repository. >> Name: draft-smyslov-ipsecme-ikev2-compression >> Revision: 00 >> Title: Compression in the Internet Key Exchange Protocol Version 2 = (IKEv2) >> Document date: 2015-12-25 >> Group: Individual Submission >> Pages: 17 >> URL: = https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-compressi= on-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compression/ >> Htmlized: = https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-compression-00 >> Abstract: >> This document describes a method for reducing the size of IKEv2 >> messages by means of lossless compression. Making IKEv2 messages >> smaller is desirable for low power consumption battery powered IoT >> devices. It also helps avoid IP fragmentation of IKEv2 messages. >> This document describes how compression is negotiated maintaining >> backward compatibility and how it is used in IKEv2. >> = 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 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 5 21:28:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DD41A92A9 for ; Tue, 5 Jan 2016 21:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=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 7Zrt09CAVhbN for ; Tue, 5 Jan 2016 21:28:25 -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 067701A9143 for ; Tue, 5 Jan 2016 21:28:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pZzkG6P2pzpK for ; Wed, 6 Jan 2016 06:28:22 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 BtRwlxgK37QO for ; Wed, 6 Jan 2016 06:28:20 +0100 (CET) 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 ; Wed, 6 Jan 2016 06:28:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A2135603AF0F; Wed, 6 Jan 2016 00:28:18 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca A2135603AF0F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9EBA826091 for ; Wed, 6 Jan 2016 00:28:18 -0500 (EST) Date: Wed, 6 Jan 2016 00:28:18 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] IKEv2 question on nonce size and SHA2 PRFs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 05:28:27 -0000 IKEv2 (RFC-7296) states: Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated pseudorandom function (PRF). For SHA2 versions of PRF, we need to look at RFC-4868: http://tools.ietf.org/html/rfc4868#section-2.4 The PRF-HMAC-SHA-256 algorithm is identical to HMAC-SHA-256-128, except that variable-length keys are permitted, and the truncation step is NOT performed. Likewise, the implementations of PRF-HMAC- SHA-384 and PRF-HMAC-SHA-512 are identical to those of HMAC-SHA-384- 192 and HMAC-SHA-512-256 respectively, except that again, variable- length keys are permitted, and truncation is NOT performed. So when using SHA2, what should the minimum nonce size be? Paul From nobody Wed Jan 6 12:33:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E24D1A037C for ; Wed, 6 Jan 2016 12:33:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ytB_lsRy_Bz5 for ; Wed, 6 Jan 2016 12:33:17 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA001A038F for ; Wed, 6 Jan 2016 12:33:17 -0800 (PST) Received: from DM2PR09MB0683.namprd09.prod.outlook.com (10.161.144.22) by DM2PR09MB0778.namprd09.prod.outlook.com (10.161.145.150) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 20:33:16 +0000 Received: from DM2PR09MB0683.namprd09.prod.outlook.com ([10.161.144.22]) by DM2PR09MB0683.namprd09.prod.outlook.com ([10.161.144.22]) with mapi id 15.01.0361.006; Wed, 6 Jan 2016 20:33:10 +0000 From: "Perlner, Ray" To: "ipsec@ietf.org" Thread-Topic: NIST question concerning IKEv2 and quantum resistance Thread-Index: AdFIwXQqaqlOB64eRs6Nv1l1sgbGQA== Date: Wed, 6 Jan 2016 20:33:10 +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=ray.perlner@nist.gov; x-originating-ip: [129.6.226.173] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0778; 5:PCB1vy+PryGuonCPnSmxqqJySxEr2i6oSifSH/O0nHBX7t743iAa178R03oDEjk1+uzv+dsySOX5JoOVmo3xK1PoWmD6UVwVuhEt79spBrLLPoQsfTHYq4l/UW7V1Zg1IjfRLLjegv60Oc72JWqF9w==; 24:CdAy76fN3zC8D4VJCG3Oq8cKBVYMA0CDXxDZguPkgEFemszQ4ctlHQNaYDdjJR6oc552sV7h6PS09aKN+ALy6q36NTOPbTAMBmTkX3JCpvY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0778; 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)(520078)(10201501046)(3002001); SRVR:DM2PR09MB0778; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0778; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(189002)(164054003)(199003)(76576001)(229853001)(790700001)(122556002)(99286002)(586003)(19300405004)(3846002)(101416001)(189998001)(33656002)(19625215002)(74316001)(5001960100002)(2906002)(5003600100002)(66066001)(1220700001)(19609705001)(5004730100002)(92566002)(4326007)(1096002)(6116002)(105586002)(86362001)(10400500002)(97736004)(107886002)(1730700002)(50986999)(81156007)(16236675004)(2900100001)(15975445007)(102836003)(19580395003)(110136002)(77096005)(4001430100002)(87936001)(2501003)(5002640100001)(40100003)(54356999)(106356001)(5008740100001)(2351001)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0778; H:DM2PR09MB0683.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0683C4AD5E5604214749E4ED9CF40DM2PR09MB0683namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 20:33:10.3921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0778 Archived-At: Cc: "Liu, Yi-Kai" , "Moody, Dustin" , "Frankel, Sheila E." , "Waltermire, David A." Subject: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:33:20 -0000 --_000_DM2PR09MB0683C4AD5E5604214749E4ED9CF40DM2PR09MB0683namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all. NIST is investigating quantum-resistant alternatives to presently standardi= zed public-key algorithms. We are reaching out to the IPSec working group t= o determine if there are any unique needs associated with trying to add qua= ntum-resistance to IKEv2, which currently only uses variants of the Diffie-= Hellman key exchange. We believe a number of the properties of the Diffie-Hellman construction (s= uch as perfect forward secrecy) can be met using generic constructions base= d on standard cryptographic primitives and security models (such as IND-CCA= 2 encryption and EUF-CMA signature) as long as key generation times are fas= t. If IKEv2 can accommodate such generic constructions, there are likely to= be many proposals to choose from. However, there are some additional prope= rties of the Diffie-Hellman exchange which may be difficult to duplicate (s= uch as the property that the responder can compute his key exchange message= without seeing the initiator's key-exchange message) and it's not as clear= to us what the security model for a key exchange replacing DH should be. So in summary, we would like to answers to the following questions: 1) Can IKEv2 can be modified to replace the Diffie-Hellman exchange wi= th a generic construction based on standard encryption, signature, and PRF = primitives? 2) If not, what specific security and correctness requirements should= we target to meet the need? Thanks, Ray --_000_DM2PR09MB0683C4AD5E5604214749E4ED9CF40DM2PR09MB0683namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all.

 <= /p>

NIST is investigating qua= ntum-resistant alternatives to presently standardized public-key algorithms= . We are reaching out to the IPSec working group to determine if there are any unique needs associated with trying to add quantum-resist= ance to IKEv2, which currently only uses variants of the Diffie-Hellman key= exchange.

 <= /p>

We believe a number of th= e properties of the Diffie-Hellman construction (such as perfect forward se= crecy) can be met using generic constructions based on standard cryptographic primitives and security models (such as IND-CCA2 encryption = and EUF-CMA signature) as long as key generation times are fast. If IKEv2 c= an accommodate such generic constructions, there are likely to be many prop= osals to choose from. However, there are some additional properties of the Diffie-Hellman exchange which may be= difficult to duplicate (such as the property that the responder can comput= e his key exchange message without seeing the initiator’s key-exchang= e message) and it’s not as clear to us what the security model for a key exchange replacing DH should be.

 <= /p>

So in summary, we would l= ike to answers to the following questions:

1)  &= nbsp;   Can IKEv2 can be = modified to replace the Diffie-Hellman exchange with a generic construction= based on standard encryption, signature, and PRF primitives?

2)  &= nbsp;    If not, wha= t specific security and correctness requirements should we target to meet t= he need?

 <= /p>

Thanks,=

Ray

&nbs= p;

 = ;

 

--_000_DM2PR09MB0683C4AD5E5604214749E4ED9CF40DM2PR09MB0683namp_-- From nobody Wed Jan 6 12:53:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0809D1A03ED for ; Wed, 6 Jan 2016 12:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZUblQ9Bjn_od for ; Wed, 6 Jan 2016 12:53:04 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AEF1A03E1 for ; Wed, 6 Jan 2016 12:53:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pbNF96qy0z3Hg; Wed, 6 Jan 2016 21:53:01 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 xeN_Rl2lR8IS; Wed, 6 Jan 2016 21:53:00 +0100 (CET) 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, 6 Jan 2016 21:53:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CF9446000F5C; Wed, 6 Jan 2016 15:52:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CF9446000F5C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CEB9D13955B; Wed, 6 Jan 2016 15:52:58 -0500 (EST) Date: Wed, 6 Jan 2016 15:52:58 -0500 (EST) From: Paul Wouters To: "Perlner, Ray" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , "Liu, Yi-Kai" , "Frankel, Sheila E." , "Moody, Dustin" , "Waltermire, David A." Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:53:06 -0000 On Wed, 6 Jan 2016, Perlner, Ray wrote: > NIST is investigating quantum-resistant alternatives to presently standardized public-key algorithms. We are > reaching out to the IPSec working group to determine if there are any unique needs associated with trying to > add quantum-resistance to IKEv2, which currently only uses variants of the Diffie-Hellman key exchange. There is: https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 It was thrown out of the working group before. I think it is time to reconsider with everyone focusing on post-quantum worlds. Paul From nobody Wed Jan 6 23:28:10 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE151A8718 for ; Wed, 6 Jan 2016 23:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=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 nKAKjQ9ZoJn3 for ; Wed, 6 Jan 2016 23:28:07 -0800 (PST) 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 CDA171A8714 for ; Wed, 6 Jan 2016 23:28:06 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id b14so108841441wmb.1 for ; Wed, 06 Jan 2016 23:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GXCGwAM5er+MZZf4Rq3rwZ5x2fCgvY7iT1Sq6cc/M94=; b=HR+WMkERAf8egoP1VM0rAM/WqA5VwHwVgJSAPV0f7zQW+u0tgc/n2wJ05rf8CkDUiE 7v40EFmM/eRzs8bwGIb6xwwVBJFxr/lVRF2fbVsTfs6PmO8xaCD3zEPscEoAL0BkPr9x dOx65qEpGb+MykHkAst2PXZhUBckxl7v/RczLP42pCG8j1NSxL7qGjqbXltS1dO1Uu8X 8FOga8PlrWGStkJqVH5MqzVNsrfY2/4Krb4TJ9SfX79gOKD7ZrurfqNM8xCI/K6PF8cn opKthPV0PnJj2sa60tKMU2cL6SOBfLXF23IHoHenc/SkJ0592I+P9UdPTOga+lP+Z1Fl D4Lg== X-Received: by 10.194.185.231 with SMTP id ff7mr102935385wjc.23.1452151685401; Wed, 06 Jan 2016 23:28:05 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.13.17.179]) by smtp.gmail.com with ESMTPSA id pn6sm99651104wjb.15.2016.01.06.23.28.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 23:28:03 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3FB08A22-024C-4E02-858C-190170FC0551" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Thu, 7 Jan 2016 09:27:11 +0200 Message-Id: <4A5E0102-9C36-47D5-AE3F-90575BF194D6@gmail.com> References: To: "Perlner, Ray" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org" , "Liu, Yi-Kai" , "Frankel, Sheila E." , "Moody, Dustin" , "Waltermire, David A." Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 07:28:09 -0000 --Apple-Mail=_3FB08A22-024C-4E02-858C-190170FC0551 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Jan 2016, at 10:33 PM, Perlner, Ray wrote: >=20 > Hi all. > =20 > NIST is investigating quantum-resistant alternatives to presently = standardized public-key algorithms. We are reaching out to the IPSec = working group to determine if there are any unique needs associated with = trying to add quantum-resistance to IKEv2, which currently only uses = variants of the Diffie-Hellman key exchange. > =20 > We believe a number of the properties of the Diffie-Hellman = construction (such as perfect forward secrecy) can be met using generic = constructions based on standard cryptographic primitives and security = models (such as IND-CCA2 encryption and EUF-CMA signature) as long as = key generation times are fast. If IKEv2 can accommodate such generic = constructions, there are likely to be many proposals to choose from. = However, there are some additional properties of the Diffie-Hellman = exchange which may be difficult to duplicate (such as the property that = the responder can compute his key exchange message without seeing the = initiator=E2=80=99s key-exchange message) and it=E2=80=99s not as clear = to us what the security model for a key exchange replacing DH should be. > =20 > So in summary, we would like to answers to the following questions: > 1) Can IKEv2 can be modified to replace the Diffie-Hellman = exchange with a generic construction based on standard encryption, = signature, and PRF primitives? > 2) If not, what specific security and correctness requirements = should we target to meet the need? > =20 Hi, Ray RFC 7296 describes the key agreement method as =E2=80=9CDiffie-Hellman=E2=80= =9D, the identifier as a =E2=80=9CDiffie-Hellman group=E2=80=9D, the = content of the KE payload as =E2=80=9CDiffie-Hellman public value=E2=80=9D= , and the result of the calculation as g^ir. The terminology used reflects perhaps a lack of imagination, but just as = we=E2=80=99ve substituted ECDH for DH and just as we are working on = adding Curve25519 key agreement, the protocol is amenable to adding = different key agreement methods which are not even mathematical groups. The only requirements are: Negotiate the use of the mechanism in the Initial exchange (that=E2=80=99s= as simple as assigning a number to the new method) Send the initiator=E2=80=99s =E2=80=9Cpart=E2=80=9D (that=E2=80=99s the = terminology they now use in the TLS working group) in the Initial = request Send the responder=E2=80=99s =E2=80=9Cpart=E2=80=9D in the Initial = response. Be able to generate the shared value (which is going to be something = other than g^ir in your scheme) based on those two messages alone. If your method can be done with these constraints, it=E2=80=99s an OK = fit for IKE. IIUC this not-really-specified-above proposal has the Responder=E2=80=99s = public value depend on the Initiator=E2=80=99s value. This means that = the Responder cannot pre-calculate and cannot re-use something (I = won=E2=80=99t say =E2=80=9Cexponentials=E2=80=9D). These are possible with current key agreement methods, but they are not = essential to security or correct operation. They help increase the rate = of IKE SA setups that a particular piece of hardware running the = Responder can perform. If a particular platform can perform 200 setups = per second without pre-calculation and reuse, but 400 with them, = that=E2=80=99s a performance gain only. Any new proposed method will be = judged on its security as well as the session setup rate on a similar = piece of hardware. It is entirely possible and acceptable that = performance optimizations will look very different with a new algorithm. Short version: I think it=E2=80=99s fine. Now let=E2=80=99s see an = actual proposal. Yoav --Apple-Mail=_3FB08A22-024C-4E02-858C-190170FC0551 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 6 Jan 2016, at 10:33 PM, Perlner, Ray <ray.perlner@nist.gov> wrote:

Hi = all.
 
NIST is investigating = quantum-resistant alternatives to presently standardized public-key = algorithms. We are reaching out to the IPSec working group to determine = if there are any unique needs associated with trying to add = quantum-resistance to IKEv2, which currently only uses variants of the = Diffie-Hellman key exchange.
 
We believe a number of = the properties of the Diffie-Hellman construction (such as perfect = forward secrecy) can be met using generic constructions based on = standard cryptographic primitives and security models (such as IND-CCA2 = encryption and EUF-CMA signature) as long as key generation times are = fast. If IKEv2 can accommodate such generic constructions, there are = likely to be many proposals to choose from. However, there are some = additional properties of the Diffie-Hellman exchange which may be = difficult to duplicate (such as the property that the responder can = compute his key exchange message without seeing the initiator=E2=80=99s = key-exchange message) and it=E2=80=99s not as clear to us what the = security model for a key exchange replacing DH should be.
 
So in summary, we would = like to answers to the following questions:
1)      Can IKEv2 can be modified to replace the = Diffie-Hellman exchange with a generic construction based on standard = encryption, signature, and PRF primitives?
2)       If not, what specific security and = correctness requirements should we target to meet the need?
 

Hi, Ray

RFC = 7296 describes the key agreement method as =E2=80=9CDiffie-Hellman=E2=80=9D= , the identifier as a =E2=80=9CDiffie-Hellman group=E2=80=9D, the = content of the KE payload as =E2=80=9CDiffie-Hellman public value=E2=80=9D= , and the result of the calculation as g^ir.

The terminology used reflects perhaps a lack of = imagination, but just as we=E2=80=99ve substituted ECDH for DH and just = as we are working on adding Curve25519 key agreement, the protocol is = amenable to adding different key agreement methods which are not even = mathematical groups.

The only = requirements are:
  1. Negotiate the use of the mechanism in the Initial exchange = (that=E2=80=99s as simple as assigning a number to the new = method)
  2. Send the initiator=E2=80=99s =E2=80=9Cpart=E2=80= =9D (that=E2=80=99s the terminology they now use in the TLS working = group) in the Initial request
  3. Send the responder=E2=80=99= s =E2=80=9Cpart=E2=80=9D in the Initial response.
  4. Be = able to generate the shared value (which is going to be something other = than g^ir in your scheme) based on those two messages = alone.

If = your method can be done with these constraints, it=E2=80=99s an OK fit = for IKE.

IIUC = this not-really-specified-above proposal has the Responder=E2=80=99s = public value depend on the Initiator=E2=80=99s value. This means that = the Responder cannot pre-calculate and cannot re-use something (I = won=E2=80=99t say =E2=80=9Cexponentials=E2=80=9D).

These are possible with = current key agreement methods, but they are not essential to security or = correct operation. They help increase the rate of IKE SA setups that a = particular piece of hardware running the Responder can perform. If a = particular platform can perform 200 setups per second without = pre-calculation and reuse, but 400 with them, that=E2=80=99s a = performance gain only. Any new proposed method will be judged on its = security as well as the session setup rate on a similar piece of = hardware. It is entirely possible and acceptable that performance = optimizations will look very different with a new algorithm.

Short version: I think = it=E2=80=99s fine.  Now let=E2=80=99s see an actual = proposal.

Yoav

= --Apple-Mail=_3FB08A22-024C-4E02-858C-190170FC0551-- From nobody Thu Jan 7 06:16:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200141A8A91 for ; Thu, 7 Jan 2016 06:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YxAQyzxDhccy for ; Thu, 7 Jan 2016 06:16:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882131A8A6E for ; Thu, 7 Jan 2016 06:16:46 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 228232002A; Thu, 7 Jan 2016 09:24:03 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69A4863751; Thu, 7 Jan 2016 09:16:45 -0500 (EST) From: Michael Richardson To: "ipsec\@ietf.org" In-Reply-To: <4A5E0102-9C36-47D5-AE3F-90575BF194D6@gmail.com> References: <4A5E0102-9C36-47D5-AE3F-90575BF194D6@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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: "Perlner, Ray" , "Liu, Yi-Kai" , Yoav Nir , "Waltermire, David A." , "Frankel, Sheila E." , "Moody, Dustin" Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 14:16:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > Short version: I think it=E2=80=99s fine. Now let=E2=80=99s see an ac= tual proposal. +1. A desireable property which we do not presently have, is if the amount of work the initiator has to do for step 1 is less than what the responder has to do for step 2, and the responder can cheaply verify the "freshness" of the work. During times of attack, there can be an additional step -1/0 where the responder provides a challenge to the initiator. We have been looking at using puzzle solving to let the responder seperate the wheat from the DDoS-provided-chaff quickly. If a new protocol was quantum resistant, and *also* provided a measure of DDoS resistance, then that would probably significantly improve the industry interest in it. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVo5zSoCLcPvd0N1lAQLh+Qf9GmNcxWYoatsD8dS0sXCcYht4uLbKbW8B mzCX59qZHwCjo6lUSVpiATAdj2Wexc+oKx4Pj/yFApnREEjPCtBkMriotp20+Rdu QB8+WlWeQjta+UcxsZxX1LfGMrWxp2y2FH7DgPcO+EadPfXfKot0H8dcLQBSMn4/ XvG+h94fT1mptfYWphHvJ7D6F145NWL+noHMbuMa7SnUM4eQkoadxYFxQ5ZlBTFi 9YVjyAelUxRqpqyv0w+w7ArrRU+dhhDAZimsnuJ3KRI0bsgbCXskG4zI0sR7h5UC vzitC5TD9N0PaNyi6QiJvmYSLetvsjAU0pFMbUFraZtWIDwKbPdfrQ== =3sYu -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 8 02:02:10 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE71ACF09 for ; Fri, 8 Jan 2016 02:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, SPF_PASS=-0.001] autolearn=ham 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 dRgWc-M-VaZj for ; Fri, 8 Jan 2016 02:02:07 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EA51A886E for ; Fri, 8 Jan 2016 02:02:07 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id m198so24640668lfm.0 for ; Fri, 08 Jan 2016 02:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=UlP6w2rTIqZcK/Iw22x8JOb/11jcmEQ7n7S1m6egtdY=; b=e7GNgvBvNF8vLyQkBpGN4hDAQ36ddu/ji0Hm4+EDtV3YJvZyFA+egEoc3IjPQ50lXe 8Unen6HUTAMzakQ2hespNYtxR8FQlB8XIxbFyclxNT0kd1GAHw+7RL5VyvDURBLQUhaN DDFzz78JGOCosa/+6OQPzmsHviODzzEHZGrXjKzCaZezYV24YbiYJIHQSSpg6kJtFadw HndWVCc8naQJQW8gbuwON7QfKOYsQh29uNN6lGkYtyu3aK+5/Z22shHA+W/BLYTwyy5p tLTD3OnVAZ3ZjZlehpsfxZdgxyllYONJ2ZHAEsUUTyVft8BXtbwlLsPsGZdPl9VyzRh6 cyBA== X-Received: by 10.25.17.89 with SMTP id g86mr14978884lfi.82.1452247325412; Fri, 08 Jan 2016 02:02:05 -0800 (PST) Received: from chichi (ppp83-237-32-196.pppoe.mtu-net.ru. [83.237.32.196]) by smtp.gmail.com with ESMTPSA id ei4sm2799941lbb.18.2016.01.08.02.02.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 02:02:04 -0800 (PST) Message-ID: <1CB91A63CA714180975D0D277651D450@chichi> From: "Valery Smyslov" To: "Paul Hoffman" References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <747DE08D84C548F3BD34B561352F7146@chichi> In-Reply-To: Date: Fri, 8 Jan 2016 13:01:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:02:09 -0000 Hi Paul, >> If you mean TLS, then as far as I understand the compression-related >> attacks >> on TLS rely on an ability for an attacker to insert specific data into >> the >> encrypted (and compressed) stream that contains secret information >> (e.g. password). I don't think it's relevant to IKE and it is >> discussed >> in the Security Considerations section. > > No one considered it relevant to TLS until researchers discovered the > problems there. I think that's PaulW's point, and one that I agree with. IETF develops standards based on the best current knowledge. For example today AES is considered secure, but there is a non-zero probability that it'll be broken tomorrow. Shouldn't then we use it today? Coming back to compression. As far as I understand compression per se was not a problem in TLS. The problem was that TLS mixed up secret information with user-provided data and compressed it all together. The decision was to remove compression from TLS (transport) and to move it to application level, because application does know what is safe to compress and what is not. In case of IKE, IKE *is* an application. It shouldn't transfer any data that was originated outside IKE. It does know what kind of data it transfers. Moreover, no secret information is transferred in IKE SA. Some of information is sensitive (like peers identities), but no passwords or keys are transferred. Taking all these into considerations I think it is possible to use compression in IKE without degrading its security. Of course there is no gurantee that tomorrow all these consideration become wrong, but this could happen with almost any security primitive IKE uses today. >> Note, that this is -00 draft and the security considerations >> are currently very basic. What do you think should be added there? > > That seems like a premature question. We haven't even decided if the > idea of compressing IKE would give the benefits listed, whether the > computational cost match the space benefits, and thus should be > considered at all. We couldn't decide if this idea is worth to use if we don't analyse its security as deep as we can. I think that any new text in the security considerations section will help us to make a right decision. > --Paul Hoffman Regards, Valery. From nobody Fri Jan 8 02:56:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470F41AD0B4 for ; Fri, 8 Jan 2016 02:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 UnAYyghfsHRk for ; Fri, 8 Jan 2016 02:56:32 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 EFE661AD0AD for ; Fri, 8 Jan 2016 02:56:31 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id sv6so215043513lbb.0 for ; Fri, 08 Jan 2016 02:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=efbrBSvREwPNAt7qS1Q1m+nTbQPT5TKiCljd7khO9GA=; b=0D4yqMZM9I9wZrzDPoSvBBUOR67i3EkRrD+JzjaQ3TSwABKk9+zeP/ZaWDSZAaWfHK fMZcHZh67SdadTYygpESw0vx4ctQxXE/TPp+Ne0zY7aGqq+pWyw+lXYCCj2hL7xVg5VC ls/0cncWFZhVnZMKNaNSWjBi4n31UnoPE5Os99lDweRFmDco5jvxyL4x6vKKvCvJeRCP 3FXdATULFiVSKkg1OljRWJcd3ZetgI428HiPDxGXLVo/RRQrdfTLEtGvY/ean/GospWu gYt0YhwxiCLm11heOs+qCLkw6sXiJMN23ogmC0k38Wu6BOdM7tx0stOMwePsu5g91ADJ DCSQ== X-Received: by 10.112.205.105 with SMTP id lf9mr25227427lbc.57.1452250590239; Fri, 08 Jan 2016 02:56:30 -0800 (PST) Received: from chichi (ppp83-237-32-196.pppoe.mtu-net.ru. [83.237.32.196]) by smtp.gmail.com with ESMTPSA id l129sm5018001lfl.37.2016.01.08.02.56.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 02:56:29 -0800 (PST) Message-ID: <3C6E22535BD542EEA9D9D83B8BD56BAD@chichi> From: "Valery Smyslov" To: "Yoav Nir" References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> In-Reply-To: Date: Fri, 8 Jan 2016 13:56:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:56:33 -0000 Hi Yoav, > First, the problem of IKE having too large packets in certain environments is a real problem. > We’ve already addressed it with fragmentation, and the TCP encapsulation draft proposes yet another way. I don't think that compression is an alternative to TCP encapsulation. TCP encapsulation is a "last resort" and compression would just make the necessity to use this "last resort" less frequent. > I think either of those can solve most of the bad router and noisy line issues. I also think that IKE is quite > low-volume > so the savings in number of bytes sent from, say, a mobile phone are not an issue. So the only scenario where > compression > may have value is for an IoT device working on a battery and/or using a particularly slow network. I think it could be useful even in "big world" (see above), but I agree that in "IoT world" the benefit would be more substantial. > Second, as I understand it, those battery-powered devices tend to use 802.15.4 networks with 127-byte frames. > There’s 6LoWPAN to provide fragmentation support, but that’s similar to using IKE’s fragmentation for the same issue. > Can anything be done at all with 127-byte frames, that include the (IPv6?) headers, the 8-byte UDP header, > the 20-byte IKEv2 header in addition to all the payload headers? If we need fragmentation anyway, I don’t know if > compression matters. I'm not familiar with 6LoWPAN, but isn't IKE independent from the transport? I mean that IKE messages would be composed (and compressed) regardless of how they are fragmented by the lower level, wouldn't them? > Third, I haven’t tested this myself, so I may be all wrong here, but I question the value of compression on IKE. > IKE is a binary protocol with mostly compact binary payloads. Even the list of supported CAs is a list of hashes in > IKEv2. > How much can compression help? It depends on the particular content of the messages. Those payloads that contain random (or randomly-looking) data like Nonce, KE, most VIDs are almost uncompressable. However the content of SA payload contains so many zeroes that it can be compressed of up to 90%. So, if your IKE_SA_INIT's SA payload contains only a couple of transforms, the saving is minimal - about few tens of bytes. However if it contains a long list of transforms, then you could make initial message 30% or even twice as small comparing to no compression. And IKE_AUTH messages often contains a certificates, that is usually compressable by 30%. Since certificates are large, you can save few hundreds of bytes even with a short list of transforms in IKE_AUTH messages. I can provide more detailed information on next week. > Yoav Regards, Valery. From nobody Fri Jan 8 07:30:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC871A8A66 for ; Fri, 8 Jan 2016 07:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=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 V-wezfa60C6Z for ; Fri, 8 Jan 2016 07:30:02 -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 692961A8A64 for ; Fri, 8 Jan 2016 07:30:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pcSzX2dycz2H7; Fri, 8 Jan 2016 16:30:00 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 kR0vigl1NZFW; Fri, 8 Jan 2016 16:29:59 +0100 (CET) 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, 8 Jan 2016 16:29:59 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5EDB5614A48A; Fri, 8 Jan 2016 10:29:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 5EDB5614A48A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5B39826092; Fri, 8 Jan 2016 10:29:58 -0500 (EST) Date: Fri, 8 Jan 2016 10:29:58 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <3C6E22535BD542EEA9D9D83B8BD56BAD@chichi> Message-ID: References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <3C6E22535BD542EEA9D9D83B8BD56BAD@chichi> User-Agent: Alpine 2.20 (LFD 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, Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:30:03 -0000 On Fri, 8 Jan 2016, Valery Smyslov wrote: >> Third, I haven’t tested this myself, so I may be all wrong here, but I >> question the value of compression on IKE. >> IKE is a binary protocol with mostly compact binary payloads. Even the >> list of supported CAs is a list of hashes in IKEv2. >> How much can compression help? > > It depends on the particular content of the messages. Those payloads that > contain > random (or randomly-looking) data like Nonce, KE, most VIDs are almost > uncompressable. > However the content of SA payload contains so many zeroes that it can be > compressed > of up to 90%. So, if your IKE_SA_INIT's SA payload contains only a couple of > transforms, > the saving is minimal - about few tens of bytes. However if it contains a > long list of transforms, > then you could make initial message 30% or even twice as small comparing to > no compression. But IoT devices would likely only suggest one or at most two transforms anyway? Not a long list? > And IKE_AUTH messages often contains a certificates, that is usually > compressable by 30%. I thought IoT devices did not even have the memory to do X.509, which is why raw public keys were added to TLS ? Paul From nobody Fri Jan 8 10:15:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741B41B2AC1 for ; Fri, 8 Jan 2016 10:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 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, MALFORMED_FREEMAIL=1.481, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=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 wgEiCQqYV2rp for ; Fri, 8 Jan 2016 10:15:01 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6821B2ABD for ; Fri, 8 Jan 2016 10:15:00 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id f206so183755394wmf.0 for ; Fri, 08 Jan 2016 10:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:cc:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Xo1wWqAV/Z1CYIAfvNnBatgAHOzVWuN/OXWZh0iHCCM=; b=NkR1y4hfFdw38B/tcpBUXK2O/X2I06P59gGF3I+tGhcc0yC10KzyilwxBdrLaZYvSb bF3Y7CMst06GWtkV5ZpXbksGrNzG9iY6MYv64WVw1NUxX/9OCICyXWwleSqCucu+Ynul rEOFw+lJtYVo9zcKg6NVCZXRVYtSLJMTqXOx4F0ZIW5EIGu1QTBodKKdtM2DOOPg4uKJ JL1cJPdvDv9xTZw4rq3/UFjyZx2Uk/Ab3zmr1XzWvoTGJOIh/5Md2Y+Uaqk2j/SkQXn8 ZeVAZ7oOtyXgiKeOn7VqFG0irfHZGdRm7xpujHO9P9+lzIM8/Fr5sgGJvUjwJ+MxiYIm P6tQ== X-Received: by 10.28.48.194 with SMTP id w185mr275766wmw.73.1452276899404; Fri, 08 Jan 2016 10:14:59 -0800 (PST) Received: from [10.0.0.10] (bzq-79-179-196-22.red.bezeqint.net. [79.179.196.22]) by smtp.gmail.com with ESMTPSA id ql10sm107254712wjc.23.2016.01.08.10.14.57 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 10:14:57 -0800 (PST) References: <20160105013103.23315.96954.idtracker@ietfa.amsl.com> Cc: ipsec@ietf.org From: Yaron Sheffer Message-ID: <568FFCA0.9040104@gmail.com> Date: Fri, 8 Jan 2016 20:14:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160105013103.23315.96954.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:15:02 -0000 Two comments to the new version: - I suggest you add a reference to RFC 7427 (Signature Auth). - We still have SHA1 as a MUST in Sec. 4.2. Shouldn't it be deprecated, at least to MUST- ? Thanks, Yaron On 01/05/2016 03:31 AM, internet-drafts@ietf.org wrote: > 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 Working Group 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-02.txt > Pages : 13 > Date : 2016-01-04 > > Abstract: > The IPsec series of protocols makes use of various cryptographic > algorithms in order to provide security services. The Internet Key > Exchange protocol provides a mechanism to negotiate which algorithms > should be used in any given Security Association. 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 will have available. This document defines the > current algorithm implementation requirements and usage guidance of > IKEv2. 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-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jan 8 12:19:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BA91B2B71 for ; Fri, 8 Jan 2016 12:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Qndn7lc7fIgA for ; Fri, 8 Jan 2016 12:19:19 -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 397451B2B78 for ; Fri, 8 Jan 2016 12:19:19 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pcbPJ1mThz2H7; Fri, 8 Jan 2016 21:19:16 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 J18WDGcg6J4R; Fri, 8 Jan 2016 21:19:15 +0100 (CET) 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, 8 Jan 2016 21:19:15 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6AC20614A48A; Fri, 8 Jan 2016 15:19:13 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6AC20614A48A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 69B31EA8AB; Fri, 8 Jan 2016 15:19:13 -0500 (EST) Date: Fri, 8 Jan 2016 15:19:13 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <568FFCA0.9040104@gmail.com> Message-ID: References: <20160105013103.23315.96954.idtracker@ietfa.amsl.com> <568FFCA0.9040104@gmail.com> User-Agent: Alpine 2.20 (LFD 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] I-D Action: draft-ietf-ipsecme-rfc4307bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 20:19:21 -0000 On Fri, 8 Jan 2016, Yaron Sheffer wrote: > Two comments to the new version: > - I suggest you add a reference to RFC 7427 (Signature Auth). Will do. > - We still have SHA1 as a MUST in Sec. 4.2. Shouldn't it be deprecated, at > least to MUST- ? Yes, it was forgotten there when we added that section. I'll add it. Paul From nobody Sat Jan 9 01:27:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B39C1A219E for ; Sat, 9 Jan 2016 01:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7Hmu1-zYUcEy for ; Sat, 9 Jan 2016 01:27:25 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 8A3C71A212A for ; Sat, 9 Jan 2016 01:27:24 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id oh2so233846785lbb.3 for ; Sat, 09 Jan 2016 01:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=+ToN2GVwq880Xxfhz8rO4yJ7zPCMKQrGaQjag/cmVAY=; b=Tt6rk/Qq5kWla8/A7zkXru5Sr7junyS/pojMJWSL/hyzHJj8KBBJtU2OGpma/MEVJf Ifem76ssML3yvAyPeaKyPsI2+kxUetpTKGZDFFdKve9cFjhX8yFEU804wWjUhl0JkLu7 WTIdapzKBZji/3bmilC0xAdbw26gTopMyWUTffZJqBs65OAf+xHpDCtj4fD2snQZAWkh PpcVykTBFAPn2kUXRaeWIksxIsV8anO662vpfsvqGmSRe/w7UumNILF9hOiFmnYLSsbX FoKOjI3vD8OUfil5iQwRfbBue9vMjeMSC14v7PUVfpo5/W0emrrORxe3BJ7XAkA0dXe6 38ww== X-Received: by 10.112.125.9 with SMTP id mm9mr29735222lbb.113.1452331642788; Sat, 09 Jan 2016 01:27:22 -0800 (PST) Received: from chichi (ppp83-237-42-193.pppoe.mtu-net.ru. [83.237.42.193]) by smtp.gmail.com with ESMTPSA id ei4sm3559292lbb.18.2016.01.09.01.27.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jan 2016 01:27:22 -0800 (PST) Message-ID: <6B485A2889834007B0E0A72461C21931@chichi> From: "Valery Smyslov" To: "Paul Wouters" References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <3C6E22535BD542EEA9D9D83B8BD56BAD@chichi> In-Reply-To: Date: Sat, 9 Jan 2016 12:27:16 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 09:27:26 -0000 >> It depends on the particular content of the messages. Those payloads that >> contain >> random (or randomly-looking) data like Nonce, KE, most VIDs are almost >> uncompressable. >> However the content of SA payload contains so many zeroes that it can be >> compressed >> of up to 90%. So, if your IKE_SA_INIT's SA payload contains only a couple of >> transforms, >> the saving is minimal - about few tens of bytes. However if it contains a >> long list of transforms, >> then you could make initial message 30% or even twice as small comparing to >> no compression. > > But IoT devices would likely only suggest one or at most two transforms > anyway? Not a long list? As far as I understand for some lower power consumption systems even small reduction of message is significant. For example see the following: https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY >> And IKE_AUTH messages often contains a certificates, that is usually >> compressable by 30%. > > I thought IoT devices did not even have the memory to do X.509, which is > why raw public keys were added to TLS ? I don't think raw public keys cover all use cases. The IoT device could present its own certificate even if it cannot process the peer's one. And even without certificates the IKE_AUTH messages contain some redundancy to compress. > Paul Regards, Valery. From nobody Sat Jan 9 08:58:32 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0076D1A8889 for ; Sat, 9 Jan 2016 08:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553] autolearn=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 ZVOn9MvE8sTA for ; Sat, 9 Jan 2016 08:58:30 -0800 (PST) Received: from hoffman.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 68A081A88C5 for ; Sat, 9 Jan 2016 08:58:30 -0800 (PST) Received: from [192.168.1.154] (c-76-126-171-147.hsd1.ca.comcast.net [76.126.171.147]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u09GwS4Z099900 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jan 2016 09:58:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host c-76-126-171-147.hsd1.ca.comcast.net [76.126.171.147] claimed to be [192.168.1.154] From: "Paul Hoffman" To: ipsec@ietf.org Date: Sat, 09 Jan 2016 08:58:28 -0800 Message-ID: <5DFB3F9E-879B-4FAE-A8F7-A27B8D663CE1@vpnc.org> In-Reply-To: <6B485A2889834007B0E0A72461C21931@chichi> References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <3C6E22535BD542EEA9D9D83B8BD56BAD@chichi> <6B485A2889834007B0E0A72461C21931@chichi> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 16:58:31 -0000 This seems like a lot of guessing about what IoT devices want, specifically how they would handle tradeoffs of code complexity, CPU usage, and message size. If this WG offers an extension that is "for IoT", there will be a tendency to use it even in places where it might actually make things worse, so we really should be careful about deciding whether or not to pursue this. How can we determine if the IoT community (as compared to IPsec developers) have a need for IKE compression? --Paul Hoffman From nobody Mon Jan 11 07:17:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BFC1A036D for ; Mon, 11 Jan 2016 07:17:04 -0800 (PST) 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 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 nrYE-cPHBoU6 for ; Mon, 11 Jan 2016 07:17:02 -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 C76921A0302 for ; Mon, 11 Jan 2016 07:17:01 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0BFGwkb016928 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jan 2016 17:16:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0BFGuHG008878; Mon, 11 Jan 2016 17:16:56 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22163.51048.813043.947602@fireball.acr.fi> Date: Mon, 11 Jan 2016 17:16:56 +0200 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: 5 min X-Total-Time: 6 min Archived-At: Cc: "ipsec@ietf.org WG" Subject: [IPsec] IKEv2 question on nonce size and SHA2 PRFs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 15:17:04 -0000 Paul Wouters writes: > > IKEv2 (RFC-7296) states: > > Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits > in size, and MUST be at least half the key size of the negotiated > pseudorandom function (PRF). > > For SHA2 versions of PRF, we need to look at RFC-4868: > > http://tools.ietf.org/html/rfc4868#section-2.4 > > The PRF-HMAC-SHA-256 algorithm is identical to HMAC-SHA-256-128, > except that variable-length keys are permitted, and the truncation > step is NOT performed. Likewise, the implementations of PRF-HMAC- > SHA-384 and PRF-HMAC-SHA-512 are identical to those of HMAC-SHA-384- > 192 and HMAC-SHA-512-256 respectively, except that again, variable- > length keys are permitted, and truncation is NOT performed. > > > So when using SHA2, what should the minimum nonce size be? 128, 192 and 256 bits, depending on the SHA2 variant. As those are used as PRF, that means that the RFC 4868 says that "key lengths are variable", but RFC 7296 says: "For PRFs based on the HMAC construction, the preferred key size is equal to the length of the output of the underlying hash function." The key lengths for the hashes are then output lengths of the hashes, i.e. 256, 384 and 256 bits, and as Nonce needs to be at least half of they key size of the negotiated PRF, that means the minimum sizes are 128, 192 and 256 bits. -- kivinen@iki.fi From nobody Mon Jan 11 08:19:12 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6B1A7021 for ; Mon, 11 Jan 2016 08:19:10 -0800 (PST) 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 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 Yb9GrG_-V7QR for ; Mon, 11 Jan 2016 08:19:09 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B251A6F32 for ; Mon, 11 Jan 2016 08:19:08 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0BGJ452012589 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jan 2016 18:19:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0BGJ4AQ018279; Mon, 11 Jan 2016 18:19:04 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22163.54776.641819.67931@fireball.acr.fi> Date: Mon, 11 Jan 2016 18:19:04 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:19:11 -0000 Yoav Nir writes: > Second, as I understand it, those battery-powered devices tend to > use 802.15.4 networks with 127-byte frames. There=E2=80=99s 6LoWPAN t= o > provide fragmentation support, but that=E2=80=99s similar to using IK= E=E2=80=99s > fragmentation for the same issue. Can anything be done at all with > 127-byte frames, that include the (IPv6=3F) headers, the 8-byte UDP > header, the 20-byte IKEv2 header in addition to all the payload > headers=3F If we need fragmentation anyway, I don=E2=80=99t know if > compression matters.=20 802.15.4 networks also have 802.15.9, which will provide its own fragmentation and reassembly for the IKEv2 frames (not including IP or UDP headers, as those are not used, this is raw IKEv2 frames over raw 802.15.4 frames). In those environments the IKEv2 is used to negotiate link keys between two devices. The payloads are already quite compacted, i.e. there will not be several proposals for ciphers, only one, and all extra payloads are omitted anyways.=20 --=20 kivinen@iki.fi From nobody Mon Jan 11 21:44:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047561ACE2D for ; Mon, 11 Jan 2016 21:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 t9XHeu5IyxEH for ; Mon, 11 Jan 2016 21:44:15 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE211ACE2B for ; Mon, 11 Jan 2016 21:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14080; q=dns/txt; s=iport; t=1452577455; x=1453787055; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VNafzNUqkyVLyrQHo6gmTVUQoUXnUcfNysX5Ca5j/Bg=; b=OPE00K1IxNWfFNT9niQz6J4JQBNXY51KMTxujqDKWvbc1NVPALsz++3q MXkxzL4QpbBN4PBy3ni2Yv6mO/pqCDQrSdRJhbp5d82w89NoWWK2Qlsj1 dhQWFRk+aIc/8XtJcaQfI6I+PvNwnSQLoCYVs2f/zwpjIjssB+l77wqmo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgCzkZRW/4cNJK1egm5MUm0GiFOxT?= =?us-ascii?q?4ITAQ2BZiKFbQKBKjgUAQEBAQEBAYEKhDQBAQEELUcFEAIBCBEEAQEoBzIUCQg?= =?us-ascii?q?BAQQBDQUIiCYOv00BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWAYR+hQQJhDAFi?= =?us-ascii?q?D2KU4QDAYVCiA+PA45RASABAUKECnKFKYEIAQEB?= X-IronPort-AV: E=Sophos; i="5.20,556,1444694400"; d="scan'208,217"; a="62671381" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2016 05:44:14 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0C5iEcl031566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2016 05:44:14 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Jan 2016 23:44:13 -0600 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.1104.009; Mon, 11 Jan 2016 23:44:13 -0600 From: "Panos Kampanakis (pkampana)" To: "Perlner, Ray" , "ipsec@ietf.org" Thread-Topic: NIST question concerning IKEv2 and quantum resistance Thread-Index: AdFIwXQqaqlOB64eRs6Nv1l1sgbGQAEOi2dA Date: Tue, 12 Jan 2016 05:44:13 +0000 Message-ID: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> References: 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.24.31.212] Content-Type: multipart/alternative; boundary="_000_21404b33280a4b4abc841dbec888c848XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Liu, Yi-Kai" , "David McGrew \(mcgrew\)" , "Waltermire, David A." , "Frankel, Sheila E." , "Scott Fluhrer \(sfluhrer\)" , "Moody, Dustin" Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 05:44:18 -0000 --_000_21404b33280a4b4abc841dbec888c848XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ray, Scott's https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the fir= st take of QC resistant IKEv2. It is still in its early stages and has not = been adopted as any WG's item yet. Feedback is welcome. Rgs, Panos From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Perlner, Ray Sent: Wednesday, January 06, 2016 3:33 PM To: ipsec@ietf.org Cc: Liu, Yi-Kai ; Moody, Dustin ; Frankel, Sheila E. ; Waltermire, David A. Subject: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi all. NIST is investigating quantum-resistant alternatives to presently standardi= zed public-key algorithms. We are reaching out to the IPSec working group t= o determine if there are any unique needs associated with trying to add qua= ntum-resistance to IKEv2, which currently only uses variants of the Diffie-= Hellman key exchange. We believe a number of the properties of the Diffie-Hellman construction (s= uch as perfect forward secrecy) can be met using generic constructions base= d on standard cryptographic primitives and security models (such as IND-CCA= 2 encryption and EUF-CMA signature) as long as key generation times are fas= t. If IKEv2 can accommodate such generic constructions, there are likely to= be many proposals to choose from. However, there are some additional prope= rties of the Diffie-Hellman exchange which may be difficult to duplicate (s= uch as the property that the responder can compute his key exchange message= without seeing the initiator's key-exchange message) and it's not as clear= to us what the security model for a key exchange replacing DH should be. So in summary, we would like to answers to the following questions: 1) Can IKEv2 can be modified to replace the Diffie-Hellman exchange wi= th a generic construction based on standard encryption, signature, and PRF = primitives? 2) If not, what specific security and correctness requirements should= we target to meet the need? Thanks, Ray --_000_21404b33280a4b4abc841dbec888c848XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ray,

 

Scott’s https:= //datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the first take of= QC resistant IKEv2. It is still in its early stages and has not been adopt= ed as any WG’s item yet.

 

Feedback is welcome.

 

Rgs,

Panos

 

 

&nbs= p;

From: IPsec [mailto:ipsec-bounces@ie= tf.org] On Behalf Of Perlner, Ray
Sent: Wednesday, January 06, 2016 3:33 PM
To: ipsec@ietf.org
Cc: Liu, Yi-Kai <yi-kai.liu@nist.gov>; Moody, Dustin <dusti= n.moody@nist.gov>; Frankel, Sheila E. <sheila.frankel@nist.gov>; W= altermire, David A. <david.waltermire@nist.gov>
Subject: [IPsec] NIST question concerning IKEv2 and quantum resistan= ce

 

Hi all.

 

NIST is investigating quantum-resista= nt alternatives to presently standardized public-key algorithms. We are rea= ching out to the IPSec working group to determine if there are any unique needs associated with trying to add quantum-resist= ance to IKEv2, which currently only uses variants of the Diffie-Hellman key= exchange.

 

We believe a number of the properties= of the Diffie-Hellman construction (such as perfect forward secrecy) can b= e met using generic constructions based on standard cryptographic primitives and security models (such as IND-CCA2 encryption = and EUF-CMA signature) as long as key generation times are fast. If IKEv2 c= an accommodate such generic constructions, there are likely to be many prop= osals to choose from. However, there are some additional properties of the Diffie-Hellman exchange which may be= difficult to duplicate (such as the property that the responder can comput= e his key exchange message without seeing the initiator’s key-exchang= e message) and it’s not as clear to us what the security model for a key exchange replacing DH should be.

 

So in summary, we would like to answe= rs to the following questions:

1)    &= nbsp; Can IKEv2 can be modified to = replace the Diffie-Hellman exchange with a generic construction based on st= andard encryption, signature, and PRF primitives?

2)    &= nbsp;  If not, what specific s= ecurity and correctness requirements should we target to meet the need?

 

Thanks,

Ray

 

 

 

--_000_21404b33280a4b4abc841dbec888c848XCHALN010ciscocom_-- From nobody Tue Jan 12 00:09:16 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D031A1B0E for ; Tue, 12 Jan 2016 00:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 cj4y5gaexzZM for ; Tue, 12 Jan 2016 00:09:13 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5991A1B17 for ; Tue, 12 Jan 2016 00:09:12 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id cl12so50428757lbc.1 for ; Tue, 12 Jan 2016 00:09:12 -0800 (PST) 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-type; bh=ZtZOPZ7GkCQKV4y8g4T11wmWtJJW5kx4JW0XxzxHvFY=; b=CbS6rJunBWPOjHvpad9Vox2F/G3oDF00gX1J93c90S0Q6nlHPtrMRmqVEGTEOC9MvV kxd8pQhYMfbX1u2XpawsFRM3Evks15YEoXnmD+yp2JAVK0z4XOrkzrlwTrnPfIvOGqtA 4dQS5u9itfm7bIS568ocHfKq4f2gPFPJP6+T+y0aThlUWYb0rREQ6zVh2QiYk76PbuKE q9b59vRzXrREdiay42g8nyoVlUjgjznHYDeHps1Z1IhYUfBuymqXZIySyh9X6inCh3Rq kUTygl/fZHC9HkbXkuEHLZSeJzpZEwuAUer8UJ8Muvj9WfjVxz2XEJ5JQrV5hFoAH5+Q 0otA== X-Received: by 10.112.14.234 with SMTP id s10mr48105772lbc.136.1452586150702; Tue, 12 Jan 2016 00:09:10 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id l8sm11502517lfe.24.2016.01.12.00.09.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 00:09:09 -0800 (PST) Message-ID: <5810658E1DC448D59B09CAC6D8678445@buildpc> From: "Valery Smyslov" To: "Panos Kampanakis \(pkampana\)" , "Perlner, Ray" , References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> Date: Tue, 12 Jan 2016 11:09:20 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0554_01D14D29.AFAB1DC0" 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: "Liu, Yi-Kai" , "David McGrew \(mcgrew\)" , "Waltermire, David A." , "Frankel, Sheila E." , "Scott Fluhrer \(sfluhrer\)" , "Moody, Dustin" Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 08:09:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0554_01D14D29.AFAB1DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Panos, thank you for sharing this draft. A couple of quick comments.=20 First, I think that it is better to use a new status Notification to = negotiate this feature=20 rather than a Vendor ID payload. It is more in line with the way other = IKEv2 extensions=20 are negotiated and it would allow not to waste 16 bytes in the = IKE_SA_INIT messages.=20 And second, I'm not comfortable with using fixed algorithms (AES, = HMAC_SHA2) and not addressing algorithm agility. Fortunately, your draft says that this = might change in future versions. I think it is an important feature ant I hope it'll = be addressed. Regards, Valery Smyslov. ----- Original Message -----=20 From: Panos Kampanakis (pkampana)=20 To: Perlner, Ray ; ipsec@ietf.org=20 Cc: Liu, Yi-Kai ; David McGrew (mcgrew) ; Waltermire, David A. ; = Frankel, Sheila E. ; Scott Fluhrer (sfluhrer) ; Moody, Dustin=20 Sent: Tuesday, January 12, 2016 8:44 AM Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum = resistance Hi Ray, =20 Scott's https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is = the first take of QC resistant IKEv2. It is still in its early stages = and has not been adopted as any WG's item yet.=20 =20 Feedback is welcome. =20 Rgs, Panos =20 =20 =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Perlner, Ray Sent: Wednesday, January 06, 2016 3:33 PM To: ipsec@ietf.org Cc: Liu, Yi-Kai ; Moody, Dustin = ; Frankel, Sheila E. ; = Waltermire, David A. Subject: [IPsec] NIST question concerning IKEv2 and quantum resistance =20 Hi all.=20 =20 NIST is investigating quantum-resistant alternatives to presently = standardized public-key algorithms. We are reaching out to the IPSec = working group to determine if there are any unique needs associated with = trying to add quantum-resistance to IKEv2, which currently only uses = variants of the Diffie-Hellman key exchange. =20 We believe a number of the properties of the Diffie-Hellman = construction (such as perfect forward secrecy) can be met using generic = constructions based on standard cryptographic primitives and security = models (such as IND-CCA2 encryption and EUF-CMA signature) as long as = key generation times are fast. If IKEv2 can accommodate such generic = constructions, there are likely to be many proposals to choose from. = However, there are some additional properties of the Diffie-Hellman = exchange which may be difficult to duplicate (such as the property that = the responder can compute his key exchange message without seeing the = initiator's key-exchange message) and it's not as clear to us what the = security model for a key exchange replacing DH should be. =20 So in summary, we would like to answers to the following questions: 1) Can IKEv2 can be modified to replace the Diffie-Hellman = exchange with a generic construction based on standard encryption, = signature, and PRF primitives? 2) If not, what specific security and correctness requirements = should we target to meet the need? =20 Thanks, Ray =20 =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0554_01D14D29.AFAB1DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Panos,
 
thank you for sharing this draft. A couple=20 of quick comments.
 
First, I think that it is better to use a new status = Notification to negotiate this feature =
rather than a Vendor ID payload. It is more in line = with the=20 way other IKEv2 extensions
are negotiated and it would allow not to waste 16 = bytes in the=20 IKE_SA_INIT messages.
 
And second, I'm not comfortable with using fixed = algorithms=20 (AES, HMAC_SHA2) and
not addressing algorithm agility. Fortunately, your = draft says=20 that this might change
in future versions. I think it is an important = feature=20 ant I hope it'll be addressed.
 
Regards,
Valery Smyslov.
 
----- Original Message -----
From:=20 Panos = Kampanakis=20 (pkampana)
Cc: Liu, Yi-Kai ; David McGrew (mcgrew) ; Waltermire, David A. ; = Frankel,=20 Sheila E. ; Scott Fluhrer (sfluhrer) ; Moody,=20 Dustin
Sent: Tuesday, January 12, 2016 = 8:44=20 AM
Subject: Re: [IPsec] NIST = question=20 concerning IKEv2 and quantum resistance

Hi=20 Ray,

 

Scott=92s=20 https:/= /datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/=20 is the first take of QC resistant IKEv2. It is still in its early = stages and=20 has not been adopted as any WG=92s item yet.

 

Feedback=20 is welcome.

 

Rgs,

Panos

 

 

 

From: IPsec=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Perlner,=20 Ray
Sent: Wednesday, January 06, 2016 3:33 PM
To: = ipsec@ietf.org
Cc: Liu, = Yi-Kai=20 <yi-kai.liu@nist.gov>; Moody,=20 Dustin <dustin.moody@nist.gov>; = Frankel,=20 Sheila E. <sheila.frankel@nist.gov>; = Waltermire, David A. <david.waltermire@nist.gov&g= t;
Subject:=20 [IPsec] NIST question concerning IKEv2 and quantum=20 resistance

 

Hi=20 all.

 

NIST=20 is investigating quantum-resistant alternatives to presently = standardized=20 public-key algorithms. We are reaching out to the IPSec working group = to=20 determine if there are any unique needs associated with trying to add=20 quantum-resistance to IKEv2, which currently only uses variants of the = Diffie-Hellman key exchange.

 

We=20 believe a number of the properties of the Diffie-Hellman construction = (such as=20 perfect forward secrecy) can be met using generic constructions based = on=20 standard cryptographic primitives and security models (such as = IND-CCA2=20 encryption and EUF-CMA signature) as long as key generation times are = fast. If=20 IKEv2 can accommodate such generic constructions, there are likely to = be many=20 proposals to choose from. However, there are some additional = properties of the=20 Diffie-Hellman exchange which may be difficult to duplicate (such as = the=20 property that the responder can compute his key exchange message = without=20 seeing the initiator=92s key-exchange message) and it=92s not as clear = to us what=20 the security model for a key exchange replacing DH should=20 be.

 

So=20 in summary, we would like to answers to the following=20 questions:

1)     =20 Can=20 IKEv2 can be modified to replace the Diffie-Hellman exchange with a = generic=20 construction based on standard encryption, signature, and PRF=20 primitives?

2)     =20  If=20 not, what specific security and correctness requirements should we = target to=20 meet the need?

 

Thanks,

Ray

 

 

 

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0554_01D14D29.AFAB1DC0-- From nobody Tue Jan 12 06:56:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4088B1B2A84 for ; Tue, 12 Jan 2016 06:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 CJiwK9SgNxjj for ; Tue, 12 Jan 2016 06:56:26 -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 E84F81B2A6C for ; Tue, 12 Jan 2016 06:56:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pfw2v2MlKzBT for ; Tue, 12 Jan 2016 15:56:23 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 AMKHuaC1rk7S for ; Tue, 12 Jan 2016 15:56:22 +0100 (CET) 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, 12 Jan 2016 15:56:22 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CCAB6614A489; Tue, 12 Jan 2016 09:56:21 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CCAB6614A489 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C92CD130989 for ; Tue, 12 Jan 2016 09:56:21 -0500 (EST) Date: Tue, 12 Jan 2016 09:56:21 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] meeting at IETF-95 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:56:27 -0000 I hope we are scheduling a meeting for IETF-95. Last time we did not meet and ended up meeting in the hallway. This time there are more drafts being suggested and worked on. Paul From nobody Tue Jan 12 08:27:56 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A993F1B2B39 for ; Tue, 12 Jan 2016 08:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2bJvWzX35xVb for ; Tue, 12 Jan 2016 08:27:52 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D771B2AB0 for ; Tue, 12 Jan 2016 08:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1452616046; x=2316529646; 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=jFt8qu3CPJ0gOkGjZbcSkXuRt2l4C5EvikKYTZICU80=; b=r3QHhKY6fMDufEGgYbs6bYhhgP3UKs9XCHzEbCdQk1o9Yb0t4lgqJk1SIiGfKNG5 lTM3WAfZN+bP5+zEwsH+Cm4Ms6znm/Sc7OOhBrcE1qwd9zE4hs0p+P1NGQf4dLvH T0lptIjuwzLODNQQfuv10I6OHdxr3M4KPV2c8t2uO4HQvPvrl70io5ty0ch8ximN NYg5NPiFP/qgmwlqDF7ZzJl1rQpO5oa8pdNEdW6FUWRfsrfEXRoh6qLlyAiYpS5N ubHlARhKCoCevffd8AA/83WgKrS1DEwpR8gm2vPPXUtb1ifhsfl56wyLyAqBUBnr CUtYHYZiz8hsqnVlI1wrhg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 30.A4.03960.D6925965; Tue, 12 Jan 2016 08:27:26 -0800 (PST) X-AuditID: 11973e12-f796d6d000000f78-25-5695296e3808 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id BD.A9.03545.C6925965; Tue, 12 Jan 2016 08:27:25 -0800 (PST) Received: from [17.153.87.155] (unknown [17.153.87.155]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O0U008NBLPNWM40@fenugreek.apple.com> for ipsec@ietf.org; Tue, 12 Jan 2016 08:27:24 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.0 \(3159\)) From: Tommy Pauly In-reply-to: <22163.54776.641819.67931@fireball.acr.fi> Date: Tue, 12 Jan 2016 08:27:30 -0800 Content-transfer-encoding: quoted-printable Message-id: <4C042BBC-C27F-4B87-8EB5-56862B309A63@apple.com> References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <22163.54776.641819.67931@fireball.acr.fi> To: Valery Smyslov X-Mailer: Apple Mail (2.3159) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FDorJunOTXMYFOHjsX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceniP8aCG0IVj04cZm9gXMzfxcjJISFgIvH+yX1GCFtM4sK9 9WxdjFwcQgJ7GSVmT77EBFP07eUJRojEPCaJK6u72SGcaUwS/848Yu5i5OAQFpCQ2LwnEcRk FlCXmDIlF6SXV0BfYtXDPSwgtrBAkkTvi7usIDabgIrE8W8bmEFsTgFziVk7foDVsAioSrzb MAksziyQILH12RpWCFtb4sm7C6wQM20k3m/eyAJ1AqNE0+TD7CAJEaDmm9t+MkMcLSsx60M/ M0iRhMASNonV22axTWAUmYVw3ywk981CsmMBI/MqRqHcxMwc3cw8E73EgoKcVL3k/NxNjKDw nm4ntIPx1CqrQ4wCHIxKPLwZ7FPChFgTy4orcw8xSnOwKInzbngyKUxIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDY4LbwlcGlye2K4ckMSnqHjgc1W/MXdpvFvJOzHyur4IV86/wLTMCDlhp 8dUJy0f3JsffeWmzsm11LGvj9gXzNAVdwybzv+ZRXmq1Sv/O6/tfN+89av58bpmPQutXuVXs 83SXTfv2YONMfyWN2X/fSqX9KFr+rmM5h8FFjg0nPBz/fn+a6vE+TomlOCPRUIu5qDgRADF5 uytQAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FCcqJurOTXMYNNZJov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49LFf4wFN4QqHp04zN7AuJi/i5GTQ0LAROLbyxOMELaYxIV7 69m6GLk4hATmMUlcWd3NDuFMY5L4d+YRcxcjB4ewgITE5j2JICazgLrElCm5IL28AvoSqx7u YQGxhQWSJHpf3GUFsdkEVCSOf9vADGJzCphLzNrxA6yGRUBV4t2GSWBxZoEEia3P1rBC2NoS T95dYIWYaSPxfvNGFqgTGCWaJh9mB0mIADXf3PaTGeJoWYlZH/qZJzAKzkI4aRaSk2YhGbuA kXkVo0BRak5ipZFeYkFBTqpecn7uJkZwOBY672A8tszqEKMAB6MSD28G+5QwIdbEsuLK3EOM EhzMSiK8v1WnhgnxpiRWVqUW5ccXleakFh9iTAZ6ZiKzlGhyPjBW8kriDU1MDEyMjc2Mjc1N zEkTVhLnPSbZEyYkkJ5YkpqdmlqQWgSzhYmDU6qBcUtHdnrG77mMCoUNM/9MiC+6F3/16D8j /jl/VJO3TcrLuHSG/0loUrQU08uem47MeY+WnnvIcyBlp1fSQqELXiJCu1/fXhsQ/y3FIPKT zVbheUIPenzmPYx6Xyyl7lV4lr8tvbHS5vftDpXyysMTLI1v92YdmnSqfb7QT6PGAy5xLWIz H0udVWIpzkg01GIuKk4EALcS8ICLAgAA Archived-At: Cc: IPsecME WG , Tero Kivinen , Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:27:54 -0000 > On Jan 11, 2016, at 8:19 AM, Tero Kivinen wrote: >=20 > Yoav Nir writes: >> Second, as I understand it, those battery-powered devices tend to >> use 802.15.4 networks with 127-byte frames. There=E2=80=99s 6LoWPAN = to >> provide fragmentation support, but that=E2=80=99s similar to using = IKE=E2=80=99s >> fragmentation for the same issue. Can anything be done at all with >> 127-byte frames, that include the (IPv6?) headers, the 8-byte UDP >> header, the 20-byte IKEv2 header in addition to all the payload >> headers? If we need fragmentation anyway, I don=E2=80=99t know if >> compression matters.=20 >=20 > 802.15.4 networks also have 802.15.9, which will provide its own > fragmentation and reassembly for the IKEv2 frames (not including IP or > UDP headers, as those are not used, this is raw IKEv2 frames over raw > 802.15.4 frames). >=20 > In those environments the IKEv2 is used to negotiate link keys between > two devices. The payloads are already quite compacted, i.e. there will > not be several proposals for ciphers, only one, and all extra payloads > are omitted anyways.=20 Tero=E2=80=99s comments seem to confirm the idea that constrained = devices will generally be using a small set of proposals, and thus do = not need compression.=20 The document referred to in the draft as IPSEC-IOT-REQS, = draft-mglt-6lo-diet-esp-requirements-01, recommends essentially one = algorithm for the Child SA algorithm (AES-CCM), so it may be safe to = assume that IoT devices could converge to a small set of IKE SA = algorithms to standardly use. And, while this document does recommend = compression for ESP packets, I can see more of an argument being made = for compressing ESP traffic (which may be many packets) than for = compressing the IKE_SA_INIT packet, which is already a one-time-cost = small packet. Valery, do you have specific real-world examples of IKE_SA_INIT packets = that are being used by IoT devices that get a benefit from this = compression? Without this, it seems that adding compression to IKE would = add a fair amount of complexity to optimize a packet that is already = fairly inexpensive to send. Thanks, Tommy > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 12 12:52:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456F31A88DF for ; Tue, 12 Jan 2016 12:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 f3Jc3E5inx95 for ; Tue, 12 Jan 2016 12:52:49 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CA81A88D9 for ; Tue, 12 Jan 2016 12:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1452631968; x=2316545568; 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=PZcVXqN4f2sUhAnKEYEVCvND7daV8r5enLZyYffGZNM=; b=eW4/TFjbyMPYRjgKZMduvEMzDBHQFY31IxzqrFgrUen8BtFjkA2MVNAEkuJlvlFW tx0oDK31Wi1zk8DQwmnFP7rDGn5fbrHCpNYNATJ1GjZv+oeovlLP5StR8KiX9I6Z SApH3TlhotbO1CwRDDHtrX7UHyQtyntqRBpILpNUP2z6/rHhxBv9+BsTKkvSgaSh OYBT+O64VmBNEPO5KBQjqXHH3bpyzzJVI18/oDBkI3zdgCC2bsLKxhW81cftUJe3 koHAc71FuC789W+R5DUmW1iWubHiECmoKeHb3YZD8ZsWx1IAOoGs3zq+Dp/9QZ9c 76JkbQJo/4I/a8l+8JyRSQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 23.F1.27232.0A765965; Tue, 12 Jan 2016 12:52:48 -0800 (PST) X-AuditID: 11973e15-f79366d000006a60-0e-569567a0211f Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id CB.68.05180.0A765965; Tue, 12 Jan 2016 12:52:48 -0800 (PST) Received: from [17.226.23.86] (unknown [17.226.23.86]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O0U00BREXZZENA0@cilantro.apple.com> for ipsec@ietf.org; Tue, 12 Jan 2016 12:52:48 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3159\)) From: Tommy Pauly In-reply-to: Date: Tue, 12 Jan 2016 12:52:54 -0800 Content-transfer-encoding: 7bit Message-id: <4B79FA45-405A-4829-A23F-58E1D8AE2092@apple.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3159) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYrLsgfWqYwZJvqhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvp1EgU3mCsOvVzI1sD4hamLkZNDQsBEYuXcq8wQtpjEhXvr 2boYuTiEBPYyStx7+oEZpujs17mMEIk5TBJv2s8zQTgTmCQWrtvG2sXIwSEsICGxeU8iSAOz gJbE+p3HwTbwCuhLrHq4hwXEFhbQlFj84h4biM0moCJx/NsGsAWcAg4SnWdPsoPYLAKqEu/+ PGOFmKMhcfEJRJxZQF5i85q3zBAzbSQO718HViMkYC9xaWkD2HwRAUWJSWcesUAcLSsx60M/ M8idEgJL2CSOPHjNNIFRZBaS+2YhuW8Wkh0LGJlXMQrlJmbm6GbmmeklFhTkpOol5+duYgSF 93Q70R2MZ1ZZHWIU4GBU4uHNYJ8SJsSaWFZcmXuIUZqDRUmc99CZSWFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGLerRtZafVTcuFGnvm7mDZ8S4RNVzNESQi7ey5n+f7T59NtrUpLk0i0d YaLZuaJtTM/VtVev+ba7TsB0g2vjbiY+jyf/i4LuPOa+WnpSt9PBMa9cV6DC7WD/snDP6cXS nwQM7Lb+iq9vThExjs7RWrbgwL6rkZ+/u33beObgDGnvh/P8jnk/UWIpzkg01GIuKk4EALm4 igNQAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FAspLsgfWqYwe0OFYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/06iYIbzBWHXi5ka2D8wtTFyMkhIWAicfbrXEYIW0ziwr31 bF2MXBxCAnOYJN60n2eCcCYwSSxct421i5GDQ1hAQmLznkSQBmYBLYn1O4+DDeIV0JdY9XAP C4gtLKApsfjFPTYQm01AReL4tw3MIDangINE59mT7CA2i4CqxLs/z1gh5mhIXHwCEWcWkJfY vOYtM8RMG4nD+9eB1QgJ2EtcWtoANl9EQFFi0plHLBBHy0rM+tDPPIFRcBaSk2YhOWkWkrEL GJlXMQoUpeYkVhrrJRYU5KTqJefnbmIEh2Nh8A7GP8usDjEKcDAq8fBmsE8JE2JNLCuuzD3E KMHBrCTCyx06NUyINyWxsiq1KD++qDQntfgQYzLQMxOZpUST84GxklcSb2hiYmBibGxmbGxu Yk6asJI473HJnjAhgfTEktTs1NSC1CKYLUwcnFINjJkv/ts5GHCucjvoHKrhL8YXypHM82gq y2slZYVL/sseKb/Munvufr5cnkpzk3+5mHm1jVxKrEu+71u5PzENOvd2X7G/KFTrcz4h7lLH ojsu388Ybt3fYHT05dzJaY4XL925xfGsTTc+58uq9ZebKpyPqH/mlT2T5r73ga6hop30p12l h5VeKbEUZyQaajEXFScCAG+ZiOGLAgAA Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] meeting at IETF-95 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 20:52:50 -0000 +1 to having a meeting at IETF 95. Thanks, Tommy > On Jan 12, 2016, at 6:56 AM, Paul Wouters wrote: > > > I hope we are scheduling a meeting for IETF-95. Last time we did not > meet and ended up meeting in the hallway. This time there are more > drafts being suggested and worked on. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jan 13 06:32:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F181B2E34 for ; Wed, 13 Jan 2016 06:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2Iuhr0rdmzLM for ; Wed, 13 Jan 2016 06:32:38 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92311B2E0E for ; Wed, 13 Jan 2016 06:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31281; q=dns/txt; s=iport; t=1452695558; x=1453905158; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EfWjgmdhIpPMhyOxepb7+H+TQPf79hKlsTGJDxS/b6Y=; b=gZcQck7q8cwvdTQuwWBm54C6+fRl87cBBWOp89uIp4gn+XIbvPLN/UVN a+dWUr3q9RU0yDPFKbr9w6ljL/356Kal7tdEavD/Z7LRLLPvwgbnNxUch eUXZaAHKwSw3yu+VVTMct4+Fgz3JMsuiEhPvhejpA7fOuge5CikqmJyRD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQBxX5ZW/xbLJq1egm6BHm0GiFSzH?= =?us-ascii?q?AENgWQYAQmFbQKBbBQBAQEBAQEBgQqENAEBAQQBAQEqQQYFDAQCAQgOAwQBASE?= =?us-ascii?q?BBgchBgsUCQgBAQQBDQUIiBEDEg69CQ2DGQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RQEhlaDe4EEgk+CLwYJhDAFh2dYilOEAwGFQoYfgXGBZY0ihWaBDoNtg3IBIAE?= =?us-ascii?q?BQoIOH4FdcoUUgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,289,1449532800"; d="scan'208,217";a="631604285" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 14:32:34 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0DEWXuT020636 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 14:32:34 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.1104.5; Wed, 13 Jan 2016 09:32:33 -0500 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.1104.009; Wed, 13 Jan 2016 09:32:32 -0500 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , "Panos Kampanakis (pkampana)" , "Perlner, Ray" , "ipsec@ietf.org" Thread-Topic: [IPsec] NIST question concerning IKEv2 and quantum resistance Thread-Index: AdFIwXQqaqlOB64eRs6Nv1l1sgbGQAEOi2dAAAU5Ue0APu0GcA== Date: Wed, 13 Jan 2016 14:32:32 +0000 Message-ID: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> In-Reply-To: <5810658E1DC448D59B09CAC6D8678445@buildpc> 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.59] Content-Type: multipart/alternative; boundary="_000_e8e77717ba864c44a8a9b40c33654d83XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Moody, Dustin" , "Liu, Yi-Kai" , "David McGrew \(mcgrew\)" , "Frankel, Sheila E." , "Waltermire, David A." Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 14:32:43 -0000 --_000_e8e77717ba864c44a8a9b40c33654d83XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Valery Smyslov [mailto:svanru@gmail.com] Sent: Tuesday, January 12, 2016 3:09 AM To: Panos Kampanakis (pkampana); Perlner, Ray; ipsec@ietf.org Cc: Liu, Yi-Kai; David McGrew (mcgrew); Waltermire, David A.; Frankel, Shei= la E.; Scott Fluhrer (sfluhrer); Moody, Dustin Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi Panos, thank you for sharing this draft. A couple of quick comments. First, I think that it is better to use a new status Notification to negoti= ate this feature rather than a Vendor ID payload. It is more in line with the way other IKEv= 2 extensions are negotiated and it would allow not to waste 16 bytes in the IKE_SA_INIT = messages. That is certainly a reasonable suggestion. And second, I'm not comfortable with using fixed algorithms (AES, HMAC_SHA2= ) and not addressing algorithm agility. Fortunately, your draft says that this mi= ght change in future versions. I think it is an important feature ant I hope it'll be = addressed. There are two uses of crypto within the protocol: - It defines the transform of the nonce from the on-the-wire versi= on into the one presented to the IKEv2 KDF (mixing in the PPK). - The initiator gives an indication of which PPK to use (without l= eaking any information about it to someone two doesn't know the value). For the first use, it would be reasonable to have the initiator define a bi= tmask of the algorithms it supports, and the responder to select one This second use is rather trickier to have agility; it is sent before the i= nitiator has any contact to the responder. I don't see how the responder c= an indicate which algorithms it supports (without adding a round trip to th= e protocol). I don't see any really good alternatives: - The initiator could send an indication about which algorithm it = is used to encode the ppk (and the responder either understands it or rejec= ts it). I don't see how that is much of an improvement. - The initiator could send the indication with multiple algorithms= (and the responder selects which one it supports); however that strikes me= as secure as the weakest of the supported algorithms (because if one of th= em leaks any information, the attacker learns that leakage). We can update the draft to use a status notification, and to have a negotia= ted nonce transform; I think we'll leave the indication algorithm fixed (as= I don't see a good alternative). Regards, Valery Smyslov. ----- Original Message ----- From: Panos Kampanakis (pkampana) To: Perlner, Ray ; ipsec@ietf.org Cc: Liu, Yi-Kai ; David McGrew (mcgrew) ; Waltermire, David A. = ; Frankel, Sheila E. ; Scott Fluhrer (sfluh= rer) ; Moody, Dustin Sent: Tuesday, January 12, 2016 8:44 AM Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi Ray, Scott's https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the fir= st take of QC resistant IKEv2. It is still in its early stages and has not = been adopted as any WG's item yet. Feedback is welcome. Rgs, Panos From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Perlner, Ray Sent: Wednesday, January 06, 2016 3:33 PM To: ipsec@ietf.org Cc: Liu, Yi-Kai >; Moody, D= ustin >; Frankel, Sheil= a E. >; Waltermire,= David A. > Subject: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi all. NIST is investigating quantum-resistant alternatives to presently standardi= zed public-key algorithms. We are reaching out to the IPSec working group t= o determine if there are any unique needs associated with trying to add qua= ntum-resistance to IKEv2, which currently only uses variants of the Diffie-= Hellman key exchange. We believe a number of the properties of the Diffie-Hellman construction (s= uch as perfect forward secrecy) can be met using generic constructions base= d on standard cryptographic primitives and security models (such as IND-CCA= 2 encryption and EUF-CMA signature) as long as key generation times are fas= t. If IKEv2 can accommodate such generic constructions, there are likely to= be many proposals to choose from. However, there are some additional prope= rties of the Diffie-Hellman exchange which may be difficult to duplicate (s= uch as the property that the responder can compute his key exchange message= without seeing the initiator's key-exchange message) and it's not as clear= to us what the security model for a key exchange replacing DH should be. So in summary, we would like to answers to the following questions: 1) Can IKEv2 can be modified to replace the Diffie-Hellman exchange wi= th a generic construction based on standard encryption, signature, and PRF = primitives? 2) If not, what specific security and correctness requirements should= we target to meet the need? Thanks, Ray ________________________________ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_e8e77717ba864c44a8a9b40c33654d83XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Valery S= myslov [mailto:svanru@gmail.com]
Sent: Tuesday, January 12, 2016 3:09 AM
To: Panos Kampanakis (pkampana); Perlner, Ray; ipsec@ietf.org
Cc: Liu, Yi-Kai; David McGrew (mcgrew); Waltermire, David A.; Franke= l, Sheila E.; Scott Fluhrer (sfluhrer); Moody, Dustin
Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resi= stance

 

Hi Panos,

 

thank you for shari= ng this draft. A couple of quick comments.

 

First, I think that= it is better to use a new status Notification to negotiate this feature

rather than a Vendo= r ID payload. It is more in line with the way other IKEv2 extensions

are negotiated and = it would allow not to waste 16 bytes in the IKE_SA_INIT messages.

 <= /p>

That is certainly a reaso= nable suggestion.

 

And second, I'm not= comfortable with using fixed algorithms (AES, HMAC_SHA2) and

not addressing algo= rithm agility. Fortunately, your draft says that this might change

in future vers= ions. I think it is an important feature ant I hope it'll be addressed.

 <= /p>

There are two uses of cry= pto within the protocol:

-  &n= bsp;       It defines the tr= ansform of the nonce from the on-the-wire version into the one presented to= the IKEv2 KDF (mixing in the PPK).

-  &n= bsp;       The initiator giv= es an indication of which PPK to use (without leaking any information about= it to someone two doesn’t know the value).

 <= /p>

For the first use, it wou= ld be reasonable to have the initiator define a bitmask of the algorithms i= t supports, and the responder to select one

 <= /p>

This second use is rather= trickier to have agility; it is sent before the initiator has any contact = to the responder.  I don’t see how the responder can indicate which algorithms it supports (without adding a round trip to the protocol)= .  I don’t see any really good alternatives:

-  &n= bsp;       The initiator cou= ld send an indication about which algorithm it is used to encode the ppk (a= nd the responder either understands it or rejects it).  I don’t see how that is much of an improvement.

-  &n= bsp;       The initiator cou= ld send the indication with multiple algorithms (and the responder selects = which one it supports); however that strikes me as secure as the weakest of the supported algorithms (because if one of them leaks a= ny information, the attacker learns that leakage).

 <= /p>

We can update the draft t= o use a status notification, and to have a negotiated nonce transform; I th= ink we’ll leave the indication algorithm fixed (as I don’t see a good alternative).

 <= /p>

=  

Regards,

Valery Smyslov.

 

----- Original Message -----

Sent: Tuesday, J= anuary 12, 2016 8:44 AM

Subject: Re: [IP= sec] NIST question concerning IKEv2 and quantum resistance

 

Hi Ray,=

 <= /p>

Scott’s https:= //datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the first take of= QC resistant IKEv2. It is still in its early stages and has not been adopt= ed as any WG’s item yet.

 <= /p>

Feedback is welcome.=

 <= /p>

Rgs,

Panos

 <= /p>

 <= /p>

 <= /p>

From: IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Perlner, Ray
Sent: Wednesday, January 06, 2016 3:33 PM
To: ipsec@ietf.org
Cc: Liu, Yi-Kai <yi-kai.li= u@nist.gov>; Moody, Dustin <dustin.moody@nist.gov>; Frankel, Sheila E. <sheila.frankel@nist.gov>; Waltermire, David A. <davi= d.waltermire@nist.gov>
Subject: [IPsec] NIST question concerning IKEv2 and quantum resistan= ce

 

Hi all.

 <= /p>

NIST is investigating qua= ntum-resistant alternatives to presently standardized public-key algorithms= . We are reaching out to the IPSec working group to determine if there are any unique needs associated with trying to add quantum-resist= ance to IKEv2, which currently only uses variants of the Diffie-Hellman key= exchange.

 <= /p>

We believe a number of th= e properties of the Diffie-Hellman construction (such as perfect forward se= crecy) can be met using generic constructions based on standard cryptographic primitives and security models (such as IND-CCA2 encryption = and EUF-CMA signature) as long as key generation times are fast. If IKEv2 c= an accommodate such generic constructions, there are likely to be many prop= osals to choose from. However, there are some additional properties of the Diffie-Hellman exchange which may be= difficult to duplicate (such as the property that the responder can comput= e his key exchange message without seeing the initiator’s key-exchang= e message) and it’s not as clear to us what the security model for a key exchange replacing DH should be.

 <= /p>

So in summary, we would l= ike to answers to the following questions:

1)=       Can IKEv2 can be modified to replace the = Diffie-Hellman exchange with a generic construction based on standard encry= ption, signature, and PRF primitives?

2)&= nbsp;      If not, what specific security and = correctness requirements should we target to meet the need?

 <= /p>

Thanks,=

Ray

&nbs= p;

 = ;

 

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

--_000_e8e77717ba864c44a8a9b40c33654d83XCHRTP006ciscocom_-- From nobody Wed Jan 13 07:09:30 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220961B2E94 for ; Wed, 13 Jan 2016 07:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 en8W_tdRApIm for ; Wed, 13 Jan 2016 07:09:27 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 183921B2E8C for ; Wed, 13 Jan 2016 07:09:27 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id x4so35642357lbm.0 for ; Wed, 13 Jan 2016 07:09:26 -0800 (PST) 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-type:content-transfer-encoding; bh=HQzaHHdhgbQdfM4F7tzAvtpZ5F43oWZxpb8xj7cvF4c=; b=kLVawCMAbK2nlKqOpxpe4wgW4N8jugLRdvJgp9az4jP+QyUz7kCG2MxPsnv/JBZoUr bnCaMZTNaw4ijPqnTl2Rljy/xYHbWfe7+BAG497ToK8SpnuZ7Xj4PbADHZjkj2MJrayB TfEOZlMHS/W0HbUx9JXaXbMkM35E5LlQ60mllRaUJoBmDbCuPj+JX8xi7eBvtuq/4Mer nTnw4CCRzfv74FjnP4HeRcW880kJutAwCTtzrqx1PYSPB8ERdlwhdvHgrr/JVWzCzrEv iH6N1/A/1vfVPhlC2M0L7qgck3i0dsBYVMAET3FrGSbjR+gpQOqsvk7Ov5iO6Ql1rt5w uAxg== 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-type:content-transfer-encoding; bh=HQzaHHdhgbQdfM4F7tzAvtpZ5F43oWZxpb8xj7cvF4c=; b=KGegAHsw9kGDPI/4CDS8PRCgBffQCBWfKIF2qHC81XdIcT1eXV94AnQK3rB+c/YnU9 dRceV5PfkSJ0vg+pep+J7KgVSzHgEJQxAG+Mg6DpgQZlvYgCJZYCmzoVU+9tk+hi2NUk FnlKjsavuJJg8EsiVEW4JdGrKb2hsWS0rAbb6fuUAIbrNogvpJ51MZcsMfMooJlxX2X+ XMudLicY9YF+qb+QFNvaKcdWtZk994HAciLKcVbcwS5NAC8tTKZEX3RI9y5jEwZYdKdK EEA01IDWwpqIbnkv53lcdPZVGNkd7PqTDKC4IpJ1BsERtVuu4fht0Blt82wBXHDY4njC Msow== X-Gm-Message-State: ALoCoQlhI3OEQLldXvyChPWOJ+qEER3CMosJKMUnozYNz9Y49jvoXYHdYNcvYCeHblcal+y5ZikIkU0VjosAEDUNo1xH4Jlyug== X-Received: by 10.112.129.134 with SMTP id nw6mr51566851lbb.10.1452697765258; Wed, 13 Jan 2016 07:09:25 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f4sm237722lbs.10.2016.01.13.07.09.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 07:09:24 -0800 (PST) Message-ID: <766BDC320C824A3793FE8DD74566FC06@buildpc> From: "Valery Smyslov" To: "Tommy Pauly" References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <22163.54776.641819.67931@fireball.acr.fi> <4C042BBC-C27F-4B87-8EB5-56862B309A63@apple.com> Date: Wed, 13 Jan 2016 18:09:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit 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 , Tero Kivinen , Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:09:29 -0000 Hi Tommy, >> In those environments the IKEv2 is used to negotiate link keys between >> two devices. The payloads are already quite compacted, i.e. there will >> not be several proposals for ciphers, only one, and all extra payloads >> are omitted anyways. > > Tero’s comments seem to confirm the idea that constrained devices will generally > be using a small set of proposals, and thus do not need compression. Well, I'm not an expert in IoT devices. And it's true that with minimal set of transforms and with reduced number of supported features the compression won't help much in IKEv2. However, I'm a bit afraid of oversimplifying the whole picture. It seems to me that there may be different kinds of constrained devices, and some of them would be more advanced, then the most restricted ones. And I think that the IoT world won't be isolated, so that at least some of the IoT devices would have to communicate with the "big world" peers and thus would have to support more IKEv2 features and extensions, that would make their messages larger. And for those devices the compression could be useful. > The document referred to in the draft as IPSEC-IOT-REQS, draft-mglt-6lo-diet-esp-requirements-01, > recommends essentially one algorithm for the Child SA algorithm (AES-CCM), > so it may be safe to assume that IoT devices could converge to a small set of IKE SA algorithms > to standardly use. And, while this document does recommend compression for ESP packets, > I can see more of an argument being made for compressing ESP traffic (which may be many packets) > than for compressing the IKE_SA_INIT packet, which is already a one-time-cost small packet. The compression draft is not only about the IKE_SA_INIT messages. It also allows the subsequent messages to be compressed. While the IKE_AUTH is also one-time message, I can imagine that some restricted devices could use IKE SA to transmit application data (it can appear to be easier than to implement ESP). In this case the compression would be useful too. > Valery, do you have specific real-world examples of IKE_SA_INIT packets that are being used > by IoT devices that get a benefit from this compression? Without this, it seems that adding > compression to IKE would add a fair amount of complexity to optimize a packet that is already > fairly inexpensive to send. As I've already said I'm not an expert in the IoT world. And I still think that the compression can also be used in a "big world". It would allow to keep the IKE_SA_INIT message size bounded when more features are added into the protocol. And I don't see it as an alternative to TCP encapsulation. As you wrote in the TCP encapsulation draft it has a number of issues (for example TCP in TCP) and thus it should be considered as a "last resort". Compression would make those occasions when TCP encapsulation is needed more rare, when it is _really_ needed (e.g. when UDP traffic is blocked). Sure compression cannot replace TCP encapsulation. And here some data from my experiments with compression of the IKEv2 messages using DEFLATE algorithm: 1. IKE_SA_INIT, single transform of each type: HDR, SA[48]{ P[44]{ Encryption=AES-CBC {KeyLen=128}, PRF=SHA1-HMAC, Integrity=SHA1-HMAC96, Group=MODP-1536}}, NONCE[36], KE[200](MODP-1536), N[28](NAT_DETECTION_SOURCE_IP), N[28](NAT_DETECTION_DESTINATION_IP), N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512}, N[8](REDIRECT_SUPPORTED), VID[26] In this case using compression results in roughly the same message size (you can save or loose a few bytes). 2. IKE_SA_INIT, multiple transforms of each type: HDR, SA[264]{ P[104]{ Encryption=AES-CBC {KeyLen=256}, AES-CBC {KeyLen=128}, PRF=SHA2.256-HMAC, SHA2.384-HMAC, SHA2.512-HMAC, Integrity=SHA2.256-HMAC128, SHA2.384-HMAC192, SHA2.512-HMAC256, Group=ECP-256, ECP-384, ECP-521}, P[84]{ Encryption=AES-CBC {KeyLen=128}, 3DES-CBC, PRF=SHA1-HMAC, SHA2.256-HMAC, Integrity=SHA1-HMAC96, SHA2.256-HMAC128, Group=MODP-1024, ECP-224, ECP-256}, P[72]{ Encryption=DES-CBC, PRF=SHA1-HMAC, MD5-HMAC, Integrity=SHA1-HMAC96, MD5-HMAC96, Group=MODP-1024, MODP-768, ECP-192}}, NONCE[36], KE[72](ECP-256), N[28](NAT_DETECTION_SOURCE_IP), N[28](NAT_DETECTION_DESTINATION_IP), N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[16](SIGNATURE_HASH_ALGORITHMS){SHA1, SHA2-256, SHA2-384, SHA2-512}, N[8](REDIRECT_SUPPORTED), VID[26] In this case using compressions results in saving of ~150 bytes out of initial ~530 bytes (~30%). 3. IKE_AUTH with certificate, single proposal of each type, simple traffic selectors: HDR, SK[1720]{ IDi[63](DN), CERT[1167](X.509 Cert), CERTREQ[45](X.509 Cert), IDr[38](DN), AUTH[150](Sig){sha1RSA[13]}, N[8](INITIAL_CONTACT), N[8](IKEV2_MESSAGE_ID_SYNC_SUPPORTED), N[12](SET_WINDOW_SIZE), CP[16](REQUEST), SA[44]{ P[40]{ Encryption=AES-CBC {KeyLen=128}, Integrity=SHA1-HMAC96, ESN=Off}}, TSi[40], TSr[40], N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO), N[28](QCD_TOKEN), N[8](TICKET_REQUEST)} In this case using compression results in saving ~350 bytes out of ~1750 (~20%). In this particular example the resulting message would become ~1400 bytes, that would avoid IP fragmentation in most cases (and thus avoid using IKE fragmentation). Using compression here would be more effective if more transforms are included in the SA payload, more attributes are requested in the CP payload or more complex traffic selectors are included. > Thanks, > Tommy Regards, Valery. From nobody Wed Jan 13 07:10:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91FB1B2E9B for ; Wed, 13 Jan 2016 07:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 m-0J6yeqXKfU for ; Wed, 13 Jan 2016 07:10:08 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 6BD571B2E90 for ; Wed, 13 Jan 2016 07:10:08 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id oh2so292848503lbb.3 for ; Wed, 13 Jan 2016 07:10:08 -0800 (PST) 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-type:content-transfer-encoding; bh=FomkSMTvhwA5Fk5HxonFpR4Vv9cvvEceVu9LpFpFhnw=; b=MjHE7fYAMxThjnYQxnCc/0k+2qL6DDBrZoiGRxhyt2O04LjoyewNFfD+jVn/7o4wL1 g1ZSHeIyoRhCQwnlHf2d9UmXrApwIxtkSxmHFBYHa47wRA+WOPWmOGYdNKfoP8TS2xtz oe9EBKmYI2C31GN1U1PQzV2stf97AVr4s8jBrvSR04WzdgCxqdRC27Ow3YNVxCLfU1FF rx/SUlI98rFHC2tD9PpqzXtJBHfc5PlTdHc7qwpYU4NeNCc7iortQP5KOC3oxR8d9Fci gKQRhY0xbcouxCdyz0euznrENAj9/eKqJGAZ/hH7sV/QjSgSRksuuHT/5VUblRgY+TCD IDpA== 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-type:content-transfer-encoding; bh=FomkSMTvhwA5Fk5HxonFpR4Vv9cvvEceVu9LpFpFhnw=; b=FgLLqX4QCg2Zpp84bJhjhzqh2p2IYivSuqkTzYsv/Lr1Rj/07Q30Ou9pnW1x641Lkt WSRP6HocYPRZfiQdCLWeN+B6h/9fKWDDK7Nkw+x+3wuLFkNpybEEviQViKxDC2SHGCeA TIdPK6KB2ReokHnSuCE9eLLfYmj98zYSoNuffolctBsvi4DpsR26g64EwMaTaQkd9IUI pOVkA/YT4+b/MErDfOFpM10732oWSDqu9eCKxqRMA+qpDxTO+vWvmXwevC9hNVtfOkYI RjglPZQplg1uKeiqkAAMss8/vi6J4VLjPmWAcxk8u+dlBeZjof30wLSGWWqyUrQ4OjF8 +i4w== X-Gm-Message-State: ALoCoQnOMCcdcfKCd/9jPXV6r7lO9GFAvc7c3FyEsvGIDBIoHtwB6s+NL9PM5WUGASHPa4y0cNXosKwW7W1dbCabo6KFRbIe4A== X-Received: by 10.112.168.194 with SMTP id zy2mr19156429lbb.120.1452697806751; Wed, 13 Jan 2016 07:10:06 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id jm8sm234310lbc.12.2016.01.13.07.10.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 07:10:05 -0800 (PST) Message-ID: <5BD1D4EC351E46239951C15D4E53EBCD@buildpc> From: "Valery Smyslov" To: "Tommy Pauly" , "Paul Wouters" References: <4B79FA45-405A-4829-A23F-58E1D8AE2092@apple.com> Date: Wed, 13 Jan 2016 18:10:08 +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 Subject: Re: [IPsec] meeting at IETF-95 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:10:09 -0000 Count me too. Regards, Valery. > +1 to having a meeting at IETF 95. > > Thanks, > Tommy > >> On Jan 12, 2016, at 6:56 AM, Paul Wouters wrote: >> >> >> I hope we are scheduling a meeting for IETF-95. Last time we did not >> meet and ended up meeting in the hallway. This time there are more >> drafts being suggested and worked on. >> >> Paul >> >> _______________________________________________ >> 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 Jan 13 07:21:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3C91B2EA1 for ; Wed, 13 Jan 2016 07:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 iKaeA9r5YjE2 for ; Wed, 13 Jan 2016 07:21:15 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708E71B2E9B for ; Wed, 13 Jan 2016 07:21:15 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pgXY52w5hz35Z; Wed, 13 Jan 2016 16:21:13 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 m7xAQDKkILUJ; Wed, 13 Jan 2016 16:21:12 +0100 (CET) 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, 13 Jan 2016 16:21:12 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BBA3A603AF0F; Wed, 13 Jan 2016 10:21:10 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca BBA3A603AF0F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B91043A340D; Wed, 13 Jan 2016 10:21:10 -0500 (EST) Date: Wed, 13 Jan 2016 10:21:10 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <766BDC320C824A3793FE8DD74566FC06@buildpc> Message-ID: References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <22163.54776.641819.67931@fireball.acr.fi> <4C042BBC-C27F-4B87-8EB5-56862B309A63@apple.com> <766BDC320C824A3793FE8DD74566FC06@buildpc> User-Agent: Alpine 2.20 (LFD 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] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:21:18 -0000 On Wed, 13 Jan 2016, Valery Smyslov wrote: > Well, I'm not an expert in IoT devices. And it's true that with minimal set > of transforms > and with reduced number of supported features the compression won't help much > in IKEv2. > However, I'm a bit afraid of oversimplifying the whole picture. It seems to > me that > there may be different kinds of constrained devices, and some of them would > be more advanced, then the most restricted ones. And I think that the IoT > world > won't be isolated, so that at least some of the IoT devices would have to > communicate > with the "big world" peers and thus would have to support more IKEv2 features > and extensions, > that would make their messages larger. And for those devices the compression > could be useful. This seems like a very unclear use case. More of a hypothetical use case. > The compression draft is not only about the IKE_SA_INIT messages. It also > allows the subsequent > messages to be compressed. While the IKE_AUTH is also one-time message, I can > imagine > that some restricted devices could use IKE SA to transmit application data > (it can appear to be easier > than to implement ESP). In this case the compression would be useful too. And that is a use case for something not even in the specification. > As I've already said I'm not an expert in the IoT world. And I still think > that the compression can > also be used in a "big world". It would allow to keep the IKE_SA_INIT message > size bounded > when more features are added into the protocol. And I don't see it as an > alternative to > TCP encapsulation. As you wrote in the TCP encapsulation draft it has a > number of issues > (for example TCP in TCP) and thus it should be considered as a "last resort". > Compression > would make those occasions when TCP encapsulation is needed more rare, > when it is _really_ needed (e.g. when UDP traffic is blocked). Sure > compression cannot > replace TCP encapsulation. I thought Tommy had data that showed that IKE fragmentation is not an issue. If UDP flows then IKE fragmentation works too. It is only when udp is blocked that TCP was needed. I'm still not really convinced this is much of a gain compared to the added complexity on the protocol. The only real use case I've heard so far is "less bytes is less battery", but still find it weak as the newly setup IPsec tunnel is going to get used and send more bytes. Paul From nobody Wed Jan 13 07:32:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D411A90DD for ; Wed, 13 Jan 2016 07:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 EMhuOzUyH56O for ; Wed, 13 Jan 2016 07:32:51 -0800 (PST) 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 5C71B1A90DC for ; Wed, 13 Jan 2016 07:32:51 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id b14so377837872wmb.1 for ; Wed, 13 Jan 2016 07:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s4G2Lby6NWSFg5IcC0Y0b3eP5s71qPeIWJQWdodT9x8=; b=PZP0BOsFA3Py7GIVFYqGxNbEgCYEcJ/ntXBm8M69c2O6ASQOgeM/CZTV3YpErJ+8n3 yKI3yPtb8GM2xJS9O1xBTsQxZHp93Kb0QtLFz1GiAWJyyQnMontx3w3a2fbiHgHG1dMU 0ELPLjkrHNOpm4Vn2cx2mVu9r5j5IKLXznYOJE94cZ03q0R2SglfpxqiyvyNBZ1Ogjb3 ShLO1dat1DC1Kk1S+nGs9boJOedX9+Wx5BCGJ3dSSH+grl0vkjIPanyRFZtLxBxBSE6E QAm5POj404eDUCV0HXRSMdT+miNAiJSa5SNJYwuzPnK5aAxj4AeOcX1VOSOUVAjziJAb 89Xg== 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:date :message-id:subject:from:to:cc:content-type; bh=s4G2Lby6NWSFg5IcC0Y0b3eP5s71qPeIWJQWdodT9x8=; b=dXv4frq3myVJwzZiYcgmGK6Bww2jUtYA/NliztdPAMhaaPoSEYKjVGRP8HzDdK0q/c BvUvSosgqA8G77nRGwlTllMhFfXQo9yuu1He+YGflyHfAbqm4zbrM+L1quPATrxeIiXh K5TZewHdRo9o5qOSGsVpLPzUO6kziAZgYwQ+nT2GMQPbKntXo0yfWBkGw8cd1v+L1Syu k2ufHgJQmV5a94fxZtves0AeYPjuLIBJooPM5kLskrAyDlM0XU7+WQKpc4J+BPBHpCFS 5rF8JlIjGzMN/4axfb20HGtRevpjUveLNmhvEq/8mK4XCDv+QjGCrJ1K12jXqtZBY3S/ Wtww== X-Gm-Message-State: ALoCoQlIbPvhh7IerIxJaKFqBagEbvvSrNIsujAYlLGb7PYegcxDOGBEbUTtuhtdKi/py4CVhMNEQOPcDdEisbAofwBVjn3I/Q== MIME-Version: 1.0 X-Received: by 10.28.133.141 with SMTP id h135mr25400264wmd.70.1452699169972; Wed, 13 Jan 2016 07:32:49 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.250.6 with HTTP; Wed, 13 Jan 2016 07:32:49 -0800 (PST) In-Reply-To: <5BD1D4EC351E46239951C15D4E53EBCD@buildpc> References: <4B79FA45-405A-4829-A23F-58E1D8AE2092@apple.com> <5BD1D4EC351E46239951C15D4E53EBCD@buildpc> Date: Wed, 13 Jan 2016 10:32:49 -0500 X-Google-Sender-Auth: r-Iu5oD7Jw53TtfLLbqAQxnlZa0 Message-ID: From: Daniel Migault To: Valery Smyslov Content-Type: multipart/alternative; boundary=001a11442334fde8f7052938e15a Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] meeting at IETF-95 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:32:53 -0000 --001a11442334fde8f7052938e15a Content-Type: text/plain; charset=UTF-8 +1 On Wed, Jan 13, 2016 at 10:10 AM, Valery Smyslov wrote: > Count me too. > > Regards, > Valery. > > > +1 to having a meeting at IETF 95. >> >> Thanks, >> Tommy >> >> On Jan 12, 2016, at 6:56 AM, Paul Wouters wrote: >>> >>> >>> I hope we are scheduling a meeting for IETF-95. Last time we did not >>> meet and ended up meeting in the hallway. This time there are more >>> drafts being suggested and worked on. >>> >>> Paul >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a11442334fde8f7052938e15a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Wed, Jan 13, 2016 at 10:10 AM, Valery Smyslov <svanru@gmail.= com> wrote:
Count me too.
Regards,
Valery.


+1 to having a meeting at IETF 95.

Thanks,
Tommy

On Jan 12, 2016, at 6:56 AM, Paul Wouters <paul@nohats.ca> wrote:


I hope we are scheduling a meeting for IETF-95. Last time we did not
meet and ended up meeting in the hallway. This time there are more
drafts being suggested and worked on.

Paul

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

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

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

--001a11442334fde8f7052938e15a-- From nobody Wed Jan 13 07:35:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1521A8FD4 for ; Wed, 13 Jan 2016 07:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 4spZ2A8A1TxC for ; Wed, 13 Jan 2016 07:35:12 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405A11A901F for ; Wed, 13 Jan 2016 07:35:12 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id bc4so291933160lbc.2 for ; Wed, 13 Jan 2016 07:35:12 -0800 (PST) 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-type:content-transfer-encoding; bh=xB0ZPVjRLk3+u2gjih/rgqeae9r0FSeakjAIpSdoZJw=; b=i0LW4hV9Ivu5Lx1vwil+Ua3zQu6ZCj0mLvIE7JCfxjZYTv6I67XjZtp1rKjJHuTfOZ 2QWnFh2pW9UyKh5+PrJrAF4Su0EuuPuWAyH6PMpW1ssXDxXE7QRAGVbvapuglKbW9DMA /NGyz51p0ABYorXrmssj/NPh+KubvqsQ+N4LBZrL0JIZLEVqP4OFhoENHivqii7uzwMv LweiCtLSkO7NwnN+SXzrdqEywWF5gOBcF/GUgjrBrCVA2PWZIznMw6znhwz3MnllhfaP agFMe0+bXiIg8yWD95bHr//zZTHiepnomicI1WqOwUfbVT8LCKGTrsNKowWGTxIWLJbE S62w== 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-type:content-transfer-encoding; bh=xB0ZPVjRLk3+u2gjih/rgqeae9r0FSeakjAIpSdoZJw=; b=TDRMvlQiBui55seVML4C+qViX6iwTV12p/Lb0a/2Fs0KeY3XL53fqdq4uTd+Gw2Byt Lhxl+4tqtP9CH8+t9pFn2CZe4BW0ETaLDlo+50NbGP2gqACN8ZchFlizXZw2UMg2kKNh 0EFNpAWZVitsrylyK+h1Q1KylK4BTHKJRYqALqVfqA5vnO1//yZEjbW7poheNcMQpOZ3 XKPCUObpEsQ3TdfRxNKTixhe5nOBHWlzrL/eKXyfGyUd/nNCRADUW4SYuK7mgM94xPni SIHmiN7sDEFEdyRnoDYXhLU40SrIbI00p7m4w4E+3nLg1LKP2lg8JlhPZnx3EgF8m2Q+ lt0g== X-Gm-Message-State: ALoCoQkZujBWXZM957I6AtmDbglHy6+31O9E4vctb5toEK12z4sxyylZKunugTXaasCaDRIWQo9qRXOSTbdvKV1xQgEQwTDeAw== X-Received: by 10.112.184.199 with SMTP id ew7mr14637749lbc.134.1452699310385; Wed, 13 Jan 2016 07:35:10 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id b74sm239617lfb.32.2016.01.13.07.35.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 07:35:09 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <22163.54776.641819.67931@fireball.acr.fi> <4C042BBC-C27F-4B87-8EB5-56862B309A63@apple.com> <766BDC320C824A3793FE8DD74566FC06@buildpc> Date: Wed, 13 Jan 2016 18:35:11 +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: IPsecME WG Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:35:13 -0000 >> As I've already said I'm not an expert in the IoT world. And I still think >> that the compression can >> also be used in a "big world". It would allow to keep the IKE_SA_INIT message >> size bounded >> when more features are added into the protocol. And I don't see it as an >> alternative to >> TCP encapsulation. As you wrote in the TCP encapsulation draft it has a >> number of issues >> (for example TCP in TCP) and thus it should be considered as a "last resort". >> Compression >> would make those occasions when TCP encapsulation is needed more rare, >> when it is _really_ needed (e.g. when UDP traffic is blocked). Sure >> compression cannot >> replace TCP encapsulation. > > I thought Tommy had data that showed that IKE fragmentation is not > an issue. If UDP flows then IKE fragmentation works too. It is only > when udp is blocked that TCP was needed. The IKE_SA_INIT message size is an issue here. If it is too long then IKE fragmentation won't help (it starts working from the IKE_AUTH). In this case if crippled NAT box is in between the peers would be unable to complete the IKE_SA_INIT exchange and would switch to TCP encapsulation. If the IKE_SA_INITmessage were smaller, they could have completed the IKE_SA_INIT and then would have communicated using UDP without suffering from TCP encapsulation issues. > I'm still not really convinced this is much of a gain compared to the > added complexity on the protocol. > > The only real use case I've heard so far is "less bytes is less > battery", but still find it weak as the newly setup IPsec tunnel > is going to get used and send more bytes. IPsec tunnels can use IPcomp too, as recommended for the low-power consumption devices. > Paul Regards, Valery. From nobody Wed Jan 13 07:48:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735B41B2EC9 for ; Wed, 13 Jan 2016 07:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 rUMnwCOUQXx2 for ; Wed, 13 Jan 2016 07:48:31 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BB41B2EC5 for ; Wed, 13 Jan 2016 07:48:31 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pgY8Y1m8Bz35Z; Wed, 13 Jan 2016 16:48:29 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 wFXPYUSQypCI; Wed, 13 Jan 2016 16:48:28 +0100 (CET) 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, 13 Jan 2016 16:48:28 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 40F9B603AF0F; Wed, 13 Jan 2016 10:48:27 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 40F9B603AF0F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3D2813A340D; Wed, 13 Jan 2016 10:48:27 -0500 (EST) Date: Wed, 13 Jan 2016 10:48:27 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> <22163.54776.641819.67931@fireball.acr.fi> <4C042BBC-C27F-4B87-8EB5-56862B309A63@apple.com> <766BDC320C824A3793FE8DD74566FC06@buildpc> User-Agent: Alpine 2.20 (LFD 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] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:48:32 -0000 On Wed, 13 Jan 2016, Valery Smyslov wrote: >> I thought Tommy had data that showed that IKE fragmentation is not >> an issue. If UDP flows then IKE fragmentation works too. It is only >> when udp is blocked that TCP was needed. > > The IKE_SA_INIT message size is an issue here. If it is too long > then IKE fragmentation won't help (it starts working from the IKE_AUTH). Ah right. That's a fair point. > IPsec tunnels can use IPcomp too, as recommended for the low-power > consumption devices. Did anyone actually meassure battery costs of this versus not using it? Is burning main CPU cheaper than burning a bit more in the transmission chip? Paul From nobody Wed Jan 13 08:59:10 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB801B2F47 for ; Wed, 13 Jan 2016 08:59:08 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MG-G9n-FD7w3 for ; Wed, 13 Jan 2016 08:59:07 -0800 (PST) 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 308F51B2F52 for ; Wed, 13 Jan 2016 08:59:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D46842002A for ; Wed, 13 Jan 2016 12:06:44 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C99B263751 for ; Wed, 13 Jan 2016 11:59:05 -0500 (EST) From: Michael Richardson To: "ipsec\@ietf.org" In-Reply-To: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:59:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Scott Fluhrer (sfluhrer) wrote: > - It defines the transform of the nonce from the on-the-wire version = into the > one presented to the IKEv2 KDF (mixing in the PPK). > - The initiator gives an indication of which PPK to use (without leak= ing any > information about it to someone two doesn=E2=80=99t know the value). > For the first use, it would be reasonable to have the initiator defin= e a > bitmask of the algorithms it supports, and the responder to select one That's not very algorithm agile, nor very IKEv2 happy. Don't we already have IANA values for all the algorithms involved? (shouldn't we have them) > This second use is rather trickier to have agility; it is sent before= the > initiator has any contact to the responder. I don=E2=80=99t see how t= he > responder can > indicate which algorithms it supports (without adding a round trip to= the > protocol). This is why I suggested... if you have to add a round trip anyway... might = as well solve a puzzle or something along the way. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVpaCVoCLcPvd0N1lAQJSUgf+OSzaR4/FZaOSLPwcZA+cjC2V7mHyCsSK s++09R7PiA+crg3QcfsTPDrxfCfrb913e5AWr/2m7Os7SIoI+Xqp5cFe4t78mgQq GLkapflYbHMNsGBt/S+xjsMdYsdw6sY9WNk2jH4dHr4FymTSmRgMaLrzgz8V0ML6 8Yeyvy7Pe05YssGNpRAp+YPQbsJM8+CcrtUyEAhfMUsSTbviCnf6enYMC+znXZjI 0vvQBZuoBsjLFTShgG8tIu+WYfa6TP6tcE1TgfDdKQCUimma39ukzG1K777vvhdu rVuQRLezt2s2E2f6Fn17X1orkkL/snmj62o9uHlMuX+Y+8hryDgiTg== =dZnY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 13 14:45:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031581A87D9 for ; Wed, 13 Jan 2016 14:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 L0jdb-wAbLEC for ; Wed, 13 Jan 2016 14:45:44 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5621A874B for ; Wed, 13 Jan 2016 14:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3946; q=dns/txt; s=iport; t=1452725144; x=1453934744; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ToHV50k5G/Wo7Kajgd+BQnwgjTiqoCijmXlvukE2SAI=; b=F7ApFQQIYIGo7wNRZ+GVtBqJFw6B00EWrRHLXBRMm4Y+eaujSpzay9Jk YwvTUBqfiul1YnZEFtyqDnooY5kRh1zJSquD+IqJyltsDP8CBnbLr+S2i MYPLEPA6IHXDUTrdX4AqGVae8+hgo9mj1rkShbpTJh+dwDKiCiCT5vDGZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACH0pZW/xbLJq1ehHkGiFSxDoQFh?= =?us-ascii?q?g8CHIFwAQEBAQEBgQuENAEBAQMBIxFRBAIBCBEEAQEBAgIjAwICAjAUAQgIAQE?= =?us-ascii?q?EARIIE4gLCK93kEIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgQGFVYR/hG2DB4FJA?= =?us-ascii?q?QSHZ48uAY1SjweOVQFkhApyhRSBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,291,1449532800"; d="scan'208";a="623472676" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 22:45:42 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0DMjfXu016189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 22:45:42 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.1104.5; Wed, 13 Jan 2016 17:45:40 -0500 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.1104.009; Wed, 13 Jan 2016 17:45:40 -0500 From: "Scott Fluhrer (sfluhrer)" To: Michael Richardson , "ipsec@ietf.org" Thread-Topic: [IPsec] NIST question concerning IKEv2 and quantum resistance Thread-Index: AdFIwXQqaqlOB64eRs6Nv1l1sgbGQAEOi2dAAAU5Ue0APu0GcAAQWNqAAAC/12A= Date: Wed, 13 Jan 2016 22:45:40 +0000 Message-ID: <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> In-Reply-To: <17915.1452704345@obiwan.sandelman.ca> 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.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 22:45:46 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQc2VjIFttYWlsdG86aXBz ZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gUmljaGFyZHNvbg0K PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTMsIDIwMTYgMTE6NTkgQU0NCj4gVG86IGlwc2Vj QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIE5JU1QgcXVlc3Rpb24gY29uY2Vybmlu ZyBJS0V2MiBhbmQgcXVhbnR1bSByZXNpc3RhbmNlDQo+IA0KPiANCj4gU2NvdHQgRmx1aHJlciAo c2ZsdWhyZXIpIDxzZmx1aHJlckBjaXNjby5jb20+IHdyb3RlOg0KPiAgICAgPiAtIEl0IGRlZmlu ZXMgdGhlIHRyYW5zZm9ybSBvZiB0aGUgbm9uY2UgZnJvbSB0aGUgb24tdGhlLXdpcmUgdmVyc2lv biBpbnRvDQo+IHRoZQ0KPiAgICAgPiBvbmUgcHJlc2VudGVkIHRvIHRoZSBJS0V2MiBLREYgKG1p eGluZyBpbiB0aGUgUFBLKS4NCj4gDQo+ICAgICA+IC0gVGhlIGluaXRpYXRvciBnaXZlcyBhbiBp bmRpY2F0aW9uIG9mIHdoaWNoIFBQSyB0byB1c2UgKHdpdGhvdXQgbGVha2luZyBhbnkNCj4gICAg ID4gaW5mb3JtYXRpb24gYWJvdXQgaXQgdG8gc29tZW9uZSB0d28gZG9lc27igJl0IGtub3cgdGhl IHZhbHVlKS4NCj4gDQo+ICAgICA+IEZvciB0aGUgZmlyc3QgdXNlLCBpdCB3b3VsZCBiZSByZWFz b25hYmxlIHRvIGhhdmUgdGhlIGluaXRpYXRvciBkZWZpbmUgYQ0KPiAgICAgPiBiaXRtYXNrIG9m IHRoZSBhbGdvcml0aG1zIGl0IHN1cHBvcnRzLCBhbmQgdGhlIHJlc3BvbmRlciB0byBzZWxlY3Qg b25lDQo+IA0KPiBUaGF0J3Mgbm90IHZlcnkgYWxnb3JpdGhtIGFnaWxlLCBub3IgdmVyeSBJS0V2 MiBoYXBweS4gRG9uJ3Qgd2UgYWxyZWFkeSBoYXZlDQo+IElBTkEgdmFsdWVzIGZvciBhbGwgdGhl IGFsZ29yaXRobXMgaW52b2x2ZWQ/IChzaG91bGRuJ3Qgd2UgaGF2ZSB0aGVtKQ0KDQpUaGUgJ2Jp dG1hc2sgaWRlYScgd2FzIG9mZiB0aGUgdG9wIG9mIG15IGhlYWQ7IHdlIGNvdWxkIGNlcnRhaW5s eSBnaXZlIGEgbGlzdCBvZiBJQU5BIHZhbHVlcyAoc3VjaCBhcyB0aGUgSUtFdjIgUFJGKS4gIE15 IGNoaWVmIGZlYXIgaXMgdGhhdCB3ZSBkb24ndCBvdmVyZW5naW5lZXIgdGhpczsgdGhpcyByZWFs bHkgaXMgYSAic2hvcnQgdGVybSBzb2x1dGlvbiIgKHdpdGggdGhlIHVzdWFsIGNhdmVhdCB0aGF0 IHRoZXJlIGFyZSBubyBzaG9ydCB0ZXJtIHNvbHV0aW9ucyksIGFuZCB0aGF0IGEgcG9zdC1xdWFu dHVtIERILWxpa2UgZnVuY3Rpb24gaXMgdGhlIFJpZ2h0IFRoaW5nIChvbmx5IHdlIGhhdmVuJ3Qg YWdyZWVkIG9uIHRoYXQgeWV0KS4gIFRoZSBpc3N1ZSB3aXRoIGhhdmluZyBhIGNvbXBsZXggbmVn b3RpYXRpb24gcHJvY2VzcyBpcyB0aGF0IG1heSBiZSBhIGxvdCBvZiByYXJlbHkgZXhlY3V0ZWQg Y29kZSwgYW5kIHRoYXQgaW4gaXRzZWxmIG1heSBsZWFkIHRvIHNlY3VyaXR5IHZ1bG5lcmFiaWxp dGllcy4NCg0KPiANCj4gICAgID4gVGhpcyBzZWNvbmQgdXNlIGlzIHJhdGhlciB0cmlja2llciB0 byBoYXZlIGFnaWxpdHk7IGl0IGlzIHNlbnQgYmVmb3JlIHRoZQ0KPiAgICAgPiBpbml0aWF0b3Ig aGFzIGFueSBjb250YWN0IHRvIHRoZSByZXNwb25kZXIuIEkgZG9u4oCZdCBzZWUgaG93IHRoZQ0K PiAgICAgPiByZXNwb25kZXIgY2FuDQo+ICAgICA+IGluZGljYXRlIHdoaWNoIGFsZ29yaXRobXMg aXQgc3VwcG9ydHMgKHdpdGhvdXQgYWRkaW5nIGEgcm91bmQgdHJpcCB0byB0aGUNCj4gICAgID4g cHJvdG9jb2wpLg0KPiANCj4gVGhpcyBpcyB3aHkgSSBzdWdnZXN0ZWQuLi4gaWYgeW91IGhhdmUg dG8gYWRkIGEgcm91bmQgdHJpcCBhbnl3YXkuLi4gbWlnaHQgYXMNCj4gd2VsbCBzb2x2ZSBhIHB1 enpsZSBvciBzb21ldGhpbmcgYWxvbmcgdGhlIHdheS4NCg0KT25lIG9mIHRoZSBjb25zdHJhaW50 cyB0aGF0IHdlIGZlbHQgd2UgaGFkIHRvIGxpdmUgd2l0aGluIHdhcyB0byBtaW5pbWl6ZSB0aGUg Y2hhbmdlcyB3ZSBtYWRlIHRvIElLRXYyLCBib3RoIGZyb20gYSBjcnlwdG8gc3RhbmRwb2ludCwg YW5kIGZyb20gYSBzdGF0ZSBtYWNoaW5lIHN0YW5kcG9pbnQuICBIZW5jZSwgd2UgZGVjaWRlZCB0 aGF0IGFkZGluZyB2ZW5kb3IgaWQgcGF5bG9hZHMgKG9yIG5vdGlmaWNhdGlvbiBwYXlsb2Fkcykg dG8gZXhpc3RpbmcgbWVzc2FnZXMgd2UgT0ssIGhvd2V2ZXIgYWRkaW5nIGFkZGl0aW9uYWwgcm91 bmQgdHJpcHMgd2FzIG91dCBvZiBib3VuZHMuDQoNCklmIG9uZSB3ZXJlIHRvIGFkZCBhZGRpdGlv bmFsIHJvdW5kIHRyaXBzLCBhIGNsZWFuZXIgc29sdXRpb24gd291bGQgYmUgdG8gbmVnb3RpYXRl IHRoZSBpbml0aWFsIElLRSBTQSBhcyBwZXIgdGhlIFJGQywgYW5kIHRoZW4gaWYgdGhlIHR3byBz aWRlcyBkZWNpZGUgdGhhdCB0aGV5IG5lZWQgUVIsIGNyZWF0ZSBhIGNoaWxkIFNBIChpbiBhIFBR UiBtYW5uZXIpLiAgVGhlIGN1cnJlbnQgYXBwcm9hY2ggaGFzIHRoZSBpc3N1ZSB0aGF0IHdlIG5l ZWQgdG8gc3RpciBpbiB0aGUgcG9zdC1xdWFudHVtIG1hZ2ljIGJlZm9yZSB0aGUgaWRlbnRpdGll cyB3ZXJlIGV4Y2hhbmdlZCAoYW5kIGhlbmNlIHRoZSBpbml0aWF0b3IgZ2l2ZXMgdGhlIGluZGlj YXRpb24gb2YgdGhlIHBwaykuIElmIHlvdSBlc3RhYmxpc2ggYSBzZWN1cmUgY29ubmVjdGlvbiAo YW5kIGV4Y2hhbmdlIGlkZW50aXRpZXMpIGZpcnN0LCB0aGVuIGl0IGJlY29tZXMgbXVjaCBjbGVh bmVyIChhcyBib3RoIHNpZGVzIHdvdWxkIGtub3cgd2hvIHRoZXkgYXJlIHRhbGtpbmcgdG8sIGFu ZCB3aGljaCBwcGsgdGhleSBzaG91bGQgdXNlKS4gIEhvd2V2ZXIsIHRoYXQgd2FzIGRlZW1lZCB0 byBiZSB0b28gbGFyZ2Ugb2YgYW4gZGVsdGEuDQoNCg0K From nobody Wed Jan 13 14:52:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA5C1A87E1 for ; Wed, 13 Jan 2016 14:51:59 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 KstFUyZ_kKyj for ; Wed, 13 Jan 2016 14:51:57 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0311A1F70 for ; Wed, 13 Jan 2016 14:51:57 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id f206so315317882wmf.0 for ; Wed, 13 Jan 2016 14:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=1oEuu/AbAOEzJozEmZpJhoNUtJhIm1BW0tMpBiQ/JLA=; b=TtrwPHZ8dzp1UcBt/RkjPDtOrw8X7FErd2jg2MLvWm4Unyxcrx1M+zGv95J6bHAcWt NWvak5AJxjgEAozIem8BsgHv0HNUnkzINCGm26NwD6zj42FeBSbIDzJtmEJdPDXdeEml LOha+W4vr9EMAh8js7bDlxEnoIZFqmPT0XP+CV0X2BF53uY/IbHIZmtCWZWW7H+JXc/z LO/Oai7xPXF+trzOtasUNkS9BH1hjKaP0gIBUYmqB4aILu5odUTEMd21m6zFy5ym07pS BIqWKuaEGhjkgR68W3yDVojS4STVNJpeKeHTOGCi7y+UhFwP6ih71QNMMTFci2pIzAfx fBDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=1oEuu/AbAOEzJozEmZpJhoNUtJhIm1BW0tMpBiQ/JLA=; b=RiFTjeIfmSBVttnSJJlFjW9GSwv5azT2wNJ3tE8JIL2JlII3qIZ8Z4mXalNiETd1zU CG+cqSW7PiSYt59gpFhxtdZMhNp2JVI/nfuECgFN1cRh/zOZivQ5v/EayU8ZGMGEbvHf Ir3QdSWvavbmtT8+cC4ECnhnlN+/mPN5gColml/FTDZgzRrlwWm74Jb3sH5tXBbkaP8H H93mJss8TQnjvgiq18ZMHuLf+kLlzpab5BQZokiN8HGpFzcG1Z/ecIKZ1UfUwELYMdLy puer9vKOpXzKSB9N+1fmSpAzgyujSbPE/CwZsPn0gDd+StyCzGuJlqANwrRexY7cX+x3 oFCA== X-Gm-Message-State: ALoCoQk/+2XIPTgstMBxYbrP/FDMJyoClxV340GzTU8G5xYx8FZnnaTcr4Mi87R361IMT40jks0ce4pHjeUTRBo0bXKZ6NpEyw== X-Received: by 10.28.21.6 with SMTP id 6mr1440903wmv.46.1452725515963; Wed, 13 Jan 2016 14:51:55 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id r4sm3357604wjy.39.2016.01.13.14.51.54 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jan 2016 14:51:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Thu, 14 Jan 2016 00:51:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E030992-5975-4A02-83B8-695DFFF57C29@gmail.com> References: To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [IPsec] meeting at IETF-95 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 22:51:59 -0000 I believe around that time CFRG and TLS will be done with the signatures = document and rfc4492bis respectively, so we could proceed and finish = draft-ietf-ipsecme-safecurves. So count me as a +1 as well. > On 12 Jan 2016, at 4:56 PM, Paul Wouters wrote: >=20 >=20 > I hope we are scheduling a meeting for IETF-95. Last time we did not > meet and ended up meeting in the hallway. This time there are more > drafts being suggested and worked on. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jan 14 04:57:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3D1B3456 for ; Thu, 14 Jan 2016 04:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 0Lc7sCKeUJYC for ; Thu, 14 Jan 2016 04:57:44 -0800 (PST) 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 7F5EA1B3455 for ; Thu, 14 Jan 2016 04:57:44 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id l65so341703152wmf.1 for ; Thu, 14 Jan 2016 04:57:44 -0800 (PST) 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-type:content-transfer-encoding; bh=RZR4VLw/4pKQs0s0paRYFKLKJqh00aaMPKj/mqjwESo=; b=Y+ca/TWSb7R1PhgQ7AErHlJZ4nG8ziknRENaRhQ3pKNzyh40D96qi0zajWP5dU2FKe u1lkheyL07lEn5fInM1jv3yUMEknpcTGYwEJwDFw4+uQkdfrmjFOtftSlC64yF8ct7OM UlD0Jp/7cXvCIp9SPrvTOcfOKWzviGNUB7H+SUWe2KVnE83pk3Ifxy4LDNMkvmWoqnAR wGCCRZabiJE4qC8/XrBP01Uj0+VZaGOVcN4M0joEStZ+nK9q+vZOyhGDEPrnTjqv0cKr muxguPS6x3V5Z+idomkYriqkTyPFQdWdPnyHyM9B+sZQardLKprwuCD31MgOBl47s70C OsAw== 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-type:content-transfer-encoding; bh=RZR4VLw/4pKQs0s0paRYFKLKJqh00aaMPKj/mqjwESo=; b=WlqfBWNuKuAQV1Vxr71ZR+4Z2yeNmaNbu7eFTUBjylBaku96T7EvaRc7MFD41iF4Qf qmx7289FqeTV37XPEYOfH4gsVQ+OdprluOLoNRBVHRFFIlSviJB67osai26Jyu2kOhR7 taTsRDGxy+2SeTY7pHVIi+TtYNwqX+U81hnqMmn+SM0P9Ig0QtkF9+YQZJ8v1UMW60hm CY5dew82UIqdTor52WCe4+BfXKY1nKke9z0Yv42Tctrf6V6g7zp5ecQtBCVj7Fadfdfa wUs0S/iuPg6FgNuNbc3lZREnxYkwPHWYqUiQYCEGA6gmuNHnigk9MZRUhCPsvwy32hSK 3e9w== X-Gm-Message-State: ALoCoQl0YYDR7hsT2emm1Nw4dk13jtelXxJfM+5X9d29RHYG0JMGNxls5KgbfHWbW41GwOHv6vy34J4CTbSs3JjPAIbu3ZWgkg== X-Received: by 10.112.64.42 with SMTP id l10mr1047554lbs.137.1452776262971; Thu, 14 Jan 2016 04:57:42 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o66sm746770lfi.36.2016.01.14.04.57.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jan 2016 04:57:42 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , "Michael Richardson" , References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> Date: Thu, 14 Jan 2016 15:57:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit 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] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 12:57:46 -0000 Hi Scott, >> Scott Fluhrer (sfluhrer) wrote: >> > - It defines the transform of the nonce from the on-the-wire version into >> the >> > one presented to the IKEv2 KDF (mixing in the PPK). >> >> > - The initiator gives an indication of which PPK to use (without leaking any >> > information about it to someone two doesn’t know the value). >> >> > For the first use, it would be reasonable to have the initiator define a >> > bitmask of the algorithms it supports, and the responder to select one >> >> That's not very algorithm agile, nor very IKEv2 happy. Don't we already have >> IANA values for all the algorithms involved? (shouldn't we have them) > > The 'bitmask idea' was off the top of my head; we could certainly give a list of > IANA values (such as the IKEv2 PRF). My chief fear is that we don't overengineer > this; this really is a "short term solution" (with the usual caveat that there are no > short term solutions), and that a post-quantum DH-like function is the Right Thing > (only we haven't agreed on that yet). The issue with having a complex negotiation > process is that may be a lot of rarely executed code, and that in itself may lead > to security vulnerabilities. Is it possible to use the already negotiated IKEv2 prf inside the modified crypto formulas? In this case they would look like: SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir) (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr) and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't it? In this case no additional negotiation is required since prf is negotiated in IKEv2 anyway and thus we would have algorithm agility in KDF for free. >> > This second use is rather trickier to have agility; it is sent before the >> > initiator has any contact to the responder. I don’t see how the >> > responder can >> > indicate which algorithms it supports (without adding a round trip to the >> > protocol). >> >> This is why I suggested... if you have to add a round trip anyway... might as >> well solve a puzzle or something along the way. > > One of the constraints that we felt we had to live within was to minimize > the changes we made to IKEv2, both from a crypto standpoint, and from > a state machine standpoint. Hence, we decided that adding vendor > id payloads (or notification payloads) to existing messages we OK, > however adding additional round trips was out of bounds. Note, that IKEv2 state machine has already accomodated the possibility of an additional round trip in case the initiator has incorrectly guessed the DH group. Introducing one more condition for additional round trip should not be too hard, however I agree that it adds some complexity and thus may be considered inappropriate for a short-term solution. However, if no better solution exists I'd prefer to live with a single fixed crypto primitive, than with two. Is it possible to get rid of AES and to change the indication of the ppk to use to something like the following? HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes) (disclaimer: I'm not a cryptographer) > If one were to add additional round trips, a cleaner solution would be > to negotiate the initial IKE SA as per the RFC, and then if the two sides > decide that they need QR, create a child SA (in a PQR manner). > The current approach has the issue that we need to stir in the post-quantum > magic before the identities were exchanged (and hence the initiator gives > the indication of the ppk). If you establish a secure connection (and exchange > identities) first, then it becomes much cleaner (as both sides would know who > they are talking to, and which ppk they should use). However, that was > deemed to be too large of an delta. I'm not sure this approach is easier than approch with additional round trip. I understand that it has some advantages (e.g. no need for linear key search), but from state machine point of view it may appear to be more complex. Regards, Valery. From nobody Thu Jan 14 07:02:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A254F1B3541 for ; Thu, 14 Jan 2016 07:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZMssvnqtSYMI for ; Thu, 14 Jan 2016 07:02:22 -0800 (PST) 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 5DF7D1B3546 for ; Thu, 14 Jan 2016 07:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8470; q=dns/txt; s=iport; t=1452783742; x=1453993342; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PX2Bs/lDZDAMlew9alb7cdPRtVhg57dAJl+cHatxer4=; b=bNXASgHeFf2O7WyghMLlQgUtnjhIyGUGwFG6TljJLv/+81XsJjoCkjRi LibhvN23uHC/E4sAm/zWBLjDXFHhiP7tzrtU2PYrSLBYAckJPTjT+FA+n bCXJhFQxNwMRAmdbDZ0/M74aCUq6CdCtFYpD0cv3Ht82kjOpmuXEkr6dx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgCGt5dW/5xdJa1VCYM6Um0GiFWzF?= =?us-ascii?q?gENgWQYCoVtAhyBGjgUAQEBAQEBAYEKhDQBAQEDAQEBASAROhcEAgEIDgMEAQE?= =?us-ascii?q?BAgIjAwICAiULFAEICAIEARIIE4gLCA6vfZA9AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFASBAYVVhH+ELYNHgUkFh2iPLgGNU4FljSOKZoNyASABAUKCERyBXXKFKYE?= =?us-ascii?q?IAQEB?= X-IronPort-AV: E=Sophos;i="5.22,294,1449532800"; d="scan'208";a="67147914" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2016 15:02:21 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u0EF2KiD022862 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jan 2016 15:02:21 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Jan 2016 10:02:20 -0500 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.1104.009; Thu, 14 Jan 2016 10:02:20 -0500 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , Michael Richardson , "ipsec@ietf.org" Thread-Topic: [IPsec] NIST question concerning IKEv2 and quantum resistance Thread-Index: AdFIwXQqaqlOB64eRs6Nv1l1sgbGQAEOi2dAAAU5Ue0APu0GcAAQWNqAAAC/12AAHqRekwADsQxA Date: Thu, 14 Jan 2016 15:02:19 +0000 Message-ID: <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:02:26 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQc2VjIFttYWlsdG86aXBz ZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZhbGVyeSBTbXlzbG92DQo+IFNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDE0LCAyMDE2IDc6NTggQU0NCj4gVG86IFNjb3R0IEZsdWhyZXIg KHNmbHVocmVyKTsgTWljaGFlbCBSaWNoYXJkc29uOyBpcHNlY0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW0lQc2VjXSBOSVNUIHF1ZXN0aW9uIGNvbmNlcm5pbmcgSUtFdjIgYW5kIHF1YW50dW0g cmVzaXN0YW5jZQ0KPiANCj4gSGkgU2NvdHQsDQo+IA0KPiA+PiBTY290dCBGbHVocmVyIChzZmx1 aHJlcikgPHNmbHVocmVyQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ICAgICA+IC0gSXQgZGVmaW5l cyB0aGUgdHJhbnNmb3JtIG9mIHRoZSBub25jZSBmcm9tIHRoZSBvbi10aGUtd2lyZQ0KPiA+PiB2 ZXJzaW9uIGludG8gdGhlDQo+ID4+ICAgICA+IG9uZSBwcmVzZW50ZWQgdG8gdGhlIElLRXYyIEtE RiAobWl4aW5nIGluIHRoZSBQUEspLg0KPiA+Pg0KPiA+PiAgICAgPiAtIFRoZSBpbml0aWF0b3Ig Z2l2ZXMgYW4gaW5kaWNhdGlvbiBvZiB3aGljaCBQUEsgdG8gdXNlICh3aXRob3V0IGxlYWtpbmcN Cj4gYW55DQo+ID4+ICAgICA+IGluZm9ybWF0aW9uIGFib3V0IGl0IHRvIHNvbWVvbmUgdHdvIGRv ZXNu4oCZdCBrbm93IHRoZSB2YWx1ZSkuDQo+ID4+DQo+ID4+ICAgICA+IEZvciB0aGUgZmlyc3Qg dXNlLCBpdCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIGhhdmUgdGhlIGluaXRpYXRvciBkZWZpbmUg YQ0KPiA+PiAgICAgPiBiaXRtYXNrIG9mIHRoZSBhbGdvcml0aG1zIGl0IHN1cHBvcnRzLCBhbmQg dGhlIHJlc3BvbmRlciB0bw0KPiA+PiBzZWxlY3Qgb25lDQo+ID4+DQo+ID4+IFRoYXQncyBub3Qg dmVyeSBhbGdvcml0aG0gYWdpbGUsIG5vciB2ZXJ5IElLRXYyIGhhcHB5LiBEb24ndCB3ZQ0KPiA+ PiBhbHJlYWR5IGhhdmUgSUFOQSB2YWx1ZXMgZm9yIGFsbCB0aGUgYWxnb3JpdGhtcyBpbnZvbHZl ZD8gKHNob3VsZG4ndA0KPiA+PiB3ZSBoYXZlIHRoZW0pDQo+ID4NCj4gPiBUaGUgJ2JpdG1hc2sg aWRlYScgd2FzIG9mZiB0aGUgdG9wIG9mIG15IGhlYWQ7IHdlIGNvdWxkIGNlcnRhaW5seSBnaXZl DQo+ID4gYSBsaXN0IG9mIElBTkEgdmFsdWVzIChzdWNoIGFzIHRoZSBJS0V2MiBQUkYpLiAgTXkg Y2hpZWYgZmVhciBpcyB0aGF0DQo+ID4gd2UgZG9uJ3Qgb3ZlcmVuZ2luZWVyIHRoaXM7IHRoaXMg cmVhbGx5IGlzIGEgInNob3J0IHRlcm0gc29sdXRpb24iDQo+ID4gKHdpdGggdGhlIHVzdWFsIGNh dmVhdCB0aGF0IHRoZXJlIGFyZSBubyBzaG9ydCB0ZXJtIHNvbHV0aW9ucyksIGFuZA0KPiA+IHRo YXQgYSBwb3N0LXF1YW50dW0gREgtbGlrZSBmdW5jdGlvbiBpcyB0aGUgUmlnaHQgVGhpbmcgKG9u bHkgd2UNCj4gPiBoYXZlbid0IGFncmVlZCBvbiB0aGF0IHlldCkuICBUaGUgaXNzdWUgd2l0aCBo YXZpbmcgYSBjb21wbGV4DQo+ID4gbmVnb3RpYXRpb24gcHJvY2VzcyBpcyB0aGF0IG1heSBiZSBh IGxvdCBvZiByYXJlbHkgZXhlY3V0ZWQgY29kZSwgYW5kIHRoYXQgaW4NCj4gaXRzZWxmIG1heSBs ZWFkIHRvIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcy4NCj4gDQo+IElzIGl0IHBvc3NpYmxlIHRv IHVzZSB0aGUgYWxyZWFkeSBuZWdvdGlhdGVkIElLRXYyIHByZiBpbnNpZGUgdGhlIG1vZGlmaWVk DQo+IGNyeXB0byBmb3JtdWxhcz8NCj4gSW4gdGhpcyBjYXNlIHRoZXkgd291bGQgbG9vayBsaWtl Og0KPiANCj4gICAgIFNLRVlTRUVEID0gcHJmKHByZihwcGssIE5pKSB8IHByZihwcGssIE5yKSwg Z15pcikNCj4gICAgIChTS19kIHwgU0tfYWkgfCBTS19hciB8IFNLX2VpIHwgU0tfZXIgfCBTS19w aSB8IFNLX3ByKSA9DQo+ICAgICAgICAgICBwcmYrKFNLRVlTRUVELCBwcmYocHBrLCBOaSkgfCBw cmYocHBrLCBOcikgfCBTUElpIHwgU1BJcikNCj4gDQo+IGFuZCBzbyBvbi4gSSdtIG5vdCBhIGNy eXB0b2dyYXBoZXIsIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgaXMgc2FmZSwgaXNuJ3QN Cj4gaXQ/DQo+IEluIHRoaXMgY2FzZSBubyBhZGRpdGlvbmFsIG5lZ290aWF0aW9uIGlzIHJlcXVp cmVkIHNpbmNlIHByZiBpcyBuZWdvdGlhdGVkIGluDQo+IElLRXYyIGFueXdheSBhbmQgdGh1cyB3 ZSB3b3VsZCBoYXZlIGFsZ29yaXRobSBhZ2lsaXR5IGluIEtERiBmb3IgZnJlZS4NCg0KSSBsaWtl IHRoaXMgLS0gSSdtIHN0ZWFsaW5nIHRoaXMgaWRlYS4NCg0KPiANCj4gPj4gICAgID4gVGhpcyBz ZWNvbmQgdXNlIGlzIHJhdGhlciB0cmlja2llciB0byBoYXZlIGFnaWxpdHk7IGl0IGlzIHNlbnQg YmVmb3JlIHRoZQ0KPiA+PiAgICAgPiBpbml0aWF0b3IgaGFzIGFueSBjb250YWN0IHRvIHRoZSBy ZXNwb25kZXIuIEkgZG9u4oCZdCBzZWUgaG93IHRoZQ0KPiA+PiAgICAgPiByZXNwb25kZXIgY2Fu DQo+ID4+ICAgICA+IGluZGljYXRlIHdoaWNoIGFsZ29yaXRobXMgaXQgc3VwcG9ydHMgKHdpdGhv dXQgYWRkaW5nIGEgcm91bmQgdHJpcCB0bw0KPiB0aGUNCj4gPj4gICAgID4gcHJvdG9jb2wpLg0K PiA+Pg0KPiA+PiBUaGlzIGlzIHdoeSBJIHN1Z2dlc3RlZC4uLiBpZiB5b3UgaGF2ZSB0byBhZGQg YSByb3VuZCB0cmlwIGFueXdheS4uLg0KPiA+PiBtaWdodCBhcyB3ZWxsIHNvbHZlIGEgcHV6emxl IG9yIHNvbWV0aGluZyBhbG9uZyB0aGUgd2F5Lg0KPiA+DQo+ID4gT25lIG9mIHRoZSBjb25zdHJh aW50cyB0aGF0IHdlIGZlbHQgd2UgaGFkIHRvIGxpdmUgd2l0aGluIHdhcyB0bw0KPiA+IG1pbmlt aXplIHRoZSBjaGFuZ2VzIHdlIG1hZGUgdG8gSUtFdjIsIGJvdGggZnJvbSBhIGNyeXB0byBzdGFu ZHBvaW50LA0KPiA+IGFuZCBmcm9tIGEgc3RhdGUgbWFjaGluZSBzdGFuZHBvaW50LiAgSGVuY2Us IHdlIGRlY2lkZWQgdGhhdCBhZGRpbmcNCj4gPiB2ZW5kb3IgaWQgcGF5bG9hZHMgKG9yIG5vdGlm aWNhdGlvbiBwYXlsb2FkcykgdG8gZXhpc3RpbmcgbWVzc2FnZXMgd2UNCj4gPiBPSywgaG93ZXZl ciBhZGRpbmcgYWRkaXRpb25hbCByb3VuZCB0cmlwcyB3YXMgb3V0IG9mIGJvdW5kcy4NCj4gDQo+ IE5vdGUsIHRoYXQgSUtFdjIgc3RhdGUgbWFjaGluZSBoYXMgYWxyZWFkeSBhY2NvbW9kYXRlZCB0 aGUgcG9zc2liaWxpdHkgb2YgYW4NCj4gYWRkaXRpb25hbCByb3VuZCB0cmlwIGluIGNhc2UgdGhl IGluaXRpYXRvciBoYXMgaW5jb3JyZWN0bHkgZ3Vlc3NlZCB0aGUgREgNCj4gZ3JvdXAuIEludHJv ZHVjaW5nIG9uZSBtb3JlIGNvbmRpdGlvbiBmb3IgYWRkaXRpb25hbCByb3VuZCB0cmlwIHNob3Vs ZCBub3QNCj4gYmUgdG9vIGhhcmQsIGhvd2V2ZXIgSSBhZ3JlZSB0aGF0IGl0IGFkZHMgc29tZSBj b21wbGV4aXR5IGFuZCB0aHVzIG1heSBiZQ0KPiBjb25zaWRlcmVkIGluYXBwcm9wcmlhdGUgZm9y IGEgc2hvcnQtdGVybSBzb2x1dGlvbi4NCj4gDQo+IEhvd2V2ZXIsIGlmIG5vIGJldHRlciBzb2x1 dGlvbiBleGlzdHMgSSdkIHByZWZlciB0byBsaXZlIHdpdGggYSBzaW5nbGUgZml4ZWQNCj4gY3J5 cHRvIHByaW1pdGl2ZSwgdGhhbiB3aXRoIHR3by4gSXMgaXQgcG9zc2libGUgdG8gZ2V0IHJpZCBv ZiBBRVMgYW5kIHRvIGNoYW5nZQ0KPiB0aGUgaW5kaWNhdGlvbiBvZiB0aGUgcHBrIHRvIHVzZSB0 byBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nPw0KPiANCj4gSE1BQ19TSEEyNTYoSE1BQ19T SEEyNTYocHBrLCAiQSIpLCByYW5kb21fYnl0ZXMpDQo+IA0KPiAoZGlzY2xhaW1lcjogSSdtIG5v dCBhIGNyeXB0b2dyYXBoZXIpDQoNCllvdXIgcHJvcG9zYWwgaXMgcGVyZmVjdGx5IHNvdW5kIGZy b20gYSBjcnlwdG9ncmFwaHkgcGVyc3BlY3RpdmUuICBBY3R1YWxseSwgdGhlIHJlYXNvbiB3ZSBw cm9wb3NlZCB0aGUgImVudHJ5IGluIHRoZSBBRVMgY29kZWJvb2siIGFwcHJvYWNoLCByYXRoZXIg dGhhbiBzb21ldGhpbmcgbGlrZSB0aGUgYWJvdmUgc3RydWN0dXJlLCBpcyBkdWUgdG8gcHJhY3Rp Y2FsIHJlYXNvbnMuICBXaGVuIHRoZSByZXNwb25kZXIgcmVjZWl2ZXMgdGhlIGhpbnQsIGhlIGhh cyBubyBpZGVhIHdoaWNoIHBwayB0aGUgaW5pdGlhdG9yIGlzIHJlZmVycmluZyB0byAoYW5kIGhl IGRvZXNuJ3Qga25vdyB0aGUgaWRlbnRpdHkgeWV0KTsgb3VyIG1vZGVsIGlzIHRoYXQgdGhlIHJl c3BvbmRlciBoYXMgYSBsaXN0IG9mIHBwaydzIHRoYXQgaGUga25vd3MgYWJvdXQsIGFuZCBjaGVj a3MgdG8gc2VlIGlmIHRoZSBvbmUgdGhhdCB0aGUgaW5pdGlhdG9yIGhhZCBpcyBvbiB0aGUgbGlz dC4gIEl0J2QgYmUgbmljZSBpZiB0aGVyZSB3YXMgYSB3YXkgZm9yIHRoZSByZXNwb25kZXIgdG8g c2VhcmNoIHRocm91Z2ggaGlzIGRhdGFiYXNlcyBvZiBrbm93biBwcGsncyBxdWlja2x5LCBob3dl dmVyIEkgZG9uJ3Qga25vdyBob3cgdG8gbGV0IGhpbSBkbyBpdCBpbiBzdWJsaW5lYXIgdGltZSAo d2l0aG91dCBsZWFraW5nIHdoZXRoZXIgdHdvIGV4Y2hhbmdlcyB1c2VkIHRoZSBzYW1lIHBwaywg d2hpY2ggd291bGQgbGVhayBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaWRlbnRpdGllcykuICBTbywg d2hhdCB3ZSBzZXR0bGVkIG9uIGlzIHRvIG1ha2UgdGhlIGxpbmVhciBzY2FuIGZvciB0aGUgcmln aHQgUFBLIGFzIGZhc3QgYXMgcG9zc2libGUuICBXaXRoIG91ciBwcm9wb3NlZCBzb2x1dGlvbiwg YW4gYWdncmVzc2l2ZSByZXNwb25kZXIgY291bGQgaGF2ZSBhbGwgdGhlIEFFUyBrZXlzIGNvcnJl c3BvbmRpbmcgdG8gdGhlIHBwayBwcmVleHBhbmRlZCwgYW5kIGp1c3QgY2hlY2sgZWFjaCBwb3Rl bnRpYWwgcHBrIGJ5IGRvaW5nIG9uZSBBRVMgYmxvY2sgZW5jcnlwdGlvbiAob3IgZGVjcnlwdGlv biwgaWYgdGhleSBwcmVmZXIpOyBpZiB0aGUgaW1wbGVtZW50YXRpb24gaGFzIEFFUy1OSSwgdGhh dCBpcyBmYWlybHkgZmFzdC4gIFdpdGggeW91ciBwcm9wb3NhbCwgdGhleSBjb3VsZCBwcmVleHBh bmQgdGhlIEhNQUMga2V5cywgYnV0IHdvdWxkIHN0aWxsIG5lZWQgdG8gZG8gdHdvIFNIQTI1NiBj b21wcmVzc2lvbiBmdW5jdGlvbiBldmFsdWF0aW9ucy4NCg0KPiANCj4gPiBJZiBvbmUgd2VyZSB0 byBhZGQgYWRkaXRpb25hbCByb3VuZCB0cmlwcywgYSBjbGVhbmVyIHNvbHV0aW9uIHdvdWxkIGJl DQo+ID4gdG8gbmVnb3RpYXRlIHRoZSBpbml0aWFsIElLRSBTQSBhcyBwZXIgdGhlIFJGQywgYW5k IHRoZW4gaWYgdGhlIHR3bw0KPiA+IHNpZGVzIGRlY2lkZSB0aGF0IHRoZXkgbmVlZCBRUiwgY3Jl YXRlIGEgY2hpbGQgU0EgKGluIGEgUFFSIG1hbm5lcikuDQo+ID4gVGhlIGN1cnJlbnQgYXBwcm9h Y2ggaGFzIHRoZSBpc3N1ZSB0aGF0IHdlIG5lZWQgdG8gc3RpciBpbiB0aGUNCj4gPiBwb3N0LXF1 YW50dW0gbWFnaWMgYmVmb3JlIHRoZSBpZGVudGl0aWVzIHdlcmUgZXhjaGFuZ2VkIChhbmQgaGVu Y2UgdGhlDQo+ID4gaW5pdGlhdG9yIGdpdmVzIHRoZSBpbmRpY2F0aW9uIG9mIHRoZSBwcGspLiBJ ZiB5b3UgZXN0YWJsaXNoIGEgc2VjdXJlDQo+ID4gY29ubmVjdGlvbiAoYW5kIGV4Y2hhbmdlDQo+ ID4gaWRlbnRpdGllcykgZmlyc3QsIHRoZW4gaXQgYmVjb21lcyBtdWNoIGNsZWFuZXIgKGFzIGJv dGggc2lkZXMgd291bGQNCj4gPiBrbm93IHdobyB0aGV5IGFyZSB0YWxraW5nIHRvLCBhbmQgd2hp Y2ggcHBrIHRoZXkgc2hvdWxkIHVzZSkuDQo+ID4gSG93ZXZlciwgdGhhdCB3YXMgZGVlbWVkIHRv IGJlIHRvbyBsYXJnZSBvZiBhbiBkZWx0YS4NCj4gDQo+IEknbSBub3Qgc3VyZSB0aGlzIGFwcHJv YWNoIGlzIGVhc2llciB0aGFuIGFwcHJvY2ggd2l0aCBhZGRpdGlvbmFsIHJvdW5kIHRyaXAuDQo+ IEkgdW5kZXJzdGFuZCB0aGF0IGl0IGhhcyBzb21lIGFkdmFudGFnZXMgKGUuZy4gbm8gbmVlZCBm b3IgbGluZWFyIGtleQ0KPiBzZWFyY2gpLCBidXQgZnJvbSBzdGF0ZSBtYWNoaW5lIHBvaW50IG9m IHZpZXcgaXQgbWF5IGFwcGVhciB0byBiZSBtb3JlDQo+IGNvbXBsZXguDQoNCkl0IHdvdWxkIGdl dCByaWQgb2YgdGhlIGxpbmVhciBzY2FuIGlzc3VlLg0KDQo+IA0KPiBSZWdhcmRzLA0KPiBWYWxl cnkuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gSVBzZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K From nobody Thu Jan 14 08:28:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354411A1A6F for ; Thu, 14 Jan 2016 08:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 v7wDLY-oZHrc for ; Thu, 14 Jan 2016 08:28:04 -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 22D7D1A1A6E for ; Thu, 14 Jan 2016 08:28:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ph9zj5CJkz3KJ; Thu, 14 Jan 2016 17:28:01 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 1fOM-c_sMkzO; Thu, 14 Jan 2016 17:28:01 +0100 (CET) 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, 14 Jan 2016 17:28:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 146B8614AEAC; Thu, 14 Jan 2016 11:28:00 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 146B8614AEAC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 112D01302; Thu, 14 Jan 2016 11:28:00 -0500 (EST) Date: Thu, 14 Jan 2016 11:28:00 -0500 (EST) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" In-Reply-To: <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> Message-ID: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20 (LFD 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] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 16:28:05 -0000 On Thu, 14 Jan 2016, Scott Fluhrer (sfluhrer) wrote: >> Is it possible to use the already negotiated IKEv2 prf inside the modified >> crypto formulas? >> In this case they would look like: >> >> SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir) >> (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = >> prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr) >> >> and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't >> it? >> In this case no additional negotiation is required since prf is negotiated in >> IKEv2 anyway and thus we would have algorithm agility in KDF for free. > > I like this -- I'm stealing this idea. Note that using a hash of a hash is frowned upon. See the latest SLOTH on TLS for an example of a collision attack that used the fact that a hashed message got hashed again (unlike IKE which hashes only the data) Paul From nobody Thu Jan 14 09:16:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CE01A21BD for ; Thu, 14 Jan 2016 09:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 smZVH_gxCPop for ; Thu, 14 Jan 2016 09:16:21 -0800 (PST) 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 EE2CE1A6EDA for ; Thu, 14 Jan 2016 09:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1452791780; x=2316705380; 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=65vOee916DDARlXXUeh4SFDGPjuxIXtIZR7DI3qPeuE=; b=APQSLcvvqc7e2DEs/wk84jCYdlMFJp18Jo3KxI3cA27WUdSdxxL1+Ej3JhrdMa38 AsM1mtMHF+TM43q4dHWuqHA+pj388VsYyUkIonBhu0q54yTQSRq3ppW7aPRC3yHU wnURTHLonJEk0u5Qe9YwyNnr0/XsHGVr9BNJANZ7aZVo/rCeKhfzQS9wT9Tl5dvG clHLTGwtaFN0IqiGlBXIN4GmYNT+Wblexap+XQYbSnVPwHQu36aaR40WOjd0Bm78 L1zc3l2QxXjAI1fXZVD2Ns4keB25Q7LVG3++jfJjxbrlYTv/AoXuhB40H8QixzP9 7fGydMAG7g2mda9++4fYAQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id C5.B0.27014.4E7D7965; Thu, 14 Jan 2016 09:16:20 -0800 (PST) X-AuditID: 11973e16-f793c6d000006986-59-5697d7e462c6 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id E5.0C.05180.4E7D7965; Thu, 14 Jan 2016 09:16:20 -0800 (PST) Received: from [17.153.91.245] (unknown [17.153.91.245]) by jimbu.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0O0Y00MG7DB4IB00@jimbu.apple.com> for ipsec@ietf.org; Thu, 14 Jan 2016 09:16:20 -0800 (PST) Sender: dschinazi@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: David Schinazi In-reply-to: <6E030992-5975-4A02-83B8-695DFFF57C29@gmail.com> Date: Thu, 14 Jan 2016 09:16:16 -0800 Content-transfer-encoding: quoted-printable Message-id: <4A3BA7C8-3ACA-4250-8464-23CC89F10657@apple.com> References: <6E030992-5975-4A02-83B8-695DFFF57C29@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FAYrPvk+vQwgyOT5Cz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAsTpjMVNLFXHN02g7GB8S5rFyMnh4SAicS2jo/sELaYxIV7 69m6GLk4hAT2Mkosf/GSGabo0voPrBCJbiaJsw/XMkI4PUwS155eYQSpEhaQlui6ADGWWUBL Yv3O40wgNq+AnsS/CzfZIWo0JRa/uAe0goODDajmwBojkDCngK3E1lNHWEBsFgFViQu7fjJB jNGQuPjkJDuErS3x5N0FVoiRNhKPF+8BWyskUCRx+8Z7sLiIgJLE4StfoY6Wldi3YQHYNxIC C9gkzh29zzSBUWQWkvNmITlvFpIdCxiZVzEK5SZm5uhm5pnrJRYU5KTqJefnbmIEBfh0O7Ed jA9XWR1iFOBgVOLhXXB7WpgQa2JZcWXuIUZpDhYlcd6awqlhQgLpiSWp2ampBalF8UWlOanF hxiZODilGhirtX4s/GgQXyN/5uQJHqNrXGfvr6pv2Cibkrj75AGrZLtZjbv0tW9/WbAwPfvW vLPhOb7HZCUlXXy22v3o1tpxu3WST8ON91VFG2+6O8xvmH+b74kxY+rll14pkZ+3Mpo+bZk7 J+tTgaWQtc2Vn/F2IndnV0+WqTxiwBg+lTvwStzO4OVLmsSVWIozEg21mIuKEwHJB8ErUQIA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUiON1OVffJ9elhBtfapS32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAsTpjMVNLFXHN02g7GB8S5rFyMnh4SAicSl9R+gbDGJC/fW s3UxcnEICXQzSZx9uJYRwulhkrj29AojSJWwgLRE1wWIbmYBLYn1O48zgdi8AnoS/y7cZIeo 0ZRY/OIe0CQODjagmgNrjEDCnAK2EltPHWEBsVkEVCUu7PrJBDFGQ+Lik5PsELa2xJN3F1gh RtpIPF68B2ytkECRxO0b78HiIgJKEoevfGWGOFpWYt+GBWwTGAVnIbloFpKLZiEZu4CReRWj QFFqTmKlsV5iQUFOql5yfu4mRlBANhQG72D8s8zqEKMAB6MSD++C29PChFgTy4orcw8xSnAw K4nwbjw4PUyINyWxsiq1KD++qDQntfgQYzLQMxOZpUST84HRklcSb2hiYmBibGxmbGxuYk6a sJI471IdoK0C6YklqdmpqQWpRTBbmDg4pRoYc1fMvHzM+eujg8dVV77nLmC88Szz0ZH43NT4 HwFHivU2WdzP/1bHe71Rc6X+RtEHdZ33nt9ZsCnnem4o78drW3+/feu6brcOc/Pv+czB5rGN Upx+dZvlPhWdEjz6fZPxH4kLPUbf33LkX/9ZKKsXo/o89TZDWE5XyOHlqVMuVklrtzMdDnw+ QYmlOCPRUIu5qDgRABC5MneMAgAA Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] meeting at IETF-95 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 17:16:22 -0000 + 1 David > On Jan 13, 2016, at 14:51, Yoav Nir wrote: >=20 > I believe around that time CFRG and TLS will be done with the = signatures document and rfc4492bis respectively, so we could proceed and = finish draft-ietf-ipsecme-safecurves. >=20 > So count me as a +1 as well. >=20 >> On 12 Jan 2016, at 4:56 PM, Paul Wouters wrote: >>=20 >>=20 >> I hope we are scheduling a meeting for IETF-95. Last time we did not >> meet and ended up meeting in the hallway. This time there are more >> drafts being suggested and worked on. >>=20 >> Paul >>=20 >> _______________________________________________ >> 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 Thu Jan 14 23:34:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E901B2B01 for ; Thu, 14 Jan 2016 23:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 RHaGodpsWB0N for ; Thu, 14 Jan 2016 23:34:12 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E5C1B2AFE for ; Thu, 14 Jan 2016 23:34:12 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id c192so277609732lfe.2 for ; Thu, 14 Jan 2016 23:34:12 -0800 (PST) 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-type:content-transfer-encoding; bh=uwKPferEJiJdZhE8voOHB6CORMV1MV7dczSJSNjI234=; b=zLPKJOnl64P6lBzNUlaXQwpn2qsTslQQU7P7yHfHRV8NMuWMWvjvEb4e0pAWHuqKMH 9tlXjPRFOjTs6f5rwIH4hA1kq334XhSUMjzhrMM9Uhf8AEfEi92fwWvySwQ/PDJxl0so coLhLqV9Dj7bv/VXg4v3ApWk6q4hgipeDggbMX5beo3jUz+ZJiSyotDtvqd9Bo9i+GoQ gbl/lyrlJzT311494uFjraF1khyxy5hN0Emss+b41+HzzBV4dOCDX0p/UIQD6BGy/vVS 06e85iRpZJREY73IRnl5Umpy8YVkApnqdi6/n3je5TquFtn12QQ71huR8160Fnt7uyg6 T1/A== 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-type:content-transfer-encoding; bh=uwKPferEJiJdZhE8voOHB6CORMV1MV7dczSJSNjI234=; b=mnIA85A6n8EWP82WD01digWAiaMGaS4SRd76yQsTa6aULna3psPqrzP6hE9HtYorrT LiHNz0Z9PhHSTuS7HYCfnkbeXS1YTCWDiTxyHJ7bnHMKKioVSKLh37P9EHxbLW3Hwi1U EFX1+DtafGNWn+bWVTEeEef67gKCgMkIHJF3WZzaG8fsQ9ZfETwGSOPdX60AL/KGmb+l 3lZwt3b5DX/kbUTvwZ1YR8QHNVHnCHYd2JROIQQpBtRP8bpcPmsSvnvp5x6S+9VH9AHu 76brN/GEJd+PO3yWzI/mCuxUujfayUxxByEJeZbyubtJeHZaTaIvdzjcPg7C5oa7GVQz dw9g== X-Gm-Message-State: ALoCoQn1uEh9bY47L1lhHaKxjnaf+XS7EI7yftk+jjE1kZfKQNNq+h+iXDRX+8F2xRqZKUU65RObuM+F8ySJR8cDKAsQ6MOAXQ== X-Received: by 10.25.169.129 with SMTP id s123mr2236343lfe.39.1452843250548; Thu, 14 Jan 2016 23:34:10 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id l67sm1186263lfd.23.2016.01.14.23.34.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jan 2016 23:34:09 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , "Scott Fluhrer \(sfluhrer\)" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> Date: Fri, 15 Jan 2016 10:34:14 +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 Subject: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 07:34:14 -0000 Hi Paul, >>> Is it possible to use the already negotiated IKEv2 prf inside the modified >>> crypto formulas? >>> In this case they would look like: >>> >>> SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir) >>> (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = >>> prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr) >>> >>> and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't >>> it? >>> In this case no additional negotiation is required since prf is negotiated in >>> IKEv2 anyway and thus we would have algorithm agility in KDF for free. >> >> I like this -- I'm stealing this idea. > > Note that using a hash of a hash is frowned upon. See the latest SLOTH > on TLS for an example of a collision attack that used the fact that a > hashed message got hashed again (unlike IKE which hashes only the data) Not really. IKE does use prf inside prf. Let's expand SK_* computation formula: SK_* = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) = prf (prf(Ni | Nr, g^ir), Ni | Nr | SPIi | SPIr | 0x01) | prf (prf(Ni | Nr, g^ir), prf (prf(Ni | Nr, g^ir), Ni | Nr | SPIi | SPIr | 0x01) | Ni | Nr | SPIi | SPIr | 0x02) and so on. I don't think it's wrong from cryptography point of view if the prf is not broken (usual disclaimer: I'm not a cryptographer). However, thank you for bringing in the SLOTH attack. As fas as I understand from the paper http://www.mitls.org/downloads/transcript-collisions.pdf it is based on the ability for an attacker to find collisions in a weak hashes (md5 and sha1). In particular the authors uses chosen-prefix collision attacks to break some security protocols. They mostly focused on breaking TLS, but Section VI contains description of a possible attack on IKEv2. As far as I understnd the attack on IKEv2 it is based on the cookie request feature. The attacker makes a cookie request to the initiator with the cookie crafted in such a way, that the hash of the IKE_SA_INIT message containing this cookie would collide with the hash of the IKE_SA_INIT message containing attacker-chosen KE payload. It would allow the attacker to impersonate the initiator. If I got it right the ability for an attacker to quickly find a hash collision is based (besides using weak hashes) on presumption that the cookie is always the very first payload in the message, as depicted in the Section 2.6 in the RFC 7296. So it is presumed that the cookie always preceedes any unpredictable for the attacker values in the message, that allows to perform an effective chosen-prefix attack on a hash. So, I think that we can completely thwart this attack (regardless on the possible weakness of the used hashes) if we make a recommendation for implementers to put the cookie at the end of the message. RFC 7296 doesn't imply any restrictions on the payloads order. However the Section 2.6 states: If the IKE_SA_INIT response includes the COOKIE notification, the initiator MUST then retry the IKE_SA_INIT request, and include the COOKIE notification containing the received data as the first payload, and all other payloads unchanged. It's a bit unclear for me whether this MUST is concerned with the requirement to retry request only, in which case it is only a recommendation to place the COOKIE before other payloads, or the MUST is also applied to the text that COOKIE is the first payload (that would be unfortunate). What does IPsec community think of it? Should we fix the protocol to thwart this attack completely? Is the recommendation to move the COOKIE to the end of the message enough to achive that? Will this change break many existing implementations? Regards, Valery Smyslov. From nobody Thu Jan 14 23:37:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84B21B2B0E for ; Thu, 14 Jan 2016 23:37:53 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 4lkKWYIaCKHz for ; Thu, 14 Jan 2016 23:37:51 -0800 (PST) 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 981B41B2AF9 for ; Thu, 14 Jan 2016 23:37:51 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id f206so9236618wmf.0 for ; Thu, 14 Jan 2016 23:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=dHgifGGaeSiOb6ezeI0C/O05KcRilMzHw2fDOkZypfs=; b=wHojSuMWqnE+B2q9RyzKpRlZM4g0OQImVFp28oSguQ/y2AlOWIkAwJfXNX4OaKh66a qIucBirzy9LJ2C3kYEBxTr6B2TiClLEBsoqcLr62w4nqatwiZJGwzikJL30puQAPHtEA kFrq3fAQ+Ev+Cs9wTbizbHJoJ0OtFIbGuCil59LttvQiM28+yZodxNngNtT6O3I21oEn G6R5T5SdMUodxTX05Mb/cP4ZaiU5HJytCXTfWZ0BmbjPoMk0LZwTA/WK/3kr4IAASHpy FzzeE4et/aDvfcwIFZVzfIOexaf8NPLw1WPrtJw0EabNwS2OYHzvtI49RG26OxMjs3kA eGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=dHgifGGaeSiOb6ezeI0C/O05KcRilMzHw2fDOkZypfs=; b=jjkcrzsn5b+qO1VAqsUa/WqLZUv9HGbSB1iKQTCh1M90EcU27KsFlpFVnCWMJuE6RV XXaCBW+l44xvPbrmsQSQbEzfI1vjiSXSNuEY2WSq9p4Jn5khO3S8bABcdDg9B23VQpah YjGNBaru/mOu1eIhSkmgQQvGf3MF0ib3nz3hbK8pazHAWHmgfSQo8ZSlOEWBdC0MA5dF xsDT4/K7/0Fb1UJ9XLYiaX595Jb8qdP9PzL1mb2BSYpwvxFoFjFgc+NnyfAqR1Xd6GNt SVNYO7HqCr2Mj2Nhq724qL9ubRb3KJWXAjlHZoytgCi4hKkoRhiZQWNNwaozsD2xRoUW 0PNQ== X-Gm-Message-State: AG10YOSbGsnt6ktg3uIrC9Ntm+TwH8UOJAKEGmKoI/CiEYUbK5nMHD4j6oBccgaXgVpObA== X-Received: by 10.28.1.210 with SMTP id 201mr1721400wmb.90.1452843470161; Thu, 14 Jan 2016 23:37:50 -0800 (PST) Received: from [192.168.0.114] ([217.21.126.214]) by smtp.gmail.com with ESMTPSA id da10sm9353047wjb.22.2016.01.14.23.37.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jan 2016 23:37:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Les Leposo In-Reply-To: Date: Fri, 15 Jan 2016 10:37:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ipsec@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [IPsec] IPsec Digest, Vol 141, Issue 16 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 07:37:53 -0000 > On 14 Jan 2016, at 11:00 PM, ipsec-request@ietf.org wrote: >=20 > Send IPsec mailing list submissions to > ipsec@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipsec > or, via email, send a message with subject or body 'help' to > ipsec-request@ietf.org >=20 > You can reach the person managing the list at > ipsec-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPsec digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: NIST question concerning IKEv2 and quantum resistance > (Paul Wouters) > 2. Re: meeting at IETF-95 ? (David Schinazi) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Thu, 14 Jan 2016 11:28:00 -0500 (EST) > From: Paul Wouters > To: "Scott Fluhrer (sfluhrer)" > Cc: "ipsec@ietf.org" > Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum > resistance > Message-ID: > Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed >=20 > On Thu, 14 Jan 2016, Scott Fluhrer (sfluhrer) wrote: >=20 >>> Is it possible to use the already negotiated IKEv2 prf inside the = modified >>> crypto formulas? >>> In this case they would look like: >>>=20 >>> SKEYSEED =3D prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir) >>> (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =3D >>> prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr) >>>=20 >>> and so on. I'm not a cryptographer, but it seems to me that this is = safe, isn't >>> it? >>> In this case no additional negotiation is required since prf is = negotiated in >>> IKEv2 anyway and thus we would have algorithm agility in KDF for = free. >>=20 >> I like this -- I'm stealing this idea. >=20 > Note that using a hash of a hash is frowned upon. See the latest SLOTH > on TLS for an example of a collision attack that used the fact that a > hashed message got hashed again (unlike IKE which hashes only the = data) imho, the level of weakness would depend on the selected hash algorithms = and the input=E2=80=99s number space. for instance, if the number space for the input is huge, and the size of = 1st vs. 2nd hash reduces significantly, plus the (pseudo) randomness of = the hashes reduces then it would be a bad direction, I=E2=80=99d think. [not a cryptographer] >=20 > Paul >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Thu, 14 Jan 2016 09:16:16 -0800 > From: David Schinazi > To: Yoav Nir > Cc: "ipsec@ietf.org WG" > Subject: Re: [IPsec] meeting at IETF-95 ? > Message-ID: <4A3BA7C8-3ACA-4250-8464-23CC89F10657@apple.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 > + 1 >=20 > David >=20 >=20 >> On Jan 13, 2016, at 14:51, Yoav Nir wrote: >>=20 >> I believe around that time CFRG and TLS will be done with the = signatures document and rfc4492bis respectively, so we could proceed and = finish draft-ietf-ipsecme-safecurves. >>=20 >> So count me as a +1 as well. >>=20 >>> On 12 Jan 2016, at 4:56 PM, Paul Wouters wrote: >>>=20 >>>=20 >>> I hope we are scheduling a meeting for IETF-95. Last time we did not >>> meet and ended up meeting in the hallway. This time there are more >>> drafts being suggested and worked on. >>>=20 >>> Paul >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 > ------------------------------ >=20 > End of IPsec Digest, Vol 141, Issue 16 > ************************************** From nobody Fri Jan 15 00:48:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0D21A8A08 for ; Fri, 15 Jan 2016 00:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 56pWTKvR59eQ for ; Fri, 15 Jan 2016 00:48:01 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A3C1A8A07 for ; Fri, 15 Jan 2016 00:48:00 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id bc4so310224938lbc.2 for ; Fri, 15 Jan 2016 00:48:00 -0800 (PST) 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-type:content-transfer-encoding; bh=5ZbNBPxp6wZ5KEiLovvAwcMgs3qZYO4ZnnknSYWnSZg=; b=ivNTfCtwSWXBDfxaZZxJyFw3BHzVcK4cHd2cVyyO/oYhoMDdEOU8rZE7CNGMM0oNQo +PlL5cAlHzM9PIGsPbRhPWOMUgY2rL7TAseY1rIkJaOZZT0a/SEnsMoMTpumsORGj5XY e9gbz1jECbYhQvJuiIdxgwxSiUZlCStqP2/PyJgR8wP5cUYyKvbufsa/hE4U8CyHViRv tY+NVzDlCCsP+Bl/dXDWI1kMKyw0nS3ij77ayMPnYW1EDEIY3aJ1bENxIVfNjROiwdqx eMMublCiyT0DKH1sVvYCbS0gC1ianvW1SwcFMX/Ytg9+nsOWJhOkcuUbCBxtQ3VWVMYr 7vrw== 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-type:content-transfer-encoding; bh=5ZbNBPxp6wZ5KEiLovvAwcMgs3qZYO4ZnnknSYWnSZg=; b=LaVM+CcMuiP49dHXNUX+Q37sCcjCaXLCZVPNtaJE5mZ4RGAiuYk4TG7C0Zil9leu5G q5vPbQVMTenHhHsSc50fC2feRpsnO5D4DIMigwR6TWgn+U/7+cBjBD+DluFE4vwMUQnx kG8NNzjF/yvKHlOnV7rvrLnSIQ3K9Lr47AVmK2VPePIIu0sn6yjpakM+phnSFY5FUvzU 79kIacYNvrHajKTKjBuOdQLPnKAPcn2Z9PndhM3zPnARcGNI39FKZjU0XlF/0gkSW2K4 kWO6DMDKFEpNlOdk8UhcbY2EZbvjrBffBOsFuRncReGMnQ373ZM+wk894/RViLRiIMPd 9jXg== X-Gm-Message-State: ALoCoQkA6oeq7lK7UKVdssWi8SGHmJn/SspVYtpmROAaDeQ9n/eDX59jK7/EYpw4SKN2hzkbCT0UfFPYH/f3kr5jxv6fJEXRXQ== X-Received: by 10.112.139.130 with SMTP id qy2mr2355454lbb.18.1452847679225; Fri, 15 Jan 2016 00:47:59 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h8sm1207236lbd.48.2016.01.15.00.47.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 00:47:58 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , "Michael Richardson" , References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> Date: Fri, 15 Jan 2016 11:48:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; 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] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 08:48:02 -0000 Hi Scott, >> However, if no better solution exists I'd prefer to live with a single fixed >> crypto primitive, than with two. Is it possible to get rid of AES and to change >> the indication of the ppk to use to something like the following? >> >> HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes) >> >> (disclaimer: I'm not a cryptographer) > > Your proposal is perfectly sound from a cryptography perspective. > Actually, the reason we proposed the "entry in the AES codebook" approach, > rather than something like the above structure, is due to practical reasons. > When the responder receives the hint, he has no idea which ppk the initiator > is referring to (and he doesn't know the identity yet); our model is that the responder > has a list of ppk's that he knows about, and checks to see if the one that the initiator > had is on the list. It'd be nice if there was a way for the responder to search through > his databases of known ppk's quickly, however I don't know how to let him do it > in sublinear time (without leaking whether two exchanges used the same ppk, > which would leak information about the identities). So, what we settled on is to make > the linear scan for the right PPK as fast as possible. With our proposed solution, > an aggressive responder could have all the AES keys corresponding to the ppk preexpanded, > and just check each potential ppk by doing one AES block encryption (or decryption, > if they prefer); if the implementation has AES-NI, that is fairly fast. > With your proposal, they could preexpand the HMAC keys, but would still need > to do two SHA256 compression function evaluations. I see the point, thank you. However AES support in hardware is not always available, so I still think that having a single crypto primitive is better in this situation. But your explanations brings me to a conclusion, that the protocol could me modified. Please see my logical chain. The necessity to perform a linear serach of the ppk keys (and thus spending some CPU power) makes a responder more succeptible to DoS attack, because it must spend resources in response to any IKE_SA_INIT exchange even from spoofed IP address. In this situation a sane responder would try to defend itself sending a cookie request - this would guarantee that the initiator is alive and the IP address is not spoofed. So, if the cookie request is to be sent in most cases when the IKE_SA_INIT message contains ppk extension anyway, then the protocol could be modified to make cookie request mandatory in this situation. Then the IKE_SA_INIT exchange would look like: HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED) --> <-- HDR, N(COOKIE), N(PPK_SUPPORTED, crypto=xxx, random_data=zzz) The responder selects prf (and encryption, if it is used) algorithms from the SAi1 payload. It also supplies random_data that the initiator must use when it encodes the ppk. The initiator computes an encoded ppk and retries the request. HDR, N(COOKIE), SAi1, KEi, Ni, N(PPK_KEY) --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] This variant has a disadvantage that ppk will always require an additional round trip. However it has the following benefits: 1. Full support for algorithms agility 2. No need to perform CPU-intensive operations until the initiator's IP is confirmed 3. In this variant it is the responder who supplies random_data to initiator to encode ppk, so it is on the responder discretion how to choose them. For example, it may precompute the encoded ppk values when it is idle, or it can reuse random_data several times. This allow the responder to perform the ppk search in sub-linear time in some circumstances. 4. The additional round trip requires a minimum change to IKEv2, since cookie request must be supported anyway. What do you think? Regards, Valery. From nobody Fri Jan 15 00:55:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CBA1A8A56 for ; Fri, 15 Jan 2016 00:55:51 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 4oj78pqVlSkh for ; Fri, 15 Jan 2016 00:55:50 -0800 (PST) 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 BF16A1A8A50 for ; Fri, 15 Jan 2016 00:55:49 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id l65so11427291wmf.1 for ; Fri, 15 Jan 2016 00:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=O0zOfdGuzYOIX1RQtQJbiDSaKGdIsDlKkK5APGgBFe0=; b=Nnn1FWerWTyI09QhjkDi5iu2ImXdjV3AimJdhPm1CQx/hmUOM+/wmjnO8F/fXli5lM wVF8sJh+0SlAuccnzhY7zkqBDgKHwhqXC1gBXZvKbb/PsGKl3f4Zq1EgTEqOnDF+Xnwf wzWrs3Gr6Lo3owF1CGoUN6efugsISfVdyOo1RkosryDxzcp9ENc85q3rqx40Ih1ntpAc lmTV61PqEzWnHeU+in4B/KnAlSXbdXdFghpZYsLu/DRIFvQzuX53G+SdJBcvmNfY3tjT +699K1GjxlGnNXM4LAao/Gm/dHmzkLTBUI7FBq8VD3fIGIKdyPBSXMS8xDeVuaAO6t6s VvDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=O0zOfdGuzYOIX1RQtQJbiDSaKGdIsDlKkK5APGgBFe0=; b=EDjUzvx6SkCjfhIufYB8h3QDmh80Tsp/5/qkCuo2SSw+dd/QGe9TVdRymfSjlb0mwQ j2k8jH7yYhqzbhdArT3arZWkyTSZPVkq8aRSKozEK+iBLsDgnNRuEQOPN4IFrvfv4/gM s56FPp6All6X0SrW3cv/8oJrznlnDG+4bLR6js9pk1g5vq5WRQcr5rDp+hxpYWHqvLyX U7r2PXRZrwscivb2wdF/oAeVmOxt5pJTgng84sVunIeZqsQWznUMx6GYCpVAQR8MrLSl rtayhWVMzWVIN3JCQ0sK2HI0SVfrLa8nzZEGSPeK2e1vMFZNsfOF9lShJJjILxkUog51 aJuA== X-Gm-Message-State: AG10YOQdvq8vWJLLfzFFIJAc2H/4yFHIi2uDc5jPs24GTGnVIUcM7xxNtJCWbm/NjWEBGg== X-Received: by 10.28.51.17 with SMTP id z17mr2199251wmz.26.1452848148283; Fri, 15 Jan 2016 00:55:48 -0800 (PST) Received: from [10.0.0.10] (bzq-109-65-180-184.red.bezeqint.net. [109.65.180.184]) by smtp.gmail.com with ESMTPSA id p9sm9597247wjy.41.2016.01.15.00.55.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 00:55:46 -0800 (PST) To: Valery Smyslov , Paul Wouters , "Scott Fluhrer (sfluhrer)" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> From: Yaron Sheffer Message-ID: <5698B410.5030809@gmail.com> Date: Fri, 15 Jan 2016 10:55:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 08:55:52 -0000 However, thank you for bringing in the SLOTH attack. > As fas as I understand from the paper > http://www.mitls.org/downloads/transcript-collisions.pdf it is based > on the ability for an attacker to find collisions in a weak hashes > (md5 and sha1). In particular the authors uses chosen-prefix collision > attacks > to break some security protocols. They mostly focused on breaking TLS, > but Section VI contains description of a possible attack on IKEv2. > > As far as I understnd the attack on IKEv2 it is based on the cookie > request > feature. The attacker makes a cookie request to the initiator > with the cookie crafted in such a way, that the hash of the > IKE_SA_INIT message > containing this cookie would collide with the hash of the IKE_SA_INIT > message > containing attacker-chosen KE payload. It would allow the attacker > to impersonate the initiator. > > If I got it right the ability for an attacker to quickly find a hash > collision > is based (besides using weak hashes) on presumption that the cookie is > always the very first payload in the message, > as depicted in the Section 2.6 in the RFC 7296. So it is > presumed that the cookie always preceedes any unpredictable > for the attacker values in the message, that allows to perform > an effective chosen-prefix attack on a hash. > > So, I think that we can completely thwart this attack (regardless > on the possible weakness of the used hashes) if we make > a recommendation for implementers to put the cookie at the > end of the message. RFC 7296 doesn't imply any restrictions > on the payloads order. However the Section 2.6 states: > > If the IKE_SA_INIT response > includes the COOKIE notification, the initiator MUST then retry the > IKE_SA_INIT request, and include the COOKIE notification containing > the received data as the first payload, and all other payloads > unchanged. > It's a bit unclear for me whether this MUST is concerned with the > requirement to retry request only, in which case it is only > a recommendation to place the COOKIE before other payloads, > or the MUST is also applied to the text that COOKIE is the first > payload (that would be unfortunate). > > What does IPsec community think of it? Should we fix the protocol > to thwart this attack completely? Is the recommendation to move the > COOKIE to the end of the message enough to achive that? > Will this change break many existing implementations? > > Regards, > Valery Smyslov. As far as I can tell, the cookie hash algorithm is an implementation decision of the responder and (despite what's implied in the paper) is never specified in the protocol. It would be much simpler to add a section to the new 4307bis saying that this hash is security-critical, and recommending SHA-256 or stronger. The experience with TLS is that making small protocol changes to protect against weak algorithms is not a good long-term strategy. It's just a challenge for researchers to come up with better attacks. I believe the hash-and-URL mechanism is not used in practice. But if it is, that's another place where we have hardcoded SHA-1, and maybe we should start worrying about it. Thanks, Yaron From nobody Fri Jan 15 01:19:16 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32A21A8BB4 for ; Fri, 15 Jan 2016 01:19:14 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 FQmdwkNQleeK for ; Fri, 15 Jan 2016 01:19:12 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5711A8BB3 for ; Fri, 15 Jan 2016 01:19:12 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id f206so14927081wmf.0 for ; Fri, 15 Jan 2016 01:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TSCzVN50Bipj/Hv/dOg/MomehHXkNmcLpoYt5USx4F8=; b=ysCnnwWpFb1Q0+D5ICBL7u+1tf2vseDw75IByj4PQM1dZ7+dg/PrAWl5JFNXieYt1o WUnzBM6gt5t5ZWj66cunAvm2lmCj093VLhiCWFc+JVSyKIVZsgHsJoBgyBVcXBWAyp8T Vx6xRLiYqzxS0gW31uQ8vd0ZeylE8wTJ44/YZxXMswEwolZV0MycgAtmZtUB5k3n3Yb4 GcdGhfHP5AvzHRrR6MaY/taVy4AO+mVyr7nKYS81BzQY33bpDBcn9s0FY12GywZEabJY 2pFnpuO5ZHl3oE+t72U0weB4BpU80fpKPkeCNxtEgbCVURIsljKnz6Thj/0bNeivenJR Ps4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TSCzVN50Bipj/Hv/dOg/MomehHXkNmcLpoYt5USx4F8=; b=bdINnS5OpSJ6q8+OkXHrkDXXyBuFjJNeElLNVerE2ZuEIYJLRSMQhR68tXaEp7i9Cv O1o4N+cFY+FspJO8CQsga38PAl0Qdb+Py/Ay4kQ9B7mqKIj8RjBg67og8MnIvwk7AVXI T6Uq01vMK0+ONn5cLjcu47YdEOs5hWgvGW2myE4fsyxjYKkqf7rMtLNkbqDVNzk+pvBs 4Y+BLr69mbbxHkQnfeP517uKPDu2j+nToBLG00gasrlsFc3f8m99iuZ1+7kotPU6uNyg a8iJ/KXf8cRWAdYJm/eWjVCPZvFEgKPK+DEHnoFT2HBPAm0cEkR08wvbcySO0yAIrf35 KQJQ== X-Gm-Message-State: AG10YOQ982b0+63zuT13kBRSITSh55kzaYUaswqN8uCJcgcdJjPIa4Cht2rVJyvU36I9xw== X-Received: by 10.28.211.136 with SMTP id k130mr2253672wmg.84.1452849550983; Fri, 15 Jan 2016 01:19:10 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id id1sm9712488wjb.19.2016.01.15.01.19.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 01:19:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <5698B410.5030809@gmail.com> Date: Fri, 15 Jan 2016 11:19:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org, Valery Smyslov , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 09:19:14 -0000 > On 15 Jan 2016, at 10:55 AM, Yaron Sheffer = wrote: >=20 > However, thank you for bringing in the SLOTH attack. >> As fas as I understand from the paper = http://www.mitls.org/downloads/transcript-collisions.pdf it is based on = the ability for an attacker to find collisions in a weak hashes (md5 and = sha1). In particular the authors uses chosen-prefix collision attacks >> to break some security protocols. They mostly focused on breaking = TLS, >> but Section VI contains description of a possible attack on IKEv2. >>=20 >> As far as I understnd the attack on IKEv2 it is based on the cookie = request >> feature. The attacker makes a cookie request to the initiator >> with the cookie crafted in such a way, that the hash of the = IKE_SA_INIT message >> containing this cookie would collide with the hash of the IKE_SA_INIT = message >> containing attacker-chosen KE payload. It would allow the attacker >> to impersonate the initiator. >>=20 >> If I got it right the ability for an attacker to quickly find a hash = collision >> is based (besides using weak hashes) on presumption that the cookie = is always the very first payload in the message, >> as depicted in the Section 2.6 in the RFC 7296. So it is >> presumed that the cookie always preceedes any unpredictable >> for the attacker values in the message, that allows to perform >> an effective chosen-prefix attack on a hash. >>=20 >> So, I think that we can completely thwart this attack (regardless >> on the possible weakness of the used hashes) if we make >> a recommendation for implementers to put the cookie at the >> end of the message. RFC 7296 doesn't imply any restrictions >> on the payloads order. However the Section 2.6 states: >>=20 >> If the IKE_SA_INIT response >> includes the COOKIE notification, the initiator MUST then retry the >> IKE_SA_INIT request, and include the COOKIE notification containing >> the received data as the first payload, and all other payloads >> unchanged. >> It's a bit unclear for me whether this MUST is concerned with the = requirement to retry request only, in which case it is only >> a recommendation to place the COOKIE before other payloads, >> or the MUST is also applied to the text that COOKIE is the first = payload (that would be unfortunate). >>=20 >> What does IPsec community think of it? Should we fix the protocol >> to thwart this attack completely? Is the recommendation to move the = COOKIE to the end of the message enough to achive that? >> Will this change break many existing implementations? >>=20 >> Regards, >> Valery Smyslov. >=20 > As far as I can tell, the cookie hash algorithm is an implementation = decision of the responder and (despite what's implied in the paper) is = never specified in the protocol. It would be much simpler to add a = section to the new 4307bis saying that this hash is security-critical, = and recommending SHA-256 or stronger. The SLOTH paper does not depend at all on the hash used to break the = cookie. They use the cookie mechanism to inject a prefix (Because the = Initiator dutifully repeats the cookie that the MITM gave them) to = control the hash of the entire packet to create a collision. They also = rely on neither Initiator nor responder checking cookie lengths or even = validating the cookies if a DoS attack is not underway. Maybe we should = specify that in the anti-ddos draft. > The experience with TLS is that making small protocol changes to = protect against weak algorithms is not a good long-term strategy. It's = just a challenge for researchers to come up with better attacks. >=20 > I believe the hash-and-URL mechanism is not used in practice. But if = it is, that's another place where we have hardcoded SHA-1, and maybe we = should start worrying about it. AFAIK a second pre-image attack on SHA-1 where the second pre-image = looks like a valid X509 certificate is still far. Even if it were not, = what is the attack? the real Initiator fetches the wrong certificate and = the authentication fails? This happens even if you don=E2=80=99t match = the SHA-1. Yoav= From nobody Fri Jan 15 03:12:02 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951571ACD5A for ; Fri, 15 Jan 2016 03:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_NEUTRAL=0.779] autolearn=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 PsO8z_D4jFDv for ; Fri, 15 Jan 2016 03:11:58 -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 C011B1ACD32 for ; Fri, 15 Jan 2016 03:11:57 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0FBBkAt006189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Jan 2016 13:11:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0FBBkTu006444; Fri, 15 Jan 2016 13:11:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22168.54258.15030.451398@fireball.acr.fi> Date: Fri, 15 Jan 2016 13:11:46 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 34 min Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 11:12:00 -0000 Valery Smyslov writes: > However, thank you for bringing in the SLOTH attack. As fas as I > understand from the paper > http://www.mitls.org/downloads/transcript-collisions.pdf it is based > on the ability for an attacker to find collisions in a weak hashes > (md5 and sha1). In particular the authors uses chosen-prefix > collision attacks to break some security protocols. They mostly > focused on breaking TLS, but Section VI contains description of a > possible attack on IKEv2. > > As far as I understnd the attack on IKEv2 it is based on the cookie > request feature. The attacker makes a cookie request to the > initiator with the cookie crafted in such a way, that the hash of > the IKE_SA_INIT message containing this cookie would collide with > the hash of the IKE_SA_INIT message containing attacker-chosen KE > payload. It would allow the attacker to impersonate the initiator. > > If I got it right the ability for an attacker to quickly find a hash > collision is based (besides using weak hashes) on presumption that > the cookie is always the very first payload in the message, as > depicted in the Section 2.6 in the RFC 7296. So it is presumed that > the cookie always preceedes any unpredictable for the attacker > values in the message, that allows to perform an effective > chosen-prefix attack on a hash. They also assume that everything before the cookie is fixed, i.e. that the IKEv2 HDR is also fixed. IKEv2 HDR contains the SPIi and SPIr. The SPIr in the first message is all zeros, but the SPIi is selected by the initiator to be random. If the SPIi from the initiator is unpredictable, i.e. not fixed constant, then this changes the attack from offline 2^77 hash collision attack against SHA1 to online 2^77 hash collision attack, i.e. the attacker needs to fix SHA1 hash collision during the negotiation, without any precalculations. I have already sent an email to the authors of the paper about this and I think they agree on that. The problem is that RFC7296 does not require SPIs to be random or unpredictable. RFC7296 just requires them to be unique, so there is nothing wrong in the implementation which would use fixed SPIi of 0x0000 0000 0000 0001 for all IKE SAs (and would only support one IKE SA). Fortunately I have not seen any implementations doing that, I think all implementations I have seen use random IKEv2 SPIi. In the IKEv1 things were different as the SPIi and SPIr were actually cookies, and they were sometimes generated using hashing of the addresses etc and some random secret, and then there might have been some kind of secret generation counter or similar. > So, I think that we can completely thwart this attack (regardless > on the possible weakness of the used hashes) if we make > a recommendation for implementers to put the cookie at the > end of the message. RFC 7296 doesn't imply any restrictions > on the payloads order. However the Section 2.6 states: > > If the IKE_SA_INIT response > includes the COOKIE notification, the initiator MUST then retry the > IKE_SA_INIT request, and include the COOKIE notification containing > the received data as the first payload, and all other payloads > unchanged. > > It's a bit unclear for me whether this MUST is concerned with > the requirement to retry request only, in which case it is only > a recommendation to place the COOKIE before other payloads, > or the MUST is also applied to the text that COOKIE is the > first payload (that would be unfortunate). There is no point of changing the cookie location, as this attack does not really work. If attacker are able to do hash collision attacks during the exchange against the hash we are using then I think the hash needs to be considered broken. I do not think even NSA can find SHA-1 hash collision during the few seconds they have time during the exchange. Also this attack do require that the user use the groups with small subgroups, like groups 22-24 (and their previous paper the authors of this paper said that curve25519 has one small subgroup with size of 8, see page 9 of [1]) so they can make the g^xy' same as g^x'y by forcing both ends to use same small subgroup and trying so many times that the g^xy' and g^x'y happened to be same. If the size of subgroup is less than then there is good change that will happen with few tries. > What does IPsec community think of it? Should we fix the protocol > to thwart this attack completely? Is the recommendation to > move the COOKIE to the end of the message enough to achive that? > Will this change break many existing implementations? I would recommend that we make sure our SPIs are unpredicatable and random instead of only being unique, and that we always do small subgroup checks regardless whether we reuse the private Diffie-Hellman values or not for those groups that have small subgroups (22-24, curve25519). [1] https://alfredo.pironti.eu/research/sites/default/files/ndss15.pdf -- kivinen@iki.fi From nobody Fri Jan 15 05:42:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2301B2D0A for ; Fri, 15 Jan 2016 05:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 pXnUymK4yiX3 for ; Fri, 15 Jan 2016 05:42:43 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 3DE631B2D08 for ; Fri, 15 Jan 2016 05:42:42 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id oh2so315566914lbb.3 for ; Fri, 15 Jan 2016 05:42:42 -0800 (PST) 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-type:content-transfer-encoding; bh=o40gn/0H6cpcH+0Wn9zdLk1xkKF60Db7C1vId4izUJ8=; b=z9osix3+eRCXcK2gWtE0Q/LsaWSkFthxo587zlvRm0/QuoCquhYZ3U3O/ZS5LEDAc7 Cd+kqd3i3Oo3W/CuqrWIPjqyj0jf/t1VZokk6domAI1g/+u3SrGw1Wgm6ZXqJf8E9j+S ZBCTRtJtTJ4gSbM2FtqNA1DLPxCCS9Asncys0w51VuurNyriaz27jgoet3qa+4Km8cjT HKWA57QB/kll8NJX6JLGsY7s5Q2Y0qWaZUmflj/SqDKxtyDHBmifgL2aVa3ueKt805g0 qeu9EvLiPHBsF8cSZPkHyRKa6p+sGiIZ8rGW7tcVNrNTeKsXO/St1RnXVkuR3sX04NDo bb5Q== 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-type:content-transfer-encoding; bh=o40gn/0H6cpcH+0Wn9zdLk1xkKF60Db7C1vId4izUJ8=; b=MoYHWPoYJy0GHKPhriR+iYa62lYF4KlMMK4G2OSBby1+3krc8TBSD1XwVQqnoCilqK crCFU9k2hyMQ5gCKkS9Cy2Eebzn27O59vIoh0g5I12ILlagQHGURXC/1Du3R7ULc1c2g DTJQpYCWxWsa7yX4Vm0dqHadrx5i4xNsoDshCPJpCqGviFSqCDst2F4oL4Wy2wJ2A4Ca i49+3I4nZXvSXSrn7GBVsezmP8aTUJEsLQTsOLPAdv9l+s9aOb58FvJ0gC+cD+90+mGQ vzT+/2slIadtQnuufPkP+MIqCS4d7aBbVzXQF4WIrxWlyJ5SpeWqEzPrzZdXHzTQl5Sk dSsg== X-Gm-Message-State: ALoCoQkhSotxsEiBeD2tcAi8sNhe/ByT9KZG9JDYy1yj8pf7wdZmA8jFsJTVZzm5LdCWjmzyB6p4bDufdU+MK5OAJq4YL/Nkqg== X-Received: by 10.112.125.198 with SMTP id ms6mr3436514lbb.106.1452865360519; Fri, 15 Jan 2016 05:42:40 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id ak1sm1336892lbc.2.2016.01.15.05.42.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 05:42:39 -0800 (PST) Message-ID: <791581F4A4864E9EAFD4A05CFB7C935F@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com><5810658E1DC448D59B09CAC6D8678445@buildpc><17915.1452704345@obiwan.sandelman.ca><890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com><672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <22168.54258.15030.451398@fireball.acr.fi> Date: Fri, 15 Jan 2016 16:42:46 +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 , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 13:42:48 -0000 Hi Tero, >> If I got it right the ability for an attacker to quickly find a hash >> collision is based (besides using weak hashes) on presumption that >> the cookie is always the very first payload in the message, as >> depicted in the Section 2.6 in the RFC 7296. So it is presumed that >> the cookie always preceedes any unpredictable for the attacker >> values in the message, that allows to perform an effective >> chosen-prefix attack on a hash. > > They also assume that everything before the cookie is fixed, i.e. that > the IKEv2 HDR is also fixed. IKEv2 HDR contains the SPIi and SPIr. The > SPIr in the first message is all zeros, but the SPIi is selected by > the initiator to be random. If the SPIi from the initiator is > unpredictable, i.e. not fixed constant, then this changes the attack > from offline 2^77 hash collision attack against SHA1 to online 2^77 > hash collision attack, i.e. the attacker needs to fix SHA1 hash > collision during the negotiation, without any precalculations. Ah, that's right. > I have already sent an email to the authors of the paper about this > and I think they agree on that. > >> So, I think that we can completely thwart this attack (regardless >> on the possible weakness of the used hashes) if we make >> a recommendation for implementers to put the cookie at the >> end of the message. RFC 7296 doesn't imply any restrictions >> on the payloads order. However the Section 2.6 states: > > There is no point of changing the cookie location, as this attack does > not really work. If attacker are able to do hash collision attacks > during the exchange against the hash we are using then I think the > hash needs to be considered broken. I do not think even NSA can find > SHA-1 hash collision during the few seconds they have time during the > exchange. That's right, however I have an impression that we are close to the safety margins here. IKE SPI is relatively short and even if it is chosen at random it is often generated using non-cryptographically strong RNG, for example by invocation rand(), so that the attacker may have a chance to predict it. This makes me think that with a progress in hash analysys the attack may become practical. Moving COOKIE to the end of the message would make the attack much more difficult, probably infeasible. And note, that this change wouldn't violate RFC 7296, since it explicitely allows payloads to appear in the message in any order. However, I understand that it may break some existing implementations, and taking into considerations that the attack seems to be impractical currently, I tend to agree with Tero that we may do nothing right now. Probably postpone it to some future protocol update. Regards, Valery. From nobody Fri Jan 15 05:55:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D13C1ACD71 for ; Fri, 15 Jan 2016 05:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 TDmE-9cqmiOU for ; Fri, 15 Jan 2016 05:55:43 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 3A9271B2D2B for ; Fri, 15 Jan 2016 05:55:43 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id oh2so315768547lbb.3 for ; Fri, 15 Jan 2016 05:55:43 -0800 (PST) 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-type:content-transfer-encoding; bh=lNnubiPUkXhXfVhGaSgrYuh96yYziOuUfmfw+M34K60=; b=qqo7baohipEzyb9lDs26MXqAskdsTKzxnXF/K36CkaB6AufBdEPHizxe3TCPPucX15 GZB816XfwtmeFjJZyWwVY/B24R3NI1BgdaFiYlgzOrLoa24OoTtbu1uB6RrYLTOFgVnA Ss2xg6JHWWSytwzl89RfIGeP20w20aF5iGKyU17Nlc/5LDzZk8WuMnRA/XyZvCHGHU3Y XI+qdFv2+UOt1dKGH/lDxsZlEidk3mTMiCHjrLdlckc/smxO6dMzVgLU4rRl0SwbjWyY 5HojhAdNARITO0YCoRc3eAoyo5TY7Cadrr7bnfDRAfdhi1oxXRkwuofcBxLuI/OhD0rR Z/Dg== 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-type:content-transfer-encoding; bh=lNnubiPUkXhXfVhGaSgrYuh96yYziOuUfmfw+M34K60=; b=AMqtrP9xpOjQyh3VMkD6M6z3wui+A+xqyrc4VeFndGGjMpdK/mzuAXpibs1aH6Z5Kr gOj7IurSPSo+6PRbLSEBRiIo2HzksPujfzT2dwgpMBwOGPquLPIUV/7YHLWFwMbOOQZn HNrlTmTMuuSmyy9nEQrKeSk1IMfw2kQMFqU6rK6TZOKYNT+gjhLKEn15BAwvxpHUHz66 24FZ/Z9vJZIh6/FTVYiB8FSJsgi2MF803HWJSLOqOt2LUP5RkgrGNgYSR89n5yY0ASnS pldFpik4Cbk0s9ykvt6R8jHjtAp67JIbUiNRNnos/Ah9kigLVfPmbvaAcHLD37Tc01xd GPCA== X-Gm-Message-State: AG10YOSpkf/WcgxrFMoyZMRbENriWoLcjtH96hlkZvzq+McpJ307paUwLtSosolJU0x1Nw== X-Received: by 10.112.145.165 with SMTP id sv5mr1600736lbb.97.1452866141313; Fri, 15 Jan 2016 05:55:41 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id qb3sm1335664lbb.39.2016.01.15.05.55.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 05:55:40 -0800 (PST) Message-ID: <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "Yaron Sheffer" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> Date: Fri, 15 Jan 2016 16:55:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; 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 , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 13:55:44 -0000 Hi Yoav, >>> What does IPsec community think of it? Should we fix the protocol >>> to thwart this attack completely? Is the recommendation to move the COOKIE to the end of the message enough to >>> achive that? >>> Will this change break many existing implementations? >> >> As far as I can tell, the cookie hash algorithm is an implementation decision >> of the responder and (despite what's implied in the paper) is never specified >> in the protocol. It would be much simpler to add a section to the new 4307bis >>saying that this hash is security-critical, and recommending SHA-256 or stronger. > > The SLOTH paper does not depend at all on the hash used to break the cookie. > They use the cookie mechanism to inject a prefix (Because the Initiator dutifully repeats > the cookie that the MITM gave them) to control the hash of the entire packet to create a collision. > They also rely on neither Initiator nor responder checking cookie lengths or even validating > the cookies if a DoS attack is not underway. Maybe we should specify that in the anti-ddos draft. The initiator cannot validate the cookie - it is an opaque blob for him. Should he reject the cookie if its length is more than 64 bytes? Possibly. I don't know. It's a bit strange to check an opaque object... What about the responder - he doesn't see any cookie in this attack - the attacker sends the crafted cookie only to the initiator and sends a crafted IKE_SA_INIT message w/o cookie to the responder (as far as I understand the attack). Regards, Valery. From nobody Fri Jan 15 06:41:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590B51ACE25 for ; Fri, 15 Jan 2016 06:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 vOfOtI1UYYbo for ; Fri, 15 Jan 2016 06:41:30 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A541ACE24 for ; Fri, 15 Jan 2016 06:41:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3phlZJ61Hyz3KV; Fri, 15 Jan 2016 15:41:28 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 qVuTmSo_Ki_z; Fri, 15 Jan 2016 15:41:27 +0100 (CET) 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, 15 Jan 2016 15:41:27 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8726E603AF12; Fri, 15 Jan 2016 09:41:26 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 8726E603AF12 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 83455479DA4; Fri, 15 Jan 2016 09:41:26 -0500 (EST) Date: Fri, 15 Jan 2016 09:41:26 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> Message-ID: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:41:32 -0000 On Fri, 15 Jan 2016, Valery Smyslov wrote: >> > > What does IPsec community think of it? Should we fix the protocol >> > > to thwart this attack completely? Is the recommendation to move the >> > > COOKIE to the end of the message enough to achive that? >> > > Will this change break many existing implementations? We (libreswan) did a little hardening on the cookie that will verify unexpected cookies anyway, contrary to current RFC: https://securityblog.redhat.com/2016/01/13/the-sloth-attack-and-ikeipsec/ Paul From nobody Fri Jan 15 07:18:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9115A1B2F26 for ; Fri, 15 Jan 2016 07:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.001] autolearn=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 UVg8qngOiaPY for ; Fri, 15 Jan 2016 07:18:31 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9B21B2F27 for ; Fri, 15 Jan 2016 07:18:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3phmP06KrZz3KV; Fri, 15 Jan 2016 16:18:28 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 eAoWuFH3sl_8; Fri, 15 Jan 2016 16:18:27 +0100 (CET) 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, 15 Jan 2016 16:18:27 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A979B6015373; Fri, 15 Jan 2016 10:18:26 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca A979B6015373 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A5F4C1D46C; Fri, 15 Jan 2016 10:18:26 -0500 (EST) Date: Fri, 15 Jan 2016 10:18:26 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22168.54258.15030.451398@fireball.acr.fi> Message-ID: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <22168.54258.15030.451398@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 15:18:32 -0000 On Fri, 15 Jan 2016, Tero Kivinen wrote: > The problem is that RFC7296 does not require SPIs to be random or > unpredictable. RFC7296 just requires them to be unique, so there is > nothing wrong in the implementation which would use fixed SPIi of > 0x0000 0000 0000 0001 for all IKE SAs (and would only support one IKE > SA). > Fortunately I have not seen any implementations doing that, I think > all implementations I have seen use random IKEv2 SPIi. > In the IKEv1 things were different as the SPIi and SPIr were actually > cookies, and they were sometimes generated using hashing of the > addresses etc and some random secret, and then there might have been > some kind of secret generation counter or similar. We use random for the SPIi but use this latter described method for SPIr. This ensures an attacker cannot empty your entropy pool, or see the raw bytes of your entropy pool when you happened to use a bad PRNG like DUAL_EC or something. We use the same methods for IKEv1 and IKEv2. > Also this attack do require that the user use the groups with small > subgroups, like groups 22-24 (and their previous paper the authors of > this paper said that curve25519 has one small subgroup with size of 8, > see page 9 of [1]) so they can make the g^xy' same as g^x'y by forcing > both ends to use same small subgroup and trying so many times that the > g^xy' and g^x'y happened to be same. If the size of subgroup is less > than then there is good change that will happen with few tries. I did not know curve25519 also has that problem :/ > I would recommend that we make sure our SPIs are unpredicatable and > random instead of only being unique See my above concern about an attacker depleting the entropy pool. > , and that we always do small > subgroup checks regardless whether we reuse the private Diffie-Hellman > values or not for those groups that have small subgroups (22-24, > curve25519). We should, as NIST already requires it anyway. I am curious though why people re-use DH values. Is that really still needed on busy servers? This has never been in freeswan, openswan or libreswan and we have never heard people complain (and yes we do have big deployment servers too, but not on shitty 1995 hardware :) Paul From nobody Fri Jan 15 07:21:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E941B2F33 for ; Fri, 15 Jan 2016 07:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 Pd1WuTv9_zia for ; Fri, 15 Jan 2016 07:21:37 -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 CF6D11B2F27 for ; Fri, 15 Jan 2016 07:21:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3phmSb17vtz3KV; Fri, 15 Jan 2016 16:21:35 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 39Cag-LAAJuI; Fri, 15 Jan 2016 16:21:34 +0100 (CET) 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, 15 Jan 2016 16:21:34 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 73F5B6015373; Fri, 15 Jan 2016 10:21:33 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 73F5B6015373 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 709D51D46C; Fri, 15 Jan 2016 10:21:33 -0500 (EST) Date: Fri, 15 Jan 2016 10:21:33 -0500 (EST) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> User-Agent: Alpine 2.20 (LFD 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 WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 15:21:37 -0000 On Fri, 15 Jan 2016, Yoav Nir wrote: > They use the cookie mechanism to inject a prefix (Because the Initiator dutifully repeats the cookie that the MITM gave them) to control the hash of the entire packet to create a collision. They also rely on neither Initiator nor responder checking cookie lengths or even validating the cookies if a DoS attack is not underway. Maybe we should specify that in the anti-ddos draft. So we added that patch to libreswan. It will now always verify the cookie even when it isnt sending out ddos cookies itself. We might tweak it a little bit with a timer to limit the damage attackers can do by sending many spoofed IKE_INIT packets with COOKIES that we'd be burning our hasher on. > AFAIK a second pre-image attack on SHA-1 where the second pre-image looks like a valid X509 certificate is still far. Even if it were not, what is the attack? the real Initiator fetches the wrong certificate and the authentication fails? This happens even if you don’t match the SHA-1. Similarly for their proposed IKEv1 attack using the ID payload. Paul From nobody Fri Jan 15 11:24:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C6C1B31A7 for ; Fri, 15 Jan 2016 11:24:37 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 J9ATpY-A8Myz for ; Fri, 15 Jan 2016 11:24:35 -0800 (PST) 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 26E0F1B31A3 for ; Fri, 15 Jan 2016 11:24:35 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id u188so35597756wmu.1 for ; Fri, 15 Jan 2016 11:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pVuRVqxiy/qGmUPLVsjTQxgaBPS5sTyLCRs/MnroZCA=; b=VSWE2w8eRFRlVRbFA5nw+JgY19+iBl52ZshziM6MsweAWqMXcZsdrKuPDdBj+xdvcP Tx7h+ved8jDajbaPysxAbDmt/HWbz2U1TYDXVvRQ60Vj/N9rDuY/XUY9Kh5D2SMYyjRO nfnZ5bRPi/o22tAMHEt6lvyaNx8WQrh/ZBiA1NmL5Fdy3isUWjhjOISl5Idofl7G/PEl QfSzIB/DBigw8VW1z1y6avXeRVJr2sJVjxR7YIoPteDyIRDZ0yGXuUG5p5f8Ct6belrQ 7G04pTVBDMsbnKEVaHVvQ5uARbUgYQsUZOE9c0NNFjn1Hgir+SSD9BrCOs2zU2EExSxr VG+w== 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:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=pVuRVqxiy/qGmUPLVsjTQxgaBPS5sTyLCRs/MnroZCA=; b=eELdlNRnElVsU6PhdbNppEq6yLCv8PXFuvbs1J3mxY7bmg8ovy7T0gNO1QDE6qq0i+ r0JQGCG46tNawN8/WT2DSGRGp1bW0oapC2QKpmQZz4ikD0elON8bubEkYcqT+QYK4U94 yvCA3gHEehYzwXuVspVC9eJbMXysa/j3M7NUFGhwT+im0s/e74gE8fKRP/SP+V28kqOh olt3gErw20R3JHQwzpuSUj0XDst76ysdcoJuWVRcXP1qARgCKXMPy0LFre4Kn/UERNBI qPAD4KweHEM1qYIxjZXmA6fqqI1u9izjcNPuAl/GOH6w7ugfViKGf4MMVoJGBsMW0l0x 5DKw== X-Gm-Message-State: AG10YORf7Y6tP/VkOA2rSlCd0xHZXhzxE9eqgTAJEfCTEfjfDSkyEGE0RqWJ4xKjM0npKw== X-Received: by 10.28.180.10 with SMTP id d10mr291576wmf.14.1452885873693; Fri, 15 Jan 2016 11:24:33 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id t9sm11882744wjf.33.2016.01.15.11.24.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 11:24:32 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> Date: Fri, 15 Jan 2016 21:24:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 19:24:37 -0000 > On 15 Jan 2016, at 3:55 PM, Valery Smyslov wrote: >=20 > Hi Yoav, >=20 >>>> What does IPsec community think of it? Should we fix the protocol >>>> to thwart this attack completely? Is the recommendation to move the = COOKIE to the end of the message enough to achive that? >>>> Will this change break many existing implementations? >>>=20 >>> As far as I can tell, the cookie hash algorithm is an implementation = decision >>> of the responder and (despite what's implied in the paper) is never = specified >>> in the protocol. It would be much simpler to add a section to the = new 4307bis >>> saying that this hash is security-critical, and recommending SHA-256 = or stronger. >>=20 >> The SLOTH paper does not depend at all on the hash used to break the = cookie. >> They use the cookie mechanism to inject a prefix (Because the = Initiator dutifully repeats >> the cookie that the MITM gave them) to control the hash of the entire = packet to create a collision. >> They also rely on neither Initiator nor responder checking cookie = lengths or even validating >> the cookies if a DoS attack is not underway. Maybe we should specify = that in the anti-ddos draft. >=20 > The initiator cannot validate the cookie - it is an opaque blob for = him. Should he reject > the cookie if its length is more than 64 bytes? Possibly. I don't = know. > It's a bit strange to check an opaque object=E2=80=A6 It=E2=80=99s an opaque object that the RFC says should be up to 64 = bytes. > What about the responder - he doesn't see any cookie in this attack - = the attacker > sends the crafted cookie only to the initiator and sends a crafted > IKE_SA_INIT message w/o cookie to the responder (as far as I = understand the attack). There is a cookie. See Figure 12 in Paul=E2=80=99s blog post: = https://securityblog.redhat.com/2016/01/13/the-sloth-attack-and-ikeipsec/ The responder accepts a cookie that it never sent. It doesn=E2=80=99t = check the cookie because there is, in fact, no DoS attack. That seems = wrong. Yoav From nobody Fri Jan 15 12:32:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE881B3238 for ; Fri, 15 Jan 2016 12:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 pvJxxZVGvnuo for ; Fri, 15 Jan 2016 12:32:34 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82CE81B3233 for ; Fri, 15 Jan 2016 12:32:34 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id c192so289936102lfe.2 for ; Fri, 15 Jan 2016 12:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=jmYhh/Gn9hFDbPyQGXUTkS2AeCTaQxbjJfvni9wmbFg=; b=aMbDSzBtORxNDWftnVrtaILesDTLDRtJoEB0+v7jdEjmMkGRLt/5OtCCVj9d2RSKQA bQCu0gON8ausQm7TKd6gzXmwKQooz4klt7Zr0nNjq9IzYlIhILx+B3E7bBZtq6Buo3o0 AfIsoq0hQTjwCyt2sa4KJI6g7Ar3+wCvArq9C5+DEd1GRhT2/zvKf/eV0mWjRFJJHZhi Q2yHtZTHdERDteYw5KdjJqjKnzds7YmN+zO87rk9lTFpSLFH5W9sEcw3r0U+fs6ZgyUe +jzDcSduRi4R4z20eJq4XCuqy/pFCd3JZ2dGGtqgYFNwYl07TsgyCeCH+F50jZHbRg3e sCTg== 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:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=jmYhh/Gn9hFDbPyQGXUTkS2AeCTaQxbjJfvni9wmbFg=; b=KLU22k5li5SHQHmfALwQq4GQTI360civdexiuPVRL2YL3WI/NnnSoZvyv1+s9ui73u JbqHVKBj3duq0b7lw+jJMrz9KKuFadkzrW70OqhCnCdobytATGRzfwpju7T0m7oTNAiQ G6UBI4iqkpR9hsFbYAupi83qheIfgQ5EpWG8eUTlQ+XdBRGWUIpIUfirX0rrFsqbBQ0s 6Q2j95CmJ/e7Jp3tuGaUoDe/bSVUBcVqwvluKHioHVLKwjpLiHVnN3zExNcffUeJO0hR eugNUIWAl5zaNtoTN4vRbGCnQd78TUQrXOiRp1+ldPnsMd1+Ese/F7pj6gl9SREA84ur 0wxA== X-Gm-Message-State: ALoCoQlsvBsmnodjWp8vynps8zwDajj3qb/FtcDTsnmQ3PRGq+Q9WjR+8dT7ugGAY/5uI1gSdyuXAjl/GZLV1AJtbw8ThNEo/w== X-Received: by 10.25.159.9 with SMTP id i9mr4219015lfe.109.1452889952815; Fri, 15 Jan 2016 12:32:32 -0800 (PST) Received: from chichi (ppp83-237-36-195.pppoe.mtu-net.ru. [83.237.36.195]) by smtp.gmail.com with ESMTPSA id ze8sm1538169lbb.45.2016.01.15.12.32.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 12:32:31 -0800 (PST) Message-ID: <152C04DCA92A4877B9079DFCAF8B936D@chichi> From: "Valery Smyslov" To: "Yoav Nir" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> In-Reply-To: <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> Date: Fri, 15 Jan 2016 23:32:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 20:32:37 -0000 >> The initiator cannot validate the cookie - it is an opaque blob for him. Should he reject >> the cookie if its length is more than 64 bytes? Possibly. I don't know. >> It's a bit strange to check an opaque object… > > It’s an opaque object that the RFC says should be up to 64 bytes. I know that. However it doesn make this check less strange for me. In my opinion this restriction is mostly for a responder, who generates a cookie. >> What about the responder - he doesn't see any cookie in this attack - the attacker >> sends the crafted cookie only to the initiator and sends a crafted >> IKE_SA_INIT message w/o cookie to the responder (as far as I understand the attack). > > There is a cookie. See Figure 12 in Paul’s blog post: > https://securityblog.redhat.com/2016/01/13/the-sloth-attack-and-ikeipsec/ Ah, you are right. I missed that in a quick read. After second read it seems to me that there is one more obstacle to that attack in real world. It seems that attacker appends original initiator's SAi, KEi, Ni payloads to its message sent to responder (as info`). So, this message would contain two SA payloads, two KE payloads etc. I believe the responder must return INVALID_SYNTAX in this case. > The responder accepts a cookie that it never sent. It doesn’t check the cookie because there is, in fact, no DoS > attack. That seems wrong. Agreed. The proper action would be to request another cookie. And in this case the attack would fail. > Yoav Regards, Valery. From nobody Fri Jan 15 13:07:37 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23891B3291 for ; Fri, 15 Jan 2016 13:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tMF3KIEDzi-X for ; Fri, 15 Jan 2016 13:07:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3968F1B3290 for ; Fri, 15 Jan 2016 13:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2920; q=dns/txt; s=iport; t=1452892054; x=1454101654; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h/n5CcBTbkyBPLxk+ABiTn9V0dNxh8y7TGHtgfaCWHk=; b=ZPelkt0+RJk5uGRS6gaG0J0QuOxMjx8niFNRtfyB98Q7y5hjDLUuvc+0 GZn0GkdtCGp+AN1+wVEek90Ex8CCTRPHhP/kvBsyp67xLDrSx1Go/YCyJ hWW8j9ziuRRt2/jJnufe5vF/Vz4sooixmYTaSPl0cd7Vc8acOJeBY+XIt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCYXplW/5tdJa1VCYM6Um0GiFCzL?= =?us-ascii?q?AENgWMYCoI9gzACgTk4FAEBAQEBAQGBCoQ0AQEBAwEBAQE3LQcLDAQCAQgRBAE?= =?us-ascii?q?BHwkHJwsUCQgCBAENBQiICwgOwSoBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZVh?= =?us-ascii?q?H+ELYUQBZcZAYg6hRyPCI5cASABAUKCDgMcgV1yhSiBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,301,1449532800"; d="scan'208";a="227865666" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2016 21:07:33 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0FL7Xkc017170 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2016 21:07:33 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 15 Jan 2016 16:07:32 -0500 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.1104.009; Fri, 15 Jan 2016 16:07:32 -0500 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters , Tero Kivinen Thread-Topic: [IPsec] SLOTH & IKEv2 Thread-Index: AQHRT6gHZf9oSvh9EUyXu2UKeEPWcZ79CnEQ Date: Fri, 15 Jan 2016 21:07:32 +0000 Message-ID: <57dd206d9e2b4cfbb3be68c16bb13e3c@XCH-RTP-006.cisco.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <22168.54258.15030.451398@fireball.acr.fi> 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.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 21:07:36 -0000 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters > Sent: Friday, January 15, 2016 10:18 AM > To: Tero Kivinen > Cc: ipsec@ietf.org WG > Subject: Re: [IPsec] SLOTH & IKEv2 >=20 >=20 > > Also this attack do require that the user use the groups with small > > subgroups, like groups 22-24 (and their previous paper the authors of > > this paper said that curve25519 has one small subgroup with size of 8, > > see page 9 of [1]) so they can make the g^xy' same as g^x'y by forcing > > both ends to use same small subgroup and trying so many times that the > > g^xy' and g^x'y happened to be same. If the size of subgroup is less > > than then there is good change that will happen with few tries. >=20 > I did not know curve25519 also has that problem :/ Actually, if you implement curve25519 as specified in irtf-cfrg-curves draf= t, you don't have that problem With that curve, each side selects private x, y values which are a multiple= of 8 (as specified in the irtf-cfrg-curves draft, see section 5) Because of that, if someone passes you an element of the size-8 subgoup, yo= u'll always generate the identity element (aka the netural element aka the = point at infinity) for that curve And, the draft requires you to check for that value (and reject it if it oc= curs); see section 6.1 The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with order dividing the co-factor, h, of the curve. This check is cheap and so MUST always be carried out. The check may be performed by ORing all the bytes together and checking whether the result is zero as this eliminates standard side-channels in software implementations. Hence, if Curve25519 is implemented as stated in the draft, the problem doe= sn't occur; if someone introduces such a low-order point, the connection wi= ll fail. >=20 > > I would recommend that we make sure our SPIs are unpredicatable and > > random instead of only being unique >=20 > See my above concern about an attacker depleting the entropy pool. >=20 > > , and that we always do small > > subgroup checks regardless whether we reuse the private Diffie-Hellman > > values or not for those groups that have small subgroups (22-24, > > curve25519). >=20 > We should, as NIST already requires it anyway. >=20 > I am curious though why people re-use DH values. Is that really still nee= ded > on busy servers? This has never been in freeswan, openswan or libreswan > and we have never heard people complain (and yes we do have big > deployment servers too, but not on shitty 1995 hardware :) >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jan 15 13:15:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95CC1B3293 for ; Fri, 15 Jan 2016 13:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 dMCb11I0eN5c for ; Fri, 15 Jan 2016 13:15:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1251B3292 for ; Fri, 15 Jan 2016 13:15:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3phwJV6Yrvz3Kc; Fri, 15 Jan 2016 22:15:06 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 g1VrXHMz0MKI; Fri, 15 Jan 2016 22:15:06 +0100 (CET) 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, 15 Jan 2016 22:15:05 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3973C6015373; Fri, 15 Jan 2016 16:15:04 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3973C6015373 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 37C751D46C; Fri, 15 Jan 2016 16:15:04 -0500 (EST) Date: Fri, 15 Jan 2016 16:15:04 -0500 (EST) From: Paul Wouters To: Yoav Nir In-Reply-To: <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> Message-ID: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> User-Agent: Alpine 2.20 (LFD 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 WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 21:15:10 -0000 On Fri, 15 Jan 2016, Yoav Nir wrote: >> The initiator cannot validate the cookie - it is an opaque blob for him. Should he reject >> the cookie if its length is more than 64 bytes? Possibly. I don't know. >> It's a bit strange to check an opaque object… > > It’s an opaque object that the RFC says should be up to 64 bytes. I tried to find a reference that the cookie is max 64 bytes and coul not find it. So I concluded the valid max is a regular Notify payload length specified in two octets, so 65535 bytes. I'm happy to be proven wrong :P > The responder accepts a cookie that it never sent. It doesn’t check the cookie because there is, in fact, no DoS attack. That seems wrong. As I also explain, it is probably motivated by supporting the server switching to "no longer need cookies" and clients coming with a cookie not getting denied. I agree that the server should still check any cookie it receives, or after a timer reject all connections with a (guaranteed false) cookie. But that would need to be an update to RFC 7296. Paul From nobody Fri Jan 15 13:21:16 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD851B32AB for ; Fri, 15 Jan 2016 13:21:15 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 y4xABwfb7AvB for ; Fri, 15 Jan 2016 13:21:13 -0800 (PST) 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 5A91F1B32A7 for ; Fri, 15 Jan 2016 13:21:13 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id b14so43510277wmb.1 for ; Fri, 15 Jan 2016 13:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=oW4rP5QZDuHjTfflgYid6te+ctIBjqV076mC/rzy8RQ=; b=xvpvfek/FSHaTW7EcYjAW1d3RuLbWVRhNz8L0GSXn2gDTnpvVezVjuwOzrPm0/MruY MSiC3HzPrzfLHTtljo2hNWpgQBZ6l8b2hSYV3dvD5oWavoeAUU0Z4AbUacDUofhDdOXt Jn9+fkI0IihMdF35xN06XTlzz4uV0TAPE1ArC9xEwCtXLMPOdkLJ7H3bOFcrJ+ZRwES7 Gm3ETzZ3SgSYnQyLZm0ZoW3frdl0GmKdBilcy+p9CPU5mdlmsx9APu8cJ2COaShvtj1v jJz+aoqaqmyk0S4DfYj31ld6Y63n6DmttGM36RvNsBgZ/rmPwSVwEljzLw/FsEI1mhZo Yfxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=oW4rP5QZDuHjTfflgYid6te+ctIBjqV076mC/rzy8RQ=; b=RIVjqzCyBuRwzqtd/h/M7T7efzJBqR7aU5VfU6Eu5DpmAEMqfDBKK98L53Sx5fhGeU XdeuHcjakx7W6jLlYT+thtXBjLYUq6TQnRHnSGdF+iPi6CM+nQIk6bqBGX2XUUMwQEAf ApeQFh1e2NTu1gBI3/katbRNybXR4znsgBl7eGhzFMXHwHnfwti5bvaC5H0J3pwxpjEi Eyi/AcIsGSVG1+h5ZoPMdAAxoXv7cFSmt9l8cOvpem5ety5d4PkBOvGTB3x0RwVjMOFl F2xOIRqgUK3aTyXIndpebMsh6Zep0S5RdoBktQAGN+mgdjDfF639dC2s1p4V3Md/lxVa DW7A== X-Gm-Message-State: AG10YOQvFjpRLrqaBnL7qjKfqi7IZOBzNTwqw2MJnVVm1GBi61gvvSSi2R4G5Gtmfwu+gg== X-Received: by 10.28.173.71 with SMTP id w68mr715746wme.88.1452892871731; Fri, 15 Jan 2016 13:21:11 -0800 (PST) Received: from [10.0.0.10] (bzq-109-65-180-184.red.bezeqint.net. [109.65.180.184]) by smtp.gmail.com with ESMTPSA id ei9sm12263750wjd.40.2016.01.15.13.21.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 13:21:10 -0800 (PST) To: Paul Wouters , Yoav Nir References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> From: Yaron Sheffer Message-ID: <569962C5.7070404@gmail.com> Date: Fri, 15 Jan 2016 23:21:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 21:21:15 -0000 Sec. 2.6: When a responder detects a large number of half-open IKE SAs, it SHOULD reply to IKE_SA_INIT requests with a response containing the COOKIE notification. The data associated with this notification MUST be between 1 and 64 octets in length (inclusive), and its generation is described later in this section. On 01/15/2016 11:15 PM, Paul Wouters wrote: > On Fri, 15 Jan 2016, Yoav Nir wrote: > >>> The initiator cannot validate the cookie - it is an opaque blob for >>> him. Should he reject >>> the cookie if its length is more than 64 bytes? Possibly. I don't know. >>> It's a bit strange to check an opaque object… >> >> It’s an opaque object that the RFC says should be up to 64 bytes. > > I tried to find a reference that the cookie is max 64 bytes and coul not > find it. So I concluded the valid max is a regular Notify payload length > specified in two octets, so 65535 bytes. I'm happy to be proven wrong :P > >> The responder accepts a cookie that it never sent. It doesn’t check >> the cookie because there is, in fact, no DoS attack. That seems wrong. > > As I also explain, it is probably motivated by supporting the server > switching to "no longer need cookies" and clients coming with a cookie > not getting denied. I agree that the server should still check any > cookie it receives, or after a timer reject all connections with > a (guaranteed false) cookie. But that would need to be an update to > RFC 7296. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jan 15 13:24:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1390D1B32AF for ; Fri, 15 Jan 2016 13:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.798 X-Spam-Level: ** X-Spam-Status: No, score=2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, FB_CIALIS_LEO3=3.899, RP_MATCHES_RCVD=-0.001] autolearn=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 NthwOBFp1RYz for ; Fri, 15 Jan 2016 13:24:13 -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 4B2411B32AE for ; Fri, 15 Jan 2016 13:24:13 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3phwVy5wZJz3Kd; Fri, 15 Jan 2016 22:24:10 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 fT3zuU0mGVcu; Fri, 15 Jan 2016 22:24:09 +0100 (CET) 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, 15 Jan 2016 22:24:09 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B397E6015373; Fri, 15 Jan 2016 16:24:08 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B397E6015373 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AFA1A1D46C; Fri, 15 Jan 2016 16:24:08 -0500 (EST) Date: Fri, 15 Jan 2016 16:24:08 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <569962C5.7070404@gmail.com> Message-ID: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <569962C5.7070404@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 21:24:14 -0000 On Fri, 15 Jan 2016, Yaron Sheffer wrote: > Sec. 2.6: When a responder detects a large number of half-open IKE SAs, it > SHOULD reply to IKE_SA_INIT requests with a response containing the COOKIE > notification. The data associated with this notification MUST be between 1 > and 64 octets in length (inclusive), and its generation is described later in > this section. Wow you are right. I searched multiple times and missed it. Clearly it should not have been thrown in as an afterthought for "When a responder detects a large number of ....". :( Okay, I'll update the blog post and our code :P Paul From nobody Fri Jan 15 13:37:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABA1B32BC for ; Fri, 15 Jan 2016 13:37:24 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 yth4w17QdR4i for ; Fri, 15 Jan 2016 13:37:23 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 D5CA11B32BB for ; Fri, 15 Jan 2016 13:37:22 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id f206so36286524wmf.0 for ; Fri, 15 Jan 2016 13:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EGzDqwUHqlUOedq0Rv5eSqWqS3KPdw2FRqSuJewxUdE=; b=Tvk+hT+jXje7V6XOgziY56Jw78WLkwN+rsmeucSl/FxXBQ+Dod77tlWviXCxNSkP1j ikF7hggJblDi74lU9XybJ5NnzHVKFK6DEdeoiF0gSnSu3ieSE48pqd+lk6OU11cJO+9k Q4SgrnXcBjtinektYRpr8qzSz6CRPMfZF7FnaGqdhDuldTEi+aLve1JemDpHJeNc/JIT lCQilPhbENc4bR2w04eIMVEPYA+xpvtU2bMCVApUAGihIeMf5Wy4VdZhtEH3tx8tZrkA kjA/BB2lURUOPgRvH9ggw2k3Uoh1ooCHHfFVEz4UhRzgEAl1ZTN/iub2UIWtnztZiKu2 /RqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=EGzDqwUHqlUOedq0Rv5eSqWqS3KPdw2FRqSuJewxUdE=; b=Kmj+wSiM0dX7Kbpv0NkBYP7pgqy+yGppsqSDb5EagW2dFHT9oo9DdRW0KJg4nZ0JXc SCLnj5m3JuWouYyAFiBzW95p9Va9c3op5djhYVfSWlhAlDWrSS6YYG0SRbj96FIysC6l 8Fj0lwDUXcDGBFgwwVxFYQpr1ZqUHbXWtcZkct+6gxVtGj0+2ihEWlVgDi6+5m4EDlbZ 4HHMjVSn0W6wDm5ilQiLBqv2grMbfctMtBl2pQ3HIgpetD5FRoYUFJpQzl9knnXw2GPc H2CXGdvXM5VLp8CuQeWKUqeBTz71hDnFKAqmD8bpFN/l/UKqauE0Z36bxpab5FijEY74 ywwA== X-Gm-Message-State: AG10YOQhiJkJzhtl05NqouQZceCVf+Nxs6kRhCLJzLdYIzMalSJdKmEoxavGa4PdTgiuhA== X-Received: by 10.28.5.16 with SMTP id 16mr726507wmf.71.1452893841485; Fri, 15 Jan 2016 13:37:21 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id q4sm12344364wja.6.2016.01.15.13.37.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 13:37:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Fri, 15 Jan 2016 23:37:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <512BC0AF-5452-4101-B135-12D8C01DE868@gmail.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 21:37:24 -0000 > On 15 Jan 2016, at 11:15 PM, Paul Wouters wrote: >=20 > On Fri, 15 Jan 2016, Yoav Nir wrote: >=20 >>> The initiator cannot validate the cookie - it is an opaque blob for = him. Should he reject >>> the cookie if its length is more than 64 bytes? Possibly. I don't = know. >>> It's a bit strange to check an opaque object=E2=80=A6 >>=20 >> It=E2=80=99s an opaque object that the RFC says should be up to 64 = bytes. >=20 > I tried to find a reference that the cookie is max 64 bytes and coul = not > find it. So I concluded the valid max is a regular Notify payload = length > specified in two octets, so 65535 bytes. I'm happy to be proven wrong = :P Section 2.6, top of page 33 in RFC 7296: When a responder detects a large number of half-open IKE SAs, it SHOULD reply to IKE_SA_INIT requests with a response containing the COOKIE notification. The data associated with this notification MUST be between 1 and 64 octets in length (inclusive), and its generation is described later in this section.=20 >=20 >> The responder accepts a cookie that it never sent. It doesn=E2=80=99t = check the cookie because there is, in fact, no DoS attack. That seems = wrong. >=20 > As I also explain, it is probably motivated by supporting the server > switching to "no longer need cookies" and clients coming with a cookie > not getting denied. I agree that the server should still check any > cookie it receives, or after a timer reject all connections with > a (guaranteed false) cookie. But that would need to be an update to > RFC 7296. We will be making this even more murky with puzzles. A cookie should be = seen again after about 1 RTT, but an initiator may take a while to = return a solved puzzle. How long do we set the timer for a solved = puzzle? Yoav From nobody Fri Jan 15 16:12:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209531B3437 for ; Fri, 15 Jan 2016 16:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 eKmA4HqtVfGl for ; Fri, 15 Jan 2016 16:12:40 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 C19571B341F for ; Fri, 15 Jan 2016 16:12:40 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 64FA959138282; Sat, 16 Jan 2016 00:12:37 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u0G0Cdmp028716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jan 2016 00:12:40 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u0G0CdYV022216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Jan 2016 00:12:39 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.17]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 15 Jan 2016 19:12:39 -0500 From: "HU, Jun (Jun)" To: Valery Smyslov , Yoav Nir Thread-Topic: [IPsec] SLOTH & IKEv2 Thread-Index: AQHRT3KO9XvF3CWa0UKj1UECSCCqV578oH6A///5hLCAAK+gAIAAEvqA///oj2A= Date: Sat, 16 Jan 2016 00:12:37 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE848550@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> In-Reply-To: <152C04DCA92A4877B9079DFCAF8B936D@chichi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 00:12:43 -0000 IA0KPiBBZnRlciBzZWNvbmQgcmVhZCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZXJlIGlzIG9uZSBt b3JlICBvYnN0YWNsZSB0bw0KPiB0aGF0IGF0dGFjayBpbiByZWFsIHdvcmxkLg0KPiBJdCBzZWVt cyB0aGF0IGF0dGFja2VyIGFwcGVuZHMgb3JpZ2luYWwgaW5pdGlhdG9yJ3MgU0FpLCBLRWksIE5p DQo+IHBheWxvYWRzIHRvIGl0cyBtZXNzYWdlIHNlbnQgdG8gcmVzcG9uZGVyIChhcyBpbmZvYCku IFNvLCB0aGlzIG1lc3NhZ2UNCj4gd291bGQgY29udGFpbiB0d28gU0EgcGF5bG9hZHMsIHR3byBL RSBwYXlsb2FkcyBldGMuIEkgYmVsaWV2ZSB0aGUNCj4gcmVzcG9uZGVyIG11c3QgcmV0dXJuIElO VkFMSURfU1lOVEFYIGluIHRoaXMgY2FzZS4NCg0KW0hKXSBhZ3JlZSwgaG93ZXZlciBJIGNhbid0 IGZpbmQgYW55IHRleHQgaW4gUkZDNzI5NiBzdGF0ZXMgcmVzcG9uZGVyIG5lZWQgdG8gcmVqZWN0 IHRoZSByZXF1ZXN0IGFuZCByZXR1cm4gSU5WQUxJRF9TWU5UQVggaW4gc3VjaCBjYXNlOyBhbiBp bXBsZW1lbnRhdGlvbiBtaWdodCBjaG9vc2UgdG8ganVzdCBzaW1wbHkgaWdub3JlIHRoZSBzdWJz ZXF1ZW50IHJlZHVuZGFudCBwYXlsb2FkIGFuZCBwcm9jZWVkLi4uDQo= From nobody Fri Jan 15 20:14:58 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242B71B3720 for ; Fri, 15 Jan 2016 20:14:57 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 bW-2as9lYWm7 for ; Fri, 15 Jan 2016 20:14:55 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 637D11B371F for ; Fri, 15 Jan 2016 20:14:55 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id l65so42281554wmf.1 for ; Fri, 15 Jan 2016 20:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vM24zBy2A85XLd1Hny3QdknSPmITKDhlVatLpxRerQo=; b=ds3VBu1S02P09BHKlNfakPJmJ74apnMxqOU4sCWj5CQZgoGoKDDlI2cdU6m0wUr6Ft aLXJFB+zq8jd2ZHHIQDb9OeRs1LVZ78FyKvtI89wbIDGDyAJyz1+Q95GvTnMKhAstgyU 4VHHWIUTjAGbU/DYbjGGsRrsN+wL6ZHFN7lk327D/ZQtZW/LBoZUxlPa4S7VkD6for4a RXCPoJ7pzJe3aliU5EnWhSZT+vYRsPrdAgobgi196JlPAje8BsbHGsbDy8QvamSTHNE4 y24jalz5GYN0JxefYRFa3d8Xc+n5SDF1SSe7MBDnbDEDi/0CqCVcj8zt4YKzhoNrWdAL /ECg== 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:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vM24zBy2A85XLd1Hny3QdknSPmITKDhlVatLpxRerQo=; b=P3iP9t1Enb1wRSVU4MB6H6CU0pGMcgCtjq0L7r7wt6rqlhA6mKk73XkIbPN8GvPlqw Ms/DqVYaQlKxKu+Fx3e4KWq9V9+LwYctaKa3mOil8Bml06ZgLwUPkmtUXCWM52anJyeT zIV/vnms6622Jh4DzTrB7rIfqz6YgOCIY9JrSpUie1Wu9J1y/NISzwSglV+ZCWClckhi Jsgwn42Y971dDF/9ux07+m7LJhaZiukIzYSCj9g4fvNOcj+7TSWbIag95+sTFhuMSiIi rUc/JQ2ytfWtYEFhFO82fpr/O47Z0/l7lmQvIETU6OFMXKof945E9PU4AKSdtVgrgHdO EVbA== X-Gm-Message-State: AG10YORiwZZC84+8Ndc+FpHKr503WnoP/eulE0LwZftLfhEi9ykb1HD1DZ9faiQaaSRxXA== X-Received: by 10.28.232.208 with SMTP id f77mr2020789wmi.34.1452917694063; Fri, 15 Jan 2016 20:14:54 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id c203sm5200952wmd.5.2016.01.15.20.14.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 20:14:52 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <152C04DCA92A4877B9079DFCAF8B936D@chichi> Date: Sat, 16 Jan 2016 06:14:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> To: Valery Smyslov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 04:14:57 -0000 > On 15 Jan 2016, at 10:32 PM, Valery Smyslov wrote: >=20 >=20 >>> What about the responder - he doesn't see any cookie in this attack = - the attacker >>> sends the crafted cookie only to the initiator and sends a crafted >>> IKE_SA_INIT message w/o cookie to the responder (as far as I = understand the attack). >>=20 >> There is a cookie. See Figure 12 in Paul=E2=80=99s blog post: >> = https://securityblog.redhat.com/2016/01/13/the-sloth-attack-and-ikeipsec/ >=20 > Ah, you are right. I missed that in a quick read. >=20 > After second read it seems to me that there is one more obstacle to = that attack in real world. > It seems that attacker appends original initiator's SAi, KEi, Ni = payloads to its > message sent to responder (as info`). So, this message would contain = two SA payloads, > two KE payloads etc. I believe the responder must return = INVALID_SYNTAX in this case. IIUC there are no two SA payloads and two KE payloads. All of those are = part of the =E2=80=9Ccookie=E2=80=9D sent to the real Responder. That is = why it=E2=80=99s so large.= From nobody Fri Jan 15 21:17:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76BB1B37C7 for ; Fri, 15 Jan 2016 21:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 ZApT7IRu3uhf for ; Fri, 15 Jan 2016 21:17:18 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 2D3FE1B37CB for ; Fri, 15 Jan 2016 21:17:18 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id A1C139954AD7F; Sat, 16 Jan 2016 05:17:16 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u0G5HGIb027611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jan 2016 05:17:17 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u0G5HGUO017064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Jan 2016 05:17:16 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.17]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Sat, 16 Jan 2016 00:17:16 -0500 From: "HU, Jun (Jun)" To: EXT Yoav Nir , Valery Smyslov Thread-Topic: [IPsec] SLOTH & IKEv2 Thread-Index: AQHRT3KO9XvF3CWa0UKj1UECSCCqV578oH6A///5hLCAAK+gAIAAEvqAgACBMwD//7lHkA== Date: Sat, 16 Jan 2016 05:17:15 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 05:17:21 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSVBzZWMgW21haWx0bzpp cHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRVhUIFlvYXYgTmlyDQo+IFNlbnQ6 IEZyaWRheSwgSmFudWFyeSAxNSwgMjAxNiA4OjE1IFBNDQo+IFRvOiBWYWxlcnkgU215c2xvdg0K PiBDYzogaXBzZWNAaWV0Zi5vcmc7IFBhdWwgV291dGVyczsgU2NvdHQgRmx1aHJlciAoc2ZsdWhy ZXIpDQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIFNMT1RIICYgSUtFdjINCj4gDQo+IA0KPiA+IE9u IDE1IEphbiAyMDE2LCBhdCAxMDozMiBQTSwgVmFsZXJ5IFNteXNsb3YgPHN2YW5ydUBnbWFpbC5j b20+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4+IFdoYXQgYWJvdXQgdGhlIHJlc3BvbmRlciAtIGhl IGRvZXNuJ3Qgc2VlIGFueSBjb29raWUgaW4gdGhpcyBhdHRhY2sNCj4gPj4+IC0gdGhlIGF0dGFj a2VyIHNlbmRzIHRoZSBjcmFmdGVkIGNvb2tpZSBvbmx5IHRvIHRoZSBpbml0aWF0b3IgYW5kDQo+ ID4+PiBzZW5kcyBhIGNyYWZ0ZWQgSUtFX1NBX0lOSVQgbWVzc2FnZSB3L28gY29va2llIHRvIHRo ZSByZXNwb25kZXIgKGFzDQo+IGZhciBhcyBJIHVuZGVyc3RhbmQgdGhlIGF0dGFjaykuDQo+ID4+ DQo+ID4+IFRoZXJlIGlzIGEgY29va2llLiBTZWUgRmlndXJlIDEyIGluIFBhdWzigJlzIGJsb2cg cG9zdDoNCj4gPj4gaHR0cHM6Ly9zZWN1cml0eWJsb2cucmVkaGF0LmNvbS8yMDE2LzAxLzEzL3Ro ZS1zbG90aC1hdHRhY2stYW5kLWlrZWlwDQo+ID4+IHNlYy8NCj4gPg0KPiA+IEFoLCB5b3UgYXJl IHJpZ2h0LiBJIG1pc3NlZCB0aGF0IGluIGEgcXVpY2sgcmVhZC4NCj4gPg0KPiA+IEFmdGVyIHNl Y29uZCByZWFkIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgaXMgb25lIG1vcmUgIG9ic3RhY2xl IHRvDQo+IHRoYXQgYXR0YWNrIGluIHJlYWwgd29ybGQuDQo+ID4gSXQgc2VlbXMgdGhhdCBhdHRh Y2tlciBhcHBlbmRzIG9yaWdpbmFsIGluaXRpYXRvcidzIFNBaSwgS0VpLCBOaQ0KPiA+IHBheWxv YWRzIHRvIGl0cyBtZXNzYWdlIHNlbnQgdG8gcmVzcG9uZGVyIChhcyBpbmZvYCkuIFNvLCB0aGlz IG1lc3NhZ2UNCj4gPiB3b3VsZCBjb250YWluIHR3byBTQSBwYXlsb2FkcywgdHdvIEtFIHBheWxv YWRzIGV0Yy4gSSBiZWxpZXZlIHRoZQ0KPiByZXNwb25kZXIgbXVzdCByZXR1cm4gSU5WQUxJRF9T WU5UQVggaW4gdGhpcyBjYXNlLg0KPiANCj4gSUlVQyB0aGVyZSBhcmUgbm8gdHdvIFNBIHBheWxv YWRzIGFuZCB0d28gS0UgcGF5bG9hZHMuIEFsbCBvZiB0aG9zZSBhcmUNCj4gcGFydCBvZiB0aGUg 4oCcY29va2ll4oCdIHNlbnQgdG8gdGhlIHJlYWwgUmVzcG9uZGVyLiBUaGF0IGlzIHdoeSBpdOKA mXMgc28NCj4gbGFyZ2UuDQoNCltISl0gYWNjb3JkaW5nIHRvIHRoaXMgZmlndXJlKGh0dHBzOi8v c2VjdXJpdHlibG9nLnJlZGhhdC5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTYvMDEvc2xvdGgt aWtlLTIucG5nKToNClRoZSBJS0VfSU5JVCByZXF1ZXN0KG0xJykgc2VuZCB0byByZWFsIHJlc3Bv bmRlciBjb250YWluIGluZm9pJyBhdCB0aGUgZW5kLCB3aGljaCBlcXVhbHM9U0FpfGdeeHxOaXxp bmZvaSwgc28gdGhlIGFjdHVhbCBtMSc9SERSfEMyfFNBaSd8Z154J3xuaXxTQWl8Z154fG5pfGlu Zm9pOyB0aHVzIHR3byBTQSwgdHcgS0UsIHR3byBOaSBwYXlsb2FkczsgQzIgaXMgdGhlIGNvb2tp ZSBwYXlsb2FkIGluIG0xJywgaXQgZG9lc24ndCBjb250YWluIGFueSBwYXlsb2FkLiB3aGlsZSB0 aGUgY29va2llIHBheWxvYWQgaW4gbTEoSUtFX0lOSVQgcmVxdWVzdCBmcm9tIHJlbGVhc2UgaW5p dGlhdG9yKSBkb2VzIGNvbnRhaW4gQzF8U0FpJ3xnXngnfG5pDQoNCg0KDQoNCg0KDQo= From nobody Fri Jan 15 22:02:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFA31A0041 for ; Fri, 15 Jan 2016 22:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 6OUWlxe9_ixE for ; Fri, 15 Jan 2016 22:02:49 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA02A1A0040 for ; Fri, 15 Jan 2016 22:02:48 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id 17so92168735lfz.1 for ; Fri, 15 Jan 2016 22:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=T8QKnzRtcrF2MdkNlpr0RvjgPAUEuYIr9Po0H+N86eA=; b=uh05F6N/zV7LmIJRiVei3tZgcasREapgq3zP8P0cvGkdLwYQxVpRiM3YL4egA4b3RK muPog6/rwrOIZl+Vwu1ZYrezsXqhR/ipHYYnrRnDeWFDMWkey/850hUXvObUCp15KGSR /4Z1klNdnLpEB4NJOaejH2sfvR6fxvchpAxZK9kjOxz3WZHAlBvPDqMGo8rqhDCOhhUv BMTnaqhnYaXZFfZQrNmkLkjgRXM5KI0reUtXJt/8C1DY5+BcJpb/9KC/h1xbUaYrIsfw R7OVTld5vB+BEFWrR0fMnxof4mtDfVtXgc7ZeoAoSAroCaUCEqWQCp32JxHCVZP2syQ+ mxJw== 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:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=T8QKnzRtcrF2MdkNlpr0RvjgPAUEuYIr9Po0H+N86eA=; b=VfFsCQWt3HUkxxUYZoGCOYNZXM3YGjYZjbg+pwaf8CA6qbUbsR2BPUFYDe+L/shETf 17UGN+j2zb5SQBqnUR7bWJ9/bKzlUppAokgdq0ONr7llA5ZpdTlU+3FCn4KESEhYrZnK 0ljKaM1/5xtSDRaUd+6vsI5H5yXLZMryxfm/cDX2oOMaoeyHHcYza3NEOG7AWmYyrBOf AMCcbqTduqiJ9OuowIy+fsJmgWUMqW6DeNbo5pgY07c24yXwBGmZpRvpZYLr7gbZ+ah5 BZ1zx8cFb6yoadairkWl3m1TL3sAg9HOW9DuqPGXdUqdd091xr6NGPiy/6SSxIs0+J5B hCKg== X-Gm-Message-State: ALoCoQmgpocJwKlb/DFoM7pu+2g/lyjA8PCfguGHsKtX7Z9HQTXfQI/d8njcpWV7v6M4WTbH+9TpjcDRzPmJHyPNTKpxSZh6Zg== X-Received: by 10.25.25.142 with SMTP id 136mr4818873lfz.42.1452924166898; Fri, 15 Jan 2016 22:02:46 -0800 (PST) Received: from chichi (ppp83-237-36-195.pppoe.mtu-net.ru. [83.237.36.195]) by smtp.gmail.com with ESMTPSA id k3sm1728668lbp.9.2016.01.15.22.02.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 22:02:45 -0800 (PST) Message-ID: <0A9EB289609F46F49EF33501105FA878@chichi> From: "Valery Smyslov" To: "HU, Jun \(Jun\)" , "Yoav Nir" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE848550@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BE848550@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sat, 16 Jan 2016 09:02:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 06:02:50 -0000 Hi, >> After second read it seems to me that there is one more obstacle to >> that attack in real world. >> It seems that attacker appends original initiator's SAi, KEi, Ni >> payloads to its message sent to responder (as info`). So, this message >> would contain two SA payloads, two KE payloads etc. I believe the >> responder must return INVALID_SYNTAX in this case. > >[HJ] agree, however I can't find any text in RFC7296 states responder need > to reject the request and return INVALID_SYNTAX in such case; an implementation > might choose to just simply ignore the subsequent redundant payload and proceed... Sure, there is no such text in the RFC. However this requirement is implicit, since the pictures in the Appendix C.1 show those payloads that may appear multiple times in the messages as PLD+. It is assumed that those payloads that don't have the plus sign must appear only once (or not appear at all). And if an implementation chooses to ignore the redundant payload, then there is a question - which payload is redundant? There is no requirements in the RFC that payloads come in a specific order, so one implementation may think that the first payload is actual and the subsequent is redundant, while the other may think otherwise. So I think INVALID syntax is the only proper response here. Regards, Valery. From nobody Fri Jan 15 23:16:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D9D1A0387 for ; Fri, 15 Jan 2016 23:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 VyeJWdTlFaeF for ; Fri, 15 Jan 2016 23:16:19 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 61E0C1A037F for ; Fri, 15 Jan 2016 23:16:17 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 564A9F5F8DA5C; Sat, 16 Jan 2016 07:16:16 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u0G7GGdN028824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jan 2016 07:16:16 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u0G7GGOx021368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Jan 2016 07:16:16 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.17]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sat, 16 Jan 2016 02:16:16 -0500 From: "HU, Jun (Jun)" To: EXT Valery Smyslov , "HU, Jun (Jun)" , Yoav Nir Thread-Topic: [IPsec] SLOTH & IKEv2 Thread-Index: AQHRT3KO9XvF3CWa0UKj1UECSCCqV578oH6A///5hLCAAK+gAIAAEvqA///oj2CAALbCAP//wAEg Date: Sat, 16 Jan 2016 07:16:14 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE848B80@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE848550@US70UWXCHMBA05.zam.alcatel-lucent.com> <0A9EB289609F46F49EF33501105FA878@chichi> In-Reply-To: <0A9EB289609F46F49EF33501105FA878@chichi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 07:16:20 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRVhUIFZhbGVyeSBTbXlz bG92IFttYWlsdG86c3ZhbnJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE1 LCAyMDE2IDEwOjAzIFBNDQoNCltISl0gDQo+IFRvOiBIVSwgSnVuIChKdW4pOyBZb2F2IE5pcg0K PiBDYzogaXBzZWNAaWV0Zi5vcmc7IFBhdWwgV291dGVyczsgU2NvdHQgRmx1aHJlciAoc2ZsdWhy ZXIpDQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIFNMT1RIICYgSUtFdjINCj4gDQoNCj4gPltISl0g YWdyZWUsIGhvd2V2ZXIgSSBjYW4ndCBmaW5kIGFueSB0ZXh0IGluIFJGQzcyOTYgc3RhdGVzIHJl c3BvbmRlcg0KPiA+bmVlZCAgdG8gcmVqZWN0IHRoZSByZXF1ZXN0IGFuZCByZXR1cm4gSU5WQUxJ RF9TWU5UQVggaW4gc3VjaCBjYXNlOyBhbg0KPiA+aW1wbGVtZW50YXRpb24gIG1pZ2h0IGNob29z ZSB0byBqdXN0IHNpbXBseSBpZ25vcmUgdGhlIHN1YnNlcXVlbnQNCj4gcmVkdW5kYW50IHBheWxv YWQgYW5kIHByb2NlZWQuLi4NCj4gDQo+IFN1cmUsIHRoZXJlIGlzIG5vIHN1Y2ggdGV4dCBpbiB0 aGUgUkZDLiBIb3dldmVyIHRoaXMgcmVxdWlyZW1lbnQgaXMNCj4gaW1wbGljaXQsIHNpbmNlIHRo ZSBwaWN0dXJlcyBpbiB0aGUgQXBwZW5kaXggQy4xIHNob3cgdGhvc2UgcGF5bG9hZHMNCj4gdGhh dCBtYXkgYXBwZWFyIG11bHRpcGxlIHRpbWVzIGluIHRoZSBtZXNzYWdlcyBhcyBQTEQrLiBJdCBp cyBhc3N1bWVkDQo+IHRoYXQgdGhvc2UgcGF5bG9hZHMgdGhhdCBkb24ndCBoYXZlIHRoZSBwbHVz IHNpZ24gbXVzdCBhcHBlYXIgb25seSBvbmNlDQo+IChvciBub3QgYXBwZWFyIGF0IGFsbCkuDQo+ IA0KPiBBbmQgaWYgYW4gaW1wbGVtZW50YXRpb24gY2hvb3NlcyB0byBpZ25vcmUgdGhlIHJlZHVu ZGFudCBwYXlsb2FkLCB0aGVuDQo+IHRoZXJlIGlzIGEgIHF1ZXN0aW9uIC0gd2hpY2ggcGF5bG9h ZCBpcyByZWR1bmRhbnQ/IFRoZXJlIGlzIG5vDQo+IHJlcXVpcmVtZW50cyBpbiB0aGUgUkZDIHRo YXQgcGF5bG9hZHMgY29tZSBpbiBhIHNwZWNpZmljIG9yZGVyLCBzbyBvbmUNCj4gaW1wbGVtZW50 YXRpb24gbWF5IHRoaW5rIHRoYXQgdGhlIGZpcnN0IHBheWxvYWQgaXMgYWN0dWFsIGFuZCB0aGUN Cj4gc3Vic2VxdWVudCBpcyByZWR1bmRhbnQsIHdoaWxlIHRoZSBvdGhlciBtYXkgdGhpbmsgb3Ro ZXJ3aXNlLg0KPiANCj4gU28gSSB0aGluayBJTlZBTElEIHN5bnRheCBpcyB0aGUgb25seSBwcm9w ZXIgcmVzcG9uc2UgaGVyZS4NCg0KDQpbSEpdIEkgYWdyZWUgdGhhdCBzZW5kaW5nIElOVkFMSURf U1lOVEFYIGlzIHRoZSByaWdodCBiZWhhdmlvciwganVzdCB3aXNoIHRoZSBSRkMgY291bGQgYmUg bW9yZSBjbGVhciBhYm91dCBpdC4NCg== From nobody Sat Jan 16 00:55:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E931A1B85 for ; Sat, 16 Jan 2016 00:55:33 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 FqBWWM2LhcR3 for ; Sat, 16 Jan 2016 00:55:31 -0800 (PST) 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 C22AD1A1B72 for ; Sat, 16 Jan 2016 00:55:30 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f206so48866004wmf.0 for ; Sat, 16 Jan 2016 00:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nbhNggoUzpSQ+5DzGo0wgGFMtZAJg3OgaMedEChnixo=; b=gRu1WASSrCkxePajOKtxDtH9CZzWpXf6DcfSYawQ5xuASvqi8lrUU7oG86jT7ytFDo HxfNi0gE2DyfL1yWREZPraZE7z4FM4+5KyuB/6ABrCt7QCZqB51KSipTAQSufDWh6yw5 OwKG8JtH8MOOfG0j6yKsDmTlypH+ZLHGJX+cOyQ2xyCaWC768q/eUodd9KC8sOUxT8Yl 1dSUm4sTZCkQc/IosZ6iUsnOBl3VrCjBBhNY6QUqXa02gfPDQfX3y0DnA4w36cCR5Eea gbw5oABB5vP2NQhojq6pab16lAnClsbFxaaXWeqgn8mpVoFSpSwnh8ZmLNOKCKpg/H1m lwbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nbhNggoUzpSQ+5DzGo0wgGFMtZAJg3OgaMedEChnixo=; b=FSQ7kGXIGPTjrQOH1JmAaVnXG67qq08xhYRabhtEomcFGkOSFhusOCNwy+awuqGjt+ J9Wl+5FpE7FdYWlgW7uKynON572aCms77zrSRSTyEwG6X8gZCh+3RhAPA++BpNPpUUE3 769ulw03m53f/8mTLGh+5sN7QPwTYanIf6KXVJTeMMOl56zSioe4KLdww5HB/7iDzi6w IkbVViNXcWrZOgpCZ+yRVALzhaGohnprsB9N2LsvpdCLTEXyCIJhow7oU+w8F8TSerPN 5DbKlGi4ziZDQ8bHa7t6SDOZqv4Q5RnZ94sLdRkG9ZJ6qad58ToxKFQhjRYIGo+ykqpv C2aw== X-Gm-Message-State: ALoCoQk4Vm+Kb/80hV5UgFVdyfbrc1kiCdovdqjkcfMkzp5W5EKKwxdOskpGdmVZP3I0iDhHgrE679Pw0PDO4TDToviX2FwMjQ== X-Received: by 10.194.175.233 with SMTP id cd9mr14491680wjc.115.1452934529417; Sat, 16 Jan 2016 00:55:29 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id uo9sm14056182wjc.49.2016.01.16.00.55.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 16 Jan 2016 00:55:28 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sat, 16 Jan 2016 10:55:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "HU, Jun (Jun)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 08:55:33 -0000 > On 16 Jan 2016, at 7:17 AM, HU, Jun (Jun) wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of EXT Yoav Nir >> Sent: Friday, January 15, 2016 8:15 PM >> To: Valery Smyslov >> Cc: ipsec@ietf.org; Paul Wouters; Scott Fluhrer (sfluhrer) >> Subject: Re: [IPsec] SLOTH & IKEv2 >>=20 >>=20 >>> On 15 Jan 2016, at 10:32 PM, Valery Smyslov = wrote: >>>=20 >>>=20 >>>>> What about the responder - he doesn't see any cookie in this = attack >>>>> - the attacker sends the crafted cookie only to the initiator and >>>>> sends a crafted IKE_SA_INIT message w/o cookie to the responder = (as >> far as I understand the attack). >>>>=20 >>>> There is a cookie. See Figure 12 in Paul=E2=80=99s blog post: >>>> = https://securityblog.redhat.com/2016/01/13/the-sloth-attack-and-ikeip >>>> sec/ >>>=20 >>> Ah, you are right. I missed that in a quick read. >>>=20 >>> After second read it seems to me that there is one more obstacle to >> that attack in real world. >>> It seems that attacker appends original initiator's SAi, KEi, Ni >>> payloads to its message sent to responder (as info`). So, this = message >>> would contain two SA payloads, two KE payloads etc. I believe the >> responder must return INVALID_SYNTAX in this case. >>=20 >> IIUC there are no two SA payloads and two KE payloads. All of those = are >> part of the =E2=80=9Ccookie=E2=80=9D sent to the real Responder. That = is why it=E2=80=99s so >> large. >=20 > [HJ] according to this = figure(https://securityblog.redhat.com/wp-content/uploads/2016/01/sloth-ik= e-2.png): > The IKE_INIT request(m1') send to real responder contain infoi' at the = end, which equals=3DSAi|g^x|Ni|infoi, so the actual = m1'=3DHDR|C2|SAi'|g^x'|ni|SAi|g^x|ni|infoi; thus two SA, tw KE, two Ni = payloads; C2 is the cookie payload in m1', it doesn't contain any = payload. while the cookie payload in m1(IKE_INIT request from release = initiator) does contain C1|SAi'|g^x=E2=80=99|ni OK, but if those extra payloads are disguised as some notification = (there is no payload actually called =E2=80=9Cinfo=E2=80=9D), then = responders do tend to ignore notifications they don=E2=80=99t recognize.=20= Yoav From nobody Sat Jan 16 01:58:58 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4C1A6EE2 for ; Sat, 16 Jan 2016 01:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 Jqjkay8C2qzA for ; Sat, 16 Jan 2016 01:58:55 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 4BBD21A6EDC for ; Sat, 16 Jan 2016 01:58:55 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id c192so296044431lfe.2 for ; Sat, 16 Jan 2016 01:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=faCBez5CqwwuQ6+b19Hrkda9bUjYDvMWk4i7xB7phxw=; b=OcuWeMNJBcNwdzq4k5VROfCl95gqn1ErgbnTSGGqmFhrKF8G0j/RaaRhN7mea4i+/D JOmFG1OmqJmL4lWvhEGlgqTrok0PHwYTW0gWrP8O4KZsHl/0hrTwl5iRPoI8tfOVbFmz e8ZcLyMAh+2hAfaFcWxTAmjY8i/KScvBmXsqo77+kr/jXOB56SSJ8O173ziPcEltGaNV 9G2O0pi/EBJXEf7vjYObPd+EvchhX58Ajee+0A7g42rjy0YoBpYPNukrHaPqRzOD2iE1 rOUwkewlCJYePZ6/3fSDrToFeeDlZHqh4/4V31hdIsqcnpDiwxo/bzZuRfxO8I75NUD0 a2Sg== 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:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=faCBez5CqwwuQ6+b19Hrkda9bUjYDvMWk4i7xB7phxw=; b=dci66+hPooWhe9R7Lfaw3rxP8N7vr++GM8LqoaDzS1xNsxRscgmbNwNrpPQh8mS7a2 VdnFZmEMjpuNKO+0koNneVs4ucDQrbW+fGQ9o4d5z9xu/bhOTDUIp1ugXAthhSQr/8VG KEKgZZrV1vx5ri+0VldEFVdGOvvaGNMjqsTPK62VlWm+0xa0/zsuxhFQvbsnBvY463f2 BtnDaT0Z9p6AxhqzjkuNj8BwET0iHjWo+a4pEthW6IkWfLWgeSF4zGXF7SJhMmNgiaj9 TcWsnCSurxwlfTNdWtgg7gleN5BZlLMTzqJeS2maDdv7geqb78gxxiqenEqVc2iaCaCQ YzJA== X-Gm-Message-State: ALoCoQmvO08QmPsF4SOVqunqE9gM+uPO3PXK1rFnJDfchQ/hEh/YZYrKl8tHoEMQHrw2AgksIYnhwpVkSkDmI1j/39/KsVwMcQ== X-Received: by 10.25.17.89 with SMTP id g86mr4132047lfi.82.1452938333613; Sat, 16 Jan 2016 01:58:53 -0800 (PST) Received: from chichi (ppp83-237-47-197.pppoe.mtu-net.ru. [83.237.47.197]) by smtp.gmail.com with ESMTPSA id l129sm1844400lfl.37.2016.01.16.01.58.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 01:58:52 -0800 (PST) Message-ID: <5466883E332F47EDBADBE162157A6DE2@chichi> From: "Valery Smyslov" To: "Yoav Nir" , "HU, Jun \(Jun\)" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> In-Reply-To: <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> Date: Sat, 16 Jan 2016 12:58:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 09:58:56 -0000 >> [HJ] according to this figure(https://securityblog.redhat.com/wp-content/uploads/2016/01/sloth-ike-2.png): >> The IKE_INIT request(m1') send to real responder contain infoi' at the end, which equals=SAi|g^x|Ni|infoi, >> so the actual m1'=HDR|C2|SAi'|g^x'|ni|SAi|g^x|ni|infoi; thus two SA, tw KE, two Ni payloads; C2 is the cookie >> payload in m1', it doesn't contain any payload. while the cookie payload in m1(IKE_INIT request from release >> initiator) does contain C1|SAi'|g^x’|ni > > OK, but if those extra payloads are disguised as some notification (there is no payload actually called “infoâ€), > then responders do tend to ignore notifications they don’t recognize. True, but in this case the inputs to the hash function will be different (you need to insert Notification payload header in the m`), so the attack will fail. > Yoav Regards, Valery. From nobody Sat Jan 16 02:21:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CDF1A6F77 for ; Sat, 16 Jan 2016 02:21: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 f4lXdW-ArHOJ for ; Sat, 16 Jan 2016 02:21:04 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3441A6F6D for ; Sat, 16 Jan 2016 02:21:03 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id x4so70126264lbm.0 for ; Sat, 16 Jan 2016 02:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=R0K3mxgs1u18ZbTFTCt0IX9JdSmokIQNbpFUo3PpZEI=; b=kZMR5e+fWiTeaXJuPrshco/aOhb+2bMBiuuA39veOUAgqNq2dcspkmGGAtethLw0Ry Lo3TgxZGt5HtRb1UC01gSJthy63F3j3e9tzjVTGQuuGhcfapedbL/stVcO59qzIWCTgc lG3hx94dbHD1ZOyOalFmTZyvzLMEfsEuGUdneXSX6hAyi/P8R9+ZbZijU6I96rHQD/yi PxEVG2xF0aCS7q6FJIUdAbtNd99qOeq+4qmNT57cVYCitsQvc3H/Bjyp45z0D1QFm5Nm pVStQafCvAUVRSvvBoh31D6IocssMB3VYXZxJH+9eokIXwMCvlhEpsZc0DI6EO5C7ihf pJBg== 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:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=R0K3mxgs1u18ZbTFTCt0IX9JdSmokIQNbpFUo3PpZEI=; b=MnLNkq+gwM8VKXibIiujYp9N15zbYvX8aMsbNYqwcdBl0myIQgLSeBkU1DmvmFw20z UQSEujEeGHSN9Y5Z0ZZOfqkO/z7xlvWxoDLUhcMYVP4xjb7yyOx3E58LWETeSwgd1CFa HXP1HKnvJzpmVEHOCx5hBVzhAByczDXMAMFrZdtpfX39HobJqjDlKB139J3/Y2NanYpr nqY6KPW9Df8HpI9iNRmIV+SETtKbvy+ZJUTsgu1M2J3lpzPBgCUCEKO+JVW2Xyh7mjf2 Osjn+YmZ1hQ2/tm5IRYPH8yLyr/BOuTvk4+mL6K1rlFqcHioLkaKVe2kr+s7jtirj9tA vJqQ== X-Gm-Message-State: ALoCoQl0DFzJjy6XMFNGl6koetMUSGarWgtPzDJpi0KFoOOlEdZHyKVHnW+DB4XVPsq+UjFLvtj3xfAWXFEDnAN0EyTcTNiVXQ== X-Received: by 10.112.211.136 with SMTP id nc8mr4883235lbc.54.1452939662161; Sat, 16 Jan 2016 02:21:02 -0800 (PST) Received: from chichi (ppp83-237-47-197.pppoe.mtu-net.ru. [83.237.47.197]) by smtp.gmail.com with ESMTPSA id jm8sm1846951lbc.12.2016.01.16.02.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 02:21:01 -0800 (PST) Message-ID: <052BF605919C45F38015AC6F49CF56B3@chichi> From: "Valery Smyslov" To: "Yoav Nir" , "HU, Jun \(Jun\)" References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> In-Reply-To: <5466883E332F47EDBADBE162157A6DE2@chichi> Date: Sat, 16 Jan 2016 13:20:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 10:21:05 -0000 >> OK, but if those extra payloads are disguised as some notification (there is no payload actually called “infoâ€), >> then responders do tend to ignore notifications they don’t recognize. > > True, but in this case the inputs to the hash function will be different (you need to insert Notification > payload header in the m`), so the attack will fail. I must correct myself - if attacker takes care and puts the Notify payload header at the end of ck it sends to initiator (and he must correctly guess the length of info`), then it will work - all the original payloads from the initiator will appear inside Notification payload and will be ignored by responder. Regards, Valery. From jun.hu@nokia.com Fri Jan 15 15:48:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7D1B33EA for ; Fri, 15 Jan 2016 15:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 C1YAdxXyGTln for ; Fri, 15 Jan 2016 15:48:16 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 C7A161B33E7 for ; Fri, 15 Jan 2016 15:48:16 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 4235A9B9D0D8A; Fri, 15 Jan 2016 23:48:13 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u0FNmE12006940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jan 2016 23:48:14 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u0FNmECb031898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Jan 2016 23:48:14 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.17]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 15 Jan 2016 18:48:14 -0500 From: "HU, Jun (Jun)" To: Valery Smyslov , Yoav Nir Thread-Topic: [IPsec] SLOTH & IKEv2 Thread-Index: AQHRT3KO9XvF3CWa0UKj1UECSCCqV578oH6A///5hLCAAK+gAIAAEvqA///fzwA= Date: Fri, 15 Jan 2016 23:48:12 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE8483DD@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> In-Reply-To: <152C04DCA92A4877B9079DFCAF8B936D@chichi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 16 Jan 2016 08:08:39 -0800 Cc: "ipsec@ietf.org" , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 23:50:04 -0000 PiBBZnRlciBzZWNvbmQgcmVhZCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZXJlIGlzIG9uZSBtb3Jl ICBvYnN0YWNsZSB0bw0KPiB0aGF0IGF0dGFjayBpbiByZWFsIHdvcmxkLg0KPiBJdCBzZWVtcyB0 aGF0IGF0dGFja2VyIGFwcGVuZHMgb3JpZ2luYWwgaW5pdGlhdG9yJ3MgU0FpLCBLRWksIE5pDQo+ IHBheWxvYWRzIHRvIGl0cyBtZXNzYWdlIHNlbnQgdG8gcmVzcG9uZGVyIChhcyBpbmZvYCkuIFNv LCB0aGlzIG1lc3NhZ2UNCj4gd291bGQgY29udGFpbiB0d28gU0EgcGF5bG9hZHMsIHR3byBLRSBw YXlsb2FkcyBldGMuIEkgYmVsaWV2ZSB0aGUNCj4gcmVzcG9uZGVyIG11c3QgcmV0dXJuIElOVkFM SURfU1lOVEFYIGluIHRoaXMgY2FzZS4NCg0KW0hKXSBhZ3JlZSwgaG93ZXZlciBJIGNhbid0IGZp bmQgYW55IHRleHQgaW4gUkZDNzI5NiBzdGF0ZXMgcmVzcG9uZGVyIG5lZWQgdG8gcmVqZWN0IHRo ZSByZXF1ZXN0IGFuZCByZXR1cm4gSU5WQUxJRF9TWU5UQVggaW4gc3VjaCBjYXNlOyBhbiBpbXBs ZW1lbnRhdGlvbiBtaWdodCBjaG9vc2UgdG8ganVzdCBzaW1wbHkgaWdub3JlIHRoZSBzdWJzZXF1 ZW50IHJlZHVuZGFudCBwYXlsb2FkIGFuZCBwcm9jZWVkLi4uDQo= From nobody Sat Jan 16 08:45:03 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5391A8A7B for ; Sat, 16 Jan 2016 08:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 sgutdMKxp0eE for ; Sat, 16 Jan 2016 08:45:00 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7A01A8AA5 for ; Sat, 16 Jan 2016 08:44:59 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id BC305B2695CD5; Sat, 16 Jan 2016 16:44:55 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u0GGiwSW011837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jan 2016 16:44:58 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u0GGirXH019306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Jan 2016 16:44:53 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.17]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sat, 16 Jan 2016 11:44:53 -0500 From: "HU, Jun (Jun)" To: EXT Valery Smyslov , Yoav Nir , "HU, Jun (Jun)" Thread-Topic: [IPsec] SLOTH & IKEv2 Thread-Index: AQHRT3KO9XvF3CWa0UKj1UECSCCqV578oH6A///5hLCAAK+gAIAAEvqAgACBMwD//7lHkIAAlR8AgAARsICAAAYxAIAAE9oQ Date: Sat, 16 Jan 2016 16:44:54 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> In-Reply-To: <052BF605919C45F38015AC6F49CF56B3@chichi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 16:45:03 -0000 PiA+PiBPSywgYnV0IGlmIHRob3NlIGV4dHJhIHBheWxvYWRzIGFyZSBkaXNndWlzZWQgYXMgc29t ZSBub3RpZmljYXRpb24NCj4gPj4gKHRoZXJlIGlzIG5vIHBheWxvYWQgYWN0dWFsbHkgY2FsbGVk IOKAnGluZm/igJ0pLCB0aGVuIHJlc3BvbmRlcnMgZG8gdGVuZA0KPiB0byBpZ25vcmUgbm90aWZp Y2F0aW9ucyB0aGV5IGRvbuKAmXQgcmVjb2duaXplLg0KPiA+DQo+ID4gVHJ1ZSwgYnV0IGluIHRo aXMgY2FzZSB0aGUgaW5wdXRzIHRvIHRoZSBoYXNoIGZ1bmN0aW9uIHdpbGwgYmUNCj4gPiBkaWZm ZXJlbnQgKHlvdSBuZWVkIHRvIGluc2VydCBOb3RpZmljYXRpb24gcGF5bG9hZCBoZWFkZXIgaW4g dGhlIG1gKSwNCj4gc28gdGhlIGF0dGFjayB3aWxsIGZhaWwuDQo+IA0KPiBJIG11c3QgY29ycmVj dCBteXNlbGYgLSBpZiBhdHRhY2tlciB0YWtlcyBjYXJlIGFuZCBwdXRzIHRoZSBOb3RpZnkNCj4g cGF5bG9hZCBoZWFkZXIgYXQgdGhlIGVuZCBvZiBjayBpdCBzZW5kcyB0byBpbml0aWF0b3IgKGFu ZCBoZSBtdXN0DQo+IGNvcnJlY3RseSBndWVzcyB0aGUgbGVuZ3RoIG9mIGluZm9gKSwgdGhlbiBp dCB3aWxsIHdvcmsgLSBhbGwgdGhlDQo+IG9yaWdpbmFsIHBheWxvYWRzIGZyb20gdGhlIGluaXRp YXRvciB3aWxsIGFwcGVhciBpbnNpZGUgTm90aWZpY2F0aW9uDQo+IHBheWxvYWQgYW5kIHdpbGwg YmUgaWdub3JlZCBieSByZXNwb25kZXIuDQo+IA0KDQpbSEpdIGhvdyB3b3VsZCB0aGlzIHdvcms/ IGV2ZW4gYXR0YWNrIGFwcGVuZCBhIG5vdGlmaWNhdGlvbiBoZWFkZXIgaW4gY2ssIGFuZCByZXR1 cm4gYSBjaz0gQzF8U0FpJ3xnXngnfG5pfCBub3RpZnlfaGVhZGVyLCB0aGVuIG0xKGZyb20gcmVh bCBpbml0aWF0b3IpPUhEUnwoQzF8U0FpJ3xnXngnfG5pfCBub3RpZnlfaGVhZGVyKV9hc19ja3xT QWl8Z154fG5pfG5hdC10LCBub3RpZnkgaGVhZGVyIGlzIHBhcnQgb2YgY2ssIHdvbid0IGJlIHBh cnNlZCBhcyBhY3R1YWwgbm90aWZ5IHBheWxvYWQgaGVhZGVyLg0K From nobody Sun Jan 17 00:32:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E271D1A1B63 for ; Sun, 17 Jan 2016 00:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 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, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 SgHGZrfCgK6L for ; Sun, 17 Jan 2016 00:32:25 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A001A1AE3 for ; Sun, 17 Jan 2016 00:32:24 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id cl12so115885786lbc.1 for ; Sun, 17 Jan 2016 00:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=i+VqBuTgCdfLS06OXkkRirOS73ZUXplOqkRVHP9Sg/4=; b=OsrgADKRAjCFXMkaXcmgb3GEGVwifTn/EFRHfrXMVTvzowFGCUWWFgnZwTcDwPUhcV V0oLUN0pU6oy6YaZDSEV7RsHrdsTJaBNWbVNIU4pL4b0vJAgM2dqE11g6zjNeJ546U4v xs8VydnCtwdueDwttDOP0vlIpKkldHziwR+94jf5PcEzjkVRajWWgqZEmoGNaihjBHBG Z/u9TSjoexqxV4pYRtB6MpuPNFA8j8Sw2Zih3rQx1d7gMrVf3ucKfv+UeqtBedozLHAA 61LQa8kygVTZlU7BZit2Kne3BTIFmzWyXt6/OOS5nk7AIc24ur1lGqunEbln6TqlouEN ZMOQ== 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:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=i+VqBuTgCdfLS06OXkkRirOS73ZUXplOqkRVHP9Sg/4=; b=HQ0Zm0H79bYYhxkvnmx4psrEumf/Rifl/23v0QKCVwl6cpYh+5iDOy1ug3UCPsedF1 dFRnrOaHD1xrL/fFDUnCkWDZSewKId/dcFklriGFKH/IBG08pyWG7td2wZCvEgA4+PyI IP/TQUPCY1r//KiQEWwPA+nTz5d0Jxh8PVeWVuztMHGXWk5XrtJNAaBvVHmdMmfgeCbr WUSo/mpUwWhPMqJMvgvNzP3/X8c8gzlq/wia4jHa1ocfF2FXDuJEFPaoItIi9HKg38RE V0qURAWHYz4IFBD8Mpfo55yDIzazlNAlQ9elp3G25Jn8oecCvvan5jpbZvsI2yV1SnwP 9eeQ== X-Gm-Message-State: ALoCoQnKcJGSyPlambKIGthbWeYtfFNV5pAUn1yRdiq4uOcjWV0L//KbYesT912hpPEhp/iyvoMdcd/KKmwE8oOSt19HvyHSjA== X-Received: by 10.112.35.162 with SMTP id i2mr6112591lbj.107.1453019542763; Sun, 17 Jan 2016 00:32:22 -0800 (PST) Received: from chichi (ppp83-237-47-197.pppoe.mtu-net.ru. [83.237.47.197]) by smtp.gmail.com with ESMTPSA id th4sm2322383lbb.46.2016.01.17.00.32.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jan 2016 00:32:22 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" , "HU, Jun \(Jun\)" References: <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sun, 17 Jan 2016 11:32:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 08:32:26 -0000 >> I must correct myself - if attacker takes care and puts the Notify >> payload header at the end of ck it sends to initiator (and he must >> correctly guess the length of info`), then it will work - all the >> original payloads from the initiator will appear inside Notification >> payload and will be ignored by responder. >> > > [HJ] how would this work? even attack append a notification header in ck, > and return a ck= C1|SAi'|g^x'|ni| notify_header, then > m1(from real initiator)=HDR|(C1|SAi'|g^x'|ni| notify_header)_as_ck|SAi|g^x|ni|nat-t, > notify header is part of ck, won't be parsed as actual notify payload header. Yes, but when the attacker sends a message to the responder it replaces ck with C2 and the message will look like mi'=HDR | ck'=C2 | SAi' | g^xi' | ni' | notify_header | SAi | g^xi | ni | info_i If the length indicated in the notify_header will be equal to the length of SAi | g^xi | ni | info_i, then the responder will treat these payloads as a notify payload content and will ignore them. So, for the responder the message will look like: mi'=HDR | cookie | SA | KE | NONCE | Nx where Nx is some unknown notification. From nobody Sun Jan 17 15:18:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5171A90FE for ; Sun, 17 Jan 2016 15:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 YkCcHShFazDp for ; Sun, 17 Jan 2016 15:18:13 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 785561A90FC for ; Sun, 17 Jan 2016 15:18:13 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id DB4E29072C42B; Sun, 17 Jan 2016 23:18:07 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u0HNIAHi004761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 17 Jan 2016 23:18:10 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u0HNI9P3014710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Jan 2016 23:18:09 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.17]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sun, 17 Jan 2016 18:18:09 -0500 From: "HU, Jun (Jun)" To: EXT Valery Smyslov , Yoav Nir , "HU, Jun (Jun)" Thread-Topic: [IPsec] SLOTH & IKEv2 Thread-Index: AQHRT3KO9XvF3CWa0UKj1UECSCCqV578oH6A///5hLCAAK+gAIAAEvqAgACBMwD//7lHkIAAlR8AgAARsICAAAYxAIAAE9oQgAFgJICAAIyZMA== Date: Sun, 17 Jan 2016 23:18:08 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 23:18:15 -0000 >=20 > Yes, but when the attacker sends a message to the responder it replaces > ck with C2 and the message will look like >=20 > mi'=3DHDR | ck'=3DC2 | SAi' | g^xi' | ni' | notify_header | SAi | g^xi | = ni > | info_i >=20 > If the length indicated in the notify_header will be equal to the length > of SAi | g^xi | ni | info_i, then the responder will treat these > payloads as a notify payload content and will ignore them. > So, for the responder the message will look like: >=20 > mi'=3DHDR | cookie | SA | KE | NONCE | Nx >=20 > where Nx is some unknown notification. [HJ] yes, you are right. So to summary what has been discussed previous in = this thread: On Initiator side: - This attack is impractical if the initiator's SPIi is unpredictable, si= nce it is infeasible for attacker to compute C1/C2 offline for all possible= SPIi. And it is impossible to compute C1/C2 online before client switch to= a different SPIi. - On responder side: - if responder is expecting a cookie, then the C2 won't match the expectin= g cookie, responder will return the expecting cookie, this attack won't wor= k in this case. - if responder is not expecting a cookie, then it could still verify the c= ookie to prevent this attack. One of the checks could be done is a legit co= okie length must be <=3D64B. =20 From nobody Sun Jan 17 22:50:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEF21B2B43 for ; Sun, 17 Jan 2016 22:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 Ytq2_l76ekBM for ; Sun, 17 Jan 2016 22:50:37 -0800 (PST) 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 BA2F01B2B3D for ; Sun, 17 Jan 2016 22:50:36 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id m198so166004596lfm.0 for ; Sun, 17 Jan 2016 22:50:36 -0800 (PST) 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-type:content-transfer-encoding; bh=kYZ0r8XpVhnnz+fLBrcrfkbYhV6Q6ier4ywCKX/8Y+k=; b=hktbYgX+0WzAwNOyy+TLXq7DpdpXpsiObBoOZ5yJK9cAX6Zr7s3Rt+kipLAq8ZCsQz iUy9OZHk//QOgL+z4w8vEi/ksxnrHAiz446YlU0wWgYDU/UpJwToHEy25g702asF3YZX BdLgTKfWtXjAnvxitL7Tk4ulXBj2tFV2TRHDIaxnuQN7cJ67oxZp7sCMoTqekNbk9LfZ ClWcqgmJYqGEp4rwoOxK3fQkMXgjoNHf0BPt3g5sXug+C3Zan6HZa5VpeXBvmMAlo6aK 60A/FWEPlMSiyfVVxNioacEV3sGPXLmn5Ncq1QgCvnkBWg5238vom/DDmehIWapsIsrr iJDA== 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-type:content-transfer-encoding; bh=kYZ0r8XpVhnnz+fLBrcrfkbYhV6Q6ier4ywCKX/8Y+k=; b=GgQPp5jGRuIokfW2OukGgtXucpEg7zrPBfymzjSsuRCObstdtvWhZB6Q95C6RtUpje OZvOxPyhy+Baz02g3gbt5BICOR9XkoQA2XwrxWZAFpA+YZKR9ohRei8ut6IT7HiASkyP KJDmtgHOZ6sogEP1h2jwlhQaPEacIsJraWujx9MBvMveR/0WAsRqbSdISgRZsAqS0iaG ixA1DHVhLe3ELcUdGcDMeblbaTHLoyEeODiWjxyotp88Al0bYF/Qw1j/V64lUh0T5MQ6 pC+PNoSGkT8+SJ6K1i0P5kaeJ413P17KLubV8VzoePObHCdkQ42xfVu/GIi1N/ngjIAz p3ow== X-Gm-Message-State: ALoCoQny+HTmCNvLtAOSvzv94J1nrOjsOoElGebjpULsCBJC3K/QG4vpCUaIEH1z46yx/MqEZCcRA3On1blCKhHcv+YVKPsRNQ== X-Received: by 10.25.170.129 with SMTP id t123mr7760396lfe.103.1453099834954; Sun, 17 Jan 2016 22:50:34 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g16sm3027649lfe.0.2016.01.17.22.50.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jan 2016 22:50:34 -0800 (PST) Message-ID: <430470C9BE384F68B78D8931F70D9ED0@buildpc> From: "Valery Smyslov" To: "HU, Jun \(Jun\)" , "Yoav Nir" References: <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Mon, 18 Jan 2016 09:50:39 +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 , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 06:50:38 -0000 > [HJ]So to summary what has been discussed previous in this thread: > On Initiator side: - This attack is impractical if the initiator's SPIi is unpredictable, since it is infeasible > for attacker to compute C1/C2 offline for all possible SPIi. And it is impossible > to compute C1/C2 online before client switch to a different SPIi. > > - On responder side: > - if responder is expecting a cookie, then the C2 won't match the expecting cookie, > responder will return the expecting cookie, this attack won't work in this case. > - if responder is not expecting a cookie, then it could still verify the cookie to prevent this attack. > One of the checks could be done is a legit cookie length must be <=64B. I think that responder must verify the cookie if it is present, regardless on whether it is expected to be present or not. And it must request another cookie if the verification failed. Regards, Valery. From nobody Mon Jan 18 07:05:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1651B3818 for ; Mon, 18 Jan 2016 07:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 t585yhtl64aS for ; Mon, 18 Jan 2016 07:05:11 -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 B55531B37FE for ; Mon, 18 Jan 2016 07:05:11 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pkbyD6VyKz3Yc; Mon, 18 Jan 2016 16:05:08 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 TW4vwz7y3lRh; Mon, 18 Jan 2016 16:05:03 +0100 (CET) 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, 18 Jan 2016 16:05:03 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DD0BA6015373; Mon, 18 Jan 2016 10:05:01 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca DD0BA6015373 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DB3421392CA; Mon, 18 Jan 2016 10:05:01 -0500 (EST) Date: Mon, 18 Jan 2016 10:05:01 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <430470C9BE384F68B78D8931F70D9ED0@buildpc> Message-ID: References: <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> <430470C9BE384F68B78D8931F70D9ED0@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:05:13 -0000 On Mon, 18 Jan 2016, Valery Smyslov wrote: > I think that responder must verify the cookie if it is present, regardless > on whether it is expected to be present or not. And it must request > another cookie if the verification failed. That would allow an initiator to trigger the cookie generating mechanism on the responder on demand. I don't think that's a good idea. I do agree the cookie if received must validate against the "current" or "last secret before we disabled cookies". If not, I think that's a good reason to not even answer the request - it's clearly malicious. I don't think it should request a new cookie. Paul From nobody Mon Jan 18 07:29:02 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E561B383F for ; Mon, 18 Jan 2016 07:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 B2b7SSE21lxi for ; Mon, 18 Jan 2016 07:28:59 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 677651B3819 for ; Mon, 18 Jan 2016 07:28:59 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id bc4so347696391lbc.2 for ; Mon, 18 Jan 2016 07:28:59 -0800 (PST) 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-type:content-transfer-encoding; bh=R9E9TSk002lvkurLE35NgkQtSSdBhA9BH4sR8+KEoLo=; b=pAXzMWGHM0bA4HTa5nh6q0zZ4HacIAJ5iVc2GsNO8VDvcIAY5AtJJe9BlelCOQsBwb BHL9e56lu4trcYcr1NEtqMNLNtC4Pzv8zvemaTuyAD6BkFoefuqiE/lsMoejThmCs6We 4sbo9j9oIdeG9fftPV3X62NMcC52mj9X5lLw6VqpQe4DHft+iU/pOJh8h2dfMELrqk0u 8oqfo7b1Z181DzpGPjfXcyl/0rCAE8JM51iJmUbrzKZGOfZXGBSYV81723/hPDt4uep5 dItMzbH4mnz7IMvT+xB7I7IzVB1Rk1nGlN0jNAN8iEeL+EtTubrny0u36jVk6MrqrY2C JDfA== 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-type:content-transfer-encoding; bh=R9E9TSk002lvkurLE35NgkQtSSdBhA9BH4sR8+KEoLo=; b=dPeXtOxFFnMuCbCFuW5+rvVkQfKji48VdlUw0jFSKnk2Ia5b8RvFtOt4HuLnd1ZVuM Ej6JvEDkElpvaAvnZQl55q0JzfGkXZT8p1pzB4bDK9xU2KKbXJSt29NCNrhH8qli2bRX JoDd/N752LyujNtsSDo4tN5uggvoNW7B7YvWqZ9Ua8LgmhCBvmiQatkg/5tJhx7WgSGn y1p0n2Jw+JbgFFo0odmMocBjl810PrM7nkoxP4lDMgJr+Ied0hvn93Qf+PRYVlfAim4D i8KW/nUYO4giZB5BK9yBzj169r5xCh0USTZX6dD6PwfH4dsG/ZPL/G/sfNvzbtppwlpO mlXA== X-Gm-Message-State: AG10YORMsOWJt624dSRjIYHl/A2mWfMwD770+5Zqmf+CR9VpGZ9CntLFoP/tAf9J1SYHzQ== X-Received: by 10.112.134.130 with SMTP id pk2mr2966370lbb.103.1453130937521; Mon, 18 Jan 2016 07:28:57 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id rp10sm3253266lbb.13.2016.01.18.07.28.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 07:28:56 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> <430470C9BE384F68B78D8931F70D9ED0@buildpc> Date: Mon, 18 Jan 2016 18:28:57 +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 Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:29:00 -0000 >> I think that responder must verify the cookie if it is present, regardless >> on whether it is expected to be present or not. And it must request >> another cookie if the verification failed. > > That would allow an initiator to trigger the cookie generating mechanism > on the responder on demand. I don't think that's a good idea. And what then? I think the cookie generating mechanism is a local matter and you have all means to make it secure. From nobody Mon Jan 18 07:48:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5891B38C1 for ; Mon, 18 Jan 2016 07:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 PrhIEPGHAY-q for ; Mon, 18 Jan 2016 07:48:13 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C4D1B38BA for ; Mon, 18 Jan 2016 07:48:13 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pkcvt5Qscz3mw; Mon, 18 Jan 2016 16:48:10 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 APj_4kJrirHN; Mon, 18 Jan 2016 16:48:09 +0100 (CET) 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, 18 Jan 2016 16:48:08 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 963F26015373; Mon, 18 Jan 2016 10:48:07 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 963F26015373 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 94CF21D46D; Mon, 18 Jan 2016 10:48:07 -0500 (EST) Date: Mon, 18 Jan 2016 10:48:07 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> <430470C9BE384F68B78D8931F70D9ED0@buildpc> User-Agent: Alpine 2.20 (LFD 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] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:48:13 -0000 On Mon, 18 Jan 2016, Valery Smyslov wrote: >> That would allow an initiator to trigger the cookie generating mechanism >> on the responder on demand. I don't think that's a good idea. > > And what then? I think the cookie generating mechanism is a local > matter and you have all means to make it secure. Sure, but why give attackers a chance at all? Paul From nobody Mon Jan 18 23:01:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AC41ACCDA for ; Mon, 18 Jan 2016 23:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 pH9H1Sv0m8wm for ; Mon, 18 Jan 2016 23:01:30 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0181ACC86 for ; Mon, 18 Jan 2016 23:01:29 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id h129so137936073lfh.3 for ; Mon, 18 Jan 2016 23:01:29 -0800 (PST) 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-type:content-transfer-encoding; bh=zRfoAiLHm6COWgp3HisOdqGgSUqrFts4CxsMh8n2T2U=; b=e5yE5tWKN0Saft4MMqgblaQ4gRmAF0lg+HXVZA2slReKGzifqExIIS7MJbYrXEjpm2 dTw+3HVy8jttK6YXS1nHBWL52cd/nnkCORocFuqoXWvfIzw6HMiq2e9qDtuKTmf/17y8 Zq2CXy4MIwQOFO7ezRB8mSZNxKE4kd2azK4H/phlVQhtzKPrI7HoPtaUlP49fWiICI/D 6OAfxkfAkOUcPtfN4EopU7Ou3XXQdqDUtjY9et/luJ8jK+HSK5NBHY47kWS5IHFlmthi mWqrn58qWyTaiSn1yuxJ0g6K/IlbQOGl5+f0DXokkPYYOHfaD7xARFI9swCzlnOrE3mx AhPw== 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-type:content-transfer-encoding; bh=zRfoAiLHm6COWgp3HisOdqGgSUqrFts4CxsMh8n2T2U=; b=lTcNn85nRp9S+rK8c9xyDugH1BE3pcJEZmF9IWNJYERBaoCuNObELFkNm7V8DYwVaj ibqZI7/HWomg93UhOAAEmjClMsrookSz6xGVN0L07KzU0fkcvlJXFfauIOJzwG5M3KT7 /G6KXw9aCyKsAA1YkqosNzays3V2IPj/HDRWlYsd2oC932BuP6P4Xij3+3Lnr+6Vzo1D MTZUfp/EElUJV0k1onf+G7J6odN6y7r2jiV9BMhxLuVsdKtfCAEwrjuqOfN99KZMu6E/ BPsTfT5XBU0X1p+yS5WELzb1ynMQ/OUYyBp82eduLl8Q49BXlFRDqKvfELyDsnVKhmH8 VPXQ== X-Gm-Message-State: ALoCoQmEGTJP7FS3hzrFHfzneH46PPZ6Qp5P2WRjgQDC2nlSMexkd4YkG4CF26RI4PDM+z6Yl8VceczAPh9MLqltOQ+DRwsP0Q== X-Received: by 10.25.207.3 with SMTP id f3mr10416799lfg.20.1453186888027; Mon, 18 Jan 2016 23:01:28 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n185sm3591929lfd.27.2016.01.18.23.01.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 23:01:27 -0800 (PST) Message-ID: <0EC8271DD42441EB906675E32181AC18@buildpc> From: "Valery Smyslov" To: "HU, Jun \(Jun\)" , "Yoav Nir" References: <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Tue, 19 Jan 2016 10:01:27 +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 , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 07:01:31 -0000 Hi, few more thoughts on this attack. > [HJ] yes, you are right. So to summary what has been discussed previous in this thread: > On Initiator side: > - This attack is impractical if the initiator's SPIi is unpredictable, since it is infeasible > for attacker to compute C1/C2 offline for all possible SPIi. And it is impossible > to compute C1/C2 online before client switch to a different SPIi. > > - On responder side: > - if responder is expecting a cookie, then the C2 won't match the expecting cookie, > responder will return the expecting cookie, this attack won't work in this case. > - if responder is not expecting a cookie, then it could still verify the cookie to prevent this attack. > One of the checks could be done is a legit cookie length must be <=64B. While all these checks on responder side are useful, they cannot really prevent this attack. The attack can be easily modified so that the message sent from the attacker to the responder looks unsuspicious. All that attacker need to do is to find C1 and C2 so, that the COOKIE notification type in C1 is changed to any unused status notification type in C2. It is just a little bit harder than the current version of attack. However after that the message sent from the attacker to the responder will look like: M' = HDR | Nx=C2 | SAi' | KEi' | NONCEi' | Ny=(SAi | KEi | NONCEi | info_i) So the responder will see two unknown status notifications (Nx and Ny) and will just ignore them. Nothing suspicious. So the only real defense against this attack is an unpredictability of SPIi. Is it enough? I don't know. I would feel more comfortable if initiator puts the cookie at the end of the message, thus making this attack infeasible: HDR, SAi1, KEi, Ni --> <-- HDR, N(COOKIE) HDR, SAi1, KEi, Ni, N(COOKIE) --> Note that this doesn't violate RFC 7296, since the payloads may come in any order. However it may break some existing implementations... Regards, Valery. From nobody Tue Jan 19 07:23:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337761B3064 for ; Tue, 19 Jan 2016 07:23:19 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EKqgN9UQVmz2 for ; Tue, 19 Jan 2016 07:23:17 -0800 (PST) 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 67EDC1B3060 for ; Tue, 19 Jan 2016 07:23:17 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B259C200A5 for ; Tue, 19 Jan 2016 10:31:15 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 06B2A637A0 for ; Tue, 19 Jan 2016 10:23:16 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <0EC8271DD42441EB906675E32181AC18@buildpc> References: <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> <0EC8271DD42441EB906675E32181A C18@buildpc> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 15:23:19 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > So the only real defense against this attack is an unpredictability of SPIi. > Is it enough? I don't know. I would feel more comfortable if initiator > puts the cookie at the end of the message, thus making this attack > infeasible: > HDR, SAi1, KEi, Ni --> > <-- HDR, N(COOKIE) > HDR, SAi1, KEi, Ni, N(COOKIE) --> > Note that this doesn't violate RFC 7296, since the payloads may come > in any order. However it may break some existing implementations... It seems like good advice. Perhaps this is worth a IKE 2.1 value --- an initiator that says 2.1 is saying that it will always put the COOKIE last. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVp5U4YCLcPvd0N1lAQIxHAf/RkxN6uTPUsPgze5vaBAZZKRnRswYszrR sFwgh3TlpdBazIvzjichuGh7sXS1CMKVw03vqGptnVVBzoElZ05lTLwC3SicI2JK i3zbB1qQBsn5F9Td+RD2HQcfAB1G/IUYlcUL7Wta64YRyMGr67LS1ntejg/rkgeW PxMj9waqq7yR1RjLSE8w9/l7juKM1W5DZciAqM4A0zixTcsNPOax5gNElKQduI5B xQaQsZU1Xx240pTSjoJBXVLnmMP8xtjfeGWM3KepgAtEuz8Im25wGk1rhxUxq5V1 xhvIBm4v/1cjiurScwbxOLQtDtmCV53N8WGfQXN2uDFPSEFCvT9Cig== =s3Ih -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 19 08:26:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0C1B31E2 for ; Tue, 19 Jan 2016 08:26:15 -0800 (PST) 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 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 e-KK8VtFZdxa for ; Tue, 19 Jan 2016 08:26:13 -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 9FBA61B31DF for ; Tue, 19 Jan 2016 08:25:56 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0JGPjtO016231 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 18:25:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0JGPjRd023981; Tue, 19 Jan 2016 18:25:45 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22174.25480.999566.412598@fireball.acr.fi> Date: Tue, 19 Jan 2016 18:25:44 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <0EC8271DD42441EB906675E32181AC18@buildpc> References: <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <5698B410.5030809@gmail.com> <1E5F92AB1C1E4E3D87AC5FFD47BB03F0@buildpc> <67FAD982-8FAE-49B3-A494-7543EE83B043@gmail.com> <152C04DCA92A4877B9079DFCAF8B936D@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE84894E@US70UWXCHMBA05.zam.alcatel-lucent.com> <52B940D5-9BD7-4EBB-A41A-79A8762433C5@gmail.com> <5466883E332F47EDBADBE162157A6DE2@chichi> <052BF605919C45F38015AC6F49CF56B3@chichi> <876523B00C3F9D47BFD2B654D63DBF92BE849187@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE84A7EF@US70UWXCHMBA05.zam.alcatel-lucent.com> <0EC8271DD42441EB906675E32181AC18@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 12 min Archived-At: Cc: ipsec@ietf.org, "HU, Jun \(Jun\)" , Paul Wouters , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:26:15 -0000 Valery Smyslov writes: > While all these checks on responder side are useful, they cannot > really prevent this attack. Actually it does. > The attack can be easily modified so that the message sent from the > attacker to the responder looks unsuspicious. All that attacker need > to do is to find C1 and C2 so, that the COOKIE notification type in > C1 is changed to any unused status notification type in C2. It is > just a little bit harder than the current version of attack. However > after that the message sent from the attacker to the responder will > look like: > > M' = HDR | Nx=C2 | SAi' | KEi' | NONCEi' | Ny=(SAi | KEi | NONCEi | info_i) Attacker cannot do that, as attacker will not be able to get original initiator to reflect the Nx=C1 back in the m1. Cookies notifications are used because are required from the initiator to be copied from the original SA_INIT reply to the retry SA_INIT request. For that unknown notification that would not work, i.e. when the attacker sends back the SA_INIT(ck=|C1|SA',gx'|ni|) the initiator will ignore the first notification if it not cookie, and will not retry with message sending cookie notification. > So the responder will see two unknown status notifications (Nx and Ny) > and will just ignore them. Nothing suspicious. If the attacker changes the m1' to contain some other notification in the beginning that cookie notification he needs to find different type of collison where the prefix is no longer constant, i.e., he needs to modify that. > So the only real defense against this attack is an unpredictability > of SPIi. And checking the small subgroups in Diffie-Hellman, i.e., not using groups 22-24. > Is it enough? I don't know. I would feel more comfortable if initiator > puts the cookie at the end of the message, thus making this attack > infeasible: > > HDR, SAi1, KEi, Ni --> > <-- HDR, N(COOKIE) > HDR, SAi1, KEi, Ni, N(COOKIE) --> > > Note that this doesn't violate RFC 7296, since the payloads may come > in any order. However it may break some existing implementations... I think using random SPIis is enough. Even if you SPI only contained 2^32 different values, that means that attacker needs to do expensive precalculations for each of those different values, making the cost of attack 2^32 times harder. -- kivinen@iki.fi From nobody Tue Jan 19 09:48:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010251B339D for ; Tue, 19 Jan 2016 09:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 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, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 Pr4oW6On78FK for ; Tue, 19 Jan 2016 09:48:14 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 657DF1B3399 for ; Tue, 19 Jan 2016 09:48:14 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id bc4so366997690lbc.2 for ; Tue, 19 Jan 2016 09:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=41kyj0COItm75WaOj5e4Nw/yvjuXhFDrCGVC8hCPdUQ=; b=arOQ9dZlMmV7vIvujNjtsiijsW6RZP5lGOxSavnHsANdTVErdJRSLvqb+9H4jMGhKU +TPP+AaBG7vC0/saUZ6W43R26embXtF4yS1nETyMIeLQ9UjVJ5VT2EaJVlnwM+6Sw8dB Mq2hS2YLCUxUg2glIGkBiyW2IrDZP0bwuyTDIVr/7au17iJsNxq+oyd6jD1IhhUPPrjQ EY3swwL4L7a+wNX0jP0lAC/x2ptAkIgP6QvgSgyhO1ZW9PgWNn2+Z9162cZFW3yBdJML bc5QBZv8jWN5niJMQVHjgve/XM9Sxu7VVbAwvitjoj9LoUUhgi+oPTVE07bYbVSy3wPM Ua5w== 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:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=41kyj0COItm75WaOj5e4Nw/yvjuXhFDrCGVC8hCPdUQ=; b=BtPHpWIijdzsn337zpYvRvfbm1W5mwMogrlI4DGO7GF9TUXFFz2OXWxI3fsgRnR0/z Gne4rEFt/i7/Z5MbgDgksuEmCv2FE221LBdPIOXK0otD9LAhR8Ik22BpRiMpzeG88onp j+ArDiWFqT/CsjF0M7FjXG5MjYk6Jr1KKXlL1XXfpQrGVL/wyFIAIr1ZnDJIVI2nWpDh FyNF/0CA6wX8bxoz7G5DuvzhxEiT8kWtE9Mbp75Wg25OpgLJkKaq3E+N4SloWuDzNyRA 22PkyK8qn+KhiytmP0SyGwgCG8GgDikiByqJmrxxqXEL4QmIfyc7E3XgF1CzmaU4D/4D HXvw== X-Gm-Message-State: ALoCoQk4E25Kti9MwC3YZqjFllqn0W23WKPrcDlI+YxIxv0W/QTfyDmRzqwVsgCorIWOtmOFBtLDFbMcnVESqSuARk8PWA/xNg== X-Received: by 10.112.165.69 with SMTP id yw5mr11312334lbb.1.1453225692604; Tue, 19 Jan 2016 09:48:12 -0800 (PST) Received: from chichi (ppp83-237-32-243.pppoe.mtu-net.ru. [83.237.32.243]) by smtp.gmail.com with ESMTPSA id l8sm4206381lfe.24.2016.01.19.09.48.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jan 2016 09:48:11 -0800 (PST) Message-ID: <64F7A4EED4914C079AD2A28B556A35DF@chichi> From: "Valery Smyslov" To: "Tero Kivinen" References: <22174.25480.999566.412598@fireball.acr.fi> In-Reply-To: <22174.25480.999566.412598@fireball.acr.fi> Date: Tue, 19 Jan 2016 20:48:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, "HU, Jun \(Jun\)" , Paul Wouters , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:48:16 -0000 Hi Tero, >> The attack can be easily modified so that the message sent from the >> attacker to the responder looks unsuspicious. All that attacker need >> to do is to find C1 and C2 so, that the COOKIE notification type in >> C1 is changed to any unused status notification type in C2. It is >> just a little bit harder than the current version of attack. However >> after that the message sent from the attacker to the responder will >> look like: >> >> M' = HDR | Nx=C2 | SAi' | KEi' | NONCEi' | Ny=(SAi | KEi | NONCEi | info_i) > > Attacker cannot do that, as attacker will not be able to get original > initiator to reflect the Nx=C1 back in the m1. Cookies notifications > are used because are required from the initiator to be copied from the > original SA_INIT reply to the retry SA_INIT request. > > For that unknown notification that would not work, i.e. when the > attacker sends back the > > SA_INIT(ck=|C1|SA',gx'|ni|) > > the initiator will ignore the first notification if it not cookie, and > will not retry with message sending cookie notification. You missed the point. The attacker finds a collision so that C1 (sent to initiator) contains COOKIE notification (with SAi', KEi', NONCEi' included), while in C2 (sent to responder) the notification type is changed from COOKIE to smth unknown (and of course the length changed too, as in original attack). >> So the responder will see two unknown status notifications (Nx and Ny) >> and will just ignore them. Nothing suspicious. > > If the attacker changes the m1' to contain some other notification in > the beginning that cookie notification he needs to find different type > of collison where the prefix is no longer constant, i.e., he needs to > modify that. He need to do that anyway. Note, that the ck and ck' cookie length in the original attack must be correct and different (ck = C1 | SAi' | g^xi' |NONCEi, while ck' = C2). The other option for the attacker is to make the length of ck and ck' equal, but in this case the length of m and m' will be different and he must find a collision so that the length field in HDR and HDR' be correct (m' will be longer than m). The authors write about this on p.13: We also observe that the two prefixes are very similar: we only need the length of the cookie to be different. Following the format of IKE message, the length field is on bytes 22 and 23 of the hashed transcript, and all previous bytes must have a fixed value. Hence, we can _almost_ use a common-prefix collision attack, if the collision algorithm introduces a difference in bytes 22- 23, and no difference in preceding bytes. So it is not a pure collision attack. In the modified attack the additional requirement is that not only length of the notification be different, but also the type of notification in C2 changes from COOKIE in C1 to any unused status notification. It makes finding a collision harder, but I think not too much. >> So the only real defense against this attack is an unpredictability >> of SPIi. > > And checking the small subgroups in Diffie-Hellman, i.e., not using > groups 22-24. Sure. Regards, Valery. From nobody Tue Jan 19 11:14:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DC21B34A0 for ; Tue, 19 Jan 2016 11:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.779 X-Spam-Level: * X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, MANGLED_PILL=2.3, SPF_NEUTRAL=0.779] autolearn=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 AuLNRIvnaRQy for ; Tue, 19 Jan 2016 11:14:42 -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 552A71B3476 for ; Tue, 19 Jan 2016 11:14:42 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0JJET5Y023645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 21:14:29 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0JJETTl015085; Tue, 19 Jan 2016 21:14:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22174.35605.160874.324692@fireball.acr.fi> Date: Tue, 19 Jan 2016 21:14:29 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <64F7A4EED4914C079AD2A28B556A35DF@chichi> References: <22174.25480.999566.412598@fireball.acr.fi> <64F7A4EED4914C079AD2A28B556A35DF@chichi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 24 min X-Total-Time: 26 min Archived-At: Cc: ipsec@ietf.org, "HU, Jun \(Jun\)" , Paul Wouters , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 19:14:45 -0000 Valery Smyslov writes: > You missed the point. The attacker finds a collision so that > C1 (sent to initiator) contains COOKIE notification (with > SAi', KEi', NONCEi' included), while in C2 (sent to responder) > the notification type is changed from COOKIE to smth unknown > (and of course the length changed too, as in original attack). The attack finds common-prefix-collision, i.e. where everything before the C1 and C2 is same. If the C1 and C2 requires some kind of structure (i.e. other needs to start with 0x2100009600004006..., and the other starts with 0x210000960000A006) then the attack is no longer common prefix collision. If I remember right, I think that common-prefix-collions worked on blocks, so it would require full hash-blocks for prefix, but that is of course easy to take, as we can pad C1 and C2 with zeros or something until next block size. I.e. it is not as easy to find C1 and C2 so that hash(P1 || C1) == hash(P2 || C2) where P1 and P2 are different. > >> So the responder will see two unknown status notifications (Nx and Ny) > >> and will just ignore them. Nothing suspicious. > > > > If the attacker changes the m1' to contain some other notification in > > the beginning that cookie notification he needs to find different type > > of collison where the prefix is no longer constant, i.e., he needs to > > modify that. > > He need to do that anyway. Note, that the ck and ck' cookie > length in the original attack must be correct and different > (ck = C1 | SAi' | g^xi' |NONCEi, while ck' = C2). Hmm... yes, I think that also makes the attack impossible, as the length needs to be modified, thus it is no longer common prefix attack. > The other option for the attacker is to make the length of ck and > ck' equal, but in this case the length of m and m' will be different > and he must find a collision so that the length field in HDR and > HDR' be correct (m' will be longer than m). The authors write about > this on p.13: > > We also observe that the two prefixes are very similar: > we only need the length of the cookie to be different. > > Following the format of IKE message, the length field > > is on bytes 22 and 23 of the hashed transcript, and > > all previous bytes must have a fixed value. Hence, we > > can _almost_ use a common-prefix collision attack, if the > > collision algorithm introduces a difference in bytes 22- > > 23, and no difference in preceding bytes. > You should have read the rest of that paragraph: For MD5, the most efficient collision attacks do not have a compatible message difference, but it seems possible to build a dedicated attack with complexity below 2^39. However, for SHA-1, all known collision attacks use differences in every message words, and are thus unsuitable. I.e. they say that this attack is impossible with SHA-1 too for now, as they cannot use the 2^77 attack for SHA-1, as it only works with chosen-prefix collisions where this requires almost-common-prefix collision attack, and that does not work for SHA. To be able to attack SHA-1 they need to find new ways to make almost chosen-prefix attacks against SHA1. [1] https://www.mitls.org/downloads/transcript-collisions.pdf > So it is not a pure collision attack. In the modified attack the > additional requirement is that not only length of the notification > be different, but also the type of notification in C2 changes from > COOKIE in C1 to any unused status notification. It makes finding a > collision harder, but I think not too much. For MD5 they say that it might be possible, for SHA-1 they say all known collision attacks are unsuitable... I would consider that makeing it much harder in general.. > >> So the only real defense against this attack is an unpredictability > >> of SPIi. > > > > And checking the small subgroups in Diffie-Hellman, i.e., not using > > groups 22-24. > > Sure. -- kivinen@iki.fi From nobody Tue Jan 19 22:28:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96741A700B for ; Tue, 19 Jan 2016 22:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 BNOZHWHh8PCc for ; Tue, 19 Jan 2016 22:28:23 -0800 (PST) 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 8141C1A700A for ; Tue, 19 Jan 2016 22:28:23 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id 17so150781594lfz.1 for ; Tue, 19 Jan 2016 22:28:23 -0800 (PST) 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-type:content-transfer-encoding; bh=8hpZB4zNDaV2fbhwJR4VGm90mLppkjWN/jBBCFoa+zU=; b=q5zhP/EZAoz77tW0jJH5phxL77AblzB5FIBPUAeaO4ve+9yFqdxwva6x+z+ZP/FgoK ZiXCrr+rJDQHAyzt0dgjg1TzHj0zMXxh3/IwVzABniz85GIp2e4XsopnpFZfeCPoHqib x1ig99RmEGGIrCrO4X4SMf5CaMOZyLclp5f7H/eGyrUBHJUxlic8bFVY0KLC9JZmaqZT jpVFQFsFsP68yc7sls47RCOKSa+IPq2oh5RRfwL2fZnKLnY4yuLd8kUmK2GOK/4CBPab ccUFUqm7cBtrKyqtnjaCMcl/ov2siynaivaN+NhkHw300VhwYYYz4H8731P84e1NAIgy r2Aw== 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-type:content-transfer-encoding; bh=8hpZB4zNDaV2fbhwJR4VGm90mLppkjWN/jBBCFoa+zU=; b=gLTH+MD+gY050AtYYx2pE8VqITQ7FTbJokYhuUTUg0X538RXoVKBvODvCSZts9a1Zu PbuikHRpTZzjU/BneYXkpCDW/8N4toyfK21WEInqWybmioY+dkXzchDaNhTHD/35FKqy xR4b93uKHHtp8uI0jXLBz1iQoXEoqsdy0+Ok+/eeSol2TbGchJap8vkKLg6581xqOayA OvIWN0dyzhG+ogU/qjjVKpBlTyQzHk5cy1r66qbXveH9yJDkF/Gzco8WeaFVyI3jhhU7 +plLryASL+8iB2Uu6Gjeiokxul4ggJEw5mHIDotl03OggX8/HngNnL5bfE4IOdY4A+rF NPFg== X-Gm-Message-State: ALoCoQkDr1mOCGot6mFDKCjJkYZEbAJCa1qtEkOtvy+FSRDv1UFgmW6LEG06tCCmCMwDHNra5tsZLHii/jL/l7cV8OdJw6RuJQ== X-Received: by 10.25.8.214 with SMTP id 205mr12582106lfi.46.1453271301822; Tue, 19 Jan 2016 22:28:21 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d18sm4480025lfb.1.2016.01.19.22.28.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jan 2016 22:28:20 -0800 (PST) Message-ID: <3A25D06EE4D7476A96913845A72F924D@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <22174.25480.999566.412598@fireball.acr.fi><64F7A4EED4914C079AD2A28B556A35DF@chichi> <22174.35605.160874.324692@fireball.acr.fi> Date: Wed, 20 Jan 2016 09:28:19 +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, "HU, Jun \(Jun\)" , Paul Wouters , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 06:28:25 -0000 > You should have read the rest of that paragraph: > > For MD5, the most efficient collision attacks do not have a > compatible message difference, but it seems possible to build > a dedicated attack with complexity below 2^39. However, for > SHA-1, all known collision attacks use differences in every > message words, and are thus unsuitable. > > I.e. they say that this attack is impossible with SHA-1 too for now, > as they cannot use the 2^77 attack for SHA-1, as it only works with > chosen-prefix collisions where this requires almost-common-prefix > collision attack, and that does not work for SHA. To be able to attack > SHA-1 they need to find new ways to make almost chosen-prefix attacks > against SHA1. At the beginning of the paper the authors write that the attack against IKEv2 is _almost_ practical. So, it is infeasible today, but taking into considerations fast progress in hash analysis can become feasible tomorrow. That's why it's better to have an additional defense on the protocol level (like moving COOKIE at the end of the message). It is not an urgent action that we should do in a rush, but it is an option we should comsider for next major protocol update (if it happens). Regards, Valery. From nobody Wed Jan 20 03:40:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455A61B3A7F for ; Wed, 20 Jan 2016 03:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 0iegZbgsAQea for ; Wed, 20 Jan 2016 03:40:45 -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 1415C1B3A79 for ; Wed, 20 Jan 2016 03:40:45 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pllKQ1Km3z9M5; Wed, 20 Jan 2016 12:40:42 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 q_xeXqpv5OQr; Wed, 20 Jan 2016 12:40:36 +0100 (CET) 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 Jan 2016 12:40:36 +0100 (CET) Received: from [193.111.228.86] (unknown [193.111.228.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 43808600BB50; Wed, 20 Jan 2016 06:40:35 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 43808600BB50 References: <22174.25480.999566.412598@fireball.acr.fi> <64F7A4EED4914C079AD2A28B556A35DF@chichi> <22174.35605.160874.324692@fireball.acr.fi> <3A25D06EE4D7476A96913845A72F924D@buildpc> Mime-Version: 1.0 (1.0) In-Reply-To: <3A25D06EE4D7476A96913845A72F924D@buildpc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0000004D-DB72-47BE-801A-AFF88EDB267B@nohats.ca> X-Mailer: iPhone Mail (13C75) From: Paul Wouters Date: Wed, 20 Jan 2016 06:40:23 -0500 To: Valery Smyslov Archived-At: Cc: ipsec@ietf.org, "HU, Jun \(Jun\)" , Yoav Nir , Tero Kivinen , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 11:40:47 -0000 If you want to harden things, it would be better to do it much differently. I= f we depend on cookie being at the end, we would be way too fragile. IKEv1 started where payload order didn't matter and I still believe that sho= uld remain true as much as possible. It doesn't stop you from putting COOKIE at the end though. Sent from my iPhone On Jan 20, 2016, at 01:28, Valery Smyslov wrote: >> You should have read the rest of that paragraph: >> For MD5, the most efficient collision attacks do not have a >> compatible message difference, but it seems possible to build >> a dedicated attack with complexity below 2^39. However, for >> SHA-1, all known collision attacks use differences in every >> message words, and are thus unsuitable. >> I.e. they say that this attack is impossible with SHA-1 too for now, >> as they cannot use the 2^77 attack for SHA-1, as it only works with >> chosen-prefix collisions where this requires almost-common-prefix >> collision attack, and that does not work for SHA. To be able to attack >> SHA-1 they need to find new ways to make almost chosen-prefix attacks >> against SHA1. >=20 > At the beginning of the paper the authors write that the attack against > IKEv2 is _almost_ practical. So, it is infeasible today, but taking > into considerations fast progress in hash analysis can become feasible tom= orrow. That's why it's better to have an additional defense > on the protocol level (like moving COOKIE at the end of the message). > It is not an urgent action that we should do in a rush, but it is an optio= n > we should comsider for next major protocol update (if it happens). >=20 > Regards, > Valery. >=20 From nobody Wed Jan 20 06:21:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02691A89FA for ; Wed, 20 Jan 2016 06:21:34 -0800 (PST) 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 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 jAe5ZIKOydw7 for ; Wed, 20 Jan 2016 06:21:32 -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 B991F1A8934 for ; Wed, 20 Jan 2016 06:21:31 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0KELK3P002953 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Jan 2016 16:21:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0KELJ0C003495; Wed, 20 Jan 2016 16:21:19 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22175.38879.933666.673369@fireball.acr.fi> Date: Wed, 20 Jan 2016 16:21:19 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <3A25D06EE4D7476A96913845A72F924D@buildpc> References: <22174.25480.999566.412598@fireball.acr.fi> <64F7A4EED4914C079AD2A28B556A35DF@chichi> <22174.35605.160874.324692@fireball.acr.fi> <3A25D06EE4D7476A96913845A72F924D@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Cc: ipsec@ietf.org, "HU, Jun \(Jun\)" , Paul Wouters , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 14:21:35 -0000 Valery Smyslov writes: > > You should have read the rest of that paragraph: > > > > For MD5, the most efficient collision attacks do not have a > > compatible message difference, but it seems possible to build > > a dedicated attack with complexity below 2^39. However, for > > SHA-1, all known collision attacks use differences in every > > message words, and are thus unsuitable. > > > > I.e. they say that this attack is impossible with SHA-1 too for now, > > as they cannot use the 2^77 attack for SHA-1, as it only works with > > chosen-prefix collisions where this requires almost-common-prefix > > collision attack, and that does not work for SHA. To be able to attack > > SHA-1 they need to find new ways to make almost chosen-prefix attacks > > against SHA1. > > At the beginning of the paper the authors write that the attack against > IKEv2 is _almost_ practical. So, it is infeasible today, but taking > into considerations fast progress in hash analysis can become feasible > tomorrow. That's why it's better to have an additional defense > on the protocol level (like moving COOKIE at the end of the message). > It is not an urgent action that we should do in a rush, but it is an option > we should comsider for next major protocol update (if it happens). Moving cookie to the end does not help to protect against this attack. Using random SPI do protect. If they are able to do attacks against SHA-1 without chosen-prefix in the beginning, then it does not matter where the cookie is. If they cannot do that, then their attack does not work as long as either SPIi and SPIr is random. I mean if they can do attack even when the SPIs are random, then they can also do the attack when the cookie is in the end, as only thing they need to change durign the exchange is to change the g^x with g^x' so they can just then force the hash to be same where the HASH(SA_INIT(SAi | g^x | ni | infoi | ck(C1)) == HASH(SA_INIT(SAi | g^x' | ni | infoi | ck(C2)) where C1 and C2 are just selected so that they make hash same even when the SPIi and SPIr, and g^x are different... So moving cookie to the end does not offer any more protection against this attack, thus not needed. Using random SPIi and SPIr will protect against this attack, and when attacks against SHA-1 are so good that it will not protect anymore, then we say MUST NOT for SHA-1. -- kivinen@iki.fi From nobody Wed Jan 20 07:28:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652091A8AF8 for ; Wed, 20 Jan 2016 07:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 hylOxjH6-f8L for ; Wed, 20 Jan 2016 07:28:32 -0800 (PST) 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 2A34F1A8AF6 for ; Wed, 20 Jan 2016 07:28:32 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id h129so8203110lfh.3 for ; Wed, 20 Jan 2016 07:28:32 -0800 (PST) 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-type:content-transfer-encoding; bh=lCR6DP896UyCFsXuZnCqH/JUNpPLQ4xnCHccVg/bx0A=; b=azhbIVvsMzO/JpSl3yUQ9OSj2qEzIYZUoD8AzrpXbD0EBCX+SzhfEjJh0GjKs6ZdxO q6WiI9NkoXjQaEzo8rrj0WLy1vgPt8u1IgPpOId60x6dS5fVshyOAQJRG2Dj6IPTljlF 2ArWnAUtUw8XX977T2qRBTWlkt6lhi+US0cIRn6VaR314lK2ZLbKXNxvznI3o7ECpb0v P1v95Rf+wCENfQ376uxwt9Cp5AXTdXRgxpKusmQP0jzdZ7OBIe7A/obK4TylpJA9Z5Zv VAGawbIGHCUjmnGVEf+9894z+PLvSZGUkOfMo8ZgNcg9aagbHaUqoekGR0ipmpRsTD5r nrbA== 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-type:content-transfer-encoding; bh=lCR6DP896UyCFsXuZnCqH/JUNpPLQ4xnCHccVg/bx0A=; b=buSJjP0XQez6kRTfnym8lydc6YlPvH5s/VaVHU25Rc/6Sjt6J0+0kdPolozq5y3xLN bli41b30i8pge+gu4ukmPAYQcETUshcDqDN0D3l8snzAYz6oNJZnrDgrnmCnTI6aCMKG Zdeb7S4cPF97sAlasvj2ZYewsfXDdtMWm/hNWF1Xo2akBWGmk8jW5lysXFskiMZkrDSP vr/zFWn7iGu1c7lnv1If08lKWld5NfSIkDrh8sNoWcpei5gZxbswMyDArMCSFAunD4xn AteDWV7Wr2h9J4Hi0bXl7YLQ/zUowXSrZARMvEIAB7dvFKWNpak1rDP+SMz8xPhuXL9t Pbkg== X-Gm-Message-State: ALoCoQme1x5z+nPoZz3EA7ud7/s6mdTYb63CFU9y0QRN+FVDRIFN9j83KeoRfgjjNyDyiMnUXp58Ptr6wq/W3Oxr8CFugwBHoQ== X-Received: by 10.25.18.89 with SMTP id h86mr10941119lfi.165.1453303710419; Wed, 20 Jan 2016 07:28:30 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id xo4sm4732696lbb.27.2016.01.20.07.28.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 07:28:29 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <22174.25480.999566.412598@fireball.acr.fi><64F7A4EED4914C079AD2A28B556A35DF@chichi><22174.35605.160874.324692@fireball.acr.fi><3A25D06EE4D7476A96913845A72F924D@buildpc> <22175.38879.933666.673369@fireball.acr.fi> Date: Wed, 20 Jan 2016 18:28:28 +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, "HU, Jun \(Jun\)" , Paul Wouters , Yoav Nir , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] SLOTH & IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:28:33 -0000 > If they are able to do attacks against SHA-1 without chosen-prefix in > the beginning, then it does not matter where the cookie is. Right. > If they > cannot do that, then their attack does not work as long as either SPIi > and SPIr is random. > > I mean if they can do attack even when the SPIs are random, then they > can also do the attack when the cookie is in the end, as only thing > they need to change durign the exchange is to change the g^x with > g^x' so they can just then force the hash to be same where the > > HASH(SA_INIT(SAi | g^x | ni | infoi | ck(C1)) == > HASH(SA_INIT(SAi | g^x' | ni | infoi | ck(C2)) > > where C1 and C2 are just selected so that they make hash same even > when the SPIi and SPIr, and g^x are different... Note, that the attacker must do that online and g^x is unpredictable (in addition to SPIi). If finding a collision depends on the amount of unpredictable data, then moving ck to the end would help. If not - it won't. Regards, Valery. From nobody Wed Jan 20 13:04:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4104F1ACE95 for ; Wed, 20 Jan 2016 13:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Vzkd0qcqwTs1 for ; Wed, 20 Jan 2016 13:04:42 -0800 (PST) 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 9CDCB1ACE99 for ; Wed, 20 Jan 2016 13:04:41 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id n5so49778229wmn.0 for ; Wed, 20 Jan 2016 13:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=aYUDxgd6YtoEwiPFEaB4ZSykMyQ6Ln91t8OwtMyvbIg=; b=XQ2krE4UlDX7zsU8cVxgd8seIu0LUkjofWeBJfVGMKObBUSyRNNUzJxrQBSpmiYO6k Gy6E/NnQvOrZn0hYVgzob/dwb8rg9xg8rg38nEVSjJbzPZHiuyHNPax1ZzQ7hAf6UWu0 DxAuaJrSDufB9KuGiWCFBy9ZDjtEJHv7JNseh4VHiLpIcUG2/YKK+Dm6gAzcM+wtrhFA Gw8d6+/K2v+eTMJoSIWR1+weAd4hh8BzseXtnI4xFqIbypPRsR1g2CMLjVH3lJMgOtrF bMjRooKaeWH5Wt7P5QhGT5Fo55NsYPIEp0KRyJ9FpC1A82lJK9ZcLQbyyzxw3Pwg8D/Z 4YQQ== 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:date:message-id:subject:from :to:content-type; bh=aYUDxgd6YtoEwiPFEaB4ZSykMyQ6Ln91t8OwtMyvbIg=; b=R8TcRQOYj74npeIIX0JFCL/4nHnZHOYPOua4CuwfFmHANnSWD3e9rkhIDvo2SxqW6d Zbqg0msWn4rtBzZ/jiyTLfvv9o07TjihrmU7fWFEBTCkk4QaDU+2dxYqXyZH39j2Sajn ZG2HARutwYw9/dhOKuBaZHf41oAQlqS/+M1whzuU9Wz1kna9uTk+Jd9pTf5dpGfgfwVZ cYpbKFPsJY2XRjlcWYTaG2CxhTJMCcRKAcb672NDV47BVI2nKmJvZLZfIYNEScX4b0qH LAvJhmnv+HyVy332M3ARqISEuqWZw8cQ7ccq4hVBrnlq8TEjmm7CJ0zkQPw9aKAqsS2E bLKA== X-Gm-Message-State: ALoCoQkjLl1jrzyVKnTWpmsuvpGRUmm7Z9nd8DXT83O+wXecDBFhKDSBSbcIPMxrU5uvjaHuwt1FyxHAspgFBqtH3Y4Wg+z9jA== MIME-Version: 1.0 X-Received: by 10.194.118.138 with SMTP id km10mr42978591wjb.57.1453323880130; Wed, 20 Jan 2016 13:04:40 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.250.6 with HTTP; Wed, 20 Jan 2016 13:04:40 -0800 (PST) Date: Wed, 20 Jan 2016 15:04:40 -0600 X-Google-Sender-Auth: E0jyqeS3ovpOYiqDMVjz77HRfGw Message-ID: From: Daniel Migault To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=089e011764319e6ece0529ca55e1 Archived-At: Subject: [IPsec] RFC4307bis working version 3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 21:04:43 -0000 --089e011764319e6ece0529ca55e1 Content-Type: text/plain; charset=UTF-8 Hi, Please find the working version of version 03: https://github.com/mglt/drafts/commit/40e6a1e0e99064b54a328e27f0c3d498c2c7164c Feel free to provide comments. BR, Daniel A) adding recommendations for DH - Group 22- 24: 221024-bit MODP Group with 160-bit Prime Order SubgroupMUST NOT 231024-bit MODP Group with 224-bit Prime Order SubgroupMUST NOT 241024-bit MODP Group with 256-bit Prime Order SubgroupMUST NOT with the following comment: Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP Group with 224-256-bit Prime Order Subgroup are exposed to synchronization or transcription attacks. B) PKIX Do we need something more ? C) Intended Audience: Specifying the implementer vs users: The recommendations of this document mostly target IKEv2 implementers as implementations needs to meet both high security expectations as well as high interoperability between various vendors and with different updates. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suites. On the other hand, comments and recommendations are also expected to be useful for such users. D) Other Hash function has been removed E) Removing Curve25519 as not yet defined F) ENCR payload replaced by Encrypted Payload. It seems an INTG payload is running somewhere, but I could not find it. G) removing recommendation for non defined crypt suites: Ed25519 (MAY), Ed25519ph(MAY), Ed448(MAY), Ed448ph(MAY). I would like to be able to provide the right OID ASN1 code for the recommended authentication methods. --089e011764319e6ece0529ca55e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the working version= of version 03:
https://github.com/mglt/drafts/commit/4= 0e6a1e0e99064b54a328e27f0c3d498c2c7164c
Feel free to provide comment= s.

BR,
Daniel


A) adding recomm=
endations for DH - Group 22- 24:
<c>22</c><c>1024-bit MODP Group with 160-bit Prime Order =
Subgroup</c><c>MUST NOT</c>
<c>23</c><c>1024-bit MODP Group with 224-bit Prime Order =
Subgroup</c><c>MUST NOT</c>
<c>24</c><c>1024-bit MODP Group with 256-bit Prime Order =
Subgroup</c><c>MUST NOT</c>

with the following comment:
Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP Group
=
with 224-256-bit Prime Order Subgroup are exposed to synchronization
or =
transcription attacks.

B) PKIX
Do we need something more ?

C) Intended Audience:
Specifying the implementer vs users:

The recommendations of this document mostly target IKEv2 implementers
as=
 implementations needs to meet both high security expectations as 
well =
as high interoperability between various vendors and with 
different upd=
ates. Interoperability requires a smooth move to more 
secure cipher sui=
tes. This may differ from a user point of view that
=C2=A0may deploy and=
 configure IKEv2 with only the safest cipher suites. 
On the other hand,=
 comments and recommendations are also expected to be useful for such users=
.

D) Other Hash function has been removed

E) Removing Curve25519 as not yet defined

F) ENCR payload replaced by Encrypted Payload. It seems an INTG payload is =
running somewhere, but I could not find it.

G) removing recommendation for non defined crypt suites:=20
Ed25519 (MAY),  Ed25519ph(MAY), Ed448(MAY), Ed448ph(MAY).=20
I would like to be able to provide the right OID ASN1 code for the 
reco=
mmended authentication methods.

--089e011764319e6ece0529ca55e1-- From nobody Wed Jan 20 16:27:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E861B2B8E for ; Wed, 20 Jan 2016 16:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 rg7Iis1W6A4X for ; Wed, 20 Jan 2016 16:27:45 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF4C1B2B8D for ; Wed, 20 Jan 2016 16:27:45 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pm4LR0vKxz9Mp for ; Thu, 21 Jan 2016 01:27:43 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 6aZY7nriK1l2 for ; Thu, 21 Jan 2016 01:27:42 +0100 (CET) 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 ; Thu, 21 Jan 2016 01:27:42 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C6FCE600BB50; Wed, 20 Jan 2016 19:27:40 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca C6FCE600BB50 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C36B15D8CA4 for ; Wed, 20 Jan 2016 19:27:40 -0500 (EST) Date: Wed, 20 Jan 2016 19:27:40 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] ESN question regarding wording in 4304 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 00:27:46 -0000 RFC-4304 states: 2.2.1. Extended (64-bit) Sequence Number To support high-speed IPsec implementations, Extended Sequence Numbers (ESNs) SHOULD be implemented, as an extension to the current, 32-bit sequence number field. Use of an ESN MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit sequence numbers are explicitly negotiated. (The ESN feature is applicable to multicast as well as unicast SAs.) RFC-7296 states: Note that an initiator who supports ESNs will usually include two ESN transforms, with values "0" and "1", in its proposals. A proposal containing a single ESN transform with value "1" means that using normal (non-extended) sequence numbers is not acceptable. I'm a little confused about the word "default" in 4304. All proposals must have an ESN transform type, which can contain 0, 1 or 2 payloads, referring to "NO ESN" (0), "YES ESN" (1) or both. I could read this to mean, the default should be "YES ESN" only? But I could also read this as "you should allow YES and NO but as responder, when given the choice, choose YES". I'm wondering what other implementations do (and prefer) Paul From nobody Wed Jan 20 20:01:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC0D1B2E4F for ; Wed, 20 Jan 2016 20:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 IWMJQ5QQW2UA for ; Wed, 20 Jan 2016 20:01:19 -0800 (PST) Received: from hoffman.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 1B52B1B2E4E for ; Wed, 20 Jan 2016 20:01:19 -0800 (PST) Received: from [192.168.114.1] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u0L41HF8033799 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jan 2016 21:01:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [192.168.114.1] From: "Paul Hoffman" To: "IPsecME WG" Date: Wed, 20 Jan 2016 20:01:17 -0800 Message-ID: References: <20160121035713.715F418000D@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: [IPsec] Fwd: RFC 7670 on Generic Raw Public-Key Support for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 04:01:20 -0000 Of interest here for those who followed the trajectory of this draft. --Paul Hoffman Forwarded message: > From: rfc-editor@rfc-editor.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org > Subject: RFC 7670 on Generic Raw Public-Key Support for IKEv2 > Date: Wed, 20 Jan 2016 19:57:13 -0800 (PST) > > A new Request for Comments is now available in online RFC libraries. > > > RFC 7670 > > Title: Generic Raw Public-Key Support for IKEv2 > Author: T. Kivinen, P. Wouters, H. Tschofenig > Status: Standards Track > Stream: IETF > Date: January 2016 > Mailbox: kivinen@iki.fi, > pwouters@redhat.com, > Hannes.Tschofenig@gmx.net > Pages: 10 > Characters: 21350 > Updates: RFC 7296 > > I-D Tag: draft-kivinen-ipsecme-oob-pubkey-14.txt > > URL: https://www.rfc-editor.org/info/rfc7670 > > DOI: http://dx.doi.org/10.17487/RFC7670 > > The Internet Key Exchange Version 2 (IKEv2) protocol did have support > for raw public keys, but it only supported RSA raw public keys. In > constrained environments, it is useful to make use of other types of > public keys, such as those based on Elliptic Curve Cryptography. > This document updates RFC 7296, adding support for other types of raw > public keys to IKEv2. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for > the > standardization state and status of this protocol. Distribution of > this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > From nobody Wed Jan 20 20:47:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E9D1B2ECA for ; Wed, 20 Jan 2016 20:47:43 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2Aawx7VRSBWx for ; Wed, 20 Jan 2016 20:47:41 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 7CD601B2EC9 for ; Wed, 20 Jan 2016 20:47:41 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id 123so158581729wmz.0 for ; Wed, 20 Jan 2016 20:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ETOe0P163S7CgMO5002U1kW4w0r0oobWOZ2H77UmhoQ=; b=orWlg6QgMURq4a4vvjzLqDuXSM7bDiS8/cJHeNjK+Ix5VH2TwUlJwyYa9t3mwhoyoU eFHRzSLAMMbAcal6kvQBNnK6Y+CmaTv1Lh/KzfAEMMME/Oq8npQgUADMQ9ZyVb12gJON RMKzR5hYWXcQ3vlm317Pp3z4rKdewbFGVT56Qc7yrexaaajM/AIVmBLoCgakbHLuQVKP TqgjmzzE1xLQCLQeWwmYdNxFUcLcBWzO2WDZbjRwdpxhB/kiduitNS+zBW0Y+knIrs9z PdWqqPxxgEVlNL76WKmu0clX6cNPfkxZgkhrAh0//cOLJBda3NwvviNxlDOfUtVLzDhz Vj1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ETOe0P163S7CgMO5002U1kW4w0r0oobWOZ2H77UmhoQ=; b=fG1YVNtlUjPbV69B+Pr36XFkPdBPYJD1bNUAWfiH56iJB42M9gMq8bBN+4xsbGrMCv Soh9P4O9PlL9aRbBlIBWUTSdBDKVSpUhXXR61JmJCTGV9+mQs/ma9BEfU+HZq6uCzGyt 5jDh0veb1eCHx+Gv93q3zX+PLOZ5FeWwAHFuMWP3dq5jMxBBZ9hoJTaWm2bpimBtWTUd a/0FpMeecSm6ZKpPdK5OhXteHpsdhM0zpjgpdANAhtfI6c6KtuQGqiWcAAksvjvFxQgv SH6xsumn39z3lOBXWhcG2n3o4SKlUVBhnU2VbUyYx3tZfh22F0LW6CxHYn6bjlcojgoF qqwg== X-Gm-Message-State: ALoCoQnzMADzrvLeKfz/xT71Eo5126MwC1QmslSN+kbEjNtMCxOGUcz9of+2mhBruIEvfyd0BCWwfwGu5oA0ZUVg/sSSWAI+yA== X-Received: by 10.194.115.129 with SMTP id jo1mr40023982wjb.28.1453351660127; Wed, 20 Jan 2016 20:47:40 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id xx3sm36001249wjc.32.2016.01.20.20.47.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 20:47:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Thu, 21 Jan 2016 06:47:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2FE11F40-8C48-4BC2-94E6-7C8DBB6E2748@gmail.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] ESN question regarding wording in 4304 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 04:47:43 -0000 Hi, Paul At some point there was talk of allowing people to omit the ESN = attribute from the SA payload, and that would mean =E2=80=9CESN yes = only=E2=80=9D. That was not in the final 4306, but apparently a trace of = this remains in 4304. As for what my implementation does, we send only =E2=80=9CESN no=E2=80=9D = and accept only =E2=80=9CESN no=E2=80=9D. Yoav > On 21 Jan 2016, at 2:27 AM, Paul Wouters wrote: >=20 >=20 >=20 > RFC-4304 states: >=20 > 2.2.1. Extended (64-bit) Sequence Number >=20 > To support high-speed IPsec implementations, Extended Sequence > Numbers (ESNs) SHOULD be implemented, as an extension to the = current, > 32-bit sequence number field. Use of an ESN MUST be negotiated by = an > SA management protocol. Note that in IKEv2, this negotiation is > implicit; the default is ESN unless 32-bit sequence numbers are > explicitly negotiated. (The ESN feature is applicable to multicast > as well as unicast SAs.) >=20 > RFC-7296 states: >=20 > Note that an initiator who supports ESNs will usually include two = ESN > transforms, with values "0" and "1", in its proposals. A proposal > containing a single ESN transform with value "1" means that using > normal (non-extended) sequence numbers is not acceptable. >=20 >=20 > I'm a little confused about the word "default" in 4304. All proposals > must have an ESN transform type, which can contain 0, 1 or 2 payloads, > referring to "NO ESN" (0), "YES ESN" (1) or both. >=20 > I could read this to mean, the default should be "YES ESN" only? But I > could also read this as "you should allow YES and NO but as responder, > when given the choice, choose YES". >=20 > I'm wondering what other implementations do (and prefer) >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jan 20 21:26:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1C51B2F68 for ; Wed, 20 Jan 2016 21:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 iHyxW76IdM7p for ; Wed, 20 Jan 2016 21:26:03 -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 454651B2F67 for ; Wed, 20 Jan 2016 21:26:03 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pmByb6t6Tz9N6; Thu, 21 Jan 2016 06:25:59 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 ird86onMHHCS; Thu, 21 Jan 2016 06:25:58 +0100 (CET) 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, 21 Jan 2016 06:25:58 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 88BBD613024F; Thu, 21 Jan 2016 00:25:57 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 88BBD613024F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 84079130989; Thu, 21 Jan 2016 00:25:57 -0500 (EST) Date: Thu, 21 Jan 2016 00:25:57 -0500 (EST) From: Paul Wouters To: Daniel Migault In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 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] RFC4307bis working version 3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 05:26:05 -0000 On Wed, 20 Jan 2016, Daniel Migault wrote: > Please find the working version of version 03: > https://github.com/mglt/drafts/commit/40e6a1e0e99064b54a328e27f0c3d498c2c7164c > Feel free to provide comments. + The recommendations of this document mostly target IKEv2 implementers as implementations needs to meet Remove "mostly"? implementations needs to meet both high security expectations as well as high interoperability between various vendors "high interoperability" does not really work for me. How about "wide interoperability" or industry-wide or "a wide range of interoperability". a user -> an user Avoid the word "cipher suites" because it kind of has a TLS meaning. How about safest algorithms ? On the other hand, -> Although + Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP Group with 224-256-bit Prime Order + Subgroup are exposed to synchronization or transcription attacks. I'd split this up. 1024-bit MODP Group is getting too weak to be expected to provide a Here are the recommendations -> Recommendations lower than 2048 -> smaller than 2048 > B) PKIX > Do we need something more ? Maybe try and limit it and see the PKIX authenticatiom should use an algorithm of equal of stronger security than the PRF/INTEG ? > C) Intended Audience: > Specifying the implementer vs users: See above. Perhaps after this bump the draft and ask the WG for feedback? Paul From nobody Thu Jan 21 00:16:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB2F1A0406 for ; Thu, 21 Jan 2016 00:16:47 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 DPnf1dn96dy5 for ; Thu, 21 Jan 2016 00:16:46 -0800 (PST) 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 D6BEF1A0405 for ; Thu, 21 Jan 2016 00:16:45 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id 123so163452710wmz.0 for ; Thu, 21 Jan 2016 00:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ycA1CMFI7xShF111NzDd+SlVnR2RFqiKbmWH6aUF/a0=; b=YWlg9B+1xJcgLXTA1sUB34I0lmvN5+r4Ob9L7UebsamTPq0sgwZeCtMVmDWPOgv6LW WsZk69721PwV5kgSyxgXJmr3ao8HgMM0Bpl79INV8Rla/fSraAnVmGdal+wpPQCrKrzI vmgXC+vY2M5h8+q53GFYupCH4caEFmo6ugGP0Y7tV4pxKmt8fbca2sw6wT0hg7x/46y6 /1YKkWJ52ywrhSnJdrx6i605oo8sNsVy2i3K1D4eFsDZGtV0QqDEk5FLIuwqc6poH0Qk D6S1cwN0Qx6o2y90dPcGkgmjbHabyko/upP9hIicUA9TznFwiUWX6nXOAY2OoXSePr/Y dOUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ycA1CMFI7xShF111NzDd+SlVnR2RFqiKbmWH6aUF/a0=; b=W/dQ2b8dI8l382uD2Cv6YYehBoOH0UEoZBNdWkW0g5dS+W/sVqLmGaILEhu4UU/4ah XNSev83JXROza0iEsbRZkNfYo1H4efXBk7qMa8Mf/cqZPCRtqBc0s/CWhaiM0zV/XZ16 mt3PwR2dEQNPQ+K8RrkzOstmgfafo5bQpn5ICZWAk9wfOmaiNTWjtpF4DpGi0LpsIj4e pjuEfO14HdAfiJ6T3HYM/qQret1tljxKMxbgnJhQXcWOwncNXNC+W4Ll51hzNsFI5ohF AzDOwjuzgVZYHVb0BHyk/RFHPBtOVnR3AHC4+O7uuUSM0MZXdJYDqHBF4E5/JxXBON9x iu7A== X-Gm-Message-State: ALoCoQkgDosSVdnakZsSTb9G4eQUdO/oJ3VBUo9QMczc96SgtQ2RjCiWt/msbUSgQfrCJqzWiPB0l0XLuyPSH40VdKwe/A2LGA== X-Received: by 10.194.80.65 with SMTP id p1mr46148359wjx.152.1453364204500; Thu, 21 Jan 2016 00:16:44 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id aq3sm269764wjc.1.2016.01.21.00.16.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 00:16:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Thu, 21 Jan 2016 10:16:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: <5A4176C1-C807-429B-B533-8165A1277F2D@gmail.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org" , Daniel Migault Subject: Re: [IPsec] RFC4307bis working version 3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 08:16:47 -0000 > On 21 Jan 2016, at 7:25 AM, Paul Wouters wrote: > > > "high interoperability" does not really work for me. How about "wide > interoperability" or industry-wide or "a wide range of > interoperability". > > > a user -> an user Nope: http://gmatclub.com/forum/a-user-or-an-user-111564.html From nobody Thu Jan 21 07:39:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D751B3205 for ; Thu, 21 Jan 2016 07:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 js45MQKfFjre for ; Thu, 21 Jan 2016 07:39:33 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08551B3212 for ; Thu, 21 Jan 2016 07:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7148; q=dns/txt; s=iport; t=1453390773; x=1454600373; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jJC5ec7hax0xwr5/nbAEvAlp/on3eO8UnXt+AB8+NW8=; b=UeuER6h6wJ9tEr9tyw2KNZvL+gWxOe8MxT5mT6tR8b6YPRbDF4xd2BNu OSEK5bswr5CdZ0k35XWJLAuE9l3I8PT4QOWW+gOTRZWPUszrGWboaZLkU rY9s37lcUxRzgeGmf7bYFjha1otQWQRjIOgLJjL/NJLPlvoNpY2h8m1Yq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgB3+qBW/51dJa1VCYM6gT8GiFGwB?= =?us-ascii?q?4ITAQ2BYoYPAhyBITgUAQEBAQEBAYEKhDQBAQEDASMEDVEEAgEIDgMEAQEDAiM?= =?us-ascii?q?DAgICHxEUAQgIAgQBEggTh2sDCgiuDotZDYNhAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFXuFPYR0gkuBWQ0EgxmBOgWWdQGLXoFxgWWERIhXhnqDb4NSAR4BAUKBfhi?= =?us-ascii?q?BUGqGJ3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,325,1449532800"; d="scan'208";a="229166344" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 15:39:32 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0LFdWf1007567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 15:39:32 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Jan 2016 10:39:31 -0500 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.1104.009; Thu, 21 Jan 2016 10:39:31 -0500 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , Michael Richardson , "ipsec@ietf.org" Thread-Topic: [IPsec] NIST question concerning IKEv2 and quantum resistance Thread-Index: AdFIwXQqaqlOB64eRs6Nv1l1sgbGQAEOi2dAAAU5Ue0APu0GcAAQWNqAAAC/12AAHqRekwADsQxAACXflvgBBe1E0A== Date: Thu, 21 Jan 2016 15:39:31 +0000 Message-ID: <1af9d79c15ff40f2a64f148a9a7c5ce7@XCH-RTP-006.cisco.com> References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 15:39:36 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVmFsZXJ5IFNteXNsb3Yg W21haWx0bzpzdmFucnVAZ21haWwuY29tXQ0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTUsIDIw MTYgMzo0OCBBTQ0KPiBUbzogU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpOyBNaWNoYWVsIFJpY2hh cmRzb247IGlwc2VjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIE5JU1QgcXVlc3Rp b24gY29uY2VybmluZyBJS0V2MiBhbmQgcXVhbnR1bSByZXNpc3RhbmNlDQo+IA0KPiBIaSBTY290 dCwNCj4gDQo+ID4+IEhvd2V2ZXIsIGlmIG5vIGJldHRlciBzb2x1dGlvbiBleGlzdHMgSSdkIHBy ZWZlciB0byBsaXZlIHdpdGggYQ0KPiA+PiBzaW5nbGUgZml4ZWQgY3J5cHRvIHByaW1pdGl2ZSwg dGhhbiB3aXRoIHR3by4gSXMgaXQgcG9zc2libGUgdG8gZ2V0DQo+ID4+IHJpZCBvZiBBRVMgYW5k IHRvIGNoYW5nZSB0aGUgaW5kaWNhdGlvbiBvZiB0aGUgcHBrIHRvIHVzZSB0byBzb21ldGhpbmcg bGlrZQ0KPiB0aGUgZm9sbG93aW5nPw0KPiA+Pg0KPiA+PiBITUFDX1NIQTI1NihITUFDX1NIQTI1 NihwcGssICJBIiksIHJhbmRvbV9ieXRlcykNCj4gPj4NCj4gPj4gKGRpc2NsYWltZXI6IEknbSBu b3QgYSBjcnlwdG9ncmFwaGVyKQ0KPiA+DQo+ID4gWW91ciBwcm9wb3NhbCBpcyBwZXJmZWN0bHkg c291bmQgZnJvbSBhIGNyeXB0b2dyYXBoeSBwZXJzcGVjdGl2ZS4NCj4gPiBBY3R1YWxseSwgdGhl IHJlYXNvbiB3ZSBwcm9wb3NlZCB0aGUgImVudHJ5IGluIHRoZSBBRVMgY29kZWJvb2siDQo+ID4g YXBwcm9hY2gsIHJhdGhlciB0aGFuIHNvbWV0aGluZyBsaWtlIHRoZSBhYm92ZSBzdHJ1Y3R1cmUs IGlzIGR1ZSB0bw0KPiBwcmFjdGljYWwgcmVhc29ucy4NCj4gPiBXaGVuIHRoZSByZXNwb25kZXIg cmVjZWl2ZXMgdGhlIGhpbnQsIGhlIGhhcyBubyBpZGVhIHdoaWNoIHBwayB0aGUNCj4gPiBpbml0 aWF0b3IgaXMgcmVmZXJyaW5nIHRvIChhbmQgaGUgZG9lc24ndCBrbm93IHRoZSBpZGVudGl0eSB5 ZXQpOyBvdXINCj4gPiBtb2RlbCBpcyB0aGF0IHRoZSByZXNwb25kZXIgaGFzIGEgbGlzdCBvZiBw cGsncyB0aGF0IGhlIGtub3dzIGFib3V0LA0KPiA+IGFuZCBjaGVja3MgdG8gc2VlIGlmIHRoZSBv bmUgdGhhdCB0aGUgaW5pdGlhdG9yIGhhZCBpcyBvbiB0aGUgbGlzdC4NCj4gPiBJdCdkIGJlIG5p Y2UgaWYgdGhlcmUgd2FzIGEgd2F5IGZvciB0aGUgcmVzcG9uZGVyIHRvIHNlYXJjaCB0aHJvdWdo DQo+ID4gaGlzIGRhdGFiYXNlcyBvZiBrbm93biBwcGsncyBxdWlja2x5LCBob3dldmVyIEkgZG9u J3Qga25vdyBob3cgdG8gbGV0DQo+ID4gaGltIGRvIGl0IGluIHN1YmxpbmVhciB0aW1lICh3aXRo b3V0IGxlYWtpbmcgd2hldGhlciB0d28gZXhjaGFuZ2VzDQo+ID4gdXNlZCB0aGUgc2FtZSBwcGss IHdoaWNoIHdvdWxkIGxlYWsgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGlkZW50aXRpZXMpLg0KPiA+ IFNvLCB3aGF0IHdlIHNldHRsZWQgb24gaXMgdG8gbWFrZSB0aGUgbGluZWFyIHNjYW4gZm9yIHRo ZSByaWdodCBQUEsgYXMNCj4gPiBmYXN0IGFzIHBvc3NpYmxlLiAgV2l0aCBvdXIgcHJvcG9zZWQg c29sdXRpb24sIGFuIGFnZ3Jlc3NpdmUgcmVzcG9uZGVyDQo+ID4gY291bGQgaGF2ZSBhbGwgdGhl IEFFUyBrZXlzIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHBwayBwcmVleHBhbmRlZCwgYW5kDQo+IGp1 c3QgY2hlY2sgZWFjaCBwb3RlbnRpYWwgcHBrIGJ5IGRvaW5nIG9uZSBBRVMgYmxvY2sgZW5jcnlw dGlvbiAob3INCj4gZGVjcnlwdGlvbiwgaWYgdGhleSBwcmVmZXIpOyBpZiB0aGUgaW1wbGVtZW50 YXRpb24gaGFzIEFFUy1OSSwgdGhhdCBpcyBmYWlybHkNCj4gZmFzdC4NCj4gPiBXaXRoIHlvdXIg cHJvcG9zYWwsIHRoZXkgY291bGQgcHJlZXhwYW5kIHRoZSBITUFDIGtleXMsIGJ1dCB3b3VsZA0K PiA+IHN0aWxsIG5lZWQgdG8gZG8gdHdvIFNIQTI1NiBjb21wcmVzc2lvbiBmdW5jdGlvbiBldmFs dWF0aW9ucy4NCj4gDQo+IEkgc2VlIHRoZSBwb2ludCwgdGhhbmsgeW91LiBIb3dldmVyIEFFUyBz dXBwb3J0IGluIGhhcmR3YXJlIGlzIG5vdCBhbHdheXMNCj4gYXZhaWxhYmxlLCBzbyBJIHN0aWxs IHRoaW5rIHRoYXQgaGF2aW5nIGEgc2luZ2xlIGNyeXB0byBwcmltaXRpdmUgaXMgYmV0dGVyIGlu IHRoaXMNCj4gc2l0dWF0aW9uLg0KPiANCj4gQnV0IHlvdXIgZXhwbGFuYXRpb25zIGJyaW5ncyBt ZSB0byBhIGNvbmNsdXNpb24sIHRoYXQgdGhlIHByb3RvY29sIGNvdWxkIG1lDQo+IG1vZGlmaWVk LiBQbGVhc2Ugc2VlIG15IGxvZ2ljYWwgY2hhaW4uDQo+IA0KPiBUaGUgbmVjZXNzaXR5IHRvIHBl cmZvcm0gYSBsaW5lYXIgc2VyYWNoIG9mIHRoZSBwcGsga2V5cyAoYW5kIHRodXMgc3BlbmRpbmcN Cj4gc29tZSBDUFUgcG93ZXIpIG1ha2VzIGEgcmVzcG9uZGVyIG1vcmUgc3VjY2VwdGlibGUgdG8g RG9TIGF0dGFjaywNCj4gYmVjYXVzZSBpdCBtdXN0IHNwZW5kIHJlc291cmNlcyBpbiByZXNwb25z ZSB0byBhbnkgSUtFX1NBX0lOSVQgZXhjaGFuZ2UNCj4gZXZlbiBmcm9tIHNwb29mZWQgSVAgYWRk cmVzcy4gSW4gdGhpcyBzaXR1YXRpb24gYSBzYW5lIHJlc3BvbmRlciB3b3VsZCB0cnkgdG8NCj4g ZGVmZW5kIGl0c2VsZiBzZW5kaW5nIGEgY29va2llIHJlcXVlc3QgLSB0aGlzIHdvdWxkIGd1YXJh bnRlZSB0aGF0IHRoZQ0KPiBpbml0aWF0b3IgaXMgYWxpdmUgYW5kIHRoZSBJUCBhZGRyZXNzIGlz IG5vdCBzcG9vZmVkLiBTbywgaWYgdGhlIGNvb2tpZSByZXF1ZXN0IGlzDQo+IHRvIGJlIHNlbnQg aW4gbW9zdCBjYXNlcyB3aGVuIHRoZSBJS0VfU0FfSU5JVCBtZXNzYWdlIGNvbnRhaW5zIHBwaw0K PiBleHRlbnNpb24gYW55d2F5LCB0aGVuIHRoZSBwcm90b2NvbCBjb3VsZCBiZSBtb2RpZmllZCB0 byBtYWtlIGNvb2tpZQ0KPiByZXF1ZXN0IG1hbmRhdG9yeSBpbiB0aGlzIHNpdHVhdGlvbi4gVGhl biB0aGUgSUtFX1NBX0lOSVQgZXhjaGFuZ2Ugd291bGQNCj4gbG9vayBsaWtlOg0KPiANCj4gICAg SERSLCBTQWkxLCBLRWksIE5pLCBOKFBQS19TVVBQT1JURUQpICAtLT4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8LS0gIEhEUiwgTihDT09LSUUpLCBOKFBQS19TVVBQT1JURUQs IGNyeXB0bz14eHgsDQo+IHJhbmRvbV9kYXRhPXp6eikNCj4gDQo+IFRoZSByZXNwb25kZXIgc2Vs ZWN0cyBwcmYgKGFuZCBlbmNyeXB0aW9uLCBpZiBpdCBpcyB1c2VkKSBhbGdvcml0aG1zIGZyb20g dGhlDQo+IFNBaTEgcGF5bG9hZC4gSXQgYWxzbyBzdXBwbGllcyByYW5kb21fZGF0YSB0aGF0IHRo ZSBpbml0aWF0b3IgbXVzdCB1c2Ugd2hlbiBpdA0KPiBlbmNvZGVzIHRoZSBwcGsuIFRoZSBpbml0 aWF0b3IgY29tcHV0ZXMgYW4gZW5jb2RlZCBwcGsgYW5kIHJldHJpZXMgdGhlDQo+IHJlcXVlc3Qu DQo+IA0KPiAgICBIRFIsIE4oQ09PS0lFKSwgU0FpMSwgS0VpLCBOaSwgTihQUEtfS0VZKSAgLS0+ DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tICBIRFIsIFNBcjEsIEtFciwg TnIsIFtDRVJUUkVRXQ0KPiANCj4gVGhpcyB2YXJpYW50IGhhcyBhIGRpc2FkdmFudGFnZSB0aGF0 IHBwayB3aWxsIGFsd2F5cyByZXF1aXJlIGFuIGFkZGl0aW9uYWwNCj4gcm91bmQgdHJpcC4NCj4g SG93ZXZlciBpdCBoYXMgdGhlIGZvbGxvd2luZyBiZW5lZml0czoNCj4gMS4gRnVsbCBzdXBwb3J0 IGZvciBhbGdvcml0aG1zIGFnaWxpdHkNCj4gMi4gTm8gbmVlZCB0byBwZXJmb3JtIENQVS1pbnRl bnNpdmUgb3BlcmF0aW9ucyB1bnRpbCB0aGUgaW5pdGlhdG9yJ3MgSVAgaXMNCj4gY29uZmlybWVk IDMuIEluIHRoaXMgdmFyaWFudCBpdCBpcyB0aGUgcmVzcG9uZGVyIHdobyBzdXBwbGllcyByYW5k b21fZGF0YSB0bw0KPiBpbml0aWF0b3IgdG8gZW5jb2RlIHBwaywNCj4gICAgIHNvIGl0IGlzIG9u IHRoZSByZXNwb25kZXIgZGlzY3JldGlvbiBob3cgdG8gY2hvb3NlIHRoZW0uIEZvciBleGFtcGxl LA0KPiAgICAgaXQgbWF5IHByZWNvbXB1dGUgdGhlIGVuY29kZWQgcHBrIHZhbHVlcyB3aGVuIGl0 IGlzIGlkbGUsIG9yIGl0IGNhbg0KPiAgICAgcmV1c2UgcmFuZG9tX2RhdGEgc2V2ZXJhbCB0aW1l cy4gVGhpcyBhbGxvdyB0aGUgcmVzcG9uZGVyIHRvIHBlcmZvcm0NCj4gICAgIHRoZSBwcGsgc2Vh cmNoIGluIHN1Yi1saW5lYXIgdGltZSBpbiBzb21lIGNpcmN1bXN0YW5jZXMuDQo+IDQuIFRoZSBh ZGRpdGlvbmFsIHJvdW5kIHRyaXAgcmVxdWlyZXMgYSBtaW5pbXVtIGNoYW5nZSB0byBJS0V2MiwN Cj4gICAgIHNpbmNlIGNvb2tpZSByZXF1ZXN0IG11c3QgYmUgc3VwcG9ydGVkIGFueXdheS4NCj4g DQo+IFdoYXQgZG8geW91IHRoaW5rPw0KDQpJIGxpa2UgaXQuICBTb21lb25lIGFjdGluZyBhcyBh biBhY3RpdmUgc2VydmVyIGNvdWxkIGRldGVybWluZSBpZiB0d28gcGVvcGxlIGhhdmUgdGhlIHNh bWUgcHBrIChieSBnaXZpbmcgdGhlbSB0aGUgc2FtZSByYW5kb20gZGF0YSk7IGhvd2V2ZXIgYW4g YWN0aXZlIHNlcnZlciBjYW4gZGV0ZXJtaW5lIHRoZWlyIGlkZW50aXRpZXMgYW55d2F5cywgYW5k IHNvIHRoYXQncyBub3QgYSBjb25jZXJuLiAgVGhhdCBkb2VzIG1lYW4gdGhhdCB3ZSdyZSBhbGxv d2luZyB0aGUgc2VydmVyIHRvIG1ha2UgdGhlIHRyYWRlLW9mZiBiZXR3ZWVuIGNvbXB1dGF0aW9u YWwgY29tcGxleGl0eSBhbmQgY2xpZW50IHByaXZhY3k7IGlmIGV2ZXJ5b25lIGVsc2UgaXMgT0sg d2l0aCB0aGF0LCBzbyBhbSBJLg0KDQpUaGUgb25lIHBhcnQgdGhhdCBJIHdvdWxkIGFzayBpcyB0 aGF0IHRoZSBjcnlwdG89eHh4IGJlIGEgc2ltcGxlIGZpZWxkIChmb3IgZXhhbXBsZSwgaXQncyBh IDMyIGJpdCB2YWx1ZSBpbiB0aGUgcGF5bG9hZCksIGFuZCBub3QgYSBtb3JlIGNvbXBsaWNhdGVk IHBheWxvYWQuICBNeSBmZWFyIGlzIHRoYXQgaWYgd2UgbWFrZSB0aGF0IHBhcnNpbmcgbW9yZSBj b21wbGV4LCB0aGF0IHdvdWxkIGFkZCBsaXR0bGUtdXNlZCBjb21wbGV4aXR5IHRvIHRoZSBwcm90 b2NvbCAoYW5kIHBhcnRzIG9mIHRoZSBwcm90b2NvbCB0aGF0IGFyZSBsaXR0bGUgdXNlZC90ZXN0 ZWQgYXJlIGp1c3QgaGF2ZW5zIGZvciBleHBsb2l0YWJsZSBidWdzKS4NCg0KT2ssIEkgdGhpbmsg SSdsbCBnb3QgYWhlYWQgYW5kICh3aXRoIG15IGNvYXV0aG9ycykgcmV2aXNlIHRoZSBkcmFmdC4u Lg0KDQo+IA0KPiBSZWdhcmRzLA0KPiBWYWxlcnkuDQoNCg== From nobody Fri Jan 22 03:48:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407DE1A0135 for ; Fri, 22 Jan 2016 03:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 ZPZpd6nek2Kt for ; Fri, 22 Jan 2016 03:48:04 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DCB1A00C0 for ; Fri, 22 Jan 2016 03:48:04 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id 17so45337090lfz.1 for ; Fri, 22 Jan 2016 03:48:04 -0800 (PST) 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-type:content-transfer-encoding; bh=t5JWT6XH0jLd2OcHuLJwXA7wpej9IqXoApE7M2Jvemo=; b=al1t+shd7ErXFImJdvf7FF6SyjfPbOAxHSXMObB18tCgqHLx/7+A051ZmGHoyvqmwJ vE18izSbv4oQhN7Gd2jXZ/k5isspfVip5f6ITF0H1txywd8SAYLpZ9tZ9oQzGw0Wdrxv PXjvmPiZA7KL7fTsxJTlYjlYI/WDdnESmTP47fFz+Ay4zapwnW1d/ddJAY3VoWzvdVcL 5VOagXW3ncqg1Gai+tYP0igf4FTiZuTJi2jN4Z41XlhnB/ER2yrB/YXvGxkxHYJrP2KV rS5Ru+6qR/nMxClEuRgIyDZpS1hussjcV8AGA5otmnQxqsLol/3ZaLVvd8eVqEKZn+VU 1aRA== 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-type:content-transfer-encoding; bh=t5JWT6XH0jLd2OcHuLJwXA7wpej9IqXoApE7M2Jvemo=; b=Uu17EvzovLM4y/6Sd9aLvQtpzZJ9v8jrtwSPhCAxV6bwXyY5DhY/SrI27+gKHU22i1 ymMkz6ElFeE8JLbYq6bEXVYrkgzviOnD8ayBbzzbCBqGDk3lE18FMYaQh/Et190hyFo5 llPrjuqJzehJCNlqDaY86g0cmzhf8aw28pF0x6l7GXqkYM8cX2rI5+mIS2UQAxCVwc16 ntfFxpA1T6lzKFxYZrtdHx/7cpXX+7/O31iSdb0upVfW7ioKJVHtsSrn8UPxCURzcobz 2aq2Q/KAfu0hjM6AUydw44+9mJAazz2dOVvl81kS/03GdWz8In5wJRwrGl4MulZLABb2 pfCw== X-Gm-Message-State: AG10YOTIM36ZztGAx5hvwy6E24xKYoylbFKe23wTJfnE1Zubmv37sldrU9eI7cKsxUlzcQ== X-Received: by 10.25.163.19 with SMTP id m19mr1134485lfe.93.1453463282124; Fri, 22 Jan 2016 03:48:02 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id qp3sm807538lbb.17.2016.01.22.03.48.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 03:48:01 -0800 (PST) Message-ID: <8B95F40BABB54F339E8AE3361494DE46@buildpc> From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , "Michael Richardson" , References: <21404b33280a4b4abc841dbec888c848@XCH-ALN-010.cisco.com> <5810658E1DC448D59B09CAC6D8678445@buildpc> <17915.1452704345@obiwan.sandelman.ca> <890b1a87cd224e53bdc14d02308d8a50@XCH-RTP-006.cisco.com> <672f9104e0ad46a6b03a970bcea417ea@XCH-RTP-006.cisco.com> <1af9d79c15ff40f2a64f148a9a7c5ce7@XCH-RTP-006.cisco.com> Date: Fri, 22 Jan 2016 14:48:00 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; 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] NIST question concerning IKEv2 and quantum resistance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 11:48:06 -0000 Hi Scott, >> I see the point, thank you. However AES support in hardware is not always >> available, so I still think that having a single crypto primitive is better in this >> situation. >> >> But your explanations brings me to a conclusion, that the protocol could me >> modified. Please see my logical chain. >> >> The necessity to perform a linear serach of the ppk keys (and thus spending >> some CPU power) makes a responder more succeptible to DoS attack, >> because it must spend resources in response to any IKE_SA_INIT exchange >> even from spoofed IP address. In this situation a sane responder would try to >> defend itself sending a cookie request - this would guarantee that the >> initiator is alive and the IP address is not spoofed. So, if the cookie request is >> to be sent in most cases when the IKE_SA_INIT message contains ppk >> extension anyway, then the protocol could be modified to make cookie >> request mandatory in this situation. Then the IKE_SA_INIT exchange would >> look like: >> >> HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED) --> >> <-- HDR, N(COOKIE), N(PPK_SUPPORTED, crypto=xxx, >> random_data=zzz) >> >> The responder selects prf (and encryption, if it is used) algorithms from the >> SAi1 payload. It also supplies random_data that the initiator must use when it >> encodes the ppk. The initiator computes an encoded ppk and retries the >> request. >> >> HDR, N(COOKIE), SAi1, KEi, Ni, N(PPK_KEY) --> >> <-- HDR, SAr1, KEr, Nr, [CERTREQ] >> >> This variant has a disadvantage that ppk will always require an additional >> round trip. >> However it has the following benefits: >> 1. Full support for algorithms agility >> 2. No need to perform CPU-intensive operations until the initiator's IP is >> confirmed 3. In this variant it is the responder who supplies random_data to >> initiator to encode ppk, >> so it is on the responder discretion how to choose them. For example, >> it may precompute the encoded ppk values when it is idle, or it can >> reuse random_data several times. This allow the responder to perform >> the ppk search in sub-linear time in some circumstances. >> 4. The additional round trip requires a minimum change to IKEv2, >> since cookie request must be supported anyway. >> >> What do you think? > > I like it. Someone acting as an active server could determine if two people have the same ppk > (by giving them the same random data); however an active server can determine their identities > anyways, and so that's not a concern. That does mean that we're allowing the server to make > the trade-off between computational complexity and client privacy; if everyone else is OK with that, > so am I. > > The one part that I would ask is that the crypto=xxx be a simple field (for example, it's a 32 bit value > in the payload), and not a more complicated payload. My fear is that if we make that parsing > more complex, that would add little-used complexity to the protocol (and parts of the protocol > that are little used/tested are just havens for exploitable bugs). By crypto=xxx I meant a generic indication of what crypto primitive(s) are to be used by initiator. In your original proposal you used two primitives: encryption (AES) and prf (HMAC_SHA256). If you accept my proposal then I think it is better to simplify things and use only one primitive - prf (for two reasons - first now server can choose a sutable tradeoff between client's privacy and the server's CPU load, and second - with generic encryption you won't always get any speed benefit from using both encryption and prf). So I'd suggest to use only prf. In this case crypto=xxx becomes prf=xxx, where prf is a 16-bit integer containing one of the the values defined in IANA-IKEv2 table "Transform Type 2 - Pseudo-random Function Transform IDs", and the server selects it from what is present in the initiator's SA payload in transfoms of type 2. This guarantees that the initiator supports that prf (otherwise he wouldn't include it in the SA payload). In this case the initiator would then compute prf(prf(ppk, "A"), random_bytes). And there is no need that this selected prf is equal to the prf that is negotiated later and used in all SKEYSEED etc claculations - they are not related. The fact that they are not related simplifies their selection (for example, you don't need to look at the local policy when selecting mutually supported prf for ppk). Regards, Valery. From nobody Fri Jan 29 08:14:50 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 BF1941B2FA8; Thu, 28 Jan 2016 17:27:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129012759.23131.34047.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 17:27:59 -0800 Archived-At: X-Mailman-Approved-At: Fri, 29 Jan 2016 08:14:49 -0800 Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, david.waltermire@nist.gov Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 95 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 01:27:59 -0000 A new meeting session request has just been submitted by David Waltermire, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: D. Waltermire Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: dnsop dane dprive dbound curdle jsonbis saag sacm netmod mile httpauth Special Requests: Additional BOF conflicts: lurk and accord ---------------------------------------------------------