RFC 7376

Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)

📅 published September 2014, from ietf

RFC 7376 💖 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)

okay bestie, so this is RFC 7376 📖 and it came out in September 2014 as an Informational doc, which means it's published for informational purposes and is not a Standards Track spec ✨. It was written by T. Reddy and R. Ravindranath from Cisco, M. Perumal from Ericsson, and A. Yegin from Samsung 🧚. The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it stands on its own 🌸.

Abstract 🌸

this doc is all about the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages 🔐.

Status of This Memo 🎀

this doc is not an Internet Standards Track spec. it's published for informational purposes 📚.

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.

info about the current status of this doc, any errata, and how to send feedback can be found at http://www.rfc-editor.org/info/rfc7376 💅.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. please actually read those because they spell out your rights and restrictions for this doc 🧾. any Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🖤.

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   4
3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Problems with STUN Long-Term Authentication for TURN  . . . .   4
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction ✨

okay so Traversal Using Relays around NAT (TURN) [RFC5766] is a protocol that people use a LOT to boost connectivity for Peer-to-Peer (P2P) apps (see Section 2.7 of [RFC5128]) 🦋. it lets a connection get set up even when one or both sides can't do a direct P2P connection 💅. the TURN server is also a building block for interactive, real-time stuff like audio, video, collaboration, games, and more, between two peer web browsers using the Web Real-Time Communication (WebRTC) [WebRTC-Overview] framework 🎮.

a TURN server also shows up in these scenarios 🌈:

  • For privacy, users of WebRTC-based web applications may use a TURN server to hide host candidate addresses from the remote peer 🙈.
  • Enterprise networks deploy firewalls that typically block UDP traffic. When SIP user agents or WebRTC endpoints sit behind those firewalls, media can't go over UDP across the firewall and has to go over TCP instead, which gives a different user experience 😭. in those cases, a TURN server deployed in the DeMilitarized Zone (DMZ) might be used to get through the firewalls 🧱.
  • The use case in Section 3.3.5 of [WebRTC-Use-Cases] ("Simple Video Communication Service, enterprise aspects") is about deploying a TURN server in the DMZ to audit all media sessions from inside an Enterprise premises to any external peer 🕵️.
  • A TURN server could also be deployed for RTP Mobility [TURN-Mobility], etc. 🛰️
  • A TURN server may be used for IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying [RFC6156] 🔁.
  • Interactive Connectivity Establishment (ICE) [RFC5245] connectivity checks using server reflexive candidates could fail when the endpoint is behind a NAT [RFC3235] that performs address-dependent mapping, as described in Section 4.1 of [RFC4787] 🙃. in those cases, a relayed candidate allocated from the TURN server is used for media 🎀.

okay so Session Traversal Utilities for NAT (STUN) [RFC5389] specifies an authentication mechanism called the long-term credential mechanism 🔑. Section 4 of TURN [RFC5766] says that TURN servers and clients must implement this mechanism. that same section also says the TURN server must demand that all requests from the client be authenticated using this mechanism, or that an equally strong or stronger mechanism for client authentication be used 💪.

in the scenarios above, applications would use the ICE protocol to gather candidates 🧩. an ICE agent can use TURN to learn server reflexive and relayed candidates 🦋. if the TURN server requires that the TURN request be authenticated, then the ICE agent will use the long-term credential mechanism explained in Section 10 of [RFC5389] for authentication and message integrity 🔐. Section 10 of the TURN specification [RFC5766] explains why the long-term credential mechanism matters for mitigating various attacks 🛡️. client authentication is essential to keep unauthorized users away from the TURN server, and misusing credentials could cost the victim TURN server a lot 💸.

this doc focuses on listing security problems and practical problems with current STUN authentication for TURN, so it can serve as the basis for stronger authentication mechanisms 🏗️.

an Allocate request is more likely than a Binding request to be identified by a server admin as needing client authentication and message integrity protection 🧐. so the issues in this doc about STUN authentication mostly apply in the context of TURN messages 💜.

2. Notational Conventions 🎀

this doc uses terminology defined in [RFC5389] and [RFC5766] 📝.

3. Scope 🌸

this doc can be used as input for designing solutions that address problems with the current STUN authentication for TURN messages 🧠.

4. Problems with STUN Long-Term Authentication for TURN 😭

  1. As described in [RFC5389], the long-term credential mechanism could give users a long-term credential in the form of a traditional "log-in" username and password, and this credential would not change for extended periods of time 🥲. the key derived from the user credentials would be used to provide message integrity for every TURN request and response. but an attacker who can eavesdrop on a message exchange between a client and server can figure out the password by trying a bunch of candidate passwords. they check each one by calculating the message integrity with it and comparing the result to the message integrity value in the MESSAGE-INTEGRITY attribute 👀💀.
  2. When a TURN server is deployed in the DMZ and requires that requests be authenticated using the long-term credential mechanism described in [RFC5389], the TURN server needs to know the username and password so it can validate the message integrity of requests and provide message integrity for responses 🛠️. that means extra management overhead on the TURN server 😮‍💨. long-term credentials (username, realm, and password) need to be stored on the server side using an MD5 hash over the credentials, and that is not considered best current practice 🚫. [RFC6151] discusses security vulnerabilities of MD5 and encourages implementers not to use it ⚠️. it's not possible to use STUN long-term credentials in implementations that comply with US FIPS 140-2 [FIPS-140-2], since MD5 isn't an approved algorithm 🇺🇸.
  3. The long-term credential mechanism discussed in [RFC5389] says the TURN client must include a username value in the USERNAME STUN attribute 🫣. an adversary snooping on the TURN messages between the TURN client and server can identify the users involved in the call, which leaks privacy 🕵️‍♀️. if TURN usernames are linked to real usernames, that leakage happens for sure. but in some scenarios TURN usernames don't need to be linked to any real usernames given to users, because the usernames are just provisioned on a per-company basis 🏢✨.

6.1. Normative References 📚

these are the must-reads, bestie 💅 the ones the spec leans on hard:

6.2. Informative References 🦋

these ones aren't required reading, but they're giving context and I'm obsessed with all of them ✨

Acknowledgments 🫶

the authors wanted to thank Dan Wing, Harald Alvestrand, Sandeep Rao, Prashanth Patil, Pal Martinsen, Marc Petit-Huguenin, Gonzalo Camarillo, Brian E. Carpenter, Spencer Dawkins, Adrian Farrel, and Simon Perreault for their comments and reviews. the squad that showed up for this one 🙌✨

Authors' Addresses 💌

the four people who wrote this, with their contact info:

Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka  560103
India

EMail: tireddy@cisco.com


Ram Mohan Ravindranath
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka  560103
India

EMail: rmohanr@cisco.com


Muthu Arul Mozhi Perumal
Ericsson
Ferns Icon
Doddanekundi, Mahadevapura
Bangalore, Karnataka  560037
India

EMail: muthu.arul@gmail.com


Alper Yegin
Samsung
Istanbul
Turkey

EMail: alper.yegin@yegin.org
📦 where this page comes from