Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec

From: "Christian Huitema" <[email-masked]>
Date: Thu, 6 May 2004 10:58:37 -0700

> The following I-D is soon to appear in the drafts directory; until
then,
> here is the title and abstract, and it is available now at:
> 
> 	http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt
> 
> At this time, I'm soliciting discussion and feedback on both TCPM and
> IPsec mailing lists, where discussion of the issues of IPsec have been
> ongoing. I track both lists; please do NOT cross-post. I'll
> cross-summarize periodically if it proves necessary.

Your draft starts with a description of the state of the art, which
mentions how the BGP MD5 option can be used to protect the connection
against some attacks (notably, data injection). However, this option is
BGP specific, and there is no intention to generalize its usage to other
applications of TCP. In the interest of clarity, you should mention the
limits of applicability of this MD5 option, and you should mention the
obvious alternative, use SSL or TLS.

Now, on a practical note, I observe that your proposal requires a code
change. There is an alternative, which is to use a well known secret.
Yes, I know this is an oxymoron, but such well known secret would have
exactly the same properties as "anonymous IPSEC", i.e. they will protect
against random attacks by virtue of the initial DH exchange, but they
will not protect from a man-in-the-middle attack against IKE.

The advantage of the well known secret approach is that it does not
require a code change or a protocol update. Many implementations of IKE
support the use of a shared secret to secure an IPSEC connection when
PKI certificates are not available. 

-- Christian Huitema

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 12:13:16 -0700

> obvious alternative, use SSL or TLS.

Section 3.1.1 refers to RFC2385, which introduces a TCP option (the 
first reference to MD5). The RFC discusses this in regard to the same 
kind of attack to BGP at the transport layer (RST attacks in specific). 
Recommending this RFC as "standards track" may be limited to BGP, but 
there is nothing in the option that appears to be BGP-specific or even 
BGP-related.

There are application-layer solutions discussed in section 4.3, 
including SSL and TLS, as well as BGP-layer authentication.

> will not protect from a man-in-the-middle attack against IKE.

I'm suggesting that the well-known secret be "0" in section 5.1.1. I'd 
be VERY glad if this does not require a mod to IKE - as noted in the 
doc, the purpose is to show how to use IKE when CAs are not known; I'm 
not an IKE expert, and I didn't see that IKE already supports this. I'll 
look deeper, but if you can suggest where in the spec to start digging, 
that'd be helpful.

However, there still may be utility to the code mods for headerANON and 
nullANON.

> PKI certificates are not available. 

Thanks for your observations!

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 10 May 2004 11:05:58 -0400

(catching up)

> In the interest of clarity, you should mention the limits of
> applicability of this MD5 option, and you should mention the obvious
> alternative, use SSL or TLS.

I don't follow why an obvious alternative to MD5 is SSL/TLS.  SSL/TLS
won't allow bogus data to be inserted into the stream, but does nothing
about the ability of an attacker to rip down a connection (ala the MD5
option).  Right?

(And, FWIW, while the MD5 option is heavily cased in terms of BGP, I
agree with Joe (? I think - I have lost track) that there is nothing
that fundementally makes MD5 worthless for other traffic.)

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/