The STUN and TURN specifications allow for client authentication using usernames and passwords, and call this authentication via long-term credentials. In fact, TURN requires that clients authenticate by this means.
However, I would assume that almost all deployments run their STUN or TURN servers separately from their database server. For example, for a VOIP application that uses TURN servers, presumably all of the user data would be stored in a database, user account management might be primarily handled by a web server, while the clients would still need to be able to authenticate into a separate TURN server.
What’s the best practice for the STUN/TURN server to access the usernames and passwords from the database to authenticate clients? If most deployments or your solution relies upon a particular STUN/TURN server implementation that supports specific features, any recommendations as to STUN/TURN servers would be appreciated as well.
Given that:
- Both of the original STUN authentication schemes (viz. short- and long-term credentials) involve the server knowing the plaintext password of every user;
- The same authentication schemes are susceptible to offline dictionary attack, unless TLS/DTLS is used; and
- There is a general principle that passwords should be handled with secrecy even if it causes great inconvenience for system implementors and operators:
Then it is desirable to keep the long-term passwords off the STUN/TURN server (even if DTLS is used to protect them on the wire), to minimize the attack surface for the database of all passwords.
The viable authentication schemes are therefore:
- Authentication via short-term credentials, permitted by RFC-5766 section 4 because it’s at least as strong as the long-term credential scheme.
- DTLS and authentication with long-term credentials, where the STUN server would make remote calls to a central password store to perform all
MESSAGE-INTEGRITYoperations that require knowledge of passwords. The central password store must be one of the small number of systems subjected to detailed security auditing and control; it would need special new interfaces so that it could be used by the STUN servers. - General protocols for obtaining authorization credentials, e.g A REST API For Access To TURN Services, SAML, Diameter, or even slightly-misused OAuth.
- DTLS and authentication with long-term credentials, where the passwords are assigned solely for the STUN service, and are supposedly unrelated to users’ real passwords.
Of those four, the idea of STUN-specific passwords is the most likely to cause trouble because it will inspire revolt among users who have enough trouble remembering one good password.
The idea of long-term credentials, with special delegation to a central server, is undesirable because it needlessly increases the attack surface on that central server.
The short-term credential scheme is not completely specified; the STUN/TURN specs do not discuss how the credentials are generated or transported. Since it would be necessary to design a protocol to generate those credentials and transport them to the STUN client and STUN server, it would be far less effort to ignore the short-term credential scheme and instead to use one of the new federated protocols.
The choice of general protocol is not very important, but obviously it would be easier to deploy one that would be shared with other services. At the time of writing, however, A REST API For Access To TURN Services is the most complete specification.
Therefore, I recommend use of the REST API to obtain temporary usernames and passwords from an HTTPS server. The STUN/TURN server will validate the usernames and passwords using a secret that it shares with the HTTPS server.