One document matched: draft-ietf-avtcore-srtp-encrypted-header-ext-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY abnf SYSTEM
'reference.RFC.5234.xml'>
<!ENTITY hdrext SYSTEM
'reference.RFC.5285.xml'>
<!ENTITY srtp SYSTEM
'reference.RFC.3711.xml'>
<!ENTITY rfc2119 SYSTEM
'reference.RFC.2119.xml'>
<!ENTITY rtp SYSTEM
'reference.RFC.3550.xml'>
<!ENTITY sdesc SYSTEM
'reference.RFC.4568.xml'>
<!ENTITY toffset SYSTEM
'reference.RFC.5450.xml'>
<!ENTITY timecode SYSTEM
'reference.RFC.5484.xml'>
<!ENTITY audiolevel SYSTEM
'reference.I-D.ietf-avtext-client-to-mixer-audio-level.xml'>
<!ENTITY slic SYSTEM
'reference.I-D.ietf-avtext-mixer-to-client-audio-level.xml'>
<!ENTITY aesgcm SYSTEM
'reference.I-D.ietf-avt-srtp-aes-gcm'>
]>
<?rfc toc="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category='std' ipr='trust200902' docName='draft-ietf-avtcore-srtp-encrypted-header-ext-00'>
<front>
<title abbrev='Encrypted SRTP Header Extensions'>
Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)
</title>
<author initials='J.' surname='Lennox'
fullname='Jonathan Lennox'>
<organization abbrev='Vidyo'>
Vidyo, Inc.
</organization>
<address>
<postal>
<street>433 Hackensack Avenue</street>
<street>Seventh Floor</street>
<city>Hackensack</city> <region>NJ</region>
<code>07601</code>
<country>US</country>
</postal>
<email>jonathan@vidyo.com</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>AVTCORE</workgroup>
<keyword>real-time transport protocol</keyword>
<keyword>rtp</keyword>
<keyword>header extensions</keyword>
<keyword>security</keyword>
<abstract>
<t>The Secure Real-Time Transport Protocol (SRTP) provides
authentication, but not encryption, of the headers of
Real-Time Transport Protocol (RTP) packets. However,
RTP header extensions may carry sensitive information for which
participants in multimedia sessions want confidentiality. This document
provides a mechanism, extending the mechanisms of SRTP, to
selectively encrypt RTP header extensions in SRTP.</t>
</abstract>
</front>
<middle>
<section title='Introduction' anchor='introduction'>
<t>The <xref target='RFC3711'>Secure Real-Time Transport Protocol</xref>
specification provides confidentiality, message authentication, and
replay protection for multimedia payloads sent using of the
<xref target='RFC3550'>Real-Time Protocol (RTP)</xref>. However, in order
to preserve RTP header compression efficiency, SRTP provides only
authentication and replay protection for the headers of RTP packets, not
confidentiality.
</t>
<t>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.</t>
<t>However, this is not necessarily true for information carried in
RTP header extensions. A number of recent proposals for header extensions
using the <xref target='RFC5285'>General Mechanism for RTP Header
Extensions</xref> carry information for which confidentiality could
be desired or essential. Notably, two recent drafts
(<xref target='I-D.ietf-avtext-client-to-mixer-audio-level' />
and <xref target='I-D.ietf-avtext-mixer-to-client-audio-level' />) 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.</t>
<t>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 <xref target='RFC5450'>RTP transmission time offsets</xref>), this
mechanism can be selectively applied to a subset of the header
extension elements carried in an SRTP packet.</t>
</section>
<section title='Terminology'>
<t>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 <xref
target='RFC2119'>RFC 2119</xref> and indicate requirement levels for
compliant implementations.</t>
</section>
<section title='Encryption Mechanism' anchor='mechanism'>
<t>Encrypted header extension elements are carried in the same manner
as non-encrypted header extension elements, as defined by
<xref target='RFC5285' />. The (one- or two-byte) header of the
extension elements is not encrypted, nor is any of the header extension padding. If
multiple different header 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.</t>
<t>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 corresponding 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
<![CDATA[<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.)</t>
<t>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 entire payload of each header extension element that is
encrypted. It does not include any non-encrypted header extension
elements, any extension element headers, or any padding octets.
The encryption mask has all-bits-1 octets (i.e., hexadecimal 0xff) for
header extension octets which are to be encrypted, and all-bits-0
octets for header extension octets which are not to
be.</t>
<t>For those octets indicated in the encryption mask, the SRTP
participant bitwise exclusive-ors the header extension with the
keystream to produce the ciphertext version of the header extension.
Those octets not indicated in the encryption mask are
left unmodified.
Thus, conceptually, the encryption mask is logically ANDed
with the keystream to produce a masked keystream.
The sender and receiver
MUST use the same encryption mask. The set of extension elements to be
encrypted is communicated between the sender and the receiver using the
signaling mechanisms described in <xref target='signaling' />.</t>
<t>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.</t>
<section title='Example Encryption Mask' anchor='example'>
<t>If a sender wished to send a header extension containing an encrypted
<xref target='RFC5484'>SMPTE timecode</xref> with ID 1, a
plaintext <xref target='RFC5450'>transmission time offset</xref>
with ID 2, and an encrypted
<xref target='I-D.ietf-avtext-client-to-mixer-audio-level'>audio level
indication</xref> with ID 3, the plaintext RTP header
extension might look like this:</t>
<figure anchor='plaintext'>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=1 | len=15| SMTPE timecode (long form) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE (cont'd)| ID=2 | len=2 | toffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| toffset (ct'd)| ID=3 | len=0 | audio level | padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The corresponding encryption mask would then be:</t>
<figure anchor='mask'>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>In the mask, the octets corresponding to the payloads of the
encrypted header extension elements are set to all-1 values, and
octets corresponding to non-encrypted elements, element headers, and
header extension padding are set to all-0 values.</t>
</section>
</section>
<section title='Signaling (Setup) Information' anchor='signaling'>
<t>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 <xref target='RFC5484'>SMPTE timecodes</xref>, while
simultaneously signaling
plaintext <xref target='RFC5450'>transmission time
offsets</xref>, an SDP document could contain (line breaks added for
formatting):</t>
<figure anchor='exthdr'>
<artwork>
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
</artwork>
</figure>
<t>This example uses <xref target='RFC4568'>SDP Security
Descriptions</xref> for SRTP keying, but this is merely for
illustration; any SRTP keying mechanism to establish session keys
will work.</t>
</section>
<section title='Security Considerations' anchor='security'>
<t>The security properties of header extension elements protected by the
mechanism in this document
are equivalent to those for SRTP payloads.</t>
<t>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.</t>
<t>For the two-byte-header form of header extension elements (0x100x),
this mechanism does not provide any protection to zero-length header
extension elements (for which their presence or absence is the only
information they carry). It also does not provide any protection
for the two-byte-headers' app bits (field 256, the lowest four bits of the
"defined by profile" field). Neither of these features are used in
for one-byte-header form of header extension elements (0xBEDE), so
these limitations do not apply in that case.</t>
<t>This document does not specify the circumstances in which extension
header encryption should be used. Documents defining specific
header extension elements should provide guidance on when encryption
is appropriate for these elements.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>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:</t>
<t>
<list style='hanging'>
<t hangText='Extension URI:'>urn:ietf:params:rtp-hdrext:encrypt</t>
<t hangText='Description:'>Encrypted extension header element</t>
<t hangText='Contact:'>jonathan@vidyo.com</t>
<t hangText='Reference:'>RFC &rfc.number;</t>
</list>
</t>
<t>(Note to the RFC-Editor: please replace "&rfc.number;" with the
number of this document prior to publication as an RFC.)</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
<!-- &abnf; -->
&hdrext;
&srtp;
&rtp;
</references>
<references title='Informative References'>
&toffset;
&audiolevel;
&sdesc;
&slic;
&timecode;
&aesgcm;
</references>
<section title='Test Vectors'>
<t>TODO</t>
</section>
<section title='Open issues'>
<t><list style='symbols'>
<t>It is not clear how best to create the keystream for extension
headers carried in SRTP packets protected with Authenticated Encryption
with Associated Data (AEAD) cryptographic transforms, such as
<xref target='I-D.ietf-avt-srtp-aes-gcm'>AES_GCM and AES_CCM</xref>.
Header extensions are already protected as ancillary data
by AEAD mechanisms, and the mechanism defined in this document does
not have any location to insert an additional authentication tag.</t>
</list></t>
</section>
<section title='Changes From Earlier Versions'>
<t>Note to the RFC-Editor: please remove this section prior to publication
as an RFC.</t>
<section title='Changes from draft-lennox-avtcore -00'>
<t><list style='symbols'>
<t>Published as working group item.</t>
<t>Added discussion of limitations when used with the two-byte-header
form of header extension elements.</t>
<t>Added open issue about how to use this mechanism with Authenticated Encryption
with Associated Data (AEAD) transforms.</t>
<t>Updated references.</t>
</list></t>
</section>
<section title='Changes from draft-lennox-avt -02'>
<t><list style='symbols'>
<t>Retargeted at AVTCORE working group.</t>
<t>Updated references.</t>
</list></t>
</section>
<section title='Changes From Individual Submission Draft -01'>
<t><list style='symbols'>
<t>Minor editorial changes.</t>
</list></t>
</section>
<section title='Changes From Individual Submission Draft -00'>
<t><list style='symbols'>
<t>Clarified description of encryption mask creation.</t>
<t>Added example encryption mask.</t>
<t>Editorial changes.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:36:19 |