ietf
[Top] [All Lists]

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

2008-01-07 13:19:04
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf