idnits 2.17.1 draft-thomson-rtcweb-ice-dtls-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 28, 2012) is 4405 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: 'RFC5246' is defined on line 388, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAHashText' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtcweb M. Thomson 3 Internet-Draft Skype 4 Intended status: Standards Track March 28, 2012 5 Expires: September 29, 2012 7 Using Datagram Transport Layer Security (DTLS) For Interactivity 8 Connectivity Establishment (ICE) Connectivity Checking: ICE-DTLS 9 draft-thomson-rtcweb-ice-dtls-00 11 Abstract 13 Interactivity Connectivity Establishment (ICE) connectivity checking 14 using the Datagram Transport Layer Security (DTLS) handshake is 15 described. The DTLS handshake provides sufficient information to 16 identify valid candidates and establish consent. 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 29, 2012. 35 Copyright Notice 37 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. ICE using DTLS . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Without Optimization . . . . . . . . . . . . . . . . . . . 4 56 3.2. With Optimization . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Connectivity Check and Nomination . . . . . . . . . . . . 5 58 3.4. ICE Controller Selection . . . . . . . . . . . . . . . . . 5 59 3.5. DTLS Cookie Handling . . . . . . . . . . . . . . . . . . . 6 60 4. Indicating Continuing Consent to Receive . . . . . . . . . . . 7 61 5. Parallel STUN . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Signaling in SDP . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 User experience with real time applications depends greatly on low 74 latency. At session setup time, optimizing the total number of 75 network round trips between a user action and the receipt of media is 76 key to improving user experience. 78 Interactivity Connectivity Establishment (ICE) [RFC5245] performs a 79 crucial function in establishing a functional transport flow between 80 peers in the presence of network address translation (NAT) 81 middleboxes. Performing the complete ICE procedure can add 82 significant additional latency to session setup. 84 A complete ICE connectivity check and candidate nomination requires - 85 at best - one additional round trip. This assumes aggressive 86 nomination and all the associated drawbacks. Without aggressive 87 nomination, two round trips are added. 89 A transport session that is secured with Datagram Transport Layer 90 Security (DTLS) [RFC6347] requires at least two additional round 91 trips to establish once ICE negotiation completes. 93 A method is described that removes the need for blocking ICE 94 connectivity checks and nominations with only minimal additional 95 state overhead at each peer. This allows a secured session setup 96 without additional latency. In addition, the negative consequences 97 of aggressive nomination are avoided. 99 Peers identify candidates using information encoded in the DTLS 100 cookie. This avoids the need for a DTLS HelloVerifyRequest and 101 corresponding round trip. 103 Continuing consent to receive media in the session is verified using 104 the DTLS heartbeat extension [RFC6520]. 106 An extension to the Session Description Protocol (SDP) [RFC4566] 107 identifies candidates that support this method. 109 2. Terminology 111 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 112 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 113 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 114 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 115 levels for compliant implementations. 117 The term "server" and "client" are used in this document to refer to 118 the peers that act in the DTLS server and client roles. This is 119 distinct from the caller and callee who are participants in the media 120 session. 122 3. ICE using DTLS 124 The DTLS ClientHello and ServerHello messages can be used as a 125 replacement connectivity check request. 127 3.1. Without Optimization 129 A complete session setup using ICE and DTLS optimistically requires 130 between 5 and 7 round trips to complete. From the instant that the 131 caller initiates a call: 133 1. Caller gathers server reflexive and relay candidates. 135 2. Caller signals call creation. Callee signals response, callee 136 sends first connectivity check - a Session Traversal Utilities 137 for NAT (STUN) [RFC5389] Binding request. 139 3. Caller responds to connectivity check, creates own connectivity 140 check. Callee responds to connectivity check. 142 4. Caller creates an ICE nomination (a STUN Binding request with 143 USE-CANDIDATE set). Callee responds to nomination. Callee sends 144 DTLS ClientHello. 146 5. Caller sends a DTLS HelloVerifyRequest with a cookie. Callee re- 147 sends the ClientHello with the cookie. 149 6. Caller sends a DTLS ServerHello and associated messages. Callee 150 sends a DTLS Finished and ChangeCipherSpec. 152 7. Caller validates the Finished message. Caller can begin media 153 transmission. Caller sends a Finished message. Callee validates 154 the Finished message. Callee can begin media transmission. 156 This sequence assumes that no packets are lost or blocked during 157 setup. It also assumes that the callee creates the DTLS ClientHello 158 in order to save half a round trip, which probably doesn't correspond 159 with established practice. 161 The delay imposed by acquiring consent for the call from the callee 162 potentially dwarfs any delays from session setup. Low latency setup 163 is most applicable to pre-authorized sessions and situations where an 164 automated system is able to rapidly accept calls. 166 3.2. With Optimization 168 Using the DTLS handshake messages for connectivity checking takes far 169 fewer round trips in the best case: 171 1. Caller gathers server reflexive and relay candidates. 173 2. Caller signals call creation, indicating support for ICE-DTLS. 174 Callee signals response. Callee sends DTLS ClientHello including 175 a specially formatted cookie. 177 3. Caller sends a DTLS ServerHello and associated messages. Callee 178 sends a DTLS Finished and ChangeCipherSpec. 180 4. Caller validates the Finished message. Caller can begin media 181 transmission. Caller sends a Finished message. Callee validates 182 the Finished message. Callee can begin media transmission. 184 3.3. Connectivity Check and Nomination 186 Validating the DTLS handshake requires that peers retain copies of 187 the handshake messages. A (DTLS) client that sends multiple 188 ClientHello messages in place of connectivity checks MUST retain the 189 contents of each of those messages in order to later successfully 190 complete the DTLS handshake. 192 This requires additional state retention - especially at the (DTLS) 193 server - when multiple connectivity checks are sent and received. 194 This information does not add significantly to the state burden 195 imposed by ICE. Assuming that the client does not alter the 196 configuration for each session, the Random and Cookie fields will 197 vary in every ClientHello. 199 Continuing the handshake past the *Hello messages indicates that the 200 candidate pair in use has been nominated. Once a Finished message 201 has been received for any session, any state retained for other 202 candidates within the same ICE negotiation MAY be discarded and any 203 sessions abandoned. 205 3.4. ICE Controller Selection 207 This process implies that the peer in the DTLS client role is acting 208 as the ICE controller. Since both peers need to send packets in 209 order to create the session, a mechanism for determining which of the 210 two clients is the controller is necessary. 212 A DTLS peer that receives a ClientHello when it has one of its own 213 ClientHello messages outstanding continues to send. A peer that 214 receives a message is more likely to be able to respond to those 215 messages on the same transport flow than it is to successfully send 216 its own messages. Based on the receipt of a message alone, there is 217 no way to tell if the other peer has successfully received any other 218 packets. Therefore, the peer creates the ServerHello and associated 219 messages in response. 221 A peer that receives a ServerHello when its own ServerHello is 222 outstanding must choose whether to end the handshake, or whether it 223 is the controller. Only the ICE controller is able to continue the 224 handshake. 226 Unless the ICE controller is selected by other means, the ICE 227 controller is the peer that has the largest numeric public key value, 228 taken from the DTLS Certificate message. 230 3.5. DTLS Cookie Handling 232 The HelloVerifyRequest message in DTLS is used to determine that a 233 client is genuine and is able to receive packets. This allows a 234 server to avoid allocating state for a client based on the receipt of 235 an arbitrary packet. 237 Where a signaling relationship already exists between client and 238 server, the cookie exchange provides less utility. However, the 239 cookie still provides protection against receipt of spoofed 240 ClientHello packets. 242 Populating the DTLS cookie with information from the signaling allows 243 a server to determine that a packet is genuine without requiring a 244 round trip for confirmation. Using the ICE username fragment and 245 password ensures that no additional state is required to use this 246 method. 248 The DTLS cookie includes information from the signaling, chosen by 249 the DTLS server, plus a HMAC [RFC2104]. The HMAC that ensures that 250 access to packets does not enable the sending of spoofed ClientHello 251 messages. 253 The value of the Cookie is formed using a method similar to the ICE 254 short term credential mechanism. The ICE user is formed by 255 concatenating the username fragment from the peer, a colon (':') and 256 the local username fragment. The HMAC is calculated using the ICE 257 password as the key, with the text being a concatenation of the 258 Random value from the DTLS ClientHello and the ICE user. No other 259 information from the ClientHello is authenticated. 261 The Cookie is calculated as follows: 263 ice_user = ice_ufrag_peer | ':' | ice_ufrag_local 265 Cookie = HMAC[hash](ice_pwd_peer, Random | ice_user) | ice_user 267 ... where '|' implies concatenation. This method is roughly 268 equivalent to the one used by ICE when forming STUN packets. 270 Hash agility is achieved by signaling the hash to use. 271 Implementations MUST support SHA-1 [RFC3174]. See Section 6 for an 272 example. 274 Multiple hash algorithms MAY be signaled to indicate that multiple 275 different cookies are accepted. 277 In order to support ICE usernames longer than 12 octets or hash 278 algorithms other than SHA-1, DTLS 1.2 [RFC6347] MUST be supported. 279 DTLS 1.2 expands the size of the cookie field to 255 octets. 281 4. Indicating Continuing Consent to Receive 283 An important security concern for the web context is that a media 284 sender has a means of checking that a media receiver consents to 285 receive that media. Since consent can be revoked, a regular check is 286 necessary to ensure that media is not unwanted. 288 The DTLS heartbeat extension [RFC6520] provides a means of signaling 289 liveness of a DTLS session. A successful response also indicates 290 that the receiver consents to the continuing receipt of data. 292 In order to support this feature, peers MUST use the heartbeat 293 extension and MUST NOT send peer_not_allowed_to_send in the 294 handshake. 296 5. Parallel STUN 298 The main drawback of this optimization is that it is not possible to 299 gather peer reflexive addresses using the connectivity check. 300 Performing a STUN Binding request in parallel to the DTLS handshake 301 allows a client to gather a peer reflexive address without additional 302 latency. 304 6. Signaling in SDP 306 The Session Description Protocol (SDP) [RFC4566] can be used to 307 signal support for this feature. 309 The "ice-dtls" attribute is set to the textual name of the hash 310 function used in the HMAC. Valid values are taken from the IANA 311 registry of Hash Function Textual Names [IANAHashText], with multiple 312 values separated by spaces. 314 7. Security Considerations 316 The Random field in the DTLS handshake provides more entropy than the 317 corresponding field in STUN (224 bits vs. 96 bits). Both use an 318 equivalent HMAC method. This makes guessing the correct ClientHello 319 considerably harder than guessing the correct STUN Binding request. 321 The state maintained by peers using the DTLS handshake is increased 322 marginally over what is required to perform ICE. Each peer is 323 required to retain all the messages in the DTLS handshake in order to 324 correctly form the Finished message. Since each peer also 325 authenticates every ClientHello, only hosts with access to signaling 326 are able to create state in this fashion. 328 State accumulation can be limited using the same methods recommended 329 for the STUN Amplification Attack (Section 18.5.2 in [RFC5245]). 331 8. IANA Considerations 333 [[Note to IANA/RFC Editor: Please replace instance of RFCXXXX with 334 the number of the published RFC and remove this note.]] 336 This specification defines a new SDP 'ice-dtls' attribute following 337 the procedures of Section 8.2.4 of [RFC4566]. 339 Contact Name: Martin Thomson, martin.thomson@gmail.com 341 Attribute Name: ice-dtls 343 Long Form: ice-dtls 345 Type of Attribute: session- or media-level 347 Charset Considerations: The attribute is not subject to the charset 348 attribute. 350 Purpose: This attribute indicates that DTLS is supported as an 351 alternative mechanism for ICE connectivity checking and consent. 352 The values of the attribute indicate the hash functions that can 353 be used to calculate the value of the DTLS cookie. 355 Appropriate Values: A whitespace-separated list of values taken from 356 the IANA registry of Hash Function Textual Names [IANAHashText]. 358 9. Acknowledgments 360 Cullen Jennings provided the initial idea for this optimization. 362 10. References 364 10.1. Normative References 366 [IANAHashText] 367 Internet Asigned Numbers Authority, "IANA registry of Hash 368 Function Textual Names". 370 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 371 Hashing for Message Authentication", RFC 2104, 372 February 1997. 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, March 1997. 377 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 378 (SHA1)", RFC 3174, September 2001. 380 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 381 Description Protocol", RFC 4566, July 2006. 383 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 384 (ICE): A Protocol for Network Address Translator (NAT) 385 Traversal for Offer/Answer Protocols", RFC 5245, 386 April 2010. 388 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 389 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 391 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 392 Security Version 1.2", RFC 6347, January 2012. 394 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 395 Layer Security (TLS) and Datagram Transport Layer Security 396 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 398 10.2. Informative References 400 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 401 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 402 October 2008. 404 Author's Address 406 Martin Thomson 407 Skype 408 3210 Porter Drive 409 Palo Alto, CA 94304 410 US 412 Phone: +1 650-353-1925 413 Email: martin.thomson@gmail.com