idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-27.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5763, updated by this document, for RFC5378 checks: 2007-11-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 24, 2017) is 2465 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) == Missing Reference: 'RFCXXXX' is mentioned on line 747, but not defined == Unused Reference: 'RFC5245' is defined on line 1065, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-10 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 5763,7345 (if approved) R. Shpount 5 Intended status: Standards Track TurboBridge 6 Expires: January 25, 2018 July 24, 2017 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-27.txt 11 Abstract 13 This document defines the SDP offer/answer procedures for negotiating 14 and establishing a DTLS association. The document also defines the 15 criteria for when a new DTLS association must be established. The 16 document updates RFC 5763 and RFC 7345, by replacing common SDP 17 offer/answer procedures with a reference to this specification. 19 This document defines a new SDP media-level attribute, 'tls-id'. 21 This document also defines how the 'tls-id' attribute can be used for 22 negotiating and establishing a TLS connection, in conjunction with 23 the procedures in RFC 4145 and RFC 8122. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 25, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Establishing a new DTLS Association . . . . . . . . . . . . . 4 62 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Change of Local Transport Parameters . . . . . . . . . . 4 64 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 5 65 4. SDP tls-id Attribute . . . . . . . . . . . . . . . . . . . . 5 66 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 6 67 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 8 69 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 9 70 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 71 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 72 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 7. Transport Protocol Considerations . . . . . . . . . . . . . . 11 74 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 11 75 8. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14 80 10.2.1. Update to section 5 . . . . . . . . . . . . . . . . 14 81 10.2.2. Update to section 6.6 . . . . . . . . . . . . . . . 15 82 10.2.3. Update to section 6.7.1 . . . . . . . . . . . . . . 16 83 10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16 84 10.3.1. Update to section 4 . . . . . . . . . . . . . . . . 16 85 10.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . 16 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 15.2. Informative References . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 95 1. Introduction 97 [RFC5763] defines SDP offer/answer procedures for SRTP-DTLS. 98 [RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This 99 specification defines general offer/answer procedures for DTLS, based 100 on the procedures in [RFC5763]. Other specifications, defining 101 specific DTLS usages, can then reference this specification, in order 102 to ensure that the DTLS aspects are common among all usages. Having 103 common procedures is essential when multiple usages share the same 104 DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. The 105 document updates [RFC5763] and [RFC7345], by replacing common SDP 106 offer/answer procedures with a reference to this specification. 108 NOTE: Since the publication of [RFC5763], [RFC4474] has been 109 obsoleted by [I-D.ietf-stir-rfc4474bis]. The updating of the 110 references (and the associated procedures) within [RFC5763] is 111 outside the scope of this document. However, implementers of 112 [RFC5763] applications are encouraged to implement 113 [I-D.ietf-stir-rfc4474bis] instead of [RFC4474]. 115 As defined in [RFC5763], a new DTLS association MUST be established 116 when transport parameters are changed. Transport parameter change is 117 not well defined when Interactive Connectivity Establishment (ICE) 118 [I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a 119 transport change is based on ufrag [I-D.ietf-ice-rfc5245bis] change, 120 but the ufrag value is changed both when ICE is negotiated and when 121 ICE restart [I-D.ietf-ice-rfc5245bis] occurs. These events do not 122 always require a new DTLS association to be established, but 123 currently there is no way to explicitly indicate in an SDP offer or 124 answer whether a new DTLS association is required. To solve that 125 problem, this document defines a new SDP attribute, 'tls-id'. The 126 pair of SDP 'tls-id' attribute values (the attribute values of the 127 offerer and the answerer) uniquely identifies the DTLS association. 128 Providing a new value of the 'tls-id' attribute in an SDP offer or 129 answers can be used to indicate whether a new DTLS association is to 130 be established. 132 The SDP 'tls-id' attribute can be specified when negotiating a TLS 133 connection, using the procedures in this document in conjunction with 134 the procedures in [RFC5763] and [RFC8122]. The unique combination of 135 SDP 'tls-id' attribute values can be used to identity the negotiated 136 TLS connection. The unique value can be used, for example, within 137 TLS protocol extensions to differentiate between multiple TLS 138 connections and correlate those connections with specific offer/ 139 answer exchanges. The TLS specific considerations are described in 140 Section 8. 142 2. Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 3. Establishing a new DTLS Association 150 3.1. General 152 A new DTLS association must be established between two endpoints 153 after a successful SDP offer/answer exchange in the following cases: 155 o The negotiated DTLS setup roles change; or 157 o One or more fingerprint values are modified, added or removed in 158 either an SDP offer or answer; or 160 o The intent to establish a new DTLS association is explicitly 161 signaled using SDP, by changing the value of the SDP 'tls-id' 162 attribute defined in this document; 164 NOTE: The first two items above are based on the procedures in 165 [RFC5763]. This specification adds the support for explicit 166 signaling using the SDP 'tls-id' attribute. 168 A new DTLS association can only be established as a result of the 169 successful SDP offer/answer exchange. Whenever an entity determines 170 that a new DTLS association is required, the entity MUST initiate an 171 SDP offer/answer exchange, following the procedures in Section 5. 173 The sections below describe typical cases where a new DTLS 174 association needs to be established. 176 In this document, a "new DTLS association" between two endpoints 177 refers to either an initial DTLS association (when no DTLS 178 association is currently established between the endpoints) or an 179 DTLS association replacing a previously established DTLS association. 181 3.2. Change of Local Transport Parameters 183 If an endpoint modifies its local transport parameters (address and/ 184 or port), and if the modification requires a new DTLS association, 185 the endpoint must change its local SDP 'tls-id' attribute value (see 186 Section 4). 188 If the underlying transport prohibits a DTLS association from 189 spanning multiple transports, and if the transport is changed, the 190 endpoint must change its local SDP 'tls-id' attribute value (see 191 Section 4). An example of such a case is when DTLS is carried over 192 SCTP, as described in [RFC6083]. 194 3.3. Change of ICE ufrag value 196 If an endpoint uses ICE, and modifies a local ufrag value, and if the 197 modification requires a new DTLS association, the endpoint MUST 198 change its local SDP 'tls-id' attribute value (see Section 4). 200 4. SDP tls-id Attribute 202 The pair of SDP 'tls-id' attribute values (the attribute values of 203 the offerer and the answerer) uniquely identifies the DTLS 204 association or TLS connection. 206 Name: tls-id 208 Value: tls-id-value 210 Usage Level: media 212 Charset Dependent: no 214 Default Value: N/A 216 Syntax: 218 tls-id-value = 20*255(tls-id-char) 219 tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" 221 223 Example: 225 a=tls-id:abc3de65cddef001be82 227 Every time an endpoint requests to establish a new DTLS association, 228 the endpoint MUST generate a new local 'tls-id' attribute value. A 229 non-changed local 'tls-id' attribute value, in combination with non- 230 changed fingerprints, indicates that the endpoint intends to reuse 231 the existing DTLS association. 233 The 'tls-id' attribute value MUST be generated using a strong random 234 function and include at least 120 bits of randomness. 236 No default value is defined for the SDP 'tls-id' attribute. 237 Implementations that wish to use the attribute MUST explicitly 238 include it in SDP offers and answers. If an offer or answer does not 239 contain a 'tls-id' attribute (this could happen if the offerer or 240 answerer represents an existing implementation that has not been 241 updated to support the 'tls-id' attribute), unless there is another 242 mechanism to explicitly indicate that a new DTLS association is to be 243 established, a modification of one or more of the following 244 characteristics MUST be treated as an indication that an endpoint 245 wants to establish a new DTLS association: 247 o DTLS setup role; or 249 o fingerprint set; or 251 o local transport parameters; or 253 o ICE ufrag value 255 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- 256 id' attribute is 'IDENTICAL', which means that the attribute value 257 must be identical across all media descriptions being multiplexed 258 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 260 For RTP-based media, the 'tls-id' attribute applies to the whole 261 associated media description. The attribute MUST NOT be defined per 262 source (using the SDP 'ssrc' attribute [RFC5576]). 264 The SDP offer/answer [RFC3264] procedures associated with the 265 attribute are defined in Section 5. 267 5. SDP Offer/Answer Procedures 269 5.1. General 271 This section defines the generic SDP offer/answer procedures for 272 negotiating a DTLS association. Additional procedures (e.g., 273 regarding usage of specific SDP attributes etc.) for individual DTLS 274 usages (e.g., SRTP-DTLS) are outside the scope of this specification, 275 and need to be specified in a usage specific specification. 277 NOTE: The procedures in this section are generalizations of 278 procedures first specified in SRTP-DTLS [RFC5763], with the addition 279 of usage of the SDP 'tls-id' attribute. That document is herein 280 updated to make use of these new procedures. 282 The procedures in this section apply to an SDP media description 283 ("m=" line) associated with DTLS-protected media/data. 285 When an offerer or answerer indicates that it wants to establish a 286 new DTLS association, it needs to make sure that media packets 287 associated with any previously established DTLS association and the 288 new DTLS association can be de-multiplexed. In case of an ordered 289 transport (e.g., SCTP) this can be done simply by sending packets for 290 the new DTLS association after all packets associated with a 291 previously established DTLS association has been sent. In case of an 292 unordered transport, such as UDP, packets associated with a 293 previously established DTLS association can arrive after the answer 294 SDP was received and after the first packets associated with the new 295 DTLS association were received. The only way to de-multiplex packets 296 associated with with a previously established DTLS association and 297 the new DTLS association is on the basis of transport 5-tuple. 298 Because of this, if an unordered transport is used for the DTLS 299 association, a new transport (3-tuple) must be allocated by at least 300 one of the endpoints so that DTLS packets can be de-multiplexed. 302 When an offerer needs to establish a new DTLS association, and if an 303 unordered transport (e.g., UDP) is used, the offerer MUST allocate a 304 new transport (3-tuple) for the offer in such a way that the offerer 305 can disambiguate any packets associated with the new DTLS association 306 from any packets associated with any other DTLS association. This 307 typically means using a local address and/or port, or a set of ICE 308 candidates (see Section 6), which were not recently used for any 309 other DTLS association. 311 When an answerer needs to establish a new DTLS association, if an 312 unordered transport is used, and if the offerer did not allocate a 313 new transport, the answerer MUST allocate a new transport for the 314 answer in such a way that it can disambiguate any packets associated 315 with the new DTLS association from any packets associated with any 316 other DTLS association. This typically means using a local address 317 and/or port, or a set of ICE candidates (see Section 6), which were 318 not recently used for any other DTLS association. 320 In order to negotiate a DTLS association, the following SDP 321 attributes are used: 323 o The SDP 'setup' attribute, defined in [RFC4145], is used to 324 negotiate the DTLS roles; 326 o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to 327 provide one or more fingerprint values; and 329 o The SDP 'tls-id' attribute, defined in this specification, is used 330 to identity the DTLS association. 332 This specification does not define the usage of the SDP 'connection' 333 attribute [RFC4145] for negotiating a DTLS association. However, the 334 attribute MAY be used if the DTLS association is used together with 335 another protocol (e.g., SCTP or TCP) for which the usage of the 336 attribute has been defined. 338 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 339 'setup' attribute 'holdconn' value when negotiating a DTLS 340 association. 342 Endpoints MUST support the cipher suites as defined in [RFC8122]. 344 The certificate received during the DTLS handshake MUST match a 345 certificate fingerprint received in SDP 'fingerprint' attributes 346 according to the procedures defined in [RFC8122]. If fingerprints do 347 not match the hashed certificate, then an endpoint MUST tear down the 348 media session immediately (see [RFC8122]). Note that it is 349 permissible to wait until the other side's fingerprint(s) has been 350 received before establishing the connection; however, this may have 351 undesirable latency effects. 353 SDP offerers and answerers might reuse certificates across multiple 354 DTLS associations, and provide identical fingerprint values for each 355 DTLS association. The combination of the SDP 'tls-id' attribute 356 values of the SDP offerer and answerer identifies each individual 357 DTLS association. 359 NOTE: There are cases where the SDP 'tls-id' attribute value 360 generated by the offerer will end up being used for multiple DTLS 361 associations. For that reason the combination of the attribute 362 values of the offerer and answerer is needed in order to identity a 363 DTLS association. An example of such case is where the offerer sends 364 an updated offer (Section 5.5), without modifying its attribute 365 value, but the answerer determines that a new DTLS association is to 366 be created. The answerer will generate a new local attribute value 367 for the new DTLS association (Section 5.3), while the offerer will 368 use the same attribute value that it used for the current 369 association. Another example is when the Session Initiation Protocol 370 (SIP) [RFC3261] is used for signalling, and an offer is forked to 371 multiple answerers. The attribute value generated by the offerer 372 will be used for DTLS associations established by each answerer. 374 5.2. Generating the Initial SDP Offer 376 When an offerer sends the initial offer, the offerer MUST insert an 377 SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, 378 and one or more SDP 'fingerprint' attributes according to the 379 procedures in [RFC8122]. In addition, the offerer MUST insert in the 380 offer an SDP 'tls-id' attribute with a unique attribute value. 382 As the offerer inserts the SDP 'setup' attribute with an 'actpass' 383 attribute value, the offerer MUST be prepared to receive a DTLS 384 ClientHello message (if a new DTLS association is established by the 385 answerer) from the answerer before the offerer receives the SDP 386 answer. 388 If the offerer receives a DTLS ClientHello message, and a DTLS 389 association is established, before the offerer receives the SDP 390 Answer carrying the fingerprint associated with the DTLS association, 391 any data received on the DTLS association before the fingerprint MUST 392 be considered coming from an unverified source. The processing of 393 such data, and sending of data by the offerer to the unverified 394 source, is outside the scope of this document. 396 5.3. Generating the Answer 398 When an answerer sends an answer, the answerer MUST insert in the 399 answer an SDP 'setup' attribute according to the procedures in 400 [RFC4145], and one or more SDP 'fingerprint' attributes according to 401 the procedures in [RFC8122]. If the answerer determines, based on 402 the criteria specified in Section 3.1, that a new DTLS association is 403 to be established, the answerer MUST insert in the associated answer 404 an SDP 'tls-id' attribute with a new unique attribute value. Note 405 that the offerer and answerer generate their own local 'tls-id' 406 attribute values, and the combination of both values identify the 407 DTLS association. 409 If the answerer receives an offer that requires establishment of a 410 new DTLS association, and if the answerer does not accept the 411 establishment of a new DTLS association, the answerer MUST reject the 412 "m=" lines associated with the suggested DTLS association [RFC3264]. 414 If an answerer receives an offer that does not require the 415 establishment of a new DTLS association, and if the answerer 416 determines that a new DTLS association is not to be established, the 417 answerer MUST insert an SDP 'tls-id' attribute with the previously 418 assigned attribute value in the associated answer. In addition, the 419 answerer MUST insert an SDP 'setup' attribute with an attribute value 420 that does not change the previously negotiated DTLS roles, and one or 421 more SDP 'fingerprint' attributes values that do not change the 422 previously sent fingerprint set, in the associated answer. 424 If the answerer receives an offer that does not contain an SDP 'tls- 425 id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in 426 the answer. 428 If a new DTLS association is to be established, and if the answerer 429 inserts an SDP 'setup' attribute with an 'active' attribute value in 430 the answer, the answerer MUST initiate a DTLS handshake by sending a 431 DTLS ClientHello message towards the offerer. 433 Even though an offerer is required to insert an 'SDP' setup attribute 434 with an 'actpass' attribute value in initial offers (Section 5.2) and 435 subsequent offers (Section 5.5), the answerer MUST be able to receive 436 initial and subsequent offers with other attribute values, in order 437 to be backward compatible with older implementations that might 438 insert other attribute values in initial and subsequent offers. 440 5.4. Offerer Processing of the SDP Answer 442 When an offerer receives an answer that establishes a new DTLS 443 association based on criteria defined in Section 3.1, and if the 444 offerer becomes DTLS client (based on the value of the SDP 'setup' 445 attribute value [RFC4145]), the offerer MUST establish a DTLS 446 association. If the offerer becomes DTLS server, it MUST wait for 447 the answerer to establish the DTLS association. 449 If the offerer indicated a desire to reuse an existing DTLS 450 association and the answerer does not request the establishment of a 451 new DTLS association, the offerer will continue to use the previously 452 established DTLS association. 454 NOTE: A new DTLS association can be established based on changes in 455 either an SDP offer or answer. When communicating with legacy 456 endpoints, an offerer can receive an answer that includes the same 457 fingerprint set and setup role. A new DTLS association MUST still be 458 established if such an answer was received as a response to an offer 459 which requested the establishment of a new DTLS association. 461 5.5. Modifying the Session 463 When an offerer sends a subsequent offer, and if the offerer wants to 464 establish a new DTLS association, the offerer MUST insert an SDP 465 'setup' attribute [RFC4145] with an 'actpass' attribute value, and 466 one or more SDP 'fingerprint' attributes according to the procedures 467 in [RFC8122]. In addition, the offerer MUST insert in the offer an 468 SDP 'tls-id' attribute with a new unique attribute value. 470 When an offerer sends a subsequent offer, and the offerer does not 471 want to establish a new DTLS association, and if a previously 472 established DTLS association exists, the offerer MUST insert an SDP 473 'setup' attribute with an 'actpass' attribute value, and one or more 474 SDP 'fingerprint' attributes with attribute values that do not change 475 the previously sent fingerprint set, in the offer. In addition, the 476 offerer MUST insert an SDP 'tls-id' attribute with the previously 477 assigned attribute value in the offer. 479 NOTE: When a new DTLS association is being established, each endpoint 480 needs to be prepared to receive data on both the new and old DTLS 481 associations as long as both are alive. 483 6. ICE Considerations 485 When the Interactive Connectivity Establishment (ICE) mechanism 486 [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are 487 performed before the DTLS handshake begins. Note that if aggressive 488 nomination mode is used, multiple candidate pairs may be marked valid 489 before ICE finally converges on a single candidate pair. 491 NOTE: Aggressive nomination has been deprecated from ICE, but must 492 still be supported for backwards compatibility reasons 493 [I-D.ietf-ice-rfc5245bis]. 495 When a new DTLS association is established over an unordered 496 transport, in order to disambiguate any packets associated with the 497 newly established DTLS association, at least one of the endpoints 498 MUST allocate a completely new set of ICE candidates which were not 499 recently used for any other DTLS association. This means the 500 answerer cannot initiate a new DTLS association unless the offerer 501 initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer 502 wants to initiate a new DTLS association, it needs to initiate an ICE 503 restart and a new offer/answer exchange on its own. However, an ICE 504 restart does not by default require a new DTLS association to be 505 established. 507 NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets 508 are sent directly over UDP, not over DTLS. [RFC5764] describes how 509 to demultiplex STUN packets from DTLS packets and SRTP packets. 511 Each ICE candidate associated with a component is treated as being 512 part of the same DTLS association. Therefore, from a DTLS 513 perspective it is not considered a change of local transport 514 parameters when an endpoint switches between those ICE candidates. 516 7. Transport Protocol Considerations 518 7.1. Transport Re-Usage 520 If DTLS is transported on top of a connection-oriented transport 521 protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, 522 all DTLS packets associated with a previous DTLS association MUST be 523 acknowledged (or timed out) before a new DTLS association can be 524 established on the same instance of that transport (5-tuple). 526 8. TLS Considerations 528 The procedures in this document can also be used for negotiating and 529 establishing a TLS connection, with the restriction described below. 531 As specified in [RFC4145], the SDP 'connection' attribute is used to 532 indicate whether to establish a new TLS connection. An offerer and 533 answerer MUST ensure that the 'connection' attribute value and the 534 'tls-id' attribute value does not cause a conflict regarding whether 535 a new TLS connection is to be established or not. 537 NOTE: Even though the SDP 'connection' attribute can be used to 538 indicate whether a new TLS connection is to be established, the 539 unique combination of SDP 'tls-id' attribute values can be used to 540 identity a TLS connection. The unique value can be used e.g., within 541 TLS protocol extensions to differentiate between multiple TLS 542 connections and correlate those connections with specific offer/ 543 answer exchanges. 545 If an offerer or answerer inserts an SDP 'connection' attribute with 546 a 'new' value in the offer/answer and also inserts an SDP 'tls-id' 547 attribute, the value of tls-id' attribute MUST be new and unique. 549 If an offerer or answerer inserts an SDP 'connection' attribute with 550 a 'existing' value in the offer/answer, if a previously established 551 TLS connection exists, and if the offerer/answerer previously 552 inserted an SDP 'tls-id' attribute associated with the same TLS 553 connection in an offer/answer, the offerer/answerer MUST also insert 554 an SDP 'tls-id' attribute with the previously assigned value in the 555 offer/answer. 557 If an offerer or answerer receives an offer/answer with conflicting 558 attribute values, the offerer/answerer MUST process the offer/answer 559 as misformed. 561 An endpoint must not make assumptions regarding the support of the 562 SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, 563 both offerers and answerers MUST always use the 'connection' 564 attribute in conjunction with the 'tls-id' attribute. 566 NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is 567 not explicitly present, the implicit default value is 'new'. 569 The SDP example below is based on the example in section 3.4 of 570 [RFC4572], with the addition of the SDP 'tls-id' attribute. 572 m=image 54111 TCP/TLS t38 573 c=IN IP4 192.0.2.2 574 a=tls-id:abc3de65cddef001be82 575 a=setup:passive 576 a=connection:new 577 a=fingerprint:SHA-256 \ 578 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 579 3E:5D:49:6B:19:E5:7C:AB:4A:AD 580 a=fingerprint:SHA-1 \ 581 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 583 9. SIP Considerations 585 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 586 signal protocol for establishing a multimedia session, dialogs 587 [RFC3261] might be established between the caller and multiple 588 callees. This is referred to as forking. If forking occurs, 589 separate DTLS associations will be established between the caller and 590 each callee. 592 When forking occurs, an SDP offerer can receive DTLS ClientHello 593 messages and SDP answerers from multiple remote locations. Because 594 of this, the offerer might have to wait for multiple SDP answers 595 (from different remote locations) until it receives a certificate 596 fingerprint that matches the certificate associated with a specific 597 DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch 598 until it determines that it will not receive SDP answers from any 599 additional remote locations. 601 It is possible to send an INVITE request which does not contain an 602 SDP offer. Such an INVITE request is often referred to as an 'empty 603 INVITE', or an 'offer-less INVITE'. The receiving endpoint will 604 include the SDP offer in a response to the request. When the 605 endpoint generates such SDP offer, if a previously established DTLS 606 association exists, the offerer MUST insert an SDP 'tls-id' 607 attribute, and one or more SDP 'fingerprint' attributes, with 608 previously assigned attribute values. If a previously established 609 DTLS association did not exist, the offer MUST be generated based on 610 the same rules as a new offer (see Section 5.2). Regardless of the 611 previous existence of a DTLS association, the SDP 'setup' attribute 612 MUST be included according to the rules defined in [RFC4145] and if 613 ICE is used, ICE restart MUST be initiated. 615 10. RFC Updates 617 10.1. General 619 This section updates specifications that use DTLS-protected media, in 620 order to reflect the procedures defined in this specification. 622 10.2. Update to RFC 5763 624 10.2.1. Update to section 5 626 The text in section 5 (Establishing a Secure Channel) is replaced 627 with the new text below: 629 NEW TEXT: 631 The two endpoints in the exchange present their identities as part of 632 the DTLS handshake procedure using certificates. This document uses 633 certificates in the same style as described in "Connection-Oriented 634 Media Transport over the Transport Layer Security (TLS) Protocol in 635 the Session Description Protocol (SDP)" [RFC4572]. 637 If self-signed certificates are used, the content of the 638 subjectAltName attribute inside the certificate MAY use the uniform 639 resource identifier (URI) of the user. This is useful for debugging 640 purposes only and is not required to bind the certificate to one of 641 the communication endpoints. The integrity of the certificate is 642 ensured through the fingerprint attribute in the SDP. 644 The generation of public/private key pairs is relatively expensive. 645 Endpoints are not required to generate certificates for each session. 647 The offer/answer model, defined in [RFC3264], is used by protocols 648 like the Session Initiation Protocol (SIP) [RFC3261] to set up 649 multimedia sessions. 651 When an endpoint wishes to set up a secure media session with another 652 endpoint, it sends an offer in a SIP message to the other endpoint. 653 This offer includes, as part of the SDP payload, a fingerprint of 654 a certificate that the endpoint wants to use. The endpoint SHOULD 655 send the SIP message containing the offer to the offerer's SIP proxy 656 over an integrity protected channel. The proxy SHOULD add an 657 Identity header field according to the procedures outlined in 658 [RFC4474]. When the far endpoint receives the SIP message, it can 659 verify the identity of the sender using the Identity header field. 660 Since the Identity header field is a digital signature across several 661 SIP header fields, in addition to the body of the SIP message, the 662 receiver can also be certain that the message has not been tampered 663 with after the digital signature was applied and added to the SIP 664 message. 666 The far endpoint (answerer) may now establish a DTLS association with 667 the offerer. Alternately, it can indicate in its answer that the 668 offerer is to initiate the DTLS association. In either case, mutual 669 DTLS certificate-based authentication will be used. After completing 670 the DTLS handshake, information about the authenticated identities, 671 including the certificates, are made available to the endpoint 672 application. The answerer is then able to verify that the offerer's 673 certificate used for authentication in the DTLS handshake can be 674 associated to a certificate fingerprint contained in the offer in 675 the SDP. At this point, the answerer may indicate to the end user 676 that the media is secured. The offerer may only tentatively accept 677 the answerer's certificate since it may not yet have the answerer's 678 certificate fingerprint. 680 When the answerer accepts the offer, it provides an answer back to 681 the offerer containing the answerer's certificate fingerprint. At 682 this point, the offerer can accept or reject the peer's certificate 683 and the offerer can indicate to the end user that the media is 684 secured. 686 Note that the entire authentication and key exchange for securing 687 the media traffic is handled in the media path through DTLS. The 688 signaling path is only used to verify the peers' certificate 689 fingerprints. 691 The offerer and answerer MUST follow the SDP offer/answer procedures 692 defined in [RFCXXXX]. 694 10.2.2. Update to section 6.6 696 The text in section 6.6 (Session Modification) is replaced with the 697 new text below: 699 NEW TEXT: 701 Once an answer is provided to the offerer, either endpoint MAY 702 request a session modification that MAY include an updated offer. 703 This session modification can be carried in either an INVITE or 704 UPDATE request. The peers can reuse an existing DTLS association, 705 or establish a new one, following the procedures in [RFCXXXX]. 707 10.2.3. Update to section 6.7.1 709 The text in section 6.7.1 (ICE Interaction) is replaced with the new 710 text below: 712 NEW TEXT: 714 The Interactive Connectivity Establishment (ICE) 715 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 716 are described in [RFCXXXX]. 718 10.3. Update to RFC 7345 720 10.3.1. Update to section 4 722 The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer 723 Procedures) are removed, and replaced with the new text below: 725 NEW TEXT: 727 An endpoint (i.e., both the offerer and the answerer) MUST create an 728 SDP media description ("m=" line) for each UDPTL-over-DTLS media 729 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 730 "proto" field of the "m=" line. 732 The offerer and answerer MUST follow the SDP offer/answer procedures 733 defined in [RFCXXXX] in order to negotiate the DTLS association 734 associated with the UDPTL-over-DTLS media stream. In addition, 735 the offerer and answerer MUST use the SDP attributes defined for 736 UDPTL over UDP, as defined in [ITU.T38.2010]. 738 10.3.2. Update to section 5.2.1 740 The text in section 5.2.1 (ICE Usage) is replaced with the new text 741 below: 743 NEW TEXT: 745 The Interactive Connectivity Establishment (ICE) 746 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 747 are described in [RFCXXXX]. 749 [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX 750 with the RFC number of this document.] 752 11. Security Considerations 754 This specification does not modify the security considerations 755 associated with DTLS, or the SDP offer/answer mechanism. In addition 756 to the introduction of the SDP 'tls-id' attribute, the specification 757 simply clarifies the procedures for negotiating and establishing a 758 DTLS association. 760 12. IANA Considerations 762 This document updates the "Session Description Protocol Parameters" 763 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 764 it adds the SDP 'tls-id' attribute to the table for SDP media level 765 attributes. 767 Attribute name: tls-id 768 Type of attribute: media-level 769 Subject to charset: no 770 Purpose: Indicates whether a new DTLS association or TLS connection 771 is to be established/re-established. 772 Appropriate Values: see Section 4 773 Contact name: Christer Holmberg 774 Mux Category: IDENTICAL 776 13. Acknowledgements 778 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, 779 Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing 780 comments and suggestions on the document. Ben Campbell performed an 781 AD review. Paul Kyzivat performed a gen-art review. 783 14. Change Log 785 [RFC EDITOR NOTE: Please remove this section when publishing] 787 Changes from draft-ietf-mmusic-sdp-dtls-26 788 o Editorial fixes based on Gen-ART review by Paul Kyzivat. 790 Changes from draft-ietf-mmusic-sdp-dtls-25 792 o Minor editorial nits. 794 Changes from draft-ietf-mmusic-sdp-dtls-24 796 o Changes based on 2nd WGLC comments from Roman S and Martin T: 798 o - RFC update structure shortened (old text removed). 800 o - Guidance regarding receiving ClientHello before SDP answer 801 added. 803 o - Additional SIP condierations regarding forking. 805 o - SDP setup attribute value restriction in initial and subsequent 806 offers based on comment from Ekr. 808 Changes from draft-ietf-mmusic-sdp-dtls-23 810 o Editrial change to make it clear that the document does not modify 811 the procedures in RFC 8122. 813 Changes from draft-ietf-mmusic-sdp-dtls-22 815 o Support for TLS added. 817 o Editorial changes based on sec-dir review by Rich Salz. 819 o Editorial changes based on gen-art review by Paul Kyzivat. 821 o Editorial changes based on ops-dir review by Carlos Pignataro. 823 Changes from draft-ietf-mmusic-sdp-dtls-21 825 o Changes based on AD review by Ben Campbell. 827 o (https://www.ietf.org/mail-archive/web/mmusic/current/ 828 msg17707.html) 830 Changes from draft-ietf-mmusic-sdp-dtls-20 832 o Change to length and randomness of tls-id attribute value. 834 Changes from draft-ietf-mmusic-sdp-dtls-19 835 o Change based on comment from Roman. 837 Changes from draft-ietf-mmusic-sdp-dtls-18 839 o Changes based on comments from Flemming. 841 o - Change in tls-id value definition. 843 o - Editorial fixes. 845 Changes from draft-ietf-mmusic-sdp-dtls-17 847 o Reference fix. 849 Changes from draft-ietf-mmusic-sdp-dtls-16 851 o Editorial changes based on 2nd WGLC comments from Christian Groves 852 and Nevenka Biondic. 854 Changes from draft-ietf-mmusic-sdp-dtls-15 856 o tls-id attribute value made globally unique 858 Changes from draft-ietf-mmusic-sdp-dtls-14 860 o Changes based on comments from Flemming: 862 o - Additional dtls-is clarifiations 864 o - Editorial fixes 866 Changes from draft-ietf-mmusic-sdp-dtls-13 868 o Text about the updated RFCs added to Abstract and Introduction 870 o Reference to RFC 5763 removed from section 6 (ICE Considerations) 872 o Reference to RFC 5763 removed from section 8 (SIP Considerations) 874 Changes from draft-ietf-mmusic-sdp-dtls-12 876 o "unreliable" changed to "unordered" 878 Changes from draft-ietf-mmusic-sdp-dtls-11 880 o Attribute name changed to tls-id 882 o Additional text based on comments from Roman Shpount. 884 Changes from draft-ietf-mmusic-sdp-dtls-10 886 o Modified document to use tls-id instead of dtls-connection 888 o Changes are based on comments from Eric Rescorla, Justin Uberti, 889 and Paul Kyzivat. 891 Changes from draft-ietf-mmusic-sdp-dtls-08 893 o Offer/Answer section modified in order to allow sending of 894 multiple SDP 'fingerprint' attributes. 896 o Terminology made consistent: 'DTLS connection' replaced with 'DTLS 897 association'. 899 o Editorial changes based on comments from Paul Kyzivat. 901 Changes from draft-ietf-mmusic-sdp-dtls-07 903 o Reference to RFC 7315 replaced with reference to RFC 7345. 905 Changes from draft-ietf-mmusic-sdp-dtls-06 907 o Text on restrictions regarding spanning a DTLS association over 908 multiple transports added. 910 o Mux category added to IANA Considerations. 912 o Normative text regarding mux category and source-specific 913 applicability added. 915 o Reference to RFC 7315 added. 917 o Clarified that offerer/answerer that has not been updated to 918 support this specification will not include the tls-id attribute 919 in offers and answers. 921 o Editorial corrections based on WGLC comments from Charles Eckel. 923 Changes from draft-ietf-mmusic-sdp-dtls-05 925 o Text on handling offer/answer error conditions added. 927 Changes from draft-ietf-mmusic-sdp-dtls-04 929 o Editorial nits fixed based on comments from Paul Kyzivat: 931 Changes from draft-ietf-mmusic-sdp-dtls-03 932 o Changes based on comments from Paul Kyzivat: 934 o - Modification of tls-id attribute section. 936 o - Removal of IANA considerations subsection. 938 o - Making note into normative text in o/a section. 940 o Changes based on comments from Martin Thompson: 942 o - Abbreviations section removed. 944 o - Clarify that a new DTLS association requires a new o/a 945 transaction. 947 Changes from draft-ietf-mmusic-sdp-dtls-02 949 o - Updated RFCs added to boilerplate. 951 Changes from draft-ietf-mmusic-sdp-dtls-01 953 o - Annex regarding 'tls-id-id' attribute removed. 955 o - Additional SDP offer/answer procedures, related to certificates, 956 added. 958 o - Updates to RFC 5763 and RFC 7345 added. 960 o - Transport protocol considerations added. 962 Changes from draft-ietf-mmusic-sdp-dtls-00 964 o - SDP 'connection' attribute replaced with new 'tls-id' attribute. 966 o - IANA Considerations added. 968 o - E-mail regarding 'tls-id-id' attribute added as Annex. 970 Changes from draft-holmberg-mmusic-sdp-dtls-01 972 o - draft-ietf-mmusic version of draft submitted. 974 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 975 with another expired draft. 977 o - Clarify that if ufrag in offer is unchanged, it must be 978 unchanged in associated answer. 980 o - SIP Considerations section added. 982 o - Section about multiple SDP fingerprint attributes added. 984 Changes from draft-holmberg-mmusic-sdp-dtls-00 986 o - Editorial changes and clarifications. 988 15. References 990 15.1. Normative References 992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", BCP 14, RFC 2119, 994 DOI 10.17487/RFC2119, March 1997, 995 . 997 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 998 A., Peterson, J., Sparks, R., Handley, M., and E. 999 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1000 DOI 10.17487/RFC3261, June 2002, 1001 . 1003 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1004 with Session Description Protocol (SDP)", RFC 3264, 1005 DOI 10.17487/RFC3264, June 2002, 1006 . 1008 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1009 the Session Description Protocol (SDP)", RFC 4145, 1010 DOI 10.17487/RFC4145, September 2005, 1011 . 1013 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1014 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1015 July 2006, . 1017 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1018 for Establishing a Secure Real-time Transport Protocol 1019 (SRTP) Security Context Using Datagram Transport Layer 1020 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1021 2010, . 1023 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 1024 Transport Layer (UDPTL) over Datagram Transport Layer 1025 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 1026 2014, . 1028 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 1029 Transport over the Transport Layer Security (TLS) Protocol 1030 in the Session Description Protocol (SDP)", RFC 8122, 1031 DOI 10.17487/RFC8122, March 2017, 1032 . 1034 [I-D.ietf-ice-rfc5245bis] 1035 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1036 Connectivity Establishment (ICE): A Protocol for Network 1037 Address Translator (NAT) Traversal", draft-ietf-ice- 1038 rfc5245bis-10 (work in progress), May 2017. 1040 [I-D.ietf-mmusic-sdp-mux-attributes] 1041 Nandakumar, S., "A Framework for SDP Attributes when 1042 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1043 (work in progress), December 2016. 1045 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1046 Holmberg, C., Alvestrand, H., and C. Jennings, 1047 "Negotiating Media Multiplexing Using the Session 1048 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1049 negotiation-38 (work in progress), April 2017. 1051 15.2. Informative References 1053 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1054 Authenticated Identity Management in the Session 1055 Initiation Protocol (SIP)", RFC 4474, 1056 DOI 10.17487/RFC4474, August 2006, 1057 . 1059 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1060 Transport Layer Security (TLS) Protocol in the Session 1061 Description Protocol (SDP)", RFC 4572, 1062 DOI 10.17487/RFC4572, July 2006, 1063 . 1065 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1066 (ICE): A Protocol for Network Address Translator (NAT) 1067 Traversal for Offer/Answer Protocols", RFC 5245, 1068 DOI 10.17487/RFC5245, April 2010, 1069 . 1071 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1072 Media Attributes in the Session Description Protocol 1073 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1074 . 1076 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1077 Security (DTLS) Extension to Establish Keys for the Secure 1078 Real-time Transport Protocol (SRTP)", RFC 5764, 1079 DOI 10.17487/RFC5764, May 2010, 1080 . 1082 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1083 Transport Layer Security (DTLS) for Stream Control 1084 Transmission Protocol (SCTP)", RFC 6083, 1085 DOI 10.17487/RFC6083, January 2011, 1086 . 1088 [I-D.ietf-stir-rfc4474bis] 1089 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1090 "Authenticated Identity Management in the Session 1091 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 1092 (work in progress), February 2017. 1094 [ITU.T38.2010] 1095 International Telecommunications Union, "Procedures for 1096 real-time Group 3 facsimile communication over IP 1097 networks", ITU-T Recommendation T.38, September 2010. 1099 Authors' Addresses 1101 Christer Holmberg 1102 Ericsson 1103 Hirsalantie 11 1104 Jorvas 02420 1105 Finland 1107 Email: christer.holmberg@ericsson.com 1109 Roman Shpount 1110 TurboBridge 1111 4905 Del Ray Avenue, Suite 300 1112 Bethesda, MD 20814 1113 USA 1115 Phone: +1 (240) 292-6632 1116 Email: rshpount@turbobridge.com