idnits 2.17.1 draft-ietf-rtcweb-stun-consent-freshness-16.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 (August 13, 2015) is 3180 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) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-08 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-11 == Outdated reference: A later version (-18) exists of draft-ietf-tsvwg-rtcweb-qos-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Perumal 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. Wing 5 Expires: February 14, 2016 R. Ravindranath 6 T. Reddy 7 Cisco Systems 8 M. Thomson 9 Mozilla 10 August 13, 2015 12 STUN Usage for Consent Freshness 13 draft-ietf-rtcweb-stun-consent-freshness-16 15 Abstract 17 To prevent WebRTC applications, such as browsers, from launching 18 attacks by sending traffic to unwilling victims, periodic consent to 19 send needs to be obtained from remote endpoints. 21 This document describes a consent mechanism using a new Session 22 Traversal Utilities for NAT (STUN) usage. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 14, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 62 5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Expiration of Consent . . . . . . . . . . . . . . . . . . 4 64 5.2. Immediate Revocation of Consent . . . . . . . . . . . . . 6 65 6. DiffServ Treatment for Consent . . . . . . . . . . . . . . . 7 66 7. DTLS applicability . . . . . . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 11.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 To prevent attacks on peers, endpoints have to ensure the remote peer 78 is willing to receive traffic. Verification of peer consent before 79 sending traffic is necessary in deployments like WebRTC to ensure 80 that a malicious JavaScript cannot use the browser as a platform for 81 launching attacks. This is performed both when the session is first 82 established to the remote peer using Interactive Connectivity 83 Establishment ICE [RFC5245] connectivity checks, and periodically for 84 the duration of the session using the procedures defined in this 85 document. 87 When a session is first established, ICE implementations obtain an 88 initial consent to send by performing STUN connectivity checks. This 89 document describes a new STUN usage with exchange of request and 90 response messages that verifies the remote peer's ongoing consent to 91 receive traffic. This consent expires after a period of time and 92 needs to be continually renewed, which ensures that consent can be 93 terminated. 95 This document defines what it takes to obtain, maintain, and lose 96 consent to send. Consent to send applies to a single 5-tuple. How 97 applications react to changes in consent is not described in this 98 document. The consent mechanism does not update the ICE procedures 99 defined in [RFC5245]. 101 Consent is obtained only by full ICE implementations. An ICE-lite 102 agent (as defined in Section 2.7 of [RFC5245]) does not generate 103 connectivity checks or run the ICE state machine. Hence, an ICE-lite 104 agent does not generate consent checks and will only respond to any 105 checks that it receives. No changes are required to ICE-lite 106 implementations in order to respond to consent checks, as they are 107 processed as normal ICE connectivity checks. 109 2. Applicability 111 This document defines what it takes to obtain, maintain, and lose 112 consent to send using ICE. Section 4.4 and Section 5.3 of 113 [I-D.ietf-rtcweb-security-arch] further explains the value of 114 obtaining and maintaining consent. 116 Other Applications that have similar security requirements to verify 117 peer consent before sending non-ICE packets can use the consent 118 mechanism described in this document. The mechanism of how 119 applications are made aware of consent expiration is outside the 120 scope of the document. 122 3. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 Consent: The mechanism of obtaining permission from the remote 129 endpoint to send non-ICE traffic to a remote transport address. 130 Consent is obtained using ICE. Note that this is an application- 131 level consent; no human intervention is involved. 133 Consent Freshness: Maintaining and renewing consent over time. 135 Transport Address: The remote peer's IP address and UDP or TCP port 136 number. 138 4. Design Considerations 140 Although ICE requires periodic keepalive traffic to keep NAT bindings 141 alive (Section 10 of [RFC5245], [RFC6263]), those keepalives are sent 142 as STUN Indications which are send-and-forget, and do not evoke a 143 response. A response is necessary for consent to continue sending 144 traffic. Thus, we need a request/response mechanism for consent 145 freshness. ICE can be used for that mechanism because ICE 146 implementations are already required to continue listening for ICE 147 messages, as described in Section 10 of [RFC5245]. STUN binding 148 requests sent for consent freshness also serve the keepalive purpose 149 (i.e to keep NAT bindings alive). Because of that, dedicated 150 keepalives (e.g. STUN Binding Indications) are not sent on candidate 151 pairs where consent requests are sent, in accordance with 152 Section 20.2.3 of [RFC5245]. 154 When Secure Real-time Transport Protocol (SRTP) is used, the 155 following considerations are applicable. SRTP is encrypted and 156 authenticated with symmetric keys; that is, both sender and receiver 157 know the keys. With two party sessions, receipt of an authenticated 158 packet from the single remote party is a strong assurance the packet 159 came from that party. However, when a session involves more than two 160 parties, all of whom know each other's keys, any of those parties 161 could have sent (or spoofed) the packet. Such shared key 162 distributions are possible with some MIKEY [RFC3830] modes, Security 163 Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, 164 in such shared keying distributions, receipt of an authenticated SRTP 165 packet is not sufficient to verify consent. 167 The mechanism proposed in the document is an optional extension to 168 the ICE protocol, it can be deployed at one end of the two-party 169 communication session without impact on the other party. 171 5. Solution 173 Initial consent to send traffic is obtained using ICE [RFC5245]. An 174 endpoint gains consent to send on a candidate pair when the pair 175 enters the Succeeded ICE state. This document establishes a 30 176 second expiry time on consent. 30 seconds was chosen to balance the 177 need to minimize the time taken to respond to a loss of consent with 178 the desire to reduce the occurrence of spurious failures. 180 ICE does not identify when consent to send traffic ends. This 181 document describes two ways in which consent to send ends: expiration 182 of consent and immediate revocation of consent, which are discussed 183 in the following sections. 185 5.1. Expiration of Consent 187 A full ICE implementation obtains consent to send using ICE. After 188 ICE concludes on a particular candidate pair and whenever the 189 endpoint sends application data on that pair consent is maintained 190 following the procedure described in this document. 192 An endpoint MUST NOT send data other than the messages used to 193 establish consent unless the receiving endpoint has consented to 194 receive data. Connectivity checks that are paced as described in 195 Section 16 of [RFC5245] and responses to connectivity checks are 196 permitted. That is, no application data (e.g., RTP or Datagram 197 Transport Layer Security (DTLS)) can be sent until consent is 198 obtained. 200 Explicit consent to send is obtained and maintained by sending a STUN 201 binding request to the remote peer's transport address and receiving 202 a matching, authenticated, non-error STUN binding response from the 203 remote peer's transport address. These STUN binding requests and 204 responses are authenticated using the same short-term credentials as 205 the initial ICE exchange. 207 Note: Although TCP has its own consent mechanism (TCP 208 acknowledgements), consent is necessary over a TCP connection 209 because it could be translated to a UDP connection (e.g., 210 [RFC6062]). 212 Consent expires after 30 seconds. That is, if a valid STUN binding 213 response has not been received from the remote peer's transport 214 address in 30 seconds, the endpoint MUST cease transmission on that 215 5-tuple. STUN consent responses received after consent expiry do not 216 re-establish consent, and may be discarded or cause an ICMP error. 218 To prevent expiry of consent, a STUN binding request can be sent 219 periodically. To prevent synchronization of consent checks, each 220 interval MUST be randomized from between 0.8 and 1.2 times the basic 221 period. Implementations SHOULD set a default interval of 5 seconds, 222 resulting in a period between checks of 4 to 6 seconds. 223 Implementations MUST NOT set the period between checks to less than 4 224 seconds. This timer is independent of the consent expiry timeout. 226 Each STUN binding request for consent MUST use a new STUN transaction 227 identifier, as described in Section 6 of [RFC5389]. Each STUN 228 binding request for consent is transmitted once only. A sender 229 therefore cannot assume that it will receive a response for every 230 consent request, and a response might be for a previous request 231 (rather than for the most recently sent request). 233 An endpoint SHOULD await a binding response for each request it sends 234 for a time based on the estimated round-trip time (RTT) (see 235 Section 7.2.1 of [RFC5389]) with an allowance for variation in 236 network delay. The RTT value can be updated as described in 237 [RFC5389]. All outstanding STUN consent transactions for a candidate 238 pair MUST be discarded when consent expires. 240 To meet the security needs of consent, an untrusted application 241 (e.g., JavaScript or signaling servers) MUST NOT be able to obtain or 242 control the STUN transaction identifier, because that enables 243 spoofing of STUN responses, falsifying consent. 245 To prevent attacks on the peer during ICE restart, an endpoint that 246 continues to send traffic on the previously validated candidate pair 247 during ICE restart MUST continue to perform consent freshness on that 248 candidate pair as described earlier. 250 While TCP affords some protection from off-path attackers ([RFC5961], 251 [RFC4953]), there is still a risk an attacker could cause a TCP 252 sender to send forever by spoofing ACKs. To prevent such an attack, 253 consent checks MUST be performed over all transport connections, 254 including TCP. In this way, an off-path attacker spoofing TCP 255 segments cannot cause a TCP sender to send once the consent timer 256 expires (30 seconds). 258 An endpoint does not need to maintain consent if it does not send 259 application data. However, an endpoint MUST regain consent before it 260 resumes sending application data. In the absence of any packets, any 261 bindings in middleboxes for the flow might expire. Furthermore, 262 having one peer unable to send is detrimental to many protocols. 263 Absent better information about the network, if an endpoint needs to 264 ensure its NAT or firewall mappings do not expire, it can be done 265 using keepalive or other techniques (see Section 10 of [RFC5245] and 266 see [RFC6263]). 268 After consent is lost, the same ICE credentials MUST NOT be used on 269 the affected 5-tuple again. That means that a new session, or an ICE 270 restart, is needed to obtain consent to send on the affected 271 candidate pair. 273 5.2. Immediate Revocation of Consent 275 In some cases it is useful to signal that consent is terminated 276 rather than relying on a timeout. 278 Consent for sending application data is immediately revoked by 279 receipt of an authenticated message that closes the connection (e.g., 280 a TLS fatal alert) or receipt of a valid and authenticated STUN 281 response with error code Forbidden (403). Note however that consent 282 revocation messages can be lost on the network, so an endpoint could 283 resend these messages, or wait for consent to expire. 285 Receipt of an unauthenticated message that closes a connection (e.g., 286 TCP FIN) does not indicate revocation of consent. Thus, an endpoint 287 receiving an unauthenticated end-of-session message SHOULD continue 288 sending media (over connectionless transport) or attempt to re- 289 establish the connection (over connection-oriented transport) until 290 consent expires or it receives an authenticated message revoking 291 consent. 293 Note that an authenticated SRTCP BYE does not terminate consent; it 294 only indicates the associated SRTP source has quit. 296 6. DiffServ Treatment for Consent 298 It is RECOMMENDED that STUN consent checks use the same Diffserv 299 Codepoint markings as the ICE connectivity checks described in 300 Section 7.1.2.4 of [RFC5245] for a given 5-tuple. 302 Note: It is possible that different Diffserv Codepoints are used by 303 different media over the same transport address 304 [I-D.ietf-tsvwg-rtcweb-qos]. Such a case is outside the scope of 305 this document. 307 7. DTLS applicability 309 The DTLS applicability is identical to what is described in 310 Section 4.2 of [RFC7350]. 312 8. Security Considerations 314 This document describes a security mechanism, details of which are 315 mentioned in Section 4.1 and Section 4.2. Consent requires 96 bits 316 transaction ID defined in section 6 of [RFC5389] to be uniformly and 317 randomly chosen from the interval 0 .. 2**96-1, and be 318 cryptographically strong. This is good enough security against an 319 off-path attacker replaying old STUN consent responses. Consent 320 Verification to avoid attacks using a browser as an attack platform 321 against machines is discussed in Sections 3.3 and 4.2 of 322 [I-D.ietf-rtcweb-security]. 324 The security considerations discussed in [RFC5245] should also be 325 taken into account. 327 9. IANA Considerations 329 This document does not require any action from IANA. 331 10. Acknowledgement 333 Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus 334 Westerlund, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul 335 Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan 336 Banavi, Christian Groves, Meral Shirazipour, David Black, Barry 337 Leiba, Ben Campbell and Stephen Farrell for their valuable inputs and 338 comments. Thanks to Christer Holmberg for doing a thorough review. 340 11. References 342 11.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, 347 . 349 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 350 (ICE): A Protocol for Network Address Translator (NAT) 351 Traversal for Offer/Answer Protocols", RFC 5245, 352 DOI 10.17487/RFC5245, April 2010, 353 . 355 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 356 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 357 DOI 10.17487/RFC5389, October 2008, 358 . 360 11.2. Informative References 362 [I-D.ietf-avtcore-srtp-ekt] 363 Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key 364 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-03 365 (work in progress), October 2014. 367 [I-D.ietf-rtcweb-security] 368 Rescorla, E., "Security Considerations for WebRTC", draft- 369 ietf-rtcweb-security-08 (work in progress), February 2015. 371 [I-D.ietf-rtcweb-security-arch] 372 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 373 rtcweb-security-arch-11 (work in progress), March 2015. 375 [I-D.ietf-tsvwg-rtcweb-qos] 376 Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. 377 Polk, "DSCP and other packet markings for RTCWeb QoS", 378 draft-ietf-tsvwg-rtcweb-qos-04 (work in progress), July 379 2015. 381 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 382 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 383 DOI 10.17487/RFC3830, August 2004, 384 . 386 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 387 Description Protocol (SDP) Security Descriptions for Media 388 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 389 . 391 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 392 RFC 4953, DOI 10.17487/RFC4953, July 2007, 393 . 395 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 396 Robustness to Blind In-Window Attacks", RFC 5961, 397 DOI 10.17487/RFC5961, August 2010, 398 . 400 [RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using 401 Relays around NAT (TURN) Extensions for TCP Allocations", 402 RFC 6062, DOI 10.17487/RFC6062, November 2010, 403 . 405 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 406 Keeping Alive the NAT Mappings Associated with RTP / RTP 407 Control Protocol (RTCP) Flows", RFC 6263, 408 DOI 10.17487/RFC6263, June 2011, 409 . 411 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 412 Layer Security (DTLS) as Transport for Session Traversal 413 Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, 414 August 2014, . 416 Authors' Addresses 418 Muthu Arul Mozhi Perumal 419 Ericsson 420 Ferns Icon 421 Doddanekundi, Mahadevapura 422 Bangalore, Karnataka 560037 423 India 425 Email: muthu.arul@gmail.com 426 Dan Wing 427 Cisco Systems 428 821 Alder Drive 429 Milpitas, California 95035 430 USA 432 Email: dwing@cisco.com 434 Ram Mohan Ravindranath 435 Cisco Systems 436 Cessna Business Park 437 Sarjapur-Marathahalli Outer Ring Road 438 Bangalore, Karnataka 560103 439 India 441 Email: rmohanr@cisco.com 443 Tirumaleswar Reddy 444 Cisco Systems 445 Cessna Business Park, Varthur Hobli 446 Sarjapur Marathalli Outer Ring Road 447 Bangalore, Karnataka 560103 448 India 450 Email: tireddy@cisco.com 452 Martin Thomson 453 Mozilla 454 Suite 300 455 650 Castro Street 456 Mountain View, California 94041 457 US 459 Email: martin.thomson@gmail.com