<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>not so recent comments ...</title></head><body>
<div>David,</div>
<div><br></div>
<div>In your response to my last call comments, you began by noting
that it would have been preferable to receive them much earlier in the
process.</div>
<div><br></div>
<div>In a message to you and the other authors on 12/9/205, I
suggested several changes that, if addressed, might have avoided the
most recent set of comments. I received only one reply to my comments,
from you, and your message addressed only one of my comments. This
two-year old exchange shows that, even two years ago, several of the
motivations cited in the document were questionable. This is not an
example of 20-20 hindsight. It is an example of authors who elect to
not make changes.</div>
<div><br></div>
<div>My comments from that message are in<b> bold</b> below.</div>
<div>-----------</div>
<div><br></div>
<div>I noted that the argument about the need to use different sets of
credentials for applications (vs. what IKE/Ipsec can use) needed to be
improved. It still does.</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote type="cite" cite><font
color="#000000">...</font></blockquote>
<blockquote type="cite" cite><font color="#000000">We can't use
application credentials for IPsec; the formats of the
two</font></blockquote>
<blockquote type="cite" cite><font color="#000000">may be
incompatible. There's no API for injecting credentials into
IPsec</font></blockquote>
<blockquote type="cite" cite><font
color="#000000">either.</font></blockquote>
<blockquote type="cite" cite><br></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#000000"><b>Most IETF
security standards have no API defined for this purpose, so this
argument, while true, seems a bit odd in the larger context. Also,
depending on the nature of the user credentials, they may be
compatible with IKE use, since IKE allows for shared secrets (e.g.,
passwords) as well as certificates.</b></font></blockquote>
<div><br></div>
<div>I noted that the use of PKI terminology was poor, at best.</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote type="cite" cite><font
color="#000000">...</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">With regard to BGP
in particular, it has been understood that the use</font></blockquote>
<blockquote type="cite" cite><font color="#000000">of appropriate
authentication is the preferred solution [1].</font></blockquote>
<blockquote type="cite" cite><font color="#000000">Supporting
authentication, e.g., by using signed certificates, at
one</font></blockquote>
</blockquote>
<blockquote type="cite" cite><font
color="#000000"><b><x-tab>
</x-tab>All certificates are signed, so delete that modifier
above</b></font></blockquote>
<div><br></div>
<div>The modifier was changed to "CA-signed" in the latest
draft, which is still generally wrong.</div>
<div><br></div>
<div><br></div>
<div>I also noted that using VoIP as an motivation for BTNS was a bad
idea, yet the example persists in the most recent version.</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote type="cite" cite><font
color="#000000">...</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">VoIP may require
efficiency but its bandwidth use is low (450 Kbps</font></blockquote>
<blockquote type="cite" cite><font color="#000000">telephone-grade,
typically less) and thus does not require
substantial</font></blockquote>
<blockquote type="cite" cite><font color="#000000">CPU resources to
protect. We do not believe it is necessary to address
this.</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#000000"><b>I agree that
VoIP bandwidth is low, but the objection to using IPsec for VoIP
(which primarily calls for using SRTP) is the per-packet overhead.
That concern motivated those folks to develop SRTP, not the amount of
processing power needed to apply IPsec. (Also, they can make a
god case for not needing the access control facilities of
IPsec.)</b></font></blockquote>
<div><br></div>
<div>I objected to the sloppy analysis of why one might use BTNS to
protect web access.</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">> The flash
crowd and DDoS attack discussions seems like a red herring,<br>
> given that they may saturate a link irrespective of the
security<br>
> protocol employed.<br>
<br>
<br>
They were left in for completeness of discussion.</font><br>
<font color="#000000"></font></blockquote>
<blockquote type="cite" cite><font color="#000000"><b>If they are kept
for completeness, the at least make sure that readers understand that
these attacks may pose problems irrespective of the use of specific
network layer security mechanisms, as I noted
above.</b></font></blockquote>
<div><br></div>
<div>The details of rationale in the analysis were changed in the
current version of the I-D, but the rationale is still poor, i.e., now
it argues for use of BTNS-IPsec to protects against TCP-layer reset
attacks, a concern that does not seem to be widely shared.</div>
<div><br></div>
<div>The only response to my comments was from you, and we had one
further exchange related to the use of EAP with IKE, and how it
relates to the BTNS context, in a message on 12/15/05:</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote type="cite" cite><font face="Times New Roman"><b>>
Also, depending on the nature of the user credentials, they may be
compatible</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"><b>>
with IKE use, since IKE allows for shared secrets (e.g., passwords) as
well as certificates.</b></font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">Did
you really mean "e.g., passwords"? IMHO,
anyone who uses anything</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">as
weak as a plain password directly as an IKE pre-shared key
should</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">be
shot (or at least ignored when they complain about a
security</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">breach). I hope this wasn't what you had in mind.
Beyond this, there are various problems with mechanisms that can
handle</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">a weak
secret with IKE. For IKEv1, one has to resort to the
XAUTH</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">crock
(not exactly interoperable), or other stuff that I don't
recall</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">as
being much better - do you have something in mind here that's
not</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">embarrassing to talk about in public? For IKEv2, EAP
is a much better</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">answer, but even that framework doesn't seem to be
there for all</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">protocols (e.g., I don't think anyone's worked out the
details, or</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">is in
any hurry to do so for how iSCSI and/or NFSv4 should
play nice</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">with
EAP). For iSCSI, the hash function transition will
probably</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">force
the retirement of CHAP, and EAP is certainly a possible
approach</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">to dealing with that problem, but it's not a slam-dunk
certainty to be</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">chosen, and in any case, the transition is not likely
to happen quickly.</font></blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>You are right; I was not clear in my
comment. What I should have said was that IKE allows for use of
passwords, SecurID challenge-response, and other common methods of
user authentication via EAP (section 2.16 of IKE). Thus if one wants
to argue that user authentication credentials that might be used by an
application would not generally be suitable for use with IKE, one has
to make this argument in the face of this explicit provision for
"legacy authentication mechanisms" in IKEv2. Also, EAP is
being extended (the EMU BoF at the last IETF meeting)
...</b></blockquote>
<div><br></div>
<div>Your most recent message cited text fro RFC 3748 (EAP) and
stated that the cited text argues against use of EAP with IPsec when
the applications are "bulk data transfer." The reality is
that use of EAP with IKE does happen, as well as in the TLS context,
etc. So, given the widespread use of EAP, this document needs to
explain why it is inapplicable. Your reference to network layer
identities seems odd, as EAP usually makes use of individual IDs. A
better rationale is still needed.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>