From nobody Mon Jan 5 23:14:07 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 D1C2D1A9103; Mon, 5 Jan 2015 23:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 MHt-QV-1gk-y; Mon, 5 Jan 2015 23:13:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6738D1A1A3D; Mon, 5 Jan 2015 23:13:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106071358.13248.8710.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 23:13:58 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/i0YUbx9WyCzxQx40r5EuXBlo13o Cc: ipsec@ietf.org, "Paul E. Hoffman" , Yaron Sheffer Subject: [IPsec] Pete Resnick's No Objection on charter-ietf-ipsecme-09-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 07:14:01 -0000 Pete Resnick has entered the following ballot position for charter-ietf-ipsecme-09-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do find these "This charter will expire" lines kind of silly, but I'm not going to stand in the way because of it. From nobody Tue Jan 6 13:24:49 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 9E25B1A870B; Tue, 6 Jan 2015 13:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PXLtCQnBtnZo; Tue, 6 Jan 2015 13:24:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D89B31A86FF; Tue, 6 Jan 2015 13:24:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106212445.17906.20208.idtracker@ietfa.amsl.com> Date: Tue, 06 Jan 2015 13:24:45 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/UgwHYUDhyNGeHvyiVmLN0fzU71s Cc: ipsec@ietf.org, "Paul E. Hoffman" , Yaron Sheffer Subject: [IPsec] Benoit Claise's No Objection on charter-ietf-ipsecme-09-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:24:47 -0000 Benoit Claise has entered the following ballot position for charter-ietf-ipsecme-09-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This charter will expire in December 2015 (a year from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. I like this "fail fast" type of paragraph. From nobody Tue Jan 6 17:57:08 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 86E281A88A5; Tue, 6 Jan 2015 17:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Ltca2Szo-M-W; Tue, 6 Jan 2015 17:57:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id C23B01A889F; Tue, 6 Jan 2015 17:57:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D17B0181CD3; Tue, 6 Jan 2015 17:56:37 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150107015637.D17B0181CD3@rfc-editor.org> Date: Tue, 6 Jan 2015 17:56:37 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/r8iA3K-1MZd5UvYwQ04qK5_mP0s Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 7427 on Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 01:57:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7427 Title: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) Author: T. Kivinen, J. Snyder Status: Standards Track Stream: IETF Date: January 2015 Mailbox: kivinen@iki.fi, jms@opus1.com Pages: 18 Characters: 39041 Updates: RFC 7296 I-D Tag: draft-kivinen-ipsecme-signature-auth-07.txt URL: https://www.rfc-editor.org/info/rfc7427 The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jan 7 00:41:00 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 C62F41A898B for ; Wed, 7 Jan 2015 00:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.747 X-Spam-Level: * X-Spam-Status: No, score=1.747 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=2.726, 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 Yiq5BS_wA-yh for ; Wed, 7 Jan 2015 00:40:58 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106F91A8965 for ; Wed, 7 Jan 2015 00:40:58 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so1082276wiv.2 for ; Wed, 07 Jan 2015 00:40:56 -0800 (PST) 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=XeAHJFdl0bCWaGMW5UO72ju4B/KuyyjNCZ8pNZD5328=; b=hquWUL1NVmLncLM1WeG2JCVK23e+TgSRpFZ2fWNFvlivRCdAsUwEvny3GM15ZWUM27 OOCfZ+5r0tz9p5lZ45u19UoXf9xE9bz9k3jBhGndgmlVhDPJ+WbV1gaWN7ui7CBUm2qu 0ktxpyK41qqU1UxVURfINhptlV22N3wu5g4jzJMv7XXKdH1MsglwBdCRyKBgSPKU53h4 FMk6KT7LXq2zXgi+j/9exnBNJvC8eXioilBZJurk+oCCdFIFRLHeEb5zi4nEA7AiND3H n8KrJMge5zqbiqn+W8Z3RQfBS0WRikhztH/w2e9vYdDkaDhaDqaqLPhzSaT9Pt1ClbS2 AZBQ== X-Received: by 10.180.206.47 with SMTP id ll15mr5198103wic.34.1420620056867; Wed, 07 Jan 2015 00:40:56 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id i15sm1235880wjq.22.2015.01.07.00.40.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jan 2015 00:40:56 -0800 (PST) Message-ID: <54ACF117.3080700@gmail.com> Date: Wed, 07 Jan 2015 10:40:55 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 CC: ipsec@ietf.org References: <20150107015637.D17B0181CD3@rfc-editor.org> In-Reply-To: <20150107015637.D17B0181CD3@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/klBiyaQmKTdlbIRSGAC9M6bomVM Subject: Re: [IPsec] RFC 7427 on Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 08:41:00 -0000 This is an important addition to IKEv2. Thank you Tero and Joel, and the other members of the design team: Dan Harkins, Johannes Merkle, David McGrew and Yoav Nir. Paul and Yaron On 01/07/2015 03:56 AM, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7427 > > Title: Signature Authentication in the Internet > Key Exchange Version 2 (IKEv2) > Author: T. Kivinen, J. Snyder > Status: Standards Track > Stream: IETF > Date: January 2015 > Mailbox: kivinen@iki.fi, > jms@opus1.com > Pages: 18 > Characters: 39041 > Updates: RFC 7296 > > I-D Tag: draft-kivinen-ipsecme-signature-auth-07.txt > > URL: https://www.rfc-editor.org/info/rfc7427 > > The Internet Key Exchange Version 2 (IKEv2) protocol has limited > support for the Elliptic Curve Digital Signature Algorithm (ECDSA). > The current version only includes support for three Elliptic Curve > groups, and there is a fixed hash algorithm tied to each group. This > document generalizes IKEv2 signature support to allow any signature > method supported by PKIX and also adds signature hash algorithm > negotiation. This is a generic mechanism and is not limited to > ECDSA; it can also be used with other signature algorithms. > > This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > From nobody Fri Jan 9 09:24:48 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 855041A8A83 for ; Fri, 9 Jan 2015 09:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJCDrW6dCTqa for ; Fri, 9 Jan 2015 09:24:45 -0800 (PST) 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 3ED6E1A8A79 for ; Fri, 9 Jan 2015 09:24:45 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t09HOhL4047433 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jan 2015 10:24:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> Date: Fri, 9 Jan 2015 09:24:43 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 09 Jan 2015 17:24:46 -0000 Greetings again. The chairs apologize for the log delay on this, but it = is time to move on this document. This begins the two-week WG Last Call = on https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth. = The purpose of the WG Last Call is to get as many people as possible to = read the document carefully, looking for any technical or editorial = issues that should be discussed before the document is sent to the IETF. I certainly hope we can get thorough reviews from the people who = supported its adoption as a WG item, but the WG would also benefit from = anyone else doing a review as well. Please send all comments to the list = before Friday, January 23. Thanks! --Paul Hoffman= From nobody Fri Jan 9 09:42:07 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 A2AE31A8856; Fri, 9 Jan 2015 09:42:03 -0800 (PST) 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 lwZ991MTXf2t; Fri, 9 Jan 2015 09:42:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09691A8A7D; Fri, 9 Jan 2015 09:42:00 -0800 (PST) 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: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109174200.10206.94571.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 09:42:00 -0800 Archived-At: Cc: ipsecme WG Subject: [IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme) 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, 09 Jan 2015 17:42:03 -0000 The IP Security Maintenance and Extensions (ipsecme) working group in the Security Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Current Status: Active WG Chairs: Paul Hoffman Yaron Sheffer Assigned Area Director: Kathleen Moriarty Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. There is interest in adapting the IKE protocol for opportunistic use cases, by allowing one or both endpoints of the exchange to remain unauthenticated. The group will extend the protocol to support these use cases. This charter will expire in December 2015 (a year from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - IETF Last Call on large scale VPN use cases and requirements Done - IETF last call on IKE fragmentation solution Done - IETF last call on new mandatory-to-implement algorithms Aug 2015 - IETF Last Call on DDoS protection Dec 2015 - IETF Last Call on null authentication From nobody Fri Jan 9 12:28: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 4448B1A1A37 for ; Fri, 9 Jan 2015 12:28:39 -0800 (PST) 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 L-_jfixsmQCM for ; Fri, 9 Jan 2015 12:28:35 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F346E1A1A55 for ; Fri, 9 Jan 2015 12:28:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kJwqf5WNWzCfT; Fri, 9 Jan 2015 21:28:14 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=nzVEuMyK; dkim-adsp=pass 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 WE0e_65vEmWy; Fri, 9 Jan 2015 21:28:13 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 9 Jan 2015 21:28:13 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A39B1809FE; Fri, 9 Jan 2015 15:28:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1420835292; bh=rjXPa60N/geJXlpV2xGSiKvBodht2gK+Y/aITn5dnSE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nzVEuMyKlfhYja2H4tbGh+Ehq+ovOdcMdz/ilJnDRHhh8VNzW81ysMZWjBMmyGHQq rSKsEcv/dUM2+OwhUgDsnXVrXd9N/tmXBxUeB5/bU0wx1LdoXv/S4aZa9Jk3ZtFIxf RlEgOSFPFXXzm/22mjq0Nx53de91LOzTQS8jyKyY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t09KSCmo030863; Fri, 9 Jan 2015 15:28:12 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 9 Jan 2015 15:28:11 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> Message-ID: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 09 Jan 2015 20:28:39 -0000 On Fri, 9 Jan 2015, Paul Hoffman wrote: > > Greetings again. The chairs apologize for the log delay on this, but it is time to move on this document. This begins the two-week WG Last Call on https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth. The purpose of the WG Last Call is to get as many people as possible to read the document carefully, looking for any technical or editorial issues that should be discussed before the document is sent to the IETF. Paul meant: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth > I certainly hope we can get thorough reviews from the people who supported its adoption as a WG item, but the WG would also benefit from anyone else doing a review as well. Please send all comments to the list before Friday, January 23. Thanks! Paul From nobody Fri Jan 9 13:06: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 182051A90E9 for ; Fri, 9 Jan 2015 13:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZdRfQ_6hiOE for ; Fri, 9 Jan 2015 13:06:34 -0800 (PST) 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 D546B1A90EB for ; Fri, 9 Jan 2015 13:06:29 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t09L5Y8e059043 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2015 14:06:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Fri, 9 Jan 2015 13:06:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1993) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 09 Jan 2015 21:06:36 -0000 On Jan 9, 2015, at 12:28 PM, Paul Wouters wrote: >=20 > On Fri, 9 Jan 2015, Paul Hoffman wrote: >=20 >> Greetings again. The chairs apologize for the log delay on this, but = it is time to move on this document. This begins the two-week WG Last = Call on = https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth. The = purpose of the WG Last Call is to get as many people as possible to read = the document carefully, looking for any technical or editorial issues = that should be discussed before the document is sent to the IETF. >=20 > Paul meant: >=20 > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth Blarg, I certainly did. I have no idea how that happened in my tool = chain. --Paul Hoffman= From nobody Sun Jan 11 07:24:50 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 982ED1A6F02 for ; Sun, 11 Jan 2015 07:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHTmJ7iBP0tP for ; Sun, 11 Jan 2015 07:24:47 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CD91A1BDA for ; Sun, 11 Jan 2015 07:24:47 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so15251102wes.2 for ; Sun, 11 Jan 2015 07:24:46 -0800 (PST) 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=GUHRUJiBXgnp889W6cghCm5jESX3mRVMCxIsGpRyyGA=; b=rBKJK+XxbU7RJF3L8khD7P2OKO6ERrPU588ulKxjJWkeaskAgLwkcB0jFybkh1uJ73 mQwEYJeJxBYIvdZBlsRiQHukiO8vXObSr0iyz+MD9hpmU8QAA3TaLLowLtyNOLu2l3Fe bz76G7NuctdpHNv1OkELDAgh46Kn/aqjDM/jvtDtu6Cz5NQ+uykmbeurY5U/1yitgW2p RV5BdpQSWEiCMABYogqOaPYul6fzxpkEYE2IpuhBrrUy3zvqyv7fCXox5KhAC7RdznT1 zayfmYRaJzOL8z5YSB3rykzKGjU2u1AGpc5mhBZM0uVTZhAI2g3BPkx0ozQqoIdEA0qd fkwA== X-Received: by 10.194.79.226 with SMTP id m2mr22223632wjx.60.1420989886335; Sun, 11 Jan 2015 07:24:46 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id a1sm17908000wjx.28.2015.01.11.07.24.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jan 2015 07:24:45 -0800 (PST) Message-ID: <54B295BC.9090605@gmail.com> Date: Sun, 11 Jan 2015 17:24:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paul Hoffman , Paul Wouters References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth-01 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, 11 Jan 2015 15:24:49 -0000 Hi Valery, Please see my comments below. - Unclosed sentence in the abstract: "It may be used to preserve anonymity of" - Reference to IKEv2: please use RFC 7296. - 2.1: it may be trivial, but we want to add that the AUTH payload MUST be verified by the recipient. - I don't think that we have consensus on "The Identification Data in Identity payload for the ID_NULL type MUST be absent". The asserted but unproven identity may be used for logging, or may be proven with a later authentication. Quoting from an email by Tero: "I think the most important point of this feature is that the client is UNAUTHENTICATED, not that it is ANONYMOUS." - "If endpoint receives a request to create an unauthenticated IKE SA from the IP address, which is configured on the endpoint to be authenticated, the request SHOULD be rejected." - I don't see why. What if there are several peers behind an IP address, some authenticated and some not? Maybe we need to think some more about the policy that each of the peers should enforce. - The issue of Traffic Selectors needs better treatment. Should we add a MUST for allocation of internal IP addresses? Thanks, Yaron From nobody Sun Jan 11 08:34:38 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 56F7E1A7026 for ; Sun, 11 Jan 2015 08:34:35 -0800 (PST) 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 3Y3M7ERR0lNa for ; Sun, 11 Jan 2015 08:34:32 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A8D1A7012 for ; Sun, 11 Jan 2015 08:34:32 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kL3Xz5BvXzCCt; Sun, 11 Jan 2015 17:34:27 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=kjlhO3Y+; dkim-adsp=pass 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 jfMQ9XyW3ch8; Sun, 11 Jan 2015 17:34:27 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 11 Jan 2015 17:34:26 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 81AF88004F; Sun, 11 Jan 2015 11:34:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1420994065; bh=NXCXUvTBDwSA2Ci7GAz6pV/x7P1TPQK26yvjRv/AfaA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kjlhO3Y+UrsjE2Av6w7Kc4nszRjKY02Qk0GsF1p4Zd2Fu8EbP8iuY+3q2PJWafgXF UXyJttTpnYXeJapDnEBrd36nwRz54WS9qlkvM54RKw5MxEWNRhWK9cMlCtSPdFab+L QNE89vACkwJcDyUuLLCUl16kSnWH21OBEsTDLqd0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0BGYPcE018439; Sun, 11 Jan 2015 11:34:25 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 11 Jan 2015 11:34:24 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <54B295BC.9090605@gmail.com> Message-ID: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <54B295BC.9090605@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth-01 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, 11 Jan 2015 16:34:35 -0000 On Sun, 11 Jan 2015, Yaron Sheffer wrote: I sent Valery an updated version which he can hopefully incorporate in this WGLC. I'll just comment on Yaron's remarks below. > - Unclosed sentence in the abstract: "It may be used to preserve anonymity > of" I suggested a rewriten abstract to Valery. > - Reference to IKEv2: please use RFC 7296. Did that. > - 2.1: it may be trivial, but we want to add that the AUTH payload MUST be > verified by the recipient. Sure. > - I don't think that we have consensus on "The Identification Data in > Identity payload for the ID_NULL type MUST be absent". The asserted but > unproven identity may be used for logging, or may be proven with a later > authentication. Quoting from an email by Tero: "I think the most important > point of this feature is that the client is UNAUTHENTICATED, not that it is > ANONYMOUS." I think you mean to say the NULL Authentication Method does not require ID_NULL. But obviously ID_NULL cannot have a payload. Because if you give it one, what type would it be? :P > - "If endpoint receives a request to create an unauthenticated IKE SA from > the IP address, which is configured on the endpoint to be authenticated, the > request SHOULD be rejected." - I don't see why. What if there are several > peers behind an IP address, some authenticated and some not? Maybe we need to > think some more about the policy that each of the peers should enforce. > > - The issue of Traffic Selectors needs better treatment. Should we add a MUST > for allocation of internal IP addresses? These issues are difficult and need to be addressed in the "opoprtunistic ipsec" document. I'm not sure how much of this discussion belongs in this document. I would prefer if this document keeps it focus on the format of the Null Authentication Method and ID_NONE payloads. (I think what I put in my suggestions to Valery is already too much for this document) If you have more peers behind the same NAT, you need a GOOD strategy for containing those private IPs or else one of those clients is going to use 8.8.8.8 and steal the servers DNS traffic. Paul From nobody Sun Jan 11 12:59:35 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 C49F01A87E1 for ; Sun, 11 Jan 2015 12:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG_aMkkgHIzy for ; Sun, 11 Jan 2015 12:59:32 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53CB1A87DE for ; Sun, 11 Jan 2015 12:59:31 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id w62so16028988wes.13 for ; Sun, 11 Jan 2015 12:59:30 -0800 (PST) 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=BwuOGXwollA7NLEqlkeXjDXj+x41nq001H4fIV4sSoI=; b=M7SayU9uJf+pm1vlC/ytLL8melHBYodWzJYrq+rT4Ag1EpVsraMl20b7QGJt2nfChY +sIRWVM2Vx0chV9b1nrD1GjD8yV4kPRBnWQ8qA5bxhbODCPI+VVL/0f08Q2n842x/vUL 79/vJ19doSKLGLL9sJs/XOrO6HrR4XukdlPOdhJJR1xeOTFNeS3Sxi+gZD11l2MYdTxJ il2LTgFCu8ijh/qNM0PKFs+jMB5VxJOgy9caXfYKlNUaf/CjUcCF8hSZlVcvS101UFdh WGp3UzSd1NR6heZlbmwTtzQ9A7HBOjhUjLBNk0flqObefjZNTvKghy0MXuTKfNW+cd0m WHpQ== X-Received: by 10.180.101.98 with SMTP id ff2mr24251587wib.83.1421009970624; Sun, 11 Jan 2015 12:59:30 -0800 (PST) Received: from [192.168.1.199] ([176.12.145.6]) by mx.google.com with ESMTPSA id fc6sm7522394wib.12.2015.01.11.12.59.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jan 2015 12:59:30 -0800 (PST) Message-ID: <54B2E430.3050108@gmail.com> Date: Sun, 11 Jan 2015 22:59:28 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paul Wouters References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <54B295BC.9090605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth-01 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, 11 Jan 2015 20:59:34 -0000 Hi Paul, Valery, Please see below. Thanks, Yaron On 01/11/2015 06:34 PM, Paul Wouters wrote: > On Sun, 11 Jan 2015, Yaron Sheffer wrote: > > I sent Valery an updated version which he can hopefully incorporate in > this WGLC. I'll just comment on Yaron's remarks below. > >> - Unclosed sentence in the abstract: "It may be used to preserve >> anonymity of" > > I suggested a rewriten abstract to Valery. > If there's a newer and cleaner version of the draft, can you please submit it to make all our lives somewhat easier. >> - Reference to IKEv2: please use RFC 7296. > > Did that. > >> - 2.1: it may be trivial, but we want to add that the AUTH payload >> MUST be verified by the recipient. > > Sure. > >> - I don't think that we have consensus on "The Identification Data in >> Identity payload for the ID_NULL type MUST be absent". The asserted >> but unproven identity may be used for logging, or may be proven with a >> later authentication. Quoting from an email by Tero: "I think the most >> important point of this feature is that the client is UNAUTHENTICATED, >> not that it is ANONYMOUS." > > I think you mean to say the NULL Authentication Method does not require > ID_NULL. But obviously ID_NULL cannot have a payload. Because if you > give it one, what type would it be? :P > Agreed. I would prefer the NULL Authentication Method to not require ID_NULL. >> - "If endpoint receives a request to create an unauthenticated IKE SA >> from the IP address, which is configured on the endpoint to be >> authenticated, the request SHOULD be rejected." - I don't see why. >> What if there are several peers behind an IP address, some >> authenticated and some not? Maybe we need to think some more about the >> policy that each of the peers should enforce. >> >> - The issue of Traffic Selectors needs better treatment. Should we add >> a MUST for allocation of internal IP addresses? > > These issues are difficult and need to be addressed in the "opoprtunistic > ipsec" document. I'm not sure how much of this discussion belongs in > this document. I would prefer if this document keeps it focus on the > format of the Null Authentication Method and ID_NONE payloads. > (I think what I put in my suggestions to Valery is already too much for > this document) > > If you have more peers behind the same NAT, you need a GOOD strategy for > containing those private IPs or else one of those clients is going to > use 8.8.8.8 and steal the servers DNS traffic. I tend to agree. But in that case, the above two points need to be removed from the draft. And a more detailed (non-normative!) placeholder added to the Security Considerations, so that until we have an "opportunistic IPsec" draft, people will know where the minefields are. > > Paul From nobody Tue Jan 13 00:56: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 5E6B01ACE34; Tue, 13 Jan 2015 00:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9UYc7sqPJ2wX; Tue, 13 Jan 2015 00:56:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1531A00B6; Tue, 13 Jan 2015 00:56:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113085627.32517.72891.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 00:56:27 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 08:56:29 -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-02.txt Pages : 12 Date : 2015-01-13 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 un-authenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunsitic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonimity. 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: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 13 01:07:38 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 6B50F1A8A6C for ; Tue, 13 Jan 2015 01:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6LDLozocPgD for ; Tue, 13 Jan 2015 01:07:34 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A588D1A8A39 for ; Tue, 13 Jan 2015 01:07:33 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z12so1492643lbi.3 for ; Tue, 13 Jan 2015 01:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=2tdBk1XJ8+KKjBGSR+sOK00KcY1J7SPgm7VpZTbmt44=; b=qUQzocJA7EmQwnKre9+cG0DZUaDum+zdsBe//dRQ9+huoveEqGMbINf4Fzuey8lf6T N27IcFCcblZn0d/+AtdaUeXc41lxwIJ4GsT4Y6rQGCsaM8YopSfgS+WyyFMbBLGcRRRF Zhb2PvCDPr+x1CEx3mxUSZG51ufpOLFYAc1okxOFqg9gLjV5Ryj5XiTeUrrBjDHK3BbW pTcJTtxsLXgl231eBIgXLza4VMgRH1qgnds9PlIyynsvppcSGtA4kHhWeThdalhCgThg N8d+T8I4xcq8sVHkp5XmGNow11v4JJIk+laFZDLCZejuoyYtWWI3efAXGvMZs6dzNNFx KbWQ== X-Received: by 10.152.4.233 with SMTP id n9mr41411672lan.61.1421140052183; Tue, 13 Jan 2015 01:07:32 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id q17sm691308lal.2.2015.01.13.01.07.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 13 Jan 2015 01:07:31 -0800 (PST) Message-ID: <4DEE1E5627D942179CF5D6DA81ACB213@buildpc> From: "Valery Smyslov" To: References: <20150113085627.32517.72891.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 12:07:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 09:07:35 -0000 Hi all, I've posted a new version of the document. Paul Wouters is now a co-author. Paul has made a great job improving the language and extending the Security Consideration Section. I apologize for the delay, this version should really have been posted before the WGLC has beed announced. Please, use this version for WGLC reviews. Regards, Valery Smyslov. ----- Original Message ----- From: To: Cc: Sent: Tuesday, January 13, 2015 11:56 AM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > 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-02.txt > Pages : 12 > Date : 2015-01-13 > > 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 > un-authenticated IKE sessions for those use cases where a peer is > unwilling or unable to authenticate itself. This ensures IKEv2 can > be used for Opportunistic Security (also known as Opportunsitic > Encryption) to defend against Pervasive Monitoring attacks without > the need to sacrifice anonimity. > > > 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: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 13 12:39:30 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 505B31ACD46 for ; Tue, 13 Jan 2015 12:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 FqmtjiwgzhT0 for ; Tue, 13 Jan 2015 12:39:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264951ACD87 for ; Tue, 13 Jan 2015 12:39:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kMHWg2JfTzCfH for ; Tue, 13 Jan 2015 17:37:35 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=MHGcSCzz; dkim-adsp=pass 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 XgcY6k5bPwU5 for ; Tue, 13 Jan 2015 17:37:34 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 13 Jan 2015 17:37:34 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D7FA80046 for ; Tue, 13 Jan 2015 11:37:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421167053; bh=ZWC5TfhN9e2Y1CnC3PKyCpJXaWnkvZxpeEHCemy4cVw=; h=Date:From:To:Subject; b=MHGcSCzzeAKEHSG6U2kVA4sIat8liWKf4Y/HhnssJ10yzAGk6q+nYDVjYDUOGzBop PTKhsbT4dVK0yyrfOWt8SL73rgeCh+gcoSF+Kt5f1DXprGj7QvzqSvFunpdGtFJtKp MAsYsQwDZ12W8uxUMXtCpzMdq3YwiaphQ8mLMDnw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0DGbXbK009419 for ; Tue, 13 Jan 2015 11:37:33 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 Jan 2015 11:37:33 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: [IPsec] IKEv1 OSX Server interop issue 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, 13 Jan 2015 20:39:28 -0000 We received a bug report for a libreswan to OSX server interop failure: > 003 "ner" #2: DOI of ISAKMP Notification Payload has an unknown value: > 16777216 16777216 looks like someone with Apple forgot a htonl() entry: $ python Python 2.7.5 (default, Nov 3 2014, 14:33:39) [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> hex(16777216) '0x1000000' >>> import socket >>> socket.htonl(1) 16777216L We're going to patch libreswan to accept this weird value, but if there is anyone from Apple on this list, please pass this bug report along[1] Paul [1] Yes I used their developer reporting system before - didn't work out for me From nobody Tue Jan 13 12:39:36 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 27F0B1ACD46 for ; Tue, 13 Jan 2015 12:39:30 -0800 (PST) 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 5STmyOsb8s9w for ; Tue, 13 Jan 2015 12:39:28 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230F61ACD47 for ; Tue, 13 Jan 2015 12:39:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kMFVM39P2zCPY; Tue, 13 Jan 2015 16:06:19 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=nP1vvSI7; dkim-adsp=pass 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 U-AchW1piOnz; Tue, 13 Jan 2015 16:06:18 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 13 Jan 2015 16:06:18 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5589C8008E; Tue, 13 Jan 2015 10:06:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421161577; bh=3qXL+au8bYiT/XX/qIj8iDafuQY+A7X4zuPKQ8/8DK8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nP1vvSI7MW4m/NXRqV/BKanC/Hx+m4JNwYBfpT6Kn4Snb5kEdv4tequaJLhZAZox+ YWhIelyGP90B2cAOKdoMGy5J5Bm8Y9vaWW6nVt24IU2l/p0NqgCZwm9TR9Fv0coyiT 4CcCpDBvXR0rCBlt3ye2BrBk2XTWV9XgX0Wr8PEI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0DF6GIt016444; Tue, 13 Jan 2015 10:06:16 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 Jan 2015 10:06:16 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 13 Jan 2015 20:39:30 -0000 >> https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth So since the WGLC came onto us a little early, the document authors still have some different opinions about some of this. So let me raise those in the WGLC :) INITIAL_CONTACT Section 2.3 tries to address the problem of not being able to trust INITIAL_CONTACT. Normally this payload is only honoured after authentication, but we don't have a real authentication here, and one anonymous IKE SA should not be allowed to obsolete another IKE SA. Valery suggests sending liveness checks to all IKE SA's that used AUTH_NONE. I suggested sending liveness checks only to those IKE SA's that used the same IP address, thus limiting the scope to a more likely pool of possible orphaned SA's by a remote that crashed/restarted. Of course, implementations can be smart, and skip liveness checks for those IKE SA's whose IPsec SA is showing traffic now in in the very recent past. We need to consider the harm of leaving orphaned SA's versus the harm of being tricked into sending too many liveness probes. And in general, we need to ensure one IKE SA isn't sending a zillion useless IKE messages - as we've lost the protection of a real authentication to punish abusers by locking them out. (if you thought ddos-puzzles were interesting, come tackle this problem :) Traffic Selectors We touched a bit on the traffic selector problem. If a peer is able to pick its own address, it could attempt to steal traffic (say 8.8.8.8) from the server. We advise people to isolate these peers. We cannot fully disallow this because we need NAT-traversal support. Valery preferred server assigned IP addresses (using CP) which will work great in the "sensor network" but would cause overlapping problems with IKE peers that talk to multiple peers that hand out their own range of addresses. And opens up the reverse attack of the server stealing the client's 8.8.8.8 traffic. Some more discussion and insights on this would be useful. Additionally, if we allow some kind of narrowed traffic selector, malicious IKE peers would only need their one IP and could setup (protocol * sport * dport) IPsec SAs. Or a variant of this could be done with when allowing CREATE_CHILD_SA to setup a plethora of IPsec SAs. Restrictions based on IP address is hard, again because of the NAT support problem. What we tried to do with the security consideration section is to keep advise generic. Then specific opportunistic IPsec related issues could find themselves in a soon to be draft-ipsec-opportunistic document. Paul From nobody Tue Jan 13 12:39:38 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 BA2D81ACD79 for ; Tue, 13 Jan 2015 12:39:30 -0800 (PST) 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 LagjN5jkVXKZ for ; Tue, 13 Jan 2015 12:39:28 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF3B1ACD88 for ; Tue, 13 Jan 2015 12:39:27 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kMHZ73lt3zCg5 for ; Tue, 13 Jan 2015 17:39:43 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=CgcA3vTh; dkim-adsp=pass 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 M3SR4YAFs4pd for ; Tue, 13 Jan 2015 17:39:42 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 13 Jan 2015 17:39:42 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 96A8980046 for ; Tue, 13 Jan 2015 11:39:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421167181; bh=1bwUITAVOr/zE+RhSiCICTcQ35vEh4xCn6SeDyfG8z4=; h=Date:From:To:Subject; b=CgcA3vThBQr/A0ZAO9XPFh1J5i9EnLmQJbduV+3Rigus8eEBpXMaP49EVuXg0evd3 k+E12RdYEdGgYNBere/n9Ea/gs53WaVuq4ryUhHA5Ie/uLfXEiWCe9gs2kRa6g72De xPyk4WsdY0zDZwJYpZrJMSyQY7xc+vcSRMHI3Tdc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0DGdf2Z012941 for ; Tue, 13 Jan 2015 11:39:41 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 Jan 2015 11:39:41 -0500 (EST) From: Paul Wouters To: IPsecME WG Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd) 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, 13 Jan 2015 20:39:31 -0000 (seems previous message was lost) >> https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth So since the WGLC came onto us a little early, the document authors still have some different opinions about some of this. So let me raise those in the WGLC :) INITIAL_CONTACT Section 2.3 tries to address the problem of not being able to trust INITIAL_CONTACT. Normally this payload is only honoured after authentication, but we don't have a real authentication here, and one anonymous IKE SA should not be allowed to obsolete another IKE SA. Valery suggests sending liveness checks to all IKE SA's that used AUTH_NONE. I suggested sending liveness checks only to those IKE SA's that used the same IP address, thus limiting the scope to a more likely pool of possible orphaned SA's by a remote that crashed/restarted. Of course, implementations can be smart, and skip liveness checks for those IKE SA's whose IPsec SA is showing traffic now in in the very recent past. We need to consider the harm of leaving orphaned SA's versus the harm of being tricked into sending too many liveness probes. And in general, we need to ensure one IKE SA isn't sending a zillion useless IKE messages - as we've lost the protection of a real authentication to punish abusers by locking them out. (if you thought ddos-puzzles were interesting, come tackle this problem :) Traffic Selectors We touched a bit on the traffic selector problem. If a peer is able to pick its own address, it could attempt to steal traffic (say 8.8.8.8) from the server. We advise people to isolate these peers. We cannot fully disallow this because we need NAT-traversal support. Valery preferred server assigned IP addresses (using CP) which will work great in the "sensor network" but would cause overlapping problems with IKE peers that talk to multiple peers that hand out their own range of addresses. And opens up the reverse attack of the server stealing the client's 8.8.8.8 traffic. Some more discussion and insights on this would be useful. Additionally, if we allow some kind of narrowed traffic selector, malicious IKE peers would only need their one IP and could setup (protocol * sport * dport) IPsec SAs. Or a variant of this could be done with when allowing CREATE_CHILD_SA to setup a plethora of IPsec SAs. Restrictions based on IP address is hard, again because of the NAT support problem. What we tried to do with the security consideration section is to keep advise generic. Then specific opportunistic IPsec related issues could find themselves in a soon to be draft-ipsec-opportunistic document. Paul From nobody Tue Jan 13 15:17: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 345E01B2B84 for ; Tue, 13 Jan 2015 15:17:11 -0800 (PST) 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 auSm87to-2vo for ; Tue, 13 Jan 2015 15:17:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A3B1B2ABF for ; Tue, 13 Jan 2015 15:17:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kMSNc0LgYzCPY; Wed, 14 Jan 2015 00:17:04 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=htXrjd7i; dkim-adsp=pass 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 OxijGmkSXjKs; Wed, 14 Jan 2015 00:17:01 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 14 Jan 2015 00:17:01 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7F74C8004F; Tue, 13 Jan 2015 18:17:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421191020; bh=XZwqmunJ7M66BAJ4HnMATjDvyyMlUZIsW1CnBTHpjl4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=htXrjd7iT+Y3OMIBimwysu/zo+kPa+50Oz8NtqbjD1LuxamJjuUbZRY61AqT7Wr2T PRtXiB4zQO0bjv2y85G5Jn6jHj7inRjw2bJIA6YNtYbjEgZ7BklACweGvH6YtbaNNn 6Klep0xY2joTzcY1OdS1ngDkNoFga8OqqHkSxprI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0DNGxC6030523; Tue, 13 Jan 2015 18:16:59 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 Jan 2015 18:16:59 -0500 (EST) From: Paul Wouters To: "Graham Bartlett (grbartle)" In-Reply-To: Message-ID: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <363A367E1CF64C4C98586DC57F1AC987@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 13 Jan 2015 23:17:11 -0000 On Tue, 13 Jan 2015, Graham Bartlett (grbartle) wrote: > Hi Valery / Paul [ CC:ing this back to the list ] >>> Or maybe you have 1000 sensors and there is only 250 IP addresses in the >>> DHCP pool, as you say the sensor is meant to wake, then send, then >>> sleep. >>> But it wakes, sends and keeps the IKE SA open, which prevents other >>> sensors connecting. >> >> Please, see above. I assumed it should delete IKE SA before going into >> sleep. > > It should delete the SA (in a perfect world), but what if it didn't sleep > and stayed awake forever.. As peers can't be authenticated then it allows > an easy self inflicted DOS. :-) Well, anonymous IPsec is a self inflicted DOS :) If it remains awake then normal liveness checks combined with IKE/IPsec SA lifetimes should handle the cleanup. > What I was alluding to is covered now in section 3.2 (and in Paul's > email). However I think some final words at the end of 3.2 such as 'For > this reason systems should be designed to accommodate legitimate and > non-legitimate non-authenticated peers', would then make this message > crystal clear. Can you propose text? I personally find "legitimate and non-legitimate non-authenticated peers" very unclear. I don't think a server can ever tell those two aparts based on IKE. > The following are just minor syntax errors which I noticed; > > 'The KEv2 Authentication Method value for the NULL Authentication' - > missing 'I' ? > > 'Un-authenticated IKE sessions MUST only attempted when authenticated' - > 'MUST only be attempted' ? Thanks, we will fix those in the next version. > I have seen Paul's email from this afternoon which covers everything I was > trying to say (and more!). My personal feeling is that a new session being > authenticated should not initiate a liveness check on ALL connected peers. > I feel that the liveness check should be performed on an idle time (or > Pauls idea of only checking the same IP address), otherwise an attacker > would know when they connect then the headend sends a liveness check to > all connected peers, if you had a headend serving many 1000s of peers this > is an easy amplification attack. And as Valery said, if your IKE SA shows activity (or perhaps even if the IPsec SA shows activity on the inbound SA) why not skip the liveness check for those peers, even if those are using the same IP. I found it interesting that Valery and I think quite differently about liveness. I always think of it as something to do on idle peers to see if they didn't vanish. Valery thinks there is no point sending a liveness check on an idle peer if you don't have any traffic anyway. It all comes down to which resources you are protecting. If you have enough memory, Valery's approach is valid, don't bother with sending liveness packets because the IKE SA and IPsec SA are just a few bytes of lingering data. Not worth sending (encrypted) network traffic for. But if the host is getting too many IKE/IPsec SAs, those might be worth poking to clean up. Paul From nobody Wed Jan 14 00:32: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 62AFC1A6F96 for ; Wed, 14 Jan 2015 00:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V86aXTIl9oT0 for ; Wed, 14 Jan 2015 00:32:21 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E84B1A0025 for ; Wed, 14 Jan 2015 00:32:21 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z12so6754867lbi.3 for ; Wed, 14 Jan 2015 00:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=E8c28rDqBOK/cY6/nOaPCtVP0D89T9ZK4wHzaF+iteM=; b=cuec8XdLbn5qj8y1yvUzoXrECOiBzUOeOH4VjHp+VRg627/jc/sAejHA6UjtP/kSqk X8SAoxNXHhnY/U1+eLP0pTQpBlYRhcdHKAygc/7CrB1kslp6rVDgqny3ciqiOGwktzvz Z0pHTolDhzJQfO4s/13YVECNWSChcwJtJsvCERom9+u+cvgc7BTG31odm/vB3tW/4Yr1 k6fA5BUDYg10NM1qbYMxYRzvlcFBrOtJy/RrGhfTs53DwzZ7GP9A1hcifNDwioFUGIZQ 6Z3BKLarvTG7/P13IcpypkoW3jAfwADEY+AzJosTncQoX25cvJL3MEN4XRvWrDI+lw/b G3CA== X-Received: by 10.152.19.7 with SMTP id a7mr2651553lae.16.1421224339715; Wed, 14 Jan 2015 00:32:19 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id e1sm1525039lah.43.2015.01.14.00.32.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 14 Jan 2015 00:32:19 -0800 (PST) Message-ID: <038B7179C6EB4C5BB2A110AD37541204@buildpc> From: "Valery Smyslov" To: "Paul Wouters" , "IPsecME WG" References: Date: Wed, 14 Jan 2015 11:32:39 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd) 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, 14 Jan 2015 08:32:24 -0000 Some clarifications below. > (seems previous message was lost) > >>> https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth > > So since the WGLC came onto us a little early, the document authors > still have some different opinions about some of this. So let me raise > those in the WGLC :) > > INITIAL_CONTACT > > Section 2.3 tries to address the problem of not being able to trust > INITIAL_CONTACT. Normally this payload is only honoured after > authentication, but we don't have a real authentication here, and one > anonymous IKE SA should not be allowed to obsolete another IKE SA. > > Valery suggests sending liveness checks to all IKE SA's that used > AUTH_NONE. > > I suggested sending liveness checks only to those IKE SA's that used > the same IP address, thus limiting the scope to a more likely pool > of possible orphaned SA's by a remote that crashed/restarted. I don't think that restricting liveness checks in this case to the same IP address covers all the situations. The peer may crash, reboot and get new IP from its ISP and then create new IKE SA. In this situation (very common, not?) the proposed restriction will prevent the server from finding that old stale SA and it will continue to consume resources untill the server decides to send smth. over it or to check its liveness based on a long period of its inactivity or until its lifetime is over. I don't think that the document should impose such a restriction, but instead it should give some guidance of how implementation should behave in this situation. To clarify my position: I don't propose that implementation should blindly send liveness check messages on every SA once new one is created. If SA is active (there was recent incoming traffic over it) or implementation has just successfully finished liveness check on that particular SA, then there is no need to do it again. But if some unauthenticated SAs are idle for a while, then the event of creating new unauthenticated IKE SA MAY (not SHOULD, not MUST) trigger the liveness check on those SAs, regardless of their IP addresses. > Of course, implementations can be smart, and skip liveness checks for > those IKE SA's whose IPsec SA is showing traffic now in in the very > recent past. > > We need to consider the harm of leaving orphaned SA's versus the harm > of being tricked into sending too many liveness probes. > > And in general, we need to ensure one IKE SA isn't sending a zillion > useless IKE messages - as we've lost the protection of a real > authentication to punish abusers by locking them out. (if you thought > ddos-puzzles were interesting, come tackle this problem :) This is interesting problem, but I think that in general implementations should be robust enough to deal with that. Of course you may punish abusers if you know their IDs, but it would be a shame on you if those abusers could crash your implementation, just because their implementations are buggy and send zillion messages. > Traffic Selectors > > We touched a bit on the traffic selector problem. If a peer is able > to pick its own address, it could attempt to steal traffic (say 8.8.8.8) > from the server. We advise people to isolate these peers. We cannot > fully disallow this because we need NAT-traversal support. Valery > preferred server assigned IP addresses (using CP) which will work great > in the "sensor network" but would cause overlapping problems with IKE > peers that talk to multiple peers that hand out their own range of > addresses. The server assigned IP addresses using CP is a standard way of dealing with it. I admit that others are possible and don't want to limit implementations to the only one. And in general the problem of overlapping is irrelevant to NULL Auth. > And opens up the reverse attack of the server stealing the > client's 8.8.8.8 traffic. Some more discussion and insights on this > would be useful. > > Additionally, if we allow some kind of narrowed traffic selector, > malicious IKE peers would only need their one IP and could setup > (protocol * sport * dport) IPsec SAs. Or a variant of this could > be done with when allowing CREATE_CHILD_SA to setup a plethora of > IPsec SAs. Restrictions based on IP address is hard, again because > of the NAT support problem. I think it is a server's policy issue. It can always restrict the number of IPsec SAs from a single peer by using NO_ADDITIONAL_SAS notification. The document should not impose any restrictions here, IMHO. > What we tried to do with the security consideration section is to keep > advise generic. Then specific opportunistic IPsec related issues could > find themselves in a soon to be draft-ipsec-opportunistic document. Exactly. > Paul Valery. From nobody Sun Jan 18 07:16:32 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 0EFB61B2A00 for ; Sun, 18 Jan 2015 07:16:30 -0800 (PST) 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 F39GAFZmw6Mc for ; Sun, 18 Jan 2015 07:16:28 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481E91B29FE for ; Sun, 18 Jan 2015 07:16:28 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id x3so987869wes.1 for ; Sun, 18 Jan 2015 07:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=brH6RNNpAnNov+EXQlbUxbnBLU7BUKFbH6gnkdhXP98=; b=xcU6Fd4mernE/LnKCz4hy9qpn1N5bZ/pCOf6asimT2yB3wmNB3hYbWfK5/Ygyi9bpq qceYPpoNrM2mrywxbpPdezU2tfmDQjOytMGY0Ku5aclryzzmWKegOtZ/W5/EbQSnxSAW w1isP/OOkwpMVy3WnL99IKGR6jh8uPNp82uCiavHekIV9iVuSCtVS/6Cg23RmhuCdr9i mDJmGUP7lsFrdQROR29rHrkBhueiUUffOq1AO8itbCpLibKEf/ZBlBogoMYEawiNCEZY jzuPMnvhPd2N8ivwBPvFSmAGx3jGWvf7z4uA8xjVLRYNrJWHTa0GLGDyylXU45ezZyij ZczQ== X-Received: by 10.180.84.98 with SMTP id x2mr25464983wiy.14.1421594186963; Sun, 18 Jan 2015 07:16:26 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id bj3sm10665774wib.3.2015.01.18.07.16.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Jan 2015 07:16:26 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_10FA1499-9CB2-4F12-B8CA-7A7D38544C56" Message-Id: Date: Sun, 18 Jan 2015 17:16:23 +0200 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [IPsec] Status of IKE DDoS 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, 18 Jan 2015 15:16:30 -0000 --Apple-Mail=_10FA1499-9CB2-4F12-B8CA-7A7D38544C56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all A few updates about the IKE DDoS draft: 1. Valery Smyslov has agreed to join as co-author. Thanks, Valery 2. We have moved the source onto github [1], so now anyone can easily = create pull requests. 3. I=E2=80=99ve been asked by the chairs to emphasize that despite (2), = the discussion is to take place on this list, not on github. 4. Valery has created the first pull request [2], about puzzle = algorithm negotiation (new thread soon) Yoav [1] = https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-ddos= -protection.xml = [2] https://github.com/ietf-ipsecme/drafts/pull/2 = --Apple-Mail=_10FA1499-9CB2-4F12-B8CA-7A7D38544C56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all

A = few updates about the IKE DDoS draft:

 1. Valery Smyslov has agreed to = join as co-author. Thanks, Valery
 2. We have = moved the source onto github [1], so now anyone can easily create pull = requests.
 3. I=E2=80=99ve been asked by the = chairs to emphasize that despite (2), the discussion is to take place on = this list, not on github.
 4. Valery has = created the first pull request [2], about puzzle algorithm negotiation = (new thread soon)

Yoav

[1] https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-i= psecme-ddos-protection.xml
[2] https://github.com/ietf-ipsecme/drafts/pull/2

= --Apple-Mail=_10FA1499-9CB2-4F12-B8CA-7A7D38544C56-- From nobody Sun Jan 18 07:39:09 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 449581ACD07 for ; Sun, 18 Jan 2015 07:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqQsi6CMlPjA for ; Sun, 18 Jan 2015 07:39:07 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8BF1B2A03 for ; Sun, 18 Jan 2015 07:39:07 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id z12so27796730wgg.13 for ; Sun, 18 Jan 2015 07:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=wuAdsac7EabvVK7hy8JSFKjsfSN5qdaEf3TMUT1M+t0=; b=Ikc88xE/sYPkLiCzRY783k9ZqCYlboujy6ZDvEQ9YfRmlHnCOwqzQf5p6NI4/VMFtX oCMv+/4QXsr8N8xDqt0afhWI57VaVx5WnpRrosmYhs7ifjKRW6Qq9qXI1nXYVEq5mwQO Y6W//0c5aGKY2fxN/9G+qxvxUqKMSaXRE9KgJdyw/CuFV5aoZWNTWD2Ot/uKzd+52S+1 JctknvB48Xo/JH8Pr7WyxJM1GOsQLrICzfHx/sPXjoMTKAwXW/D+8Q7YdLQgwxR2srT7 BRnBr4dgnCpzzAcd1gXQyZ8C7znN5IKPT4sKW1NLqPMveWsE3wue8U5DPMMD6MGJzuxv Kqfw== X-Received: by 10.194.48.109 with SMTP id k13mr50886489wjn.7.1421595546308; Sun, 18 Jan 2015 07:39:06 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id gl1sm5812043wib.13.2015.01.18.07.39.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Jan 2015 07:39:05 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_2EB15AC3-62AE-40AF-AED7-7DD9A11D3D5E" Message-Id: Date: Sun, 18 Jan 2015 17:39:04 +0200 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [IPsec] Puzzle algorithm negotiation 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, 18 Jan 2015 15:39:09 -0000 --Apple-Mail=_2EB15AC3-62AE-40AF-AED7-7DD9A11D3D5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2 = Hi, Valery has created this pull request. During the meeting in Honolulu and = subsequent discussion on the list, several people requested that there = be a negotiation of the algorithm used in the puzzle rather than fixing = it to SHA-256. The pull request suggests figuring out which algorithms the Initiator = supports by examining the SA payload in the IKE_SA_INIT request, and = using the PRF algorithms. I=E2=80=99m posting this to the list, even thought we=E2=80=99re not = sure about this. Specifically, PRF_AES128_XCBC and (I think) = PRF_AES128_CMAC won=E2=80=99t work with the bitcoin-like puzzle that is = currently in the draft. Why? For convenience assume a 16-byte cookie, a fixed zero IV (as always in = AES-XCBC) and fixed zero key. So let Y =3D AESENC(key, IV XOR COOKIE) =3D AESENC(zero, COOKIE) Let Z =3D AESDEC(key, zero) =3D AESDEC(zero, zero) Extend the cookie by Y XOR Z. The result will give you a 128-bit tag of all zeros. Way too easy. Another way to do this is to add a notification in the Initiator=E2=80=99s= request listing the hash algorithms that it supports. We could reuse = the RFC 7427 registry of hash algorithms.=20 Personally, I really don=E2=80=99t like this algorithm agility, because = we don=E2=80=99t want to give the Initiator the options of a hard vs = easy puzzle. So suppose the Responder supports two algorithms, SHA-256 = and SHA-512, and that the latter is half as fast as the former, then a = SHA-512 puzzle would have to have 1 bit less than the SHA-256 puzzle. = But in fact, we know that SHA-512 is faster on 64-bit platforms, while = SHA-256 is faster on 32-bit platforms. Add some GOST-certified hash to = the mix, and the administrator=E2=80=99s task becomes that much harder. = OTOH often when a protocol is published without algorithm agility, we = end up extending it later. Yoav --Apple-Mail=_2EB15AC3-62AE-40AF-AED7-7DD9A11D3D5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2

Hi,

Valery has created this = pull request. During the meeting in Honolulu and subsequent discussion = on the list, several people requested that there be a negotiation of the = algorithm used in the puzzle rather than fixing it to SHA-256.

The pull request = suggests figuring out which algorithms the Initiator supports by = examining the SA payload in the IKE_SA_INIT request, and using the PRF = algorithms.

I=E2=80=99m posting this to the list, even thought we=E2=80=99r= e not sure about this. Specifically, PRF_AES128_XCBC and (I think) = PRF_AES128_CMAC won=E2=80=99t work with the bitcoin-like puzzle that is = currently in the draft.

Why?

For convenience assume a 16-byte cookie, a fixed zero IV (as = always in AES-XCBC) and fixed zero key.

So let Y =3D AESENC(key, IV XOR COOKIE) = =3D AESENC(zero, COOKIE)
Let Z =3D AESDEC(key, = zero) =3D AESDEC(zero, zero)
Extend the cookie by Y = XOR Z.

The = result will give you a 128-bit tag of all zeros. Way too easy.

Another way to do this = is to add a notification in the Initiator=E2=80=99s request listing the = hash algorithms that it supports. We could reuse the RFC 7427 registry = of hash algorithms. 

Personally, I really don=E2=80=99t like this algorithm = agility, because we don=E2=80=99t want to give the Initiator the options = of a hard vs easy puzzle. So suppose the Responder supports two = algorithms, SHA-256 and SHA-512, and that the latter is half as fast as = the former, then a SHA-512 puzzle would have to have 1 bit less than the = SHA-256 puzzle. But in fact, we know that SHA-512 is faster on 64-bit = platforms, while SHA-256 is faster on 32-bit platforms. Add some = GOST-certified hash to the mix, and the administrator=E2=80=99s task = becomes that much harder. OTOH often when a protocol is published = without algorithm agility, we end up extending it later.

Yoav


= --Apple-Mail=_2EB15AC3-62AE-40AF-AED7-7DD9A11D3D5E-- From nobody Sun Jan 18 20:26: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 333721AD0AD for ; Sun, 18 Jan 2015 20:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.173 X-Spam-Level: * X-Spam-Status: No, score=1.173 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DATE_IN_PAST_12_24=1.049, 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 ETJ_-TgzXKcg for ; Sun, 18 Jan 2015 20:26:02 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8371ACE09 for ; Sun, 18 Jan 2015 20:26:02 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so36195923pab.6 for ; Sun, 18 Jan 2015 20:26:01 -0800 (PST) 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=6PP9VrG6I6LreXN0vflgu6IilCAvWVz7GQ7yV4RsU9M=; b=q60vdNORqdfq4+TBDL7TePIw0+ywdRLnYZday2e61xZX7Ywl1T/UIE6KN3HCP+s6H0 frO0RVXNBJP3hKVdoOAF085g9A9OOfgg2t0qJ/iZ8RGxoPqahra/U0eCNoEuB9DQ2HhP 2g88LTVxefkMJZmBwoZJhNH/nFraOsYVfsiFBeBNjtsLRCPJYo7vXMCpCGV6BGvecglQ d9+vXKX67LcK6ohiIplm717P0wReR9QdoQM9HLTzMbM2jk0jyDUUX+V6n9q7y1Dkxjks GVsiSDcAjKGDs26R3ksVaynEHziQQCmdhat4BIG4K2CP/CuR6qZzJ5yBQhPY44S7f5+9 DyVw== X-Received: by 10.66.253.197 with SMTP id ac5mr14449306pad.152.1421641561357; Sun, 18 Jan 2015 20:26:01 -0800 (PST) Received: from [192.168.3.166] (50-203-213-210-static.hfc.comcastbusiness.net. [50.203.213.210]) by mx.google.com with ESMTPSA id vz1sm10237907pbc.55.2015.01.18.20.25.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jan 2015 20:26:00 -0800 (PST) Message-ID: <54BB6795.4050302@gmail.com> Date: Sun, 18 Jan 2015 09:58:13 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: ipsec Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 04:26:03 -0000 Hi Valery, Paul,

I re-read the new draft and I must say it is much clearer than the previous version. Still, a few comments:
  • Please spell-check the draft. There are numerous typos.
  • The "privileged IKE operations" is obviously a bit thin. "Initial Contact" may be a good example of an operation that we'd be better off without. But if we don't have any specific examples, let's remove this section.
  • Implementations MAY force... to single host-to-host IPsec SAs. If we cannot come up with a good way for an unauthenticated peer to prove ownership of SA ranges (whatever "ownership" might mean in this context), then I guess we should change the MAY into a SHOULD.
  • We are still using IP addresses to identify peers: "if an IKE peer receives... from an IP address that matches a configured connection". I think an IKE peer that supports null auth should be able to distinguish peers depending on other characteristics, and should be able to handle mixed configurations/policies even for a single IP address.
  • I suggest adding this short subsection to the Security Considerations:

Although this document discourages the use of non-null ID payloads to identify an unauthenticated peer, IKEv2 provides channel bindings capabilities and those may be used to authenticate this identity at a later time, while binding the authenticated identity with the original IKE exchange. This applies to a related but distinct use case, where peers cannot be authenticated at the time of the exchange but do not wish to remain anonymous. Please see [AutoVPN] for one way of after-the-fact authentication of an IKE peer.


[AutoVPN] draft-sheffer-autovpn, 2014.

From nobody Sun Jan 18 21:31:08 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 CBE581AD0C1 for ; Sun, 18 Jan 2015 21:31:04 -0800 (PST) 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 YZ6TGNdg5LvY for ; Sun, 18 Jan 2015 21:31:01 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FCC1AD0C0 for ; Sun, 18 Jan 2015 21:31:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kQhRj3FDsz9gg; Mon, 19 Jan 2015 06:30:57 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=NoMLEkHi; dkim-adsp=pass 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 z0hYlwknSjPD; Mon, 19 Jan 2015 06:30:55 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Jan 2015 06:30:55 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 683288004F; Mon, 19 Jan 2015 00:30:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421645453; bh=IFfTb+jKDt655HH446iNIo+R60gwsmyOMhJ/FXjpE5Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NoMLEkHiVGZ4vfN0tj7iNuiEDw4kfh132InAZIjCYAcQ1cbJMtGSPlpN0bGWW92uh cySnleSJD1BTk509fg0drJodmhgRV6uLTn1beZTWW+OL+sYuiBWClfjz9O6fjgFQa7 K6fjPhtyT0iD7zAdGtlRS5QHGwkDgKRS012NpaIE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0J5Urgf007376; Mon, 19 Jan 2015 00:30:53 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 19 Jan 2015 00:30:52 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <54BB6795.4050302@gmail.com> Message-ID: References: <54BB6795.4050302@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 05:31:05 -0000 On Sun, 18 Jan 2015, Yaron Sheffer wrote: > I re-read the new draft and I must say it is much clearer than the previous version. Still, a few comments: > * Please spell-check the draft. There are numerous typos. Will do. > * The "privileged IKE operations" is obviously a bit thin. "Initial Contact" may be a good example of an operation that we'd be better > off without. But if we don't have any specific examples, let's remove this section. That was partially because Valery and I didn't fully agree. Which means it might not belong in this document. Initial Contact is addressed in the document already in its own section. The question for example is about CREATE_CHILD_SA. Which comes back to your point below about making claims of owning an IP range that cannot be verified without an identity. I'm thinking with my OE hat on, so I am perfectly fine with restricting things to a single ip-ip connection (with natt support) and so in such a case the initial exchange is all that is needed and CREATE_CHILD_SA is never a valid exchange. > * Implementations MAY force... to single host-to-host IPsec SAs. If we cannot come up with a good way for an unauthenticated peer to > prove ownership of SA ranges (whatever "ownership" might mean in this context), then I guess we should change the MAY into a SHOULD. I even wanted a MUST, for the exact same reason. Any claim of IP address ownership other than the apparent source ip is dangerous. If the party does not authenticate, we cannot trust any claim. And two clients could attempt to claim the same ranges to get each other traffic. > * We are still using IP addresses to identify peers: "if an IKE peer receives... from an IP address that matches a configured > connection". I think an IKE peer that supports null auth should be able to distinguish peers depending on other characteristics, and > should be able to handle mixed configurations/policies even for a single IP address. You might be able to distinguish, but there is (per definition with auth_null) no proof, so any decisions based on apparent distinction would be very insecure. I'm not sure how you would support mixing auth and auth_null. If I setup a PSK between 1.2.3.4 and 5.6.7.8, and my 1.2.3.4 server suddenly gets AUTH_NULL, it has to reject it based on the wrong type of AUTH TYPE payload. If it would not reject it, would it mean this un-authenticated client mayb setup an IPsec SA that was supposed to be protected and limited to a machine that knows the PSK? > * I suggest adding this short subsection to the Security Considerations: > > Although this document discourages the use of non-null ID payloads to identify an unauthenticated peer, IKEv2 provides channel bindings > capabilities and those may be used to authenticate this identity at a later time, while binding the authenticated identity with the > original IKE exchange. This applies to a related but distinct use case, where peers cannot be authenticated at the time of the exchange > but do not wish to remain anonymous. Please see [AutoVPN] for one way of after-the-fact authentication of an IKE peer. If there is to be "authentication later", say through an Informational Exchange, then the time to present your ID (and your ID TYPE) is during that later authentication step. There is no good reason to throw in an untrustable identifier. It will only lead to implementation errors and security issues. I find channel binding extremely dangerous. It adds a lot of complexity for something that can simple be done with seperate or new IKE SAs. That is, an IKE peer could start with AUTH_NONE and later if it would need access to some non-public IP range, decide to start another IKE SA that is authenticated to the same peer. Mixing that all into a single IKE SA for complicated handovers seems unneccesary and prone to errors. Additionally, I have no idea how this channel binding is supposed to affect applications. If the remote peer gives me an AUTH_NULL based IPsec SA to 1.2.3.4, and later bumps that up to PSK authenticated, what does that mean for an application? What does it mean for the existing TCP connection to 1.2.3.4 going through ESP? You might have valid use cases with auto-vpn, but then, like for opportunustic IPsec, those use cases and their security considerations probably belong in their respective documents. I think this document should only put out a warning, especially to implementors, to think about what it means to have unauthenticated IKE and IPsec SAs. Paul From nobody Mon Jan 19 00:01:59 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 DB8BF1AD1BF for ; Mon, 19 Jan 2015 00:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 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, J_CHICKENPOX_64=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-bvG8pv_wWc for ; Mon, 19 Jan 2015 00:01:56 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB941ACEBD for ; Mon, 19 Jan 2015 00:01:55 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so27262186lab.6 for ; Mon, 19 Jan 2015 00:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type; bh=L9Uumwi/DgBoUDgQoTFZFFf9WHgjIH75jn43ytdAzKA=; b=TWhnZ+Gmu7BuiAOcEyYLkyXvEespXiRFVVKPyEKQRZTwsi6VteUrIvVY10A9WbKSpU Xy8V2YU1wZSykHdrxohfWbx4l3QBbei3U9sJcB9vS3OJ1No3xpewnJxpsHydGrTYwoFa A815MR729j5eDf/moa8VNLj2ys94ThyxNKPRopcc/S64rlTtVQSeWaM/WLqDmolxKVwK PaIRK288U7yyg0B12VXnOPo+lpWBQbnErad34LFmdi1x3O1X/mVU+wkUaMfGe0Nx0LYh hYbKdSinsuFz8s+jiCXtdpYBC4K4QjjEyZGDVKJrl0vfDaAlYF9AsEBBPTsqsOfynKlc n0JQ== X-Received: by 10.112.78.39 with SMTP id y7mr29253179lbw.42.1421654513965; Mon, 19 Jan 2015 00:01:53 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id pn7sm2888375lbb.6.2015.01.19.00.01.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 19 Jan 2015 00:01:53 -0800 (PST) Message-ID: <0305AC94D9084D07B34DB45847595AD6@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "ipsec" References: Date: Mon, 19 Jan 2015 11:02:31 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06C2_01D033D7.6BF1AC50" 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] Puzzle algorithm negotiation 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, 19 Jan 2015 08:01:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06C2_01D033D7.6BF1AC50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yoav, Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2 Hi, Valery has created this pull request. During the meeting in Honolulu = and subsequent discussion on the list, several people requested that = there be a negotiation of the algorithm used in the puzzle rather than = fixing it to SHA-256. The pull request suggests figuring out which algorithms the Initiator = supports by examining the SA payload in the IKE_SA_INIT request, and = using the PRF algorithms. I=E2=80=99m posting this to the list, even thought we=E2=80=99re not = sure about this. Specifically, PRF_AES128_XCBC and (I think) = PRF_AES128_CMAC won=E2=80=99t work with the bitcoin-like puzzle that is = currently in the draft. Why? For convenience assume a 16-byte cookie, a fixed zero IV (as always in = AES-XCBC) and fixed zero key. So let Y =3D AESENC(key, IV XOR COOKIE) =3D AESENC(zero, COOKIE) Let Z =3D AESDEC(key, zero) =3D AESDEC(zero, zero) Extend the cookie by Y XOR Z. The result will give you a 128-bit tag of all zeros. Way too easy. You forgot about the mandatory 10* padding in AES-XCBC. So, the result of AESDEC(zero, zero) should not be a random string, but should look like properly padded one. But anyway, I think that if we use PRF for puzzles, then the puzzle = definition should be changed. Let R=3DPRF(K,S). Then the puzzle should be: using supplied cookie as = message S, find a key K so, that result R contains the requested number of trailing = zero bits. I'm not a cryptographer, but I think this variant of puzzle should be = secure for all PRFs, defined in IPsec. Why? First, every secure PRF is a secure = MAC=20 (not visa versa). This is pointed out by several sources. Then, secure = MAC should not allow attacker to recover a key given the message and the authentication tag. In our case the authentication tag is not fully = given, but it must have some properties (desired number of trailing zero bits), so it is not arbitrary. Another way to do this is to add a notification in the = Initiator=E2=80=99s request listing the hash algorithms that it = supports. We could reuse the RFC 7427 registry of hash algorithms.=20 I don't think this is a good idea. First, it will require initiator to = include=20 a list of supported hash algorithms into request message. This will=20 unnecessary increase its size in all cases: at this point initiator has no idea whether responder will ever use puzzles or even whether it supports them. I think this is a waste of resources, especially taking into consideration that we may reuse=20 information, that is always present in the request message. Personally, I really don=E2=80=99t like this algorithm agility, = because we don=E2=80=99t want to give the Initiator the options of a = hard vs easy puzzle. So suppose the Responder supports two algorithms, = SHA-256 and SHA-512, and that the latter is half as fast as the former, = then a SHA-512 puzzle would have to have 1 bit less than the SHA-256 = puzzle. But in fact, we know that SHA-512 is faster on 64-bit platforms, = while SHA-256 is faster on 32-bit platforms. Add some GOST-certified = hash to the mix, and the administrator=E2=80=99s task becomes that much = harder.=20 If the difference in algorithms speeds is significant, then some weights = could be added to algorithm definitions to make the required time to solve puzzle = roughly the same on the same platform. OTOH often when a protocol is published without algorithm agility, we = end up extending it later. Exactly. Yoav Regards, Valery. ------=_NextPart_000_06C2_01D033D7.6BF1AC50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Yoav,
Pull=20 Request: https://github.com= /ietf-ipsecme/drafts/pull/2

Hi,

Valery has created this pull request. During the meeting in = Honolulu and=20 subsequent discussion on the list, several people requested that there = be a=20 negotiation of the algorithm used in the puzzle rather than fixing it = to=20 SHA-256.

The pull request suggests figuring out which algorithms the = Initiator=20 supports by examining the SA payload in the IKE_SA_INIT request, and = using the=20 PRF algorithms.

I=E2=80=99m posting this to the list, even thought we=E2=80=99re = not sure about this.=20 Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC = won=E2=80=99t work with=20 the bitcoin-like puzzle that is currently in the draft.

Why?

For convenience assume a 16-byte cookie, a fixed zero IV (as = always in=20 AES-XCBC) and fixed zero key.

So let Y =3D AESENC(key, IV XOR COOKIE) =3D AESENC(zero, = COOKIE)
Let Z =3D AESDEC(key, zero) =3D AESDEC(zero, zero)
Extend the cookie by Y XOR Z.
 
The result will give you a 128-bit tag of all zeros. Way too=20 easy.
You forgot about the mandatory 10* padding in=20 AES-XCBC.
So, the result of AESDEC(zero, zero) should not be a = random
string, but should look like properly padded = one.
 
But anyway, I think that if we = use PRF for=20 puzzles, then the puzzle definition should be = changed.
 
Let R=3DPRF(K,S). Then the puzzle should be: using = supplied=20 cookie as message S,
find a key K so, that result R contains the = requested number=20 of trailing zero bits.
 
I'm not a cryptographer, but I think = this variant of=20 puzzle should be secure
for all PRFs, defined in IPsec. Why? First, every = secure PRF=20 is a secure MAC
(not visa versa). This is pointed out by several = sources.=20 Then, secure MAC
should not allow attacker to recover a key given the = message=20 and
the authentication tag. In our case the = authentication tag is=20 not fully given,
but it must have some properties (desired number of = trailing=20 zero bits),
so it is not arbitrary.
Another way to do this is to add a notification in the = Initiator=E2=80=99s=20 request listing the hash algorithms that it supports. We could reuse = the RFC=20 7427 registry of hash algorithms. 
I don't think this is a good idea. First, it = will require=20 initiator to include
a list of supported hash algorithms into request = message. This=20 will
unnecessary increase its size in all cases: at this = point=20 initiator
has no idea whether responder will ever use puzzles = or=20 even
whether it supports them. I think this is a waste of = resources,
especially taking into consideration that we may = reuse=20
information, that is always present in the request=20 message.
Personally, I really don=E2=80=99t like this algorithm agility, = because we don=E2=80=99t=20 want to give the Initiator the options of a hard vs easy puzzle. So = suppose=20 the Responder supports two algorithms, SHA-256 and SHA-512, and that = the=20 latter is half as fast as the former, then a SHA-512 puzzle would have = to have=20 1 bit less than the SHA-256 puzzle. But in fact, we know that SHA-512 = is=20 faster on 64-bit platforms, while SHA-256 is faster on 32-bit = platforms. Add=20 some GOST-certified hash to the mix, and the administrator=E2=80=99s = task becomes that=20 much harder.
If the difference in algorithms speeds is = significant, then=20 some weights could be
added to algorithm definitions to make the = required time=20 to solve puzzle roughly the same
on the same platform.
OTOH often when a protocol is published without algorithm = agility, we end=20 up extending it later.
Exactly.
Yoav
Regards,
Valery.
 
------=_NextPart_000_06C2_01D033D7.6BF1AC50-- From nobody Mon Jan 19 05:32: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 A14D31AD2A9 for ; Mon, 19 Jan 2015 05:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukS2ydQb7PdF for ; Mon, 19 Jan 2015 05:32:09 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969E51ACE1A for ; Mon, 19 Jan 2015 05:32:08 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id hv19so1371722lab.3 for ; Mon, 19 Jan 2015 05:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=7wipDbVizFfNZz4DswYUvoO8oBJBYUhmWUmQGbwU6ts=; b=NOmJRJgjteq84nwou4ZEjcCYu8cArdsWE1w0BtDA7t2d54/nSZ+kARsjhJWUcNUC9t /+A+iRF2oqwGvsipx5ZfHUkG58WU1IvRvXuGjn8PD02mqp+AkSQlbMnQGBwPwVRBB1YF LDjwtAtMwBsLCF1nipB4gsXQ/GqzskTLhL8ZUIg4NDc5Fozi5a+Q88wmIXrxWZTlZ7KV 1DTQWvnZjWkbPgsE8DLviaLblJol5d0mOMDQFFreUexmWGhqa61cIvntD24eUgjq0dv1 zeOVSBQuUApiju8+Qta/T01saP8rSN4mpNUQ27Jgl+NzZoQf+TQK4ERVXu0sM0TkG84W B9JQ== X-Received: by 10.112.119.201 with SMTP id kw9mr30350500lbb.99.1421672478360; Mon, 19 Jan 2015 05:01:18 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id pn7sm3071552lbb.6.2015.01.19.05.01.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 19 Jan 2015 05:01:17 -0800 (PST) Message-ID: <00768F90B3184B5181EB7A2D0E664DBC@buildpc> From: "Valery Smyslov" To: "Paul Wouters" , "Yaron Sheffer" References: <54BB6795.4050302@gmail.com> Date: Mon, 19 Jan 2015 16:01:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 13:32:11 -0000 Hi Yaron, Paul, >> * The "privileged IKE operations" is obviously a bit thin. "Initial >> Contact" may be a good example of an operation that we'd be better >> off without. But if we don't have any specific examples, let's remove >> this section. I agree that this section currently is vague. Paul has some examples of "privileged IKE operations" in his mind, so I think he will fill this section with them. >> * Implementations MAY force... to single host-to-host IPsec SAs. If we >> cannot come up with a good way for an unauthenticated peer to >> prove ownership of SA ranges (whatever "ownership" might mean in this >> context), then I guess we should change the MAY into a SHOULD. > > I even wanted a MUST, for the exact same reason. Any claim of IP address > ownership other than the apparent source ip is dangerous. If the party > does not authenticate, we cannot trust any claim. And two clients could > attempt to claim the same ranges to get each other traffic. Well, host-to-host is too restrictive in any case. If anonymous client wants to get access to a DMZ network, then what the reason not to allow him/her to do it? The restriction should be applied only to unauthenticated peer, while the authenticated server could very well represent the subnet behind it. And in case of unauthenticated client the server could (should?) assign him/her an internal IP address, so the client won't represent arbitrary IP address, only the address the server gives him. >> * We are still using IP addresses to identify peers: "if an IKE peer >> receives... from an IP address that matches a configured >> connection". I think an IKE peer that supports null auth should be >> able to distinguish peers depending on other characteristics, and >> should be able to handle mixed configurations/policies even for a >> single IP address. > > You might be able to distinguish, but there is (per definition with > auth_null) > no proof, so any decisions based on apparent distinction would be very > insecure. I'm not sure how you would support mixing auth and auth_null. > If I setup a PSK between 1.2.3.4 and 5.6.7.8, and my 1.2.3.4 server > suddenly gets AUTH_NULL, it has to reject it based on the wrong type of > AUTH TYPE payload. If it would not reject it, would it mean this > un-authenticated client mayb setup an IPsec SA that was supposed to > be protected and limited to a machine that knows the PSK? I think that the presence or absence of authentication may influence on the scope of services the client can reach. For example, un-authenticated client may be restricted to only one DMZ network, but if it re-enters and authenticates itself (even from the same IP address), then it may get access to a full protected network. I think Yaron is right here and we should not impose such restrictions. >> * I suggest adding this short subsection to the Security >> Considerations: >> >> Although this document discourages the use of non-null ID payloads to >> identify an unauthenticated peer, IKEv2 provides channel bindings >> capabilities and those may be used to authenticate this identity at a >> later time, while binding the authenticated identity with the >> original IKE exchange. This applies to a related but distinct use case, >> where peers cannot be authenticated at the time of the exchange >> but do not wish to remain anonymous. Please see [AutoVPN] for one way of >> after-the-fact authentication of an IKE peer. > > If there is to be "authentication later", say through an Informational > Exchange, then the time to present your ID (and your ID TYPE) is during > that later authentication step. There is no good reason to throw in an > untrustable identifier. It will only lead to implementation errors and > security issues. > > I find channel binding extremely dangerous. It adds a lot of complexity > for something that can simple be done with seperate or new IKE SAs. That > is, an IKE peer could start with AUTH_NONE and later if it would need > access to some non-public IP range, decide to start another IKE SA > that is authenticated to the same peer. Mixing that all into a single > IKE SA for complicated handovers seems unneccesary and prone to errors. > > Additionally, I have no idea how this channel binding is supposed to > affect applications. If the remote peer gives me an AUTH_NULL based IPsec > SA to 1.2.3.4, and later bumps that up to PSK authenticated, what does > that mean for an application? What does it mean for the existing TCP > connection to 1.2.3.4 going through ESP? > > You might have valid use cases with auto-vpn, but then, like for > opportunustic IPsec, those use cases and their security considerations > probably belong in their respective documents. I think this document > should only put out a warning, especially to implementors, to think > about what it means to have unauthenticated IKE and IPsec SAs. I agree with Paul here, but I also think that this document must not prohibit such use cases, if they exist. How about the following (I took Yaron's text as the base)? Although this document discourages the use of non-null ID payloads to identify an unauthenticated peer, IKEv2 provides channel bindings capabilities and those may be used to authenticate this identity at a later time, while binding the authenticated identity with the original IKE exchange. The security of such scheems must be well analysed, as they are easy to be compromised. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 19 06:37: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 4016B1B2A94 for ; Mon, 19 Jan 2015 06:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, 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 bm1pBxA0e2qs for ; Mon, 19 Jan 2015 06:37:41 -0800 (PST) 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 BB9EC1B2A93 for ; Mon, 19 Jan 2015 06:37:40 -0800 (PST) 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 t0JEbZZk028432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jan 2015 16:37:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0JEbZaJ005955; Mon, 19 Jan 2015 16:37:35 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21693.5807.717164.946333@fireball.kivinen.iki.fi> Date: Mon, 19 Jan 2015 16:37:35 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <54BB6795.4050302@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 31 min Archived-At: Cc: ipsec Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 14:37:43 -0000 Paul Wouters writes: > That was partially because Valery and I didn't fully agree. Which means > it might not belong in this document. Initial Contact is addressed in > the document already in its own section. The question for example is > about CREATE_CHILD_SA. Which comes back to your point below about > making claims of owning an IP range that cannot be verified without > an identity. I'm thinking with my OE hat on, so I am perfectly fine > with restricting things to a single ip-ip connection (with natt support) > and so in such a case the initial exchange is all that is needed and > CREATE_CHILD_SA is never a valid exchange. Rekeys are not valid? I would expect null authentication method to be used in cases where they might still want to do rekey, both for Child SAs and the IKE SA. Also even in IP-IP connections there might be per protocol+port connections, i.e. it could be possible to do per tcp-flow Child SAs, and that is still possible even if you restrict it to single IP-IP connection. > > * Implementations MAY force... to single host-to-host IPsec SAs. > > If we cannot come up with a good way for an unauthenticated > > peer to prove ownership of SA ranges (whatever "ownership" > > might mean in this context), then I guess we should change the > > MAY into a SHOULD. > > I even wanted a MUST, for the exact same reason. Any claim of IP address > ownership other than the apparent source ip is dangerous. Not true. For example if the RFC5739 is used and the client receives full /64 IPv6 network from the server, that makes it clear what addresses the client owns. Or actually any addresses the server gives to client. > If the party > does not authenticate, we cannot trust any claim. And two clients could > attempt to claim the same ranges to get each other traffic. They can do that even if they authenticate, and you should still provide protection against such attacks even then. -- kivinen@iki.fi From nobody Mon Jan 19 06:58:22 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 93E631B2A9A for ; Mon, 19 Jan 2015 06:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.708 X-Spam-Level: * X-Spam-Status: No, score=1.708 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, J_CHICKENPOX_84=0.6, 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 yRkg8ZnGzD-r for ; Mon, 19 Jan 2015 06:58:19 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526661B2A94 for ; Mon, 19 Jan 2015 06:58:19 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so3195285lbv.13 for ; Mon, 19 Jan 2015 06:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=2bANrFOBbgWGhNO0jYYxzfx3cVcMCEiJSxcM1hKO6+8=; b=RlO3Kai94VPA8QAawDvIATeRfIbrfny7d6Bx+ajpAFAdSSWaUWoUTjSgyZR+kik9aL YNglSSiE0xGF/Ue2FXMpdWfR03nEovl63onTQex177y5WxdZ2gLacCgOkNcx0h1a64ME L2oY+Nub43A/8F+I0evzdtAAYfo2XUr/bFIQLKohQUrQIq00tULfUQxSli9d5N8z3bNq 8DZj5chv/D2G25hK6vzsSxjQC/VMdWXC61mibhvmKi32iHpVjB0zZA6Q/BxENHDjrAm1 y2zh9iB0M7XqOL1356+ECJ+smFzeSNTwV+g9UHe2DFbZc7YHGVWkNKPtoZAweADLgAgN 0MXQ== X-Received: by 10.112.125.202 with SMTP id ms10mr31811636lbb.33.1421679497797; Mon, 19 Jan 2015 06:58:17 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id o7sm3723751lao.3.2015.01.19.06.58.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 19 Jan 2015 06:58:17 -0800 (PST) Message-ID: <3F633BD75DE042B9B4956EF2DA666D3E@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "Paul Wouters" References: <54BB6795.4050302@gmail.com> <21693.5807.717164.946333@fireball.kivinen.iki.fi> Date: Mon, 19 Jan 2015 17:58:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 14:58:20 -0000 >> That was partially because Valery and I didn't fully agree. Which means >> it might not belong in this document. Initial Contact is addressed in >> the document already in its own section. The question for example is >> about CREATE_CHILD_SA. Which comes back to your point below about >> making claims of owning an IP range that cannot be verified without >> an identity. I'm thinking with my OE hat on, so I am perfectly fine >> with restricting things to a single ip-ip connection (with natt support) >> and so in such a case the initial exchange is all that is needed and >> CREATE_CHILD_SA is never a valid exchange. > > Rekeys are not valid? I would expect null authentication method to be > used in cases where they might still want to do rekey, both for Child > SAs and the IKE SA. Paul's idea was to limit unauthenticated peer to have a single IPsec SA. I don't think he has rekey in mind, when suggested to prohibit CREATE_CHILD_SA. However, since we disageed on that, this prohibition was not inserted into the document. > Also even in IP-IP connections there might be per protocol+port > connections, i.e. it could be possible to do per tcp-flow Child SAs, > and that is still possible even if you restrict it to single IP-IP > connection. I agree. This must be a policy issue, not a protocol issue - whether per-flow SAs are allowed and how many SAs server is willing to maintain. And the protocol has already all the means to control it - NO_ADDITIONAL_SAS, SINGLE_PAIR_REQUIRED, TS_UNACCETPABLE, ADDITIONAL_TS_POSSIBLE notifications. Regards, Valery. From nobody Mon Jan 19 07:51: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 03E6E1AD10A for ; Mon, 19 Jan 2015 07:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 O4M2Kow6HOuZ for ; Mon, 19 Jan 2015 07:51:02 -0800 (PST) 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 C38421B29AD for ; Mon, 19 Jan 2015 07:51:01 -0800 (PST) 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 t0JFouks021400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 19 Jan 2015 17:50:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0JFot03002959; Mon, 19 Jan 2015 17:50:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21693.10207.704401.394139@fireball.kivinen.iki.fi> Date: Mon, 19 Jan 2015 17:50:55 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 64 min X-Total-Time: 66 min Archived-At: Subject: [IPsec] My comments to the Null Authentication Method draft 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, 19 Jan 2015 15:51:05 -0000 In section 2.2. it still says that ID presented MUST be ignored. I think this needs to be changed to SHOULD. There are valid cases where we would like to use the ID, for example we might want to assign the same ID same IP-address every time, just to make things easier. This does not mean we trust the ID in any way, it would be used just in same way as DHCP client id is used, it is just conveniency feature, not security feature. Another use case for it is to audit it in the logs, or show it to adminstrators. I.e. in some environments the users do not have reason to lie for their ID, but they still might not want to do authentication. Yes attacker can fake the ID, and there is nothing we can do for it, but when the user contacts the admin and wants to complain something, it much easier if he can say that I use ID foo@example.com, and then admin can check out the logs or mangement information for that ID. Also how are you going to validate that the server actually follows that MUST? How do you verify form outside that the implementation actually ignores the ID field? I would recommend changing that text to either say that SHOULD, or to change it to say where it it is ignored, i.e "MUST be ignored for trust and policy checking", or something similar. On the other hand same section says that ID_NULL SHOULD only be used with NULL authentication method. In which scenarios do you think ID_NULL can be used when using normal authentication? I.e. which is the exception for the SHOULD? One such case might be when using Raw public key authentication, i.e. in which case the ID is not really in the ID payload, but the public key is the identity instead. If this is the reason why you say SHOULD, then we should mention it here. The section 2.3, I do not think there is ever reason to do liveness check for all other IKE SAs using null authentication. There is already normal inactivity based liveness checks, so that will take care of the SAs already, there is nothing we need to do when we receive INITIAL_CONTACT for some other IP address. What we can do that if we do receive INITIAL_CONTACT from same IP-address we already have IKE SA, we could do liveness check for that SA, as that is the most common case. I.e. device creates anonymous IKE SA with server, then device is restarted, and it creates new IKE SA and now it will send INITIAL_CONTACT as it does not have any SAs with server. Most likely those connections have same IP-address, thus to clean up state, it is enough to just do liveness check for old IKE SA from the same IP-address. We cannot just remove it as the IP-address might be the address of the NAT box. Also if the device sent some other ID than ID_NULL, we could again do liveness check for those IKE SAs which have same ID than the new connection coming in, but of course you would want to rate limit those just in case someone makes implementation where everybody uses "user@example.com" or similar as their ID, so everybody has exactly same ID (doing that would be stupid, but that has never stopped people to do things). Btw, this INITIAL_CONTACT cleanup might be one reason why people might have good reasons to use unique valid IDs (perhaps random KEY_ID created when software is installed, or once per week or something like that). In security considerations section there is text: Un-authenticated IKE sessions MUST only attempted when authenticated IKE sessions are not possible for the remote host and the only alternative would be to send plaintext. I assume that s/MUST only attempted/MUST only be attempted/ but also I do not think we cannot use un-authenticated IKE session even when there was 3rot13 method to "encrypt" the packet. In your text we cannot replace 3rot13 method with Un-authenticated IKE sessions as it is not plaintext (you can also replace 3rot13 with other weak cipher for example 40-bit RC4, or single DES). Also limiting un-authenticated IKE sessions this way really restricts the use cases for this. I would rather says that "If authenticated IKE sessions are possible between the hosts, then un-authenticated IKE MUST NOT be used". But even that will restrict some use cases. For example some forum site might want to restrict posting of new comments to authenticated users, but would still want to allow reading of entries without doing authentication. In such cases the client can be configured to be able to do both. In normal case the user will always do un-authenticated connection to read entries, and when he decides to post a reply or new comment, the software would automatically create new authenticated IKE SA and do the actual post through that, even when still at the same time keep the un-authenticated connection for reading... Btw, in such cases the connections might use per TCP-flow Child SAs... You repeat the ID processing rules in the security section, but the MUST is different, as here you do have the logging exception (which you did not have in section 2.2). But there might also be other uses in addition to the logging for the ID, for example the INITIAL_CONTACT notification matching, i.e. which peers to check for liveness when INITIAL_CONTACT is received. You also claim that using ID type other than ID_NULL will compromise the clients anonymity. I do not agree on this statement. Using pseudonyms, or completely random ID for each connection will not compromise anonymity, but will allow certain use cases. In some cases there might be reasons to allow matching old and new sessions to same client (for example INITIAL_CONTACT) but even that does not compromise the anonymity. Even if you know that same ID is used, and it might be same user than last time, that does not mean that you know who the user is. Section 3.1 asks for implemntations to "audit implementations for any assumptions". I think better wording is needed, I do not want to provide our customers a audit records for this kind of things (and I know some of our customers would be reading this text in such way that we must provide those audit records). Perhaps the text should say that implemenations should verify that their assumptions are still valid or something like that. Or just warn implementors that their assumptions might not be valid anymore... In section 3.3 you only say that un-authenticated IKE peers MUST NOT be able to replace the IPsec SAs of an authenticated IKE peer, but not that authenticated IKE peer cannot steal un-authenticated, i.e. replace them IPsec SAs. Is this intentional? I.e why would there ever be use case where any two different users should be allowed to steal other users IPsec SAs (i.e. replace / overwrite them)? I would assume that if user1 has Child SA, then user2 should not be able to create Child SA that steals user1's traffic. I think this should be true even if user1 is authenticated and user2 is not, or vice versa. It should also be true even if both user1 and user2 are un-authenticated (i.e. all un-authenticated users are by definition different users). There are use cases where user1 wants to replace Child SAs created by same user1, i.e. when you reconnect after crash, or you have multiple devices using same resource (i.e. moving video stream from your mobile phone to your laptop by just connecting from your laptop and creating new Child SA with same traffic selectors and disconnecting your mobile phone, so all traffic will now go to the laptop (which have requested same internal address associated with the user from the server). So I would think the section 3.3 should be formatted better. Section 3.4 should most likely also mention RFC5739 as it allows assigning full /64 address block to client, and with that you might use wider traffic selectors. I think we need separate section for the traffic selectors. Now some of that is in the section 3.3 (not replacing IPsec SA), and some are in 3.4. The title of "Network topology changes" does not really describe the problem with traffic selectors. Moving all text related to it to separate subsection might make things easier. Also what error is used when client tries to use traffic selectors which are already in use, or which are not allowed for it (i.e. trying to steal 8.8.8.8)? For stealing attempts the TS_UNACCEPTABLE would be correct, as servers policy should not allow such traffic selectors. Or SINGLE_PAIR_REQUIRED is also possible if there is no trigger packet information. If you try to reuse traffic selectors in use, I think the TS_UNACCEPTABLE is ok for that too, as this could also be considered similar policy error as described in the rfc7296: o If the responder's policy does not allow it to accept any part of the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE Notify message. Note, that we do want to put policy blocks for all addresses given to the client, not only those which are in use now. I.e. if IP A and B are given to client, both of them should be blocked from everybody else even if only one of them is in use. Same thing with prefix given by RFC5739. In general I think we still need more work on this draft, especially in the security considerations section, and actually moving some text away from there to the actual body would be good. I.e. adding new section between 2.2 and 2.3 about the traffic selectors, and moving discussion about the traffic selectors and what kind of policy checks to do for those, and what kind of use cases there might be is needed, and the security considerations section should have more about the attacks, and their counter measures. I.e. the first section would say that server could be configured to only allow IP-IP transport mode connection, or always give client a address using configuration mode, and limit client end to it (or to /64 given by RFC5739), and also perhaps talk about per flow SAs etc. The second part should talk about the address stealing and policy checks on traffic selectors. -- kivinen@iki.fi From nobody Mon Jan 19 08:09:48 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 3BF061B2AD2 for ; Mon, 19 Jan 2015 08:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_84=0.6, 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 oM0aiarE0ym6 for ; Mon, 19 Jan 2015 08:09:43 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE6F1B2ACD for ; Mon, 19 Jan 2015 08:07:58 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kQyZh0wD1zC73; Mon, 19 Jan 2015 17:07:56 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=LaYA4c5t; dkim-adsp=pass 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 4xrnREMo44qb; Mon, 19 Jan 2015 17:07:52 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Jan 2015 17:07:51 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BA06880040; Mon, 19 Jan 2015 11:07:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421683669; bh=NCK3ME4aHeBfaylvS44FCm4cTvGMCcR39BN+lcK/Ho0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LaYA4c5tRFwoziEOo0/DWmeubQV5jyjWBE+77U0X7jGnDz9iT4TdSH2WfnZKI3/k2 e384lvwf40hkL0Pev3jda7bgVhQLRcCf4NgMJSqauKYVhgKUQBYZlehHBDmZnenu4O qqJ9KXS6178aeEsDQ7TniVpeQoGkyY3kZ21Jn9g0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0JG7m7n026834; Mon, 19 Jan 2015 11:07:49 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 19 Jan 2015 11:07:48 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21693.5807.717164.946333@fireball.kivinen.iki.fi> Message-ID: References: <54BB6795.4050302@gmail.com> <21693.5807.717164.946333@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 16:09:44 -0000 On Mon, 19 Jan 2015, Tero Kivinen wrote: >> and so in such a case the initial exchange is all that is needed and >> CREATE_CHILD_SA is never a valid exchange. > > Rekeys are not valid? I would expect null authentication method to be > used in cases where they might still want to do rekey, both for Child > SAs and the IKE SA. You are right, I meant any new non-replacement IPsec SA's. I did not mean to limit rekeying. > Also even in IP-IP connections there might be per protocol+port > connections, i.e. it could be possible to do per tcp-flow Child SAs, > and that is still possible even if you restrict it to single IP-IP > connection. What is the purpose of installing a zillion unauthenticated protoport specific IPsec SA's over a single one? The abuse case here for unauthenticated clients is clear, thousands of SA's per IP in the botnet. It's a better DDOS than sending ESP because this takes CPU power to decrypt the IKE message_and_ takes up kernel memory. And I think with PFS on the CREATE_CHILD_SA you might runn the server out of entropy too? >>> * Implementations MAY force... to single host-to-host IPsec SAs. >>> If we cannot come up with a good way for an unauthenticated >>> peer to prove ownership of SA ranges (whatever "ownership" >>> might mean in this context), then I guess we should change the >>> MAY into a SHOULD. >> >> I even wanted a MUST, for the exact same reason. Any claim of IP address >> ownership other than the apparent source ip is dangerous. > > Not true. For example if the RFC5739 is used and the client receives > full /64 IPv6 network from the server, that makes it clear what > addresses the client owns. But who says the server owns that IPv6 range? Unless you have PKIX validated that server (IPSECKEY in random DNS zone is not good enough!) you cannot trust that. > Or actually any addresses the server gives to client. This is dangerous! the server could tell the client to give ALL of the IPv6 network to it and become your ipv6 default router! A sane client will never let a server dictate the ranges just like a sane server will > They can do that even if they authenticate, and you should still > provide protection against such attacks even then. I'll come up with some text that limits traffic selectors and CREATE_CHILD_SA to those authentication methods that convey trust by configuration (eg PKIX) and not by authentication (NULL or random IPSECKEY records in DNS) Paul From nobody Mon Jan 19 08:59:35 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 82B901B2B60 for ; Mon, 19 Jan 2015 08:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, 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 1LXA65Nxb60K for ; Mon, 19 Jan 2015 08:59:31 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B8B1B2B5D for ; Mon, 19 Jan 2015 08:59:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kQzk801nyzC7g; Mon, 19 Jan 2015 17:59:27 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=h1/LCPPp; dkim-adsp=pass 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 ZgfIHchHhlSh; Mon, 19 Jan 2015 17:59:25 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Jan 2015 17:59:25 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DC81A8008E; Mon, 19 Jan 2015 11:59:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421686764; bh=mIB0Yt7CRyWt8zvJHAtGhpP1AzrOj0w/Ggp6HuWloT0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=h1/LCPPp/DZGvT/qvAui3iZqg24UJibb824riGohHts0z5uv/87NN8O1MAwoJV8aD TAyY/QzV4CeBTIJH+qauilhPOJwskrEMlPmQxKqKEb3dZ3Hn579reOkJjtrwJMlG8j 0cDBVlu7pL7qVCiI2/gWRepSVceGnCSf+P2DeVTs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0JGxOxc001835; Mon, 19 Jan 2015 11:59:24 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 19 Jan 2015 11:59:24 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21693.10207.704401.394139@fireball.kivinen.iki.fi> Message-ID: References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My comments to the Null Authentication Method draft 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, 19 Jan 2015 16:59:33 -0000 On Mon, 19 Jan 2015, Tero Kivinen wrote: > In section 2.2. it still says that ID presented MUST be ignored. > > I think this needs to be changed to SHOULD. > > There are valid cases where we would like to use the ID, for example > we might want to assign the same ID same IP-address every time, just > to make things easier. Of course that's just a band-aid for the ill advised idea of handing out IP addresses to strangers :) > This does not mean we trust the ID in any way, > it would be used just in same way as DHCP client id is used, it is > just conveniency feature, not security feature. > > Another use case for it is to audit it in the logs, or show it to > adminstrators. If we say SHOULD, that would conflict with your use cases. I don't want to give advise in a document only to have common practise ignore that advise. If your use cases are valid then we should address it differently. It seems to be that what you want is something that is neither ID_NONE nor any of the currently defined ID types. Perhaps a new ID Type should be introduced for your use cases? ID_SESSION ? > I.e. in some environments the users do not have reason to lie for > their ID, but they still might not want to do authentication. Yes > attacker can fake the ID, and there is nothing we can do for it, but > when the user contacts the admin and wants to complain something, it > much easier if he can say that I use ID foo@example.com, and then > admin can check out the logs or mangement information for that ID. Honestly, in those use cases asking them for whatsmyipaddress.com is going to accomplish the same (or "show IP" if on a LAN) > Also how are you going to validate that the server actually follows > that MUST? How do you verify form outside that the implementation > actually ignores the ID field? Is there a rule that says you cannot say MUST if you cannot confirm compliance? > I would recommend changing that text to either say that SHOULD, or to > change it to say where it it is ignored, i.e "MUST be ignored for > trust and policy checking", or something similar. Works for me. If I can also add a "SHOULD NOT be sent when anonimity is a concern". > On the other hand same section says that ID_NULL SHOULD only be used > with NULL authentication method. In which scenarios do you think > ID_NULL can be used when using normal authentication? I.e. which is > the exception for the SHOULD? I'm thinking this was mostly an editing mistake. We did want to give you your logging Id option. I think perhaps we changed the wrong MUST to SHOULD. > One such case might be when using Raw public key authentication, i.e. > in which case the ID is not really in the ID payload, but the public > key is the identity instead. If this is the reason why you say SHOULD, > then we should mention it here. I had not thought about that, but it is a good point. Will do. > The section 2.3, I do not think there is ever reason to do liveness > check for all other IKE SAs using null authentication. There is > already normal inactivity based liveness checks, so that will take > care of the SAs already, there is nothing we need to do when we > receive INITIAL_CONTACT for some other IP address. What we can do that > if we do receive INITIAL_CONTACT from same IP-address we already have > IKE SA, we could do liveness check for that SA, as that is the most > common case. I fully agree, except replacing INITIAL_CONTACT with "new unauthenticated IKE SA". INITIAL_CONTACT is meanngless in the context of unauthenticated SAs. If you would take that into account, an attacker could launch a zilltion IKE SAs with you omiting INITIAL_CONTACT to fill up your memory without itself needing to keep its IKE SAs in memory. Much better to ignore INITIAL_CONTACT and send liveness probes for the same IP address, so that if this is an attacker, they also have to keep up all the IKE SAs. (and still an easy defense is not more than XXX IKE SA's per IP address, sure some CGN might suffer, but they're CGN :P) > I.e. device creates anonymous IKE SA with server, then device is > restarted, and it creates new IKE SA and now it will send > INITIAL_CONTACT as it does not have any SAs with server. Most likely > those connections have same IP-address, thus to clean up state, it is > enough to just do liveness check for old IKE SA from the same > IP-address. We cannot just remove it as the IP-address might be the > address of the NAT box. I'd say just always do that check, and ignore INITIAL_CONTACT. > Also if the device sent some other ID than ID_NULL, we could Please don't make any decisions based on IDs of unauthenticated IKE SA's. You keep saying "only for logging" and keep trying to be smart and use it for other things.. Keep it simple, "nothing but logging of the ID". That's my compromise :) > Btw, this INITIAL_CONTACT cleanup might be one reason why people might > have good reasons to use unique valid IDs (perhaps random KEY_ID > created when software is installed, or once per week or something like > that). unfortunately, the nice user that causes a few lingering SA's is not a problem at all. It's a few bytes in the kernel and IKE daemon. It's the malicious clients that matter, and they can tweak using or not using INITIAL_CONTACT and unverifiable IDs. So in my opinion, this adds complexity and optimises only for the case that does not need optimising and fails to be useful for the actual malicious case. > In security considerations section there is text: > > Un-authenticated IKE > sessions MUST only attempted when authenticated IKE sessions are not > possible for the remote host and the only alternative would be to > send plaintext. > > I assume that s/MUST only attempted/MUST only be attempted/ yes. > but also I do not think we cannot use un-authenticated IKE session > even when there was 3rot13 method to "encrypt" the packet. In your > text we cannot replace 3rot13 method with Un-authenticated IKE > sessions as it is not plaintext (you can also replace 3rot13 with > other weak cipher for example 40-bit RC4, or single DES). Yes, if you have a corporate VPN tunnel defined that uses authentication and dictates 3rot13 encryption, I believe it should pick your corporate VPN and not do unauthenticated IKE with unbreakable threefish. Because your undecryptable threefish can still be trivially MITM'ed. We should not start evaluating whether we think MITM'able threefish is more secure than authenticated 3rot13 or not. The decision was made when you configured that authenticated VPN. > Also limiting un-authenticated IKE sessions this way really restricts > the use cases for this. I would rather says that "If authenticated IKE > sessions are possible between the hosts, then un-authenticated IKE > MUST NOT be used". But even that will restrict some use cases. I'm fine with that text. If it restricts a use case, then that's great. The use case would be inheritently unsafe and provide a false sense of security. > For example some forum site might want to restrict posting of new > comments to authenticated users, but would still want to allow reading > of entries without doing authentication. That's really an application level issue. We are just talking about encrypting the transport where the alternative is plaintext. Your forum should have HTTP basic auth to identify users, the user identification does not belong at the IKE layer. > be configured to be able to do both. In normal case the user will > always do un-authenticated connection to read entries, and when he > decides to post a reply or new comment, the software would > automatically create new authenticated IKE SA and do the actual post > through that, even when still at the same time keep the > un-authenticated connection for reading... Btw, in such cases the > connections might use per TCP-flow Child SAs... Apache is not going to talk to the IKE daemon to do user authentication. That's far more expensive than HTTP Basic Auth, and would require a decade of IKE deployments to make it universally available. Let's talk about real use cases? :) > You repeat the ID processing rules in the security section, but the > MUST is different, as here you do have the logging exception (which > you did not have in section 2.2). But there might also be other uses > in addition to the logging for the ID, for example the INITIAL_CONTACT > notification matching, i.e. which peers to check for liveness when > INITIAL_CONTACT is received. I'll sync those sections. > You also claim that using ID type other than ID_NULL will compromise > the clients anonymity. I do not agree on this statement. Using > pseudonyms, or completely random ID for each connection will not > compromise anonymity, but will allow certain use cases. In some cases > there might be reasons to allow matching old and new sessions to same > client (for example INITIAL_CONTACT) but even that does not compromise > the anonymity. You are right it might not compromise it, but it also might. For instance your phone switching between LTE and Wifi while using the same "random ID". > Even if you know that same ID is used, and it might be > same user than last time, that does not mean that you know who the > user is. If you can track to user, so can active attackers doing MITM. That's the problem. > Section 3.1 asks for implemntations to "audit implementations for any > assumptions". I think better wording is needed, I do not want to > provide our customers a audit records for this kind of things (and I > know some of our customers would be reading this text in such way that > we must provide those audit records). > > Perhaps the text should say that implemenations should verify that > their assumptions are still valid or something like that. Or just warn > implementors that their assumptions might not be valid anymore... Sure :) I was not aware of such creative customers. > In section 3.3 you only say that un-authenticated IKE peers MUST NOT > be able to replace the IPsec SAs of an authenticated IKE peer, but not > that authenticated IKE peer cannot steal un-authenticated, i.e. > replace them IPsec SAs. Is this intentional? No. I will fix that. > There are use cases where user1 wants to replace Child SAs created by > same user1, i.e. when you reconnect after crash, or you have multiple > devices using same resource (i.e. moving video stream from your mobile > phone to your laptop by just connecting from your laptop and creating > new Child SA with same traffic selectors and disconnecting your mobile > phone, so all traffic will now go to the laptop (which have requested > same internal address associated with the user from the server). First of all, if you crashed there is nothing anyone can do. There is no way to tell you apart from another new connection. Unless you abuse the random ID and store it across reboots which is _really_ putting in too much trust, because now I can obtain/hack/reverse engineer your random ID to actually obtain your encrypted IP streams. I really don't want to go there. Second, if you want to move your video stream from your phone to your laptop, explain to me how I cannot abuse that mechanism to streal your phone's videostream to _my_ laptop? The only way I can think of is if your securely transfer your "random ID" from one device to the other, meaning it is easier really easy for you to type in, or you are using an authenticated connection between your laptop and phone, in which case you should just transfer the entire IKE and IPsec state without needing a protocol change here. Also, your "random ID" is beginning to look a lot like a kerberos token :P > Section 3.4 should most likely also mention RFC5739 as it allows > assigning full /64 address block to client, and with that you might > use wider traffic selectors. I think we need separate section for the > traffic selectors. Now some of that is in the section 3.3 (not > replacing IPsec SA), and some are in 3.4. The title of "Network > topology changes" does not really describe the problem with traffic > selectors. Moving all text related to it to separate subsection might > make things easier. Sure, once we reach agreement of what can/should/must not be done with traffic selectors. > Also what error is used when client tries to use traffic selectors > which are already in use, or which are not allowed for it (i.e. trying > to steal 8.8.8.8)? > For stealing attempts the TS_UNACCEPTABLE would be correct, as servers > policy should not allow such traffic selectors. Or > SINGLE_PAIR_REQUIRED is also possible if there is no trigger packet > information. I'm fine with TS_UNACCEPTABLE (38) > If you try to reuse traffic selectors in use, I think the > TS_UNACCEPTABLE is ok for that too, as this could also be considered > similar policy error as described in the rfc7296: > > o If the responder's policy does not allow it to accept any part of > the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE > Notify message. > > Note, that we do want to put policy blocks for all addresses given to > the client, not only those which are in use now. I.e. if IP A and B > are given to client, both of them should be blocked from everybody > else even if only one of them is in use. Same thing with prefix given > by RFC5739. Sure. > In general I think we still need more work on this draft, especially > in the security considerations section, and actually moving some text > away from there to the actual body would be good. I.e. adding new > section between 2.2 and 2.3 about the traffic selectors, and moving > discussion about the traffic selectors and what kind of policy checks > to do for those, and what kind of use cases there might be is needed, > and the security considerations section should have more about the > attacks, and their counter measures. That sounds fair. > I.e. the first section would say that server could be configured to > only allow IP-IP transport mode connection, or always give client a > address using configuration mode, and limit client end to it (or to > /64 given by RFC5739), Sure. > and also perhaps talk about per flow SAs etc. I still have not understood a valid use case for this, let alone one that justifies the potential negative effects allowing multiple IPsec SA's gives. Thanks for your review! We will put out an updated version after collecting other feedback during this WGLC. Paul From nobody Mon Jan 19 12:42: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 409CD1B2C40 for ; Mon, 19 Jan 2015 12:42:09 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 1fCeTec-aC0x for ; Mon, 19 Jan 2015 12:42:07 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43651B2C3E for ; Mon, 19 Jan 2015 12:42:07 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:54511 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YDJ9C-000Ah1-4p for ipsec@ietf.org; Mon, 19 Jan 2015 15:42:06 -0500 Message-ID: <54BD6C1D.1020109@bbn.com> Date: Mon, 19 Jan 2015 15:42:05 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <54BB6795.4050302@gmail.com> In-Reply-To: <54BB6795.4050302@gmail.com> Content-Type: multipart/alternative; boundary="------------080006030602080404090406" Archived-At: Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 20:42:09 -0000 This is a multi-part message in MIME format. --------------080006030602080404090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yaron, > I re-read the new draft and I must say it is much clearer than the > previous version. Still, a few comments: > > * > > > * We are still using IP addresses to identify peers: "if an IKE peer > receives... from an IP address that matches a configured > connection". I think an IKE peer that supports null auth should be > able to distinguish peers depending on other characteristics, and > should be able to handle mixed configurations/policies even for a > single IP address. > because NULL auth alters a fundamental security aspect of IPsec, I think we need to describe in this document how this new capability interacts with the SPD and the PAD. The doc should reference 4301 an describe any changes to that RFC that are needed to security accommodate Null auth. A quick scan of this I-D does not indicate any references to either database or to 4301. Steve --------------080006030602080404090406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yaron,

I re-read the new draft and I must say it is much clearer than the previous version. Still, a few comments:

  • We are still using IP addresses to identify peers: "if an IKE peer receives... from an IP address that matches a configured connection". I think an IKE peer that supports null auth should be able to distinguish peers depending on other characteristics, and should be able to handle mixed configurations/policies even for a single IP address.
because NULL auth alters a fundamental security aspect of IPsec, I think we need to describe
in this document how this new capability interacts with the SPD and the PAD. The doc should
reference 4301 an describe any changes to that RFC that are needed to security accommodate Null auth.

A quick scan of this I-D does not indicate any references to either database or to 4301.

Steve

--------------080006030602080404090406-- From nobody Mon Jan 19 12:55:29 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 9770F1B2C5A for ; Mon, 19 Jan 2015 12:55:26 -0800 (PST) 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 3sVIIKDM38VN for ; Mon, 19 Jan 2015 12:55:25 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF351B2C48 for ; Mon, 19 Jan 2015 12:55:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kR4yL6V03zCHB; Mon, 19 Jan 2015 21:55:22 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=XCnG/jyS; dkim-adsp=pass 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 B4UoXuqQDd8E; Mon, 19 Jan 2015 21:55:22 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Jan 2015 21:55:22 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 594A38004F; Mon, 19 Jan 2015 15:55:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421700921; bh=9U6lb0lAhwVBucebjCPxJ0BOJ+qS+v/uVK7Lrw7MVkY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XCnG/jySSq7GoUnkKvkA38L/ZuM70Zaig4B7Nr9enCweJPHeLAXm0mGn9StdPgxbs KRD+dhGePWsjN21rlAJ6qpeNIP0NkIN2szeAzK/NaEgxjjmQWInlqig5ZsrnhpyM4+ oBsxrnFX8b0AmGqbnznaSCAIdW0gzKQk/qadUA+s= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0JKtKVC022092; Mon, 19 Jan 2015 15:55:21 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 19 Jan 2015 15:55:20 -0500 (EST) From: Paul Wouters To: Stephen Kent In-Reply-To: <54BD6C1D.1020109@bbn.com> Message-ID: References: <54BB6795.4050302@gmail.com> <54BD6C1D.1020109@bbn.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 20:55:26 -0000 On Mon, 19 Jan 2015, Stephen Kent wrote: > because NULL auth alters a fundamental security aspect of IPsec, I think we need to describe > in this document how this new capability interacts with the SPD and the PAD. The doc should > reference 4301 an describe any changes to that RFC that are needed to security accommodate > Null auth. There are no changes to the SPD or the PAD. This document merely defines a new way of authentication at the IKE level. It is not different from other documenst that added an authentication method, such as RFC-7427 which also does not mention the SPD or the PAD. 7427 does have the following text: IKEv2 peers have a series of policy databases (see Section 4.4 of [RFC4301]) that define which security algorithms and methods should be used during establishment of security associations. To help end users select the desired security levels for communications protected by IPsec, implementers may wish to provide a mechanism in the IKE policy databases to limit the mixing of security levels or to restrict combinations of protocols. Would using this text in the security considerations resolve your issue? We could change "mixing of security levels" to "mixing authenticated and un-authenticated security levels". Paul From nobody Mon Jan 19 13:19:02 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 261001B2C94 for ; Mon, 19 Jan 2015 13:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 Bah2H9D-VP5x for ; Mon, 19 Jan 2015 13:18:58 -0800 (PST) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4F31ACE17 for ; Mon, 19 Jan 2015 13:18:58 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=k3CinfsbSsrvdwEmfJ0UCYgXI46IM7ODDYJEUMB7KjB1sKk5R/lf4YAm N2FVBXOEHIeHTh41k2VnTCvwiQmhSG20UjzSCzk8T8WAyWn+lJkrPv8uM RmXBeTt01oWXs2BYtt6GIRyEv77/JXEXtVhbk/jU9zJWGNbEvfqWUzTuI c=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1421702338; x=1453238338; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RrTok7eImoXrORwzYiJ/gURqUkauob6sPjKrHrj56jE=; b=wz+pJ6+j9O1o5UwK9T4KDLZoy8zcsX4lBWLP+rHXHlfNgC/HuBjbLvIF gHA5eiAUB85X96Kj4FK+J3njXMCrA8VOah2UyUZv+TLhwWAiP3mEYZ1MC yVFJthuIqDrZQooav9tRZpCAXoKECbfZvzm3GTFUk6tUlaL+IYdSmm1V+ k=; X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.09,429,1418104800"; d="scan'208";a="611554953" From: To: Thread-Topic: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" Thread-Index: AQHQM6ANSRDkVYORpkCOTv7EplFUCpzIThqAgAADswCAAAaRAA== Date: Mon, 19 Jan 2015 21:18:51 +0000 Message-ID: <5CAF1839-888D-4844-87DD-82A2F5B42755@dell.com> References: <54BB6795.4050302@gmail.com> <54BD6C1D.1020109@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.97] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, kent@bbn.com Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 21:19:00 -0000 DQo+IE9uIEphbiAxOSwgMjAxNSwgYXQgMzo1NSBQTSwgUGF1bCBXb3V0ZXJzIDxwYXVsQG5vaGF0 cy5jYT4gd3JvdGU6DQo+IA0KPiBPbiBNb24sIDE5IEphbiAyMDE1LCBTdGVwaGVuIEtlbnQgd3Jv dGU6DQo+IA0KPj4gYmVjYXVzZSBOVUxMIGF1dGggYWx0ZXJzIGEgZnVuZGFtZW50YWwgc2VjdXJp dHkgYXNwZWN0IG9mIElQc2VjLCBJIHRoaW5rIHdlIG5lZWQgdG8gZGVzY3JpYmUNCj4+IGluIHRo aXMgZG9jdW1lbnQgaG93IHRoaXMgbmV3IGNhcGFiaWxpdHkgaW50ZXJhY3RzIHdpdGggdGhlIFNQ RCBhbmQgdGhlIFBBRC4gVGhlIGRvYyBzaG91bGQNCj4+IHJlZmVyZW5jZSA0MzAxIGFuIGRlc2Ny aWJlIGFueSBjaGFuZ2VzIHRvIHRoYXQgUkZDIHRoYXQgYXJlIG5lZWRlZCB0byBzZWN1cml0eSBh Y2NvbW1vZGF0ZQ0KPj4gTnVsbCBhdXRoLg0KPiANCj4gVGhlcmUgYXJlIG5vIGNoYW5nZXMgdG8g dGhlIFNQRCBvciB0aGUgUEFELiBUaGlzIGRvY3VtZW50IG1lcmVseSBkZWZpbmVzDQo+IGEgbmV3 IHdheSBvZiBhdXRoZW50aWNhdGlvbiBhdCB0aGUgSUtFIGxldmVsLiBJdCBpcyBub3QgZGlmZmVy ZW50IGZyb20NCj4gb3RoZXIgZG9jdW1lbnN0IHRoYXQgYWRkZWQgYW4gYXV0aGVudGljYXRpb24g bWV0aG9kLCBzdWNoIGFzIFJGQy03NDI3DQo+IHdoaWNoIGFsc28gZG9lcyBub3QgbWVudGlvbiB0 aGUgU1BEIG9yIHRoZSBQQUQuIDc0MjcgZG9lcyBoYXZlIHRoZQ0KPiBmb2xsb3dpbmcgdGV4dDoN Cj4gDQo+ICBJS0V2MiBwZWVycyBoYXZlIGEgc2VyaWVzIG9mIHBvbGljeSBkYXRhYmFzZXMgKHNl ZSBTZWN0aW9uIDQuNCBvZg0KPiAgIFtSRkM0MzAxXSkgdGhhdCBkZWZpbmUgd2hpY2ggc2VjdXJp dHkgYWxnb3JpdGhtcyBhbmQgbWV0aG9kcyBzaG91bGQNCj4gICBiZSB1c2VkIGR1cmluZyBlc3Rh Ymxpc2htZW50IG9mIHNlY3VyaXR5IGFzc29jaWF0aW9ucy4gIFRvIGhlbHAgZW5kDQo+ICAgdXNl cnMgc2VsZWN0IHRoZSBkZXNpcmVkIHNlY3VyaXR5IGxldmVscyBmb3IgY29tbXVuaWNhdGlvbnMg cHJvdGVjdGVkDQo+ICAgYnkgSVBzZWMsIGltcGxlbWVudGVycyBtYXkgd2lzaCB0byBwcm92aWRl IGEgbWVjaGFuaXNtIGluIHRoZSBJS0UNCj4gICBwb2xpY3kgZGF0YWJhc2VzIHRvIGxpbWl0IHRo ZSBtaXhpbmcgb2Ygc2VjdXJpdHkgbGV2ZWxzIG9yIHRvDQo+ICAgcmVzdHJpY3QgY29tYmluYXRp b25zIG9mIHByb3RvY29scy4NCj4gDQo+IFdvdWxkIHVzaW5nIHRoaXMgdGV4dCBpbiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgcmVzb2x2ZSB5b3VyIGlzc3VlPw0KPiBXZSBjb3VsZCBjaGFu Z2UgIm1peGluZyBvZiBzZWN1cml0eSBsZXZlbHMiIHRvICJtaXhpbmcgYXV0aGVudGljYXRlZCBh bmQNCj4gdW4tYXV0aGVudGljYXRlZCBzZWN1cml0eSBsZXZlbHPigJ0uDQoNCkkgdGhpbmsgbnVs bCBhdXRoZW50aWNhdGlvbiBpcyBhIGJpdCBtb3JlIGRyYXN0aWMgdGhhbiBhIG5ldyBhbGdvcml0 aG0gdG8gZG8gd2hhdCBJUFNlYy9JS0UgaGFzIGFsd2F5cyBkb25lOiB0d28gd2F5IGF1dGhlbnRp Y2F0aW9uIG9mIGVzc2VudGlhbGx5IGFsbCBjb21tdW5pY2F0aW9uLiAgDQoNCkZvciBleGFtcGxl LCB3aGF0IHdvdWxkIGEgUEFEIGVudHJ5IGxvb2sgbGlrZSB0aGF0IGV4cHJlc3NlcyDigJxOVUxM IGF1dGhlbnRpY2F0aW9uIHBlcm1pdHRlZOKAnT8gIFdoZXJlIHdvdWxkIEkgZmluZCB0aGUgc3Bl YyBmb3IgdGhlIGFsZ29yaXRobSB0aGF0IHJlamVjdHMgdW5hdXRoZW50aWNhdGVkIGNvbW11bmlj YXRpb24gd2hlbiBpdCBpcyBzdXBwb3NlZCB0byBiZSByZWplY3RlZCwgYW5kIGFjY2VwdHMgaXQg d2hlbiBpdCBpdCBpcyB3YW50ZWQ/ICBJIHdvdWxkIGV4cGVjdCB0aGlzIHRvIGJlIGluIFJGQyA0 MzAxIHNlY3Rpb24gNC40LjMuMSwgc28gaXQgd291bGQgc2VlbSB0aGF0IHRoZSBuZXcgZHJhZnQg aGFzIHRvIGFtZW5kIHRoYXQgc2VjdGlvbiB0byBjb3ZlciB0aGVzZSBuZXcgcnVsZXMuDQoNCglw YXVsDQo= From nobody Mon Jan 19 14:50:51 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 4F0021B2CFE for ; Mon, 19 Jan 2015 14:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 U1OQqgz-RKlf for ; Mon, 19 Jan 2015 14:50:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4341ACE21 for ; Mon, 19 Jan 2015 14:50:47 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:35100 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YDL9f-000D4w-Rh; Mon, 19 Jan 2015 17:50:43 -0500 Message-ID: <54BD8A43.3010000@bbn.com> Date: Mon, 19 Jan 2015 17:50:43 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Wouters References: <54BB6795.4050302@gmail.com> <54BD6C1D.1020109@bbn.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 19 Jan 2015 22:50:50 -0000 Paul, Other authentication methods defined for IKE perform authentication, so there was no need to express anything special in the SPD or PAD. NULL is obviously very different. The text you cited from 4727, with the edit you proposed would be a big improvement. Steve From nobody Mon Jan 19 20:25: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 4925C1ACF18 for ; Mon, 19 Jan 2015 20:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u1Tz58RD5AL for ; Mon, 19 Jan 2015 20:25:27 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2F71ACF02 for ; Mon, 19 Jan 2015 20:25:27 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so43060887pad.1 for ; Mon, 19 Jan 2015 20:25:27 -0800 (PST) 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=lf42/mEBhacFtzT03xR/Am9UC6fwtasMN6eqe8PyvN0=; b=k4hQkwbEQHCKWZIpIWJ0OKNnnUlKcuF8o5geFKcfrk4PEOMDGniB0wUxjpT2e4AFsp qlugnCMOWNVRG4DWGPKjett2qiURzN7eH2SW7X/94E1jvNNgiEPDXj0BTB8VFVdmtWaZ zsrUc5XKa0Sr3AFl02cU0tmmmuNpqjpRcIaZvqQSFQA1ILrAKjmEph0umZHeTePeDwSm 2AfCTd45kh8IPN3QazjuWAyIsCgiEnpBHgVJ1t50m3FSeQTgeArXPH9hDv9QMhdXamFH Net7Qh+T2w4pXwfDmCm/xwaH6I3E/fYnE1joNHxprWlSCcdbz224V4MTY1OyZ1fdtnRH 6ZJw== X-Received: by 10.70.8.65 with SMTP id p1mr36275641pda.34.1421727926894; Mon, 19 Jan 2015 20:25:26 -0800 (PST) Received: from [192.168.3.166] (50-203-213-210-static.hfc.comcastbusiness.net. [50.203.213.210]) by mx.google.com with ESMTPSA id fa10sm2573981pdb.55.2015.01.19.20.25.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 20:25:25 -0800 (PST) Message-ID: <54BDD8B4.1070203@gmail.com> Date: Mon, 19 Jan 2015 20:25:24 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paul_Koning@Dell.com, paul@nohats.ca References: <54BB6795.4050302@gmail.com> <54BD6C1D.1020109@bbn.com> <5CAF1839-888D-4844-87DD-82A2F5B42755@dell.com> In-Reply-To: <5CAF1839-888D-4844-87DD-82A2F5B42755@dell.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipsec@ietf.org, kent@bbn.com Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 20 Jan 2015 04:25:33 -0000 >> >> IKEv2 peers have a series of policy databases (see Section 4.4 of >> [RFC4301]) that define which security algorithms and methods should >> be used during establishment of security associations. To help end >> users select the desired security levels for communications protected >> by IPsec, implementers may wish to provide a mechanism in the IKE >> policy databases to limit the mixing of security levels or to >> restrict combinations of protocols. >> >> Would using this text in the security considerations resolve your issue? >> We could change "mixing of security levels" to "mixing authenticated and >> un-authenticated security levels”. > > I think null authentication is a bit more drastic than a new algorithm to do what IPSec/IKE has always done: two way authentication of essentially all communication. > > For example, what would a PAD entry look like that expresses “NULL authentication permitted”? Where would I find the spec for the algorithm that rejects unauthenticated communication when it is supposed to be rejected, and accepts it when it it is wanted? I would expect this to be in RFC 4301 section 4.4.3.1, so it would seem that the new draft has to amend that section to cover these new rules. > > paul And then on the SPD side, I'm not sure we even know what this policy would look like. Even if we only allow a single IP, the address presented by the peer, the policy would not in general be secure. Because a "true" MITM, one that gets hold of the access router, would be able to assume any IP, including for example 8.8.8.8. So should we exclude certain services? Certain IP ranges? This could get very messy. Paul W. is right that IKE gateways had always needed to protect against malicious peers, but IMHO the unauthenticated case is qualitatively more risky. Thanks, Yaron From nobody Tue Jan 20 05:53:56 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 A75801B2A26 for ; Tue, 20 Jan 2015 05:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL71r87SzwpF for ; Tue, 20 Jan 2015 05:53:53 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF391B2A24 for ; Tue, 20 Jan 2015 05:53:52 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so34327055lab.13 for ; Tue, 20 Jan 2015 05:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=ufV15OZbRMuRjvf0BLN02/bH0u59ZlZUI89ZRMVttGc=; b=VB9DWn+3O3leYUatnUZIDrc5QsW1WpMfk82P8U+hVrKeqyq/BH6poUWdxNSktvuQjN Cx44LnESok/eVcWNaXF0r4Zw7QFPGyvHOwgV/NBlX7YlJYLiNMFrs7tVKO5wN4GfSvR3 JHwab1NsQoZuueixd0apV315ij03CiVsTknpmCRYMMOZA6Bwx85dt+FmvqwPQB3s3HVz gnTmbtbomHQfD+xUXIIHuUen0U8ZvaROuVyNYLcwmYbOuowJ0pOwajmZI8Enm2UM2RlV nKJFMCAK3jXf3MFmeEYjM9oO1a9FACJ9yncxrdYSlK/ziqbc7NoKxy5Ah/RfEltrOBeo Gbkg== X-Received: by 10.112.132.2 with SMTP id oq2mr38356208lbb.11.1421762030928; Tue, 20 Jan 2015 05:53:50 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id vu9sm4023621lbb.36.2015.01.20.05.53.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 20 Jan 2015 05:53:50 -0800 (PST) Message-ID: <42287653737F4C17925AAF23F337AAD3@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> Date: Tue, 20 Jan 2015 16:53:23 +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] My comments to the Null Authentication Method draft 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, 20 Jan 2015 13:53:54 -0000 Hi Tero, thanks for your detailed review. Please see inline. I commented only the issues where we disagree with Paul. > On the other hand same section says that ID_NULL SHOULD only be used > with NULL authentication method. In which scenarios do you think > ID_NULL can be used when using normal authentication? I.e. which is > the exception for the SHOULD? It could be used, for example, in the first IKE_AUTH message sent from the client when EAP authentication is requested. If SGW is acting as pass-through between client and backend authentication server (e.g. RADIUS), that server will typically start EAP session from requesting EAP Identity anyway, so the ID Payload received from the client becomes useless. > One such case might be when using Raw public key authentication, i.e. > in which case the ID is not really in the ID payload, but the public > key is the identity instead. If this is the reason why you say SHOULD, > then we should mention it here. This is another example when ID_NULL could be used with non-NULL authentication. > The section 2.3, I do not think there is ever reason to do liveness > check for all other IKE SAs using null authentication. There is > already normal inactivity based liveness checks, so that will take > care of the SAs already, there is nothing we need to do when we > receive INITIAL_CONTACT for some other IP address. What we can do that > if we do receive INITIAL_CONTACT from same IP-address we already have > IKE SA, we could do liveness check for that SA, as that is the most > common case. The intent was to hint to implementers, that the event of creating new unauthenticated IKE SA MAY be considered as a trigger for liveness check procedure on inactive unauthenticated SAs. There is no requirement that this check be immediately done on all the SAs. But without such advise naive implementation may ends up having a lot of stale IKE SAs (for example, if it performs liveness check only if it needs to send data over SA). > I.e. device creates anonymous IKE SA with server, then device is > restarted, and it creates new IKE SA and now it will send > INITIAL_CONTACT as it does not have any SAs with server. Most likely > those connections have same IP-address, thus to clean up state, it is Not necessary. Depending on the ISP the client may get new IP address. > enough to just do liveness check for old IKE SA from the same > IP-address. We cannot just remove it as the IP-address might be the > address of the NAT box. It is not enough to check only SAs with same IP-address. However, as I've written above, there is no need to immediately perform liveness check on all SAs. The event of creating new unauthenticated IKE SA is just a hint, that some of other such SAs might become stale and they need to be checked (no rush though). It is implementation dependant how this check is done - implementations may check all the SAs if there are a handfull of them, check first SAs with the same IP address and let the other to be checked on a time-based basis, or ignore this event at all and rely on usual regular checking. I don't think the document should mandate such things. > Also if the device sent some other ID than ID_NULL, we could again do > liveness check for those IKE SAs which have same ID than the new The -01 version of the draft recommended doing so. Do you think it is worth put it back? > connection coming in, but of course you would want to rate limit those > just in case someone makes implementation where everybody uses Sure. > "user@example.com" or similar as their ID, so everybody has exactly > same ID (doing that would be stupid, but that has never stopped people > to do things). ... > Also limiting un-authenticated IKE sessions this way really restricts > the use cases for this. I would rather says that "If authenticated IKE > sessions are possible between the hosts, then un-authenticated IKE > MUST NOT be used". But even that will restrict some use cases. I think this wording is too restrictive. Well, the question is: why do we need NULL auth at all. If it is intended only for opportunistic security, then yes, it must only be used if the peers cannot authenticate themselves. But there are use cases when the user is able to authenticate himself/herself, but he/she doesn't want to do it for the particular SA. For example, if I'm an Wikipedia editor, then I need to be able to authentiacte myself while I perform edits. But I want to keep anonimity while I read Wikipedia to prevent tracing back what I'm interested in. > For example some forum site might want to restrict posting of new > comments to authenticated users, but would still want to allow reading > of entries without doing authentication. In such cases the client can > be configured to be able to do both. In normal case the user will > always do un-authenticated connection to read entries, and when he > decides to post a reply or new comment, the software would > automatically create new authenticated IKE SA and do the actual post > through that, even when still at the same time keep the > un-authenticated connection for reading... Btw, in such cases the > connections might use per TCP-flow Child SAs... Exactly. > -- > kivinen@iki.fi Regards, Valery. From nobody Tue Jan 20 06:34: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 CE9C01B2DAB for ; Tue, 20 Jan 2015 06:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PtDlHoC2aUAa for ; Tue, 20 Jan 2015 06:34:07 -0800 (PST) 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 D0E9C1B2DB0 for ; Tue, 20 Jan 2015 06:34:05 -0800 (PST) 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 t0KEXxKD024163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jan 2015 16:33:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0KEXwZr016695; Tue, 20 Jan 2015 16:33:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21694.26453.977101.952972@fireball.kivinen.iki.fi> Date: Tue, 20 Jan 2015 16:33:57 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <038B7179C6EB4C5BB2A110AD37541204@buildpc> References: <038B7179C6EB4C5BB2A110AD37541204@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 13 min Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd) 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, 20 Jan 2015 14:34:10 -0000 Valery Smyslov writes: > > Valery suggests sending liveness checks to all IKE SA's that used > > AUTH_NONE. > > > > I suggested sending liveness checks only to those IKE SA's that used > > the same IP address, thus limiting the scope to a more likely pool > > of possible orphaned SA's by a remote that crashed/restarted. > > I don't think that restricting liveness checks in this case to the same > IP address covers all the situations. The peer may crash, > reboot and get new IP from its ISP and then create new IKE SA. > In this situation (very common, not?) the proposed restriction > will prevent the server from finding that old stale SA and it will continue > to consume resources untill the server decides to send smth. > over it or to check its liveness based on a long period of its > inactivity or until its lifetime is over. > > I don't think that the document should impose such a restriction, > but instead it should give some guidance of how implementation > should behave in this situation. > > To clarify my position: I don't propose that implementation > should blindly send liveness check messages on > every SA once new one is created. If SA is active > (there was recent incoming traffic over it) or implementation > has just successfully finished liveness check on that > particular SA, then there is no need to do it again. > But if some unauthenticated SAs are idle for a while, then the event of > creating new unauthenticated IKE SA MAY (not SHOULD, not MUST) > trigger the liveness check on those SAs, regardless of their IP addresses. Or the implementation could just do n liveness checks for unauthenticated clients per second. I.e. go through all your unauthentication clients ever now and while, and see whether you need to clear the resources. How fast you want to go through them depends how much resources you have left. If you have plenty of resources, there is no need to wast other resources to clean up some other resources. If you are running out of memory because you have too many unauthenticated IKE SAs then send liveness check to them faster (== consume more CPU resource), to clean up resource you are running out (==memory). This all is implementation details. We could give some hints here, but I do not think we want to make any hard rules... > > Traffic Selectors ... > > And opens up the reverse attack of the server stealing the > > client's 8.8.8.8 traffic. Some more discussion and insights on this > > would be useful. Actually I think I am missing something. How can server steal clients 8.8.8.8 traffic? Even if it assigns client 8.8.8.7 IP address, that does not mean 8.8.8.8 is sent to the server. Server can assign 8.8.8.8 for the client, which means that 8.8.8.8 traffic from the client does not go anywhere (i.e. it is routed to localhost, because client think it is his own IP), but that does not allow stealing traffic. Assigning address using configuration payloads do not affect routing table. Only traffic selectors and perhaps INTERNAL_IP*_SUBNET stuff might affect routing, and client should not ever allow traffic selectors which are wider than what his policy allows. For unauthenticated host-to-host conection client would always put exactly one IP address (servers IP-address) to the TSr when proposing traffic selectors, and server cannot make it wider than that. Also client can easily limit that address assigned to it via configuration payload must be from the private address range, as there is no reason for server to assign client real routable IP-address in unauthenticated user case. But again this is policy decision which implementations need to do. > > Additionally, if we allow some kind of narrowed traffic selector, > > malicious IKE peers would only need their one IP and could setup > > (protocol * sport * dport) IPsec SAs. Or a variant of this could > > be done with when allowing CREATE_CHILD_SA to setup a plethora of > > IPsec SAs. Restrictions based on IP address is hard, again because > > of the NAT support problem. > > I think it is a server's policy issue. It can always restrict > the number of IPsec SAs from a single peer > by using NO_ADDITIONAL_SAS notification. > The document should not impose any restrictions here, IMHO. Agree. Implementations might also have different limits depending whether the other end is authenticated or unauthenticated, i.e. unauthenticated clients might only be able to create for example 10 Child SAs, and authenticated clients can create 1000 Child SAs... And btw child SAs are quite cheap, so the limit does not need to be 1 and 3... :) On the other hand on some environments Child SAs are expensive, for example if you have hardware acceleration which only supports limited amount of SAs. In those environments the server's policy might disallow per flow SA. -- kivinen@iki.fi From nobody Tue Jan 20 06:59: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 163771B2DD7 for ; Tue, 20 Jan 2015 06:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eWlKniNbyQpy for ; Tue, 20 Jan 2015 06:59:43 -0800 (PST) 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 719161B2DC8 for ; Tue, 20 Jan 2015 06:59:42 -0800 (PST) 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 t0KExdWX022991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jan 2015 16:59:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0KExdOh013769; Tue, 20 Jan 2015 16:59:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21694.27995.559367.780986@fireball.kivinen.iki.fi> Date: Tue, 20 Jan 2015 16:59:39 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <54BB6795.4050302@gmail.com> <21693.5807.717164.946333@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 15 min Archived-At: Cc: ipsec Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 20 Jan 2015 14:59:44 -0000 Paul Wouters writes: > What is the purpose of installing a zillion unauthenticated protoport > specific IPsec SA's over a single one? The abuse case here for > unauthenticated clients is clear, thousands of SA's per IP in the > botnet. I do not think anybody wants to install or allow zillion unauthenticated SAs, but I can see people wanting to have per flow Child SAs, which might be several Child SAs, depending how many flows you are going to allow. Note, that TCP session requires MUCH more memory than the Child SA used to protect it. TCP session has receive/transmit windows and those are usually several kilobytes in size etc... Anyways all this is policy decisions which should be left to the policy, not hardcoded in the protocol or in the RFC. > It's a better DDOS than sending ESP because this takes CPU power to > decrypt the IKE message_and_ takes up kernel memory. And I think with > PFS on the CREATE_CHILD_SA you might runn the server out of > entropy too? Whether you want to allow PFS for per flow SAs is again policy decision. Currently people who what protection against prevasive monitoring do want to have PFS, as that means attacks need to break Diffie-Hellman for each flow they want to break, compared to just breaking Diffie-Hellman once, and then being able to break all Child SAs created using it. Also there is no such thing as running out of entropy. Entropy is not consumed when it is used. If you have 256 bits of randomess in the system, if you use it once, the attacker still needs to know all 256 bits of randomess to break the system (we are assuming this is secure crypto system). If you use it 2^256 times, the attacker still needs to know all 256 bits to be able to break any one of them. On the other hand if we gets those 256 bits, he can break all 2^256 flows at the same time, so the cost of breaking one connection goes down, but the initial cost of breaking any of them stays same. So the entropy in the system is not going away even if you use it. Also the total cost to break the system does not go down, but the value you gain if you break the system goes up the more you use the same entropy.. > > Not true. For example if the RFC5739 is used and the client receives > > full /64 IPv6 network from the server, that makes it clear what > > addresses the client owns. > > But who says the server owns that IPv6 range? Unless you have PKIX > validated that server (IPSECKEY in random DNS zone is not good enough!) > you cannot trust that. This is good question. For IPv4 there is no point of giving any other address than private use address, but for IPv6 there actually might be. On the other if client is given prefix to public addresses where it tries to talk to (for example google dns-servers ipv6 address block), the server can only cause DoS for the client, it cannot get the client to send any packets to server, as client will know that all those addresses are his addresses, so he should take care of them (they are assigned to him). > > Or actually any addresses the server gives to client. > > This is dangerous! the server could tell the client to give ALL of the > IPv6 network to it and become your ipv6 default router! A sane client > will never let a server dictate the ranges just like a sane server will How can server do that in configuration payload? Configuration payloads assigning address give the addresses which are given to user. There is INTERNAL_IP*_SUBNET stuff that can be used as hints by the client what subnets might be served by the server, but clients should most likely ignore those anyways. Also the traffic selectors are the ones that really tell what traffic is sent to server, not anything in configuration payloads. Client will know why it created the connection to the server, and should create the traffic selectors accordingly. I.e. if it only wants to talk to the one specific address (opportunistic ipsec), then it should include that address in TSr. It can leave TSi out and use the server assigned IP-address, and when it gets TSi in, it might check that it is properly narrowed to only include that one assigned IP-address, but those checks are already there in the code, they are nothing new to the unauthenticated connections. If client is connecting to the server as there is some network behind it wants to connect, that will require configuration in the client, so that configuration needs to tell which networks there are behind the gateway, and normal policy rules will check that server does not steal more data than what is allowed by policy. -- kivinen@iki.fi From nobody Tue Jan 20 07:19:50 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 ACD851B2DC2 for ; Tue, 20 Jan 2015 07:19:47 -0800 (PST) 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 0aabtuXP4I_1 for ; Tue, 20 Jan 2015 07:19:44 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8891B2DB7 for ; Tue, 20 Jan 2015 07:19:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kRYSV1d3CzCKy; Tue, 20 Jan 2015 16:19:38 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=cy450Xox; dkim-adsp=pass 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 J309ccSL1JZI; Tue, 20 Jan 2015 16:19:37 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Jan 2015 16:19:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 44D178004F; Tue, 20 Jan 2015 10:19:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1421767176; bh=Kg6UeaIPqMbWU1Je0tLl7XETTJn3bWDv/XT84iYeNOA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cy450XoxXTZV9A0rVUxccCk8h+lr70t2aCKC1GSwI9uSrX7NJ5IeFXbckhumExt+Q QDn+snkT61UasoF+v2LXOCRobZYbVTpQGF1UBgN4wjyb9cU06L1IIGGXo4rHAVoMrG imRQFDOPPeCuNcX9Gvx8WiVJCbWZ2kYaXuhC9WvQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0KFJZZX031003; Tue, 20 Jan 2015 10:19:35 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 20 Jan 2015 10:19:35 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21694.26453.977101.952972@fireball.kivinen.iki.fi> Message-ID: References: <038B7179C6EB4C5BB2A110AD37541204@buildpc> <21694.26453.977101.952972@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd) 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, 20 Jan 2015 15:19:48 -0000 On Tue, 20 Jan 2015, Tero Kivinen wrote: >>> Traffic Selectors > ... >>> And opens up the reverse attack of the server stealing the >>> client's 8.8.8.8 traffic. Some more discussion and insights on this >>> would be useful. > > Actually I think I am missing something. How can server steal clients > 8.8.8.8 traffic? Even if it assigns client 8.8.8.7 IP address, that > does not mean 8.8.8.8 is sent to the server. Server can assign 8.8.8.8 > for the client, which means that 8.8.8.8 traffic from the client does > not go anywhere (i.e. it is routed to localhost, because client think > it is his own IP), but that does not allow stealing traffic. You are right. I was thinking of 8.8.8.8 <-> 0.0.0.0/0 but you don't do that. I guess you would just use the equivalent of: ip route add serverip src 8.8.8.8 > Also client can easily limit that address assigned to it via > configuration payload must be from the private address range, as there > is no reason for server to assign client real routable IP-address in > unauthenticated user case. But again this is policy decision which > implementations need to do. Sure. and this discussion is suitable for the opportunistic document, not auth_null. We should only put in a short summary here. >> I think it is a server's policy issue. It can always restrict >> the number of IPsec SAs from a single peer >> by using NO_ADDITIONAL_SAS notification. >> The document should not impose any restrictions here, IMHO. > > Agree. Implementations might also have different limits depending > whether the other end is authenticated or unauthenticated, i.e. > unauthenticated clients might only be able to create for example 10 > Child SAs, and authenticated clients can create 1000 Child SAs... And > btw child SAs are quite cheap, so the limit does not need to be 1 and > 3... :) But what's the point? Just to protect th per-port IPsec SA's with more PFS in CREATE_CHILD_SA ? It will only cause interop failures. The client will not pick a host-to-host but picks say port 80 only. Then it wants port 443 and gets NO_ADDITIONAL_SAS. Then it needs to drop the port 80 SA and restart everything to get the full range single SA. If you are not authenticated, what is the point in splitting up the traffic in different IPsec SA's per protocol or port? The only use case I have heard of that could apply, is the use case of being mandated to NOT encrypt something for auditing purposes. But traffic selectors really suck for "everything but sip and smtp and pop and imap" :P We need less buttons and possibly interop issues, not more. So Instead of trying to allow as much of IKEv2 features as you can dream of, lets stick to those bells and whistles that make sense in the unauthenticated scenario. Paul From nobody Tue Jan 20 07:34:49 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 710D51B2DFE for ; Tue, 20 Jan 2015 07:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 woFYkcZ01FEq for ; Tue, 20 Jan 2015 07:34:47 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66661B29EC for ; Tue, 20 Jan 2015 07:34:45 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=wxkwUAFCCFo+ILJjANDzG33HTiibWQ62tdz2hIdWVdVnWGv5enIE2lKt LrCZ52dWl1MgHkf/zFyOcmJGH/Ctrtu5E56rioyH+fg8dm+FpEePqUfeM cBfXiZfZhKyTJdNpt32BRaflcaVz0Nv1gAfozgkEYCe39FnJtnn5L4Tlk w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1421768087; x=1453304087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DBb/z2/ojE6sZOLVij+CWFHj18A1QZ23sc1z0iVHI3I=; b=HCsfLECnM/x4Gzas6I8ILMvAstF3dKNyvYAeAxQyfe1nbkHSlr6jFM4U Qd79dDRnOXBLM5ilUqGiO5CRjNvFKHiB2ydvqtmBSe1Wa9BJeYIEkqjZG L9+YgQDo+fXucLV+MMz0sbe4DR+B0kH2mFMsFFJlMZCcE7eW3fOKy/r8i 0=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.09,434,1418104800"; d="scan'208";a="744876501" From: To: Thread-Topic: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" Thread-Index: AQHQM6ANSRDkVYORpkCOTv7EplFUCpzHT4IAgACYwYCAABk0AIABf0uAgAAJu4A= Date: Tue, 20 Jan 2015 15:34:31 +0000 Message-ID: References: <54BB6795.4050302@gmail.com> <21693.5807.717164.946333@fireball.kivinen.iki.fi> <21694.27995.559367.780986@fireball.kivinen.iki.fi> In-Reply-To: <21694.27995.559367.780986@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.97] Content-Type: text/plain; charset="utf-8" Content-ID: <4D7E4C4D90024842AC0FB5B96F0E0496@dell.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, paul@nohats.ca Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" 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, 20 Jan 2015 15:34:48 -0000 DQo+IE9uIEphbiAyMCwgMjAxNSwgYXQgOTo1OSBBTSwgVGVybyBLaXZpbmVuIDxraXZpbmVuQGlr aS5maT4gd3JvdGU6DQo+IC4uLg0KPiBBbHNvIHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgcnVu bmluZyBvdXQgb2YgZW50cm9weS4gRW50cm9weSBpcyBub3QNCj4gY29uc3VtZWQgd2hlbiBpdCBp cyB1c2VkLiBJZiB5b3UgaGF2ZSAyNTYgYml0cyBvZiByYW5kb21lc3MgaW4gdGhlDQo+IHN5c3Rl bSwgaWYgeW91IHVzZSBpdCBvbmNlLCB0aGUgYXR0YWNrZXIgc3RpbGwgbmVlZHMgdG8ga25vdyBh bGwgMjU2DQo+IGJpdHMgb2YgcmFuZG9tZXNzIHRvIGJyZWFrIHRoZSBzeXN0ZW0gKHdlIGFyZSBh c3N1bWluZyB0aGlzIGlzIHNlY3VyZQ0KPiBjcnlwdG8gc3lzdGVtKS4gSWYgeW91IHVzZSBpdCAy XjI1NiB0aW1lcywgdGhlIGF0dGFja2VyIHN0aWxsIG5lZWRzIHRvDQo+IGtub3cgYWxsIDI1NiBi aXRzIHRvIGJlIGFibGUgdG8gYnJlYWsgYW55IG9uZSBvZiB0aGVtLiAuLi4NCg0KWWVzLCDigJxl bnRyb3B5IHVzZWQgdXDigJ0gaXMgYW4gdW5mb3J0dW5hdGUgbWlzY29uY2VwdGlvbiBjcmVhdGVk IGJ5IHRoZSBhdXRob3JzIG9mIGVhcmx5IC9kZXYvcmFuZG9tIGltcGxlbWVudGF0aW9ucy4NCg0K SSB3b3VsZCBwdXQgaXQgbm90IHF1aXRlIGFzIHN0cm9uZ2x5IGFzIHlvdSBkaWQuICBJZiB5b3Ug aGF2ZSBhbiBSTkcgdGhhdCB1c2VzIGEgc3Ryb25nIGJpdCBzdHJlYW0gZXh0ZW5kZXIgdG8gZXh0 ZW5kIHRoZSBlbnRyb3B5IHBvb2wgY29udGVudCwgeW91ciBzdGF0ZW1lbnQgaXMgdmFsaWQgc2lu Y2UgdGhlIHN0cm9uZyBleHRlbmRlciBoaWRlcyB0aGUgY29udGVudCBvZiB0aGUgZW50cm9weSBw b29sLiAgQnV0IGlmIHRoZSBSTkcgdXNlcyBhIHdlYWsgZXh0ZW5kZXIsIHRoZW4geW91ciBSTkcg c2VjdXJpdHkgYmFzaWNhbGx5IGNvbWVzIGZyb20gdGhlIGVudHJvcHkgaW4gaXRzIGVudHJvcHkg cG9vbCwgYW5kIGtub3dsZWRnZSBvZiB0aGF0IHBvb2zigJlzIGNvbnRlbnQgaXMgbGVha2VkIGJ5 IHRoZSBSTkcgb3V0cHV0LiAgSSB0aGluayBzb21lIGVhcmx5IC9kZXYvcmFuZG9tIGltcGxlbWVu dGF0aW9ucyB3ZXJlIGluZGVlZCBvZiB0aGF0IHNlY29uZCBmb3JtLCBzbyB0aGUg4oCcZW50cm9w eSB1c2VkIHVw4oCdIG5vdGlvbiB3YXMgcGVyaGFwcyB2YWxpZCBiYWNrIHRoZW4uICBCdXQgaXQg aXNu4oCZdCBhbnkgbG9uZ2VyLg0KDQpUaGUgWWFycm93IHBhcGVyIGJ5IFNjaGVpZXIgZXQgYWwu IG1ha2VzIHRoaXMgYW5hbHlzaXMgcXVpdGUgY2xlYXIgKGFuZCB0aGV5IGNvbWUgdG8gdGhlIHNh bWUgY29uY2x1c2lvbiBhcyB5b3UgZGlkIGFzIGEgcmVzdWx0KS4NCg0KCXBhdWwNCg0K From nobody Tue Jan 20 13:30: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 985F01A0012 for ; Tue, 20 Jan 2015 13:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.727 X-Spam-Level: ** X-Spam-Status: No, score=2.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PROFIT1=3.858, 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 MU66pN-Nt0em for ; Tue, 20 Jan 2015 13:30:38 -0800 (PST) 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 7A2E31A0015 for ; Tue, 20 Jan 2015 13:30:37 -0800 (PST) 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 t0KLUXYI019383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jan 2015 23:30:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0KLUXoc000875; Tue, 20 Jan 2015 23:30:33 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21694.51448.891480.737652@fireball.kivinen.iki.fi> Date: Tue, 20 Jan 2015 23:30:32 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 32 min X-Total-Time: 34 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My comments to the Null Authentication Method draft 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, 20 Jan 2015 21:30:40 -0000 Paul Wouters writes: > On Mon, 19 Jan 2015, Tero Kivinen wrote: > > There are valid cases where we would like to use the ID, for example > > we might want to assign the same ID same IP-address every time, just > > to make things easier. > > Of course that's just a band-aid for the ill advised idea of handing out > IP addresses to strangers :) Assigning IP address to clients makes things easier, especially if the client is behind NAT. If client is behind NAT it will have non-routeable, perhaps overlapping addresses, thus using the real client address is hard, and the server will most likely need to do internal NAT for the address (specific to each Child SA) before it is given to the IP stack of the server. Giving address to the client makes things bit easier, as this is standard, widely used method of doing this, and then server can use this address it allocated from its own address pool without any problems, as it can ensure that there are no overlaps, and those addresses in the address pool are so that they will be routed properly. > > This does not mean we trust the ID in any way, > > it would be used just in same way as DHCP client id is used, it is > > just conveniency feature, not security feature. > > > > Another use case for it is to audit it in the logs, or show it to > > adminstrators. > > If we say SHOULD, that would conflict with your use cases. I don't want > to give advise in a document only to have common practise ignore that > advise. If your use cases are valid then we should address it > differently. Yes, MAY is another possibility, but I think actually SHOULD is good compromize. Not everybody wants to use ID for anything, and if you really do unauthenticated, and anonymous connections only, there is no point of using ID. If you do unauthenticated, but not necessarily anonymous (in a sense that clients can claim to be same person than before, or give their identification information, even when they cannot proof it) then using ID has valid points. I myself claim that there are use cases where clients might have valid use cases for giving some kind of ID, even when they do not authenticate the ID. > It seems to be that what you want is something that is neither ID_NONE > nor any of the currently defined ID types. Perhaps a new ID Type should > be introduced for your use cases? ID_SESSION ? No. I do not want that. I want to use currently defined IDs. For example I might configure my client to use ID of kivinen@iki.fi when I am connecting to the forum, even when I do not authenticate that ID anyway to the server. I myself usually do not try to be anonymous, but I do see value of having encryption, even when it would be unauthenticated. The forum adminstrator might then log that information, and might even contact me using that completely untrusted information, just because it happens to be there. This is similar to many other information I give to those stupid registration pages, some of those are true, quite often they are just "none", "none", etc as I see no reason to give some information to them just because they ask them. I do usually give my real name, and quite often also real email address... I understand that not everybody want to do that, and I agree that there are some uses cases where you do not want to give any identity information, but I do want this document to remove possibility for giving that information... > > I.e. in some environments the users do not have reason to lie for > > their ID, but they still might not want to do authentication. Yes > > attacker can fake the ID, and there is nothing we can do for it, but > > when the user contacts the admin and wants to complain something, it > > much easier if he can say that I use ID foo@example.com, and then > > admin can check out the logs or mangement information for that ID. > > Honestly, in those use cases asking them for whatsmyipaddress.com is > going to accomplish the same (or "show IP" if on a LAN) Not really, as the IP-addresses used changes quite often. Especially on mobile devices roaming around the world... Yes, my home-ip happens to be stable, but my laptop IP isn't, so I have no idea what IP I used last week on my laptop when in IEEE meeting, or in the hotel room. If the issue happens just now, then show IP might work, if it happened last week that does not help. The configured ID will help. > > Also how are you going to validate that the server actually follows > > that MUST? How do you verify form outside that the implementation > > actually ignores the ID field? > > Is there a rule that says you cannot say MUST if you cannot confirm > compliance? No, but when you receive customer request to provide you the line numbers in your source where you ignore that ID, then it gets fun. We did get customer asking us where we implement "MUST NOT send certain packets", i.e. what are the exact code lines where we do that "MUST NOT"... (or something like that). I think we responded that all of the lines in our source code implement that, as none of the lines send those packets :-) Also of course we should be able to provide matrix that we have two independent implementations do implement that MUST... > > I would recommend changing that text to either say that SHOULD, or to > > change it to say where it it is ignored, i.e "MUST be ignored for > > trust and policy checking", or something similar. > > Works for me. If I can also add a "SHOULD NOT be sent when anonimity is > a concern". That works. > > On the other hand same section says that ID_NULL SHOULD only be used > > with NULL authentication method. In which scenarios do you think > > ID_NULL can be used when using normal authentication? I.e. which is > > the exception for the SHOULD? > > I'm thinking this was mostly an editing mistake. We did want to give you > your logging Id option. I think perhaps we changed the wrong MUST to > SHOULD. Ok. > > One such case might be when using Raw public key authentication, i.e. > > in which case the ID is not really in the ID payload, but the public > > key is the identity instead. If this is the reason why you say SHOULD, > > then we should mention it here. > > I had not thought about that, but it is a good point. Will do. Ok. > > I.e. device creates anonymous IKE SA with server, then device is > > restarted, and it creates new IKE SA and now it will send > > INITIAL_CONTACT as it does not have any SAs with server. Most likely > > those connections have same IP-address, thus to clean up state, it is > > enough to just do liveness check for old IKE SA from the same > > IP-address. We cannot just remove it as the IP-address might be the > > address of the NAT box. > > I'd say just always do that check, and ignore INITIAL_CONTACT. Thats fine. Initial contact is not that important in IKEv2 anymore, as we do have other ways of cleaning up state. > > Also if the device sent some other ID than ID_NULL, we could > > Please don't make any decisions based on IDs of unauthenticated IKE SA's. > You keep saying "only for logging" and keep trying to be smart and > use it for other things.. Keep it simple, "nothing but logging of the > ID". That's my compromise :) I was not saying only for logging. I was saying there are uses for it, and one of those uses is for example logging. There are other uses for it, and matching pervious connections is one of them. That is not trust or policy decision, it is just decision whether to do liveness check or not for some specific IKE SA, and that will be something that will help the server to handle its resources... Again we are talking about unauthenticated connections, not necessarily anonymous connections. > > Btw, this INITIAL_CONTACT cleanup might be one reason why people might > > have good reasons to use unique valid IDs (perhaps random KEY_ID > > created when software is installed, or once per week or something like > > that). > > unfortunately, the nice user that causes a few lingering SA's is not a > problem at all. It's a few bytes in the kernel and IKE daemon. It's > the malicious clients that matter, and they can tweak using or not > using INITIAL_CONTACT and unverifiable IDs. So in my opinion, this > adds complexity and optimises only for the case that does not need > optimising and fails to be useful for the actual malicious case. It does not really add complexity as the code is already there. That is what is done for normal authenticated initial contacts. The only thing we want to do there is not to delete it immediately, but instead trigger liveness check instead. Also most of the time you are NOT under attack, so maintaining resources during that time is also nice... Telechat in 2 minutes, need to stop now... I'll be back... -- kivinen@iki.fi From nobody Thu Jan 22 13:57: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 ED6641A87E4 for ; Thu, 22 Jan 2015 13:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 bRJ8ILa94m0r for ; Thu, 22 Jan 2015 13:57:42 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.56.150.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ADE1A87DE for ; Thu, 22 Jan 2015 13:57:42 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 3B2E3BCC55ECE; Thu, 22 Jan 2015 15:57:42 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 2728CBCC55E47 for ; Thu, 22 Jan 2015 15:57:42 -0600 (CST) Received: from [96.231.226.60] (port=51488 helo=192.168.1.2) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YEPkz-0005eB-Kd for ipsec@ietf.org; Thu, 22 Jan 2015 15:57:41 -0600 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> Date: Thu, 22 Jan 2015 16:57:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <02A8585F-9DFA-4BC5-993E-C30615D1B538@ieca.com> References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> To: IPsecME WG X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.226.60 X-Exim-ID: 1YEPkz-0005eB-Kd X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.2) [96.231.226.60]:51488 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 22 Jan 2015 21:57:44 -0000 On Jan 09, 2015, at 12:24, Paul Hoffman wrote: > Greetings again. The chairs apologize for the log delay on this, but = it is time to move on this document. This begins the two-week WG Last = Call on = https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth. The = purpose of the WG Last Call is to get as many people as possible to read = the document carefully, looking for any technical or editorial issues = that should be discussed before the document is sent to the IETF. >=20 > I certainly hope we can get thorough reviews from the people who = supported its adoption as a WG item, but the WG would also benefit from = anyone else doing a review as well. Please send all comments to the list = before Friday, January 23. Thanks! >=20 > --Paul Hoffman Just a nit: s2.1: r/The KEv2 Authentication Method/The IKEv2 Authentication Method/ spt From nobody Fri Jan 23 08:28: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 CA71B1A9121 for ; Fri, 23 Jan 2015 08:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biObSsYwkRaK for ; Fri, 23 Jan 2015 08:28:22 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440C71A8BC2 for ; Fri, 23 Jan 2015 08:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6448; q=dns/txt; s=iport; t=1422030502; x=1423240102; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=claxjj15jj7aOjWYFo3x5D/jC3yxhIFvhDC1ICi8XdQ=; b=ILHU6pfsiWptjPqFOLIdNjggudm8SwHt8ENPfpJucqPs0ah8NYJ/bxrg j8L+BbkCDlxeT1GupPFluhN3nfUgZnBRIUQ8VvuiXixYiU1B9AKCYE9UL Q9wBbHP4pFLlYORPRqqWO/hxUZ3nGQyAUDaFg794W0ngM5y7ubX+2bUC4 U=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAA92wlStJV2U/2dsb2JhbABagmQigSoExCqIFgKBF0MBAQEBAX2EDQEBBHkQAgEIOwsCMCUCBA4FDogeAdIwAQEBAQEBAQEBAQEBAQEBAQEBAQEYjxYBEAE1GweEKQWOZoFSgSmGHpI1IoIygTxvgQQIFyJ+AQEB X-IronPort-AV: E=Sophos;i="5.09,454,1418083200"; d="p7s'?scan'208";a="116982012" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP; 23 Jan 2015 16:28:21 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t0NGSLBs022290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 16:28:21 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 10:28:21 -0600 From: "Graham Bartlett (grbartle)" To: Paul Wouters Thread-Topic: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth Thread-Index: AQHQLDEvWj2UvEEBVE2YSG7LuRawAJy41OiAgAUqD8OAAQo5gIAAERKAgA9FIQA= Date: Fri, 23 Jan 2015 16:28:20 +0000 Message-ID: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <363A367E1CF64C4C98586DC57F1AC987@buildpc> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.146.101] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3504875299_26366303" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 23 Jan 2015 16:28:28 -0000 --B_3504875299_26366303 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Paul Sorry for the late reply. Hopefully the following is more clear? When designing systems which will provide connectivity for non-authenticated users, the system SHOULD be designed with the capacity to support not only the maximum intended number of peers, but also include an additional number of sessions which are created due to malicious or erroneous behaviour. This safety margin will allow a system to still operate safely under load until it is exceeded. On 13/01/2015 23:16, "Paul Wouters" wrote: >> >>What I was alluding to is covered now in section 3.2 (and in Paul's >>email). However I think some final words at the end of 3.2 such as 'For >>this reason systems should be designed to accommodate legitimate and >>non-legitimate non-authenticated peers', would then make this message >>crystal clear. > >Can you propose text? I personally find "legitimate and non-legitimate >non-authenticated peers" very unclear. I don't think a server can ever >tell those two aparts based on IKE. --B_3504875299_26366303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgaqzv DVEzl76HLP/RuY/Hkjn7L2TBQNLtZIGevK9PZz4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTUwMTIzMTYyODE4WjANBgkqhkiG9w0BAQEFAASCAQACkxhg qOtIQMYOGYhpen4kadBjW/902TQDSu3l4x9HdNya+D7DrxBIETMFggUt1QEFbES2ZGukpE6h zks+3SFZQoHjZ/aLI9H4asz+5nrzSiv7sqpcd7qpa3nq9a4P9M+F0bSpxKf2mhu7bc5rMw1k IO9roowhIcYchkvxlwZsyei+AS+sotR0nTCxJiIrTqM8RbuLfvz0MJsnMOVN9kV00qOJeRAh 9wHY+eSVwSymLFWTRin9I3+UiVzO1c8VC5fGsS8LgS8dVge8unZ/oYXM9g2FOEFOdho6+UFz 29EZ58Ahda4niVTXBbHJrKCgTcoCfXLLLaMYoXjJy+hOY+MX --B_3504875299_26366303-- From nobody Fri Jan 23 08:36:36 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 344131A8BC2 for ; Fri, 23 Jan 2015 08:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 ES8fnCXdqvdu for ; Fri, 23 Jan 2015 08:36:32 -0800 (PST) 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 3F36B1A1B06 for ; Fri, 23 Jan 2015 08:36:32 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0NGaV41079862 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jan 2015 09:36:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 23 Jan 2015 08:36:30 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [IPsec] Pause, then continuation of WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth 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, 23 Jan 2015 16:36:33 -0000 Greetings again. The two-week WG Last Call on = https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth ends = today but reviewers have clearly unearthed a reasonable number of issues = with the document, all of which seem fixable. WG: please pause for a moment while the authors incorporate the comments = so far. Valery and PaulW: please put out an -03 within a week (sooner, if = possible, in order to keep up review momentum). WG: When the -03 is out, please continue the WG Last Call on the new = document, looking for both whether the changes meet your expectations as = well as any new issues. --Paul Hoffman From nobody Fri Jan 23 08:41:30 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 E59211A9126 for ; Fri, 23 Jan 2015 08:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPIcFzQ_7r2A for ; Fri, 23 Jan 2015 08:41:25 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467A51A9138 for ; Fri, 23 Jan 2015 08:41:22 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id eu11so9544612pac.13 for ; Fri, 23 Jan 2015 08:41:21 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=39z5B3qF26zcFhTHMljqnKoRvvlbo+NvYjWTyYSseOw=; b=jFt0C4PEuu7nw7y5cddp/qvVpco1Q2dSTIA2q9y71IMbM0Hb7zVCFYluu7iIpVTZCK WeAP9axmoizcLTOd+m8vVrhT5ckVsQ78EU3PGbqjSoxbpEwTV5S/m/2G7HdgKnqJSLzb GP+k0eIaoabcrTBV7la16PPdCcwI9Zw14qya0USR1VaEL5jTESPROZ+BcdKfv2QuooiK N6Fzb4r9tZXQKIxEioUjUlSDMCMUFOYySP7Y7XK8c3kErgcqpaYbOC2qKGA+wlu6R9Le khsiuXYfidr4TvlINkliZYhLNOzHHytJyIshMh5VoGGk3dKw9+UKEY8I1CxzuGQtOaM9 cMaA== X-Received: by 10.70.123.166 with SMTP id mb6mr12574201pdb.95.1422031281460; Fri, 23 Jan 2015 08:41:21 -0800 (PST) Received: from [192.168.3.166] (50-203-213-210-static.hfc.comcastbusiness.net. [50.203.213.210]) by mx.google.com with ESMTPSA id w9sm2419833pbt.10.2015.01.23.08.41.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 08:41:19 -0800 (PST) Message-ID: <54C279AE.3070200@gmail.com> Date: Fri, 23 Jan 2015 08:41:18 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paul Hoffman , IPsecME WG References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Pause, then continuation of WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth 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, 23 Jan 2015 16:41:27 -0000 To be more precise: when -03 is out, Paul and I will issue a second last call, complete with a new target date. Thanks, Yaron On 01/23/2015 08:36 AM, Paul Hoffman wrote: > Greetings again. The two-week WG Last Call on https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth ends today but reviewers have clearly unearthed a reasonable number of issues with the document, all of which seem fixable. > > WG: please pause for a moment while the authors incorporate the comments so far. > > Valery and PaulW: please put out an -03 within a week (sooner, if possible, in order to keep up review momentum). > > WG: When the -03 is out, please continue the WG Last Call on the new document, looking for both whether the changes meet your expectations as well as any new issues. > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Jan 23 08:50:12 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 E192B1A8BC2 for ; Fri, 23 Jan 2015 08:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 3m_P391Cz0KY for ; Fri, 23 Jan 2015 08:50:10 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25041A87AC for ; Fri, 23 Jan 2015 08:50:09 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with comcast id jUpP1p0062JGN3p01Uq8Vv; Fri, 23 Jan 2015 16:50:08 +0000 Received: from akdesign.dyndns.org ([50.169.224.229]) by resomta-ch2-10v.sys.comcast.net with comcast id jUq81p00A4xb7Ai01Uq8UF; Fri, 23 Jan 2015 16:50:08 +0000 Received: from pkoning.akdesign.com (pkoning.akdesign.com [192.168.10.125]) by akdesign.dyndns.org (Postfix) with ESMTP id 7770A3C0485; Fri, 23 Jan 2015 11:50:06 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Koning In-Reply-To: Date: Fri, 23 Jan 2015 11:50:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <363A367E1CF64C4C98586DC57F1AC987@buildpc> To: "Graham Bartlett (grbartle)" X-Mailer: Apple Mail (2.1993) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1422031808; bh=FtnP4l0dTshz+yqdvGteVbWgwMJbOA2XIXj/5hI2EuM=; h=Received:Received:Received:Content-Type:Mime-Version:Subject:From: Date:Message-Id:To; b=WKWG7jH8ckH1TvII0BDxOH73gX4MvSrcSi5BzL/9A2Vq06blVsynvoxlo+ZkrKTk0 Yr9qFtGJ/DEWKbmj8UjOvcMsNbzdk1FyO7i8XndM9t60LfsjFWO40tDwjb+W+Avj9V qo9N34Lgae0l6YwLPysQcxzvaJcKGd4RdLaDNlSq7Mpc5ueOJgYYjmmOqL7Vq5Lc2Y eghn2NGRZJfKAYJHkoR1bBwTiheQTwrFAaungbBa4fSqWxFlT59g43IpQmxpCxjdEH yei07DTk3PDEG5hdwT6bvka2U71L5+dr6HT8IUjo+R14lx6HqrR9B1W9vhboxX3sHh 7o5CF6Z/0hFwQ== Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 23 Jan 2015 16:50:11 -0000 > On Jan 23, 2015, at 11:28 AM, Graham Bartlett (grbartle) = wrote: >=20 > Hi Paul >=20 >=20 > Sorry for the late reply. Hopefully the following is more clear? >=20 > When designing systems which will provide connectivity for > non-authenticated users, the system SHOULD be designed with the = capacity > to support not only the maximum intended number of peers, but also = include > an additional number of sessions which are created due to malicious or > erroneous behaviour. This safety margin will allow a system to still > operate safely under load until it is exceeded. I understand the sentiment, but this seems like a recommendation that = can=E2=80=99t be tested and can=E2=80=99t really be implemented either. = The trouble is that the number of malicious sessions is unbounded (and = may be quite large in a DOS scenario). It might be better simply to point out the limitations of the machinery: = because authentication is not provided in this case, the receiving = system has no way to distinguish legitimate peers from malicious ones. = As a result, a denial of service attack may prevent the intended number = of legitimate peers from communicating. Additional session (SA?) = capacity may help in such cases. My point is that this is definitely going to be a case of throwing some = more resources at the problem in the hopes it=E2=80=99s enough, but no = way to predict whether it=E2=80=99s good enough. Because of that, = =E2=80=9CSHOULD=E2=80=9D seems inappropriate, and a simple statement of = the issue and the limitations of this new protocol is better. paul From nobody Fri Jan 23 09:22: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 7C4AF1A1AF9 for ; Fri, 23 Jan 2015 09:22:03 -0800 (PST) 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 qbrWeWfP5PPW for ; Fri, 23 Jan 2015 09:22:01 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90511A8857 for ; Fri, 23 Jan 2015 09:21:56 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kTS295WHlz5H9; Fri, 23 Jan 2015 18:21:53 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=h3g+wIzL; dkim-adsp=pass 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 DGWS_ktZ8BWH; Fri, 23 Jan 2015 18:21:53 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 23 Jan 2015 18:21:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EFFDC8008E; Fri, 23 Jan 2015 12:21:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1422033712; bh=icYwYiT9zLrc8unEqX14uP3ZiB3eXXiVh8tB6TZQqEA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=h3g+wIzLMmofbraHvG53fsRBVgOqn5Koxnwx1XaPMUL95hWbtu1B7HqYpgnaiqwB7 ynNnDjJU8aCIsY4ByzGUDrKc6o7KTsZkJT7R/W+ZO5NW6ofGJyh538jiBBSIa8jEtJ jOMnKG3g5+2I4ZVo5K1jJCDb9PyO+6IL/GXKvIOw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0NHLpeh021256; Fri, 23 Jan 2015 12:21:51 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 23 Jan 2015 12:21:51 -0500 (EST) From: Paul Wouters To: Paul Koning In-Reply-To: Message-ID: References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <363A367E1CF64C4C98586DC57F1AC987@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 23 Jan 2015 17:22:03 -0000 On Fri, 23 Jan 2015, Paul Koning wrote: >> Sorry for the late reply. Hopefully the following is more clear? >> >> When designing systems which will provide connectivity for >> non-authenticated users, the system SHOULD be designed with the capacity >> to support not only the maximum intended number of peers, but also include >> an additional number of sessions which are created due to malicious or >> erroneous behaviour. This safety margin will allow a system to still >> operate safely under load until it is exceeded. > > I understand the sentiment, but this seems like a recommendation that can’t be tested and can’t really be implemented either. The trouble is that the number of malicious sessions is unbounded (and may be quite large in a DOS scenario). > > It might be better simply to point out the limitations of the machinery: because authentication is not provided in this case, the receiving system has no way to distinguish legitimate peers from malicious ones. As a result, a denial of service attack may prevent the intended number of legitimate peers from communicating. Additional session (SA?) capacity may help in such cases. > > My point is that this is definitely going to be a case of throwing some more resources at the problem in the hopes it’s enough, but no way to predict whether it’s good enough. Because of that, “SHOULD” seems inappropriate, and a simple statement of the issue and the limitations of this new protocol is better. There are two cases of overload. A "legitimate" overload by simply having too many (anonymous) clients, and an overload by malicious clients. It is hard to tell the difference without authentication. We could introduce a new notification payload for IKE_INIT that pre-announces the desire for unauthenticated IKE. A server could then reject/drop those connections when the load of legitimate clients gets too high without needing to create more state. If later in the exchange an attempt for authenticated IKE is made, the connection can be dropped as malicious. I'm not sure if this will turn out to be a needed feature to help with the legitimate client overload problem, so I'm tempted to postpone adding this until we have field reports that it could be useful. Currently what we (libreswan) are implementing is counting both halfopen SAs as well as states associated with unauthenticated IKE SA's. The halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed source ip packet could have caused our end to initiate an IKE_INIT. Paul From nobody Sun Jan 25 15:01:58 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 7DD0D1A00DB for ; Sun, 25 Jan 2015 15:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.192 X-Spam-Level: X-Spam-Status: No, score=0.192 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHeLN-xRH5Iq for ; Sun, 25 Jan 2015 15:01:54 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973C31A0053 for ; Sun, 25 Jan 2015 15:01:54 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so6200077wgh.10 for ; Sun, 25 Jan 2015 15:01:53 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=SOChjHjngX3XA2Chs1qMHXsb65EgsfjQ2KujfLrYJeA=; b=ifaaNlyArUgxb08eyvMJWL64pIC5YN9kt5F3/+48DCZiHJklGmpUIUpXKxHjeQ2PsG OlMpN+IGTVt4PIWYtFguTB8vTYH7NnSdwYYo/dS5AiSb9sgGfHFnBKCv3qYRJj1L6iKz NEqLSIheTtTRF5VPk+qcdyrequFIRLuveehpCgzeSA8oFjxQ/kid+n9nfuDIYx7jkWtJ WPMmy5T5laKLyxzZptBGoOnkkN9MFg38TosmaJvxKkKkqVCdOGaF2nH7thaRJ35UpJya /+S3Ax10JeKB8nR/aEqkG2Q6oHDPuQr3i4+aF6EZQW+bs4GQkiNHFDT5osyLwUDNRLc3 aDOg== X-Received: by 10.180.91.201 with SMTP id cg9mr27015954wib.63.1422226913410; Sun, 25 Jan 2015 15:01:53 -0800 (PST) Received: from [10.0.0.7] (bzq-79-177-128-127.red.bezeqint.net. [79.177.128.127]) by mx.google.com with ESMTPSA id w3sm11931400wjf.3.2015.01.25.15.01.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 15:01:52 -0800 (PST) Message-ID: <54C53CC8.5010603@gmail.com> Date: Sun, 25 Jan 2015 10:58:16 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Valery Smyslov , Yoav Nir , ipsec References: <0305AC94D9084D07B34DB45847595AD6@buildpc> In-Reply-To: <0305AC94D9084D07B34DB45847595AD6@buildpc> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] Puzzle algorithm negotiation 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, 25 Jan 2015 23:01:56 -0000 Hi Yoav, Valery, I agree with Valery's proposed redefinition of the proof-work-work, based on the PRF. I am currently off-line so my question may have been answered in the pull request, but: can we make it very clear that the PRF used for the POW must be the very same as the one selected by the responder for the IKE SA? People may not like it (I don't) but a major reason for including agility today is FIPS silliness. One day people will be forced to rip out any mention of SHA-256 from their code, and we don't want to need to reopen the RFC. Thanks, Yaron On 01/19/2015 12:02 AM, Valery Smyslov wrote: > Hi Yoav, > > Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2 > > Hi, > > Valery has created this pull request. During the meeting in Honolulu > and subsequent discussion on the list, several people requested that > there be a negotiation of the algorithm used in the puzzle rather > than fixing it to SHA-256. > > The pull request suggests figuring out which algorithms the > Initiator supports by examining the SA payload in the IKE_SA_INIT > request, and using the PRF algorithms. > > Im posting this to the list, even thought were not sure about > this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC > wont work with the bitcoin-like puzzle that is currently in the draft. > > Why? > > For convenience assume a 16-byte cookie, a fixed zero IV (as always > in AES-XCBC) and fixed zero key. > > So let Y = AESENC(key, IV XOR COOKIE) = AESENC(zero, COOKIE) > Let Z = AESDEC(key, zero) = AESDEC(zero, zero) > Extend the cookie by Y XOR Z. > The result will give you a 128-bit tag of all zeros. Way too easy. > > You forgot about the mandatory 10* padding in AES-XCBC. > So, the result of AESDEC(zero, zero) should not be a random > string, but should look like properly padded one. > But anyway, I think that if we use PRF for puzzles, then the puzzle > definition should be changed. > Let R=PRF(K,S). Then the puzzle should be: using supplied cookie as > message S, > find a key K so, that result R contains the requested number of trailing > zero bits. > I'm not a cryptographer, but I think this variant of puzzle should be secure > for all PRFs, defined in IPsec. Why? First, every secure PRF is a secure > MAC > (not visa versa). This is pointed out by several sources. Then, secure MAC > should not allow attacker to recover a key given the message and > the authentication tag. In our case the authentication tag is not fully > given, > but it must have some properties (desired number of trailing zero bits), > so it is not arbitrary. > > Another way to do this is to add a notification in the Initiators > request listing the hash algorithms that it supports. We could reuse > the RFC 7427 registry of hash algorithms. > > I don't think this is a good idea. First, it will require initiator to > include > a list of supported hash algorithms into request message. This will > unnecessary increase its size in all cases: at this point initiator > has no idea whether responder will ever use puzzles or even > whether it supports them. I think this is a waste of resources, > especially taking into consideration that we may reuse > information, that is always present in the request message. > > Personally, I really dont like this algorithm agility, because we > dont want to give the Initiator the options of a hard vs easy > puzzle. So suppose the Responder supports two algorithms, SHA-256 > and SHA-512, and that the latter is half as fast as the former, then > a SHA-512 puzzle would have to have 1 bit less than the SHA-256 > puzzle. But in fact, we know that SHA-512 is faster on 64-bit > platforms, while SHA-256 is faster on 32-bit platforms. Add some > GOST-certified hash to the mix, and the administrators task becomes > that much harder. > > If the difference in algorithms speeds is significant, then some weights > could be > added to algorithm definitions to make the required time to solve puzzle > roughly the same > on the same platform. > > OTOH often when a protocol is published without algorithm agility, > we end up extending it later. > > Exactly. > > Yoav > > Regards, > Valery. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Sun Jan 25 20:52: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 DD5C11A1BE0 for ; Sun, 25 Jan 2015 20:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcjGDz7DJD5i for ; Sun, 25 Jan 2015 20:52:37 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E341A1BC9 for ; Sun, 25 Jan 2015 20:52:36 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id k48so6984844wev.9 for ; Sun, 25 Jan 2015 20:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LwGPfzpC0xq4yLFXrDQN7sjqwuPZkHiGTn8lqDyxXJw=; b=Yz6yTRImj9hHsYNmeO9elv8jzPrhJAmS4IYheaP4EwnWrJ5vwRPEpYzMB9dn27g118 kFh6HHCutq32NAjpTGR5NKfA4XRkaubHjIJwB191TTv2eu5Lm1oyuwc4DMGBx97oFPci Bf9xj/QwEACEUafKW5RD/++dmkvJBukUY2nebEERk4A1gx2CsQd1aFYj7ZD3UNwf26yA fKnWexnfy7ytHrqGXlEpNwrZa0YofKhaMqDld7ykn8FQTKPZlzC9YCuzLU7w8dAbV07F T2MEJeP7do2hDnno8vm3EO7kDkqZPOteSLfi8cvYxNrGkOAgpcc63gd9C/Ysl/RYI5uZ JaKg== X-Received: by 10.181.28.168 with SMTP id jp8mr28891853wid.40.1422247955515; Sun, 25 Jan 2015 20:52:35 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id r3sm12278922wic.10.2015.01.25.20.52.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Jan 2015 20:52:34 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <54C53CC8.5010603@gmail.com> Date: Mon, 26 Jan 2015 06:52:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <20D5D022-62E8-4BB4-97C0-C5D2D233D266@gmail.com> References: <0305AC94D9084D07B34DB45847595AD6@buildpc> <54C53CC8.5010603@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1993) Archived-At: Cc: ipsec , Valery Smyslov Subject: Re: [IPsec] Puzzle algorithm negotiation 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, 26 Jan 2015 04:52:39 -0000 > On Jan 25, 2015, at 8:58 PM, Yaron Sheffer = wrote: >=20 > Hi Yoav, Valery, >=20 > I agree with Valery's proposed redefinition of the proof-work-work, = based on the PRF. >=20 > I am currently off-line so my question may have been answered in the = pull request, but: can we make it very clear that the PRF used for the = POW must be the very same as the one selected by the responder for the = IKE SA? It is possible, but I don=92t see why it=92s a good thing. Suppose the = conversation goes like this: Initiator: I want (AES-CBC-128 or AES-CBC-256) with (AUTH_HMAC-SHA1 or = AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 = or Group 14) Responder: First do proof-of-work with PRF_HMAC-SHA256 Initiator: Here=92s the proof-of-work, now I want (AES-CBC-128 or = AES-CBC-256) with (AUTH_HMAC-SHA1 or AUTH_HMAC-SHA256) and (PRF_ = HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 or Group 14). Responder: Fine, I choose AES-CBC-128 with HMAC-SHA1 and PRF_HMAC-SHA1 = and Group 2. What is the benefit of forcing the responder to choose the same PRF = algorithm twice? What is wrong with having it choose PRF_HMAC-SHA1? = Sure, we *can* do this, but why? > People may not like it (I don't) but a major reason for including = agility today is FIPS silliness. One day people will be forced to rip = out any mention of SHA-256 from their code, and we don't want to need to = reopen the RFC. Some algorithms are also more fashionable than others. Yoav >=20 > Thanks, > Yaron >=20 > On 01/19/2015 12:02 AM, Valery Smyslov wrote: >> Hi Yoav, >>=20 >> Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2 >>=20 >> Hi, >>=20 >> Valery has created this pull request. During the meeting in = Honolulu >> and subsequent discussion on the list, several people requested = that >> there be a negotiation of the algorithm used in the puzzle rather >> than fixing it to SHA-256. >>=20 >> The pull request suggests figuring out which algorithms the >> Initiator supports by examining the SA payload in the IKE_SA_INIT >> request, and using the PRF algorithms. >>=20 >> I=92m posting this to the list, even thought we=92re not sure = about >> this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC >> won=92t work with the bitcoin-like puzzle that is currently in the = draft. >>=20 >> Why? >>=20 >> For convenience assume a 16-byte cookie, a fixed zero IV (as = always >> in AES-XCBC) and fixed zero key. >>=20 >> So let Y =3D AESENC(key, IV XOR COOKIE) =3D AESENC(zero, COOKIE) >> Let Z =3D AESDEC(key, zero) =3D AESDEC(zero, zero) >> Extend the cookie by Y XOR Z. >> The result will give you a 128-bit tag of all zeros. Way too easy. >>=20 >> You forgot about the mandatory 10* padding in AES-XCBC. >> So, the result of AESDEC(zero, zero) should not be a random >> string, but should look like properly padded one. >> But anyway, I think that if we use PRF for puzzles, then the puzzle >> definition should be changed. >> Let R=3DPRF(K,S). Then the puzzle should be: using supplied cookie as >> message S, >> find a key K so, that result R contains the requested number of = trailing >> zero bits. >> I'm not a cryptographer, but I think this variant of puzzle should be = secure >> for all PRFs, defined in IPsec. Why? First, every secure PRF is a = secure >> MAC >> (not visa versa). This is pointed out by several sources. Then, = secure MAC >> should not allow attacker to recover a key given the message and >> the authentication tag. In our case the authentication tag is not = fully >> given, >> but it must have some properties (desired number of trailing zero = bits), >> so it is not arbitrary. >>=20 >> Another way to do this is to add a notification in the Initiator=92s= >> request listing the hash algorithms that it supports. We could = reuse >> the RFC 7427 registry of hash algorithms. >>=20 >> I don't think this is a good idea. First, it will require initiator = to >> include >> a list of supported hash algorithms into request message. This will >> unnecessary increase its size in all cases: at this point initiator >> has no idea whether responder will ever use puzzles or even >> whether it supports them. I think this is a waste of resources, >> especially taking into consideration that we may reuse >> information, that is always present in the request message. >>=20 >> Personally, I really don=92t like this algorithm agility, because = we >> don=92t want to give the Initiator the options of a hard vs easy >> puzzle. So suppose the Responder supports two algorithms, SHA-256 >> and SHA-512, and that the latter is half as fast as the former, = then >> a SHA-512 puzzle would have to have 1 bit less than the SHA-256 >> puzzle. But in fact, we know that SHA-512 is faster on 64-bit >> platforms, while SHA-256 is faster on 32-bit platforms. Add some >> GOST-certified hash to the mix, and the administrator=92s task = becomes >> that much harder. >>=20 >> If the difference in algorithms speeds is significant, then some = weights >> could be >> added to algorithm definitions to make the required time to solve = puzzle >> roughly the same >> on the same platform. >>=20 >> OTOH often when a protocol is published without algorithm agility, >> we end up extending it later. >>=20 >> Exactly. >>=20 >> Yoav >>=20 >> Regards, >> Valery. >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 From nobody Mon Jan 26 00:55:55 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 B6A661A8773 for ; Mon, 26 Jan 2015 00:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 CM7bWfJvCRqm for ; Mon, 26 Jan 2015 00:55:52 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B061A6FF9 for ; Mon, 26 Jan 2015 00:55:52 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w55so2324665wes.1 for ; Mon, 26 Jan 2015 00:55:50 -0800 (PST) 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=3vzO0ltZc5a6dMv56qxpzX9la0278vkd6sPYsb75Jm4=; b=mHgZTMkWmkdxjWnz8j4ef0PFFmgcJ7W7LcpyC+e713zs8CUyG1ubixhFTnNRk3rkcO QcenIFBYYpB4gjDYCNs8VDHexXnpa7aumemPmJKXdAyyQpAelkWIci3w2AsEK0hvvvDW yRu4tXQakZo9v2x4ZTO69PzhxVbi/GQT5wePwGqMd/kF9BlHPXhAe5RS8EOZ8DoVi6RA QDCV0RDiDYfvc8leQzSjodIJiYtqZ/yh+yoliX4g+qRrzHE3f8fwvkf2sCcb5pGkT/Bn FwKm2gZrwt9tTsKCVYqcdbS7A+Hsm2K1OH0/mQ97VdawB0Jnqlr0bHxQxqmO1/hB6VWT 6UHw== X-Received: by 10.180.74.142 with SMTP id t14mr24260740wiv.9.1422262550866; Mon, 26 Jan 2015 00:55:50 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id bo3sm13367734wjb.44.2015.01.26.00.55.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 00:55:50 -0800 (PST) Message-ID: <54C54D96.4050203@gmail.com> Date: Sun, 25 Jan 2015 22:09:58 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Paul Wouters , Paul Koning References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <363A367E1CF64C4C98586DC57F1AC987@buildpc> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ipsec@ietf.org WG" , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 26 Jan 2015 08:55:53 -0000 I would suggest to mention DDOS in this document briefly, but to move the discussion (maybe add an entire section) to our dedicated DDOS/puzzles document. For the simple reason that we want to publish the NULL Auth document sooner. Since Valery is co-author on both, I guess he gets to write it :-) Thanks, Yaron On 01/23/2015 07:21 PM, Paul Wouters wrote: > On Fri, 23 Jan 2015, Paul Koning wrote: > >>> Sorry for the late reply. Hopefully the following is more clear? >>> >>> When designing systems which will provide connectivity for >>> non-authenticated users, the system SHOULD be designed with the capacity >>> to support not only the maximum intended number of peers, but also >>> include >>> an additional number of sessions which are created due to malicious or >>> erroneous behaviour. This safety margin will allow a system to still >>> operate safely under load until it is exceeded. >> >> I understand the sentiment, but this seems like a recommendation that >> cant be tested and cant really be implemented either. The trouble >> is that the number of malicious sessions is unbounded (and may be >> quite large in a DOS scenario). >> >> It might be better simply to point out the limitations of the >> machinery: because authentication is not provided in this case, the >> receiving system has no way to distinguish legitimate peers from >> malicious ones. As a result, a denial of service attack may prevent >> the intended number of legitimate peers from communicating. >> Additional session (SA?) capacity may help in such cases. >> >> My point is that this is definitely going to be a case of throwing >> some more resources at the problem in the hopes its enough, but no >> way to predict whether its good enough. Because of that, SHOULD >> seems inappropriate, and a simple statement of the issue and the >> limitations of this new protocol is better. > > There are two cases of overload. A "legitimate" overload by simply having > too many (anonymous) clients, and an overload by malicious clients. It > is hard to tell the difference without authentication. > > We could introduce a new notification payload for IKE_INIT that > pre-announces the desire for unauthenticated IKE. A server could then > reject/drop those connections when the load of legitimate clients gets > too high without needing to create more state. If later in the exchange > an attempt for authenticated IKE is made, the connection can be dropped > as malicious. I'm not sure if this will turn out to be a needed feature > to help with the legitimate client overload problem, so I'm tempted to > postpone adding this until we have field reports that it could be > useful. > > Currently what we (libreswan) are implementing is counting both halfopen > SAs as well as states associated with unauthenticated IKE SA's. The > halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed > source ip packet could have caused our end to initiate an IKE_INIT. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 26 01:34: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 770401A885E for ; Mon, 26 Jan 2015 01:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqQT8maVDbkN for ; Mon, 26 Jan 2015 01:34:39 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861BF1A8826 for ; Mon, 26 Jan 2015 01:34:39 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so8395976wid.5 for ; Mon, 26 Jan 2015 01:34:38 -0800 (PST) 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=rE/0KEHTQcRF0p76aDms+lYBwnL4oprRpgMoReq0Xik=; b=tff3fimUvi2lUMA6/F8l8iKus/eMZFzINzW7EJ63PcHGdyM7sIKuOYFTsfmWVxMwM3 Za8upU9vd9UIbeQZde0r0eL51ydLM+EjVP0JOtWG3BCdNuyAtGZ9Xsn4Kx22OdRvk3OV V3QvJAmpG955YbsZtOMQmbHyvHNVBW/dTjcMd2a+ZFXVhKAohbWy4K5Y75OfRpz0N+cD hiMWd+CsQecz7eXHSeJkvHELH3TxBwLF7OwjgWnw/d1CrM0P5U90as9KEYRbGnvu4szk m7U8QBV9UNRnw01i4cMFUgSINCL+oFTTlUpoLTg/7DWfmDToMK9FyhpYNSoX8FZa/LoA 0Q+A== X-Received: by 10.194.71.45 with SMTP id r13mr41165843wju.128.1422264878086; Mon, 26 Jan 2015 01:34:38 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id bo3sm13502227wjb.44.2015.01.26.01.34.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 01:34:37 -0800 (PST) Message-ID: <54C60A2C.2020105@gmail.com> Date: Mon, 26 Jan 2015 11:34:36 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yoav Nir References: <0305AC94D9084D07B34DB45847595AD6@buildpc> <54C53CC8.5010603@gmail.com> <20D5D022-62E8-4BB4-97C0-C5D2D233D266@gmail.com> In-Reply-To: <20D5D022-62E8-4BB4-97C0-C5D2D233D266@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipsec , Valery Smyslov Subject: Re: [IPsec] Puzzle algorithm negotiation 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, 26 Jan 2015 09:34:41 -0000 I thought fixing the PRF would simplify the implementation, but now I realize that it wouldn't. Thanks, Yaron On 01/26/2015 06:52 AM, Yoav Nir wrote: > >> On Jan 25, 2015, at 8:58 PM, Yaron Sheffer wrote: >> >> Hi Yoav, Valery, >> >> I agree with Valery's proposed redefinition of the proof-work-work, based on the PRF. >> >> I am currently off-line so my question may have been answered in the pull request, but: can we make it very clear that the PRF used for the POW must be the very same as the one selected by the responder for the IKE SA? > > It is possible, but I don’t see why it’s a good thing. Suppose the conversation goes like this: > > Initiator: I want (AES-CBC-128 or AES-CBC-256) with (AUTH_HMAC-SHA1 or AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 or Group 14) > > Responder: First do proof-of-work with PRF_HMAC-SHA256 > > Initiator: Here’s the proof-of-work, now I want (AES-CBC-128 or AES-CBC-256) with (AUTH_HMAC-SHA1 or AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 or Group 14). > > Responder: Fine, I choose AES-CBC-128 with HMAC-SHA1 and PRF_HMAC-SHA1 and Group 2. > > What is the benefit of forcing the responder to choose the same PRF algorithm twice? What is wrong with having it choose PRF_HMAC-SHA1? Sure, we *can* do this, but why? > >> People may not like it (I don't) but a major reason for including agility today is FIPS silliness. One day people will be forced to rip out any mention of SHA-256 from their code, and we don't want to need to reopen the RFC. > > Some algorithms are also more fashionable than others. > > Yoav > >> >> Thanks, >> Yaron >> >> On 01/19/2015 12:02 AM, Valery Smyslov wrote: >>> Hi Yoav, >>> >>> Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2 >>> >>> Hi, >>> >>> Valery has created this pull request. During the meeting in Honolulu >>> and subsequent discussion on the list, several people requested that >>> there be a negotiation of the algorithm used in the puzzle rather >>> than fixing it to SHA-256. >>> >>> The pull request suggests figuring out which algorithms the >>> Initiator supports by examining the SA payload in the IKE_SA_INIT >>> request, and using the PRF algorithms. >>> >>> I’m posting this to the list, even thought we’re not sure about >>> this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC >>> won’t work with the bitcoin-like puzzle that is currently in the draft. >>> >>> Why? >>> >>> For convenience assume a 16-byte cookie, a fixed zero IV (as always >>> in AES-XCBC) and fixed zero key. >>> >>> So let Y = AESENC(key, IV XOR COOKIE) = AESENC(zero, COOKIE) >>> Let Z = AESDEC(key, zero) = AESDEC(zero, zero) >>> Extend the cookie by Y XOR Z. >>> The result will give you a 128-bit tag of all zeros. Way too easy. >>> >>> You forgot about the mandatory 10* padding in AES-XCBC. >>> So, the result of AESDEC(zero, zero) should not be a random >>> string, but should look like properly padded one. >>> But anyway, I think that if we use PRF for puzzles, then the puzzle >>> definition should be changed. >>> Let R=PRF(K,S). Then the puzzle should be: using supplied cookie as >>> message S, >>> find a key K so, that result R contains the requested number of trailing >>> zero bits. >>> I'm not a cryptographer, but I think this variant of puzzle should be secure >>> for all PRFs, defined in IPsec. Why? First, every secure PRF is a secure >>> MAC >>> (not visa versa). This is pointed out by several sources. Then, secure MAC >>> should not allow attacker to recover a key given the message and >>> the authentication tag. In our case the authentication tag is not fully >>> given, >>> but it must have some properties (desired number of trailing zero bits), >>> so it is not arbitrary. >>> >>> Another way to do this is to add a notification in the Initiator’s >>> request listing the hash algorithms that it supports. We could reuse >>> the RFC 7427 registry of hash algorithms. >>> >>> I don't think this is a good idea. First, it will require initiator to >>> include >>> a list of supported hash algorithms into request message. This will >>> unnecessary increase its size in all cases: at this point initiator >>> has no idea whether responder will ever use puzzles or even >>> whether it supports them. I think this is a waste of resources, >>> especially taking into consideration that we may reuse >>> information, that is always present in the request message. >>> >>> Personally, I really don’t like this algorithm agility, because we >>> don’t want to give the Initiator the options of a hard vs easy >>> puzzle. So suppose the Responder supports two algorithms, SHA-256 >>> and SHA-512, and that the latter is half as fast as the former, then >>> a SHA-512 puzzle would have to have 1 bit less than the SHA-256 >>> puzzle. But in fact, we know that SHA-512 is faster on 64-bit >>> platforms, while SHA-256 is faster on 32-bit platforms. Add some >>> GOST-certified hash to the mix, and the administrator’s task becomes >>> that much harder. >>> >>> If the difference in algorithms speeds is significant, then some weights >>> could be >>> added to algorithm definitions to make the required time to solve puzzle >>> roughly the same >>> on the same platform. >>> >>> OTOH often when a protocol is published without algorithm agility, >>> we end up extending it later. >>> >>> Exactly. >>> >>> Yoav >>> >>> Regards, >>> Valery. >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> > From nobody Mon Jan 26 03:37:50 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 704AF1A026F for ; Mon, 26 Jan 2015 03:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAGLfzfzqOqF for ; Mon, 26 Jan 2015 03:37:46 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5F61A8925 for ; Mon, 26 Jan 2015 03:37:44 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id u14so7043386lbd.2 for ; Mon, 26 Jan 2015 03:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=bYekKx4MHMn6EFVh0QD1h1dEyomMNiHAMM1jCNFGaYU=; b=PnJ3EH1nEAlMWzIvmt3wQPr4LkSg39Kq3uv9foOLrAeK1F71qay/JlKDUSEoiMy9xB oRdltbYFP8HyRgQHlrAYGp2LE1x+m8qOYIhaqNNJ/M0ZrvBeMpTX1L5sx7uv3LElXPhm T6wz2RErhpzY/KBWLs1mFZTIMmMAJRSMf+5w29/dcrAp/c1O36Vv4Kvtj+qii6uJPHCZ S20zetNxvq8dp4h4yu9BkWr0Wt1ITxB157nuYn7KKV4RFhW90nJQjgWKNIrdca6C2dfq vEw1DPMMWIuzhyroAjyJJCd74rlNrN7AV+efXVrdDaQRWCwsXzgov6LR1SkK/1PiJMjz plKg== X-Received: by 10.152.198.200 with SMTP id je8mr20399886lac.93.1422272263333; Mon, 26 Jan 2015 03:37:43 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id zo3sm2754258lbb.10.2015.01.26.03.37.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Jan 2015 03:37:42 -0800 (PST) Message-ID: <2DCAD3DF89C949D2B917F4049BFDB265@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Paul Wouters" , "Paul Koning" References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <363A367E1CF64C4C98586DC57F1AC987@buildpc> <54C54D96.4050203@gmail.com> Date: Mon, 26 Jan 2015 14:37:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 26 Jan 2015 11:37:48 -0000 Hi Yaron, there is already Section 3.2, which discusses possible impact of NULL Auth on DOS resistance, and the ddos/puzzles document is already referenced there. Do you think more words need to be added to this section? Regards, Valery. ----- Original Message ----- From: "Yaron Sheffer" To: "Paul Wouters" ; "Paul Koning" Cc: ; "Graham Bartlett (grbartle)" Sent: Sunday, January 25, 2015 11:09 PM Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth I would suggest to mention DDOS in this document briefly, but to move the discussion (maybe add an entire section) to our dedicated DDOS/puzzles document. For the simple reason that we want to publish the NULL Auth document sooner. Since Valery is co-author on both, I guess he gets to write it :-) Thanks, Yaron On 01/23/2015 07:21 PM, Paul Wouters wrote: > On Fri, 23 Jan 2015, Paul Koning wrote: > >>> Sorry for the late reply. Hopefully the following is more clear? >>> >>> When designing systems which will provide connectivity for >>> non-authenticated users, the system SHOULD be designed with the capacity >>> to support not only the maximum intended number of peers, but also >>> include >>> an additional number of sessions which are created due to malicious or >>> erroneous behaviour. This safety margin will allow a system to still >>> operate safely under load until it is exceeded. >> >> I understand the sentiment, but this seems like a recommendation that >> cant be tested and cant really be implemented either. The trouble >> is that the number of malicious sessions is unbounded (and may be >> quite large in a DOS scenario). >> >> It might be better simply to point out the limitations of the >> machinery: because authentication is not provided in this case, the >> receiving system has no way to distinguish legitimate peers from >> malicious ones. As a result, a denial of service attack may prevent >> the intended number of legitimate peers from communicating. >> Additional session (SA?) capacity may help in such cases. >> >> My point is that this is definitely going to be a case of throwing >> some more resources at the problem in the hopes its enough, but no >> way to predict whether its good enough. Because of that, SHOULD >> seems inappropriate, and a simple statement of the issue and the >> limitations of this new protocol is better. > > There are two cases of overload. A "legitimate" overload by simply having > too many (anonymous) clients, and an overload by malicious clients. It > is hard to tell the difference without authentication. > > We could introduce a new notification payload for IKE_INIT that > pre-announces the desire for unauthenticated IKE. A server could then > reject/drop those connections when the load of legitimate clients gets > too high without needing to create more state. If later in the exchange > an attempt for authenticated IKE is made, the connection can be dropped > as malicious. I'm not sure if this will turn out to be a needed feature > to help with the legitimate client overload problem, so I'm tempted to > postpone adding this until we have field reports that it could be > useful. > > Currently what we (libreswan) are implementing is counting both halfopen > SAs as well as states associated with unauthenticated IKE SA's. The > halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed > source ip packet could have caused our end to initiate an IKE_INIT. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 26 05:35:59 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 7160F1A8A08 for ; Mon, 26 Jan 2015 05:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d8zKGSNovBm for ; Mon, 26 Jan 2015 05:35:53 -0800 (PST) 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 969D91A8861 for ; Mon, 26 Jan 2015 05:35:53 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id h11so3910459wiw.0 for ; Mon, 26 Jan 2015 05:35:52 -0800 (PST) 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=7q6Ja8Ku+mZdN4Eh5C86vgVnGVvziAutH/cyTTP+TK8=; b=HByRWUksEPn23riR7TUHXeVj6lgzbpR+fP4Dtc/9KI5jPVeISLuG1VzOcjmsq5Q9Pe Qg5Rt49TDZ/M/5LV36zAaa+zlnMH3Buct4f2SwmF788kUe1dt7XhzBK28tsEHh+daS01 HT2gAi8xpGp3cqOhRPgEwz3M8I6VAVf3Dt4kOvGe2o8gE+HXQVm6hq1jzo4DOlWKlFWV GNTQDzzFz2jFzo+e0xFTvRaAYO119Hdu6R6TGaAD6gFYwfatlvc3Og+hZJBRyJVm419p 8vVcX0+zumh/c5Ow5r7f6PUtWKEpHsFyPbnZh/Y55JZCLFKWvFAqd0OxUwWa5WpvJvie WlvA== X-Received: by 10.194.104.196 with SMTP id gg4mr43269659wjb.31.1422279352344; Mon, 26 Jan 2015 05:35:52 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id dp8sm13952656wib.20.2015.01.26.05.35.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 05:35:51 -0800 (PST) Message-ID: <54C642B5.1050909@gmail.com> Date: Mon, 26 Jan 2015 15:35:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Valery Smyslov , Paul Wouters , Paul Koning References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <363A367E1CF64C4C98586DC57F1AC987@buildpc> <54C54D96.4050203@gmail.com> <2DCAD3DF89C949D2B917F4049BFDB265@buildpc> In-Reply-To: <2DCAD3DF89C949D2B917F4049BFDB265@buildpc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipsec@ietf.org, "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth 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, 26 Jan 2015 13:35:56 -0000 Hi Valery, The DoS/puzzles document presents a "plan" for DDoS defense. I believe that unauthenticated clients need to be considered as part of this plan. I'm OK with the general guidelines in Sec. 3.2, but suggest that the DDoS document needs to be beefed up to account for this use case. Thanks, Yaron On 01/26/2015 01:37 PM, Valery Smyslov wrote: > Hi Yaron, > > there is already Section 3.2, which discusses possible > impact of NULL Auth on DOS resistance, and > the ddos/puzzles document is already referenced there. > Do you think more words need to be added to this section? > > Regards, > Valery. > > ----- Original Message ----- From: "Yaron Sheffer" > To: "Paul Wouters" ; "Paul Koning" > Cc: ; "Graham Bartlett (grbartle)" > Sent: Sunday, January 25, 2015 11:09 PM > Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in > IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth > > > I would suggest to mention DDOS in this document briefly, but to move > the discussion (maybe add an entire section) to our dedicated > DDOS/puzzles document. For the simple reason that we want to publish the > NULL Auth document sooner. > > Since Valery is co-author on both, I guess he gets to write it :-) > > Thanks, > Yaron > > On 01/23/2015 07:21 PM, Paul Wouters wrote: >> On Fri, 23 Jan 2015, Paul Koning wrote: >> >>>> Sorry for the late reply. Hopefully the following is more clear? >>>> >>>> When designing systems which will provide connectivity for >>>> non-authenticated users, the system SHOULD be designed with the >>>> capacity >>>> to support not only the maximum intended number of peers, but also >>>> include >>>> an additional number of sessions which are created due to malicious or >>>> erroneous behaviour. This safety margin will allow a system to still >>>> operate safely under load until it is exceeded. >>> >>> I understand the sentiment, but this seems like a recommendation that >>> can’t be tested and can’t really be implemented either. The trouble >>> is that the number of malicious sessions is unbounded (and may be >>> quite large in a DOS scenario). >>> >>> It might be better simply to point out the limitations of the >>> machinery: because authentication is not provided in this case, the >>> receiving system has no way to distinguish legitimate peers from >>> malicious ones. As a result, a denial of service attack may prevent >>> the intended number of legitimate peers from communicating. >>> Additional session (SA?) capacity may help in such cases. >>> >>> My point is that this is definitely going to be a case of throwing >>> some more resources at the problem in the hopes it’s enough, but no >>> way to predict whether it’s good enough. Because of that, “SHOULD” >>> seems inappropriate, and a simple statement of the issue and the >>> limitations of this new protocol is better. >> >> There are two cases of overload. A "legitimate" overload by simply having >> too many (anonymous) clients, and an overload by malicious clients. It >> is hard to tell the difference without authentication. >> >> We could introduce a new notification payload for IKE_INIT that >> pre-announces the desire for unauthenticated IKE. A server could then >> reject/drop those connections when the load of legitimate clients gets >> too high without needing to create more state. If later in the exchange >> an attempt for authenticated IKE is made, the connection can be dropped >> as malicious. I'm not sure if this will turn out to be a needed feature >> to help with the legitimate client overload problem, so I'm tempted to >> postpone adding this until we have field reports that it could be >> useful. >> >> Currently what we (libreswan) are implementing is counting both halfopen >> SAs as well as states associated with unauthenticated IKE SA's. The >> halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed >> source ip packet could have caused our end to initiate an IKE_INIT. >> >> Paul >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 26 06:40: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 3BDA41A8851 for ; Mon, 26 Jan 2015 06:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.769 X-Spam-Level: ** X-Spam-Status: No, score=2.769 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, 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 Oe4cqLPngkDa for ; Mon, 26 Jan 2015 06:40:09 -0800 (PST) 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 777981A8AD3 for ; Mon, 26 Jan 2015 06:40:00 -0800 (PST) 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 t0QEdsjl013562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jan 2015 16:39:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0QEds0f007880; Mon, 26 Jan 2015 16:39:54 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21702.20921.799010.19985@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2015 16:39:53 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 39 min X-Total-Time: 40 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My comments to the Null Authentication Method draft 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, 26 Jan 2015 14:40:12 -0000 Paul Wouters writes: > On Mon, 19 Jan 2015, Tero Kivinen wrote: > > In security considerations section there is text: > > > > Un-authenticated IKE > > sessions MUST only attempted when authenticated IKE sessions are not > > possible for the remote host and the only alternative would be to > > send plaintext. > > > > I assume that s/MUST only attempted/MUST only be attempted/ > > yes. > > > but also I do not think we cannot use un-authenticated IKE session > > even when there was 3rot13 method to "encrypt" the packet. In your > > text we cannot replace 3rot13 method with Un-authenticated IKE > > sessions as it is not plaintext (you can also replace 3rot13 with > > other weak cipher for example 40-bit RC4, or single DES). > > Yes, if you have a corporate VPN tunnel defined that uses authentication > and dictates 3rot13 encryption, I believe it should pick your corporate > VPN and not do unauthenticated IKE with unbreakable threefish. Because > your undecryptable threefish can still be trivially MITM'ed. We should > not start evaluating whether we think MITM'able threefish is more secure > than authenticated 3rot13 or not. The decision was made when you > configured that authenticated VPN. I was not commenting about the "when authenticated IKE sessions are not possible" (== with VPN we do have authenticated IKE sessions, so it is clear it overrides the un-authenticated IKE sessions). I was commeting on the second requirement, i.e. that "only alternative would be to send plaintext". I think that requirement is too strict. I.e. I think we should be able to use un-authenticated IKE sessions even when when we are using 40-bit WEP on the link. With your text we cannot, as Un-authenticated IKE sessions MUST only be attemtpetd when the ... only alternative would be to send plaintext. 40-bit WEP is not plaintext, thus we cannot use un-authenticated IKE... > > Also limiting un-authenticated IKE sessions this way really restricts > > the use cases for this. I would rather says that "If authenticated IKE > > sessions are possible between the hosts, then un-authenticated IKE > > MUST NOT be used". But even that will restrict some use cases. > > I'm fine with that text. If it restricts a use case, then that's great. > The use case would be inheritently unsafe and provide a false sense > of security. We can only provide false sense of security if we somehow show this to user. For example in tcpinc the general consensus seems to be that users should never see if tcpinc is on or off, thus we cannot give false sense of security. Same thing here. If you do consider un-authenticated IKE as plaintext, you cannot give false sense of security. If you only put "lock" on when you actually do authenticated IKE then there is no problem. The use case I was talking about was this kind of anonymous un-authenticated reading of forums, but requiring authentication and encryption for posting. And in this context consider forums as general name for all kind of services we might run on server, not all of those need to be interactive. We might also have cloud service storing some kind of measurements from your phone. To submit new entry you would require authentication. To reading information there might not be need for authenticaiton, thus un-authenticated encrypted connection might be ok. The reason why you want to use un-authenticated connections sometimes, might be when the authentication is annoying, for example when using securID or similar interactive method. > > For example some forum site might want to restrict posting of new > > comments to authenticated users, but would still want to allow reading > > of entries without doing authentication. > > That's really an application level issue. We are just talking about > encrypting the transport where the alternative is plaintext. Your > forum should have HTTP basic auth to identify users, the user > identification does not belong at the IKE layer. HTTP basic might work for forums, but as I explained above, the protocol used might not be http, and the connection might not be coming from user. The authentication might require user interaction, which is the reason we might not want to do it all the time. You seem to have very limited use case for this thing, and I would like to see much wider user case, i.e. actually going to similar use cases than tcpinc has, but not restricted on the tcp layer, but also working with udp and other protocols. > > be configured to be able to do both. In normal case the user will > > always do un-authenticated connection to read entries, and when he > > decides to post a reply or new comment, the software would > > automatically create new authenticated IKE SA and do the actual post > > through that, even when still at the same time keep the > > un-authenticated connection for reading... Btw, in such cases the > > connections might use per TCP-flow Child SAs... > > Apache is not going to talk to the IKE daemon to do user authentication. > That's far more expensive than HTTP Basic Auth, and would require a > decade of IKE deployments to make it universally available. Let's talk > about real use cases? :) IKE has about the same expense than doing TLS. You are saying that no http server never runs TLS, because that is much more expensive than HTTP basic auth... And I used forum as example of classes of services you might run. All kind of cloud services are another class of services you might run.The forum might also be using nntp instead of http interface to provide the forum services. I talked about the forums, you assumed I talked about web/http. There are other ways of implementing forums than http. > > You also claim that using ID type other than ID_NULL will compromise > > the clients anonymity. I do not agree on this statement. Using > > pseudonyms, or completely random ID for each connection will not > > compromise anonymity, but will allow certain use cases. In some cases > > there might be reasons to allow matching old and new sessions to same > > client (for example INITIAL_CONTACT) but even that does not compromise > > the anonymity. > > You are right it might not compromise it, but it also might. For > instance your phone switching between LTE and Wifi while using the > same "random ID". So you should say that not using ID_NULL might compromise the client anonymity, not that it will compromise it. > > Even if you know that same ID is used, and it might be > > same user than last time, that does not mean that you know who the > > user is. > > If you can track to user, so can active attackers doing MITM. That's > the problem. Yes, it might be problem in some cases, but not all use cases for the null require anonymity. Actually almost all of the uses I have in mind do not. > > Section 3.1 asks for implemntations to "audit implementations for any > > assumptions". I think better wording is needed, I do not want to > > provide our customers a audit records for this kind of things (and I > > know some of our customers would be reading this text in such way that > > we must provide those audit records). > > > > Perhaps the text should say that implemenations should verify that > > their assumptions are still valid or something like that. Or just warn > > implementors that their assumptions might not be valid anymore... > > Sure :) I was not aware of such creative customers. You are so lucky... We have had customers reading appendix of RFCs listing choises the authors considered, but didn't select and reasons for not selecting them, and then asking for us to provide those options. And the reason for why they need it: "it is in the RFC". > > There are use cases where user1 wants to replace Child SAs created by > > same user1, i.e. when you reconnect after crash, or you have multiple > > devices using same resource (i.e. moving video stream from your mobile > > phone to your laptop by just connecting from your laptop and creating > > new Child SA with same traffic selectors and disconnecting your mobile > > phone, so all traffic will now go to the laptop (which have requested > > same internal address associated with the user from the server). > > First of all, if you crashed there is nothing anyone can do. There is no > way to tell you apart from another new connection. Unless you abuse the > random ID and store it across reboots which is _really_ putting in too > much trust, because now I can obtain/hack/reverse engineer your random > ID to actually obtain your encrypted IP streams. I really don't want to > go there. Your use cases are more restrictive than mine. I can see uses cases where that is useful, especially when we are talking about anonymous opportunistic uses. I mean if there is no authentication, the video stream does not have any secret information in it. I mean yes, you could steal someones youtube stream that way (again not talking about specially youtube, as it uses http, but similar kind of service or class of services), but what is the gain. You could have started looking at the same cat-video yourself. In some use cases there might be some information that might be leaked out if for example the great firewall of country x suspects someone is looking unsafe cat-videos, and would want to verify that by stealing users connection, but it might be easier to just do that from the start... For normal user the conveniency of being able to move things around is more important than the fact that someone might steal his cat-videos. If someone does active attack and steals it, then he just needs to start it again... > Second, if you want to move your video stream from your phone to your > laptop, explain to me how I cannot abuse that mechanism to streal your > phone's videostream to _my_ laptop? If it is un-authenticated, there is nothing restricting that. That is what null authentication is all about. If it is not anonymous, but uses some kind of random IDs or pseudonyms, you need first break my random ID before you can do that, so it adds more protection. > The only way I can think of is if your securely transfer your > "random ID" from one device to the other, meaning it is easier > really easy for you to type in, or you are using an authenticated > connection between your laptop and phone, in which case you should > just transfer the entire IKE and IPsec state without needing a > protocol change here. Or the random id might be derived from my long lived secret I already have in all those devices, and the current date / time. Or I might simply transfer the request to move the date over bluetooth and include the secret there or whatever. Having applications being able to move the IKE and IPsec state over is bit more challenging than sending information about to where to connect and what ID to use... For example I think chrome-browser now have this feature where you can say that move this stream of video from this screen to some other screen logged in as same user. Then the link to url will go through the cloud service provided by the application and is protected by that application. The url could include your random ID or something. > Also, your "random ID" is beginning to look a lot like a kerberos token :P Not really, as that would be authenticated token. In this case it would simply be random pseudonym of me, which I could share between few devices, and which I might change at will without telling anybody. > > Section 3.4 should most likely also mention RFC5739 as it allows > > assigning full /64 address block to client, and with that you might > > use wider traffic selectors. I think we need separate section for the > > traffic selectors. Now some of that is in the section 3.3 (not > > replacing IPsec SA), and some are in 3.4. The title of "Network > > topology changes" does not really describe the problem with traffic > > selectors. Moving all text related to it to separate subsection might > > make things easier. > > Sure, once we reach agreement of what can/should/must not be done with > traffic selectors. Yes, that is big part missing from the draft. > > and also perhaps talk about per flow SAs etc. > > I still have not understood a valid use case for this, let alone one > that justifies the potential negative effects allowing multiple IPsec > SA's gives. What are negative effects there are? If you do not have resources, then do not allow. That is what policies are for. If you have resources for it, and the policy allows it, go for it. I do not see reason why we should restrict it out here. -- kivinen@iki.fi From nobody Mon Jan 26 07:05:03 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 F23761A8BC1 for ; Mon, 26 Jan 2015 07:05:01 -0800 (PST) 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_20=-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 P2WQuiXhS_qo for ; Mon, 26 Jan 2015 07:05:00 -0800 (PST) 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 EBB341A9033 for ; Mon, 26 Jan 2015 07:04:49 -0800 (PST) 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 t0QF4kuJ021353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jan 2015 17:04:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0QF4kVu020982; Mon, 26 Jan 2015 17:04:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21702.22413.999704.762826@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2015 17:04:45 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <42287653737F4C17925AAF23F337AAD3@buildpc> References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <42287653737F4C17925AAF23F337AAD3@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 22 min X-Total-Time: 21 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My comments to the Null Authentication Method draft 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, 26 Jan 2015 15:05:02 -0000 Valery Smyslov writes: > Hi Tero, > > thanks for your detailed review. Please see inline. > I commented only the issues where we disagree with Paul. > > > On the other hand same section says that ID_NULL SHOULD only be used > > with NULL authentication method. In which scenarios do you think > > ID_NULL can be used when using normal authentication? I.e. which is > > the exception for the SHOULD? > > It could be used, for example, in the first IKE_AUTH message sent from > the client when EAP authentication is requested. If SGW is acting > as pass-through between client and backend authentication server > (e.g. RADIUS), that server will typically start EAP session from > requesting EAP Identity anyway, so the ID Payload received > from the client becomes useless. Nope. The IKE ID payloads needs to be used, and the EAP identity reqeuest and respond SHOULD NOT be used (from RFC7296 section 3.16): Note that since IKE passes an indication of initiator identity in the first message in the IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity requests. The initiator MAY, however, respond to such requests if it receives them. Also section 2.16 warns that if EAP Identity is used, there might be mismatch with the ID payloads, and correct one needs to be used for policy lookups: When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity, if different from that in the IDi payload, has to be sent from the AAA server to the IKEv2 responder. > The intent was to hint to implementers, that the event of creating > new unauthenticated IKE SA MAY be considered as a trigger for > liveness check procedure on inactive unauthenticated SAs. There is > no requirement that this check be immediately done on all the SAs. > But without such advise naive implementation may ends up > having a lot of stale IKE SAs (for example, if it performs > liveness check only if it needs to send data over SA). On the other hand if it has enough resources, there is not really a problem having lots of stale IKE SAs. Storing those IKE SAs in the memory does not really increase the power consumption of the device (yes, there might be devices where this might actually be true, and in that case it should most likely use more aggressive cleanup policy). If the device is running out of resources, then it should start doing some cleanup processes (most likely way ahead of when it actually runs out of resources). > > I.e. device creates anonymous IKE SA with server, then device is > > restarted, and it creates new IKE SA and now it will send > > INITIAL_CONTACT as it does not have any SAs with server. Most likely > > those connections have same IP-address, thus to clean up state, it is > > Not necessary. Depending on the ISP the client may get new IP > address. Yes, but very commonly it will get same IP and that is the case we should optimize for. Doing one liveness check for one IP is cheap. Starting to do it for 10000 IKE SAs is expensive... Especially if we have new un-authenticated IKE connections at the rate of 10/sec... (i.e. the average connection time is few hours). > > enough to just do liveness check for old IKE SA from the same > > IP-address. We cannot just remove it as the IP-address might be the > > address of the NAT box. > > It is not enough to check only SAs with same IP-address. We do not need to clear out all stale IKE SA from the memory, we need to make sure we optimize and clean up the most likely one. The rest are taken care of by the normal cleanup routines. > However, as I've written above, there is no need to > immediately perform liveness check on all SAs. > The event of creating new unauthenticated IKE SA is just a hint, > that some of other such SAs might become stale and > they need to be checked (no rush though). I would expect that servers having so many users that liveness checks really matter, will have so many new sessions per second, that this statement is compeltely useless, as you would get this hint several times per second, which means it is useless hint. If you only get new un-authenticate IKE SA every few minutes or so, then you most likely will not have enough stale IKE SAs for them to matter (lets say you have 4 hour lifetime for IKE SAs and new connections every 2 minutes, that will mean you have 120 IKE SA). > It is implementation dependant how this check is done - > implementations may check all the SAs if there are > a handfull of them, check first SAs with the same IP > address and let the other to be checked on a time-based basis, > or ignore this event at all and rely on usual regular checking. > I don't think the document should mandate such things. I agree. But I think more usefull hint for implementors would be to check the IKE SAs having same IP address than newly created IKE SA, than the current one we have. > > Also if the device sent some other ID than ID_NULL, we could again do > > liveness check for those IKE SAs which have same ID than the new > > The -01 version of the draft recommended doing so. > Do you think it is worth put it back? Yes. Especially as the rfc7296 will talk about INITIAL_CONTACT and authenticated identities. When we are talking about un-authenticated identities we should just say that this does not automatically clean up any state, just provide hint that liveness check might be usefull for that IKE SA. > > Also limiting un-authenticated IKE sessions this way really restricts > > the use cases for this. I would rather says that "If authenticated IKE > > sessions are possible between the hosts, then un-authenticated IKE > > MUST NOT be used". But even that will restrict some use cases. > > I think this wording is too restrictive. As I pointed out, I too think it might be too restrictive... but it is better than what we have now there. > Well, the question is: why do we need NULL auth at all. > If it is intended only for opportunistic security, then yes, > it must only be used if the peers cannot authenticate > themselves. But there are use cases when the user is able > to authenticate himself/herself, but he/she doesn't want > to do it for the particular SA. For example, if I'm an Wikipedia > editor, then I need to be able to authentiacte myself while > I perform edits. But I want to keep anonimity while I read > Wikipedia to prevent tracing back what I'm interested in. Yep. Altough as Paul will point out that wikipedia uses http, so it would be using IKE, but I assume you similar class of services, some of which might be running over UDP etc. How to formulate the text in the draft is different matter. Perhaps If authenticated IKE sessions are possible between the hosts, then un-authenticated IKE SHOULD NOT be used, unless implementations make sure to keep authenticated and un-authenticated IKE sessions separate, and has policy rules to specify when to use which IKE session. Or something like that. -- kivinen@iki.fi From nobody Mon Jan 26 07:24:24 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 0122C1A9087 for ; Mon, 26 Jan 2015 07:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YMj7jtxu7-CJ for ; Mon, 26 Jan 2015 07:24:20 -0800 (PST) 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 346E31A9081 for ; Mon, 26 Jan 2015 07:24:19 -0800 (PST) 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 t0QFOGvv026256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jan 2015 17:24:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0QFOGLY019274; Mon, 26 Jan 2015 17:24:16 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21702.23584.557958.684640@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2015 17:24:16 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <038B7179C6EB4C5BB2A110AD37541204@buildpc> <21694.26453.977101.952972@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 13 min Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd) 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, 26 Jan 2015 15:24:22 -0000 Paul Wouters writes: > >> I think it is a server's policy issue. It can always restrict > >> the number of IPsec SAs from a single peer > >> by using NO_ADDITIONAL_SAS notification. > >> The document should not impose any restrictions here, IMHO. > > > > Agree. Implementations might also have different limits depending > > whether the other end is authenticated or unauthenticated, i.e. > > unauthenticated clients might only be able to create for example 10 > > Child SAs, and authenticated clients can create 1000 Child SAs... And > > btw child SAs are quite cheap, so the limit does not need to be 1 and > > 3... :) > > But what's the point? Just to protect th per-port IPsec SA's with > more PFS in CREATE_CHILD_SA ? For some reason people wnat to turn on PFS on TLS, so that NSA cannot break all the http-connections by just stealing that one key from the server. For the same reason IKE users who already do Diffie-Hellman during the IEK SA creation, might want to do separate PFS for different Child SAs, just to make things harder for attacker. Again as we are talking about un-authenticated connections, NSA can just do MitM in the beginning, and gain all traffic, but that is active attack, which might get detected. Doing passive storing of the all traffic and then breaking Diffie-Hellman later provides better ways of staying undetected for them. If we do one 1024-bit Diffie-Hellman using un-authenticated exchange, then they can break that one 1024-bit Diffie-Hellman and get all traffic protected by each Child SA. If we do PFS for each Child SA then they need first to break the IKE SA Diffie-Helman and then for each traffic flow second one... There are people who want this kind of feature. Thats why this draft should not have any text restricting per-flow SAs... It might have comment saying that because clients are un-authenticated, there might be need for tighter resource limits than for authenticated clients. > It will only cause interop failures. The client will not pick a > host-to-host but picks say port 80 only. Then it wants port 443 and > gets NO_ADDITIONAL_SAS. Then it needs to drop the port 80 SA and > restart everything to get the full range single SA. Why should that cause interop failures? This is all standard RFC7296 stuff already. We are not changing anything here related to this. > If you are not authenticated, what is the point in splitting up the > traffic in different IPsec SA's per protocol or port? Causing more work for the passive monitoring people breaking your multiple 1024-bit Diffie-Hellmans, instead of just breaking one. And you might use shorter Diffe-Hellman groups for performance reasons than with authneticated use cases. > The only use case I have heard of that could apply, is the use case > of being mandated to NOT encrypt something for auditing purposes. But > traffic selectors really suck for "everything but sip and smtp and pop > and imap" :P Yes, usually traffic selectors are either per IP, or per-flow. Anything else are usually just silly... And for most normal authenticated use cases per-flow SAs are not really that useful, but we still have them in RFC7296, and I do not see any reason why they should be removed in this document. The most common use cases for per-flow SAs is when you have multiuser system where different users use different IKE SAs and per-flow SAs. I have not really seen those used that much lately... -- kivinen@iki.fi From nobody Mon Jan 26 07:38: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 7F10A1A8F4B for ; Mon, 26 Jan 2015 07:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 bTIGwORG8oar for ; Mon, 26 Jan 2015 07:38:09 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621521A8BC0 for ; Mon, 26 Jan 2015 07:38:09 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kWFb14QJLzCFF; Mon, 26 Jan 2015 16:38:05 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=ohfXXXnL; dkim-adsp=pass 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 gkW9BgK_uUXW; Mon, 26 Jan 2015 16:38:03 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 26 Jan 2015 16:38:03 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B2CCB80040; Mon, 26 Jan 2015 10:37:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1422286679; bh=e3UFM3TJHFl8mKqh9e2fktccuuqQjO40OTcRmyxY2LM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ohfXXXnLF7xkWQVhyV616FzEaN6UUXZjdsrezsTzXEpIAoJxA32swI0b5zQX6nEVA QprP2FMMHf4EpGnXNHFjLBJHqxS+vPkxm+VjAITdf4hj59y86vexxtHmmxCvF3nFdU gpGZn4VAJOMqOhCbpdb3vDIkdHVi8+z45c78y2a8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0QFbw5Z027627; Mon, 26 Jan 2015 10:37:58 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 26 Jan 2015 10:37:58 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21702.20921.799010.19985@fireball.kivinen.iki.fi> Message-ID: References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <21702.20921.799010.19985@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My comments to the Null Authentication Method draft 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, 26 Jan 2015 15:38:13 -0000 On Mon, 26 Jan 2015, Tero Kivinen wrote: > I was not commenting about the "when authenticated IKE sessions are > not possible" (== with VPN we do have authenticated IKE sessions, so > it is clear it overrides the un-authenticated IKE sessions). I was > commeting on the second requirement, i.e. that "only alternative would > be to send plaintext". > > I think that requirement is too strict. I.e. I think we should be able > to use un-authenticated IKE sessions even when when we are using > 40-bit WEP on the link. With your text we cannot, as Un-authenticated > IKE sessions MUST only be attemtpetd when the ... only alternative > would be to send plaintext. 40-bit WEP is not plaintext, thus we > cannot use un-authenticated IKE... I think the text clearly does not refer to the underlying smoke signals or avian carriers. plaintext clearly refers to "not encrypted by IKE/IPsec". > We can only provide false sense of security if we somehow show this to > user. For example in tcpinc the general consensus seems to be that > users should never see if tcpinc is on or off, thus we cannot give > false sense of security. Same thing here. If you do consider > un-authenticated IKE as plaintext, you cannot give false sense of > security. If you only put "lock" on when you actually do authenticated > IKE then there is no problem. I would like to remain completely outside the realm of GUI and The User. For example, OTR has a state "unverified" to indicate encryption without authentication. I do not wish this document to forbid that. > The reason why you want to use un-authenticated connections sometimes, > might be when the authentication is annoying, for example when using > securID or similar interactive method. So you want to use AUTH_NULL to bypass the administrative policies ? :) > You seem to have very limited use case for this thing, and I would > like to see much wider user case, i.e. actually going to similar use > cases than tcpinc has, but not restricted on the tcp layer, but also > working with udp and other protocols. I believe you are needlessly trying to complicate a very simple concept. How about I rephrase the original: Un-authenticated IKE sessions MUST only attempted when authenticated IKE sessions are not possible for the remote host and the only alternative would be to send plaintext. to: Un-authenticated IKE sessions MUST only be attempted when authenticated IKE sessions are not possible for the remote host and the only alternative would be to not us IKE at all. And actually, now I feel I need to clarify this further to allow properly for servers preferring anonymous IKE clients: An IKE initiator that wishes to use NULL Authentication for itself SHOULD attempt to authenticate its IKE peer. An IKE responder MAY allow its peer to remain un-authenticated but SHOULD attempt to establish an IKE session where it can be authenticated by the IKE initiator. A mutually un-authenticated IKE session should only be used if the alternative is to not use IKE at all. >> You are right it might not compromise it, but it also might. For >> instance your phone switching between LTE and Wifi while using the >> same "random ID". > > So you should say that not using ID_NULL might compromise the client > anonymity, not that it will compromise it. We do say that earlier in the document: Furthermore, sending a traditional ID field might unwittingly compromise the anonimity of the peer. But in the security section we say: Using an ID Type other than ID_NULL with the NULL Authentication Method compromises the client's anonimity. (spelling fixed in -03) So I agree this is a little conflicting. Note that there are two cases here to consider: 1) the anonymity of the client to the server 2) the anonymity of the client to an active MITM atacker So perhaps we can rewrite the security section item to: Using an ID Type other than ID_NULL with the NULL Authentication Method can compromise the client's anonimity in case of an active MITM attack [and should be avoided]. >> If you can track to user, so can active attackers doing MITM. That's >> the problem. > > Yes, it might be problem in some cases, but not all use cases for the > null require anonymity. Actually almost all of the uses I have in > mind do not. The -03 version has this relaxed. Although from reading your emails, you are doing _exactly_ what I think we should urge implementors not to do. Making decisions based on a completely falsifiable piece of information. >>> devices using same resource (i.e. moving video stream from your mobile >>> phone to your laptop by just connecting from your laptop and creating >>> new Child SA with same traffic selectors and disconnecting your mobile >>> phone, so all traffic will now go to the laptop (which have requested >>> same internal address associated with the user from the server). >> >> First of all, if you crashed there is nothing anyone can do. There is no >> way to tell you apart from another new connection. Unless you abuse the >> random ID and store it across reboots which is _really_ putting in too >> much trust, because now I can obtain/hack/reverse engineer your random >> ID to actually obtain your encrypted IP streams. I really don't want to >> go there. > > Your use cases are more restrictive than mine. I can see uses cases > where that is useful, especially when we are talking about anonymous > opportunistic uses. > > I mean if there is no authentication, the video stream does not have > any secret information in it. I mean yes, you could steal someones > youtube stream that way (again not talking about specially youtube, as > it uses http, but similar kind of service or class of services), but > what is the gain. You could have started looking at the same cat-video > yourself. The cat video is fine. Unfortunately your software used a persistent random_id when you watched that Snowden documentory afterwards.... > In some use cases there might be some information that might be leaked > out if for example the great firewall of country x suspects someone is > looking unsafe cat-videos, and would want to verify that by stealing > users connection, but it might be easier to just do that from the > start... How or when they attempt to does not matter. What matters is that you are not using an identifiable marker to put a target on your back. > For normal user the conveniency of being able to move things around is > more important than the fact that someone might steal his cat-videos. And for some users having encrypted chats be logged to disk automatically is more convenient than for others, such as a whistleblower that is now sitting in jail because of that. I'm sorry, but in my opinion that use case trumps your cat videos. >> Second, if you want to move your video stream from your phone to your >> laptop, explain to me how I cannot abuse that mechanism to streal your >> phone's videostream to _my_ laptop? > > If it is un-authenticated, there is nothing restricting that. That is > what null authentication is all about. If it is not anonymous, but > uses some kind of random IDs or pseudonyms, you need first break my > random ID before you can do that, so it adds more protection. I don't need to break it! I can just MITM you and you will give it to me. You will just hit reload and now you have your cats and I have your random identity. >> The only way I can think of is if your securely transfer your >> "random ID" from one device to the other, meaning it is easier >> really easy for you to type in, or you are using an authenticated >> connection between your laptop and phone, in which case you should >> just transfer the entire IKE and IPsec state without needing a >> protocol change here. > > Or the random id might be derived from my long lived secret I already > have in all those devices, and the current date / time. how long to you want to be able to switch between laptop and phone? Watching 45 minutes of cat video's? Your random id has to be valid for more then just 1 minute if you want to pass that along. The longer you keep it using the same ID the worse things get. Again, your abuse of the unverifiable but tracable ID is EXACTLY why the RFC should limit its use to "logging only" and "debugging only" and it should STRONGLY recommend only using ID_NONE. As for your cat video hand-over, how about handing over the reference pointer of the video stream instead between devices :P > Having applications being able to move the IKE and IPsec state over is > bit more challenging than sending information about to where to > connect and what ID to use... For example I think chrome-browser now > have this feature where you can say that move this stream of video > from this screen to some other screen logged in as same user. Then the > link to url will go through the cloud service provided by the > application and is protected by that application. The url could > include your random ID or something. Use authenticated IKE...... >> Also, your "random ID" is beginning to look a lot like a kerberos token :P > > Not really, as that would be authenticated token. In this case it > would simply be random pseudonym of me, which I could share between > few devices, and which I might change at will without telling anybody. Create ID_PSEUDONYM. >>> Section 3.4 should most likely also mention RFC5739 as it allows >>> assigning full /64 address block to client, and with that you might >>> use wider traffic selectors. I think we need separate section for the >>> traffic selectors. Now some of that is in the section 3.3 (not >>> replacing IPsec SA), and some are in 3.4. The title of "Network >>> topology changes" does not really describe the problem with traffic >>> selectors. Moving all text related to it to separate subsection might >>> make things easier. >> >> Sure, once we reach agreement of what can/should/must not be done with >> traffic selectors. > > Yes, that is big part missing from the draft. Yes, that's still a little bit of a problem in the -03 draft too. Another case of allowing many cool things versus the security risk and interop problems. >>> and also perhaps talk about per flow SAs etc. >> >> I still have not understood a valid use case for this, let alone one >> that justifies the potential negative effects allowing multiple IPsec >> SA's gives. > > What are negative effects there are? If you do not have resources, > then do not allow. That is what policies are for. If you have > resources for it, and the policy allows it, go for it. More features lead to more interop problems. More negotiation mismatches leads to more negotiation packets which lead to delays in IKE and IPsec SAs and everything needs to carry. We also have no way currently in the IPSECKEY record of advertising "only request encryption foo strength for address bar port baz". So it will just lead to a lot of useless CREATE_CHILD_SA requests failing. Allowing it when you have the resources for the additional SAs will just lead to attackers filling up your memory and now you are always running at scarce resources for real clients and real clients cannot request port specific SAs anymore and have to default to the full host-host SA anyway. You're just wasting resources with the same endresult. > I do not see reason why we should restrict it out here. That has been the problem with IKE/IPsec :P A swiss army knife to cut yourself with :P Paul From nobody Mon Jan 26 07:56:18 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 15C551A89A8 for ; Mon, 26 Jan 2015 07:56:12 -0800 (PST) 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 NevrnPUvVjjh for ; Mon, 26 Jan 2015 07:56:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5181A9126 for ; Mon, 26 Jan 2015 07:56:05 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kWFzl1WYfzCFF; Mon, 26 Jan 2015 16:56:03 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=jaHLoi55; dkim-adsp=pass 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 F1PMQ-l0KVdv; Mon, 26 Jan 2015 16:56:02 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 26 Jan 2015 16:56:02 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 799D08008E; Mon, 26 Jan 2015 10:55:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1422287759; bh=jzOxFqld1jC6MlncESrRb/OTKIV6vaC/LGs4DiKq/yo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jaHLoi55Qm72O56+ECT4nJeX1MhlDIZt0pFfWuc62pPaNrd+j3GmrIN6dnVdMmhu0 sI/EV9MeV9n05Se2r7HIJ+64D5dtioeWqh1M2rsexCgAtuPJn9xARctebVATdYk/pz JYFPslvbR89Y04NMQxJNcVoYfcGGrcPjyinwCMrw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0QFtws6013525; Mon, 26 Jan 2015 10:55:58 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 26 Jan 2015 10:55:58 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21702.23584.557958.684640@fireball.kivinen.iki.fi> Message-ID: References: <038B7179C6EB4C5BB2A110AD37541204@buildpc> <21694.26453.977101.952972@fireball.kivinen.iki.fi> <21702.23584.557958.684640@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd) 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, 26 Jan 2015 15:56:12 -0000 On Mon, 26 Jan 2015, Tero Kivinen wrote: > For the same reason IKE users who already do Diffie-Hellman during the > IEK SA creation, might want to do separate PFS for different Child > SAs, just to make things harder for attacker. Again as we are talking > about un-authenticated connections, NSA can just do MitM in the > beginning, and gain all traffic, but that is active attack, which > might get detected. Doing passive storing of the all traffic and then > breaking Diffie-Hellman later provides better ways of staying > undetected for them. But you are most likely initiating IKE because you were trying to send one kind of protocol/port, so most likely you will end up with one SA. If you do this for every port 80 connection that closes, and build up new SA's for each random source port you use, then you're just causing your user unneccessary delays while they are waiting on CREATE_CHILD_SA exchanges. It is much better for the user to get one proper IPsec SA in. If you are concerned about passive offline breakability, bump your modp group to modp8192. > If we do one 1024-bit Diffie-Hellman using un-authenticated exchange, > then they can break that one 1024-bit Diffie-Hellman and get all > traffic protected by each Child SA. If we do PFS for each Child SA > then they need first to break the IKE SA Diffie-Helman and then for > each traffic flow second one... It's better to make everything unbreakable by a higher modp group than to hope that only part of your traffic got broken :P > There are people who want this kind of feature. Yes and people want to use different modp groups for IKE and IPsec SA, and different PRFs from INTEGs, and different size GCM/CCM tags and different SHA2 length. Those were all useless knobs we should have never created. > Thats why this draft > should not have any text restricting per-flow SAs... I still have not seen a single valid use case for this. I do have described how this feature would cause issues during active attacks. > It might have comment saying that because clients are > un-authenticated, there might be need for tighter resource limits than > for authenticated clients. And this new swiss army knife has the auto-rotating circular hack saw. Please only use responsibly. >> It will only cause interop failures. The client will not pick a >> host-to-host but picks say port 80 only. Then it wants port 443 and >> gets NO_ADDITIONAL_SAS. Then it needs to drop the port 80 SA and >> restart everything to get the full range single SA. > > Why should that cause interop failures? This is all standard RFC7296 > stuff already. We are not changing anything here related to this. Yes. Nothing should ever cause interop failures if everyone followed the RFCs properly :P Welcome to the real world Neo :) >> If you are not authenticated, what is the point in splitting up the >> traffic in different IPsec SA's per protocol or port? > > Causing more work for the passive monitoring people breaking your > multiple 1024-bit Diffie-Hellmans, instead of just breaking one. That modp1024 is too weak! Use modp8192. That's much safer. What's your next use case? > And > you might use shorter Diffe-Hellman groups for performance reasons > than with authneticated use cases. So 200 PFS CREATE_CHILD_SA requestions of 1024 is less resources than 1 modp8192 initial exchange? >> The only use case I have heard of that could apply, is the use case >> of being mandated to NOT encrypt something for auditing purposes. But >> traffic selectors really suck for "everything but sip and smtp and pop >> and imap" :P > > Yes, usually traffic selectors are either per IP, or per-flow. > Anything else are usually just silly... And for most normal > authenticated use cases per-flow SAs are not really that useful, but > we still have them in RFC7296, and I do not see any reason why they > should be removed in this document. We are talking about two things here: 1) IP ranges 2) protocol and port ranges 1) is dangerous because unauthenticated peers cannot be trusted to make any claims about IPs that are not themselves. 2) we discussed in the previous email and above here :P Paul From nobody Mon Jan 26 08:17:32 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 EF0B11A8BC5 for ; Mon, 26 Jan 2015 08:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9wFvCDUVIZR for ; Mon, 26 Jan 2015 08:17:28 -0800 (PST) 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 CC7F11A8A93 for ; Mon, 26 Jan 2015 08:17:28 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0QGHR4Z073381 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Jan 2015 09:17:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jan 2015 08:17:27 -0800 References: <20150126152609.24327.45673.idtracker@ietfa.amsl.com> To: IPsecME WG Message-Id: <2006BFC8-F9BE-47E4-8E13-816F04354079@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [IPsec] Fwd: Last Call: (IKEv2-based Shared Secret Key for O/TWAMP) to Proposed Standard 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, 26 Jan 2015 16:17:30 -0000 Some folks here might be interested in this draft, now in IETF Last = Call. Do *not* send comments to the IPsecME mailing list; instead, = follow the instructions in the last call below. --Paul Hoffman > The IESG has received a request from the IP Performance Metrics WG = (ippm) > to consider the following document: > - 'IKEv2-based Shared Secret Key for O/TWAMP' > as Proposed Standard >=20 > 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-02-09. 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. >=20 > Abstract >=20 >=20 > The O/TWAMP security mechanism requires that both the client and > server endpoints possess a shared secret. Since the currently- > standardized O/TWAMP security mechanism only supports a pre-shared > key mode, large scale deployment of O/TWAMP is hindered > significantly. At the same time, recent trends point to wider IKEv2 > deployment which, in turn, calls for mechanisms and methods that > enable tunnel end-users, as well as operators, to measure one-way = and > two- way network performance in a standardized manner. This = document > describes the use of keys derived from an IKEv2 SA as the shared key > in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ > TWAMP can support certificate-based key exchange, which would allow > for more operational flexibility and efficiency. The key derivation > presented in this document can also facilitate automatic key > management. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From nobody Mon Jan 26 09:11: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 0C29A1A7D84 for ; Mon, 26 Jan 2015 09:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c7uorittTQ6 for ; Mon, 26 Jan 2015 09:11:38 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE281A7022 for ; Mon, 26 Jan 2015 09:11:38 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id fb4so11504008wid.2 for ; Mon, 26 Jan 2015 09:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=10g4kxSjqThophdqNzfYPlLDcnGJ40lRYxW8sIiH2L8=; b=e2CmgrrlyQxeKDFYYMZcXhdJIWLbgZczkK/SpmAwliHV61wpoQ041vFHQnG3gn6v38 gWg+1I/tPGCggYL3SQtnC6Js6zBrmAUoL6gvpdFDuz5fDSA207tcNMzn3atDdKAydSYp rNQB9Cj54JkbLDbCLqjyuJxUvopt8F044EUq0sQNm5/AvU9mmyJ2fCaFzUdWSnXx41Sv ADlQ1fa5F/jJPCRL1aiLfRiiGUP1YcrQhN5qrr0v5lt4oWNACCxzfE28ZQJ+gRaehKNM CdxSLq/fdlC7L1KmGSot6/z434K+muOV7oB2b8Fc9fQgJ4gTNA1QSh9SABOO4ePAtgB4 IiAQ== X-Received: by 10.180.20.177 with SMTP id o17mr24819596wie.64.1422292296727; Mon, 26 Jan 2015 09:11:36 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.12.156.169]) by mx.google.com with ESMTPSA id lq5sm15100266wjb.35.2015.01.26.09.11.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Jan 2015 09:11:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <21702.23584.557958.684640@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2015 19:11:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <038B7179C6EB4C5BB2A110AD37541204@buildpc> <21694.26453.977101.952972@fireball.kivinen.iki.fi> <21702.23584.557958.684640@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1993) Archived-At: Cc: IPsecME WG , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd) 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, 26 Jan 2015 17:11:40 -0000 > On Jan 26, 2015, at 5:24 PM, Tero Kivinen wrote: >=20 > Paul Wouters writes: >>>> I think it is a server's policy issue. It can always restrict >>>> the number of IPsec SAs from a single peer >>>> by using NO_ADDITIONAL_SAS notification. >>>> The document should not impose any restrictions here, IMHO. >>>=20 >>> Agree. Implementations might also have different limits depending >>> whether the other end is authenticated or unauthenticated, i.e. >>> unauthenticated clients might only be able to create for example 10 >>> Child SAs, and authenticated clients can create 1000 Child SAs... = And >>> btw child SAs are quite cheap, so the limit does not need to be 1 = and >>> 3... :) >>=20 >> But what's the point? Just to protect th per-port IPsec SA's with >> more PFS in CREATE_CHILD_SA ? >=20 > For some reason people wnat to turn on PFS on TLS, so that NSA cannot > break all the http-connections by just stealing that one key from the > server. This is an unfortunate naming issue. PFS in IKE vs PFS in TLS are very = different beasts. PFS in TLS is for protecting against a future compromise of the = long-term private key associated with the server certificate. RSA keying = protects the pre-master secret with the public key, requiring only the = private key to decipher. So a future compromise of the (long-term) = private key allows the attacker to decrypt your connection (very useful = for debugging in wireshark) PFS in IKE protects you against a future compromise of the ephemeral = SK_d. Unlike the certificate private key, SK_d is generated during IKE, = and is deleted at the expiration of the IKE SA. For a software-only = implementation there is no reason to believe that the SK_d is any easier = to steal than the traffic keys. Configurations tend to give IKE SAs a = longer lifetime than the child SAs, but that is not required by the = protocol. PFS in TLS makes enough sense that UTA is recommending it for all TLS = connections and the TLS working group is requiring it for the next = version of TLS. The thing that this group calls PFS is far less = important, and doesn=E2=80=99t always justify the cost. Yoav From nobody Mon Jan 26 09:21:48 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 B8A571A70FE for ; Mon, 26 Jan 2015 09:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vOkmAAz1cilu for ; Mon, 26 Jan 2015 09:21:39 -0800 (PST) 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 6FA871A1F20 for ; Mon, 26 Jan 2015 09:21:38 -0800 (PST) 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 t0QHLYVD002439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jan 2015 19:21:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0QHLYYp019303; Mon, 26 Jan 2015 19:21:34 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21702.30622.341411.862146@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2015 19:21:34 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <21702.20921.799010.19985@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 32 min X-Total-Time: 32 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My comments to the Null Authentication Method draft 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, 26 Jan 2015 17:21:44 -0000 Paul Wouters writes: > > I think that requirement is too strict. I.e. I think we should be able > > to use un-authenticated IKE sessions even when when we are using > > 40-bit WEP on the link. With your text we cannot, as Un-authenticated > > IKE sessions MUST only be attemtpetd when the ... only alternative > > would be to send plaintext. 40-bit WEP is not plaintext, thus we > > cannot use un-authenticated IKE... > > I think the text clearly does not refer to the underlying smoke signals or > avian carriers. plaintext clearly refers to "not encrypted by IKE/IPsec". If you mean that you should say so. I think not everybody think https as plaintext for example, but you seem to consider it so. > > We can only provide false sense of security if we somehow show this to > > user. For example in tcpinc the general consensus seems to be that > > users should never see if tcpinc is on or off, thus we cannot give > > false sense of security. Same thing here. If you do consider > > un-authenticated IKE as plaintext, you cannot give false sense of > > security. If you only put "lock" on when you actually do authenticated > > IKE then there is no problem. > > I would like to remain completely outside the realm of GUI and The User. > For example, OTR has a state "unverified" to indicate encryption without > authentication. I do not wish this document to forbid that. Agree, but you started talking about false sense of security, which is only possible if you have gui that leaks that information to user. > > The reason why you want to use un-authenticated connections sometimes, > > might be when the authentication is annoying, for example when using > > securID or similar interactive method. > > So you want to use AUTH_NULL to bypass the administrative policies ? :) No. I want to express adminstrative policy which only requires authentication in those operations actually needing it. You want to enforce the policy by the protocol, and I do not think that is good thing to do. > > You seem to have very limited use case for this thing, and I would > > like to see much wider user case, i.e. actually going to similar use > > cases than tcpinc has, but not restricted on the tcp layer, but also > > working with udp and other protocols. > > I believe you are needlessly trying to complicate a very simple concept. Actually you are restricting it, I want it to be open for all possible use cases... > How about I rephrase the original: > > Un-authenticated IKE > sessions MUST only attempted when authenticated IKE sessions are not > possible for the remote host and the only alternative would be to > send plaintext. > > to: > > Un-authenticated IKE > sessions MUST only be attempted when authenticated IKE sessions are not > possible for the remote host and the only alternative would be to > not us IKE at all. No, as I have already pointed out, I actally do want to use mixed authenticated and un-authenticated IKE if such thing is ALLOWED by the policy. I do not want it to be restricted at all on the protocol level. > And actually, now I feel I need to clarify this further to allow > properly for servers preferring anonymous IKE clients: > > An IKE initiator that wishes to use NULL Authentication for itself > SHOULD attempt to authenticate its IKE peer. An IKE responder MAY > allow its peer to remain un-authenticated but SHOULD attempt to > establish an IKE session where it can be authenticated by the IKE > initiator. A mutually un-authenticated IKE session should only be > used if the alternative is to not use IKE at all. Again I would rather say that all that is dictated by the policy, not by SHOULDs etc in the RFC. > >> You are right it might not compromise it, but it also might. For > >> instance your phone switching between LTE and Wifi while using the > >> same "random ID". > > > > So you should say that not using ID_NULL might compromise the client > > anonymity, not that it will compromise it. > > We do say that earlier in the document: > > Furthermore, sending a traditional ID field might > unwittingly compromise the anonimity of the peer. > > But in the security section we say: > > Using an ID Type other than ID_NULL with the NULL Authentication > Method compromises the client's anonimity. > > (spelling fixed in -03) > > So I agree this is a little conflicting. Note that there are two cases > here to consider: > > 1) the anonymity of the client to the server > 2) the anonymity of the client to an active MITM atacker > > So perhaps we can rewrite the security section item to: > > Using an ID Type other than ID_NULL with the NULL Authentication > Method can compromise the client's anonimity in case of an active > MITM attack [and should be avoided]. There is nothing that restricts null authentication to anonymous uses. It seems you are again thinking more about the opportunistic use case than the null authentication. I would suggest chaning can to may and removing the stuff at the end: Using an ID Type other than ID_NULL with the NULL Authentication Method may compromise the client's anonimity in case of an active MITM attack. > > Yes, it might be problem in some cases, but not all use cases for the > > null require anonymity. Actually almost all of the uses I have in > > mind do not. > > The -03 version has this relaxed. Although from reading your emails, you > are doing _exactly_ what I think we should urge implementors not to do. > Making decisions based on a completely falsifiable piece of information. Yes, and I would still like to do so in the future. All these emails I have been replying to are based on the emails which are completely falsifiable, and I think it is fine for me to continue assuming that they are proper unless someone points out otherwise. Similar usecases are possible in the IKE. > > Your use cases are more restrictive than mine. I can see uses cases > > where that is useful, especially when we are talking about anonymous > > opportunistic uses. > > > > I mean if there is no authentication, the video stream does not have > > any secret information in it. I mean yes, you could steal someones > > youtube stream that way (again not talking about specially youtube, as > > it uses http, but similar kind of service or class of services), but > > what is the gain. You could have started looking at the same cat-video > > yourself. > > The cat video is fine. Unfortunately your software used a persistent > random_id when you watched that Snowden documentory afterwards.... In wihch case then I would want to do something to hide that information, i.e. use tor or something else. Changing my ID does not help at all as my IP would still be stable, so what is the benefits for me of using ID_NULL all the time? > > In some use cases there might be some information that might be leaked > > out if for example the great firewall of country x suspects someone is > > looking unsafe cat-videos, and would want to verify that by stealing > > users connection, but it might be easier to just do that from the > > start... > > How or when they attempt to does not matter. What matters is that you > are not using an identifiable marker to put a target on your back. Unfortunately there is already IP-address which are already tied down to my name... If I want to hide myself from the network I need to use tor or similar, just using un-authenticated IKE connection using ID_NULL does not help me at all. > > For normal user the conveniency of being able to move things around is > > more important than the fact that someone might steal his cat-videos. > > And for some users having encrypted chats be logged to disk automatically > is more convenient than for others, such as a whistleblower that is now > sitting in jail because of that. I'm sorry, but in my opinion that use > case trumps your cat videos. So you want to provide false sense of security for that 0.0000001% of user base who are whistleblowers, and cause annoyance for the rest of the users? And as I pointed out claiming that un-authenticated IKE is safe for whistleblowers to use is really creating false sense of security. > Again, your abuse of the unverifiable but tracable ID is EXACTLY why > the RFC should limit its use to "logging only" and "debugging only" > and it should STRONGLY recommend only using ID_NONE. You seem to think this is "Anonymous Authentication mode in IKE"? It is un-authenticated authentication method. There is nothing there that requires anonymity for NULL authentication to be useful. None of the use cases described in the introduction require anonymity. Actually in use case 1 the user might want to use non-anonymous un-authenticated connections. In use case 2 the sensor does not really care what identity server provides, and as server by definition has fixed IP-address there is no anonymity there at all anyways. for the 3rd use cases there is word "anonymous" added there, which should not be there. To protect against pervasive monitoring does not need to provide anonymity. I would actually change the last sentence of the use case 3 to say "This case might use a fully anonymous un-authenticated key exchange.". I agree there might be use cases for anonymous uses for the NULL authentication, but I do not think all use cases are anonymous. Because of that I think it is good idea to define ID_NULL that can be used if anonymity is needed, but I do not see any reason why NULL authentication should only use it. > >> Sure, once we reach agreement of what can/should/must not be done with > >> traffic selectors. > > > > Yes, that is big part missing from the draft. > > Yes, that's still a little bit of a problem in the -03 draft too. > Another case of allowing many cool things versus the security risk > and interop problems. Which is why I think this draft should not say that much about it, but most of the stuff should be put to the opportunistics use case draft. > We also have no way currently in the IPSECKEY record of advertising > "only request encryption foo strength for address bar port baz". So > it will just lead to a lot of useless CREATE_CHILD_SA requests failing. You do not need to use the per flow SAs if you do not like. You might also say that in your opportunistic IPsec those are forbidden. Other people might have other uses for null authentication than your opportunistic IPsec... > Allowing it when you have the resources for the additional SAs will just > lead to attackers filling up your memory and now you are always running > at scarce resources for real clients and real clients cannot request > port specific SAs anymore and have to default to the full host-host SA > anyway. You're just wasting resources with the same endresult. For attackers it is about as hard to create 10000 IKE SAs each having one Child SA, than creating 1000 IKE SAs each having 10 Child SAs. So if you put Child SA limit too low, attackers will create more IKE SAs and vice versa. > > I do not see reason why we should restrict it out here. > > That has been the problem with IKE/IPsec :P A swiss army knife to cut > yourself with :P Hah, you have not seen swiss army knife of protocol before you start reading IEEE 802.15.4... Nothing is fixed there, everything is left open for implementors or next higher layer to solve. IKE is so simple and does not even have any options compared to it (or 802.11 too I think)... Anyways we are talking about generic protocol concept here, not some specific use case. Opportunistic IPsec should restrict all kind of things, this NULL authentication should allow policy to allow different things. If you do not want to implement such policy or such RFC specifying such policy, you do not need. -- kivinen@iki.fi From nobody Mon Jan 26 23:21:21 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 DB9711B2BA8 for ; Mon, 26 Jan 2015 23:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reYCaPaF27NR for ; Mon, 26 Jan 2015 23:21:13 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC011B2AE3 for ; Mon, 26 Jan 2015 23:21:13 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so11603039lbv.3 for ; Mon, 26 Jan 2015 23:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=CFzLI3sdFq3V+yPfQ+vec219qwT93nkzzgw6t3CtH1I=; b=XTmRP/hPqCGxHItE1TivTAxn9sPYmXk9e7fw1Z/Hw0q0D2vCeR/2FOz2G4G74amvTv ME/lc/TnszvF5fh7+aztR2kS3OVl9G74fEbI/6pRsUI5t+txbB+BELCC0XtkYPQi1oal w0xhjgFEsdEccuFsai1f4XYtKP5QlLm2u2a1NBKTfGJMoebAIz80hfKTVyF2061Bxsc9 wXqExJCMYmJhn8xl49wqMTD7iM7SfxXF2ZdtZ78L8OfVWRuclOYt5EowHlaKPo7xhq/x c9m5wF0CfW/eMBewWV2YSAcDQOOMQiizS1oPbbzVBlaZA3rVfa2+s779zblH1DmL/WNk HKxw== X-Received: by 10.112.199.39 with SMTP id jh7mr2397534lbc.46.1422343271567; Mon, 26 Jan 2015 23:21:11 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id dx2sm138081lbc.49.2015.01.26.23.21.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Jan 2015 23:21:10 -0800 (PST) Message-ID: <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <21693.10207.704401.394139@fireball.kivinen.iki.fi><42287653737F4C17925AAF23F337AAD3@buildpc> <21702.22413.999704.762826@fireball.kivinen.iki.fi> Date: Tue, 27 Jan 2015 10:21: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: Cc: ipsec@ietf.org Subject: [IPsec] Initiator Identity in case of EAP (was: My comments to the Null Authentication Method draft) 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, 27 Jan 2015 07:21:15 -0000 I changed a subject field. > Valery Smyslov writes: >> Hi Tero, >> >> > On the other hand same section says that ID_NULL SHOULD only be used >> > with NULL authentication method. In which scenarios do you think >> > ID_NULL can be used when using normal authentication? I.e. which is >> > the exception for the SHOULD? >> >> It could be used, for example, in the first IKE_AUTH message sent from >> the client when EAP authentication is requested. If SGW is acting >> as pass-through between client and backend authentication server >> (e.g. RADIUS), that server will typically start EAP session from >> requesting EAP Identity anyway, so the ID Payload received >> from the client becomes useless. > > Nope. The IKE ID payloads needs to be used, and the EAP identity > reqeuest and respond SHOULD NOT be used (from RFC7296 section 3.16): > > Note that since IKE passes an indication of initiator identity in the > first message in the IKE_AUTH exchange, the responder SHOULD NOT send > EAP Identity requests. The initiator MAY, however, respond to such > requests if it receives them. First, "SHOULD NOT" is not equal to "MUST NOT". It is fully legal for NAS to sent EAP Identity request and not use IKE Identity. Then, many modern EAP methods (like EAP-TLS) have their own means to exchange Identities within the method, and in this case the initial IKE Identity becomes almost useless. What about the sentence "The initiator MAY, however, respond to such requests if it receives them.", - I think that it is a mistake and the sentence must not be in the RFC. It tries to mandates EAP behaviour within IKEv2 spec. Moreover, it contradicts to the EAP specification (RFC3748), which states (Section 5.1): The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there is an expectation of interaction with a user. A Response of Type 1 (Identity) SHOULD be sent in Response to a Request with a Type of 1 (Identity). It is clear that SHOULD is not equal to MAY. It's unfortunate we didn't cach this contradiction while preparing RFC7296. > Also section 2.16 warns that if EAP Identity is used, there might be > mismatch with the ID payloads, and correct one needs to be used for > policy lookups: > > When the initiator authentication uses EAP, it is possible that the > contents of the IDi payload is used only for Authentication, > Authorization, and Accounting (AAA) routing purposes and selecting > which EAP method to use. This value may be different from the > identity authenticated by the EAP method. It is important that > policy lookups and access control decisions use the actual > authenticated identity. Often the EAP server is implemented in a > separate AAA server that communicates with the IKEv2 responder. In > this case, the authenticated identity, if different from that in the > IDi payload, has to be sent from the AAA server to the IKEv2 > responder. This para only supports my idea, that initiator's identity IDi in case of EAP plays no important role. It's sole purpose is for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting which EAP method to use. And it may be ID_NULL, in which case the default AAA server will be selected and EAP method will be negotiated within EAP (in most natural way). Regards, Valery. From nobody Tue Jan 27 03:08: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 0B06B1A876C for ; Tue, 27 Jan 2015 03:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TpYjn_af7kaD for ; Tue, 27 Jan 2015 03:08:27 -0800 (PST) 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 720E61A8762 for ; Tue, 27 Jan 2015 03:08:26 -0800 (PST) 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 t0RB8JmK025390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Jan 2015 13:08:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0RB8J2D025627; Tue, 27 Jan 2015 13:08:19 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21703.29091.361637.504704@fireball.kivinen.iki.fi> Date: Tue, 27 Jan 2015 13:08:19 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <42287653737F4C17925AAF23F337AAD3@buildpc> <21702.22413.999704.762826@fireball.kivinen.iki.fi> <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 19 min Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] Initiator Identity in case of EAP (was: My comments to the Null Authentication Method draft) 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, 27 Jan 2015 11:08:31 -0000 Valery Smyslov writes: > > Nope. The IKE ID payloads needs to be used, and the EAP identity > > reqeuest and respond SHOULD NOT be used (from RFC7296 section 3.16): > > > > Note that since IKE passes an indication of initiator identity in the > > first message in the IKE_AUTH exchange, the responder SHOULD NOT send > > EAP Identity requests. The initiator MAY, however, respond to such > > requests if it receives them. > > First, "SHOULD NOT" is not equal to "MUST NOT". Yes, as I pointed out in my reply. > It is fully legal for NAS to sent EAP Identity request and > not use IKE Identity. Then, many modern EAP methods > (like EAP-TLS) have their own means to exchange Identities > within the method, and in this case the initial IKE Identity becomes > almost useless. And for some EAP libraries getting rid of the EAP Identity request/reply is almost impossible. That is the reason there is SHOULD NOT vs MUST NOT. > What about the sentence "The initiator MAY, however, > respond to such requests if it receives them.", - I think that > it is a mistake and the sentence must not be in the RFC. > It tries to mandates EAP behaviour within IKEv2 spec. No it does not try to specify what EAP does, it specifis what IKEv2 does. I.e. initiator MAY respond to such query, or abort the whole negotiation, as the other end is not following the SHOULD NOT specified in the IKEv2 specification. If the initiator is not able to extract the identities from the EAP messages, it really should abort the negotiation, as this would mean that different identity is used for policy decision (the one in ID payload), and different one is used for authentication (the one inside EAP). If implementation does not have ability to verify those two match (with suitable definition of match, i.e. it might use mapping table etc to map EAP identity to identity to be used in the policy checking) it should abort the exchange. > Moreover, it contradicts to the EAP specification (RFC3748), > which states (Section 5.1): > > The Identity Type is used to query the identity of the peer. > Generally, the authenticator will issue this as the initial > Request. An optional displayable message MAY be included to > prompt the peer in the case where there is an expectation of > interaction with a user. A Response of Type 1 (Identity) SHOULD > be sent in Response to a Request with a Type of 1 (Identity). > > It is clear that SHOULD is not equal to MAY. It's unfortunate > we didn't cach this contradiction while preparing RFC7296. They do not need to be equal. They are talking about different things. EAP talks what EAP SHOULD do. IKEv2 talks what IKEv2 MAY do in that case. IKEv2 could also say MUST NOT respond, and that would still be ok. Actually as EAP only says SHOULD not MUST, it is actually valid for the IKEv2 implementation to continue exchange and not respond to identity request, but I would expect most EAP methods would fail in that case. Or IKEv2 might take the ID payload and use that to construct the EAP Identity response. > > Also section 2.16 warns that if EAP Identity is used, there might be > > mismatch with the ID payloads, and correct one needs to be used for > > policy lookups: > > > > When the initiator authentication uses EAP, it is possible that the > > contents of the IDi payload is used only for Authentication, > > Authorization, and Accounting (AAA) routing purposes and selecting > > which EAP method to use. This value may be different from the > > identity authenticated by the EAP method. It is important that > > policy lookups and access control decisions use the actual > > authenticated identity. Often the EAP server is implemented in a > > separate AAA server that communicates with the IKEv2 responder. In > > this case, the authenticated identity, if different from that in the > > IDi payload, has to be sent from the AAA server to the IKEv2 > > responder. > > This para only supports my idea, that initiator's identity IDi in case > of EAP plays no important role. It's sole purpose is for Authentication, > Authorization, and Accounting (AAA) routing purposes and selecting > which EAP method to use. And it may be ID_NULL, in which case > the default AAA server will be selected and EAP method will be negotiated > within EAP (in most natural way). ID payload is the one which is used to do policy lookups in the PAD, and the PAD is linked to the SPD, which specifies what kind of Child SAs can be specified. Because of this the ID is the really important also in the EAP case. The text above in the RFC7296 is there because some implementations uses ID payloads which do not follow this rule, and because of this special code is needed to make sure that the correct PAD entry is located using the authenticated identity, and that might be the EAP identity instead of ID payload. In normal case the authenticated identity is ID payload, in some special EAP cases it might be EAP identity. The implementation needs to be able to handle this special case if it wants to support such implementations, but it is ok acceptable for it to ignore this case, and use ID payload for all policy lookups, and forbid EAP identity exchanges completely. Usually this is not a problem as EAP identity requests are done by the server, which is also tied to the AAA-server, and server implementation will know whether it supports getting EAP authenticated identity from the AAA-server, and whether it knows how to use it for policy lookups, and in that case it also knows that AAA-server might do EAP identity requests. On the other hand server EAP may also be configured so it never does EAP identity requests, or even fakes them inside the server code. I.e. when AAA-server sends EAP identity request, that request is NOT sent to the client, but instead the server creates suitable EAP identity response based on the ID payload sent by the client. Now EAP is happy, and client and server are happy as they didn't waste one extra roundtrip to do EAP identity request from the client at all. The text in RFC7296 specifically does not limit the uses of EAP identities more than that "SHOULD NOT" just because we wanted to leave things open so different implementations can do whatever is suitable for them. -- kivinen@iki.fi From nobody Tue Jan 27 04:43:57 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 328FF1A877F for ; Tue, 27 Jan 2015 04:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrOzL9xxsJTn for ; Tue, 27 Jan 2015 04:43:53 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AE01A8746 for ; Tue, 27 Jan 2015 04:43:52 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id 10so12849245lbg.6 for ; Tue, 27 Jan 2015 04:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=RfKJ9Pu+vfRJbLOgtM21QBZlUrnT7yCz2meiNDitgE4=; b=gWJcacPPD1ju2LqKDsbQR4DuMjBx0DcfwwjSwlMCQxRZhySioLu7f6PD5VMNjg1VwD x+vnWdiLMSzHwoCyX1XQDG9nzSKSf2eDk2pjErlGJZmSjqr1KQha2zdD7ht2vWE75YZM HYGRdnLUiU4FQ+bKr5hcgBXscKUPaGxjIDXsf6iEwT4X9jD6QmMJUb2rHBZWhBKFTx2H HOLRwyflJU2fQ1oXgzwn/vfqVNON120dyaUw5GcTbvRXgEsoLPd4f9KISAFtnK3v1MAf uzIJPkgTG74XiOMpSnzcOSw9TTBLCNoA7YEziW01T5MvWB3Hho0zDucgQ7Vudk82t2G/ 2O0g== X-Received: by 10.112.235.67 with SMTP id uk3mr1435697lbc.48.1422362631280; Tue, 27 Jan 2015 04:43:51 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id w1sm405306lal.49.2015.01.27.04.43.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Jan 2015 04:43:50 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <21693.10207.704401.394139@fireball.kivinen.iki.fi><42287653737F4C17925AAF23F337AAD3@buildpc><21702.22413.999704.762826@fireball.kivinen.iki.fi><1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> Date: Tue, 27 Jan 2015 15:43:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Initiator Identity in case of EAP (was: My comments to the Null Authentication Method draft) 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, 27 Jan 2015 12:43:55 -0000 >> It is fully legal for NAS to sent EAP Identity request and >> not use IKE Identity. Then, many modern EAP methods >> (like EAP-TLS) have their own means to exchange Identities >> within the method, and in this case the initial IKE Identity becomes >> almost useless. > > And for some EAP libraries getting rid of the EAP Identity > request/reply is almost impossible. Exactly. > at is the reason there is SHOULD > NOT vs MUST NOT. > >> What about the sentence "The initiator MAY, however, >> respond to such requests if it receives them.", - I think that >> it is a mistake and the sentence must not be in the RFC. >> It tries to mandates EAP behaviour within IKEv2 spec. > > No it does not try to specify what EAP does, it specifis what IKEv2 > does. I.e. initiator MAY respond to such query, or abort the whole > negotiation, as the other end is not following the SHOULD NOT > specified in the IKEv2 specification. As you pointed out earlier in this message that it is EAP library, not IKEv2, that makes this Identity Request on Responder. And it is EAP library on the Initiator that this request is passed to. Actually, at this point EAP protocol has already been started, so why IKE need to interfere with EAP and make any decisions to which EAP request should EAP library answer and to which not? > If the initiator is not able to extract the identities from the EAP > messages, it really should abort the negotiation, as this would mean > that different identity is used for policy decision (the one in ID > payload), and different one is used for authentication (the one inside > EAP). If implementation does not have ability to verify those two > match (with suitable definition of match, i.e. it might use mapping > table etc to map EAP identity to identity to be used in the policy > checking) it should abort the exchange. What is the point of this check? For many EAP methods the EAP Identity in Identity Response message is not authenticated and just plays the same minor role of AAA server routing. The real authenticated identity is often hidden inside the EAP protocol and cannot be obtained by parsing EAP messages. For example, RFC5216, Section 2.2 (EAP-TLS): Since the identity presented in the EAP-Response/Identity need not be related to the identity presented in the peer certificate, EAP-TLS implementations SHOULD NOT require that they be identical. However, if they are not identical, the identity presented in the EAP- Response/Identity is unauthenticated information, and SHOULD NOT be used for access control or accounting purposes. >> Moreover, it contradicts to the EAP specification (RFC3748), >> which states (Section 5.1): >> >> The Identity Type is used to query the identity of the peer. >> Generally, the authenticator will issue this as the initial >> Request. An optional displayable message MAY be included to >> prompt the peer in the case where there is an expectation of >> interaction with a user. A Response of Type 1 (Identity) SHOULD >> be sent in Response to a Request with a Type of 1 (Identity). >> >> It is clear that SHOULD is not equal to MAY. It's unfortunate >> we didn't cach this contradiction while preparing RFC7296. > > They do not need to be equal. They are talking about different things. > EAP talks what EAP SHOULD do. IKEv2 talks what IKEv2 MAY do in that > case. IKEv2 could also say MUST NOT respond, and that would still be > ok. Actually as EAP only says SHOULD not MUST, it is actually valid > for the IKEv2 implementation to continue exchange and not respond to > identity request, but I would expect most EAP methods would fail in > that case. Or IKEv2 might take the ID payload and use that to > construct the EAP Identity response. Why at all should IKEv2 do something at this point? EAP has been already started and it is EAP's responsibility to response to Identity Request. >> > Also section 2.16 warns that if EAP Identity is used, there might be >> > mismatch with the ID payloads, and correct one needs to be used for >> > policy lookups: >> > >> > When the initiator authentication uses EAP, it is possible that the >> > contents of the IDi payload is used only for Authentication, >> > Authorization, and Accounting (AAA) routing purposes and selecting >> > which EAP method to use. This value may be different from the >> > identity authenticated by the EAP method. It is important that >> > policy lookups and access control decisions use the actual >> > authenticated identity. Often the EAP server is implemented in a >> > separate AAA server that communicates with the IKEv2 responder. In >> > this case, the authenticated identity, if different from that in the >> > IDi payload, has to be sent from the AAA server to the IKEv2 >> > responder. >> >> This para only supports my idea, that initiator's identity IDi in case >> of EAP plays no important role. It's sole purpose is for Authentication, >> Authorization, and Accounting (AAA) routing purposes and selecting >> which EAP method to use. And it may be ID_NULL, in which case >> the default AAA server will be selected and EAP method will be negotiated >> within EAP (in most natural way). > > ID payload is the one which is used to do policy lookups in the PAD, > and the PAD is linked to the SPD, which specifies what kind of Child > SAs can be specified. Because of this the ID is the really important > also in the EAP case. I disagree. In case of EAP IDi must not be used for PAD lookup, and the RFC is absolutely clear about it. > The text above in the RFC7296 is there because > some implementations uses ID payloads which do not follow this rule, > and because of this special code is needed to make sure that the > correct PAD entry is located using the authenticated identity, and > that might be the EAP identity instead of ID payload. The text clearly says that IDi is not used for policy lookup and control decisions. > In normal case the authenticated identity is ID payload, in some > special EAP cases it might be EAP identity. The implementation needs > to be able to handle this special case if it wants to support such > implementations, but it is ok acceptable for it to ignore this case, > and use ID payload for all policy lookups, and forbid EAP identity > exchanges completely. Usually this is not a problem as EAP identity > requests are done by the server, which is also tied to the AAA-server, > and server implementation will know whether it supports getting EAP > authenticated identity from the AAA-server, and whether it knows how > to use it for policy lookups, and in that case it also knows that > AAA-server might do EAP identity requests. On the other hand server > EAP may also be configured so it never does EAP identity requests, or > even fakes them inside the server code. I.e. when AAA-server sends EAP > identity request, that request is NOT sent to the client, but instead > the server creates suitable EAP identity response based on the ID > payload sent by the client. Now EAP is happy, and client and server > are happy as they didn't waste one extra roundtrip to do EAP identity > request from the client at all. You completely ignore the fact, that some EAP methods exchange identities themselves and don't use identity, received in response to EAP Identity request. And that inner identity is the only authenticated identity. Even if you manage to save extra roundtrip with all these complications, it doesn't make IDi an authenticated EAP identity in this case, even if it matches the EAP identity in EAP Identity response. > The text in RFC7296 specifically does not limit the uses of EAP > identities more than that "SHOULD NOT" just because we wanted to leave > things open so different implementations can do whatever is suitable > for them. That's why I think that ID_NULL can be used as IDi in case of EAP - this usage doesn't contradict to IKEv2 spec. Valery. > -- > kivinen@iki.fi From nobody Wed Jan 28 13:34:17 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 95F5F1A079D; Wed, 28 Jan 2015 13:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3Nn1wVZY6Czj; Wed, 28 Jan 2015 13:34:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 586801A1AB8; Wed, 28 Jan 2015 13:34:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150128213414.506.2250.idtracker@ietfa.amsl.com> Date: Wed, 28 Jan 2015 13:34:14 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-03.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, 28 Jan 2015 21:34:15 -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-03.txt Pages : 13 Date : 2015-01-28 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: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-03 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 Jan 28 13:38:07 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 00EB51A038A for ; Wed, 28 Jan 2015 13:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5YCoKg1_Tq9 for ; Wed, 28 Jan 2015 13:37:58 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D07F1A038B for ; Wed, 28 Jan 2015 13:37:55 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id 10so21686791lbg.10 for ; Wed, 28 Jan 2015 13:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:importance; bh=gWXfKsKc/Zvw6tUFj6kNRuDvxNxCJKJ9lPyW3TvKgAE=; b=vRB5DeaL3vDWPsqSZ01k3De+A6wIRLvU9FMq/8etSMFdOc8//Y2vf8oAtKA3zPrN+W Bb24KYi8o7lsfQ85h53JMYH7iApODM4bTaZUToJzAIvEc6aVlvMypYWit6Y8XR6wDYzp o0cuL+af9Oi+UcjALZbUPVhm/b+DC1NNSEtUNNeeQbypzncJBSDyFy1twvRepKqmLDaD YiIW+xK6pnXARjNqqdZ8fxEPs9HtPcIW4wlzl2JkqkoqL2ufENq6CfrHN6I0hEPaYl9H /IAxKdm7+1MDyzJbdqS9uYJNG9775VlQogk0txYcjGoFnmBPvsQi6X7fmuOEVhDLWN+J iP0g== X-Received: by 10.152.27.228 with SMTP id w4mr1570809lag.75.1422481074125; Wed, 28 Jan 2015 13:37:54 -0800 (PST) Received: from chichi (ppp85-141-202-176.pppoe.mtu-net.ru. [85.141.202.176]) by mx.google.com with ESMTPSA id ee5sm1642427lad.18.2015.01.28.13.37.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Jan 2015 13:37:53 -0800 (PST) Message-ID: <563F6FB67A7A4BB1A1384C1E44F60631@chichi> From: "Valery Smyslov" To: "IPsecme WG" Date: Thu, 29 Jan 2015 00:37:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: [IPsec] Fw: I-D Action: draft-ietf-ipsecme-ikev2-null-auth-03.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, 28 Jan 2015 21:38:00 -0000 Hi, new version of the draft is published. We tried to address the comments that the document received during WGLC. Valery & Paul. -----Original Message----- From: internet-drafts@ietf.org Date: 29 января 2015 г. 0:34 To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions 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-03.txt Pages : 13 Date : 2015-01-28 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: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-03 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 Wed Jan 28 14:22:07 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 9C7581A0367 for ; Wed, 28 Jan 2015 14:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNhVnYp42h9v for ; Wed, 28 Jan 2015 14:22:04 -0800 (PST) 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 A81871A00D4 for ; Wed, 28 Jan 2015 14:22:04 -0800 (PST) Received: from [10.20.30.90] (50-1-51-206.dsl.dynamic.fusionbroadband.com [50.1.51.206]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t0SMM35A092448 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Jan 2015 15:22:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-206.dsl.dynamic.fusionbroadband.com [50.1.51.206] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Wed, 28 Jan 2015 14:22:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IPsecME WG X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Second WG Last call, or continuation of WG Last Call, on "The NULL Authentication Method in IKEv2 Protocol" draft-ietf-ipsecme-ikev2-null-auth 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, 28 Jan 2015 22:22:05 -0000 Greetings again. Please review = draft-ietf-ipsecme-ikev2-null-auth-03.txt: it is now our WG Last Call = item. If you commented earlier, please look at = = and see if your comments were reflected either by adoption, or by an = adequate comment on the issue you brought up. If you did not comment during the first part of the WG Last Call, but = you were intrigued by some of the comments in the last call, *please* = read the document and comment, even if just to say "I have reviewed this = document and it is fine" or "I have now reviewed the document and here = are a few things that still deserve comment". If it looks like there is general agreement, we'll close out this = second/continued WG Last Call in two weeks, on February 11. --Paul Hoffman= From nobody Wed Jan 28 23:20:30 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 E987F1A1EFF for ; Wed, 28 Jan 2015 23:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-qegodmil9x for ; Wed, 28 Jan 2015 23:20:22 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7D31A8F4F for ; Wed, 28 Jan 2015 23:20:08 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id h11so20303918wiw.1 for ; Wed, 28 Jan 2015 23:20:06 -0800 (PST) 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=ZMCumwJfz24udMJt4tPxxV6EFpMg+vLZwi2I0FhjInA=; b=c8Bu6dAcobGm7gWr7IgD4iMrL3FUnB6JZY7nTGh24fdWUCbOJSeSTHUyXBJHelFMva azyrnXGWQ/5qI1Dwo45n0HkUxGMa0GGqe3fIR8MOO8r4Wq8EqgJWfnM5j/L+lYXf1JMT JnbQhKNFExhY+xzRXKOsZCWT6IRWr8ezATPicncEot+l2LtDH119Sbg41nt7I3usI6BO qtzZK+dS2vEwiWdicWl/6c/C1BASxvsGGY3ZcjufwCEB7W7FINPSrDWr1VYUOkKNX35d 58C7VZV/pxbqYDGfMc1ef0BUeeXWzUTy93CecebPr5g+QYWwz5LyYwB2WqZ32q1bMiT0 OYPQ== X-Received: by 10.194.237.41 with SMTP id uz9mr15980972wjc.80.1422516005985; Wed, 28 Jan 2015 23:20:05 -0800 (PST) Received: from [10.0.0.7] (bzq-79-177-128-127.red.bezeqint.net. [79.177.128.127]) by mx.google.com with ESMTPSA id u17sm1233348wij.2.2015.01.28.23.20.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 23:20:05 -0800 (PST) Message-ID: <54C9DF24.5060409@gmail.com> Date: Thu, 29 Jan 2015 09:20:04 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen References: <21693.10207.704401.394139@fireball.kivinen.iki.fi><42287653737F4C17925AAF23F337AAD3@buildpc><21702.22413.999704.762826@fireball.kivinen.iki.fi><1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> 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] Initiator Identity in case of EAP 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, 29 Jan 2015 07:20:27 -0000 > >> The text in RFC7296 specifically does not limit the uses of EAP >> identities more than that "SHOULD NOT" just because we wanted to leave >> things open so different implementations can do whatever is suitable >> for them. > > That's why I think that ID_NULL can be used as IDi > in case of EAP - this usage doesn't contradict to IKEv2 spec. > > Valery. > Hi Valery, I don't see how this can be done without breaking existing implementations, and therefore I am unhappy with the new sentence in -03, "Another example is EAP authentication when the client identity in ID payload is not used." A responder that receives a new, unknown ID type should IMHO reject the exchange as syntactically malformed. Even if some reading of the documents might lead you to think that responders should be liberal in this case, I see no benefit in breaking the non-liberal servers by using a novel ID type here. Thanks, Yaron From nobody Wed Jan 28 23:46:12 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 CE5A41A9007 for ; Wed, 28 Jan 2015 23:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqcLD6KQdqI3 for ; Wed, 28 Jan 2015 23:46:08 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390C71A9006 for ; Wed, 28 Jan 2015 23:46:08 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so25200612lbv.3 for ; Wed, 28 Jan 2015 23:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=zTTgAmbEj4mjYdErxMwR7D9+1GIb4D5iXv9xWV/iDos=; b=P40T1P82bVsJfMFq1IPzqeYVntFdmlqA3nZXCPP8LFNsHEshhF7pOGahLUBRF9x1Bv ECpSLVzThQUJ4Mxgwdb3LuJorztTPY8jmmGKq9xUb2eSvHhr8FArj5ZHJHyJL4n0IjmK z3ZOpJn3PZihZkKL/zZ+d6oMiqDNh8dUXIjfV+xCggBi/ctSOeoESjeFwvYtok2LkPp+ GQUizJkLFZ9QtDW7RWP1kXwIy1P5Kd3Tv7iUirhnEZAd+Mf+P7gCHaQI+5zPS6GBPmPg Dvv0OOh8aPIl0eN8uWPoyfKzUKo+ilyhs5/edB2VjcGFU4+kpAQ2dwUcIQVpLYaPYIGj HiLA== X-Received: by 10.152.23.98 with SMTP id l2mr12605322laf.46.1422517566668; Wed, 28 Jan 2015 23:46:06 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id ln2sm1923085lac.31.2015.01.28.23.46.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Jan 2015 23:46:06 -0800 (PST) Message-ID: <9DDFA86A78E04B2DB059840801EBA86A@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" References: <21693.10207.704401.394139@fireball.kivinen.iki.fi><42287653737F4C17925AAF23F337AAD3@buildpc><21702.22413.999704.762826@fireball.kivinen.iki.fi><1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> <54C9DF24.5060409@gmail.com> Date: Thu, 29 Jan 2015 10:46:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Initiator Identity in case of EAP 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, 29 Jan 2015 07:46:10 -0000 Hi Yaron, >>> The text in RFC7296 specifically does not limit the uses of EAP >>> identities more than that "SHOULD NOT" just because we wanted to leave >>> things open so different implementations can do whatever is suitable >>> for them. >> >> That's why I think that ID_NULL can be used as IDi >> in case of EAP - this usage doesn't contradict to IKEv2 spec. >> >> Valery. >> > > Hi Valery, > > I don't see how this can be done without breaking existing > implementations, and therefore I am unhappy with the new sentence in > -03, "Another example is EAP authentication when the client identity in > ID payload is not used." A responder that receives a new, unknown ID > type should IMHO reject the exchange as syntactically malformed. Even if > some reading of the documents might lead you to think that responders > should be liberal in this case, I see no benefit in breaking the > non-liberal servers by using a novel ID type here. The text is there because the draft doesn't restrict usage of ID_NULL to NULL AUthentication only and we were asked to provide some examples of such usage. I agree that current implementations won't probably tolerate the described scenario, but I also think that we should allow ID_NULL to be used in some use cases that might be defined in the future. We may remove this sentence that made you unhappy and replace it with something like: If ID_NULL is used with other authentication methods than NULL Authentication, then its usage must be defined in appropriate document. BTW, is another example of using ID_NULL in this para is acceptable to you? Regards, Valery. > Thanks, > Yaron From nobody Thu Jan 29 05:15:36 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 7210A1A038E for ; Thu, 29 Jan 2015 05:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HnWHX8zscRxJ for ; Thu, 29 Jan 2015 05:15:18 -0800 (PST) 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 511941A036C for ; Thu, 29 Jan 2015 05:15:16 -0800 (PST) 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 t0TDFCmj025550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jan 2015 15:15:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0TDFC8e028487; Thu, 29 Jan 2015 15:15:12 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21706.12896.496852.970305@fireball.kivinen.iki.fi> Date: Thu, 29 Jan 2015 15:15:12 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <9DDFA86A78E04B2DB059840801EBA86A@buildpc> References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <42287653737F4C17925AAF23F337AAD3@buildpc> <21702.22413.999704.762826@fireball.kivinen.iki.fi> <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> <54C9DF24.5060409@gmail.com> <9DDFA86A78E04B2DB059840801EBA86A@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Initiator Identity in case of EAP 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, 29 Jan 2015 13:15:24 -0000 Valery Smyslov writes: > > I don't see how this can be done without breaking existing > > implementations, and therefore I am unhappy with the new sentence in > > -03, "Another example is EAP authentication when the client identity in > > ID payload is not used." A responder that receives a new, unknown ID > > type should IMHO reject the exchange as syntactically malformed. Even if > > some reading of the documents might lead you to think that responders > > should be liberal in this case, I see no benefit in breaking the > > non-liberal servers by using a novel ID type here. > > The text is there because the draft doesn't restrict usage of ID_NULL > to NULL AUthentication only and we were asked to provide > some examples of such usage. I agree that current implementations > won't probably tolerate the described scenario, but I also think that we > should allow ID_NULL to be used in some use cases that might be defined > in the future. > > We may remove this sentence that made you unhappy and replace > it with something like: > > If ID_NULL is used with other authentication methods than NULL > Authentication, then its usage must be defined in appropriate > document. > > BTW, is another example of using ID_NULL in this para is > acceptable to you? I think removing the sentence saying "Another example is EAP authentication when the client identity in ID payload is not used." would be good. We already have one example in previous sentence (Raw public key) which points out why you might want to use ID_NULL with real authentication, and we do not necessarely need second example. And for the raw public key case, I do not think we need new document describing how it is used with ID_NULL... Of course we need to get the oob-pubkey draft published for that part of text to be really useful. -- kivinen@iki.fi From nobody Thu Jan 29 05:37:27 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 C00D21A037F for ; Thu, 29 Jan 2015 05:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsLz1FpPSeHS for ; Thu, 29 Jan 2015 05:37:19 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250BC1A037E for ; Thu, 29 Jan 2015 05:37:18 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id r20so24682729wiv.4 for ; Thu, 29 Jan 2015 05:37:16 -0800 (PST) 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=6NlSXIUKIl66u6BRK0X8H/z2ivkXOdlsAYrS33x1h+8=; b=nDnFzMqa2oRIF7LsnEQnymUbQS5e3BdTEqJplwNkC7E7OOR1cWHC3Nixq/B0WHnFBa eHWLCewPXdY8dVyMdC+NkgwIA/5ARSrlfZGWzN8nLfxa3+JX3hsL5eEEcwIb1EpBTssZ H9BQOKUeq9Epket95pVp8XtjdjFDO5sGG3gAnKMax6DuXUbqVxGUaHKYpP0gH2ecO0qh MQ8lj57fwO15BdLp+YoBlXHO8LDI+8PBufzm1TAOwMPIy2ta271LZACmH3A5KPmpJCw7 Z90v/7HFdTHmvVKlEqLJVfkUJvw5XnVUPsw2fJFpxeIst9xzkmQNDiqc4tCKRIzivj8e 3/gw== X-Received: by 10.180.21.206 with SMTP id x14mr154501wie.64.1422538636098; Thu, 29 Jan 2015 05:37:16 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id ej10sm2762024wib.1.2015.01.29.05.37.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 05:37:15 -0800 (PST) Message-ID: <54CA378A.7010208@gmail.com> Date: Thu, 29 Jan 2015 15:37:14 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tero Kivinen , Valery Smyslov References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <42287653737F4C17925AAF23F337AAD3@buildpc> <21702.22413.999704.762826@fireball.kivinen.iki.fi> <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> <54C9DF24.5060409@gmail.com> <9DDFA86A78E04B2DB059840801EBA86A@buildpc> <21706.12896.496852.970305@fireball.kivinen.iki.fi> In-Reply-To: <21706.12896.496852.970305@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Initiator Identity in case of EAP 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, 29 Jan 2015 13:37:20 -0000 > Valery Smyslov writes: >>> I don't see how this can be done without breaking existing >>> implementations, and therefore I am unhappy with the new sentence in >>> -03, "Another example is EAP authentication when the client identity in >>> ID payload is not used." A responder that receives a new, unknown ID >>> type should IMHO reject the exchange as syntactically malformed. Even if >>> some reading of the documents might lead you to think that responders >>> should be liberal in this case, I see no benefit in breaking the >>> non-liberal servers by using a novel ID type here. >> >> The text is there because the draft doesn't restrict usage of ID_NULL >> to NULL AUthentication only and we were asked to provide >> some examples of such usage. I agree that current implementations >> won't probably tolerate the described scenario, but I also think that we >> should allow ID_NULL to be used in some use cases that might be defined >> in the future. >> >> We may remove this sentence that made you unhappy and replace >> it with something like: >> >> If ID_NULL is used with other authentication methods than NULL >> Authentication, then its usage must be defined in appropriate >> document. >> >> BTW, is another example of using ID_NULL in this para is >> acceptable to you? > > I think removing the sentence saying "Another example is EAP > authentication when the client identity in ID payload is not used." > would be good. We already have one example in previous sentence (Raw > public key) which points out why you might want to use ID_NULL with > real authentication, and we do not necessarely need second example. > And for the raw public key case, I do not think we need new document > describing how it is used with ID_NULL... > > Of course we need to get the oob-pubkey draft published for that part > of text to be really useful. > I agree with Tero. Thanks, Yaron From nobody Thu Jan 29 06:35:58 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 CF37F1A0439 for ; Thu, 29 Jan 2015 06:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKfG4AC9Du9r for ; Thu, 29 Jan 2015 06:35:55 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871181A03A3 for ; Thu, 29 Jan 2015 06:35:55 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so28694901lbi.1 for ; Thu, 29 Jan 2015 06:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=h0AGy0FhOVmm4RKa55TDeFrzRpW6R1Oj+sS58evzYt8=; b=uWzkrABMhpMiibVXWV6G0PCOC0hzTj0sXzOp5I4QOO/fFUZCzY161oVlmJdV6axOYb +R91K/bo0pLgs/H6+ugI6ShqVrBhcPDCmuP1uSXrruq5i5eQ+UHQ4G0Agkm/faG9b/nc E84C+O3Yik4hJxyxLq/NlW31aJ8FuRMUZss/ex2n5USXs5jfCCveEh9vOvG0NFsnidMU eQyTfCjA9KTiqiVos8Sgc2rWwom2KE3sPGktmLlrSnIdT6U7wYwpw8tPX7o2JDmzMSBg dXM73HQDNVzBerL4oLzoppxaHRW/UDHkQIk+8i0+rQQaBCM25Ilt3IvAKKZgf5ahQv8s g5fw== X-Received: by 10.152.161.168 with SMTP id xt8mr1069337lab.35.1422542154065; Thu, 29 Jan 2015 06:35:54 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id i10sm2141138lah.25.2015.01.29.06.35.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Jan 2015 06:35:52 -0800 (PST) Message-ID: <7EC1348CF57D4815858372B44EE24CD4@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <42287653737F4C17925AAF23F337AAD3@buildpc> <21702.22413.999704.762826@fireball.kivinen.iki.fi> <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> <54C9DF24.5060409@gmail.com> <9DDFA86A78E04B2DB059840801EBA86A@buildpc> <21706.12896.496852.970305@fireball.kivinen.iki.fi> <54CA378A.7010208@gmail.com> Date: Thu, 29 Jan 2015 17:35:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Initiator Identity in case of EAP 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, 29 Jan 2015 14:35:57 -0000 >> Valery Smyslov writes: >>>> I don't see how this can be done without breaking existing >>>> implementations, and therefore I am unhappy with the new sentence in >>>> -03, "Another example is EAP authentication when the client identity in >>>> ID payload is not used." A responder that receives a new, unknown ID >>>> type should IMHO reject the exchange as syntactically malformed. Even >>>> if >>>> some reading of the documents might lead you to think that responders >>>> should be liberal in this case, I see no benefit in breaking the >>>> non-liberal servers by using a novel ID type here. >>> >>> The text is there because the draft doesn't restrict usage of ID_NULL >>> to NULL AUthentication only and we were asked to provide >>> some examples of such usage. I agree that current implementations >>> won't probably tolerate the described scenario, but I also think that we >>> should allow ID_NULL to be used in some use cases that might be defined >>> in the future. >>> >>> We may remove this sentence that made you unhappy and replace >>> it with something like: >>> >>> If ID_NULL is used with other authentication methods than NULL >>> Authentication, then its usage must be defined in appropriate >>> document. >>> >>> BTW, is another example of using ID_NULL in this para is >>> acceptable to you? >> >> I think removing the sentence saying "Another example is EAP >> authentication when the client identity in ID payload is not used." >> would be good. We already have one example in previous sentence (Raw >> public key) which points out why you might want to use ID_NULL with >> real authentication, and we do not necessarely need second example. >> And for the raw public key case, I do not think we need new document >> describing how it is used with ID_NULL... >> >> Of course we need to get the oob-pubkey draft published for that part >> of text to be really useful. >> > > I agree with Tero. In conclusion, is the following text OK? ID_NULL is primarily intended to be used with the NULL Authentication, but it MAY also be used in other situations, when the content of Identification payload does not matter. For example, ID_NULL can be used when authentication is performed via raw public keys and the identities are these keys themselves. If ID_NULL is used with other authentication methods than NULL Authentication, then the details of its usage must be defined in appropriate document. Valery. > Thanks, > Yaron From nobody Thu Jan 29 06:45:57 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 6F36E1A038A for ; Thu, 29 Jan 2015 06:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHnQK5-cjj8Y for ; Thu, 29 Jan 2015 06:45:55 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91F41A0275 for ; Thu, 29 Jan 2015 06:45:54 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id n3so25439719wiv.3 for ; Thu, 29 Jan 2015 06:45:53 -0800 (PST) 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=EKXhoRcQ2zsR20LjtNIZbOPMGWYNjXc3MFeahHE58G8=; b=t2Jykj/2+MUNLf02FYqARFMVHg73TGuh2khMeqo5p3SU6DfugrT8s3e56k13BCoD1d SZLZC83Nft1hcYFL/97FlISZzmYIzhntuUrAJDtFlTDT2db43mJDmQ6FosRNP4L/tTiy 1j9v3bIbnyu3cmHZY8f1P1G0LQ/MuvOYkR+SL1OrfYaN4x5M9gnwiJNAhP9D3uNxBt5z kBqnijoaeFXv0rzeI9S0iIy4QqW69pA1o8fLaX0paDnE34oPfKXhwdpDw0Mpf6Mvqdxs Iho5klAcAe+D2ECPSpMiBFKPWm9XL+PDFUWER9MFAk4aH1+uQFcLf0BXzkK46KqYsdvC x3cw== X-Received: by 10.180.98.3 with SMTP id ee3mr1985184wib.12.1422542753596; Thu, 29 Jan 2015 06:45:53 -0800 (PST) Received: from [10.2.0.130] (93-173-247-187.bb.netvision.net.il. [93.173.247.187]) by mx.google.com with ESMTPSA id i13sm10754089wjr.7.2015.01.29.06.45.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 06:45:52 -0800 (PST) Message-ID: <54CA479F.4090604@gmail.com> Date: Thu, 29 Jan 2015 16:45:51 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <42287653737F4C17925AAF23F337AAD3@buildpc> <21702.22413.999704.762826@fireball.kivinen.iki.fi> <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> <54C9DF24.5060409@gmail.com> <9DDFA86A78E04B2DB059840801EBA86A@buildpc> <21706.12896.496852.970305@fireball.kivinen.iki.fi> <54CA378A.7010208@gmail.com> <7EC1348CF57D4815858372B44EE24CD4@buildpc> In-Reply-To: <7EC1348CF57D4815858372B44EE24CD4@buildpc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Initiator Identity in case of EAP 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, 29 Jan 2015 14:45:56 -0000 Fine with me. Yaron On 01/29/2015 04:35 PM, Valery Smyslov wrote: >>> Valery Smyslov writes: >>>>> I don't see how this can be done without breaking existing >>>>> implementations, and therefore I am unhappy with the new sentence in >>>>> -03, "Another example is EAP authentication when the client >>>>> identity in >>>>> ID payload is not used." A responder that receives a new, unknown ID >>>>> type should IMHO reject the exchange as syntactically malformed. >>>>> Even if >>>>> some reading of the documents might lead you to think that responders >>>>> should be liberal in this case, I see no benefit in breaking the >>>>> non-liberal servers by using a novel ID type here. >>>> >>>> The text is there because the draft doesn't restrict usage of ID_NULL >>>> to NULL AUthentication only and we were asked to provide >>>> some examples of such usage. I agree that current implementations >>>> won't probably tolerate the described scenario, but I also think >>>> that we >>>> should allow ID_NULL to be used in some use cases that might be defined >>>> in the future. >>>> >>>> We may remove this sentence that made you unhappy and replace >>>> it with something like: >>>> >>>> If ID_NULL is used with other authentication methods than NULL >>>> Authentication, then its usage must be defined in appropriate >>>> document. >>>> >>>> BTW, is another example of using ID_NULL in this para is >>>> acceptable to you? >>> >>> I think removing the sentence saying "Another example is EAP >>> authentication when the client identity in ID payload is not used." >>> would be good. We already have one example in previous sentence (Raw >>> public key) which points out why you might want to use ID_NULL with >>> real authentication, and we do not necessarely need second example. >>> And for the raw public key case, I do not think we need new document >>> describing how it is used with ID_NULL... >>> >>> Of course we need to get the oob-pubkey draft published for that part >>> of text to be really useful. >>> >> >> I agree with Tero. > > In conclusion, is the following text OK? > > ID_NULL is primarily intended to be used with the NULL > Authentication, but it MAY also be used in other situations, when the > content of Identification payload does not matter. For example, > ID_NULL can be used when authentication is performed via raw public > keys and the identities are these keys themselves. If ID_NULL is > used with other authentication methods than NULL Authentication, then > the details of its usage must be defined in appropriate document. > > Valery. > >> Thanks, >> Yaron > From nobody Thu Jan 29 09:03:07 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 752AC1A7013 for ; Thu, 29 Jan 2015 09:03:05 -0800 (PST) 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 gJAIB_D0s0ww for ; Thu, 29 Jan 2015 09:03:02 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EE61A1BE0 for ; Thu, 29 Jan 2015 09:03:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kY7Kb4c47z7Zm; Thu, 29 Jan 2015 18:02:59 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=Rr8F52jP; dkim-adsp=pass 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 uXZvuKPaBpTt; Thu, 29 Jan 2015 18:02:58 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 29 Jan 2015 18:02:58 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8274A8324B; Thu, 29 Jan 2015 12:02:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1422550975; bh=JAO8Vv5U7lD7ZMZkwkXSO8fBTj7vALLFSd1QogVSPrM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Rr8F52jPV3D6EtMJuKkKCObwhZDT4EXvLtcPDbM6b8H1mdmkyne7vQMpdTh833IpF 04+nNIKkeoSZaBu2OTsqu9IvxGlPNL2snYuaYgA3vyF2/CAMGHUXvEc5GcVxaQ52hG /hzk+eDj3bHFOvQ+/uYYV09UW+t6xAo7rEHs6lMo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0TH2srp026933; Thu, 29 Jan 2015 12:02:55 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 29 Jan 2015 12:02:54 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <7EC1348CF57D4815858372B44EE24CD4@buildpc> Message-ID: References: <21693.10207.704401.394139@fireball.kivinen.iki.fi> <42287653737F4C17925AAF23F337AAD3@buildpc> <21702.22413.999704.762826@fireball.kivinen.iki.fi> <1F6D3F7236B64E94ABFE0C80A437040C@buildpc> <21703.29091.361637.504704@fireball.kivinen.iki.fi> <54C9DF24.5060409@gmail.com> <9DDFA86A78E04B2DB059840801EBA86A@buildpc> <21706.12896.496852.970305@fireball.kivinen.iki.fi> <54CA378A.7010208@gmail.com> <7EC1348CF57D4815858372B44EE24CD4@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Initiator Identity in case of EAP 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, 29 Jan 2015 17:03:05 -0000 On Thu, 29 Jan 2015, Valery Smyslov wrote: > In conclusion, is the following text OK? > ID_NULL is primarily intended to be used with the NULL > Authentication, but it MAY also be used in other situations, when the > content of Identification payload does not matter. For example, > ID_NULL can be used when authentication is performed via raw public > keys and the identities are these keys themselves. If ID_NULL is > used with other authentication methods than NULL Authentication, then > the details of its usage must be defined in appropriate document. Proposing some minor changes: ID_NULL is primarily intended to be used with NULL Authentication but could be used in other situations where the content of the Identification Payload is not used. For example, ID_NULL could be used when authentication is performed via raw public keys and the identities are the keys themselves. These alternative uses of ID_NULL should be described in their own respective documents. Paul From nobody Thu Jan 29 13:27:08 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 C4D771A8798 for ; Thu, 29 Jan 2015 13:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxRlSE8bgm0y for ; Thu, 29 Jan 2015 13:27:04 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2691A877F for ; Thu, 29 Jan 2015 13:27:04 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id r20so30537731wiv.4 for ; Thu, 29 Jan 2015 13:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=fMvCxk05+X0StXw/PLvCZyvNs9EndOpTsiJ7XWB8dmc=; b=V7T79Gqvy8h+XVQ8+ceCAcs/LsnTmbwAif7xqGOrBDH9mi9eizfo08pNy+ho8nlL84 iCjBft0Y+ndQq33sMczoG2YfVWRC1/NZeSU9ukogJC+ZmfCwUIGpkpx4v0eOSJaA3vJv CKzQYXU8si+K+0sTm9HCAKBVg9hg+TiXwF/FwxHr19C7Aw6WAgUfmKpbEXOirQKrgqm+ FASpp7zlT8kx2Z9rrzJV7wu3LXhOCAyzMveLaSK7XeoWA/fw5ugSxPWS9bBeqPn3+3VB w5rCRqvU3zgixSnXQ4kCf9s03M0c41v3krNJMhRdScaThfkG0TEwJrNDiySR3pg4Ho91 OQgw== X-Received: by 10.180.189.52 with SMTP id gf20mr3929807wic.27.1422566822782; Thu, 29 Jan 2015 13:27:02 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id vh8sm12052004wjc.12.2015.01.29.13.27.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 13:27:02 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_334B8D98-A68A-4A60-B35A-F2A3279D3E9C" Message-Id: Date: Thu, 29 Jan 2015 23:27:00 +0200 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] DDoS puzzle: PRF vs Hash 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, 29 Jan 2015 21:27:06 -0000 --Apple-Mail=_334B8D98-A68A-4A60-B35A-F2A3279D3E9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all. Following Valery=E2=80=99s suggestion, I=E2=80=99ve created a pull = request for replacing the puzzle mechanism: OLD: appending a string to the cookie so that the hash of the extended = string has enough zero bits at the end. NEW: finding a PRF key such that PRF(k, cookie) has enough zero bits at = the end. The source files and change are available at = https://github.com/ietf-ipsecme/drafts/pull/3 = The relevant section is appended below Please let us know what you think. Also about Valery=E2=80=99s pull = request about negotiation. Yoav 3. Puzzles The puzzle introduced here extends the cookie mechanism from RFC 7296. It is loosely based on the proof-of-work technique used in BitCoins ([bitcoins]). Future versions of this document will have the exact bit structure of the notification payloads, but for now, I will only describe the semantics of the content. A puzzle is sent to the Initiator in two cases: o The Responder is so overloaded, than no half-open SAs are allowed to be created without the puzzle, or o The Responder is not too loaded, but the rate-limiting in Section 5 prevents half-open SAs from being created with this particular peer address or prefix without first solving a puzzle. When the Responder decides to send the challenge notification in response to a IKE_SA_INIT request, the notification includes three fields: 1. Cookie - this is calculated the same as in RFC 7296. As in RFC 7296, the process of generating the cookie is not specified. 2. Algorithm, this is the identifier of a PRF algorithm, one of those proposed by the Initiator in the SA payload. 3. Zero Bit Count. This is a number between 8 and 255 that represents the length of the zero-bit run at the end of the output of the PRF function calculated over the Keyed-Cookie payload that the Initiator is to send. Since the mechanism is supposed to be stateless for the Responder, the same value is sent to all Initiators who are receiving this challenge. The values 0 and 1-8 are explicitly excluded, because the value zero is meaningless, and the values 1-8 create a puzzle that is too easy to solve for it to make any difference in mitigating DDoS attacks. Upon receiving this challenge payload, the Initiator attempts to calculate the PRF using different keys. When a key is found such that the resulting PRF output has a sufficient number of trailing zero bits, that result is sent to the Responder in a Keyed-Cookie notification, as described in Section 3.1. When receiving a request with a Keyed-Cookie, the Responder verifies two things: o That the cookie part is indeed valid. o That the PRF of the transmitted cookie calculated with the transmitted key has a sufficient number of trailing zero bits. Example 1: Suppose the calculated cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm is HMAC-SHA256, and the required number of zero bits is 18. After successively trying a bunch of keys, the Initiator finds that the key that is all-zero except for the last three bytes which are 02fc95 yields HMAC_SHA256(k, cookie) =3D 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, which has 19 trailing zero bits, so it is an acceptable solution. Example 2: Same cookie, but this time the required number of zero bits is 22. The first key to satisfy that requirement ends in 960cbb, which yields a hash with 23 trailing zero bits. Finding this requires 9,833,659 invocations of the PRF.= --Apple-Mail=_334B8D98-A68A-4A60-B35A-F2A3279D3E9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = all.

Following = Valery=E2=80=99s suggestion, I=E2=80=99ve created a pull request for = replacing the puzzle mechanism:

OLD: appending a string to the cookie = so that the hash of the extended string has enough zero bits at the = end.
NEW: finding a PRF key such that PRF(k, = cookie) has enough zero bits at the end.

The source files and change are = available at https://github.com/ietf-ipsecme/drafts/pull/3

The relevant section is = appended below

Please let us know what you think. Also about Valery=E2=80=99s = pull request about negotiation.

Yoav

3.  Puzzles

   The puzzle = introduced here extends the cookie mechanism from RFC
   7296.  It is loosely based on the = proof-of-work technique used in
   BitCoins = ([bitcoins]).  Future versions of this document will have
   the exact bit structure of the notification = payloads, but for now, I
   will only describe = the semantics of the content.

   A puzzle is sent to the = Initiator in two cases:

   o  The Responder is so = overloaded, than no half-open SAs are allowed
    =   to be created without the puzzle, or
   = o  The Responder is not too loaded, but the rate-limiting = in
      Section 5 prevents half-open SAs from = being created with this
      particular peer = address or prefix without first solving a puzzle.

   When the = Responder decides to send the challenge notification in
   response to a IKE_SA_INIT request, the = notification includes three
   = fields:

   1.  Cookie - this is calculated the same as = in RFC 7296.  As in RFC
       7296, = the process of generating the cookie is not specified.
   2.  Algorithm, this is the identifier of a = PRF algorithm, one of
       those = proposed by the Initiator in the SA payload.
   = 3.  Zero Bit Count.  This is a number between 8 and 255 = that
       represents the length of = the zero-bit run at the end of the
     =   output of the PRF function calculated over the = Keyed-Cookie
       payload that = the Initiator is to send.  Since the mechanism is
       supposed to be stateless for the = Responder, the same value is
       sent to = all Initiators who are receiving this challenge.  The
       values 0 and 1-8 are explicitly = excluded, because the value zero
     =   is meaningless, and the values 1-8 create a puzzle that is = too
       easy to solve for it to = make any difference in mitigating DDoS
     =   attacks.

   Upon receiving this = challenge payload, the Initiator attempts to
   = calculate the PRF using different keys.  When a key is found = such
   that the resulting PRF output has a = sufficient number of trailing
   zero bits, that = result is sent to the Responder in a Keyed-Cookie
   notification, as described in Section = 3.1.

   When receiving a request with a Keyed-Cookie, = the Responder verifies
   two things:

   o  = That the cookie part is indeed valid.
   o  = That the PRF of the transmitted cookie calculated with the
      transmitted key has a sufficient number = of trailing zero bits.

   Example 1: Suppose the = calculated cookie is
   = fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the = algorithm
   is HMAC-SHA256, and the required number = of zero bits is 18.  After
   = successively trying a bunch of keys, the Initiator finds that the = key
   that is all-zero except for the last = three bytes which are 02fc95
   yields HMAC_SHA256(k, = cookie) =3D
   = 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000,
   which has 19 trailing zero bits, so it is an = acceptable solution.

   Example 2: Same cookie, but = this time the required number of zero
   bits is = 22.  The first key to satisfy that requirement ends in
   960cbb, which yields a hash with 23 trailing = zero bits.  Finding this
   requires 9,833,659 = invocations of the PRF.
= --Apple-Mail=_334B8D98-A68A-4A60-B35A-F2A3279D3E9C-- From nobody Thu Jan 29 13:57:09 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 E76281A884E for ; Thu, 29 Jan 2015 13:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhIDtcJIglUw for ; Thu, 29 Jan 2015 13:57:07 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213B81A883F for ; Thu, 29 Jan 2015 13:57:07 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id fb4so30837108wid.2 for ; Thu, 29 Jan 2015 13:57:05 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=ZtBA9mTyut4xLrfG2i9MISiR8i7pkh4twHsWR6bLDHE=; b=BeHeFUT/76U2LZlaurRYLQN3/95Sbd28FgQ5vJStnnSMkF6NzDwyzwF/lkYWkd4WR+ Bptw+NKmBAvRx32coPKe7O71Z6mNG1A2vDJC4ohnM/tYsqnG7f2B+J9MtyQM7uPrvxlh LpAnAgcydmxJB1Q01508C9alyHdIhE3wM//s7SEsYCptPZhIxC2RZw6BkzDHsaE1cAq/ iv2I/BI56Gt7wFeIre9GHj3EZDrvo6J5q0xpykFRE6EaR5amOS5aUXtvEtA11fzydzF0 1bNYlOIRann/gei4Q68MWYj8uUFq5eXNb63oXLB2oA5vNJrhMFx4nf7s7kEgVRYMpwyr 0qgA== X-Received: by 10.180.98.136 with SMTP id ei8mr4312579wib.9.1422568625887; Thu, 29 Jan 2015 13:57:05 -0800 (PST) Received: from [10.0.0.7] (bzq-79-177-128-127.red.bezeqint.net. [79.177.128.127]) by mx.google.com with ESMTPSA id k1sm12139495wjn.9.2015.01.29.13.57.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 13:57:05 -0800 (PST) Message-ID: <54CAACAF.60806@gmail.com> Date: Thu, 29 Jan 2015 23:57:03 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yoav Nir , IPsecME WG References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 29 Jan 2015 21:57:09 -0000 Looking at the timing table, there is obviously significant variance in the time to solve each puzzle, compared to the ideal exponential curve. For example, for 28 bits we have 250s, whereas for 29 bits it's 1240s. Would it make sense to require the initiator to return 4 or 8 solved puzzles of the given strength? Of course, the responder would request 2-3 bits of strength less. The net effect should be a lower variance in run times, i.e. more deterministic run time for any particular type of client. Thanks, Yaron On 01/29/2015 11:27 PM, Yoav Nir wrote: > Hi all. > > Following Valery’s suggestion, I’ve created a pull request for replacing > the puzzle mechanism: > > OLD: appending a string to the cookie so that the hash of the extended > string has enough zero bits at the end. > NEW: finding a PRF key such that PRF(k, cookie) has enough zero bits at > the end. > > The source files and change are available at > https://github.com/ietf-ipsecme/drafts/pull/3 > > The relevant section is appended below > > Please let us know what you think. Also about Valery’s pull request > about negotiation. > > Yoav > > 3. Puzzles > > The puzzle introduced here extends the cookie mechanism from RFC > 7296. It is loosely based on the proof-of-work technique used in > BitCoins ([bitcoins]). Future versions of this document will have > the exact bit structure of the notification payloads, but for now, I > will only describe the semantics of the content. > > A puzzle is sent to the Initiator in two cases: > > o The Responder is so overloaded, than no half-open SAs are allowed > to be created without the puzzle, or > o The Responder is not too loaded, but the rate-limiting in > Section 5 prevents half-open SAs from being created with this > particular peer address or prefix without first solving a puzzle. > > When the Responder decides to send the challenge notification in > response to a IKE_SA_INIT request, the notification includes three > fields: > > 1. Cookie - this is calculated the same as in RFC 7296. As in RFC > 7296, the process of generating the cookie is not specified. > 2. Algorithm, this is the identifier of a PRF algorithm, one of > those proposed by the Initiator in the SA payload. > 3. Zero Bit Count. This is a number between 8 and 255 that > represents the length of the zero-bit run at the end of the > output of the PRF function calculated over the Keyed-Cookie > payload that the Initiator is to send. Since the mechanism is > supposed to be stateless for the Responder, the same value is > sent to all Initiators who are receiving this challenge. The > values 0 and 1-8 are explicitly excluded, because the value zero > is meaningless, and the values 1-8 create a puzzle that is too > easy to solve for it to make any difference in mitigating DDoS > attacks. > > Upon receiving this challenge payload, the Initiator attempts to > calculate the PRF using different keys. When a key is found such > that the resulting PRF output has a sufficient number of trailing > zero bits, that result is sent to the Responder in a Keyed-Cookie > notification, as described in Section 3.1. > > When receiving a request with a Keyed-Cookie, the Responder verifies > two things: > > o That the cookie part is indeed valid. > o That the PRF of the transmitted cookie calculated with the > transmitted key has a sufficient number of trailing zero bits. > > Example 1: Suppose the calculated cookie is > fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm > is HMAC-SHA256, and the required number of zero bits is 18. After > successively trying a bunch of keys, the Initiator finds that the key > that is all-zero except for the last three bytes which are 02fc95 > yields HMAC_SHA256(k, cookie) = > 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, > which has 19 trailing zero bits, so it is an acceptable solution. > > Example 2: Same cookie, but this time the required number of zero > bits is 22. The first key to satisfy that requirement ends in > 960cbb, which yields a hash with 23 trailing zero bits. Finding this > requires 9,833,659 invocations of the PRF. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Jan 29 15:41:58 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 0EFD21A88B8 for ; Thu, 29 Jan 2015 15:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtNgrF_7vBK4 for ; Thu, 29 Jan 2015 15:41:53 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E72B1A8893 for ; Thu, 29 Jan 2015 15:41:53 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id u56so24299537wes.0 for ; Thu, 29 Jan 2015 15:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=INVoduH7g+plI+VLXy0jpXq9Hj6s0F+H+dKewoAfIoA=; b=Oc1gGW1V5PEMZ8R93VXuHIQkH+U4b/FMGO4gWr9PJs94QET3sflMYkvtTzh1lNHCYB 84SkvaRpozfmieJJevXMq+KJCcy/+5LVIAi8gkD+q77AVi6HVn0dDmzIKTgFmZ8Bdr8T IKfmaGZ/9jzg+6yhljUGt8/HW0q0jykVZtpBHKQY48nFpL++cDTIvAHJW++0tu3BrqC7 DUraMXjxTbml1XOQvgoIUGqr3rfBCGhRUduP1re130saGODRZOoX+WSrQIukMswpKrep j3nWPCG6UQwNDumB9GSHPg6i7B2vmCjyGk0lvHVXSAGcjwx/6bxT+ZYepL3zS+yKM80t QXQQ== X-Received: by 10.180.218.133 with SMTP id pg5mr4911787wic.70.1422574911786; Thu, 29 Jan 2015 15:41:51 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id eu8sm4424789wib.21.2015.01.29.15.41.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 15:41:51 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D155B55-E4DC-42C1-A527-083CB165DD4C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <54CAACAF.60806@gmail.com> Date: Fri, 30 Jan 2015 01:41:49 +0200 Message-Id: <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> References: <54CAACAF.60806@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 29 Jan 2015 23:41:56 -0000 --Apple-Mail=_2D155B55-E4DC-42C1-A527-083CB165DD4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting. I=E2=80=99ve tried with a few different =E2=80=9Ccookies=E2=80= =9D. Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4 Key=3D=E2=80=A600003db1 PRF=3D=E2=80=A64c82f8b80000 #zeros=3D19 = time=3D0.025 Key=3D=E2=80=A60002ea6c PRF=3D=E2=80=A65faafb800000 #zeros=3D23 = time=3D0.250 Key=3D=E2=80=A60124159c PRF=3D=E2=80=A69136e5000000 #zeros=3D24 = time=3D26.013 Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b028f8c18b1 #zeros=3D14 time=3D0.016 #zeros=3D15 time=3D0.035 #zeros=3D19 time=3D0.134 #zeros=3D20 time=3D0.837 #zeros=3D21 time=3D1.932 #zeros=3D22 time=3D5.646 #zeros=3D24 time=3D16.790 #zeros=3D27 time=3D17.477 Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f #zeros=3D15 time=3D0.016 #zeros=3D17 time=3D0.434 #zeros=3D21 time=3D1.034 #zeros=3D22 time=3D1.230 #zeros=3D23 time=3D16.213 #zeros=3D24 time=3D25.554 #zeros=3D Seems like the big issue here is inconsistency. Set the puzzle level to = 22 bits, and it could be solved in a quarter second or in 5.6 seconds or = in 1.230. And these are not just outliers - they=E2=80=99re the first = three values I picked at this length. 20 bits seems an acceptable difficulty level, but beyond that it becomes = too erratic. Yoav > On Jan 29, 2015, at 11:57 PM, Yaron Sheffer = wrote: >=20 > Looking at the timing table, there is obviously significant variance = in the time to solve each puzzle, compared to the ideal exponential = curve. For example, for 28 bits we have 250s, whereas for 29 bits it's = 1240s. >=20 > Would it make sense to require the initiator to return 4 or 8 solved = puzzles of the given strength? Of course, the responder would request = 2-3 bits of strength less. The net effect should be a lower variance in = run times, i.e. more deterministic run time for any particular type of = client. >=20 > Thanks, > Yaron >=20 > On 01/29/2015 11:27 PM, Yoav Nir wrote: >> Hi all. >>=20 >> Following Valery=E2=80=99s suggestion, I=E2=80=99ve created a pull = request for replacing >> the puzzle mechanism: >>=20 >> OLD: appending a string to the cookie so that the hash of the = extended >> string has enough zero bits at the end. >> NEW: finding a PRF key such that PRF(k, cookie) has enough zero bits = at >> the end. >>=20 >> The source files and change are available at >> https://github.com/ietf-ipsecme/drafts/pull/3 >>=20 >> The relevant section is appended below >>=20 >> Please let us know what you think. Also about Valery=E2=80=99s pull = request >> about negotiation. >>=20 >> Yoav >>=20 >> 3. Puzzles >>=20 >> The puzzle introduced here extends the cookie mechanism from RFC >> 7296. It is loosely based on the proof-of-work technique used in >> BitCoins ([bitcoins]). Future versions of this document will have >> the exact bit structure of the notification payloads, but for now, = I >> will only describe the semantics of the content. >>=20 >> A puzzle is sent to the Initiator in two cases: >>=20 >> o The Responder is so overloaded, than no half-open SAs are = allowed >> to be created without the puzzle, or >> o The Responder is not too loaded, but the rate-limiting in >> Section 5 prevents half-open SAs from being created with this >> particular peer address or prefix without first solving a = puzzle. >>=20 >> When the Responder decides to send the challenge notification in >> response to a IKE_SA_INIT request, the notification includes three >> fields: >>=20 >> 1. Cookie - this is calculated the same as in RFC 7296. As in = RFC >> 7296, the process of generating the cookie is not specified. >> 2. Algorithm, this is the identifier of a PRF algorithm, one of >> those proposed by the Initiator in the SA payload. >> 3. Zero Bit Count. This is a number between 8 and 255 that >> represents the length of the zero-bit run at the end of the >> output of the PRF function calculated over the Keyed-Cookie >> payload that the Initiator is to send. Since the mechanism is >> supposed to be stateless for the Responder, the same value is >> sent to all Initiators who are receiving this challenge. The >> values 0 and 1-8 are explicitly excluded, because the value = zero >> is meaningless, and the values 1-8 create a puzzle that is too >> easy to solve for it to make any difference in mitigating DDoS >> attacks. >>=20 >> Upon receiving this challenge payload, the Initiator attempts to >> calculate the PRF using different keys. When a key is found such >> that the resulting PRF output has a sufficient number of trailing >> zero bits, that result is sent to the Responder in a Keyed-Cookie >> notification, as described in Section 3.1. >>=20 >> When receiving a request with a Keyed-Cookie, the Responder = verifies >> two things: >>=20 >> o That the cookie part is indeed valid. >> o That the PRF of the transmitted cookie calculated with the >> transmitted key has a sufficient number of trailing zero bits. >>=20 >> Example 1: Suppose the calculated cookie is >> fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the = algorithm >> is HMAC-SHA256, and the required number of zero bits is 18. After >> successively trying a bunch of keys, the Initiator finds that the = key >> that is all-zero except for the last three bytes which are 02fc95 >> yields HMAC_SHA256(k, cookie) =3D >> 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, >> which has 19 trailing zero bits, so it is an acceptable solution. >>=20 >> Example 2: Same cookie, but this time the required number of zero >> bits is 22. The first key to satisfy that requirement ends in >> 960cbb, which yields a hash with 23 trailing zero bits. Finding = this >> requires 9,833,659 invocations of the PRF. >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 --Apple-Mail=_2D155B55-E4DC-42C1-A527-083CB165DD4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Interesting. I=E2=80=99= ve tried with a few different =E2=80=9Ccookies=E2=80=9D.

Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4= f943b441cfd6f4
Key=3D=E2=80=A600003db1  PRF=3D=E2=80=A64c82f8b80000 =  #zeros=3D19  time=3D0.025
Key=3D=E2=80=A60002ea6c =  PRF=3D=E2=80=A65faafb800000  #zeros=3D23 =  time=3D0.250
Key=3D=E2=80=A60124159c  PRF=3D=E2=80=A69136e5000000 =  #zeros=3D24  time=3D26.013

Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc7= 1f8b028f8c18b1
#zeros=3D14   time=3D0.016
#zeros=3D15   = time=3D0.035
#zeros=3D19   = time=3D0.134
#zeros=3D20   = time=3D0.837
#zeros=3D21   = time=3D1.932
#zeros=3D22   = time=3D5.646
#zeros=3D24   = time=3D16.790
#zeros=3D27   = time=3D17.477

Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14= f
#zeros=3D15   time=3D0.016
#zeros=3D17   = time=3D0.434
#zeros=3D21   = time=3D1.034
#zeros=3D22   time=3D1.230
#zeros=3D23   = time=3D16.213
#zeros=3D24   time=3D25.554
#zeros=3D

Seems like the big issue here is = inconsistency. Set the puzzle level to 22 bits, and it could be solved = in a quarter second or in 5.6 seconds or in 1.230. And these are not = just outliers - they=E2=80=99re the first three values I picked at this = length.

20 = bits seems an acceptable difficulty level, but beyond that it becomes = too erratic.

Yoav

On Jan 29, 2015, at 11:57 PM, Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Looking at the timing table, there is obviously significant = variance in the time to solve each puzzle, compared to the ideal = exponential curve. For example, for 28 bits we have 250s, whereas for 29 = bits it's 1240s.

Would it make sense to = require the initiator to return 4 or 8 solved puzzles of the given = strength? Of course, the responder would request 2-3 bits of strength = less. The net effect should be a lower variance in run times, i.e. = more deterministic run time for any particular type of client.

Thanks,
Yaron

On 01/29/2015 11:27 PM, Yoav Nir wrote:
Hi all.

Following Valery=E2=80=99s suggestion, I=E2=80=99ve created a = pull request for replacing
the puzzle mechanism:

OLD: appending a string to the cookie so that = the hash of the extended
string has enough zero bits at = the end.
NEW: finding a PRF key such that PRF(k, cookie) = has enough zero bits at
the end.

The source files and change are available at
https://github.com/ietf-ipsecme/drafts/pull/3

The relevant section is appended below

Please let us know what you think. Also about = Valery=E2=80=99s pull request
about negotiation.

Yoav

3. =  Puzzles

   The puzzle = introduced here extends the cookie mechanism from RFC
 =  7296.  It is loosely based on the proof-of-work technique = used in
   BitCoins ([bitcoins]).  Future = versions of this document will have
   the exact = bit structure of the notification payloads, but for now, I
   will only describe the semantics of the = content.

   A puzzle is sent to = the Initiator in two cases:

   o =  The Responder is so overloaded, than no half-open SAs are = allowed
      to be created without the = puzzle, or
   o  The Responder is not too = loaded, but the rate-limiting in
      = Section 5 prevents half-open SAs from being created with this
      particular peer address or prefix = without first solving a puzzle.

  =  When the Responder decides to send the challenge notification = in
   response to a IKE_SA_INIT request, the = notification includes three
   fields:

   1.  Cookie - this is = calculated the same as in RFC 7296.  As in RFC
  =      7296, the process of generating the cookie is not = specified.
   2.  Algorithm, this is the = identifier of a PRF algorithm, one of
      =  those proposed by the Initiator in the SA payload.
   3.  Zero Bit Count.  This is a number = between 8 and 255 that
      =  represents the length of the zero-bit run at the end of the
       output of the PRF function = calculated over the Keyed-Cookie
      =  payload that the Initiator is to send.  Since the mechanism = is
       supposed to be stateless for = the Responder, the same value is
      =  sent to all Initiators who are receiving this challenge. =  The
       values 0 and 1-8 are = explicitly excluded, because the value zero
    =    is meaningless, and the values 1-8 create a puzzle that is = too
       easy to solve for it to = make any difference in mitigating DDoS
    =    attacks.

   Upon = receiving this challenge payload, the Initiator attempts to
   calculate the PRF using different keys. =  When a key is found such
   that the = resulting PRF output has a sufficient number of trailing
   zero bits, that result is sent to the Responder = in a Keyed-Cookie
   notification, as described = in Section 3.1.

   When receiving = a request with a Keyed-Cookie, the Responder verifies
 =  two things:

   o =  That the cookie part is indeed valid.
   o =  That the PRF of the transmitted cookie calculated with the
      transmitted key has a sufficient number = of trailing zero bits.

   Example = 1: Suppose the calculated cookie is
  =  fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the = algorithm
   is HMAC-SHA256, and the required = number of zero bits is 18.  After
  =  successively trying a bunch of keys, the Initiator finds that the = key
   that is all-zero except for the last = three bytes which are 02fc95
   yields = HMAC_SHA256(k, cookie) =3D
  =  843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000,   which has 19 trailing zero bits, so it is an = acceptable solution.

   Example = 2: Same cookie, but this time the required number of zero
   bits is 22.  The first key to satisfy that = requirement ends in
   960cbb, which yields a = hash with 23 trailing zero bits.  Finding this
  =  requires 9,833,659 invocations of the PRF.


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


= --Apple-Mail=_2D155B55-E4DC-42C1-A527-083CB165DD4C-- From nobody Fri Jan 30 03:27:31 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 C9DA31A8BB7 for ; Fri, 30 Jan 2015 03:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.071 X-Spam-Level: ** X-Spam-Status: No, score=2.071 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, J_CHICKENPOX_31=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNQC6U3ADChB for ; Fri, 30 Jan 2015 03:27:27 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEB11A010C for ; Fri, 30 Jan 2015 03:27:26 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ms9so23122384lab.1 for ; Fri, 30 Jan 2015 03:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=OHKlmX/odoIaPWxkjAZZnOIdcYQ7vizzN/274vWdCi4=; b=qawiV8/KBLPaJ9Ns/zi2EFOzJdiB9MiVAqmrT/fBvy+HSfd/Em0wK2MtIRQf3p9rJt fzLjgqJXsS1GASFL1dMJ6P97nRIZFTmiVkPQEI/Z18yHvzZUTwQBgue8smn7WTS6yC78 txKhEuCalTf3xpyMQglSBYsb3NDBorsL7JR2as3DJmKUbACL5Zrv3p1xDNg0oE334SkJ 4d7n1pCqbq/opjDKtAzsbmEGa9KvetYVo3pVr1XDVqdOtU6AGJpAWMMYRoM7qOJM3GT4 k2aAM6JjzKBXN1wpsXTl4tEmCFsN5kKEJTFGZA4fXBNuJo60StVWOzlqWrKQ6GJKTKAY gedw== X-Received: by 10.112.37.161 with SMTP id z1mr2051889lbj.87.1422617244857; Fri, 30 Jan 2015 03:27:24 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id xh7sm2670634lbb.17.2015.01.30.03.27.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Jan 2015 03:27:24 -0800 (PST) Message-ID: <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "Yaron Sheffer" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> Date: Fri, 30 Jan 2015 14:27:28 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DA_01D03C98.E02E7160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 30 Jan 2015 11:27:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01DA_01D03C98.E02E7160 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I also had some concerns on the variance of the times. But then another thought came to me. Let's look on this issue from the other = side. The responder will use puzzles only when it feels that it is under = attack. It means, that there are a lot of (thouthands, tens of thouthands) half-open connections. If responder requests that number of puzzles, then some of them will appear to be easier to solve than the others. Every initiator is different from another in terms of computing power = and=20 each of them may receive more or less hard puzzle. =20 It's like an exam - some tasks are more easy to solve, some are harder. Some clients will be more lucky, some less. That's a lottery. But all those differences will be averaged for the responder, so why = bother? Also if we require initiator to solve several puzzles, than it will need to send back all the solutions, that will noticeably increase IKE message size. So, while the idea is interesting, I think that the problem it solves is not important, so why should we bother? But it would be nice, if Yoav (as a person who already has=20 test bed) could check, that if we solve puzzle for 100=20 (or better 1000) different cookies, and average the times, that the results will be less erratic (it would also be great to measure the deviation of times for each level, not only average). Regards, Valery. ----- Original Message -----=20 From: Yoav Nir=20 To: Yaron Sheffer=20 Cc: IPsecME WG=20 Sent: Friday, January 30, 2015 2:41 AM Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash Interesting. I=E2=80=99ve tried with a few different = =E2=80=9Ccookies=E2=80=9D. Cookie: = 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4 Key=3D=E2=80=A600003db1 PRF=3D=E2=80=A64c82f8b80000 #zeros=3D19 = time=3D0.025 Key=3D=E2=80=A60002ea6c PRF=3D=E2=80=A65faafb800000 #zeros=3D23 = time=3D0.250 Key=3D=E2=80=A60124159c PRF=3D=E2=80=A69136e5000000 #zeros=3D24 = time=3D26.013 Cookie: = 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b028f8c18b1 #zeros=3D14 time=3D0.016 #zeros=3D15 time=3D0.035 #zeros=3D19 time=3D0.134 #zeros=3D20 time=3D0.837 #zeros=3D21 time=3D1.932 #zeros=3D22 time=3D5.646 #zeros=3D24 time=3D16.790 #zeros=3D27 time=3D17.477 Cookie: = 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f #zeros=3D15 time=3D0.016 #zeros=3D17 time=3D0.434 #zeros=3D21 time=3D1.034 #zeros=3D22 time=3D1.230 #zeros=3D23 time=3D16.213 #zeros=3D24 time=3D25.554 #zeros=3D Seems like the big issue here is inconsistency. Set the puzzle level = to 22 bits, and it could be solved in a quarter second or in 5.6 seconds = or in 1.230. And these are not just outliers - they=E2=80=99re the first = three values I picked at this length. 20 bits seems an acceptable difficulty level, but beyond that it = becomes too erratic. Yoav On Jan 29, 2015, at 11:57 PM, Yaron Sheffer = wrote: Looking at the timing table, there is obviously significant variance = in the time to solve each puzzle, compared to the ideal exponential = curve. For example, for 28 bits we have 250s, whereas for 29 bits it's = 1240s. Would it make sense to require the initiator to return 4 or 8 solved = puzzles of the given strength? Of course, the responder would request = 2-3 bits of strength less. The net effect should be a lower variance in = run times, i.e. more deterministic run time for any particular type of = client. Thanks, Yaron On 01/29/2015 11:27 PM, Yoav Nir wrote: Hi all. Following Valery=E2=80=99s suggestion, I=E2=80=99ve created a pull = request for replacing the puzzle mechanism: OLD: appending a string to the cookie so that the hash of the = extended string has enough zero bits at the end. NEW: finding a PRF key such that PRF(k, cookie) has enough zero = bits at the end. The source files and change are available at https://github.com/ietf-ipsecme/drafts/pull/3 The relevant section is appended below Please let us know what you think. Also about Valery=E2=80=99s = pull request about negotiation. Yoav 3. Puzzles The puzzle introduced here extends the cookie mechanism from = RFC 7296. It is loosely based on the proof-of-work technique used = in BitCoins ([bitcoins]). Future versions of this document will = have the exact bit structure of the notification payloads, but for = now, I will only describe the semantics of the content. A puzzle is sent to the Initiator in two cases: o The Responder is so overloaded, than no half-open SAs are = allowed to be created without the puzzle, or o The Responder is not too loaded, but the rate-limiting in Section 5 prevents half-open SAs from being created with = this particular peer address or prefix without first solving a = puzzle. When the Responder decides to send the challenge notification = in response to a IKE_SA_INIT request, the notification includes = three fields: 1. Cookie - this is calculated the same as in RFC 7296. As in = RFC 7296, the process of generating the cookie is not = specified. 2. Algorithm, this is the identifier of a PRF algorithm, one = of those proposed by the Initiator in the SA payload. 3. Zero Bit Count. This is a number between 8 and 255 that represents the length of the zero-bit run at the end of the output of the PRF function calculated over the Keyed-Cookie payload that the Initiator is to send. Since the mechanism = is supposed to be stateless for the Responder, the same value = is sent to all Initiators who are receiving this challenge. = The values 0 and 1-8 are explicitly excluded, because the value = zero is meaningless, and the values 1-8 create a puzzle that is = too easy to solve for it to make any difference in mitigating = DDoS attacks. Upon receiving this challenge payload, the Initiator attempts = to calculate the PRF using different keys. When a key is found = such that the resulting PRF output has a sufficient number of = trailing zero bits, that result is sent to the Responder in a = Keyed-Cookie notification, as described in Section 3.1. When receiving a request with a Keyed-Cookie, the Responder = verifies two things: o That the cookie part is indeed valid. o That the PRF of the transmitted cookie calculated with the transmitted key has a sufficient number of trailing zero = bits. Example 1: Suppose the calculated cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the = algorithm is HMAC-SHA256, and the required number of zero bits is 18. = After successively trying a bunch of keys, the Initiator finds that = the key that is all-zero except for the last three bytes which are = 02fc95 yields HMAC_SHA256(k, cookie) =3D = 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, which has 19 trailing zero bits, so it is an acceptable = solution. Example 2: Same cookie, but this time the required number of = zero bits is 22. The first key to satisfy that requirement ends in 960cbb, which yields a hash with 23 trailing zero bits. = Finding this requires 9,833,659 invocations of the PRF. _______________________________________________ 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 ------=_NextPart_000_01DA_01D03C98.E02E7160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi,
 
I also had some concerns on the variance of the = times. But=20 then
another thought came to me. Let's look on this issue = from the=20 other side.
The responder will use puzzles only when it feels = that it is=20 under attack.
It means, that there are a lot of (thouthands, tens = of=20 thouthands)
half-open connections. If responder requests that = number of=20 puzzles,
then some of them will appear to be easier to solve = than the=20 others.
Every initiator is different from another in terms = of=20 computing power and
each of them may receive more or less hard = puzzle. =20
It's like an exam - some tasks are more easy to = solve,=20 some are harder.
Some clients will be more lucky, some less. That's a = lottery.
But all those differences will be averaged for the = responder,=20 so why bother?
 
Also if we require initiator to solve several = puzzles, than it=20 will need
to send back all the solutions, that will noticeably = increase
IKE message size.
 
So, while the idea is interesting, I think that the = problem it=20 solves
is not important, so why should we = bother?
 
But it would be nice, if Yoav (as a person who = already has=20
test bed) could check, that if we solve puzzle for = 100=20
(or better 1000) different cookies, and average the=20 times,
that the results will be less erratic (it would also = be=20 great
to measure the deviation of times for each level, = not only=20 average).
 
Regards,
Valery.
 
 
----- Original Message -----
From:=20 Yoav Nir=20
Sent: Friday, January 30, 2015 = 2:41=20 AM
Subject: Re: [IPsec] DDoS = puzzle: PRF vs=20 Hash

Interesting. I=E2=80=99ve tried with a few different = =E2=80=9Ccookies=E2=80=9D.

Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b= 441cfd6f4
Key=3D=E2=80=A600003db1 =  PRF=3D=E2=80=A64c82f8b80000=20  #zeros=3D19  time=3D0.025
Key=3D=E2=80=A60002ea6c =  PRF=3D=E2=80=A65faafb800000=20  #zeros=3D23  time=3D0.250
Key=3D=E2=80=A60124159c =  PRF=3D=E2=80=A69136e5000000=20  #zeros=3D24  time=3D26.013

Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b0= 28f8c18b1
#zeros=3D14   = time=3D0.016
#zeros=3D15   = time=3D0.035
#zeros=3D19   = time=3D0.134
#zeros=3D20   = time=3D0.837
#zeros=3D21   = time=3D1.932
#zeros=3D22   = time=3D5.646
#zeros=3D24   = time=3D16.790
#zeros=3D27   = time=3D17.477

Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f
#zeros=3D15   = time=3D0.016
#zeros=3D17   = time=3D0.434
#zeros=3D21  =20 time=3D1.034
#zeros=3D22   = time=3D1.230
#zeros=3D23   = time=3D16.213
#zeros=3D24   = time=3D25.554
#zeros=3D

Seems like the big issue here is inconsistency. Set the puzzle = level to=20 22 bits, and it could be solved in a quarter second or in 5.6 seconds = or in=20 1.230. And these are not just outliers - they=E2=80=99re the first = three values I=20 picked at this length.

20 bits seems an acceptable difficulty level, but beyond that it = becomes=20 too erratic.

Yoav

On Jan 29, 2015, at 11:57 PM, Yaron Sheffer = <yaronf.ietf@gmail.com>=20 wrote:

Looking at the timing table, there is obviously = significant=20 variance in the time to solve each puzzle, compared to the ideal = exponential=20 curve. For example, for 28 bits we have 250s, whereas for 29 bits = it's=20 1240s.

Would it make sense to require the initiator to return = 4 or 8=20 solved puzzles of the given strength? Of course, the responder would = request=20 2-3 bits of strength less. The net effect should be a lower variance = in run=20 times, i.e. more deterministic run time for any particular type = of=20 client.

Thanks,
Yaron

On 01/29/2015 11:27 PM, = Yoav Nir=20 wrote:
Hi all.

Following Valery=E2=80=99s = suggestion, I=E2=80=99ve=20 created a pull request for replacing
the puzzle = mechanism:

OLD:=20 appending a string to the cookie so that the hash of the=20 extended
string has enough zero bits at the end.
NEW: = finding a PRF=20 key such that PRF(k, cookie) has enough zero bits at
the=20 end.

The source files and change are available at
https://github.com= /ietf-ipsecme/drafts/pull/3

The=20 relevant section is appended below

Please let us know what = you=20 think. Also about Valery=E2=80=99s pull request
about=20 negotiation.

Yoav

3.  Puzzles

  =  The=20 puzzle introduced here extends the cookie mechanism from = RFC
 =20  7296.  It is loosely based on the proof-of-work = technique used=20 in
   BitCoins ([bitcoins]).  Future versions of = this=20 document will have
   the exact bit structure of the=20 notification payloads, but for now, I
   will only = describe=20 the semantics of the content.

   A puzzle is sent = to the=20 Initiator in two cases:

   o  The Responder = is so=20 overloaded, than no half-open SAs are allowed
    =   to=20 be created without the puzzle, or
   o  The = Responder is=20 not too loaded, but the rate-limiting in
      = Section 5=20 prevents half-open SAs from being created with this
  =  =20   particular peer address or prefix without first solving a=20 puzzle.

   When the Responder decides to send the = challenge notification in
   response to a = IKE_SA_INIT=20 request, the notification includes three
 =20  fields:

   1.  Cookie - this is = calculated the=20 same as in RFC 7296.  As in RFC
      =  7296,=20 the process of generating the cookie is not specified.
  =  2.=20  Algorithm, this is the identifier of a PRF algorithm, one=20 of
       those proposed by the Initiator = in the SA=20 payload.
   3.  Zero Bit Count.  This is a = number=20 between 8 and 255 that
       represents = the length=20 of the zero-bit run at the end of the
      =  output=20 of the PRF function calculated over the Keyed-Cookie
  =  =20    payload that the Initiator is to send.  Since = the=20 mechanism is
       supposed to be = stateless for=20 the Responder, the same value is
      =  sent to all=20 Initiators who are receiving this challenge.  The
  =  =20    values 0 and 1-8 are explicitly excluded, because the = value=20 zero
       is meaningless, and the values = 1-8=20 create a puzzle that is too
       easy to = solve=20 for it to make any difference in mitigating DDoS
    =  =20  attacks.

   Upon receiving this challenge = payload,=20 the Initiator attempts to
   calculate the PRF using=20 different keys.  When a key is found such
  =  that the=20 resulting PRF output has a sufficient number of trailing
  =  zero bits, that result is sent to the Responder in a=20 Keyed-Cookie
   notification, as described in Section = 3.1.

   When receiving a request with a = Keyed-Cookie, the=20 Responder verifies
   two things:

  =  o=20  That the cookie part is indeed valid.
   o =  That=20 the PRF of the transmitted cookie calculated with the
  =  =20   transmitted key has a sufficient number of trailing zero=20 bits.

   Example 1: Suppose the calculated cookie = is
   fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 = octets),=20 the algorithm
   is HMAC-SHA256, and the required = number of=20 zero bits is 18.  After
   successively trying a = bunch=20 of keys, the Initiator finds that the key
   that is = all-zero=20 except for the last three bytes which are 02fc95
  =  yields=20 HMAC_SHA256(k, cookie) =3D
 =20 =  843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, =20  which has 19 trailing zero bits, so it is an acceptable=20 solution.

   Example 2: Same cookie, but this = time the=20 required number of zero
   bits is 22.  The = first key to=20 satisfy that requirement ends in
   960cbb, which = yields a=20 hash with 23 trailing zero bits.  Finding this
 =20  requires 9,833,659 invocations of the=20 = PRF.


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

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_01DA_01D03C98.E02E7160-- From nobody Fri Jan 30 04:04:24 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 BA8F91A8F39 for ; Fri, 30 Jan 2015 04:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 zG3GsKugx9bj for ; Fri, 30 Jan 2015 04:04:18 -0800 (PST) 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 87AF11A8F49 for ; Fri, 30 Jan 2015 04:04:18 -0800 (PST) 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 t0UC4DEp018328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jan 2015 14:04:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0UC4DQP001534; Fri, 30 Jan 2015 14:04:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21707.29501.372533.684249@fireball.kivinen.iki.fi> Date: Fri, 30 Jan 2015 14:04:13 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 30 Jan 2015 12:04:22 -0000 Valery Smyslov writes: > I also had some concerns on the variance of the times. But then > another thought came to me. Let's look on this issue from the other side. > The responder will use puzzles only when it feels that it is under attack. > It means, that there are a lot of (thouthands, tens of thouthands) > half-open connections. If responder requests that number of puzzles, > then some of them will appear to be easier to solve than the others. > Every initiator is different from another in terms of computing power and > each of them may receive more or less hard puzzle. > It's like an exam - some tasks are more easy to solve, some are harder. > Some clients will be more lucky, some less. That's a lottery. > But all those differences will be averaged for the responder, so why bother? Yes, it is lottery, as the execution time is randomly distributed over some max time. I agree that it does not really matter for this case, as we are protecting server sending the puzzles, and clients do not have way of knowing which puzzles are hard and which are easy. Also if client decides it will only try to solve the puzzle for 0.5 seconds and then get new one, that will not help it, as the one he already has might have been solved by just doing one more try, and the re is no guarantee that the new one he got is easier. > Also if we require initiator to solve several puzzles, than it will need > to send back all the solutions, that will noticeably increase > IKE message size. Not that much. The client could find number where: 0x01 + cookie + count1 0x02 + cookie + count2 0x03 + cookie + count3 0x04 + cookie + count4 and send back count cookie + count1-4 or something. The counters should be smaller than cookie, most likely something that can be expressed in 32 or 64 bits... The execution time of the above should be not randomly over the whole time, but binomial distribution over the time (or something like that, it is way too long when I have been doing anything like this). > So, while the idea is interesting, I think that the problem it solves > is not important, so why should we bother? Agree. > But it would be nice, if Yoav (as a person who already has > test bed) could check, that if we solve puzzle for 100 > (or better 1000) different cookies, and average the times, > that the results will be less erratic (it would also be great > to measure the deviation of times for each level, not only average). -- kivinen@iki.fi From nobody Fri Jan 30 04:39: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 C89621A8BC5 for ; Fri, 30 Jan 2015 04:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9ggepWoYH_t for ; Fri, 30 Jan 2015 04:39:34 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D861A01FA for ; Fri, 30 Jan 2015 04:39:33 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id b13so26572164wgh.9 for ; Fri, 30 Jan 2015 04:39:32 -0800 (PST) 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=6/WBr/FruZ0S+lFnB4+J4Xc4LC0x9Tns8/UoirIIGsk=; b=LNm4cSg+t4R6cOhneLuSK7aY73B1V4p3cP76PB1oOLAOxPRDche4rFHyPtxsBtJnnJ /zjm+hKQTIjk0UblVkxeoh4TtJjzk/FofGPYOvLbVTFXr6t4sjdHRin+KhSNLuddCcHW 4hlahsKJ47SMCYy54QP+Nf7uFTW3jmkqC2/jj5QZ9xXOvglmLvDFiw5Vc6E54KM7nNha cryGftRCPZHavKuQLqDAKc5Y0L2vlm9i2ROdQ6GsWrgmWb8bi9Re4ef97Owu1JAJu3Gr OKfSOz1EYCM2PqXpLWJ1uIzAQiInAAioQEOH17zCQfwIQ/h5DmO8R5Z1qSmTCP0dmNH+ 70BA== X-Received: by 10.180.160.144 with SMTP id xk16mr4619042wib.12.1422621572606; Fri, 30 Jan 2015 04:39:32 -0800 (PST) Received: from [10.0.0.4] (bzq-79-183-189-199.red.bezeqint.net. [79.183.189.199]) by mx.google.com with ESMTPSA id hv5sm14760214wjb.16.2015.01.30.04.39.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jan 2015 04:39:31 -0800 (PST) Message-ID: <54CB7B82.6060608@gmail.com> Date: Fri, 30 Jan 2015 14:39:30 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tero Kivinen , Valery Smyslov References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <21707.29501.372533.684249@fireball.kivinen.iki.fi> In-Reply-To: <21707.29501.372533.684249@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 30 Jan 2015 12:39:37 -0000 To clarify: I am NOT suggesting that the responder should generate 8 puzzles (8 cookies). I am suggesting that the initiator should send 8 different solutions to the same puzzle, using something like Tero's proposal. It is true that the execution time (a.k.a. client-side cost) will average out among many clients, so we would be fine WRT DoS protection. But it is still worthwhile to reduce the variance, in order to have a more deterministic user experience (for VPN clients) and to avoid client-side timeouts. Thanks, Yaron On 01/30/2015 02:04 PM, Tero Kivinen wrote: > Valery Smyslov writes: >> I also had some concerns on the variance of the times. But then >> another thought came to me. Let's look on this issue from the other side. >> The responder will use puzzles only when it feels that it is under attack. >> It means, that there are a lot of (thouthands, tens of thouthands) >> half-open connections. If responder requests that number of puzzles, >> then some of them will appear to be easier to solve than the others. >> Every initiator is different from another in terms of computing power and >> each of them may receive more or less hard puzzle. >> It's like an exam - some tasks are more easy to solve, some are harder. >> Some clients will be more lucky, some less. That's a lottery. >> But all those differences will be averaged for the responder, so why bother? > > Yes, it is lottery, as the execution time is randomly distributed over > some max time. I agree that it does not really matter for this case, > as we are protecting server sending the puzzles, and clients do not > have way of knowing which puzzles are hard and which are easy. > > Also if client decides it will only try to solve the puzzle for 0.5 > seconds and then get new one, that will not help it, as the one he > already has might have been solved by just doing one more try, and the > re is no guarantee that the new one he got is easier. > >> Also if we require initiator to solve several puzzles, than it will need >> to send back all the solutions, that will noticeably increase >> IKE message size. > > Not that much. The client could find number where: > > 0x01 + cookie + count1 > 0x02 + cookie + count2 > 0x03 + cookie + count3 > 0x04 + cookie + count4 > > and send back count cookie + count1-4 or something. The counters > should be smaller than cookie, most likely something that can be > expressed in 32 or 64 bits... > > The execution time of the above should be not randomly over the whole > time, but binomial distribution over the time (or something like that, > it is way too long when I have been doing anything like this). > >> So, while the idea is interesting, I think that the problem it solves >> is not important, so why should we bother? > > Agree. > >> But it would be nice, if Yoav (as a person who already has >> test bed) could check, that if we solve puzzle for 100 >> (or better 1000) different cookies, and average the times, >> that the results will be less erratic (it would also be great >> to measure the deviation of times for each level, not only average). From nobody Fri Jan 30 04:42: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 F36A21A8F40 for ; Fri, 30 Jan 2015 04:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-IGS_goOKxX for ; Fri, 30 Jan 2015 04:42:36 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423511A8BC5 for ; Fri, 30 Jan 2015 04:42:36 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so26912078wes.10 for ; Fri, 30 Jan 2015 04:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=NccIdRcRNK+44mEX7Tsz4jis8uOG1m/KyUcTlmN1WjY=; b=XmiDBsIoS5TGRytxfk6gkUc+VL/Us2inPTWXQpvvT16X1204NT10yxM8pd4ze7OWtY rFtMNyMLkOnsAWPDbMqlkeatp1YmNM6w5eUjNzkb8/SiHNjzmj4gTr/50GIeh4PLOw6P Jz848kJj4eiVEVOnqRE5PgPBYM6FcUwZguVQ0OO+LXUDDmBxn5ShV2m5BjIj+jriJdTd rMG7y4nuKvyj3SOC0N48nf3vomrzjq08xyHHn8wvKOu0E8s2XzKJ8ppU3GJbpFOqiiA8 /kv3AzKA3qegUKxA2AfkTAmJ8qpwF3giQChYu/yLQ8VddkT8EehyAL+hStSVxHxoxdqm 9TQQ== X-Received: by 10.181.11.170 with SMTP id ej10mr4444379wid.46.1422621754963; Fri, 30 Jan 2015 04:42:34 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id a1sm14769675wjs.40.2015.01.30.04.42.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 04:42:34 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2291BC7C-6772-46E7-A356-42ED9D00B685" From: Yoav Nir X-Priority: 3 In-Reply-To: <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> Date: Fri, 30 Jan 2015 14:42:31 +0200 Message-Id: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 30 Jan 2015 12:42:40 -0000 --Apple-Mail=_2291BC7C-6772-46E7-A356-42ED9D00B685 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ll try that later, but suppose we give the client 16 puzzles = to solve, then we expect solving all of them to take 16 times as long, = so they can be 16 times easier. So instead of 22 bits, they can be 18 = bits. I=E2=80=99m not sure if that increased the chance of getting = =E2=80=9Cstung=E2=80=9D by a bad outlier or that it averages better. But one effect is obvious. If we require the client to solve all = puzzles, the server has to check all 16 parts of the solution, and that = makes it 16x harder for the server. OTOH if we required to solve just one of the 16, the client could try = all 16 at the same time, and have a better chance of finding a = =E2=80=9Cgood=E2=80=9D outlier. Again, I=E2=80=99m not sure which is the = dominant effect. Yoav > On Jan 30, 2015, at 1:27 PM, Valery Smyslov wrote: >=20 > Hi, > =20 > I also had some concerns on the variance of the times. But then > another thought came to me. Let's look on this issue from the other = side. > The responder will use puzzles only when it feels that it is under = attack. > It means, that there are a lot of (thouthands, tens of thouthands) > half-open connections. If responder requests that number of puzzles, > then some of them will appear to be easier to solve than the others. > Every initiator is different from another in terms of computing power = and > each of them may receive more or less hard puzzle.=20 > It's like an exam - some tasks are more easy to solve, some are = harder. > Some clients will be more lucky, some less. That's a lottery. > But all those differences will be averaged for the responder, so why = bother? > =20 > Also if we require initiator to solve several puzzles, than it will = need > to send back all the solutions, that will noticeably increase > IKE message size. > =20 > So, while the idea is interesting, I think that the problem it solves > is not important, so why should we bother? > =20 > But it would be nice, if Yoav (as a person who already has > test bed) could check, that if we solve puzzle for 100 > (or better 1000) different cookies, and average the times, > that the results will be less erratic (it would also be great > to measure the deviation of times for each level, not only average). > =20 > Regards, > Valery. > =20 > =20 >> ----- Original Message ----- >> From: Yoav Nir >> To: Yaron Sheffer >> Cc: IPsecME WG >> Sent: Friday, January 30, 2015 2:41 AM >> Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash >>=20 >> Interesting. I=E2=80=99ve tried with a few different =E2=80=9Ccookies=E2= =80=9D. >>=20 >> Cookie: = 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4 >> Key=3D=E2=80=A600003db1 PRF=3D=E2=80=A64c82f8b80000 #zeros=3D19 = time=3D0.025 >> Key=3D=E2=80=A60002ea6c PRF=3D=E2=80=A65faafb800000 #zeros=3D23 = time=3D0.250 >> Key=3D=E2=80=A60124159c PRF=3D=E2=80=A69136e5000000 #zeros=3D24 = time=3D26.013 >>=20 >> Cookie: = 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b028f8c18b1 >> #zeros=3D14 time=3D0.016 >> #zeros=3D15 time=3D0.035 >> #zeros=3D19 time=3D0.134 >> #zeros=3D20 time=3D0.837 >> #zeros=3D21 time=3D1.932 >> #zeros=3D22 time=3D5.646 >> #zeros=3D24 time=3D16.790 >> #zeros=3D27 time=3D17.477 >>=20 >> Cookie: = 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f >> #zeros=3D15 time=3D0.016 >> #zeros=3D17 time=3D0.434 >> #zeros=3D21 time=3D1.034 >> #zeros=3D22 time=3D1.230 >> #zeros=3D23 time=3D16.213 >> #zeros=3D24 time=3D25.554 >> #zeros=3D >>=20 >> Seems like the big issue here is inconsistency. Set the puzzle level = to 22 bits, and it could be solved in a quarter second or in 5.6 seconds = or in 1.230. And these are not just outliers - they=E2=80=99re the first = three values I picked at this length. >>=20 >> 20 bits seems an acceptable difficulty level, but beyond that it = becomes too erratic. >>=20 >> Yoav >>=20 >>> On Jan 29, 2015, at 11:57 PM, Yaron Sheffer > wrote: >>>=20 >>> Looking at the timing table, there is obviously significant variance = in the time to solve each puzzle, compared to the ideal exponential = curve. For example, for 28 bits we have 250s, whereas for 29 bits it's = 1240s. >>>=20 >>> Would it make sense to require the initiator to return 4 or 8 solved = puzzles of the given strength? Of course, the responder would request = 2-3 bits of strength less. The net effect should be a lower variance in = run times, i.e. more deterministic run time for any particular type of = client. >>>=20 >>> Thanks, >>> Yaron >>>=20 >>> On 01/29/2015 11:27 PM, Yoav Nir wrote: >>>> Hi all. >>>>=20 >>>> Following Valery=E2=80=99s suggestion, I=E2=80=99ve created a pull = request for replacing >>>> the puzzle mechanism: >>>>=20 >>>> OLD: appending a string to the cookie so that the hash of the = extended >>>> string has enough zero bits at the end. >>>> NEW: finding a PRF key such that PRF(k, cookie) has enough zero = bits at >>>> the end. >>>>=20 >>>> The source files and change are available at >>>> https://github.com/ietf-ipsecme/drafts/pull/3 = >>>>=20 >>>> The relevant section is appended below >>>>=20 >>>> Please let us know what you think. Also about Valery=E2=80=99s pull = request >>>> about negotiation. >>>>=20 >>>> Yoav >>>>=20 >>>> 3. Puzzles >>>>=20 >>>> The puzzle introduced here extends the cookie mechanism from RFC >>>> 7296. It is loosely based on the proof-of-work technique used = in >>>> BitCoins ([bitcoins]). Future versions of this document will = have >>>> the exact bit structure of the notification payloads, but for = now, I >>>> will only describe the semantics of the content. >>>>=20 >>>> A puzzle is sent to the Initiator in two cases: >>>>=20 >>>> o The Responder is so overloaded, than no half-open SAs are = allowed >>>> to be created without the puzzle, or >>>> o The Responder is not too loaded, but the rate-limiting in >>>> Section 5 prevents half-open SAs from being created with this >>>> particular peer address or prefix without first solving a = puzzle. >>>>=20 >>>> When the Responder decides to send the challenge notification in >>>> response to a IKE_SA_INIT request, the notification includes = three >>>> fields: >>>>=20 >>>> 1. Cookie - this is calculated the same as in RFC 7296. As in = RFC >>>> 7296, the process of generating the cookie is not specified. >>>> 2. Algorithm, this is the identifier of a PRF algorithm, one of >>>> those proposed by the Initiator in the SA payload. >>>> 3. Zero Bit Count. This is a number between 8 and 255 that >>>> represents the length of the zero-bit run at the end of the >>>> output of the PRF function calculated over the Keyed-Cookie >>>> payload that the Initiator is to send. Since the mechanism = is >>>> supposed to be stateless for the Responder, the same value = is >>>> sent to all Initiators who are receiving this challenge. = The >>>> values 0 and 1-8 are explicitly excluded, because the value = zero >>>> is meaningless, and the values 1-8 create a puzzle that is = too >>>> easy to solve for it to make any difference in mitigating = DDoS >>>> attacks. >>>>=20 >>>> Upon receiving this challenge payload, the Initiator attempts to >>>> calculate the PRF using different keys. When a key is found = such >>>> that the resulting PRF output has a sufficient number of = trailing >>>> zero bits, that result is sent to the Responder in a = Keyed-Cookie >>>> notification, as described in Section 3.1. >>>>=20 >>>> When receiving a request with a Keyed-Cookie, the Responder = verifies >>>> two things: >>>>=20 >>>> o That the cookie part is indeed valid. >>>> o That the PRF of the transmitted cookie calculated with the >>>> transmitted key has a sufficient number of trailing zero = bits. >>>>=20 >>>> Example 1: Suppose the calculated cookie is >>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the = algorithm >>>> is HMAC-SHA256, and the required number of zero bits is 18. = After >>>> successively trying a bunch of keys, the Initiator finds that = the key >>>> that is all-zero except for the last three bytes which are = 02fc95 >>>> yields HMAC_SHA256(k, cookie) =3D >>>> = 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, >>>> which has 19 trailing zero bits, so it is an acceptable = solution. >>>>=20 >>>> Example 2: Same cookie, but this time the required number of = zero >>>> bits is 22. The first key to satisfy that requirement ends in >>>> 960cbb, which yields a hash with 23 trailing zero bits. Finding = this >>>> requires 9,833,659 invocations of the PRF. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_2291BC7C-6772-46E7-A356-42ED9D00B685 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ll try that later, but suppose we give the client = 16 puzzles to solve, then we expect solving all of them to take 16 times = as long, so they can be 16 times easier. So instead of 22 bits, they can = be 18 bits. I=E2=80=99m not sure if that increased the chance of getting = =E2=80=9Cstung=E2=80=9D by a bad outlier or that it averages better.

But one effect is = obvious. If we require the client to solve all puzzles, the server has = to check all 16 parts of the solution, and that makes it 16x harder for = the server.

OTOH= if we required to solve just one of the 16, the client could try all 16 = at the same time, and have a better chance of finding a =E2=80=9Cgood=E2=80= =9D outlier. Again, I=E2=80=99m not sure which is the dominant = effect.

Yoav

On = Jan 30, 2015, at 1:27 PM, Valery Smyslov <svanru@gmail.com> = wrote:

Hi,
 
I also had some concerns on = the variance of the times. But=20 then
another thought came to me. = Let's look on this issue from the=20 other side.
The responder will use = puzzles only when it feels that it is=20 under attack.
It means, that there are a = lot of (thouthands, tens of=20 thouthands)
half-open connections. If = responder requests that number of=20 puzzles,
then some of them will = appear to be easier to solve than the=20 others.
Every initiator is different = from another in terms of=20 computing power and
each of them may receive = more or less hard puzzle. =20
It's like an exam - = some tasks are more easy to solve,=20 some are harder.
Some clients will be more = lucky, some less. That's a=20 lottery.
But all those differences = will be averaged for the responder,=20 so why bother?
 
Also if we require initiator = to solve several puzzles, than it=20 will need
to send back all the = solutions, that will noticeably=20 increase
IKE message = size.
 
So, while the idea is = interesting, I think that the problem it=20 solves
is not important, so why = should we bother?
 
But it would be nice, if = Yoav (as a person who already has=20
test bed) could check, that = if we solve puzzle for 100=20
(or better 1000) different = cookies, and average the=20 times,
that the results will be = less erratic (it would also be=20 great
to measure the deviation of = times for each level, not only=20 average).
 
Regards,
Valery.
 
 
----- Original Message = -----
From:=20 Yoav Nir=20
To: Yaron Sheffer
Cc: IPsecME= WG
Sent: = Friday, January 30, 2015 2:41=20 AM
Subject: = Re: [IPsec] DDoS puzzle: PRF vs=20 Hash

Interesting. I=E2=80=99ve tried = with a few different =E2=80=9Ccookies=E2=80=9D.

Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4= f943b441cfd6f4
Key=3D=E2=80=A6000= 03db1  PRF=3D=E2=80=A64c82f8b80000=20  #zeros=3D19  time=3D0.025
Key=3D=E2=80=A6000= 2ea6c  PRF=3D=E2=80=A65faafb800000=20  #zeros=3D23  time=3D0.250
Key=3D=E2=80=A6012= 4159c  PRF=3D=E2=80=A69136e5000000=20  #zeros=3D24  time=3D26.013

Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc7= 1f8b028f8c18b1
#zeros=3D14 =   time=3D0.016
#zeros=3D15 =   time=3D0.035
#zeros=3D19 =   time=3D0.134
#zeros=3D20 =   time=3D0.837
#zeros=3D21 =   time=3D1.932
#zeros=3D22 =   time=3D5.646
#zeros=3D24 =   time=3D16.790
#zeros=3D27 =   time=3D17.477

Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14= f
#zeros=3D15 =   time=3D0.016
#zeros=3D17 =   time=3D0.434
#zeros=3D21  =20 time=3D1.034
#zeros=3D22 =   time=3D1.230
#zeros=3D23 =   time=3D16.213
#zeros=3D24 =   time=3D25.554
#zeros=3D

Seems like the big issue here is inconsistency. Set = the puzzle level to=20 22 bits, and it could be solved in a quarter second or in 5.6 seconds = or in=20 1.230. And these are not just outliers - they=E2=80=99re the first = three values I=20 picked at this length.

20 bits seems an acceptable difficulty level, but = beyond that it becomes=20 too erratic.

Yoav

On Jan 29, 2015, at 11:57 PM, = Yaron Sheffer <yaronf.ietf@gmail.com>=20 wrote:

Looking at the timing table, = there is obviously significant=20 variance in the time to solve each puzzle, compared to the ideal = exponential=20 curve. For example, for 28 bits we have 250s, whereas for 29 bits = it's=20 1240s.

Would it make sense to require = the initiator to return 4 or 8=20 solved puzzles of the given strength? Of course, the responder would = request=20 2-3 bits of strength less. The net effect should be a lower variance = in run=20 times, i.e. more deterministic run time for any particular type = of=20 client.

Thanks,
Yaron

On 01/29/2015 11:27 PM, Yoav Nir=20 wrote:
Hi all.

Following Valery=E2=80=99s suggestion, I=E2=80=99ve=20 created a pull request for replacing
the puzzle = mechanism:

OLD:=20 appending a string to the cookie so that the hash of the=20 extended
string has enough zero bits at the end.
NEW: finding a PRF=20 key such that PRF(k, cookie) has enough zero bits at
the=20 end.

The source files and change are = available at
https://github.com/ietf-ipsecme/drafts/pull/3

The=20 relevant section is appended below

Please let us know what you=20 think. Also about Valery=E2=80=99s pull request
about=20= negotiation.

Yoav

3.  Puzzles

  =  The=20 puzzle introduced here extends the cookie mechanism from RFC
 =20  7296.  It is loosely based on the proof-of-work = technique used=20 in
   BitCoins ([bitcoins]).  Future = versions of this=20 document will have
   the exact bit = structure of the=20 notification payloads, but for now, I
  =  will only describe=20 the semantics of the content.

  =  A puzzle is sent to the=20 Initiator in two cases:

  =  o  The Responder is so=20 overloaded, than no half-open SAs are allowed
  =     to=20 be created without the puzzle, or
   o =  The Responder is=20 not too loaded, but the rate-limiting in
  =     Section 5=20 prevents half-open SAs from being created with this
   =20   particular peer address or prefix without first solving a=20= puzzle.

   When the = Responder decides to send the=20 challenge notification in
   response to a = IKE_SA_INIT=20 request, the notification includes three
 =20  fields:

   1. =  Cookie - this is calculated the=20 same as in RFC 7296.  As in RFC
    =    7296,=20 the process of generating the cookie is not specified.
   2.=20  Algorithm, this is the identifier of a PRF algorithm, one=20 of
       those proposed by the = Initiator in the SA=20 payload.
   3.  Zero Bit Count. =  This is a number=20 between 8 and 255 that
      =  represents the length=20 of the zero-bit run at the end of the
    =    output=20 of the PRF function calculated over the Keyed-Cookie
   =20    payload that the Initiator is to send.  Since = the=20 mechanism is
       supposed to = be stateless for=20 the Responder, the same value is
    =    sent to all=20 Initiators who are receiving this challenge.  The
   =20    values 0 and 1-8 are explicitly excluded, because the = value=20 zero
       is meaningless, and = the values 1-8=20 create a puzzle that is too
      =  easy to solve=20 for it to make any difference in mitigating DDoS
     =20  attacks.

   Upon = receiving this challenge payload,=20 the Initiator attempts to
   calculate the = PRF using=20 different keys.  When a key is found such
  =  that the=20 resulting PRF output has a sufficient number of trailing
 =20  zero bits, that result is sent to the Responder in a=20 Keyed-Cookie
   notification, as described = in Section=20 3.1.

   When receiving a = request with a Keyed-Cookie, the=20 Responder verifies
   two things:

   o=20  That the cookie part is indeed valid.
  =  o  That=20 the PRF of the transmitted cookie calculated with the
   =20   transmitted key has a sufficient number of trailing zero=20 bits.

   Example 1: Suppose = the calculated cookie=20 is
  =  fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets),=20 the algorithm
   is HMAC-SHA256, and the = required number of=20 zero bits is 18.  After
  =  successively trying a bunch=20 of keys, the Initiator finds that the key
  =  that is all-zero=20 except for the last three bytes which are 02fc95
   yields=20 HMAC_SHA256(k, cookie) =3D
 =20 =  843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, =20  which has 19 trailing zero bits, so it is an acceptable=20 solution.

   Example 2: = Same cookie, but this time the=20 required number of zero
   bits is 22. =  The first key to=20 satisfy that requirement ends in
  =  960cbb, which yields a=20 hash with 23 trailing zero bits.  Finding this
 =20  requires 9,833,659 invocations of the=20 PRF.


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


=

_________________________________= ______________
IPsec mailing=20 list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_2291BC7C-6772-46E7-A356-42ED9D00B685-- From nobody Fri Jan 30 04:51:57 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 E27AA1A8BC5 for ; Fri, 30 Jan 2015 04:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j701ntZHzYj for ; Fri, 30 Jan 2015 04:51:47 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBEB1A002A for ; Fri, 30 Jan 2015 04:51:47 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so23466679lab.12 for ; Fri, 30 Jan 2015 04:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=qnmG0fFBG1XdMia1RYX13dazdQtb5GP7ZtMgxGhpEqI=; b=qv656avAfPCf4yk4mi8GvL5e2hgxiDJdm1OQWn/3picOutFFFkfLq/HPocjVlJHDWz Y/kXhlQysT7QRfnYm1zI2jyY+53hBVzOf2l4ca1ivKYuTOoXWWMv0LlOACzGLp25DXmT TaIxOs4EgmCkOtPgrPwdGT8FGW8unxFOaECxiiFKK8T7dL2XB4y5ywje0SsYlF8cCr/W iB2OJghVhxyAmuwDpbcedAbJZMLc1YikKm9pOuuSl18TcZLaHh71LtzX+LiI28Qhlyrf caOQdiFPZWazuCWlKosrYU5gP2eiXgtb9zqJ38Faviv92x4rcntiGQPxKA2r+YZuSYti DGVg== X-Received: by 10.152.20.169 with SMTP id o9mr6343604lae.50.1422622305821; Fri, 30 Jan 2015 04:51:45 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id cj6sm2704771lad.38.2015.01.30.04.51.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Jan 2015 04:51:44 -0800 (PST) Message-ID: <9D19EA800C574295B4145C619EC5B895@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <21707.29501.372533.684249@fireball.kivinen.iki.fi> <54CB7B82.6060608@gmail.com> Date: Fri, 30 Jan 2015 15:51:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 30 Jan 2015 12:51:55 -0000 > To clarify: I am NOT suggesting that the responder should generate 8 > puzzles (8 cookies). I am suggesting that the initiator should send 8 > different solutions to the same puzzle, using something like Tero's > proposal. I understand it exactly as you described. But then the initiatot need to include all 8 solutions in its second try. Even with Tero's approach it will increase the message size. And as Yoav has pointed out - the responder should then check all that 8 solutions. So for now I think it is not justified. Valery. > It is true that the execution time (a.k.a. client-side cost) will average > out among many clients, so we would be fine WRT DoS protection. But it is > still worthwhile to reduce the variance, in order to have a more > deterministic user experience (for VPN clients) and to avoid client-side > timeouts. > > Thanks, > Yaron > > On 01/30/2015 02:04 PM, Tero Kivinen wrote: >> Valery Smyslov writes: >>> I also had some concerns on the variance of the times. But then >>> another thought came to me. Let's look on this issue from the other >>> side. >>> The responder will use puzzles only when it feels that it is under >>> attack. >>> It means, that there are a lot of (thouthands, tens of thouthands) >>> half-open connections. If responder requests that number of puzzles, >>> then some of them will appear to be easier to solve than the others. >>> Every initiator is different from another in terms of computing power >>> and >>> each of them may receive more or less hard puzzle. >>> It's like an exam - some tasks are more easy to solve, some are harder. >>> Some clients will be more lucky, some less. That's a lottery. >>> But all those differences will be averaged for the responder, so why >>> bother? >> >> Yes, it is lottery, as the execution time is randomly distributed over >> some max time. I agree that it does not really matter for this case, >> as we are protecting server sending the puzzles, and clients do not >> have way of knowing which puzzles are hard and which are easy. >> >> Also if client decides it will only try to solve the puzzle for 0.5 >> seconds and then get new one, that will not help it, as the one he >> already has might have been solved by just doing one more try, and the >> re is no guarantee that the new one he got is easier. >> >>> Also if we require initiator to solve several puzzles, than it will need >>> to send back all the solutions, that will noticeably increase >>> IKE message size. >> >> Not that much. The client could find number where: >> >> 0x01 + cookie + count1 >> 0x02 + cookie + count2 >> 0x03 + cookie + count3 >> 0x04 + cookie + count4 >> >> and send back count cookie + count1-4 or something. The counters >> should be smaller than cookie, most likely something that can be >> expressed in 32 or 64 bits... >> >> The execution time of the above should be not randomly over the whole >> time, but binomial distribution over the time (or something like that, >> it is way too long when I have been doing anything like this). >> >>> So, while the idea is interesting, I think that the problem it solves >>> is not important, so why should we bother? >> >> Agree. >> >>> But it would be nice, if Yoav (as a person who already has >>> test bed) could check, that if we solve puzzle for 100 >>> (or better 1000) different cookies, and average the times, >>> that the results will be less erratic (it would also be great >>> to measure the deviation of times for each level, not only average). From nobody Fri Jan 30 05:38:03 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 1CDB31A0203 for ; Fri, 30 Jan 2015 05:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzFqQhYizTAX for ; Fri, 30 Jan 2015 05:37:59 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A4A1A01F2 for ; Fri, 30 Jan 2015 05:37:59 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id fb4so2705140wid.2 for ; Fri, 30 Jan 2015 05:37:58 -0800 (PST) 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=JneppjNj2zBYRNic1Ty/qXKTcFbsgmwgcgvlO0P0YbA=; b=jnisMS5o4erjZ06qnCUFDwsVUCnSLJt0lCFaSGE+1zYEtp6z43zvrwMIuM0VRWmVos WD4YSe48JkS3tCXhz3MrAZetKPhwretHgPlikdFASNmj1J6eVDxplkSsAdpo5IDbnYFA Iyk9MlAuG6Vco2kKLufMN0tguqWKf14qf3gnjmoPaNQPEQP6WbYD1shnBItlfl3f9zw2 faTN3CTsE7IahVZpbwf2MZ4/Hogqt4sauESmJh/2z8Z3uKGd3bk1aMLBzonyWXrMNm36 MW/GEyCXyMVUADcf7eufdXXh6RCkWR4ClmrYWyVof0ZvlJdcaBZwN11DwlGrP8AI5pNO zonw== X-Received: by 10.194.187.235 with SMTP id fv11mr12352394wjc.16.1422625077162; Fri, 30 Jan 2015 05:37:57 -0800 (PST) Received: from [10.0.0.4] (bzq-79-183-189-199.red.bezeqint.net. [79.183.189.199]) by mx.google.com with ESMTPSA id z6sm6979515wix.20.2015.01.30.05.37.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jan 2015 05:37:56 -0800 (PST) Message-ID: <54CB8932.8010406@gmail.com> Date: Fri, 30 Jan 2015 15:37:54 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yoav Nir , Valery Smyslov References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 30 Jan 2015 13:38:02 -0000 What I would suggest is: we give the client a single puzzle, and ask it to return 16 different solutions. Indeed each puzzle then should be 16X easier. The nice thing is, the server should only check *one* of them, at random. The client would still need to solve all of them because it doesn't want to risk the exchange being rejected because some solutions are invalid (the game theory is probably more complex than that, but I think what I'm saying is still close to the truth). So: the client does the same amount of work, the server does the same amount of work, but the client run-time is still much more deterministic. Thanks, Yaron On 01/30/2015 02:42 PM, Yoav Nir wrote: > I’ll try that later, but suppose we give the client 16 puzzles to solve, > then we expect solving all of them to take 16 times as long, so they can > be 16 times easier. So instead of 22 bits, they can be 18 bits. I’m not > sure if that increased the chance of getting “stung” by a bad outlier or > that it averages better. > > But one effect is obvious. If we require the client to solve all > puzzles, the server has to check all 16 parts of the solution, and that > makes it 16x harder for the server. > > OTOH if we required to solve just one of the 16, the client could try > all 16 at the same time, and have a better chance of finding a “good” > outlier. Again, I’m not sure which is the dominant effect. > > Yoav > >> On Jan 30, 2015, at 1:27 PM, Valery Smyslov > > wrote: >> >> Hi, >> I also had some concerns on the variance of the times. But then >> another thought came to me. Let's look on this issue from the other side. >> The responder will use puzzles only when it feels that it is under attack. >> It means, that there are a lot of (thouthands, tens of thouthands) >> half-open connections. If responder requests that number of puzzles, >> then some of them will appear to be easier to solve than the others. >> Every initiator is different from another in terms of computing power and >> each of them may receive more or less hard puzzle. >> It's like an exam - some tasks are more easy to solve, some are harder. >> Some clients will be more lucky, some less. That's a lottery. >> But all those differences will be averaged for the responder, so why >> bother? >> Also if we require initiator to solve several puzzles, than it will need >> to send back all the solutions, that will noticeably increase >> IKE message size. >> So, while the idea is interesting, I think that the problem it solves >> is not important, so why should we bother? >> But it would be nice, if Yoav (as a person who already has >> test bed) could check, that if we solve puzzle for 100 >> (or better 1000) different cookies, and average the times, >> that the results will be less erratic (it would also be great >> to measure the deviation of times for each level, not only average). >> Regards, >> Valery. >>> ----- Original Message ----- >>> *From:* Yoav Nir >>> *To:* Yaron Sheffer >>> *Cc:* IPsecME WG >>> *Sent:* Friday, January 30, 2015 2:41 AM >>> *Subject:* Re: [IPsec] DDoS puzzle: PRF vs Hash >>> >>> Interesting. I’ve tried with a few different “cookies”. >>> >>> Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4 >>> Key=…00003db1 PRF=…4c82f8b80000 #zeros=19 time=0.025 >>> Key=…0002ea6c PRF=…5faafb800000 #zeros=23 time=0.250 >>> Key=…0124159c PRF=…9136e5000000 #zeros=24 time=26.013 >>> >>> Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b028f8c18b1 >>> #zeros=14 time=0.016 >>> #zeros=15 time=0.035 >>> #zeros=19 time=0.134 >>> #zeros=20 time=0.837 >>> #zeros=21 time=1.932 >>> #zeros=22 time=5.646 >>> #zeros=24 time=16.790 >>> #zeros=27 time=17.477 >>> >>> Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f >>> #zeros=15 time=0.016 >>> #zeros=17 time=0.434 >>> #zeros=21 time=1.034 >>> #zeros=22 time=1.230 >>> #zeros=23 time=16.213 >>> #zeros=24 time=25.554 >>> #zeros= >>> >>> Seems like the big issue here is inconsistency. Set the puzzle level >>> to 22 bits, and it could be solved in a quarter second or in 5.6 >>> seconds or in 1.230. And these are not just outliers - they’re the >>> first three values I picked at this length. >>> >>> 20 bits seems an acceptable difficulty level, but beyond that it >>> becomes too erratic. >>> >>> Yoav >>> >>>> On Jan 29, 2015, at 11:57 PM, Yaron Sheffer >>> > wrote: >>>> >>>> Looking at the timing table, there is obviously significant variance >>>> in the time to solve each puzzle, compared to the ideal exponential >>>> curve. For example, for 28 bits we have 250s, whereas for 29 bits >>>> it's 1240s. >>>> >>>> Would it make sense to require the initiator to return 4 or 8 solved >>>> puzzles of the given strength? Of course, the responder would >>>> request 2-3 bits of strength less. The net effect should be a lower >>>> variance in run times, i.e. more deterministic run time for any >>>> particular type of client. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 01/29/2015 11:27 PM, Yoav Nir wrote: >>>>> Hi all. >>>>> >>>>> Following Valery’s suggestion, I’ve created a pull request for >>>>> replacing >>>>> the puzzle mechanism: >>>>> >>>>> OLD: appending a string to the cookie so that the hash of the extended >>>>> string has enough zero bits at the end. >>>>> NEW: finding a PRF key such that PRF(k, cookie) has enough zero bits at >>>>> the end. >>>>> >>>>> The source files and change are available at >>>>> https://github.com/ietf-ipsecme/drafts/pull/3 >>>>> >>>>> The relevant section is appended below >>>>> >>>>> Please let us know what you think. Also about Valery’s pull request >>>>> about negotiation. >>>>> >>>>> Yoav >>>>> >>>>> 3. Puzzles >>>>> >>>>> The puzzle introduced here extends the cookie mechanism from RFC >>>>> 7296. It is loosely based on the proof-of-work technique used in >>>>> BitCoins ([bitcoins]). Future versions of this document will have >>>>> the exact bit structure of the notification payloads, but for now, I >>>>> will only describe the semantics of the content. >>>>> >>>>> A puzzle is sent to the Initiator in two cases: >>>>> >>>>> o The Responder is so overloaded, than no half-open SAs are allowed >>>>> to be created without the puzzle, or >>>>> o The Responder is not too loaded, but the rate-limiting in >>>>> Section 5 prevents half-open SAs from being created with this >>>>> particular peer address or prefix without first solving a puzzle. >>>>> >>>>> When the Responder decides to send the challenge notification in >>>>> response to a IKE_SA_INIT request, the notification includes three >>>>> fields: >>>>> >>>>> 1. Cookie - this is calculated the same as in RFC 7296. As in RFC >>>>> 7296, the process of generating the cookie is not specified. >>>>> 2. Algorithm, this is the identifier of a PRF algorithm, one of >>>>> those proposed by the Initiator in the SA payload. >>>>> 3. Zero Bit Count. This is a number between 8 and 255 that >>>>> represents the length of the zero-bit run at the end of the >>>>> output of the PRF function calculated over the Keyed-Cookie >>>>> payload that the Initiator is to send. Since the mechanism is >>>>> supposed to be stateless for the Responder, the same value is >>>>> sent to all Initiators who are receiving this challenge. The >>>>> values 0 and 1-8 are explicitly excluded, because the value zero >>>>> is meaningless, and the values 1-8 create a puzzle that is too >>>>> easy to solve for it to make any difference in mitigating DDoS >>>>> attacks. >>>>> >>>>> Upon receiving this challenge payload, the Initiator attempts to >>>>> calculate the PRF using different keys. When a key is found such >>>>> that the resulting PRF output has a sufficient number of trailing >>>>> zero bits, that result is sent to the Responder in a Keyed-Cookie >>>>> notification, as described in Section 3.1. >>>>> >>>>> When receiving a request with a Keyed-Cookie, the Responder verifies >>>>> two things: >>>>> >>>>> o That the cookie part is indeed valid. >>>>> o That the PRF of the transmitted cookie calculated with the >>>>> transmitted key has a sufficient number of trailing zero bits. >>>>> >>>>> Example 1: Suppose the calculated cookie is >>>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm >>>>> is HMAC-SHA256, and the required number of zero bits is 18. After >>>>> successively trying a bunch of keys, the Initiator finds that >>>>> the key >>>>> that is all-zero except for the last three bytes which are 02fc95 >>>>> yields HMAC_SHA256(k, cookie) = >>>>> 843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c580000, >>>>> which has 19 trailing zero bits, so it is an acceptable solution. >>>>> >>>>> Example 2: Same cookie, but this time the required number of zero >>>>> bits is 22. The first key to satisfy that requirement ends in >>>>> 960cbb, which yields a hash with 23 trailing zero bits. Finding >>>>> this >>>>> requires 9,833,659 invocations of the PRF. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Fri Jan 30 14:35:23 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 A2DED1A1A67 for ; Fri, 30 Jan 2015 14:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEgaCb0zNcIZ for ; Fri, 30 Jan 2015 14:35:17 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C93F1A86E4 for ; Fri, 30 Jan 2015 14:35:17 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id l61so29572509wev.13 for ; Fri, 30 Jan 2015 14:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1/Wh4DC/jfinr/i8rYf/Cyd7ysnyP9yJbMCTAcWqtqI=; b=Y95jHzefefsCnXxw02YpT0S+kZ4zeb696TZVtipSYsuxgS9xSgYb8okPqnxLtETvzC NMerTf4PRlL5VdXLicMsdeVRv21qc4IxOFvbNzDh8vY6UPf2ioZrm31x7hoK1PsqkG8l FhvUW7IfsroU5CBeB5tJaDV2+FOPpoLL+0wOxZeq4w6kg3aOEJKIqDeXNIk+FzKumXp3 NsrGoMSOwbxNhoYIvZ0Dr7P6M4x1bnNHugaHiWvGivMkz1RNiCDZZptfDNVu7/+ljVT0 mUt14K/PeLD/LvHQCv56ImaLIyUcAxh3lpxUxO9cjCuwB5NUj6FgjtFEnn+xpi9NydE+ CLHw== X-Received: by 10.194.88.131 with SMTP id bg3mr15964349wjb.99.1422657315772; Fri, 30 Jan 2015 14:35:15 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id hz9sm16769120wjb.17.2015.01.30.14.35.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 14:35:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <54CB8932.8010406@gmail.com> Date: Sat, 31 Jan 2015 00:35:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CAACAF.60806@gmail.com> <44373351-D8EB-454F-8BCC-8CD5CD0C32E2@gmail.com> <1DFDD936EE8A4C08BBCD6621F93D1D8F@buildpc> <54CB8932.8010406@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash 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, 30 Jan 2015 22:35:19 -0000 > On Jan 30, 2015, at 3:37 PM, Yaron Sheffer = wrote: >=20 > What I would suggest is: we give the client a single puzzle, and ask = it to return 16 different solutions. Indeed each puzzle then should be = 16X easier. The nice thing is, the server should only check *one* of = them, at random. The client would still need to solve all of them = because it doesn't want to risk the exchange being rejected because some = solutions are invalid (the game theory is probably more complex than = that, but I think what I'm saying is still close to the truth). >=20 > So: the client does the same amount of work, the server does the same = amount of work, but the client run-time is still much more = deterministic. OK, I=E2=80=99ve tried that.=20 But first, I found an inefficiency in my code, so I=E2=80=99ve fixed it = and ran the tests again. Here are the results: cookie set #bits 1 2 3 =20 =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D 15 0.016 16 0.031 0.065 0.057 17 0.087 0.820 0.250 18 0.289 19 0.420 20 5.965 0.401 21 14.055 0.916 22 19.065 2.074 23 23.753 3.067 6.688 24 5.414 48.045 25 29.924 26 60.088 130.753 27 28 87.437 29 111.921 So still pretty much all over the place. So I tried Yaron=E2=80=99s = suggestion of calculating until I find 16 keys that produce at least so = many zero bits. Here are the results for 16 keys each time: cookie set #bits 1 2 3 4 =20 =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D 15 0.780 0.954 0.678 0.778 16 1.734 2.056 1.575 1.162 17 3.090 4.161 2.932 2.832 18 4.981 7.463 4.766 4.380 19 11.612 10.069 14.525 8.486 20 22.789 21.111 30.961 24.146=20 21 40.066 39.875 57.930 53.785 22 92.264 116.453 123.352 139.584 Note that these are still single core results, and most laptops can do = twice or four times as much. Now, I know that what I SHOULD be doing is = to randomly generate 100 =E2=80=9Ccookies=E2=80=9D and then calculate = the times for different bit lengths for each of them, and then calculate = mean and standard deviation. But just by looking, it looks like it=E2=80=99= s much closer to what we want. 16 bits would be a fine puzzle level for = my laptop. No idea about a phone, although I could try to compile this = and run it on an ARM-based appliance, which should match phones. Yoav =20