[anonsec] not so recent comments ...

[Stephen Kent <[e-mail]>]

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 [1].
>>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

_______________________________________________