idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-30.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 (September 8, 2017) is 2419 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 765, 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 12, 2018 September 8, 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-30.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 March 12, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Establishing a new DTLS Association . . . . . . . . . . . . . 4 67 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Change of Local Transport Parameters . . . . . . . . . . 5 69 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 5 70 4. SDP tls-id Attribute . . . . . . . . . . . . . . . . . . . . 5 71 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 72 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9 74 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 10 75 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 76 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 77 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 7. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14 83 9.2.1. Update to section 1 . . . . . . . . . . . . . . . . . 14 84 9.2.2. Update to section 5 . . . . . . . . . . . . . . . . . 15 85 9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16 86 9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16 87 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17 88 9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17 89 9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17 90 9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 94 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 97 14.2. Informative References . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 100 1. Introduction 102 [RFC5763] defines Session Description Protocol (SDP) offer/answer 103 procedures for Secure Realtime Transport Protocol Using Datagram 104 Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/ 105 answer procedures for UDP Transport Layer over Datagram Transport 106 Layer Security (UDPTL-DTLS). This specification defines general 107 offer/answer procedures for DTLS, based on the procedures in 108 [RFC5763]. Other specifications, defining specific DTLS usages, can 109 then reference this specification, in order to ensure that the DTLS 110 aspects are common among all usages. Having common procedures is 111 essential when multiple usages share the same DTLS association 112 [I-D.ietf-mmusic-sdp-bundle-negotiation]. The document updates 113 [RFC5763] and [RFC7345], by replacing common SDP offer/answer 114 procedures with a reference to this specification. 116 NOTE: Since the publication of [RFC5763], [RFC4474] has been 117 obsoleted by [I-D.ietf-stir-rfc4474bis]. The updating of the 118 references (and the associated procedures) within [RFC5763] is 119 outside the scope of this document. However, implementers of 120 [RFC5763] applications are encouraged to implement 121 [I-D.ietf-stir-rfc4474bis] instead of [RFC4474]. 123 As defined in [RFC5763], a new DTLS association MUST be established 124 when transport parameters are changed. Transport parameter change is 125 not well defined when Interactive Connectivity Establishment (ICE) 126 [I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a 127 transport change is based on ufrag [I-D.ietf-ice-rfc5245bis] change, 128 but the ufrag value is changed both when ICE is negotiated and when 129 ICE restart [I-D.ietf-ice-rfc5245bis] occurs. These events do not 130 always require a new DTLS association to be established, but 131 previously there was no way to explicitly indicate in an SDP offer or 132 answer whether a new DTLS association is required. To solve that 133 problem, this document defines a new SDP attribute, 'tls-id'. The 134 pair of SDP 'tls-id' attribute values (the attribute values of the 135 offerer and the answerer) uniquely identifies the DTLS association. 136 Providing a new value of the 'tls-id' attribute in an SDP offer or 137 answers can be used to indicate whether a new DTLS association is to 138 be established. 140 The SDP 'tls-id' attribute can be specified when negotiating a 141 Transport Layer Security (TLS) connection, using the procedures in 142 this document in conjunction with the procedures in [RFC5763] and 144 [RFC8122]. The unique combination of SDP 'tls-id' attribute values 145 can be used to identity the negotiated TLS connection. The unique 146 value can be used, for example, within TLS protocol extensions to 147 differentiate between multiple TLS connections and correlate those 148 connections with specific offer/answer exchanges. The TLS specific 149 considerations are described in Section 7. 151 2. Conventions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. Establishing a new DTLS Association 161 3.1. General 163 A new DTLS association must be established between two endpoints 164 after a successful SDP offer/answer exchange in the following cases: 166 o The negotiated DTLS setup roles change; or 168 o One or more fingerprint values are modified, added or removed in 169 either an SDP offer or answer; or 171 o The intent to establish a new DTLS association is explicitly 172 signaled using SDP, by changing the value of the SDP 'tls-id' 173 attribute defined in this document; 175 NOTE: The first two items above are based on the procedures in 176 [RFC5763]. This specification adds the support for explicit 177 signaling using the SDP 'tls-id' attribute. 179 A new DTLS association can only be established as a result of the 180 successful SDP offer/answer exchange. Whenever an entity determines 181 that a new DTLS association is required, the entity MUST initiate an 182 SDP offer/answer exchange, following the procedures in Section 5. 184 The sections below describe typical cases where a new DTLS 185 association needs to be established. 187 In this document, a "new DTLS association" between two endpoints 188 refers to either an initial DTLS association (when no DTLS 189 association is currently established between the endpoints) or an 190 DTLS association replacing a previously established DTLS association. 192 3.2. Change of Local Transport Parameters 194 If an endpoint modifies its local transport parameters (address and/ 195 or port), and if the modification requires a new DTLS association, 196 the endpoint must change its local SDP 'tls-id' attribute value (see 197 Section 4). 199 If the underlying transport prohibits a DTLS association from 200 spanning multiple transports, and if the transport is changed, the 201 endpoint must change its local SDP 'tls-id' attribute value (see 202 Section 4). An example of such a case is when DTLS is carried over 203 the Stream Control Transmission Protocol (SCTP), as described in 204 [RFC6083]. 206 3.3. Change of ICE ufrag value 208 If an endpoint uses ICE, and modifies a local ufrag value, and if the 209 modification requires a new DTLS association, the endpoint MUST 210 change its local SDP 'tls-id' attribute value (see Section 4). 212 4. SDP tls-id Attribute 214 The pair of SDP 'tls-id' attribute values (the attribute values of 215 the offerer and the answerer) uniquely identifies the DTLS 216 association or TLS connection. 218 Name: tls-id 220 Value: tls-id-value 222 Usage Level: media 224 Charset Dependent: no 226 Default Value: N/A 228 Syntax: 230 tls-id-value = 20*255(tls-id-char) 231 tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" 233 235 Example: 237 a=tls-id:abc3de65cddef001be82 239 Every time an endpoint requests to establish a new DTLS association, 240 the endpoint MUST generate a new local 'tls-id' attribute value. A 241 non-changed local 'tls-id' attribute value, in combination with non- 242 changed fingerprints, indicates that the endpoint intends to reuse 243 the existing DTLS association. 245 The 'tls-id' attribute value MUST be generated using a strong random 246 function and include at least 120 bits of randomness. 248 No default value is defined for the SDP 'tls-id' attribute. 249 Implementations that wish to use the attribute MUST explicitly 250 include it in SDP offers and answers. If an offer or answer does not 251 contain a 'tls-id' attribute (this could happen if the offerer or 252 answerer represents an existing implementation that has not been 253 updated to support the 'tls-id' attribute), unless there is another 254 mechanism to explicitly indicate that a new DTLS association is to be 255 established, a modification of one or more of the following 256 characteristics MUST be treated as an indication that an endpoint 257 wants to establish a new DTLS association: 259 o DTLS setup role; or 261 o fingerprint set; or 263 o local transport parameters 264 NOTE: A modification of the ufrag value is not treated as an 265 indication that an endpoint wants to establish a new DTLS assocation. 266 In order to indicate that a new DTLS association is to be 267 established, one or more of the characteristics listed above have to 268 be modified. 270 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- 271 id' attribute is 'IDENTICAL', which means that the attribute value 272 applies to all media descriptions being multiplexed 273 [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in 274 [I-D.ietf-mmusic-sdp-bundle-negotiation], in order to avoid 275 duplication the attribute is only associated with the "m=" line 276 representing the offerer/answerer BUNDLE-tag. 278 For RTP-based media, the 'tls-id' attribute applies to the whole 279 associated media description. The attribute MUST NOT be defined per 280 source (using the SDP 'ssrc' attribute [RFC5576]). 282 The SDP offer/answer [RFC3264] procedures associated with the 283 attribute are defined in Section 5. 285 5. SDP Offer/Answer Procedures 287 5.1. General 289 This section defines the generic SDP offer/answer procedures for 290 negotiating a DTLS association. Additional procedures (e.g., 291 regarding usage of specific SDP attributes etc.) for individual DTLS 292 usages (e.g., DTLS-SRTP) are outside the scope of this specification, 293 and need to be specified in a usage specific specification. 295 NOTE: The procedures in this section are generalizations of 296 procedures first specified in DTLS-SRTP [RFC5763], with the addition 297 of usage of the SDP 'tls-id' attribute. That document is herein 298 updated to make use of these new procedures. 300 The procedures in this section apply to an SDP media description 301 ("m=" line) associated with DTLS-protected media/data. 303 When an offerer or answerer indicates that it wants to establish a 304 new DTLS association, it needs to make sure that media packets 305 associated with any previously established DTLS association and the 306 new DTLS association can be de-multiplexed. In case of an ordered 307 transport (e.g., SCTP) this can be done simply by sending packets for 308 the new DTLS association after all packets associated with a 309 previously established DTLS association has been sent. In case of an 310 unordered transport, such as UDP, packets associated with a 311 previously established DTLS association can arrive after the answer 312 SDP was received and after the first packets associated with the new 313 DTLS association were received. The only way to de-multiplex packets 314 associated with with a previously established DTLS association and 315 the new DTLS association is on the basis of transport 5-tuple. 316 Because of this, if an unordered transport is used for the DTLS 317 association, a new transport (3-tuple) must be allocated by at least 318 one of the endpoints so that DTLS packets can be de-multiplexed. 320 When an offerer needs to establish a new DTLS association, and if an 321 unordered transport (e.g., UDP) is used, the offerer MUST allocate a 322 new transport (3-tuple) for the offer in such a way that the offerer 323 can disambiguate any packets associated with the new DTLS association 324 from any packets associated with any other DTLS association. This 325 typically means using a local address and/or port, or a set of ICE 326 candidates (see Section 6), which were not recently used for any 327 other DTLS association. 329 When an answerer needs to establish a new DTLS association, if an 330 unordered transport is used, and if the offerer did not allocate a 331 new transport, the answerer MUST allocate a new transport for the 332 answer in such a way that it can disambiguate any packets associated 333 with the new DTLS association from any packets associated with any 334 other DTLS association. This typically means using a local address 335 and/or port, or a set of ICE candidates (see Section 6), which were 336 not recently used for any other DTLS association. 338 In order to negotiate a DTLS association, the following SDP 339 attributes are used: 341 o The SDP 'setup' attribute, defined in [RFC4145], is used to 342 negotiate the DTLS roles; 344 o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to 345 provide one or more fingerprint values; and 347 o The SDP 'tls-id' attribute, defined in this specification, is used 348 to identity the DTLS association. 350 This specification does not define the usage of the SDP 'connection' 351 attribute [RFC4145] for negotiating a DTLS association. However, the 352 attribute MAY be used if the DTLS association is used together with 353 another protocol (e.g., SCTP or TCP) for which the usage of the 354 attribute has been defined. 356 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 357 'setup' attribute 'holdconn' value when negotiating a DTLS 358 association. 360 Endpoints MUST support the hash functions as defined in [RFC8122]. 362 The certificate received during the DTLS handshake [RFC6347] MUST 363 match a certificate fingerprint received in SDP 'fingerprint' 364 attributes according to the procedures defined in [RFC8122]. If 365 fingerprints do not match the hashed certificate, then an endpoint 366 MUST tear down the media session immediately (see [RFC8122]). Note 367 that it is permissible to wait until the other side's fingerprint(s) 368 has been received before establishing the connection; however, this 369 may have undesirable latency effects. 371 SDP offerers and answerers might reuse certificates across multiple 372 DTLS associations, and provide identical fingerprint values for each 373 DTLS association. The combination of the SDP 'tls-id' attribute 374 values of the SDP offerer and answerer identifies each individual 375 DTLS association. 377 NOTE: There are cases where the SDP 'tls-id' attribute value 378 generated by the offerer will end up being used for multiple DTLS 379 associations. For that reason the combination of the attribute 380 values of the offerer and answerer is needed in order to identity a 381 DTLS association. An example of such case is where the offerer sends 382 an updated offer (Section 5.5), without modifying its attribute 383 value, but the answerer determines that a new DTLS association is to 384 be created. The answerer will generate a new local attribute value 385 for the new DTLS association (Section 5.3), while the offerer will 386 use the same attribute value that it used for the current 387 association. Another example is when the Session Initiation Protocol 388 (SIP) [RFC3261] is used for signalling, and an offer is forked to 389 multiple answerers. The attribute value generated by the offerer 390 will be used for DTLS associations established by each answerer. 392 5.2. Generating the Initial SDP Offer 394 When an offerer sends the initial offer, the offerer MUST insert an 395 SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, 396 and one or more SDP 'fingerprint' attributes according to the 397 procedures in [RFC8122]. In addition, the offerer MUST insert in the 398 offer an SDP 'tls-id' attribute with a unique attribute value. 400 As the offerer inserts the SDP 'setup' attribute with an 'actpass' 401 attribute value, the offerer MUST be prepared to receive a DTLS 402 ClientHello message [RFC6347] (if a new DTLS association is 403 established by the answerer) from the answerer before the offerer 404 receives the SDP answer. 406 If the offerer receives a DTLS ClientHello message, and a DTLS 407 association is established, before the offerer receives the SDP 408 Answer carrying the fingerprint associated with the DTLS association, 409 any data received on the DTLS association before the fingerprint MUST 410 be considered coming from an unverified source. The processing of 411 such data, and sending of data by the offerer to the unverified 412 source, is outside the scope of this document. 414 5.3. Generating the Answer 416 When an answerer sends an answer, the answerer MUST insert in the 417 answer an SDP 'setup' attribute according to the procedures in 418 [RFC4145], and one or more SDP 'fingerprint' attributes according to 419 the procedures in [RFC8122]. If the answerer determines, based on 420 the criteria specified in Section 3.1, that a new DTLS association is 421 to be established, the answerer MUST insert in the associated answer 422 an SDP 'tls-id' attribute with a new unique attribute value. Note 423 that the offerer and answerer generate their own local 'tls-id' 424 attribute values, and the combination of both values identify the 425 DTLS association. 427 If the answerer receives an offer that requires establishment of a 428 new DTLS association, and if the answerer does not accept the 429 establishment of a new DTLS association, the answerer MUST reject the 430 "m=" lines associated with the suggested DTLS association [RFC3264]. 432 If an answerer receives an offer that does not require the 433 establishment of a new DTLS association, and if the answerer 434 determines that a new DTLS association is not to be established, the 435 answerer MUST insert an SDP 'tls-id' attribute with the previously 436 assigned attribute value in the associated answer. In addition, the 437 answerer MUST insert an SDP 'setup' attribute with an attribute value 438 that does not change the previously negotiated DTLS roles, and one or 439 more SDP 'fingerprint' attributes values that do not change the 440 previously sent fingerprint set, in the associated answer. 442 If the answerer receives an offer that does not contain an SDP 'tls- 443 id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in 444 the answer. 446 If a new DTLS association is to be established, and if the answerer 447 inserts an SDP 'setup' attribute with an 'active' attribute value in 448 the answer, the answerer MUST initiate a DTLS handshake by sending a 449 DTLS ClientHello message towards the offerer. 451 Even though an offerer is required to insert an 'SDP' setup attribute 452 with an 'actpass' attribute value in initial offers (Section 5.2) and 453 subsequent offers (Section 5.5), the answerer MUST be able to receive 454 initial and subsequent offers with other attribute values, in order 455 to be backward compatible with older implementations that might 456 insert other attribute values in initial and subsequent offers. 458 5.4. Offerer Processing of the SDP Answer 460 When an offerer receives an answer that establishes a new DTLS 461 association based on criteria defined in Section 3.1, and if the 462 offerer becomes DTLS client (based on the value of the SDP 'setup' 463 attribute value [RFC4145]), the offerer MUST establish a DTLS 464 association. If the offerer becomes DTLS server, it MUST wait for 465 the answerer to establish the DTLS association. 467 If the offerer indicated a desire to reuse an existing DTLS 468 association and the answerer does not request the establishment of a 469 new DTLS association, the offerer will continue to use the previously 470 established DTLS association. 472 A new DTLS association can be established based on changes in either 473 an SDP offer or answer. When communicating with legacy endpoints, an 474 offerer can receive an answer that includes the same fingerprint set 475 and setup role. A new DTLS association will still be established if 476 such an answer was received as a response to an offer which requested 477 the establishment of a new DTLS association, as the transport 478 parameters would have been changed in the offer. 480 5.5. Modifying the Session 482 When an offerer sends a subsequent offer, and if the offerer wants to 483 establish a new DTLS association, the offerer MUST insert an SDP 484 'setup' attribute [RFC4145] with an 'actpass' attribute value, and 485 one or more SDP 'fingerprint' attributes according to the procedures 486 in [RFC8122]. In addition, the offerer MUST insert in the offer an 487 SDP 'tls-id' attribute with a new unique attribute value. 489 When an offerer sends a subsequent offer, and the offerer does not 490 want to establish a new DTLS association, and if a previously 491 established DTLS association exists, the offerer MUST insert an SDP 492 'setup' attribute with an 'actpass' attribute value, and one or more 493 SDP 'fingerprint' attributes with attribute values that do not change 494 the previously sent fingerprint set, in the offer. In addition, the 495 offerer MUST insert an SDP 'tls-id' attribute with the previously 496 assigned attribute value in the offer. 498 NOTE: When a new DTLS association is being established, each endpoint 499 needs to be prepared to receive data on both the new and old DTLS 500 associations as long as both are alive. 502 6. ICE Considerations 504 When the Interactive Connectivity Establishment (ICE) mechanism 505 [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are 506 performed before the DTLS handshake begins. Note that if aggressive 507 nomination mode is used, multiple candidate pairs may be marked valid 508 before ICE finally converges on a single candidate pair. 510 NOTE: Aggressive nomination has been deprecated from ICE, but must 511 still be supported for backwards compatibility reasons 512 [I-D.ietf-ice-rfc5245bis]. 514 When a new DTLS association is established over an unordered 515 transport, in order to disambiguate any packets associated with the 516 newly established DTLS association, at least one of the endpoints 517 MUST allocate a completely new set of ICE candidates which were not 518 recently used for any other DTLS association. This means the 519 answerer cannot initiate a new DTLS association unless the offerer 520 initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer 521 wants to initiate a new DTLS association, it needs to initiate an ICE 522 restart and a new offer/answer exchange on its own. However, an ICE 523 restart does not by default require a new DTLS association to be 524 established. 526 NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets 527 are sent directly over UDP, not over DTLS. [RFC7983] describes how 528 to demultiplex STUN packets from DTLS packets and SRTP packets. 530 Each ICE candidate associated with a component is treated as being 531 part of the same DTLS association. Therefore, from a DTLS 532 perspective it is not considered a change of local transport 533 parameters when an endpoint switches between those ICE candidates. 535 7. TLS Considerations 537 The procedures in this document can also be used for negotiating and 538 establishing a TLS connection, with the restriction described below. 540 As specified in [RFC4145], the SDP 'connection' attribute is used to 541 indicate whether to establish a new TLS connection. An offerer and 542 answerer MUST ensure that the 'connection' attribute value and the 543 'tls-id' attribute value does not cause a conflict regarding whether 544 a new TLS connection is to be established or not. 546 NOTE: Even though the SDP 'connection' attribute can be used to 547 indicate whether a new TLS connection is to be established, the 548 unique combination of SDP 'tls-id' attribute values can be used to 549 identity a TLS connection. The unique value can be used e.g., within 550 TLS protocol extensions to differentiate between multiple TLS 551 connections and correlate those connections with specific offer/ 552 answer exchanges. One such extension is defined in 553 [I-D.ietf-mmusic-sdp-uks]. 555 If an offerer or answerer inserts an SDP 'connection' attribute with 556 a 'new' value in the offer/answer and also inserts an SDP 'tls-id' 557 attribute, the value of tls-id' attribute MUST be new and unique. 559 If an offerer or answerer inserts an SDP 'connection' attribute with 560 a 'existing' value in the offer/answer, if a previously established 561 TLS connection exists, and if the offerer/answerer previously 562 inserted an SDP 'tls-id' attribute associated with the same TLS 563 connection in an offer/answer, the offerer/answerer MUST also insert 564 an SDP 'tls-id' attribute with the previously assigned value in the 565 offer/answer. 567 If an offerer or answerer receives an offer/answer with conflicting 568 attribute values, the offerer/answerer MUST process the offer/answer 569 as misformed. 571 An endpoint must not make assumptions regarding the support of the 572 SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, 573 both offerers and answerers MUST always use the 'connection' 574 attribute in conjunction with the 'tls-id' attribute. 576 NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is 577 not explicitly present, the implicit default value is 'new'. 579 The SDP example below is based on the example in section 3.4 of 580 [RFC8122], with the addition of the SDP 'tls-id' attribute. 582 m=image 54111 TCP/TLS t38 583 c=IN IP4 192.0.2.2 584 a=tls-id:abc3de65cddef001be82 585 a=setup:passive 586 a=connection:new 587 a=fingerprint:SHA-256 \ 588 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 589 3E:5D:49:6B:19:E5:7C:AB:4A:AD 590 a=fingerprint:SHA-1 \ 591 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 593 8. SIP Considerations 595 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 596 signal protocol for establishing a multimedia session, dialogs 597 [RFC3261] might be established between the caller and multiple 598 callees. This is referred to as forking. If forking occurs, 599 separate DTLS associations will be established between the caller and 600 each callee. 602 When forking occurs, an SDP offerer can receive DTLS ClientHello 603 messages and SDP answerers from multiple remote locations. Because 604 of this, the offerer might have to wait for multiple SDP answers 605 (from different remote locations) until it receives a certificate 606 fingerprint that matches the certificate associated with a specific 607 DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch 608 until it determines that it will not receive SDP answers from any 609 additional remote locations. 611 It is possible to send an INVITE request which does not contain an 612 SDP offer. Such an INVITE request is often referred to as an 'empty 613 INVITE', or an 'offer-less INVITE'. The receiving endpoint will 614 include the SDP offer in a response to the request. When the 615 endpoint generates such SDP offer, if a previously established DTLS 616 association exists, the offerer MUST insert an SDP 'tls-id' 617 attribute, and one or more SDP 'fingerprint' attributes, with 618 previously assigned attribute values. If a previously established 619 DTLS association did not exist, the offer MUST be generated based on 620 the same rules as a new offer (see Section 5.2). Regardless of the 621 previous existence of a DTLS association, the SDP 'setup' attribute 622 MUST be included according to the rules defined in [RFC4145] and if 623 ICE is used, ICE restart MUST be initiated. This is needed in order 624 to support third party call control, as described in 625 [I-D.ietf-mmusic-ice-sip-sdp]. 627 9. RFC Updates 629 9.1. General 631 This section updates specifications that use DTLS-protected media, in 632 order to reflect the procedures defined in this specification. 634 9.2. Update to RFC 5763 636 9.2.1. Update to section 1 638 The reference to [RFC4572] is replaced with a reference to [RFC8122]. 640 9.2.2. Update to section 5 642 The text in section 5 (Establishing a Secure Channel) is modified by 643 replacing generic SDP offer/answer procedures for DTLS with a 644 reference to this specification: 646 NEW TEXT: 648 The two endpoints in the exchange present their identities as part of 649 the DTLS handshake procedure using certificates. This document uses 650 certificates in the same style as described in "Connection-Oriented 651 Media Transport over the Transport Layer Security (TLS) Protocol in 652 the Session Description Protocol (SDP)" [RFC8122]. 654 If self-signed certificates are used, the content of the 655 subjectAltName attribute inside the certificate MAY use the uniform 656 resource identifier (URI) of the user. This is useful for debugging 657 purposes only and is not required to bind the certificate to one of 658 the communication endpoints. The integrity of the certificate is 659 ensured through the fingerprint attribute in the SDP. 661 The generation of public/private key pairs is relatively expensive. 662 Endpoints are not required to generate certificates for each session. 664 The offer/answer model, defined in [RFC3264], is used by protocols 665 like the Session Initiation Protocol (SIP) [RFC3261] to set up 666 multimedia sessions. 668 When an endpoint wishes to set up a secure media session with another 669 endpoint, it sends an offer in a SIP message to the other endpoint. 670 This offer includes, as part of the SDP payload, a fingerprint of 671 a certificate that the endpoint wants to use. The endpoint SHOULD 672 send the SIP message containing the offer to the offerer's SIP proxy 673 over an integrity protected channel. The proxy SHOULD add an 674 Identity header field according to the procedures outlined in 675 [RFC4474]. When the far endpoint receives the SIP message, it can 676 verify the identity of the sender using the Identity header field. 677 Since the Identity header field is a digital signature across several 678 SIP header fields, in addition to the body of the SIP message, the 679 receiver can also be certain that the message has not been tampered 680 with after the digital signature was applied and added to the SIP 681 message. 683 The far endpoint (answerer) may now establish a DTLS association with 684 the offerer. Alternately, it can indicate in its answer that the 685 offerer is to initiate the DTLS association. In either case, mutual 686 DTLS certificate-based authentication will be used. After completing 687 the DTLS handshake, information about the authenticated identities, 688 including the certificates, are made available to the endpoint 689 application. The answerer is then able to verify that the offerer's 690 certificate used for authentication in the DTLS handshake can be 691 associated to a certificate fingerprint contained in the offer in 692 the SDP. At this point, the answerer may indicate to the end user 693 that the media is secured. The offerer may only tentatively accept 694 the answerer's certificate since it may not yet have the answerer's 695 certificate fingerprint. 697 When the answerer accepts the offer, it provides an answer back to 698 the offerer containing the answerer's certificate fingerprint. At 699 this point, the offerer can accept or reject the peer's certificate 700 and the offerer can indicate to the end user that the media is 701 secured. 703 Note that the entire authentication and key exchange for securing 704 the media traffic is handled in the media path through DTLS. The 705 signaling path is only used to verify the peers' certificate 706 fingerprints. 708 The offerer and answerer MUST follow the SDP offer/answer procedures 709 defined in [RFCXXXX]. 711 9.2.3. Update to section 6.6 713 The text in section 6.6 (Session Modification) is modified by 714 replacing replacing generic SDP offer/answer procedures for DTLS with 715 a reference to this specification: 717 NEW TEXT: 719 Once an answer is provided to the offerer, either endpoint MAY 720 request a session modification that MAY include an updated offer. 721 This session modification can be carried in either an INVITE or 722 UPDATE request. The peers can reuse an existing DTLS association, 723 or establish a new one, following the procedures in [RFCXXXX]. 725 9.2.4. Update to section 6.7.1 727 The text in section 6.7.1 (ICE Interaction) is modified by replacing 728 the ICE procedures with a reference to this specification: 730 NEW TEXT: 732 The Interactive Connectivity Establishment (ICE) 733 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 734 are described in [RFCXXXX]. 736 9.3. Update to RFC 7345 738 9.3.1. Update to section 4 740 The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer 741 Procedures) are removed, and replaced with the new text below: 743 NEW TEXT: 745 An endpoint (i.e., both the offerer and the answerer) MUST create an 746 SDP media description ("m=" line) for each UDPTL-over-DTLS media 747 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 748 "proto" field of the "m=" line. 750 The offerer and answerer MUST follow the SDP offer/answer procedures 751 defined in [RFCXXXX] in order to negotiate the DTLS association 752 associated with the UDPTL-over-DTLS media stream. In addition, 753 the offerer and answerer MUST use the SDP attributes defined for 754 UDPTL over UDP, as defined in [ITU.T38.2010]. 756 9.3.2. Update to section 5.2.1 758 The text in section 5.2.1 (ICE Usage) is modified by replacing the 759 ICE procedures with a reference to this specification: 761 NEW TEXT: 763 The Interactive Connectivity Establishment (ICE) 764 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 765 are described in [RFCXXXX]. 767 [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX 768 with the RFC number of this document.] 770 9.3.3. Update to section 10.1 772 A reference to [RFC8122] is added to section 10.1 (Normative 773 References): 775 NEW TEXT: 777 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 778 Transport over the Transport Layer Security (TLS) Protocol 779 in the Session Description Protocol (SDP)", RFC 8122, 780 DOI 10.17487/RFC8122, March 2017, 781 . 783 10. Security Considerations 785 This specification does not modify the security considerations 786 associated with DTLS, or the SDP offer/answer mechanism. In addition 787 to the introduction of the SDP 'tls-id' attribute, the specification 788 simply clarifies the procedures for negotiating and establishing a 789 DTLS association. 791 This specification does not modify the actual TLS connection setup 792 procedures. The SDP 'tls-is' attribute as such cannot be used to 793 correlate an SDP Offer/Answer exchange with a TLS connection setup. 794 Thus, this draft does not introduce new security considerations 795 related to correlating an SDP Offer/Answer exchange with a TLS 796 connection setup. 798 11. IANA Considerations 800 This document updates the "Session Description Protocol Parameters" 801 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 802 it adds the SDP 'tls-id' attribute to the table for SDP media level 803 attributes. 805 Attribute name: tls-id 806 Type of attribute: media-level 807 Subject to charset: no 808 Purpose: Indicates whether a new DTLS association or TLS connection 809 is to be established/re-established. 810 Appropriate Values: see Section 4 811 Contact name: Christer Holmberg 812 Mux Category: IDENTICAL 814 12. Acknowledgements 816 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, 817 Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing 818 comments and suggestions on the document. Ben Campbell performed an 819 AD review. Paul Kyzivat performed a gen-art review. 821 13. Change Log 823 [RFC EDITOR NOTE: Please remove this section when publishing] 825 Changes from draft-ietf-mmusic-sdp-dtls-29 827 o Removal of ufrag value change as a trigger for a new DTLS 828 association 830 Changes from draft-ietf-mmusic-sdp-dtls-28 832 o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey 833 Melnikov and Mirja Kuhlewind: 835 o - Document title changed 837 o - Transport Protocol Considerations section removed 839 o - Additional text to Security Considerations section 841 o - Editorial changes 843 Changes from draft-ietf-mmusic-sdp-dtls-27 845 o Reference fixes based on Gen-ART review by Paul Kyzivat. 847 Changes from draft-ietf-mmusic-sdp-dtls-26 849 o Editorial fixes based on Gen-ART review by Paul Kyzivat. 851 Changes from draft-ietf-mmusic-sdp-dtls-25 853 o Minor editorial nits. 855 Changes from draft-ietf-mmusic-sdp-dtls-24 857 o Changes based on 2nd WGLC comments from Roman S and Martin T: 859 o - RFC update structure shortened (old text removed). 861 o - Guidance regarding receiving ClientHello before SDP answer 862 added. 864 o - Additional SIP condierations regarding forking. 866 o - SDP setup attribute value restriction in initial and subsequent 867 offers based on comment from Ekr. 869 Changes from draft-ietf-mmusic-sdp-dtls-23 871 o Editrial change to make it clear that the document does not modify 872 the procedures in RFC 8122. 874 Changes from draft-ietf-mmusic-sdp-dtls-22 876 o Support for TLS added. 878 o Editorial changes based on sec-dir review by Rich Salz. 880 o Editorial changes based on gen-art review by Paul Kyzivat. 882 o Editorial changes based on ops-dir review by Carlos Pignataro. 884 Changes from draft-ietf-mmusic-sdp-dtls-21 886 o Changes based on AD review by Ben Campbell. 888 o (https://www.ietf.org/mail-archive/web/mmusic/current/ 889 msg17707.html) 891 Changes from draft-ietf-mmusic-sdp-dtls-20 893 o Change to length and randomness of tls-id attribute value. 895 Changes from draft-ietf-mmusic-sdp-dtls-19 897 o Change based on comment from Roman. 899 Changes from draft-ietf-mmusic-sdp-dtls-18 901 o Changes based on comments from Flemming. 903 o - Change in tls-id value definition. 905 o - Editorial fixes. 907 Changes from draft-ietf-mmusic-sdp-dtls-17 908 o Reference fix. 910 Changes from draft-ietf-mmusic-sdp-dtls-16 912 o Editorial changes based on 2nd WGLC comments from Christian Groves 913 and Nevenka Biondic. 915 Changes from draft-ietf-mmusic-sdp-dtls-15 917 o tls-id attribute value made globally unique 919 Changes from draft-ietf-mmusic-sdp-dtls-14 921 o Changes based on comments from Flemming: 923 o - Additional dtls-is clarifiations 925 o - Editorial fixes 927 Changes from draft-ietf-mmusic-sdp-dtls-13 929 o Text about the updated RFCs added to Abstract and Introduction 931 o Reference to RFC 5763 removed from section 6 (ICE Considerations) 933 o Reference to RFC 5763 removed from section 8 (SIP Considerations) 935 Changes from draft-ietf-mmusic-sdp-dtls-12 937 o "unreliable" changed to "unordered" 939 Changes from draft-ietf-mmusic-sdp-dtls-11 941 o Attribute name changed to tls-id 943 o Additional text based on comments from Roman Shpount. 945 Changes from draft-ietf-mmusic-sdp-dtls-10 947 o Modified document to use tls-id instead of dtls-connection 949 o Changes are based on comments from Eric Rescorla, Justin Uberti, 950 and Paul Kyzivat. 952 Changes from draft-ietf-mmusic-sdp-dtls-08 954 o Offer/Answer section modified in order to allow sending of 955 multiple SDP 'fingerprint' attributes. 957 o Terminology made consistent: 'DTLS connection' replaced with 'DTLS 958 association'. 960 o Editorial changes based on comments from Paul Kyzivat. 962 Changes from draft-ietf-mmusic-sdp-dtls-07 964 o Reference to RFC 7315 replaced with reference to RFC 7345. 966 Changes from draft-ietf-mmusic-sdp-dtls-06 968 o Text on restrictions regarding spanning a DTLS association over 969 multiple transports added. 971 o Mux category added to IANA Considerations. 973 o Normative text regarding mux category and source-specific 974 applicability added. 976 o Reference to RFC 7315 added. 978 o Clarified that offerer/answerer that has not been updated to 979 support this specification will not include the tls-id attribute 980 in offers and answers. 982 o Editorial corrections based on WGLC comments from Charles Eckel. 984 Changes from draft-ietf-mmusic-sdp-dtls-05 986 o Text on handling offer/answer error conditions added. 988 Changes from draft-ietf-mmusic-sdp-dtls-04 990 o Editorial nits fixed based on comments from Paul Kyzivat: 992 Changes from draft-ietf-mmusic-sdp-dtls-03 994 o Changes based on comments from Paul Kyzivat: 996 o - Modification of tls-id attribute section. 998 o - Removal of IANA considerations subsection. 1000 o - Making note into normative text in o/a section. 1002 o Changes based on comments from Martin Thompson: 1004 o - Abbreviations section removed. 1006 o - Clarify that a new DTLS association requires a new o/a 1007 transaction. 1009 Changes from draft-ietf-mmusic-sdp-dtls-02 1011 o - Updated RFCs added to boilerplate. 1013 Changes from draft-ietf-mmusic-sdp-dtls-01 1015 o - Annex regarding 'tls-id-id' attribute removed. 1017 o - Additional SDP offer/answer procedures, related to certificates, 1018 added. 1020 o - Updates to RFC 5763 and RFC 7345 added. 1022 o - Transport protocol considerations added. 1024 Changes from draft-ietf-mmusic-sdp-dtls-00 1026 o - SDP 'connection' attribute replaced with new 'tls-id' attribute. 1028 o - IANA Considerations added. 1030 o - E-mail regarding 'tls-id-id' attribute added as Annex. 1032 Changes from draft-holmberg-mmusic-sdp-dtls-01 1034 o - draft-ietf-mmusic version of draft submitted. 1036 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 1037 with another expired draft. 1039 o - Clarify that if ufrag in offer is unchanged, it must be 1040 unchanged in associated answer. 1042 o - SIP Considerations section added. 1044 o - Section about multiple SDP fingerprint attributes added. 1046 Changes from draft-holmberg-mmusic-sdp-dtls-00 1048 o - Editorial changes and clarifications. 1050 14. References 1052 14.1. Normative References 1054 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1055 Requirement Levels", BCP 14, RFC 2119, 1056 DOI 10.17487/RFC2119, March 1997, 1057 . 1059 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1060 A., Peterson, J., Sparks, R., Handley, M., and E. 1061 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1062 DOI 10.17487/RFC3261, June 2002, 1063 . 1065 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1066 with Session Description Protocol (SDP)", RFC 3264, 1067 DOI 10.17487/RFC3264, June 2002, 1068 . 1070 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1071 the Session Description Protocol (SDP)", RFC 4145, 1072 DOI 10.17487/RFC4145, September 2005, 1073 . 1075 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1076 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1077 July 2006, . 1079 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1080 for Establishing a Secure Real-time Transport Protocol 1081 (SRTP) Security Context Using Datagram Transport Layer 1082 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1083 2010, . 1085 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1086 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1087 January 2012, . 1089 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 1090 Transport Layer (UDPTL) over Datagram Transport Layer 1091 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 1092 2014, . 1094 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 1095 Transport over the Transport Layer Security (TLS) Protocol 1096 in the Session Description Protocol (SDP)", RFC 8122, 1097 DOI 10.17487/RFC8122, March 2017, 1098 . 1100 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1101 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1102 May 2017, . 1104 [I-D.ietf-ice-rfc5245bis] 1105 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1106 Connectivity Establishment (ICE): A Protocol for Network 1107 Address Translator (NAT) Traversal", draft-ietf-ice- 1108 rfc5245bis-10 (work in progress), May 2017. 1110 [I-D.ietf-mmusic-sdp-mux-attributes] 1111 Nandakumar, S., "A Framework for SDP Attributes when 1112 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1113 (work in progress), December 2016. 1115 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1116 Holmberg, C., Alvestrand, H., and C. Jennings, 1117 "Negotiating Media Multiplexing Using the Session 1118 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1119 negotiation-38 (work in progress), April 2017. 1121 14.2. Informative References 1123 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1124 Authenticated Identity Management in the Session 1125 Initiation Protocol (SIP)", RFC 4474, 1126 DOI 10.17487/RFC4474, August 2006, 1127 . 1129 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1130 Transport Layer Security (TLS) Protocol in the Session 1131 Description Protocol (SDP)", RFC 4572, 1132 DOI 10.17487/RFC4572, July 2006, 1133 . 1135 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1136 Media Attributes in the Session Description Protocol 1137 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1138 . 1140 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1141 Transport Layer Security (DTLS) for Stream Control 1142 Transmission Protocol (SCTP)", RFC 6083, 1143 DOI 10.17487/RFC6083, January 2011, 1144 . 1146 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1147 Updates for Secure Real-time Transport Protocol (SRTP) 1148 Extension for Datagram Transport Layer Security (DTLS)", 1149 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1150 . 1152 [I-D.ietf-stir-rfc4474bis] 1153 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1154 "Authenticated Identity Management in the Session 1155 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 1156 (work in progress), February 2017. 1158 [I-D.ietf-mmusic-ice-sip-sdp] 1159 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 1160 "Session Description Protocol (SDP) Offer/Answer 1161 procedures for Interactive Connectivity Establishment 1162 (ICE)", draft-ietf-mmusic-ice-sip-sdp-13 (work in 1163 progress), June 2017. 1165 [I-D.ietf-mmusic-sdp-uks] 1166 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 1167 uses of Transport Layer Security with the Session 1168 Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00 1169 (work in progress), August 2017. 1171 [ITU.T38.2010] 1172 International Telecommunications Union, "Procedures for 1173 real-time Group 3 facsimile communication over IP 1174 networks", ITU-T Recommendation T.38, September 2010. 1176 Authors' Addresses 1178 Christer Holmberg 1179 Ericsson 1180 Hirsalantie 11 1181 Jorvas 02420 1182 Finland 1184 Email: christer.holmberg@ericsson.com 1185 Roman Shpount 1186 TurboBridge 1187 4905 Del Ray Avenue, Suite 300 1188 Bethesda, MD 20814 1189 USA 1191 Phone: +1 (240) 292-6632 1192 Email: rshpount@turbobridge.com