[anonsec] not so recent comments ...
Stephen Kent <email@example.com> Mon, 14 January 2008 17:07 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESmK-0003y8-Kl for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:07:16 -0500
Received: from boreas.isi.edu ([184.108.40.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JESmJ-00084z-5t for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:07:16 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EGuLK5007388; Mon, 14 Jan 2008 08:56:21 -0800 (PST)
Received: from mx12.bbn.com (mx12.bbn.com [220.127.116.11]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EGtbRe007098 for <firstname.lastname@example.org>; Mon, 14 Jan 2008 08:55:38 -0800 (PST)
Received: from dommiel.bbn.com ([18.104.22.168] helo=[192.168.0.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <email@example.com>) id 1JESb2-0003l9-43; Mon, 14 Jan 2008 11:55:36 -0500
Date: Mon, 14 Jan 2008 11:56:04 -0500
From: Stephen Kent <firstname.lastname@example.org>
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: [anonsec] not so recent comments ...
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:firstname.lastname@example.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0944773126=="
X-Spam-Score: 0.0 (/)
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. >>... >>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, >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. >>... >> >>With regard to BGP in particular, it has been understood that the use >>of appropriate authentication is the preferred solution . >>Supporting authentication, e.g., by using signed certificates, at one > All certificates are signed, so delete that modifier above 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. >>... >> >>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 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.) I objected to the sloppy analysis of why one might use BTNS to 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. > >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 the BTNS context, in a message on 12/15/05: >> > 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. >> >>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