Subject: [SAFE] eliminating TLS from STUN Control

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Jun 2007 08:25:45 -0700

I have been bothered by the need for TLS in STUN Control.  This is present
to protect against one particular attack:  a malicious party acquires your
NAT's public IP address and then starts their own STUN server which lies to
you (that is, it provides inaccurate addresses in XOR-MAPPED-ADDRESS).

I believe I have a solution to removing the need for TLS:  when the STUN
Client first talks to the STUN server built into the NAT, the STUN server
returns XOR-INTERNAL-ADDRESS (as it does in the current specification) and
also returns a 64-bit value in a new attribute called BOOTSTAMP.  This value
is generated randomly by the NAT device each time it initializes.  The STUN
client expects to see this same BOOTSTAMP value in each response from that
NAT; if it sees a different value, the STUN client discards all of the
information it has learned about that NAT (and all NATs inside of it).

This protects against the attack that TLS protected against.

However, this new technique is vulnerable to a malicious party learning the
BOOTSTAMP value.  The rogue party could connect to your 'inside' network and
communicate with your NAT and learn the BOOTSTAMP value.  This might be done
via 802.11.  

If the NAT used unique BOOTSTAMP values for each client IP address, the
malicious party would have to be on-path to see the BOOTSTAMP value
associated with your IP address.

Thoughts?  (I also don't like the name 'BOOTSTAMP', but that is the best I
have come up with so far.)

-d

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Jun 2007 22:28:25 +0200

Hi Dan,

I have a few minor comments:

> you (that is, it provides inaccurate addresses in XOR-MAPPED-ADDRESS).

Could you elaborate this attack a bit more?

TLS provides a number of functions, the most important (in this case) 
are entity authentication and confidentiality protection.

> information it has learned about that NAT (and all NATs inside of it).
In some sense you would like to accomplish functionality, which is 
called "Sender Invariance":

"A party is assured that the source of the communication has remained 
the same as the one that started the communication, although the actual 
identity of the source is not important to the recipient."

In former versions of the NSIS NATFW NSLP draft we used a sender 
invariance property that used Purpose Built Keys.
The sender initially set the key and then every new message could be 
associated with the subsequent sender. This is nice functionality and 
provides quite interesting security properties. (One can every extend it 
to cases where you use CGAs but that's for IPv6 only.)

Later, we removed it from the spec since we used TLS already.

When you a cryptographic mechanism then you have a big advantage: An 
adversary that shows up later does not have a chance to modify or delete 
allocated state.

> This protects against the attack that TLS protected against.
It is true that it protects against this type of attack. The downside, 
however, is that you need some form of protection for authorization 
tokens and client authentication (in case of firewall traversal).

> communicate with your NAT and learn the BOOTSTAMP value.  This might be done
That's always a problem with these mechanisms unless you use CGAs.

> associated with your IP address.
That's true. The adversary has to be on-path or on the same shared medium.

> have come up with so far.)
I like the concept of sender invariance. I am, however, not sure how 
this concept extends to firewall traversal.
I still believe you need a bit more than just a random value since it 
does not protect against a couple of attacks. Particularly in a mobile 
environment you might get a
annoying effects: A node that was once along the communication path will 
be able to damage your future connection and it would be difficult to 
figure out where the attack actually came from.

Ciao
Hannes

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Jun 2007 16:42:58 -0700

> Could you elaborate this attack a bit more?

It's described in section 9.3 of the spec,
http://www.tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-02#s
ection-9.3

> are entity authentication and confidentiality protection.

To handle this attack, TLS is only used to provide a username and password
that are used to authenticate subsequent UDP exchanges with the STUN server
embedded in the NAT.

> the same as the one that started the communication, although 
> the actual identity of the source is not important to the recipient."
>  
> 
> provides quite interesting security properties. (One can 
> every extend it to cases where you use CGAs but that's for 
> IPv6 only.)
> 
> adversary that shows up later does not have a chance to 
> modify or delete allocated state.

You're describing the security properties the middlebox wants,
rather than what the host wants.

STUN Control's security model is quite different from NSIS; you
can only create a binding or adjust a binding's timeout from
the exact same transport address (source IP address and source 
UDP port) as the binding itself.  If an attacker can acquire, 
or spoof, your source IP address and source UDP port, the 
attacker can interfere with things more interesting than the
NAT binding.

> It is true that it protects against this type of attack. The 
> downside, however, is that you need some form of protection 
> for authorization tokens and client authentication (in case 
> of firewall traversal).

Yes, firewall traversal may well require client authentication
and client authorization, because the firewall's policies might
require that.

That's a different requirement than the threat described in
http://www.tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-02#s
ection-9.3

> > communicate with your NAT and learn the BOOTSTAMP value.  
> > This might be done via 802.11.  
> 

I agree it does not extend to firewall traversal.

> does not protect against a couple of attacks. Particularly in 
> a mobile environment you might get a annoying effects:  A node 
> that was once along the communication path will be able to 
> damage your future connection and it would be difficult to 

Well, I'm assuming whoever has an IP address is the owner of
that IP address; whoever had it before can't do anything with
STUN Control.  This is different from NSIS, MIDCOM, and a slew
of other protocols because the middlebox management is out-of-
band (that is, it uses a protocol that needs a lot of machinery
to tie itself to the connection it's describing; with STUN
Control, we're using the connection itself (same source IP
address and source UDP port) so can throw away much of that
machinery.)

-d