doc: Add RFC documents

1 files changed, 879 insertions, 0 deletions

diff --git a/doc/rfc/rfc8723.txt b/doc/rfc/rfc8723.txt
new file mode 100644
index 0000000..cf9d33a
--- /dev/null
+++ b/doc/rfc/rfc8723.txt
@@ -0,0 +1,879 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Jennings
+Request for Comments: 8723                                      P. Jones
+Category: Standards Track                                      R. Barnes
+ISSN: 2070-1721                                            Cisco Systems
+                                                              A.B. Roach
+                                                                 Mozilla
+                                                              April 2020
+
+
+Double Encryption Procedures for the Secure Real-Time Transport Protocol
+                                 (SRTP)
+
+Abstract
+
+   In some conferencing scenarios, it is desirable for an intermediary
+   to be able to manipulate some parameters in Real-time Transport
+   Protocol (RTP) packets, while still providing strong end-to-end
+   security guarantees.  This document defines a cryptographic transform
+   for the Secure Real-time Transport Protocol (SRTP) that uses two
+   separate but related cryptographic operations to provide hop-by-hop
+   and end-to-end security guarantees.  Both the end-to-end and hop-by-
+   hop cryptographic algorithms can utilize an authenticated encryption
+   with associated data (AEAD) algorithm or take advantage of future
+   SRTP transforms with different properties.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   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/rfc8723.
+
+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.  Terminology
+   3.  Cryptographic Context
+     3.1.  Key Derivation
+   4.  Original Header Block
+   5.  RTP Operations
+     5.1.  Encrypting a Packet
+     5.2.  Relaying a Packet
+     5.3.  Decrypting a Packet
+   6.  RTCP Operations
+   7.  Use with Other RTP Mechanisms
+     7.1.  RTP Retransmission (RTX)
+     7.2.  Redundant Audio Data (RED)
+     7.3.  Forward Error Correction (FEC)
+     7.4.  DTMF
+   8.  Recommended Inner and Outer Cryptographic Algorithms
+   9.  Security Considerations
+   10. IANA Considerations
+     10.1.  DTLS-SRTP
+   11. References
+     11.1.  Normative References
+     11.2.  Informative References
+   Appendix A.  Encryption Overview
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   Cloud conferencing systems that are based on switched conferencing
+   have a central Media Distributor (MD) device that receives media from
+   endpoints and distributes it to other endpoints, but does not need to
+   interpret or change the media content.  For these systems, it is
+   desirable to have one cryptographic key that enables encryption and
+   authentication of the media end-to-end while still allowing certain
+   information in the header of an RTP packet to be changed by the MD.
+   At the same time, a separate cryptographic key provides integrity and
+   optional confidentiality for the media flowing between the MD and the
+   endpoints.  The framework document [PRIVATE-MEDIA-FRAMEWORK]
+   describes this concept in more detail.
+
+   This specification defines a transform for SRTP that uses 1) the AES
+   Galois/Counter Mode (AES-GCM) algorithm [RFC7714] to provide
+   encryption and integrity for an RTP packet for the end-to-end
+   cryptographic key and 2) a hop-by-hop cryptographic encryption and
+   integrity between the endpoint and the MD.  The MD decrypts and
+   checks integrity of the hop-by-hop security.  The MD MAY change some
+   of the RTP header information that would impact the end-to-end
+   integrity.  In that case, the original value of any RTP header field
+   that is changed is included in an "Original Header Block" that is
+   added to the packet.  The new RTP packet is encrypted with the hop-
+   by-hop cryptographic algorithm before it is sent.  The receiving
+   endpoint decrypts and checks integrity using the hop-by-hop
+   cryptographic algorithm and then replaces any parameters the MD
+   changed using the information in the Original Header Block before
+   decrypting and checking the end-to-end integrity.
+
+   One can think of the double transform as a normal SRTP transform for
+   encrypting the RTP in a way such that things that only know half of
+   the key, can decrypt and modify part of the RTP packet but not other
+   parts, including the media payload.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Terms used throughout this document include:
+
+   Media Distributor (MD):  A device that receives media from endpoints
+      and distributes it to other endpoints, but does not need to
+      interpret or change the media content (see also
+      [PRIVATE-MEDIA-FRAMEWORK]).
+
+   end-to-end:  The path from one endpoint through one or more MDs to
+      the endpoint at the other end.
+
+   hop-by-hop:  The path from the endpoint to or from the MD.
+
+   Original Header Block (OHB):  An octet string that contains the
+      original values from the RTP header that might have been changed
+      by an MD.
+
+3.  Cryptographic Context
+
+   This specification uses a cryptographic context with two parts:
+
+   *  An inner (end-to-end) part that is used by endpoints that
+      originate and consume media to ensure the integrity of media end-
+      to-end, and
+
+   *  An outer (hop-by-hop) part that is used between endpoints and MDs
+      to ensure the integrity of media over a single hop and to enable
+      an MD to modify certain RTP header fields.  RTCP is also handled
+      using the hop-by-hop cryptographic part.
+
+   The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithms
+   is AES-GCM.  Other combinations of SRTP ciphers that support the
+   procedures in this document can be added to the IANA registry.
+
+   The keys and salt for these algorithms are generated with the
+   following steps:
+
+   *  Generate key and salt values of the length required for the
+      combined inner (end-to-end) and outer (hop-by-hop) algorithms.
+
+   *  Assign the key and salt values generated for the inner (end-to-
+      end) algorithm to the first half of the key and the first half of
+      the salt for the double algorithm.
+
+   *  Assign the key and salt values for the outer (hop-by-hop)
+      algorithm to the second half of the key and second half of the
+      salt for the double algorithm.  The first half of the key is
+      referred to as the inner key while the second half is referred to
+      as the outer key.  When a key is used by a cryptographic
+      algorithm, the salt that is used is the part of the salt generated
+      with that key.
+
+   *  the synchronization source (SSRC) is the same for both the inner
+      and outer algorithms as it cannot be changed.
+
+   *  The sequence number (SEQ) and rollover counter (ROC) are tracked
+      independently for the inner and outer algorithms.
+
+   If the MD is to be able to modify header fields but not decrypt the
+   payload, then it must have a cryptographic key for the outer
+   algorithm but not the inner (end-to-end) algorithm.  This document
+   does not define how the MD should be provisioned with this
+   information.  One possible way to provide keying material for the
+   outer (hop-by-hop) algorithm is to use [DTLS-TUNNEL].
+
+3.1.  Key Derivation
+
+   Although SRTP uses a single master key to derive keys for an SRTP
+   session, this transform requires separate inner and outer keys.  In
+   order to allow the inner and outer keys to be managed independently
+   via the master key, the transforms defined in this document MUST be
+   used with the following pseudorandom function (PRF), which preserves
+   the separation between the two halves of the key.  Given a positive
+   integer "n" representing the desired output length, a master key
+   "k_master", and an input "x":
+
+        PRF_double_n(k_master,x) = PRF_(n/2)(inner(k_master),x) ||
+                                   PRF_(n/2)(outer(k_master),x)
+
+   Here "PRF_double_n(k_master, x)" represents the AES_CM PRF Key
+   Derivation Function (KDF) (see Section 4.3.3 of [RFC3711]) for
+   DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF
+   KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm.
+   The term "inner(k_master)" represents the first half of the key;
+   "outer(k_master)" represents the second half of the key.
+
+4.  Original Header Block
+
+   The OHB contains the original values of any modified RTP header
+   fields.  In the encryption process, the OHB is included in an SRTP
+   packet as described in Section 5.  In the decryption process, the
+   receiving endpoint uses it to reconstruct the original RTP header so
+   that it can pass the proper additional authenticated data (AAD) value
+   to the inner transform.
+
+   The OHB can reflect modifications to the following fields in an RTP
+   header: the payload type (PT), the SEQ, and the marker bit.  All
+   other fields in the RTP header MUST remain unmodified; since the OHB
+   cannot reflect their original values, the receiver will be unable to
+   verify the end-to-end integrity of the packet.
+
+   The OHB has the following syntax (in ABNF [RFC5234]):
+
+   OCTET = %x00-FF
+
+   PT = OCTET
+   SEQ = 2OCTET
+   Config = OCTET
+   OHB = [ PT ] [ SEQ ] Config
+
+   If present, the PT and SEQ parts of the OHB contain the original
+   payload type and sequence number fields, respectively.  The final
+   "Config" octet of the OHB specifies whether these fields are present,
+   and the original value of the marker bit (if necessary):
+
+   +-+-+-+-+-+-+-+-+
+   |R R R R B M P Q|
+   +-+-+-+-+-+-+-+-+
+
+   *  P: PT is present
+
+   *  Q: SEQ is present
+
+   *  M: Marker bit is present
+
+   *  B: Value of marker bit
+
+   *  R: Reserved, MUST be set to 0
+
+   In particular, an all-zero OHB Config octet ("0x00") indicates that
+   there have been no modifications from the original header.
+
+   If the marker bit is not present (M=0), then "B" MUST be set to zero.
+   That is, if "C" represents the value of the Config octet, then the
+   masked value "C & 0x0C" MUST NOT have the value "0x80".
+
+5.  RTP Operations
+
+   As implied by the use of the word "double" above, this transform
+   applies AES-GCM to the SRTP packet twice.  This allows media
+   distributors to be able to modify some header fields while allowing
+   endpoints to verify the end-to-end integrity of a packet.
+
+   The first, "inner" application of AES-GCM encrypts the SRTP payload
+   and protects the integrity of a version of the SRTP header with
+   extensions truncated.  Omitting extensions from the inner integrity
+   check means that they can be modified by an MD holding only the outer
+   key.
+
+   The second, "outer" application of AES-GCM encrypts the ciphertext
+   produced by the inner encryption (i.e., the encrypted payload and
+   authentication tag), plus an OHB that expresses any changes made
+   between the inner and outer transforms.
+
+   An MD that has the outer key but not the inner key may modify the
+   header fields that can be included in the OHB by decrypting,
+   modifying, and re-encrypting the packet.
+
+5.1.  Encrypting a Packet
+
+   An endpoint encrypts a packet by using the inner (end-to-end)
+   cryptographic key and then the outer (hop-by-hop) cryptographic key.
+   The encryption also supports a mode for repair packets that only does
+   the outer (hop-by-hop) encryption.  The processes is as follows:
+
+   1.  Form an RTP packet.  If there are any header extensions, they
+       MUST use [RFC8285].
+
+   2.  If the packet is for repair mode data, skip to step 6.
+
+   3.  Form a synthetic RTP packet with the following contents:
+
+       *  Header: The RTP header of the original packet with the
+          following modifications:
+
+          -  The X bit is set to zero.
+
+          -  The header is truncated to remove any extensions (i.e.,
+             keep only the first 12 + 4 * CSRC count (CC) bytes of the
+             header).
+
+       *  Payload: The RTP payload of the original packet (including
+          padding when present).
+
+   4.  Apply the inner cryptographic algorithm to the synthetic RTP
+       packet from the previous step.
+
+   5.  Replace the header of the protected RTP packet with the header of
+       the original packet (to restore any header extensions and reset
+       the X bit), and append an empty OHB ("0x00") to the encrypted
+       payload (with the authentication tag) obtained from step 4.
+
+   6.  Apply the outer cryptographic algorithm to the RTP packet.  If
+       encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST
+       be used when encrypting the RTP packet using the outer
+       cryptographic key.
+
+   When using Encrypted Key Transport (EKT) [EKT-SRTP], the EKTField
+   comes after the SRTP packet, exactly like using EKT with any other
+   SRTP transform.
+
+5.2.  Relaying a Packet
+
+   The MD has the part of the key for the outer (hop-by-hop)
+   cryptographic algorithm, but it does not have the part of the key for
+   the inner (end-to-end) cryptographic algorithm.  The cryptographic
+   algorithm and key used to decrypt a packet and any encrypted RTP
+   header extensions would be the same as those used in the endpoint's
+   outer algorithm and key.
+
+   In order to modify a packet, the MD decrypts the received packet,
+   modifies the packet, updates the OHB with any modifications not
+   already present in the OHB, and re-encrypts the packet using the
+   outer (hop-by-hop) cryptographic key before transmitting using the
+   following steps:
+
+   1.  Apply the outer (hop-by-hop) cryptographic algorithm to decrypt
+       the packet.  If decrypting RTP header extensions hop-by-hop, then
+       [RFC6904] MUST be used.  Note that the RTP payload produced by
+       this decryption operation contains the original encrypted payload
+       with the tag from the inner transform and the OHB appended.
+
+   2.  Make any desired changes to the fields that are allowed to be
+       changed, i.e., PT, SEQ, and M.  The MD MAY also make
+       modifications to header extensions, without the need to reflect
+       these changes in the OHB.
+
+   3.  Reflect any changes to header fields in the OHB:
+
+       *  If the MD changed a field that is not already in the OHB, then
+          it MUST add the original value of the field to the OHB.  Note
+          that this might result in an increase in the size of the OHB.
+
+       *  If the MD took a field that had previously been modified and
+          reset to its original value, then it SHOULD drop the
+          corresponding information from the OHB.  Note that this might
+          result in a decrease in the size of the OHB.
+
+       *  Otherwise, the MD MUST NOT modify the OHB.
+
+   4.  Apply the outer (hop-by-hop) cryptographic algorithm to the
+       packet.  If the RTP sequence number has been modified, SRTP
+       processing happens as defined in SRTP and will end up using the
+       new sequence number.  If encrypting RTP header extensions hop-by-
+       hop, then [RFC6904] MUST be used.
+
+   In order to avoid nonce reuse, the cryptographic contexts used in
+   steps 1 and 4 MUST use different, independent master keys.  Note that
+   this means that the key used for decryption by the MD MUST be
+   different from the key used for re-encryption to the end recipient.
+
+   Note that if multiple MDs modify the same packet, then the first MD
+   to alter a given header field is the one that adds it to the OHB.  If
+   a subsequent MD changes the value of a header field that has already
+   been changed, then the original value will already be in the OHB, so
+   no update to the OHB is required.
+
+   An MD that decrypts, modifies, and re-encrypts packets in this way
+   MUST use an independent key for each recipient, and MUST NOT re-
+   encrypt the packet using the sender's keys.  If the MD decrypts and
+   re-encrypts with the same key and salt, it will result in the reuse
+   of a (key, nonce) pair, undermining the security of AES-GCM.
+
+5.3.  Decrypting a Packet
+
+   To decrypt a packet, the endpoint first decrypts and verifies using
+   the outer (hop-by-hop) cryptographic key, then uses the OHB to
+   reconstruct the original packet, which it decrypts and verifies with
+   the inner (end-to-end) cryptographic key using the following steps:
+
+   1.  Apply the outer cryptographic algorithm to the packet.  If the
+       integrity check does not pass, discard the packet.  The result of
+       this is referred to as the outer SRTP packet.  If decrypting RTP
+       header extensions hop-by-hop, then [RFC6904] MUST be used when
+       decrypting the RTP packet using the outer cryptographic key.
+
+   2.  If the packet is for repair mode data, skip the rest of the
+       steps.  Note that the packet that results from the repair
+       algorithm will still have encrypted data that needs to be
+       decrypted as specified by the repair algorithm sections.
+
+   3.  Remove the inner authentication tag and the OHB from the end of
+       the payload of the outer SRTP packet.
+
+   4.  Form a new synthetic SRTP packet with:
+
+       *  Header = Received header, with the following modifications:
+
+          -  Header fields replaced with values from OHB (if any).
+
+          -  The X bit is set to zero.
+
+          -  The header is truncated to remove any extensions (i.e.,
+             keep only the first 12 + 4 * CC bytes of the header).
+
+       *  Payload is the encrypted payload from the outer SRTP packet
+          (after the inner tag and OHB have been stripped).
+
+       *  Authentication tag is the inner authentication tag from the
+          outer SRTP packet.
+
+   5.  Apply the inner cryptographic algorithm to this synthetic SRTP
+       packet.  Note if the RTP sequence number was changed by the MD,
+       the synthetic packet has the original sequence number.  If the
+       integrity check does not pass, discard the packet.
+
+   Once the packet has been successfully decrypted, the application
+   needs to be careful about which information it uses to get the
+   correct behavior.  The application MUST use only the information
+   found in the synthetic SRTP packet and MUST NOT use the other data
+   that was in the outer SRTP packet with the following exceptions:
+
+   *  The PT from the outer SRTP packet is used for normal matching to
+      Session Description Protocol (SDP) and codec selection.
+
+   *  The sequence number from the outer SRTP packet is used for normal
+      RTP ordering.
+
+   The PT and sequence number from the inner SRTP packet can be used for
+   collection of various statistics.
+
+   If the RTP header of the outer packet contains extensions, they MAY
+   be used.  However, because extensions are not protected end-to-end,
+   implementations SHOULD reject an RTP packet containing headers that
+   would require end-to-end protection.
+
+6.  RTCP Operations
+
+   Unlike RTP, which is encrypted both hop-by-hop and end-to-end using
+   two separate cryptographic keys, RTCP is encrypted using only the
+   outer (hop-by-hop) cryptographic key.  The procedures for RTCP
+   encryption are specified in [RFC3711], and this document introduces
+   no additional steps.
+
+7.  Use with Other RTP Mechanisms
+
+   MDs sometimes interact with RTP media packets sent by endpoints,
+   e.g., to provide recovery or receive commands via dual-tone multi-
+   frequency (DTMF) signaling.  When media packets are encrypted end-to-
+   end, these procedures require modification.  (End-to-end
+   interactions, including end-to-end recovery, are not affected by end-
+   to-end encryption.)
+
+   Repair mechanisms, in general, will need to perform recovery on
+   encrypted packets (double-encrypted when using this transform), since
+   the MD does not have access to the plaintext of the packet, only an
+   intermediate, E2E-encrypted form.
+
+   When the recovery mechanism calls for the recovery packet itself to
+   be encrypted, it is encrypted with only the outer, hop-by-hop key.
+   This allows an MD to generate recovery packets without having access
+   to the inner, end-to-end keys.  However, it also results in recovery
+   packets being triple-encrypted, twice for the base transform, and
+   once for the recovery protection.
+
+7.1.  RTP Retransmission (RTX)
+
+   When using RTX [RFC4588] with the double transform, the cached
+   payloads MUST be the double-encrypted packets, i.e., the bits that
+   are sent over the wire to the other side.  When encrypting a
+   retransmission packet, it MUST be encrypted like a packet in repair
+   mode (i.e., with only the hop-by-hop key).
+
+   If the MD were to cache the inner, E2E-encrypted payload and
+   retransmit it with an RTX original sequence number field prepended,
+   then the modifications to the payload would cause the inner integrity
+   check to fail at the receiver.
+
+   A typical RTX receiver would decrypt the packet, undo the RTX
+   transformation, then process the resulting packet normally by using
+   the steps in Section 5.3.
+
+7.2.  Redundant Audio Data (RED)
+
+   When using RED [RFC2198] with the double transform, the processing at
+   the sender and receiver is the same as when using RED with any other
+   SRTP transform.
+
+   The main difference between the double transform and any other
+   transform is that in an intermediated environment, usage of RED must
+   be end-to-end.  An MD cannot synthesize RED packets, because it lacks
+   access to the plaintext media payloads that are combined to form a
+   RED payload.
+
+   Note that Flexible Forward Error Correction (Flex FEC) may often
+   provide similar or better repair capabilities compared to RED.  For
+   most applications, Flex FEC is a better choice than RED; in
+   particular, Flex FEC has modes in which the MD can synthesize
+   recovery packets.
+
+7.3.  Forward Error Correction (FEC)
+
+   When using Flex FEC [RFC8627] with the double transform, repair
+   packets MUST be constructed by first double-encrypting the packet,
+   then performing FEC.  Processing of repair packets proceeds in the
+   opposite order, performing FEC recovery and then decrypting.  This
+   ensures that the original media is not revealed to the MD but, at the
+   same time, allows the MD to repair media.  When encrypting a packet
+   that contains the Flex FEC data, which is already encrypted, it MUST
+   be encrypted with only the outer, hop-by-hop transform.
+
+   The algorithm recommended in [WEBRTC-FEC] for repair of video is Flex
+   FEC [RFC8627].  Note that for interoperability with WebRTC,
+   [WEBRTC-FEC] recommends not using additional FEC-only "m=" lines in
+   SDP for the repair packets.
+
+7.4.  DTMF
+
+   When DTMF is sent using the mechanism in [RFC4733], it is end-to-end
+   encrypted; the relay cannot read it, so it cannot be used to control
+   the relay.  Other out-of-band methods to control the relay need to be
+   used instead.
+
+8.  Recommended Inner and Outer Cryptographic Algorithms
+
+   This specification recommends and defines AES-GCM as both the inner
+   and outer cryptographic algorithms, identified as
+   DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
+   DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM.  These algorithms provide
+   for authenticated encryption and will consume additional processing
+   time double-encrypting for hop-by-hop and end-to-end.  However, the
+   approach is secure and simple; thus, it is viewed as an acceptable
+   trade-off in processing efficiency.
+
+   Note that names for the cryptographic transforms are of the form
+   DOUBLE_(inner algorithm)_(outer algorithm).
+
+   While this document only defines a profile based on AES-GCM, it is
+   possible for future documents to define further profiles with
+   different inner and outer algorithms in this same framework.  For
+   example, if a new SRTP transform were defined that encrypts some or
+   all of the RTP header, it would be reasonable for systems to have the
+   option of using that for the outer algorithm.  Similarly, if a new
+   transform were defined that provided only integrity, that would also
+   be reasonable to use for the outer transform as the payload data is
+   already encrypted by the inner transform.
+
+   The AES-GCM cryptographic algorithm introduces an additional 16
+   octets to the length of the packet.  When using AES-GCM for both the
+   inner and outer cryptographic algorithms, the total additional length
+   is 32 octets.  The OHB will consume an additional 1-4 octets.
+   Packets in repair mode will carry additional repair data, further
+   increasing their size.
+
+9.  Security Considerations
+
+   This SRTP transform provides protection against two classes of
+   attacker: a network attacker that knows neither the inner nor outer
+   keys and a malicious MD that knows the outer key.  Obviously, it
+   provides no protections against an attacker that holds both the inner
+   and outer keys.
+
+   The protections with regard to the network are the same as with the
+   normal SRTP AES-GCM transforms.  The major difference is that the
+   double transforms are designed to work better in a group context.  In
+   such contexts, it is important to note that because these transforms
+   are symmetric, they do not protect against attacks within the group.
+   Any member of the group can generate valid SRTP packets for any SSRC
+   in use by the group.
+
+   With regard to a malicious MD, the recipient can verify the integrity
+   of the base header fields and confidentiality and integrity of the
+   payload.  The recipient has no assurance, however, of the integrity
+   of the header extensions in the packet.
+
+   The main innovation of this transform relative to other SRTP
+   transforms is that it allows a partly trusted MD to decrypt, modify,
+   and re-encrypt a packet.  When this is done, the cryptographic
+   contexts used for decryption and re-encryption MUST use different,
+   independent master keys.  If the same context is used, the nonce
+   formation rules for SRTP will cause the same key and nonce to be used
+   with two different plaintexts, which substantially degrades the
+   security of AES-GCM.
+
+   In other words, from the perspective of the MD, re-encrypting packets
+   using this protocol will involve the same cryptographic operations as
+   if it had established independent AES-GCM crypto contexts with the
+   sender and the receiver.  This property allows the use of an MD that
+   supports AES-GCM but does not modify any header fields, without
+   requiring any modification to the MD.
+
+10.  IANA Considerations
+
+10.1.  DTLS-SRTP
+
+   IANA has added the following protection profiles to the "DTLS-SRTP
+   Protection Profiles" registry defined in [RFC5764].
+
+     +--------+------------------------------------------+-----------+
+     | Value  | Profile                                  | Reference |
+     +========+==========================================+===========+
+     | {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFC 8723  |
+     | 0x09}  |                                          |           |
+     +--------+------------------------------------------+-----------+
+     | {0x00, | DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM | RFC 8723  |
+     | 0x0A}  |                                          |           |
+     +--------+------------------------------------------+-----------+
+
+       Table 1: Updates to the DTLS-SRTP Protection Profiles Registry
+
+   The SRTP transform parameters for each of these protection profiles
+   are:
+
+        +---------------------------------------------------------+
+        | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM                |
+        +-----------------------+---------------------------------+
+        | cipher:               | AES_128_GCM then AES_128_GCM    |
+        +-----------------------+---------------------------------+
+        | cipher_key_length:    | 256 bits                        |
+        +-----------------------+---------------------------------+
+        | cipher_salt_length:   | 192 bits                        |
+        +-----------------------+---------------------------------+
+        | aead_auth_tag_length: | 256 bits                        |
+        +-----------------------+---------------------------------+
+        | auth_function:        | NULL                            |
+        +-----------------------+---------------------------------+
+        | auth_key_length:      | N/A                             |
+        +-----------------------+---------------------------------+
+        | auth_tag_length:      | N/A                             |
+        +-----------------------+---------------------------------+
+        | maximum lifetime:     | at most 2^(31) SRTCP packets    |
+        |                       | and at most 2^(48) SRTP packets |
+        +-----------------------+---------------------------------+
+
+                   Table 2: SRTP Transform Parameters for
+                  DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM
+
+        +---------------------------------------------------------+
+        | DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM                |
+        +-----------------------+---------------------------------+
+        | cipher:               | AES_256_GCM then AES_256_GCM    |
+        +-----------------------+---------------------------------+
+        | cipher_key_length:    | 512 bits                        |
+        +-----------------------+---------------------------------+
+        | cipher_salt_length:   | 192 bits                        |
+        +-----------------------+---------------------------------+
+        | aead_auth_tag_length: | 256 bits                        |
+        +-----------------------+---------------------------------+
+        | auth_function:        | NULL                            |
+        +-----------------------+---------------------------------+
+        | auth_key_length:      | N/A                             |
+        +-----------------------+---------------------------------+
+        | auth_tag_length:      | N/A                             |
+        +-----------------------+---------------------------------+
+        | maximum lifetime:     | at most 2^(31) SRTCP packets    |
+        |                       | and at most 2^(48) SRTP packets |
+        +-----------------------+---------------------------------+
+
+                   Table 3: SRTP Transform Parameters for
+                  DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM
+
+   The first half of the key and salt is used for the inner (end-to-end)
+   algorithm and the second half is used for the outer (hop-by-hop)
+   algorithm.
+
+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>.
+
+   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
+              Security (DTLS) Extension to Establish Keys for the Secure
+              Real-time Transport Protocol (SRTP)", RFC 5764,
+              DOI 10.17487/RFC5764, May 2010,
+              <https://www.rfc-editor.org/info/rfc5764>.
+
+   [RFC6188]  McGrew, D., "The Use of AES-192 and AES-256 in Secure
+              RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011,
+              <https://www.rfc-editor.org/info/rfc6188>.
+
+   [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>.
+
+   [RFC7714]  McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
+              in the Secure Real-time Transport Protocol (SRTP)",
+              RFC 7714, DOI 10.17487/RFC7714, December 2015,
+              <https://www.rfc-editor.org/info/rfc7714>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [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>.
+
+11.2.  Informative References
+
+   [DTLS-TUNNEL]
+              Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
+              between a Media Distributor and Key Distributor to
+              Facilitate Key Exchange", Work in Progress, Internet-
+              Draft, draft-ietf-perc-dtls-tunnel-06, 16 October 2019,
+              <https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel-
+              06>.
+
+   [EKT-SRTP] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
+              Andreasen, "Encrypted Key Transport for DTLS and Secure
+              RTP", Work in Progress, Internet-Draft, draft-ietf-perc-
+              srtp-ekt-diet-10, 8 July 2019,
+              <https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-
+              diet-10>.
+
+   [PRIVATE-MEDIA-FRAMEWORK]
+              Jones, P., Benham, D., and C. Groves, "A Solution
+              Framework for Private Media in Privacy Enhanced RTP
+              Conferencing (PERC)", Work in Progress, Internet-Draft,
+              draft-ietf-perc-private-media-framework-12, 5 June 2019,
+              <https://tools.ietf.org/html/draft-ietf-perc-private-
+              media-framework-12>.
+
+   [RFC2198]  Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
+              Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-
+              Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
+              DOI 10.17487/RFC2198, September 1997,
+              <https://www.rfc-editor.org/info/rfc2198>.
+
+   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+              DOI 10.17487/RFC4588, July 2006,
+              <https://www.rfc-editor.org/info/rfc4588>.
+
+   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
+              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
+              DOI 10.17487/RFC4733, December 2006,
+              <https://www.rfc-editor.org/info/rfc4733>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC8627]  Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP
+              Payload Format for Flexible Forward Error Correction
+              (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019,
+              <https://www.rfc-editor.org/info/rfc8627>.
+
+   [WEBRTC-FEC]
+              Uberti, J., "WebRTC Forward Error Correction
+              Requirements", Work in Progress, Internet-Draft, draft-
+              ietf-rtcweb-fec-10, 16 July 2019,
+              <https://tools.ietf.org/html/draft-ietf-rtcweb-fec-10>.
+
+Appendix A.  Encryption Overview
+
+   The following figures show a double-encrypted SRTP packet.  The sides
+   indicate the parts of the packet that are encrypted and authenticated
+   by the hop-by-hop and end-to-end operations.
+
+        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             |
+       |                               ....                            |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                    RTP extension (OPTIONAL) ...               |
+   +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   O I |                          payload ...                          |
+   O I |                               +-------------------------------+
+   O I |                               | RTP padding   | RTP pad count |
+   O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   O | |                    E2E authentication tag                     |
+   O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   O | |                            OHB ...                            |
+   +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | | |                    HBH authentication tag                     |
+   | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | |
+   | +- E2E Encrypted Portion
+   |
+   +--- HBH Encrypted Portion
+
+    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         | I O
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I O
+   |                           timestamp                           | I O
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I O
+   |           synchronization source (SSRC) identifier            | I O
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ I O
+   |            contributing source (CSRC) identifiers             | I O
+   |                               ....                            | I O
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O
+   |                    RTP extension (OPTIONAL) ...               | | O
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O
+   |                           payload ...                         | I O
+   |                               +-------------------------------+ I O
+   |                               | RTP padding   | RTP pad count | I O
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O
+   |                    E2E authentication tag                     | | O
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O
+   |                            OHB ...                            | | O
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<+
+   |                    HBH authentication tag                     | | |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+                                                                     | |
+                                        E2E Authenticated Portion ---+ |
+                                                                       |
+                                        HBH Authenticated Portion -----+
+
+Acknowledgments
+
+   Thank you to Alex Gouaillard, David Benham, Magnus Westerlund, Nils
+   Ohlmeier, Roni Even, and Suhas Nandakumar for reviews and
+   improvements to this specification.  In addition, thank you to Sergio
+   Garcia Murillo, who proposed the change of transporting the OHB
+   information in the RTP payload instead of the RTP header.
+
+Authors' Addresses
+
+   Cullen Jennings
+   Cisco Systems
+
+   Email: fluffy@iii.ca
+
+
+   Paul E. Jones
+   Cisco Systems
+
+   Email: paulej@packetizer.com
+
+
+   Richard Barnes
+   Cisco Systems
+
+   Email: rlb@ipv.sx
+
+
+   Adam Roach
+   Mozilla
+
+   Email: adam@nostrum.com