rfc9335.original   rfc9335.txt 
AVTCORE J. Uberti Internet Engineering Task Force (IETF) J. Uberti
Internet-Draft Clubhouse Request for Comments: 9335
Updates: 3711 (if approved) C. Jennings Updates: 3711 C. Jennings
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: 5 February 2023 S. Garcia Murillo ISSN: 2070-1721 S. Garcia Murillo
Millicast Millicast
4 August 2022 January 2023
Completely Encrypting RTP Header Extensions and Contributing Sources Completely Encrypting RTP Header Extensions and Contributing Sources
draft-ietf-avtcore-cryptex-08
Abstract Abstract
While the Secure Real-time Transport Protocol (SRTP) provides While the Secure Real-time Transport Protocol (SRTP) provides
confidentiality for the contents of a media packet, a significant confidentiality for the contents of a media packet, a significant
amount of metadata is left unprotected, including RTP header amount of metadata is left unprotected, including RTP header
extensions and contributing sources (CSRCs). However, this data can extensions and contributing sources (CSRCs). However, this data can
be moderately sensitive in many applications. While there have been be moderately sensitive in many applications. While there have been
previous attempts to protect this data, they have had limited previous attempts to protect this data, they have had limited
deployment, due to complexity as well as technical limitations. deployment, due to complexity as well as technical limitations.
This document updates RFC 3711, the SRTP specification, and defines This document updates RFC 3711, the SRTP specification, and defines
Cryptex as a new mechanism that completely encrypts header extensions Cryptex as a new mechanism that completely encrypts header extensions
and CSRCs and uses simpler Session Description Protocol (SDP) and CSRCs and uses simpler Session Description Protocol (SDP)
signaling with the goal of facilitating deployment. signaling with the goal of facilitating deployment.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 5 February 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9335.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement
1.2. Previous Solutions . . . . . . . . . . . . . . . . . . . 3 1.2. Previous Solutions
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Goals
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design
4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. SDP Considerations
5. RTP Header Processing . . . . . . . . . . . . . . . . . . . . 6 5. RTP Header Processing
5.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Sending
5.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Receiving
6. Encryption and Decryption . . . . . . . . . . . . . . . . . . 8 6. Encryption and Decryption
6.1. Packet Structure . . . . . . . . . . . . . . . . . . . . 8 6.1. Packet Structure
6.2. Encryption Procedure . . . . . . . . . . . . . . . . . . 8 6.2. Encryption Procedure
6.3. Decryption Procedure . . . . . . . . . . . . . . . . . . 10 6.3. Decryption Procedure
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 7. Backward Compatibility
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations
9.1. SDP cryptex Attribute . . . . . . . . . . . . . . . . . . 12 10. References
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Test Vectors
11.2. Informative References . . . . . . . . . . . . . . . . . 13 A.1. AES-CTR
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 14 A.1.1. RTP Packet with One-Byte Header Extension
A.1. AES-CTR . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.1.2. RTP Packet with Two-Byte Header Extension
A.1.1. RTP Packet with 1-byte header extension . . . . . . . 14 A.1.3. RTP Packet with One-Byte Header Extension and CSRC
A.1.2. RTP Packet with 2-byte header extension . . . . . . . 15 Fields
A.1.3. RTP Packet with 1-byte header extension and CSRC A.1.4. RTP Packet with Two-Byte Header Extension and CSRC
fields . . . . . . . . . . . . . . . . . . . . . . . 16 Fields
A.1.4. RTP Packet with 2-byte header extension and CSRC A.1.5. RTP Packet with Empty One-Byte Header Extension and
fields . . . . . . . . . . . . . . . . . . . . . . . 17 CSRC Fields
A.1.5. RTP Packet with empty 1-byte header extension and CSRC A.1.6. RTP Packet with Empty Two-Byte Header Extension and
fields . . . . . . . . . . . . . . . . . . . . . . . 17 CSRC Fields
A.1.6. RTP Packet with empty 2-byte header extension and CSRC A.2. AES-GCM
fields . . . . . . . . . . . . . . . . . . . . . . . 18 A.2.1. RTP Packet with One-Byte Header Extension
A.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2.2. RTP Packet with Two-Byte Header Extension
A.2.1. RTP Packet with 1-byte header extension . . . . . . . 19 A.2.3. RTP Packet with One-Byte Header Extension and CSRC
A.2.2. RTP Packet with 2-byte header extension . . . . . . . 19 Fields
A.2.3. RTP Packet with 1-byte header extension and CSRC A.2.4. RTP Packet with Two-Byte Header Extension and CSRC
fields . . . . . . . . . . . . . . . . . . . . . . . 20 Fields
A.2.4. RTP Packet with 2-byte header extension and CSRC A.2.5. RTP Packet with Empty One-Byte Header Extension and
fields . . . . . . . . . . . . . . . . . . . . . . . 21 CSRC Fields
A.2.5. RTP Packet with empty 1-byte header extension and CSRC A.2.6. RTP Packet with Empty Two-Byte Header Extension and
fields . . . . . . . . . . . . . . . . . . . . . . . 22 CSRC Fields
A.2.6. RTP Packet with empty 2-byte header extension and CSRC Acknowledgements
fields . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
1.1. Problem Statement 1.1. Problem Statement
The Secure Real-time Transport Protocol (SRTP) [RFC3711] mechanism The Secure Real-time Transport Protocol (SRTP) [RFC3711] mechanism
provides message authentication for the entire RTP packet, but only provides message authentication for the entire RTP packet but only
encrypts the RTP payload. This has not historically been a problem, encrypts the RTP payload. This has not historically been a problem,
as much of the information carried in the header has minimal as much of the information carried in the header has minimal
sensitivity (e.g., RTP timestamp); in addition, certain fields need sensitivity (e.g., RTP timestamp); in addition, certain fields need
to remain as cleartext because they are used for key scheduling to remain as cleartext because they are used for key scheduling
(e.g., RTP SSRC and sequence number). (e.g., RTP synchronization source (SSRC) and sequence number).
However, as noted in [RFC6904], the security requirements can be However, as noted in [RFC6904], the security requirements can be
different for information carried in RTP header extensions, including different for information carried in RTP header extensions, including
the per-packet sound levels defined in [RFC6464] and [RFC6465], which the per-packet sound levels defined in [RFC6464] and [RFC6465], which
are specifically noted as being sensitive in the Security are specifically noted as being sensitive in the Security
Considerations section of those RFCs. Considerations sections of those RFCs.
In addition to the contents of the header extensions, there are now In addition to the contents of the header extensions, there are now
enough header extensions in active use that the header extension enough header extensions in active use that the header extension
identifiers themselves can provide meaningful information in terms of identifiers themselves can provide meaningful information in terms of
determining the identity of the endpoint and/or application. determining the identity of the endpoint and/or application.
Accordingly, these identifiers can be considered a fingerprinting Accordingly, these identifiers can be considered a fingerprinting
issue. issue.
Finally, the CSRCs included in RTP packets can also be sensitive, Finally, the CSRCs included in RTP packets can also be sensitive,
potentially allowing a network eavesdropper to determine who was potentially allowing a network eavesdropper to determine who was
speaking and when during an otherwise secure conference call. speaking and when during an otherwise secure conference call.
1.2. Previous Solutions 1.2. Previous Solutions
Encryption of Header Extensions in SRTP [RFC6904] was proposed in Encryption of Header Extensions in SRTP [RFC6904] was proposed in
2013 as a solution to the problem of unprotected header extension 2013 as a solution to the problem of unprotected header extension
values. However, it has not seen significant adoption, and has a few values. However, it has not seen significant adoption and has a few
technical shortcomings. technical shortcomings.
First, the mechanism is complicated. Since it allows encryption to First, the mechanism is complicated. Since it allows encryption to
be negotiated on a per-extension basis, a fair amount of signaling be negotiated on a per-extension basis, a fair amount of signaling
logic is required. And in the SRTP layer, a somewhat complex logic is required. And in the SRTP layer, a somewhat complex
transform is required to allow only the selected header extension transform is required to allow only the selected header extension
values to be encrypted. One of the most popular SRTP implementations values to be encrypted. One of the most popular SRTP implementations
had a significant bug in this area that was not detected for five had a significant bug in this area that was not detected for five
years. years.
Second, it only protects the header extension values, and not their Second, the mechanism only protects the header extension values and
ids or lengths. It also does not protect the CSRCs. As noted above, not their identifiers or lengths. It also does not protect the
this leaves a fair amount of potentially sensitive information CSRCs. As noted above, this leaves a fair amount of potentially
exposed. sensitive information exposed.
Third, it bloats the header extension space. Because each extension Third, the mechanism bloats the header extension space. Because each
must be offered in both unencrypted and encrypted forms, twice as extension must be offered in both unencrypted and encrypted forms,
many header extensions must be offered, which will in many cases push twice as many header extensions must be offered, which will in many
implementations past the 14-extension limit for the use of one-byte cases push implementations past the 14-extension limit for the use of
extension headers defined in [RFC8285]. Accordingly, implementations one-byte extension headers defined in [RFC8285]. Accordingly, in
will need to use two-byte headers in many cases, which are not many cases, implementations will need to use two-byte headers, which
supported well by some existing implementations. are not supported well by some existing implementations.
Finally, the header extension bloat combined with the need for Finally, the header extension bloat combined with the need for
backwards compatibility results in additional wire overhead. Because backward compatibility results in additional wire overhead. Because
two-byte extension headers may not be handled well by existing two-byte extension headers may not be handled well by existing
implementations, one-byte extension identifiers will need to be used implementations, one-byte extension identifiers will need to be used
for the unencrypted (backwards compatible) forms, and two-byte for for the unencrypted (backward-compatible) forms, and two-byte for the
the encrypted forms. Thus, deployment of [RFC6904] encryption for encrypted forms. Thus, deployment of encryption for header
header extensions will typically result in multiple extra bytes in extensions [RFC6904] will typically result in multiple extra bytes in
each RTP packet, compared to the present situation. each RTP packet, compared to the present situation.
1.3. Goals 1.3. Goals
From the previous analysis, the desired properties of a solution are: From the previous analysis, the desired properties of a solution are:
* Build on existing [RFC3711] SRTP framework (simple to understand) * Built on the existing SRTP framework [RFC3711] (simple to
understand)
* Build on existing [RFC8285] header extension framework (simple to * Built on the existing header extension framework [RFC8285] (simple
implement) to implement)
* Protection of header extension ids, lengths, and values * Protection of header extension identifiers, lengths, and values
* Protection of CSRCs when present * Protection of CSRCs when present
* Simple signaling * Simple signaling
* Simple crypto transform and SRTP interactions * Simple crypto transform and SRTP interactions
* Backward compatible with unencrypted endpoints, if desired * Backward compatibility with unencrypted endpoints, if desired
* Backward compatible with existing RTP tooling
The last point deserves further discussion. While considering * Backward compatibility with existing RTP tooling
possible solutions that would have encrypted more of the RTP header
(e.g., the number of CSRCs), lack of support on current tools was The last point deserves further discussion. While other possible
inevitable and the additional complexity outweighed the slight solutions that would have encrypted more of the RTP header (e.g., the
improvement in confidentiality by fixing previous solutions. Hence, number of CSRCs) were considered, the inability to parse the
a new approach was needed to solve the described problem in resultant packets with current tools and a generally higher level of
Section 1.1. complexity outweighed the slight improvement in confidentiality in
these solutions. Hence, a more pragmatic approach was taken to solve
the problem described in Section 1.1.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Design 3. Design
This specification proposes a mechanism to negotiate encryption of This specification proposes a mechanism to negotiate encryption of
all RTP header extensions (ids, lengths, and values) as well as CSRC all RTP header extensions (ids, lengths, and values) as well as CSRC
values. It reuses the existing SRTP framework, is accordingly simple values. It reuses the existing SRTP framework, is accordingly simple
to implement, and is backward compatible with existing RTP packet to implement, and is backward compatible with existing RTP packet
parsing code, even when support for the mechanism has been parsing code, even when support for the mechanism has been
negotiated. negotiated.
Except when explicitly stated otherwise, Cryptex reuses all the Except when explicitly stated otherwise, Cryptex reuses all the
framework procedures, transforms and considerations described in framework procedures, transforms, and considerations described in
[RFC3711]. [RFC3711].
4. SDP Considerations 4. SDP Considerations
Cryptex support is indicated via a new "a=cryptex" SDP attribute Cryptex support is indicated via a new "a=cryptex" SDP attribute
defined in this specification. defined in this specification.
The new "a=cryptex" attribute is a property attribute as defined in The new "a=cryptex" attribute is a property attribute as defined in
[RFC8866] section 5.13 and therefore takes no value, and can be used Section 5.13 of [RFC8866]; it therefore takes no value and can be
at the session level or media level. used at the session level or media level.
The presence of the "a=cryptex" attribute in the SDP (either in an The presence of the "a=cryptex" attribute in the SDP (in either an
offer or answer) indicates that the endpoint is capable of receiving offer or an answer) indicates that the endpoint is capable of
RTP packets encrypted with Cryptex, as defined below. receiving RTP packets encrypted with Cryptex, as defined below.
Once each peer has verified that the other party supports receiving Once each peer has verified that the other party supports receiving
RTP packets encrypted with Cryptex, senders can unilaterally decide RTP packets encrypted with Cryptex, senders can unilaterally decide
whether to use or not the Cryptex mechanism on a per packet basis. whether or not to use the Cryptex mechanism on a per-packet basis.
If BUNDLE is in use as per [RFC9143] and the "a=cryptex" attribute is If BUNDLE is in use as per [RFC9143] and the "a=cryptex" attribute is
present for a media line, it MUST be present for all RTP-based "m=" present for a media line, it MUST be present for all RTP-based "m="
sections belonging to the same bundle group. This ensures that the sections belonging to the same bundle group. This ensures that the
encrypted MID header extensions can be processed, allowing to encrypted Media Identifier (MID) header extensions can be processed,
associate RTP streams with the correct "m=" section in each BUNDLE allowing RTP streams to be associated with the correct "m=" section
group as specified in [RFC9143] section 9.2. When used with BUNDLE, in each BUNDLE group as specified in Section 9.2 of [RFC9143]. When
this attribute is assigned to the TRANSPORT category [RFC8859]. used with BUNDLE, this attribute is assigned to the TRANSPORT
category [RFC8859].
Both endpoints can change the Cryptex support status by modifying the Both endpoints can change the Cryptex support status by modifying the
session as specified in [RFC3264] section 8. Generating subsequent session as specified in Section 8 of [RFC3264]. Generating
SDP offers and answers MUST use the same procedures for including the subsequent SDP offers and answers MUST use the same procedures for
"a=cryptex" attribute as the ones on the initial offer and answer. including the "a=cryptex" attribute as the ones on the initial offer
and answer.
5. RTP Header Processing 5. RTP Header Processing
A General Mechanism for RTP Header Extensions [RFC8285] defines two A General Mechanism for RTP Header Extensions [RFC8285] defines two
values for the "defined by profile" field for carrying one-byte and values for the "defined by profile" field for carrying one-byte and
two-byte header extensions. In order to allow a receiver to two-byte header extensions. In order to allow a receiver to
determine if an incoming RTP packet is using the encryption scheme in determine if an incoming RTP packet is using the encryption scheme in
this specification, two new values are defined: this specification, two new values are defined:
* 0xC0DE for the encrypted version of the one-byte header extensions * 0xC0DE for the encrypted version of the one-byte header extensions
(instead of 0xBEDE). (instead of 0xBEDE).
* 0xC2DE for the encrypted versions of the two-byte header * 0xC2DE for the encrypted versions of the two-byte header
extensions (instead of 0x100). extensions (instead of 0x100).
In the case of using two-byte header extensions, the extension id In the case of using two-byte header extensions, the extension
with value 256 MUST NOT be negotiated, as the value of this id is identifier with value 256 MUST NOT be negotiated, as the value of
meant to be contained in the "appbits" of the "defined by profile" this identifier is meant to be contained in the "appbits" of the
field, which are not available when using the values above. "defined by profile" field, which is not available when using the
values above.
Note that as per [RFC8285] it is not possible to mix one-byte and Note that as per [RFC8285], it is not possible to mix one-byte and
two-byte headers on the same RTP packet. Mixing one-byte and two- two-byte headers on the same RTP packet. Mixing one-byte and two-
byte headers on the same RTP stream requires negotiation of the byte headers on the same RTP stream requires negotiation of the
"extmap-allow-mixed" SDP attribute as defined in [RFC8285] section "extmap-allow-mixed" SDP attribute as defined in Section 6 of
4.1.2. [RFC8285].
Peers MAY negotiate both Cryptex and the Encryption of Header Peers MAY negotiate both Cryptex and the Encryption of Header
Extensions mechanism defined in [RFC6904] via SDP offer/answer as Extensions mechanism defined in [RFC6904] via SDP offer/answer as
described in Section 4, and if both mechanisms are supported, either described in Section 4, and if both mechanisms are supported, either
one can be used for any given packet. However, if a packet is one can be used for any given packet. However, if a packet is
encrypted with Cryptex, it MUST NOT also use [RFC6904] header encrypted with Cryptex, it MUST NOT also use header extension
extension encryption, and vice versa. encryption [RFC6904], and vice versa.
If one of the peers has advertised both the ability to receive If one of the peers has advertised the ability to receive both
cryptex and the ability to receive header extensions encrypted as per Cryptex and header extensions encrypted as per [RFC6904] in the SDP
[RFC6904] in the SDP exchange, it is RECOMMENDED for the other peer exchange, it is RECOMMENDED that the other peer use Cryptex rather
to use Cryptex rather than [RFC6904] when sending RTP packets so all than the mechanism in [RFC6904] when sending RTP packets so that all
the header extensions and CSRCS are encrypted unless there is a the header extensions and CSRCS are encrypted. However, if there is
compelling reason to use [RFC6904] (e.g. a need for some header a compelling reason to use the mechanism in [RFC6904] (e.g., a need
extensions to be sent in the clear so that so they are processable by for some header extensions to be sent in the clear so that so they
RTP middleboxes) in which case, it SHOULD use [RFC6904] instead. are processable by RTP middleboxes), the other peer SHOULD use the
mechanism in [RFC6904] instead.
5.1. Sending 5.1. Sending
When the mechanism defined by this specification has been negotiated, When the mechanism defined by this specification has been negotiated,
sending an RTP packet that has any CSRCs or contains any [RFC8285] sending an RTP packet that has any CSRCs or contains any header
header extensions follows the steps below. This mechanism MUST NOT extensions [RFC8285] follows the steps below. This mechanism MUST
be used with header extensions other than the [RFC8285] variety. NOT be used with header extensions other than the variety described
in [RFC8285].
If the RTP packet contains one-byte headers, the 16-bit RTP header If the RTP packet contains one-byte headers, the 16-bit RTP header
extension tag MUST be set to 0xC0DE to indicate that the encryption extension tag MUST be set to 0xC0DE to indicate that the encryption
has been applied, and the one-byte framing is being used. Otherwise, has been applied and the one-byte framing is being used. If the RTP
the header extension tag MUST be set to 0xC2DE to indicate encryption packet contains two-byte headers, the header extension tag MUST be
has been applied, and the two-byte framing is being used. set to 0xC2DE to indicate encryption has been applied and the two-
byte framing is being used.
If the packet contains CSRCs but no header extensions, an empty If the packet contains CSRCs but no header extensions, an empty
extension block consisting of the 0xC0DE tag and a 16-bit length extension block consisting of the 0xC0DE tag and a 16-bit length
field set to zero (explicitly permitted by [RFC3550]) MUST be field set to zero (explicitly permitted by [RFC3550]) MUST be
appended, and the X bit MUST be set to 1 to indicate an extension appended, and the X bit MUST be set to 1 to indicate an extension
block is present. This is necessary to provide the receiver an block is present. This is necessary to provide the receiver an
indication that the CSRCs in the packet are encrypted. indication that the CSRCs in the packet are encrypted.
The RTP packet MUST then be encrypted as described in Encryption The RTP packet MUST then be encrypted as described in Section 6.2
Procedure. ("Encryption Procedure").
5.2. Receiving 5.2. Receiving
When receiving an RTP packet that contains header extensions, the When receiving an RTP packet that contains header extensions, the
"defined by profile" field MUST be checked to ensure the payload is "defined by profile" field MUST be checked to ensure the payload is
formatted according to this specification. If the field does not formatted according to this specification. If the field does not
match one of the values defined above, the implementation MUST match one of the values defined above, the implementation MUST
instead handle it according to the specification that defines that instead handle it according to the specification that defines that
value. value.
Alternatively, if the implementation considers the use of this Alternatively, if the implementation considers the use of this
specification mandatory and the "defined by profile" field does not specification mandatory and the "defined by profile" field does not
match one of the values defined above, it MUST stop the processing of match one of the values defined above, it MUST stop the processing of
the RTP packet and report an error for the RTP stream. the RTP packet and report an error for the RTP stream.
If the RTP packet passes this check, it is then decrypted according If the RTP packet passes this check, it is then decrypted as
to Decryption Procedure, and passed to the next layer to process the described in Section 6.3 ("Decryption Procedure") and passed to the
packet and its extensions. In the event that a zero-length extension next layer to process the packet and its extensions. In the event
block was added as indicated above, it can be left as-is and will be that a zero-length extension block was added as indicated above, it
processed normally. can be left as is and will be processed normally.
6. Encryption and Decryption 6. Encryption and Decryption
6.1. Packet Structure 6.1. Packet Structure
When this mechanism is active, the SRTP packet is protected as When this mechanism is active, the SRTP packet is protected as
follows: follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | | |V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | | | timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | | | synchronization source (SSRC) identifier | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | contributing source (CSRC) identifiers | | | | contributing source (CSRC) identifiers | |
| | .... | | | | .... | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
X | 0xC0 or 0xC2 | 0xDE | length | | X | 0xC0 or 0xC2 | 0xDE | length | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RFC 8285 header extensions | | | | RFC 8285 header extensions | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | | | | payload ... | |
| | +-------------------------------+ | | | +-------------------------------+ |
| | | RTP padding | RTP pad count | | | | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ | | ~ SRTP Master Key Identifier (MKI) (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : | | : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+- Encrypted Portion* Authenticated Portion ---+ +- Encrypted Portion Authenticated Portion ---+
Figure 1 Figure 1: A Protected SRTP Packet
* Note that, as required by [RFC8285], the 4 bytes at the start of Note that, as required by [RFC8285], the 4 bytes at the start of the
the extension block are not encrypted. extension block are not encrypted.
Specifically, the encrypted portion MUST include any CSRC Specifically, the Encrypted Portion MUST include any CSRC
identifiers, any RTP header extension (except for the first 4 bytes), identifiers, any RTP header extension (except for the first 4 bytes),
and the RTP payload. and the RTP payload.
6.2. Encryption Procedure 6.2. Encryption Procedure
The encryption procedure is identical to that of [RFC3711] except for The encryption procedure is identical to that of [RFC3711] except for
the Encrypted Portion of the SRTP packet. The plaintext input to the the Encrypted Portion of the SRTP packet. The plaintext input to the
cipher is as follows: cipher is as follows:
Plaintext = CSRC identifiers (if used) || header extension data || Plaintext = CSRC identifiers (if used) || header extension data ||
RTP payload || RTP padding (if used) || RTP pad count (if used). RTP payload || RTP padding (if used) || RTP pad count (if used)
Here "header extension data" refers to the content of the RTP Here "header extension data" refers to the content of the RTP
extension field, excluding the first four bytes (the RFC 8285 extension field, excluding the first four bytes (the extension header
extension header). The first 4 * CSRC count (CC) bytes of the [RFC8285]). The first 4 * CSRC count (CC) bytes of the ciphertext
ciphertext are placed in the CSRC field of the RTP header. The are placed in the CSRC field of the RTP header. The remainder of the
remainder of the ciphertext is the RTP payload of the encrypted ciphertext is the RTP payload of the encrypted packet.
packet.
To minimize changes to surrounding code, the encryption mechanism can To minimize changes to surrounding code, the encryption mechanism can
choose to replace a "defined by profile" field from [RFC8285] with choose to replace a "defined by profile" field from [RFC8285] with
its counterpart defined in RTP Header Processing above and encrypt at its counterpart defined in Section 5 ("RTP Header Processing") and
the same time. encrypt at the same time.
For AEAD ciphers (e.g., GCM), the 12-byte fixed header and the four- For Authenticated Encryption with Associated Data (AEAD) ciphers
byte header extension header (the "defined by profile" field and the (e.g., AES-GCM), the 12-byte fixed header and the four-byte header
length) are considered AAD, even though they are non-contiguous in extension header (the "defined by profile" field and the length) are
the packet if CSRCs are present. considered additional authenticated data (AAD), even though they are
non-contiguous in the packet if CSRCs are present.
Associated Data: fixed header || extension header (if X=1) Associated Data: fixed header || extension header (if X=1)
Here "fixed header" refers to the 12-byte fixed portion of the RTP Here "fixed header" refers to the 12-byte fixed portion of the RTP
header, and "extension header" refers to the four-byte RFC 8285 header, and "extension header" refers to the four-byte extension
extension header ("defined by profile" and extension length). header [RFC8285] ("defined by profile" and extension length).
Implementations can rearrange a packet so that the AAD and plaintext Implementations can rearrange a packet so that the AAD and plaintext
are contiguous by swapping the order of the extension header and the are contiguous by swapping the order of the extension header and the
CSRC identifiers, resulting in an intermediate representation of the CSRC identifiers, resulting in an intermediate representation of the
form shown in Figure 2. After encryption, the CSRCs (now encrypted) form shown in Figure 2. After encryption, the CSRCs (now encrypted)
and extension header would need to be swapped back to their original and extension header would need to be swapped back to their original
positions. A similar operation can be done when decrypting to create positions. A similar operation can be done when decrypting to create
contiguous ciphertext and AAD inputs. contiguous ciphertext and AAD inputs.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | | |V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | | | timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | | | synchronization source (SSRC) identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0xC0 or 0xC2 | 0xDE | length | | | 0xC0 or 0xC2 | 0xDE | length | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+ +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+
| | contributing source (CSRC) identifiers | | | | contributing source (CSRC) identifiers | |
| | .... | | | | .... | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RFC 8285 header extensions | | | | RFC 8285 header extensions | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | | | | payload ... | |
| | +-------------------------------+ | | | +-------------------------------+ |
| | | RTP padding | RTP pad count | | | | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+- Plaintext Input AAD Input ---+ +- Plaintext Input AAD Input ---+
Figure 2: An RTP packet transformed to make Cryptex cipher inputs Figure 2: An RTP Packet Transformed to Make Cryptex Cipher Inputs
contiguous Contiguous
Note: This intermediate representation is only displayed as reference Note that this intermediate representation is only displayed as
for implementations and is not meant to be sent on the wire. reference for implementations and is not meant to be sent on the
wire.
6.3. Decryption Procedure 6.3. Decryption Procedure
The decryption procedure is identical to that of [RFC3711] except for The decryption procedure is identical to that of [RFC3711] except for
the Encrypted Portion of the SRTP packet, which is as shown in the the Encrypted Portion of the SRTP packet, which is as shown in the
section above. section above.
To minimize changes to surrounding code, the decryption mechanism can To minimize changes to surrounding code, the decryption mechanism can
choose to replace the "defined by profile" field with its no- choose to replace the "defined by profile" field with its no-
encryption counterpart from [RFC8285] and decrypt at the same time. encryption counterpart from [RFC8285] and decrypt at the same time.
7. Backwards Compatibility 7. Backward Compatibility
This specification attempts to encrypt as much as possible without This specification attempts to encrypt as much as possible without
interfering with backwards compatibility for systems that expect a interfering with backward compatibility for systems that expect a
certain structure from an RTPv2 packet, including systems that certain structure from an RTPv2 packet, including systems that
perform demultiplexing based on packet headers. Accordingly, the perform demultiplexing based on packet headers. Accordingly, the
first two bytes of the RTP packet are not encrypted. first two bytes of the RTP packet are not encrypted.
This specification also attempts to reuse the key scheduling from This specification also attempts to reuse the key scheduling from
SRTP, which depends on the RTP packet sequence number and SSRC SRTP, which depends on the RTP packet sequence number and SSRC
identifier. Accordingly, these values are also not encrypted. identifier. Accordingly, these values are also not encrypted.
8. Security Considerations 8. Security Considerations
All security considerations in [RFC3711] section 9 are applicable to All security considerations in Section 9 of [RFC3711] are applicable
this specification, except section 9.4. Confidentiality of the RTP to this specification; the exception is Section 9.4, because
Header which is the purpose of this specification. confidentiality of the RTP Header is the purpose of this
specification.
The risks of using weak or NULL authentication with SRTP, described The risks of using weak or NULL authentication with SRTP, described
in Section 9.5 of [RFC3711], apply to encrypted header extensions as in Section 9.5 of [RFC3711], apply to encrypted header extensions as
well. well.
This specification extends SRTP by expanding the Encrypted Portion of This specification extends SRTP by expanding the Encrypted Portion of
the RTP packet, as shown in Packet Structure. It does not change how the RTP packet, as shown in Section 6.1 ("Packet Structure"). It
SRTP authentication works in any way. Given that more of the packet does not change how SRTP authentication works in any way. Given that
is being encrypted than before, this is necessarily an improvement. more of the packet is being encrypted than before, this is
necessarily an improvement.
The RTP fields that are left unencrypted (see rationale above) are as The RTP fields that are left unencrypted (see rationale above) are as
follows: follows:
* RTP version * RTP version
* padding bit * padding bit
* extension bit * extension bit
skipping to change at page 11, line 45 skipping to change at line 514
* marker bit * marker bit
* payload type * payload type
* sequence number * sequence number
* timestamp * timestamp
* SSRC identifier * SSRC identifier
* number of [RFC8285] header extensions * number of header extensions [RFC8285]
These values contain a fixed set (i.e., one that won't be changed by These values contain a fixed set (i.e., one that won't be changed by
extensions) of information that, at present, is observed to have low extensions) of information that, at present, is observed to have low
sensitivity. In the event any of these values need to be encrypted, sensitivity. In the event any of these values need to be encrypted,
SRTP is likely the wrong protocol to use and a fully-encapsulating SRTP is likely the wrong protocol to use and a fully encapsulating
protocol such as DTLS is preferred (with its attendant per-packet protocol such as DTLS is preferred (with its attendant per-packet
overhead). overhead).
9. IANA Considerations 9. IANA Considerations
9.1. SDP cryptex Attribute This document updates the "attribute-name (formerly "att-field")"
subregistry of the "Session Description Protocol (SDP) Parameters"
This document updates the "Session Description Protocol Parameters" registry (see Section 8.2.4 of [RFC8866]). Specifically, it adds the
as specified in Section 8.2.4 of [RFC8866]. Specifically, it adds SDP "a=cryptex" attribute for use at both the media level and the
the SDP "a=cryptex" attribute to the Attribute Names (<attribute- session level.
name>) registry for both media and session level usage.
Contact name: IETF AVT Working Group or IESG if AVT is closed
Contact email address: avt@ietf.org
Attribute name: cryptex Contact name: IETF AVT Working Group or IESG if the AVT Working
Group is closed
Attribute syntax: This attribute takes no values. Contact email address: avt@ietf.org
Attribute semantics: N/A Attribute name: cryptex
Attribute value: N/A Attribute syntax: This attribute takes no values.
Usage level: session, media Attribute semantics: N/A
Charset dependent: No Attribute value: N/A
Purpose: The presence of this attribute in the SDP indicates that the Usage level: session, media
endpoint is capable of receiving RTP packets encrypted with Cryptex
as described in this document.
O/A procedures: SDP O/A procedures are described in Section 4 of this Charset dependent: No
document.
Mux Category: TRANSPORT Purpose: The presence of this attribute in the SDP indicates that
the endpoint is capable of receiving RTP packets encrypted with
Cryptex as described in this document.
10. Acknowledgements O/A procedures: SDP O/A procedures are described in Section 4 of
this document.
The authors wish to thank Lennart Grahl for pointing out many of the Mux Category: TRANSPORT
issues with the existing header encryption mechanism, as well as
suggestions for this proposal. Thanks also to Jonathan Lennox, Inaki
Castillo, and Bernard Aboba for their review and suggestions.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
skipping to change at page 13, line 50 skipping to change at line 606
Session Description Protocol", RFC 8866, Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021, DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>. <https://www.rfc-editor.org/info/rfc8866>.
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 9143, Description Protocol (SDP)", RFC 9143,
DOI 10.17487/RFC9143, February 2022, DOI 10.17487/RFC9143, February 2022,
<https://www.rfc-editor.org/info/rfc9143>. <https://www.rfc-editor.org/info/rfc9143>.
11.2. Informative References 10.2. Informative References
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011, DOI 10.17487/RFC6464, December 2011,
<https://www.rfc-editor.org/info/rfc6464>. <https://www.rfc-editor.org/info/rfc6464>.
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
time Transport Protocol (RTP) Header Extension for Mixer- time Transport Protocol (RTP) Header Extension for Mixer-
to-Client Audio Level Indication", RFC 6465, to-Client Audio Level Indication", RFC 6465,
skipping to change at page 14, line 34 skipping to change at line 637
RFC 7714, DOI 10.17487/RFC7714, December 2015, RFC 7714, DOI 10.17487/RFC7714, December 2015,
<https://www.rfc-editor.org/info/rfc7714>. <https://www.rfc-editor.org/info/rfc7714>.
Appendix A. Test Vectors Appendix A. Test Vectors
All values are in hexadecimal and represented in network order (big All values are in hexadecimal and represented in network order (big
endian). endian).
A.1. AES-CTR A.1. AES-CTR
The following section list the test vectors for using cryptex with The following subsections list the test vectors for using Cryptex
AES-CTR as per [RFC3711] with AES-CTR as per [RFC3711].
Common values are organized as follows: Common values are organized as follows:
Rollover Counter: 00000000 Rollover Counter: 00000000
Master Key: e1f97a0d3e018be0d64fa32c06de4139 Master Key: e1f97a0d3e018be0d64fa32c06de4139
Master Salt: 0ec675ad498afeebb6960b3aabe6 Master Salt: 0ec675ad498afeebb6960b3aabe6
Crypto Suite: AES_CM_128_HMAC_SHA1_80 Crypto Suite: AES_CM_128_HMAC_SHA1_80
Session Key: c61e7a93744f39ee10734afe3ff7a087 Session Key: c61e7a93744f39ee10734afe3ff7a087
Session Salt: 30cbbc08863d8c85d49db34a9ae1 Session Salt: 30cbbc08863d8c85d49db34a9ae1
Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4 Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4
A.1.1. RTP Packet with 1-byte header extension A.1.1. RTP Packet with One-Byte Header Extension
RTP Packet: RTP Packet:
900f1235 900f1235
decafbad decafbad
cafebabe cafebabe
bede0001 bede0001
51000200 51000200
abababab abababab
abababab abababab
skipping to change at page 15, line 30 skipping to change at line 679
c0de0001 c0de0001
eb923652 eb923652
51c3e036 51c3e036
f8de27e9 f8de27e9
c27ee3e0 c27ee3e0
b4651d9f b4651d9f
bc4218a7 bc4218a7
0244522f 0244522f
34a5 34a5
A.1.2. RTP Packet with 2-byte header extension A.1.2. RTP Packet with Two-Byte Header Extension
RTP Packet: RTP Packet:
900f1236 900f1236
decafbad decafbad
cafebabe cafebabe
10000001 10000001
05020002 05020002
abababab abababab
abababab abababab
skipping to change at page 16, line 18 skipping to change at line 708
c2de0001 c2de0001
4ed9cc4e 4ed9cc4e
6a712b30 6a712b30
96c5ca77 96c5ca77
339d4204 339d4204
ce0d7739 ce0d7739
6cab6958 6cab6958
5fbce381 5fbce381
94a5 94a5
A.1.3. RTP Packet with 1-byte header extension and CSRC fields A.1.3. RTP Packet with One-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f1238 920f1238
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
bede0001 bede0001
51000200 51000200
skipping to change at page 17, line 5 skipping to change at line 741
c0de0001 c0de0001
92838c8c 92838c8c
09e58393 09e58393
e1de3a9a e1de3a9a
74734d67 74734d67
45671338 45671338
c3acf11d c3acf11d
a2df8423 a2df8423
bee0 bee0
A.1.4. RTP Packet with 2-byte header extension and CSRC fields A.1.4. RTP Packet with Two-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f1239 920f1239
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
10000001 10000001
05020002 05020002
skipping to change at page 17, line 38 skipping to change at line 774
c2de0001 c2de0001
bbed4848 bbed4848
faa64466 faa64466
5f3d7f34 5f3d7f34
125914e9 125914e9
f4d0ae92 f4d0ae92
3c6f479b 3c6f479b
95a0f7b5 95a0f7b5
3133 3133
A.1.5. RTP Packet with empty 1-byte header extension and CSRC fields A.1.5. RTP Packet with Empty One-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f123a 920f123a
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
bede0000 bede0000
abababab abababab
skipping to change at page 18, line 21 skipping to change at line 805
fe2ab0e3 fe2ab0e3
c0de0000 c0de0000
e3d9f64b e3d9f64b
25c9e74c 25c9e74c
b4cf8e43 b4cf8e43
fb92e378 fb92e378
1c2c0cea 1c2c0cea
b6b3a499 b6b3a499
a14c a14c
A.1.6. RTP Packet with empty 2-byte header extension and CSRC fields A.1.6. RTP Packet with Empty Two-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f123b 920f123b
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
10000000 10000000
abababab abababab
skipping to change at page 19, line 7 skipping to change at line 838
599dd45b 599dd45b
c9d687b6 c9d687b6
03e8b59d 03e8b59d
771fd38e 771fd38e
88b170e0 88b170e0
cd31e125 cd31e125
eabe eabe
A.2. AES-GCM A.2. AES-GCM
The following section list the test vectors for using cryptex with The following subsections list the test vectors for using Cryptex
AES-GCM as per [RFC7714] with AES-GCM as per [RFC7714].
Common values are organized as follows: Common values are organized as follows:
Rollover Counter: 00000000 Rollover Counter: 00000000
Master Key: 000102030405060708090a0b0c0d0e0f Master Key: 000102030405060708090a0b0c0d0e0f
Master Salt: a0a1a2a3a4a5a6a7a8a9aaab Master Salt: a0a1a2a3a4a5a6a7a8a9aaab
Crypto Suite: AEAD_AES_128_GCM Crypto Suite: AEAD_AES_128_GCM
Session Key: 077c6143cb221bc355ff23d5f984a16e Session Key: 077c6143cb221bc355ff23d5f984a16e
Session Salt: 9af3e95364ebac9c99c5a7c4 Session Salt: 9af3e95364ebac9c99c5a7c4
A.2.1. RTP Packet with 1-byte header extension A.2.1. RTP Packet with One-Byte Header Extension
RTP Packet: RTP Packet:
900f1235 900f1235
decafbad decafbad
cafebabe cafebabe
bede0001 bede0001
51000200 51000200
abababab abababab
abababab abababab
skipping to change at page 19, line 49 skipping to change at line 880
39972dc9 39972dc9
572c4d99 572c4d99
e8fc355d e8fc355d
e743fb2e e743fb2e
94f9d8ff 94f9d8ff
54e72f41 54e72f41
93bbc5c7 93bbc5c7
4ffab0fa 4ffab0fa
9fa0fbeb 9fa0fbeb
A.2.2. RTP Packet with 2-byte header extension A.2.2. RTP Packet with Two-Byte Header Extension
RTP Packet: RTP Packet:
900f1236 900f1236
decafbad decafbad
cafebabe cafebabe
10000001 10000001
05020002 05020002
abababab abababab
abababab abababab
skipping to change at page 20, line 31 skipping to change at line 910
bb75a4c5 bb75a4c5
45cd1f41 45cd1f41
3bdb7daa 3bdb7daa
2b1e3263 2b1e3263
de313667 de313667
c9632490 c9632490
81b35a65 81b35a65
f5cb6c88 f5cb6c88
b394235f b394235f
A.2.3. RTP Packet with 1-byte header extension and CSRC fields A.2.3. RTP Packet with One-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f1238 920f1238
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
bede0001 bede0001
51000200 51000200
skipping to change at page 21, line 21 skipping to change at line 944
8ad7c71f 8ad7c71f
ac70a80c ac70a80c
92866b4c 92866b4c
6ba98546 6ba98546
ef913586 ef913586
e95ffaaf e95ffaaf
fe956885 fe956885
bb0647a8 bb0647a8
bc094ac8 bc094ac8
A.2.4. RTP Packet with 2-byte header extension and CSRC fields A.2.4. RTP Packet with Two-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f1239 920f1239
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
10000001 10000001
05020002 05020002
skipping to change at page 22, line 21 skipping to change at line 978
c78d1200 c78d1200
38422bc1 38422bc1
11a7187a 11a7187a
18246f98 18246f98
0c059cc6 0c059cc6
bc9df8b6 bc9df8b6
26394eca 26394eca
344e4b05 344e4b05
d80fea83 d80fea83
A.2.5. RTP Packet with empty 1-byte header extension and CSRC fields A.2.5. RTP Packet with Empty One-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f123a 920f123a
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
bede0000 bede0000
abababab abababab
skipping to change at page 23, line 5 skipping to change at line 1010
c0de0000 c0de0000
b7b96453 b7b96453
7a2b03ab 7a2b03ab
7ba5389c 7ba5389c
e9331712 e9331712
6b5d974d 6b5d974d
f30c6884 f30c6884
dcb651c5 dcb651c5
e120c1da e120c1da
A.2.6. RTP Packet with empty 2-byte header extension and CSRC fields A.2.6. RTP Packet with Empty Two-Byte Header Extension and CSRC Fields
RTP Packet: RTP Packet:
920f123b 920f123b
decafbad decafbad
cafebabe cafebabe
0001e240 0001e240
0000b26e 0000b26e
10000000 10000000
abababab abababab
skipping to change at page 23, line 37 skipping to change at line 1042
c2de0000 c2de0000
61ee432c 61ee432c
f9203170 f9203170
76613258 76613258
d3ce4236 d3ce4236
c06ac429 c06ac429
681ad084 681ad084
13512dc9 13512dc9
8b5207d8 8b5207d8
Acknowledgements
The authors wish to thank Lennart Grahl for pointing out many of the
issues with the existing header encryption mechanism, as well as
suggestions for this proposal. Thanks also to Jonathan Lennox, Inaki
Castillo, and Bernard Aboba for their reviews and suggestions.
Authors' Addresses Authors' Addresses
Justin Uberti Justin Uberti
Clubhouse
Email: justin@uberti.name Email: justin@uberti.name
Cullen Jennings Cullen Jennings
Cisco Cisco
Email: fluffy@iii.ca Email: fluffy@iii.ca
Sergio Garcia Murillo Sergio Garcia Murillo
Millicast Millicast
Email: sergio.garcia.murillo@cosmosoftware.io Email: sergio.garcia.murillo@cosmosoftware.io
 End of changes. 87 change blocks. 
283 lines changed or deleted 289 lines changed or added

This html diff was produced by rfcdiff 1.48.