idnits 2.17.1 draft-muthu-behave-consent-freshness-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 (July 15, 2013) is 3931 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) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave Muthu. Perumal 3 Internet-Draft D. Wing 4 Intended status: Standards Track R. Ravindranath 5 Expires: January 16, 2014 T. Reddy 6 Cisco Systems 7 July 15, 2013 9 STUN Usage for Consent Freshness 10 draft-muthu-behave-consent-freshness-04 12 Abstract 14 Verification of peer consent before sending traffic is necessary in 15 WebRTC deployments to ensure that a malicious JavaScript cannot use 16 the browser as a platform for launching attacks. A related problem 17 is session liveness. WebRTC application may want to detect 18 connection failure and take appropriate action. 20 This document describes how a WebRTC browser can verify peer consent 21 to continue sending traffic and detect connection failure. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 16, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 61 5. W3C API Implications . . . . . . . . . . . . . . . . . . . . 5 62 6. Interaction with Keepalives used for Refreshing NAT Bindings 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 66 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 To prevent attacks on WebRTC peers, WebRTC browsers have to ensure 72 the remote peer wants to receive traffic. This is performed both 73 when the session is first established to the remote peer (using ICE 74 connectivity checks), and periodically when for the duration of the 75 session (using the procedure defined in this document). 77 When a session is first established, WebRTC implementations are 78 required to perform STUN connectivity checks as part of ICE 79 [RFC5245]. That initial consent is not described further in this 80 document. 82 Related to consent is loss of connectivity ("liveness"). WebRTC 83 applications want notification of connection failure to take 84 appropriate actions (e.g., alert the user, try switching to a 85 different interface). 87 This document describes a new STUN usage with a request and response 88 which verifies the remote peer consents to receive traffic, and 89 detects loss of liveness. To meet the security needs of consent, the 90 JavaScript application has no control over the consent requests or 91 the requirement to receive a consent response. However, the 92 JavaScript does get notification of consent failure and loss of 93 connectivity. 95 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 Consent: It is the mechanism of obtaining permission from the peer 101 to send traffic on a candidate pair. 103 Consent Freshness: It is the mechanism of obtaining permission from 104 the peer to continue sending traffic on a nominated candidate pair 105 after ICE has concluded. 107 Session Liveness: It is the mechanism of detecting connectivity on a 108 nominated candidate pair after ICE has concluded. 110 Transport Address: The combination of an IP address and port number 111 (such as a UDP or TCP port number). 113 3. Design Considerations 115 Although ICE requires periodic keepalive traffic to be sent in order 116 to keep NAT bindings alive (Section 10 of [RFC5245], [RFC6263]), 117 those keepalives are send-and-forget, and do not evoke a response. A 118 response is necessary both for consent to continue sending traffic, 119 as well as to ensure connectivity. Thus, we need a request/response 120 mechanism. 122 Though ICE specifies STUN Binding indications to be used for 123 keepalives, it requires that an agent be prepared to receive 124 connectivity check as well. If a connectivity check is received, a 125 response is generated, but there is no impact on ICE processing, as 126 described in section 10 of [RFC5245]. 128 While a WebRTC browser could verify whether the peer continues to 129 send SRTCP reports before sending traffic to the peer, the usage of 130 SRTCP together with Security Descriptions [RFC4568] requires exposing 131 the media keys to the JavaScript and renders SRTCP unsuitable for 132 consent freshness. 134 For consent, calculating the SHA1 HMAC is necessary for MESSAGE- 135 INTEGRITY which is computationally expensive. Security analysis 136 concluded that the STUN 96 bits transaction ID is sufficient for 137 consent, without needing MESSAGE-INTEGRITY. However, omitting the 138 MESSAGE-INTEGRITY attribute from STUN Binding request/response to 139 avoid the cost of computing SHA1 would make browsers incapable of 140 verifying consent freshness with legacy ICE/ICE-lite implementations, 141 resulting in backward compatibility issues. 143 The above considerations suggest that STUN Binding request/response 144 is most suitable for performing consent freshness. 146 4. Solution Overview 148 Consent freshness serves as a circuit breaker (so that if the path or 149 remote peer fails the WebRTC browser stops sending all traffic on 150 that remote peer), determining session liveness serves the purpose of 151 notifying the application of connectivity failure so that the 152 application can take appropriate action. 154 The solution uses three values: 156 1. A consent timer, Tc, whose value is determined by the browser. 157 This value MUST be 15 seconds. 159 2. A packet receipt timer, Tr, whose value is determined by the 160 application, but MUST NOT be shorter than 1 second or longer than 161 15 seconds, and SHOULD have a default value of 5 seconds. 163 3. A consent timeout, Tf, which is how many seconds elapse without a 164 consent response before the browser ceases transmission of media. 165 Its value MUST be 15 seconds or less, and the value 15 seconds is 166 RECOMMENDED. 168 A WebRTC browser performs a combined consent freshness and session 169 liveness test using STUN request/response as described below: 171 Every Tc seconds, the WebRTC browser sends a STUN Binding Request to 172 the peer. This request MUST use a new, cryptographically random 173 Transaction ID [RFC4086], and is formatted as for an ICE connectivity 174 check [RFC5245]. A valid STUN Binding Response is also formatted as 175 for an ICE connectivity check [RFC5245]. The STUN Binding Request 176 and STUN Binding Response are validated as for an ICE connectivity 177 check [RFC5245]. 179 If a valid STUN Binding Response is received, the consent timer is 180 reset and fires again Tc seconds later. 182 If a valid STUN Binding Response is not received after 500ms, the 183 STUN Binding Request is retransmitted (with the same Transaction ID 184 and all other fields). As long as a valid STUN Binding Response is 185 not received, this retransmission is repeated every 500ms until Tf 186 seconds have elapsed or a valid response is received. If no valid 187 response is received after Tf seconds, the WebRTC browser MUST quit 188 transmitting traffic to this remote peer. Considering the default 189 value of Tf=15 seconds, this means transmission will stop after 30 190 consent check packets have resulted in no response. 192 Liveness timer: If no packets have been received on the local port in 193 Tr seconds, the WebRTC browser MUST inform the JavaScript that 194 connectivity has been lost. The JavaScript application will use this 195 notification however it desires (e.g., cease transmitting to the 196 remote peer, provide a notification to the user, etc.). Note the 197 definition of a received packet is liberal, and includes an SRTP 198 packet that fails authentication, a STUN Binding Request with an 199 invalid USERNAME or PASSWORD, or any other packet. 201 5. W3C API Implications 203 For the consent freshness and liveness test the W3C specification 204 should provide APIs as described below: 206 1. Ability for the browser to notify the JavaScript that a consent 207 freshness transaction has failed for a media stream and the 208 browser has stopped transmitting for that stream. 210 2. Ability for the JavaScript to start and stop liveness test and 211 set the liveness test interval. 213 3. Ability for the browser to notify the JavaScript that a liveness 214 test has failed for a media stream. 216 6. Interaction with Keepalives used for Refreshing NAT Bindings 218 When not actively sending traffic on a nominated candidate pair, 219 performing consent freshness does not serve any purpose from a 220 security perspective. If consent freshness is not performed during 221 this period, the browser continues to performs the ICE keepalives 222 [RFC5245] or RTP keepalive [RFC6263] to refresh NAT bindings. 224 7. Security Considerations 226 Security considerations discussed in [RFC5245] are to be taken into 227 account. 229 In ICE [RFC5245] the STUN request/response are protected with 230 MESSAGE-INTEGRITY, using an ephemeral username and password exchanged 231 in the SDP ice-ufrag and ice-pwd attributes. This prevents ICE from 232 accidentally connecting to an in-intended peer, in that ICE will only 233 connect to a peer that also knows the same username and password 234 (exchanged in call signaling). Once that connection to the remote 235 peer has been established with ICE, the consent to continue sending 236 traffic does not benefit from re-asserting that same username and 237 password, so long as the senders and receiver's IP addresses remain 238 the same (as they usually do). 240 8. IANA Considerations 242 This document does not require any action from IANA. 244 9. Acknowledgement 246 Thanks to Eric Rescorla, Harald Alvestrand, Martin Thomson, Bernard 247 Aboba, Cullen Jennings and Simon Perreault for their valuable inputs 248 and comments. 250 10. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 256 Requirements for Security", BCP 106, RFC 4086, June 2005. 258 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 259 Description Protocol (SDP) Security Descriptions for Media 260 Streams", RFC 4568, July 2006. 262 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 263 (ICE): A Protocol for Network Address Translator (NAT) 264 Traversal for Offer/Answer Protocols", RFC 5245, April 265 2010. 267 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 268 Keeping Alive the NAT Mappings Associated with RTP / RTP 269 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 271 Authors' Addresses 273 Muthu Arul Mozhi Perumal 274 Cisco Systems 275 Cessna Business Park 276 Sarjapur-Marathahalli Outer Ring Road 277 Bangalore, Karnataka 560103 278 India 280 Email: mperumal@cisco.com 281 Dan Wing 282 Cisco Systems 283 821 Alder Drive 284 Milpitas, California 95035 285 USA 287 Email: dwing@cisco.com 289 Ram Mohan Ravindranath 290 Cisco Systems 291 Cessna Business Park 292 Sarjapur-Marathahalli Outer Ring Road 293 Bangalore, Karnataka 560103 294 India 296 Email: rmohanr@cisco.com 298 Tirumaleswar Reddy 299 Cisco Systems 300 Cessna Business Park, Varthur Hobli 301 Sarjapur Marathalli Outer Ring Road 302 Bangalore, Karnataka 560103 303 India 305 Email: tireddy@cisco.com