--- 1/draft-ietf-mmusic-udptl-dtls-01.txt 2013-12-09 14:54:08.544451995 -0800 +++ 2/draft-ietf-mmusic-udptl-dtls-02.txt 2013-12-09 14:54:08.584453180 -0800 @@ -1,21 +1,21 @@ MMUSIC Working Group C. Holmberg Internet-Draft I. Sedlacek Intended status: Standards Track Ericsson -Expires: May 25, 2014 G. Salgueiro +Expires: June 8, 2014 G. Salgueiro Cisco - November 21, 2013 + December 5, 2013 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) - draft-ietf-mmusic-udptl-dtls-01 + draft-ietf-mmusic-udptl-dtls-02 Abstract This document specifies how the UDP Transport Layer (UDPTL) protocol 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). @@ -27,61 +27,64 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5 - 3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 5 + 3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 6 4. Miscellaneous Considerations . . . . . . . . . . . . . . . . 6 4.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 6 4.2. Middlebox Interaction . . . . . . . . . . . . . . . . . . 6 - 4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 - 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 4.2.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 6 + 4.2.2. Latching Control without ICE . . . . . . . . . . . . 6 + 4.2.3. STUN Interaction . . . . . . . . . . . . . . . . . . 7 + 4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 + 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 - A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 - A.2. Basic Message Flow with Identity . . . . . . . . . . . . 10 + A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 + A.2. Basic Message Flow with Identity . . . . . . . . . . . . 11 A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in - An Existing Audio-Only Session . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + An Existing Audio-Only Session . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction While telephony encryption devices have been traditionally used for highly sensitive documents, secure fax on the Public Switched Telephone Network (PSTN) was not as widely considered or prioritized because of the challenges involved with 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 @@ -212,60 +217,89 @@ assigns the SDP setup attribute with a setup:actpass value or setup:passive value, it MUST be prepared to receive a DTLS client_hello message before it receives the SDP answer. If the answerer accepts the media stream, then it MUST assign the SDP setup attribute with either a setup:active value or setup:passive value, according to the procedures in [RFC4145]. The answerer MUST NOT assign an SDP setup attribute with a setup:holdconn value. Whichever party is active, it MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). - o The endpoint MUST use the SDP certificate fingerprint attribute - [RFC4572]. - o The certificate presented during the DTLS handshake MUST match the - fingerprint exchanged via the signaling path in the SDP. - o 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. + o If the endpoint supports, and is willing to use, a cipher suite + with an associated certificate, it MUST include an SDP fingerprint + attribute [RFC4572] in the SDP. + o 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. o The endpoint MUST NOT use the SDP connection attribute [RFC4145]. 3.2. Secure Channel Usage DTLS is used as specified in [RFC6347]. Once the DTLS handshake is completed, the UDPTL packets SHALL be transported in DTLS record layer "application_data" packets. 4. Miscellaneous Considerations 4.1. Anonymous Calls When making anonymous calls, a new self-signed certificate SHOULD be used for each call and the content of the subjectAltName attribute inside the certificate MUST NOT contain information that either allows correlation or identification of the user making anonymous calls. 4.2. Middlebox Interaction - The procedures defined for SRTP-DTLS in Section 6.7 of [RFC5763] for - interaction with middleboxes also apply to UDPTL over DTLS. +4.2.1. ICE Interaction - The procedures defined for SRTP-DTLS in Section 5.1.2 of [RFC5764] - for distinguishing DTLS and STUN packets also apply to UDPTL over - DTLS. + When 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. 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. - Only the parts for interaction with middleboxes in RFC5763 and for - distinguishing DTLS and STUN packets in RFC5764 are needed. Should - those be copied into this document? +4.2.2. Latching Control without ICE + + 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 + 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 After the DTLS handshake caused by rekeying has completed, because of possible packet reordering on the wire, packets protected by the previous set of keys can arrive. To compensate for this fact, receivers SHOULD 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 scope for this document. @@ -314,33 +348,41 @@ +-------+---------------+------------+ Table 3: SDP "proto" field values [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] 7. Acknowledgments Special thanks to Peter Dawes, who provided comments on the initial - version of the draft, and to Paul E. Jones, James Rafferty and - Albrecht Schwarz who provided valuable feedback and input on the - MMUSIC mailing list. + version of the draft, and to Paul E. Jones, James Rafferty, Albrecht + Schwarz and Oscar Ohlsson who provided valuable feedback and input on + the MMUSIC mailing list. 8. Change Log [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 + o SDP offerer is allowed to assign an a=setup:active or a=setup:passive value, in addition to the recommended a=setup:actpass (http://www.ietf.org/mail-archive/web/mmusic/ current/msg12331.html). + o The example for secure fax replacing audio stream in audio-only session added (http://www.ietf.org/mail-archive/web/mmusic/current /msg12428.html). o Editor's note on the connection attribute resolved by prohibiting usage of the SDP connection attribute (http://www.ietf.org/mail- archive/web/mmusic/current/msg12772.html). o Editorial corrections. Changes from draft-holmberg-mmusic-udptl-dtls-02 @@ -387,33 +429,33 @@ 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. + [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. - [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework - for Establishing a Secure Real-time Transport Protocol - (SRTP) Security Context Using Datagram Transport Layer - 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. + [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. [ITU.T30.2005] International Telecommunications Union, "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, September 2005.