Network Working Group H. Tschofenig Internet-Draft Siemens Expires: August 29, 2006 E. Rescorla Network Resonance February 25, 2006 Real-Time Transport Protocol (RTP) over Datagram Transport Layer Security (DTLS) draft-tschofenig-avt-rtp-dtls-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This specification defines how to establish secure Real-Time Transport Protocol (RTP) sessions over the Datagram Transport Layer Security (DTLS) protocol. Tschofenig & Rescorla Expires August 29, 2006 [Page 1]
Internet-Draft RTP over DTLS February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. RTP Packet Generation . . . . . . . . . . . . . . . . . . . . 3 4. SRTP Compatibility Mode . . . . . . . . . . . . . . . . . . . 4 5. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Size Comparison to SRTP . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informational References . . . . . . . . . . . . . . . . 8 Appendix A. Packet Header Formats . . . . . . . . . . . . . . . . 9 A.1. SRTP Packet Format . . . . . . . . . . . . . . . . . . . 9 A.2. DTLS/RTP Packet Format . . . . . . . . . . . . . . . . . 10 A.3. DTLS/RTP Packet Format in SRTP-compatibility mode . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Tschofenig & Rescorla Expires August 29, 2006 [Page 2]
Internet-Draft RTP over DTLS February 2006 1. Introduction Security is a major concern for real-time multimedia systems such as Internet telephony. This document is part of a suite of documents describing a complete system for securing such communications using Datagram Transport Layer Security (DTLS). Readers should also read [18] and [17] for background. This document focuses on using DTLS to protect the Real-Time Transport Protocol (RTP). 2. Conventions Used In This Document 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 [1]. DTLS[4] and TLS[5] uses the term "session" to refer to a long-lived set of keying material that spans associations. In this document, consistent with SIP/SDP usage, we use it to refer to a multimedia session and use the term "TLS session" to refer to the TLS construct. We use the term "association" to refer to a particular DTLS ciphersuite and keying material set. 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/TLS. In this document, the term "Mutual DTLS" indicates that both the DTLS client and server present certificates even if one or both certificates are self-signed. 3. RTP Packet Generation The normal RTP[3] and RTCP payloads that would be sent inside a UDP packet are also sent inside of a DTLS packet. The synchronization source (SSRC) is filled in as with a normal RTP packet. For example, in an audio session that also contains DTMF using RFC2833 [9] the audio packets will have different SSRC values than the DTMF packets. A DTLS/RTP packet has the following layout: Tschofenig & Rescorla Expires August 29, 2006 [Page 3]
Internet-Draft RTP over DTLS February 2006 +-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Header | | | +-----------------------+ | | | UDP Header | | | +-----------------------+ | | | DTLS Header | | | +.......................+ | +--------------------+ | | | | | RTP Header | | | | | +--------------------+ | +--------------------+ | | | | | Payload | | | | | +--------------------+ +.......................+ | | | DTLS Trailer | | | +-----------------------+ A sample packet is shown in Appendix A (using the TLS MAC truncation mode from [6] and the TLS Counter mode of [14]). 4. SRTP Compatibility Mode SRTP [13] is a tightly coupled encryption mode for RTP which utilizes a number of advanced techniques to provide optimal performance and deployability for protected RTP traffic. These benefits include: o Leaving the RTP header unencrypted (enabling header compression[8][10][12] and easy debugging). o Having the packets appear to be RTP packets for firewall compatibility. o Zero header overhead This section describes a profile of RTP over DTLS which allows the use of DTLS key management while providing an on-the-wire packet format which is the same as that of SRTP. This profile depends on 'Extensions for DTLS in Low Bandwidth Tschofenig & Rescorla Expires August 29, 2006 [Page 4]
Internet-Draft RTP over DTLS February 2006 Environments' described in [15] and on 'TLS Partial Encryption Mode' [16]. The former extension reduces the per-record bandwidth of the data channel. The latter extension allows partial encryption of record bodies. In order to use DTLS/RTP in SRTP compatibility mode, implementations SHOULD negotiate: o The TLS partial encryption extension with an InitialPlaintext value equal to the length of the RTP header. o The DTLS implicit application data header. o The TLS MAC truncation extension. With these extensions negotiated, RTP over DTLS packets look identical to SRTP records with a 10-byte MAC value. In fact, they cannot be distinguished without access to the DTLS or SRTP keying material. In addition, since the RTP header is in the clear, header compression and debugging both work. Note that DTLS running in SRTP compatibility mode has the same security properties as ordinary DTLS (with the truncated MAC); there is a reduction between the two protocols. 5. RTP and RTCP Note that the active endpoint will establish two DTLS sessions with the passive endpoint for each of the RTP and RTCP channels. The RTP and RTCP sessions share the same certificate and thus the same fingerprint. [Editor's Note: In next draft revision TLS session resumption will be discussed.] 6. Size Comparison to SRTP One of the major arguments for SRTP is its low space overhead, which comes from reusing as much as possible of the RTP infrastructure. There are two areas where RTP over DTLS has overhead greater than that of SRTP: o Record header (type, version, length, sequence number, epoch) o MAC (DTLS uses a 10 byte MAC and SRTP uses a 4 byte MAC). Tschofenig & Rescorla Expires August 29, 2006 [Page 5]
Internet-Draft RTP over DTLS February 2006 +------------------+--------------+--------------+ | Header | DTLS (bytes) | SRTP (bytes) | +------------------+--------------+--------------+ | Record Header | 5 | 0 | | sequence + epoch | 8 | 0 | | MAC | 10 | 4 | | Total | 23 | 4 | +------------------+--------------+--------------+ The DTLS record header consumes 5 bytes for the type, version, and length + 8 bytes for the sequence number and epoch. Thus, the total size difference between DTLS and SRTP is 19 bytes if the master key identifier (MKI) is not used in SRTP and 15 bytes if a 4 byte MKI is used. The profile discussed in the previous section allows the complete removal of the header for a net difference of 6 bytes (without MKI) or 2 bytes (with MKI). This difference is entirely due to the longer (and more secure) MAC provided by TLS and DTLS. This section provides a comparison of packet sizes for G.729 and G.711 codecs using 20ms packets. Comparisons are provided for unencrypted packets, SRTP without MKI, SRTP with MKI, DTLS and DTLS in SRTP compatibility mode. +-----------------------------------+-------------+---------------+ | packet | size(bytes) | bitrate(kb/s) | +-----------------------------------+-------------+---------------+ | G.729 | 60 | 24.0 | | G.729 + SRTP | 64 | 25.6 | | G.729 + SRTP w/ MKI | 68 | 27.2 | | G.729 + DTLS (SRTP-compatibility) | 70 | 28.0 | | G.729 + DTLS | 98 | 39.2 | | G.711 | 200 | 80.0 | | G.711 + SRTP | 204 | 81.6 | | G.711 + SRTP w/ MKI | 208 | 83.2 | | G.711 + DTLS (SRTP-compatibility) | 210 | 84.0 | | G.711 + DTLS | 238 | 95.2 | +-----------------------------------+-------------+---------------+ Note that DTLS with the SRTP-compatibility attributes is 1.09 times the bandwidth of SRTP (without MKI) for G.729 and 1.03 times the bandwidth of SRTP with MKI. It is 1.03 times the bandwidth of SRTP with MKI for G.711 and 1.01 times the bandwidth of SRTP with MKI. 7. Security Considerations Tschofenig & Rescorla Expires August 29, 2006 [Page 6]
Internet-Draft RTP over DTLS February 2006 Because RTP/DTLS runs over DTLS, which is based on TLS, which has seen extensive security analysis, we can have fairly high confidence in the security of the system once the channel is established. Similarly, because DTLS incorporates a handshake mechanism, there is no need to provide for confidentiality of the handshake channel. All that is necessary is to ensure that the communicating peers' certificates are correct. The standard TLS/DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [2] 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 with well-defined names; a situation which does not usually occur in the VoIP context. An alternative strategy can be used where the certificates are self- signed. When using this approach, the endpoint that acts as a client MUST have a way to verify that the server's certificate is correct and vice-versa. An approach to address this using the Session Initiation Protocol (SIP) [11] and the Session Description Protocol (SDP) [7] is described in SIP for DTLS Media [17] and SDP for DTLS [18] 8. IANA Considerations This specification does not require any IANA actions. 9. Acknowledgments Jason Fischl and Cullen Jennings contributed substantial text and comments to this document. This document benefitted from discussions with Francois Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew, and David Oran. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation Tschofenig & Rescorla Expires August 29, 2006 [Page 7]
Internet-Draft RTP over DTLS February 2006 List (CRL) Profile", RFC 3280, April 2002. [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", draft-rescorla-dtls-05 (work in progress), June 2005. 10.2. Informational References [5] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. [6] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions", draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005. [7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [8] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [10] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [11] 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. [12] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003. [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [14] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites for TLS and DTLS", draft-modadugu-tls-ctr-00 (work in progress), October 2005. Tschofenig & Rescorla Expires August 29, 2006 [Page 8]
Internet-Draft RTP over DTLS February 2006 [15] Modadugu, N. and E. Rescorla, "Extensions for DTLS in Low Bandwidth Environments", draft-modadugu-dtls-short-00 (work in progress), October 2005. [16] Rescorla, E., "TLS Partial Encryption Mode", draft-rescorla-tls-partial-00 (work in progress), January 2006. [17] Fischl, J., Tschofenig, H., and E. Rescorla, "Session Initiation Protocol (SIP) for Media Over Transport Layer Security (TLS)", February 2006. [18] Fischl, J. and H. Tschofenig, "Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS)", draft-fischl-mmusic-sdp-dtls-00 (work in progress), February 2006. Appendix A. Packet Header Formats The subsequent figures illustrate the different packet formats and the size of the headers. A.1. SRTP Packet Format This figure shows the SRTP packet format layout. Tschofenig & Rescorla Expires August 29, 2006 [Page 9]
Internet-Draft RTP over DTLS February 2006 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | IHL | TOS | Length | 4 +---------------------------------------------------------------| | Identification | Flags | Fragment Offset | 8 +---------------------------------------------------------------| | TTL | Protocol | Header Checksum | 12 +---------------------------------------------------------------| | Source IP | 16 +---------------------------------------------------------------| | Destination IP | 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | 24 +---------------------------------------------------------------| | Length | Checksum | 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | 32 +---------------------------------------------------------------| | timestamp | 36 +---------------------------------------------------------------| | synchronization source (SSRC) identifier | 40 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | | G.729 Payload (20ms) | 44| |-------------------------------+-------------------------------+ | | G.729 Cont. | 48| |-------------------------------+-------------------------------+ | | G.729 Cont. | 52| |-------------------------------+-------------------------------+ | | G.729 Cont. | 56| |-------------------------------+-------------------------------+ | | G.729 Cont. | 60| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | SRTP MKI (OPTIONAL) | 64| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | authentication tag (RECOMMENDED) | 68| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.2. DTLS/RTP Packet Format This figure shows the DTLS/RTP packet format layout. 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | IHL | TOS | Length | 4 +---------------------------------------------------------------| | Identification | Flags | Fragment Offset | 8 +---------------------------------------------------------------| | TTL | Protocol | Header Checksum | 12 +---------------------------------------------------------------| Tschofenig & Rescorla Expires August 29, 2006 [Page 10]
Internet-Draft RTP over DTLS February 2006 | Source IP | 16 +---------------------------------------------------------------| | Destination IP | 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | 24 +---------------------------------------------------------------| | Length | Checksum | 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Version | epoch-low | 32 +---------------------------------------------------------------| | epoc-hi | seq-low-24 | 36 +---------------------------------------------------------------| | seq-hi-24 | length-low | 40 +---------------------------------------------------------------| | length-hi | xxxxxxxxxx NO BYTES HERE xxxxxxxxxxxxxxxxxxxx 41 |---------------------------------------------------------------| | |V=2|P|X| CC |M| PT | sequence number | 45| +---------------------------------------------------------------| | | timestamp | 49| +---------------------------------------------------------------| | | synchronization source (SSRC) identifier | 53| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | G.729 Payload (20ms) | 57| |-------------------------------+-------------------------------+ | | G.729 Cont. | 61| |-------------------------------+-------------------------------+ | | G.729 Cont. | 65| |-------------------------------+-------------------------------+ | | G.729 Cont. | 69| |-------------------------------+-------------------------------+ | | G.729 Cont. | 73 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | | HMAC-SHA1 | 77| |-------------------------------+-------------------------------+ | | HMAC-SHA1 (cont) | 81| |-------------------------------+-------------------------------+ | | HMAC-SHA1 (cont) | 85| |-------------------------------+-------------------------------+ | | HMAC-SHA1 (cont) | 89| |-------------------------------+-------------------------------+ | | HMAC-SHA1 (cont) | 93| |-------------------------------+-------------------------------+ | | PAD | 97| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PAD LEN | XXX NO BYTES | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tschofenig & Rescorla Expires August 29, 2006 [Page 11]
Internet-Draft RTP over DTLS February 2006 A.3. DTLS/RTP Packet Format in SRTP-compatibility mode This figure shows the DTLS/RTP packet with low bandwidth extensions. 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | IHL | TOS | Length | 4 +---------------------------------------------------------------| | Identification | Flags | Fragment Offset | 8 +---------------------------------------------------------------| | TTL | Protocol | Header Checksum | 12 +---------------------------------------------------------------| | Source IP | 16 +---------------------------------------------------------------| | Destination IP | 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | 24 +---------------------------------------------------------------| | Length | Checksum | 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | 32 +---------------------------------------------------------------| | timestamp | 36 +---------------------------------------------------------------| | synchronization source (SSRC) identifier | 40 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | | G.729 Payload (20ms) | 44| |-------------------------------+-------------------------------+ | | G.729 Cont. | 48| |-------------------------------+-------------------------------+ | | G.729 Cont. | 52| |-------------------------------+-------------------------------+ | | G.729 Cont. | 56| |-------------------------------+-------------------------------+ | | G.729 Cont. | 60| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | SRTP MKI (OPTIONAL) | 64| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | HMAC-SHA1 | 68| |-------------------------------+-------------------------------+ | | HMAC-SHA1 (cont) | 72| |-------------------------------+-------------------------------+ | | HMAC-SHA1 (cont) | 74| |-------------------------------+ Tschofenig & Rescorla Expires August 29, 2006 [Page 12]
Internet-Draft RTP over DTLS February 2006 Authors' Addresses Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Eric Rescorla Network Resonance 2483 E. Bayshore #212 Palo Alto, CA 94303 USA Email: ekr@networkresonance.com Tschofenig & Rescorla Expires August 29, 2006 [Page 13]
Internet-Draft RTP over DTLS February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Tschofenig & Rescorla Expires August 29, 2006 [Page 14]