idnits 2.17.1 draft-ietf-tram-auth-problems-00.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 (March 24, 2014) is 3684 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6544' is defined on line 254, but no explicit reference was found in the text ** 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-09 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 == Outdated reference: A later version (-07) exists of draft-wing-mmusic-ice-mobility-06 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE T. Reddy 3 Internet-Draft Ram. Ravindranath 4 Intended status: Informational Muthu. Perumal 5 Expires: September 25, 2014 Cisco 6 A. Yegin 7 Samsung 8 March 24, 2014 10 Problems with STUN Authentication for TURN 11 draft-ietf-tram-auth-problems-00 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 September 25, 2014. 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 usage of STUN Authentication . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The TURN server is a building block to support interactive, real-time 67 communication using audio, video, collaboration, games, etc., between 68 two peer web browsers using the Web Real-Time communication (WebRTC) 69 [I-D.ietf-rtcweb-overview] framework. The use-case explained in 70 "Simple Video Communication Service, enterprise aspects" 71 (Section 3.2.5 of [I-D.ietf-rtcweb-use-cases-and-requirements]) 72 refers to deploying a TURN[RFC5766] server in the DMZ to audit all 73 media sessions from inside an Enterprise premises to any external 74 peer. TURN server could also be deployed for RTP Mobility 75 [I-D.wing-mmusic-ice-mobility] etc. 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 DMZ 87 MAY be used to traverse Firewalls. 89 o TURN Server may be used for IPv4-to-IPv6, IPv6-to-IPv6, and IPv6 90 -to-IPv4 relaying [RFC6156]. 92 o ICE connectivity checks using server-reflexive candidates could 93 fail when the endpoint is behind NAT that performs Address- 94 dependent mapping. In such cases relayed candidate allocated from 95 the TURN server is used for media. 97 STUN [RFC5389] specifies an authentication mechanism called the long- 98 term credential mechanism. TURN [RFC5766] in section 4 specifies 99 that TURN servers and clients MUST implement this mechanism and the 100 TURN server MUST demand that all requests from the client be 101 authenticated using this mechanism, or that a equally strong or 102 stronger mechanism for client authentication be used. 104 In the above scenarios RTCWEB based web applications would use 105 Interactive Connectivity Establishment (ICE) protocol [RFC5245] for 106 gathering candidates. ICE agent can use TURN to learn server- 107 reflexive and relayed candidates. If the TURN server requires the 108 TURN request to be authenticated then ICE agent will use the long- 109 term credential mechanism explained in section 10 of [RFC5389] for 110 authentication and message integrity. TURN specification [RFC5766] 111 in section 10 explains the importance of long-term credential 112 mechanism to mitigate various attacks. With proposals 113 like[I-D.thomson-mmusic-rtcweb-bw-consent] that defines a STUN 114 BANDWIDTH attribute for requesting bandwidth allocation at a TURN 115 server, STUN authentication becomes further important to prevent un- 116 authorized users from accessing the TURN server and misuse of 117 credentials could impose significant cost on the victim TURN server. 119 This note focuses on listing the problems with current STUN 120 authentication for TURN so that it can serve as the basis for 121 stronger authentication mechanisms. 123 Compared to a Binding request the Allocate request is more likely to 124 be identified by a server administrator as needing client 125 authentication and integrity protection of messages exchanged. 126 Hence, the issues discussed here in STUN authentication are 127 applicable mainly in the context of TURN messages. 129 2. Notational Conventions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 This note uses terminology defined in [RFC5389], [RFC5766]. 137 3. Scope 139 This document can be used as an input to design solution(s) to 140 address the problems with the current STUN authentication for TURN 141 messages. 143 4. Problems with usage of STUN Authentication 145 1. The long-term credential mechanism in [RFC5389] could use 146 traditional "log-in" username and password given to users which 147 does not change for extended periods of time and uses the key 148 derived from user credentials to generate message integrity for 149 every TURN request/response. An attacker that is capable of 150 eavesdropping on a message exchange between a client and server 151 can determine the password by trying a number of candidate 152 passwords and checking if one of them is correct by calculating 153 the message-integrity of the message using these candidate 154 passwords and comparing with the message integrity value in the 155 MESSAGE-INTEGRITY attribute. 157 2. When TURN server is deployed in DMZ and requires requests to be 158 authenticated using the long-term credential mechanism in 159 [RFC5389], TURN server needs to be aware of the username and 160 password to validate the message integrity of the requests and to 161 provide message integrity for responses. This results in 162 management overhead on the TURN server. 164 3. The long-term credential mechanism in [RFC5389] requires that the 165 TURN client must include username value in the USERNAME STUN 166 attribute. An adversary snooping the TURN messages between the 167 TURN client and server can identify the users involved in the 168 call resulting in privacy leakage. In certain scenarios TURN 169 usernames need not be linked to any real usernames given to users 170 as they are just provisioned on a per company basis. 172 4. An Attacker posing as a TURN server challenges the client to 173 authenticate, learns the USERNAME of the client and later snoops 174 the traffic from the client identifying the user activity 175 resulting in privacy leakage. 177 5. Hosting multiple realms on a single IP address is challenging 178 with TURN. When a TURN server needs to send the REALM attribute 179 in response to an unauthenticated request, it has no useful 180 information for determining which realm it should send, except 181 the source transport address of the TURN request. Note this is a 182 problem with multi-tenant scenarios only. This may not be a 183 problem when TURN server is located in enterprise premises. 185 6. In WebRTC the Javascript needs be know the username and password 186 to use in W3C RTCPeerConnection API to access the TURN server. 187 This exposes the user credentials to the Javascript which could 188 be malicious. 190 5. Security Considerations 192 This document lists problems with current STUN authentication for 193 TURN so that it can serve as the basis for stronger authentication 194 mechanisms. 196 6. IANA Considerations 198 This document does not require any action from IANA. 200 7. Acknowledgments 202 Authors would like to thank Dan Wing, Harald Alvestrand, Sandeep Rao, 203 Prashanth Patil, Pal Martinsen and Simon Perreault for their comments 204 and review. 206 8. References 208 8.1. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, March 1997. 213 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 214 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 215 October 2008. 217 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 218 Relays around NAT (TURN): Relay Extensions to Session 219 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 221 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 222 Using Relays around NAT (TURN) Extension for IPv6", RFC 223 6156, April 2011. 225 8.2. Informative References 227 [I-D.ietf-rtcweb-overview] 228 Alvestrand, H., "Overview: Real Time Protocols for Brower- 229 based Applications", draft-ietf-rtcweb-overview-09 (work 230 in progress), February 2014. 232 [I-D.ietf-rtcweb-use-cases-and-requirements] 233 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 234 Time Communication Use-cases and Requirements", draft- 235 ietf-rtcweb-use-cases-and-requirements-14 (work in 236 progress), February 2014. 238 [I-D.thomson-mmusic-rtcweb-bw-consent] 239 Thomson, M. and B. Aboba, "Bandwidth Constraints for 240 Session Traversal Utilities for NAT (STUN)", draft- 241 thomson-mmusic-rtcweb-bw-consent-00 (work in progress), 242 October 2012. 244 [I-D.wing-mmusic-ice-mobility] 245 Wing, D., Reddy, T., Patil, P., and P. Martinsen, 246 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 247 mobility-06 (work in progress), February 2014. 249 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 250 (ICE): A Protocol for Network Address Translator (NAT) 251 Traversal for Offer/Answer Protocols", RFC 5245, April 252 2010. 254 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 255 "TCP Candidates with Interactive Connectivity 256 Establishment (ICE)", RFC 6544, March 2012. 258 Authors' Addresses 260 Tirumaleswar Reddy 261 Cisco Systems, Inc. 262 Cessna Business Park, Varthur Hobli 263 Sarjapur Marathalli Outer Ring Road 264 Bangalore, Karnataka 560103 265 India 267 Email: tireddy@cisco.com 269 Ram Mohan Ravindranath 270 Cisco Systems, Inc. 271 Cessna Business Park, Varthur Hobli 272 Sarjapur Marathalli Outer Ring Road 273 Bangalore, Karnataka 560103 274 India 276 Email: rmohanr@cisco.com 277 Muthu Arul Mozhi Perumal 278 Cisco Systems, Inc. 279 Cessna Business Park 280 Sarjapur-Marathahalli Outer Ring Road 281 Bangalore, Karnataka 560103 282 India 284 Email: mperumal@cisco.com 286 Alper Yegin 287 Samsung 288 Istanbul 289 Turkey 291 Email: alper.yegin@yegin.org