idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-24.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 (April 20, 2017) is 2560 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 955, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-08 == 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 (~~), 5 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: October 22, 2017 April 20, 2017 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-24.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 October 22, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 8 70 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 9 71 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 72 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. Transport Protocol Considerations . . . . . . . . . . . . . . 11 74 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 11 75 8. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 13 80 10.2.1. Update to section 5 . . . . . . . . . . . . . . . . 13 81 10.2.2. Update to section 6.6 . . . . . . . . . . . . . . . 17 82 10.2.3. Update to section 6.7.1 . . . . . . . . . . . . . . 17 83 10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 18 84 10.3.1. Update to section 4 . . . . . . . . . . . . . . . . 18 85 10.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . 21 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 15.1. Normative References . . . . . . . . . . . . . . . . . . 26 92 15.2. Informative References . . . . . . . . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 also be used for negotiating a TLS 133 connection, using the procedures in this document in conjunction with 134 the procedures in [RFC5763] and [RFC8122]. The TLS specific 135 considerations are described in Section 8. 137 2. Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Establishing a new DTLS Association 145 3.1. General 147 A new DTLS association must be established between two endpoints 148 after a successful SDP offer/answer exchange in the following cases: 150 o The negotiated DTLS setup roles change; or 152 o One or more fingerprint values are modified, added or removed in 153 either an SDP offer or answer; or 155 o The intent to establish a new DTLS association is explicitly 156 signaled using SDP, by changing the value of the SDP 'tls-id' 157 attribute defined in this document; 159 NOTE: The first two items above are based on the procedures in 160 [RFC5763]. This specification adds the support for explicit 161 signaling using the SDP 'tls-id' attribute. 163 A new DTLS association can only be established as a result of the 164 successful SDP offer/answer exchange. Whenever an entity determines 165 that a new DTLS association is required, the entity MUST initiate an 166 SDP offer/answer exchange, following the procedures in Section 5. 168 The sections below describe typical cases where a new DTLS 169 association needs to be established. 171 In this document, a "new DTLS association" between two endpoints 172 refers to either an initial DTLS association (when no DTLS 173 association is currently established between the endpoints) or an 174 DTLS association replacing a previously established DTLS association. 176 3.2. Change of Local Transport Parameters 178 If an endpoint modifies its local transport parameters (address and/ 179 or port), and if the modification requires a new DTLS association, 180 the endpoint must change its local SDP 'tls-id' attribute value (see 181 Section 4). 183 If the underlying transport prohibits a DTLS association from 184 spanning multiple transports, and if the transport is changed, the 185 endpoint must change its local SDP 'tls-id' attribute value (see 186 Section 4). An example of such a case is when DTLS is carried over 187 SCTP, as described in [RFC6083]. 189 3.3. Change of ICE ufrag value 191 If an endpoint uses ICE, and modifies a local ufrag value, and if the 192 modification requires a new DTLS association, the endpoint MUST 193 change its local SDP 'tls-id' attribute value (see Section 4). 195 4. SDP tls-id Attribute 197 The pair of SDP 'tls-id' attribute values (the attribute values of 198 the offerer and the answerer) uniquely identifies the DTLS 199 association or TLS connection. 201 Name: tls-id 203 Value: tls-id-value 205 Usage Level: media 207 Charset Dependent: no 209 Default Value: N/A 211 Syntax: 213 tls-id-value = 20*255(tls-id-char) 214 tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" 216 218 Example: 220 a=tls-id:abc3de65cddef001be82 222 Every time an endpoint requests to establish a new DTLS association, 223 the endpoint MUST generate a new local 'tls-id' attribute value. A 224 non-changed local 'tls-id' attribute value, in combination with non- 225 changed fingerprints, indicates that the endpoint intends to reuse 226 the existing DTLS association. 228 The 'tls-id' attribute value MUST be generated using a strong random 229 function and include at least 120 bits of randomness. 231 No default value is defined for the SDP 'tls-id' attribute. 232 Implementations that wish to use the attribute MUST explicitly 233 include it in SDP offers and answers. If an offer or answer does not 234 contain a 'tls-id' attribute (this could happen if the offerer or 235 answerer represents an existing implementation that has not been 236 updated to support the 'tls-id' attribute), unless there is another 237 mechanism to explicitly indicate that a new DTLS association is to be 238 established, a modification of one or more of the following 239 characteristics MUST be treated as an indication that an endpoint 240 wants to establish a new DTLS association: 242 o DTLS setup role; or 244 o fingerprint set; or 246 o local transport parameters; or 248 o ICE ufrag value 250 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- 251 id' attribute is 'IDENTICAL', which means that the attribute value 252 must be identical across all media descriptions being multiplexed 253 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 255 For RTP-based media, the 'tls-id' attribute applies to the whole 256 associated media description. The attribute MUST NOT be defined per 257 source (using the SDP 'ssrc' attribute [RFC5576]). 259 The SDP offer/answer [RFC3264] procedures associated with the 260 attribute are defined in Section 5. 262 5. SDP Offer/Answer Procedures 264 5.1. General 266 This section defines the generic SDP offer/answer procedures for 267 negotiating a DTLS association. Additional procedures (e.g., 268 regarding usage of specific SDP attributes etc.) for individual DTLS 269 usages (e.g., SRTP-DTLS) are outside the scope of this specification, 270 and need to be specified in a usage specific specification. 272 NOTE: The procedures in this section are generalizations of 273 procedures first specified in SRTP-DTLS [RFC5763], with the addition 274 of usage of the SDP 'tls-id' attribute. That document is herein 275 updated to make use of these new procedures. 277 The procedures in this section apply to an SDP media description 278 ("m=" line) associated with DTLS-protected media/data. 280 When an offerer or answerer indicates that it wants to establish a 281 new DTLS association, it needs to make sure that media packets 282 associated with any previously established DTLS association and the 283 new DTLS association can be de-multiplexed. In case of an ordered 284 transport (e.g., SCTP) this can be done simply by sending packets for 285 the new DTLS association after all packets associated with a 286 previously established DTLS association has been sent. In case of an 287 unordered transport, such as UDP, packets associated with a 288 previously established DTLS association can arrive after the answer 289 SDP was received and after the first packets associated with the new 290 DTLS association were received. The only way to de-multiplex packets 291 associated with with a previously established DTLS association and 292 the new DTLS association is on the basis of transport 5-tuple. 293 Because of this, if an unordered transport is used for the DTLS 294 association, a new transport (3-tuple) must be allocated by at least 295 one of the endpoints so that DTLS packets can be de-multiplexed. 297 When an offerer needs to establish a new DTLS association, and if an 298 unordered transport (e.g., UDP) is used, the offerer MUST allocate a 299 new transport (3-tuple) for the offer in such a way that the offerer 300 can disambiguate any packets associated with the new DTLS association 301 from any packets associated with any other DTLS association. This 302 typically means using a local address and/or port, or a set of ICE 303 candidates (see Section 6), which were not recently used for any 304 other DTLS association. 306 When an answerer needs to establish a new DTLS association, if an 307 unordered transport is used, and if the offerer did not allocate a 308 new transport, the answerer MUST allocate a new transport for the 309 answer in such a way that it can disambiguate any packets associated 310 with the new DTLS association from any packets associated with any 311 other DTLS association. This typically means using a local address 312 and/or port, or a set of ICE candidates (see Section 6), which were 313 not recently used for any other DTLS association. 315 In order to negotiate a DTLS association, the following SDP 316 attributes are used: 318 o The SDP 'setup' attribute, defined in [RFC4145], is used to 319 negotiate the DTLS roles; 321 o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to 322 provide one or more fingerprint values; and 324 o The SDP 'tls-id' attribute, defined in this specification, is used 325 to identity the DTLS association. 327 This specification does not define the usage of the SDP 'connection' 328 attribute [RFC4145] for negotiating a DTLS association. However, the 329 attribute MAY be used if the DTLS association is used together with 330 another protocol (e.g., SCTP or TCP) for which the usage of the 331 attribute has been defined. 333 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 334 'setup' attribute 'holdconn' value when negotiating a DTLS 335 association. 337 Endpoints MUST support the cipher suites as defined in [RFC8122]. 339 The certificate received during the DTLS handshake MUST match a 340 certificate fingerprint received in SDP 'fingerprint' attributes 341 according to the procedures defined in [RFC8122]. If fingerprints do 342 not match the hashed certificate, then an endpoint MUST tear down the 343 media session immediately (see [RFC8122]). Note that it is 344 permissible to wait until the other side's fingerprint(s) has been 345 received before establishing the connection; however, this may have 346 undesirable latency effects. 348 SDP offerers and answerers might reuse certificates across multiple 349 DTLS associations, and provide identical fingerprint values for each 350 DTLS association. The combination of the SDP 'tls-id' attribute 351 values of the SDP offerer and answerer identifies each individual 352 DTLS association. 354 5.2. Generating the Initial SDP Offer 356 When an offerer sends the initial offer, the offerer MUST insert an 357 SDP 'setup' attribute according to the procedures in [RFC4145], and 358 one or more SDP 'fingerprint' attributes according to the procedures 359 in [RFC8122]. In addition, the offerer MUST insert in the offer an 360 SDP 'tls-id' attribute with a unique value. 362 If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 363 'passive' attribute value, the offerer MUST be prepared to receive a 364 DTLS ClientHello message (if a new DTLS association is established by 365 the answerer) from the answerer before the offerer receives the SDP 366 answer. 368 5.3. Generating the Answer 370 When an answerer sends an answer, the answerer MUST insert in the 371 answer an SDP 'setup' attribute according to the procedures in 372 [RFC4145], and one or more SDP 'fingerprint' attributes according to 373 the procedures in [RFC8122]. If the answerer determines, based on 374 the criteria specified in Section 3.1, that a new DTLS association is 375 to be established, the answerer MUST insert in the associated answer 376 an SDP 'tls-id' attribute with a new unique value. Note that the 377 offerer and answerer generate their own local 'tls-id' attribute 378 values, and the combination of both values identify the DTLS 379 association. 381 If the answerer receives an offer that requires establishment of a 382 new DTLS association, and if the answerer does not accept the 383 establishment of a new DTLS association, the answerer MUST reject the 384 "m=" lines associated with the suggested DTLS association [RFC3264]. 386 If an answerer receives an offer that does not require the 387 establishment of a new DTLS association, and if the answerer 388 determines that a new DTLS association is not to be established, the 389 answerer MUST insert an SDP 'tls-id' attribute with the previously 390 assigned value in the associated answer. In addition, the answerer 391 MUST insert an SDP 'setup' attribute with a value that does not 392 change the previously negotiated DTLS roles, and one or more SDP 393 'fingerprint' attributes values that do not change the previously 394 sent fingerprint set, in the associated answer. 396 If the answerer receives an offer that does not contain an SDP 'tls- 397 id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in 398 the answer. 400 If a new DTLS association is to be established, and if the answerer 401 inserts an SDP 'setup' attribute with an 'active' value in the 402 answer, the answerer MUST initiate a DTLS handshake by sending a DTLS 403 ClientHello message towards the offerer. 405 5.4. Offerer Processing of the SDP Answer 407 When an offerer receives an answer that establishes a new DTLS 408 association based on criteria defined in Section 3.1, and if the 409 offerer becomes DTLS client (based on the value of the SDP 'setup' 410 attribute value [RFC4145]), the offerer MUST establish a DTLS 411 association. If the offerer becomes DTLS server, it MUST wait for 412 the answerer to establish the DTLS association. 414 If the offerer indiciated a desire to reuse an existing DTLS 415 association and the answerer does not request the establishment of a 416 new DTLS assocation, the offerer will continue to use the previously 417 established DTLS association. 419 NOTE: A new DTLS association can be established based on changes in 420 either an SDP offer or answer. When communicating with legacy 421 endpoints, an offerer can receive an answer that includes the same 422 fingerprint set and setup role. A new DTLS association MUST still be 423 established if such an answer was received as a response to an offer 424 which requested the establishment of a new DTLS association. 426 5.5. Modifying the Session 428 When the offerer sends a subsequent offer, and if the offerer wants 429 to establish a new DTLS association, the offerer MUST insert an SDP 430 'setup' attribute according to the procedures in [RFC4145], and one 431 or more SDP 'fingerprint' attributes according to the procedures in 432 [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 433 'tls-id' attribute with a new unique value. 435 When the offerer sends a subsequent offer, and the offerer does not 436 want to establish a new DTLS association, and if a previously 437 established DTLS association exists, the offerer MUST insert an SDP 438 'tls-id' attribute with the previously assigned value in the offer. 439 In addition, the offerer MUST insert an SDP 'setup' attribute, and 440 one or more SDP 'fingerprint' attributes with values that do not 441 change the previously sent fingerprint set, in the offer. The value 442 of the 'setup' attribute SHOULD be set to 'actpass', in order to 443 allow the answerer to establish a new DTLS association with a 444 different role, but MAY be set to the current negotiated role 445 ('active' or 'passive'). It MUST NOT be set to a value that changes 446 the current negotiated role. 448 NOTE: When a new DTLS association is being established, each endpoint 449 needs to be prepared to receive data on both the new and old DTLS 450 associations as long as both are alive. 452 6. ICE Considerations 454 When the Interactive Connectivity Establishment (ICE) mechanism 455 [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are 456 performed before the DTLS handshake begins. Note that if aggressive 457 nomination mode is used, multiple candidate pairs may be marked valid 458 before ICE finally converges on a single candidate pair. 460 NOTE: Aggressive nomination has been deprecated from ICE, but must 461 still be supported for backwards compatibility reasons 462 [I-D.ietf-ice-rfc5245bis]. 464 When a new DTLS association is established over an unordered 465 transport, in order to disambiguate any packets associated with the 466 newly established DTLS association, at least one of the endpoints 467 MUST allocate a completely new set of ICE candidates which were not 468 recently used for any other DTLS association. This means the 469 answerer cannot initiate a new DTLS association unless the offerer 470 initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer 471 wants to initiate a new DTLS association, it needs to initiate an ICE 472 restart and a new offer/answer exchange on its own. However, an ICE 473 restart does not by default require a new DTLS association to be 474 established. 476 NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets 477 are sent directly over UDP, not over DTLS. [RFC5764] describes how 478 to demultiplex STUN packets from DTLS packets and SRTP packets. 480 Each ICE candidate associated with a component is treated as being 481 part of the same DTLS association. Therefore, from a DTLS 482 perspective it is not considered a change of local transport 483 parameters when an endpoint switches between those ICE candidates. 485 7. Transport Protocol Considerations 487 7.1. Transport Re-Usage 489 If DTLS is transported on top of a connection-oriented transport 490 protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, 491 all DTLS packets associated with a previous DTLS association MUST be 492 acknowledged (or timed out) before a new DTLS association can be 493 established on the same instance of that transport (5-tuple). 495 8. TLS Considerations 497 The procedures in this document can also be used for negotiating and 498 establishing aTLS connection, with the restriction described below. 500 As specified in [RFC4145], the SDP 'connection' attribute is used to 501 indicate whether to establish a new TLS connection. An offerer and 502 answerer MUST ensure that the 'connection' attribute value and the 503 'tls-id' attribute value does not cause a conflict regarding whether 504 a new TLS connection is to be established or not. 506 NOTE: Even though the SDP 'connection' attribute can be used to 507 indicate whether a new TLS connection is to be established, the 508 unique combination of SDP 'tls-id' attribute values can be used to 509 identity a TLS connection. The unique value can be used e.g., within 510 TLS protocol extensions to differentiate between mulitple TLS 511 connections and correlate those connections with specific offer/ 512 answer exchanges. 514 If an offerer or answerer inserts an SDP 'connection' attribute with 515 a 'new' value in the offer/answer and also inserts an SDP 'tls-id' 516 attribute, the value of tls-id' attribute MUST be new and unique. 518 If an offerer or answerer inserts an SDP 'connection' attribute with 519 a 'existing' value in the offer/answer, if a previously established 520 TLS connection exists, and if the offerer/answerer previously 521 inserted an SDP 'tls-id' attribute associated with the same TLS 522 connection in an offer/answer, the offerer/answerer MUST also insert 523 an SDP 'tls-id' attribute with the previously assigned value in the 524 offer/answer. 526 If an offerer or answerer receives an offer/answer with conflicting 527 attribute values, the offerer/answerer MUST process the offer/answer 528 as misformed. 530 An endpoint must not make assumptions regarding the support of the 531 SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, 532 both offerers and answerers MUST always use the 'connection' 533 attribute in conjunction with the 'tls-id' attribute. 535 NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is 536 not explicitly present, the implicit default value is 'new'. 538 The SDP example below is based on the example in section 3.4 of 539 [RFC3261], with the addition of the SDP 'tls-id' attribute. 541 m=image 54111 TCP/TLS t38 542 c=IN IP4 192.0.2.2 543 a=tls-id:abc3de65cddef001be82 544 a=setup:passive 545 a=connection:new 546 a=fingerprint:SHA-256 \ 547 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 548 3E:5D:49:6B:19:E5:7C:AB:4A:AD 549 a=fingerprint:SHA-1 \ 550 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 552 9. SIP Considerations 554 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 555 signal protocol for establishing a multimedia session, dialogs 556 [RFC3261] might be established between the caller and multiple 557 callees. This is referred to as forking. If forking occurs, 558 separate DTLS associations will be established between the caller and 559 each callee. 561 It is possible to send an INVITE request which does not contain an 562 SDP offer. Such an INVITE request is often referred to as an 'empty 563 INVITE', or an 'offer-less INVITE'. The receiving endpoint will 564 include the SDP offer in a response to the request. When the 565 endpoint generates such SDP offer, if a previously established DTLS 566 association exists, the offerer MUST insert an SDP 'tls-id' 567 attribute, and one or more SDP 'fingerprint' attributes, with 568 previously assigned attribute values. If a previously established 569 DTLS association did not exist, the offer MUST be generated based on 570 the same rules as a new offer (see Section 5.2). Regardless of the 571 previous existence of a DTLS association, the SDP 'setup' attribute 572 MUST be included according to the rules defined in [RFC4145] and if 573 ICE is used, ICE restart MUST be initiated. 575 10. RFC Updates 577 10.1. General 579 This section updates specifications that use DTLS-protected media, in 580 order to reflect the procedures defined in this specification. 582 10.2. Update to RFC 5763 584 10.2.1. Update to section 5 586 OLD TEXT: 588 5. Establishing a Secure Channel 590 The two endpoints in the exchange present their identities as part of 591 the DTLS handshake procedure using certificates. This document uses 592 certificates in the same style as described in "Connection-Oriented 593 Media Transport over the Transport Layer Security (TLS) Protocol in 594 the Session Description Protocol (SDP)" [RFC4572]. 596 If self-signed certificates are used, the content of the 597 subjectAltName attribute inside the certificate MAY use the uniform 598 resource identifier (URI) of the user. This is useful for debugging 599 purposes only and is not required to bind the certificate to one of 600 the communication endpoints. The integrity of the certificate is 601 ensured through the fingerprint attribute in the SDP. The 602 subjectAltName is not an important component of the certificate 603 verification. 605 The generation of public/private key pairs is relatively expensive. 606 Endpoints are not required to generate certificates for each session. 608 The offer/answer model, defined in [RFC3264], is used by protocols 609 like the Session Initiation Protocol (SIP) [RFC3261] to set up 610 multimedia sessions. In addition to the usual contents of an SDP 611 [RFC4566] message, each media description ("m=" line and associated 612 parameters) will also contain several attributes as specified in 613 [RFC5764], [RFC4145], and [RFC4572]. 615 When an endpoint wishes to set up a secure media session with another 616 endpoint, it sends an offer in a SIP message to the other endpoint. 617 This offer includes, as part of the SDP payload, the fingerprint of 618 the certificate that the endpoint wants to use. The endpoint SHOULD 619 send the SIP message containing the offer to the offerer's SIP proxy 620 over an integrity protected channel. The proxy SHOULD add an 621 Identity header field according to the procedures outlined in 622 [RFC4474]. The SIP message containing the offer SHOULD be sent to 623 the offerer's SIP proxy over an integrity protected channel. When 624 the far endpoint receives the SIP message, it can verify the identity 625 of the sender using the Identity header field. Since the Identity 626 header field is a digital signature across several SIP header fields, 627 in addition to the body of the SIP message, the receiver can also be 628 certain that the message has not been tampered with after the digital 629 signature was applied and added to the SIP message. 631 The far endpoint (answerer) may now establish a DTLS association with 632 the offerer. Alternately, it can indicate in its answer that the 633 offerer is to initiate the TLS association. In either case, mutual 634 DTLS certificate-based authentication will be used. After completing 635 the DTLS handshake, information about the authenticated identities, 636 including the certificates, are made available to the endpoint 637 application. The answerer is then able to verify that the offerer's 638 certificate used for authentication in the DTLS handshake can be 639 associated to the certificate fingerprint contained in the offer in 640 the SDP. At this point, the answerer may indicate to the end user 641 that the media is secured. The offerer may only tentatively accept 642 the answerer's certificate since it may not yet have the answerer's 643 certificate fingerprint. 645 When the answerer accepts the offer, it provides an answer back to 646 the offerer containing the answerer's certificate fingerprint. At 647 this point, the offerer can accept or reject the peer's certificate 648 and the offerer can indicate to the end user that the media is 649 secured. 651 Note that the entire authentication and key exchange for securing the 652 media traffic is handled in the media path through DTLS. The 653 signaling path is only used to verify the peers' certificate 654 fingerprints. 656 The offer and answer MUST conform to the following requirements. 658 o The endpoint MUST use the setup attribute defined in [RFC4145]. 659 The endpoint that is the offerer MUST use the setup attribute 660 value of setup:actpass and be prepared to receive a client_hello 661 before it receives the answer. The answerer MUST use either a 662 setup attribute value of setup:active or setup:passive. Note that 663 if the answerer uses setup:passive, then the DTLS handshake will 664 not begin until the answerer is received, which adds additional 665 latency. setup:active allows the answer and the DTLS handshake to 666 occur in parallel. Thus, setup:active is RECOMMENDED. Whichever 667 party is active MUST initiate a DTLS handshake by sending a 668 ClientHello over each flow (host/port quartet). 670 o The endpoint MUST NOT use the connection attribute defined in 671 [RFC4145]. 673 o The endpoint MUST use the certificate fingerprint attribute as 674 specified in [RFC4572]. 676 o The certificate presented during the DTLS handshake MUST match the 677 fingerprint exchanged via the signaling path in the SDP. The 678 security properties of this mechanism are described in Section 8. 680 o If the fingerprint does not match the hashed certificate, then the 681 endpoint MUST tear down the media session immediately. Note that 682 it is permissible to wait until the other side's fingerprint has 683 been received before establishing the connection; however, this 684 may have undesirable latency effects. 686 NEW TEXT: 688 5. Establishing a Secure Channel 690 The two endpoints in the exchange present their identities as part of 691 the DTLS handshake procedure using certificates. This document uses 692 certificates in the same style as described in "Connection-Oriented 693 Media Transport over the Transport Layer Security (TLS) Protocol in 694 the Session Description Protocol (SDP)" [RFC4572]. 696 If self-signed certificates are used, the content of the 697 subjectAltName attribute inside the certificate MAY use the uniform 698 resource identifier (URI) of the user. This is useful for debugging 699 purposes only and is not required to bind the certificate to one of 700 the communication endpoints. The integrity of the certificate is 701 ensured through the fingerprint attribute in the SDP. 703 The generation of public/private key pairs is relatively expensive. 704 Endpoints are not required to generate certificates for each session. 706 The offer/answer model, defined in [RFC3264], is used by protocols 707 like the Session Initiation Protocol (SIP) [RFC3261] to set up 708 multimedia sessions. 710 When an endpoint wishes to set up a secure media session with another 711 endpoint, it sends an offer in a SIP message to the other endpoint. 712 This offer includes, as part of the SDP payload, a fingerprint of 713 a certificate that the endpoint wants to use. The endpoint SHOULD 714 send the SIP message containing the offer to the offerer's SIP proxy 715 over an integrity protected channel. The proxy SHOULD add an 716 Identity header field according to the procedures outlined in 717 [RFC4474]. When the far endpoint receives the SIP message, it can 718 verify the identity of the sender using the Identity header field. 719 Since the Identity header field is a digital signature across several 720 SIP header fields, in addition to the body of the SIP message, the 721 receiver can also be certain that the message has not been tampered 722 with after the digital signature was applied and added to the SIP 723 message. 725 The far endpoint (answerer) may now establish a DTLS association with 726 the offerer. Alternately, it can indicate in its answer that the 727 offerer is to initiate the DTLS association. In either case, mutual 728 DTLS certificate-based authentication will be used. After completing 729 the DTLS handshake, information about the authenticated identities, 730 including the certificates, are made available to the endpoint 731 application. The answerer is then able to verify that the offerer's 732 certificate used for authentication in the DTLS handshake can be 733 associated to a certificate fingerprint contained in the offer in 734 the SDP. At this point, the answerer may indicate to the end user 735 that the media is secured. The offerer may only tentatively accept 736 the answerer's certificate since it may not yet have the answerer's 737 certificate fingerprint. 739 When the answerer accepts the offer, it provides an answer back to 740 the offerer containing the answerer's certificate fingerprint. At 741 this point, the offerer can accept or reject the peer's certificate 742 and the offerer can indicate to the end user that the media is 743 secured. 745 Note that the entire authentication and key exchange for securing 746 the media traffic is handled in the media path through DTLS. The 747 signaling path is only used to verify the peers' certificate 748 fingerprints. 750 The offerer and answerer MUST follow the SDP offer/answer procedures 751 defined in [RFCXXXX]. 753 10.2.2. Update to section 6.6 755 OLD TEXT: 757 6.6. Session Modification 759 Once an answer is provided to the offerer, either endpoint MAY 760 request a session modification that MAY include an updated offer. 761 This session modification can be carried in either an INVITE or 762 UPDATE request. The peers can reuse the existing associations if 763 they are compatible (i.e., they have the same key fingerprints and 764 transport parameters), or establish a new one following the same 765 rules are for initial exchanges, tearing down the existing 766 association as soon as the offer/answer exchange is completed. Note 767 that if the active/passive status of the endpoints changes, a new 768 connection MUST be established. 770 NEW TEXT: 772 6.6. Session Modification 774 Once an answer is provided to the offerer, either endpoint MAY 775 request a session modification that MAY include an updated offer. 776 This session modification can be carried in either an INVITE or 777 UPDATE request. The peers can reuse an existing DTLS association, 778 or establish a new one, following the procedures in [RFCXXXX]. 780 10.2.3. Update to section 6.7.1 781 OLD TEXT: 783 6.7.1. ICE Interaction 785 Interactive Connectivity Establishment (ICE), as specified in 786 [RFC5245], provides a methodology of allowing participants in 787 multimedia sessions to verify mutual connectivity. When ICE is being 788 used, the ICE connectivity checks are performed before the DTLS 789 handshake begins. Note that if aggressive nomination mode is used, 790 multiple candidate pairs may be marked valid before ICE finally 791 converges on a single candidate pair. Implementations MUST treat all 792 ICE candidate pairs associated with a single component as part of the 793 same DTLS association. Thus, there will be only one DTLS handshake 794 even if there are multiple valid candidate pairs. Note that this may 795 mean adjusting the endpoint IP addresses if the selected candidate 796 pair shifts, just as if the DTLS packets were an ordinary media 797 stream. 799 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 800 packets are sent directly over UDP, not over DTLS. [RFC5764] 801 describes how to demultiplex STUN packets from DTLS packets and SRTP 802 packets. 804 NEW TEXT: 806 6.7.1. ICE Interaction 808 The Interactive Connectivity Establishment (ICE) 809 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 810 are described in [RFCXXXX]. 812 10.3. Update to RFC 7345 814 10.3.1. Update to section 4 816 OLD TEXT: 818 4. SDP Offerer/Answerer Procedures 820 4.1. General 822 An endpoint (i.e., both the offerer and the answerer) MUST create an 823 SDP media description ("m=" line) for each UDPTL-over-DTLS media 824 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 825 "proto" field of the "m=" line. 827 The procedures in this section apply to an "m=" line associated with 828 a UDPTL-over-DTLS media stream. 830 In order to negotiate a UDPTL-over-DTLS media stream, the following 831 SDP attributes are used: 833 o The SDP attributes defined for UDPTL over UDP, as described in 834 [ITU.T38.2010]; and 836 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 837 described in this section. 839 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 841 In order to negotiate the TLS roles for the UDPTL-over-DTLS transport 842 connection, the endpoint MUST use the SDP "setup" attribute 843 [RFC4145]. 845 If the endpoint supports, and is willing to use, a cipher suite with 846 an associated certificate, the endpoint MUST include an SDP 847 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 848 for generating and verifying the SDP "fingerprint" attribute value. 849 The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST 850 support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 851 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 852 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 853 Secrecy (PFS) cipher suites over non-PFS cipher suites. 854 Implementations SHOULD disable TLS-level compression. 856 If a cipher suite with an associated certificate is selected during 857 the DTLS handshake, the certificate received during the DTLS 858 handshake MUST match the fingerprint received in the SDP 859 "fingerprint" attribute. If the fingerprint does not match the 860 hashed certificate, then the endpoint MUST tear down the media 861 session immediately. Note that it is permissible to wait until the 862 other side's fingerprint has been received before establishing the 863 connection; however, this may have undesirable latency effects. 865 4.2. Generating the Initial Offer 867 The offerer SHOULD assign the SDP "setup" attribute with a value of 868 "actpass", unless the offerer insists on being either the sender or 869 receiver of the DTLS ClientHello message, in which case the offerer 870 can use either a value of "active" (the offerer will be the sender of 871 ClientHello) or "passive" (the offerer will be the receiver of 872 ClientHello). The offerer MUST NOT assign an SDP "setup" attribute 873 with a "holdconn" value. 875 If the offerer assigns the SDP "setup" attribute with a value of 876 "actpass" or "passive", the offerer MUST be prepared to receive a 877 DTLS ClientHello message before it receives the SDP answer. 879 4.3. Generating the Answer 881 If the answerer accepts the offered UDPTL-over-DTLS transport 882 connection, in the associated SDP answer, the answerer MUST assign an 883 SDP "setup" attribute with a value of either "active" or "passive", 884 according to the procedures in [RFC4145]. The answerer MUST NOT 885 assign an SDP "setup" attribute with a value of "holdconn". 887 If the answerer assigns an SDP "setup" attribute with a value of 888 "active" value, the answerer MUST initiate a DTLS handshake by 889 sending a DTLS ClientHello message on the negotiated media stream, 890 towards the IP address and port of the offerer. 892 4.4. Offerer Processing of the Answer 894 When the offerer receives an SDP answer, if the offerer ends up being 895 active it MUST initiate a DTLS handshake by sending a DTLS 896 ClientHello message on the negotiated media stream, towards the IP 897 address and port of the answerer. 899 4.5. Modifying the Session 901 Once an offer/answer exchange has been completed, either endpoint MAY 902 send a new offer in order to modify the session. The endpoints can 903 reuse the existing DTLS association if the key fingerprint values and 904 transport parameters indicated by each endpoint are unchanged. 905 Otherwise, following the rules for the initial offer/answer exchange, 906 the endpoints can negotiate and create a new DTLS association and, 907 once created, delete the previous DTLS association, following the 908 same rules for the initial offer/answer exchange. Each endpoint 909 needs to be prepared to receive data on both the new and old DTLS 910 associations as long as both are alive. 912 NEW TEXT: 914 4. SDP Offerer/Answerer Procedures 916 An endpoint (i.e., both the offerer and the answerer) MUST create an 917 SDP media description ("m=" line) for each UDPTL-over-DTLS media 918 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 919 "proto" field of the "m=" line. 921 The offerer and answerer MUST follow the SDP offer/answer procedures 922 defined in [RFCXXXX] in order to negotiate the DTLS association 923 associated with the UDPTL-over-DTLS media stream. In addition, 924 the offerer and answerer MUST use the SDP attributes defined for 925 UDPTL over UDP, as defined in [ITU.T38.2010]. 927 10.3.2. Update to section 5.2.1 929 OLD TEXT: 931 5.2.1. ICE Usage 933 When Interactive Connectivity Establishment (ICE) [RFC5245] is being 934 used, the ICE connectivity checks are performed before the DTLS 935 handshake begins. Note that if aggressive nomination mode is used, 936 multiple candidate pairs may be marked valid before ICE finally 937 converges on a single candidate pair. User Agents (UAs) MUST treat 938 all ICE candidate pairs associated with a single component as part 939 of the same DTLS association. Thus, there will be only one DTLS 940 handshake even if there are multiple valid candidate pairs. Note 941 that this may mean adjusting the endpoint IP addresses if the 942 selected candidate pair shifts, just as if the DTLS packets were an 943 ordinary media stream. In the case of an ICE restart, the DTLS 944 handshake procedure is repeated, and a new DTLS association is 945 created. Once the DTLS handshake is completed and the new DTLS 946 association has been created, the previous DTLS association is 947 deleted. 949 NEW TEXT: 951 5.2.1. ICE Usage 953 The Interactive Connectivity Establishment (ICE) 954 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 955 are described in [RFCXXXX]. 957 [RFC EDITOR NOTE: Througout the document, please replace RFCXXXX 958 with the RFC number of this document.] 960 11. Security Considerations 962 This specification does not modify the security considerations 963 associated with DTLS, or the SDP offer/answer mechanism. In addition 964 to the introduction of the SDP 'tls-id' attribute, the specification 965 simply clarifies the procedures for negotiating and establishing a 966 DTLS association. 968 12. IANA Considerations 970 This document updates the "Session Description Protocol Parameters" 971 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 972 it adds the SDP 'tls-id' attribute to the table for SDP media level 973 attributes. 975 Attribute name: tls-id 976 Type of attribute: media-level 977 Subject to charset: no 978 Purpose: Indicates whether a new DTLS association or TLS connection 979 is to be established/re-established. 980 Appropriate Values: see Section 4 981 Contact name: Christer Holmberg 982 Mux Category: IDENTICAL 984 13. Acknowledgements 986 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, 987 Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing 988 comments and suggestions on the document. Ben Campbell performed an 989 AD review. 991 14. Change Log 993 [RFC EDITOR NOTE: Please remove this section when publishing] 995 Changes from draft-ietf-mmusic-sdp-dtls-23 997 o Editrial change to make it clear that the document does not modify 998 the procedures in RFC 8122. 1000 Changes from draft-ietf-mmusic-sdp-dtls-22 1002 o Support for TLS added. 1004 o Editorial changes based on sec-dir review by Rich Salz. 1006 o Editorial changes based on gen-art review by Paul Kyzivat. 1008 o Editorial changes based on ops-dir review by Carlos Pignataro. 1010 Changes from draft-ietf-mmusic-sdp-dtls-21 1012 o Changes based on AD review by Ben Campbell. 1014 o (https://www.ietf.org/mail-archive/web/mmusic/current/ 1015 msg17707.html) 1017 Changes from draft-ietf-mmusic-sdp-dtls-20 1019 o Change to length and randomness of tls-id attribute value. 1021 Changes from draft-ietf-mmusic-sdp-dtls-19 1023 o Change based on comment from Roman. 1025 Changes from draft-ietf-mmusic-sdp-dtls-18 1027 o Changes based on comments from Flemming. 1029 o - Change in tls-id value definition. 1031 o - Editorial fixes. 1033 Changes from draft-ietf-mmusic-sdp-dtls-17 1035 o Reference fix. 1037 Changes from draft-ietf-mmusic-sdp-dtls-16 1039 o Editorial changes based on 2nd WGLC comments from Christian Groves 1040 and Nevenka Biondic. 1042 Changes from draft-ietf-mmusic-sdp-dtls-15 1044 o tls-id attribute value made globally unique 1046 Changes from draft-ietf-mmusic-sdp-dtls-14 1048 o Changes based on comments from Flemming: 1050 o - Additional dtls-is clarifiations 1052 o - Editorial fixes 1054 Changes from draft-ietf-mmusic-sdp-dtls-13 1056 o Text about the updated RFCs added to Abstract and Introduction 1058 o Reference to RFC 5763 removed from section 6 (ICE Considerations) 1060 o Reference to RFC 5763 removed from section 8 (SIP Considerations) 1061 Changes from draft-ietf-mmusic-sdp-dtls-12 1063 o "unreliable" changed to "unordered" 1065 Changes from draft-ietf-mmusic-sdp-dtls-11 1067 o Attribute name changed to tls-id 1069 o Additional text based on comments from Roman Shpount. 1071 Changes from draft-ietf-mmusic-sdp-dtls-10 1073 o Modified document to use tls-id instead of dtls-connection 1075 o Changes are based on comments from Eric Rescorla, Justin Uberti, 1076 and Paul Kyzivat. 1078 Changes from draft-ietf-mmusic-sdp-dtls-08 1080 o Offer/Answer section modified in order to allow sending of 1081 multiple SDP 'fingerprint' attributes. 1083 o Terminology made consistent: 'DTLS connection' replaced with 'DTLS 1084 association'. 1086 o Editorial changes based on comments from Paul Kyzivat. 1088 Changes from draft-ietf-mmusic-sdp-dtls-07 1090 o Reference to RFC 7315 replaced with reference to RFC 7345. 1092 Changes from draft-ietf-mmusic-sdp-dtls-06 1094 o Text on restrictions regarding spanning a DTLS association over 1095 multiple transports added. 1097 o Mux category added to IANA Considerations. 1099 o Normative text regarding mux category and source-specific 1100 applicability added. 1102 o Reference to RFC 7315 added. 1104 o Clarified that offerer/answerer that has not been updated to 1105 support this specification will not include the tls-id attribute 1106 in offers and answers. 1108 o Editorial corrections based on WGLC comments from Charles Eckel. 1110 Changes from draft-ietf-mmusic-sdp-dtls-05 1112 o Text on handling offer/answer error conditions added. 1114 Changes from draft-ietf-mmusic-sdp-dtls-04 1116 o Editorial nits fixed based on comments from Paul Kyzivat: 1118 Changes from draft-ietf-mmusic-sdp-dtls-03 1120 o Changes based on comments from Paul Kyzivat: 1122 o - Modification of tls-id attribute section. 1124 o - Removal of IANA considerations subsection. 1126 o - Making note into normative text in o/a section. 1128 o Changes based on comments from Martin Thompson: 1130 o - Abbreviations section removed. 1132 o - Clarify that a new DTLS association requires a new o/a 1133 transaction. 1135 Changes from draft-ietf-mmusic-sdp-dtls-02 1137 o - Updated RFCs added to boilerplate. 1139 Changes from draft-ietf-mmusic-sdp-dtls-01 1141 o - Annex regarding 'tls-id-id' attribute removed. 1143 o - Additional SDP offer/answer procedures, related to certificates, 1144 added. 1146 o - Updates to RFC 5763 and RFC 7345 added. 1148 o - Transport protocol considerations added. 1150 Changes from draft-ietf-mmusic-sdp-dtls-00 1152 o - SDP 'connection' attribute replaced with new 'tls-id' attribute. 1154 o - IANA Considerations added. 1156 o - E-mail regarding 'tls-id-id' attribute added as Annex. 1158 Changes from draft-holmberg-mmusic-sdp-dtls-01 1160 o - draft-ietf-mmusic version of draft submitted. 1162 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 1163 with another expired draft. 1165 o - Clarify that if ufrag in offer is unchanged, it must be 1166 unchanged in associated answer. 1168 o - SIP Considerations section added. 1170 o - Section about multiple SDP fingerprint attributes added. 1172 Changes from draft-holmberg-mmusic-sdp-dtls-00 1174 o - Editorial changes and clarifications. 1176 15. References 1178 15.1. Normative References 1180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1181 Requirement Levels", BCP 14, RFC 2119, 1182 DOI 10.17487/RFC2119, March 1997, 1183 . 1185 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1186 A., Peterson, J., Sparks, R., Handley, M., and E. 1187 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1188 DOI 10.17487/RFC3261, June 2002, 1189 . 1191 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1192 with Session Description Protocol (SDP)", RFC 3264, 1193 DOI 10.17487/RFC3264, June 2002, 1194 . 1196 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1197 the Session Description Protocol (SDP)", RFC 4145, 1198 DOI 10.17487/RFC4145, September 2005, 1199 . 1201 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1202 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1203 July 2006, . 1205 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1206 for Establishing a Secure Real-time Transport Protocol 1207 (SRTP) Security Context Using Datagram Transport Layer 1208 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1209 2010, . 1211 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 1212 Transport Layer (UDPTL) over Datagram Transport Layer 1213 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 1214 2014, . 1216 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 1217 Transport over the Transport Layer Security (TLS) Protocol 1218 in the Session Description Protocol (SDP)", RFC 8122, 1219 DOI 10.17487/RFC8122, March 2017, 1220 . 1222 [I-D.ietf-ice-rfc5245bis] 1223 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1224 Connectivity Establishment (ICE): A Protocol for Network 1225 Address Translator (NAT) Traversal", draft-ietf-ice- 1226 rfc5245bis-08 (work in progress), December 2016. 1228 [I-D.ietf-mmusic-sdp-mux-attributes] 1229 Nandakumar, S., "A Framework for SDP Attributes when 1230 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1231 (work in progress), December 2016. 1233 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1234 Holmberg, C., Alvestrand, H., and C. Jennings, 1235 "Negotiating Media Multiplexing Using the Session 1236 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1237 negotiation-38 (work in progress), April 2017. 1239 15.2. Informative References 1241 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1242 Authenticated Identity Management in the Session 1243 Initiation Protocol (SIP)", RFC 4474, 1244 DOI 10.17487/RFC4474, August 2006, 1245 . 1247 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1248 Transport Layer Security (TLS) Protocol in the Session 1249 Description Protocol (SDP)", RFC 4572, 1250 DOI 10.17487/RFC4572, July 2006, 1251 . 1253 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1254 (ICE): A Protocol for Network Address Translator (NAT) 1255 Traversal for Offer/Answer Protocols", RFC 5245, 1256 DOI 10.17487/RFC5245, April 2010, 1257 . 1259 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1260 Media Attributes in the Session Description Protocol 1261 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1262 . 1264 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1265 Security (DTLS) Extension to Establish Keys for the Secure 1266 Real-time Transport Protocol (SRTP)", RFC 5764, 1267 DOI 10.17487/RFC5764, May 2010, 1268 . 1270 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1271 Transport Layer Security (DTLS) for Stream Control 1272 Transmission Protocol (SCTP)", RFC 6083, 1273 DOI 10.17487/RFC6083, January 2011, 1274 . 1276 [I-D.ietf-stir-rfc4474bis] 1277 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1278 "Authenticated Identity Management in the Session 1279 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 1280 (work in progress), February 2017. 1282 [ITU.T38.2010] 1283 International Telecommunications Union, "Procedures for 1284 real-time Group 3 facsimile communication over IP 1285 networks", ITU-T Recommendation T.38, September 2010. 1287 Authors' Addresses 1289 Christer Holmberg 1290 Ericsson 1291 Hirsalantie 11 1292 Jorvas 02420 1293 Finland 1295 Email: christer.holmberg@ericsson.com 1296 Roman Shpount 1297 TurboBridge 1298 4905 Del Ray Avenue, Suite 300 1299 Bethesda, MD 20814 1300 USA 1302 Phone: +1 (240) 292-6632 1303 Email: rshpount@turbobridge.com