From nobody Mon Jun 1 06:33:53 2015 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 835C81ACDD4 for ; Mon, 1 Jun 2015 06:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, 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 GCSbgDHs0-eO for ; Mon, 1 Jun 2015 06:33:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 AD00A1ACDD1 for ; Mon, 1 Jun 2015 06:33:49 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t51DXhIi017682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jun 2015 16:33:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t51DXgoX007578; Mon, 1 Jun 2015 16:33:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21868.24374.675089.122684@fireball.kivinen.iki.fi> Date: Mon, 1 Jun 2015 16:33:42 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <63145AF1-CE50-4919-A659-6120B128AB68@gmail.com> <21862.61621.303517.567806@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Question about PFS in 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, 01 Jun 2015 13:33:52 -0000 Yoav Nir writes: > > IKEv2 tries to notice some misconfigurations, but it cannot catch them > > all. > > IKEv1 caught that particular one. Oh, you can catch this in IKEv2 too immediately, if you are fine with wasting some resources. I.e. you can either create the IKE SA as Childless IKE SA (RFC6023), and then do CREATE_CHILD_SA immediately with PFS. This will allow to have separate Diffie-Hellman groups for IPsec and IKE SAs, and detect misconfigurations immediately. If the other end does not support Childless IKE SAs then you can simply rekey the first Child SA immediately after it has been created. I.e in both cases you do one extra round trip and second Diffie-Hellman calculation. This (2+1 roundtrips) is still more efficient than 3+1.5 roundrips for IKEv1... Diffie-Hellman calculation costs are same. -- kivinen@iki.fi From nobody Wed Jun 3 01:31:06 2015 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 2EB6D1AD0C4; Wed, 3 Jun 2015 01:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 EKa1ssevhPK0; Wed, 3 Jun 2015 01:31:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1262F1B3654; Wed, 3 Jun 2015 01:30:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603083029.12261.88542.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 01:30:29 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-07.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: Wed, 03 Jun 2015 08:31:05 -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 : The NULL Authentication Method in IKEv2 Protocol Authors : Valery Smyslov Paul Wouters Filename : draft-ietf-ipsecme-ikev2-null-auth-07.txt Pages : 15 Date : 2015-06-03 Abstract: This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 01:36:10 2015 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 67BCB1B3651 for ; Wed, 3 Jun 2015 01:36:08 -0700 (PDT) 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 ef-qni38fdCO for ; Wed, 3 Jun 2015 01:36:07 -0700 (PDT) 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 F3C991B364D for ; Wed, 3 Jun 2015 01:36:06 -0700 (PDT) Received: by lbcue7 with SMTP id ue7so2144279lbc.0 for ; Wed, 03 Jun 2015 01:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=WRAIJ2POgwzFZF/vVl7qzuViErl5tgnYi2XJifaloE8=; b=EXmTIgf/voKckvT0SqqhJx1prkC7ALdkDCPL6be0sWEuoLUqdHZvar29J+FsQjH/d/ cSmgtC0XYWw81YF+hxfz3xFxcVx4LiHJntyFrCGD/F7QgAFRJyP5j2s/mhIJKl6Fo0X4 Vo3KmDkoNwSli0dsa3PaMSP0s4yhLM+Nr73o4k68ZAP0TwUrCKSudfjUekxE4Ye8MKCF yWMCT3vZC/UoVuVNI+6oozu3cDBsYokxazAlZxmcDCE8dXYotpA4DmpuzHjTUJJeiZGF 1r6T8GW0m3w8b9dwjWSwkMmxjJ+gufIw5STvYmJIlWszbj93R1FuDvisXiV1ZvcGEKTr OOnA== X-Received: by 10.112.72.164 with SMTP id e4mr27162509lbv.113.1433320565344; Wed, 03 Jun 2015 01:36:05 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id yc3sm5624832lbb.6.2015.06.03.01.36.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 01:36:04 -0700 (PDT) Message-ID: <9D6B5BC627CE42B1BBF27639501D7774@buildpc> From: "Valery Smyslov" To: References: <20150603083029.12261.88542.idtracker@ietfa.amsl.com> Date: Wed, 3 Jun 2015 11:36:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-07.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, 03 Jun 2015 08:36:08 -0000 Hi all, a new version of the NULL Authentication draft is published. It addresses the comments received during IESG evaluation of the draft. Regards, Valery & Paul. > 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 : The NULL Authentication Method in IKEv2 Protocol > Authors : Valery Smyslov > Paul Wouters > Filename : draft-ietf-ipsecme-ikev2-null-auth-07.txt > Pages : 15 > Date : 2015-06-03 > > Abstract: > This document specifies the NULL Authentication method and the > ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This > allows two IKE peers to establish single-side authenticated or mutual > unauthenticated IKE sessions for those use cases where a peer is > unwilling or unable to authenticate or identify itself. This ensures > IKEv2 can be used for Opportunistic Security (also known as > Opportunistic Encryption) to defend against Pervasive Monitoring > attacks without the need to sacrifice anonymity. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jun 4 08:03:39 2015 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 460591B2AE4 for ; Thu, 4 Jun 2015 05:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 nJvJst_EfRrO for ; Thu, 4 Jun 2015 05:10:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id E4D341AD248 for ; Thu, 4 Jun 2015 05:10:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9CD2718046B; Thu, 4 Jun 2015 05:08:05 -0700 (PDT) To: charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150604120805.9CD2718046B@rfc-editor.org> Date: Thu, 4 Jun 2015 05:08:05 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 04 Jun 2015 08:03:37 -0700 Cc: ipsec@ietf.org, ynir.ietf@gmail.com, rfc-editor@rfc-editor.org Subject: [IPsec] [Editorial Errata Reported] RFC7296 (4387) 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, 04 Jun 2015 12:10:37 -0000 The following errata report has been submitted for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7296&eid=4387 -------------------------------------- Type: Editorial Reported by: Yoav Nir Section: 3.7 Original Text ------------- The Certificate Request payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. Corrected Text -------------- The Certificate Request payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_SA_INIT response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. Notes ----- IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Jun 4 08:03:40 2015 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 7B1A51B3386 for ; Thu, 4 Jun 2015 06:51:08 -0700 (PDT) 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 GKQcmaKRqu8K for ; Thu, 4 Jun 2015 06:51:06 -0700 (PDT) Received: from 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 11B8F1B3368 for ; Thu, 4 Jun 2015 06:40:09 -0700 (PDT) Received: from [10.20.30.109] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t54De4nv036560 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2015 06:40:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <20150604120805.9CD2718046B@rfc-editor.org> Date: Thu, 4 Jun 2015 06:40:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150604120805.9CD2718046B@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Thu, 04 Jun 2015 08:03:37 -0700 Cc: nir.ietf@gmail.com, Pasi Eronen , Tero Kivinen , ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ynir.ietf@gmail.com, Charlie Kaufman , Stephen Farrell Subject: Re: [IPsec] [Editorial Errata Reported] RFC7296 (4387) 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, 04 Jun 2015 13:51:08 -0000 Please accept this erratum and mark it has "Held for document update". --Paul Hoffman > On Jun 4, 2015, at 5:08 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7296, > "Internet Key Exchange Protocol Version 2 (IKEv2)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7296&eid=3D4387 >=20 > -------------------------------------- > Type: Editorial > Reported by: Yoav Nir >=20 > Section: 3.7 >=20 > Original Text > ------------- > The Certificate Request payload, denoted CERTREQ in this document, > provides a means to request preferred certificates via IKE and can > appear in the IKE_INIT_SA response and/or the IKE_AUTH request. > Certificate Request payloads MAY be included in an exchange when the > sender needs to get the certificate of the receiver. >=20 > Corrected Text > -------------- > The Certificate Request payload, denoted CERTREQ in this document, > provides a means to request preferred certificates via IKE and can > appear in the IKE_SA_INIT response and/or the IKE_AUTH request. > Certificate Request payloads MAY be included in an exchange when the > sender needs to get the certificate of the receiver. >=20 > Notes > ----- > IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) > -------------------------------------- > Title : Internet Key Exchange Protocol Version 2 (IKEv2) > Publication Date : October 2014 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. = Kivinen > Category : INTERNET STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Thu Jun 4 08:03:42 2015 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 4E4321B34B7; Thu, 4 Jun 2015 06:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 cQuon6D8tf7F; Thu, 4 Jun 2015 06:54:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A3A281B33A2; Thu, 4 Jun 2015 06:42:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 25AA8180208; Thu, 4 Jun 2015 06:40:18 -0700 (PDT) To: ynir.ietf@gmail.com, charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150604134018.25AA8180208@rfc-editor.org> Date: Thu, 4 Jun 2015 06:40:18 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 04 Jun 2015 08:03:37 -0700 Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] [Errata Held for Document Update] RFC7296 (4387) 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, 04 Jun 2015 13:54:17 -0000 The following errata report has been held for document update for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7296&eid=4387 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Yoav Nir Date Reported: 2015-06-04 Held by: Stephen Farrell (IESG) Section: 3.7 Original Text ------------- The Certificate Request payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. Corrected Text -------------- The Certificate Request payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_SA_INIT response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. Notes ----- IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time. -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Jun 4 08:03:43 2015 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 A66541B34BA for ; Thu, 4 Jun 2015 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cJ6vki2haboy for ; Thu, 4 Jun 2015 06:54:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89091B3590 for ; Thu, 4 Jun 2015 06:43:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A66E6BF26; Thu, 4 Jun 2015 14:43:00 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bovyrsxsXlRb; Thu, 4 Jun 2015 14:43:00 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 39A06BF1C; Thu, 4 Jun 2015 14:43:00 +0100 (IST) Message-ID: <557055E2.2040207@cs.tcd.ie> Date: Thu, 04 Jun 2015 14:42:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Hoffman , RFC Errata System References: <20150604120805.9CD2718046B@rfc-editor.org> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 04 Jun 2015 08:03:37 -0700 Cc: nir.ietf@gmail.com, Pasi Eronen , Tero Kivinen , ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ynir.ietf@gmail.com, Charlie Kaufman Subject: Re: [IPsec] [Editorial Errata Reported] RFC7296 (4387) 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, 04 Jun 2015 13:54:32 -0000 Done S On 04/06/15 14:40, Paul Hoffman wrote: > Please accept this erratum and mark it has "Held for document update". > > --Paul Hoffman > >> On Jun 4, 2015, at 5:08 AM, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC7296, >> "Internet Key Exchange Protocol Version 2 (IKEv2)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7296&eid=4387 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Yoav Nir >> >> Section: 3.7 >> >> Original Text >> ------------- >> The Certificate Request payload, denoted CERTREQ in this document, >> provides a means to request preferred certificates via IKE and can >> appear in the IKE_INIT_SA response and/or the IKE_AUTH request. >> Certificate Request payloads MAY be included in an exchange when the >> sender needs to get the certificate of the receiver. >> >> Corrected Text >> -------------- >> The Certificate Request payload, denoted CERTREQ in this document, >> provides a means to request preferred certificates via IKE and can >> appear in the IKE_SA_INIT response and/or the IKE_AUTH request. >> Certificate Request payloads MAY be included in an exchange when the >> sender needs to get the certificate of the receiver. >> >> Notes >> ----- >> IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) >> -------------------------------------- >> Title : Internet Key Exchange Protocol Version 2 (IKEv2) >> Publication Date : October 2014 >> Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen >> Category : INTERNET STANDARD >> Source : IP Security Maintenance and Extensions >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> > From nobody Fri Jun 5 13:50:16 2015 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 B28241B3213; Fri, 5 Jun 2015 13:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 gPSILpZxysru; Fri, 5 Jun 2015 13:50:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3641B321C; Fri, 5 Jun 2015 13:50:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150605205008.29974.73917.idtracker@ietfa.amsl.com> Date: Fri, 05 Jun 2015 13:50:08 -0700 Archived-At: Cc: ipsecme mailing list , ipsecme chair , RFC Editor Subject: [IPsec] Protocol Action: 'The NULL Authentication Method in IKEv2 Protocol' to Proposed Standard (draft-ietf-ipsecme-ikev2-null-auth-07.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: Fri, 05 Jun 2015 20:50:13 -0000 The IESG has approved the following document: - 'The NULL Authentication Method in IKEv2 Protocol' (draft-ietf-ipsecme-ikev2-null-auth-07.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ Technical Summary This document defines a new authentication mechanism for IKEv2, appropriately called "NULL". The NULL mechanism allows two IKE peers to establish either single-side or mutual authentication for those use cases where a peer is unwilling or unable to authenticate or identify itself. This is useful for using IPsec with opportunistic security without the need to sacrifice anonymity. The document also defines a new identification type, ID_NULL. Working Group Summary The working group had a fair amount of review of this draft and the draft has consensus. In my AD review, I requested changes to explicitly state that the draft Updates RFC4301. After discussion and agreement, this change was included. Document Quality There are at least 2 interoperable implementations - ELVIS-PLUS and libreswan. Personnel The Document Shepherd is Paul Hoffman and the Responsible Area Director is Kathleen Moriarty. From nobody Fri Jun 5 15:19:46 2015 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 0DFCC1A8AF9 for ; Fri, 5 Jun 2015 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 pF7nriaSZIoK for ; Fri, 5 Jun 2015 15:19:43 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 A7CF81A8BB3 for ; Fri, 5 Jun 2015 15:19:42 -0700 (PDT) Received: by wiam3 with SMTP id m3so32270983wia.1 for ; Fri, 05 Jun 2015 15:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1WKtXTSTKfwTh6n3HJwsL0/2Q/eOH6LlsqCavPh7Bx8=; b=D1cd1nUwgPucOVnCTeGy2TLAnJYi4ksctJgM516gYOcVnjDVH+3tRVb+E5MhJT0SRy hZfZBg9zFYX8Hy0oI4AvmKofHdm3GHJCfcDiFI4UmHOfBY6YxfjMpVZ1P5fZwAhkbPve XcLsFVlst5I4jYwIhGFruzGtf6Qne/UQgYgxUr0rWTU6HLpUDtTQdCTXFSiRIQgItO1N bQRAG8o4VmoErHMuONxmQHb12RnQvIDkS+bQv+sLvx/NieEl34KzN8c6sbLOFBTfkFSq iCyZYq2KycuqlpFYd9DVnEI76pWBszY+ZfQtzXP0I5xiOP5tUiglyy3LVTLRsJFjgpTK PL+A== MIME-Version: 1.0 X-Received: by 10.194.61.180 with SMTP id q20mr2129264wjr.80.1433542781500; Fri, 05 Jun 2015 15:19:41 -0700 (PDT) Received: by 10.28.148.148 with HTTP; Fri, 5 Jun 2015 15:19:41 -0700 (PDT) Date: Fri, 5 Jun 2015 18:19:41 -0400 Message-ID: From: Kathleen Moriarty To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=047d7ba9742443024f0517ccb04a Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08 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, 05 Jun 2015 22:19:45 -0000 --047d7ba9742443024f0517ccb04a Content-Type: text/plain; charset=UTF-8 Hi, Sorry this took me a bit of time to get to, I wanted to read through some of the background materials first and have been a bit swamped lately (should clear up soon). Anyway, I have a few comments from my review and also some from a developer. Please don't feel the need to respond over the weekend as I am sending this late on a Friday. First, thank you very much for your work on this draft. Having a standby cipher n hand is a good thing for algorithm agility. Hopefully we don't need it for some time. Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement that the initialization vector (part of the nonce) does not have to be unpredictable. That might be okay for chacha20 as long as you have uniqueness, but I thought POLY1305 required an unpredictable nonce (section 2.5 of rfc7539). It is not entirely clear to me where that value comes from in this description. Please let me know if I am missing something in section 2. o The Initialization Vector (IV) is 64-bit, and is used as part of the nonce. The IV MUST be unique for each invocation for a particular SA but does not need to be unpredictable. The use of a counter or a linear feedback shift register (LFSR) is RECOMMENDED. The IANA considerations list ENCR_CHACHA20_POLY1305 as the name of the algorithm without explanation in the draft. It appears that this was a WG decision: https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html An explanation might be helpful. Elsewhere in the draft, you just have AEAD_CHACHA20_POLY1305. I had another implementer of AEAD_CHACHA20_POLY1305 (but not for IPsec) read the draft and he commented that he didn't understand the term 'Standby cipher'. This was clear to me, but I read a lot of drafts. It might be helpful to expand on that a bit more since this came from a developer. He also requested that it would be helpful if the packet could be laid out to explain where the IV, ciphertext and tag go. This seems like a reasonable request and is from a developer. Thank you & have a nice weekend! -- Best regards, Kathleen --047d7ba9742443024f0517ccb04a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sorry this took me a bit of time to= get to, I wanted to read through some of the background materials first an= d have been a bit swamped lately (should clear up soon).=C2=A0 Anyway, I ha= ve a few comments from my review and also some from a developer.=C2=A0 Plea= se don't feel the need to respond over the weekend as I am sending this= late on a Friday.

First, thank you very much for = your work on this draft.=C2=A0 Having a standby cipher n hand is a good thi= ng for algorithm agility.=C2=A0 Hopefully we don't need it for some tim= e.


Section 2 talks about AEAD_= CHACHA20_POLY1305 and makes the statement that the initialization vector (p= art of the nonce) does not have to be unpredictable.=C2=A0 That might be ok= ay for chacha20 as long as you have uniqueness, but I thought POLY1305 requ= ired an unpredictable nonce (section 2.5 of rfc7539).=C2=A0 It is not entir= ely clear to me where that value comes from in this description.=C2=A0 Plea= se let me know if I am missing something in section 2.=C2=A0

=
=C2=A0 o =C2=A0The Initialization Vector (IV) is 64-bit, and is = used as part of
=C2=A0 =C2=A0 =C2=A0 the nonce.=C2=A0 The IV MUST= be unique for each invocation for a
=C2=A0 =C2=A0 =C2=A0 particu= lar SA but does not need to be unpredictable.=C2=A0 The use of a
= =C2=A0 =C2=A0 =C2=A0 counter or a linear feedback shift register (LFSR) is = RECOMMENDED.

The IANA considerations list ENCR_CHA= CHA20_POLY1305 as the name of the algorithm without explanation in the draf= t.=C2=A0 It appears that this was a WG decision:
An expla= nation might be helpful.=C2=A0 Elsewhere in the draft, you just have AEAD_C= HACHA20_POLY1305.

I had another implementer of AEA= D_CHACHA20_POLY1305 (but not for IPsec) read the draft and he commented tha= t he didn't understand the term 'Standby cipher'.=C2=A0 This wa= s clear to me, but I read a lot of drafts.=C2=A0 It might be helpful to exp= and on that a bit more since this came from a developer.

He also requested that it would be helpful if the packet could be la= id out to explain where the IV, ciphertext and tag go.=C2=A0 This seems lik= e a reasonable request and is from a developer.

Th= ank you & have a nice weekend!

--

Best regards,
Kathlee= n
--047d7ba9742443024f0517ccb04a-- From nobody Sat Jun 6 15:03:41 2015 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 9D91F1A03A5 for ; Sat, 6 Jun 2015 15:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 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, HTML_MESSAGE=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 6PDfAnl6_TxG for ; Sat, 6 Jun 2015 15:03:38 -0700 (PDT) Received: from mail-wg0-x244.google.com (mail-wg0-x244.google.com [IPv6:2a00:1450:400c:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39A41A03A2 for ; Sat, 6 Jun 2015 15:03:37 -0700 (PDT) Received: by wggy19 with SMTP id y19so7285415wgg.0 for ; Sat, 06 Jun 2015 15:03:36 -0700 (PDT) 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=adimCbHa6smE7NE0Ar7+Zach3G3nTDCqGo3IYtUxZIA=; b=CmW64Ou4r+SNdSqQOesctSyHGiHhwM3b4cBO7PDyAxJXJ2VlNehE1oEh8Q9jT3Sr3b 8Flu7zH1aZyEsGEeXdWOp+SV7BU1el0jeuIPzJdcz1QFY/dWmjtwyFpYvH3oitleGgPi MxOJsJTNA7C6UKvqk9W6F0UflV1/htgdA4LOcXu8fvDQNGESNQrjiHWa0wXRotMtoT1W +uGycKQYO9WMS6wEV9XlGrEU8Xf95/PI8X26Fa6r1leOb6j5KXaurAMOFdYOAojXow2+ cELYjHtu8bwMIxKaRdkIPXzxYVKUJpuGV+OHB/GMQmNLAib/rMXoLGpb7FMDYT68+GaX R9gA== X-Received: by 10.180.208.7 with SMTP id ma7mr8645888wic.0.1433628216319; Sat, 06 Jun 2015 15:03:36 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id q4sm16879591wja.24.2015.06.06.15.03.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jun 2015 15:03:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F6069F6-97E8-4A04-A664-64490241002D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Sun, 7 Jun 2015 01:03:32 +0300 Message-Id: References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08 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, 06 Jun 2015 22:03:40 -0000 --Apple-Mail=_2F6069F6-97E8-4A04-A664-64490241002D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Kathleen. Please see below > On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty = wrote: >=20 > Hi, >=20 > Sorry this took me a bit of time to get to, I wanted to read through = some of the background materials first and have been a bit swamped = lately (should clear up soon). Anyway, I have a few comments from my = review and also some from a developer. Please don't feel the need to = respond over the weekend as I am sending this late on a Friday. >=20 > First, thank you very much for your work on this draft. Having a = standby cipher n hand is a good thing for algorithm agility. Hopefully = we don't need it for some time. >=20 >=20 > Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement = that the initialization vector (part of the nonce) does not have to be = unpredictable. That might be okay for chacha20 as long as you have = uniqueness, but I thought POLY1305 required an unpredictable nonce = (section 2.5 of rfc7539). It is not entirely clear to me where that = value comes from in this description. Please let me know if I am = missing something in section 2.=20 The Poly1305 function does require a unique key. The way that we = generate this unique and unpredictable key is by running the ChaCha20 = block function with the same key and nonce, but with the block counter = set to zero and using the top 256 bits of the result as the one time = key. If ChaCha20 is a valid encryption function that has output = indistinguishable from random data, this makes the one-time Poly1305 key = unpredictable, even though the nonce is not unpredictable. The text for = that is at the bottom of page 3: The same key and nonce, along with a block counter of zero are passed to the ChaCha20 block function, and the top 256 bits of the result are used as the Poly1305 key. > o The Initialization Vector (IV) is 64-bit, and is used as part of > the nonce. The IV MUST be unique for each invocation for a > particular SA but does not need to be unpredictable. The use of = a > counter or a linear feedback shift register (LFSR) is = RECOMMENDED. >=20 > The IANA considerations list ENCR_CHACHA20_POLY1305 as the name of the = algorithm without explanation in the draft. It appears that this was a = WG decision: > https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html = > An explanation might be helpful. Elsewhere in the draft, you just = have AEAD_CHACHA20_POLY1305. Well AEAD_CHACHA20_POLY1305 is the code point already assigned to RFC = 7539 for the algorithm. = http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aead= -parameters-2 = As a side note, I have no idea what that registry is for. It assigns = numeric IDs to algorithms but those numeric IDs are never stored or = transmitted in any protocol. ENCR_CHACHA20_POLY1305 is the identifier we are requesting for use = within IKE. Perhaps I should change the last paragraph of section 2 as = follows: OLD: The encryption algorithm transform ID for negotiating this algorithm in IKE is TBA by IANA. NEW: The encryption algorithm transform ID for negotiating this algorithm in IKE is ENCR_CHACHA20_POLY1305 (number is TBA by IANA). >=20 > I had another implementer of AEAD_CHACHA20_POLY1305 (but not for = IPsec) read the draft and he commented that he didn't understand the = term 'Standby cipher'. This was clear to me, but I read a lot of = drafts. It might be helpful to expand on that a bit more since this = came from a developer. This is strange to me, because the second paragraph of the introduction = both discusses the need for a standby cipher and links to = draft-mcgrew-standby- = cipher. I = don=E2=80=99t know how to clarify this further. > He also requested that it would be helpful if the packet could be laid = out to explain where the IV, ciphertext and tag go. This seems like a = reasonable request and is from a developer. I guess this can be done. I wanted to keep the draft short by minimizing = copying and pasting diagrams from 4303 and 7296, but it=E2=80=99s no = great effort. Yoav --Apple-Mail=_2F6069F6-97E8-4A04-A664-64490241002D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Kathleen.

Please see below

On = Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi,

Sorry = this took me a bit of time to get to, I wanted to read through some of = the background materials first and have been a bit swamped lately = (should clear up soon).  Anyway, I have a few comments from my = review and also some from a developer.  Please don't feel the need = to respond over the weekend as I am sending this late on a = Friday.

First, = thank you very much for your work on this draft.  Having a standby = cipher n hand is a good thing for algorithm agility.  Hopefully we = don't need it for some time.


Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the = statement that the initialization vector (part of the nonce) does not = have to be unpredictable.  That might be okay for chacha20 as long = as you have uniqueness, but I thought POLY1305 required an unpredictable = nonce (section 2.5 of rfc7539).  It is not entirely clear to me = where that value comes from in this description.  Please let me = know if I am missing something in section = 2. 

The Poly1305 function does require a unique key. = The way that we generate this unique and unpredictable key is by running = the ChaCha20 block function with the same key and nonce, but with the = block counter set to zero and using the top 256 bits of the result as = the one time key. If ChaCha20 is a valid encryption function that has = output indistinguishable from random data, this makes the one-time = Poly1305 key unpredictable, even though the nonce is not unpredictable. =  The text for that is at the bottom of page 3:

   The =
same key and nonce, along with a block counter of zero are passed
   to the ChaCha20 block function, and the top 256 bits of the result
   are used as the Poly1305 key.


  o =  The Initialization Vector (IV) is 64-bit, and is used as part = of
      the nonce.  The IV = MUST be unique for each invocation for a
  =     particular SA but does not need to be unpredictable.  = The use of a
      counter or a = linear feedback shift register (LFSR) is RECOMMENDED.

The IANA considerations = list ENCR_CHACHA20_POLY1305 as the name of the algorithm without = explanation in the draft.  It appears that this was a WG = decision:
https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.ht= ml
An explanation might be helpful.  = Elsewhere in the draft, you just have = AEAD_CHACHA20_POLY1305.

Well AEAD_CHACHA20_POLY1305 is the code point already = assigned to RFC 7539 for the algorithm.
As a side note, I have no idea = what that registry is for. It assigns numeric IDs to algorithms but = those numeric IDs are never stored or transmitted in any = protocol.

ENCR_CHACHA20_POLY1305 is = the identifier we are requesting for use within IKE. Perhaps I should = change the last paragraph of section 2 as = follows:
OLD:
   The encryption algorithm transform ID for =
negotiating this algorithm
   in IKE is TBA by IANA.

NEW:
   The encryption algorithm transform ID for =
negotiating this algorithm
   in IKE is ENCR_CHACHA20_POLY1305 (number is TBA by IANA).

I had another implementer of = AEAD_CHACHA20_POLY1305 (but not for IPsec) read the draft and he = commented that he didn't understand the term 'Standby cipher'.  = This was clear to me, but I read a lot of drafts.  It might be = helpful to expand on that a bit more since this came from a = developer.

This is strange to me, because the second paragraph of = the introduction both discusses the need for a standby cipher and links = to draft-mcgrew-standby-cipher.  I don=E2=80=99t know = how to clarify this further.

He also requested that it would be helpful if = the packet could be laid out to explain where the IV, ciphertext and tag = go.  This seems like a reasonable request and is from a = developer.

I= guess this can be done. I wanted to keep the draft short by minimizing = copying and pasting diagrams from 4303 and 7296, but it=E2=80=99s no = great effort.

Yoav
= --Apple-Mail=_2F6069F6-97E8-4A04-A664-64490241002D-- From nobody Thu Jun 11 08:36:11 2015 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 044561AD333 for ; Thu, 11 Jun 2015 08:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 eADoXAvmF55g for ; Thu, 11 Jun 2015 08:36:09 -0700 (PDT) Received: from mail-wi0-x244.google.com (mail-wi0-x244.google.com [IPv6:2a00:1450:400c:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95661B2A83 for ; Thu, 11 Jun 2015 08:36:08 -0700 (PDT) Received: by wibbw19 with SMTP id bw19so3925258wib.2 for ; Thu, 11 Jun 2015 08:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=txtYbB3/xdeVVyCpqmNLSsuCbeEPqemcqdki+IUurEU=; b=U2UaC6PJk0kf/LQ35pbxpExqTuRxgdKjcwo1dGz4eiqpsZurzHaY/Tg8suxgyMu0nP eo1W8mAeLVprzEH6rE9h6vbY2b5iNzLejbmSOlfm4fSlarUSdoYmAOM//3hxhu7nnRma u8k/YL1xcmTB3yk8uS36svC5oDvfl2kKwiSzb3zQb6ka/9ph+K4ybVjpOFBiZhVqmS6M waXEtkavB8cnLVTR+PAZQU883mgTMpsshB8QGToyPkG0tk8LaN+2ZRGj7aMQBbEhaGXX X8S+JOR0hkPk3HwVujZboIPnGfi9cGmwYVOniWBrBSqvJd5p7p/Sx07uO4xClpk0OSsk yXgw== X-Received: by 10.194.21.232 with SMTP id y8mr18017458wje.36.1434036967459; Thu, 11 Jun 2015 08:36:07 -0700 (PDT) Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id pf4sm1590481wjb.23.2015.06.11.08.36.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jun 2015 08:36:06 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_0F9AA793-6180-4562-B4BE-38B89EB256E4" Message-Id: <39AE92BD-B1AE-49CF-A2A7-B415A244623A@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Thu, 11 Jun 2015 18:36:03 +0300 References: <20150611080126.29376.94702.idtracker@ietfa.amsl.com> To: IPsecME WG X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Simon Josefsson Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-curve25519-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: Thu, 11 Jun 2015 15:36:11 -0000 --Apple-Mail=_0F9AA793-6180-4562-B4BE-38B89EB256E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi I=E2=80=99ve submitted this draft, mostly based on Simon=E2=80=99s TLS = draft. CFRG is considering new curves for key agreement. So far, they=E2=80=99ve = selected Curve25519 and they might add another one. This draft requests = an identifier for this curve and standardizes payload format for IKE. Compared to NIST curves such as P-256, Curve25519 is faster and easier = to implement securely. It is now being used in SSH and TLS = (experimentally). I believe the security requirements of IKE and those = other protocols are very similar, so it makes sense to standardize this = here as well. My future plans for this draft: - Solicit feedback (that is this message) - Request adoption - Add examples - Request publication (only when CFRG is done, probably in parallel = with TLS) Yoav > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nir-ipsecme-curve25519-00.txt > Date: June 11, 2015 at 11:01:26 AM GMT+3 > To: "Yoav Nir" , "Simon Josefsson" = , "Yoav Nir" , "Simon = Josefsson" >=20 >=20 > A new version of I-D, draft-nir-ipsecme-curve25519-00.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. >=20 > Name: draft-nir-ipsecme-curve25519 > Revision: 00 > Title: Using Curve25519 for IKEv2 Key Agreement > Document date: 2015-06-11 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-nir-ipsecme-curve25519-00.txt > Status: = https://datatracker.ietf.org/doc/draft-nir-ipsecme-curve25519/ > Htmlized: = https://tools.ietf.org/html/draft-nir-ipsecme-curve25519-00 >=20 >=20 > Abstract: > This document describes the use of Curve25519 for ephemeral key > exchange in the Internet Key Exchange (IKEv2) protocol. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_0F9AA793-6180-4562-B4BE-38B89EB256E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

I=E2=80=99= ve submitted this draft, mostly based on Simon=E2=80=99s TLS = draft.

CFRG is = considering new curves for key agreement. So far, they=E2=80=99ve = selected Curve25519 and they might add another one. This draft requests = an identifier for this curve and standardizes payload format for = IKE.

Compared = to NIST curves such as P-256, Curve25519 is faster and easier to = implement securely. It is now being used in SSH and TLS = (experimentally). I believe the security requirements of IKE and those = other protocols are very similar, so it makes sense to standardize this = here as well.

My= future plans for this draft:
 - Solicit = feedback (that is this message)
 - Request = adoption
 - Add examples
 - Request publication (only when CFRG is done, probably = in parallel with TLS)

Yoav

Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-nir-ipsecme-curve25519-00.txt
Date: = June 11, 2015 at 11:01:26 AM = GMT+3
To: = "Yoav Nir" <ynir.ietf@gmail.com>, "Simon Josefsson" <simon@josefsson.org>, "Yoav Nir" <ynir.ietf@gmail.com>, "Simon Josefsson" <simon@josefsson.org>


A new version of I-D, = draft-nir-ipsecme-curve25519-00.txt
has been successfully = submitted by Yoav Nir and posted to the
IETF = repository.

Name: = draft-nir-ipsecme-curve25519
Revision: 00
Title:= = Using Curve25519 for IKEv2 Key Agreement
Document = date: = 2015-06-11
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-nir-ipsecme-curve255= 19-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-nir-ipsecme-curve25519/<= /a>
Htmlized:       https://tools.ietf.org/html/draft-nir-ipsecme-curve25519-00=


Abstract:
=   This document describes the use of Curve25519 for ephemeral = key
  exchange in the Internet Key Exchange = (IKEv2) protocol.




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


= --Apple-Mail=_0F9AA793-6180-4562-B4BE-38B89EB256E4-- From nobody Fri Jun 12 12:08:25 2015 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 29E5D1AD05F for ; Fri, 12 Jun 2015 12:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 KNR_EekB3NWc for ; Fri, 12 Jun 2015 12:08:21 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 174531AD05B for ; Fri, 12 Jun 2015 12:08:21 -0700 (PDT) Received: by wgez8 with SMTP id z8so30335987wge.0 for ; Fri, 12 Jun 2015 12:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NVCHsD/f710eiUn6L+p27YgbkkfoCg+yCei7R+Vv1s8=; b=XLQGNFrA0DOP5XBstQzwZQSrNuQYhCtIOmUzD5eA8YcU9/ho9Lyx2H5plE46IZk0vU lEsR4aZH7xUXHF8KScTYtqhjLd9dCMzbNu1yJ94Txa/fifadKI12m+ISV2/b+XO/Bold BWMn9wbLhW9LqIfoLSIahVEGQ87tpWtGzCK64oTGARJeUgO+mEMjeqwRO8R7EdU8nz0r yEhjjpEk7ntWwp+hBYY5vSggxzpDSZUw2jzn1a/bXNtMJqV1ygK5K+E9qeyVyzKbcxFC 5sZDd8HgibUd97XYnLrjW737F/8cnmcbHWluH2eQsJmilN34I3DT0yNoTQ2X3gwEnClD u/3A== MIME-Version: 1.0 X-Received: by 10.180.86.168 with SMTP id q8mr9408226wiz.80.1434136099795; Fri, 12 Jun 2015 12:08:19 -0700 (PDT) Received: by 10.28.148.148 with HTTP; Fri, 12 Jun 2015 12:08:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jun 2015 15:08:19 -0400 Message-ID: From: Kathleen Moriarty To: Yoav Nir Content-Type: multipart/alternative; boundary=bcaec5555030c9b810051856d41d Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08 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, 12 Jun 2015 19:08:24 -0000 --bcaec5555030c9b810051856d41d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav, Once again, sorry for the delay! My schedule should start to get better in a couple of weeks. On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir wrote: > Hi, Kathleen. > > Please see below > > On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Hi, > > Sorry this took me a bit of time to get to, I wanted to read through some > of the background materials first and have been a bit swamped lately > (should clear up soon). Anyway, I have a few comments from my review and > also some from a developer. Please don't feel the need to respond over t= he > weekend as I am sending this late on a Friday. > > First, thank you very much for your work on this draft. Having a standby > cipher n hand is a good thing for algorithm agility. Hopefully we don't > need it for some time. > > > Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement that > the initialization vector (part of the nonce) does not have to be > unpredictable. That might be okay for chacha20 as long as you have > uniqueness, but I thought POLY1305 required an unpredictable nonce (secti= on > 2.5 of rfc7539). It is not entirely clear to me where that value comes > from in this description. Please let me know if I am missing something i= n > section 2. > > > The Poly1305 function does require a unique key. The way that we generate > this unique and unpredictable key is by running the ChaCha20 block functi= on > with the same key and nonce, but with the block counter set to zero and > using the top 256 bits of the result as the one time key. If ChaCha20 is = a > valid encryption function that has output indistinguishable from random > data, this makes the one-time Poly1305 key unpredictable, even though the > nonce is not unpredictable. The text for that is at the bottom of page 3= : > > The same key and nonce, along with a block counter of zero are passed > to the ChaCha20 block function, and the top 256 bits of the result > are used as the Poly1305 key. > > Right, but the RFC7539 for POLY1305, the nonce must be unpredictable. If you are feeding in the same nonce used for chacha, then it should also be unpredictable. > > > o The Initialization Vector (IV) is 64-bit, and is used as part of > the nonce. The IV MUST be unique for each invocation for a > particular SA but does not need to be unpredictable. The use of a > counter or a linear feedback shift register (LFSR) is RECOMMENDED. > > The IANA considerations list ENCR_CHACHA20_POLY1305 as the name of the > algorithm without explanation in the draft. It appears that this was a W= G > decision: > https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html > An explanation might be helpful. Elsewhere in the draft, you just have > AEAD_CHACHA20_POLY1305. > > > Well AEAD_CHACHA20_POLY1305 is the code point already assigned to RFC 753= 9 > for the algorithm. > > http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aea= d-parameters-2 > As a side note, I have no idea what that registry is for. It assigns > numeric IDs to algorithms but those numeric IDs are never stored or > transmitted in any protocol. > > ENCR_CHACHA20_POLY1305 is the identifier we are requesting for use within > IKE. Perhaps I should change the last paragraph of section 2 as follows: > OLD: > > The encryption algorithm transform ID for negotiating this algorithm > in IKE is TBA by IANA. > > > NEW: > > The encryption algorithm transform ID for negotiating this algorithm > in IKE is ENCR_CHACHA20_POLY1305 (number is TBA by IANA). > > That's better. It should appear somewhere to explain what it is before the IANA section, thanks! > > > I had another implementer of AEAD_CHACHA20_POLY1305 (but not for IPsec) > read the draft and he commented that he didn't understand the term 'Stand= by > cipher'. This was clear to me, but I read a lot of drafts. It might be > helpful to expand on that a bit more since this came from a developer. > > > This is strange to me, because the second paragraph of the introduction > both discusses the need for a standby cipher and links to > draft-mcgrew-standby- > cipher. I don= =E2=80=99t > know how to clarify this further. > OK, I was fine with the text. We can leave it and see if it comes up by any other reviewer. > > He also requested that it would be helpful if the packet could be laid ou= t > to explain where the IV, ciphertext and tag go. This seems like a > reasonable request and is from a developer. > > > I guess this can be done. I wanted to keep the draft short by minimizing > copying and pasting diagrams from 4303 and 7296, but it=E2=80=99s no grea= t effort. > Thank you! It just makes the draft have more pages and could be helpful to developers. > > Yoav > > --=20 Best regards, Kathleen --bcaec5555030c9b810051856d41d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yoav,

Once again, sorry for the dela= y!=C2=A0 My schedule should start to get better in a couple of weeks.
=

On Sat, Jun 6, 20= 15 at 6:03 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Kathle= en.

Please see below

On Jun 6, 2015, at 1:19 AM, Kathleen Moriar= ty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi,

Sorry this took me a bit of time to get to, I = wanted to read through some of the background materials first and have been= a bit swamped lately (should clear up soon).=C2=A0 Anyway, I have a few co= mments from my review and also some from a developer.=C2=A0 Please don'= t feel the need to respond over the weekend as I am sending this late on a = Friday.

First, thank you very much for your work o= n this draft.=C2=A0 Having a standby cipher n hand is a good thing for algo= rithm agility.=C2=A0 Hopefully we don't need it for some time.


Section 2 talks about AEAD_CHACHA20_PO= LY1305 and makes the statement that the initialization vector (part of the = nonce) does not have to be unpredictable.=C2=A0 That might be okay for chac= ha20 as long as you have uniqueness, but I thought POLY1305 required an unp= redictable nonce (section 2.5 of rfc7539).=C2=A0 It is not entirely clear t= o me where that value comes from in this description.=C2=A0 Please let me k= now if I am missing something in section 2.=C2=A0

The Poly1305 function does require a = unique key. The way that we generate this unique and unpredictable key is b= y running the ChaCha20 block function with the same key and nonce, but with= the block counter set to zero and using the top 256 bits of the result as = the one time key. If ChaCha20 is a valid encryption function that has outpu= t indistinguishable from random data, this makes the one-time Poly1305 key = unpredictable, even though the nonce is not unpredictable.=C2=A0 The text f= or that is at the bottom of page 3:

   The same key and nonce,=
 along with a block counter of zero are passed
   to the ChaCha20 block function, and the top 256 bits of the result
   are used as the Poly1305 key.
=

Right, but the RFC7539 for POLY1305, the nonce must be = unpredictable.=C2=A0 If you are feeding in the same nonce used for chacha, = then it should also be unpredictable.=C2=A0


=
=C2=A0 o =C2=A0The Initialization Vector (IV) is 64-bit, and is used as par=
t of
=C2=A0 =C2=A0 =C2=A0 the nonce.=C2=A0 The IV MUST be unique =
for each invocation for a
=C2=A0 =C2=A0 =C2=A0 particular SA but =
does not need to be unpredictable.=C2=A0 The use of a
=C2=A0 =C2=
=A0 =C2=A0 counter or a linear feedback shift register (LFSR) is RECOMMENDE=
D.

The IANA considerations list ENCR_CHACHA20_POLY=
1305 as the name of the algorithm without explanation in the draft.=C2=A0 I=
t appears that this was a WG decision:
=
An explanation might be helpful.=C2=A0 Elsewhere in the draft, you just hav=
e AEAD_CHACHA20_POLY1305.

Well AEAD_CHACHA20_POLY1305 is the code point already assigned to =
RFC 7539 for the algorithm.
As a side note, I have no idea what that r=
egistry is for. It assigns numeric IDs to algorithms but those numeric IDs =
are never stored or transmitted in any protocol.

E=
NCR_CHACHA20_POLY1305 is the identifier we are requesting for use within IK=
E. Perhaps I should change the last paragraph of section 2 as follows:
OLD:
   The encryption algorithm transform ID for negotiating this algo=
rithm
   in IKE is TBA by IANA.

NEW:
   The encrypti=
on algorithm transform ID for negotiating this algorithm
   in IKE is ENCR_CHACHA20_POLY1305 (number is TBA by IANA).

That's better.=C2=A0 It shoul=
d appear somewhere to explain what it is before the IANA section, thanks!=
=C2=A0


I had another implementer of AE=
AD_CHACHA20_POLY1305 (but not for IPsec) read the draft and he commented th=
at he didn't understand the term 'Standby cipher'.=C2=A0 This w=
as clear to me, but I read a lot of drafts.=C2=A0 It might be helpful to ex=
pand on that a bit more since this came from a developer.
=


This is strange to me, because the=
 second paragraph of the introduction both discusses the need for a standby=
 cipher and links to=C2=A0draft-mcgrew-standby-cipher.=C2=A0=
 I don=E2=80=99t know how to clarify this further.

OK, I was fine with the text.=C2=A0 We can leave =
it and see if it comes up by any other reviewer.=C2=A0

He also=
 requested that it would be helpful if the packet could be laid out to expl=
ain where the IV, ciphertext and tag go.=C2=A0 This seems like a reasonable=
 request and is from a developer.
=

I guess this can be done. I wanted to keep the draft short=
 by minimizing copying and pasting diagrams from 4303 and 7296, but it=E2=
=80=99s no great effort.

=
Thank you!=C2=A0 It just makes the draft have more pages and could be helpf=
ul to developers.=C2=A0

Yoav

<=
br>

-- 
<=
div dir=3D"ltr">
Best regards,
Kathleen



--bcaec5555030c9b810051856d41d--


From nobody Fri Jun 12 12:33:47 2015
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 A1B081AD1BA for ; Fri, 12 Jun 2015 12:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 G8yFUFCZf7yk for ; Fri, 12 Jun 2015 12:33:44 -0700 (PDT)
Received: from mail-wg0-x242.google.com (mail-wg0-x242.google.com [IPv6:2a00:1450:400c:c00::242]) (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 72A5D1AD1DB for ; Fri, 12 Jun 2015 12:33:43 -0700 (PDT)
Received: by wggx12 with SMTP id x12so2474048wgg.1 for ; Fri, 12 Jun 2015 12:33:42 -0700 (PDT)
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=FRlbQh9iev3N7giR251LLWlehO/neFmTYQ5sQLo2/cg=; b=ZejqF6uqRd7Cw6ZB+IcK71s8UV8+DiWYaC6zbNFFW+3a4QpQVIRuiJdwp4QfihK81w vwDMN/8aqkPzAJrGvhENUtI6kUHtKWC4kpLQ6tYcoesESOxc/3Stsqfnef+kqShstnRp bdPsdmQInRIBWCeJIdAbhQSur+f20qLRFFtIuCoe4X+VrcOVFyx9gS1GOD25pr0Ok+PA RuGEVcpMKaj4xVi5yj3ZCJrMjFWHdmknaafQ5QFjM2+89PA7ajvwrBRje9x/bHDmcY2I XDAwlGeZczG8XoB9qet7v/VzpTUiMuWIr9ehlDLi7MAQ354zl7ZLZObbJ2RQkQNhFkcE RRiA==
X-Received: by 10.194.172.130 with SMTP id bc2mr29651728wjc.85.1434137622191;  Fri, 12 Jun 2015 12:33:42 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id i6sm7178381wjf.29.2015.06.12.12.33.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 12:33:41 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B85C4A4F-2A2F-4B90-86F9-AC9FBE909113"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir 
In-Reply-To: 
Date: Fri, 12 Jun 2015 22:33:38 +0300
Message-Id: 
References:   
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08
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, 12 Jun 2015 19:33:45 -0000

--Apple-Mail=_B85C4A4F-2A2F-4B90-86F9-AC9FBE909113
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty =
 wrote:
>=20
> Hi Yoav,
>=20
> Once again, sorry for the delay!  My schedule should start to get =
better in a couple of weeks.
>=20
> On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir > wrote:
> Hi, Kathleen.
>=20
> Please see below
>=20
>> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty =
> wrote:
>>=20
>> Hi,
>>=20
>> Sorry this took me a bit of time to get to, I wanted to read through =
some of the background materials first and have been a bit swamped =
lately (should clear up soon).  Anyway, I have a few comments from my =
review and also some from a developer.  Please don't feel the need to =
respond over the weekend as I am sending this late on a Friday.
>>=20
>> First, thank you very much for your work on this draft.  Having a =
standby cipher n hand is a good thing for algorithm agility.  Hopefully =
we don't need it for some time.
>>=20
>>=20
>> Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement =
that the initialization vector (part of the nonce) does not have to be =
unpredictable.  That might be okay for chacha20 as long as you have =
uniqueness, but I thought POLY1305 required an unpredictable nonce =
(section 2.5 of rfc7539).  It is not entirely clear to me where that =
value comes from in this description.  Please let me know if I am =
missing something in section 2.=20
>=20
> The Poly1305 function does require a unique key. The way that we =
generate this unique and unpredictable key is by running the ChaCha20 =
block function with the same key and nonce, but with the block counter =
set to zero and using the top 256 bits of the result as the one time =
key. If ChaCha20 is a valid encryption function that has output =
indistinguishable from random data, this makes the one-time Poly1305 key =
unpredictable, even though the nonce is not unpredictable.  The text for =
that is at the bottom of page 3:
>=20
>    The same key and nonce, along with a block counter of zero are =
passed
>    to the ChaCha20 block function, and the top 256 bits of the result
>    are used as the Poly1305 key.
>=20
> Right, but the RFC7539 for POLY1305, the nonce must be unpredictable.  =
If you are feeding in the same nonce used for chacha, then it should =
also be unpredictable.=20

Ah, I see the source of the confusion. Poly1305 does not get a nonce at =
all. It gets a one-time key. You could generate this one-time =
(unpredictable) key in many ways, but the way we do it here is by =
encrypting the (predictable) nonce using ChaCha20. This is similar to =
the practice of generating a random 128-bit value, and using that as an =
AES key, and encrypting a counter to generate unpredictable values (such =
as initialization vectors).

So it=E2=80=99s fine for the nonce to be predictable as long as the =
encrypted nonce is not.

I=E2=80=99ll make the rest of the changes soon.

Yoav


--Apple-Mail=_B85C4A4F-2A2F-4B90-86F9-AC9FBE909113
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi Yoav,

Once again, sorry for =
the delay!  My schedule should start to get better in a couple of =
weeks.

On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Kathleen.

Please see =
below

On Jun =
6, 2015, at 1:19 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi,

Sorry this took me a bit =
of time to get to, I wanted to read through some of the background =
materials first and have been a bit swamped lately (should clear up =
soon).  Anyway, I have a few comments from my review and also some =
from a developer.  Please don't feel the need to respond over the =
weekend as I am sending this late on a Friday.

First, thank you very much for your =
work on this draft.  Having a standby cipher n hand is a good thing =
for algorithm agility.  Hopefully we don't need it for some =
time.


Section 2 talks about =
AEAD_CHACHA20_POLY1305 and makes the statement that the initialization =
vector (part of the nonce) does not have to be unpredictable.  That =
might be okay for chacha20 as long as you have uniqueness, but I thought =
POLY1305 required an unpredictable nonce (section 2.5 of rfc7539).  =
It is not entirely clear to me where that value comes from in this =
description.  Please let me know if I am missing something in =
section 2. 

The Poly1305 function does =
require a unique key. The way that we generate this unique and =
unpredictable key is by running the ChaCha20 block function with the =
same key and nonce, but with the block counter set to zero and using the =
top 256 bits of the result as the one time key. If ChaCha20 is a valid =
encryption function that has output indistinguishable from random data, =
this makes the one-time Poly1305 key unpredictable, even though the =
nonce is not unpredictable.  The text for that is at the bottom of =
page 3:

   The same key and nonce, along with a block counter of zero =
are passed
   to the ChaCha20 block function, and the top 256 bits of the result
   are used as the Poly1305 =
key.

Right, but the RFC7539 for POLY1305, =
the nonce must be unpredictable.  If you are feeding in the same =
nonce used for chacha, then it should also be =
unpredictable. 

Ah, I see the source of the confusion. Poly1305 =
does not get a nonce at all. It gets a one-time key. You could generate =
this one-time (unpredictable) key in many ways, but the way we do it =
here is by encrypting the (predictable) nonce using ChaCha20. This is =
similar to the practice of generating a random 128-bit value, and using =
that as an AES key, and encrypting a counter to generate unpredictable =
values (such as initialization vectors).

So it=E2=80=99s fine for the nonce to be =
predictable as long as the encrypted nonce is not.

I=E2=80=99ll make the rest of the changes =
soon.

Yoav

=

--Apple-Mail=_B85C4A4F-2A2F-4B90-86F9-AC9FBE909113--


From nobody Fri Jun 12 13:23:14 2015
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 9672C1B2A55 for ; Fri, 12 Jun 2015 13:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Level: 
X-Spam-Status: No, score=0.623 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 TzUzgQmB7IiZ for ; Fri, 12 Jun 2015 13:23:11 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 8EFDD1B2A53 for ; Fri, 12 Jun 2015 13:23:11 -0700 (PDT)
Received: by wgzl5 with SMTP id l5so6252878wgz.3 for ; Fri, 12 Jun 2015 13:23:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ItLpcZojcSxw6eZ/7zsIIXVZDetTXgrWC3s7BI5/DZ4=; b=wUMHsojOF2KlapnjtKVnhYZPD1qhW/918Oz8J+gwuK4m5+Nhw9VeGSP0uA8sPdA5b1 8s2pGuc6u6hClsZw7auefvSH7cdyjW6pxVrduXHGFk+g6XwLY0D45sKcVrKb/2V/2iFZ 6OrWUwFHaABGMugG1I2kWACGUvZvN02HOTkWHzSDPhwe3w3ig2a2mFVyqn7yFkZiFS6b 9V83ch+5CDGGnEON6AxYu/qZhWGNMJnIjcoBS1QMmMpYJwDOocyFt2ua32vQgSa3nfcL KLc+dLSLs2VaXugSR5MKnP83SfrvxHRxKtkm4UgyLhbWlgyVz9M8CgqpYYxozyCQ/I3v CnMA==
X-Received: by 10.180.103.194 with SMTP id fy2mr10390698wib.55.1434140590371;  Fri, 12 Jun 2015 13:23:10 -0700 (PDT)
Received: from [10.0.0.6] (bzq-79-176-172-139.red.bezeqint.net. [79.176.172.139]) by mx.google.com with ESMTPSA id f8sm4240837wiy.7.2015.06.12.13.23.08 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2015 13:23:09 -0700 (PDT)
Message-ID: <557B3FAB.40408@gmail.com>
Date: Fri, 12 Jun 2015 23:23:07 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: ipsec 
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [IPsec] IPsecME: agenda items for Prague
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, 12 Jun 2015 20:23:12 -0000


  

    
    
  
  
    Hi,

    

    Paul and I are working on our agenda for the upcoming meeting. We
    have a 1 hr slot planned. If you'd like to claim part of it, do let
    us know.

    

    Thanks,

        Yaron

  



From nobody Fri Jun 12 16:02:14 2015
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 BF4171A1C02 for ; Fri, 12 Jun 2015 16:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 H508-b1roxyL for ; Fri, 12 Jun 2015 16:02:11 -0700 (PDT)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 150501A1BD7 for ; Fri, 12 Jun 2015 16:02:11 -0700 (PDT)
Received: by wgv5 with SMTP id 5so32714370wgv.1 for ; Fri, 12 Jun 2015 16:02:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jXSWm5jn8aEquavHObNHswZusQ/WiOaUJ71ipV/UAlk=; b=x+ts2xeDqUJ4xrVfJUQ+JrFdjmvBRP0iaHhFsotiZ5l+KIf7WWCqR9j6mBeFARoIQ/ zjiCTRvfB84EL2nZMncpsP97RXa4k7o/fQAUZuEO+aj0WcU9UYOohKGPXQIn2G2hppyF P4KbbwAlvTG6vmj+ManUigrTfA+EBym3+75v4k4s5oUpAE51o5C9rMs9fnCSjx+D0uAu RQteDnQaFCJF+qoSnu8pNqAfuMg5K3SMFqcHXoBTiMjXZG0MuYOo5leOo2xtiFQMg5LD 1KeY4JzWts/ZCZQM6UrgoaA29tJjwoS6dHCHh9SSvXAbbEDz75gveLZAogLin8mAhlTv ADnQ==
MIME-Version: 1.0
X-Received: by 10.180.86.73 with SMTP id n9mr10767293wiz.78.1434150129840; Fri, 12 Jun 2015 16:02:09 -0700 (PDT)
Received: by 10.28.148.148 with HTTP; Fri, 12 Jun 2015 16:02:09 -0700 (PDT)
In-Reply-To: 
References:    
Date: Fri, 12 Jun 2015 19:02:09 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=f46d0442806e0b36eb05185a19e7
Archived-At: 
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08
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, 12 Jun 2015 23:02:13 -0000

--f46d0442806e0b36eb05185a19e7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yoav,

On Fri, Jun 12, 2015 at 3:33 PM, Yoav Nir  wrote:

>
> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
> Hi Yoav,
>
> Once again, sorry for the delay!  My schedule should start to get better
> in a couple of weeks.
>
> On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir  wrote:
>
>> Hi, Kathleen.
>>
>> Please see below
>>
>> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <
>> kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> Hi,
>>
>> Sorry this took me a bit of time to get to, I wanted to read through som=
e
>> of the background materials first and have been a bit swamped lately
>> (should clear up soon).  Anyway, I have a few comments from my review an=
d
>> also some from a developer.  Please don't feel the need to respond over =
the
>> weekend as I am sending this late on a Friday.
>>
>> First, thank you very much for your work on this draft.  Having a standb=
y
>> cipher n hand is a good thing for algorithm agility.  Hopefully we don't
>> need it for some time.
>>
>>
>> Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement tha=
t
>> the initialization vector (part of the nonce) does not have to be
>> unpredictable.  That might be okay for chacha20 as long as you have
>> uniqueness, but I thought POLY1305 required an unpredictable nonce (sect=
ion
>> 2.5 of rfc7539).  It is not entirely clear to me where that value comes
>> from in this description.  Please let me know if I am missing something =
in
>> section 2.
>>
>>
>> The Poly1305 function does require a unique key. The way that we generat=
e
>> this unique and unpredictable key is by running the ChaCha20 block funct=
ion
>> with the same key and nonce, but with the block counter set to zero and
>> using the top 256 bits of the result as the one time key. If ChaCha20 is=
 a
>> valid encryption function that has output indistinguishable from random
>> data, this makes the one-time Poly1305 key unpredictable, even though th=
e
>> nonce is not unpredictable.  The text for that is at the bottom of page =
3:
>>
>>    The same key and nonce, along with a block counter of zero are passed
>>    to the ChaCha20 block function, and the top 256 bits of the result
>>    are used as the Poly1305 key.
>>
>>
> Right, but the RFC7539 for POLY1305, the nonce must be unpredictable.  If
> you are feeding in the same nonce used for chacha, then it should also be
> unpredictable.
>
>
> Ah, I see the source of the confusion. Poly1305 does not get a nonce at
> all. It gets a one-time key. You could generate this one-time
> (unpredictable) key in many ways, but the way we do it here is by
> encrypting the (predictable) nonce using ChaCha20. This is similar to the
> practice of generating a random 128-bit value, and using that as an AES
> key, and encrypting a counter to generate unpredictable values (such as
> initialization vectors).
>
OK, so the difference here is that the method you are using is in section
2.6 and I was looking at the requirements for POLY1305 from section 2.5,
which uses a different method.


>
>
So it=E2=80=99s fine for the nonce to be predictable as long as the encrypt=
ed nonce
> is not.
>
> I=E2=80=99ll make the rest of the changes soon.
>

Thank you!  I'll look for the update to kick-start last call.
Kathleen

>
> Yoav
>
>


--=20

Best regards,
Kathleen

--f46d0442806e0b36eb05185a19e7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Yoav,

On Fri, Jun 12, 2015 at 3:33 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:


Hi Yoav,

=

Once again, sorry for the delay!=C2=A0 My schedule should start =
to get better in a couple of weeks.

On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir=C2=
=A0<ynir.ietf@gmail.com>=C2=A0wrote:
Hi, Kathleen.
Please see below

On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <kathleen.moriarty.i=
etf@gmail.com> wrote:

Hi,

Sorry this took me a bit of time to get to, I wanted to read throug=
h some of the background materials first and have been a bit swamped lately=
 (should clear up soon).=C2=A0 Anyway, I have a few comments from my review=
 and also some from a developer.=C2=A0 Please don't feel the need to re=
spond over the weekend as I am sending this late on a Friday.
First, thank you very much for your work on this draft.=C2=A0 H=
aving a standby cipher n hand is a good thing for algorithm agility.=C2=A0 =
Hopefully we don't need it for some time.


=

Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the =
statement that the initialization vector (part of the nonce) does not have =
to be unpredictable.=C2=A0 That might be okay for chacha20 as long as you h=
ave uniqueness, but I thought POLY1305 required an unpredictable nonce (sec=
tion 2.5 of rfc7539).=C2=A0 It is not entirely clear to me where that value=
 comes from in this description.=C2=A0 Please let me know if I am missing s=
omething in section 2.=C2=A0

<=
/div>
The Poly1305 function does require a unique key. The way t=
hat we generate this unique and unpredictable key is by running the ChaCha2=
0 block function with the same key and nonce, but with the block counter se=
t to zero and using the top 256 bits of the result as the one time key. If =
ChaCha20 is a valid encryption function that has output indistinguishable f=
rom random data, this makes the one-time Poly1305 key unpredictable, even t=
hough the nonce is not unpredictable.=C2=A0 The text for that is at the bot=
tom of page 3:

   The same key and nonce, along with a block c=
ounter of zero are passed
   to the ChaCha20 block function, and the top 256 bits of the result
   are used as the Poly1305 key.
=


Right, but the RFC7539 for POLY1305, the nonce must be =
unpredictable.=C2=A0 If you are feeding in the same nonce used for chacha, =
then it should also be unpredictable.=C2=A0

Ah, I see the source of the confusion=
. Poly1305 does not get a nonce at all. It gets a one-time key. You could g=
enerate this one-time (unpredictable) key in many ways, but the way we do i=
t here is by encrypting the (predictable) nonce using ChaCha20. This is sim=
ilar to the practice of generating a random 128-bit value, and using that a=
s an AES key, and encrypting a counter to generate unpredictable values (su=
ch as initialization vectors).
OK, so the difference here is that the method you are using is in section=
 2.6 and I was looking at the requirements for POLY1305 from section 2.5, w=
hich uses a different method.
=C2=A0
=C2=A0
So it=E2=80=99s fine for the nonce t=
o be predictable as long as the encrypted nonce is not.

I=E2=80=99ll make the rest of the changes soon.

Thank you!=C2=A0 I'll look for the update =
to kick-start last call.
Kathleen=C2=A0
=


Yoav




-- 

Best regar=
ds,
Kathleen




--f46d0442806e0b36eb05185a19e7--


From nobody Sat Jun 13 23:47:40 2015
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 232591B2AD6; Sat, 13 Jun 2015 23:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bjyV5ic6_Xqt; Sat, 13 Jun 2015 23:47:37 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5612B1B2B4A; Sat, 13 Jun 2015 23:46:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150614064621.15901.47260.idtracker@ietfa.amsl.com>
Date: Sat, 13 Jun 2015 23:46:21 -0700
Archived-At: 
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.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: Sun, 14 Jun 2015 06:47:39 -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           : ChaCha20, Poly1305 and their use in IKE & IPsec
        Author          : Yoav Nir
	Filename        : draft-ietf-ipsecme-chacha20-poly1305-09.txt
	Pages           : 12
	Date            : 2015-06-13

Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and for IPsec.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-09


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 Sun Jun 14 00:37:19 2015
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 77F471A19F2 for ; Sun, 14 Jun 2015 00:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 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=0.001, 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 s_RBS2tABcTf for ; Sun, 14 Jun 2015 00:37:13 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 49FEC1A07BD for ; Sun, 14 Jun 2015 00:37:13 -0700 (PDT)
Received: by wibdq8 with SMTP id dq8so49073327wib.1 for ; Sun, 14 Jun 2015 00:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bwNx9mQmuTBGe4GGD58cEuLAkbfSsMZVOfOvsHAx6WQ=; b=JMuJQ/KvYk2qBUtYY+swalgpAEl84b60RorJxYq1F3CaNwYPKqY/wTzRgmQK5ny01M 674sKCE/Ta1OT/XOZtPPRnVEd+M7BD/SwzrkDR/KN7jY+5EPttsYJ7FaCFEJ2oI9Khd5 40dqqDK8yP0uf/MHwbMHq27oHoECErb/gycV2jSqVunkuALzn3gBw5r5JIfy3wILCX3l KnsjKbv3D2T3SnG9+ya9R81CKq6Wt8xP/uFaW7rblpMx9F4qiUZGra6BB0X2i1ynuDaL zl4z+sCJ6HoEg+N1/RpDu3DlR1hl3xZ3VU59ka0fGmM7q8/gB6OigvEvSKrMTGV+L1qJ kXzg==
X-Received: by 10.180.99.39 with SMTP id en7mr21230017wib.31.1434267431942; Sun, 14 Jun 2015 00:37:11 -0700 (PDT)
Received: from [192.168.12.102] (bzq-218-112-74.red.bezeqint.net. [81.218.112.74]) by mx.google.com with ESMTPSA id wi1sm13418957wjb.41.2015.06.14.00.37.10 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jun 2015 00:37:10 -0700 (PDT)
Message-ID: <557D2F25.8060607@gmail.com>
Date: Sun, 14 Jun 2015 10:37:09 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
CC: ipsec@ietf.org
References: <20150614064621.15901.47260.idtracker@ietfa.amsl.com>
In-Reply-To: <20150614064621.15901.47260.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.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: Sun, 14 Jun 2015 07:37:17 -0000

Quick nit: the sentence "The Pad Length field need not exceed 4 octets" 
is a bit confusing, because the Pad Length field is obviously a constant 
2 octets. I would suggest "The Padding field's length (and the value of 
the Pad Length field) need not exceed 4 octets."

Thanks,
	Yaron

On 06/14/2015 09:46 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           : ChaCha20, Poly1305 and their use in IKE & IPsec
>          Author          : Yoav Nir
> 	Filename        : draft-ietf-ipsecme-chacha20-poly1305-09.txt
> 	Pages           : 12
> 	Date            : 2015-06-13
>
> Abstract:
>     This document describes the use of the ChaCha20 stream cipher along
>     with the Poly1305 authenticator, combined into an AEAD algorithm for
>     the Internet Key Exchange protocol (IKEv2) and for IPsec.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-09
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


From nobody Sun Jun 14 04:11:33 2015
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 4622A1B2CBA for ; Sun, 14 Jun 2015 04:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ox3Q_oDZ3HrG for ; Sun, 14 Jun 2015 04:11:29 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 71B541B2CB9 for ; Sun, 14 Jun 2015 04:11:29 -0700 (PDT)
Received: by wiga1 with SMTP id a1so51459496wig.0 for ; Sun, 14 Jun 2015 04:11:28 -0700 (PDT)
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=x+kTRkjqFlKCdy42e0nnKWiPDOzNlUa50vLTGW55k+g=; b=FHdM87n9eLCKsTFt4acYXvzCzNx7x+fqzUr4dZJGPzNZqJNfDlsy0RYrTDM6PLRGXr 2qtp53z8QQrjz452L3om4pn9wBxWyQ0TEtTiLrqWLWJmZH8bB/lvFWuD3LerukgoyG6V X20CwufQ2fRAdBZKbzm0E33j/dkgzQqFzkwI8Bzc6wRpYsHhdi1xqFeZSBPDgLLXoikm TW/Ply+YYlD/CuFR8iCM+Vi2a0TlrdpxEjcnJobviZlcO1WpthNvr4FHEcJN7bRB/xRq Au/Vcp/8uMlnNIVu0v2e/sO51vL7YHPqRTVXvu4oLUjakhmeibcFYe1Xm9y5MAH1yWx3 /vVQ==
X-Received: by 10.194.23.106 with SMTP id l10mr3731479wjf.1.1434280288173; Sun, 14 Jun 2015 04:11:28 -0700 (PDT)
Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id n8sm10952969wiy.19.2015.06.14.04.11.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jun 2015 04:11:25 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir 
In-Reply-To: <557D2F25.8060607@gmail.com>
Date: Sun, 14 Jun 2015 14:11:21 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150614064621.15901.47260.idtracker@ietfa.amsl.com> <557D2F25.8060607@gmail.com>
To: Yaron Sheffer 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.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: Sun, 14 Jun 2015 11:11:31 -0000

How about:

OLD:
   The Pad Length field need not exceed 4 octets. However, RFC 4303 and =
this specification do not=20
   prohibit using greater pad lengths.

NEW:
   The length of the Padding field need not exceed 4 octets. However, =
neither RFC 4303 nor this=20
   specification require using the minimal padding length.

Yoav

> On Jun 14, 2015, at 10:37 AM, Yaron Sheffer  =
wrote:
>=20
> Quick nit: the sentence "The Pad Length field need not exceed 4 =
octets" is a bit confusing, because the Pad Length field is obviously a =
constant 2 octets. I would suggest "The Padding field's length (and the =
value of the Pad Length field) need not exceed 4 octets."
>=20
> Thanks,
> 	Yaron
>=20
> On 06/14/2015 09:46 AM, internet-drafts@ietf.org wrote:
>>=20
>> 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.
>>=20
>>         Title           : ChaCha20, Poly1305 and their use in IKE & =
IPsec
>>         Author          : Yoav Nir
>> 	Filename        : draft-ietf-ipsecme-chacha20-poly1305-09.txt
>> 	Pages           : 12
>> 	Date            : 2015-06-13
>>=20
>> Abstract:
>>    This document describes the use of the ChaCha20 stream cipher =
along
>>    with the Poly1305 authenticator, combined into an AEAD algorithm =
for
>>    the Internet Key Exchange protocol (IKEv2) and for IPsec.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> =
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09
>>=20
>> A diff from the previous version is available at:
>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-0=
9
>>=20
>>=20
>> 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.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>=20
>=20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From nobody Sun Jun 14 10:57:46 2015
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 754551B3076 for ; Sun, 14 Jun 2015 10:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 fvIK34Tskhu1 for ; Sun, 14 Jun 2015 10:57:42 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 3FA5C1B3075 for ; Sun, 14 Jun 2015 10:57:42 -0700 (PDT)
Received: by wgez8 with SMTP id z8so53413327wge.0 for ; Sun, 14 Jun 2015 10:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iBcaNK7zbnDa2RhP+3gu5XzhwwHjIbcwyylCO9rN5n8=; b=S8t+jvP8oseKC1PY61xtArdpNhfmTmJuKPtnpg6NscxzTSpop14B9xlyyINZdj3kJn cylZdQXCg8GWpf/a+lawOBUBKFXJTQBeLv+KYzjZddiTYKWiL9B8gLeblXid58R5dcbP kndPVmDw32iKD39VcZb7wtVgCit0jws6JXyMkBwMCV33Xxv/YpDBBamjogrB+aMutnUD e66UOL6KDDZhOFGpu/ZqVViFuewbLucNHHsvcqlfASHlu+Q7xNSwa2G35jQ07/Uzv3kQ lcLn+6rb3SgJ/OjDo0hWTVLpBEMCS5j5GARNnnwHfYvwx37z8EslLS4+wAhR0oDOmTCC Z+Iw==
X-Received: by 10.194.157.168 with SMTP id wn8mr43872381wjb.79.1434304660802;  Sun, 14 Jun 2015 10:57:40 -0700 (PDT)
Received: from [10.0.0.6] (bzq-79-177-18-17.red.bezeqint.net. [79.177.18.17]) by mx.google.com with ESMTPSA id gz3sm12832535wib.0.2015.06.14.10.57.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jun 2015 10:57:39 -0700 (PDT)
Message-ID: <557DC090.106@gmail.com>
Date: Sun, 14 Jun 2015 20:57:36 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Yoav Nir 
References: <20150614064621.15901.47260.idtracker@ietfa.amsl.com> <557D2F25.8060607@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.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: Sun, 14 Jun 2015 17:57:44 -0000

Sure.

On 06/14/2015 02:11 PM, Yoav Nir wrote:
> How about:
>
> OLD:
>     The Pad Length field need not exceed 4 octets. However, RFC 4303 and this specification do not
>     prohibit using greater pad lengths.
>
> NEW:
>     The length of the Padding field need not exceed 4 octets. However, neither RFC 4303 nor this
>     specification require using the minimal padding length.
>
> Yoav
>
>> On Jun 14, 2015, at 10:37 AM, Yaron Sheffer  wrote:
>>
>> Quick nit: the sentence "The Pad Length field need not exceed 4 octets" is a bit confusing, because the Pad Length field is obviously a constant 2 octets. I would suggest "The Padding field's length (and the value of the Pad Length field) need not exceed 4 octets."
>>
>> Thanks,
>> 	Yaron
>>
>> On 06/14/2015 09:46 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           : ChaCha20, Poly1305 and their use in IKE & IPsec
>>>          Author          : Yoav Nir
>>> 	Filename        : draft-ietf-ipsecme-chacha20-poly1305-09.txt
>>> 	Pages           : 12
>>> 	Date            : 2015-06-13
>>>
>>> Abstract:
>>>     This document describes the use of the ChaCha20 stream cipher along
>>>     with the Poly1305 authenticator, combined into an AEAD algorithm for
>>>     the Internet Key Exchange protocol (IKEv2) and for IPsec.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-09
>>>
>>>
>>> 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
>>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>


From nobody Sun Jun 14 11:11:04 2015
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 6DCBF1A1B45 for ; Sun, 14 Jun 2015 11:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 2qK7HhrI593q for ; Sun, 14 Jun 2015 11:11:01 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 9B03F1A1A58 for ; Sun, 14 Jun 2015 11:11:01 -0700 (PDT)
Received: by wigg3 with SMTP id g3so56888553wig.1 for ; Sun, 14 Jun 2015 11:11:00 -0700 (PDT)
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=Ev+ZJubO6z/Jfz/MMIwEv9522LtIaK8v2zUIIP3FOhM=; b=v152t0/g6CJz55r6v8YXt51jALJX0ORFi6EFOR4lFX1sxFhKObBf+70Oh/Dz8tKHVb rE3Iqt/156I/QVARYuYUX9kPd3nnRLXNcrvwXIIw14Cs6KmrXgMsYNN2ZWGey65T6UIN wTB+d7ZeuoXMW/qKDuMWJecKGGkWQxu2Xe4Yx0slKjrgJ1QwTOvj2pagdzOlA0fvmDEI WCcoB08L7ixkmbrUJ8z2SoMwexhtK+qWr558RyleXrTpUCajQLkKo9RsBFmOK9h0Ma4+ LCgLHQgHTgbOPk+Ly31u42trxDckSLxmOkJ7sc2sG3S8w7ir2W6WZZ3dp2erd0k9Da14 JyUw==
X-Received: by 10.180.88.169 with SMTP id bh9mr25338393wib.6.1434305460383; Sun, 14 Jun 2015 11:11:00 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id q2sm15360478wjz.15.2015.06.14.11.10.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jun 2015 11:10:59 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir 
In-Reply-To: <557DC090.106@gmail.com>
Date: Sun, 14 Jun 2015 21:10:57 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <38C2831F-93E3-4172-B4AA-B00380ABF6EE@gmail.com>
References: <20150614064621.15901.47260.idtracker@ietfa.amsl.com> <557D2F25.8060607@gmail.com>  <557DC090.106@gmail.com>
To: Yaron Sheffer 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.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: Sun, 14 Jun 2015 18:11:03 -0000

Done.

> On Jun 14, 2015, at 8:57 PM, Yaron Sheffer  =
wrote:
>=20
> Sure.
>=20
> On 06/14/2015 02:11 PM, Yoav Nir wrote:
>> How about:
>>=20
>> OLD:
>>    The Pad Length field need not exceed 4 octets. However, RFC 4303 =
and this specification do not
>>    prohibit using greater pad lengths.
>>=20
>> NEW:
>>    The length of the Padding field need not exceed 4 octets. However, =
neither RFC 4303 nor this
>>    specification require using the minimal padding length.
>>=20
>> Yoav
>>=20
>>> On Jun 14, 2015, at 10:37 AM, Yaron Sheffer  =
wrote:
>>>=20
>>> Quick nit: the sentence "The Pad Length field need not exceed 4 =
octets" is a bit confusing, because the Pad Length field is obviously a =
constant 2 octets. I would suggest "The Padding field's length (and the =
value of the Pad Length field) need not exceed 4 octets."
>>>=20
>>> Thanks,
>>> 	Yaron
>>>=20
>>> On 06/14/2015 09:46 AM, internet-drafts@ietf.org wrote:
>>>>=20
>>>> 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.
>>>>=20
>>>>         Title           : ChaCha20, Poly1305 and their use in IKE & =
IPsec
>>>>         Author          : Yoav Nir
>>>> 	Filename        : draft-ietf-ipsecme-chacha20-poly1305-09.txt
>>>> 	Pages           : 12
>>>> 	Date            : 2015-06-13
>>>>=20
>>>> Abstract:
>>>>    This document describes the use of the ChaCha20 stream cipher =
along
>>>>    with the Poly1305 authenticator, combined into an AEAD algorithm =
for
>>>>    the Internet Key Exchange protocol (IKEv2) and for IPsec.
>>>>=20
>>>>=20
>>>> The IETF datatracker status page for this draft is:
>>>> =
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
>>>>=20
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09
>>>>=20
>>>> A diff from the previous version is available at:
>>>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-0=
9
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>=20
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> IPsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>=20
>>>=20
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>=20


From nobody Sun Jun 14 11:11:14 2015
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 99FBB1A1BFA; Sun, 14 Jun 2015 11:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 UnKAD565OfRX; Sun, 14 Jun 2015 11:11:04 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74F1A1A58; Sun, 14 Jun 2015 11:11:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150614181104.17655.64699.idtracker@ietfa.amsl.com>
Date: Sun, 14 Jun 2015 11:11:04 -0700
Archived-At: 
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-10.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: Sun, 14 Jun 2015 18:11:05 -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           : ChaCha20, Poly1305 and their use in IKE & IPsec
        Author          : Yoav Nir
	Filename        : draft-ietf-ipsecme-chacha20-poly1305-10.txt
	Pages           : 12
	Date            : 2015-06-14

Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and for IPsec.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jun 15 07:23:10 2015
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 7CF711B2D84; Mon, 15 Jun 2015 07:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 X05aTM3dyS7R; Mon, 15 Jun 2015 07:23:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 392B61B2BDC; Mon, 15 Jun 2015 07:22:10 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20150615142210.20481.57389.idtracker@ietfa.amsl.com>
Date: Mon, 15 Jun 2015 07:22:10 -0700
Archived-At: 
Cc: ipsec@ietf.org
Subject: [IPsec] Last Call:  (ChaCha20, Poly1305 and their use in IKE & IPsec) to Proposed Standard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2015 14:23:09 -0000

The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'ChaCha20, Poly1305 and their use in IKE & IPsec'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and for IPsec.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ballot/


No IPR declarations have been submitted directly on this I-D.



From webczat_200@poczta.onet.pl  Tue Jun 16 04:34:34 2015
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 847E11B2BA0 for ; Tue, 16 Jun 2015 04:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.844
X-Spam-Level: ****
X-Spam-Status: No, score=4.844 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, 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 A1c_MZxbkGcW for ; Tue, 16 Jun 2015 04:34:32 -0700 (PDT)
Received: from smtpo11.poczta.onet.pl (smtpo11.poczta.onet.pl [213.180.142.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899871B32C5 for ; Tue, 16 Jun 2015 04:34:30 -0700 (PDT)
Received: from [192.168.1.6] (blaster.blast.pl [193.200.47.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: webczat_200@poczta.onet.pl) by smtp.poczta.onet.pl (Onet) with ESMTPSA id 3m9nVr2QqGz9vnYL for ; Tue, 16 Jun 2015 13:34:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=poczta.onet.pl; s=2011; t=1434454468; bh=Ah38O0vLk9FJO2aUnMm/+6j7kMHDiHVRcJFVg6nf/EY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=Nt2dtb3cqUwCOLDnFPHvmIYBS+pMrvxN68bSfImsZHUsF6fjKwGHxjp8OZ87cTgRF ihXi8xgGzFJ0gzcnYxT/PD0au56ICoS+817qCK6ZnHmcXTJzUZULdvA9TkBqF1gNVT nYt8VnUMir/l7+14QZ6vYoexzwCAzmWXv4ZKg/ww=
Message-ID: <558009C9.8040509@poczta.onet.pl>
Date: Tue, 16 Jun 2015 13:34:33 +0200
From: =?UTF-8?B?TWljaGHFgiBaZWdhbg==?= 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: ipsec@ietf.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [IPsec] nat traversal and transport mode
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, 16 Jun 2015 11:45:41 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.

I have heard that transport mode should not be used if the initiator
is behind a NAT, even with nat traversal protocols, because this does
have some issues.
However, I am not quite sure if I understand what issues are that?
Also, does it mean that l2tp over ipsec suffers the same issues but
you have no choice in this case?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVgAnHAAoJEHb1CzgxXKwYEmkP+gOyeNY+JjLJW78mIUb6WPaW
DKQ8TyrnWsB3rTjWeNlO0eADKlj5XfpXRhf257XDkZgDxlNNhcJxol23nx7tRRqB
8kZimQqgpSA+WE4vQ6odZeSEIzfXElv4viPeIZgOcftDMhsgfqhpkqn7gfH+Kg8J
SRy9JWxdPQ2oJHiurjRIjZ4/KoLqGgU+ncl9wj68FJrKjs2uM2NIncHQAlW9AEUD
KFy/+QbIo5/UFkHzwXKzw/I5Z4Fic2YfELW6H5JmQEl77zQywKknM+OgDL58VpXW
cQTPKvJaQLlJ7PbJi7N3t/SupQsUmQBQsPfit/q0+H3il+i+Yijkz8d/Ofy0lssB
DUnIxr+o6R3qGx5XHNtA1F2fJ3gGFCLd5mQHOs40+Bl3Xlhyx0PcGChHGrne7INl
vIqnLOQWyJxEUzIdTkzUbFo7UlYYJh6wUq2MViMDGrV6TbaPuhj+FewQvylpeyqH
Bjfumhj5ShhMNeXqv0isEQz/V7KWWO47GvL8jveUcaOK7udzSwjHETK9H+Rp8S29
BZTCFXs2TMMPEppJoSljVz/xue22aV6eCB0cT1VOtZUn3+2pZybq2Qlkzu7mAFtl
LYYMdV/XS9ZEyYUf5KDQWIiK5+Q3dK5gFUSb6eiiWb5COToY247DsPR9yrHDDCpT
1SfJd/Dcg4mg6i1aKB75
=14QR
-----END PGP SIGNATURE-----


From nobody Tue Jun 16 05:08:13 2015
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 C316D1A038C for ; Tue, 16 Jun 2015 05:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 h9KmKSvgC840 for ; Tue, 16 Jun 2015 05:08:10 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 EBBF31B2B96 for ; Tue, 16 Jun 2015 05:08:08 -0700 (PDT)
Received: by wibdq8 with SMTP id dq8so17287231wib.1 for ; Tue, 16 Jun 2015 05:08:07 -0700 (PDT)
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=TahVhNv2u7a+OB6s4ivCgvahiMvGGJJuscpnWB2VOrY=; b=tH3pkWctb3Xu/2UtpbvKNDewzB8j3SOJPgV9PBpXyJj7EG/Eifoy8m4lFiIQxjGHF/ b5aItPnrn/GPr89NyiRsUggVYgXDrK6hCVDXM9DguiOFp6ZOVzFWfb6Zs8HNL8E+SdEt vqd30Xxm83sK/nu2UI7n+RmhDR8HCMrPtnNrB5apw6x3H9y1Wr2RPcHzS1BNKqW4cbQe yKPocB8jMEEiMW7v9PrdxxuMmsE2XO3p+YttAYyY6xA/B2SAu2XZORUtJqBVIkQ/0R0O DY0nZDK9FBGJQkLjX7Aw5fQT9Ib7kBcpVEuJ0sQoGKw3gBIT0dxjP7igN8jY3LGGT92P ywrQ==
X-Received: by 10.180.82.135 with SMTP id i7mr43747040wiy.68.1434456066146; Tue, 16 Jun 2015 05:01:06 -0700 (PDT)
Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ch2sm2214767wib.18.2015.06.16.05.01.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jun 2015 05:01:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir 
In-Reply-To: <558009C9.8040509@poczta.onet.pl>
Date: Tue, 16 Jun 2015 15:01:03 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B5045FC-A79A-45D1-B051-7B82A546D01F@gmail.com>
References: <558009C9.8040509@poczta.onet.pl>
To: =?utf-8?Q?Micha=C5=82_Zegan?= 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: ipsec@ietf.org
Subject: Re: [IPsec] nat traversal and transport mode
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, 16 Jun 2015 12:08:11 -0000

Hi.

Transport mode works fine behind NAT devices. For example, L2TP clients =
connect to VPN gateways using transport mode and they work behind NAT =
devices.

It is AH that cannot work behind NAT. =20

HTH

Yoav

> On Jun 16, 2015, at 2:34 PM, Micha=C5=82 Zegan =
 wrote:
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hello.
>=20
> I have heard that transport mode should not be used if the initiator
> is behind a NAT, even with nat traversal protocols, because this does
> have some issues.
> However, I am not quite sure if I understand what issues are that?
> Also, does it mean that l2tp over ipsec suffers the same issues but
> you have no choice in this case?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>=20
> iQIcBAEBAgAGBQJVgAnHAAoJEHb1CzgxXKwYEmkP+gOyeNY+JjLJW78mIUb6WPaW
> DKQ8TyrnWsB3rTjWeNlO0eADKlj5XfpXRhf257XDkZgDxlNNhcJxol23nx7tRRqB
> 8kZimQqgpSA+WE4vQ6odZeSEIzfXElv4viPeIZgOcftDMhsgfqhpkqn7gfH+Kg8J
> SRy9JWxdPQ2oJHiurjRIjZ4/KoLqGgU+ncl9wj68FJrKjs2uM2NIncHQAlW9AEUD
> KFy/+QbIo5/UFkHzwXKzw/I5Z4Fic2YfELW6H5JmQEl77zQywKknM+OgDL58VpXW
> cQTPKvJaQLlJ7PbJi7N3t/SupQsUmQBQsPfit/q0+H3il+i+Yijkz8d/Ofy0lssB
> DUnIxr+o6R3qGx5XHNtA1F2fJ3gGFCLd5mQHOs40+Bl3Xlhyx0PcGChHGrne7INl
> vIqnLOQWyJxEUzIdTkzUbFo7UlYYJh6wUq2MViMDGrV6TbaPuhj+FewQvylpeyqH
> Bjfumhj5ShhMNeXqv0isEQz/V7KWWO47GvL8jveUcaOK7udzSwjHETK9H+Rp8S29
> BZTCFXs2TMMPEppJoSljVz/xue22aV6eCB0cT1VOtZUn3+2pZybq2Qlkzu7mAFtl
> LYYMdV/XS9ZEyYUf5KDQWIiK5+Q3dK5gFUSb6eiiWb5COToY247DsPR9yrHDDCpT
> 1SfJd/Dcg4mg6i1aKB75
> =3D14QR
> -----END PGP SIGNATURE-----
>=20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From nobody Tue Jun 16 06:41:11 2015
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 26CBD1B3553 for ; Tue, 16 Jun 2015 06:41:09 -0700 (PDT)
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, 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 QH5LT5NZNePH for ; Tue, 16 Jun 2015 06:41:07 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BCE1B3545 for ; Tue, 16 Jun 2015 06:41:07 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 55A672016A; Tue, 16 Jun 2015 09:55:49 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id BAA6E63B10; Tue, 16 Jun 2015 09:41:06 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A3FB263AE8; Tue, 16 Jun 2015 09:41:06 -0400 (EDT)
From: Michael Richardson 
To: =?us-ascii?Q?=3D=3FUTF-8=3FB=3FTWljaGHFgiBaZWdhbg=3D=3D=3F=3D?= 
In-Reply-To: <558009C9.8040509@poczta.onet.pl>
References: <558009C9.8040509@poczta.onet.pl>
X-Mailer: MH-E 8.6; nmh 1.3-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
Sender: mcr@sandelman.ca
Archived-At: 
Cc: ipsec@ietf.org
Subject: Re: [IPsec] nat traversal and transport mode
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, 16 Jun 2015 13:41:09 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Micha=C5=82 Zegan  wrote:
    > I have heard that transport mode should not be used if the initiator
    > is behind a NAT, even with nat traversal protocols, because this does
    > have some issues.

Yes, the issue is that on the gateway system, you wind up with zillions
of transport sockets that are connected to 192.168.1.101 on the remote
end, and you have to distinguish them by the IPsec state.
(If you use tunnel mode through NAT, one usually assigns an IP address
to the end system to use, and one can make that address unique)

So, it's not a security or protocol problem, but on a generic operating sys=
tem
(Linux, *BSD, probably windows), it's a problem to get the right bookeeping
in place.

=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)

iQEVAwUBVYAncoCLcPvd0N1lAQJxfwgAoouOe1YtqbudzF4rGkwzHOxne3WNkTls
dOoT5R0/FnQb96G6CoGgAHTO+1xboubbYQmPUZSLwvIlL+yiExpDLSO29lOYSUOR
a3XLUN3EqhLSzHOdRH9ao3ZqKMz24MhSQsAFHbp66RgFp3IzyOg2CtLeAquCmq4f
cHePI/cH7M2d2b5k74FXr9G5E9QZwEnip7kpeLBNoKIF2Ru9A71T+jaG3zsnSjyc
N5gczDFfHNFG3uubY8kweOP+iVJwZKxsS0bzlBDS6HCIfnQYE3nD1YzAw1bJ6PYN
o7Emvk0WQmxq74Bg3b42wyR4+9jKQy9CeBdNi+N5R/gMZTqCVqUUlg==
=Vqth
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Jun 16 06:44:45 2015
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 62EFD1B3569 for ; Tue, 16 Jun 2015 06:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QFffY82bAZd3 for ; Tue, 16 Jun 2015 06:44:42 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E691B354C for ; Tue, 16 Jun 2015 06:44:20 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m9rNg07fCzrl; Tue, 16 Jun 2015 15:44:19 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Gej6arjy
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 eZCiN7khGF8p; Tue, 16 Jun 2015 15:44:17 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 16 Jun 2015 15:44:17 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E09E3800A3; Tue, 16 Jun 2015 09:44:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434462256; bh=0YEKtKvtUHWLZyJex9kW6tG2EraFxByTVsVxseRvIqQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Gej6arjyCRrSopg7NXuL399KpQzOJLu4oyZS/ujZvl20LDWckiu46DV/zbyQnKr6v IMF5COSe6PIMsV08Mw1vi/qWbWw6z6m6f2DXPNyK9FIAJy4dqbzYMQDny3Whokocpk k2B5Sl8iLn9ZVCehHcsSglvkPjA3+VPlDAXrnFuE=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5GDiGvL025281; Tue, 16 Jun 2015 09:44:16 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 16 Jun 2015 09:44:16 -0400 (EDT)
From: Paul Wouters 
To: "ipsec@ietf.org WG" 
In-Reply-To: <5B5045FC-A79A-45D1-B051-7B82A546D01F@gmail.com>
Message-ID: 
References: <558009C9.8040509@poczta.onet.pl> <5B5045FC-A79A-45D1-B051-7B82A546D01F@gmail.com>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: 
Cc: =?ISO-8859-2?Q?Micha=B3_Zegan?= 
Subject: Re: [IPsec] nat traversal and transport mode
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, 16 Jun 2015 13:44:44 -0000

On Tue, 16 Jun 2015, Yoav Nir wrote:

> Transport mode works fine behind NAT devices. For example, L2TP clients connect to VPN gateways using transport mode and they work behind NAT devices.
>
> It is AH that cannot work behind NAT.

It's a lot more complicated. Since transport mode crypto binds to
the outer IP address, you will end up with multiple clients using
the same remote IP on their security policy. Eg multiple clients can
have 192.168.1.1. Now you have to keep track of these (Linux: SAref or
conntrack) and you still cannot initiate a new connection to a specific
remote endpoint from the server without additional hacking to ensure
you are going to the right 192.168.1.1 client.

When using tunnel mode, you can give each connecting client their own IP
address to avoid all conflicts.

Paul

> Yoav
>
>> On Jun 16, 2015, at 2:34 PM, Michał Zegan  wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello.
>>
>> I have heard that transport mode should not be used if the initiator
>> is behind a NAT, even with nat traversal protocols, because this does
>> have some issues.
>> However, I am not quite sure if I understand what issues are that?
>> Also, does it mean that l2tp over ipsec suffers the same issues but
>> you have no choice in this case?
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQIcBAEBAgAGBQJVgAnHAAoJEHb1CzgxXKwYEmkP+gOyeNY+JjLJW78mIUb6WPaW
>> DKQ8TyrnWsB3rTjWeNlO0eADKlj5XfpXRhf257XDkZgDxlNNhcJxol23nx7tRRqB
>> 8kZimQqgpSA+WE4vQ6odZeSEIzfXElv4viPeIZgOcftDMhsgfqhpkqn7gfH+Kg8J
>> SRy9JWxdPQ2oJHiurjRIjZ4/KoLqGgU+ncl9wj68FJrKjs2uM2NIncHQAlW9AEUD
>> KFy/+QbIo5/UFkHzwXKzw/I5Z4Fic2YfELW6H5JmQEl77zQywKknM+OgDL58VpXW
>> cQTPKvJaQLlJ7PbJi7N3t/SupQsUmQBQsPfit/q0+H3il+i+Yijkz8d/Ofy0lssB
>> DUnIxr+o6R3qGx5XHNtA1F2fJ3gGFCLd5mQHOs40+Bl3Xlhyx0PcGChHGrne7INl
>> vIqnLOQWyJxEUzIdTkzUbFo7UlYYJh6wUq2MViMDGrV6TbaPuhj+FewQvylpeyqH
>> Bjfumhj5ShhMNeXqv0isEQz/V7KWWO47GvL8jveUcaOK7udzSwjHETK9H+Rp8S29
>> BZTCFXs2TMMPEppJoSljVz/xue22aV6eCB0cT1VOtZUn3+2pZybq2Qlkzu7mAFtl
>> LYYMdV/XS9ZEyYUf5KDQWIiK5+Q3dK5gFUSb6eiiWb5COToY247DsPR9yrHDDCpT
>> 1SfJd/Dcg4mg6i1aKB75
>> =14QR
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> 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 Tue Jun 16 06:50:19 2015
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 5D9261B35A8 for ; Tue, 16 Jun 2015 06:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 L1ZeHZtnNwwG for ; Tue, 16 Jun 2015 06:50:14 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 32FC41B35AD for ; Tue, 16 Jun 2015 06:50:12 -0700 (PDT)
Received: by wiga1 with SMTP id a1so109647201wig.0 for ; Tue, 16 Jun 2015 06:50:11 -0700 (PDT)
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=vTH+XKk2IOm/QJo8wFl1A4g+0NRipXGXuvcZtsuYFrI=; b=a+TtSZuSwQsVMW1gXhtA9TQltyWlRMrbGvBgoDNmJ+4dhoCJiO2D+phkc2S3f86Ot1 7Z/fONMxjztqITMFMuEcVgxIYcP+B1zufC951IwUPPnR167sszP92iiYRFgfnEqXpmtU wwEK6Z8PjUn9qzMxadhx26izOcgkbx0f+oo0y9p2gSEa+AltUMDvSCBt24XWXUMr8V32 ZsJ+JAG0U6Y1j78MOTWMRK+rbWhHx5mQWazGfbUO39iyPiqGPHfA7pcOXh3aXOWUuOIp 7XI5NqJco9XY790MXB3AZBo4u57KNkku9GgWTYwPtD8P4cHslpIQQIYcu5AE6CPbhiLF eX9g==
X-Received: by 10.180.90.209 with SMTP id by17mr43405251wib.2.1434462610927; Tue, 16 Jun 2015 06:50:10 -0700 (PDT)
Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id bg6sm1765698wjc.13.2015.06.16.06.50.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jun 2015 06:50:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir 
In-Reply-To: 
Date: Tue, 16 Jun 2015 16:50:08 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FEC8628-D892-4171-86F5-6BE58F580432@gmail.com>
References: <558009C9.8040509@poczta.onet.pl> <5B5045FC-A79A-45D1-B051-7B82A546D01F@gmail.com> 
To: Paul Wouters 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "ipsec@ietf.org WG" , =?utf-8?Q?Micha=C5=82_Zegan?= 
Subject: Re: [IPsec] nat traversal and transport mode
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, 16 Jun 2015 13:50:18 -0000

> On Jun 16, 2015, at 4:44 PM, Paul Wouters  wrote:
>=20
> On Tue, 16 Jun 2015, Yoav Nir wrote:
>=20
>> Transport mode works fine behind NAT devices. For example, L2TP =
clients connect to VPN gateways using transport mode and they work =
behind NAT devices.
>>=20
>> It is AH that cannot work behind NAT.
>=20
> It's a lot more complicated. Since transport mode crypto binds to
> the outer IP address, you will end up with multiple clients using
> the same remote IP on their security policy. Eg multiple clients can
> have 192.168.1.1. Now you have to keep track of these (Linux: SAref or
> conntrack) and you still cannot initiate a new connection to a =
specific
> remote endpoint from the server without additional hacking to ensure
> you are going to the right 192.168.1.1 client.
>=20
> When using tunnel mode, you can give each connecting client their own =
IP
> address to avoid all conflicts.

If you=E2=80=99re using transport mode, you never get to see 192.168.1.1 =
- that=E2=80=99s converted by the NAT device to its own external IP =
address.  But it=E2=80=99s true that you have to be stateful about flows =
to be able to return the right packet to the right source.=20

Which is why VPNs need tunnels (either IPsec or GRE or L2TP, but =
preferably IPsec)=


From nobody Sat Jun 20 13:23:33 2015
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 23B1F1A9244 for ; Sat, 20 Jun 2015 13:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.124
X-Spam-Level: 
X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 XNP2MTfReGjg for ; Sat, 20 Jun 2015 13:23:31 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 E60441A923E for ; Sat, 20 Jun 2015 13:23:30 -0700 (PDT)
Received: by wgfq1 with SMTP id q1so66413296wgf.1 for ; Sat, 20 Jun 2015 13:23:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=9ot3KykJ+rGuumgSVBZL/ZEUMY6hcjmap05KfWqUGeE=; b=ecut7dp6GDLZXrYewbD2cOgu9YJ+blFzlZ13dLswizo1u5y3mkvkKcHEN3PNEVm7oM 4LB4yOr3z6b/q4qLvxi7i/0qDj1UE9sAswMXl1JGkIlsntWHZmZ/PvKpfMjevlRDk4rb /lk4s5VbW4ECpQ8y5G3Sfooc7HCo1brW8Ov5+N9DdaiskVpASQ0Mq0oLqcQJnLUtYPdy cbLBDtVMnk4COkzQyW1Cq19XdBxADkev0pSrN2g37fgNcHStcSXk5Gx0Zr49xhfpPOfS RLkspXKk/Ikr/DPqOIPA6J301aO0QEeegL5+GELZ2Z8zrA7JABlHAHPv14f+Ch5pDU1U rNTg==
X-Received: by 10.194.142.146 with SMTP id rw18mr35915226wjb.110.1434831809592;  Sat, 20 Jun 2015 13:23:29 -0700 (PDT)
Received: from [10.0.0.5] (bzq-79-183-169-34.red.bezeqint.net. [79.183.169.34]) by mx.google.com with ESMTPSA id jy6sm17932960wjc.4.2015.06.20.13.23.28 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2015 13:23:28 -0700 (PDT)
Message-ID: <5585CBBE.20101@gmail.com>
Date: Sat, 20 Jun 2015 23:23:26 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: IPsecME WG 
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [IPsec] IPsecME DDoS draft - please review
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, 20 Jun 2015 20:23:32 -0000


  

    
    
  
  
    Hi,

    

    The authors and the working group brought the draft
    (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/)
    into pretty good shape, but we're not done yet. To prepare for the
    Prague session with this draft as our only active one, I suggest
    that those people who care about DDoS protection give the draft one
    more read during the coming week, and send their comments to the
    list.

    

    Thanks,

        Yaron

    

  



From nobody Tue Jun 30 06:05:25 2015
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 24F841A9119 for ; Tue, 30 Jun 2015 06:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 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, HTML_MESSAGE=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 9l1fneTdz3Yh for ; Tue, 30 Jun 2015 06:05:24 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 B4CFE1A8AA4 for ; Tue, 30 Jun 2015 06:05:23 -0700 (PDT)
Received: by wicgi11 with SMTP id gi11so16085604wic.0 for ; Tue, 30 Jun 2015 06:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=miOg1G8+4kJHQPK6NqrJDbHMIYY9JGf2FEb/kXXg6/4=; b=H42xkHdJzQGC9Pj7vWN+cFr4Pv9v5ZgJ9kAYEpuUnIAcv/AmMoSODsdwigBqxjmSWF tKPg/WFO4qtQGQmtFtyfILWed/azD/4BE8vWJllpsBCb4GdNv4jxM7TGL1GNhPWVzl6Q gF3IYfs/4oNgj+SZLAc8gOQFuFI+gGv3ozw2NwejM1Dn0F39WT/nXGooS1+qWU23DOB1 M2EK0r9lVtWWCPeHoGnJwYO7xcWwGmRtuapUdqlwcOjwLqLDDPDdOQAGzn7HlT5bCQ1y nrrbqDh/dJL+auOVbI/3tH9Mv+ahn7ftz6/gahqqJH+HTqW2NOCbUwXhMdmMLdS+BjWV oTZQ==
MIME-Version: 1.0
X-Received: by 10.180.86.73 with SMTP id n9mr32582645wiz.78.1435669522125; Tue, 30 Jun 2015 06:05:22 -0700 (PDT)
Received: by 10.28.31.194 with HTTP; Tue, 30 Jun 2015 06:05:22 -0700 (PDT)
Date: Tue, 30 Jun 2015 09:05:22 -0400
Message-ID: 
From: Kathleen Moriarty 
To: "ipsec@ietf.org" 
Content-Type: multipart/alternative; boundary=f46d0442806ee198be0519bbdb82
Archived-At: 
Subject: [IPsec] draft-ietf-ipsecme-chacha20-poly1305
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, 30 Jun 2015 13:05:25 -0000

--f46d0442806ee198be0519bbdb82
Content-Type: text/plain; charset=UTF-8

Hello,

I am getting the ballot ready for the next telechat (next week on
Thursday).  Are there any implementations?

My other question is to see if some more text is going to be added to
distinguish AEAD_CHACHA20_POLY1305 from ENCR_CHACHA20_POLY1305.  I ask
because this came up in 2 reviews.  While the definitions for both are in
the draft and this should be clear enough, an added sentence could do some
good to explain that they are different.

Thanks.

-- 

Best regards,
Kathleen

--f46d0442806ee198be0519bbdb82
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello,

I am getting the ballot ready fo=
r the next telechat (next week on Thursday).=C2=A0 Are there any implementa=
tions?

My other question is to see if some more te=
xt is going to be added to distinguish=C2=A0AEAD_CHACHA20_POLY1305 from=C2=A0<=
/span>ENCR_CHACHA20_POLY1305. =C2=A0I ask because this came up in 2 rev=
iews.=C2=A0 While the definitions for both are in the draft and this should=
 be clear enough, an added sentence could do some good to explain that they=
 are different.

Thanks.

-- 
<=
div class=3D"gmail_signature">

Best regards,
=

Kathleen




--f46d0442806ee198be0519bbdb82--