Subject: review comments on draft-ietf-btns-prob-and-applic-06.txt

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jan 2008 15:18:09 -0500

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jan 2008 18:00:20 -0600

[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.
> 
> 	   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.

> 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: Stephen Kent <[email-masked]>
Date: Mon, 14 Jan 2008 14:25:53 -0500

At 6:00 PM -0600 1/11/08, Nicolas Williams wrote:
>...

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: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jan 2008 14:06:23 -0600

On Mon, Jan 14, 2008 at 02:25:53PM -0500, Stephen Kent wrote:
> them, e.g., on a per-TCP connection basis.

Right.

>                                            Ipsec does support 
                                             ^^^^^
You're slipping :) :)

> 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 

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: Stephen Kent <[email-masked]>
Date: Mon, 14 Jan 2008 16:07:52 -0500

>You're slipping :) :)

oh my!

>(So then, the name selector in the SPD can be used to select the local

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.
>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.

>for those -- that those examples are speculative.  Provided that such

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

Steve