idnits 2.17.1 draft-ietf-tram-auth-problems-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 18, 2014) is 3531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-10 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 == Outdated reference: A later version (-03) exists of draft-wing-tram-turn-mobility-00 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM T. Reddy 3 Internet-Draft R. Ravindranath 4 Intended status: Informational Cisco 5 Expires: February 19, 2015 M. Perumal 6 Ericsson 7 A. Yegin 8 Samsung 9 August 18, 2014 11 Problems with STUN long-term Authentication for TURN 12 draft-ietf-tram-auth-problems-05 14 Abstract 16 This document discusses some of the security and practical problems 17 with the current Session Traversal Utilities for NAT (STUN) 18 authentication for Traversal Using Relays around NAT (TURN) messages. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 19, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 56 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Problems with STUN long-term Authentication for TURN . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 8.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Traversal Using Relays around NAT (TURN) [RFC5766] is a protocol that 69 is often used to improve the connectivity of Peer-to-Peer (P2P) 70 applications (as defined in section 2.7 of [RFC5128]). TURN allows a 71 connection to be established when one or both sides is incapable of a 72 direct P2P connection. The TURN server is also a building block to 73 support interactive, real-time communication using audio, video, 74 collaboration, games, etc., between two peer web browsers using the 75 Web Real-Time communication (WebRTC) [I-D.ietf-rtcweb-overview] 76 framework. 78 TURN server is also used in the following scenarios: 80 o Users of WebRTC based web application may use TURN server to hide 81 host candidate addresses from the remote peer for privacy. 83 o Enterprise networks deploy firewalls which typically block UDP 84 traffic. When SIP user agents or WebRTC endpoints are deployed 85 behind such firewalls, media cannot be sent over UDP across the 86 firewall, but must be sent using TCP (which causes a different 87 user experience). In such cases a TURN server deployed in the 88 DeMilitarized Zone (DMZ) might be used to traverse firewalls. 90 o The use-case explained in "Simple Video Communication Service, 91 enterprise aspects" (Section 3.2.5 of 92 [I-D.ietf-rtcweb-use-cases-and-requirements]) refers to deploying 93 a TURN server in the DMZ to audit all media sessions from inside 94 an Enterprise premises to any external peer. 96 o TURN server could also be deployed for RTP Mobility 97 [I-D.wing-tram-turn-mobility] etc. 99 o TURN Server may be used for IPv4-to-IPv6, IPv6-to-IPv6, and IPv6 - 100 to-IPv4 relaying [RFC6156]. 102 o Interactive Connectivity Establishment (ICE) [RFC5245] 103 connectivity checks using server reflexive candidates could fail 104 when the endpoint is behind NAT [RFC3235] that performs Address- 105 dependent mapping as described in section 4.1 of [RFC4787]. In 106 such cases relayed candidate allocated from the TURN server is 107 used for media. 109 STUN [RFC5389] specifies an authentication mechanism called the long- 110 term credential mechanism. TURN [RFC5766] in section 4 specifies 111 that TURN servers and clients must implement this mechanism and the 112 TURN server must demand that all requests from the client be 113 authenticated using this mechanism, or that a equally strong or 114 stronger mechanism for client authentication be used. 116 In the above scenarios applications would use ICE protocol for 117 gathering candidates. ICE agent can use TURN to learn server 118 reflexive and relayed candidates. If the TURN server requires the 119 TURN request to be authenticated then ICE agent will use the long- 120 term credential mechanism explained in section 10 of [RFC5389] for 121 authentication and message integrity. TURN specification [RFC5766] 122 in section 10 explains the importance of long-term credential 123 mechanism to mitigate various attacks, client authentication is 124 essential to prevent un-authorized users from accessing the TURN 125 server and misuse of credentials could impose significant cost on the 126 victim TURN server. 128 This note focuses on listing security and practical problems with 129 current STUN authentication for TURN so that it can serve as the 130 basis for stronger authentication mechanisms. 132 An Allocate request is more likely than a Binding request to be 133 identified by a server administrator as needing client authentication 134 and integrity protection of messages exchanged. Hence, the issues 135 discussed here in STUN authentication are applicable mainly in the 136 context of TURN messages. 138 2. Notational Conventions 140 This note uses terminology defined in [RFC5389], [RFC5766]. 142 3. Scope 144 This document can be used as an input to design solution(s) to 145 address the problems with the current STUN authentication for TURN 146 messages. 148 4. Problems with STUN long-term Authentication for TURN 150 1. The long-term credential mechanism in [RFC5389] could use 151 traditional "log-in" username and password given to users which 152 does not change for extended periods of time and uses the key 153 derived from user credentials to generate message integrity for 154 every TURN request/response. An attacker that is capable of 155 eavesdropping on a message exchange between a client and server 156 can determine the password by trying a number of candidate 157 passwords and checking if one of them is correct by calculating 158 the message-integrity of the message using these candidate 159 passwords and comparing with the message integrity value in the 160 MESSAGE-INTEGRITY attribute. 162 2. When TURN server is deployed in the DMZ and requires requests to 163 be authenticated using the long-term credential mechanism in 164 [RFC5389], TURN server needs to be aware of the username and 165 password to validate the message integrity of the requests and to 166 provide message integrity for responses. This results in 167 management overhead on the TURN server. Long-term credentials 168 (username, realm, and password) need to be stored on the server- 169 side using MD5 hash over the credentials, which is not considered 170 best current practice. [RFC6151] discusses security 171 vulnerabilities of MD5 and encourages not to use it. It is not 172 possible to use STUN long-term credentials in US FIPS 140-2 173 [FIPS-140-2] compliant implementations, since MD5 isn't an 174 approved algorithm. 176 3. The long-term credential mechanism in [RFC5389] requires that the 177 TURN client must include username value in the USERNAME STUN 178 attribute. An adversary snooping the TURN messages between the 179 TURN client and server can identify the users involved in the 180 call resulting in privacy leakage. If TURN usernames are linked 181 to real usernames then it will result in privacy leakage, but in 182 certain scenarios TURN usernames need not be linked to any real 183 usernames given to users as they are just provisioned on a per 184 company basis. 186 4. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no 187 mechanism for hash agility in the protocol itself, although 188 Section 16.3 of [RFC5389] does discuss a plan for migrating to a 189 more secure algorithm in case HMAC-SHA1 is found to be 190 compromised. 192 5. A man-in-the middle attacker posing as a TURN server challenges 193 the client to authenticate, learns the USERNAME of the client and 194 later snoops the traffic from the client identifying the user 195 activity resulting in privacy leakage. 197 6. Hosting multiple realms on a single IP address is challenging 198 with TURN. When a TURN server needs to send the REALM attribute 199 in response to an unauthenticated request, it has no useful 200 information for determining which realm it should send in the 201 response, except the source transport address of the TURN 202 request. Note this is a problem with multi-tenant scenarios 203 only. This may not be a problem when TURN server is located in 204 enterprise premises. 206 7. In WebRTC the Javascript code needs to know the username and 207 password to use in W3C RTCPeerConnection API to access the TURN 208 server. This exposes the user credentials to the Javascript 209 which could be malicious. The malicious java script could misuse 210 or leak the credentials. If the credentials happen to be used 211 for accessing services other than TURN then the security 212 implications are much larger. 214 5. Security Considerations 216 This document lists problems with current STUN authentication for 217 TURN so that it can serve as the basis for stronger authentication 218 mechanisms. 220 6. IANA Considerations 222 This document does not require any action from IANA. 224 7. Acknowledgments 226 Authors would like to thank Dan Wing, Harald Alvestrand, Sandeep Rao, 227 Prashanth Patil, Pal Martinsen, Marc Petit-Huguenin, Gonzalo 228 Camarillo, Brian E Carpenter, Spencer Dawkins, Adrian Farrel and 229 Simon Perreault for their comments and review. 231 8. References 232 8.1. Normative References 234 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 235 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 236 October 2008. 238 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 239 Relays around NAT (TURN): Relay Extensions to Session 240 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 242 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 243 Using Relays around NAT (TURN) Extension for IPv6", RFC 244 6156, April 2011. 246 8.2. Informative References 248 [FIPS-140-2] 249 NIST, , "NIST, "Security Requirements for Cryptographic 250 Modules"", June 2005, 251 . 254 [I-D.ietf-rtcweb-overview] 255 Alvestrand, H., "Overview: Real Time Protocols for 256 Browser-based Applications", draft-ietf-rtcweb-overview-10 257 (work in progress), June 2014. 259 [I-D.ietf-rtcweb-use-cases-and-requirements] 260 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 261 Time Communication Use-cases and Requirements", draft- 262 ietf-rtcweb-use-cases-and-requirements-14 (work in 263 progress), February 2014. 265 [I-D.wing-tram-turn-mobility] 266 Wing, D., Patil, P., Reddy, T., and P. Martinsen, 267 "Mobility with TURN", draft-wing-tram-turn-mobility-00 268 (work in progress), June 2014. 270 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 271 Hashing for Message Authentication", RFC 2104, February 272 1997. 274 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 275 Application Design Guidelines", RFC 3235, January 2002. 277 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 278 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 279 RFC 4787, January 2007. 281 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 282 Peer (P2P) Communication across Network Address 283 Translators (NATs)", RFC 5128, March 2008. 285 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 286 (ICE): A Protocol for Network Address Translator (NAT) 287 Traversal for Offer/Answer Protocols", RFC 5245, April 288 2010. 290 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 291 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 292 RFC 6151, March 2011. 294 Authors' Addresses 296 Tirumaleswar Reddy 297 Cisco Systems, Inc. 298 Cessna Business Park, Varthur Hobli 299 Sarjapur Marathalli Outer Ring Road 300 Bangalore, Karnataka 560103 301 India 303 Email: tireddy@cisco.com 305 Ram Mohan Ravindranath 306 Cisco Systems, Inc. 307 Cessna Business Park, Varthur Hobli 308 Sarjapur Marathalli Outer Ring Road 309 Bangalore, Karnataka 560103 310 India 312 Email: rmohanr@cisco.com 314 Muthu Arul Mozhi Perumal 315 Ericsson 316 Ferns Icon 317 Doddanekundi, Mahadevapura 318 Bangalore, Karnataka 560037 319 India 321 Email: muthu.arul@gmail.com 322 Alper Yegin 323 Samsung 324 Istanbul 325 Turkey 327 Email: alper.yegin@yegin.org