Subject: [rtcweb] draft-rescorla-rtcweb-security

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Sep 2011 01:04:51 -0700

Much of this document is very good, but the sections on ICE and masking aren't quite right.

The security properties attributed to ICE only exist under a very carefully circumscribed set of conditions.  Unfortunately, Sections 4.2.1 and 4.2.2 aren't clear about this.

The ICE exchange is fine for verifying willingness to accept a particular stream, assuming that the receiver provides an indication of willingness to receive.   In part, this works because the specific characteristics of the stream are negotiated in SDP offer/answer simultaneous with ICE.  However, Section 4.2.1 isn't specific enough about what guarantees are provided by ICE and under what conditions.  An ICE exchange doesn't enable "traffic";  at best it enables media with characteristics specified in SDP offer/answer to be sent.   

Section 4.2.2 says that masking is not necessary for UDP, but the logic behind the statement needs more elaboration. There are lots of potentially nasty things that can be done if a browser can send arbitrary datagrams to a receiver, even if we postulate a STUN exchange.  Things like:

* Sending a datagram that might be mistaken for a DNS response, potentially poisoning the cache. 
* Sending an SNMP set to a device.
* Sourcing a routing packet (e.g. RIPv2). 

It strikes me that Section 4.2.2 is needs to be more specific about the specific threats and the conditions under which they are mitigated via ICE, SDP offer/answer, etc.

4.2.1.  ICE

   Verifying receiver consent requires some sort of explicit handshake,
   but conveniently we already need one in order to do NAT hole-
   punching.  ICE [RFC5245] includes a handshake designed to verify that
   the receiving element wishes to receive traffic from the sender. 

[BA] I believe that the requirement needs to be stronger -- that
the receiver has agreed to specific traffic offered
by the sender.  So if the receiver agrees to receive audio and gets
video instead, that isn't ok.  Similarly, the guarantee shouldn't
permit a browser to DoS a public STUN server, that merely by responding
to a STUN request, hasn't indicated a willingness to receive any
media at all.  Overall, it's important that we get into the specific
conditions under which ICE provides the security guarantees we need. 
More on this later. 

   It is important to remember here that the site initiating ICE is
   presumed malicious; in order for the handshake to be secure the
   receiving element MUST demonstrate receipt/knowledge of some value
   not available to the site (thus preventing it from forging
   responses).  In order to achieve this objective with ICE, the STUN
   transaction IDs must be generated by the browser and MUST NOT be made
   available to the initiating script, even via a diagnostic interface.
4.2.2.  Masking

   Once consent is verified, there still is some concern about
   misinterpretation attacks as described by Huang et al.[huang-w2sp].
   As long as communication is limited to UDP, then this risk is
   probably limited, thus masking is not required for UDP.  I.e., once
   communications consent has been verified, it is most likely safe to
   allow the implementation to send arbitrary UDP traffic to the chosen
   destination, provided that the STUN keepalives continue to succeed.

[BA] Receiving a STUN keepalive (particularly one which is not authenticated)
is not sufficient to protect against UDP-based attacks.  

   However, with TCP the risk of transparent proxies becomes much more
   severe.  If TCP is to be used, then WebSockets style masking MUST be
   employed.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Sep 2011 12:10:45 +0200

On 09/08/11 10:04, Bernard Aboba wrote:
> The security properties attributed to ICE only exist under a very 
> carefully circumscribed set of conditions.  Unfortunately, Sections 
> 4.2.1 and 4.2.2 aren't clear about this.
>
> The ICE exchange is fine for verifying willingness to accept a 
> particular stream, assuming that the receiver provides an indication 
> of willingness to receive.   In part, this works because the specific 
> characteristics of the stream are negotiated in SDP offer/answer 
> simultaneous with ICE.  However, Section 4.2.1 isn't specific enough 
> about what guarantees are provided by ICE and under what conditions.  
> An ICE exchange doesn't enable "traffic";  at best it enables media 
> with characteristics specified in SDP offer/answer to be sent.
I think that what a completed ICE exchange provides is a guarantee that 
someone sending datagrams with the source address of <IP+PORT> has 
access to a) an incoming datagram sent to that <IP+PORT>, and b) a 
secret shared out-of-band. That's all.

We have made the assumption that in correctly implemented applications, 
this means that the listener at <IP+PORT> is willing to receive media as 
negotiated in the same exchange as that which exchanged the shared secret.

>
> Section 4.2.2 says that masking is not necessary for UDP, but the 
> logic behind the statement needs more elaboration. There are lots of 
> potentially nasty things that can be done if a browser can send 
> arbitrary datagrams to a receiver, even if we postulate a STUN 
> exchange.  Things like:
>
This only works if we have completed the ICE exchange to the port that 
is listening for DNS responses.
> * Sending an SNMP set to a device.
This only works if we have completed the ICE exchange to port 161 on the 
device.
> * Sourcing a routing packet (e.g. RIPv2).
Again....
>
> It strikes me that Section 4.2.2 is needs to be more specific about 
> the specific threats and the conditions under which they are mitigated 
> via ICE, SDP offer/answer, etc.
More specific language is usually better. But in this particular 
instance, I have trouble interpreting the argument.
>     punching.  ICE [RFC5245  <http://tools.ietf.org/html/rfc5245>] includes a handshake designed to verify that
> video instead, that isn't ok.
I believe this is outside what ICE can provide - the same issue exists 
if someone asks for 140x100 thumbnail video and gets 8K cinema 
resolution instead.
Agreed that it needs addressing, but now we're into "have to obey 
constraints specified in the media negotiation" territory.
>    Similarly, the guarantee shouldn't
What exactly does a public STUN server respond to? Somehow I doubt that 
it completes an ICE handshake according to RFC 5245.

>     misinterpretation attacks as described by Huang et al.[huang-w2sp  <http://tools.ietf.org/html/draft-rescorla-rtcweb-security-01#ref-huang-w2sp>].
Why not?
Note - the RFC 5389 short term credential mechanism is mandatory for all 
ICE packets. I see no reason to relax this requirement.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb