draft-ietf-mmusic-udptl-dtls-01.txt   draft-ietf-mmusic-udptl-dtls-02.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: May 25, 2014 G. Salgueiro Expires: June 8, 2014 G. Salgueiro
Cisco Cisco
November 21, 2013 December 5, 2013
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-01 draft-ietf-mmusic-udptl-dtls-02
Abstract Abstract
This document specifies how the UDP Transport Layer (UDPTL) protocol This document specifies how the UDP Transport Layer (UDPTL) protocol
can be transported over the Datagram Transport Layer Security (DTLS) can be transported over the Datagram Transport Layer Security (DTLS)
protocol, how the usage of UDPTL over DTLS is indicated in the protocol, how the usage of UDPTL over DTLS is indicated in the
Session Description Protocol (SDP), and how UDPTL over DTLS is Session Description Protocol (SDP), and how UDPTL over DTLS is
negotiated in a session established using the Session Initiation negotiated in a session established using the Session Initiation
Protocol (SIP). 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 May 25, 2014. This Internet-Draft will expire on June 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 4 3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5 3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5
3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 5 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.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4.2.2. Latching Control without ICE . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4.2.3. STUN Interaction . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2. Basic Message Flow with Identity . . . . . . . . . . . . 10 A.2. Basic Message Flow with Identity . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . 15 An Existing Audio-Only Session . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
While telephony encryption devices have been traditionally used for While telephony encryption devices have been traditionally used for
highly sensitive documents, secure fax on the Public Switched highly sensitive documents, secure fax on the Public Switched
Telephone Network (PSTN) was not as widely considered or prioritized Telephone Network (PSTN) was not as widely considered or prioritized
because of the challenges involved with physical access to telephony because of the challenges involved with physical access to telephony
equipment. As real-time communications transition to IP networks, equipment. As real-time communications transition to IP networks,
where information might potentially be intercepted or spoofed, an where information might potentially be intercepted or spoofed, an
appropriate level of security for fax that offers integrity and appropriate level of security for fax that offers integrity and
skipping to change at page 5, line 35 skipping to change at page 5, line 38
assigns the SDP setup attribute with a setup:actpass value or assigns the SDP setup attribute with a setup:actpass value or
setup:passive value, it MUST be prepared to receive a DTLS setup:passive value, it MUST be prepared to receive a DTLS
client_hello message before it receives the SDP answer. If the client_hello message before it receives the SDP answer. If the
answerer accepts the media stream, then it MUST assign the SDP answerer accepts the media stream, then it MUST assign the SDP
setup attribute with either a setup:active value or setup:passive setup attribute with either a setup:active value or setup:passive
value, according to the procedures in [RFC4145]. The answerer value, according to the procedures in [RFC4145]. The answerer
MUST NOT assign an SDP setup attribute with a setup:holdconn MUST NOT assign an SDP setup attribute with a setup:holdconn
value. Whichever party is active, it MUST initiate a DTLS value. Whichever party is active, it MUST initiate a DTLS
handshake by sending a ClientHello over each flow (host/port handshake by sending a ClientHello over each flow (host/port
quartet). quartet).
o The endpoint MUST use the SDP certificate fingerprint attribute o If the endpoint supports, and is willing to use, a cipher suite
[RFC4572]. with an associated certificate, it MUST include an SDP fingerprint
o The certificate presented during the DTLS handshake MUST match the attribute [RFC4572] in the SDP.
fingerprint exchanged via the signaling path in the SDP. o If a cipher suite with an associated certificate is selected
o If the fingerprint does not match the hashed certificate, then the during the DTLS handshake, the certificate received during the
endpoint MUST tear down the media session immediately. Note that DTLS handshake MUST match the fingerprint received in the SDP
it is permissible to wait until the other side's fingerprint has fingerprint attribute. If the fingerprint does not match the
been received before establishing the connection; however, this hashed certificate, then the endpoint MUST tear down the media
may have undesirable latency effects. 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.
o The endpoint MUST NOT use the SDP connection attribute [RFC4145]. o The endpoint MUST NOT use the SDP connection attribute [RFC4145].
3.2. Secure Channel Usage 3.2. Secure Channel Usage
DTLS is used as specified in [RFC6347]. Once the DTLS handshake is DTLS is used as specified in [RFC6347]. Once the DTLS handshake is
completed, the UDPTL packets SHALL be transported in DTLS record completed, the UDPTL packets SHALL be transported in DTLS record
layer "application_data" packets. 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 the content of the subjectAltName attribute
inside the certificate MUST NOT contain information that either inside the certificate MUST NOT contain information that either
allows correlation or identification of the user making anonymous allows correlation or identification of the user making anonymous
calls. calls.
4.2. Middlebox Interaction 4.2. Middlebox Interaction
The procedures defined for SRTP-DTLS in Section 6.7 of [RFC5763] for 4.2.1. ICE Interaction
interaction with middleboxes also apply to UDPTL over DTLS.
The procedures defined for SRTP-DTLS in Section 5.1.2 of [RFC5764] When ICE [RFC5245] is being used, the ICE connectivity checks are
for distinguishing DTLS and STUN packets also apply to UDPTL over performed before the DTLS handshake begins. Note that if aggressive
DTLS. nomination mode is used, multiple candidate pairs may be marked valid
before ICE finally converges on a single candidate pair. 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.
Editor's note: The complete SRTP-DTLS implementation is not needed. 4.2.2. Latching Control without ICE
Only the parts for interaction with middleboxes in RFC5763 and for
distinguishing DTLS and STUN packets in RFC5764 are needed. Should When ICE [RFC5245] is not being used and the DTLS handshake has not
those be copied into this document? completed upon receiving the other side's SDP, then the passive side
MUST do a single unauthenticated STUN [RFC5389] connectivity check in
order to open up the appropriate pinhole. All UAs MUST be prepared
to answer this request during the handshake period even if they do
not otherwise do ICE. However, the active side MUST proceed with the
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
ServerHello.
4.2.3. STUN Interaction
The UA SHALL send the STUN packets [RFC5389] directly over UDP, not
over DTLS.
The UA MUST demultiplex packets arriving on the IP address and port
associated with the DTLS association as follows:
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.
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 SHOULD 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.
skipping to change at page 7, line 43 skipping to change at page 8, line 32
+-------+---------------+------------+ +-------+---------------+------------+
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 and version of the draft, and to Paul E. Jones, James Rafferty, Albrecht
Albrecht Schwarz who provided valuable feedback and input on the Schwarz and Oscar Ohlsson who provided valuable feedback and input on
MMUSIC mailing list. 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-01
o Usage of the SDP fingerprint attribute depends on whether a cipher
suite with an associated certificate is used.
o Editor's note in section 4.2 removed. Procedure text added.
Changes from draft-ietf-mmusic-udptl-dtls-00 Changes from draft-ietf-mmusic-udptl-dtls-00
o SDP offerer is allowed to assign an a=setup:active or o SDP offerer is allowed to assign an a=setup:active or
a=setup:passive value, in addition to the recommended a=setup:passive value, in addition to the recommended
a=setup:actpass (http://www.ietf.org/mail-archive/web/mmusic/ a=setup:actpass (http://www.ietf.org/mail-archive/web/mmusic/
current/msg12331.html). current/msg12331.html).
o The example for secure fax replacing audio stream in audio-only o The example for secure fax replacing audio stream in audio-only
session added (http://www.ietf.org/mail-archive/web/mmusic/current session added (http://www.ietf.org/mail-archive/web/mmusic/current
/msg12428.html). /msg12428.html).
o Editor's note on the connection attribute resolved by prohibiting o Editor's note on the connection attribute resolved by prohibiting
usage of the SDP connection attribute (http://www.ietf.org/mail- usage of the SDP connection attribute (http://www.ietf.org/mail-
archive/web/mmusic/current/msg12772.html). archive/web/mmusic/current/msg12772.html).
o Editorial corrections. o Editorial corrections.
Changes from draft-holmberg-mmusic-udptl-dtls-02 Changes from draft-holmberg-mmusic-udptl-dtls-02
skipping to change at page 9, line 20 skipping to change at page 10, line 16
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. 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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
for Establishing a Secure Real-time Transport Protocol "Session Traversal Utilities for NAT (STUN)", RFC 5389,
(SRTP) Security Context Using Datagram Transport Layer October 2008.
Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[ITU.T30.2005] [ITU.T30.2005]
International Telecommunications Union, "Procedures for International Telecommunications Union, "Procedures for
document facsimile transmission in the general switched document facsimile transmission in the general switched
telephone network", ITU-T Recommendation T.30, September telephone network", ITU-T Recommendation T.30, September
2005. 2005.
 End of changes. 19 change blocks. 
46 lines changed or deleted 86 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/