idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-04.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 (January 18, 2016) is 3020 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 640, but not defined == Missing Reference: 'RFC4474' is mentioned on line 540, but not defined ** Obsolete undefined reference: RFC 4474 (Obsoleted by RFC 8224) == Missing Reference: 'RFCXXXX' is mentioned on line 789, but not defined == Missing Reference: 'ITU.T38.2010' is mentioned on line 757, but not defined == Unused Reference: 'RFC5234' is defined on line 914, 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) Summary: 4 errors (**), 0 flaws (~~), 6 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: July 21, 2016 January 18, 2016 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-04.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 July 21, 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 . . . . . . . . . . . . . . . . . . 6 66 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 7 67 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7 68 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Transport Protocol Considerations . . . . . . . . . . . . . . 8 70 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 8 71 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 9 75 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 14 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 79 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 14. Normative References . . . . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. This 86 draft defines the SDP Offer/Answer [RFC3264] procedures for 87 negotiation DTLS in general, based on the procedures in [RFC5763]. 89 This draft also defines a new SDP attribute, 'dtls-connection'. The 90 attribute is used in SDP offers and answers to explicitly indicate 91 whether a new DTLS association is to be established. 93 As defined in [RFC5763], a new DTLS association MUST be established 94 when transport parameters are changed. Transport parameter change is 95 not well defined when Interactive Connectivity Establishment (ICE) 96 [RFC5245] is used. One possible way to determine a transport change 97 is based on ufrag change, but the ufrag value is changed both when 98 ICE is negotiated and when ICE restart [RFC5245] occurs. These 99 events do not always require a new DTLS association to be 100 established, but currently there is no way to explicitly indicate in 101 an SDP offer or answer whether a new DTLS association is required. 102 To solve that problem, this draft defines a new SDP attribute, 'dtls- 103 connection'. The attribute is used in SDP offers and answers to 104 explicitly indicate whether a new DTLS association is to be 105 established/re-established. The attribute can be used both with and 106 without ICE. 108 2. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Establishing a new DTLS Association 116 3.1. General 118 A new DTLS association MUST be established in the following cases: 120 o The DTLS roles change; 122 o The fingerprint (certificate) value changes; or 124 o The establishment of a new DTLS association is explicitly 125 signaled; 127 NOTE: The first two items list above are based on the procedures in 128 [RFC5763]. This draft adds the support for explicit signaling. 130 Whenever an entity determines, based on the criteria above, that a 131 new DTLS association is the entity MUST initiate an associated SDP 132 offer/answer transaction, following to the procedures in Section 5. 134 The sections below describe typical cases where a new DTLS 135 association needs to be established. 137 3.2. Change of Local Transport Parameters 139 If an endpoint modifies its local transport parameters (IP address 140 and/or port), and if the modification requires a new DTLS 141 association, the endpoint MUST either change its DTLS role, its 142 fingerprint value and/or use the SDP 'dtls-connection' attribute with 143 a 'new' value Section 4. 145 3.3. Change of ICE ufrag value 147 If an endpoint uses ICE, and modifies a local ufrag value, and if the 148 modification requires a new DTLS association, the endpoint MUST 149 either change its DTLS role, its fingerprint value and/or use the SDP 150 'dtls-connection' attribute with a 'new' value Section 4. 152 3.4. Multiple SDP fingerprint attributes 154 It is possible to associate multiple SDP fingerprint attribute values 155 to an 'm-' line. If any of the attribute values associated with an 156 'm-' line are removed, or if any new attribute values are added, it 157 is considered a fingerprint value change. 159 4. SDP dtls-connection Attribute 161 The SDP 'connection' attribute [RFC4145] was originally defined for 162 connection-oriented protocols, e.g. TCP and TLS. This section 163 defines a similar attribute, 'dtls-connection', to be used with DTLS. 165 Name: dtls-connection 167 Value: conn-value 169 Usage Level: media 171 Charset Dependent: no 173 Syntax: 175 conn-value = "new" / "existing" 177 Example: 179 a=dtls-connection:existing 181 A 'dtls-connection' attribute value of 'new' indicates that a new 182 DTLS association MUST be established. A 'dtls-connection' attribute 183 value of 'existing' indicates that a new DTLS association MUST NOT be 184 established. 186 Unlike the SDP 'connection' attribute for TLS, there is no default 187 value defined for the 'dtls-connection' attribute. Implementations 188 that wish to use the attribute MUST explicitly include it in SDP 189 offers and answers. If an offer or answer does not contain an 190 attribute, other means needs to be used in order for endpoints to 191 determine whether an offer or answer is associated with an event that 192 requires the DTLS association to be re-established. 194 The SDP Offer/Answer [RFC3264] procedures associated with the 195 attribute are defined in Section 5 197 5. SDP Offer/Answer Procedures 199 5.1. General 201 This section defines the generic SDP offer/answer procedures for 202 negotiating a DTLS association. Additional procedures (e.g. 203 regarding usage of usage specific SDP attributes etc) for individual 204 DTLS usages (e.g. SRTP-DTLS) are outside the scope of this 205 specification, and needs to be specified in a usage specific 206 specification. 208 NOTE: The procedures in this section are generalizations of 209 procedures first specified in SRTP-DTLS [RFC5763], with the addition 210 of usage of the SDP 'dtls-connection' attribute. That document is 211 herein revised to make use of these new procedures. 213 The procedures in this section apply to an SDP media description 214 ("m=" line) associated a DTLS-protected media/data stream. 216 In order to negotiate a DTLS association, the following SDP 217 attributes are used: 219 o The SDP 'setup' attribute, defined in [RFC4145], is used to 220 negotiate the DTLS roles; 222 o The SDP 'fingerprint' attribute, defined in [RFC4572], is used to 223 provide the fingerprint value; and 225 o The SDP 'dtls-connection' attribute, defined in this 226 specification, is used to explicitly indicate whether a new DTLS 227 association is to be established or whether a previous association 228 is to be used. 230 Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] when 231 negotiating a DTLS association. 233 The SDP 'connection' attribute MAY be used if the usage is associated 234 with another protocol layer, e.g. SCTP or TCP, used together with 235 DTLS. 237 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 238 'setup' attribute 'holdconn' value when negotiating a DTLS 239 association. 241 Endpoints MUST support the algorithms defined in **** Endpoints MUST 242 support SHA-256 for generating and verifying the fingerprint value 243 associated with the DTLS association. The use of SHA-256 is 244 preferred. 246 Endpoints MUST, at a minimum, support 247 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 248 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 249 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 250 Secrecy (PFS) cipher suites over non-PFS cipher suites. 251 Implementations SHOULD disable TLS-level compression. 253 The certificate received during the DTLS handshake MUST match the 254 fingerprint received in the SDP "fingerprint" attribute. If the 255 fingerprint does not match the hashed certificate, then the endpoint 256 MUST tear down the media session immediately. Note that it is 257 permissible to wait until the other side's fingerprint has been 258 received before establishing the connection; however, this may have 259 undesirable latency effects. 261 5.2. Generating the Initial SDP Offer 263 When the offerer sends the initial offer, and the offerer wants to 264 establish a DTLS association, it MUST insert an SDP 'dtls-connection' 265 attribute with a 'new' value in the offer. In addition, the offerer 266 MUST insert an SDP 'setup' attribute according to the procedures in 267 [RFC4145], and an SDP 'fingerprint' attribute according to the 268 procedures in [RFC4572], in the offer. 270 If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 271 'passive' value, the offerer MUST be prepared to receive a DTLS 272 ClientHello message (if a new DTLS association is established by the 273 answerer) from the answerer before it receives the SDP answer. 275 5.3. Generating the Answer 277 If an answerer receives an offer that contains an SDP 'dtls- 278 connection' attribute with a 'new' value, or if the answerer receives 279 and offer that contains an 'dtls-connection' attribute with an 280 'existing' value and the answerer determines (based on the criteria 281 for establishing a new DTLS association) that a new DTLS association 282 is to be established, the answerer MUST insert a 'new' value in the 283 associated answer. In addition, the answerer MUST insert an SDP 284 'setup' attribute according to the procedures in [RFC4145], and an 285 SDP 'fingerprint' attribute according to the procedures in [RFC4572], 286 in the answer. 288 If an answerer receives an offer that contains an SDP 'dtls- 289 connection' attribute with a 'new' value, and if the answerer does 290 not accept the establishment of a new DTLS association, the answerer 291 MUST reject the "m=" lines associated with the suggested DTLS 292 association [RFC3264]. 294 If an answerer receives an offer that contains a 'dtls-connection' 295 attribute with an 'existing' value, and if the answerer determines 296 that a new DTLS association is not to be established, the answerer 297 MUST insert a 'dtls-connection' attribute with an 'existing' value in 298 the associated answer. In addition, the answerer MUST insert an SDP 299 'setup' attribute with a value that does not change the previously 300 negotiated DTLS roles, and an SDP 'fingerprint' attribute with a 301 value that does not change the previously sent fingerprint, in the 302 answer. 304 If the answerer receives an offer that does not contain an SDP 'dtls- 305 connection' attribute, the answerer MUST NOT insert a 'dtls- 306 connection' attribute in the answer. 308 If a new DTLS association is to be established, and if the answerer 309 inserts an SDP 'setup' attribute with an 'active' value in the 310 answer, the answerer MUST initiate a DTLS handshake by sending a DTLS 311 ClientHello message towards the the offerer. 313 5.4. Offerer Processing of the SDP Answer 315 When an offerer receives an answer that contains an SDP 'dtls- 316 connection' attribute with a 'new' value, and if the offerer becomes 317 DTLS client (based on the value of the SDP 'setup' attribute value 318 [RFC4145]), the offerer MUST establish a DTLS association. If the 319 offerer becomes DTLS server, it MUST wait for the answerer to 320 establish the DTLS association. 322 If the answer contains an SDP 'dtls-connection' attribute with an 323 'existing' value, the offerer will continue using the previously 324 established DTLS association. It is considered an error case if the 325 answer contains a 'dtls-connection' attribute with an 'existing' 326 value, and a DTLS association does not exist. 328 5.5. Modifying the Session 330 When the offerer sends a subsequent offer, and if the offerer wants 331 to establish a new DTLS association, the offerer MUST insert an SDP 332 'dtls-connection' attribute with a 'new' value in the offer. In 333 addition, the offerer MUST insert an SDP 'setup' attribute according 334 to the procedures in [RFC4145], and an SDP 'fingerprint' attribute 335 according to the procedures in [RFC4572], in the offer. 337 when the offerer sends a subsequent offer, and the offerer does not 338 want to establish a new DTLS association, and if a previously 339 established DTLS association exists, the offerer MUST insert an SDP 340 'dtls-connection' attribute with an 'existing' value in the offer. 341 In addition, the offerer MUST insert an SDP 'setup' attribute with a 342 value that does not change the previously negotiated DTLS roles, and 343 an SDP 'fingerprint' attribute with a value that does not change the 344 previously sent fingerprint, in the offer. 346 NOTE: When a new DTLS association is established, each endpoint needs 347 to be prepared to receive data on both the new and old DTLS 348 associations as long as both are alive. 350 6. ICE Considerations 352 When ICE is used, the ICE connectivity checks are performed before 353 the DTLS handshake begins. Note that if aggressive nomination mode 354 is used, multiple candidate pairs may be marked valid before ICE 355 finally converges on a single candidate pair. 357 An ICE restart [RFC5245] does not by default require a new DTLS 358 association to be established. 360 As defined in [RFC5763], each ICE candidate associated with a 361 component is treated as being part of the same DTLS association. 362 Therefore, from a DTLS perspective it is not considered a change of 363 local transport parameters when an endpoint switches between those 364 ICE candidates. 366 7. Transport Protocol Considerations 368 7.1. Transport Re-Usage 370 If DTLS is transported on top of a connection-oriented transport 371 protocol (e.g. TCP or SCTP), where all IP packets are acknowledged, 372 all DTLS packets associated with a previous DTLS association MUST be 373 acknowledged (or timed out) before a new DTLS association can be 374 established on the same transport. 376 8. SIP Considerations 378 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 379 signal protocol for establishing a multimedia session, dialogs 380 [RFC3261] might be established between the caller and multiple 381 callees. This is referred to as forking. If forking occurs, 382 separate DTLS associations MUST be established between the caller and 383 each callee. 385 It is possible to send an INVITE request which does not contain an 386 SDP offer. Such INVITE request is often referred to as an 'empty 387 INVITE', or an 'offerless INVITE'. The receiving endpoint will 388 include the SDP offer in a response associated with the response. 389 When the endpoint generates such SDP offer, it MUST assign an SDP 390 connection attribute, with a 'new' value, to each 'm-' line that 391 describes DTLS protected media. If ICE is used, the endpoint MUST 392 allocate a new set of ICE candidates, in order to ensure that two 393 DTLS association would not be running over the same transport. 395 9. RFC Updates 397 9.1. General 399 This section updates specifications that use DTLS-protected media, in 400 order to reflect the procedures defined in this specification. 402 9.2. Update to RFC 5763 404 Update to section 5: 405 -------------------- 407 OLD TEXT: 409 5. Establishing a Secure Channel 411 The two endpoints in the exchange present their identities as part of 412 the DTLS handshake procedure using certificates. This document uses 413 certificates in the same style as described in "Connection-Oriented 414 Media Transport over the Transport Layer Security (TLS) Protocol in 415 the Session Description Protocol (SDP)" [RFC4572]. 417 If self-signed certificates are used, the content of the 418 subjectAltName attribute inside the certificate MAY use the uniform 419 resource identifier (URI) of the user. This is useful for debugging 420 purposes only and is not required to bind the certificate to one of 421 the communication endpoints. The integrity of the certificate is 422 ensured through the fingerprint attribute in the SDP. The 423 subjectAltName is not an important component of the certificate 424 verification. 426 The generation of public/private key pairs is relatively expensive. 427 Endpoints are not required to generate certificates for each session. 429 The offer/answer model, defined in [RFC3264], is used by protocols 430 like the Session Initiation Protocol (SIP) [RFC3261] to set up 431 multimedia sessions. In addition to the usual contents of an SDP 432 [RFC4566] message, each media description ("m=" line and associated 433 parameters) will also contain several attributes as specified in 434 [RFC5764], [RFC4145], and [RFC4572]. 436 When an endpoint wishes to set up a secure media session with another 437 endpoint, it sends an offer in a SIP message to the other endpoint. 438 This offer includes, as part of the SDP payload, the fingerprint of 439 the certificate that the endpoint wants to use. The endpoint SHOULD 440 send the SIP message containing the offer to the offerer's SIP proxy 441 over an integrity protected channel. The proxy SHOULD add an 442 Identity header field according to the procedures outlined in 443 [RFC4474]. The SIP message containing the offer SHOULD be sent to 444 the offerer's SIP proxy over an integrity protected channel. When 445 the far endpoint receives the SIP message, it can verify the identity 446 of the sender using the Identity header field. Since the Identity 447 header field is a digital signature across several SIP header fields, 448 in addition to the body of the SIP message, the receiver can also be 449 certain that the message has not been tampered with after the digital 450 signature was applied and added to the SIP message. 452 The far endpoint (answerer) may now establish a DTLS association with 453 the offerer. Alternately, it can indicate in its answer that the 454 offerer is to initiate the TLS association. In either case, mutual 455 DTLS certificate-based authentication will be used. After completing 456 the DTLS handshake, information about the authenticated identities, 457 including the certificates, are made available to the endpoint 458 application. The answerer is then able to verify that the offerer's 459 certificate used for authentication in the DTLS handshake can be 460 associated to the certificate fingerprint contained in the offer in 461 the SDP. At this point, the answerer may indicate to the end user 462 that the media is secured. The offerer may only tentatively accept 463 the answerer's certificate since it may not yet have the answerer's 464 certificate fingerprint. 466 When the answerer accepts the offer, it provides an answer back to 467 the offerer containing the answerer's certificate fingerprint. At 468 this point, the offerer can accept or reject the peer's certificate 469 and the offerer can indicate to the end user that the media is 470 secured. 472 Note that the entire authentication and key exchange for securing the 473 media traffic is handled in the media path through DTLS. The 474 signaling path is only used to verify the peers' certificate 475 fingerprints. 477 The offer and answer MUST conform to the following requirements. 479 o The endpoint MUST use the setup attribute defined in [RFC4145]. 480 The endpoint that is the offerer MUST use the setup attribute 481 value of setup:actpass and be prepared to receive a client_hello 482 before it receives the answer. The answerer MUST use either a 483 setup attribute value of setup:active or setup:passive. Note that 484 if the answerer uses setup:passive, then the DTLS handshake will 485 not begin until the answerer is received, which adds additional 486 latency. setup:active allows the answer and the DTLS handshake to 487 occur in parallel. Thus, setup:active is RECOMMENDED. Whichever 488 party is active MUST initiate a DTLS handshake by sending a 489 ClientHello over each flow (host/port quartet). 491 o The endpoint MUST NOT use the connection attribute defined in 492 [RFC4145]. 494 o The endpoint MUST use the certificate fingerprint attribute as 495 specified in [RFC4572]. 497 o The certificate presented during the DTLS handshake MUST match the 498 fingerprint exchanged via the signaling path in the SDP. The 499 security properties of this mechanism are described in Section 8. 501 o If the fingerprint does not match the hashed certificate, then the 502 endpoint MUST tear down the media session immediately. Note that 503 it is permissible to wait until the other side's fingerprint has 504 been received before establishing the connection; however, this 505 may have undesirable latency effects. 507 NEW TEXT: 509 5. Establishing a Secure Channel 511 The two endpoints in the exchange present their identities as part of 512 the DTLS handshake procedure using certificates. This document uses 513 certificates in the same style as described in "Connection-Oriented 514 Media Transport over the Transport Layer Security (TLS) Protocol in 515 the Session Description Protocol (SDP)" [RFC4572]. 517 If self-signed certificates are used, the content of the 518 subjectAltName attribute inside the certificate MAY use the uniform 519 resource identifier (URI) of the user. This is useful for debugging 520 purposes only and is not required to bind the certificate to one of 521 the communication endpoints. The integrity of the certificate is 522 ensured through the fingerprint attribute in the SDP. The 523 subjectAltName is not an important component of the certificate 524 verification. 526 The generation of public/private key pairs is relatively expensive. 527 Endpoints are not required to generate certificates for each session. 529 The offer/answer model, defined in [RFC3264], is used by protocols 530 like the Session Initiation Protocol (SIP) [RFC3261] to set up 531 multimedia sessions. 533 When an endpoint wishes to set up a secure media session with another 534 endpoint, it sends an offer in a SIP message to the other endpoint. 535 This offer includes, as part of the SDP payload, the fingerprint of 536 the certificate that the endpoint wants to use. The endpoint SHOULD 537 send the SIP message containing the offer to the offerer's SIP proxy 538 over an integrity protected channel. The proxy SHOULD add an 539 Identity header field according to the procedures outlined in 540 [RFC4474]. The SIP message containing the offer SHOULD be sent to 541 the offerer's SIP proxy over an integrity protected channel. When 542 the far endpoint receives the SIP message, it can verify the identity 543 of the sender using the Identity header field. Since the Identity 544 header field is a digital signature across several SIP header fields, 545 in addition to the body of the SIP message, the receiver can also be 546 certain that the message has not been tampered with after the digital 547 signature was applied and added to the SIP message. 549 The far endpoint (answerer) may now establish a DTLS association with 550 the offerer. Alternately, it can indicate in its answer that the 551 offerer is to initiate the TLS association. In either case, mutual 552 DTLS certificate-based authentication will be used. After completing 553 the DTLS handshake, information about the authenticated identities, 554 including the certificates, are made available to the endpoint 555 application. The answerer is then able to verify that the offerer's 556 certificate used for authentication in the DTLS handshake can be 557 associated to the certificate fingerprint contained in the offer in 558 the SDP. At this point, the answerer may indicate to the end user 559 that the media is secured. The offerer may only tentatively accept 560 the answerer's certificate since it may not yet have the answerer's 561 certificate fingerprint. 563 When the answerer accepts the offer, it provides an answer back to 564 the offerer containing the answerer's certificate fingerprint. At 565 this point, the offerer can accept or reject the peer's certificate 566 and the offerer can indicate to the end user that the media is 567 secured. 569 Note that the entire authentication and key exchange for securing the 570 media traffic is handled in the media path through DTLS. The 571 signaling path is only used to verify the peers' certificate 572 fingerprints. 574 The offerer and answerer MUST follow the SDP offer/answer procedures 575 defined in [RFCXXXX]. 577 Update to section 6.6: 578 ---------------------- 580 OLD TEXT: 582 6.6. Session Modification 584 Once an answer is provided to the offerer, either endpoint MAY 585 request a session modification that MAY include an updated offer. 586 This session modification can be carried in either an INVITE or 587 UPDATE request. The peers can reuse the existing associations if 588 they are compatible (i.e., they have the same key fingerprints and 589 transport parameters), or establish a new one following the same 590 rules are for initial exchanges, tearing down the existing 591 association as soon as the offer/answer exchange is completed. Note 592 that if the active/passive status of the endpoints changes, a new 593 connection MUST be established. 595 NEW TEXT: 597 6.6. Session Modification 599 Once an answer is provided to the offerer, either endpoint MAY 600 request a session modification that MAY include an updated offer. 601 This session modification can be carried in either an INVITE or 602 UPDATE request. The peers can reuse an existing DTLS association, 603 or establish a new one, following the procedures in [RFCXXXX]. 605 Update to section 6.7.1: 606 ------------------------ 608 OLD TEXT: 610 6.7.1. ICE Interaction 612 Interactive Connectivity Establishment (ICE), as specified in 613 [RFC5245], provides a methodology of allowing participants in 614 multimedia sessions to verify mutual connectivity. When ICE is being 615 used, the ICE connectivity checks are performed before the DTLS 616 handshake begins. Note that if aggressive nomination mode is used, 617 multiple candidate pairs may be marked valid before ICE finally 618 converges on a single candidate pair. Implementations MUST treat all 619 ICE candidate pairs associated with a single component as part of the 620 same DTLS association. Thus, there will be only one DTLS handshake 621 even if there are multiple valid candidate pairs. Note that this may 622 mean adjusting the endpoint IP addresses if the selected candidate 623 pair shifts, just as if the DTLS packets were an ordinary media 624 stream. 626 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 627 packets are sent directly over UDP, not over DTLS. [RFC5764] 628 describes how to demultiplex STUN packets from DTLS packets and SRTP 629 packets. 631 NEW TEXT: 633 6.7.1. ICE Interaction 635 The Interactive Connectivity Establishment (ICE) [RFC5245] 636 considerations for DTLS-protected media are described in 637 [RFCXXXX]. 639 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 640 packets are sent directly over UDP, not over DTLS. [RFC5764] 641 describes how to demultiplex STUN packets from DTLS packets and SRTP 642 packets. 644 9.3. Update to RFC 7345 646 Update to section 4: 647 -------------------- 649 OLD TEXT: 651 4. SDP Offerer/Answerer Procedures 653 4.1. General 655 An endpoint (i.e., both the offerer and the answerer) MUST create an 656 SDP media description ("m=" line) for each UDPTL-over-DTLS media 657 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 658 "proto" field of the "m=" line. 660 The procedures in this section apply to an "m=" line associated with 661 a UDPTL-over-DTLS media stream. 663 In order to negotiate a UDPTL-over-DTLS media stream, the following 664 SDP attributes are used: 666 o The SDP attributes defined for UDPTL over UDP, as described in 667 [ITU.T38.2010]; and 669 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 670 described in this section. 672 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 674 In order to negotiate the TLS roles for the UDPTL-over-DTLS transport 675 connection, the endpoint MUST use the SDP "setup" attribute 676 [RFC4145]. 678 If the endpoint supports, and is willing to use, a cipher suite with 679 an associated certificate, the endpoint MUST include an SDP 680 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 681 for generating and verifying the SDP "fingerprint" attribute value. 682 The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST 683 support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 684 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 685 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 686 Secrecy (PFS) cipher suites over non-PFS cipher suites. 687 Implementations SHOULD disable TLS-level compression. 689 If a cipher suite with an associated certificate is selected during 690 the DTLS handshake, the certificate received during the DTLS 691 handshake MUST match the fingerprint received in the SDP 692 "fingerprint" attribute. If the fingerprint does not match the 693 hashed certificate, then the endpoint MUST tear down the media 694 session immediately. Note that it is permissible to wait until the 695 other side's fingerprint has been received before establishing the 696 connection; however, this may have undesirable latency effects. 698 4.2. Generating the Initial Offer 700 The offerer SHOULD assign the SDP "setup" attribute with a value of 701 "actpass", unless the offerer insists on being either the sender or 702 receiver of the DTLS ClientHello message, in which case the offerer 703 can use either a value of "active" (the offerer will be the sender of 704 ClientHello) or "passive" (the offerer will be the receiver of 705 ClientHello). The offerer MUST NOT assign an SDP "setup" attribute 706 with a "holdconn" value. 708 If the offerer assigns the SDP "setup" attribute with a value of 709 "actpass" or "passive", the offerer MUST be prepared to receive a 710 DTLS ClientHello message before it receives the SDP answer. 712 4.3. Generating the Answer 713 If the answerer accepts the offered UDPTL-over-DTLS transport 714 connection, in the associated SDP answer, the answerer MUST assign an 715 SDP "setup" attribute with a value of either "active" or "passive", 716 according to the procedures in [RFC4145]. The answerer MUST NOT 717 assign an SDP "setup" attribute with a value of "holdconn". 719 If the answerer assigns an SDP "setup" attribute with a value of 720 "active" value, the answerer MUST initiate a DTLS handshake by 721 sending a DTLS ClientHello message on the negotiated media stream, 722 towards the IP address and port of the offerer. 724 4.4. Offerer Processing of the Answer 726 When the offerer receives an SDP answer, if the offerer ends up being 727 active it MUST initiate a DTLS handshake by sending a DTLS 728 ClientHello message on the negotiated media stream, towards the IP 729 address and port of the answerer. 731 4.5. Modifying the Session 733 Once an offer/answer exchange has been completed, either endpoint MAY 734 send a new offer in order to modify the session. The endpoints can 735 reuse the existing DTLS association if the key fingerprint values and 736 transport parameters indicated by each endpoint are unchanged. 737 Otherwise, following the rules for the initial offer/answer exchange, 738 the endpoints can negotiate and create a new DTLS association and, 739 once created, delete the previous DTLS association, following the 740 same rules for the initial offer/answer exchange. Each endpoint 741 needs to be prepared to receive data on both the new and old DTLS 742 associations as long as both are alive. 744 NEW TEXT: 746 4. SDP Offerer/Answerer Procedures 748 An endpoint (i.e., both the offerer and the answerer) MUST create an 749 SDP media description ("m=" line) for each UDPTL-over-DTLS media 750 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 751 "proto" field of the "m=" line. 753 The offerer and answerer MUST follow the SDP offer/answer procedures 754 defined in [RFCXXXX] in order to negotiate the DTLS association 755 associated with the UDPTL-over-DTLS media stream. In addition, 756 the offerer and answerer MUST use the SDP attributes defined for 757 UDPTL over UDP, as defined in [ITU.T38.2010]. 759 Update to section 5.2.1: 761 ------------------------ 763 OLD TEXT: 765 5.2.1. ICE Usage 767 When Interactive Connectivity Establishment (ICE) [RFC5245] is being 768 used, the ICE connectivity checks are performed before the DTLS 769 handshake begins. Note that if aggressive nomination mode is used, 770 multiple candidate pairs may be marked valid before ICE finally 771 converges on a single candidate pair. User Agents (UAs) MUST treat 772 all ICE candidate pairs associated with a single component as part of 773 the same DTLS association. Thus, there will be only one DTLS 774 handshake even if there are multiple valid candidate pairs. Note 775 that this may mean adjusting the endpoint IP addresses if the 776 selected candidate pair shifts, just as if the DTLS packets were an 777 ordinary media stream. In the case of an ICE restart, the DTLS 778 handshake procedure is repeated, and a new DTLS association is 779 created. Once the DTLS handshake is completed and the new DTLS 780 association has been created, the previous DTLS association is 781 deleted. 783 NEW TEXT: 785 5.2.1. ICE Usage 787 The Interactive Connectivity Establishment (ICE) [RFC5245] 788 considerations for DTLS-protected media are described in 789 [RFCXXXX]. 791 10. Security Considerations 793 This specification does not modify the security considerations 794 associated with DTLS, or the SDP offer/answer mechanism. In addition 795 to the introduction of the SDP 'dtls-connection' attribute, the 796 specification simply clarifies the procedures for negotiating and 797 establishing a DTLS association. 799 11. IANA Considerations 801 This document updates the "Session Description Protocol Parameters" 802 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 803 it adds the SDP dtls-connection attribute to the table for SDP media 804 level attributes. 806 Attribute name: dtls-connection 807 Type of attribute: media-level 808 Subject to charset: no 809 Purpose: TBD 810 Appropriate Values: see Section X 811 Contact name: Christer Holmberg 813 12. Acknowledgements 815 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat and Jens 816 Guballa for providing comments and suggestions on the draft. 818 13. Change Log 820 [RFC EDITOR NOTE: Please remove this section when publishing] 822 Changes from draft-ietf-mmusic-sdp-dtls-03 824 o Changes based on comments from Paul Kyzivat: 826 o - Modification of dtls-connection attribute section. 828 o - Removal of IANA considerations subsection. 830 o - Making note into normative text in o/a section. 832 o Changes based on comments from Martin Thompson: 834 o - Abbreviations section removed. 836 o - Clarify that a new DTLS association requires a new o/a 837 transaction. 839 Changes from draft-ietf-mmusic-sdp-dtls-02 841 o - Updated RFCs added to boilerplate. 843 Changes from draft-ietf-mmusic-sdp-dtls-01 845 o - Annex regarding 'dtls-connection-id' attribute removed. 847 o - Additional SDP offer/answer procedures, related to certificates, 848 added. 850 o - Updates to RFC 5763 and RFC 7345 added. 852 o - Transport protocol considerations added. 854 Changes from draft-ietf-mmusic-sdp-dtls-00 856 o - SDP 'connection' attribute replaced with new 'dtls-connection' 857 attribute. 859 o - IANA Considerations added. 861 o - E-mail regarding 'dtls-connection-id' attribute added as Annex. 863 Changes from draft-holmberg-mmusic-sdp-dtls-01 865 o - draft-ietf-mmusic version of draft submitted. 867 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 868 with another expired draft. 870 o - Clarify that if ufrag in offer is unchanged, it must be 871 unchanged in associated answer. 873 o - SIP Considerations section added. 875 o - Section about multiple SDP fingerprint attributes added. 877 Changes from draft-holmberg-mmusic-sdp-dtls-00 879 o - Editorial changes and clarifications. 881 14. Normative References 883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 884 Requirement Levels", BCP 14, RFC 2119, 885 DOI 10.17487/RFC2119, March 1997, 886 . 888 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 889 A., Peterson, J., Sparks, R., Handley, M., and E. 890 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 891 DOI 10.17487/RFC3261, June 2002, 892 . 894 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 895 with Session Description Protocol (SDP)", RFC 3264, 896 DOI 10.17487/RFC3264, June 2002, 897 . 899 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 900 the Session Description Protocol (SDP)", RFC 4145, 901 DOI 10.17487/RFC4145, September 2005, 902 . 904 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 905 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 906 July 2006, . 908 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 909 Transport Layer Security (TLS) Protocol in the Session 910 Description Protocol (SDP)", RFC 4572, 911 DOI 10.17487/RFC4572, July 2006, 912 . 914 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 915 Specifications: ABNF", STD 68, RFC 5234, 916 DOI 10.17487/RFC5234, January 2008, 917 . 919 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 920 (ICE): A Protocol for Network Address Translator (NAT) 921 Traversal for Offer/Answer Protocols", RFC 5245, 922 DOI 10.17487/RFC5245, April 2010, 923 . 925 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 926 for Establishing a Secure Real-time Transport Protocol 927 (SRTP) Security Context Using Datagram Transport Layer 928 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 929 2010, . 931 Authors' Addresses 933 Christer Holmberg 934 Ericsson 935 Hirsalantie 11 936 Jorvas 02420 937 Finland 939 Email: christer.holmberg@ericsson.com 940 Roman Shpount 941 TurboBridge 942 4905 Del Ray Avenue, Suite 300 943 Bethesda, MD 20814 944 USA 946 Phone: +1 (240) 292-6632 947 Email: rshpount@turbobridge.com