1270514 - Implement STUN binding request auth with Long Term Credential mechanism

Status: NEW

(Core :: WebRTC: Networking, defect, P4)

Description

[u507892]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/49.0.2623.108 Chrome/49.0.2623.108 Safari/537.36

Steps to reproduce:

coTURN(Coturn-4.5.0.2 'dan Eider') with secure-stun config option 
and mozilla-central


Actual results:

FF do not send after the 401 auth challenge any new binding request with the LTC credential.


Expected results:

Send a new binding request after 401 with credentials (username, nonce, message integrity, etc.)
Work the same way as TURN LTC is implemented.

Comment 1

[Nils Ohlmeier [:drno]]

According to https://github.com/coturn/coturn/blob/master/README.turnserver secure-stun requires to provide long term credentials for binding requests.

--secure-stun		Require authentication of the STUN Binding request.
By default, the clients are allowed anonymous access to the STUN Binding functionality.

which we don't have support for, according to this:

https://dxr.mozilla.org/mozilla-central/source/media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.c#316

Can you please explain what you need this for, or what you are trying to accomplish by turning on this option?

Comment 2

[u507892]

> Can you please explain what you need this for, or what you are trying to
> accomplish by turning on this option?

Reasons..

Contra:
 *  https://tools.ietf.org/html/rfc5389#section-13  
    it states:

    "It SHOULD NOT utilize the short-term or long-term credential mechanism. This is because the work involved in authenticating the request is more than the work in simply processing it."

    We know that RFC5389 defines this basic(!) server behavior. Despite it propose to not use auth, it still don't prohibit STUN auth usage, and only defines it for basic(!) STUN service.

Pro:
 *  The STUN RFC gives the possibility to use authenticated STUN. 
 *  In coTURN there is an implementation, so people may will use it in this way. 
 *  It would be nice to have at least to have a Warning for devs, that STUN& LTC auth is not yet supported.
 *  I would like to provide STUN service to a closed group. And indicate that I do not provide to everyone, stun auth is filter.
 *  Avoid crawling bots what look for open stun service, and then advertise it and adding extra load on the service through this way.
 *  TURN is an extension STUN protocol, so I would like to use uniform way the STUN auth like TURN.
 *  coTURN is giving out sw VERSION information by default, if I create a patch to give out empty Version information in 401 Challenge, then I could defend and not expose the exact STUN/TURN version, and keep this information to only the users who are authenticated. STUN/TURN version information may could help to find exploit and attack the service.
 *  STUN server with RFC5780 support according NAT behavior discovery STUN gives the possibility for the attacker to detect secondary IP address from the OTHER_ADDRESS attribute. With STUN auth this information could also protected and expose to only a closed group.

Comment 3

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.