idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-03.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 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 (December 8, 2015) is 3062 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 635, but not defined == Missing Reference: 'RFC4474' is mentioned on line 535, but not defined ** Obsolete undefined reference: RFC 4474 (Obsoleted by RFC 8224) == Missing Reference: 'RFCXXXX' is mentioned on line 784, but not defined == Missing Reference: 'ITU.T38.2010' is mentioned on line 752, 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) Summary: 4 errors (**), 0 flaws (~~), 5 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: June 10, 2016 December 8, 2015 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-03.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 June 10, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Establishing a new DTLS Association . . . . . . . . . . . . . 3 58 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.2. Change of Local Transport Parameters . . . . . . . . . . 4 60 4.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4 61 4.4. Multiple SDP fingerprint attributes . . . . . . . . . . . 4 62 5. SDP dtls-connection Attribute . . . . . . . . . . . . . . . . 4 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 66 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.2. Generating the Initial SDP Offer . . . . . . . . . . . . 6 68 6.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6 69 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 7 70 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7 71 7. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. Transport Protocol Considerations . . . . . . . . . . . . . . 8 73 8.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 8 74 9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 9 77 10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 9 78 10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 14 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 12.1. Registration of New SDP Attribute . . . . . . . . . . . 17 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 83 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 15. Normative References . . . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. This 90 draft defines the SDP Offer/Answer [RFC3264] procedures for 91 negotiation DTLS in general, based on the procedures in [RFC5763]. 93 This draft also defines a new SDP attribute, 'dtls-connection'. The 94 attribute is used in SDP offers and answers to explicitly indicate 95 whether a new DTLS association is to be established. 97 As defined in [RFC5763], a new DTLS association MUST be established 98 when transport parameters are changed. Transport parameter change is 99 not well defined when Interactive Connectivity Establishment (ICE) 100 [RFC5245] is used. One possible way to determine a transport change 101 is based on ufrag change, but the ufrag value is changed both when 102 ICE is negotiated and when ICE restart [RFC5245] occurs. These 103 events do not always require a new DTLS association to be 104 established, but currently there is no way to explicitly indicate in 105 an SDP offer or answer whether a new DTLS association is required. 106 To solve that problem, this draft defines a new SDP attribute, 'dtls- 107 connection'. The attribute is used in SDP offers and answers to 108 explicitly indicate whether a new DTLS association is to be 109 established/re-established. The attribute can be used both with and 110 without ICE. 112 2. Abbreviations 114 TBD 116 3. Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 4. Establishing a new DTLS Association 124 4.1. General 126 A new DTLS association MUST be established in the following cases: 128 o The DTLS roles change; 130 o The fingerprint (certificate) value changes; or 132 o The establishment of a new DTLS association is explicitly 133 signaled; 135 NOTE: The first two items list above are based on the procedures in 136 [RFC5763]. This draft adds the support for explicit signaling. 138 The sections below describe typical cases where a new DTLS 139 association needs to be established. 141 4.2. Change of Local Transport Parameters 143 If an endpoint modifies its local transport parameters (IP address 144 and/or port), and if the modification requires a new DTLS 145 association, the endpoint MUST either change its DTLS role, its 146 fingerprint value and/or use the SDP 'dtls-connection' attribute with 147 a 'new' value Section 5. 149 4.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 5. 156 4.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 5. SDP dtls-connection Attribute 165 5.1. General 167 The SDP 'connection' attribute [RFC4145] was originally defined for 168 connection-oriented protocols, e.g. TCP and TLS. This section 169 defines a similar attribute, 'dtls-connection', to be used with DTLS. 171 A 'dtls-connection' attribute value of 'new' indicates that a new 172 DTLS association MUST be established. A 'dtls-connection' attribute 173 value of 'existing' indicates that a new DTLS association MUST NOT be 174 established. 176 Unlike the SDP 'connection' attribute for TLS, there is no default 177 value defined for the 'dtls-connection' attribute. Implementations 178 that wish to use the attribute MUST explicitly include it in SDP 179 offers and answers. If an offer or answer does not contain an 180 attribute, other means needs to be used in order for endpoints to 181 determine whether an offer or answer is associated with an event that 182 requires the DTLS association to be re-established. 184 The SDP Offer/Answer [RFC3264] procedures associated with the 185 attribute are defined in Section 6 187 5.2. ABNF 189 The ABNF [RFC5234] grammar for the SDP 'dtls-connection' attributes 190 is: 192 dtls-connection-attr = "a=dtls-connection:" conn-value 193 conn-value = "new" / "existing" 195 6. SDP Offer/Answer Procedures 197 6.1. General 199 This section defines the generic SDP offer/answer procedures for 200 negotiating a DTLS association. Additional procedures (e.g. 201 regarding usage of usage specific SDP attributes etc) for individual 202 DTLS usages (e.g. SRTP-DTLS) are outside the scope of this 203 specification, and needs to be specified in a usage specific 204 specification. 206 NOTE: The procedures in this section are based on the procedures for 207 SRTP-DTLS [RFC5763], with the addition of usage of the SDP 'dtls- 208 connection' attribute. 210 The procedures in this section apply to an SDP media description 211 ("m=" line) associated a DTLS-protected media/data stream. 213 In order to negotiate a DTLS association, the following SDP 214 attributes are used: 216 o The SDP 'setup' attribute, defined in [RFC4145], is used to 217 negotiate the DTLS roles; 219 o The SDP 'fingerprint' attribute, defined in [RFC4572], is used to 220 provide the fingerprint value; and 222 o The SDP 'dtls-connection' attribute, defined in this 223 specification, is used to explicitly indicate whether a new DTLS 224 association is to be established or whether a previous association 225 is to be used. 227 Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] when 228 negotiating a DTLS association. 230 NOTE: The SDP 'connection' attribute may be used if the usage is 231 associated with another protocol layer, e.g. SCTP or TCP, used 232 together with DTLS. 234 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 235 'setup' attribute 'holdconn' value when negotiating a DTLS 236 association. 238 Endpoints MUST support SHA-256 for generating and verifying the 239 fingerprint value associated with the DTLS association. The use of 240 SHA-256 is preferred. 242 Endpoints MUST, at a minimum, support 243 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 244 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 245 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 246 Secrecy (PFS) cipher suites over non-PFS cipher suites. 247 Implementations SHOULD disable TLS-level compression. 249 The certificate received during the DTLS handshake MUST match the 250 fingerprint received in the SDP "fingerprint" attribute. If the 251 fingerprint does not match the hashed certificate, then the endpoint 252 MUST tear down the media session immediately. Note that it is 253 permissible to wait until the other side's fingerprint has been 254 received before establishing the connection; however, this may have 255 undesirable latency effects. 257 6.2. Generating the Initial SDP Offer 259 When the offerer sends the initial offer, and the offerer wants to 260 establish a DTLS association, it MUST insert an SDP 'dtls-connection' 261 attribute with a 'new' value in the offer. In addition, the offerer 262 MUST insert an SDP 'setup' attribute according to the procedures in 263 [RFC4145], and an SDP 'fingerprint' attribute according to the 264 procedures in [RFC4572], in the offer. 266 If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 267 'passive' value, the offerer MUST be prepared to receive a DTLS 268 ClientHello message (if a new DTLS association is established by the 269 answerer) from the answerer before it receives the SDP answer. 271 6.3. Generating the Answer 273 If an answerer receives an offer that contains an SDP 'dtls- 274 connection' attribute with a 'new' value, or if the answerer receives 275 and offer that contains an 'dtls-connection' attribute with an 276 'existing' value and the answerer determines (based on the criteria 277 for establishing a new DTLS association) that a new DTLS association 278 is to be established, the answerer MUST insert a 'new' value in the 279 associated answer. In addition, the answerer MUST insert an SDP 280 'setup' attribute according to the procedures in [RFC4145], and an 281 SDP 'fingerprint' attribute according to the procedures in [RFC4572], 282 in the answer. 284 If an answerer receives an offer that contains an SDP 'dtls- 285 connection' attribute with a 'new' value, and if the answerer does 286 not accept the establishment of a new DTLS association, the answerer 287 MUST reject the "m=" lines associated with the suggested DTLS 288 association [RFC3264]. 290 If an answerer receives an offer that contains a 'dtls-connection' 291 attribute with an 'existing' value, and if the answerer determines 292 that a new DTLS association is not to be established, the answerer 293 MUST insert a 'dtls-connection' attribute with an 'existing' value in 294 the associated answer. In addition, the answerer MUST insert an SDP 295 'setup' attribute with a value that does not change the previously 296 negotiated DTLS roles, and an SDP 'fingerprint' attribute with a 297 value that does not change the previously sent fingerprint, in the 298 answer. 300 If the answerer receives an offer that does not contain an SDP 'dtls- 301 connection' attribute, the answerer MUST NOT insert a 'dtls- 302 connection' attribute in the answer. 304 If a new DTLS association is to be established, and if the answerer 305 inserts an SDP 'setup' attribute with an 'active' value in the 306 answer, the answerer MUST initiate a DTLS handshake by sending a DTLS 307 ClientHello message towards the the offerer. 309 6.4. Offerer Processing of the SDP Answer 311 When an offerer receives an answer that contains an SDP 'dtls- 312 connection' attribute with a 'new' value, and if the offerer becomes 313 DTLS client, the offerer MUST establish a DTLS association. If the 314 offerer becomes DTLS server, it MUST wait for the answerer to 315 establish the DTLS association. 317 If the answer contains an SDP 'dtls-connection' attribute with an 318 'existing' value, the offerer will continue using the previously 319 established DTLS association. It is considered an error case if the 320 answer contains a 'dtls-connection' attribute with an 'existing' 321 value, and a DTLS association does not exist. 323 6.5. Modifying the Session 325 When the offerer sends a subsequent offer, and if the offerer wants 326 to establish a new DTLS association, the offerer MUST insert an SDP 327 'dtls-connection' attribute with a 'new' value in the offer. In 328 addition, the offerer MUST insert an SDP 'setup' attribute according 329 to the procedures in [RFC4145], and an SDP 'fingerprint' attribute 330 according to the procedures in [RFC4572], in the offer. 332 when the offerer sends a subsequent offer, and the offerer does not 333 want to establish a new DTLS association, and if a previously 334 established DTLS association exists, the offerer MUST insert an SDP 335 'dtls-connection' attribute with an 'existing' value in the offer. 336 In addition, the offerer MUST insert an SDP 'setup' attribute with a 337 value that does not change the previously negotiated DTLS roles, and 338 an SDP 'fingerprint' attribute with a value that does not change the 339 previously sent fingerprint, in the offer. 341 NOTE: When a new DTLS association is established, each endpoint needs 342 to be prepared to receive data on both the new and old DTLS 343 associations as long as both are alive. 345 7. ICE Considerations 347 When ICE is used, the ICE connectivity checks are performed before 348 the DTLS handshake begins. Note that if aggressive nomination mode 349 is used, multiple candidate pairs may be marked valid before ICE 350 finally converges on a single candidate pair. 352 An ICE restart [RFC5245] does not by default require a new DTLS 353 association to be established. 355 As defined in [RFC5763], each ICE candidate associated with a 356 component is treated as being part of the same DTLS association. 357 Therefore, from a DTLS perspective it is not considered a change of 358 local transport parameters when an endpoint switches between those 359 ICE candidates. 361 8. Transport Protocol Considerations 363 8.1. Transport Re-Usage 365 If DTLS is transported on top of a connection-oriented transport 366 protocol (e.g. TCP or SCTP), where all IP packets are acknowledged, 367 all DTLS packets associated with a previous DTLS association MUST be 368 acknowledged (or timed out) before a new DTLS association can be 369 established on the same transport. 371 9. SIP Considerations 373 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 374 signal protocol for establishing a multimedia session, dialogs 375 [RFC3261] might be established between the caller and multiple 376 callees. This is referred to as forking. If forking occurs, 377 separate DTLS associations MUST be established between the caller and 378 each callee. 380 It is possible to send an INVITE request which does not contain an 381 SDP offer. Such INVITE request is often referred to as an 'empty 382 INVITE', or an 'offerless INVITE'. The receiving endpoint will 383 include the SDP offer in a response associated with the response. 384 When the endpoint generates such SDP offer, it MUST assign an SDP 385 connection attribute, with a 'new' value, to each 'm-' line that 386 describes DTLS protected media. If ICE is used, the endpoint MUST 387 allocate a new set of ICE candidates, in order to ensure that two 388 DTLS association would not be running over the same transport. 390 10. RFC Updates 392 10.1. General 394 This section updates specifications that use DTLS-protected media, in 395 order to reflect the procedures defined in this specification. 397 10.2. Update to RFC 5763 399 Update to section 5: 400 -------------------- 402 OLD TEXT: 404 5. Establishing a Secure Channel 406 The two endpoints in the exchange present their identities as part of 407 the DTLS handshake procedure using certificates. This document uses 408 certificates in the same style as described in "Connection-Oriented 409 Media Transport over the Transport Layer Security (TLS) Protocol in 410 the Session Description Protocol (SDP)" [RFC4572]. 412 If self-signed certificates are used, the content of the 413 subjectAltName attribute inside the certificate MAY use the uniform 414 resource identifier (URI) of the user. This is useful for debugging 415 purposes only and is not required to bind the certificate to one of 416 the communication endpoints. The integrity of the certificate is 417 ensured through the fingerprint attribute in the SDP. The 418 subjectAltName is not an important component of the certificate 419 verification. 421 The generation of public/private key pairs is relatively expensive. 422 Endpoints are not required to generate certificates for each session. 424 The offer/answer model, defined in [RFC3264], is used by protocols 425 like the Session Initiation Protocol (SIP) [RFC3261] to set up 426 multimedia sessions. In addition to the usual contents of an SDP 427 [RFC4566] message, each media description ("m=" line and associated 428 parameters) will also contain several attributes as specified in 429 [RFC5764], [RFC4145], and [RFC4572]. 431 When an endpoint wishes to set up a secure media session with another 432 endpoint, it sends an offer in a SIP message to the other endpoint. 433 This offer includes, as part of the SDP payload, the fingerprint of 434 the certificate that the endpoint wants to use. The endpoint SHOULD 435 send the SIP message containing the offer to the offerer's SIP proxy 436 over an integrity protected channel. The proxy SHOULD add an 437 Identity header field according to the procedures outlined in 438 [RFC4474]. The SIP message containing the offer SHOULD be sent to 439 the offerer's SIP proxy over an integrity protected channel. When 440 the far endpoint receives the SIP message, it can verify the identity 441 of the sender using the Identity header field. Since the Identity 442 header field is a digital signature across several SIP header fields, 443 in addition to the body of the SIP message, the receiver can also be 444 certain that the message has not been tampered with after the digital 445 signature was applied and added to the SIP message. 447 The far endpoint (answerer) may now establish a DTLS association with 448 the offerer. Alternately, it can indicate in its answer that the 449 offerer is to initiate the TLS association. In either case, mutual 450 DTLS certificate-based authentication will be used. After completing 451 the DTLS handshake, information about the authenticated identities, 452 including the certificates, are made available to the endpoint 453 application. The answerer is then able to verify that the offerer's 454 certificate used for authentication in the DTLS handshake can be 455 associated to the certificate fingerprint contained in the offer in 456 the SDP. At this point, the answerer may indicate to the end user 457 that the media is secured. The offerer may only tentatively accept 458 the answerer's certificate since it may not yet have the answerer's 459 certificate fingerprint. 461 When the answerer accepts the offer, it provides an answer back to 462 the offerer containing the answerer's certificate fingerprint. At 463 this point, the offerer can accept or reject the peer's certificate 464 and the offerer can indicate to the end user that the media is 465 secured. 467 Note that the entire authentication and key exchange for securing the 468 media traffic is handled in the media path through DTLS. The 469 signaling path is only used to verify the peers' certificate 470 fingerprints. 472 The offer and answer MUST conform to the following requirements. 474 o The endpoint MUST use the setup attribute defined in [RFC4145]. 475 The endpoint that is the offerer MUST use the setup attribute 476 value of setup:actpass and be prepared to receive a client_hello 477 before it receives the answer. The answerer MUST use either a 478 setup attribute value of setup:active or setup:passive. Note that 479 if the answerer uses setup:passive, then the DTLS handshake will 480 not begin until the answerer is received, which adds additional 481 latency. setup:active allows the answer and the DTLS handshake to 482 occur in parallel. Thus, setup:active is RECOMMENDED. Whichever 483 party is active MUST initiate a DTLS handshake by sending a 484 ClientHello over each flow (host/port quartet). 486 o The endpoint MUST NOT use the connection attribute defined in 487 [RFC4145]. 489 o The endpoint MUST use the certificate fingerprint attribute as 490 specified in [RFC4572]. 492 o The certificate presented during the DTLS handshake MUST match the 493 fingerprint exchanged via the signaling path in the SDP. The 494 security properties of this mechanism are described in Section 8. 496 o If the fingerprint does not match the hashed certificate, then the 497 endpoint MUST tear down the media session immediately. Note that 498 it is permissible to wait until the other side's fingerprint has 499 been received before establishing the connection; however, this 500 may have undesirable latency effects. 502 NEW TEXT: 504 5. Establishing a Secure Channel 506 The two endpoints in the exchange present their identities as part of 507 the DTLS handshake procedure using certificates. This document uses 508 certificates in the same style as described in "Connection-Oriented 509 Media Transport over the Transport Layer Security (TLS) Protocol in 510 the Session Description Protocol (SDP)" [RFC4572]. 512 If self-signed certificates are used, the content of the 513 subjectAltName attribute inside the certificate MAY use the uniform 514 resource identifier (URI) of the user. This is useful for debugging 515 purposes only and is not required to bind the certificate to one of 516 the communication endpoints. The integrity of the certificate is 517 ensured through the fingerprint attribute in the SDP. The 518 subjectAltName is not an important component of the certificate 519 verification. 521 The generation of public/private key pairs is relatively expensive. 522 Endpoints are not required to generate certificates for each session. 524 The offer/answer model, defined in [RFC3264], is used by protocols 525 like the Session Initiation Protocol (SIP) [RFC3261] to set up 526 multimedia sessions. 528 When an endpoint wishes to set up a secure media session with another 529 endpoint, it sends an offer in a SIP message to the other endpoint. 530 This offer includes, as part of the SDP payload, the fingerprint of 531 the certificate that the endpoint wants to use. The endpoint SHOULD 532 send the SIP message containing the offer to the offerer's SIP proxy 533 over an integrity protected channel. The proxy SHOULD add an 534 Identity header field according to the procedures outlined in 535 [RFC4474]. The SIP message containing the offer SHOULD be sent to 536 the offerer's SIP proxy over an integrity protected channel. When 537 the far endpoint receives the SIP message, it can verify the identity 538 of the sender using the Identity header field. Since the Identity 539 header field is a digital signature across several SIP header fields, 540 in addition to the body of the SIP message, the receiver can also be 541 certain that the message has not been tampered with after the digital 542 signature was applied and added to the SIP message. 544 The far endpoint (answerer) may now establish a DTLS association with 545 the offerer. Alternately, it can indicate in its answer that the 546 offerer is to initiate the TLS association. In either case, mutual 547 DTLS certificate-based authentication will be used. After completing 548 the DTLS handshake, information about the authenticated identities, 549 including the certificates, are made available to the endpoint 550 application. The answerer is then able to verify that the offerer's 551 certificate used for authentication in the DTLS handshake can be 552 associated to the certificate fingerprint contained in the offer in 553 the SDP. At this point, the answerer may indicate to the end user 554 that the media is secured. The offerer may only tentatively accept 555 the answerer's certificate since it may not yet have the answerer's 556 certificate fingerprint. 558 When the answerer accepts the offer, it provides an answer back to 559 the offerer containing the answerer's certificate fingerprint. At 560 this point, the offerer can accept or reject the peer's certificate 561 and the offerer can indicate to the end user that the media is 562 secured. 564 Note that the entire authentication and key exchange for securing the 565 media traffic is handled in the media path through DTLS. The 566 signaling path is only used to verify the peers' certificate 567 fingerprints. 569 The offerer and answerer MUST follow the SDP offer/answer procedures 570 defined in [RFCXXXX]. 572 Update to section 6.6: 573 ---------------------- 575 OLD TEXT: 577 6.6. Session Modification 579 Once an answer is provided to the offerer, either endpoint MAY 580 request a session modification that MAY include an updated offer. 581 This session modification can be carried in either an INVITE or 582 UPDATE request. The peers can reuse the existing associations if 583 they are compatible (i.e., they have the same key fingerprints and 584 transport parameters), or establish a new one following the same 585 rules are for initial exchanges, tearing down the existing 586 association as soon as the offer/answer exchange is completed. Note 587 that if the active/passive status of the endpoints changes, a new 588 connection MUST be established. 590 NEW TEXT: 592 6.6. Session Modification 594 Once an answer is provided to the offerer, either endpoint MAY 595 request a session modification that MAY include an updated offer. 596 This session modification can be carried in either an INVITE or 597 UPDATE request. The peers can reuse an existing DTLS association, 598 or establish a new one, following the procedures in [RFCXXXX]. 600 Update to section 6.7.1: 601 ------------------------ 603 OLD TEXT: 605 6.7.1. ICE Interaction 607 Interactive Connectivity Establishment (ICE), as specified in 608 [RFC5245], provides a methodology of allowing participants in 609 multimedia sessions to verify mutual connectivity. When ICE is being 610 used, the ICE connectivity checks are performed before the DTLS 611 handshake begins. Note that if aggressive nomination mode is used, 612 multiple candidate pairs may be marked valid before ICE finally 613 converges on a single candidate pair. Implementations MUST treat all 614 ICE candidate pairs associated with a single component as part of the 615 same DTLS association. Thus, there will be only one DTLS handshake 616 even if there are multiple valid candidate pairs. Note that this may 617 mean adjusting the endpoint IP addresses if the selected candidate 618 pair shifts, just as if the DTLS packets were an ordinary media 619 stream. 621 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 622 packets are sent directly over UDP, not over DTLS. [RFC5764] 623 describes how to demultiplex STUN packets from DTLS packets and SRTP 624 packets. 626 NEW TEXT: 628 6.7.1. ICE Interaction 630 The Interactive Connectivity Establishment (ICE) [RFC5245] 631 considerations for DTLS-protected media are described in 632 [RFCXXXX]. 634 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 635 packets are sent directly over UDP, not over DTLS. [RFC5764] 636 describes how to demultiplex STUN packets from DTLS packets and SRTP 637 packets. 639 10.3. Update to RFC 7345 641 Update to section 4: 642 -------------------- 644 OLD TEXT: 646 4. SDP Offerer/Answerer Procedures 648 4.1. General 650 An endpoint (i.e., both the offerer and the answerer) MUST create an 651 SDP media description ("m=" line) for each UDPTL-over-DTLS media 652 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 653 "proto" field of the "m=" line. 655 The procedures in this section apply to an "m=" line associated with 656 a UDPTL-over-DTLS media stream. 658 In order to negotiate a UDPTL-over-DTLS media stream, the following 659 SDP attributes are used: 661 o The SDP attributes defined for UDPTL over UDP, as described in 662 [ITU.T38.2010]; and 664 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 665 described in this section. 667 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 669 In order to negotiate the TLS roles for the UDPTL-over-DTLS transport 670 connection, the endpoint MUST use the SDP "setup" attribute 671 [RFC4145]. 673 If the endpoint supports, and is willing to use, a cipher suite with 674 an associated certificate, the endpoint MUST include an SDP 675 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 676 for generating and verifying the SDP "fingerprint" attribute value. 677 The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST 678 support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 679 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 680 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 681 Secrecy (PFS) cipher suites over non-PFS cipher suites. 682 Implementations SHOULD disable TLS-level compression. 684 If a cipher suite with an associated certificate is selected during 685 the DTLS handshake, the certificate received during the DTLS 686 handshake MUST match the fingerprint received in the SDP 687 "fingerprint" attribute. If the fingerprint does not match the 688 hashed certificate, then the endpoint MUST tear down the media 689 session immediately. Note that it is permissible to wait until the 690 other side's fingerprint has been received before establishing the 691 connection; however, this may have undesirable latency effects. 693 4.2. Generating the Initial Offer 695 The offerer SHOULD assign the SDP "setup" attribute with a value of 696 "actpass", unless the offerer insists on being either the sender or 697 receiver of the DTLS ClientHello message, in which case the offerer 698 can use either a value of "active" (the offerer will be the sender of 699 ClientHello) or "passive" (the offerer will be the receiver of 700 ClientHello). The offerer MUST NOT assign an SDP "setup" attribute 701 with a "holdconn" value. 703 If the offerer assigns the SDP "setup" attribute with a value of 704 "actpass" or "passive", the offerer MUST be prepared to receive a 705 DTLS ClientHello message before it receives the SDP answer. 707 4.3. Generating the Answer 708 If the answerer accepts the offered UDPTL-over-DTLS transport 709 connection, in the associated SDP answer, the answerer MUST assign an 710 SDP "setup" attribute with a value of either "active" or "passive", 711 according to the procedures in [RFC4145]. The answerer MUST NOT 712 assign an SDP "setup" attribute with a value of "holdconn". 714 If the answerer assigns an SDP "setup" attribute with a value of 715 "active" value, the answerer MUST initiate a DTLS handshake by 716 sending a DTLS ClientHello message on the negotiated media stream, 717 towards the IP address and port of the offerer. 719 4.4. Offerer Processing of the Answer 721 When the offerer receives an SDP answer, if the offerer ends up being 722 active it MUST initiate a DTLS handshake by sending a DTLS 723 ClientHello message on the negotiated media stream, towards the IP 724 address and port of the answerer. 726 4.5. Modifying the Session 728 Once an offer/answer exchange has been completed, either endpoint MAY 729 send a new offer in order to modify the session. The endpoints can 730 reuse the existing DTLS association if the key fingerprint values and 731 transport parameters indicated by each endpoint are unchanged. 732 Otherwise, following the rules for the initial offer/answer exchange, 733 the endpoints can negotiate and create a new DTLS association and, 734 once created, delete the previous DTLS association, following the 735 same rules for the initial offer/answer exchange. Each endpoint 736 needs to be prepared to receive data on both the new and old DTLS 737 associations as long as both are alive. 739 NEW TEXT: 741 4. SDP Offerer/Answerer Procedures 743 An endpoint (i.e., both the offerer and the answerer) MUST create an 744 SDP media description ("m=" line) for each UDPTL-over-DTLS media 745 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 746 "proto" field of the "m=" line. 748 The offerer and answerer MUST follow the SDP offer/answer procedures 749 defined in [RFCXXXX] in order to negotiate the DTLS association 750 associated with the UDPTL-over-DTLS media stream. In addition, 751 the offerer and answerer MUST use the SDP attributes defined for 752 UDPTL over UDP, as defined in [ITU.T38.2010]. 754 Update to section 5.2.1: 756 ------------------------ 758 OLD TEXT: 760 5.2.1. ICE Usage 762 When Interactive Connectivity Establishment (ICE) [RFC5245] is being 763 used, the ICE connectivity checks are performed before the DTLS 764 handshake begins. Note that if aggressive nomination mode is used, 765 multiple candidate pairs may be marked valid before ICE finally 766 converges on a single candidate pair. User Agents (UAs) MUST treat 767 all ICE candidate pairs associated with a single component as part of 768 the same DTLS association. Thus, there will be only one DTLS 769 handshake even if there are multiple valid candidate pairs. Note 770 that this may mean adjusting the endpoint IP addresses if the 771 selected candidate pair shifts, just as if the DTLS packets were an 772 ordinary media stream. In the case of an ICE restart, the DTLS 773 handshake procedure is repeated, and a new DTLS association is 774 created. Once the DTLS handshake is completed and the new DTLS 775 association has been created, the previous DTLS association is 776 deleted. 778 NEW TEXT: 780 5.2.1. ICE Usage 782 The Interactive Connectivity Establishment (ICE) [RFC5245] 783 considerations for DTLS-protected media are described in 784 [RFCXXXX]. 786 11. Security Considerations 788 This specification does not modify the security considerations 789 associated with DTLS, or the SDP offer/answer mechanism. In addition 790 to the introduction of the SDP 'dtls-connection' attribute, the 791 specification simply clarifies the procedures for negotiating and 792 establishing a DTLS association. 794 12. IANA Considerations 796 12.1. Registration of New SDP Attribute 798 This document updates the "Session Description Protocol Parameters" 799 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 800 it adds the SDP attributes in Section 12.1 to the table for SDP media 801 level attributes. 803 Attribute name: dtls-connection 804 Type of attribute: media-level 805 Subject to charset: no 806 Purpose: TBD 807 Appropriate Values: see Section X 808 Contact name: Christer Holmberg 810 13. Acknowledgements 812 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat and Jens 813 Guballa for providing comments and suggestions on the draft. 815 14. Change Log 817 [RFC EDITOR NOTE: Please remove this section when publishing] 819 Changes from draft-ietf-mmusic-sdp-dtls-02 821 o - Updated RFCs added to boilerplate. 823 Changes from draft-ietf-mmusic-sdp-dtls-01 825 o - Annex regarding 'dtls-connection-id' attribute removed. 827 o - Additional SDP offer/answer procedures, related to certificates, 828 added. 830 o - Updates to RFC 5763 and RFC 7345 added. 832 o - Transport protocol considerations added. 834 Changes from draft-ietf-mmusic-sdp-dtls-00 836 o - SDP 'connection' attribute replaced with new 'dtls-connection' 837 attribute. 839 o - IANA Considerations added. 841 o - E-mail regarding 'dtls-connection-id' attribute added as Annex. 843 Changes from draft-holmberg-mmusic-sdp-dtls-01 845 o - draft-ietf-mmusic version of draft submitted. 847 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 848 with another expired draft. 850 o - Clarify that if ufrag in offer is unchanged, it must be 851 unchanged in associated answer. 853 o - SIP Considerations section added. 855 o - Section about multiple SDP fingerprint attributes added. 857 Changes from draft-holmberg-mmusic-sdp-dtls-00 859 o - Editorial changes and clarifications. 861 15. Normative References 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, 865 DOI 10.17487/RFC2119, March 1997, 866 . 868 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 869 A., Peterson, J., Sparks, R., Handley, M., and E. 870 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 871 DOI 10.17487/RFC3261, June 2002, 872 . 874 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 875 with Session Description Protocol (SDP)", RFC 3264, 876 DOI 10.17487/RFC3264, June 2002, 877 . 879 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 880 the Session Description Protocol (SDP)", RFC 4145, 881 DOI 10.17487/RFC4145, September 2005, 882 . 884 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 885 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 886 July 2006, . 888 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 889 Transport Layer Security (TLS) Protocol in the Session 890 Description Protocol (SDP)", RFC 4572, 891 DOI 10.17487/RFC4572, July 2006, 892 . 894 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 895 Specifications: ABNF", STD 68, RFC 5234, 896 DOI 10.17487/RFC5234, January 2008, 897 . 899 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 900 (ICE): A Protocol for Network Address Translator (NAT) 901 Traversal for Offer/Answer Protocols", RFC 5245, 902 DOI 10.17487/RFC5245, April 2010, 903 . 905 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 906 for Establishing a Secure Real-time Transport Protocol 907 (SRTP) Security Context Using Datagram Transport Layer 908 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 909 2010, . 911 Authors' Addresses 913 Christer Holmberg 914 Ericsson 915 Hirsalantie 11 916 Jorvas 02420 917 Finland 919 Email: christer.holmberg@ericsson.com 921 Roman Shpount 922 TurboBridge 923 4905 Del Ray Avenue, Suite 300 924 Bethesda, MD 20814 925 USA 927 Phone: +1 (240) 292-6632 928 Email: rshpount@turbobridge.com