draft-ietf-perc-double-08.txt   draft-ietf-perc-double-09.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: September 6, 2018 Cisco Systems Expires: November 4, 2018 Cisco Systems
A. Roach A. Roach
Mozilla Mozilla
March 5, 2018 May 3, 2018
SRTP Double Encryption Procedures SRTP Double Encryption Procedures
draft-ietf-perc-double-08 draft-ietf-perc-double-09
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 RTP parameters, while still providing
strong end-to-end security guarantees. This document defines SRTP strong end-to-end security guarantees. This document defines SRTP
procedures that use two separate but related cryptographic operations procedures that use two separate but related cryptographic operations
to provide hop-by-hop and end-to-end security guarantees. Both the 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 end-to-end and hop-by-hop cryptographic algorithms can utilize an
authenticated encryption with associated data scheme or take authenticated encryption with associated data scheme or take
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 6, 2018. This Internet-Draft will expire on November 4, 2018.
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 29 skipping to change at page 2, line 29
5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 6 5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 6
5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 7 5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 7
5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 8 5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 8
6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 9 6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 9
7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 9 7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 9
7.1. RTX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. RTX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. RED . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. RED . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.4. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Recommended Inner and Outer Cryptographic Algorithms . . . . 11 8. Recommended Inner and Outer Cryptographic Algorithms . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Encryption Overview . . . . . . . . . . . . . . . . 16 Appendix A. Encryption Overview . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 RTP header information to be
skipping to change at page 3, line 15 skipping to change at page 3, line 15
The framework document [I-D.ietf-perc-private-media-framework] The framework document [I-D.ietf-perc-private-media-framework]
describes this concept in more detail. describes this concept in more detail.
This specification defines an SRTP transform that uses the AES-GCM This specification defines an SRTP transform that uses the AES-GCM
algorithm [RFC7714] to provide encryption and integrity for an RTP algorithm [RFC7714] to provide encryption and integrity for an RTP
packet for the end-to-end cryptographic key as well as a hop-by-hop packet for the end-to-end cryptographic key as well as a hop-by-hop
cryptographic encryption and integrity between the endpoint and the cryptographic encryption and integrity between the endpoint and the
Media Distributor. The Media Distributor decrypts and checks Media Distributor. The Media Distributor decrypts and checks
integrity of the hop-by-hop security. The Media Distributor MAY integrity of the hop-by-hop security. The Media Distributor MAY
change some of the RTP header information that would impact the end- change some of the RTP header information that would impact the end-
to-end integrity. The original value of any RTP header field that is to-end integrity. In that case, the original value of any RTP header
changed is included in a new RTP header extension called the Original field that is changed is included in a new RTP header extension
Header Block. The new RTP packet is encrypted with the hop-by-hop called the Original Header Block. The new RTP packet is encrypted
cryptographic algorithm before it is sent. The receiving endpoint with the hop-by-hop cryptographic algorithm before it is sent. The
decrypts and checks integrity using the hop-by-hop cryptographic receiving endpoint decrypts and checks integrity using the hop-by-hop
algorithm and then replaces any parameters the Media Distributor cryptographic algorithm and then replaces any parameters the Media
changed using the information in the Original Header Block before Distributor changed using the information in the Original Header
decrypting and checking the end-to-end integrity. 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 of if 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Terms used throughout this document include: Terms used throughout this document include:
skipping to change at page 4, line 7 skipping to change at page 4, line 7
o hop-by-hop: meaning the link from the endpoint to or from the o hop-by-hop: meaning the link from the endpoint to or from the
Media Distributor. Media Distributor.
o OHB: Original Header Block is an octet string that contains the o OHB: Original Header Block is 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: an This specification uses a cryptographic context with two parts:
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 o An inner (end-to-end) part that is used by endpoints that
outer (hop-by-hop) part that is used between endpoints and Media originate and consume media to ensure the integrity of media end-
Distributors to ensure the integrity of media over a single hop and to-end, and
to enable a Media Distributor to modify certain RTP header fields.
RTCP is also handled using the hop-by-hop cryptographic part. The o An outer (hop-by-hop) part that is used between endpoints and
RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is Media Distributors to ensure the integrity of media over a single
hop and to enable a Media Distributor 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 algorithm is
AES-GCM. Other combinations of SRTP ciphers that support the AES-GCM. Other combinations of SRTP ciphers that support the
procedures in this document can be added to the IANA registry. procedures in this document can be added to the IANA registry.
The keys and salt for these algorithms are generated with the The keys and salt for these algorithms are generated with the
following steps: following steps:
o Generate key and salt values of the length required for the o Generate key and salt values of the length required for the
combined inner (end-to-end) and outer (hop-by-hop) algorithms. combined inner (end-to-end) and outer (hop-by-hop) algorithms.
o Assign the key and salt values generated for the inner (end-to- o Assign the key and salt values generated for the inner (end-to-
skipping to change at page 5, line 18 skipping to change at page 5, line 20
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 PRF, which preserves the
separation between the two halves of the key: separation between the two halves of the key:
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 default SRTP PRF [RFC3711], 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
KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm.
"inner(key)" represents the first half of the key, and "outer(key)" "inner(key)" represents the first half of the key, and "outer(key)"
represents the second half of the key. represents the second half of the key.
4. Original Header Block 4. Original Header Block
The Original Header Block (OHB) contains the original values of any The Original Header Block (OHB) contains the original values of any
modified header fields. In the encryption process, the OHB is modified RTP header fields. In the encryption process, the OHB is
appended to the RTP payload. In the decryption process, the appended to the RTP payload. In the decryption process, the
receiving endpoint uses it to reconstruct the original RTP header, so receiving endpoint uses it to reconstruct the original RTP header, so
that it can pass the proper AAD value to the inner transform. that it can pass the proper AAD value to the inner transform.
The OHB can reflect modifications to the following fields in an RTP The OHB can reflect modifications to the following fields in an RTP
header: the payload type, the sequence number, and the marker bit. header: the payload type, the sequence number, and the marker bit.
All other fields in the RTP header MUST remain unmodified; since the All other fields in the RTP header MUST remain unmodified; since the
OHB cannot reflect their original values, the receiver will be unable OHB cannot reflect their original values, the receiver will be unable
to verify the E2E integrity of the packet. to verify the E2E integrity of the packet.
The OHB has the following syntax (in ABNF): The OHB has the following syntax (in ABNF [RFC5234]):
BYTE = %x00-FF
PT = BYTE OCTET = %x00-FF
SEQ = 2BYTE
Config = BYTE
OHB = ?PT ?SEQ Config PT = OCTET
SEQ = 2OCTET
Config = OCTET
OHB = [ PT ] [ SEQ ] Config
If present, the PT and SEQ parts of the OHB contain the original If present, the PT and SEQ parts of the OHB contain the original
payload type and sequence number fields, respectively. The final payload type and sequence number fields, respectively. The final
"config" octet of the OHB specifies whether these fields are present, "config" octet of the OHB specifies whether these fields are present,
and the original value of the marker bit (if necessary): and the original value of the marker bit (if necessary):
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R R R R B M P Q| |R R R R B M P Q|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 7, line 6 skipping to change at page 7, line 9
* The header is truncated to remove any extensions (12 + 4 * CC * The header is truncated to remove any extensions (12 + 4 * CC
bytes) bytes)
* 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 to the payload of the packet (1) the original packet, and append an empty OHB (0x00) to the
the authentication tag from the original transform, and (2) an encrypted payload (with the authentication tag) obtained from the
empty OHB (0x00). step 4.
6. Apply the outer cryptographic algorithm to the RTP packet. If 6. Apply the outer cryptographic algorithm to the RTP packet. If
encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST
be used when encrypting the RTP packet using the outer be used when encrypting the RTP packet using the outer
cryptographic key. cryptographic key.
When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes
after the SRTP packet exactly like using EKT with any other SRTP after the SRTP packet exactly like using EKT with any other SRTP
transform. transform.
5.2. Relaying a Packet 5.2. Relaying a Packet
The Media Distributor has the part of the key for the outer (hop-by- The Media Distributor has the part of the key for the outer (hop-by-
hop), but it does not have the part of the key for the (end-to-end) hop) cryptographic algorithm, but it does not have the part of the
cryptographic algorithm. The cryptographic algorithm and key used to key for the (end-to-end) cryptographic algorithm. The cryptographic
decrypt a packet and any encrypted RTP header extensions would be the algorithm and key used to decrypt a packet and any encrypted RTP
same as those used in the endpoint's outer algorithm and key. header extensions would be the same as those used in the endpoint's
outer algorithm and key.
In order to modify a packet, the Media Distributor decrypts the In order to modify a packet, the Media Distributor decrypts the
packet, modifies the packet, updates the OHB with any modifications received packet, modifies the packet, updates the OHB with any
not already present in the OHB, and re-encrypts the packet using the modifications not already present in the OHB, and re-encrypts the
cryptographic using the outer (hop-by-hop) key. packet using the the outer (hop-by-hop) cryptographic key before
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. Change any parts of the RTP packet that the relay wishes to
change and should be changed. change and should be changed.
skipping to change at page 9, line 28 skipping to change at page 9, line 34
collection of various statistics. collection of various statistics.
If any of the following RTP headers extensions are found in the outer If any of the following RTP headers extensions are found in the outer
SRTP packet, they MAY be used: SRTP packet, they MAY be used:
o Mixer-to-client audio level indicators (See [RFC6465]) o Mixer-to-client audio level indicators (See [RFC6465])
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 key, 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 There are some RTP related extensions that need special consideration
to be used by a relay when using the double transform due to the end- to be used by a relay when using the double transform due to the end-
to-end protection of the RTP. The repair mechanism, when used with to-end protection of the RTP. The repair mechanism, when used with
double, typically operate on the double encrypted data then take the double, typically operates on the double encrypted data and encrypts
results of theses operations and encrypted them using only the HBH them using only the HBH key. This results in three cryptography
key. This results in three cryptography operation happening to the operation happening to the repair data sent over the wire.
repair data sent over the wire.
7.1. RTX 7.1. 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 encrypted packets with the bits that are sent over the wire to the
other side. When encrypting a retransmission packet, it MUST be other side. When encrypting a retransmission packet, it MUST be
encrypted in packet repair mode. encrypted the packet in repair mode.
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 using the normally transformation, then process the resulting packet normally by using
by using the steps in Section 5.3. the steps in Section 5.3.
7.2. RED 7.2. 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 can not. encodings cannot.
The sender takes encrypted payloads 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 cary the RED payload and the other copied to the RTP packet that will carry the RED payload and the
RTP header information such as SSRC, SEQ, CSRC, etc are set to the other RTP header information such as SSRC, SEQ, CSRC, etc are set to
same as the primary payload. The RED RTP packet is then encrypted in the same as the primary payload. The RED RTP packet is then
repair mode and sent. encrypted in repair mode and sent.
The receiver decrypts the payload to find the RED payload. Note a The receiver decrypts the payload to find the encrypted RED payload.
media relay can do this decryption as the packet was sent in repair Note a media relay can do this decryption as the packet was sent in
mode that only needs the hop-by-hop key. The RTP headers and header repair mode that only needs the hop-by-hop key. The RTP headers and
extensions along with the primary payload and PT from inside the RED header extensions along with the primary payload and PT from inside
payload are used to form the encrypted primary RTP packet which can the RED payload (for the primary encoding) are used to form the
then be decrypted with double. The RTP headers (but not header encrypted primary RTP packet which can then be decrypted with double.
extensions or CSRC) along with PT from inside the RED payload are
used for from the non primary payloads. The time offset information The RTP headers (but not header extensions or CSRC) along with PT
in the RED data MUST be used to adjust the sequence number in the RTP from inside the RED payload corresponding to the redundant encoding
header by using the timestamp offset and packet rate to find a are used to from the non primary payloads. The time offset and
sequence number offset to adjust by. At this point the non primary 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
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. 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, the negotiation of double for the crypto is the out of band
skipping to change at page 11, line 8 skipping to change at page 11, line 15
packet. packet.
The algorithm recommend in [I-D.ietf-rtcweb-fec] for repair of video The algorithm recommend in [I-D.ietf-rtcweb-fec] for repair of video
is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that for is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that for
interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends not interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends not
using additional FEC only m-line in SDP for the repair packets. 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 with [RFC4733], it is end-to-end encrypted and the
relay can not read it so it can not be used to control the relay. relay can not read it so it cannot be used to control the relay.
Other out of band methods to control the relay need to be used Other out of band methods to control the relay need to be used
instead. 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
trade-off in processing efficiency. trade-off in processing efficiency.
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 crypto 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 hop-by-hop as the payload data is
already encrypted by the end-to-end. already encrypted by the end-to-end.
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
skipping to change at page 11, line 50 skipping to change at page 12, line 9
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. For packets in repair mode, the
data they are caring is often already encrypted further increasing data they are caring is often already encrypted further increasing
the size. the size.
9. Security Considerations 9. Security Considerations
To summarize what is encrypted and authenticated, we will refer to To summarize what is encrypted and authenticated, we will refer to
all the RTP fields except headers created by the sender and before all the RTP fields except headers created by the sender and before
the pay load as the initial envelope and the RTP payload information the payload as the initial envelope and the RTP payload information
with the media as the payload. Any additional headers added by the with the media as the payload. Any additional headers added by the
sender or Media Distributor are referred to as the extra envelope. sender or Media Distributor are referred to as the extra envelope.
The sender uses the end-to-end key to encrypt the payload and
The sender uses the end-to-end key to encrypts the payload and authenticate the payload + initial envelope, which using an AEAD
authenticate the payload + initial envelope which using an AEAD
cipher results in a slight longer new payload. Then the sender uses 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 the hop-by-hop key to encrypt the new payload and authenticate the
initial envelope extra envelope and the new payload. 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 The Media Distributor has the hop-by-hop key so it can check the
authentication of the received packet across the initial envelope, authentication of the received packet across the initial envelope,
extra envelope and payload data but it can't decrypt the payload as 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 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. It then authenticates the initial plus extra
envelope information plus payload with a hop-by-hop key. This hop- envelope information plus payload with a hop-by-hop key. The hop-by-
by-hop for the outgoing packet is typically different than the hop- hop key for the outgoing packet is typically different than the hop-
by-hop key for the incoming packet. by-hop key for the incoming packet.
The receiver can check the authentication of the initial and extra The receiver can check the authentication of the initial and extra
envelope information from the Media Distributor. This, along with envelope information from the Media Distributor. This, along with
the OHB, is used to construct a synthetic packet that is should be the OHB, is used to construct a synthetic packet which should be
identical initial envelope plus payload to one the sender created and identical to the initial envelope plus payload to one the sender
the receiver can check that it is identical and then decrypt the created and the receiver can check that it is identical and then
original payload. decrypt the original payload.
The end result is that if the authentications succeed, the receiver The end result is that if the authentications succeed, the receiver
knows exactly what the payload and initial envelope the sender sent, knows exactly the payload and initial envelope the sender sent, as
as well as exactly which modifications were made by the Media well as exactly which modifications were made by the Media
Distributor and what extra envelope the Media Distributor send. The Distributor and what extra envelope the Media Distributor sent. The
receive does not know exactly what extra envelope the sender sent. receiver does not know exactly what extra envelope the sender sent.
It is obviously critical that the intermediary has only the outer It is obviously critical that the intermediary has access to just the
(hop-by-hop) algorithm key and not the half of the key for the the outer (hop-by-hop) algorithm key and not the half of the key for the
inner (end-to-end) algorithm. We rely on an external key management the inner (end-to-end) algorithm. We rely on an external key
protocol to assure this property. management protocol to ensure this property.
Modifications by the intermediary result in the recipient getting two Modifications by the intermediary results in the recipient getting
values for changed parameters (original and modified). The recipient two values for changed parameters (original and modified). The
will have to choose which to use; there is risk in using either that recipient will have to choose which to use; there is risk in using
depends on the session setup. either that depends on the session setup.
The security properties for both the inner (end-to-end) and outer The security properties for both the inner (end-to-end) and outer
(hop-by-hop) key holders are the same as the security properties of (hop-by-hop) key holders are the same as the security properties of
classic SRTP. classic SRTP.
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 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFCXXXX | | {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFCXXXX |
| 0x09} | | | | 0x09} | | |
skipping to change at page 13, line 27 skipping to change at page 14, line 9
Note to IANA: Please assign value RFCXXXX and update table to point Note to IANA: Please assign value RFCXXXX and update table to point
at this RFC for these values. at this RFC for these values.
The SRTP transform parameters for each of these protection are: The SRTP transform parameters for each of these protection are:
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM
cipher: AES_128_GCM then AES_128_GCM cipher: AES_128_GCM then AES_128_GCM
cipher_key_length: 256 bits cipher_key_length: 256 bits
cipher_salt_length: 192 bits cipher_salt_length: 192 bits
aead_auth_tag_length: 32 octets aead_auth_tag_length: 256 bits
auth_function: NULL auth_function: NULL
auth_key_length: N/A auth_key_length: N/A
auth_tag_length: N/A auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets at most 2^48 SRTP packets
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM
cipher: AES_256_GCM then AES_256_GCM cipher: AES_256_GCM then AES_256_GCM
cipher_key_length: 512 bits cipher_key_length: 512 bits
cipher_salt_length: 192 bits cipher_salt_length: 192 bits
aead_auth_tag_length: 32 octets aead_auth_tag_length: 256 bits
auth_function: NULL auth_function: NULL
auth_key_length: N/A auth_key_length: N/A
auth_tag_length: N/A auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets at most 2^48 SRTP packets
The first half of the key and salt is used for the inner (end-to-end) 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 and the second half is used for the outer (hop-by-hop)
algorithm. algorithm.
skipping to change at page 14, line 33 skipping to change at page 15, line 11
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>. <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 [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>.
[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]
Singh, V., Begen, A., Zanaty, M., 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-05 (work in (FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in
progress), July 2017. progress), March 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-02 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-03
(work in progress), October 2017. (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-05 Conferencing", draft-ietf-perc-private-media-framework-06
(work in progress), October 2017. (work in progress), March 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-06 (work in progress), RTP", draft-ietf-perc-srtp-ekt-diet-07 (work in progress),
October 2017. March 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 5 skipping to change at page 16, line 32
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<https://www.rfc-editor.org/info/rfc4588>. <https://www.rfc-editor.org/info/rfc4588>.
[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
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
time Transport Protocol (RTP) Header Extension for Mixer- time Transport Protocol (RTP) Header Extension for Mixer-
to-Client Audio Level Indication", RFC 6465, to-Client Audio Level Indication", RFC 6465,
DOI 10.17487/RFC6465, December 2011, DOI 10.17487/RFC6465, December 2011,
<https://www.rfc-editor.org/info/rfc6465>. <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 hob-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
| timestamp | IO | timestamp | IO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
| synchronization source (SSRC) identifier | IO | synchronization source (SSRC) identifier | IO
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO
 End of changes. 47 change blocks. 
106 lines changed or deleted 131 lines changed or added

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