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

[Stephen Kent <[e-mail]>]

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
_______________________________________________