One document matched: draft-ietf-avtcore-srtp-encrypted-header-ext-02.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 bigaes SYSTEM
'reference.RFC.6188.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 seedsrtp SYSTEM
'reference.RFC.5669.xml'>
<!ENTITY ntptimestamp SYSTEM
'reference.RFC.6051.xml'>
<!ENTITY audiolevel SYSTEM
'reference.RFC.6464.xml'>
<!ENTITY slic SYSTEM
'reference.RFC.6465.xml'>
]>
<?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-02' updates='3711'>
<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>
<t>This document updates RFC 3711, the Secure Real-Time Transport Protocol
specification, to require that all SRTP encryption transforms
specify how RTP header extensions are to be encrypted.</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 specifications
(<xref target='RFC6464' />
and <xref target='RFC6465' />) carry information about
per-packet sound levels of the media data carried in the RTP payload,
and exposing this to an eavesdropper is 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>
<t>The mechanism defined by this document encrypts packets' header
extensions using the same cryptographic algorithms and parameters as
are used to encrypt the packets' RTP payloads. This document
defines how this is done for the encryption transforms defined in
<xref target='RFC3711' />, <xref target='RFC5669' />, and
<xref target='RFC6188' />, the SRTP encryption transforms defined by
standards-track IETF documents at the time of this writing. It also updates
<xref target='RFC3711' />, to indicate that specifications of future
SRTP encryption transforms must define how header extension
encryption is to be performed.</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>Encrypted extension headers are only carried in packets encrypted
using the <xref target='RFC3711'>Secure Real-Time Transport Protocol</xref>.
To encrypt (or decrypt) encrypted extension headers, an SRTP
participant first uses the SRTP Key Derivation Algorithm, specified
in Section 4.3.1 of <xref target='RFC3711' />, to generate header
encryption and header salting keys, using the same pseudo-random
function family as are used for the key derivation for the SRTP
session. These keys are derived as follows:
<list style="symbols">
<t>k_he (SRTP header encryption): <![CDATA[<label>]]> = 0x06, n=n_e.</t>
<t>k_hs (SRTP header salting key): <![CDATA[<label>]]> = 0x07, n=n_s.</t>
</list>
where n_e and n_s are from the cryptographic context: the same size
encryption key and salting key are used as are used for the SRTP payload.
(Note that since RTP headers, including extension headers,
are authenticated in SRTP, no new authentication key is needed for
extension headers.)
</t>
<t>A header extension keystream is generated for each packet
containing encrypted header extension elements.
The details of how this header extension keystream is
generated depend on the encryption transform that is used for the
SRTP packet. For encryption transforms that have been standardized
as of the publication of this document, see
<xref target='existing-transforms'/>; for requirements for new
transforms, see <xref target='new-transforms'/>.
</t>
<t>Once the header extension keystream is generated, 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. 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 participant bitwise-ANDs the encryption mask with the keystream to
produce a masked keystream. It then bitwise exclusive-ors the
header extension with this masked keystream to produce the
ciphertext version of the header extension.
(Thus, octets indicated as all-bits-1 in the encrypted mask are encrypted,
whereas those indicated as all-bits-0 are not.)</t>
<t>The header extension encryption process does not include the
"defined by profile" or "length" fields of the header extension,
only the field that <xref target='RFC3550'/> Section 5.3.1 calls
"header extension" proper, starting with the first
<xref target='RFC5285'/> ID and length. Thus, both the encryption
mask and the keystream begin at this point.</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, and the
receiver MUST NOT take any actions based on decrypted headers that
could affect the security or proper functioning of the system, prior to
validating the 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, an encrypted
<xref target='RFC6464'>audio level
indication</xref> with ID 3, and an
encrypted <xref target='RFC6051'>NTP Timestamp</xref> with ID 4,
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=7 | SMTPE timecode (long form) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE timecode (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMTPE (cont'd)| ID=2 | len=2 | toffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| toffset (ct'd)| ID=3 | len=0 | audio level | ID=4 | len=6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (Variant B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (Variant B, cont.) | 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|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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 header extension elements, element
headers, and header extension padding are set to all-0 values.</t>
</section>
<section title='Header Extension Keystream Generation for Existing
Encryption Transforms' anchor='existing-transforms'>
<t>For the <xref target='RFC3711'>AES-CM and AES-f8 transforms</xref>,
the <xref target='RFC5669'>SEED-CTR transform</xref>,
and the <xref target='RFC6188'>AES_192_CM and AES_256_CM
transforms</xref>,
the header extension keystream SHALL be generated for each packet
containing encrypted header extension elements, using the same encryption
transform and Initialization Vector (IV) as is used for that packet's SRTP
payload, except that the SRTP encryption and salting keys k_e and
k_s are replaced by the SRTP header encryption and header salting
keys k_he and k_hs, defined above, respectively.</t>
<t>For the <xref target='RFC5669'>SEED-CCM and SEED-GCM transforms</xref>,
the header extension keystream SHALL be
generated using the algorithm specified above for the
SEED-CTR algorithm. (Because the AEAD transform used on the payload
in these algorithms includes the RTP header, including the RTP
header extension, in its Associated Authenticated Data (AAD),
counter-mode encryption for the header extension is believed to be
of equivalent cryptographic strength to the CCM and GCM transforms.)</t>
<t>For the <xref target='RFC3711'>NULL encryption transform</xref>,
the header extension keystream SHALL be all-zero.</t>
</section>
<section title='Header Extension Keystream Generation for Future
Encryption Transforms' anchor='new-transforms'>
<t>When new SRTP encryption transforms are defined, this document
updates <xref target='RFC3711'/> as follows: in addition
to the rules specified in Section 6 of RFC 3711, the standard track
RFC defining the new transform MUST specify how the encryption
transform is to be used with header extension encryption.</t>
<t>It is RECOMMENDED that new transformations follow the same
mechanisms as are defined in <xref target='existing-transforms'/>,
if these are applicable and are believed to be cryptographically
adequate for the transform in question.</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.
<xref target='encrypt_grammar' /> gives a
formal <xref target='RFC5234'>Augmented Backus-Naur Form (ABNF)</xref>
showing this grammar extension.</t>
<figure anchor="encrypt_grammar" title="Syntax of the "encrypt"
extensionattributes">
<artwork>
enc-extensionattributes = extensionname [SP extensionattributes]
extensionattributes /= enc-extensionattributes
</artwork>
</figure>
<t>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>
<t>The extmap SDP attribute is defined in <xref target='RFC5285' /> as
being either a session or media attribute. If the extmap for an
encrypted header extension is specified as a media attribute, it
MUST only be specified for media which use SRTP-based RTP profiles.
If such an extmap is specified as a session attribute, there MUST be
at least one media in the SDP session which uses an SRTP-based RTP
profile; the session-level extmap applies to all the SRTP-based
media in the session, and MUST be ignored for all other (non-SRTP or
non-RTP) media.</t>
<t>The "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be
recursively applied to itself.</t>
<section title='Backward compatibility'>
<t>Following the procedures in <xref target='RFC5285' />, an SDP
endpoint which does not understand the
"urn:ietf:params:rtp-hdrext:encrypt" extension URI will ignore the
extension, and (for SDP offer/answer) negotiate not to use it.</t>
<t>In a negotiated session (whether using offer/answer or some other
means), best-effort encryption of a header extension element is
possible: an endpoint MAY offer the same header extension element
both encrypted and unencrypted. Receivers which understand header
extension encryption SHOULD choose the encrypted form and mark the
unencrypted form "inactive", unless they have an explicit reason to
prefer the unencrypted form. (Note that, as always, users of
best-effort encryption MUST be cautious of bid-down attacks, where a
man-in-the-middle attacker removes a higher-security option, forcing
endpoints to negotiate a lower-security one. Appropriate
countermeasures depend on the signaling protocol in use, but users
can ensure, for example, that signaling is integrity-protected.)</t>
</section>
</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 present in
for one-byte-header form of header extension elements (0xBEDE), so
these limitations do not apply in that case.</t>
<t>This mechanism cannot protect RTP header extensions which do not
use the mechanism defined in <xref target='RFC5285' />.</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>
<t>If a middlebox does not have access to the SRTP authentication
keys, it has no way to verify the authenticity of unencrypted RTP
header extension elements (or the unencrypted RTP header), even
though it can monitor them. Therefore, such middleboxes MUST treat
such headers as untrusted and potentially generated by an attacker,
in the same way as unauthenticated traffic. (This does not mean
that middleboxes cannot view and interpret such traffic, of course,
only that appropriate skepticism needs to be maintained about the
results of such interpretation.).</t>
<t>There is no mechanism defined to protect header extensions with
different algorithms or encryption keys than are used to protect the
RTP payloads. In particular, it is not possible to provide
confidentiality for a header extension while leaving the payload in
cleartext.</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>
<section title='Acknowledgments'>
<t>Thanks to Roni Even, Kevin Igoe, David McGrew, Magnus Westerlund, David Singer, Qin
Wu, and Felix Wyss for their comments and suggestions in the
development of this specification.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&abnf;
&hdrext;
&srtp;
&rtp;
&bigaes;
&seedsrtp;
</references>
<references title='Informative References'>
&toffset;
&audiolevel;
&sdesc;
&slic;
&timecode;
&ntptimestamp;
</references>
<section title='Test Vectors'>
<section title='Key derivation test vectors' anchor='kdatestvect'>
<t>This section provides test data for the header extension key derivation
function, using AES-128 in Counter Mode. (The algorithms and keys
used are the same as those for the the test vectors in Appendix B.3 of
<xref target='RFC3711' />.)</t>
<t>The inputs to the key derivation function are the 16 octet master key
and the 14 octet master salt:
<list style='empty'>
<t>master key: E1F97A0D3E018BE0D64FA32C06DE4139</t>
<t>master salt: 0EC675AD498AFEEBB6960B3AABE6</t>
</list>
</t>
<t>Following <xref target='RFC3711'/>, the input block for
AES-CM is generated by exclusive-oring the master salt with the
concatenation of the encryption key label 0x06 with (index DIV kdr),
then padding on the right with two null octets (which implements the
multiply-by-2^16 operation, see Section 4.3.3
of <xref target='RFC3711' />). The resulting value
is then AES-CM- encrypted using the master key to get the cipher
key.</t>
<figure>
<artwork>
index DIV kdr: 000000000000
label: 06
master salt: 0EC675AD498AFEEBB6960B3AABE6
--------------------------------------------------
xor: 0EC675AD498AFEEDB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input)
hdr. cipher key: 549752054D6FB708622C4A2E596A1B93 (AES-CM output)
</artwork>
</figure>
<t>Next, we show how the cipher salt is generated. The input block for
AES-CM is generated by exclusive-oring the master salt with the
concatenation of the encryption salt label. That value is padded and
encrypted as above.</t>
<figure>
<artwork>
index DIV kdr: 000000000000
label: 07
master salt: 0EC675AD498AFEEBB6960B3AABE6
--------------------------------------------------
xor: 0EC675AD498AFEECB6960B3AABE6 (x, PRF input)
x*2^16: 0EC675AD498AFEECB6960B3AABE60000 (AES-CM input)
AB01818174C40D39A3781F7C2D270733 (AES-CM ouptut)
hdr. cipher salt: AB01818174C40D39A3781F7C2D27
</artwork>
</figure>
</section>
<section title='Header Encryption Test Vectors using AES-CM'>
<t>This section provides test vectors for the encryption of a header
extension, using the AES_CM cryptographic transform.</t>
<t>The header extension is encrypted using the header cipher
key and header cipher salt computed in <xref target='kdatestvect'
/>. The header extension is carried in an SRTP-encrypted RTP packet
with SSRC 0xCAFEBABE, sequence number 0x1234, and an all-zero
rollover counter.</t>
<figure>
<artwork>
Session Key: 549752054D6FB708622C4A2E596A1B93
Session Salt: AB01818174C40D39A3781F7C2D27
SSRC: CAFEBABE
Rollover Counter: 00000000
Sequence Number: 1234
----------------------------------------------
Init. Counter: AB018181BE3AB787A3781F7C3F130000
</artwork>
</figure>
<t>The SRTP session was negotiated to indicate that header extension
ID values 1, 3 and 4 are encrypted.</t>
<t>In hexadecimal, the header extension being encrypted is (spaces
added to show the internal structure of the header extension):</t>
<figure>
<artwork>
17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00
</artwork>
</figure>
<t>This header extension is 24 bytes long. (Its values are intended
to represent plausible values of the header extension elements shown
in <xref target='example' />, but their specific meaning is not
important for the example.) The header extension "defined by
profile" and "length" fields, which in this case are BEDE 0006
in hexadecimal, are not included in the encryption process.</t>
<t>In hexadecimal, the corresponding encryption mask selecting the
bodies of header extensions 1, 2, and 4 (corresponding to the mask
in <xref target='mask' />) is:</t>
<figure>
<artwork>
00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00
</artwork>
</figure>
<t>Finally, we compute the keystream from the session key and the
initial counter, apply the mask to the keystream, and then xor the
keystream with the plaintext:</t>
<figure>
<artwork>
Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A
FC0D933AE7ED6CC8
Mask (Hex): 00FFFFFFFFFFFFFFFF0000000000FF00
FFFFFFFFFFFFFF00
Masked keystream: 0019C8E1D481C7795400000000001B00
FC0D933AE7ED6C00
Plaintext: 17414273A475262748220000C8308E46
55996386B395FB00
Ciphertext: 17588A9270F4E15E1C220000C8309546
A994F0BC54789700
</artwork>
</figure>
</section>
</section>
<!--
<section title='Open issues'>
<t><list style='symbols'>
<t></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-ietf-avtcore -01'>
<t>Made the draft update RFC 3711, and added a section specifying that
all future SRTP encryption transforms must specify how header
extension encryption is to be done.</t>
<t>Explicitly distinguished the processing of existing encryption
transforms from future ones.</t>
<t>Clarified description of the process by which the encryption mask
is applied, and that encryption does not apply to the header
extension "defined by profile" or "length" fields.</t>
<t>Defined how header extension encryption is to be done
with the SEED algorithms defined in RFC 5669, and with the NULL
algorithm.</t>
<t>Added ABNF grammar for the SDP syntax.</t>
<t>Clarified that header extension encryption must not be applied to
itself.</t>
<t>Expanded discussion of bid-down attacks.</t>
<t>Pointed out that this mechanism can't protect non-RFC5285 header
extensions, and that there's no way to give different protection to
header extensions than to payloads.</t>
<t>Updated references to now-published RFCs.</t>
<t>Editorial clarifications.</t>
<t>Added Magnus Westerlund to the Acknowledgments.</t>
</section>
<section title='Changes from draft-ietf-avtcore -00'>
<t>Clarified usage of Key Derivation Algorithm</t>
<t>Provided non-normative guidance for how to use this mechanism with
Authenticated Encryption with Associated Data (AEAD) transforms.</t>
<t>Corrected SMPTE Timecode header extension element in example header
extension (it's eight bytes, not sixteen). Added an NTP timestamp
to the example to fill it back out to original size.</t>
<t>Specified applicability of the extmap attribute if it's specified
as a session-level attribute.</t>
<t>Added description of backward compatibility, including a
description of how you can negotiate best-effort encryption.</t>
<t>Added a note to the security considerations about the dangers for
middleboxes observing unencrypted headers (both header extension
elements and RTP headers) without being able to verify the
authentication keys.</t>
<t>Added test vectors.</t>
<t>Added acknowledgments section.</t>
</section>
<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:35:19 |