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

[Harald Alvestrand <[e-mail]>]

On 09/08/11 10:04, Bernard Aboba wrote:
> 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.
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:
>
> * Sending a datagram that might be mistaken for a DNS response, 
> potentially poisoning the cache.
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.
>
>
>         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  <http://tools.ietf.org/html/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.
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
> 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.
What exactly does a public STUN server respond to? Somehow I doubt that 
it completes an ICE handshake according to RFC 5245.

>     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  <http://tools.ietf.org/html/draft-rescorla-rtcweb-security-01#ref-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.
Why not?
Note - the RFC 5389 short term credential mechanism is mandatory for all 
ICE packets. I see no reason to relax this requirement.
>      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.
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb