DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key ExchangeCisco Systems, Inc.7025 Kit Creek Rd.Research Triangle Park27709United States of AmericaNorth Carolina+1 919 476 2048paulej@packetizer.comPrinceton University+1 206 851 2069pe5@cs.princeton.edu8x8, Inc.+1 408 659 6457nils@ohlmeier.org
Applications and Real-Time Area
Privacy Enhanced RTP ConferencingPERCSRTPRTPDTLSDTLS-SRTPDTLS tunnelconferencingsecurityThis document defines a protocol for tunneling DTLS traffic in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the Media
Distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the Media Distributor.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Conventions Used in This Document
. Tunneling Concept
. Example Message Flows
. Tunneling Procedures
. Endpoint Procedures
. Tunnel Establishment Procedures
. Media Distributor Tunneling Procedures
. Key Distributor Tunneling Procedures
. Versioning Considerations
. Tunneling Protocol
. TunnelMessage Structure
. SupportedProfiles Message
. UnsupportedVersion Message
. MediaKeys Message
. TunneledDtls Message
. EndpointDisconnect Message
. Example Binary Encoding
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionAn objective of Privacy-Enhanced RTP Conferencing (PERC) is to
ensure that endpoints in a multimedia conference have access to the
end-to-end (E2E) and hop-by-hop (HBH) keying material used to encrypt
and authenticate Real-time Transport Protocol (RTP)
packets , while the Media Distributor has access only to the HBH
keying material for encryption and authentication.This specification defines a tunneling protocol that enables the Media
Distributor to tunnel DTLS messages between an endpoint
and a Key Distributor, thus allowing an endpoint to use DTLS for the Secure Real-time Transport Protocol (DTLS-SRTP)
for establishing encryption and authentication keys with
the Key Distributor.The tunnel established between the Media Distributor and Key
Distributor is a TLS connection that is established before any
messages are forwarded by the Media Distributor on behalf of
endpoints. DTLS packets received from an endpoint are encapsulated by
the Media Distributor inside this tunnel as data to be sent to the Key
Distributor. Likewise, when the Media Distributor receives data from
the Key Distributor over the tunnel, it extracts the DTLS message
inside and forwards the DTLS message to the endpoint. In this way,
the DTLS association for the DTLS-SRTP procedures is established
between an endpoint and the Key Distributor, with the Media
Distributor forwarding DTLS messages between the two entities via the
established tunnel to the Key Distributor and having no visibility into
the confidential information exchanged.Following the existing DTLS-SRTP procedures, the endpoint and Key
Distributor will arrive at a selected cipher and keying material,
which are used for HBH encryption and authentication by both the
endpoint and the Media Distributor. However, since the Media
Distributor would not have direct access to this information, the Key
Distributor explicitly shares the HBH key information with the Media
Distributor via the tunneling protocol defined in this document.
Additionally, the endpoint and Key Distributor will agree on a cipher
for E2E encryption and authentication. The Key Distributor will
transmit keying material to the endpoint for E2E operations but will
not share that information with the Media Distributor.By establishing this TLS tunnel between the Media Distributor and Key
Distributor and implementing the protocol defined in this document, it
is possible for the Media Distributor to facilitate the establishment
of a secure DTLS association between an endpoint and the Key
Distributor in order for the endpoint to generate E2E and HBH keying
material. At the same time, the Key Distributor can securely provide
the HBH keying material to the Media Distributor.Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
This document uses the terms "endpoint", "Media Distributor", and
"Key Distributor" defined in .Tunneling ConceptA TLS connection (tunnel) is established between the Media Distributor
and the Key Distributor. This tunnel is used to relay DTLS messages
between the endpoint and Key Distributor, as depicted in
:The three entities involved in this communication flow are the
endpoint, the Media Distributor, and the Key Distributor. The
behavior of each entity is described in . The Key Distributor is a logical function that might be co-resident
with a key management server operated by an enterprise, might
reside in one of the endpoints participating in the conference, or
might reside at some other location that is trusted with E2E keying
material.
Example Message FlowsThis section provides an example message flow to help clarify the
procedures described later in this document. It is necessary that the
Key Distributor and Media Distributor establish a mutually
authenticated TLS connection for the purpose of sending tunneled
messages, though the complete TLS handshake for the tunnel is not
shown in because there is nothing new this document
introduces with regard to those procedures.Once the tunnel is established, it is possible for the Media
Distributor to relay the DTLS messages between the endpoint and the
Key Distributor. shows a message flow wherein the
endpoint uses DTLS-SRTP to establish an association with the Key
Distributor. In the process, the Media Distributor shares its
supported SRTP protection profile information (see ), and
the Key Distributor shares the HBH keying material and selected cipher
with the Media Distributor.After the initial TLS connection has been established, each of the
messages on the right-hand side of is a tunneling
protocol message, as defined in .SRTP protection profiles supported by the Media Distributor will be
sent in a SupportedProfiles message when the TLS tunnel is initially
established. The Key Distributor will use that information to select
a common profile supported by both the endpoint and the Media
Distributor to ensure that HBH operations can be successfully
performed.As DTLS messages are received from the endpoint by the Media
Distributor, they are forwarded to the Key Distributor encapsulated
inside a TunneledDtls message. Likewise, as TunneledDtls
messages are received by the Media Distributor from the Key
Distributor, the encapsulated DTLS packet is forwarded to the
endpoint.The Key Distributor will provide the SRTP keying material
to the Media Distributor for HBH operations via the MediaKeys
message. The Media Distributor will extract this keying material from
the MediaKeys message when received and use it for HBH
encryption and authentication.Tunneling ProceduresThe following subsections explain in detail the expected behavior of
the endpoint, the Media Distributor, and the Key Distributor.It is important to note that the tunneling protocol described in this
document is not an extension to TLS or DTLS. Rather, it is a protocol that
transports DTLS messages generated by an endpoint or Key Distributor as data
inside of the TLS connection established between the Media Distributor and
Key Distributor.Endpoint ProceduresThe endpoint follows the procedures outlined for DTLS-SRTP
in order to establish the cipher and keys used for encryption and
authentication, with the endpoint acting as the client and the Key
Distributor acting as the server. The endpoint does not need to be
aware of the fact that DTLS messages it transmits toward the Media
Distributor are being tunneled to the Key Distributor.The endpoint MUST include a unique identifier in the tls-id
Session Description Protocol (SDP) attribute in all offer and answer messages
that it generates, as per . Further, the
endpoint MUST include this same unique identifier in the
external_session_id extension in the
ClientHello message when establishing a DTLS association.When receiving an external_session_id value from the Key Distributor, the
client MUST check to ensure that value matches the tls-id value
received in SDP. If the values do not match, the endpoint MUST
consider any received keying material to be invalid and terminate the
DTLS association.Tunnel Establishment ProceduresEither the Media Distributor or Key Distributor initiates the
establishment of a TLS tunnel. Which entity acts as the TLS client
when establishing the tunnel and what event triggers the establishment
of the tunnel are outside the scope of this document. Further, how
the trust relationships are established between the Key Distributor
and Media Distributor are also outside the scope of this document.A tunnel MUST be a mutually authenticated TLS connection.The Media Distributor or Key Distributor MUST establish a tunnel
prior to forwarding tunneled DTLS messages. Given the time-sensitive
nature of DTLS-SRTP procedures, a tunnel SHOULD be established
prior to the Media Distributor receiving a DTLS message from an
endpoint.A single tunnel MAY be used to relay DTLS messages between any
number of endpoints and the Key Distributor.A Media Distributor MAY have more than one tunnel established
between itself and one or more Key Distributors. When multiple
tunnels are established, which tunnel or tunnels to use to send
messages for a given conference is outside the scope of this document.Media Distributor Tunneling ProceduresThe first message transmitted over the tunnel is the
SupportedProfiles message (see ). This message informs
the Key Distributor about which DTLS-SRTP profiles the Media
Distributor supports. This message MUST be sent each time a new
tunnel connection is established or, in the case of connection loss,
when a connection is re-established. The Media Distributor MUST
support the same list of protection profiles for the duration of any
endpoint-initiated DTLS association and tunnel connection.The Media Distributor MUST assign a unique association identifier
for each endpoint-initiated DTLS association and include it in all
messages forwarded to the Key Distributor. The Key Distributor will
subsequently include this identifier in all messages it sends so that
the Media Distributor can map messages received via a tunnel and
forward those messages to the correct endpoint. The association
identifier MUST be a version 4 Universally Unique Identifier (UUID), as described in
.When a DTLS message is received by the Media Distributor from an
endpoint, it forwards the UDP payload portion of that message to the
Key Distributor encapsulated in a TunneledDtls message.
The Media Distributor is not required to forward all messages received
from an endpoint for a given DTLS association through the same tunnel
if more than one tunnel has been established between it and a Key
Distributor.When a MediaKeys message is received, the Media Distributor MUST
extract the cipher and keying material conveyed in order to
subsequently perform HBH encryption and authentication operations for
RTP and RTP Control Protocol (RTCP) packets sent between it and an endpoint. Since the HBH
keying material will be different for each endpoint, the Media
Distributor uses the association identifier included by the Key
Distributor to ensure that the HBH keying material is used with the
correct endpoint.The Media Distributor MUST forward all DTLS messages received from
either the endpoint or the Key Distributor (via the TunneledDtls
message) to ensure proper communication between those two entities.When the Media Distributor detects an endpoint has disconnected or
when it receives conference control messages indicating the endpoint
is to be disconnected, the Media Distributor MUST send an
EndpointDisconnect message with the association identifier assigned
to the endpoint to the Key Distributor. The Media Distributor
SHOULD take a loss of all RTP and RTCP packets as an indicator
that the endpoint has disconnected. The particulars of how RTP and
RTCP are to be used to detect an endpoint disconnect, such as timeout
period, are not specified. The Media Distributor MAY use
additional indicators to determine when an endpoint has disconnected.Key Distributor Tunneling ProceduresEach TLS tunnel established between the Media Distributor and the
Key Distributor MUST be mutually authenticated.When the Media Distributor relays a DTLS message from an endpoint, the
Media Distributor will include an association identifier that is
unique per endpoint-originated DTLS association. The association
identifier remains constant for the life of the DTLS association. The
Key Distributor identifies each distinct endpoint-originated DTLS
association by the association identifier.When processing an incoming endpoint association, the Key Distributor
MUST extract the external_session_id value transmitted in the
ClientHello message and match that against the tls-id value the endpoint
transmitted via SDP. If the values in SDP and the ClientHello message do not match,
the DTLS association MUST be rejected.The process through which the tls-id value in SDP is conveyed to
the Key Distributor is outside the scope of this document.The Key Distributor MUST match the fingerprint of the certificate and
external_session_id received from the endpoint via DTLS with the
expected fingerprint and tls-id values received via
SDP. It is through this process that the Key Distributor can be sure to
deliver the correct conference key to the endpoint.The Key Distributor MUST report its own unique identifier in the
external_session_id extension. This extension is sent in the
EncryptedExtensions message in DTLS 1.3 and the ServerHello message in
previous DTLS versions. This value MUST also be conveyed back to
the client via SDP as a tls-id attribute.The Key Distributor MUST encapsulate any DTLS message it sends to
an endpoint inside a TunneledDtls message (see
). The Key Distributor is not required to transmit
all messages for a given DTLS association through the same tunnel if more
than one tunnel has been established between it and the Media Distributor.The Key Distributor MUST use the same association identifier in
messages sent to an endpoint as was received in messages from that
endpoint. This ensures the Media Distributor can forward the messages
to the correct endpoint.The Key Distributor extracts tunneled DTLS messages from an endpoint
and acts on those messages as if that endpoint had established the
DTLS association directly with the Key Distributor. The Key
Distributor is acting as the DTLS server, and the endpoint is acting as
the DTLS client. The handling of the messages and certificates is
exactly the same as normal DTLS-SRTP procedures between endpoints.The Key Distributor MUST send a MediaKeys message to the Media
Distributor immediately after the DTLS handshake completes. The MediaKeys
message includes the selected cipher (i.e., protection profile), Master Key Identifier (MKI)
value (if any), HBH SRTP master keys, and SRTP master salt
values. The Key Distributor MUST use the same association
identifier in the MediaKeys message as is used in the TunneledDtls
messages for the given endpoint.There are presently two SRTP protection profiles defined for PERC,
namely DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. As explained in , the Media Distributor is only given the SRTP
master key for HBH operations. As such, the SRTP master key
length advertised in the MediaKeys message is half the length of the key
normally associated with the selected "double" protection profile.The Key Distributor uses the certificate fingerprint of the endpoint
along with the unique identifier received in the external_session_id
extension to determine with which conference a given DTLS association is
associated.The Key Distributor MUST select a cipher that is supported by itself, the endpoint, and the Media Distributor to ensure proper HBH
operations.When the DTLS association between the endpoint and the Key Distributor
is terminated, regardless of which entity initiated the termination,
the Key Distributor MUST send an EndpointDisconnect message
with the association identifier assigned to the endpoint to the Media
Distributor.Versioning ConsiderationsSince the Media Distributor sends the first message over the tunnel,
it effectively establishes the version of the protocol to be used. If
that version is not supported by the Key Distributor, the Key
Distributor MUST transmit an UnsupportedVersion message containing
the highest version number supported and close the TLS connection.The Media Distributor MUST take note of the version received in an
UnsupportedVersion message and use that version when attempting to
re-establish a failed tunnel connection. Note that it is not
necessary for the Media Distributor to understand the newer version of
the protocol to understand that the first message received is an
UnsupportedVersion message. The Media Distributor can determine from the
first four octets received what the version number is and that the
message is an UnsupportedVersion message. The rest of the data received, if
any, would be discarded and the connection closed (if not already
closed).Tunneling ProtocolTunneled messages are transported via the TLS tunnel as application
data between the Media Distributor and the Key Distributor. Tunnel
messages are specified using the format described in . As in , all values are stored in network byte
(big endian) order; the uint32 represented by the hex bytes 01 02 03
04 is equivalent to the decimal value 16909060.This protocol defines several different messages, each of which
contains the following information:
message type identifier
message body length
the message body
Each of the tunnel messages is a TunnelMessage structure with the
message type indicating the actual content of the message body.TunnelMessage StructureTunnelMessage defines the structure of all messages sent via the tunnel
protocol. That structure includes a field called msg_type that identifies the
specific type of message contained within TunnelMessage.
enum {
supported_profiles(1),
unsupported_version(2),
media_keys(3),
tunneled_dtls(4),
endpoint_disconnect(5),
(255)
} MsgType;
opaque uuid[16];
struct {
MsgType msg_type;
uint16 length;
select (MsgType) {
case supported_profiles: SupportedProfiles;
case unsupported_version: UnsupportedVersion;
case media_keys: MediaKeys;
case tunneled_dtls: TunneledDtls;
case endpoint_disconnect: EndpointDisconnect;
} body;
} TunnelMessage;
The elements of TunnelMessage include:
msg_type:
the type of message contained within the structure body.
length:
the length in octets of the following body of the message.
body:
the actual message being conveyed within this TunnelMessage structure.
SupportedProfiles MessageThe SupportedProfiles message is defined as:
uint8 SRTPProtectionProfile[2]; /* from RFC 5764 */
struct {
uint8 version;
SRTPProtectionProfile protection_profiles<2..2^16-1>;
} SupportedProfiles;
The elements of SupportedProfiles include:
version:
this document specifies version 0x00.
protection_profiles:
the list of two-octet SRTP protection profile
values, as per , supported by the Media Distributor.
UnsupportedVersion MessageThe UnsupportedVersion message is defined as:
struct {
uint8 highest_version;
} UnsupportedVersion;
UnsupportedVersion contains this single element:
highest_version:
indicates the highest version of the protocol supported
by the Key Distributor.
MediaKeys MessageThe MediaKeys message is defined as:
struct {
uuid association_id;
SRTPProtectionProfile protection_profile;
opaque mki<0..255>;
opaque client_write_SRTP_master_key<1..255>;
opaque server_write_SRTP_master_key<1..255>;
opaque client_write_SRTP_master_salt<1..255>;
opaque server_write_SRTP_master_salt<1..255>;
} MediaKeys;
The fields are described as follows:
association_id:
a value that identifies a distinct DTLS association
between an endpoint and the Key Distributor.
protection_profiles:
the value of the two-octet SRTP protection
profile value, as per , used for this DTLS association.
mki:
master key identifier ; a zero-length field indicates
that no MKI value is present.
client_write_SRTP_master_key:
the value of the SRTP master key used by the client (endpoint).
server_write_SRTP_master_key:
the value of the SRTP master key used by the server (Media Distributor).
client_write_SRTP_master_salt:
the value of the SRTP master salt used by the client (endpoint).
server_write_SRTP_master_salt:
the value of the SRTP master salt used by the server (Media Distributor).
TunneledDtls MessageThe TunneledDtls message is defined as:
struct {
uuid association_id;
opaque dtls_message<1..2^16-1>;
} TunneledDtls;
The fields are described as follows:
association_id:
a value that identifies a distinct DTLS association
between an endpoint and the Key Distributor.
dtls_message:
the content of the DTLS message received by the
endpoint or to be sent to the endpoint, including one or more complete
DTLS records.
EndpointDisconnect MessageThe EndpointDisconnect message is defined as:
struct {
uuid association_id;
} EndpointDisconnect;
The field is described as follows:
association_id:
a value that identifies a distinct DTLS association
between an endpoint and the Key Distributor.
Example Binary EncodingThe TunnelMessage is encoded in binary, following the procedures
specified in . This section provides an example of what
the bits on the wire would look like for the SupportedProfiles
message that advertises support for both
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM.
TunnelMessage:
message_type: 0x01
length: 0x0007
SupportedProfiles:
version: 0x00
protection_profiles: 0x0004 (length)
0x0009000A (value)
Thus, the encoding on the wire, presented here in network byte order,
would be this stream of octets:
0x0100070000040009000A
IANA ConsiderationsThis document establishes the "Datagram Transport Layer Security (DTLS) Tunnel Protocol Message Types for Privacy Enhanced Conferencing" registry to contain message type
values used in the DTLS tunnel protocol. These message type values are a
single octet in length. This document defines the values shown in
below, leaving the balance of possible values
reserved for future specifications:
Message Type Values for the DTLS Tunnel Protocol
MsgType
Description
0x01
Supported SRTP Protection Profiles
0x02
Unsupported Version
0x03
Media Keys
0x04
Tunneled DTLS
0x05
Endpoint Disconnect
The value 0x00 is reserved, and all values in the range 0x06 to 0xFF are
available for allocation. The procedures for updating this table are those
defined as "IETF Review" in .Security ConsiderationsSince the procedures in this document rely on TLS for transport
security, the security considerations for TLS should be reviewed when
implementing the protocol defined in this document.While the tunneling protocol defined in this document does not use
DTLS-SRTP directly, it does convey and negotiate some of the
same information (e.g., protection profile data). As such, a review of the
security considerations found in that document may be useful.This document describes a means of securely exchanging keying material and
cryptographic transforms for both E2E and HBH encryption and authentication of
media between an endpoint and a Key Distributor via a Media Distributor.
Additionally, the procedures result in delivering HBH information to the
intermediary Media Distributor. The Key Distributor and endpoint are the only
two entities with access to both the E2E and HBH keys, while the Media
Distributor has access to only HBH information.
enumerates various attacks against which one must guard when implementing a
Media Distributor; these scenarios are important to note.A requirement in this document is that a TLS connection between the Media
Distributor and the Key Distributor be mutually authenticated. The reason
for this requirement is to ensure that only an authorized Media Distributor
receives the HBH keying material. If an unauthorized Media Distributor gains
access to the HBH keying material, it can easily cause service degradation or
denial by transmitting HBH-valid packets that ultimately fail E2E
authentication or replay protection checks (see ).
Even if service does not appear degraded in any way, transmitting and
processing bogus packets are a waste of both computational and network
resources.The procedures defined in this document assume that the Media Distributor
will properly convey DTLS messages between the endpoint and Key Distributor.
Should it fail in that responsibility by forwarding DTLS messages from
endpoint A advertised as being from endpoint B, this will result in
a failure at the DTLS layer of those DTLS sessions. This could be an additional
attack vector that Key Distributor implementations should consider.While E2E keying material passes through the Media Distributor via the protocol
defined in this document, the Media Distributor has no means of gaining access
to that information and therefore cannot affect the E2E media processing
function in the endpoint except to present it with invalid or replayed data.
That said, any entity along the path that interferes with the DTLS exchange
between the endpoint and the Key Distributor, including a malicious Media
Distributor that is not properly authorized, could prevent an endpoint from
properly communicating with the Key Distributor and therefore prevent
successful conference participation.It is worth noting that a compromised Media Distributor can convey
information to an adversary, such as participant IP addresses,
negotiated protection profiles, or other metadata.
While explains that
a malicious or compromised Media Distributor can disrupt communications,
an additional attack vector introduced by this protocol is the potential
disruption of DTLS negotiation or premature removal of a participant from
a conference by sending an EndpointDisconnect message to the
Key Distributor.The Key Distributor should be aware of the possibility that a malicious
Media Distributor might transmit an EndpointDisconnect message to the Key
Distributor when the endpoint is in fact still connected.While the Security Considerations section of describes various
attacks one needs to consider with respect to the Key Distributor and
denial of service, use of this protocol introduces another possible
attack vector. Consider the case where a malicious endpoint sends unsolicited
DTLS-SRTP messages to a Media Distributor. The Media Distributor will normally
forward those messages to the Key Distributor and, if found invalid, such
messages only serve to consume resources on both the Media Distributor and
Key Distributor.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Secure Real-time Transport Protocol (SRTP)This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]A Universally Unique IDentifier (UUID) URN NamespaceThis specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, "tls-id". This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122.Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where Media Distributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP).The Datagram Transport Layer Security (DTLS) Protocol Version 1.3Informative ReferencesAn Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]RTP: A Transport Protocol for Real-Time ApplicationsThis memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.AcknowledgementsThe authors would like to thank and for reviewing this document and providing constructive
comments.Authors' AddressesCisco Systems, Inc.7025 Kit Creek Rd.Research Triangle Park27709United States of AmericaNorth Carolina+1 919 476 2048paulej@packetizer.comPrinceton University+1 206 851 2069pe5@cs.princeton.edu8x8, Inc.+1 408 659 6457nils@ohlmeier.org