idnits 2.17.1 draft-ietf-mmusic-udptl-dtls-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2014) is 3596 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: 'RFC-XXXX' is mentioned on line 434, but not defined ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** 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) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.T30.2005' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.T38.2010' -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft I. Sedlacek 4 Intended status: Standards Track Ericsson 5 Expires: December 22, 2014 G. Salgueiro 6 Cisco 7 June 20, 2014 9 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security 10 (DTLS) 11 draft-ietf-mmusic-udptl-dtls-10 13 Abstract 15 This document specifies how the UDP Transport Layer (UDPTL) protocol, 16 the predominant transport protocol for T.38 fax, can be transported 17 over the Datagram Transport Layer Security (DTLS) protocol, how the 18 usage of UDPTL over DTLS is indicated in the Session Description 19 Protocol (SDP), and how UDPTL over DTLS is negotiated in a session 20 established using the Session Initiation Protocol (SIP). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 22, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. SDP Offerer/Answerer Procedures . . . . . . . . . . . . . . . 5 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Generating the Initial Offer . . . . . . . . . . . . . . 6 62 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6 63 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7 64 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7 65 5. Miscellaneous Considerations . . . . . . . . . . . . . . . . 7 66 5.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7 68 5.2.1. ICE Usage . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2.2. STUN Interaction . . . . . . . . . . . . . . . . . . 8 70 5.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.4. Compatibility With UDPTL over UDP . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 80 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 15 82 A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in 83 An Existing Audio-Only Session . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 86 1. Introduction 88 While it is possible to transmit highly sensitive documents using 89 traditional telephony encryption devices, secure fax on the Public 90 Switched Telephone Network (PSTN) was never widely considered or 91 prioritized. This was mainly because of the challenges involved with 92 malevolent physical access to telephony equipment. As real-time 93 communications transition to IP networks, where information might 94 potentially be intercepted or spoofed, an appropriate level of 95 security for fax that offers integrity and confidentiality protection 96 is vital. 98 The overwhelmingly predominant fax transport protocol is UDPTL-based, 99 as described in section 9.1 of [ITU.T38.2010]. The protocol stack 100 for fax transport using UDPTL is shown in Figure 1. 102 +-----------------------------+ 103 | Internet facsimile protocol | 104 +-----------------------------+ 105 | UDPTL | 106 +-----------------------------+ 107 | UDP | 108 +-----------------------------+ 109 | IP | 110 +-----------------------------+ 112 Figure 1: Protocol stack for UDPTL over UDP 114 The following mechanisms are available for securing fax: 116 o [ITU.T30.2005] Annex H specifies a transport protocol-independent 117 application-layer integrity and confidentiality protection of fax 118 based on the RSA algorithm for use with the T.30 telephony 119 protocol by Group 3 facsimile equipment (G3FE). 120 o [ITU.T38.2010] specifies fax transport over RTP/SAVP which enables 121 integrity and confidentiality protection of fax in IP network. 123 Both of these mechanisms have been available for many years and never 124 gained any significant adoption in the market. This has prompted an 125 effort to develop an open standards-based approach to secure fax 126 communications over an IP-based transport. 128 Telephony-based protocols like T.30 offer application-level security 129 options like the RSA-based approached detailed in Annex H of the T.30 130 specification. The problem is that it is very sparingly implemented 131 and not enforced at the transport level. 133 It is worth noting that while T.38 over RTP offers a very viable 134 option for such standards-based IP security solution using SRTP, this 135 fax over IP transport never gained any traction in the market place 136 and accounts for a negligible percentage of fax over IP 137 implementations. 139 Thus, security mechanisms offering integrity and confidentiality 140 protection should be limited to UDPTL-based fax transport, which is 141 the only broad-based fax over IP solution. The 3rd Generation 142 Partnership Project (3GPP) launched a study on how best to provide 143 secure fax in the IP Multimedia Subsystem (IMS) for UDPTL. Results 144 of the study confirmed that this security was best achieved by using 145 UDPTL over DTLS. 147 This document specifies fax transport using UDPTL over DTLS 148 [RFC6347], which enables integrity and confidentiality protection of 149 fax in IP networks. The protocol stack which enhances fax transport 150 to offer integrity and confidentiality using UDPTL over DTLS is shown 151 in Figure 2. 153 +-----------------------------+ 154 | Internet facsimile protocol | 155 +-----------------------------+ 156 | UDPTL | 157 +-----------------------------+ 158 | DTLS | 159 +-----------------------------+ 160 | UDP | 161 +-----------------------------+ 162 | IP | 163 +-----------------------------+ 165 Figure 2: Protocol stack for UDPTL over DTLS over UDP 167 The primary motivations for the mechanism in this document are: 169 o The design of DTLS [RFC6347] is clearly defined and well 170 understood and implementations are widely available. 171 o No DTLS extensions are required in order to enable UDPTL transport 172 over DTLS. 173 o Fax transport using UDPTL over DTLS only requires insertion of the 174 DTLS layer between the UDPTL layer and the UDP layer, as shown in 175 Figure 2. The UDPTL layer and the layers above the UDPTL layer 176 require no modifications. 177 o UDPTL [ITU.T38.2010] is by far the most widely deployed fax 178 transport protocol in IP networks. 179 o 3GPP and the IP fax community need a mechanism to transport UDPTL 180 over DTLS in order to provide secure fax in SIP-based networks 181 (including IMS). 183 This document specifies the transport of UDPTL over DTLS using the 184 DTLS record layer "application_data" packets [RFC5246] [RFC6347]. 186 Since the DTLS record layer "application_data" packet does not 187 indicate whether it carries UDPTL, or some other protocol, the usage 188 of a dedicated DTLS association for transport of UDPTL needs to be 189 negotiated, e.g. using the Session Description Protocol (SDP) 190 [RFC4566] and the SDP offer/answer mechanism [RFC3264]. 192 Therefore, this document specifies a new value [RFC4566] for 193 the SDP media description ("m=" line) [RFC3264], in order to indicate 194 UDPTL over DTLS in SDP messages [RFC4566]. 196 2. Conventions 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in BCP 14, RFC 2119 201 [RFC2119]. 203 DTLS uses the term "session" to refer to a long-lived set of keying 204 material that spans DTLS associations. In this document, in order to 205 be consistent with SIP/SDP usage of "session" terminology, we use 206 "session" to refer to a multimedia session and use the term "DTLS 207 session" to refer to the DTLS construct. We use the term "DTLS 208 association" to refer to a particular DTLS cipher suite and keying 209 material set that is associated with a single host/port quartet. The 210 same DTLS session can be used to establish the keying material for 211 multiple DTLS associations. For consistency with other SIP/SDP 212 usage, we use the term "connection" when what's being referred to is 213 a multimedia stream that is not specifically DTLS. 215 3. Secure Channel 217 The UDPTL over DTLS media stream is negotiated using the SDP offer/ 218 answer mechanism [RFC3264]. See Section 4 for more details. 220 DTLS is used as specified in [RFC6347]. Once the DTLS handshake is 221 successfully completed (in order to prevent facsimile data from being 222 transmitted insecurely), the UDPTL packets MUST be transported in 223 DTLS record layer "application_data" packets. 225 4. SDP Offerer/Answerer Procedures 227 4.1. General 229 An endpoint (i.e. both the offerer and the answerer) MUST create an 230 SDP media description ("m=" line) for each UDPTL over DTLS media 231 stream, and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 232 "proto" field of the "m=" line. 234 The procedures in this section apply to an "m=" line associated with 235 a UDPTL over DTLS media stream. 237 In order to negotiate a UDPTL over DTLS media stream, the following 238 SDP attributes are used: 240 o The SDP attributes defined for UDPTL over UDP, as described in 241 [ITU.T38.2010]; and 242 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 243 described in this section. 245 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 247 In order to negotiate the TLS roles for the UDPTL over DTLS transport 248 connection, the endpoint MUST use the SDP "setup" attribute 249 [RFC4145]. 251 If the endpoint supports, and is willing to use, a cipher suite with 252 an associated certificate, the endpoint MUST include an SDP 253 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 254 for generating and verifying the SDP "fingerprint" attribute value. 255 The use of SHA-256 is preferred. UPDPTL over DTLS, at a minimum, 256 MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 257 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 258 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 259 Secrecy (PFS) cipher suites over non-PFS cipher suites. 260 Implementations SHOULD disable TLS-level compression. 262 If a cipher suite with an associated certificate is selected during 263 the DTLS handshake, the certificate received during the DTLS 264 handshake MUST match the fingerprint received in the SDP 265 "fingerprint" attribute. If the fingerprint does not match the 266 hashed certificate, then the endpoint MUST tear down the media 267 session immediately. Note that it is permissible to wait until the 268 other side's fingerprint has been received before establishing the 269 connection; however, this may have undesirable latency effects. 271 4.2. Generating the Initial Offer 273 The offerer SHOULD assign the SDP "setup" attribute with a value of 274 "actpass", unless the offerer insists on being either the sender or 275 receiver of the DTLS ClientHello message, in which case the offerer 276 can use either a value of "active" (the offerer will be the sender of 277 ClientHello) or "passive" (the offerer will be the receiver of 278 ClientHello). The offerer MUST NOT assign an SDP "setup" attribute 279 with a "holdconn" value. 281 If the offerer assigns the SDP "setup" attribute with a value of 282 "actpass" or "passive", the offerer MUST be prepared to receive a 283 DTLS ClientHello message before it receives the SDP answer. 285 4.3. Generating the Answer 287 If the answerer accepts the offered UDPTL over DTLS transport 288 connection, in the associated SDP answer the answerer MUST assign an 289 SDP "setup" attribute with a value of either "active" or "passive", 290 according to the procedures in [RFC4145]. The answerer MUST NOT 291 assign an SDP "setup" attribute with a value of "holdconn". 293 If the answerer assigns an SDP "setup" attribute with a value of 294 "active" value, the answerer MUST initiate a DTLS handshake by 295 sending a DTLS ClientHello message on the negotiated media stream, 296 towards the IP address and port of the offerer. 298 4.4. Offerer Processing of the Answer 300 When the offerer receives an SDP answer, if the offerer ends up being 301 active it MUST initiate a DTLS handshake by sending a DTLS 302 ClientHello message on the negotiated media stream, towards the IP 303 address and port of the answerer. 305 4.5. Modifying the Session 307 Once an offer/answer exchange has been completed, either endpoint MAY 308 send a new offer in order to modify the session. The endpoints can 309 reuse the existing DTLS association if the key fingerprint values and 310 transport parameters indicated by each endpoint are unchanged. 311 Otherwise, following the rules as for the initial offer/answer 312 exchange, the endpoints can negotiate and create a new DTLS 313 association and, once created, delete the previous DTLS association, 314 following the same rules for the initial offer/answer exchange. Each 315 endpoint needs to be prepared to receive data on both the new and old 316 DTLS associations, as long as both are alive. 318 5. Miscellaneous Considerations 320 5.1. Anonymous Calls 322 When making anonymous calls, a new self-signed certificate SHOULD be 323 used for each call and attributes inside the certificate MUST NOT 324 contain information that either allows correlation or identification 325 of the user making anonymous calls. This is particularly important 326 for the subjectAltName and commonName attributes. 328 5.2. NAT Traversal 330 5.2.1. ICE Usage 332 When ICE [RFC5245] is being used, the ICE connectivity checks are 333 performed before the DTLS handshake begins. Note that if aggressive 334 nomination mode is used, multiple candidate pairs may be marked valid 335 before ICE finally converges on a single candidate pair. UAs MUST 336 treat all ICE candidate pairs associated with a single component as 337 part of the same DTLS association. Thus, there will be only one DTLS 338 handshake even if there are multiple valid candidate pairs. Note 339 that this may mean adjusting the endpoint IP addresses if the 340 selected candidate pair shifts, just as if the DTLS packets were an 341 ordinary media stream. In case of an ICE restart, the DTLS handshake 342 procedure is repeated and a new DTLS association is created. Once 343 the DTLS handshake is completed ,and the new DTLS association has 344 been created, the previous DTLS association is deleted. 346 5.2.2. STUN Interaction 348 The UA MUST send the STUN packets [RFC5389] directly over UDP, not 349 over DTLS. 351 The UA MUST support the following mechanism for demultiplexing 352 packets arriving on the IP address and port associated with the DTLS 353 association: 355 o If the value of the first byte of the packet is 0 or 1, then the 356 packet is STUN. 357 o If the value of the first byte of the packet is between 20 and 63 358 (inclusive), the packet is DTLS. 360 5.3. Rekeying 362 During rekeying, packets protected by the previous set of keys can 363 arrive after the DTLS handshake caused by rekeying has completed, 364 because packets can be reordered on the wire. To compensate for this 365 fact, receivers MUST maintain both sets of keys for some time in 366 order to be able to decrypt and verify older packets. The duration 367 of maintaining the previous set of keys after the finish of the DTLS 368 handshake is out of scope for this document. 370 5.4. Compatibility With UDPTL over UDP 372 If a user requires fax to be transported securely using UDPTL over 373 DTLS, and if the remote user does not support UDPTL over DTLS, then a 374 fax media stream cannot be established. 376 If a user prefers fax to be transported securely using UDPTL over 377 DTLS, but is willing to transport the fax insecurely in case the 378 remote user does not support UDPTL over DTLS, then the SDP Capability 379 Negotiation mechanism [RFC5939] can be used to offer both UDPTL over 380 DTLS and UDPTL over UDP. Alternatively, if the remote user rejects 381 an SDP offer for UDPTL over DTLS, a new SDP offer for a UDPTL over 382 UDP media stream can be sent. 384 6. Security Considerations 386 Fax may be used to transmit a wide range of sensitive data, including 387 personal, corporate, and governmental information. It is therefore 388 critical to be able to protect against threats to the confidentiality 389 and integrity of the transmitted data. 391 The mechanism in this document provides integrity and confidentiality 392 protection for fax by specifying fax transport using UDPTL over DTLS 393 [RFC6347]. 395 DTLS media stream negotiated using SIP/SDP requires a mechanism to 396 ensure that the certificate received via DTLS was issued by the 397 remote party of the SIP session. 399 The standard DTLS strategy for authenticating the communicating 400 parties is to give the server (and optionally the client) a PKIX 401 [RFC5280] certificate. The client then verifies the certificate and 402 checks that the name in the certificate matches the server's domain 403 name. This works because there are a relatively small number of 404 servers and the cost for issuing and deploying PKIX certificates can 405 be justified. Issuing and deploying PKIX certificates to all clients 406 is not realistic in most deployment scenarios. 408 The design described in this document is intended to leverage the 409 integrity protection of the SIP signaling, while not requiring 410 confidentiality. As long as each side of the connection can verify 411 the integrity of the SDP received from the other side, then the DTLS 412 handshake cannot be hijacked via a man-in-the-middle attack. This 413 integrity protection is easily provided by the caller to the callee 414 via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as 415 the S/MIME mechanism [RFC3261], or perhaps future mechanisms yet to 416 be specified could also serve this purpose. 418 While this mechanism can still be used without such integrity 419 mechanisms, the security provided is limited to defense against 420 passive attack by intermediaries. An active attack on the signaling 421 plus an active attack on the media plane can allow an attacker to 422 attack the connection (R-SIG-MEDIA in the notation of [RFC5479]). 424 7. IANA Considerations 426 This document updates the "Session Description Protocol (SDP) 427 Parameters" registry as specified in Section 8.2.2 of [RFC4566]. 428 Specifically, it adds the values in Table 1 to the table for the SDP 429 "proto" field registry. 431 +-------+---------------+------------+ 432 | Type | SDP Name | Reference | 433 +-------+---------------+------------+ 434 | proto | UDP/TLS/UDPTL | [RFC-XXXX] | 435 +-------+---------------+------------+ 437 Table 1: SDP "proto" field values 439 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 440 document.] 442 8. Acknowledgments 444 Special thanks to Peter Dawes, who provided comments on the initial 445 version of the draft, and to Paul E. Jones, James Rafferty, Albrecht 446 Schwarz, Oscar Ohlsson, David Hanes, Adam Gensler, Ari Keranen, 447 Flemming Andreasen, John Mattsson and Marc Petit-Huguenin who 448 provided valuable feedback and input. Barry Leiba, Spencer Dawkins, 449 Pete Resnick, Kathleen Moriarty and Stephen Farrell provided valuable 450 feedback during the IESG review. Thanks to Scott Brim for performing 451 the Gen-ART review. Thanks to Alissa Cooper for her help as 452 sponsoring Area Director. 454 9. Change Log 456 [RFC EDITOR NOTE: Please remove this section when publishing] 458 Changes from draft-ietf-mmusic-udptl-dtls-09 460 o Removal of previous changes based on comments by Marc Petit- 461 Huguenin: 462 o - Future correction might be needed based on generic NAT traversal 463 work in IETF. 465 Changes from draft-ietf-mmusic-udptl-dtls-08 467 o Changes based on comments by Marc Petit-Huguenin: 468 o - Corrected text on how to distinguish STUN, TURN and DTLS 469 packets. 471 Changes from draft-ietf-mmusic-udptl-dtls-07 473 o Changes based on IESG comments by Barry Leiba: 474 o - SHALL replaced with MUST. 475 o - Text modifications in sections 4.2, 4.4, 5.2.2, 5.3 and 6. 476 o Changes based on IESG comments by Pete Resnick and Kathleen 477 Moriarty: 479 o - Additional text on existing mechanisms for securing fax in 480 section 1. 481 o Changes based on IESG comments by Stephen Farrell: 482 o - Added text regarding MTI cipher suites. 484 Changes from draft-ietf-mmusic-udptl-dtls-06 486 o Changes based on WGLC comments by Paul Kyzivat 487 o - Indicating that, when a new and an old DTLS association exist, 488 each endpoint needs to be prepared to receive data on both. 489 o - Editorial nit. 491 Changes from draft-ietf-mmusic-udptl-dtls-05 493 o Changes based on comments by Flemming Andreasen 494 o - SDP Offer/Answer sections structured according to RFC 3264. 495 o - Clarified that ICE considerations also apply to ICE restart. 496 o - Editorial changes. 498 Changes from draft-ietf-mmusic-udptl-dtls-04 500 o Changes based on comments by Flemming Andreasen 501 o - Addition of SDP Offer/Answer procedure section. 502 o - Removal of non-ICE NAT traversal procedures. 503 o - Addition of guidance regarding compatibility with UDPTL over 504 UDP. 505 o - Editorial corrections. 506 o Minor editorial corrections 507 o -Spelling of Ari's family name. 509 Changes from draft-ietf-mmusic-udptl-dtls-03 511 o Changes based on comments by Adam Gensler (http://www.ietf.org/ 512 mail-archive/web/mmusic/current/msg12945.html) 513 o -Indicating that, in case of rekeying, entities MUST maintain both 514 set of keys for some time (previously SHOULD). 515 o -Explicit mentioning of the commonName attribute in text about 516 correlation/identification of users. 517 o Changes based on comments by Ari Keranen (http://www.ietf.org/ 518 mail-archive/web/mmusic/current/msg12966.html) 519 o -Informative reference to RFC 5246 added. 520 o -Re-naming of sections 4.2.1 and 4.2.2. 521 o -Clarifying that documented STUN/DTLS demux mechanism is only one 522 way of doing the demux. 523 o -Editorial corrections. 525 Changes from draft-ietf-mmusic-udptl-dtls-02 526 o Editorial comments based on review comments by James Rafferty 527 (http://www.ietf.org/mail-archive/web/mmusic/current/ 528 msg12890.html) 529 o Editorial comments based on review comments by David Hanes 530 (http://www.ietf.org/mail-archive/web/mmusic/current/ 531 msg12886.html) 532 o Editorial comments based on review comments by Oscar Ohlsson 533 (http://www.ietf.org/mail-archive/web/mmusic/current/ 534 msg12882.html) 535 o Editorial comments based on review comments by Albrecht Schwartz 536 (http://www.ietf.org/mail-archive/web/mmusic/current/ 537 msg12900.html) 539 Changes from draft-ietf-mmusic-udptl-dtls-01 541 o Usage of the SDP fingerprint attribute depends on whether a cipher 542 suite with an associated certificate is used. 543 o Editor's note in section 4.2 removed. Procedure text added. 545 Changes from draft-ietf-mmusic-udptl-dtls-00 547 o SDP offerer is allowed to assign an a=setup:active or 548 a=setup:passive value, in addition to the recommended 549 a=setup:actpass (http://www.ietf.org/mail- 550 archive/web/mmusic/current/msg12331.html). 551 o The example for secure fax replacing audio stream in audio-only 552 session added (http://www.ietf.org/mail- 553 archive/web/mmusic/current/msg12428.html). 554 o Editor's note on the connection attribute resolved by prohibiting 555 usage of the SDP connection attribute (http://www.ietf.org/mail- 556 archive/web/mmusic/current/msg12772.html). 557 o Editorial corrections. 559 Changes from draft-holmberg-mmusic-udptl-dtls-02 561 o Milestone adopted - draft-ietf-mmusic version of the draft 562 submitted. 564 Changes from draft-holmberg-mmusic-udptl-dtls-01 566 o Gonzalo Salgueiro added as co-author. 567 o PSTN comparison text and Introduction text modified. 569 Changes from draft-holmberg-mmusic-udptl-dtls-00 571 o Text about T.30 added. 572 o Latest version of T.38 referenced. 573 o Additional text about the need for secure fax in IP networks. 575 Changes from draft-holmberg-dispatch-udptl-dtls-00 577 o WG changed to MMUSIC. 578 o Added text about 3GPP need for UDPTL/DTLS. 580 10. References 582 10.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 588 A., Peterson, J., Sparks, R., Handley, M., and E. 589 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 590 June 2002. 592 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 593 with Session Description Protocol (SDP)", RFC 3264, June 594 2002. 596 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 597 the Session Description Protocol (SDP)", RFC 4145, 598 September 2005. 600 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 601 Authenticated Identity Management in the Session 602 Initiation Protocol (SIP)", RFC 4474, August 2006. 604 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 605 Description Protocol", RFC 4566, July 2006. 607 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 608 Transport Layer Security (TLS) Protocol in the Session 609 Description Protocol (SDP)", RFC 4572, July 2006. 611 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 612 (ICE): A Protocol for Network Address Translator (NAT) 613 Traversal for Offer/Answer Protocols", RFC 5245, April 614 2010. 616 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 617 Housley, R., and W. Polk, "Internet X.509 Public Key 618 Infrastructure Certificate and Certificate Revocation List 619 (CRL) Profile", RFC 5280, May 2008. 621 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 622 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 623 October 2008. 625 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 626 Security Version 1.2", RFC 6347, January 2012. 628 [ITU.T30.2005] 629 International Telecommunications Union, "Procedures for 630 document facsimile transmission in the general switched 631 telephone network", ITU-T Recommendation T.30, September 632 2005. 634 [ITU.T38.2010] 635 International Telecommunications Union, "Procedures for 636 real-time Group 3 facsimile communication over IP 637 networks", ITU-T Recommendation T.38, September 2010. 639 10.2. Informative References 641 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 642 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 644 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 645 "Requirements and Analysis of Media Security Management 646 Protocols", RFC 5479, April 2009. 648 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 649 Capability Negotiation", RFC 5939, September 2010. 651 Appendix A. Examples 653 A.1. General 655 Prior to establishing the session, both Alice and Bob generate self- 656 signed certificates which are used for a single session or, more 657 likely, reused for multiple sessions. 659 The SIP signaling from Alice to her proxy is transported over TLS to 660 ensure an integrity protected channel between Alice and her identity 661 service. Alice's identity service asserts identity of Alice and 662 protects the SIP message, e.g. using SIP Identity. Transport between 663 proxies should also be protected, e.g. by use of TLS. 665 In order to simplify the flow, only one element is shown for Alice's 666 and Bob's proxies. 668 For the sake of brevity and simplicity, only the mandatory SDP T.38 669 attributes are shown. 671 A.2. Basic Message Flow 673 Figure 3 shows an example message flow of session establishment for 674 T.38 fax securely transported using UDPTL over DTLS. 676 In this example flow, Alice acts as the passive endpoint of the DTLS 677 association and Bob acts as the active endpoint of the DTLS 678 association. 680 Alice Proxies Bob 681 | (1) SIP INVITE | | 682 |----------------------->| | 683 | | (2) SIP INVITE | 684 | |----------------------->| 685 | | (3) DTLS ClientHello | 686 |<------------------------------------------------| 687 | (4) remaining messages of DTLS handshake | 688 |<----------------------------------------------->| 689 | | | 690 | | | 691 | | (5) SIP 200 OK | 692 | |<-----------------------| 693 | (6) SIP 200 OK | | 694 |<-----------------------| | 695 | (7) SIP ACK | | 696 |------------------------------------------------>| 697 | (8) T.38 message using UDPTL over DTLS | 698 |<----------------------------------------------->| 699 | | | 701 Figure 3: Basic message flow 703 Message (1): 705 Figure 4 shows the initial INVITE request sent by Alice to Alice's 706 proxy. The initial INVITE request contains an SDP offer. 708 The "m=" line in the SDP offer indicates T.38 fax using UDPTL over 709 DTLS. 711 The SDP "setup" attribute with a value of "actpass" in the SDP 712 offer indicates that Alice has requested to be either the active 713 or passive endpoint. 715 The SDP "fingerprint" attribute in the SDP offer contains the 716 certificate fingerprint computed from Alice's self-signed 717 certificate. 719 INVITE sip:bob@example.com SIP/2.0 720 To: 721 From: "Alice";tag=843c7b0b 722 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 723 Contact: 724 Call-ID: 6076913b1c39c212@REVMTEpG 725 CSeq: 1 INVITE 726 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 727 Max-Forwards: 70 728 Content-Type: application/sdp 729 Content-Length: xxxx 730 Supported: from-change 732 v=0 733 o=- 1181923068 1181923196 IN IP4 ua1.example.com 734 s=- 735 c=IN IP4 ua1.example.com 736 t=0 0 737 m=image 6056 UDP/TLS/UDPTL t38 738 a=setup:actpass 739 a=fingerprint: SHA-1 \ 740 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 741 a=T38FaxRateManagement:transferredTCF 743 Figure 4: Message (1) 745 Message (2): 747 Figure 5 shows the SIP INVITE request sent by Bob's proxy to Bob. 749 When received, Bob verifies the identity provided in the SIP 750 INVITE request. 752 INVITE sip:bob@ua2.example.com SIP/2.0 753 To: 754 From: "Alice";tag=843c7b0b 755 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk 756 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 757 Record-Route: 758 Contact: 759 Call-ID: 6076913b1c39c212@REVMTEpG 760 CSeq: 1 INVITE 761 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 762 Max-Forwards: 69 763 Content-Type: application/sdp 764 Content-Length: xxxx 765 Supported: from-change 767 v=0 768 o=- 1181923068 1181923196 IN IP4 ua1.example.com 769 s=- 770 c=IN IP4 ua1.example.com 771 t=0 0 772 m=image 6056 UDP/TLS/UDPTL t38 773 a=setup:actpass 774 a=fingerprint: SHA-1 \ 775 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 776 a=T38FaxRateManagement:transferredTCF 778 Figure 5: Message (2) 780 Message (3): 782 Assuming that Alice's identity is valid, Bob sends a DTLS 783 ClientHello directly to Alice. 785 Message (4): 787 Alice and Bob exchange further messages of DTLS handshake 788 (HelloVerifyRequest, ClientHello, ServerHello, Certificate, 789 ServerKeyExchange, CertificateRequest, ServerHelloDone, 790 Certificate, ClientKeyExchange, CertificateVerify, 791 ChangeCipherSpec, Finished). 793 When Bob receives the certificate of Alice via DTLS, Bob checks 794 whether the certificate fingerprint calculated from Alice's 795 certificate received via DTLS matches the certificate fingerprint 796 received in the a=fingerprint SDP attribute of Figure 5. In this 797 message flow, the check is successful and thus session setup 798 continues. 800 Note that, unlike in this example, it is not necessary to wait for 801 the DTLS handshake to finish before the SDP answer is sent. If 802 Bob has sent the SIP 200 (OK) response and later detects that the 803 certificate fingerprints do not match, he will terminate the 804 session. 806 Message (5): 808 Figure 6 shows a SIP 200 (OK) response to the initial SIP INVITE 809 request, sent by Bob to Bob's proxy. The SIP 200 (OK) response 810 contains an SDP answer. 812 The "m=" line in the SDP answer indicates T.38 fax using UDPTL 813 over DTLS. 815 The SDP "setup" attribute with a value of "active" in the SDP 816 answer indicates that Bob has requested to be the active endpoint. 818 The SDP "fingerprint" attribute in the SDP answer contains the 819 certificate fingerprint computed from Bob's self-signed 820 certificate. 822 SIP/2.0 200 OK 823 To: ;tag=6418913922105372816 824 From: "Alice" ;tag=843c7b0b 825 Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk 826 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 827 Record-Route: 828 Call-ID: 6076913b1c39c212@REVMTEpG 829 CSeq: 1 INVITE 830 Contact: 831 Content-Type: application/sdp 832 Content-Length: xxxx 833 Supported: from-change 835 v=0 836 o=- 8965454521 2105372818 IN IP4 ua2.example.com 837 s=- 838 c=IN IP4 ua2.example.com 839 t=0 0 840 m=image 12000 UDP/TLS/UDPTL t38 841 a=setup:active 842 a=fingerprint: SHA-1 \ 843 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 844 a=T38FaxRateManagement:transferredTCF 846 Figure 6: Message (5) 848 Message (6): 850 Figure 7 shows a SIP 200 (OK) response to the initial SIP INVITE 851 request, sent by Alice's proxy to Alice. Alice checks if the 852 certificate fingerprint calculated from the Bob's certificate 853 received via DTLS is the same as the certificate fingerprint 854 received in the a=fingerprint SDP attribute of Figure 7. In this 855 message flow, the check is successful and thus the session setup 856 continues. 858 SIP/2.0 200 OK 859 To: ;tag=6418913922105372816 860 From: "Alice" ;tag=843c7b0b 861 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 862 Record-Route: 863 Call-ID: 6076913b1c39c212@REVMTEpG 864 CSeq: 1 INVITE 865 Contact: 866 Content-Type: application/sdp 867 Content-Length: xxxx 868 Supported: from-change 870 v=0 871 o=- 8965454521 2105372818 IN IP4 ua2.example.com 872 s=- 873 c=IN IP4 ua2.example.com 874 t=0 0 875 m=image 12000 UDP/TLS/UDPTL t38 876 a=setup:active 877 a=fingerprint: SHA-1 \ 878 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 879 a=T38FaxRateManagement:transferredTCF 881 Figure 7: Message (6) 883 Message (7): 885 Alice sends the SIP ACK request to Bob. 887 Message (8): 889 At this point, Bob and Alice can exchange T.38 fax securely 890 transported using UDPTL over DTLS. 892 A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An 893 Existing Audio-Only Session 895 Traditionally, most sessions with non-secure transport of T.38 fax, 896 transported using UDPTL, are established by modifying an ongoing 897 audio session into a fax session. Figure 8 shows an example message 898 flow of modifying an existing audio session into a session with T.38 899 fax securely transported using UDPTL over DTLS. 901 In this example flow, Alice acts as the passive endpoint of the DTLS 902 association and Bob acts as the active endpoint of the DTLS 903 association. 905 Alice Proxies Bob 906 | | | 907 | (1) Audio-only session initiation | 908 |<-----------------------+----------------------->| 909 | | | 910 | (2) SIP re-INVITE | | 911 |------------------------------------------------>| 912 | | (3) DTLS ClientHello | 913 |<------------------------------------------------| 914 | (4) remaining messages of DTLS handshake | 915 |<----------------------------------------------->| 916 | | | 917 | | | 918 | | (5) SIP 200 OK | 919 |<------------------------------------------------| 920 | (6) SIP ACK | | 921 |------------------------------------------------>| 922 | (7) T.38 message using UDPTL over DTLS | 923 |<----------------------------------------------->| 924 | | | 926 Figure 8: Message Flow Of T.38 Fax Replacing Audio Media Stream in An 927 Existing Audio-Only Session 929 Message (1): 931 Session establishment of audio-only session. The proxies decide 932 not to record-route. 934 Message (2): 936 Alice sends SIP re-INVITE request. The SDP offer included in the 937 SIP re-INVITE request is shown in Figure 9. 939 The first "m=" line in the SDP offer indicates audio media stream 940 being removed. The second "m=" line in the SDP offer indicates 941 T.38 fax using UDPTL over DTLS being added. 943 The SDP "setup" attribute with a value of "actpass" in the SDP 944 offer indicates that Alice has requested to be either the active 945 or passive endpoint. 947 The SDP "fingerprint" attribute in the SDP offer contains the 948 certificate fingerprint computed from Alice's self-signed 949 certificate. 951 v=0 952 o=- 2465353433 3524244442 IN IP4 ua1.example.com 953 s=- 954 c=IN IP4 ua1.example.com 955 t=0 0 956 m=audio 0 UDP/TLS/RTP/SAVP 0 957 m=image 46056 UDP/TLS/UDPTL t38 958 a=setup:actpass 959 a=fingerprint: SHA-1 \ 960 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 961 a=T38FaxRateManagement:transferredTCF 963 Figure 9: SDP offer of message (2) 965 Message (3): 967 Bob sends a DTLS ClientHello directly to Alice. 969 Message (4): 971 Alice and Bob exchange further messages of DTLS handshake 972 (HelloVerifyRequest, ClientHello, ServerHello, Certificate, 973 ServerKeyExchange, CertificateRequest, ServerHelloDone, 974 Certificate, ClientKeyExchange, CertificateVerify, 975 ChangeCipherSpec, Finished). 977 When Bob receives the certificate of Alice via DTLS, Bob checks 978 whether the certificate fingerprint calculated from Alice's 979 certificate received via DTLS matches the certificate fingerprint 980 received in the SDP "fingerprint" attribute of Figure 9. In this 981 message flow, the check is successful and thus session setup 982 continues. 984 Message (5): 986 Bob sends a SIP 200 (OK) response to the SIP re-INVITE request. 987 The SIP 200 (OK) response contains an SDP answer shown in 988 Figure 10. 990 The first "m=" line in the SDP offer indicates audio media stream 991 being removed. The second "m=" line in the SDP answer indicates 992 T.38 fax using UDPTL over DTLS being added. 994 The SDP "setup" attribute with a value of "active" in the SDP 995 answer indicates that Bob has requested to be the active endpoint. 997 The SDP "fingerprint" attribute in the SDP answer contains the 998 certificate fingerprint computed from Bob's self-signed 999 certificate. 1001 v=0 1002 o=- 4423478999 5424222292 IN IP4 ua2.example.com 1003 s=- 1004 c=IN IP4 ua2.example.com 1005 t=0 0 1006 m=audio 0 UDP/TLS/RTP/SAVP 0 1007 m=image 32000 UDP/TLS/UDPTL t38 1008 a=setup:active 1009 a=fingerprint: SHA-1 \ 1010 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1011 a=T38FaxRateManagement:transferredTCF 1013 Figure 10: SDP answer of message (5) 1015 Message (6): 1017 Alice sends the SIP ACK request to Bob. 1019 Message (7): 1021 At this point, Bob and Alice can exchange T.38 fax securely 1022 transported using UDPTL over DTLS. 1024 Authors' Addresses 1026 Christer Holmberg 1027 Ericsson 1028 Hirsalantie 11 1029 Jorvas 02420 1030 Finland 1032 Email: christer.holmberg@ericsson.com 1034 Ivo Sedlacek 1035 Ericsson 1036 Sokolovska 79 1037 Praha 18600 1038 Czech Republic 1040 Email: ivo.sedlacek@ericsson.com 1042 Gonzalo Salgueiro 1043 Cisco Systems, Inc. 1044 7200-12 Kit Creek Road 1045 Research Triangle Park, NC 27709 1046 US 1048 Email: gsalguei@cisco.com