Subject: [BEHAVE] TLS in draft-wing-behave-nat-control-stun-usage-01 ?!

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 19 Feb 2007 13:04:23 +0200

Hello,

I have been looking at the new -01 revision... Now it came to my mind that, 
hmm, using STUN+TLS was a bit problematic.

First, I would expect some NATs implementors to not want to bother putting a 
TLS stack. But I cannot really comment on that, not being a NAT implementor. 
Second, the I-D really ought to specify how the TLS session is to be 
authenticated.

x509 seems very impractical, because:
- admins will not want to pay a certification per NAT box,
- NATs are supposed to be easy to deploy, and provisioning an x509 cert is not 
at all easy as in plug-and-play-easy; moreover, getting a cert takes time,
- NATs usually do not have a good fixed CN to use, which means no cert.

This means TLS_RSA_WITH_AES_128_CBC_SHA cannot realistically be relied upon, 
and the client cannot rely on certificate check, even though this 
unfortunately contradicts draft-ietf-behave-rfc3489bis-05 (§ 8.3.1).

OpenPGP resp shared secret auth are even worst, since you would basically need 
to configure both the clients and the NAT with the keyring resp shared 
secret. On top of that, they are not supported by all the common TLS stacks.

So I am afraid we are left with either anonymous TLS "authentication" (if it 
can be called authentication...) or not using TLS at all. At least in the 
first case, protection against passive eavesdroppers is retained, if there is 
any point in having it.

-- 
Rémi Denis-Courmont <[email-masked]>
Research Engineer

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Feb 2007 10:32:27 -0800

> 	Hello,
> 
> I have been looking at the new -01 revision... Now it came to 
> my mind that, hmm, using STUN+TLS was a bit problematic.
> 
> First, I would expect some NATs implementors to not want to 
> bother putting a TLS stack. 

Agreed.  The counter-argument is that many NATs already include 
HTTPS for their own administration.

> But I cannot really comment on that, not being a 
> NAT implementor. 

Establishing a TLS connection with your outer-most NAT only protects 
against one specific attack described in section 8.3,
http://tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-01#secti
on-8.3:

    >
    >     8.3. Rogue STUN Server
    >
    >     As described in Section 6, a STUN client can learn its
    >     outer-most NAT runs an embedded STUN server.  However,
    >     without the STUN client's knowledge, the outer-most NAT
    >     may acquire a new IP address.  This could occur when
    >     the NAT moves to a new mobile network or its DHCP lease
    >     expires.  When the NAT acquires a new IP address, the
    >     STUN client will send a STUN Binding Request to the
    >     NAT's prior public IP address, which will be routed to
    >     the NAT's previous address.
    >
    >     If an attacker runs a rogue STUN server on that
    >     address, the attacker has effectively compromised the
    >     STUN server (the attacked described in section 12.2.1
    >     of [RFC3489]).  The attacker will send STUN Binding
    >     Responses indicating his IP address, which will be
    >     indistinguishable, to the STUN client, from the
    >     behavior of the legitimate STUN server.
    >
    >     To defend against this attack, the STUN client and STUN
    >     server obtain a short-term password as described in
    >     section Section 5.6.
    >

To protect against this attack, it isn't necessary to authenticate the
STUN server embedded in the outer-most NAT; the only time an attacker
could take advantage of the lack of authentication is if the attacker
acquired your outer-most NAT's IP address between the time you learned
it and the time you made a TLS connection to it.  Specifically, the 
attacker would have to acquire that IP address between steps 6 and 7 
of Figure 2 in section 4:

 >
 >    STUN Client                        NAT     STUN Server
 >       |                               |          |
 >  1.   |-----TLS/TCP----------------------------->|   }
 >  2.   |-----Shared Secret Request (TLS)--------->|    }
 >  3.   |<----Shared Secret Response (TLS)---------|     } normal STUN
 >  4.   |-----TCP connection closed--------------->|     } behavior
 >  5.   |-----Binding Request (UDP)--------------->|    }
 >  6.   |<----Binding Response (UDP)---------------|   }
 >       |                               |          |
 >  7.   |-----TLS/TCP------------------>|          |   }
 >  8.   |--Shared Secret Request (TLS)->|          |    }
 >  9.   |<-Shared Secret Response (TLS)-|          |     } NAT Control
 > 10.   |--TCP connection closed------->|          |     } STUN Usage
 > 11.   |--Binding Request (UDP)------->|          |    }
 > 12.   |<-Binding Response (UDP)-------|          |   }
 >       |                               |          |
 >

> This means TLS_RSA_WITH_AES_128_CBC_SHA cannot realistically 
> be relied upon, and the client cannot rely on certificate 
> check, even though this unfortunately contradicts 
> draft-ietf-behave-rfc3489bis-05 (§ 8.3.1).
> 
> OpenPGP resp shared secret auth are even worst, since you 
> would basically need to configure both the clients and the 
> NAT with the keyring resp shared secret. On top of that, 
> they are not supported by all the common TLS stacks.
> 
> So I am afraid we are left with either anonymous TLS 
> "authentication" (if it can be called authentication...) or 
> not using TLS at all. At least in the first case, protection 
> against passive eavesdroppers is retained, if there is any 
> point in having it.

I am on the fence, myself, if the attack described in section 8.3
is sufficiently 'real' to bother with TLS.  If you're going to use
encrypted an transport for your data (SRTP, for example), the
attacker will only be able to collect IP addresses or interfere
with the session (delay/drop packets); the attacker cannot listen
to the session.

There are other ways to accomplish similar protection, without using
TLS.  One technique is to have the NAT's embedded STUN server return a
NONCE in each response.  That NONCE would be a random value that
persists until the NAT's embedded STUN server re-initializes (such as
when it reboots).  The STUN client could simply verify that all
subsequent communications with the NAT's embedded STUN server has the
same NONCE.  This would provide identical protection against the
attack described in section 8.3 as TLS.

I can write that up if you think it would be useful.

-d