idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 17 characters in excess of 72. -- The draft header indicates that this document updates RFC5763, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7315, 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) (Using the creation date from RFC7315, updated by this document, for RFC5378 checks: 2005-10-20) -- 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 (February 21, 2016) is 2980 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 663, but not defined == Missing Reference: 'RFC4474' is mentioned on line 563, but not defined ** Obsolete undefined reference: RFC 4474 (Obsoleted by RFC 8224) == Missing Reference: 'RFCXXXX' is mentioned on line 811, but not defined == Missing Reference: 'ITU.T38.2010' is mentioned on line 780, but not defined == Unused Reference: 'RFC5234' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'RFC7315' is defined on line 981, but no explicit reference was found in the text ** 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) ** Downref: Normative reference to an Informational RFC: RFC 7315 == 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-25 Summary: 6 errors (**), 0 flaws (~~), 9 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,7315 (if approved) R. Shpount 5 Intended status: Standards Track TurboBridge 6 Expires: August 24, 2016 February 21, 2016 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-07.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- 18 connection'. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 24, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Establishing a new DTLS Association . . . . . . . . . . . . . 3 57 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Change of Local Transport Parameters . . . . . . . . . . 3 59 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4 60 3.4. Multiple SDP fingerprint attributes . . . . . . . . . . . 4 61 4. SDP dtls-connection Attribute . . . . . . . . . . . . . . . . 4 62 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 6 65 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 7 66 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 7 67 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 8 68 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Transport Protocol Considerations . . . . . . . . . . . . . . 9 70 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 9 71 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 10 75 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 15 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 79 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 82 14.2. Informative References . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. This 88 draft defines the SDP Offer/Answer [RFC3264] procedures for 89 negotiation DTLS in general, based on the procedures in [RFC5763]. 91 As defined in [RFC5763], a new DTLS association MUST be established 92 when transport parameters are changed. Transport parameter change is 93 not well defined when Interactive Connectivity Establishment (ICE) 94 [RFC5245] is used. One possible way to determine a transport change 95 is based on ufrag change, but the ufrag value is changed both when 96 ICE is negotiated and when ICE restart [RFC5245] occurs. These 97 events do not always require a new DTLS association to be 98 established, but currently there is no way to explicitly indicate in 99 an SDP offer or answer whether a new DTLS association is required. 100 To solve that problem, this draft defines a new SDP attribute, 'dtls- 101 connection'. The attribute is used in SDP offers and answers to 102 explicitly indicate whether a new DTLS association is to be 103 established/re-established. The attribute can be used both with and 104 without ICE. 106 2. Conventions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Establishing a new DTLS Association 114 3.1. General 116 A new DTLS association MUST be established in the following cases: 118 o The DTLS roles change; 120 o The fingerprint (certificate) value changes; or 122 o The establishment of a new DTLS association is explicitly 123 signaled; 125 NOTE: The first two items list above are based on the procedures in 126 [RFC5763]. This draft adds the support for explicit signaling. 128 Whenever an entity determines, based on the criteria above, that a 129 new DTLS association is required, the entity MUST initiate an 130 associated SDP offer/answer transaction, following the procedures in 131 Section 5. 133 The sections below describe typical cases where a new DTLS 134 association needs to be established. 136 3.2. Change of Local Transport Parameters 138 If an endpoint modifies its local transport parameters (address and/ 139 or port), and if the modification requires a new DTLS association, 140 the endpoint MUST change its DTLS role, change its fingerprint value, 141 and/or use the SDP 'dtls-connection' attribute with a 'new' value 142 Section 4. 144 If the underlying transport explicitly prohibits a DTLS association 145 to span multiple transports, the SDP 'dtls-connection' attribute MUST 146 be set to 'new' if the transport is changed. An example of such case 147 is when DTLS is carried over SCTP, as described in [RFC6083]. 149 3.3. Change of ICE ufrag value 151 If an endpoint uses ICE, and modifies a local ufrag value, and if the 152 modification requires a new DTLS association, the endpoint MUST 153 either change its DTLS role, its fingerprint value and/or use the SDP 154 'dtls-connection' attribute with a 'new' value Section 4. 156 3.4. Multiple SDP fingerprint attributes 158 It is possible to associate multiple SDP fingerprint attribute values 159 to an 'm-' line. If any of the attribute values associated with an 160 'm-' line are removed, or if any new attribute values are added, it 161 is considered a fingerprint value change. 163 4. SDP dtls-connection Attribute 165 The SDP 'connection' attribute [RFC4145] was originally defined for 166 connection-oriented protocols, e.g. TCP and TLS. This section 167 defines a similar attribute, 'dtls-connection', to be used with DTLS. 169 Name: dtls-connection 171 Value: conn-value 173 Usage Level: media 175 Charset Dependent: no 177 Syntax: 179 conn-value = "new" / "existing" 181 Example: 183 a=dtls-connection:existing 185 A 'dtls-connection' attribute value of 'new' indicates that a new 186 DTLS association MUST be established. A 'dtls-connection' attribute 187 value of 'existing' indicates that a new DTLS association MUST NOT be 188 established. 190 Unlike the SDP 'connection' attribute for TLS, there is no default 191 value defined for the 'dtls-connection' attribute. Implementations 192 that wish to use the attribute MUST explicitly include it in SDP 193 offers and answers. If an offer or answer does not contain an 194 attribute (this could happen if the offerer or answerer represents an 195 existing implementation that has not been updated to support the 196 attribute defined in this specification), other means needs to be 197 used in order for endpoints to determine whether an offer or answer 198 is associated with an event that requires the DTLS association to be 199 re-established. 201 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'dtls- 202 connection' attribute is 'IDENTICAL', which means that the attribute 203 value must be identical across all media descriptions being 204 multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. 206 For RTP-based media, the 'dtls-connection' attribute apply to whole 207 associated media description. The attribute MUST NOT be defined per 208 source (using the SDP 'ssrc' attribute [RFC5576]). 210 The SDP Offer/Answer [RFC3264] procedures associated with the 211 attribute are defined in Section 5 213 5. SDP Offer/Answer Procedures 215 5.1. General 217 This section defines the generic SDP offer/answer procedures for 218 negotiating a DTLS association. Additional procedures (e.g. 219 regarding usage of specific SDP attributes etc) for individual DTLS 220 usages (e.g. SRTP-DTLS) are outside the scope of this specification, 221 and need to be specified in a usage specific specification. 223 NOTE: The procedures in this section are generalizations of 224 procedures first specified in SRTP-DTLS [RFC5763], with the addition 225 of usage of the SDP 'dtls-connection' attribute. That document is 226 herein revised to make use of these new procedures. 228 The procedures in this section apply to an SDP media description 229 ("m=" line) associated a DTLS-protected media/data stream. 231 In order to negotiate a DTLS association, the following SDP 232 attributes are used: 234 o The SDP 'setup' attribute, defined in [RFC4145], is used to 235 negotiate the DTLS roles; 237 o The SDP 'fingerprint' attribute, defined in [RFC4572], is used to 238 provide the fingerprint value; and 240 o The SDP 'dtls-connection' attribute, defined in this 241 specification, is used to explicitly indicate whether a new DTLS 242 association is to be established or a previous association is to 243 be used. 245 This specification does not define the usage of the SDP 'connection' 246 attribute [RFC4145] for negotiating a DTLS connection. However, the 247 attribute MAY be used if the DTLS connection is used together with 248 another protocol, e.g. SCTP or TCP, for which the usage of the 249 attribute has been defined. 251 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 252 'setup' attribute 'holdconn' value when negotiating a DTLS 253 association. 255 Endpoints MUST support SHA-256 for generating and verifying the 256 fingerprint value associated with the DTLS association. The use of 257 SHA-256 is preferred. 259 Endpoints MUST, at a minimum, support 260 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 261 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 262 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 263 Secrecy (PFS) cipher suites over non-PFS cipher suites. 264 Implementations SHOULD disable TLS-level compression. 266 The certificate received during the DTLS handshake MUST match the 267 fingerprint received in the SDP "fingerprint" attribute. If the 268 fingerprint does not match the hashed certificate, then the endpoint 269 MUST tear down the media session immediately. Note that it is 270 permissible to wait until the other side's fingerprint has been 271 received before establishing the connection; however, this may have 272 undesirable latency effects. 274 5.2. Generating the Initial SDP Offer 276 When the offerer sends the initial offer, and the offerer wants to 277 establish a DTLS association, it MUST insert an SDP 'dtls-connection' 278 attribute with a 'new' value in the offer. In addition, the offerer 279 MUST insert an SDP 'setup' attribute according to the procedures in 280 [RFC4145], and an SDP 'fingerprint' attribute according to the 281 procedures in [RFC4572], in the offer. 283 If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 284 'passive' value, the offerer MUST be prepared to receive a DTLS 285 ClientHello message (if a new DTLS association is established by the 286 answerer) from the answerer before it receives the SDP answer. 288 5.3. Generating the Answer 290 If an answerer receives an offer that contains an SDP 'dtls- 291 connection' attribute with a 'new' value, or if the answerer receives 292 an offer that contains an 'dtls-connection' attribute with an 293 'existing' value and the answerer determines (based on the criteria 294 for establishing a new DTLS association) that a new DTLS association 295 is to be established, the answerer MUST insert a 'new' value in the 296 associated answer. In addition, the answerer MUST insert an SDP 297 'setup' attribute according to the procedures in [RFC4145], and an 298 SDP 'fingerprint' attribute according to the procedures in [RFC4572], 299 in the answer. 301 If an answerer receives an offer that contains an SDP 'dtls- 302 connection' attribute with a 'new' value, and if the answerer does 303 not accept the establishment of a new DTLS association, the answerer 304 MUST reject the "m=" lines associated with the suggested DTLS 305 association [RFC3264]. 307 If an answerer receives an offer that contains a 'dtls-connection' 308 attribute with an 'existing' value, and if the answerer determines 309 that a new DTLS association is not to be established, the answerer 310 MUST insert a 'dtls-connection' attribute with an 'existing' value in 311 the associated answer. In addition, the answerer MUST insert an SDP 312 'setup' attribute with a value that does not change the previously 313 negotiated DTLS roles, and an SDP 'fingerprint' attribute with a 314 value that does not change the previously sent fingerprint, in the 315 answer. 317 If the answerer receives an offer that does not contain an SDP 'dtls- 318 connection' attribute, the answerer MUST NOT insert a 'dtls- 319 connection' attribute in the answer. 321 If a new DTLS association is to be established, and if the answerer 322 inserts an SDP 'setup' attribute with an 'active' value in the 323 answer, the answerer MUST initiate a DTLS handshake by sending a DTLS 324 ClientHello message towards the offerer. 326 5.4. Offerer Processing of the SDP Answer 328 When an offerer receives an answer that contains an SDP 'dtls- 329 connection' attribute with a 'new' value, and if the offerer becomes 330 DTLS client (based on the value of the SDP 'setup' attribute value 331 [RFC4145]), the offerer MUST establish a DTLS association. If the 332 offerer becomes DTLS server, it MUST wait for the answerer to 333 establish the DTLS association. 335 If the answer contains an SDP 'dtls-connection' attribute with an 336 'existing' value, the offerer will continue using the previously 337 established DTLS association. It is considered an error case if the 338 answer contains a 'dtls-connection' attribute with an 'existing' 339 value, and a DTLS association does not exist. 341 An offerer needs to be able to handle error conditions that can occur 342 during an offer/answer transaction, e.g. if an answer contains an SDP 343 'dtls-connection' attribute with an 'existing' value even if no DTLS 344 connection exists, or if the answer contains a new fingerprint value 345 for an existing DTLS connection. If such error case occurs, the 346 offerer SHOULD terminate the associated DTLS connection (if it 347 exists) and send a new offer in order to terminate each media stream 348 using the DTLS association, by setting the associated port value to 349 zero [RFC4145]. 351 5.5. Modifying the Session 353 When the offerer sends a subsequent offer, and if the offerer wants 354 to establish a new DTLS association, the offerer MUST insert an SDP 355 'dtls-connection' attribute with a 'new' value in the offer. In 356 addition, the offerer MUST insert an SDP 'setup' attribute according 357 to the procedures in [RFC4145], and an SDP 'fingerprint' attribute 358 according to the procedures in [RFC4572], in the offer. 360 when the offerer sends a subsequent offer, and the offerer does not 361 want to establish a new DTLS association, and if a previously 362 established DTLS association exists, the offerer MUST insert an SDP 363 'dtls-connection' attribute with an 'existing' value in the offer. 364 In addition, the offerer MUST insert an SDP 'setup' attribute with a 365 value that does not change the previously negotiated DTLS roles, and 366 an SDP 'fingerprint' attribute with a value that does not change the 367 previously sent fingerprint, in the offer. 369 NOTE: When a new DTLS association is established, each endpoint needs 370 to be prepared to receive data on both the new and old DTLS 371 associations as long as both are alive. 373 6. ICE Considerations 375 When ICE is used, the ICE connectivity checks are performed before 376 the DTLS handshake begins. Note that if aggressive nomination mode 377 is used, multiple candidate pairs may be marked valid before ICE 378 finally converges on a single candidate pair. 380 An ICE restart [RFC5245] does not by default require a new DTLS 381 association to be established. 383 As defined in [RFC5763], each ICE candidate associated with a 384 component is treated as being part of the same DTLS association. 385 Therefore, from a DTLS perspective it is not considered a change of 386 local transport parameters when an endpoint switches between those 387 ICE candidates. 389 7. Transport Protocol Considerations 391 7.1. Transport Re-Usage 393 If DTLS is transported on top of a connection-oriented transport 394 protocol (e.g. TCP or SCTP), where all IP packets are acknowledged, 395 all DTLS packets associated with a previous DTLS association MUST be 396 acknowledged (or timed out) before a new DTLS association can be 397 established on the same transport. 399 8. SIP Considerations 401 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 402 signal protocol for establishing a multimedia session, dialogs 403 [RFC3261] might be established between the caller and multiple 404 callees. This is referred to as forking. If forking occurs, 405 separate DTLS associations MUST be established between the caller and 406 each callee. 408 It is possible to send an INVITE request which does not contain an 409 SDP offer. Such INVITE request is often referred to as an 'empty 410 INVITE', or an 'offerless INVITE'. The receiving endpoint will 411 include the SDP offer in a response associated with the response. 412 When the endpoint generates such SDP offer, it MUST assign an SDP 413 'dtls-connection' attribute, with a 'new' value, to each 'm-' line 414 that describes DTLS protected media. If ICE is used, the endpoint 415 MUST allocate a new set of ICE candidates, in order to ensure that 416 two DTLS association would not be running over the same transport. 418 9. RFC Updates 420 9.1. General 422 This section updates specifications that use DTLS-protected media, in 423 order to reflect the procedures defined in this specification. 425 9.2. Update to RFC 5763 427 Update to section 5: 428 -------------------- 430 OLD TEXT: 432 5. Establishing a Secure Channel 434 The two endpoints in the exchange present their identities as part of 435 the DTLS handshake procedure using certificates. This document uses 436 certificates in the same style as described in "Connection-Oriented 437 Media Transport over the Transport Layer Security (TLS) Protocol in 438 the Session Description Protocol (SDP)" [RFC4572]. 440 If self-signed certificates are used, the content of the 441 subjectAltName attribute inside the certificate MAY use the uniform 442 resource identifier (URI) of the user. This is useful for debugging 443 purposes only and is not required to bind the certificate to one of 444 the communication endpoints. The integrity of the certificate is 445 ensured through the fingerprint attribute in the SDP. The 446 subjectAltName is not an important component of the certificate 447 verification. 449 The generation of public/private key pairs is relatively expensive. 450 Endpoints are not required to generate certificates for each session. 452 The offer/answer model, defined in [RFC3264], is used by protocols 453 like the Session Initiation Protocol (SIP) [RFC3261] to set up 454 multimedia sessions. In addition to the usual contents of an SDP 455 [RFC4566] message, each media description ("m=" line and associated 456 parameters) will also contain several attributes as specified in 457 [RFC5764], [RFC4145], and [RFC4572]. 459 When an endpoint wishes to set up a secure media session with another 460 endpoint, it sends an offer in a SIP message to the other endpoint. 461 This offer includes, as part of the SDP payload, the fingerprint of 462 the certificate that the endpoint wants to use. The endpoint SHOULD 463 send the SIP message containing the offer to the offerer's SIP proxy 464 over an integrity protected channel. The proxy SHOULD add an 465 Identity header field according to the procedures outlined in 466 [RFC4474]. The SIP message containing the offer SHOULD be sent to 467 the offerer's SIP proxy over an integrity protected channel. When 468 the far endpoint receives the SIP message, it can verify the identity 469 of the sender using the Identity header field. Since the Identity 470 header field is a digital signature across several SIP header fields, 471 in addition to the body of the SIP message, the receiver can also be 472 certain that the message has not been tampered with after the digital 473 signature was applied and added to the SIP message. 475 The far endpoint (answerer) may now establish a DTLS association with 476 the offerer. Alternately, it can indicate in its answer that the 477 offerer is to initiate the TLS association. In either case, mutual 478 DTLS certificate-based authentication will be used. After completing 479 the DTLS handshake, information about the authenticated identities, 480 including the certificates, are made available to the endpoint 481 application. The answerer is then able to verify that the offerer's 482 certificate used for authentication in the DTLS handshake can be 483 associated to the certificate fingerprint contained in the offer in 484 the SDP. At this point, the answerer may indicate to the end user 485 that the media is secured. The offerer may only tentatively accept 486 the answerer's certificate since it may not yet have the answerer's 487 certificate fingerprint. 489 When the answerer accepts the offer, it provides an answer back to 490 the offerer containing the answerer's certificate fingerprint. At 491 this point, the offerer can accept or reject the peer's certificate 492 and the offerer can indicate to the end user that the media is 493 secured. 495 Note that the entire authentication and key exchange for securing the 496 media traffic is handled in the media path through DTLS. The 497 signaling path is only used to verify the peers' certificate 498 fingerprints. 500 The offer and answer MUST conform to the following requirements. 502 o The endpoint MUST use the setup attribute defined in [RFC4145]. 503 The endpoint that is the offerer MUST use the setup attribute 504 value of setup:actpass and be prepared to receive a client_hello 505 before it receives the answer. The answerer MUST use either a 506 setup attribute value of setup:active or setup:passive. Note that 507 if the answerer uses setup:passive, then the DTLS handshake will 508 not begin until the answerer is received, which adds additional 509 latency. setup:active allows the answer and the DTLS handshake to 510 occur in parallel. Thus, setup:active is RECOMMENDED. Whichever 511 party is active MUST initiate a DTLS handshake by sending a 512 ClientHello over each flow (host/port quartet). 514 o The endpoint MUST NOT use the connection attribute defined in 515 [RFC4145]. 517 o The endpoint MUST use the certificate fingerprint attribute as 518 specified in [RFC4572]. 520 o The certificate presented during the DTLS handshake MUST match the 521 fingerprint exchanged via the signaling path in the SDP. The 522 security properties of this mechanism are described in Section 8. 524 o If the fingerprint does not match the hashed certificate, then the 525 endpoint MUST tear down the media session immediately. Note that 526 it is permissible to wait until the other side's fingerprint has 527 been received before establishing the connection; however, this 528 may have undesirable latency effects. 530 NEW TEXT: 532 5. Establishing a Secure Channel 534 The two endpoints in the exchange present their identities as part of 535 the DTLS handshake procedure using certificates. This document uses 536 certificates in the same style as described in "Connection-Oriented 537 Media Transport over the Transport Layer Security (TLS) Protocol in 538 the Session Description Protocol (SDP)" [RFC4572]. 540 If self-signed certificates are used, the content of the 541 subjectAltName attribute inside the certificate MAY use the uniform 542 resource identifier (URI) of the user. This is useful for debugging 543 purposes only and is not required to bind the certificate to one of 544 the communication endpoints. The integrity of the certificate is 545 ensured through the fingerprint attribute in the SDP. The 546 subjectAltName is not an important component of the certificate 547 verification. 549 The generation of public/private key pairs is relatively expensive. 550 Endpoints are not required to generate certificates for each session. 552 The offer/answer model, defined in [RFC3264], is used by protocols 553 like the Session Initiation Protocol (SIP) [RFC3261] to set up 554 multimedia sessions. 556 When an endpoint wishes to set up a secure media session with another 557 endpoint, it sends an offer in a SIP message to the other endpoint. 558 This offer includes, as part of the SDP payload, the fingerprint of 559 the certificate that the endpoint wants to use. The endpoint SHOULD 560 send the SIP message containing the offer to the offerer's SIP proxy 561 over an integrity protected channel. The proxy SHOULD add an 562 Identity header field according to the procedures outlined in 563 [RFC4474]. The SIP message containing the offer SHOULD be sent to 564 the offerer's SIP proxy over an integrity protected channel. When 565 the far endpoint receives the SIP message, it can verify the identity 566 of the sender using the Identity header field. Since the Identity 567 header field is a digital signature across several SIP header fields, 568 in addition to the body of the SIP message, the receiver can also be 569 certain that the message has not been tampered with after the digital 570 signature was applied and added to the SIP message. 572 The far endpoint (answerer) may now establish a DTLS association with 573 the offerer. Alternately, it can indicate in its answer that the 574 offerer is to initiate the TLS association. In either case, mutual 575 DTLS certificate-based authentication will be used. After completing 576 the DTLS handshake, information about the authenticated identities, 577 including the certificates, are made available to the endpoint 578 application. The answerer is then able to verify that the offerer's 579 certificate used for authentication in the DTLS handshake can be 580 associated to the certificate fingerprint contained in the offer in 581 the SDP. At this point, the answerer may indicate to the end user 582 that the media is secured. The offerer may only tentatively accept 583 the answerer's certificate since it may not yet have the answerer's 584 certificate fingerprint. 586 When the answerer accepts the offer, it provides an answer back to 587 the offerer containing the answerer's certificate fingerprint. At 588 this point, the offerer can accept or reject the peer's certificate 589 and the offerer can indicate to the end user that the media is 590 secured. 592 Note that the entire authentication and key exchange for securing the 593 media traffic is handled in the media path through DTLS. The 594 signaling path is only used to verify the peers' certificate 595 fingerprints. 597 The offerer and answerer MUST follow the SDP offer/answer procedures 598 defined in [RFCXXXX]. 600 Update to section 6.6: 601 ---------------------- 603 OLD TEXT: 605 6.6. Session Modification 607 Once an answer is provided to the offerer, either endpoint MAY 608 request a session modification that MAY include an updated offer. 609 This session modification can be carried in either an INVITE or 610 UPDATE request. The peers can reuse the existing associations if 611 they are compatible (i.e., they have the same key fingerprints and 612 transport parameters), or establish a new one following the same 613 rules are for initial exchanges, tearing down the existing 614 association as soon as the offer/answer exchange is completed. Note 615 that if the active/passive status of the endpoints changes, a new 616 connection MUST be established. 618 NEW TEXT: 620 6.6. Session Modification 622 Once an answer is provided to the offerer, either endpoint MAY 623 request a session modification that MAY include an updated offer. 624 This session modification can be carried in either an INVITE or 625 UPDATE request. The peers can reuse an existing DTLS association, 626 or establish a new one, following the procedures in [RFCXXXX]. 628 Update to section 6.7.1: 629 ------------------------ 631 OLD TEXT: 633 6.7.1. ICE Interaction 635 Interactive Connectivity Establishment (ICE), as specified in 636 [RFC5245], provides a methodology of allowing participants in 637 multimedia sessions to verify mutual connectivity. When ICE is being 638 used, the ICE connectivity checks are performed before the DTLS 639 handshake begins. Note that if aggressive nomination mode is used, 640 multiple candidate pairs may be marked valid before ICE finally 641 converges on a single candidate pair. Implementations MUST treat all 642 ICE candidate pairs associated with a single component as part of the 643 same DTLS association. Thus, there will be only one DTLS handshake 644 even if there are multiple valid candidate pairs. Note that this may 645 mean adjusting the endpoint IP addresses if the selected candidate 646 pair shifts, just as if the DTLS packets were an ordinary media 647 stream. 649 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 650 packets are sent directly over UDP, not over DTLS. [RFC5764] 651 describes how to demultiplex STUN packets from DTLS packets and SRTP 652 packets. 654 NEW TEXT: 656 6.7.1. ICE Interaction 658 The Interactive Connectivity Establishment (ICE) [RFC5245] 659 considerations for DTLS-protected media are described in 660 [RFCXXXX]. 662 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 663 packets are sent directly over UDP, not over DTLS. [RFC5764] 664 describes how to demultiplex STUN packets from DTLS packets and SRTP 665 packets. 667 9.3. Update to RFC 7345 669 Update to section 4: 670 -------------------- 672 OLD TEXT: 674 4. SDP Offerer/Answerer Procedures 676 4.1. General 678 An endpoint (i.e., both the offerer and the answerer) MUST create an 679 SDP media description ("m=" line) for each UDPTL-over-DTLS media 680 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 681 "proto" field of the "m=" line. 683 The procedures in this section apply to an "m=" line associated with 684 a UDPTL-over-DTLS media stream. 686 In order to negotiate a UDPTL-over-DTLS media stream, the following 687 SDP attributes are used: 689 o The SDP attributes defined for UDPTL over UDP, as described in 690 [ITU.T38.2010]; and 692 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 693 described in this section. 695 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 697 In order to negotiate the TLS roles for the UDPTL-over-DTLS transport 698 connection, the endpoint MUST use the SDP "setup" attribute 699 [RFC4145]. 701 If the endpoint supports, and is willing to use, a cipher suite with 702 an associated certificate, the endpoint MUST include an SDP 703 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 704 for generating and verifying the SDP "fingerprint" attribute value. 705 The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST 706 support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 707 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 708 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 709 Secrecy (PFS) cipher suites over non-PFS cipher suites. 710 Implementations SHOULD disable TLS-level compression. 712 If a cipher suite with an associated certificate is selected during 713 the DTLS handshake, the certificate received during the DTLS 714 handshake MUST match the fingerprint received in the SDP 715 "fingerprint" attribute. If the fingerprint does not match the 716 hashed certificate, then the endpoint MUST tear down the media 717 session immediately. Note that it is permissible to wait until the 718 other side's fingerprint has been received before establishing the 719 connection; however, this may have undesirable latency effects. 721 4.2. Generating the Initial Offer 723 The offerer SHOULD assign the SDP "setup" attribute with a value of 724 "actpass", unless the offerer insists on being either the sender or 725 receiver of the DTLS ClientHello message, in which case the offerer 726 can use either a value of "active" (the offerer will be the sender of 727 ClientHello) or "passive" (the offerer will be the receiver of 728 ClientHello). The offerer MUST NOT assign an SDP "setup" attribute 729 with a "holdconn" value. 731 If the offerer assigns the SDP "setup" attribute with a value of 732 "actpass" or "passive", the offerer MUST be prepared to receive a 733 DTLS ClientHello message before it receives the SDP answer. 735 4.3. Generating the Answer 737 If the answerer accepts the offered UDPTL-over-DTLS transport 738 connection, in the associated SDP answer, the answerer MUST assign an 739 SDP "setup" attribute with a value of either "active" or "passive", 740 according to the procedures in [RFC4145]. The answerer MUST NOT 741 assign an SDP "setup" attribute with a value of "holdconn". 743 If the answerer assigns an SDP "setup" attribute with a value of 744 "active" value, the answerer MUST initiate a DTLS handshake by 745 sending a DTLS ClientHello message on the negotiated media stream, 746 towards the IP address and port of the offerer. 748 4.4. Offerer Processing of the Answer 750 When the offerer receives an SDP answer, if the offerer ends up being 751 active it MUST initiate a DTLS handshake by sending a DTLS 752 ClientHello message on the negotiated media stream, towards the IP 753 address and port of the answerer. 755 4.5. Modifying the Session 756 Once an offer/answer exchange has been completed, either endpoint MAY 757 send a new offer in order to modify the session. The endpoints can 758 reuse the existing DTLS association if the key fingerprint values and 759 transport parameters indicated by each endpoint are unchanged. 760 Otherwise, following the rules for the initial offer/answer exchange, 761 the endpoints can negotiate and create a new DTLS association and, 762 once created, delete the previous DTLS association, following the 763 same rules for the initial offer/answer exchange. Each endpoint 764 needs to be prepared to receive data on both the new and old DTLS 765 associations as long as both are alive. 767 NEW TEXT: 769 4. SDP Offerer/Answerer Procedures 771 An endpoint (i.e., both the offerer and the answerer) MUST create an 772 SDP media description ("m=" line) for each UDPTL-over-DTLS media 773 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 774 "proto" field of the "m=" line. 776 The offerer and answerer MUST follow the SDP offer/answer procedures 777 defined in [RFCXXXX] in order to negotiate the DTLS association 778 associated with the UDPTL-over-DTLS media stream. In addition, 779 the offerer and answerer MUST use the SDP attributes defined for 780 UDPTL over UDP, as defined in [ITU.T38.2010]. 782 Update to section 5.2.1: 783 ------------------------ 785 OLD TEXT: 787 5.2.1. ICE Usage 789 When Interactive Connectivity Establishment (ICE) [RFC5245] is being 790 used, the ICE connectivity checks are performed before the DTLS 791 handshake begins. Note that if aggressive nomination mode is used, 792 multiple candidate pairs may be marked valid before ICE finally 793 converges on a single candidate pair. User Agents (UAs) MUST treat 794 all ICE candidate pairs associated with a single component as part of 795 the same DTLS association. Thus, there will be only one DTLS 796 handshake even if there are multiple valid candidate pairs. Note 797 that this may mean adjusting the endpoint IP addresses if the 798 selected candidate pair shifts, just as if the DTLS packets were an 799 ordinary media stream. In the case of an ICE restart, the DTLS 800 handshake procedure is repeated, and a new DTLS association is 801 created. Once the DTLS handshake is completed and the new DTLS 802 association has been created, the previous DTLS association is 803 deleted. 805 NEW TEXT: 807 5.2.1. ICE Usage 809 The Interactive Connectivity Establishment (ICE) [RFC5245] 810 considerations for DTLS-protected media are described in 811 [RFCXXXX]. 813 10. Security Considerations 815 This specification does not modify the security considerations 816 associated with DTLS, or the SDP offer/answer mechanism. In addition 817 to the introduction of the SDP 'dtls-connection' attribute, the 818 specification simply clarifies the procedures for negotiating and 819 establishing a DTLS association. 821 11. IANA Considerations 823 This document updates the "Session Description Protocol Parameters" 824 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 825 it adds the SDP dtls-connection attribute to the table for SDP media 826 level attributes. 828 Attribute name: dtls-connection 829 Type of attribute: media-level 830 Subject to charset: no 831 Purpose: Indicate whether a new DTLS association is to be established/re-established. 832 Appropriate Values: see Section 4 833 Contact name: Christer Holmberg 834 Category: IDENTICAL 836 12. Acknowledgements 838 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat and Jens 839 Guballa for providing comments and suggestions on the draft. 841 13. Change Log 843 [RFC EDITOR NOTE: Please remove this section when publishing] 845 Changes from draft-ietf-mmusic-sdp-dtls-06 846 o Text on restrictions regarding spanning a DTLS connection over 847 multiple transports added. 849 o Mux category added to IANA Considerations. 851 o Normative text regarding mux category and source-specific 852 applicability added. 854 o Reference to RFC 7315 added. 856 o Clarified that offerer/answerer that has not been updated to 857 support this specification will not include the dtls-connection 858 attribute in offers and answers. 860 o Editorial corrections based on WGLC comments from Charles Eckel. 862 Changes from draft-ietf-mmusic-sdp-dtls-05 864 o Text on handling offer/answer error conditions added. 866 Changes from draft-ietf-mmusic-sdp-dtls-04 868 o Editorial nits fixed based on comments from Paul Kyzivat: 870 Changes from draft-ietf-mmusic-sdp-dtls-03 872 o Changes based on comments from Paul Kyzivat: 874 o - Modification of dtls-connection attribute section. 876 o - Removal of IANA considerations subsection. 878 o - Making note into normative text in o/a section. 880 o Changes based on comments from Martin Thompson: 882 o - Abbreviations section removed. 884 o - Clarify that a new DTLS association requires a new o/a 885 transaction. 887 Changes from draft-ietf-mmusic-sdp-dtls-02 889 o - Updated RFCs added to boilerplate. 891 Changes from draft-ietf-mmusic-sdp-dtls-01 893 o - Annex regarding 'dtls-connection-id' attribute removed. 895 o - Additional SDP offer/answer procedures, related to certificates, 896 added. 898 o - Updates to RFC 5763 and RFC 7345 added. 900 o - Transport protocol considerations added. 902 Changes from draft-ietf-mmusic-sdp-dtls-00 904 o - SDP 'connection' attribute replaced with new 'dtls-connection' 905 attribute. 907 o - IANA Considerations added. 909 o - E-mail regarding 'dtls-connection-id' attribute added as Annex. 911 Changes from draft-holmberg-mmusic-sdp-dtls-01 913 o - draft-ietf-mmusic version of draft submitted. 915 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 916 with another expired draft. 918 o - Clarify that if ufrag in offer is unchanged, it must be 919 unchanged in associated answer. 921 o - SIP Considerations section added. 923 o - Section about multiple SDP fingerprint attributes added. 925 Changes from draft-holmberg-mmusic-sdp-dtls-00 927 o - Editorial changes and clarifications. 929 14. References 931 14.1. Normative References 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, 935 DOI 10.17487/RFC2119, March 1997, 936 . 938 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 939 A., Peterson, J., Sparks, R., Handley, M., and E. 940 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 941 DOI 10.17487/RFC3261, June 2002, 942 . 944 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 945 with Session Description Protocol (SDP)", RFC 3264, 946 DOI 10.17487/RFC3264, June 2002, 947 . 949 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 950 the Session Description Protocol (SDP)", RFC 4145, 951 DOI 10.17487/RFC4145, September 2005, 952 . 954 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 955 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 956 July 2006, . 958 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 959 Transport Layer Security (TLS) Protocol in the Session 960 Description Protocol (SDP)", RFC 4572, 961 DOI 10.17487/RFC4572, July 2006, 962 . 964 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 965 Specifications: ABNF", STD 68, RFC 5234, 966 DOI 10.17487/RFC5234, January 2008, 967 . 969 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 970 (ICE): A Protocol for Network Address Translator (NAT) 971 Traversal for Offer/Answer Protocols", RFC 5245, 972 DOI 10.17487/RFC5245, April 2010, 973 . 975 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 976 for Establishing a Secure Real-time Transport Protocol 977 (SRTP) Security Context Using Datagram Transport Layer 978 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 979 2010, . 981 [RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header 982 (P-Header) Extensions to the Session Initiation Protocol 983 (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July 984 2014, . 986 14.2. Informative References 988 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 989 Media Attributes in the Session Description Protocol 990 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 991 . 993 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 994 Transport Layer Security (DTLS) for Stream Control 995 Transmission Protocol (SCTP)", RFC 6083, 996 DOI 10.17487/RFC6083, January 2011, 997 . 999 [I-D.ietf-mmusic-sdp-mux-attributes] 1000 Nandakumar, S., "A Framework for SDP Attributes when 1001 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 1002 (work in progress), January 2016. 1004 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1005 Holmberg, C., Alvestrand, H., and C. Jennings, 1006 "Negotiating Media Multiplexing Using the Session 1007 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1008 negotiation-25 (work in progress), January 2016. 1010 Authors' Addresses 1012 Christer Holmberg 1013 Ericsson 1014 Hirsalantie 11 1015 Jorvas 02420 1016 Finland 1018 Email: christer.holmberg@ericsson.com 1020 Roman Shpount 1021 TurboBridge 1022 4905 Del Ray Avenue, Suite 300 1023 Bethesda, MD 20814 1024 USA 1026 Phone: +1 (240) 292-6632 1027 Email: rshpount@turbobridge.com