Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 14 January 2008 20:21 UTC

Return-path: <anonsec-bounces@postel.org>
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 <anonsec@postel.org>; 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 <anonsec@postel.org>; 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 <anonsec@postel.org>; 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 <Nicolas.Williams@sun.com>
To: Stephen Kent <kent@bbn.com>
Message-ID: <20080114200623.GN810@Sun.COM>
Mail-Followup-To: Stephen Kent <kent@bbn.com>, ietf@ietf.org, anonsec@postel.org
References: <p0624051cc3a83920cdf2@[128.89.89.71]> <20080112000019.GX810@Sun.COM> <p06240518c3b166bb1281@[192.168.0.101]>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <p06240518c3b166bb1281@[192.168.0.101]>
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." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/anonsec>
List-Post: <mailto:anonsec@postel.org>
List-Help: <mailto:anonsec-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=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
-- 
_______________________________________________