[要約] RFC 9185は、メディアディストリビュータとキーディストリビュータ間のDTLSトンネルを通じてキー交換を容易にするための仕様です。このプロトコルは、安全な通信チャネルを確立し、メディアコンテンツの配信中に暗号キーを安全に交換することを目的としています。主に、エンドツーエンドのセキュリティを必要とするリアルタイムメディア配信システムで利用されます。
Internet Engineering Task Force (IETF) P. Jones
Request for Comments: 9185 Cisco Systems
Category: Informational P. Ellenbogen
ISSN: 2070-1721 Princeton University
N. Ohlmeier
8x8, Inc.
April 2022
DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange
メディアディストリビューターとキーディストリビューターの間のDTLSトンネルキー交換を促進する
Abstract
概要
This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the Media Distributor.
このドキュメントでは、メディアディストリビューターが会議のエンドポイントと主要なディストリビューターの間の主要な交換を促進できるようにするマルチメディア会議のトンネルDTLSトラフィックのプロトコルを定義しています。このプロトコルは、ホップバイホップの暗号化と認証に使用されるキーイング素材がメディアディストリビューターがアクセスできるように設計されており、エンドツーエンドの暗号化と認証に使用されるキーイング素材はメディアディストリビューターがアクセスできないことを保証するように設計されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9185.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9185で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. Tunneling Concept
4. Example Message Flows
5. Tunneling Procedures
5.1. Endpoint Procedures
5.2. Tunnel Establishment Procedures
5.3. Media Distributor Tunneling Procedures
5.4. Key Distributor Tunneling Procedures
5.5. Versioning Considerations
6. Tunneling Protocol
6.1. TunnelMessage Structure
6.2. SupportedProfiles Message
6.3. UnsupportedVersion Message
6.4. MediaKeys Message
6.5. TunneledDtls Message
6.6. EndpointDisconnect Message
7. Example Binary Encoding
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is to ensure that endpoints in a multimedia conference have access to the end-to-end (E2E) and hop-by-hop (HBH) keying material used to encrypt and authenticate Real-time Transport Protocol (RTP) packets [RFC3550], while the Media Distributor has access only to the HBH keying material for encryption and authentication.
プライバシー強化RTP会議（PERC）[RFC8871]の目的は、マルチメディア会議のエンドポイントがエンドツーエンド（E2E）とホップバイホップ（HBH）キーイングキーイングにアクセスできるようにすることです。リアルタイムトランスポートプロトコル（RTP）パケット[RFC3550]を認証しますが、メディアディストリビューターは暗号化と認証用のHBHキーイング材料にのみアクセスできます。
This specification defines a tunneling protocol that enables the Media Distributor to tunnel DTLS messages [RFC9147] between an endpoint and a Key Distributor, thus allowing an endpoint to use DTLS for the Secure Real-time Transport Protocol (DTLS-SRTP) [RFC5764] for establishing encryption and authentication keys with the Key Distributor.
この仕様は、メディアディストリビューターがエンドポイントとキーディストリビューターの間のトンネルDTLSメッセージ[RFC9147]にトンネルDTLSメッセージ[RFC9147]を可能にするトンネルプロトコルを定義し、したがって、エンドポイントが安全なリアルタイムトランスポートプロトコル（DTLS-SRTP）[RFC5764]にDTLSを使用できるようにします。キーディストリビューターとの暗号化と認証キーを確立します。
The tunnel established between the Media Distributor and Key Distributor is a TLS connection [RFC8446] that is established before any messages are forwarded by the Media Distributor on behalf of endpoints. DTLS packets received from an endpoint are encapsulated by the Media Distributor inside this tunnel as data to be sent to the Key Distributor. Likewise, when the Media Distributor receives data from the Key Distributor over the tunnel, it extracts the DTLS message inside and forwards the DTLS message to the endpoint. In this way, the DTLS association for the DTLS-SRTP procedures is established between an endpoint and the Key Distributor, with the Media Distributor forwarding DTLS messages between the two entities via the established tunnel to the Key Distributor and having no visibility into the confidential information exchanged.
メディアディストリビューターとキーディストリビューターの間に確立されたトンネルは、エンドポイントに代わってメディアディストリビューターによってメッセージが転送される前に確立されるTLS接続[RFC8446]です。エンドポイントから受信したDTLSパケットは、このトンネル内のメディアディストリビューターによって、キーディストリビューターに送信されるデータとしてカプセル化されています。同様に、メディアディストリビューターがトンネル上のキーディストリビューターからデータを受信すると、DTLSメッセージを内部に抽出し、DTLSメッセージをエンドポイントに転送します。このようにして、DTLS-SRTP手順のDTLS協会はエンドポイントと主要なディストリビューターの間に確立され、メディアディストリビューターは確立されたトンネルを介して主要なディストリビューターへの2つのエンティティ間でDTLSメッセージを転送し、機密情報への可視性を持たない交換。
Following the existing DTLS-SRTP procedures, the endpoint and Key Distributor will arrive at a selected cipher and keying material, which are used for HBH encryption and authentication by both the endpoint and the Media Distributor. However, since the Media Distributor would not have direct access to this information, the Key Distributor explicitly shares the HBH key information with the Media Distributor via the tunneling protocol defined in this document. Additionally, the endpoint and Key Distributor will agree on a cipher for E2E encryption and authentication. The Key Distributor will transmit keying material to the endpoint for E2E operations but will not share that information with the Media Distributor.
既存のDTLS-SRTP手順に従って、エンドポイントとキーディストリビューターは、エンドポイントとメディアディストリビューターの両方によるHBH暗号化と認証に使用される選択された暗号およびキーイング材料に到着します。ただし、メディアディストリビューターはこの情報に直接アクセスできないため、主要なディストリビューターは、このドキュメントで定義されているトンネリングプロトコルを介して、HBHキー情報をメディアディストリビューターと明示的に共有しています。さらに、エンドポイントとキーディストリビューターは、E2E暗号化と認証の暗号に同意します。キーディストリビューターは、キーイングマテリアルをE2Eオペレーションのエンドポイントに送信しますが、その情報をメディアディストリビューターと共有しません。
By establishing this TLS tunnel between the Media Distributor and Key Distributor and implementing the protocol defined in this document, it is possible for the Media Distributor to facilitate the establishment of a secure DTLS association between an endpoint and the Key Distributor in order for the endpoint to generate E2E and HBH keying material. At the same time, the Key Distributor can securely provide the HBH keying material to the Media Distributor.
メディアディストリビューターと主要なディストリビューターの間にこのTLSトンネルを確立し、このドキュメントで定義されたプロトコルを実装することにより、メディアディストリビューターがエンドポイントと主要なディストリビューターとの間の安全なDTLS関連の確立を促進することができます。E2EおよびHBHキーイング材料を生成します。同時に、主要なディストリビューターは、HBHキーイング資料をメディアディストリビューターに安全に提供できます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the terms "endpoint", "Media Distributor", and "Key Distributor" defined in [RFC8871].
このドキュメントでは、[RFC8871]で定義された「エンドポイント」、「メディアディストリビューター」、および「キーディストリビューター」という用語を使用します。
A TLS connection (tunnel) is established between the Media Distributor and the Key Distributor. This tunnel is used to relay DTLS messages between the endpoint and Key Distributor, as depicted in Figure 1:
TLS接続（トンネル）は、メディアディストリビューターとキーディストリビューターとの間に確立されます。このトンネルは、図1に示すように、エンドポイントとキーディストリビューターの間でDTLSメッセージを中継するために使用されます。
+-------------+
| Key |
| Distributor |
+-------------+
# ^ ^ #
# | | # <-- TLS Tunnel
# | | #
+----------+ +-------------+ +----------+
| | DTLS | | DTLS | |
| Endpoint |<------------| Media |------------>| Endpoint |
| | to Key | Distributor | to Key | |
| | Distributor | | Distributor | |
+----------+ +-------------+ +----------+
Figure 1: TLS Tunnel to Key Distributor
図1：KeyディストリビューターへのTLSトンネル
The three entities involved in this communication flow are the endpoint, the Media Distributor, and the Key Distributor. The behavior of each entity is described in Section 5.
この通信フローに関与する3つのエンティティは、エンドポイント、メディアディストリビューター、および主要なディストリビューターです。各エンティティの動作については、セクション5で説明します。
The Key Distributor is a logical function that might be co-resident with a key management server operated by an enterprise, might reside in one of the endpoints participating in the conference, or might reside at some other location that is trusted with E2E keying material.
主要なディストリビューターは、エンタープライズが運営する主要な管理サーバーと共同住宅である可能性がある論理機能であり、会議に参加しているエンドポイントの1つに居住するか、E2Eキーイング資料を信頼している他の場所に存在する可能性があります。
This section provides an example message flow to help clarify the procedures described later in this document. It is necessary that the Key Distributor and Media Distributor establish a mutually authenticated TLS connection for the purpose of sending tunneled messages, though the complete TLS handshake for the tunnel is not shown in Figure 2 because there is nothing new this document introduces with regard to those procedures.
このセクションでは、このドキュメントで後で説明した手順を明確にするのに役立つメッセージフローの例を示します。主要なディストリビューターとメディアディストリビューターは、トンネル化されたメッセージを送信する目的で相互に認証されたTLS接続を確立する必要がありますが、トンネルの完全なTLSハンドシェイクは図2には示されていません。手順。
Once the tunnel is established, it is possible for the Media Distributor to relay the DTLS messages between the endpoint and the Key Distributor. Figure 2 shows a message flow wherein the endpoint uses DTLS-SRTP to establish an association with the Key Distributor. In the process, the Media Distributor shares its supported SRTP protection profile information (see [RFC5764]), and the Key Distributor shares the HBH keying material and selected cipher with the Media Distributor.
トンネルが確立されると、メディアディストリビューターがエンドポイントとキーディストリビューターの間でDTLSメッセージを中継することができます。図2は、エンドポイントがDTLS-SRTPを使用してキーディストリビューターとの関連を確立するメッセージフローを示しています。その過程で、メディアディストリビューターはサポートされているSRTP保護プロファイル情報を共有し（[RFC5764]を参照）、主要なディストリビューターはHBHキーイングマテリアルを共有し、選択した暗号をメディアディストリビューターと共有します。
Endpoint Media Distributor Key Distributor
| | |
| |<=======================>|
| | TLS Connection Made |
| | |
| |========================>|
| | SupportedProfiles |
| | |
|------------------------>|========================>|
| DTLS handshake message | TunneledDtls |
| | |
.... may be multiple handshake messages ...
| | |
|<------------------------|<========================|
| DTLS handshake message | TunneledDtls |
| | |
| | |
| |<========================|
| | MediaKeys |
Figure 2: Sample DTLS-SRTP Exchange via the Tunnel
図2：トンネルを介したDTLS-SRTP交換のサンプル
After the initial TLS connection has been established, each of the messages on the right-hand side of Figure 2 is a tunneling protocol message, as defined in Section 6.
最初のTLS接続が確立された後、図2の右側の各メッセージは、セクション6で定義されているように、トンネリングプロトコルメッセージです。
SRTP protection profiles supported by the Media Distributor will be sent in a SupportedProfiles message when the TLS tunnel is initially established. The Key Distributor will use that information to select a common profile supported by both the endpoint and the Media Distributor to ensure that HBH operations can be successfully performed.
メディアディストリビューターがサポートするSRTP保護プロファイルは、TLSトンネルが最初に確立されたときにサポートされたプロファイルメッセージで送信されます。主要なディストリビューターは、その情報を使用して、エンドポイントとメディアディストリビューターの両方でサポートされている共通のプロファイルを選択して、HBH操作を正常に実行できるようにします。
As DTLS messages are received from the endpoint by the Media Distributor, they are forwarded to the Key Distributor encapsulated inside a TunneledDtls message. Likewise, as TunneledDtls messages are received by the Media Distributor from the Key Distributor, the encapsulated DTLS packet is forwarded to the endpoint.
DTLSメッセージはメディアディストリビューターによってエンドポイントから受信されるため、TunnELEDDTLSメッセージ内にカプセル化された主要なディストリビューターに転送されます。同様に、TunneLedDTLSメッセージはメディアディストリビューターから主要なディストリビューターから受信されるため、カプセル化されたDTLSパケットはエンドポイントに転送されます。
The Key Distributor will provide the SRTP keying material [RFC3711] to the Media Distributor for HBH operations via the MediaKeys message. The Media Distributor will extract this keying material from the MediaKeys message when received and use it for HBH encryption and authentication.
キーディストリビューターは、Mediakeysメッセージを介してHBHオペレーションのメディアディストリビューターにSRTPキーイング材料[RFC3711]を提供します。メディアディストリビューターは、受信時にMediakeysメッセージからこのキーイング資料を抽出し、HBH暗号化と認証に使用します。
The following subsections explain in detail the expected behavior of the endpoint, the Media Distributor, and the Key Distributor.
次のサブセクションでは、エンドポイント、メディアディストリビューター、および主要なディストリビューターの予想される動作を詳細に説明しています。
It is important to note that the tunneling protocol described in this document is not an extension to TLS or DTLS. Rather, it is a protocol that transports DTLS messages generated by an endpoint or Key Distributor as data inside of the TLS connection established between the Media Distributor and Key Distributor.
このドキュメントで説明されているトンネルプロトコルは、TLSまたはDTLSの拡張ではないことに注意することが重要です。むしろ、エンドポイントまたはキーディストリビューターによって生成されたDTLSメッセージを、メディアディストリビューターとキーディストリビューターの間に確立されたTLS接続内のデータとして輸送するプロトコルです。
The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] in order to establish the cipher and keys used for encryption and authentication, with the endpoint acting as the client and the Key Distributor acting as the server. The endpoint does not need to be aware of the fact that DTLS messages it transmits toward the Media Distributor are being tunneled to the Key Distributor.
エンドポイントは、暗号化と認証に使用される暗号とキーを確立するために、DTLS-SRTP [RFC5764]の概説された手順に従います。エンドポイントは、メディアディストリビューターに送信するDTLSメッセージが主要なディストリビューターにトンネルされているという事実を認識する必要はありません。
The endpoint MUST include a unique identifier in the tls-id Session Description Protocol (SDP) attribute [RFC8866] in all offer and answer messages [RFC3264] that it generates, as per [RFC8842]. Further, the endpoint MUST include this same unique identifier in the external_session_id extension [RFC8844] in the ClientHello message when establishing a DTLS association.
エンドポイントには、[RFC8842]に従って生成するすべてのオファーおよび回答メッセージ[RFC3264]に、TLS-IDセッション説明プロトコル（SDP）属性[RFC8866]に一意の識別子を含める必要があります。さらに、エンドポイントには、DTLSアソシエーションを確立する際に、clienthelloメッセージにexternal_session_id拡張子[RFC8844]にこの同じ一意の識別子を含める必要があります。
When receiving an external_session_id value from the Key Distributor, the client MUST check to ensure that value matches the tls-id value received in SDP. If the values do not match, the endpoint MUST consider any received keying material to be invalid and terminate the DTLS association.
キーディストリビューターからexternal_session_id値を受信する場合、クライアントは、値がSDPで受信したTLS-ID値と一致することを確認する必要があります。値が一致しない場合、エンドポイントは、受信したキーイング資料が無効であることを考慮し、DTLS協会を終了する必要があります。
Either the Media Distributor or Key Distributor initiates the establishment of a TLS tunnel. Which entity acts as the TLS client when establishing the tunnel and what event triggers the establishment of the tunnel are outside the scope of this document. Further, how the trust relationships are established between the Key Distributor and Media Distributor are also outside the scope of this document.
メディアディストリビューターまたはキーディストリビューターがTLSトンネルの設立を開始します。トンネルを確立する際にTLSクライアントとして機能するエンティティは、トンネルの確立をトリガーするイベントがこのドキュメントの範囲外であります。さらに、主要なディストリビューターとメディアディストリビューターとの間に信頼関係がどのように確立されるかも、このドキュメントの範囲外です。
A tunnel MUST be a mutually authenticated TLS connection.
トンネルは、相互に認証されたTLS接続でなければなりません。
The Media Distributor or Key Distributor MUST establish a tunnel prior to forwarding tunneled DTLS messages. Given the time-sensitive nature of DTLS-SRTP procedures, a tunnel SHOULD be established prior to the Media Distributor receiving a DTLS message from an endpoint.
メディアディストリビューターまたは主要なディストリビューターは、トンネルDTLSメッセージを転送する前にトンネルを確立する必要があります。DTLS-SRTP手順の時間に敏感な性質を考えると、メディアディストリビューターがエンドポイントからDTLSメッセージを受信する前にトンネルを確立する必要があります。
A single tunnel MAY be used to relay DTLS messages between any number of endpoints and the Key Distributor.
単一のトンネルを使用して、任意の数のエンドポイントとキーディストリビューター間のDTLSメッセージを中継することができます。
A Media Distributor MAY have more than one tunnel established between itself and one or more Key Distributors. When multiple tunnels are established, which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document.
メディアディストリビューターは、それ自体と1つ以上の主要なディストリビューターとの間に複数のトンネルを確立することができます。複数のトンネルが確立されると、特定の会議のメッセージを送信するために使用するトンネルまたはトンネルは、このドキュメントの範囲外です。
The first message transmitted over the tunnel is the SupportedProfiles message (see Section 6). This message informs the Key Distributor about which DTLS-SRTP profiles the Media Distributor supports. This message MUST be sent each time a new tunnel connection is established or, in the case of connection loss, when a connection is re-established. The Media Distributor MUST support the same list of protection profiles for the duration of any endpoint-initiated DTLS association and tunnel connection.
トンネル上に送信された最初のメッセージは、サポートされているプロファイルメッセージです（セクション6を参照）。このメッセージは、メディアディストリビューターがサポートするDTLS-SRTPプロファイルを主要なディストリビューターに通知します。このメッセージは、新しいトンネル接続が確立されるたびに、または接続損失の場合、接続が再確立されたときに送信する必要があります。メディアディストリビューターは、エンドポイント開始DTLSアソシエーションとトンネル接続の期間中、同じ保護プロファイルのリストをサポートする必要があります。
The Media Distributor MUST assign a unique association identifier for each endpoint-initiated DTLS association and include it in all messages forwarded to the Key Distributor. The Key Distributor will subsequently include this identifier in all messages it sends so that the Media Distributor can map messages received via a tunnel and forward those messages to the correct endpoint. The association identifier MUST be a version 4 Universally Unique Identifier (UUID), as described in Section 4.4 of [RFC4122].
メディアディストリビューターは、各エンドポイント開始DTLS協会に一意のアソシエーション識別子を割り当て、主要なディストリビューターに転送されたすべてのメッセージにそれを含める必要があります。その後、主要なディストリビューターは、メディアディストリビューターがトンネルを介してメッセージをマッピングし、それらのメッセージを正しいエンドポイントに転送できるように、送信するすべてのメッセージにこの識別子を含めます。関連付け識別子は、[RFC4122]のセクション4.4で説明されているように、バージョン4普遍的に一意の識別子（UUID）でなければなりません。
When a DTLS message is received by the Media Distributor from an endpoint, it forwards the UDP payload portion of that message to the Key Distributor encapsulated in a TunneledDtls message. The Media Distributor is not required to forward all messages received from an endpoint for a given DTLS association through the same tunnel if more than one tunnel has been established between it and a Key Distributor.
DTLSメッセージがエンドポイントからメディアディストリビューターによって受信されると、そのメッセージのUDPペイロード部分をTunnELEDDTLSメッセージにカプセル化された主要なディストリビューターに転送します。メディアディストリビューターは、特定のDTLSアソシエーションのエンドポイントから受信したすべてのメッセージを、ITと主要なディストリビューターの間に複数のトンネルが確立されている場合、同じトンネルを介して転送する必要はありません。
When a MediaKeys message is received, the Media Distributor MUST extract the cipher and keying material conveyed in order to subsequently perform HBH encryption and authentication operations for RTP and RTP Control Protocol (RTCP) packets sent between it and an endpoint. Since the HBH keying material will be different for each endpoint, the Media Distributor uses the association identifier included by the Key Distributor to ensure that the HBH keying material is used with the correct endpoint.
Mediakeysメッセージが受信されると、メディアディストリビューターは、その後、RTPおよびRTP制御プロトコル（RTCP）パケットとエンドポイントの間に送信されるHBH暗号化と認証操作を実行するために、暗号とキーイング資料を抽出する必要があります。HBHキーイング材料は各エンドポイントで異なるため、メディアディストリビューターは主要なディストリビューターが含めて関連する識別子を使用して、HBHキーイング材料が正しいエンドポイントで使用されるようにします。
The Media Distributor MUST forward all DTLS messages received from either the endpoint or the Key Distributor (via the TunneledDtls message) to ensure proper communication between those two entities.
メディアディストリビューターは、これら2つのエンティティ間の適切な通信を確保するために、エンドポイントまたはキーディストリビューター（TunnELEDDTLSメッセージを介して）から受信したすべてのDTLSメッセージを転送する必要があります。
When the Media Distributor detects an endpoint has disconnected or when it receives conference control messages indicating the endpoint is to be disconnected, the Media Distributor MUST send an EndpointDisconnect message with the association identifier assigned to the endpoint to the Key Distributor. The Media Distributor SHOULD take a loss of all RTP and RTCP packets as an indicator that the endpoint has disconnected. The particulars of how RTP and RTCP are to be used to detect an endpoint disconnect, such as timeout period, are not specified. The Media Distributor MAY use additional indicators to determine when an endpoint has disconnected.
メディアディストリビューターがエンドポイントが切断された場合、またはエンドポイントを切断することを示す会議制御メッセージを受信した場合、メディアディストリビューターはエンドポイント識別子にエンドポイントに割り当てられたエンドポイントディスコネクトメッセージをキーディストリビューターに割り当てなければなりません。メディアディストリビューターは、エンドポイントが切断されていることを示す指標として、すべてのRTPおよびRTCPパケットを損失する必要があります。タイムアウト期間などのエンドポイントの切断を検出するためにRTPとRTCPを使用する方法の詳細は指定されていません。メディアディストリビューターは、追加のインジケーターを使用して、エンドポイントがいつ切断されたかを判断することができます。
Each TLS tunnel established between the Media Distributor and the Key Distributor MUST be mutually authenticated.
メディアディストリビューターと主要なディストリビューターの間に確立された各TLSトンネルは、相互に認証される必要があります。
When the Media Distributor relays a DTLS message from an endpoint, the Media Distributor will include an association identifier that is unique per endpoint-originated DTLS association. The association identifier remains constant for the life of the DTLS association. The Key Distributor identifies each distinct endpoint-originated DTLS association by the association identifier.
メディアディストリビューターがエンドポイントからDTLSメッセージをリレーすると、メディアディストリビューターには、エンドポイントオリジネートされたDTLSアソシエーションごとに一意のアソシエーション識別子が含まれます。協会識別子は、DTLS協会の存続期間中で一定のままです。キーディストリビューターは、協会識別子によって、それぞれの異なるエンドポイントオリジネートDTLS協会を識別します。
When processing an incoming endpoint association, the Key Distributor MUST extract the external_session_id value transmitted in the ClientHello message and match that against the tls-id value the endpoint transmitted via SDP. If the values in SDP and the ClientHello message do not match, the DTLS association MUST be rejected.
着信エンドポイントアソシエーションを処理する場合、主要なディストリビューターは、clienthelloメッセージに送信されたexternal_session_id値を抽出し、TLS-id値に対してSDPを介して送信されるエンドポイントを抽出する必要があります。SDPおよびClientHelloメッセージの値が一致しない場合、DTLS協会は拒否する必要があります。
The process through which the tls-id value in SDP is conveyed to the Key Distributor is outside the scope of this document.
SDPのTLS-ID値が主要なディストリビューターに伝えられるプロセスは、このドキュメントの範囲外です。
The Key Distributor MUST match the fingerprint of the certificate and external_session_id [RFC8844] received from the endpoint via DTLS with the expected fingerprint [RFC8122] and tls-id [RFC8842] values received via SDP. It is through this process that the Key Distributor can be sure to deliver the correct conference key to the endpoint.
主要なディストリビューターは、証明書の指紋と、DTLSを介して受け取った外部_Session_ID [RFC8844]をDTLSを介して、予想フィンガープリント[RFC8122]およびTLS-ID [RFC8842]をSDP経由で受け取った値と一致させる必要があります。主要なディストリビューターがエンドポイントに正しい会議キーを確実に配信できるのは、このプロセスを通じてです。
The Key Distributor MUST report its own unique identifier in the external_session_id extension. This extension is sent in the EncryptedExtensions message in DTLS 1.3 and the ServerHello message in previous DTLS versions. This value MUST also be conveyed back to the client via SDP as a tls-id attribute.
キーディストリビューターは、外部_Session_ID拡張機能に独自の識別子を報告する必要があります。この拡張子は、DTLS 1.3の暗号化されたEdextensionsメッセージと以前のDTLSバージョンのServerHelloメッセージで送信されます。また、この値は、TLS-ID属性としてSDPを介してクライアントに戻す必要があります。
The Key Distributor MUST encapsulate any DTLS message it sends to an endpoint inside a TunneledDtls message (see Section 6). The Key Distributor is not required to transmit all messages for a given DTLS association through the same tunnel if more than one tunnel has been established between it and the Media Distributor.
キーディストリビューターは、TunnELEDDTLSメッセージ内のエンドポイントに送信するDTLSメッセージをカプセル化する必要があります（セクション6を参照）。主要なディストリビューターは、ITとメディアディストリビューターの間に複数のトンネルが確立されている場合、同じトンネルを介して特定のDTLS関連のすべてのメッセージを送信する必要はありません。
The Key Distributor MUST use the same association identifier in messages sent to an endpoint as was received in messages from that endpoint. This ensures the Media Distributor can forward the messages to the correct endpoint.
主要なディストリビューターは、そのエンドポイントからのメッセージで受信されたエンドポイントに送信されたメッセージで、同じアソシエーション識別子を使用する必要があります。これにより、メディアディストリビューターがメッセージを正しいエンドポイントに転送できるようになります。
The Key Distributor extracts tunneled DTLS messages from an endpoint and acts on those messages as if that endpoint had established the DTLS association directly with the Key Distributor. The Key Distributor is acting as the DTLS server, and the endpoint is acting as the DTLS client. The handling of the messages and certificates is exactly the same as normal DTLS-SRTP procedures between endpoints.
キーディストリビューターは、エンドポイントからDTLSメッセージをトンネリングし、そのエンドポイントがキーディストリビューターと直接DTLSアソシエーションを確立したかのようにそれらのメッセージに動作します。キーディストリビューターはDTLSサーバーとして機能しており、エンドポイントはDTLSクライアントとして機能しています。メッセージと証明書の処理は、エンドポイント間の通常のDTLS-SRTP手順とまったく同じです。
The Key Distributor MUST send a MediaKeys message to the Media Distributor immediately after the DTLS handshake completes. The MediaKeys message includes the selected cipher (i.e., protection profile), Master Key Identifier (MKI) value [RFC3711] (if any), HBH SRTP master keys, and SRTP master salt values. The Key Distributor MUST use the same association identifier in the MediaKeys message as is used in the TunneledDtls messages for the given endpoint.
主要なディストリビューターは、DTLSハンドシェイクが完了した直後にMediakeysメッセージをメディアディストリビューターに送信する必要があります。Mediakeysメッセージには、選択した暗号（すなわち、保護プロファイル）、マスターキー識別子（MKI）値[RFC3711]（もしあれば）、HBH SRTPマスターキー、およびSRTPマスターソルト値が含まれます。キーディストリビューターは、指定されたエンドポイントのTunnELEDDTLSメッセージで使用されているMediakeysメッセージで同じ関連付け識別子を使用する必要があります。
There are presently two SRTP protection profiles defined for PERC, namely DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723]. As explained in Section 5.2 of [RFC8723], the Media Distributor is only given the SRTP master key for HBH operations. As such, the SRTP master key length advertised in the MediaKeys message is half the length of the key normally associated with the selected "double" protection profile.
現在、PERC用に定義されている2つのSRTP保護プロファイル、すなわちDouble_Aead_aes_128_GCM_AEAD_AES_128_GCMとDouble_Aead_aes_256_gcm_aead_aes_256_gcm [rfc8723]。[RFC8723]のセクション5.2で説明したように、メディアディストリビューターにはHBH操作のSRTPマスターキーのみが与えられます。そのため、Mediakeysメッセージに宣伝されているSRTPマスターキーの長さは、選択した「二重」保護プロファイルに通常関連付けられているキーの長さの半分です。
The Key Distributor uses the certificate fingerprint of the endpoint along with the unique identifier received in the external_session_id extension to determine with which conference a given DTLS association is associated.
キーディストリビューターは、Endpointの証明書指紋を使用して、外部_Session_ID拡張機能で受信した一意の識別子を使用して、特定のDTLSアソシエーションが関連付けられている会議を決定します。
The Key Distributor MUST select a cipher that is supported by itself, the endpoint, and the Media Distributor to ensure proper HBH operations.
主要なディストリビューターは、適切なHBH運用を確保するために、それ自体によってサポートされている暗号、エンドポイント、メディアディストリビューターを選択する必要があります。
When the DTLS association between the endpoint and the Key Distributor is terminated, regardless of which entity initiated the termination, the Key Distributor MUST send an EndpointDisconnect message with the association identifier assigned to the endpoint to the Media Distributor.
エンドポイントとキーディストリビューターとの間のDTLSアソシエーションが終了する場合、どのエンティティが終了したかに関係なく、主要なディストリビューターは、エンドポイントにメディアディストリビューターに割り当てられた協会識別子とエンドポイントディスコネクトメッセージを送信する必要があります。
Since the Media Distributor sends the first message over the tunnel, it effectively establishes the version of the protocol to be used. If that version is not supported by the Key Distributor, the Key Distributor MUST transmit an UnsupportedVersion message containing the highest version number supported and close the TLS connection.
メディアディストリビューターはトンネルを介して最初のメッセージを送信するため、使用するプロトコルのバージョンを効果的に確立します。そのバージョンが主要なディストリビューターによってサポートされていない場合、主要なディストリビューターは、サポートされている最高のバージョン番号を含むサポートされていないバージョンメッセージを送信し、TLS接続を閉じる必要があります。
The Media Distributor MUST take note of the version received in an UnsupportedVersion message and use that version when attempting to re-establish a failed tunnel connection. Note that it is not necessary for the Media Distributor to understand the newer version of the protocol to understand that the first message received is an UnsupportedVersion message. The Media Distributor can determine from the first four octets received what the version number is and that the message is an UnsupportedVersion message. The rest of the data received, if any, would be discarded and the connection closed (if not already closed).
メディアディストリビューターは、サポートされていないバージョンメッセージで受信したバージョンに注意し、失敗したトンネル接続を再確立しようとするときにそのバージョンを使用する必要があります。メディアディストリビューターがプロトコルの新しいバージョンを理解して、最初のメッセージがサポートされていないメッセージであることを理解する必要はないことに注意してください。メディアディストリビューターは、最初の4オクテットからバージョン番号が何であるか、メッセージがサポートされていないメッセージであると判断できます。受信した残りのデータは、ある場合は廃棄され、接続が閉じられます（まだ閉じていない場合）。
Tunneled messages are transported via the TLS tunnel as application data between the Media Distributor and the Key Distributor. Tunnel messages are specified using the format described in [RFC8446], Section 3. As in [RFC8446], all values are stored in network byte (big endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060.
トンネル化されたメッセージは、TLSトンネルを介してメディアディストリビューターとキーディストリビューター間のアプリケーションデータとして輸送されます。トンネルメッセージは、[RFC8446]、セクション3で説明されている形式を使用して指定されます。HEXバイト01 02 03 04で表されるUINT32は、小数値16909060に相当します。
This protocol defines several different messages, each of which contains the following information:
このプロトコルはいくつかの異なるメッセージを定義します。それぞれに次の情報が含まれています。
* message type identifier
* メッセージタイプ識別子
* message body length
* メッセージボディの長さ
* the message body
* メッセージ本文
Each of the tunnel messages is a TunnelMessage structure with the message type indicating the actual content of the message body.
各トンネルメッセージは、メッセージボディの実際のコンテンツを示すメッセージタイプを持つトンネルメッサージ構造です。
TunnelMessage defines the structure of all messages sent via the tunnel protocol. That structure includes a field called msg_type that identifies the specific type of message contained within TunnelMessage.
TunnelMessageは、トンネルプロトコルを介して送信されるすべてのメッセージの構造を定義します。その構造には、TunnelMessageに含まれる特定のタイプのメッセージを識別するMSG_Typeというフィールドが含まれます。
enum {
supported_profiles(1),
unsupported_version(2),
media_keys(3),
tunneled_dtls(4),
endpoint_disconnect(5),
(255)
} MsgType;
opaque uuid[16];
不透明uuid [16];
struct {
MsgType msg_type;
uint16 length;
select (MsgType) {
case supported_profiles: SupportedProfiles;
case unsupported_version: UnsupportedVersion;
case media_keys: MediaKeys;
case tunneled_dtls: TunneledDtls;
case endpoint_disconnect: EndpointDisconnect;
} body;
} TunnelMessage;
The elements of TunnelMessage include:
TunnelMessageの要素は次のとおりです。
msg_type: the type of message contained within the structure body.
MSG_TYPE：構造本体内に含まれるメッセージのタイプ。
length: the length in octets of the following body of the message.
長さ：メッセージの次の本文のオクテットの長さ。
body: the actual message being conveyed within this TunnelMessage structure.
ボディ：このトンネルメッジ構造内で伝えられる実際のメッセージ。
The SupportedProfiles message is defined as:
supportedprofilesメッセージは次のように定義されます。
uint8 SRTPProtectionProfile[2]; /* from RFC 5764 */
struct {
uint8 version;
SRTPProtectionProfile protection_profiles<2..2^16-1>;
} SupportedProfiles;
The elements of SupportedProfiles include:
supportedprofilesの要素には次のものがあります。
version: this document specifies version 0x00.
バージョン：このドキュメントは、バージョン0x00を指定します。
protection_profiles: the list of two-octet SRTP protection profile values, as per [RFC5764], supported by the Media Distributor.
Protection_Profiles：メディアディストリビューターによってサポートされている[RFC5764]によると、2オクタートSRTP保護プロファイル値のリスト。
The UnsupportedVersion message is defined as:
サポートされていないバージョンメッセージは、次のように定義されます。
struct {
uint8 highest_version;
} UnsupportedVersion;
UnsupportedVersion contains this single element:
unsupportedversionには、この単一の要素が含まれています。
highest_version: indicates the highest version of the protocol supported by the Key Distributor.
hist_version：キーディストリビューターがサポートするプロトコルの最高バージョンを示します。
The MediaKeys message is defined as:
Mediakeysメッセージは次のように定義されています。
struct {
uuid association_id;
SRTPProtectionProfile protection_profile;
opaque mki<0..255>;
opaque client_write_SRTP_master_key<1..255>;
opaque server_write_SRTP_master_key<1..255>;
opaque client_write_SRTP_master_salt<1..255>;
opaque server_write_SRTP_master_salt<1..255>;
} MediaKeys;
The fields are described as follows:
フィールドは次のように説明されています。
association_id: a value that identifies a distinct DTLS association between an endpoint and the Key Distributor.
Association_id：エンドポイントと主要なディストリビューターとの間の明確なDTLS関連を識別する値。
protection_profiles: the value of the two-octet SRTP protection profile value, as per [RFC5764], used for this DTLS association.
Protection_Profiles：このDTLSアソシエーションに使用される[RFC5764]によると、2オクテットのSRTP保護プロファイル値の値。
mki: master key identifier [RFC3711]; a zero-length field indicates that no MKI value is present.
MKI：マスターキー識別子[RFC3711];ゼロの長さのフィールドは、MKI値が存在しないことを示します。
client_write_SRTP_master_key: the value of the SRTP master key used by the client (endpoint).
client_write_srtp_master_key：クライアントが使用するSRTPマスターキーの値（エンドポイント）。
server_write_SRTP_master_key: the value of the SRTP master key used by the server (Media Distributor).
server_write_srtp_master_key：サーバーが使用するSRTPマスターキー（Media Distributor）の値。
client_write_SRTP_master_salt: the value of the SRTP master salt used by the client (endpoint).
client_write_srtp_master_salt：クライアントが使用するSRTPマスターソルトの値（エンドポイント）。
server_write_SRTP_master_salt: the value of the SRTP master salt used by the server (Media Distributor).
server_write_srtp_master_salt：サーバー（Media Distributor）が使用するSRTPマスターソルトの値。
The TunneledDtls message is defined as:
TunnELEDDTLSメッセージは次のように定義されます。
struct {
uuid association_id;
opaque dtls_message<1..2^16-1>;
} TunneledDtls;
The fields are described as follows:
フィールドは次のように説明されています。
association_id: a value that identifies a distinct DTLS association between an endpoint and the Key Distributor.
Association_id：エンドポイントと主要なディストリビューターとの間の明確なDTLS関連を識別する値。
dtls_message: the content of the DTLS message received by the endpoint or to be sent to the endpoint, including one or more complete DTLS records.
DTLS_MESSAGE：エンドポイントで受信したDTLSメッセージのコンテンツまたは1つ以上の完全なDTLSレコードを含むエンドポイントに送信される。
The EndpointDisconnect message is defined as:
endpointDisconnectメッセージは、次のように定義されています。
struct {
uuid association_id;
} EndpointDisconnect;
The field is described as follows:
フィールドは次のように説明されています。
association_id: a value that identifies a distinct DTLS association between an endpoint and the Key Distributor.
Association_id：エンドポイントと主要なディストリビューターとの間の明確なDTLS関連を識別する値。
The TunnelMessage is encoded in binary, following the procedures specified in [RFC8446]. This section provides an example of what the bits on the wire would look like for the SupportedProfiles message that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723].
[RFC8446]で指定された手順に従って、TunnelMessageはバイナリでエンコードされています。このセクションでは、double_aead_aes_128_gcm_aead_aes_128_gcmとdouble_aead_aes_256_gcm [rfc8723]の両方のサポートを宣伝するサポートプロファイルのメッセージに対して、ワイヤー上のビットがどのように見えるかの例を示します。
TunnelMessage: message_type: 0x01 length: 0x0007 SupportedProfiles: version: 0x00 protection_profiles: 0x0004 (length) 0x0009000A (value)
TunnelMessage：message_type：0x01長さ：0x0007サポートプロファイル：バージョン：0x00 Protection_Profiles：0x0004（length）0x0009000a（value）
Thus, the encoding on the wire, presented here in network byte order, would be this stream of octets:
したがって、ここでネットワークバイトの順序で提示されているワイヤー上のエンコーディングは、このオクテットの流れになります。
0x0100070000040009000A
0x0100070000040009000A
This document establishes the "Datagram Transport Layer Security (DTLS) Tunnel Protocol Message Types for Privacy Enhanced Conferencing" registry to contain message type values used in the DTLS tunnel protocol. These message type values are a single octet in length. This document defines the values shown in Table 1 below, leaving the balance of possible values reserved for future specifications:
このドキュメントでは、「データグラムトランスポートレイヤーセキュリティ（DTLS）トンネルプロトコルメッセージタイプのプライバシー強化された会議」を確立します。これらのメッセージタイプの値は、長さが単一のオクテットです。このドキュメントは、以下の表1に示す値を定義し、将来の仕様のために予約されている可能性のある値のバランスを残します。
+=========+====================================+
| MsgType | Description |
+=========+====================================+
| 0x01 | Supported SRTP Protection Profiles |
+---------+------------------------------------+
| 0x02 | Unsupported Version |
+---------+------------------------------------+
| 0x03 | Media Keys |
+---------+------------------------------------+
| 0x04 | Tunneled DTLS |
+---------+------------------------------------+
| 0x05 | Endpoint Disconnect |
+---------+------------------------------------+
Table 1: Message Type Values for the DTLS Tunnel Protocol
表1：DTLSトンネルプロトコルのメッセージタイプ値
The value 0x00 is reserved, and all values in the range 0x06 to 0xFF are available for allocation. The procedures for updating this table are those defined as "IETF Review" in Section 4.8 of [RFC8126].
値0x00は予約されており、0x06〜0xffの範囲のすべての値が割り当てに使用できます。この表を更新する手順は、[RFC8126]のセクション4.8で「IETFレビュー」として定義されている手順です。
Since the procedures in this document rely on TLS [RFC8446] for transport security, the security considerations for TLS should be reviewed when implementing the protocol defined in this document.
このドキュメントの手順は、輸送セキュリティのためにTLS [RFC8446]に依存しているため、このドキュメントで定義されているプロトコルを実装する際にTLSのセキュリティに関する考慮事項をレビューする必要があります。
While the tunneling protocol defined in this document does not use DTLS-SRTP [RFC5764] directly, it does convey and negotiate some of the same information (e.g., protection profile data). As such, a review of the security considerations found in that document may be useful.
このドキュメントで定義されているトンネルプロトコルは、DTLS-SRTP [RFC5764]を直接使用していませんが、同じ情報の一部を伝えて交渉します（たとえば、保護プロファイルデータ）。そのため、そのドキュメントで見つかったセキュリティ上の考慮事項のレビューは有用かもしれません。
This document describes a means of securely exchanging keying material and cryptographic transforms for both E2E and HBH encryption and authentication of media between an endpoint and a Key Distributor via a Media Distributor. Additionally, the procedures result in delivering HBH information to the intermediary Media Distributor. The Key Distributor and endpoint are the only two entities with access to both the E2E and HBH keys, while the Media Distributor has access to only HBH information. Section 8.2 of [RFC8871] enumerates various attacks against which one must guard when implementing a Media Distributor; these scenarios are important to note.
このドキュメントでは、エンドポイントとメディアディストリビューターを介した主要なディストリビューター間のメディアのE2EとHBHの両方の暗号化と認証のために、キーイング素材と暗号化変換を安全に交換する手段について説明します。さらに、この手順により、HBH情報が仲介メディアディストリビューターに配信されます。キーディストリビューターとエンドポイントは、E2EとHBHキーの両方にアクセスできる2つのエンティティのみですが、メディアディストリビューターはHBH情報のみにアクセスできます。[RFC8871]のセクション8.2は、メディアディストリビューターを実装するときに警備しなければならないさまざまな攻撃を列挙しています。これらのシナリオは注意することが重要です。
A requirement in this document is that a TLS connection between the Media Distributor and the Key Distributor be mutually authenticated. The reason for this requirement is to ensure that only an authorized Media Distributor receives the HBH keying material. If an unauthorized Media Distributor gains access to the HBH keying material, it can easily cause service degradation or denial by transmitting HBH-valid packets that ultimately fail E2E authentication or replay protection checks (see Section 3.3.2 of [RFC3711]). Even if service does not appear degraded in any way, transmitting and processing bogus packets are a waste of both computational and network resources.
このドキュメントの要件は、メディアディストリビューターと主要なディストリビューターとの間のTLS接続が相互に認証されることです。この要件の理由は、認定されたメディアディストリビューターのみがHBHキーイング資料を受け取ることを保証するためです。無許可のメディアディストリビューターがHBHキーイング材料へのアクセスを獲得した場合、最終的にE2E認証を失敗させるHBHバリッドパケットまたはリプレイ保護チェックを送信することにより、サービスの劣化または拒否を簡単に引き起こす可能性があります（[RFC3711]のセクション3.3.2を参照）。サービスがいかなる方法でも劣化していない場合でも、偽のパケットの送信と処理は、計算リソースとネットワークリソースの両方の無駄です。
The procedures defined in this document assume that the Media Distributor will properly convey DTLS messages between the endpoint and Key Distributor. Should it fail in that responsibility by forwarding DTLS messages from endpoint A advertised as being from endpoint B, this will result in a failure at the DTLS layer of those DTLS sessions. This could be an additional attack vector that Key Distributor implementations should consider.
このドキュメントで定義されている手順では、メディアディストリビューターがエンドポイントとキーディストリビューター間でDTLSメッセージを適切に伝えると想定しています。EndPoint AからのDTLSメッセージをEndpoint Bから宣伝されていると宣伝することでその責任が失敗した場合、これにより、これらのDTLSセッションのDTLSレイヤーで障害が発生します。これは、主要なディストリビューターの実装を考慮すべき追加の攻撃ベクトルである可能性があります。
While E2E keying material passes through the Media Distributor via the protocol defined in this document, the Media Distributor has no means of gaining access to that information and therefore cannot affect the E2E media processing function in the endpoint except to present it with invalid or replayed data. That said, any entity along the path that interferes with the DTLS exchange between the endpoint and the Key Distributor, including a malicious Media Distributor that is not properly authorized, could prevent an endpoint from properly communicating with the Key Distributor and therefore prevent successful conference participation.
E2Eキーイングマテリアルは、このドキュメントで定義されているプロトコルを介してメディアディストリビューターを通過しますが、メディアディストリビューターはその情報にアクセスする手段を持たないため、無効なデータまたは再生データを提示することを除いて、エンドポイントのE2Eメディア処理機能に影響を与えることはできません。。とはいえ、適切に許可されていない悪意のあるメディアディストリビューターを含むエンドポイントと主要なディストリビューターとの間のDTLS交換を妨げるパスに沿ったエンティティは、エンドポイントが主要なディストリビューターと適切に通信するのを防ぐことができ、したがって、会議参加の成功を妨げる可能性があります。。
It is worth noting that a compromised Media Distributor can convey information to an adversary, such as participant IP addresses, negotiated protection profiles, or other metadata. While [RFC8871] explains that a malicious or compromised Media Distributor can disrupt communications, an additional attack vector introduced by this protocol is the potential disruption of DTLS negotiation or premature removal of a participant from a conference by sending an EndpointDisconnect message to the Key Distributor.
侵害されたメディアディストリビューターは、参加者のIPアドレス、交渉された保護プロファイル、またはその他のメタデータなど、情報を敵に伝えることができることは注目に値します。[RFC8871]は、悪意のあるメディアディストリビューターがコミュニケーションを破壊できると説明していますが、このプロトコルによって導入された追加の攻撃ベクトルは、DTLの交渉または主要なディストリビューターにEndPointDisconnectメッセージを送信することにより、会議から参加者の早期除去の潜在的な混乱です。
The Key Distributor should be aware of the possibility that a malicious Media Distributor might transmit an EndpointDisconnect message to the Key Distributor when the endpoint is in fact still connected.
主要なディストリビューターは、悪意のあるメディアディストリビューターが、エンドポイントが実際に接続されている場合、EndPointDisconnectメッセージをキーディストリビューターに送信できる可能性を認識する必要があります。
While the Security Considerations section of [RFC8871] describes various attacks one needs to consider with respect to the Key Distributor and denial of service, use of this protocol introduces another possible attack vector. Consider the case where a malicious endpoint sends unsolicited DTLS-SRTP messages to a Media Distributor. The Media Distributor will normally forward those messages to the Key Distributor and, if found invalid, such messages only serve to consume resources on both the Media Distributor and Key Distributor.
[RFC8871]のセキュリティ上の考慮事項セクションでは、主要なディストリビューターとサービス拒否に関して考慮する必要があるさまざまな攻撃について説明していますが、このプロトコルの使用は別の可能な攻撃ベクトルを導入します。悪意のあるエンドポイントが未承諾のDTLS-SRTPメッセージをメディアディストリビューターに送信する場合を考えてください。メディアディストリビューターは通常、これらのメッセージをキーディストリビューターに転送し、無効であると判断された場合、そのようなメッセージはメディアディストリビューターとキーディストリビューターの両方でリソースを消費するのに役立ちます。
[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。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M.、およびR. Salz、「普遍的にユニークな識別子（UUID）URNネームスペース」、RFC 4122、DOI 10.17487/RFC4122、2005年7月、<https：//www.rfc-editor.org/info/rfc4122>。
[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、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのDatagram Transport Layer Security（DTLS）拡張安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、RFC 5764、DOI 10.17487/RFC5764、2010年5月、<：//www.rfc-editor.org/info/rfc5764>。
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, <https://www.rfc-editor.org/info/rfc8122>.
[RFC8122] Lennox、J。およびC. Holmberg、「セッション説明プロトコル（SDP）の輸送層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 8122、DOI 10.17487/RFC8122、2017年3月、<HTTPSPSP：//www.rfc-editor.org/info/rfc8122>。
[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>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[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.、ジョーンズ、P。、バーンズ、R。、およびA.B.Roach、「安全なリアルタイム輸送プロトコル（SRTP）の二重暗号化手順」、RFC 8723、DOI 10.17487/RFC8723、2020年4月、<https://www.rfc-editor.org/info/rfc8723>。
[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021, <https://www.rfc-editor.org/info/rfc8842>.
[RFC8842] Holmberg、C。およびR. Shpount、「セッション説明プロトコル（SDP）データグラム輸送層のセキュリティ（DTLS）および輸送層セキュリティ（TLS）の提供/回答の考慮事項」、RFC 8842、DOI 10.17487/RFC8842、2021年1月、<https://www.rfc-editor.org/info/rfc8842>。
[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)", RFC 8844, DOI 10.17487/RFC8844, January 2021, <https://www.rfc-editor.org/info/rfc8844>.
[RFC8844] Thomson、M。およびE. Rescorla、「セッション説明プロトコル（SDP）を使用したTLSの使用に対する未知のキーシェア攻撃」、RFC 8844、DOI 10.17487/RFC8844、2021年1月、<https：// www。rfc-editor.org/info/rfc8844>。
[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, January 2021, <https://www.rfc-editor.org/info/rfc8871>.
[RFC8871] Jones、P.、Benham、D。、およびC. Groves、「プライバシー強化RTP会議（PERC）におけるプライベートメディアのソリューションフレームワーク」、RFC 8871、DOI 10.17487/RFC8871、2021年1月、<HTTPS：//www.rfc-editor.org/info/rfc8871>。
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、DOI 10.17487/RFC3264、2002年6月、<https：//www.rfc-editor.org/info/rfc3264>。
[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>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.
[RFC8866] Begen、A.、Kyzivat、P.、Perkins、C.、およびM. Handley、「SDP：SESSION説明プロトコル」、RFC 8866、DOI 10.17487/RFC866、2021年1月、<https：//www.rfc8866-editor.org/info/rfc8866>。
Acknowledgements
謝辞
The authors would like to thank David Benham and Cullen Jennings for reviewing this document and providing constructive comments.
著者は、この文書をレビューし、建設的なコメントを提供してくれたDavid BenhamとCullen Jenningsに感謝します。
Authors' Addresses
著者のアドレス
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 United States of America Phone: +1 919 476 2048 Email: paulej@packetizer.com
Paul E. Jones Cisco Systems、Inc。7025 Kit Creek Rd。ノースカロライナ州リサーチトライアングルパーク27709アメリカ合衆国電話：1 919 476 2048メール：paulej@packetizer.com
Paul M. Ellenbogen Princeton University Phone: +1 206 851 2069 Email: pe5@cs.princeton.edu
Paul M. Ellenbogen Princeton University電話：1 206 851 2069メール：pe5@cs.princeton.edu
Nils H. Ohlmeier 8x8, Inc. Phone: +1 408 659 6457 Email: nils@ohlmeier.org
Nils H. Ohlmeier 8x8、Inc。電話：1 408 659 6457メール：nils@ohlmeier.org