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

From: [email-masked]
Date: Thu, 6 May 2004 15:06:13 -0500

Joe-

In one of my previous e-mail, I pointed out that without a CA or long-term shared key between each host (which doesn't scale), it's sort of impossible to protect transport layer by using IP layer security. I wasn't very clear, but let me describe the problem. 

Let's say Alice and Bob are two BGP routers who follow anonsec (or IPSec with a well-known shared key), and Trudy is an attacker who wants to disrupt the connection. Let's also say, Trudy somehow knows the IP address and TCP port numbers of the connection between Alice and Bob (these conditions are essentially the prerequisite for any of these attacks to be possible).

Alice and Bob use anonsec to get a SPI1 and start communicating. Trudy, sometime later, initiates Anonsec with Alice(or what ever) and gets another SPI2 (In anonynsec there is no shared secret/CA that prevents Trudy from establishing this security association, and that's the main source of problem.) Graphically, this is how it looks:

	               SPI1
	ALICE <-----------------------> BOB 
	  ^
        |	         SPI2 
        +---------------------------> Trudy

Now Trudy constructs packets as 

	[IP-Trudy, IP-Alice, SPI2, next-hdr=AH/ES, next-hdr=IP [IP-Bob, IP-Alice, next-hdr=TCP, Flags=RST], ICV ]

i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the inner packet she sends a packet which has IP address of Alice and Bob and TCP ports of Alice and Bob. Please also note that Trudy can use just one SPI2 to attack hundreds of TCP connection that might originate from Alice.

Most IPSec policies will authenticate the packet based on SPI2 and find it okay (with CA/secrets, getting this SPI2 would have been impossible and that's why this attack would have failed in normal IPSec operation). But in this case, the IPSec engine will give the inner IP packet to the actual IP engine which will give the packet to TCP layer, which will reset the connection :-)

BTW, It might seem like MITM attack, but it's not (I like to call it Man in the Corner attack :-) ). Trudy, in this case, doesn't need to intercept (actively or passively) any packets between Alice and Bob so it's not an MITM.
  
So, Anonysec will protect against an attacker who just wanted to throw some random RST packet, but if the attacker is even a little bit more sophisticated, then TCP is on it's own. Also, the fact that Trudy's IP address will be revealed in this attack is not of much solace, because most such attacks are distributed anyways (and calling an ISP to block some packets doesn't work fast enough).

Without shared secrets (not known keys) or CAs, the only way (known to me) to protect transport layer is to modify the transport layer itself. But I will let security experts comment on this. Of course other solution is to have strict policies, but that might interfere with other needs.

Yogesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Christian Huitema
> Sent: Thursday, May 06, 2004 12:59 PM
> To: Joe Touch; [email-masked]
> Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec
> 
> 
> > 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
> 

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

---

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

[email-masked] wrote:
> Joe-
> 
> In one of my previous e-mail, I pointed out that without a CA or
> long-term shared key between each host (which doesn't scale), it's sort
> of impossible to protect transport layer by using IP layer security. I
> wasn't very clear, but let me describe the problem.
> 
> Let's say Alice and Bob are two BGP routers who follow anonsec (or
> IPSec with a well-known shared key), and Trudy is an attacker who wants
> to disrupt the connection. Let's also say, Trudy somehow knows the IP
> address and TCP port numbers of the connection between Alice and Bob
> (these conditions are essentially the prerequisite for any of these
> attacks to be possible).
> 
> Alice and Bob use anonsec to get a SPI1 and start communicating.
> Trudy, sometime later, initiates Anonsec with Alice(or what ever) and
> gets another SPI2 (In anonynsec there is no shared secret/CA that
> prevents Trudy from establishing this security association, and that's
> the main source of problem.) 

In most of the attack scenarios, "Trudy" is a remote spoofer who is not 
reachable via the reverse path, i.e., she cannot be reached by packets 
sent to "Trudy". This would prevent the ANONsec association from being 
established.

As you observe, someone willing to commit resources - with a valid 
reverse path - can certainly connect. But this is a public server (I'm 
assuming), so this makes sense.

> Graphically, this is how it looks:
> 
> 
> 	               SPI1
> [IP-Trudy, IP-Alice, SPI2, next-hdr=AH/ES, next-hdr=IP [IP-Bob,
? IP-Alice, next-hdr=TCP, Flags=RST], ICV ]
> 
> i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the
> inner packet she sends a packet which has IP address of Alice and Bob
> and TCP ports of Alice and Bob. Please also note that Trudy can use just
> one SPI2 to attack hundreds of TCP connection that might originate from
> Alice.

This shouldn't be possible - as I've loosely defined ANONsec, the idea 
of the SA is to authenticate the header. I.e., SPI1 is valid only for 
packets from Alice; SPI2 is valid only for packets from Trudy.

In this case, the authentication should fail since the packet's source
address doesn't match what SPI2 requires - regardless of the next-header.

> Most IPSec policies will authenticate the packet based on SPI2 and
> find it okay (with CA/secrets, getting this SPI2 would have been
> impossible and that's why this attack would have failed in normal IPSec
> operation). But in this case, the IPSec engine will give the inner IP
> packet to the actual IP engine which will give the packet to TCP layer,
> which will reset the connection :-)

As above, I believe IPsec AH already covers this case sufficiently. A 
valid SPI is not permission to send packets with any source - only that 
which matches the previously negotiated source of that SPI.

Joe

> 
> BTW, It might seem like MITM attack, but it's not (I like to call it
> Man in the Corner attack :-) ). Trudy, in this case, doesn't need to
> intercept (actively or passively) any packets between Alice and Bob so
> it's not an MITM.
> 
> So, Anonysec will protect against an attacker who just wanted to
> throw
> some random RST packet, but if the attacker is even a little bit more
> sophisticated, then TCP is on it's own. Also, the fact that Trudy's IP
> address will be revealed in this attack is not of much solace, because
> most such attacks are distributed anyways (and calling an ISP to block
> some packets doesn't work fast enough).
> 
> Without shared secrets (not known keys) or CAs, the only way (known
> to
> me) to protect transport layer is to modify the transport layer itself.
> But I will let security experts comment on this. Of course other
> solution is to have strict policies, but that might interfere with other
> needs.
> 
> Yogesh
> 
> 
>