idnits 2.17.1 draft-reddy-behave-turn-auth-04.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 (September 30, 2013) is 3862 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6544' is defined on line 252, 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-08 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-11 == Outdated reference: A later version (-07) exists of draft-wing-mmusic-ice-mobility-05 -- 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: Standards Track Muthu. Perumal 5 Expires: April 03, 2014 Cisco 6 A. Yegin 7 Samsung 8 September 30, 2013 10 Problems with STUN Authentication for TURN 11 draft-reddy-behave-turn-auth-04 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 April 03, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 . . . . . . . . . 3 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 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 144 1. The long-term credential mechanism in [RFC5389] could use 145 traditional "log-in" username and password given to users which 146 does not change for extended periods of time and uses the key 147 derived from user credentials to generate message integrity for 148 every TURN request/response. An attacker that is capable of 149 eavesdropping on a message exchange between a client and server 150 can determine the password by trying a number of candidate 151 passwords and checking if one of them is correct by calculating 152 the message-integrity of the message using these candidate 153 passwords and comparing with the message integrity value in the 154 MESSAGE-INTEGRITY attribute. 156 2. When TURN server is deployed in DMZ and requires requests to be 157 authenticated using the long-term credential mechanism in 158 [RFC5389], TURN server needs to be aware of the username and 159 password to validate the message integrity of the requests and to 160 provide message integrity for responses. This results in 161 management overhead on the TURN server. 163 3. The long-term credential mechanism in [RFC5389] requires that the 164 TURN client must include username value in the USERNAME STUN 165 attribute. An adversary snooping the TURN messages between the 166 TURN client and server can identify the users involved in the 167 call resulting in privacy leakage. In certain scenarios TURN 168 usernames need not be linked to any real usernames given to users 169 as they are just provisioned on a per company basis. 171 4. An Attacker posing as a TURN server challenges the client to 172 authenticate, learns the USERNAME of the client and later snoops 173 the traffic from the client identifying the user activity 174 resulting in privacy leakage. 176 5. Hosting multiple realms on a single IP address is challenging 177 with TURN. When a TURN server needs to send the REALM attribute 178 in response to an unauthenticated request, it has no useful 179 information for determining which realm it should send, except 180 the source transport address of the TURN request. Note this is a 181 problem with multi-tenant scenarios only. This may not be a 182 problem when TURN server is located in enterprise premises. 184 6. In WebRTC the Javascript needs be know the username and password 185 to use in W3C RTCPeerConnection API to access the TURN server. 186 This exposes the user credentials to the Javascript which could 187 be malicious. 189 5. Security Considerations 190 This document lists problems with current STUN authentication for 191 TURN so that it can serve as the basis for stronger authentication 192 mechanisms. 194 6. IANA Considerations 196 This document does not require any action from IANA. 198 7. Acknowledgments 200 Authors would like to thank Dan Wing, Harald Alvestrand, Sandeep Rao, 201 Prashanth Patil, Pal Martinsen and Simon Perreault for their comments 202 and review. 204 8. References 206 8.1. Normative References 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 212 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 213 October 2008. 215 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 216 Relays around NAT (TURN): Relay Extensions to Session 217 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 219 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 220 Using Relays around NAT (TURN) Extension for IPv6", RFC 221 6156, April 2011. 223 8.2. Informative References 225 [I-D.ietf-rtcweb-overview] 226 Alvestrand, H., "Overview: Real Time Protocols for Brower- 227 based Applications", draft-ietf-rtcweb-overview-08 (work 228 in progress), September 2013. 230 [I-D.ietf-rtcweb-use-cases-and-requirements] 231 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 232 Time Communication Use-cases and Requirements", draft- 233 ietf-rtcweb-use-cases-and-requirements-11 (work in 234 progress), June 2013. 236 [I-D.thomson-mmusic-rtcweb-bw-consent] 237 Thomson, M. and B. Aboba, "Bandwidth Constraints for 238 Session Traversal Utilities for NAT (STUN)", draft- 239 thomson-mmusic-rtcweb-bw-consent-00 (work in progress), 240 October 2012. 242 [I-D.wing-mmusic-ice-mobility] 243 Wing, D., Reddy, T., Patil, P., and P. Martinsen, 244 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 245 mobility-05 (work in progress), September 2013. 247 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 248 (ICE): A Protocol for Network Address Translator (NAT) 249 Traversal for Offer/Answer Protocols", RFC 5245, April 250 2010. 252 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 253 "TCP Candidates with Interactive Connectivity 254 Establishment (ICE)", RFC 6544, March 2012. 256 Authors' Addresses 258 Tirumaleswar Reddy 259 Cisco Systems, Inc. 260 Cessna Business Park, Varthur Hobli 261 Sarjapur Marathalli Outer Ring Road 262 Bangalore, Karnataka 560103 263 India 265 Email: tireddy@cisco.com 267 Ram Mohan Ravindranath 268 Cisco Systems, Inc. 269 Cessna Business Park, Varthur Hobli 270 Sarjapur Marathalli Outer Ring Road 271 Bangalore, Karnataka 560103 272 India 274 Email: rmohanr@cisco.com 275 Muthu Arul Mozhi Perumal 276 Cisco Systems, Inc. 277 Cessna Business Park 278 Sarjapur-Marathahalli Outer Ring Road 279 Bangalore, Karnataka 560103 280 India 282 Email: mperumal@cisco.com 284 Alper Yegin 285 Samsung 286 Istanbul 287 Turkey 289 Email: alper.yegin@yegin.org