summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7345.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7345.txt')
-rw-r--r--doc/rfc/rfc7345.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7345.txt b/doc/rfc/rfc7345.txt
new file mode 100644
index 0000000..c19437b
--- /dev/null
+++ b/doc/rfc/rfc7345.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Holmberg
+Request for Comments: 7345 I. Sedlacek
+Category: Standards Track Ericsson
+ISSN: 2070-1721 G. Salgueiro
+ Cisco
+ August 2014
+
+
+ UDP Transport Layer (UDPTL)
+ over Datagram Transport Layer Security (DTLS)
+
+Abstract
+
+ This document specifies how the UDP Transport Layer (UDPTL) protocol,
+ the predominant transport protocol for T.38 fax, can be transported
+ over the Datagram Transport Layer Security (DTLS) protocol, how the
+ usage of UDPTL over DTLS is indicated in the Session Description
+ Protocol (SDP), and how UDPTL over DTLS is negotiated in a session
+ established using the Session Initiation Protocol (SIP).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7345.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+Holmberg, et al. Standards Track [Page 1]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions .....................................................5
+ 3. Secure Channel ..................................................5
+ 4. SDP Offerer/Answerer Procedures .................................6
+ 4.1. General ....................................................6
+ 4.2. Generating the Initial Offer ...............................7
+ 4.3. Generating the Answer ......................................7
+ 4.4. Offerer Processing of the Answer ...........................7
+ 4.5. Modifying the Session ......................................7
+ 5. Miscellaneous Considerations ....................................8
+ 5.1. Anonymous Calls ............................................8
+ 5.2. NAT Traversal ..............................................8
+ 5.2.1. ICE Usage ...........................................8
+ 5.2.2. STUN Interaction ....................................8
+ 5.3. Rekeying ...................................................9
+ 5.4. Compatibility with UDPTL over UDP ..........................9
+ 6. Security Considerations .........................................9
+ 7. IANA Considerations ............................................10
+ 8. Acknowledgments ................................................10
+ 9. References .....................................................11
+ 9.1. Normative References ......................................11
+ 9.2. Informative References ....................................12
+ Appendix A. Examples .............................................13
+ A.1. General ...................................................13
+ A.2. Basic Message Flow ........................................13
+ A.3. Message Flow of T.38 Fax Replacing Audio Media Stream in
+ an Existing Audio-Only Session ............................20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 2]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+1. Introduction
+
+ While it is possible to transmit highly sensitive documents using
+ traditional telephony encryption devices, secure fax on the Public
+ Switched Telephone Network (PSTN) was never widely considered or
+ prioritized. This was mainly because of the challenges involved with
+ malevolent physical access to telephony equipment. As real-time
+ communications transition to IP networks, where information might
+ potentially be intercepted or spoofed, an appropriate level of
+ security for fax that offers integrity and confidentiality protection
+ is vital.
+
+ The overwhelmingly predominant fax transport protocol is UDPTL-based,
+ as described in Section 9.1 of [ITU.T38.2010]. The protocol stack
+ for fax transport using UDPTL is shown in Figure 1.
+
+ +-----------------------------+
+ | Internet facsimile protocol |
+ +-----------------------------+
+ | UDPTL |
+ +-----------------------------+
+ | UDP |
+ +-----------------------------+
+ | IP |
+ +-----------------------------+
+
+ Figure 1: Protocol Stack for UDPTL over UDP
+
+ The following mechanisms are available for securing fax:
+
+ o Annex H of [ITU.T30.2005] specifies an application-layer integrity
+ and confidentiality protection of fax that is independent of the
+ transport protocol and is based on the RSA algorithm for use with
+ the T.30 telephony protocol by Group 3 facsimile equipment (G3FE).
+
+ o [ITU.T38.2010] specifies fax transport over RTP/SAVP, which
+ enables integrity and confidentiality protection of fax in IP
+ networks.
+
+ Both of these mechanisms have been available for many years and never
+ gained any significant adoption in the market. This has prompted an
+ effort to develop an approach, based on open standards, for securing
+ fax communications over an IP-based transport.
+
+ Telephony-based protocols like T.30 offer application-level security
+ options like the RSA-based approach detailed in Annex H of the T.30
+ specification [ITU.T30.2005]. The problem is that it is very
+ sparingly implemented and not enforced at the transport level.
+
+
+
+Holmberg, et al. Standards Track [Page 3]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ It is worth noting that while T.38 over RTP offers a very viable
+ option for such standards-based IP security solution using Secure
+ Realtime Transport Protocol (SRTP), this fax-over-IP transport never
+ gained any traction in the marketplace and accounts for a negligible
+ percentage of fax-over-IP implementations.
+
+ Thus, security mechanisms offering integrity and confidentiality
+ protection should be limited to UDPTL-based fax transport, which is
+ the only broad-based fax-over-IP solution. The 3rd Generation
+ Partnership Project (3GPP) launched a study on how best to provide
+ secure fax in the IP Multimedia Subsystem (IMS) for UDPTL. Results
+ of the study confirmed that this security was best achieved by using
+ UDPTL over DTLS.
+
+ This document specifies fax transport using UDPTL over DTLS
+ [RFC6347], which enables integrity and confidentiality protection of
+ fax in IP networks. The protocol stack that enhances fax transport
+ to offer integrity and confidentiality using UDPTL over DTLS is shown
+ in Figure 2.
+
+ +-----------------------------+
+ | Internet facsimile protocol |
+ +-----------------------------+
+ | UDPTL |
+ +-----------------------------+
+ | DTLS |
+ +-----------------------------+
+ | UDP |
+ +-----------------------------+
+ | IP |
+ +-----------------------------+
+
+ Figure 2: Protocol Stack for UDPTL over DTLS over UDP
+
+ The primary motivations for the mechanism in this document are:
+
+ o The design of DTLS [RFC6347] is clearly defined and well
+ understood, and implementations are widely available.
+
+ o No DTLS extensions are required in order to enable UDPTL transport
+ over DTLS.
+
+ o Fax transport using UDPTL over DTLS only requires insertion of the
+ DTLS layer between the UDPTL layer and the UDP layer, as shown in
+ Figure 2. The UDPTL layer and the layers above the UDPTL layer
+ require no modifications.
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 4]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ o UDPTL [ITU.T38.2010] is by far the most widely deployed fax
+ transport protocol in IP networks.
+
+ o 3GPP and the IP fax community need a mechanism to transport UDPTL
+ over DTLS in order to provide secure fax in SIP-based networks
+ (including IMS).
+
+ This document specifies the transport of UDPTL over DTLS using the
+ DTLS record layer "application_data" packets [RFC5246] [RFC6347].
+
+ Since the DTLS record layer "application_data" packet does not
+ indicate whether it carries UDPTL or some other protocol, the usage
+ of a dedicated DTLS association for transport of UDPTL needs to be
+ negotiated, e.g., using the Session Description Protocol (SDP)
+ [RFC4566] and the SDP offer/answer mechanism [RFC3264].
+
+ Therefore, this document specifies a new <proto> value [RFC4566] for
+ the SDP media description ("m=" line) [RFC3264], in order to indicate
+ UDPTL over DTLS in SDP messages [RFC4566].
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+ DTLS uses the term "session" to refer to a long-lived set of keying
+ material that spans DTLS associations. In this document, in order to
+ be consistent with SIP/SDP usage of "session" terminology, we use
+ "session" to refer to a multimedia session and use the term "DTLS
+ session" to refer to the DTLS construct. We use the term "DTLS
+ association" to refer to a particular DTLS cipher suite and keying
+ material set that is associated with a single host/port quartet. The
+ same DTLS session can be used to establish the keying material for
+ multiple DTLS associations. For consistency with other SIP/SDP
+ usage, we use the term "connection" when what's being referred to is
+ a multimedia stream that is not specifically DTLS.
+
+3. Secure Channel
+
+ The UDPTL-over-DTLS media stream is negotiated using the SDP offer/
+ answer mechanism [RFC3264]. See Section 4 for more details.
+
+ DTLS is used as specified in [RFC6347]. Once the DTLS handshake is
+ successfully completed (in order to prevent facsimile data from being
+ transmitted insecurely), the UDPTL packets MUST be transported in
+ DTLS record layer "application_data" packets.
+
+
+
+Holmberg, et al. Standards Track [Page 5]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+4. SDP Offerer/Answerer Procedures
+
+4.1. General
+
+ An endpoint (i.e., both the offerer and the answerer) MUST create an
+ SDP media description ("m=" line) for each UDPTL-over-DTLS media
+ stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the
+ "proto" field of the "m=" line.
+
+ The procedures in this section apply to an "m=" line associated with
+ a UDPTL-over-DTLS media stream.
+
+ In order to negotiate a UDPTL-over-DTLS media stream, the following
+ SDP attributes are used:
+
+ o The SDP attributes defined for UDPTL over UDP, as described in
+ [ITU.T38.2010]; and
+
+ o The SDP attributes, defined in [RFC4145] and [RFC4572], as
+ described in this section.
+
+ The endpoint MUST NOT use the SDP "connection" attribute [RFC4145].
+
+ In order to negotiate the TLS roles for the UDPTL-over-DTLS transport
+ connection, the endpoint MUST use the SDP "setup" attribute
+ [RFC4145].
+
+ If the endpoint supports, and is willing to use, a cipher suite with
+ an associated certificate, the endpoint MUST include an SDP
+ "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256
+ for generating and verifying the SDP "fingerprint" attribute value.
+ The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST
+ support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support
+ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer
+ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward
+ Secrecy (PFS) cipher suites over non-PFS cipher suites.
+ Implementations SHOULD disable TLS-level compression.
+
+ If a cipher suite with an associated certificate is selected during
+ the DTLS handshake, the certificate received during the DTLS
+ handshake MUST match the fingerprint received in the SDP
+ "fingerprint" attribute. If the fingerprint does not match the
+ hashed certificate, then the endpoint MUST tear down the media
+ session immediately. Note that it is permissible to wait until the
+ other side's fingerprint has been received before establishing the
+ connection; however, this may have undesirable latency effects.
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 6]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+4.2. Generating the Initial Offer
+
+ The offerer SHOULD assign the SDP "setup" attribute with a value of
+ "actpass", unless the offerer insists on being either the sender or
+ receiver of the DTLS ClientHello message, in which case the offerer
+ can use either a value of "active" (the offerer will be the sender of
+ ClientHello) or "passive" (the offerer will be the receiver of
+ ClientHello). The offerer MUST NOT assign an SDP "setup" attribute
+ with a "holdconn" value.
+
+ If the offerer assigns the SDP "setup" attribute with a value of
+ "actpass" or "passive", the offerer MUST be prepared to receive a
+ DTLS ClientHello message before it receives the SDP answer.
+
+4.3. Generating the Answer
+
+ If the answerer accepts the offered UDPTL-over-DTLS transport
+ connection, in the associated SDP answer, the answerer MUST assign an
+ SDP "setup" attribute with a value of either "active" or "passive",
+ according to the procedures in [RFC4145]. The answerer MUST NOT
+ assign an SDP "setup" attribute with a value of "holdconn".
+
+ If the answerer assigns an SDP "setup" attribute with a value of
+ "active" value, the answerer MUST initiate a DTLS handshake by
+ sending a DTLS ClientHello message on the negotiated media stream,
+ towards the IP address and port of the offerer.
+
+4.4. Offerer Processing of the Answer
+
+ When the offerer receives an SDP answer, if the offerer ends up being
+ active it MUST initiate a DTLS handshake by sending a DTLS
+ ClientHello message on the negotiated media stream, towards the IP
+ address and port of the answerer.
+
+4.5. Modifying the Session
+
+ Once an offer/answer exchange has been completed, either endpoint MAY
+ send a new offer in order to modify the session. The endpoints can
+ reuse the existing DTLS association if the key fingerprint values and
+ transport parameters indicated by each endpoint are unchanged.
+ Otherwise, following the rules for the initial offer/answer exchange,
+ the endpoints can negotiate and create a new DTLS association and,
+ once created, delete the previous DTLS association, following the
+ same rules for the initial offer/answer exchange. Each endpoint
+ needs to be prepared to receive data on both the new and old DTLS
+ associations as long as both are alive.
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 7]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+5. Miscellaneous Considerations
+
+5.1. Anonymous Calls
+
+ When making anonymous calls, a new self-signed certificate SHOULD be
+ used for each call, and attributes inside the certificate MUST NOT
+ contain information that allows either correlation or identification
+ of the user making anonymous calls. This is particularly important
+ for the "subjectAltName" and "commonName" attributes.
+
+5.2. NAT Traversal
+
+5.2.1. ICE Usage
+
+ When Interactive Connectivity Establishment (ICE) [RFC5245] is being
+ used, the ICE connectivity checks are performed before the DTLS
+ handshake begins. Note that if aggressive nomination mode is used,
+ multiple candidate pairs may be marked valid before ICE finally
+ converges on a single candidate pair. User Agents (UAs) MUST treat
+ all ICE candidate pairs associated with a single component as part of
+ the same DTLS association. Thus, there will be only one DTLS
+ handshake even if there are multiple valid candidate pairs. Note
+ that this may mean adjusting the endpoint IP addresses if the
+ selected candidate pair shifts, just as if the DTLS packets were an
+ ordinary media stream. In the case of an ICE restart, the DTLS
+ handshake procedure is repeated, and a new DTLS association is
+ created. Once the DTLS handshake is completed and the new DTLS
+ association has been created, the previous DTLS association is
+ deleted.
+
+5.2.2. STUN Interaction
+
+ The UA MUST send the Session Traversal Utilities for NAT (STUN)
+ packets [RFC5389] directly over UDP, not over DTLS.
+
+ The UA MUST support the following mechanism for demultiplexing
+ packets arriving on the IP address and port associated with the DTLS
+ association:
+
+ o If the value of the first byte of the packet is 0 or 1, then the
+ packet is STUN.
+
+ o If the value of the first byte of the packet is between 20 and 63
+ (inclusive), the packet is DTLS.
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 8]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+5.3. Rekeying
+
+ During rekeying, packets protected by the previous set of keys can
+ arrive after the DTLS handshake caused by rekeying has completed,
+ because packets can be reordered on the wire. To compensate for this
+ fact, receivers MUST maintain both sets of keys for some time in
+ order to be able to decrypt and verify older packets. The duration
+ of maintaining the previous set of keys after the finish of the DTLS
+ handshake is out of the scope of this document.
+
+5.4. Compatibility with UDPTL over UDP
+
+ If a user requires fax to be transported securely using UDPTL over
+ DTLS, and if the remote user does not support UDPTL over DTLS, then a
+ fax media stream cannot be established.
+
+ If a user prefers fax to be transported securely using UDPTL over
+ DTLS but is willing to transport the fax insecurely in case the
+ remote user does not support UDPTL over DTLS, then the SDP Capability
+ Negotiation mechanism [RFC5939] can be used to offer both UDPTL over
+ DTLS and UDPTL over UDP. Alternatively, if the remote user rejects
+ an SDP offer for UDPTL over DTLS, a new SDP offer for a UDPTL-over-
+ UDP media stream can be sent.
+
+6. Security Considerations
+
+ Fax may be used to transmit a wide range of sensitive data, including
+ personal, corporate, and governmental information. It is therefore
+ critical to be able to protect against threats to the confidentiality
+ and integrity of the transmitted data.
+
+ The mechanism in this document provides integrity and confidentiality
+ protection for fax by specifying fax transport using UDPTL over DTLS
+ [RFC6347].
+
+ DTLS media stream negotiated using SIP/SDP requires a mechanism to
+ ensure that the certificate received via DTLS was issued by the
+ remote party of the SIP session.
+
+ The standard DTLS strategy for authenticating the communicating
+ parties is to give the server (and optionally the client) a PKIX
+ [RFC5280] certificate. The client then verifies the certificate and
+ checks that the name in the certificate matches the server's domain
+ name. This works because there are a relatively small number of
+ servers and the cost for issuing and deploying PKIX certificates can
+ be justified. Issuing and deploying PKIX certificates to all clients
+ is not realistic in most deployment scenarios.
+
+
+
+
+Holmberg, et al. Standards Track [Page 9]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ The design described in this document is intended to leverage the
+ integrity protection of the SIP signaling, while not requiring
+ confidentiality. As long as each side of the connection can verify
+ the integrity of the SDP received from the other side, then the DTLS
+ handshake cannot be hijacked via a man-in-the-middle attack. This
+ integrity protection is easily provided by the caller to the callee
+ via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as
+ the S/MIME mechanism [RFC3261] or perhaps future mechanisms yet to be
+ specified, could also serve this purpose.
+
+ While this mechanism can still be used without such integrity
+ mechanisms, the security provided is limited to defense against
+ passive attack by intermediaries. An active attack on the signaling
+ plus an active attack on the media plane can allow an attacker to
+ attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).
+
+7. IANA Considerations
+
+ This document updates the "Session Description Protocol (SDP)
+ Parameters" registry as specified in Section 8.2.2 of [RFC4566].
+ Specifically, the values in Table 1 have been added to the SDP
+ "proto" field registry.
+
+ +-------+---------------+-----------+
+ | Type | SDP Name | Reference |
+ +-------+---------------+-----------+
+ | proto | UDP/TLS/UDPTL | [RFC7345] |
+ +-------+---------------+-----------+
+
+ Table 1: SDP "proto" Field Values
+
+8. Acknowledgments
+
+ Special thanks to Peter Dawes, who provided comments on the initial
+ draft version of the document, and to Paul E. Jones, James Rafferty,
+ Albrecht Schwarz, Oscar Ohlsson, David Hanes, Adam Gensler, Ari
+ Keranen, Flemming Andreasen, John Mattsson, and Marc Petit-Huguenin,
+ who provided valuable feedback and input. Barry Leiba, Spencer
+ Dawkins, Pete Resnick, Kathleen Moriarty, and Stephen Farrell
+ provided valuable feedback during the IESG review. Thanks to Scott
+ Brim for performing the Gen-ART review. Thanks to Alissa Cooper for
+ her help as sponsoring Area Director.
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 10]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+9. References
+
+9.1. Normative References
+
+ [ITU.T30.2005]
+ International Telecommunications Union, "Procedures for
+ document facsimile transmission in the general switched
+ telephone network", ITU-T Recommendation T.30, September
+ 2005.
+
+ [ITU.T38.2010]
+ International Telecommunications Union, "Procedures for
+ real-time Group 3 facsimile communication over IP
+ networks", ITU-T Recommendation T.38, September 2010.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+ with Session Description Protocol (SDP)", RFC 3264, June
+ 2002.
+
+ [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
+ the Session Description Protocol (SDP)", RFC 4145,
+ September 2005.
+
+ [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
+ Authenticated Identity Management in the Session
+ Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
+ Transport Layer Security (TLS) Protocol in the Session
+ Description Protocol (SDP)", RFC 4572, July 2006.
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245, April
+ 2010.
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 11]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, May 2008.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ October 2008.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, January 2012.
+
+9.2. Informative References
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
+ "Requirements and Analysis of Media Security Management
+ Protocols", RFC 5479, April 2009.
+
+ [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
+ Capability Negotiation", RFC 5939, September 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 12]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+Appendix A. Examples
+
+A.1. General
+
+ Prior to establishing the session, both Alice and Bob generate self-
+ signed certificates that are used for a single session or, more
+ likely, reused for multiple sessions.
+
+ The SIP signaling from Alice to her proxy is transported over TLS to
+ ensure an integrity-protected channel between Alice and her identity
+ service. Alice's identity service asserts identity of Alice and
+ protects the SIP message, e.g., using SIP Identity. Transport
+ between proxies should also be protected, e.g., by use of TLS.
+
+ In order to simplify the flow, only one element is shown for Alice's
+ and Bob's proxies.
+
+ For the sake of brevity and simplicity, only the mandatory SDP T.38
+ attributes are shown.
+
+A.2. Basic Message Flow
+
+ Figure 3 shows an example message flow of session establishment for
+ T.38 fax securely transported using UDPTL over DTLS.
+
+ In this example flow, Alice acts as the passive endpoint of the DTLS
+ association, and Bob acts as the active endpoint of the DTLS
+ association.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 13]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ Alice Proxies Bob
+ | (1) SIP INVITE | |
+ |----------------------->| |
+ | | (2) SIP INVITE |
+ | |----------------------->|
+ | | (3) DTLS ClientHello |
+ |<------------------------------------------------|
+ | (4) remaining messages of DTLS handshake |
+ |<----------------------------------------------->|
+ | | |
+ | | |
+ | | (5) SIP 200 OK |
+ | |<-----------------------|
+ | (6) SIP 200 OK | |
+ |<-----------------------| |
+ | (7) SIP ACK | |
+ |------------------------------------------------>|
+ | (8) T.38 message using UDPTL over DTLS |
+ |<----------------------------------------------->|
+ | | |
+
+ Figure 3: Basic Message Flow
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 14]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ Message (1):
+
+ Figure 4 shows the initial INVITE request sent by Alice to Alice's
+ proxy. The initial INVITE request contains an SDP offer.
+
+ The "m=" line in the SDP offer indicates T.38 fax using UDPTL over
+ DTLS.
+
+ The SDP "setup" attribute with a value of "actpass" in the SDP
+ offer indicates that Alice has requested to be either the active
+ or passive endpoint.
+
+ The SDP "fingerprint" attribute in the SDP offer contains the
+ certificate fingerprint computed from Alice's self-signed
+ certificate.
+
+ INVITE sip:bob@example.com SIP/2.0
+ To: <sip:bob@example.com>
+ From: "Alice"<sip:alice@example.com>;tag=843c7b0b
+ Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
+ Contact: <sip:alice@ua1.example.com>
+ Call-ID: 6076913b1c39c212@REVMTEpG
+ CSeq: 1 INVITE
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+ Max-Forwards: 70
+ Content-Type: application/sdp
+ Content-Length: xxxx
+ Supported: from-change
+
+ v=0
+ o=- 1181923068 1181923196 IN IP4 ua1.example.com
+ s=-
+ c=IN IP4 ua1.example.com
+ t=0 0
+ m=image 6056 UDP/TLS/UDPTL t38
+ a=setup:actpass
+ a=fingerprint: SHA-1 \
+ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
+ a=T38FaxRateManagement:transferredTCF
+
+ Figure 4: Message (1)
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 15]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ Message (2):
+
+ Figure 5 shows the SIP INVITE request sent by Bob's proxy to Bob.
+
+ When received, Bob verifies the identity provided in the SIP
+ INVITE request.
+
+ INVITE sip:bob@ua2.example.com SIP/2.0
+ To: <sip:bob@example.com>
+ From: "Alice"<sip:alice@example.com>;tag=843c7b0b
+ Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk
+ Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
+ Record-Route: <sip:proxy.example.com;lr>
+ Contact: <sip:alice@ua1.example.com>
+ Call-ID: 6076913b1c39c212@REVMTEpG
+ CSeq: 1 INVITE
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+ Max-Forwards: 69
+ Content-Type: application/sdp
+ Content-Length: xxxx
+ Supported: from-change
+
+ v=0
+ o=- 1181923068 1181923196 IN IP4 ua1.example.com
+ s=-
+ c=IN IP4 ua1.example.com
+ t=0 0
+ m=image 6056 UDP/TLS/UDPTL t38
+ a=setup:actpass
+ a=fingerprint: SHA-1 \
+ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
+ a=T38FaxRateManagement:transferredTCF
+
+ Figure 5: Message (2)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 16]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ Message (3):
+
+ Assuming that Alice's identity is valid, Bob sends a DTLS
+ ClientHello directly to Alice.
+
+ Message (4):
+
+ Alice and Bob exchange further messages of DTLS handshake
+ (HelloVerifyRequest, ClientHello, ServerHello, Certificate,
+ ServerKeyExchange, CertificateRequest, ServerHelloDone,
+ Certificate, ClientKeyExchange, CertificateVerify,
+ ChangeCipherSpec, and Finished).
+
+ When Bob receives the certificate of Alice via DTLS, Bob checks
+ whether the certificate fingerprint calculated from Alice's
+ certificate received via DTLS matches the certificate fingerprint
+ received in the a=fingerprint SDP attribute of Figure 5. In this
+ message flow, the check is successful; thus, session setup
+ continues.
+
+ Note that, unlike in this example, it is not necessary to wait for
+ the DTLS handshake to finish before the SDP answer is sent. If
+ Bob has sent the SIP 200 (OK) response and later detects that the
+ certificate fingerprints do not match, he will terminate the
+ session.
+
+ Message (5):
+
+ Figure 6 shows a SIP 200 (OK) response to the initial SIP INVITE
+ request, sent by Bob to Bob's proxy. The SIP 200 (OK) response
+ contains an SDP answer.
+
+ The "m=" line in the SDP answer indicates T.38 fax using UDPTL
+ over DTLS.
+
+ The SDP "setup" attribute with a value of "active" in the SDP
+ answer indicates that Bob has requested to be the active endpoint.
+
+ The SDP "fingerprint" attribute in the SDP answer contains the
+ certificate fingerprint computed from Bob's self-signed
+ certificate.
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 17]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ SIP/2.0 200 OK
+ To: <sip:bob@example.com>;tag=6418913922105372816
+ From: "Alice" <sip:alice@example.com>;tag=843c7b0b
+ Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
+ Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
+ Record-Route: <sip:proxy.example.com;lr>
+ Call-ID: 6076913b1c39c212@REVMTEpG
+ CSeq: 1 INVITE
+ Contact: <sip:bob@ua2.example.com>
+ Content-Type: application/sdp
+ Content-Length: xxxx
+ Supported: from-change
+
+ v=0
+ o=- 8965454521 2105372818 IN IP4 ua2.example.com
+ s=-
+ c=IN IP4 ua2.example.com
+ t=0 0
+ m=image 12000 UDP/TLS/UDPTL t38
+ a=setup:active
+ a=fingerprint: SHA-1 \
+ FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
+ a=T38FaxRateManagement:transferredTCF
+
+ Figure 6: Message (5)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 18]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ Message (6):
+
+ Figure 7 shows a SIP 200 (OK) response to the initial SIP INVITE
+ request, sent by Alice's proxy to Alice. Alice checks if the
+ certificate fingerprint calculated from the Bob's certificate
+ received via DTLS is the same as the certificate fingerprint
+ received in the a=fingerprint SDP attribute of Figure 7. In this
+ message flow, the check is successful; thus, the session setup
+ continues.
+
+ SIP/2.0 200 OK
+ To: <sip:bob@example.com>;tag=6418913922105372816
+ From: "Alice" <sip:alice@example.com>;tag=843c7b0b
+ Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
+ Record-Route: <sip:proxy.example.com;lr>
+ Call-ID: 6076913b1c39c212@REVMTEpG
+ CSeq: 1 INVITE
+ Contact: <sip:bob@ua2.example.com>
+ Content-Type: application/sdp
+ Content-Length: xxxx
+ Supported: from-change
+
+ v=0
+ o=- 8965454521 2105372818 IN IP4 ua2.example.com
+ s=-
+ c=IN IP4 ua2.example.com
+ t=0 0
+ m=image 12000 UDP/TLS/UDPTL t38
+ a=setup:active
+ a=fingerprint: SHA-1 \
+ FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
+ a=T38FaxRateManagement:transferredTCF
+
+ Figure 7: Message (6)
+
+ Message (7):
+
+ Alice sends the SIP ACK request to Bob.
+
+ Message (8):
+
+ At this point, Bob and Alice can exchange T.38 fax securely
+ transported using UDPTL over DTLS.
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 19]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+A.3. Message Flow of T.38 Fax Replacing Audio Media Stream in an
+ Existing Audio-Only Session
+
+ Traditionally, most sessions with non-secure transport of T.38 fax,
+ transported using UDPTL, are established by modifying an ongoing
+ audio session into a fax session. Figure 8 shows an example message
+ flow of modifying an existing audio session into a session with T.38
+ fax securely transported using UDPTL over DTLS.
+
+ In this example flow, Alice acts as the passive endpoint of the DTLS
+ association, and Bob acts as the active endpoint of the DTLS
+ association.
+
+ Alice Proxies Bob
+ | | |
+ | (1) Audio-only session initiation |
+ |<-----------------------+----------------------->|
+ | | |
+ | (2) SIP re-INVITE | |
+ |------------------------------------------------>|
+ | | (3) DTLS ClientHello |
+ |<------------------------------------------------|
+ | (4) remaining messages of DTLS handshake |
+ |<----------------------------------------------->|
+ | | |
+ | | |
+ | | (5) SIP 200 OK |
+ |<------------------------------------------------|
+ | (6) SIP ACK | |
+ |------------------------------------------------>|
+ | (7) T.38 message using UDPTL over DTLS |
+ |<----------------------------------------------->|
+ | | |
+
+ Figure 8: Message Flow of T.38 Fax Replacing Audio Media Stream in an
+ Existing Audio-Only Session
+
+ Message (1):
+
+ Session establishment of audio-only session. The proxies decide
+ not to record-route.
+
+ Message (2):
+
+ Alice sends SIP re-INVITE request. The SDP offer included in the
+ SIP re-INVITE request is shown in Figure 9.
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 20]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ The first "m=" line in the SDP offer indicates audio media stream
+ being removed. The second "m=" line in the SDP offer indicates
+ T.38 fax using UDPTL over DTLS being added.
+
+ The SDP "setup" attribute with a value of "actpass" in the SDP
+ offer indicates that Alice has requested to be either the active
+ or passive endpoint.
+
+ The SDP "fingerprint" attribute in the SDP offer contains the
+ certificate fingerprint computed from Alice's self-signed
+ certificate.
+
+ v=0
+ o=- 2465353433 3524244442 IN IP4 ua1.example.com
+ s=-
+ c=IN IP4 ua1.example.com
+ t=0 0
+ m=audio 0 UDP/TLS/RTP/SAVP 0
+ m=image 46056 UDP/TLS/UDPTL t38
+ a=setup:actpass
+ a=fingerprint: SHA-1 \
+ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
+ a=T38FaxRateManagement:transferredTCF
+
+ Figure 9: SDP Offer of Message (2)
+
+ Message (3):
+
+ Bob sends a DTLS ClientHello directly to Alice.
+
+ Message (4):
+
+ Alice and Bob exchange further messages of DTLS handshake
+ (HelloVerifyRequest, ClientHello, ServerHello, Certificate,
+ ServerKeyExchange, CertificateRequest, ServerHelloDone,
+ Certificate, ClientKeyExchange, CertificateVerify,
+ ChangeCipherSpec, and Finished).
+
+ When Bob receives the certificate of Alice via DTLS, Bob checks
+ whether the certificate fingerprint calculated from Alice's
+ certificate received via DTLS matches the certificate fingerprint
+ received in the SDP "fingerprint" attribute of Figure 9. In this
+ message flow, the check is successful; thus, session setup
+ continues.
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 21]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+ Message (5):
+
+ Bob sends a SIP 200 (OK) response to the SIP re-INVITE request.
+ The SIP 200 (OK) response contains an SDP answer shown in
+ Figure 10.
+
+ The first "m=" line in the SDP offer indicates audio media stream
+ being removed. The second "m=" line in the SDP answer indicates
+ T.38 fax using UDPTL over DTLS being added.
+
+ The SDP "setup" attribute with a value of "active" in the SDP
+ answer indicates that Bob has requested to be the active endpoint.
+
+ The SDP "fingerprint" attribute in the SDP answer contains the
+ certificate fingerprint computed from Bob's self-signed
+ certificate.
+
+ v=0
+ o=- 4423478999 5424222292 IN IP4 ua2.example.com
+ s=-
+ c=IN IP4 ua2.example.com
+ t=0 0
+ m=audio 0 UDP/TLS/RTP/SAVP 0
+ m=image 32000 UDP/TLS/UDPTL t38
+ a=setup:active
+ a=fingerprint: SHA-1 \
+ FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
+ a=T38FaxRateManagement:transferredTCF
+
+ Figure 10: SDP Answer of Message (5)
+
+ Message (6):
+
+ Alice sends the SIP ACK request to Bob.
+
+ Message (7):
+
+ At this point, Bob and Alice can exchange T.38 fax securely
+ transported using UDPTL over DTLS.
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 22]
+
+RFC 7345 UDPTL over DTLS August 2014
+
+
+Authors' Addresses
+
+ Christer Holmberg
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: christer.holmberg@ericsson.com
+
+
+ Ivo Sedlacek
+ Ericsson
+ Sokolovska 79
+ Praha 18600
+ Czech Republic
+
+ EMail: ivo.sedlacek@ericsson.com
+
+
+ Gonzalo Salgueiro
+ Cisco Systems, Inc.
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ US
+
+ EMail: gsalguei@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 23]
+