[要約] RFC 8871は、プライバシー強化RTP会議（PERC）におけるプライベートメディアのためのソリューションフレームワークを提供します。このRFCの目的は、PERC環境でのプライベートメディアのセキュリティとプライバシーを向上させることです。
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)
プライバシー強化RTP会議（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).
このドキュメントは、メディアの機密性と整合性がエンドツーエンドのメディア暗号化キーで信頼されていない交換会議環境のコンテキスト内で終了することを保証するためのソリューションフレームワークを説明しています。ソリューションは、リアルタイムトランスポートプロトコル（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.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
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.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、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.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
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
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.
交換会議は、オーディオ、ビデオ、テキスト、その他のメディアタイプの組み合わせを使用して、複数の参加者とのマルチメディアカンファレンスのためのますます一般的なモデルです。このモデルでは、会議参加者からのリアルタイムメディアフローは、伝統的なメディアサーバーまたはマルチポイントコントロールユニット（MCU）の場合があるため、メディアディストリビュータによって混在、トランスコード、翻訳、再帰的、またはその他の方法で操作されません。代わりに、会議参加者によって送信されたメディアフローは、他の各参加者にメディアディストリビュータによって単純に転送されます。メディアディストリビューターは、音声活動検出または他の基準に基づいてフローのサブセットのみを転送します。いくつかの例では、メディアディストリビュータは、例えばRTPヘッダ[RFC3550]に制限された変更を加えることができるが、実際のメディアコンテンツ（例えば、音声またはビデオデータ）は変更されない。
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.
この文書は、会議参加者間で送信された実際のメディアコンテンツを復号化または認証するのに必要なキーへのアクセスを不可能にすることで、メディアのプライバシーが保証されるソリューションフレームワークを定義します。同時に、フレームワークはメディアディストリビュータが特定のRTPヘッダーを変更することを可能にします。RTPヘッダー拡張機能を追加、削除、暗号化、または復号化します。RTP制御プロトコル（RTCP）パケット[RFC3550]を暗号化および復号化します。フレームワークはまた、メディア暗号化および認証のためのキーとは無関係のエンドポイントごとに一意のキーを使用して、特定の参加者とメディアディストリビュータを使用して送信される各パケットを認証することによって、再生攻撃を防ぎます。
This solution framework provides for enhanced privacy in RTP-based conferencing environments while utilizing existing security procedures defined for RTP with minimal enhancements.
このソリューションフレームワークは、最小限の機能強化でRTPに定義された既存のセキュリティ手順を利用しながら、RTPベースの会議環境におけるプライバシーの強化を提供します。
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.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
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.
エンドツーエンド（E2E）：あるエンドポイントから1つ以上のメディアディストリビュータへの通信相手のエンドポイントへの通信。
Hop-by-Hop (HBH): Communications between an endpoint and a Media Distributor or between Media Distributors.
ホップバイホップ（HBH）：エンドポイントとメディアディストリビュータ間の通信、またはメディア配信業者間の通信。
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).
信頼されたエンドポイント（または単にエンドポイント）：E2Eメディア暗号化キーを所有しているRTPフロー終了エンティティとE2E暗号化を終了します。これには、特定の展開のための信頼できるドメインにあるコンピュータ、メディアゲートウェイ、MCU、メディア記録装置などの組み込みユーザー会議機器またはブラウザが含まれます。セッションの制御がJavaScriptアプリケーションとブラウザの間で分割されているWebRTC [w3c.cr-webrtc]のコンテキストでは、ブラウザはこのフレームワークの目的のために信頼できるエンドポイントとして機能します（DTLSのエンドポイントとして機能するのと同じように-srtp [RFC5764] 1対1の呼び出し）。
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.
Media Distributor（MD）：エンドポイントメディアコンテンツ（音声またはビデオデータ）を変更しない - サブセットまたはすべてのフローのいずれかを変更したRTPミドルボックス - E2E暗号化キーにアクセスできることを許可されていません。。Privacy-Enhanced RTP会議（PERC）システムで定義されている制約ごとに選択的転送ミドルボックスRTPトポロジー[RFC7667]に従って動作します。これには、RTPメディアの平文にアクセスできない変更できるRTPヘッダーフィールドの制限。メディアディストリビュータによって修正される可能性があるヘッダフィールドは、ダブル暗号変換仕様[RFC8723]のセクション4で列挙され、この文書で概説されているユーティリティおよびセキュリティ上の考慮事項に関して選択されます。
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.
KEY Distributor：キーイングマテリアルと関連情報を信頼できるエンドポイントとメディアディストリビュータに配布する論理関数であるエンティティは、それぞれに適しているものだけです。鍵販売代理店は、E2Eキーイング材料で信頼されている別のエンティティと共存している可能性があります。
Conference: Two or more participants communicating via Trusted Endpoints to exchange RTP flows through one or more Media Distributors.
会議：信頼できるエンドポイントを介してコミュニケーションをとる2つ以上の参加者は、1つ以上のメディアディストリビュータを介してRTPの流れを流します。
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].
通話処理：すべての信頼済みエンドポイントは、例えば、「セッション開始プロトコル（SIP）との会議のためのフレームワーク」で定義されている「フォーカス」を介して、「フォーカス」を介して会議に接続します。
Third Party: Any entity that is not an endpoint, Media Distributor, Key Distributor, or call processing entity as described in this document.
第三者：この文書に記載されているエンドポイント、メディアディストリビュータ、鍵配布者、または呼処理エンティティではないエンティティ。
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.
図1は、後続のサブセクションで説明されているエンティティ間の信頼関係、直接的または間接的なものを示しています。これらのエンティティは、同じ場所に配置またはさらに別々の物理デバイスに分割されてもよいことに注意してください。
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
図1：PERCの信頼されていると信頼できないエンティティ
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.
このフレームワークドキュメントに記載されているアーキテクチャは、CloudNiencing Providerの施設など、ドメイン内でホストされることを可能にし、信頼性は、参加者のメディアのプライバシーが損なわれないと仮定されていないレベルを下回ることができます。そのようなドメインの会議インフラストラクチャは、会議で参加者を確実に接続することで信頼されていますが、参加者のメディアのどれかを復号化するのに必要なキーワードと信頼されていません。そのような信頼できるドメインのエンティティは、この時点から信頼できないエンティティと呼ばれます。
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.
この文書の「信頼されていない」がエンティティが正しく機能することが期待されていないことを意味しないことを理解することは重要です。そうではなく、エンティティがE2Eメディア暗号化キーにアクセスできないことだけを意味します。
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.
メディアディストリビュータは、各RTPパケットのホップごとの認証を実行しながら、会議のエンドポイント間のRTPフローを転送します。メディアディストリビュータは、1つまたは複数のRTPヘッダまたはヘッダ拡張機能にアクセスする必要があり、特定のサブセットを追加または変更することができる。メディアディストリビューターはまた、エンドポイントと鍵ディストリビュータの間のセキュアメッセージングを中継し、キーディストリビュータからホップごとのキー情報を取得します。実際のメディアコンテンツは、E2Eメディア暗号化キーにアクセスできるように信頼されていないため、メディアディストリビュータによって復号化できません。このフレームワークで指定された鍵交換機構は、メディアディストリビュータがE2Eメディア暗号化キーへのアクセスを許可しないようにします。
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.
メディアディストリビュータによってサービスを提供する会議に接続するエンドポイントの機能は、エンドポイントがE2Eメディア暗号化キーにアクセスできることを意味しているが、メディアディストリビュータはエンドポイントが許可されているかどうかを判断する機能を有していないことを意味します。代わりに、キーディストリビュータはエンドポイントを認証し（例えば、WEBRTC IDアサーション[RFC8827]を使用）、E2EおよびHBHメディア暗号化キーを受信する権限を決定する責任があります。
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.
メディアディストリビュータは、サービス拒否攻撃の悪影響を軽減するためのメディアパケットを正しく転送するのに役割を果たしている必要があります（セクション8）、従来の会議（非PERC）展開よりも等しいレベルまで。
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.
メディアディストリビュータまたは関連する会議インフラストラクチャはまた、会議管理に関連するさまざまなメッセージング技術を開始または終了させることができる。このトピックはこのフレームワーク文書の範囲外です。
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.
通話処理は、シンプルで一般的な展開シナリオでは信頼されていません。通話処理の物理サブセットが信頼されたドメインの外部の機能にあるとき、それはE2Eキー情報にアクセスできるように信頼されるべきではありません。
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.
呼処理は、呼シグナリングメッセージの処理、ならびにそれらのメッセージの署名を含み得る。それはまた、呼シグナリングの目的で、そして続いて1つまたは複数のメディア配信業者を通してホストされた会議を参加させるためにエンドポイントを認証することができる。呼処理は、それ自体（呼処理）、エンドポイント、およびその他のエンティティ間の呼シグナリングメッセージのプライバシーを任意に保証することができる。
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.
PERCモデルシステムの観点から、信頼されたと見なされる事業体（図1参照）は、1つ以上の会議のためのE2Eメディア暗号化キーを所有することができます。
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.
エンドポイントは信頼されていると見なされ、E2Eキー情報にアクセスできます。エンドポイントが危険にさらされる可能性があるが、その後望ましくない方法で実行され、エンドポイント抵抗に対するエンドポイント抵抗を定義することはこの文書の範囲外である。エンドポイントは、他のエンドポイントを含む他のエンティティからのサービス拒否攻撃の悪影響を軽減するための措置を講じています。
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.
エンドポイントまたは存在スタンドアロンと同じ場所に配置されている可能性がある鍵販売代理店は、E2EとHBHセキュリティの両方のためのエンドポイントにキー情報を提供し、HBHセキュリティのためのメディアディストリビュータに鍵情報を提供する責任があります。
Interaction between the Key Distributor and call processing is necessary for proper conference-to-endpoint mappings. This is described in Section 5.3.
キーディストリビュータと呼処理との間の相互作用は、適切な会議からエンドポイントマッピングに必要です。これについてはセクション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.
鍵販売代理店は、どのエンドポイントとどのメディアディストリビュータが会議に参加する権限を与えられているかを知る必要があります。この情報がこの文書の範囲外にある鍵ディストリビュータがどのように取得されていますか。ただし、鍵配布者は、いかなる不正なエンドポイントまたはメディアディストリビュータとのDTLSアソシエーションを拒否しなければなりません。
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.
このフレームワークの目的は、切り替えられた1つまたは複数のメディア配信業者からなる会議環境内で通信するときに、メディアのプライバシーが確保され、したがってメディアを終了しないという手段を定義することです。それ以外の点では、エンドポイント間の会議が行われているという事実を隠そうとしていません。
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.
このフレームワークは、セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]、暗号化キートランスポート（EKT）[RFC8870]、およびDTLS-SRTPを含む、特定のRTPセキュリティテクノロジをいくつか再利用します。
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.
このソリューションフレームワークは、認証されたE2E暗号化に使用されるE2Eキーへの信頼できるエンティティのみへのアクセスを制限することによって、参加者のメディアのE2Eのプライバシーと完全性に焦点を当てています。ただし、このフレームワークは、RTPヘッダーフィールドとヘッダー拡張機能、およびヘッダーフィールドの特定のサブセットを変更したり、ヘッダー拡張機能を追加または変更する機能を提供したりすることができます。メディアディストリビュータまたはエンドポイントによって受信されたパケットはホップで認証されます。
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.
上記のすべてを有効にするには、このフレームワークは、2つのセキュリティコンテキストと関連する2つの暗号化キーの使用を定義します。エンドポイントとエンドポイント間のRTPメディアの認証された暗号化のための「内部」キー（送信された各メディアフローのための異なるE2Eキー）メディアディストリビュータまたはエンドポイントとメディアディストリビュータまたはピアエンドポイントの間のホップの隣接エンドポイントのみにわたるキー（HBHキー）。エンドポイントは、それらの他のエンドポイントによって送信されたメディアフローに対応する会議で、他のすべてのエンドポイントから1つ以上のE2Eキーを受信しますが、HBHキーはキーディストリビュータとのDTLS-SRTPアソシエーションから派生します。2つの通信メディアディストリビューターは、DTLS-SRTPアソシエーションを互いに直接使用して、それらが使用するHBHキーを取得します。キー交換の詳細については、セクション4.5を参照してください。
+-------------+ +-------------+
| |################################| |
| 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
図2：SRTPパケットの認証された暗号化に使用されるE2EおよびHBHキー
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.
Double Transform [RFC8723]は、E2EコンテキストとHBHコンテキストの両方を使用して暗号化を実行し、他のSRTP変換と同じ全体的なインターフェイスを保存しながら暗号化を実行できます。メディアディストリビュータは、適切なHBHキーでキー入力された対応する通常の（シングル）AES-GCM変換を単に使用します。PERCで使用されるキーとセクション7では、Wireに表示されているキーの説明については、セクション6.1を参照してください。
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.
RTCPはホップでのみ暗号化されていません。このフレームワークは、RTCP認証された暗号化に追加のステップを提供しません。むしろ、実装は[RFC3711]で指定された既存の手順を利用しています。これらの手順は、上述の二重変換動作で選択された同じ外側のHBH暗号文脈を使用する。このため、エンドポイントはRTCPを介して機密情報を送信してはなりません。
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].
エンドポイント間で共有されているE2Eキーの機密性を確保するために、エンドポイントは、会議の信頼できるエンティティによってのみ知られている共通のキー暗号化キー（KEK）を使用します。EKTキー[RFC8870]で定義されているそのKEKは、指定されたエンドポイントによって送信されたメディアのE2E認証された暗号化に使用されるSRTPマスターキーをその後暗号化するために使用されます。会議の各エンドポイントは、E2E認証された暗号化のためのSRTPマスターキーを作成し、それが受信メディアを正しく復号化することができるように、会議内の別個の同期ソース（SSRC）ごとにフルEKTタグを介して受信したE2Eキーを追跡します。エンドポイントは、E2Eキーをいつでも変更し、[RFC8870]で指定されているようにその新しいキーを会議に宣伝することがあります。
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.
特定のRTPメディアフローはそのSSRCによって識別され、エンドポイントは一度に複数を送信し、会議の存続期間中に送信されたメディアフローの組み合わせを変更することがあります。
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.
したがって、エンドポイントは、受信したRTPフローおよび各SSRCの各E2Eキー情報からのSSRCのリストを維持しなければなりません。エンドポイントは、会議を離れたときよりも後に、古いE2Eキーを廃棄しなければなりません。
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.
パケットにRTPヘッダー拡張子を含める場合は、それらの拡張機能は[RFC8723]に対してホップごとにのみ暗号化されていることに注意してください。このため、エンドポイントはRTPヘッダー拡張機能を介して機密情報を送信してはなりません。
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.
送信されたメディアパケットの完全性を確実にするためには、エンドポイントとメディアディストリビュータとの間のホップ、ならびにメディア配信業者間のホップによってすべてのパケットがホップすることが必要である。HBH認証に使用される認証キーは、各ホップ上でのみ共有されているSRTPマスターキーから派生しています。各HBHキーはホップごとに異なり、2ホップは同じSRTPマスターキーを使用していません。
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.
エンドポイントもHBH認証を実行する間、エンドポイントが元のRTPヘッダーを再構築する機能もまた、エンドポイントがRTPパケットの終了を認証することを可能にします。この設計は、パケットが転送されるときに特定のRTPヘッダ値を変更するために、メディアディストリビュータに対する柔軟性をもたらす。RTPヘッダーでメディアディストリビュータが変更できる値は[RFC8723]で定義されています。RTCPはホップでのみ暗号化でき、メディアディストリビュータに（1）順方向RTCPコンテンツの柔軟性を柔軟にして（2）送信する（2）送信統計情報を報告するためのRTCPパケットを開始する、または（4）他の情報を伝えます。すべてのRTPおよびRTCPパケットのHBH認証の実行は、再生保護を提供するのにも役立ちます（セクション8を参照）。各ホップで[RFC3711]のセクション3.3.2で指定されている再生保護メカニズムを使用することが必要です。
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.
1つ以上のRTPヘッダ拡張子をホップで暗号化する必要がある場合、エンドポイントはHBH SRTPマスターキーからの暗号化キーを導き、[RFC6904]に従ってヘッダー拡張子を暗号化します。これは、会議参加者のオーディオレベル[RFC6464]を決定するために使用されるものなど、ヘッダー拡張機能にメディアディストリビュータの可視性を示しています。RTPヘッダー拡張機能が暗号化されている場合、すべてのホップはこれらの暗号化されたヘッダー拡張機能を復号化して再暗号化する必要があります。RTPヘッダー拡張暗号化と復号化を実行する手順については、「RFC8723」のセクション5.1,5.2、および5.3を参照してください。
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).
* エンドポイントがSRTPメディアを送受信するために使用するHBHキーは、エンドポイントがキーディストリビュータで実行されるDTLSハンドシェイクから派生しています（通常のDTLS-SRTPプロシージャーに従って）。
* 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.
* EndpointがSRTPメディアを送信するために使用するE2Eキーは、DTLS-SRTPアソシエーションからキーディストリビュータを使用するか、またはエンドポイントによって選択できます。それは次にそれは完全なEKTタグ内の他のエンドポイントに配布され、ネゴシエートされたDTLSチャネル内の鍵ディストリビュータによってクライアントに提供されたEKTキーの下で暗号化されます。エンドポイントはメディアフローごとに異なるE2Eキーを作成し、そこでメディアフローがそのSSRC値によって識別されます。
* Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Tag from another endpoint.
* エンドポイントがSRTPメディアを受信するために使用する各E2Eキーは、別のエンドポイントからフルEKTタグを受信することによって設定されます。
* The HBH keys used between two Media Distributors are derived via DTLS-SRTP procedures employed directly between them.
* 2つのメディア分配器の間で使用されるHBHキーは、それらの間で直接使用されているDTLS-SRTPプロシージャーを介して導き出されます。
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.
メディアディストリビュータは、（たとえば、[PERC-DTLS]で定義されているトンネルプロトコルを使用して）キーディストリビュータとトンネルを管理し、メディアディストリビュータが各エンドポイントとキーディストリビュータの間のセキュアDTLS関連の確立を容易にすることを可能にします。図3に示すように、エンドポイントとキーディストリビュータの間のDTLSアソシエーションは、各エンドポイントがE2EおよびHBHキーを生成し、KEKを受信できます。同時に、キーディストリビュータはHBHキー情報をメディアディストリビュータに安全に提供します。ここに要約された重要な情報は、SRTPマスターキー、SRTPマスター塩、およびネゴシエートされた暗号変換を含み得る。
+-----------+
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
図3：エンティティ間のキー情報の交換
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.
メディアディストリビュータとキーディストリビュータの間のセキュアトンネルに加えて、次の段落で説明したように、鍵交換の一部として利用される2つの種類のセキュリティアソシエーションがあります。1つは、エンドポイントとキーディストリビュータ（メディアディストリビュータを通過するパケットを持つ）との間のDTLS-SRTPアソシエーション、もう1つはピアメディアディストリビュータ間のDTLS-SRTPアソシエーションです。
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.
エンドポイントは、キーディストリビュータとのキー情報交換を目的として、メディアディストリビュータとそのメディアポートとのRTPセッションを介したDTLS-SRTPアソシエーションを確立します。メディアディストリビュータはDTLSシグナリングを終了しないが、代わりに、メディアディストリビュータとキーディストリビュータの間に確立されたトンネルを介して、エンドポイントから受信したDTLSパケットをキーディストリビュータ（およびその逆）に転送します。
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.
エンドポイントとキーディストリビュータの間のDTLSアソシエーションを確立するとき、エンドポイントはDTLSクライアントとして機能し、鍵ディストリビュータはDTLSサーバーとして機能する必要があります。KEKは、EKTKEYメッセージを介してEKT [RFC8870]で定義されている手続きを介して、DTLSアソシエーションを介してキーディストリビュータを介してキーディストリビュータによって伝えられます。
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.
キーディストリビュータは、エンドポイントからDTLS-SRTPパケットをトンネリングするメディアディストリビュータトンネリングを最初に認証することなく、エンドポイントとのDTLS-SRTPアソシエーションを確立してはいけません。
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].
[RFC8723]で定義されている暗号のDTLS-SRTPプロシージャーに続いて、エンドポイントはE2EとHBH暗号化キーとSALT値の両方を生成します。エンドポイントは、送信のためにDTLS-SRTP生成E2Eキーを使用するか、フレッシュE2Eキーを生成する必要があります。いずれの場合も、E2E暗号化のための生成されたSRTPマスター塩は、EKTKEYメッセージを介して鍵ディストリビュータによって提供される塩値と置き換えなければならない。つまり、会議のすべてのエンドポイントは同じSRTPマスターソルトを使用しているためです。エンドポイントは、E2E暗号化に使用されるSRTPマスターキー（RFC8870]ごとのRTP / RTCPパケットの他のエンドポイントに送信します。
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.
Media Distributorsは、DTLS-SRTPをピアメディアディストリビュータで直接使用して、RTPパケットとRTCPパケットをそのピアメディアディストリビュータに送信するためのHBHキーを確立します。鍵販売代理店は、メディア配布者間で使用するためのHBHキーの設定を容易にしません。
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.
キーディストリビュータとの最初のキー情報交換に続いて、エンドポイントはE2Eキーでメディアエンドを暗号化することができ、そのE2EキーをKEKで暗号化された他のエンドポイントに送信し、HBHを使用してRTPパケットを暗号化および認証できます。キー。このフレームワークでは、メディアディストリビュータがKEK情報へのアクセスを取得し、それが任意のエンドポイントのE2Eキーへのアクセスを許可し、続いてメディアを復号化することを防ぎません。
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.
KEKは、新しい参加者が会議を結合または退会させるときなど、会議の存続期間中に時間から変更する必要があるかもしれません。この文書の範囲外の範囲外の場合、いつ、または頻度がかかりますが、このフレームワークは、会議の一生の間に回復に対応しています。
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.
鍵ディストリビュータが会議を再確認することを決定すると、新しいEKTキーを含む新しいEktkeyメッセージを各会議参加者に送信します。新しいEKTキーを受信すると、エンドポイントは新しいSRTPマスターキーを作成し、[RFC8870]のセクション4.5に従って新しいEKTキーを使用してFullektFieldの内部にそのキーを送信する準備をしてください。会議のすべてのエンドポイントが新しいキーを受信する時間を許可するために、送信者は[RFC8870]のセクション4.6の推奨事項に従うべきです。新しいEKTキーを受信すると、新しいキーを使用してEKTタグを復号化するようにエンドポイントを準備する必要があります。EKTセキュリティパラメータインデックス（SPI）フィールドは、古いキーと新しいキーで暗号化されたEKTタグを区別するために使用されます。
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.
再ローインした後、エンドポイントは、以前のキーを使用した他のエンドポイントによって送信された遅延パケットまたはパケットを復号することができるようにすることを目的として、以前のSRTPマスターキーとEKTキーを一定期間保持する必要があります。回った後の期間中に始まった。エンドポイントは、会議の終了まで古いキーを保持することがあります。
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.
エンドポイントは[RFC5764]のセクション5.2の手順に従って、必要に応じてHBHキーを再交渉することができます。新しいHBHキーが生成された場合、新しいキーは、1つの可能な方法として[PERC-DTLS]で定義されている手順に従ってメディアディストリビュータに配信されます。
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].
いつでも、エンドポイントが使用されているE2E暗号化キーを変更することがあります。エンドポイントは、新しいEKTキーを受信するたびに、新しいE2E暗号化キーを生成する必要があります。新しいキーに切り替えた後、新しいキーは[RFC8870]ごとのRTP / RTCPパケットの会議の他のエンドポイントに伝えます。
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.
エンティティは、他のエンティティの信頼性、特に鍵の販売店とエンドポイントを検証できることが重要です。このトピックの詳細はこの仕様の範囲外ですが、いくつかの可能性については次のセクションで説明します。重要な要件は、（1）エンドポイントが会議の正しいキーディストリビュータに接続されていることを確認でき、（2）キーディストリビュータがエンドポイントが会議の正しいエンドポイントであることを確認できます。
Two possible approaches to resolve this situation are identity assertions and certificate fingerprints.
この状況を解決するための2つの可能なアプローチは、IDアサーションと証明書の指紋です。
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.
WebRTC Identity Assertion [RFC8827]は、エンドポイントのユーザーのIDを呼び出しに使用されているDTLS-SRTP証明書の指紋にバインドするために使用されます。この証明書は、特定の通話と会議に固有のものです。この証明書は、特定の通話と会議に固有のもので、鍵ディストリビューターが認可されたユーザーだけが会議に参加できるようにします。同様に、キーディストリビュータはこの会議のキーディストリビュータによって使用される固有の証明書の指紋をこの会議でバインドするためのWEBRTC IDアサーションを作成することができ、エンドポイントが正しいキーディストリビュータと話していることを確認できるようにします。そのようなセットアップには、エンドポイントとキーディストリビュータによって信頼されたIDプロバイダ（IDP）が必要です。
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.
セッションシグナリングを管理するエンティティは、一般にPERCフレームワークでは信頼されていないと見なされます。ただし、認証されることができる方法で、セッションシグナリングの一部が信頼できると想定される展開シナリオがあります。
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.
具体例として、SIP [RFC3261]とセッション記述プロトコル（SDP）[RFC4566]を使用して、[RFC5763]ごとに指紋情報を伝達できます。エンドポイントのSIPユーザーエージェントは、メディアセッションのSDPを含むINVITEメッセージをエンドポイントの証明書フィンガープリントとともに送信します。]。他のエンティティは、指紋がDTLS-SRTP接続で見つかった証明書とDTLS-SRTP接続の遠端の識別情報を見つけ、それが許可されたエンティティであることを確認することを確認できます。
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.
最終的には、セッションシグナリングを使用すると、エンドポイントの証明書フィンガープリントをユーザーに安全にマッピングし、問題のユーザーが許可されていることを確認できるようにする必要があります。同様に、キーディストリビュータの証明書フィンガープリントは、この会議の認証鍵販売代理店であると認証できるようにエンドポイントに伝えられます。
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.
鍵配布業者は、特定の会議にどのエンドポイントが追加されているかを知る必要があります。したがって、鍵配布者とメディアディストリビュータは、[PERC-DTLS]で説明されているように会議固有の一意の識別子を交換することによって有効になっているエンドポイント間マッピングを知る必要があります。この一意の識別子がどのように割り当てられているかは、この文書の範囲外です。
This section describes the various keys employed by PERC.
このセクションでは、PERCによって採用されているさまざまなキーについて説明します。
This section summarizes the several different keys used in the PERC framework, how they are generated, and what purpose they serve.
このセクションでは、PERCフレームワークで使用されているいくつかの異なるキー、それらがどのように生成されているか、およびそれらがどのような目的を達成します。
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.
PERCで使用されているさまざまなキーを以下の表1に示します。
+===========+=============================================+
| 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
表1：キーインベントリ
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.
一例として、会議で1,000人の参加者がある場合、少なくとも1,000以上の異なるSRTPマスターキーがあり、そのすべては同じマスターソルトを共有します。これらの各キーは、[RFC3711]で定義されているキー派生機能（KDF）を通過して、実際の暗号化キーと認証キーを作成します。
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.
キー管理を複雑にすることは、KEKが変わる可能性があるという事実であり、それが実行されると、エンドポイントは新しいEKT SPIに関連付けられている新しいSRTPマスターキーを生成します。エンドポイントは、到着したまたは順序外のパケットを正しく復号化できるように、古いキーを一定期間保持することができ、それはその期間中に保持されているキーの数が実質的に高いかもしれないことを意味します。
A more detailed explanation of each of the keys follows.
各キーの詳細な説明は次のとおりです。
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.
取得された最初のキーセットは、HBH暗号化および復号化のためのものである。二重変換手順[RFC8723]ごとに、エンドポイントはキーディストリビュータとのDTLS-SRTP交換を実行し、実際には「double」のサイズを「Double」にするキーを受け取ります。E2E部分はキーの前半であるため、エンドポイントはそれ自身のキーを生成するときにその情報を廃棄します。キーイング材料の後半はHBH操作用であるため、キーの半分（最下位ビットに対応）がHBHキーとして内部的に割り当てられます。
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].
キーディストリビュータはHBHキーのメディアディストリビュータを知らせます。具体的には、キーディストリビュータは、DTLS - SRTPを介して決定されたキーイングマテリアルの半分に対応する最下位ビットをメディアディストリビュータに送信する。HBHキーと共に塩値が発生する。塩はHBH操作に必要以上に長い。したがって、必要な長さ（生成された塩材料の半分）の最下位ビットだけがメディアディストリビュータに送られる。このキーと塩の情報を送信する1つの方法は、[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.
2つのエンドポイントは同じHBHキーを持っていません。したがって、メディアディストリビュータは、それぞれの異なるHBHキー（および対応する塩）を追跡し、指定されたホップに対してのみ使用する必要があります。
The HBH key is also used for HBH encryption of RTCP. RTCP is not E2E-encrypted in PERC.
HBHキーはRTCPのHBH暗号化にも使用されます。RTCPはPERCでE2E暗号化されていません。
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.
キーディストリビュータは、前述のDTLS-SRTPアソシエーションを介して、KEK（RFC8870のEKTキー）をエンドポイントに送信します。このキーは、鍵の販売店とエンドポイントのみが知られています。このキーの知識を持たせることは、このキー（および同じメッセージの一部として送信されたSRTPマスターSALT）を保護するのが最も重要なエンティティです。エンティティは会議で任意のメディアパケットを復号化することができます。
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.
キーディストリビュータはエンドポイントに任意の数のEKTキーを送信できることに注意してください。この情報は、会議全体を再確認するために使用されます。各キーはSPI値によって識別されます。エンドポイントは、新しい参加者が会議に参加したとき、または参加者がそのようなイベントの前後の会話の機密性を保護するために、会議が再認証されることを期待しなければなりません。
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.
エンドポイントによって使用されるSRTPマスター塩は、EKTキーとともに送信されます。会議のすべてのエンドポイントは、特定のEKTキーに対応する同じSRTPマスターソルトを使用します。
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]).
メディアパケット内のフルEKTタグは、Ektkeyメッセージ（例えば、128ビットキー付きのAESキーラップ）を介して指定された暗号を使用して暗号化されています。この暗号は、メディアを保護するために使用される暗号とは異なり、エンドポイントのSRTPマスターキー（およびRFC8870のように他のEKTタグデータ）を暗号化するためにのみ使用されます。
The KEK is not given to the Media Distributor.
KEKはメディアディストリビュータには与えられていません。
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.
前述のように、DTLS-SRTPを介して決定されたE2Eキーは、局所的に生成されたE2E SRTPマスターキーを支持して破棄することができる。DTLS-SRTP派生SRTPマスターキーを最初に使用することができますが、エンドポイントはSRTPマスターキーを定期的に変更することを選択し、EKTキーの変更の結果としてSRTPマスターキーを変更する必要があります。
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.
ローカルに生成されたSRTPマスターキーは、EKTKEYメッセージを介してエンドポイントからエンドポイントに送信されたマスターソルトと共に、メディアエンドを暗号化します。
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.
メディアディストリビュータはE2E機能に関与していないため、このキーを作成しません。また、エンドポイントのE2Eキーにアクセスできません。キーディストリビュータでさえ、各エンドポイントで使用されているローカルに生成されたE2Eキーを認識していないことに注意してください。
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].
エンドポイントは、フルEKTタグ内のSRTPパケット内のそれを定期的に含めることによって、そのE2Eキーを会議の他のエンドポイントに送信します。フルEKTタグに配置されると、キーディストリビュータによって提供されたEKTキーを使用して暗号化されます。ただし、すべてのエンドポイントは鍵ディストリビュータからEKTKEYメッセージを介して同じマスターソルトを受信するため、マスターソルトは送信されません。[RFC8870]に、エンドポイントがSRTPマスターキーを送信する推奨頻度を指定します。
All endpoints have knowledge of the KEK.
すべてのエンドポイントは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.)
すべてのHBHキーは特定のエンドポイントには異なります。したがって、エンドポイントAとエンドポイントBは他方のHBHキーの知識を持っていません。HBHキーはDTLS-SRTPアソシエーションから派生しているため、エンドポイントごとに最大1つのHBHキーがあります。（唯一の例外は、DTLS-SRTPアソシエーションが[RFC5764]のセクション5.2ごとに再確認される可能性があり、元キーを置き換えるために新しいキーが作成されます。）
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.
各エンドポイントは独自のE2Eキー（SRTPマスターキー）を生成します。したがって、エンドポイントごとに異なるE2Eキーがあります。このキーは、フルEKTタグを介して他のエンドポイントに送信（暗号化）されます。特定の送信エンドポイントからメディアを受信するエンドポイントは、フルEKTタグを介して送信機のE2Eキーの知識を得る。
Table 2 summarizes the various keys and which entity is in possession of a given key.
表2は、さまざまなキーを要約し、どのエンティティが特定のキーを所有しています。
+=======================+============+======+======+============+
| 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
表2：キーの種類と実体の所有物
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.
図4は、このフレームワークごとに暗号化されたメディアパケットがどのように表示されているかの完全な画像をワイヤを介して送信したときのように見えます。図に示すパケットフォーマットは、EKTタグが最後に付加されているDouble Cryptographic変換を使用して暗号化されています。
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
図4：暗号化されたメディアパケットフォーマット
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.
オンパス攻撃は、HBHの整合性保護と暗号化によって軽減されます。完全性保護はパケットの修正を軽減します。暗号化はパケットの選択的ブロックを困難にしますが、不可能ではありません。
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.
オフパスの攻撃者は、レシーバを転送またはレンダリングするために受信側を強制することを目的として、さまざまなPERCエンティティに接続することを試みることができました。エンドポイントとメディアの配布者は、HBH認証を実行し、認証に失敗したパケットを破棄することで、そのような攻撃を軽減します。
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.
もう1つの攻撃ベクトルは、正しいものではなく、誤ったメディアディストリビュータにパケットを送信するためのエンドポイントを誇るメディアディストリビュータであることを主張する第三者です。廃棄された送信エンドポイントは、実際にはエンドポイントに配信されていると誤って想定されています。この攻撃が可能であるが、誤ったメディアディストリビュータはHBHまたはE2E暗号化キーにアクセスできないから、機密情報の漏れがない単純なサービス拒否である。
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.
相互DTLS認証の使用（DTLS-SRTPによって要求される）の使用は、誤ったエンドポイントまたは誤ったメディアディストリビュータが、そうでなければONを実行できる認識された有効なメディア送信者として正常に参加したことを妨げることによって、サービス拒否攻撃を防ぐのに役立ちます。-Path攻撃。相互認証が失敗すると、受信エンドポイントは、検査なしにエンドポイントから受信したメディアパケットを安全に破棄できることを知っています。
A malicious or compromised Media Distributor can attack the session in a number of possible ways, as discussed below.
悪意のあるまたは侵害されたメディアディストリビュータは、以下に説明するように、可能な方法でセッションを攻撃することができます。
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.
別の形態の攻撃は、転送前に受信パケットを変更しています。このソリューションフレームワークでは、E2E認証されたデータの変更は受信パケットで認証を実行するときに受信エンドポイントが整合性の障害を起こします。
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.
メディアディストリビュータは、受信エンドポイントに対するリソース消費攻撃を実行しようとすることができます。そのような攻撃の1つは、フルEKTタグと共に任意のRTPパケット内のランダムなSSRC / CSRC値を挿入することです。そのようなメッセージは、新しい暗号化コンテキストを形成するために受信機が受信機をトリガするので、メディアディストリビュータは受信側エンドポイントのリソースを消費することを試みることができる。E2E認証が失敗し、暗号化されたコンテキストが破壊されますが、それにもかかわらず、鍵導出操作はいくつかの計算資源を消費します。リソース消費攻撃を完全に軽減できないが、レート制限パケットはそのような攻撃の影響を減らすのに役立ちます。
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.
再生攻撃は、RTPストリーム内の前のポイントからのすでに受信したパケットが新しいパケットとして再生される攻撃です。これは、例えば、メディアディストリビュータが、ユーザが実際に言った「いいえ」の代わりにユーザとして識別された一連のパケットを送信することを可能にすることができる。
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.
[RFC3711]の3.3.2項で説明されているように、再生保護を実装するための要件によって再生攻撃が軽減されます。会議期間の間、E2E再生保護を提供する必要があります。
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.
E2Eの再生保護が整っていてもこの攻撃は可能です。メディアディストリビュータはストリームのサブセットを選択して、最もアクティブなスピーカーのみを転送するなどのレシーバに残りを転送できないため、受信機はE2Eパケットシーケンス内のギャップを受け入れる必要があります。ここでの問題は、メディアディストリビュータがしばらくの間特定のストリームを配信しないことを選択できることです。
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.
この攻撃を完全に排除することはできませんが、期限切れキーで暗号化された暗号化されたメディアはエンドポイントによって復号化されないので、その有効性を定期的に回復することによって低下させることができます。
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.
スプライシング攻撃は、複数のメディアソースを受信したメディアディストリビュータが1つのメディアストリームを他方にスプライスする攻撃です。メディアディストリビュータが元の送信元IDを検証するための任意の方法を有する受信機なしでSSRCを変更することができた場合、メディアディストリビュータは最初にストリームAを配信し、そのストリームAが以前に使用されていたのと同じSSRCの下でストリームAを転送することができる。各パケットの整合性チェックにSSRCを含めることで、HBHとE2E - PERCの両方がスプライシング攻撃を防ぎます。
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.
PERCはRTCPメッセージのE2E保護を提供しません。これにより、侵入されたメディアディストリビュータが、メディア統計、ピクチャリクエスト、または損失指示など、RTCPを介して送信される可能性があるメッセージに影響を与えることができます。新しい写真を送信するためのエンドポイントへの要求など、要求などの要求を偽造するための侵入されたメディアディストリビュータが妥協されたことも可能です。そのような要求はかなりの帯域幅を消費し、会議のパフォーマンスを損なうことができます。
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.
セクション3.2.2に記載されているように、キーサーバを利用することは、敵対者が1つまたは複数の会議のためのキーイング材料へのアクセスを得ることを可能にすることができるので、鍵販売代理店は確保される必要がある。そのキーイング資料にアクセスすることは、敵対者が会議の任意のエンドポイントから送信されたメディアを復号化することを可能にするであろう。
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.
会議の締結を超えてキーイング資料へのアクセスが必要かどうかを考慮する必要があります。必要ない場合、主なディストリビュータのポリシーは、会議が会議の過程で終了したとき、またはキーイングが変更されたときにキーイングの資料を破壊することであるべきです。会議の存続期間を超えてキーイング材料が必要な場合は、将来の露出からキーイング材料を保護することを検討する必要があります。それは明らかだと思われるかもしれませんが、敵対者が会議中に送信されたメディアパケットを記録し、その後、キー配布者に無承認のアクセスを取得することを疑いの余地は疑いません。敵対者は、会議中に送信されたすべてのパケットの内容を復号化することができます。
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.
さらに、敵がエンドポイントを首尾よく悪用すると、敵対者は会議にメディアを挿入することができます。例えば、敵対者は、敵対者が送信したいメディアを送信するためにRTPまたはSRTPソフトウェアを操作することができる。これにより、侵入先のエンドポイントのSSRCの再利用、またはすべての会議参加者が同じKEKを共有しているため、新しいSSRCの使用、または別のエンドポイントのSSRC値の使用が含まれます。単一のSRTP暗号スイートのみが定義されているソース認証プロパティは、エンドポイントが特定のE2E保護されたパケットを送信したことを暗号的にアサートすることを可能にするソース認証プロパティ（すなわち、タイミングの効率的なストリーム損失耐性認証（TESLA）[RFC4383]）、その使用が現在のところ現在PERCには定義されていません。PERCで定義されているスイートは、パケットが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.
ただし、エンドポイントへの攻撃は、エンドポイント内のPERC固有のソフトウェアに限定されません。攻撃者は、例えば、PERC対応アプリケーションとビデオカメラのハードウェアマイクロフォンとの間にあるソフトウェアを操作することによって、メディアまたは記録メディアを挿入することができる。同様に、エンドポイントが保護されていない場合、攻撃者はメモリ、キャッシュ、ディスクストレージなどにアクセスすることによって機密メディアにアクセスする可能性があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<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>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月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>.
[RFC6904] Lennox、J.、「セキュアリアルタイムトランスポートプロトコル（SRTP）」、RFC 6904、DOI 10.17487 / RFC6904、2013年4月、<https：//ww.rfc-editor.org/情報/ 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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8723]ジェニングニング、C、Jones、P.、Barnes、R.、およびA.B.ROACH、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 8723、DOI 10.17487 / RFC8723、<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>.
[RFC8870] Jennings、C、Mattsson、J.、McGrew、D.、Wing、D.、およびF. Andreasen、「DTLSおよびSecure RTPの暗号化キートランスポート」、RFC 8870、DOI 10.17487 / RFC8870、2021年1月、<https://www.rfc-editor.org/info/rfc8870>。
[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>.
[PERC-DTLS] Jones、PE、Ellenbogen、PM、およびNH OhlMeier、「キー交換を容易にするメディアディストリビュータとキーディストリビュータの間のDTLSトンネル」、進行中、インターネットドラフト、ドラフト-IETF-PERC-DTLSトンネル-06,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>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<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>.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）」、RFC 4353、DOI 10.17487 / RFC4353、<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>.
[RFC4383] Baugher、M.およびE. Carrara、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 4383、DOI 10.17487 / RFC4383、2006年2月、<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>.
[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ 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>.
[RFC5763] FISCHL、J.、TSCHOFENIG、H.、およびE.RESCORLA、「データグラムトランスポート層セキュリティ（DTLS）」、RFC 5763、DOI 10.17487 /を使用したセキュリティコンテキスト（SRTP）セキュリティコンテキストを確立するためのフレームワーク。2010年5月、<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>.
[RFC5764] MCGREW、D.およびE. RESCORLA、セキュアリアルタイムトランスポートプロトコル（SRTP） "、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<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>.
[RFC6464] Lennox、J.、Ed。、Ivov、E.、およびE.Marocco、「クライアントからミキサーのオーディオレベル表示のためのリアルタイムトランスポートプロトコル（RTP）ヘッダ拡張」、RFC 6464、DOI 10.17487 /RFC6464、2011年12月、<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>.
[RFC7667] Westerlund、M.およびS.Wenger、 "RTPトポロジ"、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<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>.
[RFC8224] Peterson、J.、Jennings、C、Rescorla、E.、およびC.Wendt、「セッション開始プロトコル（SIP）」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<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>.
[RFC8827] Rescorla、E.、「Webrtc Security Architecture」、RFC 8827、DOI 10.17487 / RFC8827、2021年1月、<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/>.
[W3C.CR - WEBRTC]ジェニング、C、Boström、H.、およびJ-I。Bruaroey、 "WebRTC 1.0：ブラウザ間のリアルタイム通信"、W3Cは推奨事項、<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).
著者らは、この文書の貴重な入力のためにMo Zanaty、Christian Oien、およびRichard Barnesに感謝します。また、この文書の初期ドラフトバージョンをCoauthorとして提供するためにNermeen Ismailを確認したいと思います。また、セキュリティ上の考慮事項セクションの元のテキストの多くを含む文書のいくつかのテキストを提供するために、John Mattsson、Mats Naslund、およびMagnus Westerlundをご了承ください。
Authors' Addresses
著者の住所
Paul E. Jones Cisco 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 United States of America
Paul E. Jones Cisco 7025キットクリークRD。Research Triangle Park、ノースカロライナ27709アメリカ合衆国
Phone: +1 919 476 2048
Email: paulej@packetizer.com
David Benham Independent California United States of America
David Benham Independent Californiaアメリカ合衆国
Email: dabenham@gmail.com
Christian Groves Independent Melbourne Australia
Christian Groves独立したメルボルンオーストラリア
Email: cngroves.std@gmail.com