idnits 2.17.1 draft-ietf-mmusic-udptl-dtls-06.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 (March 25, 2014) is 3685 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 403, 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: September 26, 2014 G. Salgueiro 6 Cisco 7 March 25, 2014 9 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security 10 (DTLS) 11 draft-ietf-mmusic-udptl-dtls-06 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 September 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 9 75 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 80 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 13 82 A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in 83 An Existing Audio-Only Session . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 [ITU.T38.2010]. The protocol stack for fax transport using UDPTL is 100 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 Implementations exist today for securing this fax transport type. 115 Some of these mechanisms are: 117 o [ITU.T30.2005] Annex H specifies integrity and confidentiality 118 protection of fax in the application layer, independent of 119 protocol for fax transport. 120 o [ITU.T38.2010] specifies fax transport over RTP/SAVP which enables 121 integrity and confidentiality protection of fax in IP network. 123 Despite these mechanisms to secure fax, there is no transport layer 124 security offering integrity and confidentiality protection for UDPTL. 125 This issue was addressed in a study by the 3rd Generation Partnership 126 Project (3GPP) on how to provide secure fax in the IP Multimedia 127 Subsystem (IMS). They concluded that secure fax shall be transported 128 using UDPTL over DTLS. 130 This document specifies fax transport using UDPTL over DTLS 131 [RFC6347], which enables integrity and confidentiality protection of 132 fax in IP networks. The protocol stack which enhances fax transport 133 to offer integrity and confidentiality using UDPTL over DTLS is shown 134 in Figure 2. 136 +-----------------------------+ 137 | Internet facsimile protocol | 138 +-----------------------------+ 139 | UDPTL | 140 +-----------------------------+ 141 | DTLS | 142 +-----------------------------+ 143 | UDP | 144 +-----------------------------+ 145 | IP | 146 +-----------------------------+ 148 Figure 2: Protocol stack for UDPTL over DTLS over UDP 150 The primary motivations for the mechanism in this document are: 152 o The design of DTLS [RFC6347] is clearly defined, well understood 153 and implementations are widely available. 154 o No DTLS extensions are required in order to enable UDPTL transport 155 over DTLS. 156 o Fax transport using UDPTL over DTLS only requires insertion of the 157 DTLS layer between the UDPTL layer and the UDP layer, as shown in 158 Figure 2. The UDPTL layer and the layers above the UDPTL layer 159 require no modifications. 160 o UDPTL [ITU.T38.2010] is by far the most widely deployed fax 161 transport protocol in IP networks. 162 o 3GPP and the IP fax community need a mechanism to transport UDPTL 163 over DTLS in order to provide secure fax in SIP-based networks 164 (including IMS). 166 This document specifies the transport of UDPTL over DTLS using the 167 DTLS record layer "application_data" packets [RFC5246] [RFC6347]. 169 Since the DTLS record layer "application_data" packet does not 170 indicate whether it carries UDPTL, or some other protocol, the usage 171 of a dedicated DTLS association for transport of UDPTL needs to be 172 negotiated, e.g. using the Session Description Protocol (SDP) 173 [RFC4566] and the SDP offer/answer mechanism [RFC3264]. 175 Therefore, this document specifies a new value [RFC4566] for 176 the SDP media description ("m=" line) [RFC3264], in order to indicate 177 UDPTL over DTLS in SDP messages [RFC4566]. 179 2. Conventions 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in BCP 14, RFC 2119 184 [RFC2119]. 186 DTLS uses the term "session" to refer to a long-lived set of keying 187 material that spans DTLS associations. In this document, in order to 188 be consistent with SIP/SDP usage of "session" terminology, we use 189 "session" to refer to a multimedia session and use the term "DTLS 190 session" to refer to the DTLS construct. We use the term "DTLS 191 association" to refer to a particular DTLS cipher suite and keying 192 material set that is associated with a single host/port quartet. The 193 same DTLS session can be used to establish the keying material for 194 multiple DTLS associations. For consistency with other SIP/SDP 195 usage, we use the term "connection" when what's being referred to is 196 a multimedia stream that is not specifically DTLS. 198 3. Secure Channel 200 The UDPTL over DTLS media stream is negotiated using the SDP offer/ 201 answer mechanism [RFC3264]. See Section 4 for more details. 203 DTLS is used as specified in [RFC6347]. Once the DTLS handshake is 204 successfully completed (in order to prevent facsimile data from being 205 transmitted insecurely), the UDPTL packets SHALL be transported in 206 DTLS record layer "application_data" packets. 208 4. SDP Offerer/Answerer Procedures 210 4.1. General 212 An endpoint (i.e. both the offerer and the answerer) MUST create an 213 SDP media description ("m=" line) for each UDPTL over DTLS media 214 stream, and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 215 "proto" field of the "m=" line. 217 The procedures in this section apply to an "m=" line associated with 218 a UDPTL over DTLS media stream. 220 In order to negotiate a UDPTL over DTLS media stream, the following 221 SDP attributes are used: 223 o The SDP attributes defined for UDPTL over UDP, as described in 224 [ITU.T38.2010]; and 225 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 226 described in this section. 228 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 230 In order to negotiate the TLS roles for the UDPTL over DTLS transport 231 connection, the endpoint MUST use the SDP "setup" attribute 232 [RFC4145]. 234 If the endpoint supports, and is willing to use, a cipher suite with 235 an associated certificate, the endpoint MUST include an SDP 236 "fingerprint" attribute [RFC4572]. 238 If a cipher suite with an associated certificate is selected during 239 the DTLS handshake, the certificate received during the DTLS 240 handshake MUST match the fingerprint received in the SDP 241 "fingerprint" attribute. If the fingerprint does not match the 242 hashed certificate, then the endpoint MUST tear down the media 243 session immediately. Note that it is permissible to wait until the 244 other side's fingerprint has been received before establishing the 245 connection; however, this may have undesirable latency effects. 247 4.2. Generating the Initial Offer 249 The offerer SHOULD assign the SDP "setup" attribute with a value of 250 "actpass". Alternatively, the offerer MAY assign the SDP "setup" 251 attribute with a value of "active" or "passive". The offerer MUST 252 NOT assign an SDP "setup" attribute with a "holdconn" value. 254 If the offerer assigns the SDP "setup" attribute with a value of 255 "actpass" or "passive", the offerer MUST be prepared to receive a 256 DTLS ClientHello message before it receives the SDP answer. 258 4.3. Generating the Answer 260 If the answerer accepts the offered UDPTL over DTLS transport 261 connection, in the associated SDP answer the answerer MUST assign an 262 SDP "setup" attribute with a value of either "active" or "passive", 263 according to the procedures in [RFC4145]. The answerer MUST NOT 264 assign an SDP "setup" attribute with a value of "holdconn". 266 If the answerer assigns an SDP "setup" attribute with a value of 267 "active" value, the answerer MUST initiate a DTLS handshake by 268 sending a DTLS ClientHello message on the negotiated media stream, 269 towards the IP address and port of the offerer. 271 4.4. Offerer Processing of the Answer 273 When the offerer receives an SDP answer and, if the offerer ends up 274 being active it MUST initiate a DTLS handshake by sending a DTLS 275 ClientHello message on the negotiated media stream, towards the IP 276 address and port of the answerer. 278 4.5. Modifying the Session 280 Once an offer/answer exchange has been completed, either endpoint MAY 281 send a new offer in order to modify the session. The endpoints can 282 reuse the existing DTLS association if the key fingerprint values and 283 transport parameters indicated by each endpoint are unchanged are 284 unchanged. Otherwise, following the rules as for the initial offer/ 285 answer exchange, the endpoints can negotiate and create a new DTLS 286 association and, once created, delete the previous DTLS association, 287 following the same rules of for the initial offer/answer exchange. 289 5. Miscellaneous Considerations 291 5.1. Anonymous Calls 293 When making anonymous calls, a new self-signed certificate SHOULD be 294 used for each call and attributes inside the certificate SHALL NOT 295 contain information that either allows correlation or identification 296 of the user making anonymous calls. This is particularly important 297 for the subjectAltName and commonName attributes. 299 5.2. NAT Traversal 301 5.2.1. ICE Usage 303 When ICE [RFC5245] is being used, the ICE connectivity checks are 304 performed before the DTLS handshake begins. Note that if aggressive 305 nomination mode is used, multiple candidate pairs may be marked valid 306 before ICE finally converges on a single candidate pair. UAs MUST 307 treat all ICE candidate pairs associated with a single component as 308 part of the same DTLS association. Thus, there will be only one DTLS 309 handshake even if there are multiple valid candidate pairs. Note 310 that this may mean adjusting the endpoint IP addresses if the 311 selected candidate pair shifts, just as if the DTLS packets were an 312 ordinary media stream. In case of an ICE restart, the DTLS handshake 313 procedure is repeated and a new DTLS association is created. Once 314 the DTLS handshake is completed ,and the new DTLS association has 315 been created, the previous DTLS association is deleted. 317 5.2.2. STUN Interaction 319 The UA SHALL send the STUN packets [RFC5389] directly over UDP, not 320 over DTLS. 322 The UA MUST demultiplex packets arriving on the IP address and port 323 associated with the DTLS association, e.g. as follows: 325 o If the value of the first byte of the packet is 0 or 1, then the 326 packet is STUN. 327 o If the value of the first byte of the packet is between 20 and 63 328 (inclusive), the packet is DTLS. 330 5.3. Rekeying 332 After the DTLS handshake caused by rekeying has completed, because of 333 possible packet reordering on the wire, packets protected by the 334 previous set of keys can arrive. To compensate for this fact, 335 receivers MUST maintain both sets of keys for some time in order to 336 be able to decrypt and verify older packets. The duration of 337 maintaining the previous set of keys after the finish of the DTLS 338 handshake is out of scope for this document. 340 5.4. Compatibility With UDPTL over UDP 342 If a user requires fax to be transported securely using UDPTL over 343 DTLS, and if the remote user does not support UDPTL over DTLS, then a 344 fax media stream cannot be established. 346 If a user prefers fax to be transported securely using UDPTL over 347 DTLS, but is willing to transport the fax insecurely in case the 348 remote user does not support UDPTL over DTLS, then the SDP Capability 349 Negotiation mechanism [RFC5939] can be used to offer both UDPTL over 350 DTLS and UDPTL over UDP. Alternatively, if the remote user rejects 351 an SDP offer for UDPTL over DTLS, a new SDP offer for a UDPTL over 352 UDP media stream can be sent. 354 6. Security Considerations 356 Fax may be used to transmit a wide range of sensitive data, including 357 personal, corporate, and governmental information. It is therefore 358 critical to be able to protect against threats to the confidentiality 359 and integrity of the transmitted data. 361 The mechanism in this document provides integrity and confidentiality 362 protection for fax by specifying fax transport using UDPTL over DTLS 363 [RFC6347]. 365 DTLS media stream negotiated using SIP/SDP requires a mechanism to 366 ensure that the certificate received via DTLS was issued by the 367 remote party of the SIP session. 369 The standard DTLS strategy for authenticating the communicating 370 parties is to give the server (and optionally the client) a PKIX 371 [RFC5280] certificate. The client then verifies the certificate and 372 checks that the name in the certificate matches the server's domain 373 name. This works because there are a relatively small number of 374 servers with well-defined names; a situation that does not usually 375 occur in the VoIP context. 377 The design described in this document is intended to leverage the 378 integrity protection of the SIP signaling, while not requiring 379 confidentiality. As long as each side of the connection can verify 380 the integrity of the SDP received from the other side, then the DTLS 381 handshake cannot be hijacked via a man-in-the-middle attack. This 382 integrity protection is easily provided by the caller to the callee 383 via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as 384 the S/MIME mechanism [RFC3261], or perhaps future mechanisms yet to 385 be specified could also serve this purpose. 387 While this mechanism can still be used without such integrity 388 mechanisms, the security provided is limited to defense against 389 passive attack by intermediaries. An active attack on the signaling 390 plus an active attack on the media plane can allow an attacker to 391 attack the connection (R-SIG-MEDIA in the notation of [RFC5479]). 393 7. IANA Considerations 395 This document updates the "Session Description Protocol (SDP) 396 Parameters" registry as specified in Section 8.2.2 of [RFC4566]. 397 Specifically, it adds the values in Table 1 to the table for the SDP 398 "proto" field registry. 400 +-------+---------------+------------+ 401 | Type | SDP Name | Reference | 402 +-------+---------------+------------+ 403 | proto | UDP/TLS/UDPTL | [RFC-XXXX] | 404 +-------+---------------+------------+ 406 Table 1: SDP "proto" field values 408 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 409 document.] 411 8. Acknowledgments 413 Special thanks to Peter Dawes, who provided comments on the initial 414 version of the draft, and to Paul E. Jones, James Rafferty, Albrecht 415 Schwarz, Oscar Ohlsson, David Hanes, Adam Gensler, Ari Keranen and 416 Flemming Andreasen who provided valuable feedback and input on the 417 MMUSIC mailing list. 419 9. Change Log 421 [RFC EDITOR NOTE: Please remove this section when publishing] 423 Changes from draft-ietf-mmusic-udptl-dtls-05 425 o Changes based on comments by Flemming Andreasen 426 o - SDP Offer/Answer sections structured according to RFC 3264. 427 o - Clarified that ICE considerations also apply to ICE restart. 428 o - Editorial changes. 430 Changes from draft-ietf-mmusic-udptl-dtls-04 432 o Changes based on comments by Flemming Andreasen 433 o - Addition of SDP Offer/Answer procedure section. 434 o - Removal of non-ICE NAT traversal procedures. 435 o - Addition of guidance regarding compatibility with UDPTL over 436 UDP. 437 o - Editorial corrections. 438 o Minor editorial corrections 439 o -Spelling of Ari's family name. 441 Changes from draft-ietf-mmusic-udptl-dtls-03 443 o Changes based on comments by Adam Gensler (http://www.ietf.org/ 444 mail-archive/web/mmusic/current/msg12945.html) 445 o -Indicating that, in case of rekeying, entities MUST maintain both 446 set of keys for some time (previously SHOULD). 447 o -Explicit mentioning of the commonName attribute in text about 448 correlation/identification of users. 449 o Changes based on comments by Ari Keranen (http://www.ietf.org/ 450 mail-archive/web/mmusic/current/msg12966.html) 451 o -Informative reference to RFC 5246 added. 452 o -Re-naming of sections 4.2.1 and 4.2.2. 453 o -Clarifying that documented STUN/DTLS demux mechanism is only one 454 way of doing the demux. 455 o -Editorial corrections. 457 Changes from draft-ietf-mmusic-udptl-dtls-02 459 o Editorial comments based on review comments by James Rafferty 460 (http://www.ietf.org/mail-archive/web/mmusic/current/ 461 msg12890.html) 462 o Editorial comments based on review comments by David Hanes (http:/ 463 /www.ietf.org/mail-archive/web/mmusic/current/msg12886.html) 464 o Editorial comments based on review comments by Oscar Ohlsson 465 (http://www.ietf.org/mail-archive/web/mmusic/current/ 466 msg12882.html) 468 o Editorial comments based on review comments by Albrecht Schwartz 469 (http://www.ietf.org/mail-archive/web/mmusic/current/ 470 msg12900.html) 472 Changes from draft-ietf-mmusic-udptl-dtls-01 474 o Usage of the SDP fingerprint attribute depends on whether a cipher 475 suite with an associated certificate is used. 476 o Editor's note in section 4.2 removed. Procedure text added. 478 Changes from draft-ietf-mmusic-udptl-dtls-00 480 o SDP offerer is allowed to assign an a=setup:active or 481 a=setup:passive value, in addition to the recommended 482 a=setup:actpass (http://www.ietf.org/mail-archive/web/mmusic/ 483 current/msg12331.html). 484 o The example for secure fax replacing audio stream in audio-only 485 session added (http://www.ietf.org/mail-archive/web/mmusic/current 486 /msg12428.html). 487 o Editor's note on the connection attribute resolved by prohibiting 488 usage of the SDP connection attribute (http://www.ietf.org/mail- 489 archive/web/mmusic/current/msg12772.html). 490 o Editorial corrections. 492 Changes from draft-holmberg-mmusic-udptl-dtls-02 494 o Milestone adopted - draft-ietf-mmusic version of the draft 495 submitted. 497 Changes from draft-holmberg-mmusic-udptl-dtls-01 499 o Gonzalo Salgueiro added as co-author. 500 o PSTN comparison text and Introduction text modified. 502 Changes from draft-holmberg-mmusic-udptl-dtls-00 504 o Text about T.30 added. 505 o Latest version of T.38 referenced. 506 o Additional text about the need for secure fax in IP networks. 508 Changes from draft-holmberg-dispatch-udptl-dtls-00 510 o WG changed to MMUSIC. 511 o Added text about 3GPP need for UDPTL/DTLS. 513 10. References 515 10.1. Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 521 A., Peterson, J., Sparks, R., Handley, M., and E. 522 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 523 June 2002. 525 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 526 with Session Description Protocol (SDP)", RFC 3264, June 527 2002. 529 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 530 the Session Description Protocol (SDP)", RFC 4145, 531 September 2005. 533 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 534 Authenticated Identity Management in the Session 535 Initiation Protocol (SIP)", RFC 4474, August 2006. 537 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 538 Description Protocol", RFC 4566, July 2006. 540 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 541 Transport Layer Security (TLS) Protocol in the Session 542 Description Protocol (SDP)", RFC 4572, July 2006. 544 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 545 (ICE): A Protocol for Network Address Translator (NAT) 546 Traversal for Offer/Answer Protocols", RFC 5245, April 547 2010. 549 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 550 Housley, R., and W. Polk, "Internet X.509 Public Key 551 Infrastructure Certificate and Certificate Revocation List 552 (CRL) Profile", RFC 5280, May 2008. 554 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 555 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 556 October 2008. 558 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 559 Security Version 1.2", RFC 6347, January 2012. 561 [ITU.T30.2005] 562 International Telecommunications Union, "Procedures for 563 document facsimile transmission in the general switched 564 telephone network", ITU-T Recommendation T.30, September 565 2005. 567 [ITU.T38.2010] 568 International Telecommunications Union, "Procedures for 569 real-time Group 3 facsimile communication over IP 570 networks", ITU-T Recommendation T.38, September 2010. 572 10.2. Informative References 574 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 575 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 577 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 578 "Requirements and Analysis of Media Security Management 579 Protocols", RFC 5479, April 2009. 581 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 582 Capability Negotiation", RFC 5939, September 2010. 584 Appendix A. Examples 586 A.1. General 588 Prior to establishing the session, both Alice and Bob generate self- 589 signed certificates which are used for a single session or, more 590 likely, reused for multiple sessions. 592 The SIP signaling from Alice to her proxy is transported over TLS to 593 ensure an integrity protected channel between Alice and her identity 594 service. Alice's identity service asserts identity of Alice and 595 protects the SIP message, e.g. using SIP Identity. Transport between 596 proxies should also be protected, e.g. by use of TLS. 598 In order to simplify the flow, only one element is shown for Alice's 599 and Bob's proxies. 601 For the sake of brevity and simplicity, only the mandatory SDP T.38 602 attributes are shown. 604 A.2. Basic Message Flow 606 Figure 3 shows an example message flow of session establishment for 607 T.38 fax securely transported using UDPTL over DTLS. 609 In this example flow, Alice acts as the passive endpoint of the DTLS 610 association and Bob acts as the active endpoint of the DTLS 611 association. 613 Alice Proxies Bob 614 | (1) SIP INVITE | | 615 |----------------------->| | 616 | | (2) SIP INVITE | 617 | |----------------------->| 618 | | (3) DTLS ClientHello | 619 |<------------------------------------------------| 620 | (4) remaining messages of DTLS handshake | 621 |<----------------------------------------------->| 622 | | | 623 | | | 624 | | (5) SIP 200 OK | 625 | |<-----------------------| 626 | (6) SIP 200 OK | | 627 |<-----------------------| | 628 | (7) SIP ACK | | 629 |------------------------------------------------>| 630 | (8) T.38 message using UDPTL over DTLS | 631 |<----------------------------------------------->| 632 | | | 634 Figure 3: Basic message flow 636 Message (1): 638 Figure 4 shows the initial INVITE request sent by Alice to Alice's 639 proxy. The initial INVITE request contains an SDP offer. 641 The "m=" line in the SDP offer indicates T.38 fax using UDPTL over 642 DTLS. 644 The SDP "setup" attribute with a value of "actpass" in the SDP 645 offer indicates that Alice has requested to be either the active 646 or passive endpoint. 648 The SDP "fingerprint" attribute in the SDP offer contains the 649 certificate fingerprint computed from Alice's self-signed 650 certificate. 652 INVITE sip:bob@example.com SIP/2.0 653 To: 654 From: "Alice";tag=843c7b0b 655 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 656 Contact: 657 Call-ID: 6076913b1c39c212@REVMTEpG 658 CSeq: 1 INVITE 659 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 660 Max-Forwards: 70 661 Content-Type: application/sdp 662 Content-Length: xxxx 663 Supported: from-change 665 v=0 666 o=- 1181923068 1181923196 IN IP4 ua1.example.com 667 s=- 668 c=IN IP4 ua1.example.com 669 t=0 0 670 m=image 6056 UDP/TLS/UDPTL t38 671 a=setup:actpass 672 a=fingerprint: SHA-1 \ 673 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 674 a=T38FaxRateManagement:transferredTCF 676 Figure 4: Message (1) 678 Message (2): 680 Figure 5 shows the SIP INVITE request sent by Bob's proxy to Bob. 682 When received, Bob verifies the identity provided in the SIP 683 INVITE request. 685 INVITE sip:bob@ua2.example.com SIP/2.0 686 To: 687 From: "Alice";tag=843c7b0b 688 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk 689 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 690 Record-Route: 691 Contact: 692 Call-ID: 6076913b1c39c212@REVMTEpG 693 CSeq: 1 INVITE 694 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 695 Max-Forwards: 69 696 Content-Type: application/sdp 697 Content-Length: xxxx 698 Supported: from-change 700 v=0 701 o=- 1181923068 1181923196 IN IP4 ua1.example.com 702 s=- 703 c=IN IP4 ua1.example.com 704 t=0 0 705 m=image 6056 UDP/TLS/UDPTL t38 706 a=setup:actpass 707 a=fingerprint: SHA-1 \ 708 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 709 a=T38FaxRateManagement:transferredTCF 711 Figure 5: Message (2) 713 Message (3): 715 Assuming that Alice's identity is valid, Bob sends a DTLS 716 ClientHello directly to Alice. 718 Message (4): 720 Alice and Bob exchange further messages of DTLS handshake 721 (HelloVerifyRequest, ClientHello, ServerHello, Certificate, 722 ServerKeyExchange, CertificateRequest, ServerHelloDone, 723 Certificate, ClientKeyExchange, CertificateVerify, 724 ChangeCipherSpec, Finished). 726 When Bob receives the certificate of Alice via DTLS, Bob checks 727 whether the certificate fingerprint calculated from Alice's 728 certificate received via DTLS matches the certificate fingerprint 729 received in the a=fingerprint SDP attribute of Figure 5. In this 730 message flow, the check is successful and thus session setup 731 continues. 733 Note that, unlike in this example, it is not necessary to wait for 734 the DTLS handshake to finish before the SDP answer is sent. If 735 Bob has sent the SIP 200 (OK) response and later detects that the 736 certificate fingerprints do not match, he will terminate the 737 session. 739 Message (5): 741 Figure 6 shows a SIP 200 (OK) response to the initial SIP INVITE 742 request, sent by Bob to Bob's proxy. The SIP 200 (OK) response 743 contains an SDP answer. 745 The "m=" line in the SDP answer indicates T.38 fax using UDPTL 746 over DTLS. 748 The SDP "setup" attribute with a value of "active" in the SDP 749 answer indicates that Bob has requested to be the active endpoint. 751 The SDP "fingerprint" attribute in the SDP answer contains the 752 certificate fingerprint computed from Bob's self-signed 753 certificate. 755 SIP/2.0 200 OK 756 To: ;tag=6418913922105372816 757 From: "Alice" ;tag=843c7b0b 758 Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk 759 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 760 Record-Route: 761 Call-ID: 6076913b1c39c212@REVMTEpG 762 CSeq: 1 INVITE 763 Contact: 764 Content-Type: application/sdp 765 Content-Length: xxxx 766 Supported: from-change 768 v=0 769 o=- 8965454521 2105372818 IN IP4 ua2.example.com 770 s=- 771 c=IN IP4 ua2.example.com 772 t=0 0 773 m=image 12000 UDP/TLS/UDPTL t38 774 a=setup:active 775 a=fingerprint: SHA-1 \ 776 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 777 a=T38FaxRateManagement:transferredTCF 779 Figure 6: Message (5) 781 Message (6): 783 Figure 7 shows a SIP 200 (OK) response to the initial SIP INVITE 784 request, sent by Alice's proxy to Alice. Alice checks if the 785 certificate fingerprint calculated from the Bob's certificate 786 received via DTLS is the same as the certificate fingerprint 787 received in the a=fingerprint SDP attribute of Figure 7. In this 788 message flow, the check is successful and thus the session setup 789 continues. 791 SIP/2.0 200 OK 792 To: ;tag=6418913922105372816 793 From: "Alice" ;tag=843c7b0b 794 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 795 Record-Route: 796 Call-ID: 6076913b1c39c212@REVMTEpG 797 CSeq: 1 INVITE 798 Contact: 799 Content-Type: application/sdp 800 Content-Length: xxxx 801 Supported: from-change 803 v=0 804 o=- 8965454521 2105372818 IN IP4 ua2.example.com 805 s=- 806 c=IN IP4 ua2.example.com 807 t=0 0 808 m=image 12000 UDP/TLS/UDPTL t38 809 a=setup:active 810 a=fingerprint: SHA-1 \ 811 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 812 a=T38FaxRateManagement:transferredTCF 814 Figure 7: Message (6) 816 Message (7): 818 Alice sends the SIP ACK request to Bob. 820 Message (8): 822 At this point, Bob and Alice can exchange T.38 fax securely 823 transported using UDPTL over DTLS. 825 A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An 826 Existing Audio-Only Session 828 Traditionally, most sessions with non-secure transport of T.38 fax, 829 transported using UDPTL, are established by modifying an ongoing 830 audio session into a fax session. Figure 8 shows an example message 831 flow of modifying an existing audio session into a session with T.38 832 fax securely transported using UDPTL over DTLS. 834 In this example flow, Alice acts as the passive endpoint of the DTLS 835 association and Bob acts as the active endpoint of the DTLS 836 association. 838 Alice Proxies Bob 839 | | | 840 | (1) Audio-only session initiation | 841 |<-----------------------+----------------------->| 842 | | | 843 | (2) SIP re-INVITE | | 844 |------------------------------------------------>| 845 | | (3) DTLS ClientHello | 846 |<------------------------------------------------| 847 | (4) remaining messages of DTLS handshake | 848 |<----------------------------------------------->| 849 | | | 850 | | | 851 | | (5) SIP 200 OK | 852 |<------------------------------------------------| 853 | (6) SIP ACK | | 854 |------------------------------------------------>| 855 | (7) T.38 message using UDPTL over DTLS | 856 |<----------------------------------------------->| 857 | | | 859 Figure 8: Message Flow Of T.38 Fax Replacing Audio Media Stream in An 860 Existing Audio-Only Session 862 Message (1): 864 Session establishment of audio-only session. The proxies decide 865 not to record-route. 867 Message (2): 869 Alice sends SIP re-INVITE request. The SDP offer included in the 870 SIP re-INVITE request is shown in Figure 9. 872 The first "m=" line in the SDP offer indicates audio media stream 873 being removed. The second "m=" line in the SDP offer indicates 874 T.38 fax using UDPTL over DTLS being added. 876 The SDP "setup" attribute with a value of "actpass" in the SDP 877 offer indicates that Alice has requested to be either the active 878 or passive endpoint. 880 The SDP "fingerprint" attribute in the SDP offer contains the 881 certificate fingerprint computed from Alice's self-signed 882 certificate. 884 v=0 885 o=- 2465353433 3524244442 IN IP4 ua1.example.com 886 s=- 887 c=IN IP4 ua1.example.com 888 t=0 0 889 m=audio 0 UDP/TLS/RTP/SAVP 0 890 m=image 46056 UDP/TLS/UDPTL t38 891 a=setup:actpass 892 a=fingerprint: SHA-1 \ 893 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 894 a=T38FaxRateManagement:transferredTCF 896 Figure 9: SDP offer of message (2) 898 Message (3): 900 Bob sends a DTLS ClientHello directly to Alice. 902 Message (4): 904 Alice and Bob exchange further messages of DTLS handshake 905 (HelloVerifyRequest, ClientHello, ServerHello, Certificate, 906 ServerKeyExchange, CertificateRequest, ServerHelloDone, 907 Certificate, ClientKeyExchange, CertificateVerify, 908 ChangeCipherSpec, Finished). 910 When Bob receives the certificate of Alice via DTLS, Bob checks 911 whether the certificate fingerprint calculated from Alice's 912 certificate received via DTLS matches the certificate fingerprint 913 received in the SDP "fingerprint" attribute of Figure 9. In this 914 message flow, the check is successful and thus session setup 915 continues. 917 Message (5): 919 Bob sends a SIP 200 (OK) response to the SIP re-INVITE request. 920 The SIP 200 (OK) response contains an SDP answer shown in 921 Figure 10. 923 The first "m=" line in the SDP offer indicates audio media stream 924 being removed. The second "m=" line in the SDP answer indicates 925 T.38 fax using UDPTL over DTLS being added. 927 The SDP "setup" attribute with a value of "active" in the SDP 928 answer indicates that Bob has requested to be the active endpoint. 930 The SDP "fingerprint" attribute in the SDP answer contains the 931 certificate fingerprint computed from Bob's self-signed 932 certificate. 934 v=0 935 o=- 4423478999 5424222292 IN IP4 ua2.example.com 936 s=- 937 c=IN IP4 ua2.example.com 938 t=0 0 939 m=audio 0 UDP/TLS/RTP/SAVP 0 940 m=image 32000 UDP/TLS/UDPTL t38 941 a=setup:active 942 a=fingerprint: SHA-1 \ 943 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 944 a=T38FaxRateManagement:transferredTCF 946 Figure 10: SDP answer of message (5) 948 Message (6): 950 Alice sends the SIP ACK request to Bob. 952 Message (7): 954 At this point, Bob and Alice can exchange T.38 fax securely 955 transported using UDPTL over DTLS. 957 Authors' Addresses 959 Christer Holmberg 960 Ericsson 961 Hirsalantie 11 962 Jorvas 02420 963 Finland 965 Email: christer.holmberg@ericsson.com 967 Ivo Sedlacek 968 Ericsson 969 Sokolovska 79 970 Praha 18600 971 Czech Republic 973 Email: ivo.sedlacek@ericsson.com 975 Gonzalo Salgueiro 976 Cisco Systems, Inc. 977 7200-12 Kit Creek Road 978 Research Triangle Park, NC 27709 979 US 981 Email: gsalguei@cisco.com