Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

[Added rtcweb since I am not sure if everyone involved there are following this discussion in behave]

Thanks for the review. See inline.. 

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: [e-mail]
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|> The text and the algorithm in the draft are significantly simplified in this updated version.
|>
|> Comments welcome..
|
|MUCH better introduction. Now I feel like I understand the need exactly.
|
|The "Design Considerations" section is still very confusing to me.
|
|>    Though ICE specifies STUN Binding indications to be used for
|>    keepalives, it requires that an agent be prepared to receive
|>    connectivity check as well.  If a connectivity check is received, a
|>    response is generated, but there is no impact on ICE processing, as
|>    described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE restart..

|
|>    While a WebRTC browser could verify whether the peer continues to
|>    send SRTCP reports before sending traffic to the peer, the usage of
|>    SRTCP together with Security Descriptions [RFC4568] requires exposing
|>    the media keys to the JavaScript and renders SRTCP unsuitable for
|>    consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"? Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet.

|
|>    For consent, calculating the SHA1 HMAC is necessary for MESSAGE-
|>    INTEGRITY which is computationally expensive.
|
|You need to qualify "expensive". It's certainly not expensive in all cases.
|
|>    Security analysis
|>    concluded that the STUN 96 bits transaction ID is sufficient for
|>    consent, without needing MESSAGE-INTEGRITY.
|
|What analysis? You would need to explain it in detail. But if that's not
|part of your suggested solution, just remove the sentence.

Agree it could be elaborated. The intention was to say the foll:

   STUN requires the 96 bits transaction ID to be uniformly and randomly
   chosen from the interval 0 .. 2**96-1, and be cryptographically
   random. This should suffice to prevent off path attacks on consent 
   freshness, so MESSAGE-INTEGRITY is not necessary from a security
   perspective.

However, MESSAGE-INTEGRITY is still used to maintain backward compatibility 
with legacy ICE/ICE-lite implementations.

|
|Now on to section "4. Solution Overview"...
|
|>    Every Tc seconds, the WebRTC browser sends a STUN Binding Request to
|>    the peer.  This request MUST use a new, cryptographically random
|>    Transaction ID [RFC4086], and is formatted as for an ICE connectivity
|>    check [RFC5245].  A valid STUN Binding Response is also formatted as
|>    for an ICE connectivity check [RFC5245].  The STUN Binding Request
|>    and STUN Binding Response are validated as for an ICE connectivity
|>    check [RFC5245].
|
|Couldn't this whole paragraph be simplified to "Every Tc seconds, the
|WebRTC browser sends an ICE connectivity check."? Is there anything new
|here besides the "every Tc" thing?

The difference from the ICE connectivity check is that there is no exponential back off for retransmissions.
 
|
|>    Liveness timer: If no packets have been received on the local port in
|>    Tr seconds, the WebRTC browser MUST inform the JavaScript that
|>    connectivity has been lost.  The JavaScript application will use this
|>    notification however it desires (e.g., cease transmitting to the
|>    remote peer, provide a notification to the user, etc.).
|
|This seems to me like it will not fulfill the goal set in the abstract:
|"to ensure that a malicious JavaScript cannot use the browser as a
|platform for launching attacks". If the JavaScript is free to ignore the
|notification from the browser, then it has no security benefits. If you
|want to reach that goal, the browser needs to forcefully stop transmitting.

That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on that candidate pair, including liveness checks, if there is a consent failure.

|
|>    When not actively sending traffic on a nominated candidate pair,
|>    performing consent freshness does not serve any purpose from a
|>    security perspective.
|
|I don't understand what this means. Why is the "security perspective"
|important here? Aren't we concerned about keepalives?

You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness would be required for sending them as well?

|
|>    In ICE [RFC5245] the STUN request/response are protected with
|>    MESSAGE-INTEGRITY, using an ephemeral username and password exchanged
|>    in the SDP ice-ufrag and ice-pwd attributes.  This prevents ICE from
|>    accidentally connecting to an in-intended peer, in that ICE will only
|>    connect to a peer that also knows the same username and password
|>    (exchanged in call signaling).  Once that connection to the remote
|>    peer has been established with ICE, the consent to continue sending
|>    traffic does not benefit from re-asserting that same username and
|>    password, so long as the senders and receiver's IP addresses remain
|>    the same (as they usually do).
|
|I had not understood from the text that there was no auth stuff in the
|request. The text said "This request [...] is formatted as for an ICE
|connectivity check [RFC5245]." I thought that included auth stuff.
|
|The explanation why no auth stuff in the request is acceptable should be
|moved to section 3.

Agree, it could be moved under design considerations.

Muthu 

|
|Simon
|_______________________________________________
|Behave mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/behave