3.1.Untrusted Entities

The architecture described in this framework document enablesconferencing infrastructure to be hosted in domains, such as in acloud conferencing provider's facilities, where the trustworthiness isbelow the level needed to assume that the privacy of the participant's mediais not compromised. The conferencing infrastructure in such adomain is still trusted with reliably connecting the participantstogether in a conference but is not trusted with keying material neededto decrypt any of the participant's media. Entities in suchless-trustworthy domains are referred to as untrustedentities from this point forward.¶

It is important to understand that "untrusted" in this document does notmean that an entity is not expected to function properly. Rather, it meansonly that the entity does not have access to the E2E media encryptionkeys.¶

3.2.Trusted Entities

From the PERC model system's perspective, entities considered trusted(refer toFigure 1) can be in possession of the E2E mediaencryption keys for one or more conferences.¶

4.1.E2E-Authenticated and HBH-Authenticated Encryption

This solution framework focuses on the E2E privacy andintegrity of the participant's media by limiting access to only trustedentities to the E2E key used for authenticated E2E encryption.However, this framework does give a Media Distributor access to RTP headerfields and header extensions, as well as the ability to modify a certainsubset of the header fields and to add or change header extensions. Packetsreceived by a Media Distributor or an endpoint are authenticatedhop by hop.¶

To enable all of the above, this framework defines the use of twosecurity contexts and two associated encryption keys: an "inner" key(a distinct E2E key for each transmitted media flow) for authenticatedencryption of RTP media between endpoints and an "outer" key (a HBH key)known only to a Media Distributor or the adjacent endpointfor the hop between an endpoint and a Media Distributor or peer endpoint.An endpoint will receive one or more E2E keys fromevery other endpoint in the conference that correspond to the media flowstransmitted by those other endpoints, while HBH keys are derived fromthe DTLS-SRTP association with the Key Distributor. Two communicatingMedia Distributors use DTLS-SRTP associations directly with each other toobtain the HBH keys they will use. SeeSection 4.5 for more detailson 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  |+-------------+                                +-------------+

The double transform[RFC8723] enables endpointsto perform encryption using both the E2E and HBH contexts whilestill preserving the same overall interface as other SRTPtransforms. The Media Distributor simply uses the correspondingnormal (single) AES-GCM transform, keyed with the appropriate HBHkeys. SeeSection 6.1 for a description of the keys used in PERCandSection 7 for a diagram of how encrypted RTP packets appear on thewire.¶

RTCP is only encrypted hop by hop -- not end to end. This frameworkdoes not provide an additional step for RTCP-authenticatedencryption. Rather, implementations utilize the existing proceduresspecified in[RFC3711]; those procedures usethe same outer, HBH cryptographic context chosen in the double transform operationdescribed above. For this reason, endpointsMUST NOT sendconfidential 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 isknown only by the trusted entities in a conference. That KEK, definedin the EKT specification[RFC8870] as the EKT Key, isused 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 masterkey for E2E-authenticated encryption andkeeps track of the E2E keys received via the Full EKT Tag foreach distinct synchronization source (SSRC) in the conference so that itcan properly decrypt received media. An endpoint may change its E2E key at anytime 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 endpointmight send more than one at a time and change the mix of media flowstransmitted during the lifetime of a conference.¶

Thus, an endpointMUST maintain a list of SSRCs from received RTPflows and each SSRC's associated E2E key information. An endpointMUSTdiscard old E2E keys no later than when it leaves the conference.¶

If the packet is to contain RTP header extensions, it should be notedthat those extensions are only encrypted hop by hop per[RFC8723]. Forthis reason, endpointsMUST NOT transmit confidential informationvia RTP header extensions.¶

4.4.HBH Keys and Per-Hop Operations

To ensure the integrity of transmitted media packets, it isREQUIRED that every packet be authenticated hop by hop betweenan endpoint and a Media Distributor, as well as between MediaDistributors. The authentication key used for HBHauthentication is derived from an SRTP master key shared only on therespective hop. Each HBH key is distinct per hop, and no two hops everuse the same SRTP master key.¶

While endpoints also perform HBH authentication, the ability of the endpointsto reconstruct the original RTP header also enables the endpoints toauthenticate RTP packets end to end. This design yields flexibility to the MediaDistributor to change certain RTP header values as packets areforwarded. Values that the Media Distributor can change in the RTP headerare defined in[RFC8723]. RTCP can only be encrypted hop byhop, giving the Media Distributor the flexibility to (1) forward RTCPcontent unchanged, (2) transmit compound RTCP packets, (3) initiateRTCP packets for reporting statistics, or (4) convey other information.Performing HBH authentication for all RTP and RTCP packets also helpsprovide replay protection (seeSection 8). The use of the replayprotection mechanism specified inSection 3.3.2 of [RFC3711] isREQUIRED at each hop.¶

If there is a need to encrypt one or more RTP header extensionshop by hop, the endpoint derives an encryption key from the HBH SRTPmaster key to encrypt header extensions as per[RFC6904]. Thisstill gives the Media Distributor visibility into header extensions,such as the one used to determine the audio level[RFC6464] of conferenceparticipants. Note that when RTP header extensions are encrypted, allhops need to decrypt andre-encrypt these encrypted header extensions. Please refer toSections 5.1,5.2, and5.3 of[RFC8723] for proceduresto perform RTP header extension encryption and decryption.¶

4.5.Key Exchange

In brief, the keys used by any given endpoints are determined asfollows:¶

• The HBH keys that the endpoint uses to send and receive SRTP mediaare derived from a DTLS handshake that the endpoint performs withthe Key Distributor (following normal DTLS-SRTP procedures).¶
• The E2E key that an endpoint uses to send SRTP media can beeither set from the DTLS-SRTP association with the Key Distributor or chosenby the endpoint. It is then distributed to other endpoints in aFull EKT Tag, encrypted under an EKT Key provided to the client by theKey Distributor within the DTLS channel they negotiated. Note thatan endpointMAY create a different E2E key per media flow, where amedia flow is identified by its SSRC value.¶
• Each E2E key that an endpoint uses to receive SRTP media is setby receiving a Full EKT Tag from another endpoint.¶
• The HBH keys used between two Media Distributors are derived viaDTLS-SRTP procedures employed directly between them.¶

                          +-----------+                 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  |+-----------+             +-----------+             +-----------+

5.1.Identity Assertions

A WebRTC identity assertion[RFC8827] is usedto bind the identity of the user of the endpoint to the fingerprint ofthe DTLS-SRTP certificate used for the call. This certificate isunique for a given call and a conference. This certificate is unique for a given call and a conference, allowing theKey Distributor to ensure that only authorized users participate in theconference. Similarly, the Key Distributor can create a WebRTC identityassertion to bind the fingerprint of the unique certificate used bythe Key Distributor for this conference so that the endpoint canverify that it is talking to the correct Key Distributor. Such a setuprequires an Identity Provider (IdP) trusted by the endpoints and theKey Distributor.¶

5.2.Certificate Fingerprints in Session Signaling

Entities managing session signaling are generally assumed to beuntrusted in the PERC framework. However, there are some deploymentscenarios where parts of the session signaling may be assumedtrustworthy for the purposes of exchanging, in a manner that can beauthenticated, the fingerprint of an entity's certificate.¶

As a concrete example, SIP[RFC3261] andthe Session Description Protocol (SDP)[RFC4566] can be usedto convey the fingerprint information per[RFC5763]. An endpoint'sSIP User Agent would send an INVITE message containing SDP for themedia session along with the endpoint's certificate fingerprint, whichcan be signed using the procedures described in[RFC8224] for thebenefit of forwarding the message to other entities by the focus[RFC4353]. Other entities can verify that the fingerprints match thecertificates found in the DTLS-SRTP connections to find the identityof the far end of the DTLS-SRTP connection and verify that it is theauthorized entity.¶

Ultimately, if using session signaling, an endpoint's certificatefingerprint would need to be securely mapped to a user and conveyed tothe Key Distributor so that it can check that the user in question is authorized.Similarly, the Key Distributor's certificate fingerprint can beconveyed to an endpoint in a manner that can be authenticated as being anauthorized Key Distributor for this conference.¶

5.3.Conference Identification

The Key Distributor needs to know what endpoints are being added to agiven conference. Thus, the Key Distributor and the Media Distributorneed to know endpoint-to-conference mappings, which are enabled byexchanging a conference-specific unique identifier as described in[PERC-DTLS]. How this uniqueidentifier is assigned is outside the scope of this document.¶

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 beacquired.¶

The various keys used in PERC are shown inTable 1 below.¶

While the number of key types is very small, it should be understood thatthe actual number of distinct keys can be large as the conferencegrows in size.¶

As an example, with 1,000 participants in a conference, there would be atleast 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 producethe actual encryption and authentication keys.¶

Complicating key management is the fact that the KEK can change and, whenit does, the endpoints generate new SRTP master keys that are associated witha new EKT SPI. Endpoints might retain old keys for a period of time toensure that they can properly decrypt late-arriving or out-of-order packets, whichmeans that the number of keys held during that period of time might besubstantially 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 anddecryption. Per the double transform procedures[RFC8723], theendpoint performs a DTLS-SRTP exchange with the Key Distributorand 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 discardsthat information when generating its own key. The second half of the keyingmaterial is for HBH operations, so that half of the key(corresponding to the least significant bits) is assigned internally asthe HBH key.¶

The Key Distributor informs the Media Distributor of the HBH key. Specifically,the Key Distributor sends the least significant bits corresponding to thehalf of the keying material determined through DTLS-SRTP with the endpointto the Media Distributor. A salt value isgenerated along with the HBH key. The salt is also longer than neededfor HBH operations; thus, only the least significant bits of therequired length (half of the generated salt material) are sent to theMedia Distributor. One way to transmit this key and salt informationis via the tunnel protocol defined in[PERC-DTLS].¶

No two endpoints have the same HBH key; thus, the Media DistributorMUST keep track of each distinct HBH key (and the corresponding salt) anduse it only for the specified hop.¶

The HBH key is also used for HBH encryption of RTCP. RTCP is notE2E-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 tothe Key Distributor and endpoints; it is the most important entity toprotect, since having knowledge of this key (and the SRTP master salttransmitted as a part of the same message) allows an entity todecrypt any media packet in the conference.¶

Note that the Key Distributor can send any number of EKT Keys toendpoints. This information is used to rekey the entire conference. Eachkey is identified by an SPI value.EndpointsMUST expect that a conference might be rekeyedwhen a new participant joins a conference or when a participantleaves a conference, in order to protect the confidentiality ofthe conversation before and after such events.¶

The SRTP master salt to be used by the endpoint is transmitted alongwith the EKT Key. All endpoints in the conference utilizethe same SRTP master salt that corresponds with a given EKT Key.¶

The Full EKT Tag in media packets is encrypted using a cipher specifiedvia the EKTKey message (e.g., AES Key Wrap with a 128-bit key). Thiscipher is different than the cipher used to protect media and is onlyused to encrypt the endpoint's SRTP master key (and other EKT Tag dataas 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-SRTPMAY bediscarded in favor of a locally generated E2E SRTP master key. While theDTLS-SRTP-derived SRTP master key can be used initially, the endpoint mightchoose to change the SRTP master key periodically andMUST change theSRTP master key as a result of the EKT Key changing.¶

A locally generated SRTP master key is used along with the master salttransmitted to the endpoint from the Key Distributor via the EKTKeymessage to encrypt media end to end.¶

Since the Media Distributor is not involved in E2E functions, it does notcreate 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 keysused by each endpoint.¶

The endpoint transmits its E2E key to other endpoints in the conferenceby periodically including it in SRTP packets in a Full EKT Tag. Whenplaced in the Full EKT Tag, it is encrypted using the EKT Key providedby the Key Distributor. The master salt is not transmitted, though,since all endpoints receive the same master salt via the EKTKeymessage from the Key Distributor. The recommended frequency with which anendpoint 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 andEndpoint B do not have knowledge of the other's HBH key. Since HBH keysare derived from a DTLS-SRTP association, there is at most one HBH keyper endpoint. (The only exception is where the DTLS-SRTP association mightbe rekeyed perSection 5.2 of [RFC5764] and a new key is created toreplace 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) viathe Full EKT Tag to other endpoints. Endpoints that receive media froma given transmitting endpoint gain knowledge of thetransmitter's E2E key via the Full EKT Tag.¶

Table 2 summarizes the various keys and which entity is in possession of a given key.¶

8.1.Third-Party Attacks

Third-party attacks are attacks attempted by an adversary that is notsupposed to have access to keying material or is otherwise not anauthorized participant in the conference.¶

On-path attacks are mitigated by HBH integrity protection andencryption. The integrity protection mitigates packet modification.Encryption makes selective blocking of packets harder, but notimpossible.¶

Off-path attackers could try connecting to different PERC entities tosend specifically crafted packets with an aim of forcing the receiver toforward or render bogus media packets. Endpoints and Media Distributors mitigatesuch an attack by performing HBH authentication and discarding packetsthat fail authentication.¶

Another attack vector is a third party claiming to be a MediaDistributor, fooling endpoints into sending packets to the falseMedia Distributor instead of the correct one. The deceived sendingendpoints could incorrectly assume that their packets have been deliveredto endpoints when they in fact have not. While this attack is possible,the result is a simple denial of service with no leakage of confidentialinformation, since the false Media Distributor would not have accessto either HBH or E2E encryption keys.¶

A third party could cause a denial of service by transmitting many bogusor replayed packets toward receiving devices and ultimately degradingconference or device performance. Therefore, implementations might wish todevise mechanisms to safeguard against such illegitimate packets, such asutilizing rate-limiting or performing basic sanity checks on packets(e.g., looking at packet length or expected sequence number ranges), beforeperforming decryption operations that are more expensive.¶

The use of mutual DTLS authentication (as required by DTLS-SRTP) also helps toprevent a denial-of-service attack by preventing a false endpoint or falseMedia Distributor from successfully participating as a perceived valid mediasender that could otherwise carry out an on-path attack. When mutualauthentication fails, a receiving endpoint would know that it could safelydiscard media packets received from the endpoint without inspection.¶

8.2.Media Distributor Attacks

A malicious or compromised Media Distributor can attack the session in anumber of possible ways, as discussed below.¶

8.3.Key Distributor Attacks

As stated inSection 3.2.2, the Key Distributor needs to be secured,since exploiting the Key Server can allow an adversary to gain access tothe keying material for one or more conferences. Having access to thatkeying material would then allow the adversary to decrypt media sent fromany endpoint in the conference.¶

As a first line of defense, the Key Distributor authenticates everysecurity association -- associations with both endpoints and MediaDistributors. The Key Distributor knows which entities are authorized tohave access to which keys, and inspection of certificates will substantiallyreduce the risk of providing keys to an adversary.¶

Both physical and network access to the Key Distributor should be severelyrestricted. This may be more difficult to achieve when the Key Distributoris embedded within, for example, an endpoint. Nonetheless, considerationshould be given to shielding the Key Distributor from unauthorized accessor any access that is not strictly necessary for the support of anongoing conference.¶

Consideration should be given to whether access to the keying materialwill be needed beyond the conclusion of a conference. If not needed,the Key Distributor's policy should be to destroy the keying materialonce the conference concludes or when keying material changes duringthe course of the conference. If keying material is needed beyond thelifetime of the conference, further consideration should be given toprotecting keying material from future exposure. While it might seemobvious, it is worth making this point, to avoid any doubt that if an adversary wereto record the media packets transmitted during a conference and thengain unauthorized access to the keying material left unsecured on theKey Distributor even years later, the adversary could decrypt thecontent of every packet transmitted during the conference.¶

8.4.Endpoint Attacks

A Trusted Endpoint is so named because conference confidentiality reliesheavily on the security and integrity of the endpoint. If an adversarysuccessfully exploits a vulnerability in an endpoint, it might be possiblefor the adversary to obtain all of the keying material used in theconference. With that keying material, an adversary could decrypt anyof the media flows received from any other endpoint, either in real timeor at a later point in time (assuming that the adversary makes a copy of themedia packets).¶

Additionally, if an adversary successfully exploits an endpoint, theadversary could inject media into the conference. For example, an adversarycould manipulate the RTP or SRTP software to transmitwhatever 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 sourceauthentication properties that allow an endpoint to cryptographicallyassert that it sent a particular E2E-protected packet (namely, Timed EfficientStream Loss-Tolerant Authentication (TESLA)[RFC4383]), and its usage is presently notdefined for PERC. The suitedefined in PERC only allows an endpoint to determine that whoever sent apacket had received the KEK.¶

However, attacks on the endpoint are not limited to the PERC-specificsoftware within the endpoint. An attacker could inject media or recordmedia by manipulating the software that sits between the PERC-enabledapplication and the hardware microphone of a video camera, for example.Likewise, an attacker could potentially access confidential media byaccessing memory, cache, disk storage, etc. if the endpoint is not secured.¶