From anonsec-bounces@postel.org Thu Jan 03 08:58:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAQaZ-0008Gs-FI for btns-archive-waDah9Oh@lists.ietf.org; Thu, 03 Jan 2008 08:58:27 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAQaZ-00088n-4i for btns-archive-waDah9Oh@lists.ietf.org; Thu, 03 Jan 2008 08:58:27 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m03DmCVg029937; Thu, 3 Jan 2008 05:48:12 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m03Dm4JN029877 for ; Thu, 3 Jan 2008 05:48:05 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 09B014817; Thu, 3 Jan 2008 08:48:03 -0500 (EST) From: Sam Hartman To: anonsec@postel.org Date: Thu, 03 Jan 2008 08:48:03 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Subject: [anonsec] Please submit a new draft with the minor corrections I asked for X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Authors, if a new version of the core draft can be submitted with the two corrections I requested then I can place it on the agenda of the next IESG telechat. It would need to happen today or tomorrow. If it is not on next week's telechat then it may end up waiting until I return from paternity leave. _______________________________________________ From anonsec-bounces@postel.org Thu Jan 03 12:09:05 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATZ3-0006rM-RO for btns-archive-waDah9Oh@lists.ietf.org; Thu, 03 Jan 2008 12:09:05 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JATZ3-00034y-DV for btns-archive-waDah9Oh@lists.ietf.org; Thu, 03 Jan 2008 12:09:05 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m03H0icm008045; Thu, 3 Jan 2008 09:00:45 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m03Gxc9i007270 for ; Thu, 3 Jan 2008 08:59:39 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 22so7276036fkq.13 for ; Thu, 03 Jan 2008 08:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:to:message-id:sender; bh=iN3qionJyJ0KITZg5zYWl+eOtSPsJ/gfLLENqGWwx0w=; b=eLUwgKNdGcx1iNoeXPm5NVO8k3uGMtQEAKTPk2UfPwf+3m4pdjxl/SzZL8ihum7/aZCTi+otUqCgQMgcPgUDtgdWOTG3WMuw+p4h4uLHC0NAUDIAu56Yo+ZDfDvGMz/3Ai/upQNe3sUBt6IJv0LjbWTukJiF1DpboAL2AnxkBvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:to:message-id:sender; b=HhJ255xWNMIjQE3q5Lyn7q9D2yirn9WBMpD4YonkpkyA65uqlP9yuTPX4GGeio/MOFhFgLsCQNXyvVnhISqXfFqW6ZWmx5uqDV0jBy0RnT9bpcTSVZx13wP+AF+EWCEFsEoRfL5nZG3RiKjtm1uKR6Fahvy8nCT5Q9nIlKojSlI= Received: by 10.82.174.20 with SMTP id w20mr28015233bue.21.1199379577027; Thu, 03 Jan 2008 08:59:37 -0800 (PST) Received: from klee.local ( [88.138.190.25]) by mx.google.com with ESMTPS id w7sm47204267mue.0.2008.01.03.08.59.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2008 08:59:35 -0800 (PST) From: Julien Laganier Date: Thu, 3 Jan 2008 17:59:17 +0100 User-Agent: KMail/1.9.6 Cc: anonsec@postel.org References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline To: "Undisclosed.Recipients": ; Message-Id: <200801031759.19353.julien.IETF@laposte.net> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: julien.laganier@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m03Gxc9i007270 Subject: [anonsec] LC: draft-ietf-btns-core (Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec) to Proposed Standard X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 That note was sent to the list but dropped. Here it comes. --julien ---------------------------------------------------------------- The IESG has received a request from the Better-Than-Nothing Security WG (btns) to consider the following document: - 'Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec ' =A0 =A0 as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. =A0Please send substantive comments to the ietf@ietf.org mailing lists by 2008-01-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-btns-core-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D14291&rfc_flag=3D0 _______________________________________________ From anonsec-bounces@postel.org Thu Jan 03 13:18:33 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAUeH-00015w-BP for btns-archive-waDah9Oh@lists.ietf.org; Thu, 03 Jan 2008 13:18:33 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAUeG-0004Mq-VD for btns-archive-waDah9Oh@lists.ietf.org; Thu, 03 Jan 2008 13:18:33 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m03ICvQT004072; Thu, 3 Jan 2008 10:12:57 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m03IBYLO003462 for ; Thu, 3 Jan 2008 10:11:35 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e21so2816367fga.13 for ; Thu, 03 Jan 2008 10:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=tnQnM1vPb4J7ssZWrNTnWal/8jLnUVoe4hqpMqmVI7M=; b=mmXkkBI0CyxheTTmFbDPZYK/wcph4ZhmHizr/QNOIotU39T07YKUboCQKKZbW3mDpB8JwfXyL4QYkbsCup+E6Y6YgmpBV8/M4lK+Ps7WrFMbCRtRciaqeXIjMFvyUfZjM5GPdLQOvcu6nvmniLLlybUxingICPCP9k8Mc5W89NU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ciugof7DU0+o9modm5dlo1Mhydf8j7Upw8dkQ9LYum9h6up94jrRJ6xkVCwXte3yLAOMHB4WOjWI0qYMylyksyqrOAaqGhJ8szFoG7IxT8uZGnrUFFNHqiFPH2EnjsLVbbC42eawjjuqwPgpGq/vekxE+elk+XlsXVVTI4r6oLE= Received: by 10.86.60.7 with SMTP id i7mr7131721fga.40.1199383893675; Thu, 03 Jan 2008 10:11:33 -0800 (PST) Received: from klee.local ( [88.138.190.25]) by mx.google.com with ESMTPS id d6sm17888172fga.0.2008.01.03.10.11.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2008 10:11:32 -0800 (PST) From: Julien Laganier To: anonsec@postel.org Date: Thu, 3 Jan 2008 19:11:28 +0100 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200801031911.28708.julien.IETF@laposte.net> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: julien.laganier@gmail.com Cc: Love =?iso-8859-15?q?H=F6rnquist_=C5strand?= Subject: Re: [anonsec] Please submit a new draft with the minor corrections I asked for X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On Thursday 03 January 2008, Sam Hartman wrote: > Authors, if a new version of the core draft can be submitted with the > two corrections I requested then I can place it on the agenda of the > next IESG telechat. It would need to happen today or tomorrow. If > it is not on next week's telechat then it may end up waiting until I > return from paternity leave. I contacted Nico and he said he will try to meet the deadline. Let's wait and see. --julien _______________________________________________ From anonsec-bounces@postel.org Fri Jan 04 01:01:34 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAfcc-00029X-EC for btns-archive-waDah9Oh@lists.ietf.org; Fri, 04 Jan 2008 01:01:34 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAfcc-00081E-0z for btns-archive-waDah9Oh@lists.ietf.org; Fri, 04 Jan 2008 01:01:34 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m045qMsv021166; Thu, 3 Jan 2008 21:52:22 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m045pgYt021033 for ; Thu, 3 Jan 2008 21:51:43 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m045pgMh010659 for ; Fri, 4 Jan 2008 05:51:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m045pgFW053220 for ; Thu, 3 Jan 2008 22:51:42 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m045pfx1027737; Thu, 3 Jan 2008 23:51:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m045pflb027736; Thu, 3 Jan 2008 23:51:41 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Jan 2008 23:51:41 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20080104055141.GK22538@Sun.COM> Mail-Followup-To: Sam Hartman , anonsec@postel.org References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] AD review comments on draft-ietf-btns-core X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Thu, Dec 20, 2007 at 03:25:07PM -0500, Sam Hartman wrote: > > > Hi. I've sent the core document to last call. It was not as readable > as I would like. If you get a bunch of comments back from people who > do not understand you probably should take a style and readability > pass. > > I have two changes I'd like te request as last call comments myself. > > First, when you require bare RSA cert payloads, please reference a > specific section of the IKE V2 spec for a definition of this. Also, OK (RFC4306, section 3.6). > how can BTNS work with DSA if nodes are required to include RSA > payloads? A bare DSA payload would have to be defined. We could change the language to require the use of a bare public key payload and point out that currently there is only a bare RSA key payload. > Please replace the statement in section 4.2 that leap of faith is > being handled by BTNS with a statement that it is an item for future > work. This is already done in -05. I'll make the other changes and post -06. _______________________________________________ From anonsec-bounces@postel.org Fri Jan 04 02:02:08 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAgZE-0001Zp-PC for btns-archive-waDah9Oh@lists.ietf.org; Fri, 04 Jan 2008 02:02:08 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAgZE-0000b5-7s for btns-archive-waDah9Oh@lists.ietf.org; Fri, 04 Jan 2008 02:02:08 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m046AbS5026030; Thu, 3 Jan 2008 22:10:37 -0800 (PST) Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m046A29p025617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 3 Jan 2008 22:10:03 -0800 (PST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 24C1A2AB68; Fri, 4 Jan 2008 06:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JAfkn-0007ID-Vs; Fri, 04 Jan 2008 01:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 04 Jan 2008 01:10:01 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ietf@ietf.org Cc: anonsec@postel.org Subject: [anonsec] I-D Action:draft-ietf-btns-core-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF. Title : Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec Author(s) : N. Williams, M. Richardson Filename : draft-ietf-btns-core-06.txt Pages : 16 Date : 2008-01-04 This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-btns-core-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-btns-core-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-btns-core-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-04010410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-btns-core-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-04010410.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --NextPart-- From anonsec-bounces@postel.org Mon Jan 07 15:26:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByYN-00046c-0d for btns-archive-waDah9Oh@lists.ietf.org; Mon, 07 Jan 2008 15:26:35 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JByYL-00088b-Ar for btns-archive-waDah9Oh@lists.ietf.org; Mon, 07 Jan 2008 15:26:34 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07KIb1q006583; Mon, 7 Jan 2008 12:18:37 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m07KHf5l006168 for ; Mon, 7 Jan 2008 12:17:42 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JByPl-0004ZT-4z; Mon, 07 Jan 2008 15:17:41 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 7 Jan 2008 15:18:09 -0500 To: ietf@ietf.org, anonsec@postel.org From: Stephen Kent X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kent@bbn.com Subject: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is not well structured, i.e., in many places it rambles. The document has more of an architectural framework feel to it than the title suggests. It spends too much time saying how BTNS will work, rather than focusing on the nominal topic of the document, i.e., the problem to be solved and the anticipated applicability of the solution. It never provides a clear, concise characterization of the problem to be solved, and why the functionality offered by BTNS-IPsec is the preferred way to solve the problem. (I believe this problem arises because, from the beginning, there were been multiple, independent motivations for the BTNS work and the WG never reconciled them.) There seem to be two types of problems/solutions that motivate BTNS, both starting with the assumption that use of IPsec is the goal (an assumption that needs to be justified itself, as noted below). The solutions are presented before examples of the problems, which does not help matters, but I'll characterize the problems in terms of the solutions, in keeping with the style of the I-D: - creating IPsec/IKE SAs w/o authentication, for use in contexts where it is perceived that IPsec is not used because the effort to deploy an authentication infrastructure compatible with IKE is too great a burden AND the confidentiality and integrity offered by unauthenticated SAs is "better than nothing." Since IKE supports use of passwords, this presumes that the threshold for what constitutes too great a burden is pretty low, but this is not explicitly stated. Also, the BGP use case was disputed, when this work started, and has proven to be a bad example given continuing developments, but it persists in the document. There is also a not-well-articulated argument that TLS/DTLS is not a suitable alternative, presumably because those protocols do not protect the transport protocol per se. It's true that IPsec does a better job here, but the need for using it (vs. TLS) in such circumstances does not seem to be widely accepted. - creating IPsec/IKE SAs w/o authentication, for use in contexts where an application will perform its own authentication, but wants the layer 3 confidentiality, integrity and continuity of authentication offered by ESP. Here a critical part of the argument is that these applications cannot use the authentication provided by IKE, but the explanation for this is poor. For example there is no recognition of the use of EAP authentication methods with IKE. The text also does not address the possibility that a suitable API could allow an application to acquire and track the ID asserted during an IKE exchange, in lieu of the unauthenticated SA approach that is being motivated. The document fails to introduce important concepts like continuity of authentication and channel binding near the beginning. If leap of faith authentication is important enough to be included, then it too needs to be described early in the document. The document never provides a clear, concise definition of channel binding, and the definition of LoF is mostly by example. The failure to define these terms early in the document leads to ambiguity and confusion in the problem statement sections. Several of the examples provided in the applicability section do not seem congruent with security efforts in the relevant areas. I mentioned the BGP connection example above, which is even less relevant today, given the ongoing TCPM work on TCP-AO. There is also an assertion that BTNS-IPsec is a good way to protect VoIP media, yet the RTP folks never believed that and the RAI area has recently reaffirmed its commitment to use of SRTP for this purpose, with DTLS for key management. Another questionable example is the suggestion to use both BTNS-IPsec and TLS to protect client/server connections against TCP RST attacks. This is theoretically a valid use of BTNS-IPsec, but there is no indication that web server operators believe this is a "necessary" capability, as the I-D argues. The security considerations section is too long, mostly because much of the material should be earlier, e.g., the CB discussion. One might also move the rekeying attack example (which I expanded to be more accurate) to the CB document, and just reference the notion here. I am unable to attach a copy of the I-D, with MS Word charge tracking for detailed comments and edits, because it is too big for these lists. A copy of that file was sent to tge cognizant Security AD, WG chairs, and authors. Steve _______________________________________________ From anonsec-bounces@postel.org Tue Jan 08 12:19:20 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI6i-0001P6-Tu for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 12:19:20 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCI6h-0004JH-H8 for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 12:19:20 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08HFQAM016162; Tue, 8 Jan 2008 09:15:27 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08GnQBM007199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Jan 2008 08:49:27 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08GnOfQ002866; Tue, 8 Jan 2008 11:49:24 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Tue, 8 Jan 2008 11:49:24 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08GnC5U008691; Tue, 8 Jan 2008 11:49:22 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 11:22:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jan 2008 11:22:54 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) thread-index: AchSErkdc2O0+mHIRCeV3hdoNbnnfw== To: , X-OriginalArrivalTime: 08 Jan 2008 16:22:55.0133 (UTC) FILETIME=[B94624D0:01C85212] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REFNUM 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: black_david@emc.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m08GnQBM007199 Cc: Black_David@emc.com Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 This message is an attempt to kill two review "birds" with one email "stone" - I meant to review the connection latching draft some time ago, and in addition, this is a transport directorate review of the connection latching draft. For the latter purpose, the following paragraph applies: - I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The result is a mix of transport and security comments in this email - the transport ADs should pay particular attention to the service-orientation and NAT comments. In general, this is a good draft, and I think it should go forward. -- Service Orientation The introduction considerably undersells the architectural impact of this draft. IPsec architecture has been based on inclusion of a logical firewall. This results in the configuration of security services being somewhat disconnected from the higher level protocols and applications that benefit from those services by the use of the SPD to configure the logical firewall (see Sections 3 and 3.1 of RFC 4301). This disconnection has been an important feature of IPsec, as it has enabled consistent application of security policy to all traffic crossing an IPsec boundary (e.g., to/from a specific network node, to/from an otherwise unprotected [untrusted] network at a network node), but it has made use of IPsec by higher layer applications and protocols more difficult because application usage requests for IPsec have to be expressed in terms of a firewall-like configuration through an API of some form, and conflicts are possible. The connection latching draft is aimed at precisely this gap between effective application usage and the logical firewall architecture of IPsec; in essence, the draft is defining the functional service interface through which higher layer applications and protocols should be obtaining IPsec services for themselves instead of setting up SPD (and possibly PAD) entries directly. This change from logical firewall orientation to service orientation is (IMHO) an important step towards making IPsec effectively usable for protocols such as iSCSI and NFSv4, and should be explained in the Introduction of this draft. -- NATs p.5 says: o Implementations that provide such programming interfaces SHOULD make available to applications any available NAT-related information about the peer: whether it is behind a NAT and, if it is, the inner and outer tunnel addresses of the peer. Is that serious? I don't think inflicting NAT awareness on additional protocols and applications is a good idea unless it's absolutely necessary (i.e., protocol/app won't work through a NAT that it doesn't know about). In general, IPsec NAT traversal ought to work transparently with respect to connection latching, and (IMHO), this transparency should be the preferred approach whenever feasible. -- Key Manager/Key Management The draft talks about a key manager. It should state what functions the key manager is performing with respect to the IPsec architecture (RFC 4301). While IKEv2 would clearly be inside the key manager, where is responsibility for the SPD and PAD placed and/or how is that responsibility divided? While not exactly key management, how does connection latch state lifetime relate to the lifetime of the IKE_SA for the latched SA? This is the infamous "dangling SAs" issue applied to connection latch state. I think that connection latch state does not survive termination without replacement of the IKE_SA (e.g., key management entity containing IKE/IKEv2 implementation crashes), but ought to survive replacement of the IKE_SA. In any case, this topic needs to be covered. -- Nits idnits 2.05.03 found a bunch of nits, mostly in the references. tmp/draft-ietf-btns-connection-latching-04.txt: Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: ------------------------------------------------------------------------ ---- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ------------------------------------------------------------------------ ---- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/ID-Checklist.html: ------------------------------------------------------------------------ ---- No issues found here. Miscellaneous warnings: ------------------------------------------------------------------------ ---- == The copyright year in the IETF Trust Copyright Line does not match the current year Checking references for intended status: Proposed Standard ------------------------------------------------------------------------ ---- (See RFC 3967 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC4322' is defined on line 642, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-btns-abstract-api' (No intended status found in state file of draft-ietf-btns-abstract-api) == Outdated reference: A later version (-06) exists of draft-ietf-btns-core-05 == Outdated reference: A later version (-06) exists of draft-ietf-btns-prob-and-applic-05 ** Downref: Normative reference to an Informational draft: draft-ietf-btns-prob-and-applic (ref. 'I-D.ietf-btns-prob-and-applic') ** Downref: Normative reference to an Informational RFC: RFC 2367 == Outdated reference: A later version (-07) exists of draft-bellovin-useipsec-06 == Outdated reference: draft-williams-on-channel-binding has been published as RFC 5056 Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ From anonsec-bounces@postel.org Tue Jan 08 16:26:38 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCLy2-0006J1-4g for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 16:26:38 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCLy1-0000RC-Bk for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 16:26:38 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08LJVr3028795; Tue, 8 Jan 2008 13:19:31 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08LIqTT028597 for ; Tue, 8 Jan 2008 13:18:53 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m08LIqGS012955 for ; Tue, 8 Jan 2008 21:18:52 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m08LIpTA046059 for ; Tue, 8 Jan 2008 14:18:52 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m08LImJq000333; Tue, 8 Jan 2008 15:18:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m08LIlMb000332; Tue, 8 Jan 2008 15:18:47 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 8 Jan 2008 15:18:47 -0600 From: Nicolas Williams To: Black_David@emc.com Message-ID: <20080108211846.GT22538@Sun.COM> Mail-Followup-To: Black_David@emc.com, anonsec@postel.org, tsv-dir@ietf.org References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, tsv-dir@ietf.org Subject: Re: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 On Tue, Jan 08, 2008 at 11:22:54AM -0500, Black_David@emc.com wrote: > This message is an attempt to kill two review "birds" with > one email "stone" - I meant to review the connection latching > draft some time ago, and in addition, this is a transport > directorate review of the connection latching draft. Thank you. > -- Service Orientation > > The introduction considerably undersells the architectural > impact of this draft. [...] I agree, ... > The connection latching draft is aimed at precisely this > gap between effective application usage and the logical > firewall architecture of IPsec; in essence, the draft is > defining the functional service interface through which > higher layer applications and protocols should be > obtaining IPsec services for themselves instead of setting > up SPD (and possibly PAD) entries directly. This change > from logical firewall orientation to service orientation is > (IMHO) an important step towards making IPsec effectively > usable for protocols such as iSCSI and NFSv4, and should > be explained in the Introduction of this draft. ... but connection latching is one of a multi-prong approach to closing that gap. The other main prong is IPsec APIs. A third, optional prong, is channel binding. I fear that to correct this undersell while the IPsec APIs documents are not complete might be to oversell the architectural impact of this document. Comments? > -- NATs > > p.5 says: > > o Implementations that provide such programming interfaces > SHOULD make available to applications any available > NAT-related information about the peer: whether it is > behind a NAT and, if it is, the inner and outer tunnel > addresses of the peer. > > Is that serious? I don't think inflicting NAT awareness on > additional protocols and applications is a good idea unless > it's absolutely necessary (i.e., protocol/app won't work through > a NAT that it doesn't know about). In general, IPsec NAT > traversal ought to work transparently with respect to > connection latching, and (IMHO), this transparency should > be the preferred approach whenever feasible. Well, does it hurt to have this? I suppose this could be a MAY, if implementors object (or it could be downgraded to MAY or removed altogether when in the progression to Standard). I don't feel too strongly about it, but I also don't feel too strongly about discouraging the use of NATs (face it: NATs are here to stay, at least in the IPv4 world). > -- Key Manager/Key Management > > The draft talks about a key manager. It should state what > functions the key manager is performing with respect to the > IPsec architecture (RFC 4301). While IKEv2 would clearly > be inside the key manager, where is responsibility for the > SPD and PAD placed and/or how is that responsibility divided? RFC4301 does not speak of a key manager, but does speak of key management -- see section 4.5. I'll clarify in the I-D, and here: the key manager is the part of the implementation that manages the SAD. The KE protocols (IKEv2, KINK, ...) are associated with the key manager, but what really matters here is the component of the system through which all SAD updates are done. > While not exactly key management, how does connection latch > state lifetime relate to the lifetime of the IKE_SA for the > latched SA? It doesn't. > This is the infamous "dangling SAs" issue > applied to connection latch state. What is this infamous issue? > I think that connection > latch state does not survive termination without replacement > of the IKE_SA (e.g., key management entity containing > IKE/IKEv2 implementation crashes), but ought to survive > replacement of the IKE_SA. In any case, this topic needs to > be covered. It is absolutely desirable that connection latch state survive IKE_SA and even child SA expiration. The document does describe latch termination, but -05 will do so in much more detail. Basically a latch terminates when the ULP requests it (which may be when the application requests it, or when an RST is received protected by a suitable SA) and, in the normative model, whenever the key manager adds an SA to the SAD which conflicts with the latch. > -- Nits > > ---- > > == No 'Intended status' indicated for this document; assuming Proposed > Standard Thanks. I'll fix this. > == The copyright year in the IETF Trust Copyright Line does not match > the > current year It matches the year in which it was submitted. -05 will be submitted in 2008, so its IETF Trust Copyright notice will say "2008." > (See RFC 3967 for information about using normative references to > lower-maturity documents in RFCs) > > == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632, > but no > explicit reference was found in the text If I correct the "undersell" then there will definitely be a mention of bellovin-useipsec! > == Unused Reference: 'RFC4322' is defined on line 642, but no explicit > reference was found in the text Suggestions? > -- Possible downref: Normative reference to a draft: ref. > 'I-D.ietf-btns-abstract-api' (No intended status found in state > file of > draft-ietf-btns-abstract-api) That should probably be informative, yes. > == Outdated reference: A later version (-06) exists of > draft-ietf-btns-core-05 > > == Outdated reference: A later version (-06) exists of > draft-ietf-btns-prob-and-applic-05 > > ** Downref: Normative reference to an Informational draft: > draft-ietf-btns-prob-and-applic (ref. > 'I-D.ietf-btns-prob-and-applic') > > ** Downref: Normative reference to an Informational RFC: RFC 2367 > > == Outdated reference: A later version (-07) exists of > draft-bellovin-useipsec-06 > > == Outdated reference: draft-williams-on-channel-binding has been > published > as RFC 5056 Will fix. Thanks! Nico -- _______________________________________________ From anonsec-bounces@postel.org Tue Jan 08 17:43:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCNAB-0002Yd-9F for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 17:43:15 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCNAA-0001lU-6z for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 17:43:15 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08MX8Ao027717; Tue, 8 Jan 2008 14:33:09 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08MVodx027436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Jan 2008 14:31:51 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08MVmmH016871; Tue, 8 Jan 2008 17:31:48 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Tue, 8 Jan 2008 17:31:47 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08MVLTB021657; Tue, 8 Jan 2008 17:31:43 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 17:31:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jan 2008 17:31:39 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> In-Reply-To: <20080108211846.GT22538@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) thread-index: AchSPBgT47rmKQpST0uH+scIgywjkAACGVhA References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080108211846.GT22538@Sun.COM> To: X-OriginalArrivalTime: 08 Jan 2008 22:31:40.0829 (UTC) FILETIME=[3D376CD0:01C85246] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, NO_REAL_NAME 0, __CP_NAME_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REFNUM 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: black_david@emc.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m08MVodx027436 Cc: anonsec@postel.org, tsv-dir@ietf.org Subject: Re: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Nico, Some quick responses: > > -- Service Orientation > > > > The introduction considerably undersells the architectural > > impact of this draft. [...] > > I agree, ... > > ... but connection latching is one of a multi-prong approach to closing > that gap. The other main prong is IPsec APIs. A third, optional prong, > is channel binding. Describing this overall multi-prong structure and connection latching's role in it would be a "good thing" to do in the introduction and should position the connection latching draft correctly. > > -- NATs > > > > p.5 says: > > > > o Implementations that provide such programming interfaces > > SHOULD make available to applications any available > > NAT-related information about the peer: whether it is > > behind a NAT and, if it is, the inner and outer tunnel > > addresses of the peer. > > > > Is that serious? I don't think inflicting NAT awareness on > > additional protocols and applications is a good idea unless > > it's absolutely necessary (i.e., protocol/app won't work through > > a NAT that it doesn't know about). In general, IPsec NAT > > traversal ought to work transparently with respect to > > connection latching, and (IMHO), this transparency should > > be the preferred approach whenever feasible. > > Well, does it hurt to have this? I suppose this could be a MAY, if > implementors object (or it could be downgraded to MAY or removed > altogether when in the progression to Standard). > > I don't feel too strongly about it, but I also don't feel too strongly > about discouraging the use of NATs (face it: NATs are here to stay, at > least in the IPv4 world). This isn't about discouraging use of NATs; I completely agree that NATs are a fact of life for IPv4. This is about avoiding encouragement of NAT-specific code in protocols and applications that don't need it (i.e., work just fine with IPsec NAT traversal). Think of the goal as "damage containment" - it does hurt to encourage unnecessary attempts to deal with NATs. It may be ok to have the interface if the interface adds value to what apps already have to do to cope with NATs, but there should be a rationale for the added value. > > -- Key Manager/Key Management [... snip ...] > > This is the infamous "dangling SAs" issue > > applied to connection latch state. > > What is this infamous issue? Does a CHILD_SA survive termination of the IKE_SA used to create the CHILD_SA? [... snip ...] > It is absolutely desirable that connection latch state survive IKE_SA > and even child SA expiration. > > The document does describe latch termination, but -05 will do > so in much more detail. > > Basically a latch terminates when the ULP requests it (which may be when > the application requests it, or when an RST is received protected by a > suitable SA) and, in the normative model, whenever the key manager adds > an SA to the SAD which conflicts with the latch. I think that's ok, just write it up in -05, and explain why the disconnection from the IKE_SA lifetime/fate is important. I was making intelligent guesses in the absence of detail, and I guessed wrong :-). Thanks, --David > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Tuesday, January 08, 2008 4:19 PM > To: Black, David > Cc: anonsec@postel.org; tsv-dir@ietf.org > Subject: Re: [anonsec] Connection Latching draft review > (draft-ietf-btns-connection-latching-04.txt) > > On Tue, Jan 08, 2008 at 11:22:54AM -0500, Black_David@emc.com wrote: > > This message is an attempt to kill two review "birds" with > > one email "stone" - I meant to review the connection latching > > draft some time ago, and in addition, this is a transport > > directorate review of the connection latching draft. > > Thank you. > > > -- Service Orientation > > > > The introduction considerably undersells the architectural > > impact of this draft. [...] > > I agree, ... > > > The connection latching draft is aimed at precisely this > > gap between effective application usage and the logical > > firewall architecture of IPsec; in essence, the draft is > > defining the functional service interface through which > > higher layer applications and protocols should be > > obtaining IPsec services for themselves instead of setting > > up SPD (and possibly PAD) entries directly. This change > > from logical firewall orientation to service orientation is > > (IMHO) an important step towards making IPsec effectively > > usable for protocols such as iSCSI and NFSv4, and should > > be explained in the Introduction of this draft. > > ... but connection latching is one of a multi-prong approach > to closing > that gap. The other main prong is IPsec APIs. A third, > optional prong, > is channel binding. > > I fear that to correct this undersell while the IPsec APIs > documents are > not complete might be to oversell the architectural impact of this > document. > > Comments? > > > -- NATs > > > > p.5 says: > > > > o Implementations that provide such programming interfaces > > SHOULD make available to applications any available > > NAT-related information about the peer: whether it is > > behind a NAT and, if it is, the inner and outer tunnel > > addresses of the peer. > > > > Is that serious? I don't think inflicting NAT awareness on > > additional protocols and applications is a good idea unless > > it's absolutely necessary (i.e., protocol/app won't work through > > a NAT that it doesn't know about). In general, IPsec NAT > > traversal ought to work transparently with respect to > > connection latching, and (IMHO), this transparency should > > be the preferred approach whenever feasible. > > Well, does it hurt to have this? I suppose this could be a MAY, if > implementors object (or it could be downgraded to MAY or removed > altogether when in the progression to Standard). > > I don't feel too strongly about it, but I also don't feel too strongly > about discouraging the use of NATs (face it: NATs are here to stay, at > least in the IPv4 world). > > > -- Key Manager/Key Management > > > > The draft talks about a key manager. It should state what > > functions the key manager is performing with respect to the > > IPsec architecture (RFC 4301). While IKEv2 would clearly > > be inside the key manager, where is responsibility for the > > SPD and PAD placed and/or how is that responsibility divided? > > RFC4301 does not speak of a key manager, but does speak of key > management -- see section 4.5. I'll clarify in the I-D, and here: the > key manager is the part of the implementation that manages > the SAD. The > KE protocols (IKEv2, KINK, ...) are associated with the key > manager, but > what really matters here is the component of the system through which > all SAD updates are done. > > > While not exactly key management, how does connection latch > > state lifetime relate to the lifetime of the IKE_SA for the > > latched SA? > > It doesn't. > > > This is the infamous "dangling SAs" issue > > applied to connection latch state. > > What is this infamous issue? > > > I think that connection > > latch state does not survive termination without replacement > > of the IKE_SA (e.g., key management entity containing > > IKE/IKEv2 implementation crashes), but ought to survive > > replacement of the IKE_SA. In any case, this topic needs to > > be covered. > > It is absolutely desirable that connection latch state survive IKE_SA > and even child SA expiration. > > The document does describe latch termination, but -05 will do > so in much > more detail. > > Basically a latch terminates when the ULP requests it (which > may be when > the application requests it, or when an RST is received protected by a > suitable SA) and, in the normative model, whenever the key > manager adds > an SA to the SAD which conflicts with the latch. > > > -- Nits > > > > ---- > > > > == No 'Intended status' indicated for this document; > assuming Proposed > > Standard > > Thanks. I'll fix this. > > > == The copyright year in the IETF Trust Copyright Line > does not match > > the > > current year > > It matches the year in which it was submitted. -05 will be > submitted in > 2008, so its IETF Trust Copyright notice will say "2008." > > > (See RFC 3967 for information about using normative > references to > > lower-maturity documents in RFCs) > > > > == Unused Reference: 'I-D.bellovin-useipsec' is defined > on line 632, > > but no > > explicit reference was found in the text > > If I correct the "undersell" then there will definitely be a > mention of > bellovin-useipsec! > > > == Unused Reference: 'RFC4322' is defined on line 642, > but no explicit > > reference was found in the text > > Suggestions? > > > -- Possible downref: Normative reference to a draft: ref. > > 'I-D.ietf-btns-abstract-api' (No intended status > found in state > > file of > > draft-ietf-btns-abstract-api) > > That should probably be informative, yes. > > > == Outdated reference: A later version (-06) exists of > > draft-ietf-btns-core-05 > > > > == Outdated reference: A later version (-06) exists of > > draft-ietf-btns-prob-and-applic-05 > > > > ** Downref: Normative reference to an Informational draft: > > draft-ietf-btns-prob-and-applic (ref. > > 'I-D.ietf-btns-prob-and-applic') > > > > ** Downref: Normative reference to an Informational RFC: RFC 2367 > > > > == Outdated reference: A later version (-07) exists of > > draft-bellovin-useipsec-06 > > > > == Outdated reference: draft-williams-on-channel-binding has been > > published > > as RFC 5056 > > Will fix. > > Thanks! > > Nico > -- > > _______________________________________________ From anonsec-bounces@postel.org Tue Jan 08 18:33:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCNxF-0000iX-H2 for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 18:33:57 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCNxE-0003F4-Vw for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 18:33:57 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08NRx76027870; Tue, 8 Jan 2008 15:28:00 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08MqFDj006821 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 8 Jan 2008 14:52:16 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m08MqDQ6023746 for ; Tue, 8 Jan 2008 22:52:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m08MqCSR028477 for ; Tue, 8 Jan 2008 15:52:13 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m08Mq8EK000488; Tue, 8 Jan 2008 16:52:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m08Mq8W8000487; Tue, 8 Jan 2008 16:52:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 8 Jan 2008 16:52:08 -0600 From: Nicolas Williams To: Black_David@emc.com Message-ID: <20080108225208.GW22538@Sun.COM> Mail-Followup-To: Black_David@emc.com, anonsec@postel.org, tsv-dir@ietf.org References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080108211846.GT22538@Sun.COM> <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, tsv-dir@ietf.org Subject: Re: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 On Tue, Jan 08, 2008 at 05:31:39PM -0500, Black_David@emc.com wrote: > > > The introduction considerably undersells the architectural > > > impact of this draft. [...] > > > > I agree, ... > > > > ... but connection latching is one of a multi-prong approach to > closing > > that gap. The other main prong is IPsec APIs. A third, optional > prong, > > is channel binding. > > Describing this overall multi-prong structure and connection > latching's role in it would be a "good thing" to do in the > introduction and should position the connection latching draft > correctly. OK, I will do so. > > > -- NATs > > > > > > p.5 says: > > > > Well, does it hurt to have this? I suppose this could be a MAY, if > > implementors object (or it could be downgraded to MAY or removed > > altogether when in the progression to Standard). > > > > I don't feel too strongly about it, but I also don't feel too strongly > > about discouraging the use of NATs (face it: NATs are here to stay, at > > least in the IPv4 world). > > This isn't about discouraging use of NATs; I completely agree > that NATs are a fact of life for IPv4. This is about avoiding > encouragement of NAT-specific code in protocols and applications > that don't need it (i.e., work just fine with IPsec NAT traversal). I think this text doesn't do that at all. Why would application developers bother to ask about NAT-related information when they already know that their app works with IPsec NAT traversal? > Think of the goal as "damage containment" - it does hurt to > encourage unnecessary attempts to deal with NATs. It may be ok > to have the interface if the interface adds value to what apps > already have to do to cope with NATs, but there should be a > rationale for the added value. But also, and more to the point, as long as we accept the existence of NATs we might as well accept the existence of protocols which need help to traverse them, and then we should accept some of the responsibility for helping them. I'd reverse your question and ask how making this information available to the application developer encourages the development of new applications that need help in order to traverse NATs. > > > -- Key Manager/Key Management > > [... snip ...] > > > > This is the infamous "dangling SAs" issue > > > applied to connection latch state. > > > > What is this infamous issue? > > Does a CHILD_SA survive termination of the IKE_SA used to create > the CHILD_SA? Right, that problem is irrelevant to connection latching as specified. That said, that problem is relevant to the construction of IPsec channel bindings. But that's a topic for a different I-D. Thanks, Nico -- _______________________________________________ From anonsec-bounces@postel.org Wed Jan 09 11:36:42 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCdv0-0004am-Io for btns-archive-waDah9Oh@lists.ietf.org; Wed, 09 Jan 2008 11:36:42 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCdv0-0004ym-2h for btns-archive-waDah9Oh@lists.ietf.org; Wed, 09 Jan 2008 11:36:42 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09GOELC006623; Wed, 9 Jan 2008 08:24:18 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m09GMcEt006253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 9 Jan 2008 08:22:40 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m09GMaWU013925; Wed, 9 Jan 2008 11:22:36 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Wed, 9 Jan 2008 11:22:36 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m09GMV1m005851; Wed, 9 Jan 2008 11:22:34 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 11:22:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jan 2008 11:22:31 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EC0@CORPUSMX20A.corp.emc.com> In-Reply-To: <20080108225208.GW22538@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) thread-index: AchSSR7GbIP9v4iXTf6o3VTmasp/CgAkkK+w References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080108211846.GT22538@Sun.COM> <8CC6CEAB44F131478D3A7B429ECACD91085EB3@CORPUSMX20A.corp.emc.com> <20080108225208.GW22538@Sun.COM> To: X-OriginalArrivalTime: 09 Jan 2008 16:22:33.0328 (UTC) FILETIME=[D6B0B700:01C852DB] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: black_david@emc.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m09GMcEt006253 Cc: anonsec@postel.org, tsv-dir@ietf.org Subject: Re: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Nico, > > > > -- NATs > > > > > > > > p.5 says: > > > > > > Well, does it hurt to have this? I suppose this could be a MAY, if > > > implementors object (or it could be downgraded to MAY or removed > > > altogether when in the progression to Standard). > > > > > > I don't feel too strongly about it, but I also don't feel too strongly > > > about discouraging the use of NATs (face it: NATs are here to stay, at > > > least in the IPv4 world). > > > > This isn't about discouraging use of NATs; I completely agree > > that NATs are a fact of life for IPv4. This is about avoiding > > encouragement of NAT-specific code in protocols and applications > > that don't need it (i.e., work just fine with IPsec NAT traversal). > > I think this text doesn't do that at all. Why would application > developers bother to ask about NAT-related information when > they already know that their app works with IPsec NAT traversal? Because there's a "SHOULD" in the standard written by people who may have more of a clue about NATs. > > Think of the goal as "damage containment" - it does hurt to > > encourage unnecessary attempts to deal with NATs. It may be ok > > to have the interface if the interface adds value to what apps > > already have to do to cope with NATs, but there should be a > > rationale for the added value. > > But also, and more to the point, as long as we accept the existence of > NATs we might as well accept the existence of protocols which need help > to traverse them, and then we should accept some of the responsibility for > helping them. > > I'd reverse your question and ask how making this information available > to the application developer encourages the development of new > applications that need help in order to traverse NATs. I hereby renew my membership in the "if in doubt, leave it out" design camp ;-). In any case, I'm ok with making the requirement a MAY, at least for now. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ From anonsec-bounces@postel.org Thu Jan 10 18:02:38 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6Q2-0002XM-Hi for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:02:38 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD6Q1-0000uI-1L for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:02:38 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0AMXO1G008218; Thu, 10 Jan 2008 14:33:25 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0AMWoMm007957 for ; Thu, 10 Jan 2008 14:32:51 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0AMWo5x018112 for ; Thu, 10 Jan 2008 22:32:50 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0AMWnKK014327 for ; Thu, 10 Jan 2008 15:32:49 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0AMWnP8002098; Thu, 10 Jan 2008 16:32:49 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0AMWmm1002097; Thu, 10 Jan 2008 16:32:48 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 10 Jan 2008 16:32:47 -0600 From: Nicolas Williams To: Black_David@emc.com Message-ID: <20080110223247.GZ810@Sun.COM> Mail-Followup-To: Black_David@emc.com, anonsec@postel.org, tsv-dir@ietf.org References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, tsv-dir@ietf.org Subject: Re: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 I've uploaded a new version, -05, that addresses most of your comments, as well as most of Dan McDonald's comments (made off-list; I'll forward those exchanges to the list, with Dan's permission, shortly). I still have some TODOs, but I wanted to submit a new version sooner, rather than later. I've made few changes to the design of connection latching, but several significant and substantive changes to the document. Design changes: - removed LARVAL state (it was imaginary) - added requirement for API option for conflict resolution: wait for the conflict to go away or break the latch - added SUSPENDED state corresponding to "wait for the conflict to go away" (see above) Text changes: - moved connection latch state into its own sub-section and greatly expanded it, including state transition details - I've not yet written a state diagram - added more text about the normative/informative model split - added text to the introduction about the significance of this work - added text on simultaneous latching (corresponding to TCP simultaneous opens) - added more text on connection latching in BITS and SG Thank you, David, and thank you, Dan, for your helpful comments! In particular, given that Dan and connection latching go back a long time (at least ten years) and that Dan had much to do with the Solaris implementation of connection latching, I now feel quite certain that this document is on track as far as the technical details are concerned. Nico -- _______________________________________________ From anonsec-bounces@postel.org Thu Jan 10 18:06:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6TY-0004U5-1w for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:06:16 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD6TX-00012f-Fp for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:06:16 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0AMV5iJ006964; Thu, 10 Jan 2008 14:31:06 -0800 (PST) Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0AMU6St006235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 10 Jan 2008 14:30:07 -0800 (PST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 72ADA175A5; Thu, 10 Jan 2008 22:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JD5uU-0000di-06; Thu, 10 Jan 2008 17:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 10 Jan 2008 17:30:02 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ietf@ietf.org Cc: anonsec@postel.org Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-05.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF. Title : IPsec Channels: Connection Latching Author(s) : N. Williams Filename : draft-ietf-btns-connection-latching-05.txt Pages : 24 Date : 2008-01-10 This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by "latching" "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. This can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. A model of of connection latching is given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-btns-connection-latching-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-btns-connection-latching-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-10172300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-btns-connection-latching-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-10172300.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --NextPart-- From anonsec-bounces@postel.org Thu Jan 10 18:53:32 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD7DI-0004f8-Au for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:53:32 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD7DF-0001hm-9x for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:53:32 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ANTJTb028824; Thu, 10 Jan 2008 15:29:19 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ANGBLs024224 for ; Thu, 10 Jan 2008 15:16:12 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0ANGA3t023510 for ; Thu, 10 Jan 2008 23:16:11 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0ANGApY036345 for ; Thu, 10 Jan 2008 16:16:10 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0ANGA4X002159; Thu, 10 Jan 2008 17:16:10 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0ANGAxS002158; Thu, 10 Jan 2008 17:16:10 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 10 Jan 2008 17:16:10 -0600 From: Nicolas Williams To: Black_David@emc.com, anonsec@postel.org Message-ID: <20080110231609.GD810@Sun.COM> Mail-Followup-To: Black_David@emc.com, anonsec@postel.org, Daniel McDonald References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20080110223247.GZ810@Sun.COM> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: Daniel McDonald Subject: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 10, 2008 at 04:32:47PM -0600, Nicolas Williams wrote: > I've uploaded a new version, -05, that addresses most of your comments, > as well as most of Dan McDonald's comments (made off-list; I'll forward > those exchanges to the list, with Dan's permission, shortly). Attached are Dan's comments and my replies. Nico -- --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dm3 >From danmcd@Sun.COM Tue Jan 8 12:23:33 2008 Date: Tue, 08 Jan 2008 13:08:17 -0500 From: Dan McDonald Subject: Pass-0 check of -05 of connection latching In-reply-to: <20080107203639.GG22538@Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080108180817.GB999@kebe.east.sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> Here are some pass-0 (first breezy read-through) comments: * The whole normative/informative split irks me... it feels like you're trying to assuage the Steve Kents of the world. (Perhaps that is its purpose?) * If this is "a description of how it works today", as mentioned on phone conversations - it's not. The draft points out what SHOULD be there, not what IS. I don't mind this quirk, but I just wanted to make sure it's not claiming to be entirely implemented in running code today. * Perhaps my first deep reading will answer this, but do you cover the unconnected datagram socket case at all? There are potential ways to convey the information latching requires on inbound datagrams and on outbound datagrams in the disconnected socket case, but It's Hard (TM) and would require XNET (aka UNIX98 or later) sockets using cmsg data. I don't know how that would fit into your informative model, never mind your normative one. * Maybe I need to re-read 4301, but I thought the SPD was a non-persistent repository, but you make it sound like it's persistent across boots... again, perhaps my next reading will make things clearer. I will be giving the document a second, deeper, reading later today or tomorrow. I may give it a third one if it's particularly bothersome, or if we arrive at any noteworthy changes. Just consider this a progress check of sorts! :) Dan >From Nicolas.Williams@sun.com Tue Jan 8 14:32:34 2008 Date: Tue, 8 Jan 2008 14:32:33 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-0 check of -05 of connection latching Message-ID: <20080108203233.GS22538@Sun.COM> References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080108180817.GB999@kebe.east.sun.com> On Tue, Jan 08, 2008 at 01:08:17PM -0500, Dan McDonald wrote: > Here are some pass-0 (first breezy read-through) comments: > > * The whole normative/informative split irks me... it feels like > you're trying to assuage the Steve Kents of the world. (Perhaps > that is its purpose?) That's partly it. I'm following the lead of RFC4301: lay out a reference model and any other model that provides equivalent security guarantees or better is OK. A model that might please the Steve Kents of the world is, in the IETF anyways, a big plus. Whether this one is such a model, I don't know -- Steve has indicated that he doesn't care to review this I-D :/ > * If this is "a description of how it works today", as mentioned on > phone conversations - it's not. The draft points out what SHOULD I'm aware. The informative section is meant to be the "how it works today" part. > be there, not what IS. I don't mind this quirk, but I just wanted > to make sure it's not claiming to be entirely implemented in > running code today. I did this primarily because a model that works for hybrid BITS/native implementations seemed desirable. Think of NICS that offload ESP/AH, like RNICs (NICs that implement the RDDP parts of iSER (iSCSI + RDDP) and NFSv4 -- iSCSI requires IPsec). Now put the firmware beyond your reach. And, to top it off, make it so that NIC doesn't tag incoming packets with information about what SAs protected them. How would you implement connection latching? The Solaris approach won't work, but the normative scheme laid out in the I-D does. Now, maybe *all* NICs with ESP/AH offload actually tag incoming packets with the SAs that protected them (and, conversely, allow the OS to tag outgoing packets with what SAs to use to protect them). With the normative model given we just don't have to ask anyone what the heck their NICs do in this regard. To switch to the Solaris model as the normative model would require asking lots of questions of people who we may not even know are building such NICs. > * Perhaps my first deep reading will answer this, but do you cover > the unconnected datagram socket case at all? There are potential > ways to convey the information latching requires on inbound > datagrams and on outbound datagrams in the disconnected socket > case, but It's Hard (TM) and would require XNET (aka UNIX98 or > later) sockets using cmsg data. I don't know how that would fit > into your informative model, never mind your normative one. It covers the connected datagram socket case but not the unconnected datagram case. I believe the only way to deal with the latter is through the informative packet-tagging model. > * Maybe I need to re-read 4301, but I thought the SPD was a > non-persistent repository, but you make it sound like it's > persistent across boots... again, perhaps my next reading will make > things clearer. The PAD (roughly svc:/network/ipsec/ike:default's config file) and SPD (roughly svc:/network/ipsec/policy:default's config file) are persistent. The SADB is dynamic and non-persisting across reboots (though you might think of manually keyed SADB entries as persistent). > I will be giving the document a second, deeper, reading later today or > tomorrow. I may give it a third one if it's particularly bothersome, or if > we arrive at any noteworthy changes. > > Just consider this a progress check of sorts! :) Thanks! Nico -- >From danmcd@sun.com Wed Jan 9 15:18:00 2008 Date: Wed, 09 Jan 2008 16:02:54 -0500 From: Dan McDonald Subject: Pass-1 review of -05 In-reply-to: <20080108203233.GS22538@Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080109210254.GD1329@sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> I said: > > I will be giving the document a second, deeper, reading later today or > > tomorrow. I may give it a third one if it's particularly bothersome, or > > if we arrive at any noteworthy changes. And here is pass 1 comments on draft-ietf-btns-connection-latching-05.txt. NOTE: Some pass 0 comments may be restated. This is merely because I didn't use different colored pens for marking up the paper copy. :) Dan ===================== (Cut up to and including here.) ===================== OVERALL ------- * Now that I understand the necessity for both normative and informative models, I actually like how both explain two different ways to solve the same problem. I like this document overall, and my comments are mostly centered around clarification and pitfall indication. * Any mention of OpenSolaris is made with two purposes. The first is to clarify to you, Nico, what's currently in OpenSolaris - since I believe you're drawing from us as a prototype connection-latching implementation. The second is to help me think about implementation issues. * The informative (packet-tagging) model isn't EXACTLY how OpenSolaris works today, and there will be several RFEs falling out of this draft, I think. I believe those RFEs should be covered in the context of RFC 430x work in OpenSolaris. * Implementations may store their various bits and pieces in different protection domains. (e.g. Our connection latches are auxiliary state to the conn_t, aka. control-block, but our certificates are in the IKE daemon.) You may need to acknowlege this fact somewhere. Per-section comments -------------------- Sec 2 I'm not very fond of the term "IPsec channel", because it's pg 4 more a "latch instance", but I can't think of a very good reason to rename it, so just consider that a bit of a style criticism you can ignore. pg 4 Latch parameters not in OpenSolaris today: Replay protection indicator Key lengths Peer identity information pg 5 Small descriptions with each state would be helpful. pg 5 You lead with "MUST NOT be sent unprotected" which seems obvious. You should probably stress "MUST match latch parameters" instead. (Applies to inbound and outbound processing bullets.) pg 6 You hint at section 3's "Optional Protection". I'll talk about that more later, but that's gonna be hard to get right, never mind specify. pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. Ours is totally centered on the IP_SEC_OPT socket option. See ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, of course, but that wasn't one of the intended uses of PF_KEY. Sec 2.1 You've encountered what we found operationally in punchin! When pg 9 a NAT is involved all hell breaks loose with mistaken SA sharing. In OpenSolaris, the only way to workaround this is to specify UNIQUE SA policies (which means an SA must be tied to an entire 5-tuple) and have the aggressive breaking of latches by closing connections. pg 9 Speaking of latch breaking, I like the idea of closing the connection in these situations. The question is, what errno gets passed up to the socket? (e.g. ECONNRESET for TCP RST packets). pg 11 Phrasing nit: say "(i.e. the tags don't appear..." instead of "(the tags don't appear...". pg 11 Explain a little more that acquiring an SA means kicking Key Management in the pants to do its thing. Not everyone thinks like PF_KEY coders. :) Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS SPD pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some level of IPsec protection. Privilege is required to BYPASS any SPD entries using what you call "optional protection". pg 14 How does one specify "meets or exceeds" the quality of protection. I believe the answer is "at the discretion of the system policy", but that's hard to implement properly. pg 14 Your last paragraph talks about updates to the SPD. That might make sense in some implementations, but today if I do "ipsecconf -ln" I don't see all of the per-socket exceptions, nor do I plan to. OpenSolaris caches SPD results in the conn_t for connected sockets. They're ALSO latched implicitly. For example, if I have specified: # Telnet needs IPsec protection { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} and then I open an outbound telnet connection, that connection uses ESP with AES and HMAC-SHA1 for its duration - even if I come along halfway through its lifetime and flush the local SPD! >From Nicolas.Williams@sun.com Wed Jan 9 15:44:01 2008 Date: Wed, 9 Jan 2008 15:44:00 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-1 review of -05 Message-ID: <20080109214400.GG810@Sun.COM> References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> <20080109210254.GD1329@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080109210254.GD1329@sun.com> On Wed, Jan 09, 2008 at 04:02:54PM -0500, Dan McDonald wrote: > OVERALL > ------- > > * Now that I understand the necessity for both normative and informative > models, I actually like how both explain two different ways to solve the > same problem. I like this document overall, and my comments are mostly > centered around clarification and pitfall indication. Thanks. And, if I may, *phew*. I like knowing that we're on the right track, and review has been so sorely missing here that I couldn't be quite sure... > * Any mention of OpenSolaris is made with two purposes. The first is to > clarify to you, Nico, what's currently in OpenSolaris - since I believe > you're drawing from us as a prototype connection-latching implementation. > The second is to help me think about implementation issues. I'll include my replies here, cc'ed to Julien, but Julien is free to ignore the OpenSolar-specific bits if he likes. > * The informative (packet-tagging) model isn't EXACTLY how OpenSolaris works > today, and there will be several RFEs falling out of this draft, I think. Yeah, I know. > I believe those RFEs should be covered in the context of RFC 430x work in > OpenSolaris. > > * Implementations may store their various bits and pieces in different > protection domains. (e.g. Our connection latches are auxiliary state to > the conn_t, aka. control-block, but our certificates are in the IKE > daemon.) You may need to acknowlege this fact somewhere. I think that's implied here: o Implementations that have a restartable key management process (or "daemon") MUST arrange for existing latched connections to either be broken and disconnected, or for them to survive the restart of key exchange processes. (This is implied by the above requirements.) IPsec state related to connection latches MUST be torn down when latched connections are torn down, even when the latter is implied, such as at crash/halt/reboot time. But I'll add something a bit more explicit. > Per-section comments > -------------------- > > Sec 2 I'm not very fond of the term "IPsec channel", because it's > pg 4 more a "latch instance", but I can't think of a very good reason to > rename it, so just consider that a bit of a style criticism you can > ignore. Yeah, well, we have the term "channel binding," which presupposes a channel. Connection latching provides an "IPsec channel" in that sense. Terminology is... painful. Different areas of the IETF use very different terminology and one cannot please everyone. The best I could do is have a glossary where every term like this one is explained, including its historical context. Say the word and I'll do it. I think it's too late to change from this term to something else. But since "IPsec channel" and "connection latch" are used fairly interchangeably, I could minimize all uses of "IPsec channel," relegating them to the introduction, say. > pg 4 Latch parameters not in OpenSolaris today: > > Replay protection indicator > > Key lengths > > Peer identity information We need to fix this :) > pg 5 Small descriptions with each state would be helpful. OK. I'll be adding one more state: SUSPENDED, for apps like BGP that want to avoid connection breaks as much as possible (and which expect no breaks). But connection latch breaking should probably be the default behaviour. > pg 5 You lead with "MUST NOT be sent unprotected" which seems obvious. > You should probably stress "MUST match latch parameters" instead. > (Applies to inbound and outbound processing bullets.) OK. > pg 6 You hint at section 3's "Optional Protection". I'll talk about that > more later, but that's gonna be hard to get right, never mind > specify. Earlier I called this "BYPASS OR PROTECT" and it gave Steve Kent, and, by extension, me, *heartburn*. > pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. > Ours is totally centered on the IP_SEC_OPT socket option. See > ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, > of course, but that wasn't one of the intended uses of PF_KEY. I was hinting at kernel-driven ACQUIRE, since creating a latch can ultimately lead to that situation. But I'm happy to remove the comment and the reference, if you like. > Sec 2.1 You've encountered what we found operationally in punchin! When > pg 9 a NAT is involved all hell breaks loose with mistaken SA sharing. > In OpenSolaris, the only way to workaround this is to specify UNIQUE > SA policies (which means an SA must be tied to an entire 5-tuple) and > have the aggressive breaking of latches by closing connections. If I did it's because: a) this was probably in the back of my mind anyways, b) I definitely had IP_SEC_OPT in mind, c) Michael Richardson cares about NATs very much, so he'd have seen to it that this was there. > pg 9 Speaking of latch breaking, I like the idea of closing the connection > in these situations. The question is, what errno gets passed up to > the socket? (e.g. ECONNRESET for TCP RST packets). Yes, ECONNRESET. > pg 11 Phrasing nit: say "(i.e. the tags don't appear..." instead > of "(the tags don't appear...". OK. > pg 11 Explain a little more that acquiring an SA means kicking Key > Management in the pants to do its thing. Not everyone thinks like > PF_KEY coders. :) Heh. First he complains about a reference to PF_KEY, then... :) :) > Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS SPD "PASS"? In RFC4301 parlance that'd be "PROTECT," right? > pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some > level of IPsec protection. Privilege is required to BYPASS any > SPD entries using what you call "optional protection". It was my intent to capture this. Did I? > pg 14 How does one specify "meets or exceeds" the quality of protection. > I believe the answer is "at the discretion of the system policy", but That's pretty much what it means. In practice that's the only thing it can mean, because there's no way to algorithmically compare the strength of cipher suites. (The issue of relative strength comes up *often* in the IETF. This is my answer.) > that's hard to implement properly. Well, no, local/system policy is easy to implement. In the worst (or best) case you act as if there was no such policy, in which case you don't allow any deviation from what's in the SPD. > pg 14 Your last paragraph talks about updates to the SPD. That might make > sense in some implementations, but today if I do "ipsecconf -ln" I > don't see all of the per-socket exceptions, nor do I plan to. I did use the qualifier "logically." I believe that should suffice to allow the behaviour you describe. > OpenSolaris caches SPD results in the conn_t for connected sockets. > They're ALSO latched implicitly. For example, if I have specified: > > # Telnet needs IPsec protection > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > and then I open an outbound telnet connection, that connection uses > ESP with AES and HMAC-SHA1 for its duration - even if I come along > halfway through its lifetime and flush the local SPD! Yes, I know. I should probably describe this too, and even RECOMMEND it. Not probably; I will, if I haven't already. Thanks! Nico -- >From danmcd@sun.com Thu Jan 10 12:54:16 2008 Date: Thu, 10 Jan 2008 13:38:49 -0500 From: Dan McDonald Subject: Re: Pass-1 review of -05 In-reply-to: <20080109214400.GG810@Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080110183849.GC781@kebe.east.sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> <20080109210254.GD1329@sun.com> <20080109214400.GG810@Sun.COM> Content-Length: 5743 Lines: 148 On Wed, Jan 09, 2008 at 03:44:01PM -0600, Nicolas Williams wrote: > > * Implementations may store their various bits and pieces in different > > protection domains. (e.g. Our connection latches are auxiliary state to > > the conn_t, aka. control-block, but our certificates are in the IKE > > daemon.) You may need to acknowlege this fact somewhere. > > I think that's implied here: > > o Implementations that have a restartable key management process (or > "daemon") MUST arrange for existing latched connections to either > be broken and disconnected, or for them to survive the restart of > key exchange processes. (This is implied by the above > requirements.) IPsec state related to connection latches MUST be > torn down when latched connections are torn down, even when the > latter is implied, such as at crash/halt/reboot time. > > But I'll add something a bit more explicit. You mention nothing about how hard/easy this might be given where various bits of state may or may not be stored. That's what I'm worried about. > > Per-section comments > > -------------------- > > > > Sec 2 I'm not very fond of the term "IPsec channel", because it's > > pg 4 more a "latch instance", but I can't think of a very good reason to > > rename it, so just consider that a bit of a style criticism you can > > ignore. > > Yeah, well, we have the term "channel binding," which presupposes a > channel. Connection latching provides an "IPsec channel" in that sense. > Terminology is... painful. Different areas of the IETF use very > different terminology and one cannot please everyone. The best I could > do is have a glossary where every term like this one is explained, > including its historical context. Say the word and I'll do it. > > I think it's too late to change from this term to something else. > But since "IPsec channel" and "connection latch" are used fairly > interchangeably, I could minimize all uses of "IPsec channel," > relegating them to the introduction, say. It was more of a grouse than an actual constructive comment. I feel bad for including it. > > pg 4 Latch parameters not in OpenSolaris today: > > > > Replay protection indicator > > > > Key lengths > > > > Peer identity information > > We need to fix this :) Like I said... tons of RFEs fall out of this document. > > pg 5 Small descriptions with each state would be helpful. > > OK. I'll be adding one more state: SUSPENDED, for apps like BGP that > want to avoid connection breaks as much as possible (and which expect no > breaks). But connection latch breaking should probably be the default > behaviour. Thanks. > > pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. > > Ours is totally centered on the IP_SEC_OPT socket option. See > > ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, > > of course, but that wasn't one of the intended uses of PF_KEY. > > I was hinting at kernel-driven ACQUIRE, since creating a latch can > ultimately lead to that situation. But I'm happy to remove the comment > and the reference, if you like. Your text made it sound like PF_KEY was the way to implement the connection-latching API, which probably isn't the case. > > pg 9 Speaking of latch breaking, I like the idea of closing the connection > > in these situations. The question is, what errno gets passed up to > > the socket? (e.g. ECONNRESET for TCP RST packets). > > Yes, ECONNRESET. I might argue the choice of errno value, but that it should manifest AS an error of some kind is what I was seeking. Thanks! > > Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS > SPD > > "PASS"? In RFC4301 parlance that'd be "PROTECT," right? non-PASS == PROTECT. Today on OpenSolaris, if I've an SPD: # ESP with AES and HMAC-SHA-1 {} ipsec {encr_algs aes encr_auth_algs sha1} I could set a socket option (even as a normal user) to use AH with HMAC-MD5 without incident (assuming KM succeeded). > > pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some > > level of IPsec protection. Privilege is required to BYPASS any > > SPD entries using what you call "optional protection". > > It was my intent to capture this. Did I? Mostly, except for the behaviors I specified above. > > pg 14 How does one specify "meets or exceeds" the quality of protection. > > I believe the answer is "at the discretion of the system policy", but > > That's pretty much what it means. In practice that's the only thing it > can mean, because there's no way to algorithmically compare the strength > of cipher suites. (The issue of relative strength comes up *often* in > the IETF. This is my answer.) Understood. > > pg 14 Your last paragraph talks about updates to the SPD. That might make > > sense in some implementations, but today if I do "ipsecconf -ln" I > > don't see all of the per-socket exceptions, nor do I plan to. > > I did use the qualifier "logically." I believe that should suffice to > allow the behaviour you describe. Phew! Okay. > > OpenSolaris caches SPD results in the conn_t for connected sockets. > > They're ALSO latched implicitly. For example, if I have specified: > > > > # Telnet needs IPsec protection > > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > > > and then I open an outbound telnet connection, that connection uses > > ESP with AES and HMAC-SHA1 for its duration - even if I come along > > halfway through its lifetime and flush the local SPD! > > Yes, I know. I should probably describe this too, and even RECOMMEND > it. Not probably; I will, if I haven't already. Excellent! Thanks, Dan >From Nicolas.Williams@sun.com Thu Jan 10 15:41:53 2008 Date: Thu, 10 Jan 2008 15:41:53 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-1 review of -05 Message-ID: <20080110214153.GY810@Sun.COM> References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> <20080109210254.GD1329@sun.com> <20080109214400.GG810@Sun.COM> <20080110183849.GC781@kebe.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080110183849.GC781@kebe.east.sun.com> Content-Length: 3529 Lines: 82 On Thu, Jan 10, 2008 at 01:38:49PM -0500, Dan McDonald wrote: > On Wed, Jan 09, 2008 at 03:44:01PM -0600, Nicolas Williams wrote: > > > > > > * Implementations may store their various bits and pieces in different > > > protection domains. (e.g. Our connection latches are auxiliary state to > > > the conn_t, aka. control-block, but our certificates are in the IKE > > > daemon.) You may need to acknowlege this fact somewhere. > > > > I think that's implied here: > > > > o Implementations that have a restartable key management process (or > > "daemon") MUST arrange for existing latched connections to either > > be broken and disconnected, or for them to survive the restart of > > key exchange processes. (This is implied by the above > > requirements.) IPsec state related to connection latches MUST be > > torn down when latched connections are torn down, even when the > > latter is implied, such as at crash/halt/reboot time. > > > > But I'll add something a bit more explicit. > > You mention nothing about how hard/easy this might be given where various > bits of state may or may not be stored. That's what I'm worried about. Well, does it matter? Sure, it may not be easy for *some* implementation designs. So what? The question, for me, is whether this is always so hard that we should go back to the drawing board. I think the answer is no. > > I was hinting at kernel-driven ACQUIRE, since creating a latch can > > ultimately lead to that situation. But I'm happy to remove the comment > > and the reference, if you like. > > Your text made it sound like PF_KEY was the way to implement the > connection-latching API, which probably isn't the case. I've re-read, it says "Both models imply extensions to any PF_KEY-like" protocols that may be used internally ..." ^^^ ^^^^^ In practice the extensions for kernel-driven ACQUIRE were always needed, so I'll just remove this. > > "PASS"? In RFC4301 parlance that'd be "PROTECT," right? > > non-PASS == PROTECT. > > Today on OpenSolaris, if I've an SPD: > > # ESP with AES and HMAC-SHA-1 > {} ipsec {encr_algs aes encr_auth_algs sha1} > > I could set a socket option (even as a normal user) to use AH with HMAC-MD5 > without incident (assuming KM succeeded). Very confusing. RFC4301 uses "BYPASS" to mean "sent/accepted in the clear." Bottom-line: unprivileged apps should be able to request PROTECT (RFC4301 terms) when the policy would BYPASS (RFC4301 terms), but not BYPASS when PROTECT would be required, and neither BYPASS nor PROTECT when DISCARD (drop) would be required. Privileged apps should be able to do whatever their level of privilege allows them. > > > OpenSolaris caches SPD results in the conn_t for connected sockets. > > > They're ALSO latched implicitly. For example, if I have specified: > > > > > > # Telnet needs IPsec protection > > > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > > > > > and then I open an outbound telnet connection, that connection uses > > > ESP with AES and HMAC-SHA1 for its duration - even if I come along > > > halfway through its lifetime and flush the local SPD! > > > > Yes, I know. I should probably describe this too, and even RECOMMEND > > it. Not probably; I will, if I haven't already. > > Excellent! Of course, to do this I need to figure out what the default latched parameters should be -- easy for everything except the new "break or suspend" option. --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --EeQfGwPcQSOJBaQU-- From anonsec-bounces@postel.org Thu Jan 10 18:56:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD7GV-0007H3-Jb for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:56:51 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD7GU-0001k8-8N for btns-archive-waDah9Oh@lists.ietf.org; Thu, 10 Jan 2008 18:56:51 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ANjVVf006353; Thu, 10 Jan 2008 15:45:31 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ANj7SB005975 for ; Thu, 10 Jan 2008 15:45:08 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0ANj71f006930 for ; Thu, 10 Jan 2008 23:45:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0ANj6gB049681 for ; Thu, 10 Jan 2008 16:45:06 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0ANj6QD002202; Thu, 10 Jan 2008 17:45:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0ANj6QI002201; Thu, 10 Jan 2008 17:45:06 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 10 Jan 2008 17:45:05 -0600 From: Nicolas Williams To: Black_David@emc.com, anonsec@postel.org Message-ID: <20080110234505.GG810@Sun.COM> Mail-Followup-To: Black_David@emc.com, anonsec@postel.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: [anonsec] Connection latching by default? X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Solaris creates connection latches for all connected sockets by default, whether the application requested it or not. The just-submitted draft-ietf-btns-connection-latching-05.txt says: Implementations MAY create IPsec channels automatically by default when the application does not request an IPsec channel. But I see no reason not to make that a SHOULD. Dan thinks it should be a SHOULD. Others, however, may disagree. Comments? Nico -- _______________________________________________ From anonsec-bounces@postel.org Fri Jan 11 18:29:08 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDTJE-0007vk-Aw for btns-archive-waDah9Oh@lists.ietf.org; Fri, 11 Jan 2008 18:29:08 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDTJD-0007DK-C7 for btns-archive-waDah9Oh@lists.ietf.org; Fri, 11 Jan 2008 18:29:08 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0BNJfYM010824; Fri, 11 Jan 2008 15:19:42 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0BNHDme010191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Jan 2008 15:17:15 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m0BNH2A3016055; Fri, 11 Jan 2008 18:17:02 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 11 Jan 2008 18:17:02 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m0BNGfl3011066; Fri, 11 Jan 2008 18:16:58 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 18:16:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jan 2008 18:16:42 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085F06@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt thread-index: AchRa9tSC7x6mVjVQy+ZvYr/YUo5HQDOAYvg References: To: , X-OriginalArrivalTime: 11 Jan 2008 23:16:44.0049 (UTC) FILETIME=[07B35010:01C854A8] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: black_david@emc.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m0BNHDme010191 Subject: Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc As a co-author of this draft, I want to thank Steve for his review. While it's come along a bit later in the process than one might want ideally to receive these sorts of comments, it is far better to receive them now than after an RFC is published. There are enough issues raised here that I think a new revision of the draft is in order. In exchanging email with my other co-authors and Steve, the following has emerged as a likely set of actions to respond to Steve's review (the purpose of this message is to invite WG comments on these actions): - Extend the material on document structure at end of Section 1 to actually describe the structure. As Steve says, there are two problems based on presence vs. absence of higher level authentication. In turn, each of the two solutions has 3 possible modes of operation (both, one or neither end of SA is authenticated as part of SA setup). - Clearly state the restriction that IPsec is to be used as part of the problem statements. That restriction is in the btns WG charter, and in its absence, the WG would never have been chartered (IMHO). - Provide appropriate context around the examples. The examples were important motivations at the time, and BTNS is applicable to them in principle even if non- IPsec approaches are being pursued in practice. - Shorten the security considerations section by: o removing the Leap of Faith material (section 5.7) as a distraction o replacing the Rekeying attack material in section 5.8 with a short explanation of why BTNS can increase the need for connection latching, punctuated by a pointer to the connection latching draft. One thing that will not be done is to describe EAP's encapsulation in IKEv2 as a possible solution to the BTNS problems. There are two reasons for this: 1) The existence of authentication identities and associated secrets at the network level is part of the BTNS problems, making EAP (which continues their use) a poor solution approach. 2) EAP is inapplicable. Section 1.3 of RFC 3748 (EAP) says: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. iSCSI and NFSv4 are examples of "bulk data transport" protocols to which BTNS is intended to be applicable. Instead, it would make more sense to add text that makes both of the above points so that issues about usage of EAP for BTNS purposes do not arise again. Comments? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: anonsec-bounces@postel.org > [mailto:anonsec-bounces@postel.org] On Behalf Of Stephen Kent > Sent: Monday, January 07, 2008 3:18 PM > To: ietf@ietf.org; anonsec@postel.org > Subject: [anonsec] review comments on > draft-ietf-btns-prob-and-applic-06.txt > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is not well structured, i.e., in many places it > rambles. The document has more of an architectural framework feel to > it than the title suggests. It spends too much time saying how BTNS > will work, rather than focusing on the nominal topic of the document, > i.e., the problem to be solved and the anticipated applicability of > the solution. It never provides a clear, concise characterization of > the problem to be solved, and why the functionality offered by > BTNS-IPsec is the preferred way to solve the problem. (I believe this > problem arises because, from the beginning, there were been > multiple, independent motivations for the BTNS work and the WG never > reconciled them.) > > There seem to be two types of problems/solutions that motivate BTNS, > both starting with the assumption that use of IPsec is the goal (an > assumption that needs to be justified itself, as noted below). The > solutions are presented before examples of the problems, which does > not help matters, but I'll characterize the problems in terms of the > solutions, in keeping with the style of the I-D: > > - creating IPsec/IKE SAs w/o authentication, for use > in contexts where > it is perceived that IPsec is not used because the > effort to deploy an > authentication infrastructure compatible with IKE is > too great a burden > AND the confidentiality and integrity offered by > unauthenticated SAs is > "better than nothing." Since IKE supports use of passwords, > this presumes > that the threshold for what constitutes too great a burden is > pretty low, > but this is not explicitly stated. Also, the BGP use > case was disputed, > when this work started, and has proven to be a bad example given > continuing developments, but it persists in the document. > There is also a > not-well-articulated argument that TLS/DTLS is not a suitable > alternative, > presumably because those protocols do not protect the > transport protocol > per se. It's true that IPsec does a better job here, > but the need for > using it (vs. TLS) in such circumstances does not seem to be > widely accepted. > > - creating IPsec/IKE SAs w/o authentication, for use > in contexts where an > application will perform its own authentication, but > wants the layer 3 > confidentiality, integrity and continuity of authentication > offered by ESP. > Here a critical part of the argument is that these > applications cannot use > the authentication provided by IKE, but the explanation for > this is poor. For > example there is no recognition of the use of EAP > authentication methods with > IKE. The text also does not address the possibility that a > suitable API could > allow an application to acquire and track the ID > asserted during an IKE > exchange, in lieu of the unauthenticated SA approach that is > being motivated. > > The document fails to introduce important concepts like continuity of > authentication and channel binding near the beginning. If leap of > faith authentication is important enough to be included, then it too > needs to be described early in the document. The document never > provides a clear, concise definition of channel binding, and the > definition of LoF is mostly by example. The failure to define these > terms early in the document leads to ambiguity and confusion in the > problem statement sections. > > Several of the examples provided in the applicability section do not > seem congruent with security efforts in the relevant areas. I > mentioned the BGP connection example above, which is even less > relevant today, given the ongoing TCPM work on TCP-AO. There is also > an assertion that BTNS-IPsec is a good way to protect VoIP media, yet > the RTP folks never believed that and the RAI area has recently > reaffirmed its commitment to use of SRTP for this purpose, with DTLS > for key management. Another questionable example is the suggestion to > use both BTNS-IPsec and TLS to protect client/server connections > against TCP RST attacks. This is theoretically a valid use of > BTNS-IPsec, but there is no indication that web server operators > believe this is a "necessary" capability, as the I-D argues. > > The security considerations section is too long, mostly because much > of the material should be earlier, e.g., the CB discussion. One > might also move the rekeying attack example (which I expanded to be > more accurate) to the CB document, and just reference the notion here. > > I am unable to attach a copy of the I-D, with MS Word charge tracking > for detailed comments and edits, because it is too big for these > lists. A copy of that file was sent to tge cognizant Security AD, WG > chairs, and authors. > > Steve > _______________________________________________ _______________________________________________ From anonsec-bounces@postel.org Fri Jan 11 19:08:22 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDTvC-0003gm-5D for btns-archive-waDah9Oh@lists.ietf.org; Fri, 11 Jan 2008 19:08:22 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDTvB-0007zM-Po for btns-archive-waDah9Oh@lists.ietf.org; Fri, 11 Jan 2008 19:08:22 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0C052tB026697; Fri, 11 Jan 2008 16:05:02 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0C04DNb026435 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 11 Jan 2008 16:04:14 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0C04DiJ020629 for ; Sat, 12 Jan 2008 00:04:13 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0C04Cg3050947 for ; Fri, 11 Jan 2008 17:04:12 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0C04BkN003017; Fri, 11 Jan 2008 18:04:11 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0C04BB7003016; Fri, 11 Jan 2008 18:04:11 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 11 Jan 2008 18:04:11 -0600 From: Nicolas Williams To: Black_David@emc.com Message-ID: <20080112000410.GY810@Sun.COM> Mail-Followup-To: Black_David@emc.com, kent@bbn.com, anonsec@postel.org References: <8CC6CEAB44F131478D3A7B429ECACD91085F06@CORPUSMX20A.corp.emc.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085F06@CORPUSMX20A.corp.emc.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Fri, Jan 11, 2008 at 06:16:42PM -0500, Black_David@emc.com wrote: > One thing that will not be done is to describe EAP's > encapsulation in IKEv2 as a possible solution to the BTNS > problems. There are two reasons for this: Yes, EAP is not applciable, and I've just described separately the other major reasons why authentication at the IPsec layer is not always suitable. > Instead, it would make more sense to add text that makes > both of the above points so that issues about usage of EAP > for BTNS purposes do not arise again. > > Comments? Yes please. Also let's add the multi-user multi-plexing rationale. Nico -- _______________________________________________ From anonsec-bounces@postel.org Fri Jan 11 19:16:47 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDU3L-0004Rt-DO for btns-archive-waDah9Oh@lists.ietf.org; Fri, 11 Jan 2008 19:16:47 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDU3K-00085h-SJ for btns-archive-waDah9Oh@lists.ietf.org; Fri, 11 Jan 2008 19:16:47 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0C01fmT025712; Fri, 11 Jan 2008 16:01:41 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0C00PuS025319 for ; Fri, 11 Jan 2008 16:00:26 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0C00Pv0005907 for ; Sat, 12 Jan 2008 00:00:25 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0C00OVk049152 for ; Fri, 11 Jan 2008 17:00:25 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0C00KWo003009; Fri, 11 Jan 2008 18:00:20 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0C00KGC003008; Fri, 11 Jan 2008 18:00:20 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 11 Jan 2008 18:00:20 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20080112000019.GX810@Sun.COM> Mail-Followup-To: Stephen Kent , ietf@ietf.org, anonsec@postel.org References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, ietf@ietf.org Subject: Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c [I've taken the liberty of re-formatting the quoted text for line wrapping and indentation.] On Mon, Jan 07, 2008 at 03:18:09PM -0500, Stephen Kent wrote: > - creating IPsec/IKE SAs w/o authentication, for use in > contexts where an application will perform its own > authentication, but wants the layer 3 confidentiality, > integrity and continuity of authentication offered by ESP. > > Here a critical part of the argument is that these > applications cannot use the authentication provided by IKE, > but the explanation for this is poor. I think one part of the answer to this is there, but the other part appears to be missing. > For example there is no > recognition of the use of EAP authentication methods with > IKE. EAP is not applicable. The applicability statement for EAP rules out use where end-to-end authentication is desired. Beyond that, the authentication infrastructure may not be suitable for use in IKE, even if that's merely an issue of lack of specifications or implementations. (This is mentioned in the I-D.) Finally, multi-user systems may need to authenticate individual users to other entities, in which case IPsec is inapplicable[*]. (I cannot find a mention of this in the I-D, not after a quick skim.) [*] At least to my reading of RFC4301, though I see no reason why a system couldn't negotiate narrow SAs, each with different local IDs and credentials, with other peers. But that wouldn't help applications that multiplex messages for many users' onto one TCP connection (e.g., NFS), in which case even if my readinf of RFC4301 is wrong IPsec is still not applicable for authentication. > The text also does not address the possibility that a > suitable API could allow an application to acquire and track > the ID asserted during an IKE exchange, in lieu of the > unauthenticated SA approach that is being motivated. Given the answers above such an API would be insufficient, though still quite welcome. Note that applications would care about the IDs of the SAs that protect their packets. But applications don't usually deal in packets. Connection latching is a simple method for tracking the IDs of the SAs that protect the apps' packets; the API that you suggest can be (and will be) built on top of connection latching. A non-connection-oriented version of connection latching is certainly feasible too. > The security considerations section is too long, mostly because much > of the material should be earlier, e.g., the CB discussion. One > might also move the rekeying attack example (which I expanded to be > more accurate) to the CB document, and just reference the notion here. Given that this is a problem and applicability statement for a security technology, the security considerations section might as well state that security considerations are discussed throughout the document, thus freeing the authors to structure the document like you suggest. Nico -- _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 12:07:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESmK-0003y8-Kl for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:07:16 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JESmJ-00084z-5t for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:07:16 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EGuLK5007388; Mon, 14 Jan 2008 08:56:21 -0800 (PST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EGtbRe007098 for ; Mon, 14 Jan 2008 08:55:38 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JESb2-0003l9-43; Mon, 14 Jan 2008 11:55:36 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 14 Jan 2008 11:56:04 -0500 To: Black_David@emc.com From: Stephen Kent X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kent@bbn.com Cc: anonsec@postel.org Subject: [anonsec] not so recent comments ... X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0944773126==" Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 --===============0944773126== Content-Type: multipart/alternative; boundary="============_-1011792724==_ma============" --============_-1011792724==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" David, In your response to my last call comments, you began by noting that it would have been preferable to receive them much earlier in the process. In a message to you and the other authors on 12/9/205, I suggested several changes that, if addressed, might have avoided the most recent set of comments. I received only one reply to my comments, from you, and your message addressed only one of my comments. This two-year old exchange shows that, even two years ago, several of the motivations cited in the document were questionable. This is not an example of 20-20 hindsight. It is an example of authors who elect to not make changes. My comments from that message are in bold below. ----------- I noted that the argument about the need to use different sets of credentials for applications (vs. what IKE/Ipsec can use) needed to be improved. It still does. >>... >>We can't use application credentials for IPsec; the formats of the two >>may be incompatible. There's no API for injecting credentials into IPsec >>either. >> >Most IETF security standards have no API defined for this purpose, >so this argument, while true, seems a bit odd in the larger context. >Also, depending on the nature of the user credentials, they may be >compatible with IKE use, since IKE allows for shared secrets (e.g., >passwords) as well as certificates. I noted that the use of PKI terminology was poor, at best. >>... >> >>With regard to BGP in particular, it has been understood that the use >>of appropriate authentication is the preferred solution [1]. >>Supporting authentication, e.g., by using signed certificates, at one > All certificates are signed, so delete that modifier above The modifier was changed to "CA-signed" in the latest draft, which is still generally wrong. I also noted that using VoIP as an motivation for BTNS was a bad idea, yet the example persists in the most recent version. >>... >> >>VoIP may require efficiency but its bandwidth use is low (450 Kbps >>telephone-grade, typically less) and thus does not require substantial >>CPU resources to protect. We do not believe it is necessary to address this. >> >I agree that VoIP bandwidth is low, but the objection to using IPsec >for VoIP (which primarily calls for using SRTP) is the per-packet >overhead. That concern motivated those folks to develop SRTP, not >the amount of processing power needed to apply IPsec. (Also, they >can make a god case for not needing the access control facilities of >IPsec.) I objected to the sloppy analysis of why one might use BTNS to protect web access. > > The flash crowd and DDoS attack discussions seems like a red herring, >> given that they may saturate a link irrespective of the security >> protocol employed. > > >They were left in for completeness of discussion. > >If they are kept for completeness, the at least make sure that >readers understand that these attacks may pose problems irrespective >of the use of specific network layer security mechanisms, as I noted >above. The details of rationale in the analysis were changed in the current version of the I-D, but the rationale is still poor, i.e., now it argues for use of BTNS-IPsec to protects against TCP-layer reset attacks, a concern that does not seem to be widely shared. The only response to my comments was from you, and we had one further exchange related to the use of EAP with IKE, and how it relates to the BTNS context, in a message on 12/15/05: >> > Also, depending on the nature of the user credentials, they may >>be compatible >> > with IKE use, since IKE allows for shared secrets (e.g., >>passwords) as well as certificates. >> >>Did you really mean "e.g., passwords"? IMHO, anyone who uses anything >>as weak as a plain password directly as an IKE pre-shared key should >>be shot (or at least ignored when they complain about a security >>breach). I hope this wasn't what you had in mind. Beyond this, >>there are various problems with mechanisms that can handle >>a weak secret with IKE. For IKEv1, one has to resort to the XAUTH >>crock (not exactly interoperable), or other stuff that I don't recall >>as being much better - do you have something in mind here that's not >>embarrassing to talk about in public? For IKEv2, EAP is a much better >>answer, but even that framework doesn't seem to be there for all >>protocols (e.g., I don't think anyone's worked out the details, or >>is in any hurry to do so for how iSCSI and/or NFSv4 should play nice >>with EAP). For iSCSI, the hash function transition will probably >>force the retirement of CHAP, and EAP is certainly a possible approach >>to dealing with that problem, but it's not a slam-dunk certainty to be >>chosen, and in any case, the transition is not likely to happen quickly. > >You are right; I was not clear in my comment. What I should have >said was that IKE allows for use of passwords, SecurID >challenge-response, and other common methods of user authentication >via EAP (section 2.16 of IKE). Thus if one wants to argue that user >authentication credentials that might be used by an application >would not generally be suitable for use with IKE, one has to make >this argument in the face of this explicit provision for "legacy >authentication mechanisms" in IKEv2. Also, EAP is being extended >(the EMU BoF at the last IETF meeting) ... Your most recent message cited text fro RFC 3748 (EAP) and stated that the cited text argues against use of EAP with IPsec when the applications are "bulk data transfer." The reality is that use of EAP with IKE does happen, as well as in the TLS context, etc. So, given the widespread use of EAP, this document needs to explain why it is inapplicable. Your reference to network layer identities seems odd, as EAP usually makes use of individual IDs. A better rationale is still needed. Steve --============_-1011792724==_ma============ Content-Type: text/html; charset="us-ascii" not so recent comments ...
David,

In your response to my last call comments, you began by noting that it would have been preferable to receive them much earlier in the process.

In a message to you and the other authors on 12/9/205, I suggested several changes that, if addressed, might have avoided the most recent set of comments. I received only one reply to my comments, from you, and your message addressed only one of my comments. This two-year old exchange shows that, even two years ago, several of the motivations cited in the document were questionable. This is not an example of 20-20 hindsight. It is an example of authors who elect to not make changes.

My comments from that message are in bold below.
-----------

I noted that the argument about the need to use different sets of credentials for applications (vs. what IKE/Ipsec can use) needed to be improved. It still does.

...
We can't use application credentials for IPsec; the formats of the two
may be incompatible. There's no API for injecting credentials into IPsec
either.

Most IETF security standards have no API defined for this purpose, so this argument, while true, seems a bit odd in the larger context. Also, depending on the nature of the user credentials, they may be compatible with IKE use, since IKE allows for shared secrets (e.g., passwords) as well as certificates.

I noted that the use of PKI terminology was poor, at best.

...

With regard to BGP in particular, it has been understood that the use
of appropriate authentication is the preferred solution [1].
Supporting authentication, e.g., by using signed certificates, at one
        All certificates are signed, so delete that modifier above

The modifier was changed to "CA-signed" in the latest draft, which is still generally wrong.


I also noted that using VoIP as an motivation for BTNS was a bad idea, yet the example persists in the most recent version.

...

VoIP may require efficiency but its bandwidth use is low (450 Kbps
telephone-grade, typically less) and thus does not require substantial
CPU resources to protect. We do not believe it is necessary to address this.

I agree that VoIP bandwidth is low, but the objection to using IPsec for VoIP (which primarily calls for using SRTP) is the per-packet overhead. That concern motivated those folks to develop SRTP, not the amount of processing power needed to apply IPsec.  (Also, they can make a god case for not needing the access control facilities of IPsec.)

I objected to the sloppy analysis of why one might use BTNS to protect web access.

> The flash crowd and DDoS attack discussions seems like a red herring,
> given that they may saturate a link irrespective of the security
> protocol employed.


They were left in for completeness of discussion.
If they are kept for completeness, the at least make sure that readers understand that these attacks may pose problems irrespective of the use of specific network layer security mechanisms, as I noted above.

The details of rationale in the analysis were changed in the current version of the I-D, but the rationale is still poor, i.e., now it argues for use of BTNS-IPsec to protects against TCP-layer reset attacks, a concern that does not seem to be widely shared.

The only response to my comments was from you, and we had one further exchange related to the use of EAP with IKE, and how it relates to the BTNS context, in a message on 12/15/05:

> Also, depending on the nature of the user credentials, they may be compatible
>  with IKE use, since IKE allows for shared secrets (e.g., passwords) as well as certificates.
 
Did you really mean "e.g., passwords"?  IMHO, anyone who uses anything
as weak as a plain password directly as an IKE pre-shared key should
be shot (or at least ignored when they complain about a security
breach).  I hope this wasn't what you had in mind. Beyond this, there are various problems with mechanisms that can handle
a weak secret with IKE.  For IKEv1, one has to resort to the XAUTH
crock (not exactly interoperable), or other stuff that I don't recall
as being much better - do you have something in mind here that's not
embarrassing to talk about in public?  For IKEv2, EAP is a much better
answer, but even that framework doesn't seem to be there for all
protocols (e.g., I don't think anyone's worked out the details, or
is in any hurry to do so for how iSCSI and/or NFSv4 should play nice
with EAP).  For iSCSI, the hash function transition will probably
force the retirement of CHAP, and EAP is certainly a possible approach
to dealing with that problem, but it's not a slam-dunk certainty to be
chosen, and in any case, the transition is not likely to happen quickly.

You are right; I was not clear in my comment. What I should have said was that IKE allows for use of passwords, SecurID challenge-response, and other common methods of user authentication via EAP (section 2.16 of IKE). Thus if one wants to argue that user authentication credentials that might be used by an application would not generally be suitable for use with IKE, one has to make this argument in the face of this explicit provision for "legacy authentication mechanisms" in IKEv2. Also, EAP is being extended (the EMU BoF at the last IETF meeting) ...

Your most recent message  cited text fro RFC 3748 (EAP) and stated that the cited text argues against use of EAP with IPsec when the applications are "bulk data transfer." The reality is that use of EAP with IKE does happen, as well as in the TLS context, etc. So, given the widespread use of EAP, this document needs to explain why it is inapplicable. Your reference to network layer identities seems odd, as EAP usually makes use of individual IDs. A better rationale is still needed.

Steve
--============_-1011792724==_ma============-- --===============0944773126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --===============0944773126==-- From anonsec-bounces@postel.org Mon Jan 14 12:51:31 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JETT9-0003VA-Mn for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:51:31 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JETT8-0000kX-4N for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:51:31 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EHbh94025285; Mon, 14 Jan 2008 09:37:44 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EHbLTM025131 for ; Mon, 14 Jan 2008 09:37:22 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0EHbL1U024432 for ; Mon, 14 Jan 2008 17:37:21 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0EHbK4v042753 for ; Mon, 14 Jan 2008 10:37:21 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0EHbKJt004074; Mon, 14 Jan 2008 11:37:20 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0EHbJvH004073; Mon, 14 Jan 2008 11:37:19 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 14 Jan 2008 11:37:19 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20080114173719.GI810@Sun.COM> Mail-Followup-To: Stephen Kent , Black_David@emc.com, anonsec@postel.org References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, Black_David@emc.com Subject: Re: [anonsec] not so recent comments ... X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Mon, Jan 14, 2008 at 11:56:04AM -0500, Stephen Kent wrote: > Your most recent message cited text fro RFC 3748 (EAP) and stated > that the cited text argues against use of EAP with IPsec when the > applications are "bulk data transfer." The reality is that use of EAP > with IKE does happen, as well as in the TLS context, etc. So, given > the widespread use of EAP, this document needs to explain why it is > inapplicable. Your reference to network layer identities seems odd, > as EAP usually makes use of individual IDs. A better rationale is > still needed. RFC348, section 1.3 says: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. That means that EAP is OK for use in VPN-type IKEv2 uses, but not really for end-to-end uses of IKEv2. BTNS is meant for end-to-end use where "IP layer connectivity" _is_ already available. Ergo EAP is not applicable. The key isn't "bulk data transport" but "network access authentication" and "where IP layer connectivity may not be available." (I.e., I agree with David that EAP is not applicable, but disagree as to why.) If your comment re: EAP is that the BTNS problem and applicability statement needs to be specific as to why other alternatives were rejected, then I agree. W.r.t. use for BGP, VoIP and what not, I do tend to agree that the easiest sells for BTNS are the channel binding and leap-of-faith cases. I've been skeptical of other user cases before, and still am, for in most, if not all the non-channel binding, non-LoF cases there are alternatives that seem relatively low-cost to develop (relative to BTNS). Nico -- _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 14:33:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEV3V-0005eO-FV for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 14:33:09 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEV3T-0003V8-PD for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 14:33:09 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EJSDMD014014; Mon, 14 Jan 2008 11:28:13 -0800 (PST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EJRJpS013911 for ; Mon, 14 Jan 2008 11:27:20 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JEUxq-0006WK-5O; Mon, 14 Jan 2008 14:27:18 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080112000019.GX810@Sun.COM> References: <20080112000019.GX810@Sun.COM> Date: Mon, 14 Jan 2008 14:25:53 -0500 To: Nicolas Williams From: Stephen Kent X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kent@bbn.com Cc: anonsec@postel.org, ietf@ietf.org Subject: Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 6:00 PM -0600 1/11/08, Nicolas Williams wrote: >... > >Finally, multi-user systems may need to authenticate individual users to >other entities, in which case IPsec is inapplicable[*]. (I cannot find >a mention of this in the I-D, not after a quick skim.) > >[*] At least to my reading of RFC4301, though I see no reason why a > system couldn't negotiate narrow SAs, each with different local IDs > and credentials, with other peers. But that wouldn't help > applications that multiplex messages for many users' onto one TCP > connection (e.g., NFS), in which case even if my readinf of RFC4301 > is wrong IPsec is still not applicable for authentication. IPsec has always allowed two peers to negotiate multiple SAs between them, e.g., on a per-TCP connection basis. Ipsec does support per-user authentication if protocol ID and port pairs can be used to distinguish the sessions for different users. So, if you want to restrict the cited motivation to applications that multiplex different users onto a single TCP/UDP session, that would be accurate. Steve _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 14:44:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEVER-0003pU-LX for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 14:44:27 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEVEP-0003my-IH for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 14:44:27 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EJSPtW014050; Mon, 14 Jan 2008 11:28:25 -0800 (PST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EJRKog013915 for ; Mon, 14 Jan 2008 11:27:21 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JEUxr-0006WK-4g; Mon, 14 Jan 2008 14:27:19 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080114173719.GI810@Sun.COM> References: <20080114173719.GI810@Sun.COM> Date: Mon, 14 Jan 2008 14:27:51 -0500 To: Nicolas Williams From: Stephen Kent X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kent@bbn.com Cc: anonsec@postel.org, Black_David@emc.com Subject: Re: [anonsec] not so recent comments ... X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 At 11:37 AM -0600 1/14/08, Nicolas Williams wrote: >On Mon, Jan 14, 2008 at 11:56:04AM -0500, Stephen Kent wrote: >> Your most recent message cited text fro RFC 3748 (EAP) and stated >> that the cited text argues against use of EAP with IPsec when the >> applications are "bulk data transfer." The reality is that use of EAP >> with IKE does happen, as well as in the TLS context, etc. So, given >> the widespread use of EAP, this document needs to explain why it is >> inapplicable. Your reference to network layer identities seems odd, >> as EAP usually makes use of individual IDs. A better rationale is >> still needed. > >RFC348, section 1.3 says: > > EAP was designed for use in network access authentication, where IP > layer connectivity may not be available. Use of EAP for other > purposes, such as bulk data transport, is NOT RECOMMENDED. > >That means that EAP is OK for use in VPN-type IKEv2 uses, but not really >for end-to-end uses of IKEv2. > >BTNS is meant for end-to-end use where "IP layer connectivity" _is_ >already available. Ergo EAP is not applicable. > >The key isn't "bulk data transport" but "network access authentication" >and "where IP layer connectivity may not be available." (I.e., I agree >with David that EAP is not applicable, but disagree as to why.) Your rationale is better than what David cited. I suggest it be included in a discussion of why EAP is considered inappropriate hhere. >If your comment re: EAP is that the BTNS problem and applicability >statement needs to be specific as to why other alternatives were >rejected, then I agree. yes. > >W.r.t. use for BGP, VoIP and what not, I do tend to agree that the >easiest sells for BTNS are the channel binding and leap-of-faith cases. >I've been skeptical of other user cases before, and still am, for in >most, if not all the non-channel binding, non-LoF cases there are >alternatives that seem relatively low-cost to develop (relative to >BTNS). we agree on this issue as well. Steve _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 15:21:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEVo1-0003hU-SC for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 15:21:14 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEVo1-0004ok-8U for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 15:21:13 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EK7Xhj000982; Mon, 14 Jan 2008 12:07:33 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EK6PrQ000545 for ; Mon, 14 Jan 2008 12:06:26 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0EK6PRL024410 for ; Mon, 14 Jan 2008 20:06:25 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0EK6ONJ002219 for ; Mon, 14 Jan 2008 13:06:25 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0EK6ObC004174; Mon, 14 Jan 2008 14:06:24 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0EK6NEg004173; Mon, 14 Jan 2008 14:06:23 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 14 Jan 2008 14:06:23 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20080114200623.GN810@Sun.COM> Mail-Followup-To: Stephen Kent , ietf@ietf.org, anonsec@postel.org References: <20080112000019.GX810@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, ietf@ietf.org Subject: Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 On Mon, Jan 14, 2008 at 02:25:53PM -0500, Stephen Kent wrote: > At 6:00 PM -0600 1/11/08, Nicolas Williams wrote: > >... > > > >Finally, multi-user systems may need to authenticate individual users to > >other entities, in which case IPsec is inapplicable[*]. (I cannot find > >a mention of this in the I-D, not after a quick skim.) > > > >[*] At least to my reading of RFC4301, though I see no reason why a > > system couldn't negotiate narrow SAs, each with different local IDs > > and credentials, with other peers. But that wouldn't help > > applications that multiplex messages for many users' onto one TCP > > connection (e.g., NFS), in which case even if my readinf of RFC4301 > > is wrong IPsec is still not applicable for authentication. > > IPsec has always allowed two peers to negotiate multiple SAs between > them, e.g., on a per-TCP connection basis. Right. > Ipsec does support ^^^^^ You're slipping :) :) > per-user authentication if protocol ID and port pairs can be used to > distinguish the sessions for different users. I thought this was feasible (see above) but I thought the RFC4301 model didn't quite deal with this (or at least Sam once convinced me that the name selector of the SPD didn't quite work the way I would think it should). I am glad to be wrong on this. (So then, the name selector in the SPD can be used to select the local ID and credentials?) > So, if you want to > restrict the cited motivation to applications that multiplex > different users onto a single TCP/UDP session, that would be accurate. I don't want to restrict it only to such applications, _no_. The set of applications I can see as standing to benefit from BTNS: - iSCSI -- because once revised to support use of connection latching, IPsec APIs and channel binding then configuring iSCSI to use IPsec will be a lot easier than it is today. - NFSv4 -- because of the multi-user multiplexing issue, and because reducing the number of distinct cryptographic keys and key states will improve performance, particularly for large timesharing servers (think SunRay servers). - Eventually, if BTNS takes off, we might find that using BTNS in LoF or CBB modes will be useful in apps that today do/would/should use any of SASL, GSS, TLS and/or SSHv2. This is definitely speculative, though it's certainly possible; I've no idea if it's probable. How likely this is will depend on lots of things that I cannot predict. E.g., if NICs w/ ESP/AH offload spread, then I think that will greatly help make BTNS enticing. OTOH, NICs with TCP&TLS offload will help not. CPUs like my employer's latest, with speedy on-board crypto accelerators will be neutral (which, effectively, means they will not help make BTNS popular where easier to adopt alternatives exist). - Of course, BTNS could be applicable to many new application protocols, such as new protocols that are remotely similar to iSCSI or NFS. Keep in mind that iSCSI is not all that special compared to apps that today use SASL or TLS (or both). The main difference is that iSCSI's designers felt that for a bulk data protocol it would be best (performance-wise, oer perhaps design effort-wise) to push crypto down to the lowest possible layer. So, if iSCSI can benefit from BTNS and/or related specs (connection latching, IPsec APIs), then it's not farfetched to believe that more apps will come along that can also benefit from our work. I think the examples that you object to can remain in the I-D, but it should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED') for those -- that those examples are speculative. Provided that such examples are feasible. Nico -- _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 16:23:22 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEWmA-0001vf-Qj for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:23:22 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEWm9-00061f-Qj for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:23:22 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ELAuvo027239; Mon, 14 Jan 2008 13:10:56 -0800 (PST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EL9Jt2026389 for ; Mon, 14 Jan 2008 13:09:20 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JEWYY-0008DM-5G; Mon, 14 Jan 2008 16:09:19 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080114200623.GN810@Sun.COM> References: <20080112000019.GX810@Sun.COM> <20080114200623.GN810@Sun.COM> Date: Mon, 14 Jan 2008 16:07:52 -0500 To: Nicolas Williams From: Stephen Kent X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kent@bbn.com Cc: anonsec@postel.org, ietf@ietf.org Subject: Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0768205520==" Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 --===============0768205520== Content-Type: multipart/alternative; boundary="============_-1011777501==_ma============" --============_-1011777501==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:06 PM -0600 1/14/08, Nicolas Williams wrote: >... >> Ipsec does support > ^^^^^ >You're slipping :) :) oh my! > > per-user authentication if protocol ID and port pairs can be used to >> distinguish the sessions for different users. > >I thought this was feasible (see above) but I thought the RFC4301 model >didn't quite deal with this (or at least Sam once convinced me that the >name selector of the SPD didn't quite work the way I would think it >should). I am glad to be wrong on this. > >(So then, the name selector in the SPD can be used to select the local >ID and credentials?) The following text from pages 28-29 of 4301 seems pretty clear on this point. I have marked some of the text as bold, to call attention to especially relevant parts. - Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways: 1. A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors". The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion. All IPsec implementations MUST support this use of names. 2. A named SPD entry may be used by an initiator to identify a user for whom an IPsec SA will be created (or for whom traffic may be bypassed). The initiator's IP source address (from inner IP header in tunnel mode) is used to replace the following if and when they are created: - local address in the SPD cache entry - local address in the outbound SAD entry - remote address in the inbound SAD entry Support for this use is optional for multi-user, native host implementations and not applicable to other implementations. Note that this name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context (see below). So, although support for this capability (for initiators) is not strictly required for a multi-user system, we do explain how it is intended to work in those systems. > >> So, if you want to >> restrict the cited motivation to applications that multiplex >> different users onto a single TCP/UDP session, that would be accurate. > >I don't want to restrict it only to such applications, _no_. Then you should include the sort of text you provided below, to justify why BTNS is appropriate in these circumstances, since it is not accurate to say that IPsec cannot provide the required support. >... > >I think the examples that you object to can remain in the I-D, but it >should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED') >for those -- that those examples are speculative. Provided that such >examples are feasible. my only requirement is that the motivation text be factually accurate. Steve --============_-1011777501==_ma============ Content-Type: text/html; charset="us-ascii" Re: [anonsec] review comments on draft-ietf-btns-prob-and-
At 2:06 PM -0600 1/14/08, Nicolas Williams wrote:
...
>                                            Ipsec does support
                                             ^^^^^
You're slipping :) :)

oh my!
> per-user authentication if protocol ID and port pairs can be used to
> distinguish the sessions for different users.

I thought this was feasible (see above) but I thought the RFC4301 model
didn't quite deal with this (or at least Sam once convinced me that the
name selector of the SPD didn't quite work the way I would think it
should).  I am glad to be wrong on this.

(So then, the name selector in the SPD can be used to select the local
ID and credentials?)

The following text from pages 28-29 of 4301 seems pretty clear on this point. I have marked some of the text as bold, to call attention to especially relevant parts.

      - Name:  This is not a selector like the others above.  It is not
        acquired from a packet.  A name may be used as a symbolic
        identifier for an IPsec Local or Remote address.  Named SPD
        entries are used in two ways:
         1. A named SPD entry is used by a responder (not an initiator)
            in support of access control when an IP address would not be
            appropriate for the Remote IP address selector, e.g., for
            "road warriors".  The name used to match this field is
            communicated during the IKE negotiation in the ID payload.
            In this context, the initiator's Source IP address (inner IP
            header in tunnel mode) is bound to the Remote IP address in
            the SAD entry created by the IKE negotiation.  This address
            overrides the Remote IP address value in the SPD, when the
            SPD entry is selected in this fashion.  All IPsec
            implementations MUST support this use of names.
         2. A named SPD entry may be used by an initiator to identify a
            user for whom an IPsec SA will be created (or for whom
            traffic may be bypassed).  The initiator's IP source address
            (from inner IP header in tunnel mode) is used to replace the
            following if and when they are created:

                    - local address in the SPD cache entry
                    - local address in the outbound SAD entry
                    - remote address in the inbound SAD entry
            Support for this use is optional for multi-user, native host
            implementations and not applicable to other implementations.
            Note that this name is used only locally; it is not
            communicated by the key management protocol.  Also, name
            forms other than those used for case 1 above (responder) are
            applicable in the initiator context (see below).

So, although support for this capability (for initiators) is not strictly required for a multi-user system, we do explain how it is intended to work in those systems.

>                                               So, if you want to
> restrict the cited motivation to applications that multiplex
> different users onto a single TCP/UDP session, that would be accurate.
I don't want to restrict it only to such applications, _no_.

Then you should include the sort of text you provided below, to justify why BTNS is appropriate in these circumstances, since it is not accurate to say that IPsec cannot provide the required support.

...

I think the examples that you object to can remain in the I-D, but it
should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED')
for those -- that those examples are speculative.  Provided that such
examples are feasible.

my only requirement is that the motivation text be factually accurate.

Steve
--============_-1011777501==_ma============-- --===============0768205520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --===============0768205520==-- From anonsec-bounces@postel.org Mon Jan 14 16:24:06 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEWms-0002N8-K0 for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:24:06 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEWms-00062F-8T for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:24:06 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ELJLkQ001377; Mon, 14 Jan 2008 13:19:21 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ELHajg000533 for ; Mon, 14 Jan 2008 13:17:36 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JEWgY-0008Fa-57; Mon, 14 Jan 2008 16:17:34 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080110231609.GD810@Sun.COM> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> Date: Mon, 14 Jan 2008 16:18:03 -0500 To: Nicolas Williams From: Stephen Kent X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kent@bbn.com Cc: anonsec@postel.org, Black_David@emc.com, Daniel McDonald Subject: Re: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Nico & Dan, the SPD has always been a persistent database. the newly added PAD also is persistent. It's the SAD that is transient, i.e., need not have any entries unless SAs have been created, and those entries vanish when the SAs they represent vanish. The notion of dynamic modification of the SPD is a relatively new concept, not part of the original design, but not ruled out by it. Also note that the de-correlated SPD model introduced in 4301 works very well for a persistent database, but could be costly to maintain if the SPD is frequently updated. Steve has indicated that he is tired of reviewing BTNS documents that often are hard to read and that too often are revised with only slight improvement. The BTNS problem statement is the most recent example, where comments from two years ago were not acted upon. Steve _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 16:55:24 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEXHA-0000DU-7K for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:55:24 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEXH9-0006cz-O0 for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:55:24 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ELhbDd012086; Mon, 14 Jan 2008 13:43:37 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ELgm4x011853 for ; Mon, 14 Jan 2008 13:42:49 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0ELglse008044 for ; Mon, 14 Jan 2008 21:42:48 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0ELgl4s062040 for ; Mon, 14 Jan 2008 14:42:47 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0ELgkse004405; Mon, 14 Jan 2008 15:42:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0ELgk65004404; Mon, 14 Jan 2008 15:42:46 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 14 Jan 2008 15:42:46 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20080114214245.GB4374@Sun.COM> Mail-Followup-To: Stephen Kent , Black_David@emc.com, anonsec@postel.org, Daniel McDonald References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, Black_David@emc.com, Daniel McDonald Subject: Re: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Mon, Jan 14, 2008 at 04:18:03PM -0500, Stephen Kent wrote: > Nico & Dan, > > the SPD has always been a persistent database. the newly added PAD > also is persistent. It's the SAD that is transient, i.e., need not Had I gotten this wrong? No. Dan may not be totally up to speed with RFC4301 terminology, but I wouldn't dismiss what he has to say on account of that. > have any entries unless SAs have been created, and those entries > vanish when the SAs they represent vanish. The notion of dynamic > modification of the SPD is a relatively new concept, not part of the > original design, but not ruled out by it. Also note that the > de-correlated SPD model introduced in 4301 works very well for a > persistent database, but could be costly to maintain if the SPD is > frequently updated. Are you asking that the connection latching I-D address how to perform dynamic updates of a de-correlated SPD? _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 17:27:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEXmO-0007Y9-DB for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 17:27:40 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEXmO-0007Ar-2V for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 17:27:40 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EMJAse024865; Mon, 14 Jan 2008 14:19:11 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EMIrat024756 for ; Mon, 14 Jan 2008 14:18:54 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B3F84C400B; Mon, 14 Jan 2008 17:18:52 -0500 (EST) From: Sam Hartman To: Black_David@emc.com References: <20080110234505.GG810@Sun.COM> Date: Mon, 14 Jan 2008 17:18:52 -0500 In-Reply-To: <20080110234505.GG810@Sun.COM> (Nicolas Williams's message of "Thu, 10 Jan 2008 17:45:05 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Cc: anonsec@postel.org Subject: Re: [anonsec] Connection latching by default? X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Solaris creates connection latches for all connected Nicolas> sockets by default, whether the application requested it Nicolas> or not. Nicolas> The just-submitted Nicolas> draft-ietf-btns-connection-latching-05.txt says: Nicolas> Implementations MAY create IPsec Nicolas> channels automatically by default when the application Nicolas> does not request an IPsec channel. Nicolas> But I see no reason not to make that a SHOULD. Dan Nicolas> thinks it should be a SHOULD. Nicolas> Others, however, may disagree. I think you need to have strong support for making it a should; silence is not enough on this point. _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 17:57:22 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEYF8-0002Vi-Mu for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 17:57:22 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEYF8-0007cj-B5 for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 17:57:22 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EMkjuk006217; Mon, 14 Jan 2008 14:46:45 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EMkS7d006140 for ; Mon, 14 Jan 2008 14:46:29 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0EMkSUT029577 for ; Mon, 14 Jan 2008 22:46:28 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0EMkRdq018999 for ; Mon, 14 Jan 2008 15:46:28 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0EMkR4T004620; Mon, 14 Jan 2008 16:46:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0EMkQXO004619; Mon, 14 Jan 2008 16:46:26 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 14 Jan 2008 16:46:26 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20080114224626.GF4374@Sun.COM> Mail-Followup-To: Sam Hartman , Black_David@emc.com, anonsec@postel.org References: <20080110234505.GG810@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, Black_David@emc.com Subject: Re: [anonsec] Connection latching by default? X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Mon, Jan 14, 2008 at 05:18:52PM -0500, Sam Hartman wrote: > I think you need to have strong support for making it a should; I'm asking who does support it (I know Dan does strongly support this, and there is one implementation that does this _today_, namely Solaris). > silence is not enough on this point. I'm not sure that I understand what you mean by "silence is not enough on this point" -- did I say something that indicated that silence would be taken to denote consent? Nico -- _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 18:14:50 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEYW2-0007tZ-Im for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 18:14:50 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEYW2-0007rR-8l for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 18:14:50 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EN6ES8013472; Mon, 14 Jan 2008 15:06:14 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EN5s0C013411 for ; Mon, 14 Jan 2008 15:05:55 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B4A574817; Mon, 14 Jan 2008 18:05:53 -0500 (EST) From: Sam Hartman To: Black_David@emc.com References: <20080110234505.GG810@Sun.COM> <20080114224626.GF4374@Sun.COM> Date: Mon, 14 Jan 2008 18:05:53 -0500 In-Reply-To: <20080114224626.GF4374@Sun.COM> (Nicolas Williams's message of "Mon, 14 Jan 2008 16:46:26 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Cc: anonsec@postel.org Subject: Re: [anonsec] Connection latching by default? X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 >>>>> "Nicolas" == Nicolas Williams writes: >> silence is not enough on this point. Nicolas> I'm not sure that I understand what you mean by "silence Nicolas> is not enough on this point" -- did I say something that Nicolas> indicated that silence would be taken to denote consent? I mean that if you get no objections and it is just you and Dan in favor, that's not enough to make the change in this instance. _______________________________________________ From anonsec-bounces@postel.org Mon Jan 14 18:33:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEYoX-00066A-7p for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 18:33:57 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEYoW-0008CB-RL for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 18:33:57 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ENOOtA019963; Mon, 14 Jan 2008 15:24:24 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ENO2Su019868 for ; Mon, 14 Jan 2008 15:24:03 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JEYew-0001Jw-3F; Mon, 14 Jan 2008 18:24:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080114214245.GB4374@Sun.COM> References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> <20080114214245.GB4374@Sun.COM> Date: Mon, 14 Jan 2008 16:57:29 -0500 To: Nicolas Williams From: Stephen Kent X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kent@bbn.com Cc: anonsec@postel.org, Black_David@emc.com, Daniel McDonald Subject: Re: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 At 3:42 PM -0600 1/14/08, Nicolas Williams wrote: >On Mon, Jan 14, 2008 at 04:18:03PM -0500, Stephen Kent wrote: >> Nico & Dan, >> >> the SPD has always been a persistent database. the newly added PAD >> also is persistent. It's the SAD that is transient, i.e., need not > >Had I gotten this wrong? No. Dan may not be totally up to speed with >RFC4301 terminology, but I wouldn't dismiss what he has to say on >account of that. since, as I said, the SPD has ALWAYS been defined as persistent, this misunderstanding is not attributable to a lack of familiarity with 4301. > > have any entries unless SAs have been created, and those entries >> vanish when the SAs they represent vanish. The notion of dynamic >> modification of the SPD is a relatively new concept, not part of the >> original design, but not ruled out by it. Also note that the >> de-correlated SPD model introduced in 4301 works very well for a >> persistent database, but could be costly to maintain if the SPD is >> frequently updated. > >Are you asking that the connection latching I-D address how to perform >dynamic updates of a de-correlated SPD? no. I was just noting the most recent (2 years old) text supporting the fact that the SPD was not nominally viewed as dynamic. Steve _______________________________________________ From anonsec-bounces@postel.org Tue Jan 15 02:40:44 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEgPc-0007be-DO for btns-archive-waDah9Oh@lists.ietf.org; Tue, 15 Jan 2008 02:40:44 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEgPc-0006sr-1b for btns-archive-waDah9Oh@lists.ietf.org; Tue, 15 Jan 2008 02:40:44 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0F7Z6gg028108; Mon, 14 Jan 2008 23:35:06 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0F7YdLO027830 for ; Mon, 14 Jan 2008 23:34:40 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0F7YcSn004915 for ; Tue, 15 Jan 2008 07:34:39 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0F7YbNW032737 for ; Tue, 15 Jan 2008 00:34:38 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0F7Yb3s004844; Tue, 15 Jan 2008 01:34:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0F7Yajd004843; Tue, 15 Jan 2008 01:34:36 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Jan 2008 01:34:36 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20080115073435.GG4374@Sun.COM> Mail-Followup-To: Sam Hartman , Black_David@emc.com, anonsec@postel.org References: <20080110234505.GG810@Sun.COM> <20080114224626.GF4374@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org, Black_David@emc.com Subject: Re: [anonsec] Connection latching by default? X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Mon, Jan 14, 2008 at 06:05:53PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > >> silence is not enough on this point. > > Nicolas> I'm not sure that I understand what you mean by "silence > Nicolas> is not enough on this point" -- did I say something that > Nicolas> indicated that silence would be taken to denote consent? > > I mean that if you get no objections and it is just you and Dan in > favor, that's not enough to make the change in this instance. I asked for a reason :) I don't know how many opinions we'll get. Also, recommending that connection latching be on by default can always be done later. Nico -- _______________________________________________ From anonsec-bounces@postel.org Wed Jan 16 19:26:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFIaZ-0006Pu-Jy for btns-archive-waDah9Oh@lists.ietf.org; Wed, 16 Jan 2008 19:26:35 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFIaX-00066Q-Ck for btns-archive-waDah9Oh@lists.ietf.org; Wed, 16 Jan 2008 19:26:35 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0H0NenT003898; Wed, 16 Jan 2008 16:23:40 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0H0NTI6003854 for ; Wed, 16 Jan 2008 16:23:30 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A658A4817; Wed, 16 Jan 2008 19:23:28 -0500 (EST) From: Sam Hartman To: anonsec@postel.org Date: Wed, 16 Jan 2008 19:23:28 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Cc: nicolas.williams@sun.com Subject: [anonsec] Typo in core draft X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 + bind the same public key. These certificates need not to have been + pre-shared with their peers (e.g., because ephermal, self-signed). The current text sounds like a requirement that certificates are not shared with peers. I think it's more like "These certificates do not need to be " Am I correct on this point? If so, feel free to either submit a new ID or give me an rfc editor note to apply in the tracker. Either way I'll put this on the agenda for next week. _______________________________________________ From anonsec-bounces@postel.org Thu Jan 17 05:30:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFS1M-0003Xn-3I for btns-archive-waDah9Oh@lists.ietf.org; Thu, 17 Jan 2008 05:30:52 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFS1L-0006pT-IN for btns-archive-waDah9Oh@lists.ietf.org; Thu, 17 Jan 2008 05:30:52 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0HAH2GC020466; Thu, 17 Jan 2008 02:17:03 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0HAGibV020280 for ; Thu, 17 Jan 2008 02:16:44 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0HAGhfq004442 for ; Thu, 17 Jan 2008 10:16:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0HAGhFS031463 for ; Thu, 17 Jan 2008 03:16:43 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0HAGdLp007323; Thu, 17 Jan 2008 04:16:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0HAGcM3007322; Thu, 17 Jan 2008 04:16:38 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 17 Jan 2008 04:16:38 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20080117101638.GB6591@Sun.COM> Mail-Followup-To: Sam Hartman , anonsec@postel.org References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] Typo in core draft X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Wed, Jan 16, 2008 at 07:23:28PM -0500, Sam Hartman wrote: > + bind the same public key. These certificates need not to have been > + pre-shared with their peers (e.g., because ephermal, self-signed). > > > The current text sounds like a requirement that certificates are not > shared with peers. I think it's more like "These certificates do not > need to be " Yes, that's correct -- the word "do" is missing and should be inserted before "need to be". > Am I correct on this point? If so, feel free to either submit a new > ID or give me an rfc editor note to apply in the tracker. The note is this: Add the word "do" before "need to" in the last sentence of the parapgraph that starts "Nodes wishing to be treated as BTNS nodes..." in section 2. > Either way I'll put this on the agenda for next week. Thanks. _______________________________________________ From anonsec-bounces@postel.org Thu Jan 17 10:47:53 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWy9-0003iU-5m for btns-archive-waDah9Oh@lists.ietf.org; Thu, 17 Jan 2008 10:47:53 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFWy8-0006rZ-RN for btns-archive-waDah9Oh@lists.ietf.org; Thu, 17 Jan 2008 10:47:53 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0HFdAAH010494; Thu, 17 Jan 2008 07:39:11 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0HFcbvN010260 for ; Thu, 17 Jan 2008 07:38:38 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3BA894817; Thu, 17 Jan 2008 10:38:33 -0500 (EST) From: Sam Hartman To: anonsec@postel.org References: <20080117101638.GB6591@Sun.COM> Date: Thu, 17 Jan 2008 10:38:33 -0500 In-Reply-To: <20080117101638.GB6591@Sun.COM> (Nicolas Williams's message of "Thu, 17 Jan 2008 04:16:38 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Subject: Re: [anonsec] Typo in core draft X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I've inserted the following into the ballot: Note to RFC Editor Section 2: old: bind the same public key. These certificates need not to have been new: bind the same public key. These certificates do not need to be _______________________________________________