idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-29.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 (August 31, 2017) is 2402 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 800, 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-10 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-13 == 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: March 4, 2018 August 31, 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-29.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 http://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 March 4, 2018. 47 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 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 (http://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/Answer August 2017 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 23 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/Answer August 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/Answer August 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 prohibits a DTLS association from 209 spanning multiple transports, and if the transport is changed, the 210 endpoint must change its local SDP 'tls-id' attribute value (see 211 Section 4). An example of such a case is when DTLS is carried over 212 the Stream Control Transmission Protocol (SCTP), as described in 213 [RFC6083]. 215 3.3. Change of ICE ufrag value 217 If an endpoint uses ICE, and modifies a local ufrag value, and if the 218 modification requires a new DTLS association, the endpoint MUST 219 change its local SDP 'tls-id' attribute value (see Section 4). 221 4. SDP tls-id Attribute 223 The pair of SDP 'tls-id' attribute values (the attribute values of 224 the offerer and the answerer) uniquely identifies the DTLS 225 association or TLS connection. 227 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 229 Name: tls-id 231 Value: tls-id-value 233 Usage Level: media 235 Charset Dependent: no 237 Default Value: N/A 239 Syntax: 241 tls-id-value = 20*255(tls-id-char) 242 tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" 244 246 Example: 248 a=tls-id:abc3de65cddef001be82 250 Every time an endpoint requests to establish a new DTLS association, 251 the endpoint MUST generate a new local 'tls-id' attribute value. A 252 non-changed local 'tls-id' attribute value, in combination with non- 253 changed fingerprints, indicates that the endpoint intends to reuse 254 the existing DTLS association. 256 The 'tls-id' attribute value MUST be generated using a strong random 257 function and include at least 120 bits of randomness. 259 No default value is defined for the SDP 'tls-id' attribute. 260 Implementations that wish to use the attribute MUST explicitly 261 include it in SDP offers and answers. If an offer or answer does not 262 contain a 'tls-id' attribute (this could happen if the offerer or 263 answerer represents an existing implementation that has not been 264 updated to support the 'tls-id' attribute), unless there is another 265 mechanism to explicitly indicate that a new DTLS association is to be 266 established, a modification of one or more of the following 267 characteristics MUST be treated as an indication that an endpoint 268 wants to establish a new DTLS association: 270 o DTLS setup role; or 272 o fingerprint set; or 274 o local transport parameters; or 276 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 278 o ICE ufrag value 280 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- 281 id' attribute is 'IDENTICAL', which means that the attribute value 282 applies to all media descriptions being multiplexed 283 [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in 284 [I-D.ietf-mmusic-sdp-bundle-negotiation], in order to avoid 285 duplication the attribute is only associated with the "m=" line 286 representing the offerer/answerer BUNDLE-tag. 288 For RTP-based media, the 'tls-id' attribute applies to the whole 289 associated media description. The attribute MUST NOT be defined per 290 source (using the SDP 'ssrc' attribute [RFC5576]). 292 The SDP offer/answer [RFC3264] procedures associated with the 293 attribute are defined in Section 5. 295 5. SDP Offer/Answer Procedures 297 5.1. General 299 This section defines the generic SDP offer/answer procedures for 300 negotiating a DTLS association. Additional procedures (e.g., 301 regarding usage of specific SDP attributes etc.) for individual DTLS 302 usages (e.g., DTLS-SRTP) are outside the scope of this specification, 303 and need to be specified in a usage specific specification. 305 NOTE: The procedures in this section are generalizations of 306 procedures first specified in DTLS-SRTP [RFC5763], with the addition 307 of usage of the SDP 'tls-id' attribute. That document is herein 308 updated to make use of these new procedures. 310 The procedures in this section apply to an SDP media description 311 ("m=" line) associated with DTLS-protected media/data. 313 When an offerer or answerer indicates that it wants to establish a 314 new DTLS association, it needs to make sure that media packets 315 associated with any previously established DTLS association and the 316 new DTLS association can be de-multiplexed. In case of an ordered 317 transport (e.g., SCTP) this can be done simply by sending packets for 318 the new DTLS association after all packets associated with a 319 previously established DTLS association has been sent. In case of an 320 unordered transport, such as UDP, packets associated with a 321 previously established DTLS association can arrive after the answer 322 SDP was received and after the first packets associated with the new 323 DTLS association were received. The only way to de-multiplex packets 324 associated with with a previously established DTLS association and 325 the new DTLS association is on the basis of transport 5-tuple. 327 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 329 Because of this, if an unordered transport is used for the DTLS 330 association, a new transport (3-tuple) must be allocated by at least 331 one of the endpoints so that DTLS packets can be de-multiplexed. 333 When an offerer needs to establish a new DTLS association, and if an 334 unordered transport (e.g., UDP) is used, the offerer MUST allocate a 335 new transport (3-tuple) for the offer in such a way that the offerer 336 can disambiguate any packets associated with the new DTLS association 337 from any packets associated with any other DTLS association. This 338 typically means using a local address and/or port, or a set of ICE 339 candidates (see Section 6), which were not recently used for any 340 other DTLS association. 342 When an answerer needs to establish a new DTLS association, if an 343 unordered transport is used, and if the offerer did not allocate a 344 new transport, the answerer MUST allocate a new transport for the 345 answer in such a way that it can disambiguate any packets associated 346 with the new DTLS association from any packets associated with any 347 other DTLS association. This typically means using a local address 348 and/or port, or a set of ICE candidates (see Section 6), which were 349 not recently used for any other DTLS association. 351 In order to negotiate a DTLS association, the following SDP 352 attributes are used: 354 o The SDP 'setup' attribute, defined in [RFC4145], is used to 355 negotiate the DTLS roles; 357 o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to 358 provide one or more fingerprint values; and 360 o The SDP 'tls-id' attribute, defined in this specification, is used 361 to identity the DTLS association. 363 This specification does not define the usage of the SDP 'connection' 364 attribute [RFC4145] for negotiating a DTLS association. However, the 365 attribute MAY be used if the DTLS association is used together with 366 another protocol (e.g., SCTP or TCP) for which the usage of the 367 attribute has been defined. 369 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 370 'setup' attribute 'holdconn' value when negotiating a DTLS 371 association. 373 Endpoints MUST support the hash functions as defined in [RFC8122]. 375 The certificate received during the DTLS handshake [RFC6347] MUST 376 match a certificate fingerprint received in SDP 'fingerprint' 378 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 380 attributes according to the procedures defined in [RFC8122]. If 381 fingerprints do not match the hashed certificate, then an endpoint 382 MUST tear down the media session immediately (see [RFC8122]). Note 383 that it is permissible to wait until the other side's fingerprint(s) 384 has been received before establishing the connection; however, this 385 may have undesirable latency effects. 387 SDP offerers and answerers might reuse certificates across multiple 388 DTLS associations, and provide identical fingerprint values for each 389 DTLS association. The combination of the SDP 'tls-id' attribute 390 values of the SDP offerer and answerer identifies each individual 391 DTLS association. 393 NOTE: There are cases where the SDP 'tls-id' attribute value 394 generated by the offerer will end up being used for multiple DTLS 395 associations. For that reason the combination of the attribute 396 values of the offerer and answerer is needed in order to identity a 397 DTLS association. An example of such case is where the offerer sends 398 an updated offer (Section 5.5), without modifying its attribute 399 value, but the answerer determines that a new DTLS association is to 400 be created. The answerer will generate a new local attribute value 401 for the new DTLS association (Section 5.3), while the offerer will 402 use the same attribute value that it used for the current 403 association. Another example is when the Session Initiation Protocol 404 (SIP) [RFC3261] is used for signalling, and an offer is forked to 405 multiple answerers. The attribute value generated by the offerer 406 will be used for DTLS associations established by each answerer. 408 5.2. Generating the Initial SDP Offer 410 When an offerer sends the initial offer, the offerer MUST insert an 411 SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, 412 and one or more SDP 'fingerprint' attributes according to the 413 procedures in [RFC8122]. In addition, the offerer MUST insert in the 414 offer an SDP 'tls-id' attribute with a unique attribute value. 416 As the offerer inserts the SDP 'setup' attribute with an 'actpass' 417 attribute value, the offerer MUST be prepared to receive a DTLS 418 ClientHello message [RFC6347] (if a new DTLS association is 419 established by the answerer) from the answerer before the offerer 420 receives the SDP answer. 422 If the offerer receives a DTLS ClientHello message, and a DTLS 423 association is established, before the offerer receives the SDP 424 Answer carrying the fingerprint associated with the DTLS association, 425 any data received on the DTLS association before the fingerprint MUST 426 be considered coming from an unverified source. The processing of 428 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 430 such data, and sending of data by the offerer to the unverified 431 source, is outside the scope of this document. 433 5.3. Generating the Answer 435 When an answerer sends an answer, the answerer MUST insert in the 436 answer an SDP 'setup' attribute according to the procedures in 437 [RFC4145], and one or more SDP 'fingerprint' attributes according to 438 the procedures in [RFC8122]. If the answerer determines, based on 439 the criteria specified in Section 3.1, that a new DTLS association is 440 to be established, the answerer MUST insert in the associated answer 441 an SDP 'tls-id' attribute with a new unique attribute value. Note 442 that the offerer and answerer generate their own local 'tls-id' 443 attribute values, and the combination of both values identify the 444 DTLS association. 446 If the answerer receives an offer that requires establishment of a 447 new DTLS association, and if the answerer does not accept the 448 establishment of a new DTLS association, the answerer MUST reject the 449 "m=" lines associated with the suggested DTLS association [RFC3264]. 451 If an answerer receives an offer that does not require the 452 establishment of a new DTLS association, and if the answerer 453 determines that a new DTLS association is not to be established, the 454 answerer MUST insert an SDP 'tls-id' attribute with the previously 455 assigned attribute value in the associated answer. In addition, the 456 answerer MUST insert an SDP 'setup' attribute with an attribute value 457 that does not change the previously negotiated DTLS roles, and one or 458 more SDP 'fingerprint' attributes values that do not change the 459 previously sent fingerprint set, in the associated answer. 461 If the answerer receives an offer that does not contain an SDP 'tls- 462 id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in 463 the answer. 465 If a new DTLS association is to be established, and if the answerer 466 inserts an SDP 'setup' attribute with an 'active' attribute value in 467 the answer, the answerer MUST initiate a DTLS handshake by sending a 468 DTLS ClientHello message towards the offerer. 470 Even though an offerer is required to insert an 'SDP' setup attribute 471 with an 'actpass' attribute value in initial offers (Section 5.2) and 472 subsequent offers (Section 5.5), the answerer MUST be able to receive 473 initial and subsequent offers with other attribute values, in order 474 to be backward compatible with older implementations that might 475 insert other attribute values in initial and subsequent offers. 477 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 479 5.4. Offerer Processing of the SDP Answer 481 When an offerer receives an answer that establishes a new DTLS 482 association based on criteria defined in Section 3.1, and if the 483 offerer becomes DTLS client (based on the value of the SDP 'setup' 484 attribute value [RFC4145]), the offerer MUST establish a DTLS 485 association. If the offerer becomes DTLS server, it MUST wait for 486 the answerer to establish the DTLS association. 488 If the offerer indicated a desire to reuse an existing DTLS 489 association and the answerer does not request the establishment of a 490 new DTLS association, the offerer will continue to use the previously 491 established DTLS association. 493 A new DTLS association can be established based on changes in either 494 an SDP offer or answer. When communicating with legacy endpoints, an 495 offerer can receive an answer that includes the same fingerprint set 496 and setup role. A new DTLS association will still be established if 497 such an answer was received as a response to an offer which requested 498 the establishment of a new DTLS association, as the transport 499 parameters would have been changed in the offer. 501 5.5. Modifying the Session 503 When an offerer sends a subsequent offer, and if the offerer wants to 504 establish a new DTLS association, the offerer MUST insert an SDP 505 'setup' attribute [RFC4145] with an 'actpass' attribute value, and 506 one or more SDP 'fingerprint' attributes according to the procedures 507 in [RFC8122]. In addition, the offerer MUST insert in the offer an 508 SDP 'tls-id' attribute with a new unique attribute value. 510 When an offerer sends a subsequent offer, and the offerer does not 511 want to establish a new DTLS association, and if a previously 512 established DTLS association exists, the offerer MUST insert an SDP 513 'setup' attribute with an 'actpass' attribute value, and one or more 514 SDP 'fingerprint' attributes with attribute values that do not change 515 the previously sent fingerprint set, in the offer. In addition, the 516 offerer MUST insert an SDP 'tls-id' attribute with the previously 517 assigned attribute value in the offer. 519 NOTE: When a new DTLS association is being established, each endpoint 520 needs to be prepared to receive data on both the new and old DTLS 521 associations as long as both are alive. 523 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 525 6. ICE Considerations 527 When the Interactive Connectivity Establishment (ICE) mechanism 528 [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are 529 performed before the DTLS handshake begins. Note that if aggressive 530 nomination mode is used, multiple candidate pairs may be marked valid 531 before ICE finally converges on a single candidate pair. 533 NOTE: Aggressive nomination has been deprecated from ICE, but must 534 still be supported for backwards compatibility reasons 535 [I-D.ietf-ice-rfc5245bis]. 537 When a new DTLS association is established over an unordered 538 transport, in order to disambiguate any packets associated with the 539 newly established DTLS association, at least one of the endpoints 540 MUST allocate a completely new set of ICE candidates which were not 541 recently used for any other DTLS association. This means the 542 answerer cannot initiate a new DTLS association unless the offerer 543 initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer 544 wants to initiate a new DTLS association, it needs to initiate an ICE 545 restart and a new offer/answer exchange on its own. However, an ICE 546 restart does not by default require a new DTLS association to be 547 established. 549 NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets 550 are sent directly over UDP, not over DTLS. [RFC7983] describes how 551 to demultiplex STUN packets from DTLS packets and SRTP packets. 553 Each ICE candidate associated with a component is treated as being 554 part of the same DTLS association. Therefore, from a DTLS 555 perspective it is not considered a change of local transport 556 parameters when an endpoint switches between those ICE candidates. 558 7. TLS Considerations 560 The procedures in this document can also be used for negotiating and 561 establishing a TLS connection, with the restriction described below. 563 As specified in [RFC4145], the SDP 'connection' attribute is used to 564 indicate whether to establish a new TLS connection. An offerer and 565 answerer MUST ensure that the 'connection' attribute value and the 566 'tls-id' attribute value does not cause a conflict regarding whether 567 a new TLS connection is to be established or not. 569 NOTE: Even though the SDP 'connection' attribute can be used to 570 indicate whether a new TLS connection is to be established, the 571 unique combination of SDP 'tls-id' attribute values can be used to 572 identity a TLS connection. The unique value can be used e.g., within 574 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 576 TLS protocol extensions to differentiate between multiple TLS 577 connections and correlate those connections with specific offer/ 578 answer exchanges. One such extension is defined in 579 [I-D.ietf-mmusic-sdp-uks]. 581 If an offerer or answerer inserts an SDP 'connection' attribute with 582 a 'new' value in the offer/answer and also inserts an SDP 'tls-id' 583 attribute, the value of tls-id' attribute MUST be new and unique. 585 If an offerer or answerer inserts an SDP 'connection' attribute with 586 a 'existing' value in the offer/answer, if a previously established 587 TLS connection exists, and if the offerer/answerer previously 588 inserted an SDP 'tls-id' attribute associated with the same TLS 589 connection in an offer/answer, the offerer/answerer MUST also insert 590 an SDP 'tls-id' attribute with the previously assigned value in the 591 offer/answer. 593 If an offerer or answerer receives an offer/answer with conflicting 594 attribute values, the offerer/answerer MUST process the offer/answer 595 as misformed. 597 An endpoint must not make assumptions regarding the support of the 598 SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, 599 both offerers and answerers MUST always use the 'connection' 600 attribute in conjunction with the 'tls-id' attribute. 602 NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is 603 not explicitly present, the implicit default value is 'new'. 605 The SDP example below is based on the example in section 3.4 of 606 [RFC8122], with the addition of the SDP 'tls-id' attribute. 608 m=image 54111 TCP/TLS t38 609 c=IN IP4 192.0.2.2 610 a=tls-id:abc3de65cddef001be82 611 a=setup:passive 612 a=connection:new 613 a=fingerprint:SHA-256 \ 614 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 615 3E:5D:49:6B:19:E5:7C:AB:4A:AD 616 a=fingerprint:SHA-1 \ 617 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 619 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 621 8. SIP Considerations 623 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 624 signal protocol for establishing a multimedia session, dialogs 625 [RFC3261] might be established between the caller and multiple 626 callees. This is referred to as forking. If forking occurs, 627 separate DTLS associations will be established between the caller and 628 each callee. 630 When forking occurs, an SDP offerer can receive DTLS ClientHello 631 messages and SDP answerers from multiple remote locations. Because 632 of this, the offerer might have to wait for multiple SDP answers 633 (from different remote locations) until it receives a certificate 634 fingerprint that matches the certificate associated with a specific 635 DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch 636 until it determines that it will not receive SDP answers from any 637 additional remote locations. 639 It is possible to send an INVITE request which does not contain an 640 SDP offer. Such an INVITE request is often referred to as an 'empty 641 INVITE', or an 'offer-less INVITE'. The receiving endpoint will 642 include the SDP offer in a response to the request. When the 643 endpoint generates such SDP offer, if a previously established DTLS 644 association exists, the offerer MUST insert an SDP 'tls-id' 645 attribute, and one or more SDP 'fingerprint' attributes, with 646 previously assigned attribute values. If a previously established 647 DTLS association did not exist, the offer MUST be generated based on 648 the same rules as a new offer (see Section 5.2). Regardless of the 649 previous existence of a DTLS association, the SDP 'setup' attribute 650 MUST be included according to the rules defined in [RFC4145] and if 651 ICE is used, ICE restart MUST be initiated. This is needed in order 652 to support third party call control, as described in 653 [I-D.ietf-mmusic-ice-sip-sdp]. 655 9. RFC Updates 657 9.1. General 659 This section updates specifications that use DTLS-protected media, in 660 order to reflect the procedures defined in this specification. 662 9.2. Update to RFC 5763 664 9.2.1. Update to section 1 666 The reference to [RFC4572] is replaced with a reference to [RFC8122]. 668 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 670 9.2.2. Update to section 5 672 The text in section 5 (Establishing a Secure Channel) is modified by 673 replacing generic SDP offer/answer procedures for DTLS with a 674 reference to this specification: 676 NEW TEXT: 678 The two endpoints in the exchange present their identities as part of 679 the DTLS handshake procedure using certificates. This document uses 680 certificates in the same style as described in "Connection-Oriented 681 Media Transport over the Transport Layer Security (TLS) Protocol in 682 the Session Description Protocol (SDP)" [RFC8122]. 684 If self-signed certificates are used, the content of the 685 subjectAltName attribute inside the certificate MAY use the uniform 686 resource identifier (URI) of the user. This is useful for debugging 687 purposes only and is not required to bind the certificate to one of 688 the communication endpoints. The integrity of the certificate is 689 ensured through the fingerprint attribute in the SDP. 691 The generation of public/private key pairs is relatively expensive. 692 Endpoints are not required to generate certificates for each session. 694 The offer/answer model, defined in [RFC3264], is used by protocols 695 like the Session Initiation Protocol (SIP) [RFC3261] to set up 696 multimedia sessions. 698 When an endpoint wishes to set up a secure media session with another 699 endpoint, it sends an offer in a SIP message to the other endpoint. 700 This offer includes, as part of the SDP payload, a fingerprint of 701 a certificate that the endpoint wants to use. The endpoint SHOULD 702 send the SIP message containing the offer to the offerer's SIP proxy 703 over an integrity protected channel. The proxy SHOULD add an 704 Identity header field according to the procedures outlined in 705 [RFC4474]. When the far endpoint receives the SIP message, it can 706 verify the identity of the sender using the Identity header field. 707 Since the Identity header field is a digital signature across several 708 SIP header fields, in addition to the body of the SIP message, the 709 receiver can also be certain that the message has not been tampered 710 with after the digital signature was applied and added to the SIP 711 message. 713 The far endpoint (answerer) may now establish a DTLS association with 714 the offerer. Alternately, it can indicate in its answer that the 715 offerer is to initiate the DTLS association. In either case, mutual 716 DTLS certificate-based authentication will be used. After completing 718 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 720 the DTLS handshake, information about the authenticated identities, 721 including the certificates, are made available to the endpoint 722 application. The answerer is then able to verify that the offerer's 723 certificate used for authentication in the DTLS handshake can be 724 associated to a certificate fingerprint contained in the offer in 725 the SDP. At this point, the answerer may indicate to the end user 726 that the media is secured. The offerer may only tentatively accept 727 the answerer's certificate since it may not yet have the answerer's 728 certificate fingerprint. 730 When the answerer accepts the offer, it provides an answer back to 731 the offerer containing the answerer's certificate fingerprint. At 732 this point, the offerer can accept or reject the peer's certificate 733 and the offerer can indicate to the end user that the media is 734 secured. 736 Note that the entire authentication and key exchange for securing 737 the media traffic is handled in the media path through DTLS. The 738 signaling path is only used to verify the peers' certificate 739 fingerprints. 741 The offerer and answerer MUST follow the SDP offer/answer procedures 742 defined in [RFCXXXX]. 744 9.2.3. Update to section 6.6 746 The text in section 6.6 (Session Modification) is modified by 747 replacing replacing generic SDP offer/answer procedures for DTLS with 748 a reference to this specification: 750 NEW TEXT: 752 Once an answer is provided to the offerer, either endpoint MAY 753 request a session modification that MAY include an updated offer. 754 This session modification can be carried in either an INVITE or 755 UPDATE request. The peers can reuse an existing DTLS association, 756 or establish a new one, following the procedures in [RFCXXXX]. 758 9.2.4. Update to section 6.7.1 760 The text in section 6.7.1 (ICE Interaction) is modified by replacing 761 the ICE procedures with a reference to this specification: 763 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 765 NEW TEXT: 767 The Interactive Connectivity Establishment (ICE) 768 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 769 are described in [RFCXXXX]. 771 9.3. Update to RFC 7345 773 9.3.1. Update to section 4 775 The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer 776 Procedures) are removed, and replaced with the new text below: 778 NEW TEXT: 780 An endpoint (i.e., both the offerer and the answerer) MUST create an 781 SDP media description ("m=" line) for each UDPTL-over-DTLS media 782 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 783 "proto" field of the "m=" line. 785 The offerer and answerer MUST follow the SDP offer/answer procedures 786 defined in [RFCXXXX] in order to negotiate the DTLS association 787 associated with the UDPTL-over-DTLS media stream. In addition, 788 the offerer and answerer MUST use the SDP attributes defined for 789 UDPTL over UDP, as defined in [ITU.T38.2010]. 791 9.3.2. Update to section 5.2.1 793 The text in section 5.2.1 (ICE Usage) is modified by replacing the 794 ICE procedures with a reference to this specification: 796 NEW TEXT: 798 The Interactive Connectivity Establishment (ICE) 799 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 800 are described in [RFCXXXX]. 802 [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX 803 with the RFC number of this document.] 805 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 807 9.3.3. Update to section 10.1 809 A reference to [RFC8122] is added to section 10.1 (Normative 810 References): 812 NEW TEXT: 814 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 815 Transport over the Transport Layer Security (TLS) Protocol 816 in the Session Description Protocol (SDP)", RFC 8122, 817 DOI 10.17487/RFC8122, March 2017, 818 . 820 10. Security Considerations 822 This specification does not modify the security considerations 823 associated with DTLS, or the SDP offer/answer mechanism. In addition 824 to the introduction of the SDP 'tls-id' attribute, the specification 825 simply clarifies the procedures for negotiating and establishing a 826 DTLS association. 828 This specification does not modify the actual TLS connection setup 829 procedures. The SDP 'tls-is' attribute as such cannot be used to 830 correlate an SDP Offer/Answer exchange with a TLS connection setup. 831 Thus, this draft does not introduce new security considerations 832 related to correlating an SDP Offer/Answer exchange with a TLS 833 connection setup. 835 11. IANA Considerations 837 This document updates the "Session Description Protocol Parameters" 838 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 839 it adds the SDP 'tls-id' attribute to the table for SDP media level 840 attributes. 842 Attribute name: tls-id 843 Type of attribute: media-level 844 Subject to charset: no 845 Purpose: Indicates whether a new DTLS association or TLS connection 846 is to be established/re-established. 847 Appropriate Values: see Section 4 848 Contact name: Christer Holmberg 849 Mux Category: IDENTICAL 851 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 853 12. Acknowledgements 855 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, 856 Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing 857 comments and suggestions on the document. Ben Campbell performed an 858 AD review. Paul Kyzivat performed a gen-art review. 860 13. Change Log 862 [RFC EDITOR NOTE: Please remove this section when publishing] 864 Changes from draft-ietf-mmusic-sdp-dtls-28 866 o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey 867 Melnikov and Mirja Kuhlewind: 869 o - Document title changed 871 o - Transport Protocol Considerations section removed 873 o - Additional text to Security Considerations section 875 o - Editorial changes 877 Changes from draft-ietf-mmusic-sdp-dtls-27 879 o Reference fixes based on Gen-ART review by Paul Kyzivat. 881 Changes from draft-ietf-mmusic-sdp-dtls-26 883 o Editorial fixes based on Gen-ART review by Paul Kyzivat. 885 Changes from draft-ietf-mmusic-sdp-dtls-25 887 o Minor editorial nits. 889 Changes from draft-ietf-mmusic-sdp-dtls-24 891 o Changes based on 2nd WGLC comments from Roman S and Martin T: 893 o - RFC update structure shortened (old text removed). 895 o - Guidance regarding receiving ClientHello before SDP answer 896 added. 898 o - Additional SIP condierations regarding forking. 900 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 902 o - SDP setup attribute value restriction in initial and subsequent 903 offers based on comment from Ekr. 905 Changes from draft-ietf-mmusic-sdp-dtls-23 907 o Editrial change to make it clear that the document does not modify 908 the procedures in RFC 8122. 910 Changes from draft-ietf-mmusic-sdp-dtls-22 912 o Support for TLS added. 914 o Editorial changes based on sec-dir review by Rich Salz. 916 o Editorial changes based on gen-art review by Paul Kyzivat. 918 o Editorial changes based on ops-dir review by Carlos Pignataro. 920 Changes from draft-ietf-mmusic-sdp-dtls-21 922 o Changes based on AD review by Ben Campbell. 924 o (https://www.ietf.org/mail-archive/web/mmusic/current/ 925 msg17707.html) 927 Changes from draft-ietf-mmusic-sdp-dtls-20 929 o Change to length and randomness of tls-id attribute value. 931 Changes from draft-ietf-mmusic-sdp-dtls-19 933 o Change based on comment from Roman. 935 Changes from draft-ietf-mmusic-sdp-dtls-18 937 o Changes based on comments from Flemming. 939 o - Change in tls-id value definition. 941 o - Editorial fixes. 943 Changes from draft-ietf-mmusic-sdp-dtls-17 945 o Reference fix. 947 Changes from draft-ietf-mmusic-sdp-dtls-16 949 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 951 o Editorial changes based on 2nd WGLC comments from Christian Groves 952 and Nevenka Biondic. 954 Changes from draft-ietf-mmusic-sdp-dtls-15 956 o tls-id attribute value made globally unique 958 Changes from draft-ietf-mmusic-sdp-dtls-14 960 o Changes based on comments from Flemming: 962 o - Additional dtls-is clarifiations 964 o - Editorial fixes 966 Changes from draft-ietf-mmusic-sdp-dtls-13 968 o Text about the updated RFCs added to Abstract and Introduction 970 o Reference to RFC 5763 removed from section 6 (ICE Considerations) 972 o Reference to RFC 5763 removed from section 8 (SIP Considerations) 974 Changes from draft-ietf-mmusic-sdp-dtls-12 976 o "unreliable" changed to "unordered" 978 Changes from draft-ietf-mmusic-sdp-dtls-11 980 o Attribute name changed to tls-id 982 o Additional text based on comments from Roman Shpount. 984 Changes from draft-ietf-mmusic-sdp-dtls-10 986 o Modified document to use tls-id instead of dtls-connection 988 o Changes are based on comments from Eric Rescorla, Justin Uberti, 989 and Paul Kyzivat. 991 Changes from draft-ietf-mmusic-sdp-dtls-08 993 o Offer/Answer section modified in order to allow sending of 994 multiple SDP 'fingerprint' attributes. 996 o Terminology made consistent: 'DTLS connection' replaced with 'DTLS 997 association'. 999 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 1001 o Editorial changes based on comments from Paul Kyzivat. 1003 Changes from draft-ietf-mmusic-sdp-dtls-07 1005 o Reference to RFC 7315 replaced with reference to RFC 7345. 1007 Changes from draft-ietf-mmusic-sdp-dtls-06 1009 o Text on restrictions regarding spanning a DTLS association over 1010 multiple transports added. 1012 o Mux category added to IANA Considerations. 1014 o Normative text regarding mux category and source-specific 1015 applicability added. 1017 o Reference to RFC 7315 added. 1019 o Clarified that offerer/answerer that has not been updated to 1020 support this specification will not include the tls-id attribute 1021 in offers and answers. 1023 o Editorial corrections based on WGLC comments from Charles Eckel. 1025 Changes from draft-ietf-mmusic-sdp-dtls-05 1027 o Text on handling offer/answer error conditions added. 1029 Changes from draft-ietf-mmusic-sdp-dtls-04 1031 o Editorial nits fixed based on comments from Paul Kyzivat: 1033 Changes from draft-ietf-mmusic-sdp-dtls-03 1035 o Changes based on comments from Paul Kyzivat: 1037 o - Modification of tls-id attribute section. 1039 o - Removal of IANA considerations subsection. 1041 o - Making note into normative text in o/a section. 1043 o Changes based on comments from Martin Thompson: 1045 o - Abbreviations section removed. 1047 o - Clarify that a new DTLS association requires a new o/a 1048 transaction. 1050 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 1052 Changes from draft-ietf-mmusic-sdp-dtls-02 1054 o - Updated RFCs added to boilerplate. 1056 Changes from draft-ietf-mmusic-sdp-dtls-01 1058 o - Annex regarding 'tls-id-id' attribute removed. 1060 o - Additional SDP offer/answer procedures, related to certificates, 1061 added. 1063 o - Updates to RFC 5763 and RFC 7345 added. 1065 o - Transport protocol considerations added. 1067 Changes from draft-ietf-mmusic-sdp-dtls-00 1069 o - SDP 'connection' attribute replaced with new 'tls-id' attribute. 1071 o - IANA Considerations added. 1073 o - E-mail regarding 'tls-id-id' attribute added as Annex. 1075 Changes from draft-holmberg-mmusic-sdp-dtls-01 1077 o - draft-ietf-mmusic version of draft submitted. 1079 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 1080 with another expired draft. 1082 o - Clarify that if ufrag in offer is unchanged, it must be 1083 unchanged in associated answer. 1085 o - SIP Considerations section added. 1087 o - Section about multiple SDP fingerprint attributes added. 1089 Changes from draft-holmberg-mmusic-sdp-dtls-00 1091 o - Editorial changes and clarifications. 1093 14. References 1095 14.1. Normative References 1096 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 1098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1099 Requirement Levels", BCP 14, RFC 2119, 1100 DOI 10.17487/RFC2119, March 1997, . 1103 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1104 A., Peterson, J., Sparks, R., Handley, M., and E. 1105 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1106 DOI 10.17487/RFC3261, June 2002, . 1109 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1110 with Session Description Protocol (SDP)", RFC 3264, 1111 DOI 10.17487/RFC3264, June 2002, . 1114 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1115 the Session Description Protocol (SDP)", RFC 4145, 1116 DOI 10.17487/RFC4145, September 2005, . 1119 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1120 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1121 July 2006, . 1123 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1124 for Establishing a Secure Real-time Transport Protocol 1125 (SRTP) Security Context Using Datagram Transport Layer 1126 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1127 2010, . 1129 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1130 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1131 January 2012, . 1133 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 1134 Transport Layer (UDPTL) over Datagram Transport Layer 1135 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 1136 2014, . 1138 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 1139 Transport over the Transport Layer Security (TLS) Protocol 1140 in the Session Description Protocol (SDP)", RFC 8122, 1141 DOI 10.17487/RFC8122, March 2017, . 1144 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 1146 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1147 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1148 May 2017, . 1150 [I-D.ietf-ice-rfc5245bis] 1151 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1152 Connectivity Establishment (ICE): A Protocol for Network 1153 Address Translator (NAT) Traversal", draft-ietf-ice- 1154 rfc5245bis-10 (work in progress), May 2017. 1156 [I-D.ietf-mmusic-sdp-mux-attributes] 1157 Nandakumar, S., "A Framework for SDP Attributes when 1158 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1159 (work in progress), December 2016. 1161 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1162 Holmberg, C., Alvestrand, H., and C. Jennings, 1163 "Negotiating Media Multiplexing Using the Session 1164 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1165 negotiation-38 (work in progress), April 2017. 1167 14.2. Informative References 1169 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1170 Authenticated Identity Management in the Session 1171 Initiation Protocol (SIP)", RFC 4474, 1172 DOI 10.17487/RFC4474, August 2006, . 1175 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1176 Transport Layer Security (TLS) Protocol in the Session 1177 Description Protocol (SDP)", RFC 4572, 1178 DOI 10.17487/RFC4572, July 2006, . 1181 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1182 Media Attributes in the Session Description Protocol 1183 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1184 . 1186 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1187 Transport Layer Security (DTLS) for Stream Control 1188 Transmission Protocol (SCTP)", RFC 6083, 1189 DOI 10.17487/RFC6083, January 2011, . 1192 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 1194 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1195 Updates for Secure Real-time Transport Protocol (SRTP) 1196 Extension for Datagram Transport Layer Security (DTLS)", 1197 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1198 . 1200 [I-D.ietf-stir-rfc4474bis] 1201 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1202 "Authenticated Identity Management in the Session 1203 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 1204 (work in progress), February 2017. 1206 [I-D.ietf-mmusic-ice-sip-sdp] 1207 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 1208 "Session Description Protocol (SDP) Offer/Answer 1209 procedures for Interactive Connectivity Establishment 1210 (ICE)", draft-ietf-mmusic-ice-sip-sdp-13 (work in 1211 progress), June 2017. 1213 [I-D.ietf-mmusic-sdp-uks] 1214 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 1215 uses of Transport Layer Security with the Session 1216 Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00 1217 (work in progress), August 2017. 1219 [ITU.T38.2010] 1220 International Telecommunications Union, "Procedures for 1221 real-time Group 3 facsimile communication over IP 1222 networks", ITU-T Recommendation T.38, September 2010. 1224 Authors' Addresses 1226 Christer Holmberg 1227 Ericsson 1228 Hirsalantie 11 1229 Jorvas 02420 1230 Finland 1232 Email: christer.holmberg@ericsson.com 1234 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017 1236 Roman Shpount 1237 TurboBridge 1238 4905 Del Ray Avenue, Suite 300 1239 Bethesda, MD 20814 1240 USA 1242 Phone: +1 (240) 292-6632 1243 Email: rshpount@turbobridge.com