Internet DRAFT - draft-uberti-avtcore-cryptex
draft-uberti-avtcore-cryptex
AVTCORE J. Uberti
Internet-Draft Google
Intended status: Standards Track C. Jennings
Expires: 6 May 2021 Cisco
2 November 2020
Completely Encrypting RTP Header Extensions and Contributing Sources
draft-uberti-avtcore-cryptex-01
Abstract
While the Secure Real-time Transport Protocol (SRTP) provides
confidentiality for the contents of a media packet, a significant
amount of metadata is left unprotected, including RTP header
extensions and contributing sources (CSRCs). However, this data can
be moderately sensitive in many applications. While there have been
previous attempts to protect this data, they have had limited
deployment, due to complexity as well as technical limitations.
This document proposes a new mechanism to completely encrypt header
extensions and CSRCs as well a simpler signaling mechanism intended
to facilitate deployment.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/juberti/cryptex.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 May 2021.
Uberti & Jennings Expires 6 May 2021 [Page 1]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Previous Solutions . . . . . . . . . . . . . . . . . . . 3
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. RTP Header Processing . . . . . . . . . . . . . . . . . . . . 5
5.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Encryption and Decryption . . . . . . . . . . . . . . . . . . 7
6.1. Packet Structure . . . . . . . . . . . . . . . . . . . . 7
6.2. Encryption Procedure . . . . . . . . . . . . . . . . . . 7
6.3. Decryption Procedure . . . . . . . . . . . . . . . . . . 8
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Uberti & Jennings Expires 6 May 2021 [Page 2]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
1.1. Problem Statement
The Secure Real-time Transport Protocol [RFC3711] mechanism provides
message authentication for the entire RTP packet, but only encrypts
the RTP payload. This has not historically been a problem, as much
of the information carried in the header has minimal sensitivity
(e.g., RTP timestamp); in addition, certain fields need to remain as
cleartext because they are used for key scheduling (e.g., RTP SSRC
and sequence number).
However, as noted in [RFC6904], the security requirements can be
different for information carried in RTP header extensions, including
the per-packet sound levels defined in [RFC6464] and [RFC6465], which
are specifically noted as being sensitive in the Security
Considerations section of those RFCs.
In addition to the contents of the header extensions, there are now
enough header extensions in active use that the header extension
identifiers themselves can provide meaningful information in terms of
determining the identity of endpoint and/or application.
Accordingly, these identifiers can be considered at least slightly
sensitive.
Finally, the CSRCs included in RTP packets can also be sensitive,
potentially allowing a network eavesdropper to determine who was
speaking and when during an otherwise secure conference call.
1.2. Previous Solutions
[RFC6904] was proposed in 2013 as a solution to the problem of
unprotected header extension values. However, it has not seen
significant adoption, and has a few technical shortcomings.
First, the mechanism is complicated. Since it allows encryption to
be negotiated on a per-extension basis, a fair amount of signaling
logic is required. And in the SRTP layer, a somewhat complex
transform is required to allow only the selected header extension
values to be encrypted. One of the most popular SRTP implementations
had a significant bug in this area that was not detected for five
years.
Second, it only protects the header extension values, and not their
ids or lengths. It also does not protect the CSRCs. As noted above,
this leaves a fair amount of potentially sensitive information
exposed.
Uberti & Jennings Expires 6 May 2021 [Page 3]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
Third, it bloats the header extension space. Because each extension
must be offered in both unencrypted and encrypted forms, twice as
many header extensions must be offered, which will in many cases push
implementations past the 14-extension limit for the use of one-byte
extension headers defined in [RFC8285]. Accordingly, implementations
will need to use two-byte headers in many cases, which are not
supported well by some existing implementations.
Finally, the header extension bloat combined with the need for
backwards compatibility results in additional wire overhead. Because
two-byte extension headers may not be handled well by existing
implementations, one-byte extension identifiers will need to be used
for the unencrypted (backwards compatible) forms, and two-byte for
the encrypted forms. Thus, deployment of [RFC6904] encryption for
header extensions will typically result in multiple extra bytes in
each RTP packet, compared to the present situation.
1.3. Goals
From this analysis we can state the desired properties of a solution:
* Build on existing [RFC3711] SRTP framework (simple to understand)
* Build on existing [RFC8285] header extension framework (simple to
implement)
* Protection of header extension ids, lengths, and values
* Protection of CSRCs when present
* Simple signaling
* Simple crypto transform and SRTP interactions
* Backward compatible with unencrypted endpoints, if desired
* Backward compatible with existing RTP tooling
The last point deserves further discussion. While we considered
possible solutions that would have encrypted more of the RTP header
(e.g., the number of CSRCs), we felt the inability to parse the
resultant packets with current tools, as well as additional
complexity incurred, outweighed the slight improvement in
confidentiality.
Uberti & Jennings Expires 6 May 2021 [Page 4]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Design
This specification proposes a mechanism to negotiate encryption of
all RTP header extensions (ids, lengths, and values) as well as CSRC
values. It reuses the existing SRTP framework, is accordingly simple
to implement, and is backward compatible with existing RTP packet
parsing code, even when support for this mechanism has been
negotiated.
4. Signaling
In order to determine whether this mechanism defined in this
specification is supported, this document defines a new "a=extmap-
encrypted" Session Description Protocol (SDP) [RFC4566] attribute to
indicate support. This attribute takes no value, and can be used at
the session level or media level. Offering this attribute indicates
that the endpoint is capable of receiving RTP packets encrypted as
defined below.
The formal definition of this attribute is:
Name: extmap-encrypted
Value: None
Usage Level: session, media
Charset Dependent: No
Example:
a=extmap-encrypted
When used with BUNDLE, this attribute is specified as the TRANSPORT
category. (todo: REF)
5. RTP Header Processing
[RFC8285] defines two values for the "defined by profile" field for
carrying one-byte and two-byte header extensions. In order to allow
a receiver to determine if an incoming RTP packet is using the
encryption scheme in this specification, two new values are defined:
Uberti & Jennings Expires 6 May 2021 [Page 5]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
* 0xC0DE for the encrypted version of the one-byte header extensions
(instead of 0xBEDE).
* 0xC2DE for the encrypted versions of the two-byte header
extensions (instead of 0x100).
In the case of using two-byte header extensions, the extension id
with value 256 MUST NOT be negotiated, as the value of this id is
meant to be contained in the "appbits" of the "defined by profile"
field, which are not available when using the values above.
If the "a=extmap-allow-mixed" attribute defined in [RFC8285] is
negotiated, either one-byte or two-byte header ids can be used (with
the values above), as in [RFC8285].
5.1. Sending
When sending an RTP packet that requires any header extensions to a
destination that has negotiated header encryption, the header
extensions MUST be formatted as [RFC8285] header extensions, as
usual.
If one-byte extension ids are in use, the 16-bit RTP header extension
tag MUST be set to 0xC0DE to indicate that the encryption defined in
this specification has been applied. If two-byte header extension
codes are in use, the 16-bit RTP header extension tag MUST be set to
0xC2DE to indicate the same.
The RTP packet MUST then be encrypted as described in Encryption
Procedure.
5.2. Receiving
When receiving an RTP packet that contains header extensions, the
"defined by profile" field MUST be checked to ensure the payload is
formatted according to this specification. If the field does not
match one of the values defined above, the implementation MUST
instead handle it according to the specification that defines that
value. The implemntation MAY stop and report an error if it
considers use of this specification mandatory for the RTP stream.
If the RTP packet passes this check, it is then decrypted according
to Decryption Procedure, and passed to the the next layer to process
the packet and its extensions.
Uberti & Jennings Expires 6 May 2021 [Page 6]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
6. Encryption and Decryption
6.1. Packet Structure
When this mechanism is active, the SRTP packet is protected as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | contributing source (CSRC) identifiers | |
| | .... | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
X | 0xC0 | 0xDE | length=3 | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RFC 8285 header extensions | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portions* Authenticated Portion ---+
* Note that the 4 bytes at the start of the extension block are not
encrypted, as required by [RFC8285].
Specifically, the encrypted portion MUST include any CSRC
identifiers, any RTP header extension (except for the first 4 bytes),
and the RTP payload.
6.2. Encryption Procedure
The encryption procedure is identical to that of [RFC3711] except for
the region to encrypt, which is as shown in the section above.
Uberti & Jennings Expires 6 May 2021 [Page 7]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
To minimize changes to surrounding code, the encryption mechanism can
choose to replace a "defined by profile" field from [RFC8285] with
its counterpart defined in RTP Header Processing above and encrypt at
the same time.
6.3. Decryption Procedure
The decryption procedure is identical to that of [RFC3711] except for
the region to decrypt, which is as shown in the section above.
To minimize changes to surrounding code, the decryption mechanism can
choose to replace the "defined by profile" field with its no-
encryption counterpart from [RFC8285] and decrypt at the same time.
7. Backwards Compatibility
This specification attempts to encrypt as much as possible without
interfering with backwards compatibility for systems that expect a
certain structure from an RTPv2 packet, including systems that
perform demultiplexing based on packet headers. Accordingly, the
first two bytes of the RTP packet are not encrypted.
This specification also attempts to reuse the key scheduling from
SRTP, which depends on the RTP packet sequence number and SSRC
identifier. Accordingly these values are also not encrypted.
8. Security Considerations
This specification extends SRTP by expanding the portion of the
packet that is encrypted, as shown in Packet Structure. It does not
change how SRTP authentication works in any way. Given that 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
follows:
* RTP version
* padding bit
* extension bit
* number of CSRCs
* marker bit
* payload type
Uberti & Jennings Expires 6 May 2021 [Page 8]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
* sequence number
* timestamp
* SSRC identifier
* number of [RFC8285] header extensions
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
sensitivity. In the event any of these values need to be encrypted,
SRTP is likely the wrong protocol to use and a fully-encapsulating
protocol such as DTLS is preferred (with its attendant per-packet
overhead).
9. IANA Considerations
This document defines two new 'defined by profile' attributes, as
noted in RTP Header Processing.
10. Acknowledgements
The authors wish to thank Sergio Murillo, Jonathan Lennox, and Inaki
Castillo for their review and text suggestions.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>.
Uberti & Jennings Expires 6 May 2021 [Page 9]
Internet-Draft Completely Encrypting RTP Header Extensi November 2020
11.2. Informative References
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<https://www.rfc-editor.org/info/rfc6464>.
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
time Transport Protocol (RTP) Header Extension for Mixer-
to-Client Audio Level Indication", RFC 6465,
DOI 10.17487/RFC6465, December 2011,
<https://www.rfc-editor.org/info/rfc6465>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013,
<https://www.rfc-editor.org/info/rfc6904>.
Authors' Addresses
Justin Uberti
Google
Email: justin@uberti.name
Cullen Jennings
Cisco
Email: fluffy@iii.ca
Uberti & Jennings Expires 6 May 2021 [Page 10]