Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 7376 R. Ravindranath
Category: Informational Cisco
ISSN: 2070-1721 M. Perumal
Ericsson
A. Yegin
Samsung
September 2014
Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 7376 R. Ravindranath
Category: Informational Cisco
ISSN: 2070-1721 M. Perumal
Ericsson
A. Yegin
Samsung
September 2014
Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)
NAT会话遍历实用程序的问题（STUN）使用NAT周围的中继进行遍历的长期身份验证（TURN）
Abstract
摘要
This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.
本文档讨论了当前NAT（STUN）会话遍历实用程序的一些安全问题和实际问题，该实用程序使用NAT（TURN）消息周围的中继进行遍历。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7376.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7376.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
Traversal Using Relays around NAT (TURN) [RFC5766] is a protocol that is often used to improve the connectivity of Peer-to-Peer (P2P) applications (as defined in Section 2.7 of [RFC5128]). TURN allows a connection to be established when one or both sides are incapable of a direct P2P connection. The TURN server is also a building block to support interactive, real-time communication using audio, video, collaboration, games, etc., between two peer web browsers using the Web Real-Time Communication (WebRTC) [WebRTC-Overview] framework.
使用NAT（TURN）周围的中继进行遍历[RFC5766]是一种协议，通常用于改善对等（P2P）应用程序的连接性（如[RFC5128]第2.7节所定义）。TURN允许在一方或双方无法建立直接P2P连接时建立连接。TURN服务器也是一个构建块，用于支持使用web实时通信（WebRTC）[WebRTC概述]框架的两个对等web浏览器之间使用音频、视频、协作、游戏等进行交互式实时通信。
A TURN server is also used in the following scenarios:
TURN服务器也用于以下场景：
o For privacy, users of WebRTC-based web applications may use a TURN server to hide host candidate addresses from the remote peer.
o 出于隐私考虑，基于WebRTC的web应用程序的用户可以使用TURN服务器向远程对等方隐藏主机候选地址。
o Enterprise networks deploy firewalls that typically block UDP traffic. When SIP user agents or WebRTC endpoints are deployed behind such firewalls, media cannot be sent over UDP across the firewall but must instead be sent using TCP (which causes a
o 企业网络部署通常阻止UDP通信的防火墙。当SIP用户代理或WebRTC端点部署在此类防火墙之后时，不能通过UDP跨防火墙发送媒体，而必须使用TCP发送媒体（这会导致
different user experience). In such cases, a TURN server deployed in the DeMilitarized Zone (DMZ) might be used to traverse firewalls.
不同的用户体验）。在这种情况下，可以使用部署在非军事区（DMZ）中的TURN服务器来穿越防火墙。
o The use case explained in Section 3.3.5 of [WebRTC-Use-Cases] ("Simple Video Communication Service, enterprise aspects") refers to deploying a TURN server in the DMZ to audit all media sessions from inside an Enterprise premises to any external peer.
o [WebRTC用例]（“简单视频通信服务，企业方面”）第3.3.5节中解释的用例是指在DMZ中部署TURN服务器，以审核从企业内部到任何外部对等方的所有媒体会话。
o A TURN server could also be deployed for RTP Mobility [TURN-Mobility], etc.
o TURN服务器也可以部署用于RTP移动性[TURN Mobility]，等等。
o A TURN server may be used for IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying [RFC6156].
o TURN服务器可用于IPv4到IPv6、IPv6到IPv6和IPv6到IPv4中继[RFC6156]。
o 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 such cases, a relayed candidate allocated from the TURN server is used for media.
o 如[RFC4787]第4.1节所述，当端点位于执行地址相关映射的NAT[RFC3235]之后时，使用服务器自反候选项的交互式连接建立（ICE）[RFC5245]连接检查可能会失败。在这种情况下，从TURN服务器分配的中继候选者用于媒体。
Session Traversal Utilities for NAT (STUN) [RFC5389] specifies an authentication mechanism called the long-term credential mechanism. Section 4 of TURN [RFC5766] specifies that TURN servers and clients must implement this mechanism; Section 4 of TURN [RFC5766] also specifies that 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.
NAT会话遍历实用程序（STUN）[RFC5389]指定一种称为长期凭证机制的身份验证机制。TURN[RFC5766]第4节规定TURN服务器和客户端必须实现此机制；TURN[RFC5766]的第4节还规定，TURN服务器必须要求使用此机制对来自客户端的所有请求进行身份验证，或者使用同样强或更强的客户端身份验证机制。
In the above scenarios, applications would use the ICE protocol for gathering 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 the importance of the long-term credential mechanism to mitigate various attacks. Client authentication is essential to prevent unauthorized users from accessing the TURN server, and misuse of credentials could impose significant cost on the victim TURN server.
在上述场景中，应用程序将使用ICE协议来收集候选人。ICE代理可以使用TURN来学习服务器反射和中继候选。如果TURN服务器要求对TURN请求进行身份验证，则ICE代理将使用[RFC5389]第10节中解释的长期凭证机制进行身份验证和消息完整性。TURN规范[RFC5766]的第10节解释了长期凭证机制对于缓解各种攻击的重要性。客户端身份验证对于防止未经授权的用户访问TURN服务器至关重要，滥用凭据可能会给受害者TURN服务器带来巨大的成本。
This document focuses on listing security problems and practical problems with current STUN authentication for TURN so that it can serve as the basis for stronger authentication mechanisms.
本文档重点列出当前TURN的STUN身份验证的安全问题和实际问题，以便它可以作为更强大的身份验证机制的基础。
An Allocate request is more likely than a Binding request to be identified by a server administrator as needing client authentication and integrity protection of messages exchanged. Hence, the issues discussed here regarding STUN authentication are applicable mainly in the context of TURN messages.
分配请求比绑定请求更有可能被服务器管理员识别为需要客户端身份验证和交换消息的完整性保护。因此，这里讨论的有关STUN身份验证的问题主要适用于TURN消息的上下文。
This document uses terminology defined in [RFC5389] and [RFC5766].
本文件使用[RFC5389]和[RFC5766]中定义的术语。
This document can be used as input for designing solution(s) to address problems with the current STUN authentication for TURN messages.
本文档可作为设计解决方案的输入，以解决当前TURN消息的STUN身份验证问题。
1. As described in [RFC5389], the long-term credential mechanism could provide to users a long-term credential in the form of a traditional "log-in" username and password; 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/response. However, an attacker that is capable of eavesdropping on a message exchange between a client and server can determine the password by trying a number of candidate passwords and checking to see if one of them is correct by calculating the message integrity using these candidate passwords and comparing them with the message integrity value in the MESSAGE-INTEGRITY attribute.
1. 如[RFC5389]所述，长期凭证机制可以以传统的“登录”用户名和密码的形式向用户提供长期凭证；此凭证在较长时间内不会更改。从用户凭据派生的密钥将用于为每个回合请求/响应提供消息完整性。然而能够窃听客户端和服务器之间的消息交换的攻击者可以通过尝试多个候选密码并通过使用这些候选密码计算消息完整性并将其与中的消息完整性值进行比较来检查其中一个密码是否正确来确定密码消息完整性属性。
2. When a TURN server is deployed in the DMZ and requires that requests be authenticated using the long-term credential mechanism as described in [RFC5389], the TURN server needs to be aware of the username and password to validate the message integrity of the requests and to provide message integrity for responses. This results in 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, which is not considered best current practice. [RFC6151] discusses security vulnerabilities of MD5 and encourages implementers not to use it. It is not possible to use STUN long-term credentials in implementations that are compliant with US FIPS 140-2 [FIPS-140-2], since MD5 isn't an approved algorithm.
2. 当在DMZ中部署TURN服务器并要求使用[RFC5389]中所述的长期凭证机制对请求进行身份验证时，TURN服务器需要知道用户名和密码，以验证请求的消息完整性，并为响应提供消息完整性。这会导致TURN服务器上的管理开销。长期凭证（用户名、域和密码）需要存储在服务器端，在凭证上使用MD5哈希，这不是当前的最佳实践。[RFC6151]讨论了MD5的安全漏洞，并鼓励实施者不要使用它。在符合美国FIPS 140-2[FIPS-140-2]的实施中，不可能使用STUN长期凭证，因为MD5不是经批准的算法。
3. The long-term credential mechanism discussed in [RFC5389] specifies that the TURN client must include a username value in the USERNAME STUN attribute. An adversary snooping the TURN messages between the TURN client and server can identify the users involved in the call, resulting in privacy leakage. If TURN usernames are linked to real usernames, then privacy leakage will result, but in certain scenarios TURN usernames need not be linked to any real usernames given to users, as the usernames are just provisioned on a per-company basis.
3. [RFC5389]中讨论的长期凭证机制指定TURN客户端必须在username STUN属性中包含用户名值。敌方窥探TURN客户端和服务器之间的TURN消息可以识别通话中涉及的用户，从而导致隐私泄露。如果TURN用户名链接到真实用户名，则会导致隐私泄露，但在某些情况下，TURN用户名不需要链接到提供给用户的任何真实用户名，因为这些用户名只是按每个公司设置的。
4. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no mechanism for hash agility in the protocol itself, although Section 16.3 of [RFC5389] does discuss a plan for migrating to a more secure algorithm in case HMAC-SHA1 is found to be compromised.
4. STUN身份验证依赖于HMAC-SHA1[RFC2104]。虽然[RFC5389]第16.3节确实讨论了在HMAC-SHA1被发现受损的情况下迁移到更安全算法的计划，但协议本身没有哈希灵活性机制。
5. A man-in-the middle attacker posing as a TURN server challenges the client to authenticate, learns the USERNAME of the client, and later snoops the traffic from the client, thereby identifying user activity; this results in privacy leakage.
5. 中间人攻击者冒充TURN服务器，挑战客户端进行身份验证，了解客户端的用户名，然后窥探来自客户端的流量，从而识别用户活动；这会导致隐私泄露。
6. Hosting multiple realms on a single IP address is challenging with TURN. When a TURN server needs to send the REALM attribute in response to an unauthenticated request, it has no useful information for determining which realm it should send in the response, except the source transport address of the TURN request. Note that this is a problem with multi-tenant scenarios only; this may not be a problem when the TURN server is located in enterprise premises.
6. 在一个IP地址上托管多个领域对TURN来说是一个挑战。当TURN服务器需要发送REALM属性以响应未经身份验证的请求时，除了TURN请求的源传输地址之外，它没有有用的信息来确定应该在响应中发送哪个领域。请注意，这只是多租户场景的问题；当TURN服务器位于企业内部时，这可能不是问题。
7. In WebRTC, the JavaScript code needs to know the username and password to use in the W3C RTCPeerConnection API to access the TURN server. This exposes user credentials to the JavaScript code, which could be malicious; the malicious JavaScript code could then misuse or leak the credentials. If the credentials happen to be used for accessing services other than TURN, then the security implications are much larger.
7. 在WebRTC中，JavaScript代码需要知道在W3C RTPeerConnection API中使用的用户名和密码才能访问TURN服务器。这会向JavaScript代码公开用户凭据，这可能是恶意的；恶意JavaScript代码可能会误用或泄漏凭据。如果凭证恰好用于访问TURN以外的服务，那么安全性影响就大得多。
This document lists problems with current STUN authentication for TURN so that it can serve as the basis for stronger authentication mechanisms.
本文档列出了当前TURN的STUN身份验证存在的问题，以便它可以作为更强大的身份验证机制的基础。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011, <http://www.rfc-editor.org/info/rfc6156>.
[RFC6156]Camarillo，G.，Novo，O.，和S.Perreault，“使用IPv6 NAT（TURN）扩展周围的中继进行遍历”，RFC 6156，2011年4月<http://www.rfc-editor.org/info/rfc6156>.
[FIPS-140-2] NIST, "Security Requirements for Cryptographic Modules", FIPS PUB 140-2, May 2001, <http://csrc.nist.gov/ publications/fips/fips140-2/fips1402.pdf>.
[FIPS-140-2]NIST，“加密模块的安全要求”，FIPS PUB 140-2，2001年5月<http://csrc.nist.gov/ 出版物/fips/fips140-2/fips1402.pdf>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月<http://www.rfc-editor.org/info/rfc2104>.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002, <http://www.rfc-editor.org/info/rfc3235>.
[RFC3235]Senie，D.，“网络地址转换器（NAT）-友好应用程序设计指南”，RFC 32352002年1月<http://www.rfc-editor.org/info/rfc3235>.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月<http://www.rfc-editor.org/info/rfc4787>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008, <http://www.rfc-editor.org/info/rfc5128>.
[RFC5128]Srisuresh，P.，Ford，B.，和D.Kegel，“跨网络地址转换器（NAT）的对等（P2P）通信状态”，RFC 51282008年3月<http://www.rfc-editor.org/info/rfc5128>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011, <http://www.rfc-editor.org/info/rfc6151>.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月<http://www.rfc-editor.org/info/rfc6151>.
[TURN-Mobility] Wing, D., Patil, P., Reddy, T., and P. Martinsen, "Mobility with TURN", Work in Progress, draft-wing-tram-turn-mobility-02, September 2014.
[转弯机动]Wing，D.，Patil，P.，Reddy，T.，和P.Martinsen，“转弯机动”，正在进行的工作，草稿-Wing-tram-TURN-Mobility-022014年9月。
[WebRTC-Overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-11, August 2014.
[WebRTC概述]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-rtcweb-Overview-11，2014年8月。
[WebRTC-Use-Cases] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use-cases and Requirements", Work in Progress, draft-ietf-rtcweb-use-cases-and-requirements-14, February 2014.
[WebRTC用例]Holmberg，C.，Hakanson，S.，和G.Eriksson，“网络实时通信用例和需求”，正在进行的工作，草稿-ietf-rtcweb-Use-Cases-and-Requirements-142014年2月。
Acknowledgments
致谢
The authors would like 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.
作者要感谢Dan Wing、Harald Alvestrand、Sandeep Rao、Prashanth Patil、Pal Martinsen、Marc Petit Hugunin、Gonzalo Camarillo、Brian E.Carpenter、Spencer Dawkins、Adrian Farrel和Simon Perreault的评论和评论。
Authors' Addresses
作者地址
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里萨贾普尔马拉塔利塞斯纳商业园560103
EMail: tireddy@cisco.com
EMail: tireddy@cisco.com
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Ravindranath Cisco Systems，Inc.印度卡纳塔克邦班加罗尔市瓦尔图尔霍布里萨尔贾普尔马拉塔利外环路塞斯纳商业园560103
EMail: rmohanr@cisco.com
EMail: rmohanr@cisco.com
Muthu Arul Mozhi Perumal Ericsson Ferns Icon Doddanekundi, Mahadevapura Bangalore, Karnataka 560037 India
Muthu Arul Mozhi Perumal Ericsson蕨类植物图标Doddanekundi，马哈德瓦普拉班加罗尔，卡纳塔克邦560037印度
EMail: muthu.arul@gmail.com
EMail: muthu.arul@gmail.com
Alper Yegin Samsung Istanbul Turkey
土耳其伊斯坦布尔阿尔珀·耶金酒店
EMail: alper.yegin@yegin.org
EMail: alper.yegin@yegin.org