Re: [rtcweb] What is consent?

[Eric Rescorla <[e-mail]>]

On Mon, Sep 10, 2012 at 5:30 PM, Martin Thomson
<[e-mail]> wrote:
> What specific properties of a STUN Binding request does the browser
> use to determine that the peer has consented to receive packets?
>
> From what I can infer, it's simply the existence of a response.  That
> is insufficient.
>
> -security says:
>    [...]  ICE provides this verification as
>    well, by using the STUN credentials as a form of per-session shared
>    secret.  Those credentials are known to the Web application, but
>    would need to also be known and used by the STUN-receiving element to
>    be useful.
>
> But that's not strictly correct.  The Binding response necessarily
> does not include MESSAGE-INTEGRITY, which is the critical tie to
> per-session credentials.

You lost me here.  RFC 5389 specifically requires that if the
client provided MESSAGE-INTEGRITY in the Binding Response
in S 10.1.2:

   If these checks pass, the agent continues to process the request or
   indication.  Any response generated by a server MUST include the
   MESSAGE-INTEGRITY attribute, computed using the password utilized to
   authenticate the request.  The response MUST NOT contain the USERNAME
   attribute.

And the client is required to check it in 10.1.3:

10.1.3.  Receiving a Response

   The client looks for the MESSAGE-INTEGRITY attribute in the response.
   If present, the client computes the message integrity over the
   response as defined in Section 15.4, using the same password it
   utilized for the request.  If the resulting value matches the
   contents of the MESSAGE-INTEGRITY attribute, the response is
   considered authenticated.  If the value does not match, or if
   MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if
   it was never received.  This means that retransmits, if applicable,
   will continue.


-Ekr