Stephen Kent
2008-01-14 16:56:04 UTC
David,
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.
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.
My comments from that message are in bold below.
-----------
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.
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.
I noted that the use of PKI terminology was poor, at best.
The modifier was changed to "CA-signed" in the latest draft, which is
still generally wrong.
I also noted that using VoIP as an motivation for BTNS was a bad
idea, yet the example persists in the most recent version.
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.)
I objected to the sloppy analysis of why one might use BTNS to
protect web access.
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.
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.
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
Did you really mean "e.g., passwords"? IMHO, anyone who uses anything
as weak as a plain password directly as an IKE pre-shared key should
be shot (or at least ignored when they complain about a security
breach). I hope this wasn't what you had in mind. Beyond this,
there are various problems with mechanisms that can handle
a weak secret with IKE. For IKEv1, one has to resort to the XAUTH
crock (not exactly interoperable), or other stuff that I don't recall
as being much better - do you have something in mind here that's not
embarrassing to talk about in public? For IKEv2, EAP is a much better
answer, but even that framework doesn't seem to be there for all
protocols (e.g., I don't think anyone's worked out the details, or
is in any hurry to do so for how iSCSI and/or NFSv4 should play nice
with EAP). For iSCSI, the hash function transition will probably
force the retirement of CHAP, and EAP is certainly a possible approach
to dealing with that problem, but it's not a slam-dunk certainty to be
chosen, and in any case, the transition is not likely to happen quickly.
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) ...
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.
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/anonsec/attachments/20080114/276e1404/attachment.html
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.
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.
My comments from that message are in bold below.
-----------
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.
...
We can't use application credentials for IPsec; the formats of the two
may be incompatible. There's no API for injecting credentials into IPsec
either.
Most IETF security standards have no API defined for this purpose,We can't use application credentials for IPsec; the formats of the two
may be incompatible. There's no API for injecting credentials into IPsec
either.
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.
...
With regard to BGP in particular, it has been understood that the use
of appropriate authentication is the preferred solution [1].
Supporting authentication, e.g., by using signed certificates, at one
All certificates are signed, so delete that modifier aboveWith regard to BGP in particular, it has been understood that the use
of appropriate authentication is the preferred solution [1].
Supporting authentication, e.g., by using signed certificates, at one
still generally wrong.
I also noted that using VoIP as an motivation for BTNS was a bad
idea, yet the example persists in the most recent version.
...
VoIP may require efficiency but its bandwidth use is low (450 Kbps
telephone-grade, typically less) and thus does not require substantial
CPU resources to protect. We do not believe it is necessary to address this.
I agree that VoIP bandwidth is low, but the objection to using IPsecVoIP may require efficiency but its bandwidth use is low (450 Kbps
telephone-grade, typically less) and thus does not require substantial
CPU resources to protect. We do not believe it is necessary to address this.
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.)
protect web access.
The flash crowd and DDoS attack discussions seems like a red herring,
given that they may saturate a link irrespective of the security
protocol employed.
They were left in for completeness of discussion.given that they may saturate a link irrespective of the security
protocol employed.
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.
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.
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
Also, depending on the nature of the user credentials, they may
be compatiblewith IKE use, since IKE allows for shared secrets (e.g.,
passwords) as well as certificates.Did you really mean "e.g., passwords"? IMHO, anyone who uses anything
as weak as a plain password directly as an IKE pre-shared key should
be shot (or at least ignored when they complain about a security
breach). I hope this wasn't what you had in mind. Beyond this,
there are various problems with mechanisms that can handle
a weak secret with IKE. For IKEv1, one has to resort to the XAUTH
crock (not exactly interoperable), or other stuff that I don't recall
as being much better - do you have something in mind here that's not
embarrassing to talk about in public? For IKEv2, EAP is a much better
answer, but even that framework doesn't seem to be there for all
protocols (e.g., I don't think anyone's worked out the details, or
is in any hurry to do so for how iSCSI and/or NFSv4 should play nice
with EAP). For iSCSI, the hash function transition will probably
force the retirement of CHAP, and EAP is certainly a possible approach
to dealing with that problem, but it's not a slam-dunk certainty to be
chosen, and in any case, the transition is not likely to happen quickly.
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) ...
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.
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/anonsec/attachments/20080114/276e1404/attachment.html