Skip to main content

Completely Encrypting RTP Header Extensions and Contributing Sources
draft-ietf-avtcore-cryptex-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9335.
Authors Justin Uberti , Cullen Fluffy Jennings , Sergio Garcia Murillo
Last updated 2021-03-10
Replaces draft-uberti-avtcore-cryptex
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Dr. Bernard D. Aboba
IESG IESG state Became RFC 9335 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to bernard.aboba@gmail.com
draft-ietf-avtcore-cryptex-01
AVTCORE                                                        J. Uberti
Internet-Draft                                                    Google
Intended status: Standards Track                             C. Jennings
Expires: 11 September 2021                                         Cisco
                                                       S. Garcia Murillo
                                                                   CoSMo
                                                           10 March 2021

  Completely Encrypting RTP Header Extensions and Contributing Sources
                     draft-ietf-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."

Uberti, et al.          Expires 11 September 2021               [Page 1]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

   This Internet-Draft will expire on 11 September 2021.

Copyright Notice

   Copyright (c) 2021 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  . . . . . . . . . . . . . . . . . .   8
     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, et al.          Expires 11 September 2021               [Page 2]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

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, et al.          Expires 11 September 2021               [Page 3]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

   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, et al.          Expires 11 September 2021               [Page 4]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

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=cryptex"
   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: cryptex

     Value: None

     Usage Level: session, media

     Charset Dependent: No

     Example:

        a=cryptex

   When used with BUNDLE, this attribute is assigned to the TRANSPORT
   category [RFC8859].

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, et al.          Expires 11 September 2021               [Page 5]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

   *  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 the mechanism defined by this specification has been negotiated,
   sending a RTP packet that has any CSRCs or contains any {RFC8285}}
   header extensions follows the steps below.  This mechanism MUST NOT
   be used with header extensions other than the [RFC8285] variety.

   If the packet contains solely one-byte extension ids, the 16-bit RTP
   header extension tag MUST be set to 0xC0DE to indicate that the
   encryption has been applied, and the one-byte framing is being used.
   If the packet contains only two-byte extension ids, the header
   extension tag MUST be 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
   extension block consisting of the 0xC0DE tag and a 16-bit length
   field set to zero (explicitly permitted by [RFC3550]) MUST be
   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
   indication that the CSRCs in the packet are encrypted.

   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.

Uberti, et al.          Expires 11 September 2021               [Page 6]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

   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.  In the event that a zero-length
   extension block was added as indicated above, it can be left as-is
   and will be processed normally.

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.

Uberti, et al.          Expires 11 September 2021               [Page 7]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

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.

   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

Uberti, et al.          Expires 11 September 2021               [Page 8]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

   *  number of CSRCs

   *  marker bit

   *  payload type

   *  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 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 and
   Inaki Castillo for their review and 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>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

Uberti, et al.          Expires 11 September 2021               [Page 9]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

   [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>.

   [RFC8859]  Nandakumar, S., "A Framework for Session Description
              Protocol (SDP) Attributes When Multiplexing", RFC 8859,
              DOI 10.17487/RFC8859, January 2021,
              <https://www.rfc-editor.org/info/rfc8859>.

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

Uberti, et al.          Expires 11 September 2021              [Page 10]
Internet-Draft  Completely Encrypting RTP Header Extensi      March 2021

   Cullen Jennings
   Cisco

   Email: fluffy@iii.ca

   Sergio Garcia Murillo
   CoSMo

   Email: sergio.garcia.murillo@cosmosoftware.io

Uberti, et al.          Expires 11 September 2021              [Page 11]