Re: [rtcweb] What is consent?

[Martin Thomson <[e-mail]>]

Clearly, I did miss something.  Obviously, this relates to the bit in
ICE where it requires that the STUN backward compatibility measures
are not used.

But it didn't really answer my question.

Clearly, an RFC 3489 STUN server will not pass this basic test.  That
means that we can safely exclude servers like stunserver.org from the
set of consenting peers.

I suspect that for practical reasons we have to tolerate missing
MESSAGE-INTEGRITY and FINGERPRINT.  That means we can at least use old
servers to collect server reflexive addresses.  For those old servers
it's trivial to use the absence of either parameter as an indication
that they do not provide consent.

But the question stands: for STUN servers that are 5389 compliant,
what distinguishes the STUN server from a consenting peer?

--Martin

p.s. I reached my conclusion for the following reasons:
1. Section 7.1.3.2 of RFC 5245, which I presumed to be
complete...which it is, sort of.
2. MESSAGE-INTEGRITY is only of questionable utility in the response
if you assume that the server is ignoring requests that don't have a
valid MESSAGE-INTEGRITY.

On 10 September 2012 17:44, Eric Rescorla <[e-mail]> wrote:
> 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