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

Black_David@emc.com Fri, 11 January 2008 23:29 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 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 <anonsec@postel.org>; 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: <p0624051cc3a83920cdf2@[128.89.89.71]>
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: <p0624051cc3a83920cdf2@[128.89.89.71]>
To: kent@bbn.com, anonsec@postel.org
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." <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: 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
> _______________________________________________

_______________________________________________