draft-ietf-perc-double-09.txt   draft-ietf-perc-double-10.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft P. Jones Internet-Draft P. Jones
Intended status: Standards Track R. Barnes Intended status: Standards Track R. Barnes
Expires: November 4, 2018 Cisco Systems Expires: April 20, 2019 Cisco Systems
A. Roach A. Roach
Mozilla Mozilla
May 3, 2018 October 17, 2018
SRTP Double Encryption Procedures SRTP Double Encryption Procedures
draft-ietf-perc-double-09 draft-ietf-perc-double-10
Abstract Abstract
In some conferencing scenarios, it is desirable for an intermediary In some conferencing scenarios, it is desirable for an intermediary
to be able to manipulate some RTP parameters, while still providing to be able to manipulate some parameters in Real Time Protocol (RTP)
strong end-to-end security guarantees. This document defines SRTP packets, while still providing strong end-to-end security guarantees.
procedures that use two separate but related cryptographic operations This document defines a cryptographic transform for the Secure Real
to provide hop-by-hop and end-to-end security guarantees. Both the Time Protocol (SRTP) that uses two separate but related cryptographic
end-to-end and hop-by-hop cryptographic algorithms can utilize an operations to provide hop-by-hop and end-to-end security guarantees.
authenticated encryption with associated data scheme or take Both the end-to-end and hop-by-hop cryptographic algorithms can
advantage of future SRTP transforms with different properties. utilize an authenticated encryption with associated data scheme or
take advantage of future SRTP transforms with different properties.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2018. This Internet-Draft will expire on April 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Cryptographic Context . . . . . . . . . . . . . . . . . . . . 4 3. Cryptographic Context . . . . . . . . . . . . . . . . . . . . 4
3.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 5 3.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 5
4. Original Header Block . . . . . . . . . . . . . . . . . . . . 5 4. Original Header Block . . . . . . . . . . . . . . . . . . . . 5
5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 6 5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 6 5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 7
5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 7 5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 8
5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 8 5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 9
6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 9 6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 10
7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 9 7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 10
7.1. RTX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. RTP Retransmission (RTX) . . . . . . . . . . . . . . . . 11
7.2. RED . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Redundant Audio Data (RED) . . . . . . . . . . . . . . . 11
7.3. FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Forward Error Correction (FEC) . . . . . . . . . . . . . 11
7.4. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Recommended Inner and Outer Cryptographic Algorithms . . . . 11 8. Recommended Inner and Outer Cryptographic Algorithms . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Encryption Overview . . . . . . . . . . . . . . . . 16 Appendix A. Encryption Overview . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Cloud conferencing systems that are based on switched conferencing Cloud conferencing systems that are based on switched conferencing
have a central Media Distributor device that receives media from have a central Media Distributor device that receives media from
endpoints and distributes it to other endpoints, but does not need to endpoints and distributes it to other endpoints, but does not need to
interpret or change the media content. For these systems, it is interpret or change the media content. For these systems, it is
desirable to have one cryptographic key from the sending endpoint to desirable to have one cryptographic key from the sending endpoint to
the receiving endpoint that can encrypt and authenticate the media the receiving endpoint that can encrypt and authenticate the media
end-to-end while still allowing certain RTP header information to be end-to-end while still allowing certain information in the header of
changed by the Media Distributor. At the same time, a separate a Real Time Protocol (RTP) packet to be changed by the Media
cryptographic key provides integrity and optional confidentiality for Distributor. At the same time, a separate cryptographic key provides
the media flowing between the Media Distributor and the endpoints. integrity and optional confidentiality for the media flowing between
the Media Distributor and the endpoints. The framework document
The framework document [I-D.ietf-perc-private-media-framework] [I-D.ietf-perc-private-media-framework] describes this concept in
describes this concept in more detail. more detail.
This specification defines an SRTP transform that uses the AES-GCM This specification defines a transform for the Secure Real Time
algorithm [RFC7714] to provide encryption and integrity for an RTP Protocol (SRTP) that uses the AES-GCM algorithm [RFC7714] to provide
packet for the end-to-end cryptographic key as well as a hop-by-hop encryption and integrity for an RTP packet for the end-to-end
cryptographic encryption and integrity between the endpoint and the cryptographic key as well as a hop-by-hop cryptographic encryption
Media Distributor. The Media Distributor decrypts and checks and integrity between the endpoint and the Media Distributor. The
integrity of the hop-by-hop security. The Media Distributor MAY Media Distributor decrypts and checks integrity of the hop-by-hop
change some of the RTP header information that would impact the end- security. The Media Distributor MAY change some of the RTP header
to-end integrity. In that case, the original value of any RTP header information that would impact the end-to-end integrity. In that
field that is changed is included in a new RTP header extension case, the original value of any RTP header field that is changed is
called the Original Header Block. The new RTP packet is encrypted included in a new RTP header extension called the Original Header
with the hop-by-hop cryptographic algorithm before it is sent. The Block. The new RTP packet is encrypted with the hop-by-hop
receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm before it is sent. The receiving endpoint
cryptographic algorithm and then replaces any parameters the Media decrypts and checks integrity using the hop-by-hop cryptographic
Distributor changed using the information in the Original Header algorithm and then replaces any parameters the Media Distributor
Block before decrypting and checking the end-to-end integrity. changed using the information in the Original Header Block before
decrypting and checking the end-to-end integrity.
One can think of the double as a normal SRTP transform for encrypting One can think of the double as a normal SRTP transform for encrypting
the RTP in a way where things that only know half of the key, can the RTP in a way where things that only know half of the key, can
decrypt and modify part of the RTP packet but not other parts, decrypt and modify part of the RTP packet but not other parts,
including the media payload. including the media payload.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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: Terms used throughout this document include:
o Media Distributor: media distribution device that routes media o Media Distributor: A device that receives media from endpoints and
from one endpoint to other endpoints distributes it to other endpoints, but does not need to interpret
or change the media content (see also
[I-D.ietf-perc-private-media-framework])
o end-to-end: meaning the link from one endpoint through one or more o end-to-end: The path from one endpoint through one or more Media
Media Distributors to the endpoint at the other end. Distributors to the endpoint at the other end.
o hop-by-hop: meaning the link from the endpoint to or from the o hop-by-hop: The path from the endpoint to or from the Media
Media Distributor. Distributor.
o OHB: Original Header Block is an octet string that contains the o Original Header Block (OHB): An octet string that contains the
original values from the RTP header that might have been changed original values from the RTP header that might have been changed
by a Media Distributor. by a Media Distributor.
3. Cryptographic Context 3. Cryptographic Context
This specification uses a cryptographic context with two parts: This specification uses a cryptographic context with two parts:
o An inner (end-to-end) part that is used by endpoints that o An inner (end-to-end) part that is used by endpoints that
originate and consume media to ensure the integrity of media end- originate and consume media to ensure the integrity of media end-
to-end, and to-end, and
skipping to change at page 4, line 47 skipping to change at page 4, line 51
as the outer key. When a key is used by a cryptographic as the outer key. When a key is used by a cryptographic
algorithm, the salt used is the part of the salt generated with algorithm, the salt used is the part of the salt generated with
that key. that key.
o the SSRC is the same for both the inner and out outer algorithms o the SSRC is the same for both the inner and out outer algorithms
as it can not be changed. as it can not be changed.
o The SEQ and ROC are tracked independently for the inner and outer o The SEQ and ROC are tracked independently for the inner and outer
algorithms. algorithms.
Obviously, if the Media Distributor is to be able to modify header If the Media Distributor is to be able to modify header fields but
fields but not decrypt the payload, then it must have cryptographic not decrypt the payload, then it must have cryptographic key for the
key for the outer algorithm, but not the inner (end-to-end) outer algorithm, but not the inner (end-to-end) algorithm. This
algorithm. This document does not define how the Media Distributor document does not define how the Media Distributor should be
should be provisioned with this information. One possible way to provisioned with this information. One possible way to provide
provide keying material for the outer (hop-by-hop) algorithm is to keying material for the outer (hop-by-hop) algorithm is to use
use [I-D.ietf-perc-dtls-tunnel]. [I-D.ietf-perc-dtls-tunnel].
3.1. Key Derivation 3.1. Key Derivation
In order to allow the inner and outer keys to be managed In order to allow the inner and outer keys to be managed
independently via the master key, the transforms defined in this independently via the master key, the transforms defined in this
document MUST be used with the following PRF, which preserves the document MUST be used with the following pseudo-random function
separation between the two halves of the key: (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_inner_(n/2)(k_master,x) || PRF_double_n(k_master,x) = PRF_inner_(n/2)(k_master,x) ||
PRF_outer_(n/2)(k_master,x) PRF_outer_(n/2)(k_master,x)
PRF_inner_n(k_master,x) = PRF_n(inner(k_master),x) PRF_inner_n(k_master,x) = PRF_n(inner(k_master),x)
PRF_outer_n(k_master,x) = PRF_n(outer(k_master),x) PRF_outer_n(k_master,x) = PRF_n(outer(k_master),x)
Here "PRF_n(k, x)" represents the AES_CM PRF KDF [RFC3711] for Here "PRF_n(k, x)" represents the AES_CM PRF KDF [RFC3711] for
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF 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. KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm.
skipping to change at page 6, line 26 skipping to change at page 6, line 36
o B: Value of marker bit o B: Value of marker bit
o R: Reserved, MUST be set to 0 o R: Reserved, MUST be set to 0
In particular, an all-zero OHB config octet (0x00) indicates that In particular, an all-zero OHB config octet (0x00) indicates that
there have been no modifications from the original header. there have been no modifications from the original header.
5. RTP Operations 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 and confidentiality of a
packet.
The first, "inner" application of AES-GCM encrypts the SRTP payload
and integrity-protects a version of the SRTP header with extensions
truncated. Omitting extensions from the inner integrity check means
that they can be modified by a media distributor 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.
A media distributor 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 5.1. Encrypting a Packet
To encrypt a packet, the endpoint encrypts the packet using the inner To encrypt a packet, the endpoint encrypts the packet using the inner
(end-to-end) cryptographic key and then encrypts using the outer (end-to-end) cryptographic key and then encrypts using the outer
(hop-by-hop) cryptographic key. The encryption also supports a mode (hop-by-hop) cryptographic key. The encryption also supports a mode
for repair packets that only does the outer (hop-by-hop) encryption. for repair packets that only does the outer (hop-by-hop) encryption.
The processes is as follows: The processes is as follows:
1. Form an RTP packet. If there are any header extensions, they 1. Form an RTP packet. If there are any header extensions, they
MUST use [RFC8285]. MUST use [RFC8285].
2. If the packet is for repair mode data, skip to step 6. 2. If the packet is for repair mode data, skip to step 6.
3. Form a synthetic RTP packet with the following contents: 3. Form a synthetic RTP packet with the following contents:
* Header: The RTP header of the original packet with the * Header: The RTP header of the original packet with the
following modifications: following modifications:
* The X bit is set to zero * The X bit is set to zero
* The header is truncated to remove any extensions (12 + 4 * CC * The header is truncated to remove any extensions (i.e., keep
bytes) only the first 12 + 4 * CC bytes of the header)
* Payload: The RTP payload of the original packet * Payload: The RTP payload of the original packet
4. Apply the inner cryptographic algorithm to the synthetic RTP 4. Apply the inner cryptographic algorithm to the synthetic RTP
packet from the previous step. packet from the previous step.
5. Replace the header of the protected RTP packet with the header of 5. Replace the header of the protected RTP packet with the header of
the original packet, and append an empty OHB (0x00) to the the original packet, and append an empty OHB (0x00) to the
encrypted payload (with the authentication tag) obtained from the encrypted payload (with the authentication tag) obtained from the
step 4. step 4.
skipping to change at page 7, line 43 skipping to change at page 8, line 26
modifications not already present in the OHB, and re-encrypts the modifications not already present in the OHB, and re-encrypts the
packet using the the outer (hop-by-hop) cryptographic key before packet using the the outer (hop-by-hop) cryptographic key before
transmitting. transmitting.
1. Apply the outer (hop-by-hop) cryptographic algorithm to decrypt 1. Apply the outer (hop-by-hop) cryptographic algorithm to decrypt
the packet. If decrypting RTP header extensions hop-by-hop, then the packet. If decrypting RTP header extensions hop-by-hop, then
[RFC6904] MUST be used. Note that the RTP payload produced by [RFC6904] MUST be used. Note that the RTP payload produced by
this decryption operation contains the original encrypted payload this decryption operation contains the original encrypted payload
with the tag from the inner transform and the OHB appended. with the tag from the inner transform and the OHB appended.
2. Change any parts of the RTP packet that the relay wishes to 2. Make any desired changes to the fields are allowed to be changed,
change and should be changed. i.e., PT, SEQ, and M.
3. A Media Distributor can add information to the OHB, but MUST NOT 3. A Media Distributor can add information to the OHB, but MUST NOT
change existing information in the OHB. If RTP value is changed change existing information in the OHB. If RTP value is changed
and not already in the OHB, then add it with its original value and not already in the OHB, then add it with its original value
to the OHB. to the OHB.
4. If the Media Distributor resets a parameter to its original 4. If the Media Distributor resets a parameter to its original
value, it MAY drop it from the OHB. Note that this might result value, it MAY drop it from the OHB. Note that this might result
in a decrease in the size of the OHB. in a decrease in the size of the OHB.
5. Apply the outer (hop-by-hop) cryptographic algorithm to the 5. Apply the outer (hop-by-hop) cryptographic algorithm to the
packet. If the RTP Sequence Number has been modified, SRTP packet. If the RTP Sequence Number has been modified, SRTP
processing happens as defined in SRTP and will end up using the processing happens as defined in SRTP and will end up using the
new Sequence Number. If encrypting RTP header extensions hop-by- new Sequence Number. If encrypting RTP header extensions hop-by-
hop, then [RFC6904] MUST be used. hop, then [RFC6904] MUST be used.
In order to avoid nonce reuse, the cryptographic contexts used in
step 1 and step 5 MUST use different, independent master keys and
master salts.
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.
A Media Distributor that decrypts, modifies, and re-encrypts packets
in this way MUST use an independent key for each recipient, SHOULD
use an independent salt for each recipient, and MUST NOT re-encrypt
the packet using the sender's keys. If the Media Distributor
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 GCM.
5.3. Decrypting a Packet 5.3. Decrypting a Packet
To decrypt a packet, the endpoint first decrypts and verifies using To decrypt a packet, the endpoint first decrypts and verifies using
the outer (hop-by-hop) cryptographic key, then uses the OHB to the outer (hop-by-hop) cryptographic key, then uses the OHB to
reconstruct the original packet, which it decrypts and verifies with reconstruct the original packet, which it decrypts and verifies with
the inner (end-to-end) cryptographic key. the inner (end-to-end) cryptographic key.
1. Apply the outer cryptographic algorithm to the packet. If the 1. Apply the outer cryptographic algorithm to the packet. If the
integrity check does not pass, discard the packet. The result of integrity check does not pass, discard the packet. The result of
this is referred to as the outer SRTP packet. If decrypting RTP this is referred to as the outer SRTP packet. If decrypting RTP
skipping to change at page 8, line 44 skipping to change at page 9, line 41
the payload of the outer SRTP packet. the payload of the outer SRTP packet.
4. Form a new synthetic SRTP packet with: 4. Form a new synthetic SRTP packet with:
* Header = Received header, with the following modifications: * Header = Received header, with the following modifications:
* Header fields replaced with values from OHB (if any) * Header fields replaced with values from OHB (if any)
* The X bit is set to zero * The X bit is set to zero
* The header is truncated to remove any extensions (12 + 4 * CC * The header is truncated to remove any extensions (i.e., keep
bytes) only the first 12 + 4 * CC bytes of the header)
* Payload is the encrypted payload from the outer SRTP packet * Payload is the encrypted payload from the outer SRTP packet
(after the inner tag and OHB have been stripped). (after the inner tag and OHB have been stripped).
* Authentication tag is the inner authentication tag from the * Authentication tag is the inner authentication tag from the
outer SRTP packet. outer SRTP packet.
5. Apply the inner cryptographic algorithm to this synthetic SRTP 5. Apply the inner cryptographic algorithm to this synthetic SRTP
packet. Note if the RTP Sequence Number was changed by the Media packet. Note if the RTP Sequence Number was changed by the Media
Distributor, the synthetic packet has the original Sequence Distributor, the synthetic packet has the original Sequence
skipping to change at page 9, line 26 skipping to change at page 10, line 22
o The PT from the outer SRTP packet is used for normal matching to o The PT from the outer SRTP packet is used for normal matching to
SDP and codec selection. SDP and codec selection.
o The sequence number from the outer SRTP packet is used for normal o The sequence number from the outer SRTP packet is used for normal
RTP ordering. RTP ordering.
The PT and sequence number from the inner SRTP packet can be used for The PT and sequence number from the inner SRTP packet can be used for
collection of various statistics. collection of various statistics.
If any of the following RTP headers extensions are found in the outer If the RTP header of the outer packet contains extensions, they MAY
SRTP packet, they MAY be used: be used. However, because extensions are not protected end-to-end,
implementations SHOULD reject an RTP packet containing headers that
o Mixer-to-client audio level indicators (See [RFC6465]) would require end-to-end protection.
6. RTCP Operations 6. RTCP Operations
Unlike RTP, which is encrypted both hop-by-hop and end-to-end using Unlike RTP, which is encrypted both hop-by-hop and end-to-end using
two separate cryptographic keys, RTCP is encrypted using only the two separate cryptographic keys, RTCP is encrypted using only the
outer (hop-by-hop) cryptographic key. The procedures for RTCP outer (hop-by-hop) cryptographic key. The procedures for RTCP
encryption are specified in [RFC3711] and this document introduces no encryption are specified in [RFC3711] and this document introduces no
additional steps. additional steps.
7. Use with Other RTP Mechanisms 7. Use with Other RTP Mechanisms
There are some RTP related extensions that need special consideration Media distributors sometimes interact with RTP media packets sent by
to be used by a relay when using the double transform due to the end- endpoints, e.g., to provide recovery or receive commands via DTMF.
to-end protection of the RTP. The repair mechanism, when used with When media packets are encrypted end-to-end, these procedures require
double, typically operates on the double encrypted data and encrypts modification.
them using only the HBH key. This results in three cryptography
operation happening to the repair data sent over the wire.
7.1. RTX Repair mechanisms, in general, will need to perform recovery on
encrypted packets (double-encrypted when using this transform). When
the recovery mechanism calls for the recovery packet itself to be
encrypted, it is encrypted with only the outer, HBH key. This allows
a media distributor to generate recovery packets without having
access to the inner, E2E 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 double, the cached payloads MUST be the When using RTX [RFC4588] with double, the cached payloads MUST be the
encrypted packets with the bits that are sent over the wire to the double-encrypted packets, i.e., the bits that are sent over the wire
other side. When encrypting a retransmission packet, it MUST be to the other side. When encrypting a retransmission packet, it MUST
encrypted the packet in repair mode. be encrypted the packet in repair mode (i.e., with only the HBH key).
A typical RTX receiver would decrypt the packet, undo the RTX A typical RTX receiver would decrypt the packet, undo the RTX
transformation, then process the resulting packet normally by using transformation, then process the resulting packet normally by using
the steps in Section 5.3. the steps in Section 5.3.
7.2. RED 7.2. Redundant Audio Data (RED)
When using RED [RFC2198] with double, the primary encoding MAY When using RED [RFC2198] with double, the primary encoding MAY
contain RTP header extensions and CSRC identifiers but non primary contain RTP header extensions and CSRC identifiers but non primary
encodings cannot. encodings cannot.
The sender takes encrypted payload from the cached packets to form The sender takes encrypted payload from the cached packets to form
the RED payload. Any header extensions from the primary encoding are the RED payload. Any header extensions from the primary encoding are
copied to the RTP packet that will carry the RED payload and the copied to the RTP packet that will carry the RED payload and the
other RTP header information such as SSRC, SEQ, CSRC, etc are set to other RTP header information such as SSRC, SEQ, CSRC, etc are set to
the same as the primary payload. The RED RTP packet is then the same as the primary payload. The RED RTP packet is then
skipping to change at page 10, line 42 skipping to change at page 11, line 47
from inside the RED payload corresponding to the redundant encoding from inside the RED payload corresponding to the redundant encoding
are used to from the non primary payloads. The time offset and are used to from the non primary payloads. The time offset and
packet rate information in the RED data MUST be used to adjust the packet rate information in the RED data MUST be used to adjust the
sequence number in the RTP header. At this point the non primary sequence number in the RTP header. At this point the non primary
packets can be decrypted with double. packets can be decrypted with double.
Note that Flex FEC [I-D.ietf-payload-flexible-fec-scheme] is a Note that Flex FEC [I-D.ietf-payload-flexible-fec-scheme] is a
superset of the capabilities of RED. For most applications, FlexFEC superset of the capabilities of RED. For most applications, FlexFEC
is a better choice than RED. is a better choice than RED.
7.3. FEC 7.3. Forward Error Correction (FEC)
When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with
double, the negotiation of double for the crypto is the out of band double, repair packets MUST be constructed by first double-encrypting
signaling that indicates that the repair packets MUST use the order the packet, then performing FEC. Processing of repair packets
of operations of SRTP followed by FEC when encrypting. This is to proceeds in the opposite order, performing FEC recovery and then
ensure that the original media is not revealed to the Media decrypting. This ensures that the original media is not revealed to
Distributor but at the same time allow the Media Distributor to the Media Distributor but at the same time allows the Media
repair media. When encrypting a packet that contains the Flex FEC Distributor to repair media. When encrypting a packet that contains
data, which is already encrypted, it MUST be encrypted in repair mode the Flex FEC data, which is already encrypted, it MUST be encrypted
packet. with only the outer, HBH transform.
The algorithm recommend in [I-D.ietf-rtcweb-fec] for repair of video The algorithm recommended in [I-D.ietf-rtcweb-fec] for repair of
is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that for video is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that
interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends not for interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends
using additional FEC only m-line in SDP for the repair packets. not using additional FEC only m-line in SDP for the repair packets.
7.4. DTMF 7.4. DTMF
When DTMF is sent with [RFC4733], it is end-to-end encrypted and the When DTMF is sent using the mechanism in [RFC4733], it is end-to-end
relay can not read it so it cannot be used to control the relay. encrypted and the relay can not read it, so it cannot be used to
Other out of band methods to control the relay need to be used control the relay. Other out of band methods to control the relay
instead. need to be used instead.
8. Recommended Inner and Outer Cryptographic Algorithms 8. Recommended Inner and Outer Cryptographic Algorithms
This specification recommends and defines AES-GCM as both the inner This specification recommends and defines AES-GCM as both the inner
and outer cryptographic algorithms, identified as and outer cryptographic algorithms, identified as
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithm provide DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithm provide
for authenticated encryption and will consume additional processing for authenticated encryption and will consume additional processing
time double-encrypting for hop-by-hop and end-to-end. However, the time double-encrypting for hop-by-hop and end-to-end. However, the
approach is secure and simple, and is thus viewed as an acceptable approach is secure and simple, and is thus viewed as an acceptable
skipping to change at page 11, line 40 skipping to change at page 12, line 43
Note that names for the cryptographic transforms are of the form Note that names for the cryptographic transforms are of the form
DOUBLE_(inner algorithm)_(outer algorithm). DOUBLE_(inner algorithm)_(outer algorithm).
While this document only defines a profile based on AES-GCM, it is While this document only defines a profile based on AES-GCM, it is
possible for future documents to define further profiles with possible for future documents to define further profiles with
different inner and outer algorithms in this same framework. For different inner and outer algorithms in this same framework. For
example, if a new SRTP transform was defined that encrypts some or example, if a new SRTP transform was defined that encrypts some or
all of the RTP header, it would be reasonable for systems to have the 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 option of using that for the outer algorithm. Similarly, if a new
transform was defined that provided only integrity, that would also transform was defined that provided only integrity, that would also
be reasonable to use for the hop-by-hop as the payload data is be reasonable to use for the outer transform as the payload data is
already encrypted by the end-to-end. already encrypted by the inner transform.
The AES-GCM cryptographic algorithm introduces an additional 16 The AES-GCM cryptographic algorithm introduces an additional 16
octets to the length of the packet. When using AES-GCM for both the octets to the length of the packet. When using AES-GCM for both the
inner and outer cryptographic algorithms, the total additional length inner and outer cryptographic algorithms, the total additional length
is 32 octets. If no other header extensions are present in the is 32 octets. If no other header extensions are present in the
packet and the OHB is introduced, that will consume an additional 8 packet and the OHB is introduced, that will consume an additional 8
octets. If other extensions are already present, the OHB will octets. If other extensions are already present, the OHB will
consume up to 4 additional octets. For packets in repair mode, the consume up to 4 additional octets. Packets in repair mode will carry
data they are caring is often already encrypted further increasing additional repair data, further increasing their size.
the size.
9. Security Considerations 9. Security Considerations
To summarize what is encrypted and authenticated, we will refer to This SRTP transform provides protection against two classes of
all the RTP fields except headers created by the sender and before attacker: An network attacker that knows neither the inner nor outer
the payload as the initial envelope and the RTP payload information keys, and a malicious MD that knows the outer key. Obviously, it
with the media as the payload. Any additional headers added by the provides no protections against an attacker that holds both the inner
sender or Media Distributor are referred to as the extra envelope. and outer keys.
The sender uses the end-to-end key to encrypt the payload and
authenticate the payload + initial envelope, which using an AEAD
cipher results in a slight longer new payload. Then the sender uses
the hop-by-hop key to encrypt the new payload and authenticate the
initial envelope, extra envelope and the new payload. Also to note,
the "Associated Data" input (which excludes header extensions ) to
the inner crypto differs from [RFC7714] construction. This shouldn't
typically impact the strength of e2e integrity given the fact that
there doesn't exist header extensions defined today that needs e2e
protection. However, if future specifications define header
extensions that needs e2e integrity protection, the input to inner
transform may be modified to consider including the header
extensions.
The Media Distributor has the hop-by-hop key so it can check the
authentication of the received packet across the initial envelope,
extra envelope and payload data but it can't decrypt the payload as
it does not have the end-to-end key. It can add or change extra
envelope information. It then authenticates the initial plus extra
envelope information plus payload with a hop-by-hop key. The hop-by-
hop key for the outgoing packet is typically different than the hop-
by-hop key for the incoming packet.
The receiver can check the authentication of the initial and extra
envelope information from the Media Distributor. This, along with
the OHB, is used to construct a synthetic packet which should be
identical to the initial envelope plus payload to one the sender
created and the receiver can check that it is identical and then
decrypt the original payload.
The end result is that if the authentications succeed, the receiver The protections with regard to the network are the same as with the
knows exactly the payload and initial envelope the sender sent, as normal SRTP AES-GCM transforms.
well as exactly which modifications were made by the Media
Distributor and what extra envelope the Media Distributor sent. The
receiver does not know exactly what extra envelope the sender sent.
It is obviously critical that the intermediary has access to just the With regard to a malicious MD, the recipient can verify the integrity
outer (hop-by-hop) algorithm key and not the half of the key for the of the base header fields and confidentiality and integrity of the
the inner (end-to-end) algorithm. We rely on an external key payload. The recipient has no assurance, however, of the integrity
management protocol to ensure this property. of the header extensions in the packet.
Modifications by the intermediary results in the recipient getting The main innovation of this transform relative to other SRTP
two values for changed parameters (original and modified). The transforms is that it allows a partly-trusted MD to decrypt, modify,
recipient will have to choose which to use; there is risk in using and re-encrypt a packet. When this is done, the cryptographic
either that depends on the session setup. contexts used for decryption and re-encryption MUST use different,
independent master keys and master salts. 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.
The security properties for both the inner (end-to-end) and outer In other words, from the perspective of the MD, re-encrypting packets
(hop-by-hop) key holders are the same as the security properties of using this protocol will involve the same cryptographic operations as
classic SRTP. if it had established independent AES-GCM crypto contexts with the
sender and the receiver. If the MD doesn't modify any header fields,
then an MD that supports AES-GCM could be unused unmodified.
10. IANA Considerations 10. IANA Considerations
10.1. DTLS-SRTP 10.1. DTLS-SRTP
We request IANA to add the following values to defines a DTLS-SRTP We request IANA to add the following values to defines a DTLS-SRTP
"SRTP Protection Profile" defined in [RFC5764]. "SRTP Protection Profile" defined in [RFC5764].
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Value | Profile | Reference | | Value | Profile | Reference |
skipping to change at page 15, line 25 skipping to change at page 15, line 39
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013, DOI 10.17487/RFC6904, April 2013,
<https://www.rfc-editor.org/info/rfc6904>. <https://www.rfc-editor.org/info/rfc6904>.
[RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
in the Secure Real-time Transport Protocol (SRTP)", in the Secure Real-time Transport Protocol (SRTP)",
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>.
[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 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>. <https://www.rfc-editor.org/info/rfc8285>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-payload-flexible-fec-scheme] [I-D.ietf-payload-flexible-fec-scheme]
Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP
Payload Format for Flexible Forward Error Correction Payload Format for Flexible Forward Error Correction
(FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in (FEC)", draft-ietf-payload-flexible-fec-scheme-08 (work in
progress), March 2018. progress), July 2018.
[I-D.ietf-perc-dtls-tunnel] [I-D.ietf-perc-dtls-tunnel]
Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
between a Media Distributor and Key Distributor to between a Media Distributor and Key Distributor to
Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-03 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-03
(work in progress), April 2018. (work in progress), April 2018.
[I-D.ietf-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-06 Conferencing", draft-ietf-perc-private-media-framework-07
(work in progress), March 2018. (work in progress), September 2018.
[I-D.ietf-perc-srtp-ekt-diet] [I-D.ietf-perc-srtp-ekt-diet]
Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
Andreasen, "Encrypted Key Transport for DTLS and Secure Andreasen, "Encrypted Key Transport for DTLS and Secure
RTP", draft-ietf-perc-srtp-ekt-diet-07 (work in progress), RTP", draft-ietf-perc-srtp-ekt-diet-08 (work in progress),
March 2018. July 2018.
[I-D.ietf-rtcweb-fec] [I-D.ietf-rtcweb-fec]
Uberti, J., "WebRTC Forward Error Correction Uberti, J., "WebRTC Forward Error Correction
Requirements", draft-ietf-rtcweb-fec-08 (work in Requirements", draft-ietf-rtcweb-fec-08 (work in
progress), March 2018. progress), March 2018.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997, DOI 10.17487/RFC2198, September 1997,
skipping to change at page 16, line 37 skipping to change at page 17, line 10
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006, DOI 10.17487/RFC4733, December 2006,
<https://www.rfc-editor.org/info/rfc4733>. <https://www.rfc-editor.org/info/rfc4733>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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>.
Appendix A. Encryption Overview Appendix A. Encryption Overview
The following figure shows a double encrypted SRTP packet. The sides The following figure shows a double encrypted SRTP packet. The sides
indicate the parts of the packet that are encrypted and authenticated indicate the parts of the packet that are encrypted and authenticated
by the hop-by-hop and end-to-end operations. by the hop-by-hop and end-to-end operations.
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 | IO |V=2|P|X| CC |M| PT | sequence number | IO
 End of changes. 43 change blocks. 
170 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/