draft-ietf-mmusic-udptl-dtls-03.txt   draft-ietf-mmusic-udptl-dtls-04.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: July 21, 2014 G. Salgueiro Expires: August 5, 2014 G. Salgueiro
Cisco Cisco
January 17, 2014 February 1, 2014
UDP Transport Layer (UDPTL) over Datagram Transport Layer Security UDP Transport Layer (UDPTL) over Datagram Transport Layer Security
(DTLS) (DTLS)
draft-ietf-mmusic-udptl-dtls-03 draft-ietf-mmusic-udptl-dtls-04
Abstract Abstract
This document specifies how the UDP Transport Layer (UDPTL) protocol, This document specifies how the UDP Transport Layer (UDPTL) protocol,
the predominant transport protocol for T.38 fax, can be transported the predominant transport protocol for T.38 fax, can be transported
over the Datagram Transport Layer Security (DTLS) protocol, how the over the Datagram Transport Layer Security (DTLS) protocol, how the
usage of UDPTL over DTLS is indicated in the Session Description usage of UDPTL over DTLS is indicated in the Session Description
Protocol (SDP), and how UDPTL over DTLS is negotiated in a session Protocol (SDP), and how UDPTL over DTLS is negotiated in a session
established using the Session Initiation Protocol (SIP). established using the Session Initiation Protocol (SIP).
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2014. This Internet-Draft will expire on August 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5 3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5 3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5
3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 6 3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 6
4. Miscellaneous Considerations . . . . . . . . . . . . . . . . 6 4. Miscellaneous Considerations . . . . . . . . . . . . . . . . 6
4.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 6 4.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 6
4.2. Middlebox Interaction . . . . . . . . . . . . . . . . . . 6 4.2. Middlebox Interaction . . . . . . . . . . . . . . . . . . 6
4.2.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 6 4.2.1. NAT Traversal With ICE . . . . . . . . . . . . . . . 6
4.2.2. Latching Control without ICE . . . . . . . . . . . . 6 4.2.2. NAT Traversal Without ICE . . . . . . . . . . . . . . 6
4.2.3. STUN Interaction . . . . . . . . . . . . . . . . . . 7 4.2.3. STUN Interaction . . . . . . . . . . . . . . . . . . 7
4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 11 A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 12
A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in
An Existing Audio-Only Session . . . . . . . . . . . . . 17 An Existing Audio-Only Session . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
While it is possible to transmit highly sensitive documents using While it is possible to transmit highly sensitive documents using
traditional telephony encryption devices, secure fax on the Public traditional telephony encryption devices, secure fax on the Public
Switched Telephone Network (PSTN) was never widely considered or Switched Telephone Network (PSTN) was never widely considered or
prioritized. This was mainly because of the challenges involved with prioritized. This was mainly because of the challenges involved with
physical access to telephony equipment. As real-time communications malevolent physical access to telephony equipment. As real-time
transition to IP networks, where information might potentially be communications transition to IP networks, where information might
intercepted or spoofed, an appropriate level of security for fax that potentially be intercepted or spoofed, an appropriate level of
offers integrity and confidentiality protection is vital. security for fax that offers integrity and confidentiality protection
is vital.
The overwhelmingly predominant fax transport protocol is UDPTL-based The overwhelmingly predominant fax transport protocol is UDPTL-based
[ITU.T38.2010]. The protocol stack for fax transport using UDPTL is [ITU.T38.2010]. The protocol stack for fax transport using UDPTL is
shown in Table 1. shown in Table 1.
+-----------------------------+ +-----------------------------+
| Internet facsimile protocol | | Internet facsimile protocol |
+-----------------------------+ +-----------------------------+
| UDPTL | | UDPTL |
+-----------------------------+ +-----------------------------+
skipping to change at page 4, line 22 skipping to change at page 4, line 22
DTLS layer between the UDPTL layer and the UDP layer, as shown in DTLS layer between the UDPTL layer and the UDP layer, as shown in
Table 2. The UDPTL layer and layers above UDPTL layer require no Table 2. The UDPTL layer and layers above UDPTL layer require no
modification. modification.
o UDPTL [ITU.T38.2010] is by far the most widely deployed fax o UDPTL [ITU.T38.2010] is by far the most widely deployed fax
transport protocol in IP networks. transport protocol in IP networks.
o 3GPP and the IP fax community need a mechanism to transport UDPTL o 3GPP and the IP fax community need a mechanism to transport UDPTL
over DTLS in order to provide secure fax in IMS and other SIP- over DTLS in order to provide secure fax in IMS and other SIP-
based networks. based networks.
This document specifies the transport of UDPTL over DTLS using the This document specifies the transport of UDPTL over DTLS using the
DTLS record layer "application_data" packets [RFC6347]. DTLS record layer "application_data" packets [RFC5246] [RFC6347].
Since the DTLS record layer "application_data" packet does not Since the DTLS record layer "application_data" packet does not
indicate whether it carries UDPTL, or some other protocol, the usage indicate whether it carries UDPTL, or some other protocol, the usage
of a dedicated DTLS association for transport of UDPTL needs to be of a dedicated DTLS association for transport of UDPTL needs to be
negotiated, e.g. using the Session Description Protocol (SDP) negotiated, e.g. using the Session Description Protocol (SDP)
[RFC4566] and the SDP offer/answer mechanism [RFC3264]. [RFC4566] and the SDP offer/answer mechanism [RFC3264].
Therefore, this document specifies a new <proto> value [RFC4566] for Therefore, this document specifies a new <proto> value [RFC4566] for
the SDP media description ("m=" line) [RFC3264], in order to indicate the SDP media description ("m=" line) [RFC3264], in order to indicate
UDPTL over DTLS in SDP messages [RFC4566]. UDPTL over DTLS in SDP messages [RFC4566].
skipping to change at page 6, line 17 skipping to change at page 6, line 17
DTLS is used as specified in [RFC6347]. Once the DTLS handshake is DTLS is used as specified in [RFC6347]. Once the DTLS handshake is
successfully completed (in order to prevent facsimile data from being successfully completed (in order to prevent facsimile data from being
transmitted insecurely), the UDPTL packets SHALL be transported in transmitted insecurely), the UDPTL packets SHALL be transported in
DTLS record layer "application_data" packets. DTLS record layer "application_data" packets.
4. Miscellaneous Considerations 4. Miscellaneous Considerations
4.1. Anonymous Calls 4.1. Anonymous Calls
When making anonymous calls, a new self-signed certificate SHOULD be When making anonymous calls, a new self-signed certificate SHOULD be
used for each call and the content of the subjectAltName attribute used for each call and attributes inside the certificate SHALL NOT
inside the certificate MUST NOT contain information that either contain information that either allows correlation or identification
allows correlation or identification of the user making anonymous of the user making anonymous calls. This is particularly important
calls. for the subjectAltName and commonName attributes.
4.2. Middlebox Interaction 4.2. Middlebox Interaction
4.2.1. ICE Interaction 4.2.1. NAT Traversal With ICE
When ICE [RFC5245] is being used, the ICE connectivity checks are When ICE [RFC5245] is being used, the ICE connectivity checks are
performed before the DTLS handshake begins. Note that if aggressive performed before the DTLS handshake begins. Note that if aggressive
nomination mode is used, multiple candidate pairs may be marked valid nomination mode is used, multiple candidate pairs may be marked valid
before ICE finally converges on a single candidate pair. UAs MUST before ICE finally converges on a single candidate pair. UAs MUST
treat all ICE candidate pairs associated with a single component as treat all ICE candidate pairs associated with a single component as
part of the same DTLS association. Thus, there will be only one DTLS part of the same DTLS association. Thus, there will be only one DTLS
handshake even if there are multiple valid candidate pairs. Note handshake even if there are multiple valid candidate pairs. Note
that this may mean adjusting the endpoint IP addresses if the that this may mean adjusting the endpoint IP addresses if the
selected candidate pair shifts, just as if the DTLS packets were an selected candidate pair shifts, just as if the DTLS packets were an
ordinary media stream. ordinary media stream.
4.2.2. Latching Control without ICE 4.2.2. NAT Traversal Without ICE
When ICE [RFC5245] is not being used and the DTLS handshake has not When ICE [RFC5245] is not being used and the DTLS handshake has not
completed upon receiving the other side's SDP, then the passive side completed upon receiving the other side's SDP, then the passive side
MUST do a single unauthenticated STUN [RFC5389] connectivity check in MUST do a single unauthenticated STUN [RFC5389] connectivity check in
order to open up the appropriate pinhole. All UAs MUST be prepared order to open up the appropriate pinhole. All UAs MUST be prepared
to answer this request during the handshake period even if they do to answer this request during the handshake period even if they do
not otherwise do ICE. However, the active side MUST proceed with the not otherwise do ICE. However, the active side MUST proceed with the
DTLS handshake as appropriate even if no such STUN check is received DTLS handshake as appropriate even if no such STUN check is received
and the passive MUST NOT wait for a STUN answer before sending its and the passive side MUST NOT wait for a STUN answer before sending
ServerHello. its ServerHello.
4.2.3. STUN Interaction 4.2.3. STUN Interaction
The UA SHALL send the STUN packets [RFC5389] directly over UDP, not The UA SHALL send the STUN packets [RFC5389] directly over UDP, not
over DTLS. over DTLS.
The UA MUST demultiplex packets arriving on the IP address and port The UA MUST demultiplex packets arriving on the IP address and port
associated with the DTLS association as follows: associated with the DTLS association, e.g. as follows:
o If the value of the first byte of the packet is 0 or 1, then the o If the value of the first byte of the packet is 0 or 1, then the
packet is STUN. packet is STUN.
o If the value of the first byte of the packet is between 20 and 63 o If the value of the first byte of the packet is between 20 and 63
(inclusive), the packet is DTLS. (inclusive), the packet is DTLS.
4.3. Rekeying 4.3. Rekeying
After the DTLS handshake caused by rekeying has completed, because of After the DTLS handshake caused by rekeying has completed, because of
possible packet reordering on the wire, packets protected by the possible packet reordering on the wire, packets protected by the
previous set of keys can arrive. To compensate for this fact, previous set of keys can arrive. To compensate for this fact,
receivers SHOULD maintain both sets of keys for some time in order to receivers MUST maintain both sets of keys for some time in order to
be able to decrypt and verify older packets. The duration of be able to decrypt and verify older packets. The duration of
maintaining the previous set of keys after the finish of the DTLS maintaining the previous set of keys after the finish of the DTLS
handshake is out of scope for this document. handshake is out of scope for this document.
5. Security Considerations 5. Security Considerations
Fax may be used to transmit a wide range of sensitive data, including Fax may be used to transmit a wide range of sensitive data, including
personal, corporate, and governmental information. It is therefore personal, corporate, and governmental information. It is therefore
critical to be able to protect against threats to the confidentiality critical to be able to protect against threats to the confidentiality
and integrity of the transmitted data. and integrity of the transmitted data.
skipping to change at page 8, line 39 skipping to change at page 8, line 39
Table 3: SDP "proto" field values Table 3: SDP "proto" field values
[RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this
document.] document.]
7. Acknowledgments 7. Acknowledgments
Special thanks to Peter Dawes, who provided comments on the initial Special thanks to Peter Dawes, who provided comments on the initial
version of the draft, and to Paul E. Jones, James Rafferty, Albrecht version of the draft, and to Paul E. Jones, James Rafferty, Albrecht
Schwarz, Oscar Ohlsson and David Hanes who provided valuable feedback Schwarz, Oscar Ohlsson, David Hanes, Adam Gensler and Ari Keraenen
and input on the MMUSIC mailing list. who provided valuable feedback and input on the MMUSIC mailing list.
8. Change Log 8. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-udptl-dtls-03
o Changes based on comments by Adam Gensler (http://www.ietf.org/
mail-archive/web/mmusic/current/msg12945.html)
o -Indicating that, in case of rekeying, entities MUST maintain both
set of keys for some time (previously SHOULD).
o -Explicit mentioning of the commonName attribute in text about
correlation/identification of users.
o Changes based on comments by Ari Keraenen (http://www.ietf.org/
mail-archive/web/mmusic/current/msg12966.html)
o -Informative reference to RFC 5246 added.
o -Re-naming of sections 4.2.1 and 4.2.2.
o -Clarifying that documented STUN/DTLS demux mechanism is only one
way of doing the demux.
o -Editorial corrections.
Changes from draft-ietf-mmusic-udptl-dtls-02 Changes from draft-ietf-mmusic-udptl-dtls-02
o Editorial comments based on review comments by James Rafferty o Editorial comments based on review comments by James Rafferty
(http://www.ietf.org/mail-archive/web/mmusic/current/ (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12890.html) msg12890.html)
o Editorial comments based on review comments by David Hanes (http:/ o Editorial comments based on review comments by David Hanes (http:/
/www.ietf.org/mail-archive/web/mmusic/current/msg12886.html) /www.ietf.org/mail-archive/web/mmusic/current/msg12886.html)
o Editorial comments based on review comments by Oscar Ohlsson o Editorial comments based on review comments by Oscar Ohlsson
(http://www.ietf.org/mail-archive/web/mmusic/current/ (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12882.html) msg12882.html)
o Editorial comments based on review comments by Albrecht Schwartz o Editorial comments based on review comments by Albrecht Schwartz
(http://www.ietf.org/mail-archive/web/mmusic/current/ (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12900.html) msg12900.html)
Changes from draft-ietf-mmusic-udptl-dtls-01 Changes from draft-ietf-mmusic-udptl-dtls-01
skipping to change at page 11, line 21 skipping to change at page 11, line 35
telephone network", ITU-T Recommendation T.30, September telephone network", ITU-T Recommendation T.30, September
2005. 2005.
[ITU.T38.2010] [ITU.T38.2010]
International Telecommunications Union, "Procedures for International Telecommunications Union, "Procedures for
real-time Group 3 facsimile communication over IP real-time Group 3 facsimile communication over IP
networks", ITU-T Recommendation T.38, September 2010. networks", ITU-T Recommendation T.38, September 2010.
9.2. Informative References 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, [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management "Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009. Protocols", RFC 5479, April 2009.
Appendix A. Examples Appendix A. Examples
A.1. General A.1. General
Prior to establishing the session, both Alice and Bob generate self- Prior to establishing the session, both Alice and Bob generate self-
signed certificates which are used for a single session or, more signed certificates which are used for a single session or, more
skipping to change at page 17, line 42 skipping to change at page 17, line 42
Alice sends the SIP ACK request to Bob. Alice sends the SIP ACK request to Bob.
Message (8): Message (8):
At this point, Bob and Alice can exchange T.38 fax securely At this point, Bob and Alice can exchange T.38 fax securely
transported using UDPTL over DTLS. transported using UDPTL over DTLS.
A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An
Existing Audio-Only Session Existing Audio-Only Session
Traditionally, most session with non-secure transport of T.38 fax, Traditionally, most sessions with non-secure transport of T.38 fax,
transported using UDPTL, are established by modifying an ongoing transported using UDPTL, are established by modifying an ongoing
audio session into a fax session. Figure 6 shows an example message audio session into a fax session. Figure 6 shows an example message
flow of modifying an existing audio session into a session with T.38 flow of modifying an existing audio session into a session with T.38
fax securely transported using UDPTL over DTLS. fax securely transported using UDPTL over DTLS.
In this example flow, Alice acts as the passive endpoint of the 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 and Bob acts as the active endpoint of the DTLS
association. association.
Alice Proxies Bob Alice Proxies Bob
 End of changes. 19 change blocks. 
26 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/