MMUSIC J. Lennox
Internet-Draft Vidyo
Intended status: Standards Track October 19, 2009
Expires: April 22, 2010
Encryption of Header Extensions in the Secure Real-Time Transport
Protocol (SRTP)
draft-lennox-avt-srtp-encrypted-extension-headers-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 April 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The Secure Real-Time Transport Protocol (SRTP) provides
authentication, but not encryption, of the headers of Real-Time
Lennox Expires April 22, 2010 [Page 1]
Internet-Draft Encrypted SRTP Header Extensions October 2009
Transport Protocol (RTP) packets. However, RTP header extensions may
carry sensitive information for which participants in multimedia want
confidentiality. This document provides a mechanism, extending the
mechanisms of SRTP, to selectively encrypt RTP header extensions in
SRTP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encryption Mechanism . . . . . . . . . . . . . . . . . . . . . 3
4. Signaling (Setup) Information . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Lennox Expires April 22, 2010 [Page 2]
Internet-Draft Encrypted SRTP Header Extensions October 2009
1. Introduction
The Secure Real-Time Transport Protocol [RFC3711] specification
provides confidentiality, message authentication, and replay
protection for multimedia payloads sent using of the Real-Time
Protocol (RTP) [RFC3550]. However, in order to preserve RTP header
compression efficiency, SRTP provides only authentication and replay
protection for the headers of RTP packets, not confidentiality.
For the standard portions of an RTP header, this does not normally
present a problem, as the information carried in an RTP header does
not provide much information beyond that which an attacker could
infer by observing the size and timing of RTP packets. Thus, there
is little need for confidentiality of the header information.
However, this is not necessarily true for information carried in RTP
header extensions. A number of recent proposals for header
extensions using the General Mechanism for RTP Header Extensions
[RFC5285] carry information for which confidentiality could be
desired or essential. Notably, two recent drafts
([I-D.lennox-avt-rtp-audio-level-exthdr] and [I-D.ivov-avt-slic])
carry information about per-packet sound levels of the media data
carried in the RTP payload, and exposing this to an eavesdropper may
be unacceptable in many circumstances.
This document, therefore, defines a mechanism by which encryption can
be applied to RTP header extensions when they are transported using
SRTP. As an RTP sender may wish some extension information to be
sent in the clear (for example, it may be useful for a network
monitoring device to be aware of RTP transmission time offsets
[RFC5450]), this mechanism can be selectively applied to a subset of
the header extension elements carried in an SRTP packet.
2. Terminology
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 RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations.
3. Encryption Mechanism
Encrypted header extension elements are carried in the same manner as
non-encrypted header extension elements, as defined by [RFC5285].
The (one- or two-byte) header of the extension elements is not
encrypted, nor is any padding. If multiple different header
Lennox Expires April 22, 2010 [Page 3]
Internet-Draft Encrypted SRTP Header Extensions October 2009
extension elements are being encrypted, they have separate element
identifier values, just as they would if they were not encrypted;
similarly, encrypted and non-encrypted header extension elements have
separate identifier values.
To encrypt (or decrypt) an encrypted extension header, an SRTP
participant first generates a keystream for the SRTP extension
header. This keystream is generated in the same manner as the
encryption keystream for the corersponding SRTP payload, except the
the SRTP encryption and salting keys k_e and k_s are replaced by the
keys k_he and k_hs, respectively. The keys k_he and k_hs are
computed in the same manner as k_e and k_s, except that the <label>
values used are 0x06 for k_he and and 0x07 for k_hs. (Note that
since RTP headers, including extension headers, are authenticated in
SRTP, no new authentication key is needed for extension headers.
The SRTP participant then computes an encryption mask for the header
extension, identifying the portions of the header extension that are,
or are to be, encrypted. This encryption mask corresponds to the
payloads of those header extension elements that are encrypted. It
does not include any non-encrypted header extension elements, any
extension element headers, or any padding octets.
For those octets indicated in the encryption mask, the SRTP
participant bitwise exclusive-ors the header extension with the
keystream. Those octets not indicated in the encryption mask are
left unmodified.
The SRTP authentication tag is computed across the encrypted header
extension, i.e., the data that is actually transmitted on the wire.
Thus, header extension encryption MUST be done before the
authentication tag is computed, and authentication tag validation
MUST be done on the encrypted header extensions. For receivers,
header extension decryption SHOULD be done only after the receiver
has validated the packet's message authentication tag.
4. Signaling (Setup) Information
Encrypted header extension elements are signaled in the SDP extmap
attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt",
followed by the URI of the header extension element being encrypted
as well as any extensionattributes that extension normally takes.
Thus, for example, to signal an SRTP session using encrypted SMPTE
timecodes [RFC5484], while simultaneously signaling plaintext
transmission time offsets [RFC5450], an SDP document could contain
(linebreaks added for formatting):
Lennox Expires April 22, 2010 [Page 4]
Internet-Draft Encrypted SRTP Header Extensions October 2009
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
Figure 1
This example uses SDP Security Descriptions [RFC4568] for SRTP
keying, but this is merely for illustration; any SRTP keying
mechanism to establish session keys will work.
5. Security Considerations
The security properties of the mechanism in this document appear to
be equivalent to those for SRTP payloads.
The mechanism defined in this document does not provide
confidentiality about which header extension elements are used for a
given SRTP packet, only for the content of those header extension
elements. This appears to be in the spirit of SRTP itself, which
does not encrypt RTP headers. If this is a concern, an alternate
mechanism would be needed to provide confidentiality.
This document does not specify the circumstances in which extension
header encryption should be used. Documents defining specific
extension header elements should provide guidance on when encryption
is appropriate for these elements.
6. IANA Considerations
This document defines a new extension URI to the RTP Compact Header
Extensions subregistry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:encrypt
Description: Encrypted extension header element
Contact: jonathan@vidyo.com
Reference: RFC XXXX
(Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.)
Lennox Expires April 22, 2010 [Page 5]
Internet-Draft Encrypted SRTP Header Extensions October 2009
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
7.2. Informative References
[I-D.ivov-avt-slic]
Ivov, E. and E. Marocco, "A Real-Time Transport Protocol
(RTP) Extension Header for Mixer-to- client Audio Level
Indication", draft-ivov-avt-slic-01 (work in progress),
October 2009.
[I-D.lennox-avt-rtp-audio-level-exthdr]
Lennox, J., "A Real-Time Transport Protocol (RTP)
Extension Header for Audio Level Indication",
draft-lennox-avt-rtp-audio-level-exthdr-00 (work in
progress), June 2009.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams",
RFC 5484, March 2009.
Appendix A. Test Vectors
TODO
Lennox Expires April 22, 2010 [Page 6]
Internet-Draft Encrypted SRTP Header Extensions October 2009
Author's Address
Jonathan Lennox
Vidyo, Inc.
433 Hackensack Avenue
Sixth Floor
Hackensack, NJ 07601
US
Email: jonathan@vidyo.com
Lennox Expires April 22, 2010 [Page 7]