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