Stephen Kent
2008-01-07 20:18:09 UTC
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
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