idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-12.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 draft header indicates that this document updates RFC7345, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5763, but the abstract doesn't seem to mention this, which it should. 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 (May 21, 2016) is 2897 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: 'RFC5764' is mentioned on line 703, but not defined == Missing Reference: 'RFC4474' is mentioned on line 603, but not defined ** Obsolete undefined reference: RFC 4474 (Obsoleted by RFC 8224) == Missing Reference: 'RFCXXXX' is mentioned on line 853, but not defined == Missing Reference: 'ITU.T38.2010' is mentioned on line 822, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-12 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-29 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 4 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: November 22, 2016 May 21, 2016 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-12.txt 11 Abstract 13 This draft defines the SDP offer/answer procedures for negotiating 14 and establishing a DTLS association. The draft also defines the 15 criteria for when a new DTLS association must be established. 17 This draft defines a new SDP media-level attribute, 'dtls-id'. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 22, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Establishing a new DTLS Association . . . . . . . . . . . . . 3 56 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Change of Local Transport Parameters . . . . . . . . . . 4 58 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4 59 4. SDP dtls-id Attribute . . . . . . . . . . . . . . . . . . . . 4 60 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 61 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 7 63 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 7 64 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 8 65 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 9 66 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Transport Protocol Considerations . . . . . . . . . . . . . . 10 68 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 10 69 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 11 73 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 77 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 80 14.2. Informative References . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. 86 [RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This 87 specification defines general offer/answer procedures for DTLS, based 88 on the procedures in [RFC5763]. Other specifications, defining 89 specific DTLS usages, can then reference this specification, in order 90 to ensure that the DTLS aspects are common among all usages. Having 91 common procedures is essential when multiple usages share the same 92 DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. 94 As defined in [RFC5763], a new DTLS association MUST be established 95 when transport parameters are changed. Transport parameter change is 96 not well defined when Interactive Connectivity Establishment (ICE) 97 [RFC5245] is used. One possible way to determine a transport change 98 is based on ufrag change, but the ufrag value is changed both when 99 ICE is negotiated and when ICE restart [RFC5245] occurs. These 100 events do not always require a new DTLS association to be 101 established, but currently there is no way to explicitly indicate in 102 an SDP offer or answer whether a new DTLS association is required. 103 To solve that problem, this draft defines a new SDP attribute, 'dtls- 104 id'. The attribute contains a unique value associated with a DTLS 105 association, and by providing a new value in SDP offers and answers 106 the attribute can be used to indicate whether a new DTLS association 107 is to be established/re-established. 109 2. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Establishing a new DTLS Association 117 3.1. General 119 A new DTLS association MUST be established in the following cases: 121 o The DTLS roles change; 123 o One or more fingerprint values are modified, added or removed; or 125 o The intent to establish a new DTLS association is explicitly 126 signaled; 128 NOTE: The first two items list above are based on the procedures in 129 [RFC5763]. This specification adds the support for explicit 130 signaling. 132 Whenever an entity determines, based on the criteria above, that a 133 new DTLS association is required, the entity MUST initiate an 134 associated SDP offer/answer transaction, following the procedures in 135 Section 5. 137 The sections below describe typical cases where a new DTLS 138 association needs to be established. 140 3.2. Change of Local Transport Parameters 142 If an endpoint modifies its local transport parameters (address and/ 143 or port), and if the modification requires a new DTLS association, 144 the endpoint MUST change its DTLS role, change its fingerprint value, 145 and/or use the SDP 'dtls-id' attribute with a new value Section 4. 147 If the underlying transport explicitly prohibits a DTLS association 148 to span multiple transports, and if the transport is changed, a new 149 value MUST be assigned to the the SDP 'dtls-id' attribute. An 150 example of such case is when DTLS is carried over SCTP, as described 151 in [RFC6083]. 153 3.3. Change of ICE ufrag value 155 If an endpoint uses ICE, and modifies a local ufrag value, and if the 156 modification requires a new DTLS association, the endpoint MUST 157 either change its DTLS role, a fingerprint value and/or assign a new 158 value to the SDP 'dtls-id' attribute Section 4. 160 4. SDP dtls-id Attribute 162 The SDP 'dtls-id' attribute contains a unique value associated with a 163 DTLS association. 165 Name: dtls-id 167 Value: conn-value 169 Usage Level: media 171 Charset Dependent: no 173 Syntax: 175 conn-value = 1*256alphanum 177 Example: 179 a=dtls-id:abc3dl 181 A 'dtls-id' attribute that contains a new value indicates an 182 intention to establish a new DTLS association. A 'dtls-id' attribute 183 that contains a previously assigned value indicates an intention to 184 reuse an existing association. 186 There is no default value defined for the SDP 'dtls-id' attribute. 187 Implementations that wish to use the attribute MUST explicitly 188 include it in SDP offers and answers. If an offer or answer does not 189 contain an attribute (this could happen if the offerer or answerer 190 represents an existing implementation that has not been updated to 191 support the attribute defined in this specification or an 192 implementation which allocates a new temporary certificate for each 193 association and uses change in fingerprint to indicate new 194 association), other means needs to be used in order for endpoints to 195 determine whether an offer or answer is associated with an event that 196 requires the DTLS association to be re-established. 198 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'dtls- 199 id' attribute is 'IDENTICAL', which means that the attribute value 200 must be identical across all media descriptions being multiplexed 201 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 203 For RTP-based media, the 'dtls-id' attribute apply to whole 204 associated media description. The attribute MUST NOT be defined per 205 source (using the SDP 'ssrc' attribute [RFC5576]). 207 The SDP offer/answer [RFC3264] procedures associated with the 208 attribute are defined in Section 5 210 5. SDP Offer/Answer Procedures 212 5.1. General 214 This section defines the generic SDP offer/answer procedures for 215 negotiating a DTLS association. Additional procedures (e.g. 216 regarding usage of specific SDP attributes etc) for individual DTLS 217 usages (e.g. SRTP-DTLS) are outside the scope of this specification, 218 and need to be specified in a usage specific specification. 220 NOTE: The procedures in this section are generalizations of 221 procedures first specified in SRTP-DTLS [RFC5763], with the addition 222 of usage of the SDP 'dtls-id' attribute. That document is herein 223 revised to make use of these new procedures. 225 The procedures in this section apply to an SDP media description 226 ("m=" line) associated a DTLS-protected media/data. 228 When an offerer needs to establish a new DTLS association, and if an 229 unreliable transport (e.g. UDP) is used, the offerer MUST allocate a 230 new transport for the offer in such a way that the offerer can 231 disambiguate any packets associated with the new DTLS association 232 from any packets associated with any other DTLS association. This 233 typically means using a local address and or port, or a set of ICE 234 candidates (see Section 6), which were not recently used for any 235 other DTLS association. 237 When an answerer needs to establish a new DTLS association, if 238 unreliable transport is used, and if the offerer did not allocate a 239 new transport, the answerer MUST allocate a new transport for the 240 offer in answer a way that it can disambiguate any packets associated 241 with new DTLS association from any packets associated with any other 242 DTLS association. This typically means using a local address and or 243 port, or a set of ICE candidates (see Section 6), which were not 244 recently used for any other DTLS association. 246 In order to negotiate a DTLS association, the following SDP 247 attributes are used: 249 o The SDP 'setup' attribute, defined in [RFC4145], is used to 250 negotiate the DTLS roles; 252 o The SDP 'fingerprint' attribute, defined in [RFC4572], is used to 253 provide a fingerprint value; and 255 o The SDP 'dtls-id' attribute, defined in this specification, 256 indicates a unique value associated with the DTLS association. 257 The attribute value can be used to explicitly indicate the 258 intention of establishing a new DTLS association. 260 This specification does not define the usage of the SDP 'connection' 261 attribute [RFC4145] for negotiating a DTLS connection. However, the 262 attribute MAY be used if the DTLS association is used together with 263 another protocol, e.g. SCTP or TCP, for which the usage of the 264 attribute has been defined. 266 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 267 'setup' attribute 'holdconn' value when negotiating a DTLS 268 association. 270 Endpoints MUST support SHA-256 for generating and verifying any 271 fingerprint value associated with the DTLS association. The use of 272 SHA-256 is preferred. 274 Endpoints MUST, at a minimum, support 275 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 276 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 277 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 278 Secrecy (PFS) cipher suites over non-PFS cipher suites. 279 Implementations SHOULD disable TLS-level compression. 281 The certificate received during the DTLS handshake MUST match at 282 least one of the certificate fingerprints received in SDP 283 'fingerprint' attributes. If no fingerprint matches the hashed 284 certificate, then an endpoint MUST tear down the media session 285 immediately. Note that it is permissible to wait until the other 286 side's fingerprint has been received before establishing the 287 connection; however, this may have undesirable latency effects. 289 SDP offerers and answerers might reuse certificates across multiple 290 DTLS associations, and provide identical fingerprint values for each 291 DTLS association. It MUST be ensured that the combination of the 292 fingerprint values and the SDP 'dtls-id' attribute value is unique 293 across all DTLS associations. 295 If an SDP offerer or answerer generates a new temporary self-signed 296 certificate for each new DTLS association, they can omit the SDP 297 'dtls-id' attribute. 299 5.2. Generating the Initial SDP Offer 301 When the offerer sends the initial offer, and the offerer wants to 302 establish a DTLS association, it MUST insert an SDP 'dtls-id' 303 attribute with a new value in the offer. In addition, the offerer 304 MUST insert an SDP 'setup' attribute according to the procedures in 305 [RFC4145], and one or more SDP 'fingerprint' attributes according to 306 the procedures in [RFC4572], in the offer. 308 If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 309 'passive' value, the offerer MUST be prepared to receive a DTLS 310 ClientHello message (if a new DTLS association is established by the 311 answerer) from the answerer before it receives the SDP answer. 313 5.3. Generating the Answer 315 If an answerer receives an offer that contains an SDP 'dtls-id' 316 attribute with a new value, or if the answerer receives an offer that 317 contains an 'dtls-id' attribute with a previously assigned value and 318 the answerer determines (based on the criteria for establishing a new 319 DTLS association) that a new DTLS association is to be established, 320 the answerer MUST insert a new value in the associated answer. In 321 addition, the answerer MUST insert an SDP 'setup' attribute according 322 to the procedures in [RFC4145], and one or more SDP 'fingerprint' 323 attributes according to the procedures in [RFC4572], in the answer. 325 If an answerer receives an offer that contains an SDP 'dtls-id' 326 attribute with a new value, and if the answerer does not accept the 327 establishment of a new DTLS association, the answerer MUST reject the 328 "m=" lines associated with the suggested DTLS association [RFC3264]. 330 If an answerer receives an offer that contains a 'dtls-id' attribute 331 with a previously assigned value, and if the answerer determines that 332 a new DTLS association is not to be established, the answerer MUST 333 insert a 'dtls-id' attribute with the previously assigned value in 334 the associated answer. In addition, the answerer MUST insert an SDP 335 'setup' attribute with a value that does not change the previously 336 negotiated DTLS roles, and one or more SDP 'fingerprint' attributes 337 values that do not change the previously sent fingerprints, in the 338 answer. 340 If the answerer receives an offer that does not contain an SDP 'dtls- 341 id' attribute, the answerer MUST NOT insert a 'dtls-id' attribute in 342 the answer. 344 If a new DTLS association is to be established, and if the answerer 345 inserts an SDP 'setup' attribute with an 'active' value in the 346 answer, the answerer MUST initiate a DTLS handshake by sending a DTLS 347 ClientHello message towards the offerer. 349 5.4. Offerer Processing of the SDP Answer 351 When an offerer receives an answer that contains an SDP 'dtls-id' 352 attribute with a new value, and if the offerer becomes DTLS client 353 (based on the value of the SDP 'setup' attribute value [RFC4145]), 354 the offerer MUST establish a DTLS association. If the offerer 355 becomes DTLS server, it MUST wait for the answerer to establish the 356 DTLS association. 358 If the answer contains an SDP 'dtls-id' attribute with a previously 359 assigned value, the offerer will continue using the previously 360 established DTLS association. It is considered an error case if the 361 answer contains a 'dtls-id' attribute with a previously assigned 362 value, and a DTLS association does not exist. 364 An offerer needs to be able to handle error conditions that can occur 365 during an offer/answer transaction, e.g. if an answer contains an SDP 366 'dtls-id' attribute with a previosuly assigned value even if no DTLS 367 association exists, or if the answer contains one or more new 368 fingerprint values for an existing DTLS association. If such error 369 case occurs, the offerer SHOULD terminate the associated DTLS 370 association (if it exists) and send a new offer in order to terminate 371 each media stream using the DTLS association, by setting the 372 associated port value to zero [RFC4145]. 374 5.5. Modifying the Session 376 When the offerer sends a subsequent offer, and if the offerer wants 377 to establish a new DTLS association, the offerer MUST insert an SDP 378 'dtls-id' attribute with a new value in the offer. In addition, the 379 offerer MUST insert an SDP 'setup' attribute according to the 380 procedures in [RFC4145], and one or more SDP 'fingerprint' attributes 381 according to the procedures in [RFC4572], in the offer. 383 when the offerer sends a subsequent offer, and the offerer does not 384 want to establish a new DTLS association, and if a previously 385 established DTLS association exists, the offerer MUST insert an SDP 386 'dtls-id' attribute with a previously assigned value in the offer. 387 In addition, the offerer MUST insert an SDP 'setup' attribute with a 388 value that does not change the previously negotiated DTLS roles, and 389 one or more SDP 'fingerprint' attributes with values that do not 390 change the previously sent fingerprints, in the offer. 392 NOTE: When a new DTLS association is established, each endpoint needs 393 to be prepared to receive data on both the new and old DTLS 394 associations as long as both are alive. 396 6. ICE Considerations 398 When ICE is used, the ICE connectivity checks are performed before 399 the DTLS handshake begins. Note that if aggressive nomination mode 400 is used, multiple candidate pairs may be marked valid before ICE 401 finally converges on a single candidate pair. 403 NOTE: Aggressive nomination has been deprecated from ICE, but must 404 still be supported for backwards compatibility reasons. 406 When new DTLS association is established over an unreliable 407 transport, in order to disambiguate any packets associated with newly 408 established DTLS association, at least one of the endpoints MUST 409 allocate a completely new set of ICE candidates which were not 410 recently used for any other DTLS association. This means that 411 answerer cannot initiate a new DTLS association unless the offerer 412 initiated ICE restart [RFC5245]. If the answerer wants to initiate a 413 new DTLS association, it needs to initiate an ICE restart on its own. 414 However, an ICE restart does not by default require a new DTLS 415 association to be established. 417 NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets 418 are sent directly over UDP, not over DTLS. [RFC3261] describes how 419 to demultiplex STUN packets from DTLS packets and SRTP packets. 421 As defined in [RFC5763], each ICE candidate associated with a 422 component is treated as being part of the same DTLS association. 423 Therefore, from a DTLS perspective it is not considered a change of 424 local transport parameters when an endpoint switches between those 425 ICE candidates. 427 7. Transport Protocol Considerations 429 7.1. Transport Re-Usage 431 If DTLS is transported on top of a connection-oriented transport 432 protocol (e.g. TCP or SCTP), where all IP packets are acknowledged, 433 all DTLS packets associated with a previous DTLS association MUST be 434 acknowledged (or timed out) before a new DTLS association can be 435 established on the same transport. 437 8. SIP Considerations 439 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 440 signal protocol for establishing a multimedia session, dialogs 441 [RFC3261] might be established between the caller and multiple 442 callees. This is referred to as forking. If forking occurs, 443 separate DTLS associations MUST be established between the caller and 444 each callee. 446 It is possible to send an INVITE request which does not contain an 447 SDP offer. Such INVITE request is often referred to as an 'empty 448 INVITE', or an 'offer-less INVITE'. The receiving endpoint will 449 include the SDP offer in a response associated with the response. 450 When the endpoint generates such SDP offer, if a previously 451 established DTLS association exists, the offerer SHOULD insert an SDP 452 'dtls-id' attribute, and one or more SDP 'fingerprint' attributes, 453 with previously assigned attribute values. If a previously 454 established DTLS association did not exists offer SHOULD be generated 455 based on the same rules as new offer Section 5.2. Regardless of the 456 previous existence of DTLS association, the SDP 'setup' attribute 457 MUST be included according to rules defiend in [RFC4145] and if ICE 458 is used, ICE restart MUST be initiated as defined in [RFC5763]. 460 9. RFC Updates 462 9.1. General 464 This section updates specifications that use DTLS-protected media, in 465 order to reflect the procedures defined in this specification. 467 9.2. Update to RFC 5763 469 Update to section 5: 470 -------------------- 472 OLD TEXT: 474 5. Establishing a Secure Channel 476 The two endpoints in the exchange present their identities as part of 477 the DTLS handshake procedure using certificates. This document uses 478 certificates in the same style as described in "Connection-Oriented 479 Media Transport over the Transport Layer Security (TLS) Protocol in 480 the Session Description Protocol (SDP)" [RFC4572]. 482 If self-signed certificates are used, the content of the 483 subjectAltName attribute inside the certificate MAY use the uniform 484 resource identifier (URI) of the user. This is useful for debugging 485 purposes only and is not required to bind the certificate to one of 486 the communication endpoints. The integrity of the certificate is 487 ensured through the fingerprint attribute in the SDP. The 488 subjectAltName is not an important component of the certificate 489 verification. 491 The generation of public/private key pairs is relatively expensive. 492 Endpoints are not required to generate certificates for each session. 494 The offer/answer model, defined in [RFC3264], is used by protocols 495 like the Session Initiation Protocol (SIP) [RFC3261] to set up 496 multimedia sessions. In addition to the usual contents of an SDP 497 [RFC4566] message, each media description ("m=" line and associated 498 parameters) will also contain several attributes as specified in 499 [RFC5764], [RFC4145], and [RFC4572]. 501 When an endpoint wishes to set up a secure media session with another 502 endpoint, it sends an offer in a SIP message to the other endpoint. 503 This offer includes, as part of the SDP payload, the fingerprint of 504 the certificate that the endpoint wants to use. The endpoint SHOULD 505 send the SIP message containing the offer to the offerer's SIP proxy 506 over an integrity protected channel. The proxy SHOULD add an 507 Identity header field according to the procedures outlined in 508 [RFC4474]. The SIP message containing the offer SHOULD be sent to 509 the offerer's SIP proxy over an integrity protected channel. When 510 the far endpoint receives the SIP message, it can verify the identity 511 of the sender using the Identity header field. Since the Identity 512 header field is a digital signature across several SIP header fields, 513 in addition to the body of the SIP message, the receiver can also be 514 certain that the message has not been tampered with after the digital 515 signature was applied and added to the SIP message. 517 The far endpoint (answerer) may now establish a DTLS association with 518 the offerer. Alternately, it can indicate in its answer that the 519 offerer is to initiate the TLS association. In either case, mutual 520 DTLS certificate-based authentication will be used. After completing 521 the DTLS handshake, information about the authenticated identities, 522 including the certificates, are made available to the endpoint 523 application. The answerer is then able to verify that the offerer's 524 certificate used for authentication in the DTLS handshake can be 525 associated to the certificate fingerprint contained in the offer in 526 the SDP. At this point, the answerer may indicate to the end user 527 that the media is secured. The offerer may only tentatively accept 528 the answerer's certificate since it may not yet have the answerer's 529 certificate fingerprint. 531 When the answerer accepts the offer, it provides an answer back to 532 the offerer containing the answerer's certificate fingerprint. At 533 this point, the offerer can accept or reject the peer's certificate 534 and the offerer can indicate to the end user that the media is 535 secured. 537 Note that the entire authentication and key exchange for securing the 538 media traffic is handled in the media path through DTLS. The 539 signaling path is only used to verify the peers' certificate 540 fingerprints. 542 The offer and answer MUST conform to the following requirements. 544 o The endpoint MUST use the setup attribute defined in [RFC4145]. 545 The endpoint that is the offerer MUST use the setup attribute 546 value of setup:actpass and be prepared to receive a client_hello 547 before it receives the answer. The answerer MUST use either a 548 setup attribute value of setup:active or setup:passive. Note that 549 if the answerer uses setup:passive, then the DTLS handshake will 550 not begin until the answerer is received, which adds additional 551 latency. setup:active allows the answer and the DTLS handshake to 552 occur in parallel. Thus, setup:active is RECOMMENDED. Whichever 553 party is active MUST initiate a DTLS handshake by sending a 554 ClientHello over each flow (host/port quartet). 556 o The endpoint MUST NOT use the connection attribute defined in 557 [RFC4145]. 559 o The endpoint MUST use the certificate fingerprint attribute as 560 specified in [RFC4572]. 562 o The certificate presented during the DTLS handshake MUST match the 563 fingerprint exchanged via the signaling path in the SDP. The 564 security properties of this mechanism are described in Section 8. 566 o If the fingerprint does not match the hashed certificate, then the 567 endpoint MUST tear down the media session immediately. Note that 568 it is permissible to wait until the other side's fingerprint has 569 been received before establishing the connection; however, this 570 may have undesirable latency effects. 572 NEW TEXT: 574 5. Establishing a Secure Channel 576 The two endpoints in the exchange present their identities as part of 577 the DTLS handshake procedure using certificates. This document uses 578 certificates in the same style as described in "Connection-Oriented 579 Media Transport over the Transport Layer Security (TLS) Protocol in 580 the Session Description Protocol (SDP)" [RFC4572]. 582 If self-signed certificates are used, the content of the 583 subjectAltName attribute inside the certificate MAY use the uniform 584 resource identifier (URI) of the user. This is useful for debugging 585 purposes only and is not required to bind the certificate to one of 586 the communication endpoints. The integrity of the certificate is 587 ensured through the fingerprint attribute in the SDP. 589 The generation of public/private key pairs is relatively expensive. 590 Endpoints are not required to generate certificates for each session. 592 The offer/answer model, defined in [RFC3264], is used by protocols 593 like the Session Initiation Protocol (SIP) [RFC3261] to set up 594 multimedia sessions. 596 When an endpoint wishes to set up a secure media session with another 597 endpoint, it sends an offer in a SIP message to the other endpoint. 598 This offer includes, as part of the SDP payload, a fingerprint of 599 a certificate that the endpoint wants to use. The endpoint SHOULD 600 send the SIP message containing the offer to the offerer's SIP proxy 601 over an integrity protected channel. The proxy SHOULD add an 602 Identity header field according to the procedures outlined in 603 [RFC4474]. The SIP message containing the offer SHOULD be sent to 604 the offerer's SIP proxy over an integrity protected channel. When 605 the far endpoint receives the SIP message, it can verify the identity 606 of the sender using the Identity header field. Since the Identity 607 header field is a digital signature across several SIP header fields, 608 in addition to the body of the SIP message, the receiver can also be 609 certain that the message has not been tampered with after the digital 610 signature was applied and added to the SIP message. 612 The far endpoint (answerer) may now establish a DTLS association with 613 the offerer. Alternately, it can indicate in its answer that the 614 offerer is to initiate the DTLS association. In either case, mutual 615 DTLS certificate-based authentication will be used. After completing 616 the DTLS handshake, information about the authenticated identities, 617 including the certificates, are made available to the endpoint 618 application. The answerer is then able to verify that the offerer's 619 certificate used for authentication in the DTLS handshake can be 620 associated to the certificate fingerprint contained in the offer in 621 the SDP. At this point, the answerer may indicate to the end user 622 that the media is secured. The offerer may only tentatively accept 623 the answerer's certificate since it may not yet have the answerer's 624 certificate fingerprint. 626 When the answerer accepts the offer, it provides an answer back to 627 the offerer containing the answerer's certificate fingerprint. At 628 this point, the offerer can accept or reject the peer's certificate 629 and the offerer can indicate to the end user that the media is 630 secured. 632 Note that the entire authentication and key exchange for securing the 633 media traffic is handled in the media path through DTLS. The 634 signaling path is only used to verify the peers' certificate 635 fingerprints. 637 The offerer and answerer MUST follow the SDP offer/answer procedures 638 defined in [RFCXXXX]. 640 Update to section 6.6: 641 ---------------------- 643 OLD TEXT: 645 6.6. Session Modification 647 Once an answer is provided to the offerer, either endpoint MAY 648 request a session modification that MAY include an updated offer. 649 This session modification can be carried in either an INVITE or 650 UPDATE request. The peers can reuse the existing associations if 651 they are compatible (i.e., they have the same key fingerprints and 652 transport parameters), or establish a new one following the same 653 rules are for initial exchanges, tearing down the existing 654 association as soon as the offer/answer exchange is completed. Note 655 that if the active/passive status of the endpoints changes, a new 656 connection MUST be established. 658 NEW TEXT: 660 6.6. Session Modification 662 Once an answer is provided to the offerer, either endpoint MAY 663 request a session modification that MAY include an updated offer. 664 This session modification can be carried in either an INVITE or 665 UPDATE request. The peers can reuse an existing DTLS association, 666 or establish a new one, following the procedures in [RFCXXXX]. 668 Update to section 6.7.1: 669 ------------------------ 671 OLD TEXT: 673 6.7.1. ICE Interaction 675 Interactive Connectivity Establishment (ICE), as specified in 676 [RFC5245], provides a methodology of allowing participants in 677 multimedia sessions to verify mutual connectivity. When ICE is being 678 used, the ICE connectivity checks are performed before the DTLS 679 handshake begins. Note that if aggressive nomination mode is used, 680 multiple candidate pairs may be marked valid before ICE finally 681 converges on a single candidate pair. Implementations MUST treat all 682 ICE candidate pairs associated with a single component as part of the 683 same DTLS association. Thus, there will be only one DTLS handshake 684 even if there are multiple valid candidate pairs. Note that this may 685 mean adjusting the endpoint IP addresses if the selected candidate 686 pair shifts, just as if the DTLS packets were an ordinary media 687 stream. 689 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 690 packets are sent directly over UDP, not over DTLS. [RFC5764] 691 describes how to demultiplex STUN packets from DTLS packets and SRTP 692 packets. 694 NEW TEXT: 696 6.7.1. ICE Interaction 698 The Interactive Connectivity Establishment (ICE) [RFC5245] 699 considerations for DTLS-protected media are described in 700 [RFCXXXX]. 702 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 703 packets are sent directly over UDP, not over DTLS. [RFC5764] 704 describes how to demultiplex STUN packets from DTLS packets and SRTP 705 packets. 707 9.3. Update to RFC 7345 709 Update to section 4: 710 -------------------- 712 OLD TEXT: 714 4. SDP Offerer/Answerer Procedures 716 4.1. General 718 An endpoint (i.e., both the offerer and the answerer) MUST create an 719 SDP media description ("m=" line) for each UDPTL-over-DTLS media 720 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 721 "proto" field of the "m=" line. 723 The procedures in this section apply to an "m=" line associated with 724 a UDPTL-over-DTLS media stream. 726 In order to negotiate a UDPTL-over-DTLS media stream, the following 727 SDP attributes are used: 729 o The SDP attributes defined for UDPTL over UDP, as described in 730 [ITU.T38.2010]; and 732 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 733 described in this section. 735 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 737 In order to negotiate the TLS roles for the UDPTL-over-DTLS transport 738 connection, the endpoint MUST use the SDP "setup" attribute 739 [RFC4145]. 741 If the endpoint supports, and is willing to use, a cipher suite with 742 an associated certificate, the endpoint MUST include an SDP 743 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 744 for generating and verifying the SDP "fingerprint" attribute value. 745 The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST 746 support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 747 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 748 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 749 Secrecy (PFS) cipher suites over non-PFS cipher suites. 751 Implementations SHOULD disable TLS-level compression. 753 If a cipher suite with an associated certificate is selected during 754 the DTLS handshake, the certificate received during the DTLS 755 handshake MUST match the fingerprint received in the SDP 756 "fingerprint" attribute. If the fingerprint does not match the 757 hashed certificate, then the endpoint MUST tear down the media 758 session immediately. Note that it is permissible to wait until the 759 other side's fingerprint has been received before establishing the 760 connection; however, this may have undesirable latency effects. 762 4.2. Generating the Initial Offer 764 The offerer SHOULD assign the SDP "setup" attribute with a value of 765 "actpass", unless the offerer insists on being either the sender or 766 receiver of the DTLS ClientHello message, in which case the offerer 767 can use either a value of "active" (the offerer will be the sender of 768 ClientHello) or "passive" (the offerer will be the receiver of 769 ClientHello). The offerer MUST NOT assign an SDP "setup" attribute 770 with a "holdconn" value. 772 If the offerer assigns the SDP "setup" attribute with a value of 773 "actpass" or "passive", the offerer MUST be prepared to receive a 774 DTLS ClientHello message before it receives the SDP answer. 776 4.3. Generating the Answer 778 If the answerer accepts the offered UDPTL-over-DTLS transport 779 connection, in the associated SDP answer, the answerer MUST assign an 780 SDP "setup" attribute with a value of either "active" or "passive", 781 according to the procedures in [RFC4145]. The answerer MUST NOT 782 assign an SDP "setup" attribute with a value of "holdconn". 784 If the answerer assigns an SDP "setup" attribute with a value of 785 "active" value, the answerer MUST initiate a DTLS handshake by 786 sending a DTLS ClientHello message on the negotiated media stream, 787 towards the IP address and port of the offerer. 789 4.4. Offerer Processing of the Answer 791 When the offerer receives an SDP answer, if the offerer ends up being 792 active it MUST initiate a DTLS handshake by sending a DTLS 793 ClientHello message on the negotiated media stream, towards the IP 794 address and port of the answerer. 796 4.5. Modifying the Session 798 Once an offer/answer exchange has been completed, either endpoint MAY 799 send a new offer in order to modify the session. The endpoints can 800 reuse the existing DTLS association if the key fingerprint values and 801 transport parameters indicated by each endpoint are unchanged. 802 Otherwise, following the rules for the initial offer/answer exchange, 803 the endpoints can negotiate and create a new DTLS association and, 804 once created, delete the previous DTLS association, following the 805 same rules for the initial offer/answer exchange. Each endpoint 806 needs to be prepared to receive data on both the new and old DTLS 807 associations as long as both are alive. 809 NEW TEXT: 811 4. SDP Offerer/Answerer Procedures 813 An endpoint (i.e., both the offerer and the answerer) MUST create an 814 SDP media description ("m=" line) for each UDPTL-over-DTLS media 815 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 816 "proto" field of the "m=" line. 818 The offerer and answerer MUST follow the SDP offer/answer procedures 819 defined in [RFCXXXX] in order to negotiate the DTLS association 820 associated with the UDPTL-over-DTLS media stream. In addition, 821 the offerer and answerer MUST use the SDP attributes defined for 822 UDPTL over UDP, as defined in [ITU.T38.2010]. 824 Update to section 5.2.1: 825 ------------------------ 827 OLD TEXT: 829 5.2.1. ICE Usage 831 When Interactive Connectivity Establishment (ICE) [RFC5245] is being 832 used, the ICE connectivity checks are performed before the DTLS 833 handshake begins. Note that if aggressive nomination mode is used, 834 multiple candidate pairs may be marked valid before ICE finally 835 converges on a single candidate pair. User Agents (UAs) MUST treat 836 all ICE candidate pairs associated with a single component as part of 837 the same DTLS association. Thus, there will be only one DTLS 838 handshake even if there are multiple valid candidate pairs. Note 839 that this may mean adjusting the endpoint IP addresses if the 840 selected candidate pair shifts, just as if the DTLS packets were an 841 ordinary media stream. In the case of an ICE restart, the DTLS 842 handshake procedure is repeated, and a new DTLS association is 843 created. Once the DTLS handshake is completed and the new DTLS 844 association has been created, the previous DTLS association is 845 deleted. 847 NEW TEXT: 849 5.2.1. ICE Usage 851 The Interactive Connectivity Establishment (ICE) [RFC5245] 852 considerations for DTLS-protected media are described in 853 [RFCXXXX]. 855 10. Security Considerations 857 This specification does not modify the security considerations 858 associated with DTLS, or the SDP offer/answer mechanism. In addition 859 to the introduction of the SDP 'dtls-id' attribute, the specification 860 simply clarifies the procedures for negotiating and establishing a 861 DTLS association. 863 11. IANA Considerations 865 This document updates the "Session Description Protocol Parameters" 866 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 867 it adds the SDP dtls-id attribute to the table for SDP media level 868 attributes. 870 Attribute name: dtls-id 871 Type of attribute: media-level 872 Subject to charset: no 873 Purpose: Indicate whether a new DTLS association is to be 874 established/re-established. 875 Appropriate Values: see Section 4 876 Contact name: Christer Holmberg 877 Category: IDENTICAL 879 12. Acknowledgements 881 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, 882 Charles Eckel and Gonzalo Salgueiro for providing comments and 883 suggestions on the draft. 885 13. Change Log 887 [RFC EDITOR NOTE: Please remove this section when publishing] 889 Changes from draft-ietf-mmusic-sdp-dtls-11 891 o Attribute name changed to dtls-id 892 o Additional text based on comments from Roman Shpount. 894 Changes from draft-ietf-mmusic-sdp-dtls-10 896 o Modified document to use dtls-id instead of dtls-connection 898 o Changes are based on comments from Eric Rescorla, Justin Uberti, 899 and Paul Kyzivat. 901 Changes from draft-ietf-mmusic-sdp-dtls-08 903 o Offer/Answer section modified in order to allow sending of 904 multiple SDP 'fingerprint' attributes. 906 o Terminology made consistent: 'DTLS connection' replaced with 'DTLS 907 association'. 909 o Editorial changes based on comments from Paul Kyzivat. 911 Changes from draft-ietf-mmusic-sdp-dtls-07 913 o Reference to RFC 7315 replaced with reference to RFC 7345. 915 Changes from draft-ietf-mmusic-sdp-dtls-06 917 o Text on restrictions regarding spanning a DTLS association over 918 multiple transports added. 920 o Mux category added to IANA Considerations. 922 o Normative text regarding mux category and source-specific 923 applicability added. 925 o Reference to RFC 7315 added. 927 o Clarified that offerer/answerer that has not been updated to 928 support this specification will not include the dtls-id attribute 929 in offers and answers. 931 o Editorial corrections based on WGLC comments from Charles Eckel. 933 Changes from draft-ietf-mmusic-sdp-dtls-05 935 o Text on handling offer/answer error conditions added. 937 Changes from draft-ietf-mmusic-sdp-dtls-04 939 o Editorial nits fixed based on comments from Paul Kyzivat: 941 Changes from draft-ietf-mmusic-sdp-dtls-03 943 o Changes based on comments from Paul Kyzivat: 945 o - Modification of dtls-id attribute section. 947 o - Removal of IANA considerations subsection. 949 o - Making note into normative text in o/a section. 951 o Changes based on comments from Martin Thompson: 953 o - Abbreviations section removed. 955 o - Clarify that a new DTLS association requires a new o/a 956 transaction. 958 Changes from draft-ietf-mmusic-sdp-dtls-02 960 o - Updated RFCs added to boilerplate. 962 Changes from draft-ietf-mmusic-sdp-dtls-01 964 o - Annex regarding 'dtls-id-id' attribute removed. 966 o - Additional SDP offer/answer procedures, related to certificates, 967 added. 969 o - Updates to RFC 5763 and RFC 7345 added. 971 o - Transport protocol considerations added. 973 Changes from draft-ietf-mmusic-sdp-dtls-00 975 o - SDP 'connection' attribute replaced with new 'dtls-id' 976 attribute. 978 o - IANA Considerations added. 980 o - E-mail regarding 'dtls-id-id' attribute added as Annex. 982 Changes from draft-holmberg-mmusic-sdp-dtls-01 984 o - draft-ietf-mmusic version of draft submitted. 986 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 987 with another expired draft. 989 o - Clarify that if ufrag in offer is unchanged, it must be 990 unchanged in associated answer. 992 o - SIP Considerations section added. 994 o - Section about multiple SDP fingerprint attributes added. 996 Changes from draft-holmberg-mmusic-sdp-dtls-00 998 o - Editorial changes and clarifications. 1000 14. References 1002 14.1. Normative References 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, 1006 DOI 10.17487/RFC2119, March 1997, 1007 . 1009 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1010 A., Peterson, J., Sparks, R., Handley, M., and E. 1011 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1012 DOI 10.17487/RFC3261, June 2002, 1013 . 1015 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1016 with Session Description Protocol (SDP)", RFC 3264, 1017 DOI 10.17487/RFC3264, June 2002, 1018 . 1020 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1021 the Session Description Protocol (SDP)", RFC 4145, 1022 DOI 10.17487/RFC4145, September 2005, 1023 . 1025 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1026 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1027 July 2006, . 1029 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1030 Transport Layer Security (TLS) Protocol in the Session 1031 Description Protocol (SDP)", RFC 4572, 1032 DOI 10.17487/RFC4572, July 2006, 1033 . 1035 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1036 (ICE): A Protocol for Network Address Translator (NAT) 1037 Traversal for Offer/Answer Protocols", RFC 5245, 1038 DOI 10.17487/RFC5245, April 2010, 1039 . 1041 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1042 for Establishing a Secure Real-time Transport Protocol 1043 (SRTP) Security Context Using Datagram Transport Layer 1044 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1045 2010, . 1047 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 1048 Transport Layer (UDPTL) over Datagram Transport Layer 1049 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 1050 2014, . 1052 14.2. Informative References 1054 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1055 Media Attributes in the Session Description Protocol 1056 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1057 . 1059 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1060 Transport Layer Security (DTLS) for Stream Control 1061 Transmission Protocol (SCTP)", RFC 6083, 1062 DOI 10.17487/RFC6083, January 2011, 1063 . 1065 [I-D.ietf-mmusic-sdp-mux-attributes] 1066 Nandakumar, S., "A Framework for SDP Attributes when 1067 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 1068 (work in progress), January 2016. 1070 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1071 Holmberg, C., Alvestrand, H., and C. Jennings, 1072 "Negotiating Media Multiplexing Using the Session 1073 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1074 negotiation-29 (work in progress), April 2016. 1076 Authors' Addresses 1077 Christer Holmberg 1078 Ericsson 1079 Hirsalantie 11 1080 Jorvas 02420 1081 Finland 1083 Email: christer.holmberg@ericsson.com 1085 Roman Shpount 1086 TurboBridge 1087 4905 Del Ray Avenue, Suite 300 1088 Bethesda, MD 20814 1089 USA 1091 Phone: +1 (240) 292-6632 1092 Email: rshpount@turbobridge.com