idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-32.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 (October 29, 2017) is 2370 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 802, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-13 == 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-39 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-14 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-sdp-uks-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 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: May 2, 2018 October 29, 2017 8 Session Description Protocol (SDP) Offer/Answer Considerations for 9 Datagram Transport Layer Security (DTLS) and Transport Layer Security 10 (TLS) 11 draft-ietf-mmusic-dtls-sdp-32.txt 13 Abstract 15 This document defines the Session Description Protocol (SDP) offer/ 16 answer procedures for negotiating and establishing a Datagram 17 Transport Layer Security (DTLS) association. The document also 18 defines the criteria for when a new DTLS association must be 19 established. The document updates RFC 5763 and RFC 7345, by 20 replacing common SDP offer/answer procedures with a reference to this 21 specification. 23 This document defines a new SDP media-level attribute, 'tls-id'. 25 This document also defines how the 'tls-id' attribute can be used for 26 negotiating and establishing a Transport Layer Security (TLS) 27 connection, in conjunction with the procedures in RFC 4145 and RFC 28 8122. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 2, 2018. 47 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Establishing a new DTLS Association . . . . . . . . . . . . . 4 69 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Change of Local Transport Parameters . . . . . . . . . . 5 71 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 5 72 4. SDP tls-id Attribute . . . . . . . . . . . . . . . . . . . . 5 73 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 74 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9 76 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 10 77 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 78 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 79 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14 85 9.2.1. Update to section 1 . . . . . . . . . . . . . . . . . 14 86 9.2.2. Update to section 5 . . . . . . . . . . . . . . . . . 15 87 9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16 88 9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16 89 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17 90 9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17 91 9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17 92 9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 96 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 102 14.2. Informative References . . . . . . . . . . . . . . . . . 25 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 105 1. Introduction 107 [RFC5763] defines Session Description Protocol (SDP) offer/answer 108 procedures for Secure Realtime Transport Protocol Using Datagram 109 Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/ 110 answer procedures for UDP Transport Layer over Datagram Transport 111 Layer Security (UDPTL-DTLS). This specification defines general 112 offer/answer procedures for DTLS, based on the procedures in 113 [RFC5763]. Other specifications, defining specific DTLS usages, can 114 then reference this specification, in order to ensure that the DTLS 115 aspects are common among all usages. Having common procedures is 116 essential when multiple usages share the same DTLS association 117 [I-D.ietf-mmusic-sdp-bundle-negotiation]. The document updates 118 [RFC5763] and [RFC7345], by replacing common SDP offer/answer 119 procedures with a reference to this specification. 121 NOTE: Since the publication of [RFC5763], [RFC4474] has been 122 obsoleted by [I-D.ietf-stir-rfc4474bis]. The updating of the 123 references (and the associated procedures) within [RFC5763] is 124 outside the scope of this document. However, implementers of 125 [RFC5763] applications are encouraged to implement 126 [I-D.ietf-stir-rfc4474bis] instead of [RFC4474]. 128 As defined in [RFC5763], a new DTLS association MUST be established 129 when transport parameters are changed. Transport parameter change is 130 not well defined when Interactive Connectivity Establishment (ICE) 131 [I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a 132 transport change is based on ufrag [I-D.ietf-ice-rfc5245bis] change, 133 but the ufrag value is changed both when ICE is negotiated and when 134 ICE restart [I-D.ietf-ice-rfc5245bis] occurs. These events do not 135 always require a new DTLS association to be established, but 136 previously there was no way to explicitly indicate in an SDP offer or 137 answer whether a new DTLS association is required. To solve that 138 problem, this document defines a new SDP attribute, 'tls-id'. The 139 pair of SDP 'tls-id' attribute values (the attribute values of the 140 offerer and the answerer) uniquely identifies the DTLS association. 141 Providing a new value of the 'tls-id' attribute in an SDP offer or 142 answers can be used to indicate whether a new DTLS association is to 143 be established. 145 The SDP 'tls-id' attribute can be specified when negotiating a 146 Transport Layer Security (TLS) connection, using the procedures in 147 this document in conjunction with the procedures in [RFC5763] and 149 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 151 [RFC8122]. The unique combination of SDP 'tls-id' attribute values 152 can be used to identity the negotiated TLS connection. The unique 153 value can be used, for example, within TLS protocol extensions to 154 differentiate between multiple TLS connections and correlate those 155 connections with specific offer/answer exchanges. The TLS specific 156 considerations are described in Section 7. 158 2. Conventions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. Establishing a new DTLS Association 168 3.1. General 170 A new DTLS association must be established between two endpoints 171 after a successful SDP offer/answer exchange in the following cases: 173 o The negotiated DTLS setup roles change; or 175 o One or more fingerprint values are modified, added or removed in 176 either an SDP offer or answer; or 178 o The intent to establish a new DTLS association is explicitly 179 signaled using SDP, by changing the value of the SDP 'tls-id' 180 attribute defined in this document; 182 NOTE: The first two items above are based on the procedures in 183 [RFC5763]. This specification adds the support for explicit 184 signaling using the SDP 'tls-id' attribute. 186 A new DTLS association can only be established as a result of the 187 successful SDP offer/answer exchange. Whenever an entity determines 188 that a new DTLS association is required, the entity MUST initiate an 189 SDP offer/answer exchange, following the procedures in Section 5. 191 The sections below describe typical cases where a new DTLS 192 association needs to be established. 194 In this document, a "new DTLS association" between two endpoints 195 refers to either an initial DTLS association (when no DTLS 196 association is currently established between the endpoints) or an 197 DTLS association replacing a previously established DTLS association. 199 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 201 3.2. Change of Local Transport Parameters 203 If an endpoint modifies its local transport parameters (address and/ 204 or port), and if the modification requires a new DTLS association, 205 the endpoint MUST change its local SDP 'tls-id' attribute value (see 206 Section 4). 208 If the underlying transport protocol prohibits a DTLS association 209 from spanning multiple 5-tuples (transport/source address/source 210 port/destination address/destination port), and if the 5-tuple is 211 changed, the endpoint MUST change its local SDP 'tls-id' attribute 212 value (see Section 4). An example of such a case is when DTLS is 213 carried over the Stream Control Transmission Protocol (SCTP), as 214 described in [RFC6083]. 216 3.3. Change of ICE ufrag value 218 If an endpoint uses ICE, and modifies a local ufrag value, and if the 219 modification requires a new DTLS association, the endpoint MUST 220 change its local SDP 'tls-id' attribute value (see Section 4). 222 4. SDP tls-id Attribute 224 The pair of SDP 'tls-id' attribute values (the attribute values of 225 the offerer and the answerer) uniquely identifies the DTLS 226 association or TLS connection. 228 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 230 Name: tls-id 232 Value: tls-id-value 234 Usage Level: media 236 Charset Dependent: no 238 Default Value: N/A 240 Syntax: 242 tls-id-value = 20*255(tls-id-char) 243 tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" 245 247 Example: 249 a=tls-id:abc3de65cddef001be82 251 Every time an endpoint requests to establish a new DTLS association, 252 the endpoint MUST generate a new local 'tls-id' attribute value. A 253 non-changed local 'tls-id' attribute value, in combination with non- 254 changed fingerprints, indicates that the endpoint intends to reuse 255 the existing DTLS association. 257 The 'tls-id' attribute value MUST be generated using a strong random 258 function and include at least 120 bits of randomness. 260 No default value is defined for the SDP 'tls-id' attribute. 261 Implementations that wish to use the attribute MUST explicitly 262 include it in SDP offers and answers. If an offer or answer does not 263 contain a 'tls-id' attribute (this could happen if the offerer or 264 answerer represents an existing implementation that has not been 265 updated to support the 'tls-id' attribute), unless there is another 266 mechanism to explicitly indicate that a new DTLS association is to be 267 established, a modification of one or more of the following 268 characteristics MUST be treated as an indication that an endpoint 269 wants to establish a new DTLS association: 271 o DTLS setup role; or 273 o fingerprint set; or 275 o local transport parameters 277 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 279 NOTE: A modification of the ufrag value is not treated as an 280 indication that an endpoint wants to establish a new DTLS assocation. 281 In order to indicate that a new DTLS association is to be 282 established, one or more of the characteristics listed above have to 283 be modified. 285 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- 286 id' attribute is 'IDENTICAL', which means that the attribute value 287 applies to all media descriptions being multiplexed 288 [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in 289 [I-D.ietf-mmusic-sdp-bundle-negotiation], in order to avoid 290 duplication the attribute is only associated with the "m=" line 291 representing the offerer/answerer BUNDLE-tag. 293 For RTP-based media, the 'tls-id' attribute applies to the whole 294 associated media description. The attribute MUST NOT be defined per 295 source (using the SDP 'ssrc' attribute [RFC5576]). 297 The SDP offer/answer [RFC3264] procedures associated with the 298 attribute are defined in Section 5. 300 5. SDP Offer/Answer Procedures 302 5.1. General 304 This section defines the generic SDP offer/answer procedures for 305 negotiating a DTLS association. Additional procedures (e.g., 306 regarding usage of specific SDP attributes etc.) for individual DTLS 307 usages (e.g., DTLS-SRTP) are outside the scope of this specification, 308 and need to be specified in a usage specific specification. 310 NOTE: The procedures in this section are generalizations of 311 procedures first specified in DTLS-SRTP [RFC5763], with the addition 312 of usage of the SDP 'tls-id' attribute. That document is herein 313 updated to make use of these new procedures. 315 The procedures in this section apply to an SDP media description 316 ("m=" line) associated with DTLS-protected media/data. 318 When an offerer or answerer indicates that it wants to establish a 319 new DTLS association, it needs to make sure that media packets 320 associated with any previously established DTLS association and the 321 new DTLS association can be de-multiplexed. In case of an ordered 322 transport (e.g., SCTP) this can be done simply by sending packets for 323 the new DTLS association after all packets associated with a 324 previously established DTLS association has been sent. In case of an 325 unordered transport, such as UDP, packets associated with a 326 previously established DTLS association can arrive after the answer 328 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 330 SDP was received and after the first packets associated with the new 331 DTLS association were received. The only way to de-multiplex packets 332 associated with with a previously established DTLS association and 333 the new DTLS association is on the basis of the 5-tuple. Because of 334 this, if an unordered transport is used for the DTLS association, a 335 new 3-tuple (transport/source address/source port) MUST be allocated 336 by at least one of the endpoints so that DTLS packets can be de- 337 multiplexed. 339 When an offerer needs to establish a new DTLS association, and if an 340 unordered transport (e.g., UDP) is used, the offerer MUST allocate a 341 new 3-tuple for the offer in such a way that the offerer can 342 disambiguate any packets associated with the new DTLS association 343 from any packets associated with any other DTLS association. This 344 typically means using a local address and/or port, or a set of ICE 345 candidates (see Section 6), which were not recently used for any 346 other DTLS association. 348 When an answerer needs to establish a new DTLS association, if an 349 unordered transport is used, and if the offerer did not allocate a 350 new 3-tuple, the answerer MUST allocate a new 3-tuple for the answer 351 in such a way that it can disambiguate any packets associated with 352 the new DTLS association from any packets associated with any other 353 DTLS association. This typically means using a local address and/or 354 port, or a set of ICE candidates (see Section 6), which were not 355 recently used for any other DTLS association. 357 In order to negotiate a DTLS association, the following SDP 358 attributes are used: 360 o The SDP 'setup' attribute, defined in [RFC4145], is used to 361 negotiate the DTLS roles; 363 o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to 364 provide one or more fingerprint values; and 366 o The SDP 'tls-id' attribute, defined in this specification, is used 367 to identity the DTLS association. 369 This specification does not define the usage of the SDP 'connection' 370 attribute [RFC4145] for negotiating a DTLS association. However, the 371 attribute MAY be used if the DTLS association is used together with 372 another protocol (e.g., SCTP or TCP) for which the usage of the 373 attribute has been defined. 375 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 376 'setup' attribute 'holdconn' value when negotiating a DTLS 377 association. 379 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 381 Endpoints MUST support the hash functions as defined in [RFC8122]. 383 The certificate received during the DTLS handshake [RFC6347] MUST 384 match a certificate fingerprint received in SDP 'fingerprint' 385 attributes according to the procedures defined in [RFC8122]. If 386 fingerprints do not match the hashed certificate, then an endpoint 387 MUST tear down the media session immediately (see [RFC8122]). 389 SDP offerers and answerers might reuse certificates across multiple 390 DTLS associations, and provide identical fingerprint values for each 391 DTLS association. The combination of the SDP 'tls-id' attribute 392 values of the SDP offerer and answerer identifies each individual 393 DTLS association. 395 NOTE: There are cases where the SDP 'tls-id' attribute value 396 generated by the offerer will end up being used for multiple DTLS 397 associations. For that reason the combination of the attribute 398 values of the offerer and answerer is needed in order to identity a 399 DTLS association. An example of such case is where the offerer sends 400 an updated offer (Section 5.5), without modifying its attribute 401 value, but the answerer determines that a new DTLS association is to 402 be created. The answerer will generate a new local attribute value 403 for the new DTLS association (Section 5.3), while the offerer will 404 use the same attribute value that it used for the current 405 association. Another example is when the Session Initiation Protocol 406 (SIP) [RFC3261] is used for signalling, and an offer is forked to 407 multiple answerers. The attribute value generated by the offerer 408 will be used for DTLS associations established by each answerer. 410 5.2. Generating the Initial SDP Offer 412 When an offerer sends the initial offer, the offerer MUST insert an 413 SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, 414 and one or more SDP 'fingerprint' attributes according to the 415 procedures in [RFC8122]. In addition, the offerer MUST insert in the 416 offer an SDP 'tls-id' attribute with a unique attribute value. 418 As the offerer inserts the SDP 'setup' attribute with an 'actpass' 419 attribute value, the offerer MUST be prepared to receive a DTLS 420 ClientHello message [RFC6347] (if a new DTLS association is 421 established by the answerer) from the answerer before the offerer 422 receives the SDP answer. 424 If the offerer receives a DTLS ClientHello message, and a DTLS 425 association is established, before the offerer receives the SDP 426 Answer carrying the fingerprint associated with the DTLS association, 427 any data received on the DTLS association before the fingerprint MUST 428 be considered coming from an unverified source. The processing of 430 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 432 such data, and sending of data by the offerer to the unverified 433 source, is outside the scope of this document. 435 5.3. Generating the Answer 437 When an answerer sends an answer, the answerer MUST insert in the 438 answer an SDP 'setup' attribute according to the procedures in 439 [RFC4145], and one or more SDP 'fingerprint' attributes according to 440 the procedures in [RFC8122]. If the answerer determines, based on 441 the criteria specified in Section 3.1, that a new DTLS association is 442 to be established, the answerer MUST insert in the associated answer 443 an SDP 'tls-id' attribute with a new unique attribute value. Note 444 that the offerer and answerer generate their own local 'tls-id' 445 attribute values, and the combination of both values identify the 446 DTLS association. 448 If the answerer receives an offer that requires establishment of a 449 new DTLS association, and if the answerer does not accept the 450 establishment of a new DTLS association, the answerer MUST reject the 451 "m=" lines associated with the suggested DTLS association [RFC3264]. 453 If an answerer receives an offer that does not require the 454 establishment of a new DTLS association, and if the answerer 455 determines that a new DTLS association is not to be established, the 456 answerer MUST insert an SDP 'tls-id' attribute with the previously 457 assigned attribute value in the associated answer. In addition, the 458 answerer MUST insert an SDP 'setup' attribute with an attribute value 459 that does not change the previously negotiated DTLS roles, and one or 460 more SDP 'fingerprint' attributes values that do not change the 461 previously sent fingerprint set, in the associated answer. 463 If the answerer receives an offer that does not contain an SDP 'tls- 464 id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in 465 the answer. 467 If a new DTLS association is to be established, and if the answerer 468 inserts an SDP 'setup' attribute with an 'active' attribute value in 469 the answer, the answerer MUST initiate a DTLS handshake [RFC6347]) by 470 sending a DTLS ClientHello message towards the offerer. 472 Even though an offerer is required to insert an 'SDP' setup attribute 473 with an 'actpass' attribute value in initial offers (Section 5.2) and 474 subsequent offers (Section 5.5), the answerer MUST be able to receive 475 initial and subsequent offers with other attribute values, in order 476 to be backward compatible with older implementations that might 477 insert other attribute values in initial and subsequent offers. 479 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 481 5.4. Offerer Processing of the SDP Answer 483 When an offerer receives an answer that establishes a new DTLS 484 association based on criteria defined in Section 3.1, and if the 485 offerer becomes DTLS client (based on the value of the SDP 'setup' 486 attribute value [RFC4145]), the offerer MUST establish a DTLS 487 association. If the offerer becomes DTLS server, it MUST wait for 488 the answerer to establish the DTLS association. 490 If the offerer indicated a desire to reuse an existing DTLS 491 association and the answerer does not request the establishment of a 492 new DTLS association, the offerer will continue to use the previously 493 established DTLS association. 495 A new DTLS association can be established based on changes in either 496 an SDP offer or answer. When communicating with legacy endpoints, an 497 offerer can receive an answer that includes the same fingerprint set 498 and setup role. A new DTLS association will still be established if 499 such an answer was received as a response to an offer which requested 500 the establishment of a new DTLS association, as the transport 501 parameters would have been changed in the offer. 503 5.5. Modifying the Session 505 When an offerer sends a subsequent offer, and if the offerer wants to 506 establish a new DTLS association, the offerer MUST insert an SDP 507 'setup' attribute [RFC4145] with an 'actpass' attribute value, and 508 one or more SDP 'fingerprint' attributes according to the procedures 509 in [RFC8122]. In addition, the offerer MUST insert in the offer an 510 SDP 'tls-id' attribute with a new unique attribute value. 512 When an offerer sends a subsequent offer, and the offerer does not 513 want to establish a new DTLS association, and if a previously 514 established DTLS association exists, the offerer MUST insert an SDP 515 'setup' attribute with an 'actpass' attribute value, and one or more 516 SDP 'fingerprint' attributes with attribute values that do not change 517 the previously sent fingerprint set, in the offer. In addition, the 518 offerer MUST insert an SDP 'tls-id' attribute with the previously 519 assigned attribute value in the offer. 521 NOTE: When a new DTLS association is being established, each endpoint 522 needs to be prepared to receive data on both the new and old DTLS 523 associations as long as both are alive. 525 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 527 6. ICE Considerations 529 When the Interactive Connectivity Establishment (ICE) mechanism 530 [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are 531 performed before the DTLS handshake begins. Note that if aggressive 532 nomination mode is used, multiple candidate pairs may be marked valid 533 before ICE finally converges on a single candidate pair. 535 NOTE: Aggressive nomination has been deprecated from ICE, but must 536 still be supported for backwards compatibility reasons 537 [I-D.ietf-ice-rfc5245bis]. 539 When a new DTLS association is established over an unordered 540 transport, in order to disambiguate any packets associated with the 541 newly established DTLS association, at least one of the endpoints 542 MUST allocate a completely new set of ICE candidates which were not 543 recently used for any other DTLS association. This means the 544 answerer cannot initiate a new DTLS association unless the offerer 545 initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer 546 wants to initiate a new DTLS association, it needs to initiate an ICE 547 restart and a new offer/answer exchange on its own. However, an ICE 548 restart does not by default require a new DTLS association to be 549 established. 551 NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets 552 are sent directly over UDP, not over DTLS. [RFC7983] describes how 553 to demultiplex STUN packets from DTLS packets and SRTP packets. 555 Each ICE candidate associated with a component is treated as being 556 part of the same DTLS association. Therefore, from a DTLS 557 perspective it is not considered a change of local transport 558 parameters when an endpoint switches between those ICE candidates. 560 7. TLS Considerations 562 The procedures in this document can also be used for negotiating and 563 establishing a TLS connection, with the restriction described below. 565 As specified in [RFC4145], the SDP 'connection' attribute is used to 566 indicate whether to establish a new TLS connection. An offerer and 567 answerer MUST ensure that the 'connection' attribute value and the 568 'tls-id' attribute value does not cause a conflict regarding whether 569 a new TLS connection is to be established or not. 571 NOTE: Even though the SDP 'connection' attribute can be used to 572 indicate whether a new TLS connection is to be established, the 573 unique combination of SDP 'tls-id' attribute values can be used to 574 identity a TLS connection. The unique value can be used e.g., within 576 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 578 TLS protocol extensions to differentiate between multiple TLS 579 connections and correlate those connections with specific offer/ 580 answer exchanges. One such extension is defined in 581 [I-D.ietf-mmusic-sdp-uks]. 583 If an offerer or answerer inserts an SDP 'connection' attribute with 584 a 'new' value in the offer/answer and also inserts an SDP 'tls-id' 585 attribute, the value of tls-id' attribute MUST be new and unique. 587 If an offerer or answerer inserts an SDP 'connection' attribute with 588 a 'existing' value in the offer/answer, if a previously established 589 TLS connection exists, and if the offerer/answerer previously 590 inserted an SDP 'tls-id' attribute associated with the same TLS 591 connection in an offer/answer, the offerer/answerer MUST also insert 592 an SDP 'tls-id' attribute with the previously assigned value in the 593 offer/answer. 595 If an offerer or answerer receives an offer/answer with conflicting 596 attribute values, the offerer/answerer MUST process the offer/answer 597 as misformed. 599 An endpoint MUST NOT make assumptions regarding the support of the 600 SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, 601 both offerers and answerers MUST always use the 'connection' 602 attribute in conjunction with the 'tls-id' attribute. 604 NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is 605 not explicitly present, the implicit default value is 'new'. 607 The SDP example below is based on the example in section 3.4 of 608 [RFC8122], with the addition of the SDP 'tls-id' attribute. 610 m=image 54111 TCP/TLS t38 611 c=IN IP4 192.0.2.2 612 a=tls-id:abc3de65cddef001be82 613 a=setup:passive 614 a=connection:new 615 a=fingerprint:SHA-256 \ 616 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 617 3E:5D:49:6B:19:E5:7C:AB:4A:AD 618 a=fingerprint:SHA-1 \ 619 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 621 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 623 8. SIP Considerations 625 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 626 signal protocol for establishing a multimedia session, dialogs 627 [RFC3261] might be established between the caller and multiple 628 callees. This is referred to as forking. If forking occurs, 629 separate DTLS associations will be established between the caller and 630 each callee. 632 When forking occurs, an SDP offerer can receive DTLS ClientHello 633 messages and SDP answerers from multiple remote locations. Because 634 of this, the offerer might have to wait for multiple SDP answers 635 (from different remote locations) until it receives a certificate 636 fingerprint that matches the certificate associated with a specific 637 DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch 638 until it determines that it will not receive SDP answers from any 639 additional remote locations. 641 It is possible to send an INVITE request which does not contain an 642 SDP offer. Such an INVITE request is often referred to as an 'empty 643 INVITE', or an 'offer-less INVITE'. The receiving endpoint will 644 include the SDP offer in a response to the request. When the 645 endpoint generates such SDP offer, if a previously established DTLS 646 association exists, the offerer MUST insert an SDP 'tls-id' 647 attribute, and one or more SDP 'fingerprint' attributes, with 648 previously assigned attribute values. If a previously established 649 DTLS association did not exist, the offer MUST be generated based on 650 the same rules as a new offer (see Section 5.2). Regardless of the 651 previous existence of a DTLS association, the SDP 'setup' attribute 652 MUST be included according to the rules defined in [RFC4145]. 653 Furthermore, if ICE is used, according to the third party call 654 control considerations described in [I-D.ietf-mmusic-ice-sip-sdp], 655 ICE restart MUST be initiated. 657 9. RFC Updates 659 9.1. General 661 This section updates specifications that use DTLS-protected media, in 662 order to reflect the procedures defined in this specification. 664 9.2. Update to RFC 5763 666 9.2.1. Update to section 1 668 The reference to [RFC4572] is replaced with a reference to [RFC8122]. 670 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 672 9.2.2. Update to section 5 674 The text in section 5 (Establishing a Secure Channel) is modified by 675 replacing generic SDP offer/answer procedures for DTLS with a 676 reference to this specification: 678 NEW TEXT: 680 The two endpoints in the exchange present their identities as part of 681 the DTLS handshake procedure using certificates. This document uses 682 certificates in the same style as described in "Connection-Oriented 683 Media Transport over the Transport Layer Security (TLS) Protocol in 684 the Session Description Protocol (SDP)" [RFC8122]. 686 If self-signed certificates are used, the content of the 687 subjectAltName attribute inside the certificate MAY use the uniform 688 resource identifier (URI) of the user. This is useful for debugging 689 purposes only and is not required to bind the certificate to one of 690 the communication endpoints. The integrity of the certificate is 691 ensured through the fingerprint attribute in the SDP. 693 The generation of public/private key pairs is relatively expensive. 694 Endpoints are not required to generate certificates for each session. 696 The offer/answer model, defined in [RFC3264], is used by protocols 697 like the Session Initiation Protocol (SIP) [RFC3261] to set up 698 multimedia sessions. 700 When an endpoint wishes to set up a secure media session with another 701 endpoint, it sends an offer in a SIP message to the other endpoint. 702 This offer includes, as part of the SDP payload, a fingerprint of 703 a certificate that the endpoint wants to use. The endpoint SHOULD 704 send the SIP message containing the offer to the offerer's SIP proxy 705 over an integrity protected channel. The proxy SHOULD add an 706 Identity header field according to the procedures outlined in 707 [RFC4474]. When the far endpoint receives the SIP message, it can 708 verify the identity of the sender using the Identity header field. 709 Since the Identity header field is a digital signature across several 710 SIP header fields, in addition to the body of the SIP message, the 711 receiver can also be certain that the message has not been tampered 712 with after the digital signature was applied and added to the SIP 713 message. 715 The far endpoint (answerer) may now establish a DTLS association with 716 the offerer. Alternately, it can indicate in its answer that the 717 offerer is to initiate the DTLS association. In either case, mutual 718 DTLS certificate-based authentication will be used. After completing 720 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 722 the DTLS handshake, information about the authenticated identities, 723 including the certificates, are made available to the endpoint 724 application. The answerer is then able to verify that the offerer's 725 certificate used for authentication in the DTLS handshake can be 726 associated to a certificate fingerprint contained in the offer in 727 the SDP. At this point, the answerer may indicate to the end user 728 that the media is secured. The offerer may only tentatively accept 729 the answerer's certificate since it may not yet have the answerer's 730 certificate fingerprint. 732 When the answerer accepts the offer, it provides an answer back to 733 the offerer containing the answerer's certificate fingerprint. At 734 this point, the offerer can accept or reject the peer's certificate 735 and the offerer can indicate to the end user that the media is 736 secured. 738 Note that the entire authentication and key exchange for securing 739 the media traffic is handled in the media path through DTLS. The 740 signaling path is only used to verify the peers' certificate 741 fingerprints. 743 The offerer and answerer MUST follow the SDP offer/answer procedures 744 defined in [RFCXXXX]. 746 9.2.3. Update to section 6.6 748 The text in section 6.6 (Session Modification) is modified by 749 replacing generic SDP offer/answer procedures for DTLS with a 750 reference to this specification: 752 NEW TEXT: 754 Once an answer is provided to the offerer, either endpoint MAY 755 request a session modification that MAY include an updated offer. 756 This session modification can be carried in either an INVITE or 757 UPDATE request. The peers can reuse an existing DTLS association, 758 or establish a new one, following the procedures in [RFCXXXX]. 760 9.2.4. Update to section 6.7.1 762 The text in section 6.7.1 (ICE Interaction) is modified by replacing 763 the ICE procedures with a reference to this specification: 765 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 767 NEW TEXT: 769 The Interactive Connectivity Establishment (ICE) 770 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 771 are described in [RFCXXXX]. 773 9.3. Update to RFC 7345 775 9.3.1. Update to section 4 777 The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer 778 Procedures) are removed, and replaced with the new text below: 780 NEW TEXT: 782 An endpoint (i.e., both the offerer and the answerer) MUST create an 783 SDP media description ("m=" line) for each UDPTL-over-DTLS media 784 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 785 "proto" field of the "m=" line. 787 The offerer and answerer MUST follow the SDP offer/answer procedures 788 defined in [RFCXXXX] in order to negotiate the DTLS association 789 associated with the UDPTL-over-DTLS media stream. In addition, 790 the offerer and answerer MUST use the SDP attributes defined for 791 UDPTL over UDP, as defined in [ITU.T38.2010]. 793 9.3.2. Update to section 5.2.1 795 The text in section 5.2.1 (ICE Usage) is modified by replacing the 796 ICE procedures with a reference to this specification: 798 NEW TEXT: 800 The Interactive Connectivity Establishment (ICE) 801 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 802 are described in [RFCXXXX]. 804 [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX 805 with the RFC number of this document.] 807 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 809 9.3.3. Update to section 10.1 811 A reference to [RFC8122] is added to section 10.1 (Normative 812 References): 814 NEW TEXT: 816 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 817 Transport over the Transport Layer Security (TLS) Protocol 818 in the Session Description Protocol (SDP)", RFC 8122, 819 DOI 10.17487/RFC8122, March 2017, 820 . 822 10. Security Considerations 824 This specification does not modify the security considerations 825 associated with DTLS, or the SDP offer/answer mechanism. In addition 826 to the introduction of the SDP 'tls-id' attribute, the specification 827 simply clarifies the procedures for negotiating and establishing a 828 DTLS association. 830 This specification does not modify the actual TLS connection setup 831 procedures. The SDP 'tls-is' attribute as such cannot be used to 832 correlate an SDP Offer/Answer exchange with a TLS connection setup. 833 Thus, this draft does not introduce new security considerations 834 related to correlating an SDP Offer/Answer exchange with a TLS 835 connection setup. 837 11. IANA Considerations 839 This document updates the "Session Description Protocol Parameters" 840 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 841 it adds the SDP 'tls-id' attribute to the table for SDP media level 842 attributes. 844 Attribute name: tls-id 845 Type of attribute: media-level 846 Subject to charset: no 847 Purpose: Indicates whether a new DTLS association or TLS connection 848 is to be established/re-established. 849 Appropriate Values: see Section 4 850 Contact name: Christer Holmberg 851 Mux Category: IDENTICAL 853 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 855 12. Acknowledgements 857 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, 858 Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing 859 comments and suggestions on the document. Ben Campbell performed an 860 AD review. Paul Kyzivat performed a gen-art review. 862 13. Change Log 864 [RFC EDITOR NOTE: Please remove this section when publishing] 866 Changes from draft-ietf-mmusic-sdp-dtls-31 868 o Changes based on IESG comments from Eric R 870 Changes from draft-ietf-mmusic-sdp-dtls-30 872 o Changes based on IESG comments from Mirja K 874 Changes from draft-ietf-mmusic-sdp-dtls-29 876 o Removal of ufrag value change as a trigger for a new DTLS 877 association 879 Changes from draft-ietf-mmusic-sdp-dtls-28 881 o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey 882 Melnikov and Mirja Kuhlewind: 884 o - Document title changed 886 o - Transport Protocol Considerations section removed 888 o - Additional text to Security Considerations section 890 o - Editorial changes 892 Changes from draft-ietf-mmusic-sdp-dtls-27 894 o Reference fixes based on Gen-ART review by Paul Kyzivat. 896 Changes from draft-ietf-mmusic-sdp-dtls-26 898 o Editorial fixes based on Gen-ART review by Paul Kyzivat. 900 Changes from draft-ietf-mmusic-sdp-dtls-25 902 o Minor editorial nits. 904 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 906 Changes from draft-ietf-mmusic-sdp-dtls-24 908 o Changes based on 2nd WGLC comments from Roman S and Martin T: 910 o - RFC update structure shortened (old text removed). 912 o - Guidance regarding receiving ClientHello before SDP answer 913 added. 915 o - Additional SIP considerations regarding forking. 917 o - SDP setup attribute value restriction in initial and subsequent 918 offers based on comment from Ekr. 920 Changes from draft-ietf-mmusic-sdp-dtls-23 922 o Editorial change to make it clear that the document does not 923 modify the procedures in RFC 8122. 925 Changes from draft-ietf-mmusic-sdp-dtls-22 927 o Support for TLS added. 929 o Editorial changes based on sec-dir review by Rich Salz. 931 o Editorial changes based on gen-art review by Paul Kyzivat. 933 o Editorial changes based on ops-dir review by Carlos Pignataro. 935 Changes from draft-ietf-mmusic-sdp-dtls-21 937 o Changes based on AD review by Ben Campbell. 939 o (https://www.ietf.org/mail-archive/web/mmusic/current/ 940 msg17707.html) 942 Changes from draft-ietf-mmusic-sdp-dtls-20 944 o Change to length and randomness of tls-id attribute value. 946 Changes from draft-ietf-mmusic-sdp-dtls-19 948 o Change based on comment from Roman. 950 Changes from draft-ietf-mmusic-sdp-dtls-18 952 o Changes based on comments from Flemming. 954 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 956 o - Change in tls-id value definition. 958 o - Editorial fixes. 960 Changes from draft-ietf-mmusic-sdp-dtls-17 962 o Reference fix. 964 Changes from draft-ietf-mmusic-sdp-dtls-16 966 o Editorial changes based on 2nd WGLC comments from Christian Groves 967 and Nevenka Biondic. 969 Changes from draft-ietf-mmusic-sdp-dtls-15 971 o tls-id attribute value made globally unique 973 Changes from draft-ietf-mmusic-sdp-dtls-14 975 o Changes based on comments from Flemming: 977 o - Additional dtls-is clarifications 979 o - Editorial fixes 981 Changes from draft-ietf-mmusic-sdp-dtls-13 983 o Text about the updated RFCs added to Abstract and Introduction 985 o Reference to RFC 5763 removed from section 6 (ICE Considerations) 987 o Reference to RFC 5763 removed from section 8 (SIP Considerations) 989 Changes from draft-ietf-mmusic-sdp-dtls-12 991 o "unreliable" changed to "unordered" 993 Changes from draft-ietf-mmusic-sdp-dtls-11 995 o Attribute name changed to tls-id 997 o Additional text based on comments from Roman Shpount. 999 Changes from draft-ietf-mmusic-sdp-dtls-10 1001 o Modified document to use tls-id instead of dtls-connection 1003 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 1005 o Changes are based on comments from Eric Rescorla, Justin Uberti, 1006 and Paul Kyzivat. 1008 Changes from draft-ietf-mmusic-sdp-dtls-08 1010 o Offer/Answer section modified in order to allow sending of 1011 multiple SDP 'fingerprint' attributes. 1013 o Terminology made consistent: 'DTLS connection' replaced with 'DTLS 1014 association'. 1016 o Editorial changes based on comments from Paul Kyzivat. 1018 Changes from draft-ietf-mmusic-sdp-dtls-07 1020 o Reference to RFC 7315 replaced with reference to RFC 7345. 1022 Changes from draft-ietf-mmusic-sdp-dtls-06 1024 o Text on restrictions regarding spanning a DTLS association over 1025 multiple transports added. 1027 o Mux category added to IANA Considerations. 1029 o Normative text regarding mux category and source-specific 1030 applicability added. 1032 o Reference to RFC 7315 added. 1034 o Clarified that offerer/answerer that has not been updated to 1035 support this specification will not include the tls-id attribute 1036 in offers and answers. 1038 o Editorial corrections based on WGLC comments from Charles Eckel. 1040 Changes from draft-ietf-mmusic-sdp-dtls-05 1042 o Text on handling offer/answer error conditions added. 1044 Changes from draft-ietf-mmusic-sdp-dtls-04 1046 o Editorial nits fixed based on comments from Paul Kyzivat: 1048 Changes from draft-ietf-mmusic-sdp-dtls-03 1050 o Changes based on comments from Paul Kyzivat: 1052 o - Modification of tls-id attribute section. 1054 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 1056 o - Removal of IANA considerations subsection. 1058 o - Making note into normative text in o/a section. 1060 o Changes based on comments from Martin Thompson: 1062 o - Abbreviations section removed. 1064 o - Clarify that a new DTLS association requires a new o/a 1065 transaction. 1067 Changes from draft-ietf-mmusic-sdp-dtls-02 1069 o - Updated RFCs added to boilerplate. 1071 Changes from draft-ietf-mmusic-sdp-dtls-01 1073 o - Annex regarding 'tls-id-id' attribute removed. 1075 o - Additional SDP offer/answer procedures, related to certificates, 1076 added. 1078 o - Updates to RFC 5763 and RFC 7345 added. 1080 o - Transport protocol considerations added. 1082 Changes from draft-ietf-mmusic-sdp-dtls-00 1084 o - SDP 'connection' attribute replaced with new 'tls-id' attribute. 1086 o - IANA Considerations added. 1088 o - E-mail regarding 'tls-id-id' attribute added as Annex. 1090 Changes from draft-holmberg-mmusic-sdp-dtls-01 1092 o - draft-ietf-mmusic version of draft submitted. 1094 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 1095 with another expired draft. 1097 o - Clarify that if ufrag in offer is unchanged, it must be 1098 unchanged in associated answer. 1100 o - SIP Considerations section added. 1102 o - Section about multiple SDP fingerprint attributes added. 1104 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 1106 Changes from draft-holmberg-mmusic-sdp-dtls-00 1108 o - Editorial changes and clarifications. 1110 14. References 1112 14.1. Normative References 1114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1115 Requirement Levels", BCP 14, RFC 2119, 1116 DOI 10.17487/RFC2119, March 1997, 1117 . 1119 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1120 A., Peterson, J., Sparks, R., Handley, M., and E. 1121 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1122 DOI 10.17487/RFC3261, June 2002, 1123 . 1125 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1126 with Session Description Protocol (SDP)", RFC 3264, 1127 DOI 10.17487/RFC3264, June 2002, 1128 . 1130 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1131 the Session Description Protocol (SDP)", RFC 4145, 1132 DOI 10.17487/RFC4145, September 2005, 1133 . 1135 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1136 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1137 July 2006, . 1139 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1140 for Establishing a Secure Real-time Transport Protocol 1141 (SRTP) Security Context Using Datagram Transport Layer 1142 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1143 2010, . 1145 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1146 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1147 January 2012, . 1149 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 1150 Transport Layer (UDPTL) over Datagram Transport Layer 1151 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 1152 2014, . 1154 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 1156 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 1157 Transport over the Transport Layer Security (TLS) Protocol 1158 in the Session Description Protocol (SDP)", RFC 8122, 1159 DOI 10.17487/RFC8122, March 2017, 1160 . 1162 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1163 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1164 May 2017, . 1166 [I-D.ietf-ice-rfc5245bis] 1167 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1168 Connectivity Establishment (ICE): A Protocol for Network 1169 Address Translator (NAT) Traversal", draft-ietf-ice- 1170 rfc5245bis-13 (work in progress), October 2017. 1172 [I-D.ietf-mmusic-sdp-mux-attributes] 1173 Nandakumar, S., "A Framework for SDP Attributes when 1174 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1175 (work in progress), December 2016. 1177 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1178 Holmberg, C., Alvestrand, H., and C. Jennings, 1179 "Negotiating Media Multiplexing Using the Session 1180 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1181 negotiation-39 (work in progress), August 2017. 1183 14.2. Informative References 1185 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1186 Authenticated Identity Management in the Session 1187 Initiation Protocol (SIP)", RFC 4474, 1188 DOI 10.17487/RFC4474, August 2006, 1189 . 1191 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1192 Transport Layer Security (TLS) Protocol in the Session 1193 Description Protocol (SDP)", RFC 4572, 1194 DOI 10.17487/RFC4572, July 2006, 1195 . 1197 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1198 Media Attributes in the Session Description Protocol 1199 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1200 . 1202 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 1204 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1205 Transport Layer Security (DTLS) for Stream Control 1206 Transmission Protocol (SCTP)", RFC 6083, 1207 DOI 10.17487/RFC6083, January 2011, 1208 . 1210 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1211 Updates for Secure Real-time Transport Protocol (SRTP) 1212 Extension for Datagram Transport Layer Security (DTLS)", 1213 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1214 . 1216 [I-D.ietf-stir-rfc4474bis] 1217 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1218 "Authenticated Identity Management in the Session 1219 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 1220 (work in progress), February 2017. 1222 [I-D.ietf-mmusic-ice-sip-sdp] 1223 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 1224 "Session Description Protocol (SDP) Offer/Answer 1225 procedures for Interactive Connectivity Establishment 1226 (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in 1227 progress), October 2017. 1229 [I-D.ietf-mmusic-sdp-uks] 1230 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 1231 uses of Transport Layer Security with the Session 1232 Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00 1233 (work in progress), August 2017. 1235 [ITU.T38.2010] 1236 International Telecommunications Union, "Procedures for 1237 real-time Group 3 facsimile communication over IP 1238 networks", ITU-T Recommendation T.38, September 2010. 1240 Authors' Addresses 1242 Christer Holmberg 1243 Ericsson 1244 Hirsalantie 11 1245 Jorvas 02420 1246 Finland 1248 Email: christer.holmberg@ericsson.com 1250 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 1252 Roman Shpount 1253 TurboBridge 1254 4905 Del Ray Avenue, Suite 300 1255 Bethesda, MD 20814 1256 USA 1258 Phone: +1 (240) 292-6632 1259 Email: rshpount@turbobridge.com