Re: [rtcweb] What is consent?

[Eric Rescorla <[e-mail]>]

On Tue, Sep 11, 2012 at 9:09 AM, Martin Thomson
<[e-mail]> wrote:
> 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.

I'm really not following this.

Responses from the server need to *contain* the MESSAGE-INTEGRITY
field and otherwise are not taken as evidence of consent. This field can
only be generated by a server that has the ICE credentials. So, obviously,
a legacy STUN server won't generate that.

-Ekr