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