diff options
Diffstat (limited to 'doc/rfc/rfc8871.txt')
| -rw-r--r-- | doc/rfc/rfc8871.txt | 1245 |
1 files changed, 1245 insertions, 0 deletions
diff --git a/doc/rfc/rfc8871.txt b/doc/rfc/rfc8871.txt new file mode 100644 index 0000000..de98b2a --- /dev/null +++ b/doc/rfc/rfc8871.txt @@ -0,0 +1,1245 @@ + + + + +Internet Engineering Task Force (IETF) P. Jones +Request for Comments: 8871 Cisco +Category: Standards Track D. Benham +ISSN: 2070-1721 C. Groves + Independent + January 2021 + + + A Solution Framework for Private Media in Privacy-Enhanced RTP + Conferencing (PERC) + +Abstract + + 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). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8871. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions Used in This Document + 3. PERC Entities and Trust Model + 3.1. Untrusted Entities + 3.1.1. Media Distributor + 3.1.2. Call Processing + 3.2. Trusted Entities + 3.2.1. Endpoint + 3.2.2. Key Distributor + 4. Framework for PERC + 4.1. E2E-Authenticated and HBH-Authenticated Encryption + 4.2. E2E Key Confidentiality + 4.3. E2E Keys and Endpoint Operations + 4.4. HBH Keys and Per-Hop Operations + 4.5. Key Exchange + 4.5.1. Initial Key Exchange and Key Distributor + 4.5.2. Key Exchange during a Conference + 5. Authentication + 5.1. Identity Assertions + 5.2. Certificate Fingerprints in Session Signaling + 5.3. Conference Identification + 6. PERC Keys + 6.1. Key Inventory and Management Considerations + 6.2. DTLS-SRTP Exchange Yields HBH Keys + 6.3. The Key Distributor Transmits the KEK (EKT Key) + 6.4. Endpoints Fabricate an SRTP Master Key + 6.5. Summary of Key Types and Entity Possession + 7. Encrypted Media Packet Format + 8. Security Considerations + 8.1. Third-Party Attacks + 8.2. Media Distributor Attacks + 8.2.1. Denial of Service + 8.2.2. Replay Attacks + 8.2.3. Delayed Playout Attacks + 8.2.4. Splicing Attacks + 8.2.5. RTCP Attacks + 8.3. Key Distributor Attacks + 8.4. Endpoint Attacks + 9. IANA Considerations + 10. References + 10.1. Normative References + 10.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + Switched conferencing is an increasingly popular model for multimedia + conferences with multiple participants using a combination of audio, + video, text, and other media types. With this model, real-time media + flows from conference participants are not mixed, transcoded, + translated, recomposed, or otherwise manipulated by a Media + Distributor, as might be the case with a traditional media server or + Multipoint Control Unit (MCU). Instead, media flows transmitted by + conference participants are simply forwarded by Media Distributors to + each of the other participants. Media Distributors often forward + only a subset of flows based on voice activity detection or other + criteria. In some instances, Media Distributors may make limited + modifications to RTP headers [RFC3550], for example, but the actual + media content (e.g., voice or video data) is unaltered. + + An advantage of switched conferencing is that Media Distributors can + be more easily deployed on general-purpose computing hardware, + including virtualized environments in private and public clouds. + Virtualized public cloud environments have been viewed as less + secure, since resources are not always physically controlled by those + who use them. This document defines improved security so as to lower + the barrier to taking advantage of those environments. + + This document defines a solution framework wherein media privacy is + ensured by making it impossible for a Media Distributor to gain + access to keys needed to decrypt or authenticate the actual media + content sent between conference participants. At the same time, the + framework allows for the Media Distributors to modify certain RTP + headers; add, remove, encrypt, or decrypt RTP header extensions; and + encrypt and decrypt RTP Control Protocol (RTCP) packets [RFC3550]. + The framework also prevents replay attacks by authenticating each + packet transmitted between a given participant and the Media + Distributor using a unique key per endpoint that is independent from + the key for media encryption and authentication. + + This solution framework provides for enhanced privacy in RTP-based + conferencing environments while utilizing existing security + procedures defined for RTP with minimal enhancements. + +2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + Additionally, this solution framework uses the following terms and + abbreviations: + + End-to-End (E2E): Communications from one endpoint through one or + more Media Distributors to the endpoint at the other end. + + Hop-by-Hop (HBH): Communications between an endpoint and a Media + Distributor or between Media Distributors. + + Trusted Endpoint (or simply endpoint): An RTP flow-terminating + entity that has possession of E2E media encryption keys and + terminates E2E encryption. This may include embedded user + conferencing equipment or browsers on computers, media gateways, + MCUs, media recording devices, and more, that are in the trusted + domain for a given deployment. In the context of WebRTC + [W3C.CR-webrtc], where control of a session is divided between a + JavaScript application and a browser, the browser acts as the + Trusted Endpoint for purposes of this framework (just as it acts + as the endpoint for DTLS-SRTP [RFC5764] in one-to-one calls). + + Media Distributor (MD): An RTP middlebox that forwards endpoint + media content (e.g., voice or video data) unaltered -- either a + subset or all of the flows at any given time -- and is never + allowed to have access to E2E encryption keys. It operates + according to the Selective Forwarding Middlebox RTP topologies + [RFC7667] per the constraints defined by the Private Media in + Privacy-Enhanced RTP Conferencing (PERC) system, which includes, + but is not limited to, having no access to RTP media plaintext and + having limits on what RTP header fields it can alter. The header + fields that may be modified by a Media Distributor are enumerated + in Section 4 of the double cryptographic transform specification + [RFC8723] and chosen with respect to utility and the security + considerations outlined in this document. + + Key Distributor: An entity that is a logical function that + distributes keying material and related information to Trusted + Endpoints and Media Distributor(s) -- only what is appropriate for + each. The Key Distributor might be co-resident with another + entity trusted with E2E keying material. + + Conference: Two or more participants communicating via Trusted + Endpoints to exchange RTP flows through one or more Media + Distributors. + + Call Processing: All Trusted Endpoints connect to a conference via a + call processing dialog, e.g., with the "focus" as defined in "A + Framework for Conferencing with the Session Initiation Protocol + (SIP)" [RFC4353]. + + Third Party: Any entity that is not an endpoint, Media Distributor, + Key Distributor, or call processing entity as described in this + document. + +3. PERC Entities and Trust Model + + Figure 1 depicts the trust relationships, direct or indirect, between + entities described in the subsequent subsections. Note that these + entities may be co-located or further divided into multiple, separate + physical devices. + + Please note that some entities classified as untrusted in the simple, + general deployment scenario used most commonly in this document might + be considered trusted in other deployments. This document does not + preclude such scenarios, but it keeps the definitions and examples + focused by only using the simple, most general deployment scenario. + + | + +----------+ | +-----------------+ + | Endpoint | | | Call Processing | + +----------+ | +-----------------+ + | + | + +----------------+ | +--------------------+ + | Key Distributor| | | Media Distributor | + +----------------+ | +--------------------+ + | + Trusted | Untrusted + Entities | Entities + | + + Figure 1: Trusted and Untrusted Entities in PERC + +3.1. Untrusted Entities + + The architecture described in this framework document enables + conferencing infrastructure to be hosted in domains, such as in a + cloud conferencing provider's facilities, where the trustworthiness + is below the level needed to assume that the privacy of the + participant's media is not compromised. The conferencing + infrastructure in such a domain is still trusted with reliably + connecting the participants together in a conference but is not + trusted with keying material needed to decrypt any of the + participant's media. Entities in such less-trustworthy domains are + referred to as untrusted entities from this point forward. + + It is important to understand that "untrusted" in this document does + not mean that an entity is not expected to function properly. + Rather, it means only that the entity does not have access to the E2E + media encryption keys. + +3.1.1. Media Distributor + + A Media Distributor forwards RTP flows between endpoints in the + conference while performing per-hop authentication of each RTP + packet. The Media Distributor may need access to one or more RTP + headers or header extensions, potentially adding or modifying a + certain subset. The Media Distributor also relays secured messaging + between the endpoints and the Key Distributor and acquires per-hop + key information from the Key Distributor. The actual media content + must not be decryptable by a Media Distributor, as it is not trusted + to have access to the E2E media encryption keys. The key exchange + mechanisms specified in this framework prevent the Media Distributor + from gaining access to the E2E media encryption keys. + + An endpoint's ability to connect to a conference serviced by a Media + Distributor implies that the endpoint is authorized to have access to + the E2E media encryption keys, although the Media Distributor does + not have the ability to determine whether an endpoint is authorized. + Instead, the Key Distributor is responsible for authenticating the + endpoint (e.g., using WebRTC identity assertions [RFC8827]) and + determining its authorization to receive E2E and HBH media encryption + keys. + + A Media Distributor must perform its role in properly forwarding + media packets while taking measures to mitigate the adverse effects + of denial-of-service attacks (refer to Section 8) to a level equal to + or better than traditional conferencing (non-PERC) deployments. + + A Media Distributor or associated conferencing infrastructure may + also initiate or terminate various messaging techniques related to + conference control. This topic is outside the scope of this + framework document. + +3.1.2. Call Processing + + Call processing is untrusted in the simple, general deployment + scenario. When a physical subset of call processing resides in + facilities outside the trusted domain, it should not be trusted to + have access to E2E key information. + + Call processing may include the processing of call signaling + messages, as well as the signing of those messages. It may also + authenticate the endpoints for the purpose of call signaling and of + subsequently joining a conference hosted through one or more Media + Distributors. Call processing may optionally ensure the privacy of + call signaling messages between itself (call processing), the + endpoint, and other entities. + +3.2. Trusted Entities + + From the PERC model system's perspective, entities considered trusted + (refer to Figure 1) can be in possession of the E2E media encryption + keys for one or more conferences. + +3.2.1. Endpoint + + An endpoint is considered trusted and has access to E2E key + information. While it is possible for an endpoint to be compromised, + subsequently performing in undesired ways, defining endpoint + resistance to compromise is outside the scope of this document. + Endpoints take measures to mitigate the adverse effects of denial-of- + service attacks (refer to Section 8) from other entities, including + from other endpoints, to a level equal to or better than traditional + conference (non-PERC) deployments. + +3.2.2. Key Distributor + + The Key Distributor, which may be co-located with an endpoint or + exist standalone, is responsible for providing key information to + endpoints for both E2E and HBH security and for providing key + information to Media Distributors for HBH security. + + Interaction between the Key Distributor and call processing is + necessary for proper conference-to-endpoint mappings. This is + described in Section 5.3. + + The Key Distributor needs to be secured and managed in a way that + prevents exploitation by an adversary, as any kind of compromise of + the Key Distributor puts the security of the conference at risk. + + The Key Distributor needs to know which endpoints and which Media + Distributors are authorized to participate in the conference. How + the Key Distributor obtains this information is outside the scope of + this document. However, Key Distributors MUST reject DTLS + associations with any unauthorized endpoint or Media Distributor. + +4. Framework for PERC + + The purpose of this framework is to define a means through which + media privacy is ensured when communicating within a conferencing + environment consisting of one or more Media Distributors that only + switch, and hence do not terminate, media. It does not otherwise + attempt to hide the fact that a conference between endpoints is + taking place. + + This framework reuses several specified RTP security technologies, + including the Secure Real-time Transport Protocol (SRTP) [RFC3711], + Encrypted Key Transport (EKT) [RFC8870], and DTLS-SRTP. + +4.1. E2E-Authenticated and HBH-Authenticated Encryption + + This solution framework focuses on the E2E privacy and integrity of + the participant's media by limiting access to only trusted entities + to the E2E key used for authenticated E2E encryption. However, this + framework does give a Media Distributor access to RTP header fields + and header extensions, as well as the ability to modify a certain + subset of the header fields and to add or change header extensions. + Packets received by a Media Distributor or an endpoint are + authenticated hop by hop. + + To enable all of the above, this framework defines the use of two + security contexts and two associated encryption keys: an "inner" key + (a distinct E2E key for each transmitted media flow) for + authenticated encryption of RTP media between endpoints and an + "outer" key (a HBH key) known only to a Media Distributor or the + adjacent endpoint for the hop between an endpoint and a Media + Distributor or peer endpoint. An endpoint will receive one or more + E2E keys from every other endpoint in the conference that correspond + to the media flows transmitted by those other endpoints, while HBH + keys are derived from the DTLS-SRTP association with the Key + Distributor. Two communicating Media Distributors use DTLS-SRTP + associations directly with each other to obtain the HBH keys they + will use. See Section 4.5 for more details on key exchange. + + +-------------+ +-------------+ + | |################################| | + | Media |------------------------ *----->| Media | + | Distributor |<----------------------*-|------| Distributor | + | X |#####################*#|#|######| Y | + | | | | | | | + +-------------+ | | | +-------------+ + # ^ | # HBH Key (XY) -+ | | # ^ | # + # | | # E2E Key (B) ---+ | # | | # + # | | # E2E Key (A) -----+ # | | # + # | | # # | | # + # | | # # | | # + # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # + # | | # # | | # + # *--------- E2E Key (A) E2E Key (A) ---------* # + # | *------- E2E Key (B) E2E Key (B) -------* | # + # | | # # | | # + # | v # # | v # + +-------------+ +-------------+ + | Endpoint A | | Endpoint B | + +-------------+ +-------------+ + + Figure 2: E2E and HBH Keys Used for Authenticated Encryption of + SRTP Packets + + The double transform [RFC8723] enables endpoints to perform + encryption using both the E2E and HBH contexts while still preserving + the same overall interface as other SRTP transforms. The Media + Distributor simply uses the corresponding normal (single) AES-GCM + transform, keyed with the appropriate HBH keys. See Section 6.1 for + a description of the keys used in PERC and Section 7 for a diagram of + how encrypted RTP packets appear on the wire. + + RTCP is only encrypted hop by hop -- not end to end. This framework + does not provide an additional step for RTCP-authenticated + encryption. Rather, implementations utilize the existing procedures + specified in [RFC3711]; those procedures use the same outer, HBH + cryptographic context chosen in the double transform operation + described above. For this reason, endpoints MUST NOT send + confidential information via RTCP. + +4.2. E2E Key Confidentiality + + To ensure the confidentiality of E2E keys shared between endpoints, + endpoints use a common Key Encryption Key (KEK) that is known only by + the trusted entities in a conference. That KEK, defined in the EKT + specification [RFC8870] as the EKT Key, is used to subsequently + encrypt the SRTP master key used for E2E-authenticated encryption of + media sent by a given endpoint. Each endpoint in the conference + creates an SRTP master key for E2E-authenticated encryption and keeps + track of the E2E keys received via the Full EKT Tag for each distinct + synchronization source (SSRC) in the conference so that it can + properly decrypt received media. An endpoint may change its E2E key + at any time and advertise that new key to the conference as specified + in [RFC8870]. + +4.3. E2E Keys and Endpoint Operations + + Any given RTP media flow is identified by its SSRC, and an endpoint + might send more than one at a time and change the mix of media flows + transmitted during the lifetime of a conference. + + Thus, an endpoint MUST maintain a list of SSRCs from received RTP + flows and each SSRC's associated E2E key information. An endpoint + MUST discard old E2E keys no later than when it leaves the + conference. + + If the packet is to contain RTP header extensions, it should be noted + that those extensions are only encrypted hop by hop per [RFC8723]. + For this reason, endpoints MUST NOT transmit confidential information + via RTP header extensions. + +4.4. HBH Keys and Per-Hop Operations + + To ensure the integrity of transmitted media packets, it is REQUIRED + that every packet be authenticated hop by hop between an endpoint and + a Media Distributor, as well as between Media Distributors. The + authentication key used for HBH authentication is derived from an + SRTP master key shared only on the respective hop. Each HBH key is + distinct per hop, and no two hops ever use the same SRTP master key. + + While endpoints also perform HBH authentication, the ability of the + endpoints to reconstruct the original RTP header also enables the + endpoints to authenticate RTP packets end to end. This design yields + flexibility to the Media Distributor to change certain RTP header + values as packets are forwarded. Values that the Media Distributor + can change in the RTP header are defined in [RFC8723]. RTCP can only + be encrypted hop by hop, giving the Media Distributor the flexibility + to (1) forward RTCP content unchanged, (2) transmit compound RTCP + packets, (3) initiate RTCP packets for reporting statistics, or + (4) convey other information. Performing HBH authentication for all + RTP and RTCP packets also helps provide replay protection (see + Section 8). The use of the replay protection mechanism specified in + Section 3.3.2 of [RFC3711] is REQUIRED at each hop. + + If there is a need to encrypt one or more RTP header extensions hop + by hop, the endpoint derives an encryption key from the HBH SRTP + master key to encrypt header extensions as per [RFC6904]. This still + gives the Media Distributor visibility into header extensions, such + as the one used to determine the audio level [RFC6464] of conference + participants. Note that when RTP header extensions are encrypted, + all hops need to decrypt and re-encrypt these encrypted header + extensions. Please refer to Sections 5.1, 5.2, and 5.3 of [RFC8723] + for procedures to perform RTP header extension encryption and + decryption. + +4.5. Key Exchange + + In brief, the keys used by any given endpoints are determined as + follows: + + * The HBH keys that the endpoint uses to send and receive SRTP media + are derived from a DTLS handshake that the endpoint performs with + the Key Distributor (following normal DTLS-SRTP procedures). + + * The E2E key that an endpoint uses to send SRTP media can be either + set from the DTLS-SRTP association with the Key Distributor or + chosen by the endpoint. It is then distributed to other endpoints + in a Full EKT Tag, encrypted under an EKT Key provided to the + client by the Key Distributor within the DTLS channel they + negotiated. Note that an endpoint MAY create a different E2E key + per media flow, where a media flow is identified by its SSRC + value. + + * Each E2E key that an endpoint uses to receive SRTP media is set by + receiving a Full EKT Tag from another endpoint. + + * The HBH keys used between two Media Distributors are derived via + DTLS-SRTP procedures employed directly between them. + +4.5.1. Initial Key Exchange and Key Distributor + + The Media Distributor maintains a tunnel with the Key Distributor + (e.g., using the tunnel protocol defined in [PERC-DTLS]), making it + possible for the Media Distributor to facilitate the establishment of + a secure DTLS association between each endpoint and the Key + Distributor as shown in Figure 3. The DTLS association between + endpoints and the Key Distributor enables each endpoint to generate + E2E and HBH keys and receive the KEK. At the same time, the Key + Distributor securely provides the HBH key information to the Media + Distributor. The key information summarized here may include the + SRTP master key, the SRTP master salt, and the negotiated + cryptographic transform. + + +-----------+ + KEK info | Key | HBH Key info to + to Endpoints |Distributor| Endpoints & Media Distributor + +-----------+ + # ^ ^ # + # | | #--- Tunnel + # | | # + +-----------+ +-----------+ +-----------+ + | Endpoint | DTLS | Media | DTLS | Endpoint | + | KEK |<------------|Distributor|------------>| KEK | + | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | + +-----------+ +-----------+ +-----------+ + + Figure 3: Exchanging Key Information between Entities + + In addition to the secure tunnel between the Media Distributor and + the Key Distributor, there are two additional types of security + associations utilized as a part of the key exchange, as discussed in + the following paragraphs. One is a DTLS-SRTP association between an + endpoint and the Key Distributor (with packets passing through the + Media Distributor), and the other is a DTLS-SRTP association between + peer Media Distributors. + + Endpoints establish a DTLS-SRTP association over the RTP session with + the Media Distributor and its media ports for the purposes of key + information exchange with the Key Distributor. The Media Distributor + does not terminate the DTLS signaling but instead forwards DTLS + packets received from an endpoint on to the Key Distributor (and vice + versa) via a tunnel established between the Media Distributor and the + Key Distributor. + + When establishing the DTLS association between endpoints and the Key + Distributor, the endpoint MUST act as the DTLS client, and the Key + Distributor MUST act as the DTLS server. The KEK is conveyed by the + Key Distributor over the DTLS association to endpoints via procedures + defined in EKT [RFC8870] via the EKTKey message. + + The Key Distributor MUST NOT establish DTLS-SRTP associations with + endpoints without first authenticating the Media Distributor + tunneling the DTLS-SRTP packets from the endpoint. + + Note that following DTLS-SRTP procedures for the cipher defined in + [RFC8723], the endpoint generates both E2E and HBH encryption keys + and salt values. Endpoints MUST either use the DTLS-SRTP-generated + E2E key for transmission or generate a fresh E2E key. In either + case, the generated SRTP master salt for E2E encryption MUST be + replaced with the salt value provided by the Key Distributor via the + EKTKey message. That is because every endpoint in the conference + uses the same SRTP master salt. The endpoint only transmits the SRTP + master key (not the salt) used for E2E encryption to other endpoints + in RTP/RTCP packets per [RFC8870]. + + Media Distributors use DTLS-SRTP directly with a peer Media + Distributor to establish the HBH key for transmitting RTP and RTCP + packets to that peer Media Distributor. The Key Distributor does not + facilitate establishing a HBH key for use between Media Distributors. + +4.5.2. Key Exchange during a Conference + + Following the initial key information exchange with the Key + Distributor, an endpoint is able to encrypt media end to end with an + E2E key, sending that E2E key to other endpoints encrypted with the + KEK, and is able to encrypt and authenticate RTP packets using a HBH + key. This framework does not allow the Media Distributor to gain + access to the KEK information, preventing it from gaining access to + any endpoint's E2E key and subsequently decrypting media. + + The KEK may need to change from time to time during the lifetime of a + conference, such as when a new participant joins or leaves a + conference. Dictating if, when, or how often a conference is to be + rekeyed is outside the scope of this document, but this framework + does accommodate rekeying during the lifetime of a conference. + + When a Key Distributor decides to rekey a conference, it transmits a + new EKTKey message containing the new EKT Key to each of the + conference participants. Upon receipt of the new EKT Key, the + endpoint MUST create a new SRTP master key and prepare to send that + key inside a FullEKTField using the new EKT Key as per Section 4.5 of + [RFC8870]. In order to allow time for all endpoints in the + conference to receive the new keys, the sender should follow the + recommendations in Section 4.6 of [RFC8870]. On receiving a new EKT + Key, endpoints MUST be prepared to decrypt EKT Tags using the new + key. The EKT Security Parameter Index (SPI) field is used to + differentiate between EKT Tags encrypted with the old and new keys. + + After rekeying, an endpoint SHOULD retain prior SRTP master keys and + EKT Keys for a period of time sufficient for the purpose of ensuring + that it can decrypt late-arriving or out-of-order packets or packets + sent by other endpoints that used the prior keys for a period of time + after rekeying began. An endpoint MAY retain old keys until the end + of the conference. + + Endpoints MAY follow the procedures in Section 5.2 of [RFC5764] to + renegotiate HBH keys as desired. If new HBH keys are generated, the + new keys are also delivered to the Media Distributor following the + procedures defined in [PERC-DTLS] as one possible method. + + At any time, endpoints MAY change the E2E encryption key being used. + An endpoint MUST generate a new E2E encryption key whenever it + receives a new EKT Key. After switching to a new key, the new key is + conveyed to other endpoints in the conference in RTP/RTCP packets per + [RFC8870]. + +5. Authentication + + It is important that entities can validate the authenticity of other + entities, especially the Key Distributor and endpoints. Details on + this topic are outside the scope of this specification, but a few + possibilities are discussed in the following sections. The critical + requirements are that (1) an endpoint can verify that it is connected + to the correct Key Distributor for the conference and (2) the Key + Distributor can verify that the endpoint is the correct endpoint for + the conference. + + Two possible approaches to resolve this situation are identity + assertions and certificate fingerprints. + +5.1. Identity Assertions + + A WebRTC identity assertion [RFC8827] is used to bind the identity of + the user of the endpoint to the fingerprint of the DTLS-SRTP + certificate used for the call. This certificate is unique for a + given call and a conference. This certificate is unique for a given + call and a conference, allowing the Key Distributor to ensure that + only authorized users participate in the conference. Similarly, the + Key Distributor can create a WebRTC identity assertion to bind the + fingerprint of the unique certificate used by the Key Distributor for + this conference so that the endpoint can verify that it is talking to + the correct Key Distributor. Such a setup requires an Identity + Provider (IdP) trusted by the endpoints and the Key Distributor. + +5.2. Certificate Fingerprints in Session Signaling + + Entities managing session signaling are generally assumed to be + untrusted in the PERC framework. However, there are some deployment + scenarios where parts of the session signaling may be assumed + trustworthy for the purposes of exchanging, in a manner that can be + authenticated, the fingerprint of an entity's certificate. + + As a concrete example, SIP [RFC3261] and the Session Description + Protocol (SDP) [RFC4566] can be used to convey the fingerprint + information per [RFC5763]. An endpoint's SIP User Agent would send + an INVITE message containing SDP for the media session along with the + endpoint's certificate fingerprint, which can be signed using the + procedures described in [RFC8224] for the benefit of forwarding the + message to other entities by the focus [RFC4353]. Other entities can + verify that the fingerprints match the certificates found in the + DTLS-SRTP connections to find the identity of the far end of the + DTLS-SRTP connection and verify that it is the authorized entity. + + Ultimately, if using session signaling, an endpoint's certificate + fingerprint would need to be securely mapped to a user and conveyed + to the Key Distributor so that it can check that the user in question + is authorized. Similarly, the Key Distributor's certificate + fingerprint can be conveyed to an endpoint in a manner that can be + authenticated as being an authorized Key Distributor for this + conference. + +5.3. Conference Identification + + The Key Distributor needs to know what endpoints are being added to a + given conference. Thus, the Key Distributor and the Media + Distributor need to know endpoint-to-conference mappings, which are + enabled by exchanging a conference-specific unique identifier as + described in [PERC-DTLS]. How this unique identifier is assigned is + outside the scope of this document. + +6. PERC Keys + + This section describes the various keys employed by PERC. + +6.1. Key Inventory and Management Considerations + + This section summarizes the several different keys used in the PERC + framework, how they are generated, and what purpose they serve. + + The keys are described in the order in which they would typically be + acquired. + + The various keys used in PERC are shown in Table 1 below. + + +===========+=============================================+ + | Key | Description | + +===========+=============================================+ + | HBH Key | SRTP master key used to encrypt media hop | + | | by hop. | + +-----------+---------------------------------------------+ + | KEK | Key shared by all endpoints and used to | + | (EKT Key) | encrypt each endpoint's E2E SRTP master key | + | | so receiving endpoints can decrypt media. | + +-----------+---------------------------------------------+ + | E2E Key | SRTP master key used to encrypt media end | + | | to end. | + +-----------+---------------------------------------------+ + + Table 1: Key Inventory + + While the number of key types is very small, it should be understood + that the actual number of distinct keys can be large as the + conference grows in size. + + As an example, with 1,000 participants in a conference, there would + be at least 1,000 distinct SRTP master keys, all of which share the + same master salt. Each of those keys is passed through the Key + Derivation Function (KDF) as defined in [RFC3711] to produce the + actual encryption and authentication keys. + + Complicating key management is the fact that the KEK can change and, + when it does, the endpoints generate new SRTP master keys that are + associated with a new EKT SPI. Endpoints might retain old keys for a + period of time to ensure that they can properly decrypt late-arriving + or out-of-order packets, which means that the number of keys held + during that period of time might be substantially higher. + + A more detailed explanation of each of the keys follows. + +6.2. DTLS-SRTP Exchange Yields HBH Keys + + The first set of keys acquired are for HBH encryption and decryption. + Per the double transform procedures [RFC8723], the endpoint performs + a DTLS-SRTP exchange with the Key Distributor and receives a key that + is, in fact, "double" the size that is needed. The E2E part is the + first half of the key, so the endpoint discards that information when + generating its own key. The second half of the keying material is + for HBH operations, so that half of the key (corresponding to the + least significant bits) is assigned internally as the HBH key. + + The Key Distributor informs the Media Distributor of the HBH key. + Specifically, the Key Distributor sends the least significant bits + corresponding to the half of the keying material determined through + DTLS-SRTP with the endpoint to the Media Distributor. A salt value + is generated along with the HBH key. The salt is also longer than + needed for HBH operations; thus, only the least significant bits of + the required length (half of the generated salt material) are sent to + the Media Distributor. One way to transmit this key and salt + information is via the tunnel protocol defined in [PERC-DTLS]. + + No two endpoints have the same HBH key; thus, the Media Distributor + MUST keep track of each distinct HBH key (and the corresponding salt) + and use it only for the specified hop. + + The HBH key is also used for HBH encryption of RTCP. RTCP is not + E2E-encrypted in PERC. + +6.3. The Key Distributor Transmits the KEK (EKT Key) + + The Key Distributor sends the KEK (the EKT Key per [RFC8870]) to the + endpoint via the aforementioned DTLS-SRTP association. This key is + known only to the Key Distributor and endpoints; it is the most + important entity to protect, since having knowledge of this key (and + the SRTP master salt transmitted as a part of the same message) + allows an entity to decrypt any media packet in the conference. + + Note that the Key Distributor can send any number of EKT Keys to + endpoints. This information is used to rekey the entire conference. + Each key is identified by an SPI value. Endpoints MUST expect that a + conference might be rekeyed when a new participant joins a conference + or when a participant leaves a conference, in order to protect the + confidentiality of the conversation before and after such events. + + The SRTP master salt to be used by the endpoint is transmitted along + with the EKT Key. All endpoints in the conference utilize the same + SRTP master salt that corresponds with a given EKT Key. + + The Full EKT Tag in media packets is encrypted using a cipher + specified via the EKTKey message (e.g., AES Key Wrap with a 128-bit + key). This cipher is different than the cipher used to protect media + and is only used to encrypt the endpoint's SRTP master key (and other + EKT Tag data as per [RFC8870]). + + The KEK is not given to the Media Distributor. + +6.4. Endpoints Fabricate an SRTP Master Key + + As stated earlier, the E2E key determined via DTLS-SRTP MAY be + discarded in favor of a locally generated E2E SRTP master key. While + the DTLS-SRTP-derived SRTP master key can be used initially, the + endpoint might choose to change the SRTP master key periodically and + MUST change the SRTP master key as a result of the EKT Key changing. + + A locally generated SRTP master key is used along with the master + salt transmitted to the endpoint from the Key Distributor via the + EKTKey message to encrypt media end to end. + + Since the Media Distributor is not involved in E2E functions, it does + not create this key, nor does it have access to any endpoint's E2E + key. Note, too, that even the Key Distributor is unaware of the + locally generated E2E keys used by each endpoint. + + The endpoint transmits its E2E key to other endpoints in the + conference by periodically including it in SRTP packets in a Full EKT + Tag. When placed in the Full EKT Tag, it is encrypted using the EKT + Key provided by the Key Distributor. The master salt is not + transmitted, though, since all endpoints receive the same master salt + via the EKTKey message from the Key Distributor. The recommended + frequency with which an endpoint transmits its SRTP master key is + specified in [RFC8870]. + +6.5. Summary of Key Types and Entity Possession + + All endpoints have knowledge of the KEK. + + Every HBH key is distinct for a given endpoint; thus, Endpoint A and + Endpoint B do not have knowledge of the other's HBH key. Since HBH + keys are derived from a DTLS-SRTP association, there is at most one + HBH key per endpoint. (The only exception is where the DTLS-SRTP + association might be rekeyed per Section 5.2 of [RFC5764] and a new + key is created to replace the former key.) + + Each endpoint generates its own E2E key (SRTP master key); thus, + there is a distinct E2E key per endpoint. This key is transmitted + (encrypted) via the Full EKT Tag to other endpoints. Endpoints that + receive media from a given transmitting endpoint gain knowledge of + the transmitter's E2E key via the Full EKT Tag. + + Table 2 summarizes the various keys and which entity is in possession + of a given key. + + +=======================+============+======+======+============+ + | Key/Entity | Endpoint A | MD X | MD Y | Endpoint B | + +=======================+============+======+======+============+ + | KEK (EKT Key) | Yes | No | No | Yes | + +-----------------------+------------+------+------+------------+ + | E2E Key (A and B) | Yes | No | No | Yes | + +-----------------------+------------+------+------+------------+ + | HBH Key (A<=>MD X) | Yes | Yes | No | No | + +-----------------------+------------+------+------+------------+ + | HBH Key (B<=>MD Y) | No | No | Yes | Yes | + +-----------------------+------------+------+------+------------+ + | HBH Key (MD X<=>MD Y) | No | Yes | Yes | No | + +-----------------------+------------+------+------+------------+ + + Table 2: Key Types and Entity Possession + +7. Encrypted Media Packet Format + + Figure 4 presents a complete picture of what an encrypted media + packet per this framework looks like when transmitted over the wire. + The packet format shown in the figure is encrypted using the double + cryptographic transform with an EKT Tag appended to the end. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++ + |V=2|P|X| CC |M| PT | sequence number | IO + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO + | timestamp | IO + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO + | synchronization source (SSRC) identifier | IO + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO + | contributing source (CSRC) identifiers | IO + | .... | IO + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O + | RTP extension (OPTIONAL) ... | |O ++>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O +O I | payload ... | IO +O I | +-------------------------------+ IO +O I | | RTP padding | RTP pad count | IO +O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O +O | | E2E authentication tag | |O +O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O +O | | OHB ... | |O ++>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ +| | | HBH authentication tag | || +| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || +| | | EKT Tag ... | R || +| | +-+-+-+-+-+-+-+-+-+ | || +| | +- Neither encrypted nor authenticated; || +| | appended after the double transform || +| | is performed || +| | || +| +- E2E-Encrypted Portion E2E-Authenticated Portion ---+| +| | ++--- HBH-Encrypted Portion HBH-Authenticated Portion ----+ + + I = Inner (E2E) encryption/authentication + O = Outer (HBH) encryption/authentication + + Figure 4: Encrypted Media Packet Format + +8. Security Considerations + +8.1. Third-Party Attacks + + Third-party attacks are attacks attempted by an adversary that is not + supposed to have access to keying material or is otherwise not an + authorized participant in the conference. + + On-path attacks are mitigated by HBH integrity protection and + encryption. The integrity protection mitigates packet modification. + Encryption makes selective blocking of packets harder, but not + impossible. + + Off-path attackers could try connecting to different PERC entities to + send specifically crafted packets with an aim of forcing the receiver + to forward or render bogus media packets. Endpoints and Media + Distributors mitigate such an attack by performing HBH authentication + and discarding packets that fail authentication. + + Another attack vector is a third party claiming to be a Media + Distributor, fooling endpoints into sending packets to the false + Media Distributor instead of the correct one. The deceived sending + endpoints could incorrectly assume that their packets have been + delivered to endpoints when they in fact have not. While this attack + is possible, the result is a simple denial of service with no leakage + of confidential information, since the false Media Distributor would + not have access to either HBH or E2E encryption keys. + + A third party could cause a denial of service by transmitting many + bogus or replayed packets toward receiving devices and ultimately + degrading conference or device performance. Therefore, + implementations might wish to devise mechanisms to safeguard against + such illegitimate packets, such as utilizing rate-limiting or + performing basic sanity checks on packets (e.g., looking at packet + length or expected sequence number ranges), before performing + decryption operations that are more expensive. + + The use of mutual DTLS authentication (as required by DTLS-SRTP) also + helps to prevent a denial-of-service attack by preventing a false + endpoint or false Media Distributor from successfully participating + as a perceived valid media sender that could otherwise carry out an + on-path attack. When mutual authentication fails, a receiving + endpoint would know that it could safely discard media packets + received from the endpoint without inspection. + +8.2. Media Distributor Attacks + + A malicious or compromised Media Distributor can attack the session + in a number of possible ways, as discussed below. + +8.2.1. Denial of Service + + A simple form of attack is discarding received packets that should be + forwarded. This solution framework does not provide any mitigation + mechanisms for Media Distributors that fail to forward media packets. + + Another form of attack is modifying received packets before + forwarding. With this solution framework, any modification of the + E2E-authenticated data results in the receiving endpoint getting an + integrity failure when performing authentication on the received + packet. + + The Media Distributor can also attempt to perform resource + consumption attacks on the receiving endpoint. One such attack would + be to insert random SSRC/CSRC values in any RTP packet along with a + Full EKT Tag. Since such a message would trigger the receiver to + form a new cryptographic context, the Media Distributor can attempt + to consume the receiving endpoint's resources. While E2E + authentication would fail and the cryptographic context would be + destroyed, the key derivation operation would nonetheless consume + some computational resources. While resource consumption attacks + cannot be mitigated entirely, rate-limiting packets might help reduce + the impact of such attacks. + +8.2.2. Replay Attacks + + A replay attack is an attack where an already-received packet from a + previous point in the RTP stream is replayed as a new packet. This + could, for example, allow a Media Distributor to transmit a sequence + of packets identified as a user saying "yes", instead of the "no" the + user actually said. + + A replay attack is mitigated by the requirement to implement replay + protection as described in Section 3.3.2 of [RFC3711]. E2E replay + protection MUST be provided for the duration of the conference. + +8.2.3. Delayed Playout Attacks + + A delayed playout attack is an attack where media is received and + held by a Media Distributor and then forwarded to endpoints at a + later point in time. + + This attack is possible even if E2E replay protection is in place. + Because the Media Distributor is allowed to select a subset of + streams and not forward the rest to a receiver, such as in forwarding + only the most active speakers, the receiver has to accept gaps in the + E2E packet sequence. The problem here is that a Media Distributor + can choose to not deliver a particular stream for a while. + + While the Media Distributor can purposely stop forwarding media + flows, it can also select an arbitrary starting point to resume + forwarding those media flows, perhaps forwarding old packets rather + than current packets. As a consequence, what the media source sent + can be substantially delayed at the receiver with the receiver + believing that newly arriving packets are delayed only by transport + delay when the packets may actually be minutes or hours old. + + While this attack cannot be eliminated entirely, its effectiveness + can be reduced by rekeying the conference periodically, since + significantly delayed media encrypted with expired keys would not be + decrypted by endpoints. + +8.2.4. Splicing Attacks + + A splicing attack is an attack where a Media Distributor receiving + multiple media sources splices one media stream into the other. If + the Media Distributor were able to change the SSRC without the + receiver having any method for verifying the original source ID, then + the Media Distributor could first deliver stream A and then later + forward stream B under the same SSRC that stream A was previously + using. By including the SSRC in the integrity check for each packet + -- both HBH and E2E -- PERC prevents splicing attacks. + +8.2.5. RTCP Attacks + + PERC does not provide E2E protection of RTCP messages. This allows a + compromised Media Distributor to impact any message that might be + transmitted via RTCP, including media statistics, picture requests, + or loss indication. It is also possible for a compromised Media + Distributor to forge requests, such as requests to the endpoint to + send a new picture. Such requests can consume significant bandwidth + and impair conference performance. + +8.3. Key Distributor Attacks + + As stated in Section 3.2.2, the Key Distributor needs to be secured, + since exploiting the Key Server can allow an adversary to gain access + to the keying material for one or more conferences. Having access to + that keying material would then allow the adversary to decrypt media + sent from any endpoint in the conference. + + As a first line of defense, the Key Distributor authenticates every + security association -- associations with both endpoints and Media + Distributors. The Key Distributor knows which entities are + authorized to have access to which keys, and inspection of + certificates will substantially reduce the risk of providing keys to + an adversary. + + Both physical and network access to the Key Distributor should be + severely restricted. This may be more difficult to achieve when the + Key Distributor is embedded within, for example, an endpoint. + Nonetheless, consideration should be given to shielding the Key + Distributor from unauthorized access or any access that is not + strictly necessary for the support of an ongoing conference. + + Consideration should be given to whether access to the keying + material will be needed beyond the conclusion of a conference. If + not needed, the Key Distributor's policy should be to destroy the + keying material once the conference concludes or when keying material + changes during the course of the conference. If keying material is + needed beyond the lifetime of the conference, further consideration + should be given to protecting keying material from future exposure. + While it might seem obvious, it is worth making this point, to avoid + any doubt that if an adversary were to record the media packets + transmitted during a conference and then gain unauthorized access to + the keying material left unsecured on the Key Distributor even years + later, the adversary could decrypt the content of every packet + transmitted during the conference. + +8.4. Endpoint Attacks + + A Trusted Endpoint is so named because conference confidentiality + relies heavily on the security and integrity of the endpoint. If an + adversary successfully exploits a vulnerability in an endpoint, it + might be possible for the adversary to obtain all of the keying + material used in the conference. With that keying material, an + adversary could decrypt any of the media flows received from any + other endpoint, either in real time or at a later point in time + (assuming that the adversary makes a copy of the media packets). + + Additionally, if an adversary successfully exploits an endpoint, the + adversary could inject media into the conference. For example, an + adversary could manipulate the RTP or SRTP software to transmit + whatever media the adversary wishes to send. This could involve the + reuse of the compromised endpoint's SSRC or, since all conference + participants share the same KEK, the use of a new SSRC or the SSRC + value of another endpoint. Only a single SRTP cipher suite defined + provides source authentication properties that allow an endpoint to + cryptographically assert that it sent a particular E2E-protected + packet (namely, Timed Efficient Stream Loss-Tolerant Authentication + (TESLA) [RFC4383]), and its usage is presently not defined for PERC. + The suite defined in PERC only allows an endpoint to determine that + whoever sent a packet had received the KEK. + + However, attacks on the endpoint are not limited to the PERC-specific + software within the endpoint. An attacker could inject media or + record media by manipulating the software that sits between the PERC- + enabled application and the hardware microphone of a video camera, + for example. Likewise, an attacker could potentially access + confidential media by accessing memory, cache, disk storage, etc. if + the endpoint is not secured. + +9. IANA Considerations + + This document has no IANA actions. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <https://www.rfc-editor.org/info/rfc3550>. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + <https://www.rfc-editor.org/info/rfc3711>. + + [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure + Real-time Transport Protocol (SRTP)", RFC 6904, + DOI 10.17487/RFC6904, April 2013, + <https://www.rfc-editor.org/info/rfc6904>. + + [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>. + + [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, + "Double Encryption Procedures for the Secure Real-Time + Transport Protocol (SRTP)", RFC 8723, + DOI 10.17487/RFC8723, April 2020, + <https://www.rfc-editor.org/info/rfc8723>. + + [RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. + Andreasen, "Encrypted Key Transport for DTLS and Secure + RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021, + <https://www.rfc-editor.org/info/rfc8870>. + +10.2. Informative References + + [PERC-DTLS] + Jones, P. E., Ellenbogen, P. M., and N. H. Ohlmeier, "DTLS + Tunnel between a Media Distributor and Key Distributor to + Facilitate Key Exchange", Work in Progress, Internet- + Draft, draft-ietf-perc-dtls-tunnel-06, 16 October 2019, + <https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel- + 06>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC4353] Rosenberg, J., "A Framework for Conferencing with the + Session Initiation Protocol (SIP)", RFC 4353, + DOI 10.17487/RFC4353, February 2006, + <https://www.rfc-editor.org/info/rfc4353>. + + [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient + Stream Loss-Tolerant Authentication (TESLA) in the Secure + Real-time Transport Protocol (SRTP)", RFC 4383, + DOI 10.17487/RFC4383, February 2006, + <https://www.rfc-editor.org/info/rfc4383>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + + [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework + for Establishing a Secure Real-time Transport Protocol + (SRTP) Security Context Using Datagram Transport Layer + Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May + 2010, <https://www.rfc-editor.org/info/rfc5763>. + + [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for the Secure + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, + <https://www.rfc-editor.org/info/rfc5764>. + + [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time + Transport Protocol (RTP) Header Extension for Client-to- + Mixer Audio Level Indication", RFC 6464, + DOI 10.17487/RFC6464, December 2011, + <https://www.rfc-editor.org/info/rfc6464>. + + [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, + DOI 10.17487/RFC7667, November 2015, + <https://www.rfc-editor.org/info/rfc7667>. + + [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, + "Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 8224, + DOI 10.17487/RFC8224, February 2018, + <https://www.rfc-editor.org/info/rfc8224>. + + [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, + DOI 10.17487/RFC8827, January 2021, + <https://www.rfc-editor.org/info/rfc8827>. + + [W3C.CR-webrtc] + Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: + Real-time Communication Between Browsers", W3C Proposed + Recommendation, <https://www.w3.org/TR/webrtc/>. + +Acknowledgments + + The authors would like to thank Mo Zanaty, Christian Oien, and + Richard Barnes for invaluable input on this document. Also, we would + like to acknowledge Nermeen Ismail for serving on the initial draft + versions of this document as a coauthor. We would also like to + acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for + providing some of the text in the document, including much of the + original text in the Security Considerations section (Section 8). + +Authors' Addresses + + Paul E. Jones + Cisco + 7025 Kit Creek Rd. + Research Triangle Park, North Carolina 27709 + United States of America + + Phone: +1 919 476 2048 + Email: paulej@packetizer.com + + + David Benham + Independent + California + United States of America + + Email: dabenham@gmail.com + + + Christian Groves + Independent + Melbourne + Australia + + Email: cngroves.std@gmail.com |