[要約] RFC 7201は、RTPセッションを保護するためのオプションについて説明しています。その目的は、セキュリティ要件に応じて適切なセキュリティメカニズムを選択するためのガイダンスを提供することです。
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 7201 Ericsson
Category: Informational C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
Options for Securing RTP Sessions
RTPセッションを保護するためのオプション
Abstract
概要
The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.
Real-time Transport Protocol（RTP）は、多数の異なるアプリケーションドメインおよび環境で使用されます。この異種性は、さまざまな環境に適したRTPおよびRTP制御プロトコル（RTCP）パケットの機密性、整合性、ソース認証などのサービスを提供するために、さまざまなセキュリティメカニズムが必要であることを意味します。ソリューションの範囲が広いため、RTPベースのアプリケーション開発者が最適なメカニズムを選択するのは困難です。このドキュメントでは、RTPのさまざまなセキュリティソリューションの概要を示し、適切なセキュリティメカニズムの選択方法に関する開発者向けのガイダンスを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7201.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7201で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 5
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 5
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 6
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 6
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 8
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 8
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 12
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 14
3.1.3. Key Management for SRTP: Security Descriptions . . . 15
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 16
3.1.5. Key Management for SRTP: ZRTP and Other Solutions . . 17
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 17
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 18
3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 18
3.6. Media Content Security/Digital Rights Management . . . . 19
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 19
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 20
4.1. Application Requirements . . . . . . . . . . . . . . . . 20
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 20
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 22
4.1.4. Identifiers and Identity . . . . . . . . . . . . . . 23
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Application Structure . . . . . . . . . . . . . . . . . . 25
4.3. Automatic Key Management . . . . . . . . . . . . . . . . 25
4.4. End-to-End Security vs. Tunnels . . . . . . . . . . . . . 25
4.5. Plaintext Keys . . . . . . . . . . . . . . . . . . . . . 26
4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 26
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Media Security for SIP-Established Sessions Using
DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 27
5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 28
5.4. 3GPP Packet-Switched Streaming Service (PSS) . . . . . . 29
5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8. Informative References . . . . . . . . . . . . . . . . . . . 31
The Real-time Transport Protocol (RTP) [RFC3550] is widely used in a large variety of multimedia applications, including Voice over IP (VoIP), centralized multimedia conferencing, sensor data transport, and Internet television (IPTV) services. These applications can range from point-to-point phone calls, through centralized group teleconferences, to large-scale television distribution services. The types of media can vary significantly, as can the signaling methods used to establish the RTP sessions.
リアルタイム転送プロトコル（RTP）[RFC3550]は、Voice over IP（VoIP）、集中型マルチメディア会議、センサーデータ転送、インターネットテレビ（IPTV）サービスなど、さまざまなマルチメディアアプリケーションで広く使用されています。これらのアプリケーションは、ポイントツーポイントの電話から、集中型のグループ電話会議を介して、大規模なテレビ配信サービスまでさまざまです。メディアのタイプは、RTPセッションを確立するために使用されるシグナリング方式と同様に、大幅に異なります。
So far, this multidimensional heterogeneity has prevented development of a single security solution that meets the needs of the different applications. Instead, a significant number of different solutions have been developed to meet different sets of security goals. This makes it difficult for application developers to know what solutions exist and whether their properties are appropriate. This memo gives an overview of the available RTP solutions and provides guidance on their applicability for different application domains. It also attempts to provide an indication of actual and intended usage at the time of writing as additional input to help with considerations such as interoperability, availability of implementations, etc. The guidance provided is not exhaustive, and this memo does not provide normative recommendations.
これまでのところ、この多次元の異質性は、さまざまなアプリケーションのニーズを満たす単一のセキュリティソリューションの開発を妨げてきました。その代わり、さまざまなセキュリティ目標のセットを満たすために、多数のさまざまなソリューションが開発されています。これにより、アプリケーション開発者は、どのようなソリューションが存在し、それらのプロパティが適切であるかどうかを知ることが難しくなります。このメモは、利用可能なRTPソリューションの概要を示し、さまざまなアプリケーションドメインへのそれらの適用性に関するガイダンスを提供します。また、相互運用性、実装の可用性などの考慮事項に役立つ追加の入力として、執筆時点での実際の使用目的の表示を提供しようとします。提供されるガイダンスは網羅的ではなく、このメモは規範的な推奨事項を提供しません。
It is important that application developers consider the security goals and requirements for their application. The IETF considers it important that protocols implement secure modes of operation and makes them available to users [RFC3365]. Because of the heterogeneity of RTP applications and use cases, however, a single security solution cannot be mandated [RFC7202]. Instead, application developers need to select mechanisms that provide appropriate security for their environment. It is strongly encouraged that common mechanisms be used by related applications in common environments. The IETF publishes guidelines for specific classes of applications, so it is worth searching for such guidelines.
アプリケーション開発者は、アプリケーションのセキュリティの目標と要件を考慮することが重要です。 IETFは、プロトコルが安全な動作モードを実装し、ユーザーが利用できるようにすることが重要であると考えています[RFC3365]。ただし、RTPアプリケーションとユースケースの多様性のため、単一のセキュリティソリューションを義務付けることはできません[RFC7202]。代わりに、アプリケーション開発者は、環境に適切なセキュリティを提供するメカニズムを選択する必要があります。一般的なメカニズムは、一般的な環境で関連するアプリケーションによって使用されることを強くお勧めします。 IETFは特定のクラスのアプリケーションのガイドラインを公開しているので、そのようなガイドラインを探す価値はあります。
The remainder of this document is structured as follows. Section 2 provides additional background. Section 3 outlines the available security mechanisms at the time of this writing and lists their key security properties and constraints. Section 4 provides guidelines and important aspects to consider when securing an RTP application. Finally, in Section 5, we give some examples of application domains where guidelines for security exist.
このドキュメントの残りの部分は、次のように構成されています。セクション2では、追加の背景情報を提供します。セクション3では、この記事の執筆時点で利用可能なセキュリティメカニズムの概要を説明し、それらの主要なセキュリティプロパティと制約を示します。セクション4は、RTPアプリケーションを保護する際に考慮すべきガイドラインと重要な側面を提供します。最後に、セクション5では、セキュリティのガイドラインが存在するアプリケーションドメインの例をいくつか示します。
RTP can be used in a wide variety of topologies due to its support for point-to-point sessions, multicast groups, and other topologies built around different types of RTP middleboxes. In the following, we review the different topologies supported by RTP to understand their implications for the security properties and trust relations that can exist in RTP sessions.
RTPは、ポイントツーポイントセッション、マルチキャストグループ、およびさまざまなタイプのRTPミドルボックスを中心に構築されたその他のトポロジをサポートしているため、さまざまなトポロジで使用できます。以下では、RTPがサポートするさまざまなトポロジを確認して、RTPセッションに存在する可能性のあるセキュリティプロパティと信頼関係への影響を理解します。
The most basic use case is two directly connected endpoints, shown in Figure 1, where A has established an RTP session with B. In this case, the RTP security is primarily about ensuring that any third party be unable to compromise the confidentiality and integrity of the media communication. This requires confidentiality protection of the RTP session, integrity protection of the RTP/RTCP packets, and source authentication of all the packets to ensure no man-in-the-middle (MITM) attack is taking place.
最も基本的な使用例は、図1に示すように、2つの直接接続されたエンドポイントです。ここで、AはBとのRTPセッションを確立します。この場合、RTPセキュリティは主に、第三者が機密性と整合性を侵害できないようにすることです。メディア通信。これには、RTPセッションの機密保護、RTP / RTCPパケットの整合性保護、および中間者（MITM）攻撃が行われないようにするためのすべてのパケットのソース認証が必要です。
The source authentication can also be tied to a user or an endpoint's verifiable identity to ensure that the peer knows with whom they are communicating. Here, the combination of the security protocol protecting the RTP session (and, hence, the RTP and RTCP traffic) and the key management protocol becomes important to determine what security claims can be made.
ソース認証をユーザーまたはエンドポイントの検証可能なIDに関連付けて、ピアが通信相手を確実に認識できるようにすることもできます。ここでは、RTPセッションを保護するセキュリティプロトコル（つまり、RTPおよびRTCPトラフィック）とキー管理プロトコルの組み合わせが、どのセキュリティクレームを作成できるかを決定するために重要になります。
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1: Point-to-Point Topology
図1：ポイントツーポイントトポロジ
An RTP mixer is an RTP session-level middlebox around which one can build a multiparty RTP-based conference. The RTP mixer might actually perform media mixing, like mixing audio or compositing video images into a new media stream being sent from the mixer to a given participant, or it might provide a conceptual stream; for example, the video of the current active speaker. From a security point of view, the important features of an RTP mixer are that it generates a new media stream, has its own source identifier, and does not simply forward the original media.
RTPミキサーは、マルチパーティRTPベースの会議を構築できるRTPセッションレベルのミドルボックスです。 RTPミキサーは、ミキサーから特定の参加者に送信される新しいメディアストリームにオーディオを混合したり、ビデオ画像を合成したりするなど、実際にメディアミキシングを実行したり、概念的なストリームを提供したりします。たとえば、現在アクティブな発言者のビデオ。セキュリティの観点から見ると、RTPミキサーの重要な機能は、新しいメディアストリームを生成し、独自のソース識別子を持ち、単純に元のメディアを転送しないことです。
An RTP session using a mixer might have a topology like that in Figure 2. In this example, participants A through D each send unicast RTP traffic to the RTP mixer, and receive an RTP stream from the mixer, comprising a mixture of the streams from the other participants.
ミキサーを使用するRTPセッションは、図2のようなトポロジを持つ場合があります。この例では、参加者AからDはそれぞれ、ユニキャストRTPトラフィックをRTPミキサーに送信し、ミキサーからのRTPストリームを受信します。他の参加者。
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 2: Example RTP Mixer Topology
図2：RTPミキサートポロジの例
A consequence of an RTP mixer having its own source identifier and acting as an active participant towards the other endpoints is that the RTP mixer needs to be a trusted device that has access to the security context(s) established. The RTP mixer can also become a security-enforcing entity. For example, a common approach to secure the topology in Figure 2 is to establish a security context between the mixer and each participant independently and have the mixer source authenticate each peer. The mixer then ensures that one participant cannot impersonate another.
独自のソース識別子を持ち、他のエンドポイントに対してアクティブな参加者として機能するRTPミキサーの結果として、RTPミキサーは、セキュリティコンテキストへのアクセスが確立された信頼できるデバイスである必要があります。 RTPミキサーは、セキュリティを強化するエンティティにもなります。たとえば、図2のトポロジを保護する一般的なアプローチは、ミキサーと各参加者の間に独立してセキュリティコンテキストを確立し、ミキサーのソースに各ピアを認証させることです。次に、ミキサーは、ある参加者が別の参加者になりすますことができないようにします。
RTP translators are middleboxes that provide various levels of in-network media translation and transcoding. Their security properties vary widely, depending on which type of operations they attempt to perform. We identify and discuss three different categories of RTP translators: transport translators, gateways, and media transcoders.
RTPトランスレータは、さまざまなレベルのネットワーク内メディア変換およびトランスコーディングを提供するミドルボックスです。それらのセキュリティプロパティは、実行しようとする操作の種類に応じて大きく異なります。 RTPトランスレータには、トランスポートトランスレータ、ゲートウェイ、およびメディアトランスコーダという3つのカテゴリがあります。
A transport translator [RFC5117] operates on a level below RTP and RTCP. It relays the RTP/RTCP traffic from one endpoint to one or more other addresses. This can be done based only on IP addresses and transport protocol ports, and each receive port on the translator can have a very basic list of where to forward traffic. Transport translators also need to implement ingress filtering to prevent random traffic from being forwarded that isn't coming from a participant in the conference.
トランスポートトランスレータ[RFC5117]は、RTPおよびRTCPの下のレベルで動作します。 1つのエンドポイントから1つ以上の他のアドレスにRTP / RTCPトラフィックを中継します。これは、IPアドレスとトランスポートプロトコルポートのみに基づいて行うことができ、トランスレータの各受信ポートは、トラフィックの転送先の非常に基本的なリストを持つことができます。トランスポートトランスレータは、会議の参加者からのものではないランダムなトラフィックが転送されないように、入力フィルタリングを実装する必要もあります。
Figure 3 shows an example transport translator, where traffic from any one of the four participants will be forwarded to the other three participants unchanged. The resulting topology is very similar to an Any Source Multicast (ASM) session (as discussed in Section 2.4) but is implemented at the application layer.
図3は、トランスポートトランスレータの例を示しています。4人の参加者のいずれか1人からのトラフィックは、他の3人の参加者にそのまま転送されます。結果のトポロジは、Any Source Multicast（ASM）セッション（セクション2.4で説明）とよく似ていますが、アプリケーション層で実装されます。
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | Relay | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 3: RTP Relay Translator Topology
図3：RTPリレートランスレータトポロジ
A transport translator can often operate without needing access to the security context, as long as the security mechanism does not provide protection over the transport-layer information. A transport translator does, however, make the group communication visible and, thus, can complicate keying and source authentication mechanisms. This is further discussed in Section 2.4.
多くの場合、トランスポートトランスレータは、セキュリティメカニズムがトランスポート層情報を保護しない限り、セキュリティコンテキストにアクセスすることなく動作できます。ただし、トランスポートトランスレータはグループ通信を表示するため、キーイングとソース認証メカニズムが複雑になる可能性があります。これについては、セクション2.4で詳しく説明します。
Gateways are deployed when the endpoints are not fully compatible. Figure 4 shows an example topology. The functions a gateway provides can be diverse and range from transport-layer relaying between two domains not allowing direct communication, via transport or media protocol function initiation or termination, to protocol- or media-encoding translation. The supported security protocol might even be one of the reasons a gateway is needed.
ゲートウェイは、エンドポイントに完全な互換性がない場合に展開されます。図4にトポロジーの例を示します。ゲートウェイが提供する機能は多岐にわたる可能性があり、トランスポートまたはメディアプロトコル機能の開始または終了を介した直接通信を許可しない2つのドメイン間のトランスポート層中継から、プロトコルまたはメディアエンコーディング変換までさまざまです。サポートされているセキュリティプロトコルは、ゲートウェイが必要な理由の1つである場合もあります。
+---+ +-----------+ +---+
| A |<---->| Gateway |<---->| B |
+---+ +-----------+ +---+
Figure 4: RTP Gateway Topology
図4：RTPゲートウェイトポロジ
The choice of security protocol, and the details of the gateway function, will determine if the gateway needs to be trusted with access to the application security context. Many gateways need to be trusted by all peers to perform the translation; in other cases, some or all peers might not be aware of the presence of the gateway. The security protocols have different properties depending on the degree of trust and visibility needed. Ensuring communication is possible without trusting the gateway can be a strong incentive for accepting different security properties. Some security solutions will be able to detect the gateways as manipulating the media stream, unless the gateway is a trusted device.
セキュリティプロトコルの選択とゲートウェイ機能の詳細によって、ゲートウェイがアプリケーションのセキュリティコンテキストへのアクセスで信頼される必要があるかどうかが決まります。多くのゲートウェイは、変換を実行するためにすべてのピアから信頼される必要があります。他の場合では、一部またはすべてのピアがゲートウェイの存在を認識していない場合があります。セキュリティプロトコルには、必要な信頼度と可視性の程度に応じて異なるプロパティがあります。ゲートウェイを信頼せずに通信が可能であることを保証することは、さまざまなセキュリティプロパティを受け入れるための強力なインセンティブになります。一部のセキュリティソリューションは、ゲートウェイが信頼できるデバイスでない限り、メディアストリームを操作しているゲートウェイを検出できます。
A media transcoder is a special type of gateway device that changes the encoding of the media being transported by RTP. The discussion in Section 2.3.2 applies. A media transcoder alters the media data and, thus, needs to be trusted with access to the security context.
メディアトランスコーダは、RTPによって転送されるメディアのエンコーディングを変更する特別なタイプのゲートウェイデバイスです。セクション2.3.2の説明が適用されます。メディアトランスコーダーはメディアデータを変更するため、セキュリティコンテキストへのアクセスで信頼される必要があります。
Any Source Multicast [RFC1112] is the original multicast model where any multicast group participant can send to the multicast group and get their packets delivered to all group members (see Figure 5). This form of communication has interesting security properties due to the many-to-many nature of the group. Source authentication is important, but all participants with access to the group security context will have the necessary secrets to decrypt and verify the integrity of the traffic. Thus, use of any group security context fails if the goal is to separate individual sources; alternate solutions are needed.
Any Source Multicast [RFC1112]は、すべてのマルチキャストグループ参加者がマルチキャストグループに送信し、パケットをすべてのグループメンバーに配信できる元のマルチキャストモデルです（図5を参照）。グループの多対多の性質により、この形式の通信には興味深いセキュリティプロパティがあります。ソース認証は重要ですが、グループのセキュリティコンテキストにアクセスできるすべての参加者は、トラフィックの完全性を復号化して検証するために必要な秘密を持っています。したがって、個々のソースを分離することが目的である場合、グループセキュリティコンテキストの使用は失敗します。別のソリューションが必要です。
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / \ +---+
+ Multicast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
Figure 5: Any Source Multicast (ASM) Group
図5：Any Source Multicast（ASM）グループ
In addition, the potential large size of multicast groups creates some considerations for the scalability of the solution and how the key management is handled.
さらに、マルチキャストグループのサイズが大きくなる可能性があるため、ソリューションのスケーラビリティと、キー管理の処理方法に関する考慮事項がいくつかあります。
Source-Specific Multicast (SSM) [RFC4607] allows only a specific endpoint to send traffic to the multicast group, irrespective of the number of RTP media sources. The endpoint is known as the media distribution source. For the RTP session to function correctly with RTCP over an SSM session, extensions have been defined in [RFC5760]. Figure 6 shows a sample SSM-based RTP session where several media sources, MS1...MSm, all send media to a distribution source, which then forwards the media data to the SSM group for delivery to the receivers, R1...Rn, and the feedback targets, FT1...FTn. RTCP reception quality feedback is sent unicast from each receiver to one of the feedback targets. The feedback targets aggregate reception quality feedback and forward it upstream towards the distribution source. The distribution source forwards (possibly aggregated and summarized) reception feedback to the SSM group and back to the original media sources. The feedback targets are also members of the SSM group and receive the media data, so they can send unicast repair data to the receivers in response to feedback if appropriate.
Source-Specific Multicast（SSM）[RFC4607]では、RTPメディアソースの数に関係なく、特定のエンドポイントのみがマルチキャストグループにトラフィックを送信できます。エンドポイントはメディア配布ソースと呼ばれます。 RTPセッションがSSMセッション上のRTCPで正しく機能するために、[RFC5760]で拡張機能が定義されています。図6は、複数のメディアソースMS1 ... MSmがすべてメディアを配布ソースに送信し、次にメディアデータをSSMグループに転送して受信者R1 ... Rnに配信する、サンプルのSSMベースのRTPセッションを示しています。 、およびフィードバックターゲット、FT1 ... FTn。 RTCP受信品質フィードバックは、各レシーバーからフィードバックターゲットの1つにユニキャストで送信されます。フィードバックターゲットは、受信品質フィードバックを集約し、それを上流の配布ソースに転送します。配布ソースは、受信フィードバックをSSMグループに転送（集約および要約される可能性があります）して、元のメディアソースに戻します。フィードバックターゲットはSSMグループのメンバーでもあり、メディアデータを受信するため、適切な場合はフィードバックに応じてユニキャスト修復データを受信者に送信できます。
+-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+
^ ^ ^
| | |
V V V
+---------------------------------+
| Distribution Source |
+--------+ |
| FT Agg | |
+--------+------------------------+
^ ^ |
: . |
: +...................+
: | .
: / \ .
+------+ / \ +-----+
| FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+
^ ^ / \ ^ ^
: : / \ : :
: : / \ : :
: : / \ : :
: ./\ /\. :
: /. \ / .\ :
: V . V V . V :
+----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+
Figure 6: Example SSM-Based RTP Session with Two Feedback Targets
図6：2つのフィードバックターゲットを持つSSMベースのRTPセッションの例
The use of SSM makes it more difficult to inject traffic into the multicast group, but not impossible. Source authentication requirements apply for SSM sessions, too; an individual verification of who sent the RTP and RTCP packets is needed. An RTP session using SSM will have a group security context that includes the media sources, distribution source, feedback targets, and the receivers. Each has a different role and will be trusted to perform different actions. For example, the distribution source will need to authenticate the media sources to prevent unwanted traffic from being distributed via the SSM group. Similarly, the receivers need to authenticate both the distribution source and their feedback target to prevent injection attacks from malicious devices claiming to be feedback targets. An understanding of the trust relationships and group security context is needed between all components of the system.
SSMを使用すると、マルチキャストグループにトラフィックを注入することが難しくなりますが、不可能ではありません。ソース認証要件はSSMセッションにも適用されます。 RTPおよびRTCPパケットの送信者を個別に確認する必要があります。 SSMを使用するRTPセッションには、メディアソース、配布ソース、フィードバックターゲット、およびレシーバーを含むグループセキュリティコンテキストがあります。それぞれに異なる役割があり、異なるアクションを実行するために信頼されます。たとえば、不要なトラフィックがSSMグループ経由で配信されるのを防ぐために、配信元はメディアソースを認証する必要があります。同様に、受信者は配布ソースとそのフィードバックターゲットの両方を認証して、フィードバックターゲットであると主張する悪意のあるデバイスからのインジェクション攻撃を防ぐ必要があります。システムのすべてのコンポーネント間で、信頼関係とグループセキュリティコンテキストを理解する必要があります。
This section provides an overview of security requirements and the current RTP security mechanisms that implement those requirements. This cannot be a complete survey, since new security mechanisms are defined regularly. The goal is to help applications designers by reviewing the types of solutions that are available. This section will use a number of different security-related terms, as described in the Internet Security Glossary, Version 2 [RFC4949].
このセクションでは、セキュリティ要件の概要と、それらの要件を実装する現在のRTPセキュリティメカニズムについて説明します。新しいセキュリティメカニズムが定期的に定義されているため、これは完全な調査ではありません。目標は、利用可能なソリューションの種類を確認することにより、アプリケーション設計者を支援することです。このセクションでは、インターネットセキュリティ用語集、バージョン2 [RFC4949]で説明されているように、さまざまなセキュリティ関連の用語を使用します。
The Secure Real-time Transport Protocol (SRTP) [RFC3711] is one of the most commonly used mechanisms to provide confidentiality, integrity protection, source authentication, and replay protection for RTP. SRTP was developed with RTP header compression and third-party monitors in mind. Thus, the RTP header is not encrypted in RTP data packets, and the first 8 bytes of the first RTCP packet header in each compound RTCP packet are not encrypted. The entirety of RTP packets and compound RTCP packets are integrity protected. This allows RTP header compression to work and lets third-party monitors determine what RTP traffic flows exist based on the synchronization source (SSRC) fields, but it protects the sensitive content.
Secure Real-time Transport Protocol（SRTP）[RFC3711]は、RTPの機密性、完全性保護、ソース認証、および再生保護を提供するために最も一般的に使用されるメカニズムの1つです。 SRTPは、RTPヘッダー圧縮とサードパーティのモニターを考慮して開発されました。したがって、RTPヘッダーはRTPデータパケットでは暗号化されず、各複合RTCPパケットの最初のRTCPパケットヘッダーの最初の8バイトは暗号化されません。 RTPパケット全体と複合RTCPパケットは完全性が保護されています。これにより、RTPヘッダー圧縮が機能し、サードパーティのモニターが同期ソース（SSRC）フィールドに基づいてどのRTPトラフィックフローが存在するかを判別できますが、機密コンテンツは保護されます。
SRTP works with transforms where different combinations of encryption algorithm, authentication algorithm, and pseudorandom function can be used, and the authentication tag length can be set to any value. SRTP can also be easily extended with additional cryptographic transforms. This gives flexibility but requires more security knowledge by the application developer. To simplify things, Session Description Protocol (SDP) security descriptions (see Section 3.1.3) and Datagram Transport Layer Security Extension for SRTP (DTLS-SRTP) (see Section 3.1.1) use predefined combinations of transforms, known as SRTP crypto suites and SRTP protection profiles, that bundle together transforms and other parameters, making them easier to use but reducing flexibility. The Multimedia Internet Keying (MIKEY) protocol (see Section 3.1.2) provides flexibility to negotiate the full selection of transforms. At the time of this writing, the following transforms, SRTP crypto suites, and SRTP protection profiles are defined or under definition: AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys combined with 160-bit keyed HMAC-SHA-1 with an 80-bit authentication tag. This is the default cryptographic transform that needs to be supported. The transforms are defined in SRTP [RFC3711], with the corresponding SRTP crypto suite defined in [RFC4568] and SRTP protection profile defined in [RFC5764].
SRTPは、暗号化アルゴリズム、認証アルゴリズム、および疑似ランダム関数のさまざまな組み合わせを使用できる変換で機能し、認証タグの長さは任意の値に設定できます。 SRTPは、暗号化変換を追加することで簡単に拡張することもできます。これにより柔軟性が得られますが、アプリケーション開発者によるより多くのセキュリティ知識が必要です。簡単にするために、セッション記述プロトコル（SDP）のセキュリティ記述（セクション3.1.3を参照）およびSRTPのデータグラムトランスポート層セキュリティ拡張機能（DTLS-SRTP）（セクション3.1.1を参照）は、SRTP暗号スイートと呼ばれる変換の定義済みの組み合わせを使用します。トランスフォームとその他のパラメーターを一緒にバンドルするSRTP保護プロファイル。これらを使用すると、使いやすくなりますが、柔軟性が低下します。マルチメディアインターネットキーイング（MIKEY）プロトコル（セクション3.1.2を参照）は、変換の完全な選択を交渉する柔軟性を提供します。これを書いている時点で、次の変換、SRTP暗号スイート、およびSRTP保護プロファイルが定義されているか、定義されています：AES-CMおよびHMAC-SHA-1：AESカウンターモード暗号化（128ビットキーと160ビットキーの組み合わせ） 80ビット認証タグを備えたHMAC-SHA-1。これは、サポートする必要があるデフォルトの暗号変換です。変換はSRTP [RFC3711]で定義され、対応するSRTP暗号スイートは[RFC4568]で定義され、SRTP保護プロファイルは[RFC5764]で定義されます。
AES-f8 and HMAC-SHA-1: AES f8-mode encryption using 128-bit keys combined with keyed HMAC-SHA-1 using 80-bit authentication. The transforms are defined in [RFC3711], with the corresponding SRTP crypto suite defined in [RFC4568]. The corresponding SRTP protection profile is not defined.
AES-f8およびHMAC-SHA-1：128ビットキーを使用するAES f8モード暗号化と、80ビット認証を使用するキー付きHMAC-SHA-1を組み合わせたもの。変換は[RFC3711]で定義されており、対応するSRTP暗号スイートは[RFC4568]で定義されています。対応するSRTP保護プロファイルが定義されていません。
SEED: A Korean national standard cryptographic transform that is defined to be used with SRTP in [RFC5669]. Three options are defined: one using SHA-1 authentication, one using Counter Mode with Cipher Block Chaining Message Authentication Code (CBC-MAC), and one using Galois Counter Mode.
シード：[RFC5669]でSRTPとともに使用するように定義されている韓国の国家標準暗号変換。 3つのオプションが定義されています。1つはSHA-1認証を使用し、1つは暗号化ブロックチェーンメッセージ認証コード（CBC-MAC）を使用するカウンターモードを使用し、もう1つはガロアカウンターモードを使用します。
ARIA: A Korean block cipher [ARIA-SRTP] that supports 128-, 192-, and 256-bit keys. It also defines three options: Counter Mode where combined with HMAC-SHA-1 with 80- or 32-bit authentication tags, Counter Mode with CBC-MAC, and Galois Counter Mode. It also defines a different key derivation function than the AES-based systems.
ARIA：128、192、および256ビットのキーをサポートする韓国のブロック暗号[ARIA-SRTP]。また、3つのオプションも定義します。80ビットまたは32ビットの認証タグを備えたHMAC-SHA-1と組み合わせたカウンターモード、CBC-MACを備えたカウンターモード、およびガロアカウンターモードです。また、AESベースのシステムとは異なる鍵導出関数を定義します。
AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based on AES-192 and AES-256 Counter Mode encryption and 160-bit keyed HMAC-SHA-1 with 80- and 32-bit authentication tags. These provide 192- and 256-bit encryption keys, but otherwise match the default 128-bit AES-CM transform. The transforms are defined in [RFC3711] and [RFC6188], and the SRTP crypto suites are defined in [RFC6188].
AES-192-CMおよびAES-256-CM：AES-192およびAES-256カウンターモード暗号化と、80ビットおよび32ビットの認証タグを備えた160ビットのキー付きHMAC-SHA-1に基づくSRTPの暗号変換。これらは、192ビットおよび256ビットの暗号化キーを提供しますが、それ以外はデフォルトの128ビットAES-CMトランスフォームと一致します。変換は[RFC3711]と[RFC6188]で定義されており、SRTP暗号スイートは[RFC6188]で定義されています。
AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter Mode with CBC-MAC for AES-128 and AES-256. This authentication is included in the cipher text, which becomes expanded with the length of the authentication tag instead of using the SRTP authentication tag. This is defined in [AES-GCM].
AES-GCMおよびAES-CCM：AES GaloisカウンターモードおよびAES-128およびAES-256のCBC-MACを使用したAESカウンターモード。この認証は暗号テキストに含まれており、SRTP認証タグを使用する代わりに、認証タグの長さで拡張されます。これは[AES-GCM]で定義されています。
NULL: SRTP [RFC3711] also provides a NULL cipher that can be used when no confidentiality for RTP/RTCP is requested. The corresponding SRTP protection profile is defined in [RFC5764].
NULL：SRTP [RFC3711]は、RTP / RTCPの機密性が要求されない場合に使用できるNULL暗号も提供します。対応するSRTP保護プロファイルは[RFC5764]で定義されています。
The source authentication guarantees provided by SRTP depend on the cryptographic transform and key management used. Some transforms give strong source authentication even in multiparty sessions; others give weaker guarantees and can authenticate group membership but not sources. Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383] offers a complement to the regular symmetric keyed authentication transforms, like HMAC-SHA-1, and can provide per-source authentication in some group communication scenarios. The downside is the need for buffering the packets for a while before authenticity can be verified.
SRTPによって提供されるソース認証の保証は、使用される暗号変換とキー管理に依存します。一部の変換では、マルチパーティセッションでも強力なソース認証が提供されます。他のものはより弱い保証を提供し、グループメンバーシップを認証できますが、ソースは認証できません。 Timed Efficient Stream Loss-Tolerant Authentication（TESLA）[RFC4383]は、HMAC-SHA-1などの通常の対称鍵認証変換を補完し、一部のグループ通信シナリオでソースごとの認証を提供できます。欠点は、信頼性を検証する前にしばらくパケットをバッファリングする必要があることです。
[RFC4771] defines a variant of the authentication tag that enables a receiver to obtain the Roll over Counter for the RTP sequence number that is part of the Initialization Vector (IV) for many cryptographic transforms. This enables quicker and easier options for joining a long-lived RTP group; for example, a broadcast session.
[RFC4771]は、多くの暗号化変換の初期化ベクトル（IV）の一部であるRTPシーケンス番号のロールオーバーカウンターを受信者が取得できるようにする認証タグのバリアントを定義しています。これにより、存続期間の長いRTPグループに参加するためのより迅速で簡単なオプションが可能になります。たとえば、ブロードキャストセッション。
RTP header extensions are normally carried in the clear and are only integrity protected in SRTP. This can be problematic in some cases, so [RFC6904] defines an extension to also encrypt selected header extensions.
RTPヘッダー拡張は通常、クリアテキストで伝送され、SRTPでのみ整合性が保護されます。これは場合によっては問題になる可能性があるため、[RFC6904]は、選択したヘッダー拡張も暗号化する拡張を定義します。
SRTP is specified and deployed in a number of RTP usage contexts; significant support is provided in SIP-established VoIP clients, including IP Multimedia Subsystems (IMS), and in the Real Time Streaming Protocol (RTSP) [RTSP] and RTP-based media streaming. Thus, SRTP in general is widely deployed. When it comes to cryptographic transforms, the default (AES-CM and HMAC-SHA-1) is the most commonly used, but it might be expected that AES-GCM, AES-192-CM, and AES-256-CM will gain usage in future, especially due to the AES- and GCM-specific instructions in new CPUs.
SRTPは、いくつかのRTP使用状況で指定および展開されます。重要なサポートは、IPマルチメディアサブシステム（IMS）を含むSIPが確立したVoIPクライアント、およびリアルタイムストリーミングプロトコル（RTSP）[RTSP]およびRTPベースのメディアストリーミングで提供されます。したがって、SRTPは一般に広く展開されています。暗号化変換に関しては、デフォルト（AES-CMおよびHMAC-SHA-1）が最も一般的に使用されますが、AES-GCM、AES-192-CM、およびAES-256-CMは、特に新しいCPUでのAESおよびGCM固有の命令による将来の使用。
SRTP does not contain an integrated key management solution; instead, it relies on an external key management protocol. There are several protocols that can be used. The following sections outline some popular schemes.
SRTPには、統合されたキー管理ソリューションは含まれていません。代わりに、外部キー管理プロトコルに依存しています。使用できるプロトコルはいくつかあります。次のセクションでは、いくつかの一般的なスキームの概要を説明します。
A Datagram Transport Layer Security (DTLS) extension exists for establishing SRTP keys [RFC5763][RFC5764]. This extension provides secure key exchange between two peers, enabling Perfect Forward Secrecy (PFS) and binding strong identity verification to an endpoint. PFS is a property of the key agreement protocol that ensures that a session key derived from a set of long-term keys will not be compromised if one of the long-term keys is compromised in the future. The default key generation will generate a key that contains material contributed by both peers. The key exchange happens in the media plane directly between the peers. The common key exchange procedures will take two round trips assuming no losses. Transport Layer Security (TLS) resumption can be used when establishing additional media streams with the same peer, and it reduces the setup time to one RTT for these streams (see [RFC5764] for a discussion of TLS resumption in this context).
SRTPキーを確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張が存在します[RFC5763] [RFC5764]。この拡張機能は、2つのピア間の安全なキー交換を提供し、Perfect Forward Secrecy（PFS）を有効にし、強力なID検証をエンドポイントにバインドします。 PFSは鍵合意プロトコルのプロパティであり、長期鍵の1つが将来侵害されても、長期鍵のセットから派生したセッション鍵が侵害されないことを保証します。デフォルトのキー生成では、両方のピアから提供された素材を含むキーが生成されます。キー交換は、ピア間のメディアプレーンで直接行われます。共通の鍵交換手順は、損失がないと仮定して2回のラウンドトリップを行います。トランスポート層セキュリティ（TLS）再開は、同じピアで追加のメディアストリームを確立するときに使用でき、これらのストリームのセットアップ時間を1つのRTTに短縮します（このコンテキストでのTLS再開の説明については、[RFC5764]を参照してください）。
The actual security properties of an established SRTP session using DTLS will depend on the cipher suites offered and used, as well as the mechanism for identifying the endpoints of the handshake. For example, some cipher suites provide PFS, while others do not. When using DTLS, the application designer needs to select which cipher suites DTLS-SRTP can offer and accept so that the desired security properties are achieved. The next choice is how to verify the identity of the peer endpoint. One choice can be to rely on the certificates and use a PKI to verify them to make an identity assertion. However, this is not the most common way; instead, self-signed certificates are common to use to establish trust through signaling or other third-party solutions.
DTLSを使用して確立されたSRTPセッションの実際のセキュリティプロパティは、提供および使用される暗号スイート、およびハンドシェイクのエンドポイントを識別するメカニズムによって異なります。たとえば、PFSを提供する暗号スイートもあれば、提供しない暗号スイートもあります。 DTLSを使用する場合、アプリケーション設計者は、DTLS-SRTPが提供および受け入れできる暗号スイートを選択して、目的のセキュリティプロパティを実現する必要があります。次の選択は、ピアエンドポイントのIDを確認する方法です。 1つの選択肢は、証明書に依存し、PKIを使用してそれらを検証してIDアサーションを作成することです。ただし、これは最も一般的な方法ではありません。その代わり、自己署名証明書は、シグナリングまたは他のサードパーティソリューションを通じて信頼を確立するために使用するのが一般的です。
DTLS-SRTP key management can use the signaling protocol in four ways: First, to agree on using DTLS-SRTP for media security. Second, to determine the network location (address and port) where each side is running a DTLS listener to let the parts perform the key management handshakes that generate the keys used by SRTP. Third, to exchange hashes of each side's certificates to bind these to the signaling and ensure there is no MITM attack. This assumes that one can trust the signaling solution to be resistant to modification and not be in collaboration with an attacker. Finally, to provide an asserted identity, e.g., [RFC4474], that can be used to prevent modification of the signaling and the exchange of certificate hashes. That way, it enables binding between the key exchange and the signaling.
DTLS-SRTPキー管理は、4つの方法でシグナリングプロトコルを使用できます。最初に、メディアセキュリティのためのDTLS-SRTPの使用に同意します。次に、各側がDTLSリスナーを実行しているネットワークの場所（アドレスとポート）を特定し、SRTPで使用されるキーを生成するキー管理ハンドシェイクを実行できるようにします。 3番目に、各サイドの証明書のハッシュを交換してこれらをシグナリングにバインドし、MITM攻撃がないことを確認します。これは、信号ソリューションが変更に耐性があり、攻撃者と協力していないと信頼できることを前提としています。最後に、[RFC4474]などのアサートされたIDを提供して、シグナリングの変更や証明書ハッシュの交換を防ぐために使用できます。これにより、鍵交換とシグナリングの間のバインディングが可能になります。
This usage is well defined for SIP/SDP in [RFC5763] and, in most cases, can be adopted for use with other bidirectional signaling solutions. It is to be noted that there is work underway to revisit the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
この使用法は、[RFC5763]のSIP / SDPで明確に定義されており、ほとんどの場合、他の双方向シグナリングソリューションで使用するために採用できます。 IETF STIRワーキンググループでSIP Identityメカニズム[RFC4474]を再検討する作業が進行中であることに注意してください。
The main question regarding DTLS-SRTP's security properties is how one verifies any peer identity or at least prevents MITM attacks. This does require trust in some DTLS-SRTP external parties: either a PKI, a signaling system, or some identity provider.
DTLS-SRTPのセキュリティプロパティに関する主な問題は、ピアIDを確認する方法、または少なくともMITM攻撃を防ぐ方法です。これには、一部のDTLS-SRTP外部関係者（PKI、信号システム、または一部のIDプロバイダー）での信頼が必要です。
DTLS-SRTP usage is clearly on the rise. It is mandatory to support in Web Real-Time Communication (WebRTC). It has growing support among SIP endpoints. DTLS-SRTP was developed in IETF primarily to meet security requirements for RTP-based media established using SIP. The requirements considered can be reviewed in "Requirements and Analysis of Media Security Management Protocols" [RFC5479].
DTLS-SRTPの使用は明らかに増加しています。 Webリアルタイム通信（WebRTC）でのサポートは必須です。 SIPエンドポイント間でサポートが拡大しています。 DTLS-SRTPは、主にSIPを使用して確立されたRTPベースのメディアのセキュリティ要件を満たすためにIETFで開発されました。検討される要件は、「メディアセキュリティ管理プロトコルの要件と分析」[RFC5479]で確認できます。
Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol that has several modes with different properties. MIKEY can be used in point-to-point applications using SIP and RTSP (e.g., VoIP calls) but is also suitable for use in broadcast and multicast applications and centralized group communications.
マルチメディアインターネットキーイング（MIKEY）[RFC3830]は、異なるプロパティを持ついくつかのモードを持つキーイングプロトコルです。 MIKEYは、SIPおよびRTSPを使用するポイントツーポイントアプリケーション（VoIPコールなど）で使用できますが、ブロードキャストおよびマルチキャストアプリケーションや集中型グループ通信での使用にも適しています。
MIKEY can establish multiple security contexts or cryptographic sessions with a single message. It is usable in scenarios where one entity generates the key and needs to distribute the key to a number of participants. The different modes and the resulting properties are highly dependent on the cryptographic method used to establish the session keys actually used by the security protocol, like SRTP.
MIKEYは、単一のメッセージで複数のセキュリティコンテキストまたは暗号化セッションを確立できます。 1つのエンティティがキーを生成し、多数の参加者にキーを配布する必要があるシナリオで使用できます。さまざまなモードと結果のプロパティは、SRTPなどのセキュリティプロトコルで実際に使用されるセッションキーを確立するために使用される暗号化方法に大きく依存します。
MIKEY has the following modes of operation:
MIKEYには次の操作モードがあります。
Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto used to secure a keying message carrying the already-generated session key. This system is the most efficient from the perspective of having small messages and processing demands. The downside is scalability, where usually the effort for the provisioning of pre-shared keys is only manageable if the number of endpoints is small.
事前共有鍵：すでに生成されたセッション鍵を運ぶ鍵メッセージを保護するために使用される対称鍵暗号に事前共有秘密を使用します。このシステムは、小さなメッセージを処理し、要求を処理する観点から最も効率的です。欠点はスケーラビリティです。通常、事前共有キーのプロビジョニングの労力は、エンドポイントの数が少ない場合にのみ管理できます。
Public Key Encryption: Uses a public key crypto to secure a keying message carrying the already-generated session key. This is more resource intensive but enables scalable systems. It does require a public key infrastructure to enable verification.
公開鍵暗号化：公開鍵暗号を使用して、すでに生成されたセッション鍵を運ぶ鍵メッセージを保護します。これはより多くのリソースを必要としますが、スケーラブルなシステムを可能にします。検証を有効にするには、公開鍵インフラストラクチャが必要です。
Diffie-Hellman: Uses Diffie-Hellman key agreement to generate the session key, thus providing perfect forward secrecy. The downside is high resource consumption in bandwidth and processing during the MIKEY exchange. This method can't be used to establish group keys as each pair of peers performing the MIKEY exchange will establish different keys.
Diffie-Hellman：Diffie-Hellmanキー合意を使用してセッションキーを生成し、完全な転送秘密を提供します。欠点は、帯域幅とMIKEY交換中の処理におけるリソース消費量が多いことです。 MIKEY交換を実行するピアの各ペアが異なるキーを確立するため、このメソッドを使用してグループキーを確立することはできません。
HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of the Diffie-Hellman exchange that uses a pre-shared key in a keyed Hashed Message Authentication Code (HMAC) to verify authenticity of the keying material instead of a digital signature as in the previous method. This method is still restricted to point-to-point usage.
HMAC-Authenticated Diffie-Hellman：[RFC4650]は、キー付きHashed Message Authentication Code（HMAC）の事前共有キーを使用して、デジタル署名の代わりにデジタル署名ではなくキー情報の真正性を検証するDiffie-Hellman交換のバリアントを定義します以前の方法。この方法は、ポイントツーポイントの使用に限定されています。
RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the public key method, which doesn't rely on the initiator of the key exchange knowing the responder's certificate. This method lets both the initiator and the responder specify the session keying material depending on the use case. Usage of this mode requires one round-trip time.
RSA-R：リバースモードのMIKEY-RSA [RFC4738]は、公開鍵方式の変形であり、応答者の証明書を知っている鍵交換の開始者に依存しません。この方法では、イニシエーターとレスポンダーの両方が、ユースケースに応じてセッションキーイングマテリアルを指定できます。このモードを使用するには、1回の往復時間が必要です。
TICKET: Ticket Payload (TICKET) [RFC6043] is a MIKEY extension using a trusted centralized key management service (KMS). The initiator and responder do not share any credentials; instead, they trust a third party, the KMS, with which they both have or can establish shared credentials.
TICKET：チケットペイロード（TICKET）[RFC6043]は、信頼された集中鍵管理サービス（KMS）を使用するMIKEY拡張です。イニシエーターとレスポンダーは資格情報を共有しません。代わりに、サードパーティであるKMSを信頼します。KMSを使用すると、両方が共有の資格情報を持っているか、確立できます。
IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) [RFC6267] uses a KMS infrastructure but with lower demand on the KMS. It claims to provide both perfect forward and backwards secrecy.
IBAKE：Identity-Based Authenticated Key Exchange（IBAKE）[RFC6267]はKMSインフラストラクチャを使用しますが、KMSへの要求は低くなります。それは完全な前方と後方の両方の秘密を提供すると主張しています。
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption (SAKKE) in MIKEY. It is based on Identity-based Public Key Cryptography and a KMS infrastructure to establish a shared secret value and certificateless signatures to provide source authentication. Its features include simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.
SAKKE：[RFC6509]はMIKEYで堺笠原キー暗号化（SAKKE）を提供します。 IDベースの公開キー暗号化とKMSインフラストラクチャに基づいており、共有の秘密の値と証明書のない署名を確立して、ソース認証を提供します。その機能には、シンプレックス伝送、スケーラビリティ、低遅延のコールセットアップ、および安全な遅延配信のサポートが含まれます。
MIKEY messages have several different transports. [RFC4567] defines how MIKEY messages can be embedded in general SDP for usage with the signaling protocols SIP, Session Announcement Protocol (SAP), and RTSP. There also exists a usage of MIKEY defined by the Third Generation Partnership Project (3GPP) that sends MIKEY messages directly over UDP [T3GPP.33.246] to key the receivers of Multimedia Broadcast and Multicast Service (MBMS) [T3GPP.26.346]. [RFC3830] defines the application/mikey media type, allowing MIKEY to be used in, e.g., email and HTTP.
MIKEYメッセージにはいくつかの異なるトランスポートがあります。 [RFC4567]は、シグナリングプロトコルSIP、セッションアナウンスメントプロトコル（SAP）、およびRTSPで使用するために、MIKEYメッセージを一般的なSDPに埋め込む方法を定義しています。マルチメディアブロードキャストおよびマルチキャストサービス（MBMS）[T3GPP.26.346]の受信者をキーイングするために、UDP [T3GPP.33.246]を介してMIKEYメッセージを直接送信する第3世代パートナーシッププロジェクト（3GPP）によって定義されたMIKEYの使用法も存在します。 [RFC3830]は、アプリケーション/ mikeyメディアタイプを定義し、MIKEYを電子メールやHTTPなどで使用できるようにします。
Based on the many choices, it is important to consider the properties needed in one's solution and based on that evaluate which modes are candidates for use. More information on the applicability of the different MIKEY modes can be found in [RFC5197].
多くの選択肢に基づいて、自分のソリューションに必要なプロパティを検討し、それに基づいて、どのモードが使用の候補であるかを評価することが重要です。さまざまなMIKEYモードの適用性の詳細については、[RFC5197]を参照してください。
MIKEY with pre-shared keys is used by 3GPP MBMS [T3GPP.33.246], and IMS media security [T3GPP.33.328] specifies the use of the TICKET mode transported over SIP and HTTP. RTSP 2.0 [RTSP] specifies use of the RSA-R mode. There are some SIP endpoints that support MIKEY. The modes they use are unknown to the authors.
事前共有キー付きのMIKEYは3GPP MBMS [T3GPP.33.246]で使用され、IMSメディアセキュリティ[T3GPP.33.328]はSIPおよびHTTPで転送されるTICKETモードの使用を指定します。 RTSP 2.0 [RTSP]は、RSA-Rモードの使用を指定します。 MIKEYをサポートするSIPエンドポイントがいくつかあります。彼らが使用するモードは、著者には不明です。
[RFC4568] provides a keying solution based on sending plaintext keys in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/ Answer model and is well defined in point-to-point sessions where each side declares its own unique key. Using security descriptions to establish group keys is less well defined and can have security issues since it's difficult to guarantee unique SSRCs (as needed to avoid a "two-time pad" attack -- see Section 9 of [RFC3711]).
[RFC4568]は、SDP [RFC4566]でプレーンテキストキーを送信することに基づくキーソリューションを提供します。これは主にSIPおよびSDPオファー/アンサーモデルで使用され、各サイドが独自の一意のキーを宣言するポイントツーポイントセッションで適切に定義されます。セキュリティの説明を使用してグループキーを確立することはあまり明確ではなく、一意のSSRCを保証することが難しいため、セキュリティ上の問題が発生する可能性があります（「2回パッド」攻撃を回避するために必要です。[RFC3711]のセクション9を参照してください）。
Since keys are transported in plaintext in SDP, they can easily be intercepted unless the SDP carrying protocol provides strong end-to-end confidentiality and authentication guarantees. This is not normally the case; instead, hop-by-hop security is provided between signaling nodes using TLS. This leaves the keying material sensitive to capture by the traversed signaling nodes. Thus, in most cases, the security properties of security descriptions are weak. The usage of security descriptions usually requires additional security measures; for example, the signaling nodes are trusted and protected by strict access control. Usage of security descriptions requires careful design in order to ensure that the security goals can be met.
鍵はSDPでプレーンテキストで転送されるため、SDP伝送プロトコルが強力なエンドツーエンドの機密性と認証を保証しない限り、鍵は簡単に傍受される可能性があります。これは通常は当てはまりません。代わりに、ホップバイホップのセキュリティが、TLSを使用してシグナリングノード間に提供されます。これにより、キーイングマテリアルは、通過したシグナリングノードによるキャプチャに対して敏感になります。したがって、ほとんどの場合、セキュリティ記述のセキュリティプロパティは脆弱です。セキュリティの説明を使用するには、通常、追加のセキュリティ対策が必要です。たとえば、信号ノードは信頼され、厳格なアクセス制御によって保護されています。セキュリティの説明を使用するには、セキュリティの目標を確実に満たすために注意深い設計が必要です。
Security descriptions are the most commonly deployed keying solution for SIP-based endpoints, where almost all endpoints that support SRTP also support security descriptions. It is also used for access protection in IMS Media Security [T3GPP.33.328].
セキュリティの説明は、SIPベースのエンドポイントに最も一般的に導入されているキーイングソリューションです。SRTPをサポートするほとんどすべてのエンドポイントがセキュリティの説明もサポートしています。また、IMS Media Security [T3GPP.33.328]でのアクセス保護にも使用されます。
Encrypted Key Transport (EKT) [EKT] is an SRTP extension that enables group keying despite using a keying mechanism like DTLS-SRTP that doesn't support group keys. It is designed for centralized conferencing, but it can also be used in sessions where endpoints connect to a conference bridge or a gateway and need to be provisioned with the keys each participant on the bridge or gateway uses to avoid decryption and encryption cycles. This can enable interworking between DTLS-SRTP and other keying systems where either party can set the key (e.g., interworking with security descriptions).
暗号化キー転送（EKT）[EKT]は、グループキーをサポートしないDTLS-SRTPなどのキーイングメカニズムを使用している場合でも、グループキーイングを有効にするSRTP拡張です。これは集中会議用に設計されていますが、エンドポイントが会議ブリッジまたはゲートウェイに接続し、ブリッジまたはゲートウェイの各参加者が復号化と暗号化のサイクルを回避するために使用するキーをプロビジョニングする必要があるセッションでも使用できます。これにより、DTLS-SRTPと、いずれかの当事者がキーを設定できる他のキーイングシステム間のインターワーキングが可能になります（たとえば、セキュリティの説明とのインターワーキング）。
The mechanism is based on establishing an additional EKT key, which everyone uses to protect their actual session key. The actual session key is sent in an expanded authentication tag to the other session participants. This key is only sent occasionally or periodically depending on use cases and depending on what requirements exist for timely delivery or notification.
このメカニズムは、誰もが実際のセッションキーを保護するために使用する追加のEKTキーの確立に基づいています。実際のセッションキーは、拡張認証タグで他のセッション参加者に送信されます。このキーは、ユースケースに応じて、またタイムリーな配信または通知に存在する要件に応じて、時折または定期的にのみ送信されます。
The only known deployment of EKT so far is in some Cisco video conferencing products.
これまでに知られている唯一のEKTの展開は、一部のCiscoビデオ会議製品です。
The ZRTP [RFC6189] key management system for SRTP was proposed as an alternative to DTLS-SRTP. ZRTP provides best effort encryption independent of the signaling protocol and utilizes key continuity, Short Authentication Strings, or a PKI for authentication. ZRTP wasn't adopted as an IETF Standards Track protocol, but was instead published as an Informational RFC in the IETF stream. Commercial implementations exist.
SRTPのZRTP [RFC6189]キー管理システムは、DTLS-SRTPの代替として提案されました。 ZRTPは、シグナリングプロトコルから独立したベストエフォート型の暗号化を提供し、認証に鍵の連続性、短い認証文字列、またはPKIを利用します。 ZRTPはIETF標準トラックプロトコルとして採用されていませんが、代わりにIETFストリームで情報RFCとして公開されていました。商用実装が存在します。
Additional proprietary solutions are also known to exist.
追加の独自のソリューションも存在することが知られています。
Section 9 of the RTP standard [RFC3550] defines a Data Encryption Standard (DES) or 3DES-based encryption of RTP and RTCP packets. This mechanism is keyed using plaintext keys in SDP [RFC4566] using the "k=" SDP field. This method can provide confidentiality but, as discussed in Section 9 of [RFC3550], it has extremely weak security properties and is not to be used.
RTP標準[RFC3550]のセクション9は、RTPおよびRTCPパケットのデータ暗号化標準（DES）または3DESベースの暗号化を定義しています。このメカニズムは、「k = SDP」フィールドを使用して、SDP [RFC4566]のプレーンテキストキーを使用してキーイングされます。この方法は機密性を提供できますが、[RFC3550]のセクション9で説明されているように、非常に弱いセキュリティプロパティがあり、使用されません。
IPsec [RFC4301] can be used in either tunnel or transport mode to protect RTP and RTCP packets in transit from one network interface to another. This can be sufficient when the network interfaces have a direct relation or in a secured environment where it can be controlled who can read the packets from those interfaces.
IPsec [RFC4301]は、トンネルモードまたはトランスポートモードのいずれかで使用して、1つのネットワークインターフェイスから別のネットワークインターフェイスへの転送中のRTPおよびRTCPパケットを保護できます。これは、ネットワークインターフェイスが直接の関係にある場合、またはそれらのインターフェイスからパケットを読み取ることができるユーザーを制御できる安全な環境で十分な場合があります。
The main concern with using IPsec to protect RTP traffic is that in most cases, using a VPN approach that terminates the security association at some node prior to the RTP endpoint leaves the traffic vulnerable to attack between the VPN termination node and the endpoint. Thus, usage of IPsec requires careful thought and design of its usage so that it meets the security goals. An important question is how one ensures the IPsec terminating peer and the ultimate destination are the same. Applications can have issues using existing APIs when determining if IPsec is being used or not and when determining who the authenticated peer entity is when IPsec is used.
IPsecを使用してRTPトラフィックを保護することの主な懸念は、ほとんどの場合、RTPエンドポイントの前にセキュリティアソシエーションを終了するVPNアプローチを使用すると、VPNターミネーションノードとエンドポイント間の攻撃に対してトラフィックが脆弱になることです。したがって、IPsecを使用するには、セキュリティの目標を達成するために、IPsecを慎重に検討して使用する必要があります。重要な問題は、IPsec終端ピアと最終的な宛先が同じであることをどのように保証するかです。 IPsecが使用されているかどうかを判別するとき、およびIPsecが使用されているときに認証されたピアエンティティが誰であるかを判別するときに、アプリケーションは既存のAPIを使用して問題を抱えることがあります。
IPsec with RTP is more commonly used as a security solution between infrastructure nodes that exchange many RTP sessions and media streams. The establishment of a secure tunnel between such nodes minimizes the key management overhead.
RTPを使用したIPsecは、多くのRTPセッションとメディアストリームを交換するインフラストラクチャノード間のセキュリティソリューションとしてより一般的に使用されます。このようなノード間に安全なトンネルを確立すると、キー管理のオーバーヘッドが最小限に抑えられます。
Just as RTP can be sent over TCP [RFC4571], it can also be sent over TLS over TCP [RFC4572], using TLS to provide point-to-point security services. The security properties TLS provides are confidentiality, integrity protection, and possible source authentication if the client or server certificates are verified and provide a usable identity. When used in multiparty scenarios using a central node for media distribution, the security provided is only between the central node and the peers, so the security properties for the whole session are dependent on what trust one can place in the central node.
RTPがTCP [RFC4571]で送信できるのと同様に、ポイントツーポイントのセキュリティサービスを提供するためにTLSを使用して、TLS over TCP [RFC4572]で送信することもできます。 TLSが提供するセキュリティプロパティは、機密性、整合性保護、およびクライアントまたはサーバーの証明書が検証され、使用可能なIDを提供する場合に可能なソース認証です。メディア配信にセントラルノードを使用するマルチパーティシナリオで使用する場合、提供されるセキュリティはセントラルノードとピア間のみであるため、セッション全体のセキュリティプロパティは、セントラルノードに配置できる信頼に依存します。
RTSP 1.0 [RFC2326] and 2.0 [RTSP] specify the usage of RTP over the same TLS/TCP connection that the RTSP messages are sent over. It appears that RTP over TLS/TCP is also used in some proprietary solutions that use TLS to bypass firewalls.
RTSP 1.0 [RFC2326]および2.0 [RTSP]は、RTSPメッセージが送信されるのと同じTLS / TCP接続でのRTPの使用を指定します。 RTP over TLS / TCPは、ファイアウォールをバイパスするためにTLSを使用するいくつかの独自のソリューションでも使用されているようです。
DTLS [RFC6347] is based on TLS [RFC5246] but designed to work over an unreliable datagram-oriented transport rather than requiring reliable byte stream semantics from the transport protocol. Accordingly, DTLS can provide point-to-point security for RTP flows analogous to that provided by TLS but over a datagram transport such as UDP. The two peers establish a DTLS association between each other, including the possibility to do certificate-based source authentication when establishing the association. All RTP and RTCP packets flowing will be protected by this DTLS association.
DTLS [RFC6347]はTLS [RFC5246]に基づいていますが、トランスポートプロトコルからの信頼性の高いバイトストリームセマンティクスを要求するのではなく、信頼性の低いデータグラム指向のトランスポート上で機能するように設計されています。したがって、DTLSは、TLSによって提供されるものと類似しているが、UDPなどのデータグラム転送を介して、RTPフローにポイントツーポイントのセキュリティを提供できます。 2つのピアは、相互にDTLSアソシエーションを確立します。これには、アソシエーションを確立するときに証明書ベースのソース認証を行う可能性も含まれます。流れるすべてのRTPおよびRTCPパケットは、このDTLSアソシエーションによって保護されます。
Note that using DTLS for RTP flows is different from using DTLS-SRTP key management. DTLS-SRTP uses the same key management steps as DTLS, but uses SRTP for the per-packet security operations. Using DTLS for RTP flows uses the normal datagram TLS data protection, wrapping complete RTP packets. When using DTLS for RTP flows, the RTP and RTCP packets are completely encrypted with no headers in the clear; when using DTLS-SRTP, the RTP headers are in the clear and only the payload data is encrypted.
RTPフローにDTLSを使用することは、DTLS-SRTPキー管理を使用することとは異なることに注意してください。 DTLS-SRTPはDTLSと同じキー管理手順を使用しますが、パケットごとのセキュリティ操作にはSRTPを使用します。 RTPフローにDTLSを使用すると、通常のデータグラムTLSデータ保護が使用され、完全なRTPパケットがラップされます。 RTPフローにDTLSを使用する場合、RTPおよびRTCPパケットは完全に暗号化され、平文のヘッダーはありません。 DTLS-SRTPを使用する場合、RTPヘッダーは平文であり、ペイロードデータのみが暗号化されます。
DTLS can use similar techniques to those available for DTLS-SRTP to bind a signaling-side agreement to communicate to the certificates used by the endpoint when doing the DTLS handshake. This enables use without having a certificate-based trust chain to a trusted certificate root.
DTLSは、DTLS-SRTPで使用可能なものと同様の手法を使用して、シグナリング側の合意をバインドし、DTLSハンドシェイクを行うときにエンドポイントが使用する証明書と通信することができます。これにより、信頼できる証明書ルートへの証明書ベースの信頼チェーンがなくても使用できます。
There does not appear to be significant usage of DTLS for RTP.
RTPのDTLSの重要な使用法はないようです。
Mechanisms have been defined that encrypt only the media content operating within the RTP payload data and leaving the RTP headers and RTCP unaffected. There are several reasons why this might be appropriate, but a common rationale is to ensure that the content stored by RTSP streaming servers has the media content in a protected format that cannot be read by the streaming server (this is mostly done in the context of Digital Rights Management). These approaches then use a key management solution between the rights provider and the consuming client to deliver the key used to protect the content and do not give the media server access to the security context. Such methods have several security weaknesses such as the fact that the same key is handed out to a potentially large group of receiving clients, increasing the risk of a leak.
RTPペイロードデータ内で動作し、RTPヘッダーとRTCPに影響を与えずに動作するメディアコンテンツのみを暗号化するメカニズムが定義されています。これが適切である理由はいくつかありますが、一般的な根拠は、RTSPストリーミングサーバーによって格納されたコンテンツに、ストリーミングサーバーが読み取ることができない保護された形式のメディアコンテンツが含まれていることを確認することです（これは主に、デジタル著作権管理）。次に、これらのアプローチは、権利プロバイダーと消費クライアント間のキー管理ソリューションを使用して、コンテンツの保護に使用されるキーを配信し、メディアサーバーにセキュリティコンテキストへのアクセス権を付与しません。このような方法には、同じキーが潜在的に大きな受信クライアントのグループに渡されるため、リークのリスクが高まるなど、いくつかのセキュリティ上の弱点があります。
Use of this type of solution can be of interest in environments that allow middleboxes to rewrite the RTP headers and select which streams are delivered to an endpoint (e.g., some types of centralized video conference systems). The advantage of encrypting and possibly integrity protecting the payload but not the headers is that the middlebox can't eavesdrop on the media content, but it can still provide stream switching functionality. The downside of such a system is that it likely needs two levels of security: the payload-level solution, to provide confidentiality and source authentication, and a second layer with additional transport security ensuring source authentication and integrity of the RTP headers associated with the encrypted payloads. This can also result in the need to have two different key management systems as the entity protecting the packets and payloads are different with a different set of keys.
このタイプのソリューションの使用は、ミドルボックスがRTPヘッダーを書き換えて、エンドポイントに配信するストリームを選択できる環境（たとえば、一部のタイプの集中型ビデオ会議システム）で興味深いことがあります。ヘッダーではなくペイロードを暗号化し、場合によっては整合性を保護することの利点は、ミドルボックスがメディアコンテンツを盗聴できないことですが、ストリーム切り替え機能を提供できます。このようなシステムの欠点は、2つのセキュリティレベルが必要になる可能性が高いことです。機密性とソース認証を提供するペイロードレベルのソリューションと、暗号化に関連付けられたRTPヘッダーのソース認証と整合性を保証する追加のトランスポートセキュリティを備えた第2レイヤーペイロード。また、パケットとペイロードを保護するエンティティが異なるキーのセットでは異なるため、2つの異なるキー管理システムが必要になる場合もあります。
The aspect of two tiers of security are present in ISMACryp (see Section 3.6.1) and the deprecated 3GPP Packet-switched Streaming Service solution; see Annex K of [T3GPP.26.234R8].
2層のセキュリティの側面は、ISMACryp（セクション3.6.1を参照）および非推奨の3GPPパケット交換ストリーミングサービスソリューションに存在します。 [T3GPP.26.234R8]の付録Kを参照してください。
The Internet Streaming Media Alliance (ISMA) has defined ISMA Encryption and Authentication 2.0 [ISMACryp2]. This specification defines how one encrypts and packetizes the encrypted application data units (ADUs) in an RTP payload using the MPEG-4 generic payload format [RFC3640]. The ADU types that are allowed are those that can be stored as elementary streams in an ISO Media File format-based file. ISMACryp uses SRTP for packet-level integrity and source authentication from a streaming server to the receiver.
インターネットストリーミングメディアアライアンス（ISMA）は、ISMA暗号化および認証2.0 [ISMACryp2]を定義しています。この仕様は、MPEG-4汎用ペイロード形式[RFC3640]を使用して、RTPペイロード内の暗号化されたアプリケーションデータユニット（ADU）を暗号化およびパケット化する方法を定義します。許可されるADUタイプは、ISOメディアファイル形式ベースのファイルにエレメンタリーストリームとして保存できるタイプです。 ISMACrypはSRTPを使用して、パケットレベルの整合性と、ストリーミングサーバーから受信機へのソース認証を行います。
Key management for an ISMACryp-based system can be achieved through Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], for example.
ISMACrypベースのシステムのキー管理は、たとえばOpen Mobile Alliance（OMA）Digital Rights Management 2.0 [OMADRMv2]を通じて実現できます。
In the following, we provide guidelines for how to choose appropriate security mechanisms for RTP applications.
以下では、RTPアプリケーションに適切なセキュリティメカニズムを選択する方法のガイドラインを示します。
This section discusses a number of application requirements that need to be considered. An application designer choosing security solutions requires a good understanding of what level of security is needed and what behavior they strive to achieve.
このセクションでは、考慮が必要ないくつかのアプリケーション要件について説明します。セキュリティソリューションを選択するアプリケーション設計者は、どのレベルのセキュリティが必要であり、どのような振る舞いを実現しようとしているのかをよく理解する必要があります。
When it comes to confidentiality of an RTP session, there are several aspects to consider:
RTPセッションの機密性に関しては、考慮すべきいくつかの側面があります。
Probability of compromise: When using encryption to provide media confidentiality, it is necessary to have some rough understanding of the security goal and how long one can expect the protected content to remain confidential. National or other regulations might provide additional requirements on a particular usage of an RTP. From that, one can determine which encryption algorithms are to be used from the set of available transforms.
侵害の確率：暗号化を使用してメディアの機密性を提供する場合は、セキュリティの目標と、保護されたコンテンツの機密性を保持できる期間をある程度理解する必要があります。国またはその他の規制により、RTPの特定の使用に関する追加要件が規定されている場合があります。これにより、使用可能な変換のセットから、使用する暗号化アルゴリズムを決定できます。
Potential for other leakage: RTP-based security in most of its forms simply wraps RTP and RTCP packets into cryptographic containers. This commonly means that the size of the original RTP payload is visible to observers of the protected packet flow. This can provide information to those observers. A well-documented case is the risk with variable bitrate speech codecs that produce different sized packets based on the speech input [RFC6562]. Potential threats such as these need to be considered and, if they are significant, then restrictions will be needed on mode choices in the codec, or additional padding will need to be added to make all packets equal size and remove the informational leakage.
その他の漏洩の可能性：ほとんどの形式のRTPベースのセキュリティは、RTPおよびRTCPパケットを暗号化コンテナーに単純にラップします。これは通常、元のRTPペイロードのサイズが、保護されたパケットフローの監視者に見えることを意味します。これにより、これらのオブザーバーに情報を提供できます。十分に文書化されたケースは、音声入力に基づいて異なるサイズのパケットを生成する可変ビットレート音声コーデックのリスクです[RFC6562]。これらのような潜在的な脅威を考慮する必要があり、それらが重要な場合は、コーデックのモード選択に制限が必要になるか、またはすべてのパケットを同じサイズにして情報漏えいを取り除くために追加のパディングを追加する必要があります。
Another case is RTP header extensions. If SRTP is used, header extensions are normally not protected by the security mechanism protecting the RTP payload. If the header extension carries information that is considered sensitive, then the application needs to be modified to ensure that mechanisms used to protect against such information leakage are employed.
別のケースは、RTPヘッダー拡張です。 SRTPを使用する場合、ヘッダー拡張は通常、RTPペイロードを保護するセキュリティメカニズムによって保護されません。ヘッダー拡張に機密と見なされる情報が含まれている場合は、アプリケーションを変更して、このような情報漏えいから保護するためのメカニズムを使用する必要があります。
Who has access: When considering the confidentiality properties of a system, it is important to consider where the media handled in the clear. For example, if the system is based on an RTP mixer that needs the keys to decrypt the media, process it, and repacketize it, then is the mixer providing the security guarantees expected by the other parts of the system? Furthermore, it is important to consider who has access to the keys. The policies for the handling of the keys, and who can access the keys, need to be considered along with the confidentiality goals.
誰がアクセスできるか：システムの機密性を検討する場合、メディアが平文でどこで処理されたかを検討することが重要です。たとえば、システムがRTPミキサーに基づいており、メディアを復号化して処理し、再パケット化するためのキーが必要な場合、ミキサーはシステムの他の部分で期待されるセキュリティ保証を提供していますか？さらに、誰がキーにアクセスできるかを検討することが重要です。キーの処理に関するポリシー、およびキーにアクセスできるユーザーは、機密性の目標とともに検討する必要があります。
As can be seen, the actual confidentiality level has likely more to do with the application's usage of centralized nodes, and the details of the key management solution chosen, than with the actual choice of encryption algorithm (although, of course, the encryption algorithm needs to be chosen appropriately for the desired security level).
見てわかるように、実際の機密性レベルは、暗号化アルゴリズムの実際の選択よりも、アプリケーションの集中型ノードの使用と、選択された鍵管理ソリューションの詳細に関係している可能性が高いです（ただし、暗号化アルゴリズムには、目的のセキュリティレベルに応じて適切に選択されます）。
Protection against modification of content by a third party, or due to errors in the network, is another factor to consider. The first aspect that one assesses is what resilience one has against modifications to the content. Some media types are extremely sensitive to network bit errors, whereas others might be able to tolerate some degree of data corruption. Equally important is to consider the sensitivity of the content, who is providing the integrity assertion, what is the source of the integrity tag, and what are the risks of modifications happening prior to that point where protection is applied. These issues affect what cryptographic algorithm is used, the length of the integrity tags, and whether the entire payload is protected.
第三者による、またはネットワークのエラーによるコンテンツの変更に対する保護は、考慮すべきもう1つの要素です。評価する最初の側面は、コンテンツの変更に対する回復力です。一部のメディアタイプはネットワークビットエラーに非常に敏感ですが、他のメディアタイプはある程度のデータ破損を許容できる場合があります。同様に重要なのは、整合性アサーションを提供しているコンテンツの機密性、整合性タグのソース、および保護が適用されるそのポイントの前に発生する変更のリスクを考慮することです。これらの問題は、使用される暗号化アルゴリズム、整合性タグの長さ、ペイロード全体が保護されているかどうかに影響します。
RTP applications that rely on central nodes need to consider if hop-by-hop integrity is acceptable or if true end-to-end integrity protection is needed. Is it important to be able to tell if a middlebox has modified the data? There are some uses of RTP that require trusted middleboxes that can modify the data in a way that doesn't break integrity protection as seen by the receiver, for example, local advertisement insertion in IPTV systems. There are also uses where it is essential that such in-network modification be detectable. RTP can support both with appropriate choices of security mechanisms.
中央ノードに依存するRTPアプリケーションは、ホップバイホップの整合性が受け入れられるかどうか、または真のエンドツーエンドの整合性保護が必要かどうかを考慮する必要があります。ミドルボックスがデータを変更したかどうかを確認できることが重要ですか？ IPTVシステムでのローカルアドバタイズメントの挿入など、受信者から見た整合性保護を壊さない方法でデータを変更できる信頼できるミドルボックスを必要とするRTPの使用法がいくつかあります。そのようなネットワーク内の変更が検出可能であることが不可欠である用途もあります。 RTPは、セキュリティメカニズムを適切に選択することで、両方をサポートできます。
Integrity of the data is commonly closely tied to the question of source authentication. That is, it becomes important to know who makes an integrity assertion for the data.
データの整合性は、通常、ソース認証の問題と密接に関連しています。つまり、誰がデータの整合性を主張するかを知ることが重要になります。
Source authentication is about determining who sent a particular RTP or RTCP packet. It is normally closely tied with integrity, since a receiver generally also wants to ensure that the data received is what the source really sent, so source authentication without integrity is not particularly useful. Similarly, integrity protection without source authentication is also not particularly useful; a claim that a packet is unchanged that cannot itself be validated as from the source (or some from other known and trusted party) is meaningless.
ソース認証とは、特定のRTPまたはRTCPパケットをだれが送信したかを判別することです。受信者は通常、受信したデータがソースが実際に送信したものであることを確認する必要があるため、通常は完全性と密接に関連しています。したがって、完全性のないソース認証は特に有用ではありません。同様に、ソース認証なしの整合性保護も特に有用ではありません。送信元（または他の既知の信頼できるパーティからのパケット）としてそれ自体を検証できないパケットが変更されていないという主張は無意味です。
Source authentication can be asserted in several different ways:
ソース認証は、いくつかの異なる方法でアサートできます。
Base level: Using cryptographic mechanisms that give authentication with some type of key management provide an implicit method for source authentication. Assuming that the mechanism has sufficient strength not to be circumvented in the time frame when you would accept the packet as valid, it is possible to assert a source-authenticated statement; this message is likely from a source that has the cryptographic key(s) to this communication.
基本レベル：あるタイプの鍵管理で認証を提供する暗号化メカニズムを使用すると、ソース認証に暗黙的な方法が提供されます。メカニズムが、パケットを有効として受け入れる時間枠内で回避されない十分な強度があると仮定すると、送信元認証ステートメントをアサートすることが可能です。このメッセージは、この通信に対する暗号化キーを持つソースから送信された可能性があります。
What that assertion actually means is highly dependent on the application and how it handles the keys. If only the two peers have access to the keys, this can form a basis for a strong trust relationship that traffic is authenticated coming from one of the peers. However, in a multiparty scenario where security contexts are shared among participants, most base-level authentication solutions can't even assert that this packet is from the same source as the previous packet.
このアサーションが実際に意味することは、アプリケーションとそれがキーを処理する方法に大きく依存します。 2つのピアのみがキーにアクセスできる場合、これは、ピアの1つからのトラフィックが認証されるという強力な信頼関係の基礎を形成できます。ただし、セキュリティコンテキストが参加者間で共有されるマルチパーティシナリオでは、ほとんどの基本レベルの認証ソリューションは、このパケットが前のパケットと同じソースからのものであると断言することもできません。
Binding the source and the signaling: A step up in the assertion that can be done in base-level systems is to tie the signaling to the key exchange. Here, the goal is to at least be able to assert that the source of the packets is the same entity with which the receiver established the session. How feasible this is depends on the properties of the key management system, the ability to tie the signaling to a particular source, and the degree of trust the receiver places on the different nodes involved.
ソースとシグナリングのバインド：基本レベルのシステムで実行できるアサーションのステップアップは、シグナリングを鍵交換に関連付けることです。ここでの目標は、少なくともパケットのソースが、受信者がセッションを確立したのと同じエンティティであることをアサートできるようにすることです。これがどの程度実現可能かは、鍵管理システムの特性、シグナリングを特定のソースに結び付ける能力、および受信者が関与するさまざまなノードに与える信頼度によって異なります。
For example, systems where the key exchange is done using the signaling systems, such as security descriptions [RFC4568] enable a direct binding between signaling and key exchange. In such systems, the actual security depends on the trust one can place in the signaling system to correctly associate the peer's identifier with the key exchange.
たとえば、セキュリティ記述[RFC4568]などのシグナリングシステムを使用してキー交換が行われるシステムでは、シグナリングとキー交換を直接バインドできます。このようなシステムでは、実際のセキュリティは、ピアの識別子をキー交換に正しく関連付けるためにシグナリングシステムに設定できる信頼に依存します。
Using identifiers: If the applications have access to a system that can provide verifiable identifiers, then the source authentication can be bound to that identifier. For example, in a point-to-point communication, even symmetric key crypto, where the key management can assert that the key has only been exchanged with a particular identifier, can provide a strong assertion about the source of the traffic. SIP Identity [RFC4474] provides one example of how this can be done and could be used to bind DTLS-SRTP certificates used by an endpoint to the identity provider's public key to authenticate the source of a DTLS-SRTP flow.
識別子の使用：アプリケーションが検証可能な識別子を提供できるシステムにアクセスできる場合、ソース認証をその識別子にバインドできます。たとえば、ポイントツーポイント通信では、キー管理が特定の識別子とのみ交換されたことをキー管理がアサートできる対称キー暗号でも、トラフィックのソースに関する強力なアサーションを提供できます。 SIP Identity [RFC4474]は、これを行う方法の一例を提供し、エンドポイントが使用するDTLS-SRTP証明書をIDプロバイダーの公開鍵にバインドして、DTLS-SRTPフローのソースを認証するために使用できます。
Note that all levels of the system need to have matching capability to assert identifiers. If the signaling can assert that only a given entity in a multiparty session has a key, then the media layer might be able to provide guarantees about the identifier used by the media sender. However, using a signaling authentication mechanism built on a group key can limit the media layer to asserting only group membership.
システムのすべてのレベルには、識別子をアサートするための一致機能が必要であることに注意してください。マルチパーティセッションの特定のエンティティにのみキーがあることをシグナリングがアサートできる場合、メディアレイヤーは、メディア送信者が使用する識別子について保証を提供できる可能性があります。ただし、グループキーに基づいて構築されたシグナリング認証メカニズムを使用すると、メディアレイヤーがグループメンバーシップのみをアサートするように制限できます。
There exist many different types of systems providing identifiers with different properties (e.g., SIP Identity [RFC4474]). In the context of RTP applications, the most important property is the possibility to perform source authentication and verify such assertions in relation to any claimed identifiers. What an identifier really represents can also vary but, in the context of communication, one of the most obvious is the identifiers representing the identity of the human user with which one communicates. However, the human user can also have additional identifiers in a particular role. For example, the human (Alice) can also be a police officer, and in some cases, an identifier for her role as police officer will be more relevant than one that asserts that she is Alice. This is common in contact with organizations, where it is important to prove the person's right to represent the organization. Some examples of identifier/identity mechanisms that can be used:
さまざまなプロパティ（SIP Identity [RFC4474]など）を持つ識別子を提供するシステムには、さまざまな種類があります。 RTPアプリケーションのコンテキストでは、最も重要な特性は、ソース認証を実行し、主張された識別子に関連してそのようなアサーションを検証する可能性です。識別子が実際に表すものもさまざまですが、通信のコンテキストでは、最も明白なものの1つは、通信する人間のユーザーのIDを表す識別子です。ただし、人間のユーザーは、特定の役割で追加の識別子を持つこともできます。たとえば、人間（アリス）は警察官になることもでき、場合によっては、警察官としての彼女の役割の識別子は、彼女がアリスであると断言するものよりも関連性が高くなります。これは、組織を代表する個人の権利を証明することが重要である組織との接触において一般的です。使用できるID / IDメカニズムの例：
Certificate based: A certificate is used to assert the identifiers used to claim an identity; by having access to the private part of the certificate, one can perform signing to assert one's identity. Any entity interested in verifying the assertion then needs the public part of the certificate. By having the certificate, one can verify the signature against the certificate. The next step is to determine if one trusts the certificate's trust chain. Commonly, by provisioning the verifier with the public part of a root certificate, this enables the verifier to verify a trust chain from the root certificate down to the identifier in the certificate. However, the trust is based on all steps in the certificate chain being verifiable and trusted. Thus, the provisioning of root certificates and the ability to revoke compromised certificates are aspects that will require infrastructure.
証明書ベース：証明書は、アイデンティティを主張するために使用される識別子をアサートするために使用されます。証明書のプライベート部分にアクセスすることにより、署名を実行して自分の身元を主張できます。アサーションの検証に関心のあるエンティティには、証明書の公開部分が必要です。証明書を持つことにより、証明書に対して署名を検証できます。次のステップは、証明書の信頼チェーンを信頼するかどうかを決定することです。一般に、ルート証明書の公開部分で検証をプロビジョニングすることにより、検証はルート証明書から証明書の識別子までの信頼チェーンを検証できます。ただし、信頼は、証明書チェーンのすべてのステップに基づいており、検証可能で信頼されています。したがって、ルート証明書のプロビジョニングと侵害された証明書を取り消す機能は、インフラストラクチャを必要とする側面です。
Online identity providers: An online identity provider (IdP) can authenticate a user's right to use an identifier and then perform assertions on their behalf or provision the requester with short-term credentials to assert the identifiers. The verifier can then contact the IdP to request verification of a particular identifier. Here, the trust is highly dependent on how much one trusts the IdP. The system also becomes dependent on having access to the relevant IdP.
オンラインIDプロバイダー：オンラインIDプロバイダー（IdP）は、ユーザーが識別子を使用する権利を認証し、ユーザーに代わってアサーションを実行するか、識別子をアサートするための短期的な資格情報をリクエスターにプロビジョニングできます。次に、検証者はIdPに連絡して、特定の識別子の検証を要求できます。ここで、信頼は、IdPをどれだけ信頼するかに大きく依存しています。システムは、関連するIdPへのアクセス権にも依存します。
In all of the above examples, an important part of the security properties is related to the method for authenticating the access to the identity.
上記のすべての例で、セキュリティプロパティの重要な部分は、IDへのアクセスを認証する方法に関連しています。
RTP applications need to consider what privacy goals they have. As RTP applications communicate directly between peers in many cases, the IP addresses of any communication peer will be available. The main privacy concern with IP addresses is related to geographical location and the possibility to track a user of an endpoint. The main way to avoid such concerns is the introduction of relay (e.g., a Traversal Using Relay NAT (TURN) server [RFC5766]) or centralized media mixers or forwarders that hide the address of a peer from any other peer. The security and trust placed in these relays obviously needs to be carefully considered.
RTPアプリケーションは、プライバシーの目的を検討する必要があります。多くの場合、RTPアプリケーションはピア間で直接通信するため、通信ピアのIPアドレスを使用できます。 IPアドレスに関するプライバシーの主な問題は、地理的な場所とエンドポイントのユーザーを追跡する可能性に関連しています。このような懸念を回避する主な方法は、他のピアからピアのアドレスを隠すリレー（たとえば、NATを使用したトラバーサル（TURN）サーバー[RFC5766]）または集中型メディアミキサーまたはフォワーダーの導入です。これらのリレーに置かれたセキュリティと信頼は、慎重に検討する必要があります。
RTP itself can contribute to enabling a particular user to be tracked between communication sessions if the Canonical Name (CNAME) is generated according to the RTP specification in the form of user@host. Such RTCP CNAMEs are likely long-term stable over multiple sessions, allowing tracking of users. This can be desirable for long-term fault tracking and diagnosis, but it clearly has privacy implications. Instead, cryptographically random ones could be used as defined by "Guidelines for Choosing RTP Control Protocol (RTCP) CNAMEs" [RFC7022].
RTP仕様に従ってuser @ hostの形式で正規名（CNAME）が生成されている場合、RTP自体が特定のユーザーを通信セッション間で追跡できるようにするのに役立ちます。そのようなRTCP CNAMEは、複数のセッションにわたって長期的に安定している可能性が高く、ユーザーの追跡を可能にします。これは、長期的な障害追跡と診断には望ましい場合がありますが、プライバシーに明らかに影響します。代わりに、「RTP制御プロトコル（RTCP）CNAMEを選択するためのガイドライン」[RFC7022]で定義されているように、暗号的にランダムなものを使用できます。
If privacy goals exist, they need to be considered and the system designed with them in mind. In addition, certain RTP features might have to be configured to safeguard privacy or have requirements on how the implementation is done.
プライバシーの目標が存在する場合、それらを検討し、それらを念頭に置いてシステムを設計する必要があります。また、特定のRTP機能は、プライバシーを保護するために構成する必要がある場合や、実装の方法に関する要件がある場合があります。
When it comes to RTP security, the most appropriate solution is often highly dependent on the topology of the communication session. The signaling also impacts what information can be provided and if this can be instance specific or common for a group. In the end, the key management system will highly affect the security properties achieved by the application. At the same time, the communication structure of the application limits what key management methods are applicable. As different key management methods have different requirements on underlying infrastructure, it is important to take that aspect into consideration early in the design.
RTPセキュリティに関しては、最も適切なソリューションは多くの場合、通信セッションのトポロジに大きく依存します。シグナリングは、提供できる情報、およびインスタンス固有またはグループに共通の情報であるかどうかにも影響します。結局、鍵管理システムは、アプリケーションによって達成されるセキュリティプロパティに大きな影響を与えます。同時に、アプリケーションの通信構造により、適用できる主要な管理方法が制限されます。主要な管理方法が異なると、基盤となるインフラストラクチャに対する要件も異なるため、設計の早い段階でその側面を考慮することが重要です。
The guidelines for Cryptographic Key Management [RFC4107] provide an overview of why automatic key management is important. They also provide a strong recommendation on using automatic key management. Most of the security solutions reviewed in this document provide or support automatic key management, at least to establish session keys. In some more long-term use cases, credentials might need to be manually deployed in certain cases.
暗号鍵管理[RFC4107]のガイドラインは、自動鍵管理が重要である理由の概要を提供します。また、自動キー管理の使用に関する強力な推奨事項も提供します。このドキュメントで説明するセキュリティソリューションのほとんどは、少なくともセッションキーを確立するために、自動キー管理を提供またはサポートしています。さらに長期間の使用例では、資格情報を手動でデプロイする必要がある場合があります。
For SRTP, an important aspect of automatic key management is to ensure that two-time pads do not occur, in particular by preventing multiple endpoints using the same session key and SSRC. In these cases, automatic key management methods can have strong dependencies on signaling features to function correctly. If those dependencies can't be fulfilled, additional constrains on usage, e.g., per-endpoint session keys, might be needed to avoid the issue.
SRTPの場合、自動キー管理の重要な側面は、特に複数のエンドポイントが同じセッションキーとSSRCを使用しないようにすることで、2タイムパッドが発生しないようにすることです。このような場合、自動キー管理方法は、正しく機能するためにシグナリング機能に強く依存することがあります。これらの依存関係を満たせない場合、問題を回避するために、エンドポイントごとのセッションキーなど、使用に関する追加の制約が必要になる場合があります。
When selecting security mechanisms for an RTP application, it is important to consider the properties of the key management. Using key management that is both automatic and integrated will provide minimal interruption for the user and is important to ensure that security can, and will remain, to be on by default.
RTPアプリケーションのセキュリティメカニズムを選択するときは、キー管理の特性を考慮することが重要です。自動と統合の両方のキー管理を使用すると、ユーザーへの影響が最小限に抑えられ、セキュリティをデフォルトでオンにしておくことができるようにすることが重要です。
If the security mechanism only provides a secured tunnel, for example, like some common uses of IPsec (Section 3.3), it is important to consider the full end-to-end properties of the system. How does one ensure that the path from the endpoint to the local tunnel ingress/egress is secure and can be trusted (and similarly for the other end of the tunnel)? How does one handle the source authentication of the peer, as the security protocol identifies the other end of the tunnel? These are some of the issues that arise when one considers a tunnel-based security protocol rather than an end-to-end one. Even with clear requirements and knowledge that one still can achieve the security properties using a tunnel-based solution, one ought to prefer to use end-to-end mechanisms, as they are much less likely to violate any assumptions made about deployment. These assumptions can also be difficult to automatically verify.
たとえば、IPsecの一般的な使用方法（セクション3.3）のように、セキュリティメカニズムがセキュリティで保護されたトンネルのみを提供する場合、システムの完全なエンドツーエンドのプロパティを考慮することが重要です。エンドポイントからローカルトンネルの入口/出口へのパスが安全で信頼できることをどのように保証しますか（トンネルのもう一方の端についても同様です）。セキュリティプロトコルはトンネルのもう一方の端を識別するため、ピアのソース認証をどのように処理しますか？これらは、エンドツーエンドのプロトコルではなく、トンネルベースのセキュリティプロトコルを検討するときに発生する問題の一部です。トンネルベースのソリューションを使用してセキュリティプロパティを引き続き達成できるという明確な要件と知識があっても、エンドツーエンドメカニズムを使用することをお勧めします。これは、導入に関する想定に違反する可能性がはるかに低いためです。これらの仮定は、自動的に検証することも難しい場合があります。
Key management solutions that use plaintext keys, like SDP security descriptions (Section 3.1.3), require care to ensure a secure transport of the signaling messages that contain the plaintext keys. For plaintext keys, the security properties of the system depend on how securely the plaintext keys are protected end-to-end between the sender and receiver(s). Not only does one need to consider what transport protection is provided for the signaling message, including the keys, but also the degree to which any intermediaries in the signaling are trusted. Untrusted intermediaries can perform MITM attacks on the communication or can log the keys, resulting in the encryption being compromised significantly after the actual communication occurred.
SDPセキュリティ記述（セクション3.1.3）のようなプレーンテキストキーを使用するキー管理ソリューションでは、プレーンテキストキーを含むシグナリングメッセージの安全なトランスポートを確保するように注意する必要があります。平文キーの場合、システムのセキュリティプロパティは、送信者と受信者の間で平文キーがエンドツーエンドでどの程度安全に保護されるかに依存します。キーを含むシグナリングメッセージにどのトランスポート保護が提供されているかだけでなく、シグナリングの仲介者が信頼されている度合いも考慮する必要があります。信頼できない仲介者は、通信に対してMITM攻撃を実行したり、キーをログに記録したりする可能性があり、実際の通信が発生した後で暗号化が大幅に侵害されます。
Few RTP applications exist as independent applications that never interoperate with anything else. Rather, they enable communication with a potentially large number of other systems. To minimize the number of security mechanisms that need to be implemented, it is important to consider if one can use the same security mechanisms as other applications. This can also reduce problems with determining what security level is actually negotiated in a particular session.
他のものと相互運用しない独立したアプリケーションとして存在するRTPアプリケーションはほとんどありません。むしろ、潜在的に多数の他のシステムとの通信を可能にします。実装する必要のあるセキュリティメカニズムの数を最小限に抑えるには、他のアプリケーションと同じセキュリティメカニズムを使用できるかどうかを検討することが重要です。これにより、特定のセッションで実際にネゴシエートされるセキュリティレベルの決定に関する問題を減らすこともできます。
The desire to be interoperable can, in some cases, be in conflict with the security requirements of an application. To meet the security goals, it might be necessary to sacrifice interoperability. Alternatively, one can implement multiple security mechanisms; this, however, introduces the complication of ensuring that the user understands what it means to use a particular security system. In addition, the application can then become vulnerable to bid-down attacks.
相互運用可能であるという願望は、場合によっては、アプリケーションのセキュリティ要件と矛盾することがあります。セキュリティ目標を達成するには、相互運用性を犠牲にする必要がある場合があります。あるいは、複数のセキュリティメカニズムを実装することもできます。ただし、これにより、特定のセキュリティシステムを使用することの意味をユーザーが確実に理解できるようにするという複雑さが生じます。さらに、アプリケーションはビッドダウン攻撃に対して脆弱になる可能性があります。
In the following, we describe a number of example security solutions for applications using RTP services or frameworks. These examples are provided to illustrate the choices available. They are not normative recommendations for security.
以下では、RTPサービスまたはフレームワークを使用するアプリケーションのセキュリティソリューションの例をいくつか説明します。これらの例は、利用可能な選択肢を示すために提供されています。これらはセキュリティに関する規範的な推奨事項ではありません。
In 2009, the IETF evaluated media security for RTP sessions established using point-to-point SIP sessions. A number of requirements were determined, and based on those, the existing solutions for media security and especially the keying methods were analyzed. The resulting requirements and analysis were published in [RFC5479]. Based on this analysis and working group discussion, DTLS-SRTP was determined to be the best solution.
2009年、IETFはポイントツーポイントSIPセッションを使用して確立されたRTPセッションのメディアセキュリティを評価しました。いくつかの要件が決定され、それらに基づいて、メディアセキュリティの既存のソリューション、特にキーイング方法が分析されました。結果の要件と分析は[RFC5479]で公開されました。この分析とワーキンググループの議論に基づいて、DTLS-SRTPが最良のソリューションであると判断されました。
The security solution for SIP using DTLS-SRTP is defined in "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)" [RFC5763]. On a high level, the framework uses SIP with SDP offer/answer procedures to exchange the network addresses where the server endpoint will have a DTLS-SRTP-enabled server running. The SIP signaling is also used to exchange the fingerprints of the certificate each endpoint will use in the DTLS establishment process. When the signaling is sufficiently completed, the DTLS-SRTP client performs DTLS handshakes and establishes SRTP session keys. The clients also verify the fingerprints of the certificates to verify that no man in the middle has inserted themselves into the exchange.
DTLS-SRTPを使用したSIPのセキュリティソリューションは、「データグラムトランスポート層セキュリティ（DTLS）を使用したセキュアなリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」[RFC5763]で定義されています。高レベルでは、フレームワークはSIPとSDPオファー/アンサー手順を使用して、サーバーエンドポイントでDTLS-SRTP対応サーバーが実行されるネットワークアドレスを交換します。 SIPシグナリングは、各エンドポイントがDTLS確立プロセスで使用する証明書のフィンガープリントを交換するためにも使用されます。シグナリングが十分に完了すると、DTLS-SRTPクライアントはDTLSハンドシェイクを実行し、SRTPセッションキーを確立します。クライアントはまた、証明書のフィンガープリントを検証して、途中の男が自分自身を取引所に挿入していないことを検証します。
DTLS has a number of good security properties. For example, to enable a MITM, someone in the signaling path needs to perform an active action and modify both the signaling message and the DTLS handshake. Solutions also exist that enable the fingerprints to be bound to identities. SIP Identity provides an identity established by the first proxy for each user [RFC4474]. This reduces the number of nodes the connecting User Agent has to trust to include just the first-hop proxy rather than the full signaling path. The biggest security weakness of this system is its dependency on the signaling. SIP signaling passes multiple nodes and there is usually no message security deployed, only hop-by-hop transport security, if any, between the nodes.
DTLSには多くの優れたセキュリティプロパティがあります。たとえば、MITMを有効にするには、シグナリングパスの誰かがアクティブなアクションを実行し、シグナリングメッセージとDTLSハンドシェイクの両方を変更する必要があります。指紋をアイデンティティにバインドできるようにするソリューションも存在します。 SIP IDは、各ユーザーの最初のプロキシによって確立されたIDを提供します[RFC4474]。これにより、接続しているユーザーエージェントが信頼する必要があるノードの数が減り、完全な信号パスではなく、最初のホップのプロキシだけが含まれるようになります。このシステムの最大のセキュリティ上の弱点は、シグナリングへの依存です。 SIPシグナリングは複数のノードを通過し、通常、メッセージセキュリティは展開されず、ノード間のホップバイホップトランスポートセキュリティ（存在する場合）のみが展開されます。
Web Real-Time Communication (WebRTC) [WebRTC] is a solution providing JavaScript web applications with real-time media directly between browsers. Media is transported using RTP and protected using a mandatory application of SRTP [RFC3711], with keying done using DTLS-SRTP [RFC5764]. The security configuration is further defined in "WebRTC Security Architecture" [WebRTC-SEC].
Webリアルタイム通信（WebRTC）[WebRTC]は、ブラウザ間で直接リアルタイムメディアを使用してJavaScript Webアプリケーションを提供するソリューションです。メディアは、RTPを使用してトランスポートされ、SRTP [RFC3711]の必須アプリケーションを使用して保護され、DTLS-SRTP [RFC5764]を使用してキーイングが行われます。セキュリティ構成は、「WebRTCセキュリティアーキテクチャ」[WebRTC-SEC]でさらに定義されています。
A hash of the peer's certificate is provided to the JavaScript web application, allowing that web application to verify identity of the peer. There are several ways in which the certificate hashes can be verified. An approach identified in the WebRTC security architecture [WebRTC-SEC] is to use an identity provider. In this solution, the identity provider, which is a third party to the web application, signs the DTLS-SRTP hash combined with a statement on the validity of the user identity that has been used to sign the hash. The receiver of such an identity assertion can then independently verify the user identity to ensure that it is the identity that the receiver intended to communicate with, and that the cryptographic assertion holds; this way, a user can be certain that the application also can't perform a MITM and acquire the keys to the media communication. Other ways of verifying the certificate hashes exist; for example, they could be verified against a hash carried in some out-of-band channel (e.g., compare with a hash printed on a business card) or using a verbal short authentication string (e.g., as in ZRTP [RFC6189]) or using hash continuity.
ピアの証明書のハッシュがJavaScript Webアプリケーションに提供され、そのWebアプリケーションがピアのIDを確認できるようになります。証明書のハッシュを確認する方法はいくつかあります。 WebRTCセキュリティアーキテクチャ[WebRTC-SEC]で特定されているアプローチは、IDプロバイダーを使用することです。このソリューションでは、WebアプリケーションのサードパーティであるIDプロバイダーが、DTLS-SRTPハッシュと、そのハッシュの署名に使用されたユーザーIDの有効性に関するステートメントを組み合わせて署名します。このようなIDアサーションの受信者は、ユーザーIDを独自に検証して、受信者が通信することを意図したIDであること、および暗号化アサーションが保持することを確認できます。このようにして、ユーザーはアプリケーションがMITMを実行してメディア通信のキーを取得できないことを確認できます。証明書ハッシュを確認する他の方法があります。たとえば、帯域外チャネルで運ばれるハッシュ（たとえば、名刺に印刷されたハッシュと比較）、または口頭で短い認証文字列（ZRTP [RFC6189]など）を使用して検証できます。ハッシュ連続性を使用します。
In the development of WebRTC, there has also been attention given to privacy considerations. The main RTP-related concerns that have been raised are:
WebRTCの開発では、プライバシーに関する考慮事項にも注意が払われています。提起されたRTP関連の主な懸念事項は次のとおりです。
Location disclosure: As Interactive Connectivity Establishment (ICE) negotiation [RFC5245] provides IP addresses and ports for the browser, this leaks location information in the signaling to the peer. To prevent this, one can block the usage of any ICE candidate that isn't a relay candidate, i.e., where the IP and port provided belong to the service providers media traffic relay.
場所の開示：Interactive Connectivity Establishment（ICE）ネゴシエーション[RFC5245]がブラウザーにIPアドレスとポートを提供するため、これはシグナリングの位置情報をピアに漏らします。これを防ぐには、リレー候補ではないICE候補の使用をブロックします。つまり、提供されたIPとポートがサービスプロバイダーのメディアトラフィックリレーに属している場合です。
Prevent tracking between sessions: Static RTP CNAMEs and DTLS-SRTP certificates provide information that is reused between session instances. Thus, to prevent tracking, such information ought not be reused between sessions, or the information ought not be sent in the clear. Note that generating new certificates each time prevents continuity in authentication, however, as WebRTC users are expected to use multiple devices to access the same communication service, such continuity can't be expected anyway; instead, the above-described identity mechanism has to be relied on.
セッション間の追跡を防止：静的RTP CNAMEとDTLS-SRTP証明書は、セッションインスタンス間で再利用される情報を提供します。したがって、追跡を防止するために、そのような情報はセッション間で再利用してはならず、情報は平文で送信されるべきではありません。毎回新しい証明書を生成すると、認証の継続性が妨げられることに注意してください。ただし、WebRTCユーザーは複数のデバイスを使用して同じ通信サービスにアクセスすることが想定されているため、このような継続性は期待できません。代わりに、上記のIDメカニズムに依存する必要があります。
Note: The above cases are focused on providing privacy from other parties, not on providing privacy from the web server that provides the WebRTC JavaScript application.
注：上記のケースは、WebRTC JavaScriptアプリケーションを提供するWebサーバーからのプライバシーの提供ではなく、他の当事者からのプライバシーの提供に焦点を当てています。
In IMS, the core network is controlled by a single operator or by several operators with high trust in each other. Except for some types of accesses, the operator is in full control, and no packages are routed over the Internet. Nodes in the core network offer services such as voice mail, interworking with legacy systems (Public Switched Telephone Network (PSTN), Global System for Mobile Communications (GSM), and 3G), and transcoding. Endpoints are authenticated during the SIP registration using either IMS and Authentication and Key Agreement (AKA) (using Subscriber Identity Module (SIM) credentials) or SIP Digest (using a password).
IMSでは、コアネットワークは、単一のオペレーターまたは相互に高い信頼を持つ複数のオペレーターによって制御されます。一部のタイプのアクセスを除いて、オペレーターは完全に制御され、パッケージはインターネット経由でルーティングされません。コアネットワークのノードは、ボイスメール、レガシーシステムとのインターワーキング（公衆交換電話網（PSTN）、グローバルシステムフォーモバイルコミュニケーション（GSM）、3G）、トランスコーディングなどのサービスを提供します。エンドポイントは、IMSおよび認証および鍵合意（AKA）（Subscriber Identity Module（SIM）資格情報を使用）またはSIPダイジェスト（パスワードを使用）を使用して、SIP登録中に認証されます。
In IMS media security [T3GPP.33.328], end-to-end encryption is, therefore, not seen as needed or desired as it would hinder, for example, interworking and transcoding, making calls between incompatible terminals impossible. Because of this, IMS media security mostly uses end-to-access-edge security where SRTP is terminated in the first node in the core network. As the SIP signaling is trusted and encrypted (with TLS or IPsec), security descriptions [RFC4568] is considered to give good protection against eavesdropping over the accesses that are not already encrypted (GSM, 3G, and Long Term Evolution (LTE)). Media source authentication is based on knowledge of the SRTP session key and trust in that the IMS network will only forward media from the correct endpoint.
したがって、IMSメディアセキュリティ[T3GPP.33.328]では、エンドツーエンドの暗号化は、たとえばインターワーキングやトランスコーディングを妨げ、互換性のない端末間のコールを不可能にするため、必要または望ましいとは見なされません。このため、IMSメディアセキュリティは主に、SRTPがコアネットワークの最初のノードで終端されるエンドツーアクセスエッジセキュリティを使用します。 SIPシグナリングは信頼され暗号化されているため（TLSまたはIPsecを使用）、セキュリティの説明[RFC4568]は、まだ暗号化されていないアクセス（GSM、3G、およびLong Term Evolution（LTE））を盗聴から十分に保護すると考えられています。メディアソース認証は、SRTPセッションキーの知識と、IMSネットワークが正しいエンドポイントからのみメディアを転送するという信頼に基づいています。
For enterprises and government agencies, which might have weaker trust in the IMS core network and can be assumed to have compatible terminals, end-to-end security can be achieved by deploying their own key management server.
IMSコアネットワークへの信頼が弱く、互換性のある端末があると想定できる企業や政府機関の場合、独自のキー管理サーバーを展開することで、エンドツーエンドのセキュリティを実現できます。
Work on interworking with WebRTC is currently ongoing; the security will still be end-to-access-edge but using DTLS-SRTP [RFC5763] instead of security descriptions.
WebRTCとの相互作用に関する作業は現在進行中です。セキュリティはエンドツーアクセスエッジのままですが、セキュリティの説明の代わりにDTLS-SRTP [RFC5763]を使用します。
The 3GPP Release 11 PSS specification of the Packet-switched Streaming Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of security mechanisms. These security mechanisms are concerned with protecting the content from being copied, i.e., Digital Rights Management (DRM). To meet these goals with the specified solution, the client implementation and the application platform are trusted to protect against access and modification by an attacker.
パケット交換ストリーミングサービス（PSS）の3GPPリリース11 PSS仕様[T3GPP.26.234R11]は、Annex Rで一連のセキュリティメカニズムを定義しています。これらのセキュリティメカニズムは、コンテンツがコピーされないように保護すること、つまりデジタル著作権管理（DRM）に関係しています。指定されたソリューションでこれらの目標を達成するために、クライアントの実装とアプリケーションプラットフォームは、攻撃者によるアクセスと変更から保護することが信頼されています。
PSS is media controlled by RTSP 1.0 [RFC2326] streaming over RTP. Thus, an RTSP client whose user wants to access a protected content will request a session description (SDP [RFC4566]) for the protected content. This SDP will indicate that the media is protected by ISMACryp 2.0 [ISMACryp2] encoding application units (AUs). The key(s) used to protect the media is provided in one of two ways. If a single key is used, then the client uses some DRM system to retrieve the key as indicated in the SDP. Commonly, OMA DRM v2 [OMADRMv2] will be used to retrieve the key. If multiple keys are to
PSSは、RTPを介したRTSP 1.0 [RFC2326]ストリーミングによって制御されるメディアです。したがって、ユーザーが保護されたコンテンツにアクセスしたいRTSPクライアントは、保護されたコンテンツのセッション記述（SDP [RFC4566]）を要求します。このSDPは、メディアがISMACryp 2.0 [ISMACryp2]エンコードアプリケーションユニット（AU）によって保護されていることを示します。メディアの保護に使用されるキーは、2つの方法のいずれかで提供されます。単一のキーが使用されている場合、クライアントはDRMシステムを使用して、SDPに示されているキーを取得します。通常、OMA DRM v2 [OMADRMv2]を使用してキーを取得します。複数のキーが
be used, then an additional RTSP stream for key updates in parallel with the media streams is established, where key updates are sent to the client using Short Term Key Messages defined in the "Service and Content Protection for Mobile Broadcast Services" part [OMASCP] of the OMA Mobile Broadcast Services [OMABCAST].
メディアストリームと並行してキーを更新するための追加のRTSPストリームが確立され、「モバイルブロードキャストサービスのサービスとコンテンツの保護」の部分で定義されている短期キーメッセージを使用してキーの更新がクライアントに送信されます[OMASCP] OMA Mobile Broadcast Services [OMABCAST]の概要。
Worth noting is that this solution doesn't provide any integrity verification method for the RTP header and payload header information; only the encoded media AU is protected. 3GPP has not defined any requirement for supporting any solution that could provide that service. Thus, replay or insertion attacks are possible. Another property is that the media content can be protected by the ones providing the media, so that the operators of the RTSP server have no access to unprotected content. Instead, all that want to access the media are supposed to contact the DRM keying server, and if the device is acceptable, they will be given the key to decrypt the media.
注目に値するのは、このソリューションはRTPヘッダーとペイロードヘッダー情報の整合性検証方法を提供しないことです。エンコードされたメディアAUのみが保護されます。 3GPPは、そのサービスを提供できるソリューションをサポートするための要件を定義していません。したがって、リプレイまたは挿入攻撃が可能です。別の特性は、メディアを提供するコンテンツによってメディアコンテンツを保護できるため、RTSPサーバーのオペレーターが保護されていないコンテンツにアクセスできないことです。代わりに、メディアにアクセスするすべてのユーザーがDRMキーイングサーバーに接続することになっています。デバイスが受け入れ可能であれば、メディアを復号化するためのキーが与えられます。
To protect the signaling, RTSP 1.0 supports the usage of TLS. This is, however, not explicitly discussed in the PSS specification. Usage of TLS can prevent both modification of the session description information and help maintain some privacy of what content the user is watching as all URLs would then be confidentiality protected.
シグナリングを保護するために、RTSP 1.0はTLSの使用をサポートしています。ただし、これは、PSS仕様では明示的に説明されていません。 TLSを使用すると、セッションの説明情報の変更が防止され、すべてのURLの機密性が保護されるため、ユーザーが見ているコンテンツのプライバシーを維持できます。
The Real-time Streaming Protocol 2.0 [RTSP] offers an interesting comparison to the PSS service (Section 5.4) that is based on RTSP 1.0 and service requirements perceived by mobile operators. A major difference between RTSP 1.0 and RTSP 2.0 is that 2.0 is fully defined under the requirement to have a mandatory-to-implement security mechanism. As it specifies one transport media over RTP, it is also defining security mechanisms for the RTP-transported media streams.
Real-time Streaming Protocol 2.0 [RTSP]は、RTSP 1.0に基づくPSSサービス（セクション5.4）と、携帯電話事業者が認識するサービス要件との興味深い比較を提供します。 RTSP 1.0とRTSP 2.0の主な違いは、2.0は、必須から実装へのセキュリティメカニズムを持つという要件の下で完全に定義されていることです。 RTPを介した1つのトランスポートメディアを指定するため、RTPで転送されるメディアストリームのセキュリティメカニズムも定義しています。
The security goal for RTP in RTSP 2.0 is to ensure that there is confidentiality, integrity, and source authentication between the RTSP server and the client. This to prevent eavesdropping on what the user is watching for privacy reasons and to prevent replay or injection attacks on the media stream. To reach these goals, the signaling also has to be protected, requiring the use of TLS between the client and server.
RTSP 2.0のRTPのセキュリティ目標は、RTSPサーバーとクライアントの間に機密性、整合性、およびソース認証があることを確認することです。これは、プライバシー上の理由でユーザーが見ているものの盗聴を防ぎ、メディアストリームへのリプレイまたはインジェクション攻撃を防ぐためです。これらの目標を達成するには、シグナリングも保護する必要があり、クライアントとサーバー間でTLSを使用する必要があります。
Using TLS-protected signaling, the client and server agree on the media transport method when doing the SETUP request and response. The secured media transport is SRTP (SAVP/RTP) normally over UDP. The key management for SRTP is MIKEY using RSA-R mode. The RSA-R mode is selected as it allows the RTSP server to select the key despite having the RTSP client initiate the MIKEY exchange. It also enables the reuse of the RTSP server's TLS certificate when creating the MIKEY messages, thus ensuring a binding between the RTSP server and the key exchange. Assuming the SETUP process works, this will establish a SRTP crypto context to be used between the RTSP server and the client for the RTP-transported media streams.
TLSで保護されたシグナリングを使用して、クライアントとサーバーは、SETUP要求と応答を行うときに、メディア転送方法について合意します。保護されたメディアトランスポートは、通常UDPを介したSRTP（SAVP / RTP）です。 SRTPのキー管理は、RSA-Rモードを使用するMIKEYです。 RTSPクライアントがMIKEY交換を開始しても、RTSPサーバーがキーを選択できるため、RSA-Rモードが選択されています。また、MIKEYメッセージの作成時にRTSPサーバーのTLS証明書を再利用できるため、RTSPサーバーとキー交換の間のバインディングが保証されます。 SETUPプロセスが機能すると想定すると、RTSPサーバーとクライアント間でRTPトランスポートされたメディアストリームに使用されるSRTP暗号コンテキストが確立されます。
This entire document is about security. Please read it.
このドキュメント全体はセキュリティに関するものです。読んでください。
We thank the IESG for their careful review of [RFC7202], which led to the writing of this memo. John Mattsson has contributed the IMS Media Security example (Section 5.3).
このメモの執筆につながった[RFC7202]を注意深くレビューしてくれたIESGに感謝します。 John Mattssonは、IMS Media Securityの例（セクション5.3）に貢献しています。
The authors wish to thank Christian Correll, Dan Wing, Kevin Gross, Alan Johnston, Michael Peck, Ole Jacobsen, Spencer Dawkins, Stephen Farrell, John Mattsson, and Suresh Krishnan for their reviews and proposals for improvements to the text.
著者は、テキストの改善に対するレビューと提案について、Christian Correll、Dan Wing、Kevin Gross、Alan Johnston、Michael Peck、Ole Jacobsen、Spencer Dawkins、Stephen Farrell、John Mattsson、およびSuresh Krishnanに感謝します。
[AES-GCM] McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", Work in Progress, September 2013.
[AES-GCM] McGrew、D.およびK. Igoe、「Secure RTP（SRTP）におけるAES-GCMおよびAES-CCM Authenticated Encryption」、作業中、2013年9月。
[ARIA-SRTP] Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)", Work in Progress, November 2013.
[ARIA-SRTP] Kim、W.、Lee、J.、Kim、D.、Park、J.、and D. Kwon、 "ARIA Algorithm and its Use with the Secure Real-time Transport Protocol（SRTP）"、作業中、2013年11月。
[EKT] McGrew, D. and D. Wing, "Encrypted Key Transport for Secure RTP", Work in Progress, February 2014.
[EKT] McGrew、D。およびD. Wing、「Secure RTPの暗号化されたキートランスポート」、進行中の作業、2014年2月。
[ISMACryp2] Internet Streaming Media Alliance (ISMA), "ISMA Encryption and Authentication Version 2.0", November 2007, <http://www.oipf.tv/images/site/DOCS/mpegif/ISMA/ isma_easpec2.0.pdf>.
[ISMACryp2]インターネットストリーミングメディアアライアンス（ISMA）、「ISMA暗号化および認証バージョン2.0」、2007年11月、<http://www.oipf.tv/images/site/DOCS/mpegif/ISMA/ isma_easpec2.0.pdf> 。
[OMABCAST] Open Mobile Alliance, "Mobile Broadcast Services Version 1.0", February 2009, <http://technical.openmobilealliance.org/Technical/ release_program/bcast_v1_0.aspx>.
[OMABCAST] Open Mobile Alliance、「Mobile Broadcast Services Version 1.0」、2009年2月、<http://technical.openmobilealliance.org/Technical/ release_program / bcast_v1_0.aspx>。
[OMADRMv2] Open Mobile Alliance, "OMA Digital Rights Management V2.0", July 2008, <http://technical.openmobilealliance.org/ Technical/release_program/drm_v2_0.aspx>.
[OMADRMv2] Open Mobile Alliance、「OMA Digital Rights Management V2.0」、2008年7月、<http://technical.openmobilealliance.org/ Technical / release_program / drm_v2_0.aspx>。
[OMASCP] Open Mobile Alliance, "Service and Content Protection for Mobile Broadcast Services", January 2013, <http://technical.openmobilealliance.org/Technical/ release_program/docs/BCAST/V1_0_1-20130109-A/ OMA-TS-BCAST_SvcCntProtection-V1_0_1-20130109-A.pdf>.
[OMASCP] Open Mobile Alliance、「Service and Content Protection for Mobile Broadcast Services」、2013年1月、<http://technical.openmobilealliance.org/Technical/ release_program / docs / BCAST / V1_0_1-20130109-A / OMA-TS- BCAST_SvcCntProtection-V1_0_1-20130109-A.pdf>。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365] Schiller、J。、「Strong Security Requirements for Internet Engineering Task Force Standard Protocols」、BCP 61、RFC 3365、2002年8月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and P. Gentric, "RTP Payload Format for Transport of MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3640] van der Meer、J.、Mackie、D.、Swaminathan、V.、Singer、D。、およびP. Gentric、「MPEG-4 Elementary Streamsのトランスポート用のRTPペイロードフォーマット」、RFC 3640、2003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「MIKEY：Multimedia Internet KEYing」、RFC 3830、2004年8月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[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, February 2006.
[RFC4383]バウアー、M。、およびE.カララ、「Secure Real-time Transport Protocol（SRTP）での時間指定された効率的なストリームのロストレラント認証（TESLA）の使用」、RFC 4383、2006年2月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567] Arkko、J.、Lindholm、F.、Naslund、M.、Norrman、K.、and E. Carrara、 "Key Management Extensions for Session Description Protocol（SDP）and Real Time Streaming Protocol（RTSP）"、RFC 4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「メディアストリームのセッション記述プロトコル（SDP）セキュリティ記述」、RFC 4568、2006年7月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571] Lazzaro、J。、「接続指向のトランスポートを介したフレーミングリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケット」、RFC 4571、2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572] Lennox、J。、「Session Description Protocol（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、2006年7月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「ソース固有のIPマルチキャスト」、RFC 4607、2006年8月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650]オイヒナーM.、「マルチメディアインターネットキーイング（MIKEY）のHMAC認証済みDiffie-Hellman」、RFC 4650、2006年9月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738] Ignjatic、D.、Dondeti、L.、Audet、F。、およびP. Lin、「MIKEY-RSA-R：マルチメディアインターネットキーイング（MIKEY）でのキー配布の追加モード」、RFC 4738、2006年11月。
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4771] Lehtovirta、V.、Naslund、M。、およびK. Norrman、「Integrity Transform Carrying Roll-over Counter for the Secure Real-time Transport Protocol（SRTP）」、RFC 4771、2007年1月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 5117、2008年1月。
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008.
[RFC5197] Fries、S。およびD. Ignjatic、「さまざまなマルチメディアインターネットキーイング（MIKEY）モードと拡張機能の適用性について」、RFC 5197、2008年6月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479] Wing、D.、Fries、S.、Tschofenig、H。、およびF. Audet、「要件とメディアセキュリティ管理プロトコルの分析」、RFC 5479、2009年4月。
[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)", RFC 5669, August 2010.
[RFC5669] Yoon、S.、Kim、J.、Park、H.、Jeong、H。、およびY. Won、「SEED暗号アルゴリズムとセキュアリアルタイムトランスポートプロトコル（SRTP）でのその使用」、RFC 5669、2010年8月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760] Ott、J.、Chesterfield、J。、およびE. Schooler、「ユニキャストフィードバック付きの単一ソースマルチキャストセッション用のRTP制御プロトコル（RTCP）拡張」、RFC 5760、2010年2月。
[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, May 2010.
[RFC5763] Fischl、J.、Tschofenig、H。、およびE. Rescorla、「Datagram Transport Layer Security（DTLS）を使用したセキュアなリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、2010年5月。
[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, May 2010.
[RFC5764] McGrew、D。およびE. Rescorla、「Secure Real-time Transport Protocol（SRTP）のキーを確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張」、RFC 5764、2010年5月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy、R.、Matthews、P.、J。Rosenberg、「NAT周辺のリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、2010年4月。
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.
[RFC6043] Mattsson、J。およびT. Tian、「MIKEY-TICKET：チケットベースモードのマルチメディアインターネットキーイング（MIKEY）でのキー配布」、RFC 6043、2011年3月。
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, March 2011.
[RFC6188] McGrew、D。、「Secure RTPでのAES-192およびAES-256の使用」、RFC 6188、2011年3月。
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, April 2011.
[RFC6189] Zimmermann、P.、Johnston、A。、およびJ. Callas、「ZRTP：Media Path Key Agreement for Unicast Secure RTP」、RFC 6189、2011年4月。
[RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6267, June 2011.
[RFC6267] Cakulev、V。およびG. Sundaram、「MIKEY-IBAKE：Identity-Based Authenticated Key Exchange（IBAKE）Mode of Key Distribution in Multimedia Internet KEYing（MIKEY）」、RFC 6267、2011年6月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)", RFC 6509, February 2012.
[RFC6509] Groves、M。、「MIKEY-SAKKE：Sakai-Kasahara Key Encryption in Multimedia Internet KEYing（MIKEY）」、RFC 6509、2012年2月。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[RFC6562]パーキンス、C。およびJM。 Valin、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」、RFC 6562、2012年3月。
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, April 2013.
[RFC6904] Lennox、J。、「Secure Real-time Transport Protocol（SRTP）のヘッダー拡張の暗号化」、RFC 6904、2013年4月。
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, September 2013.
[RFC7022] Begen、A.、Perkins、C.、Wing、D。、およびE. Rescorla、「RTP制御プロトコル（RTCP）正規名（CNAME）を選択するためのガイドライン」、RFC 7022、2013年9月。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, April 2014.
[RFC7202] Perkins、C。およびM. Westerlund、「Secure the RTP Protocol Framework：Why RTP does not mandate a single Media Security Solution」、RFC 7202、2014年4月。
[RTSP] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", Work in Progress, February 2014.
[RTSP] Schulzrinne、H.、Rao、A.、Lanphier、R.、Westerlund、M。、およびM. Stiemerling、「Real Time Streaming Protocol 2.0（RTSP）」、Work in Progress、2014年2月。
[T3GPP.26.234R11] 3GPP, "Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs", 3GPP TS 26.234 11.1.0, September 2012, <http://www.3gpp.org/DynaReport/26234.htm>.
[T3GPP.26.234R11] 3GPP、「技術仕様グループサービスとシステムの側面、透過的なエンドツーエンドのパケット交換ストリーミングサービス（PSS）;プロトコルとコーデック」、3GPP TS 26.234 11.1.0、2012年9月、<http： //www.3gpp.org/DynaReport/26234.htm>。
[T3GPP.26.234R8] 3GPP, "Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs", 3GPP TS 26.234 8.4.0, September 2009, <http://www.3gpp.org/DynaReport/26234.htm>.
[T3GPP.26.234R8] 3GPP、「技術仕様グループサービスとシステムの側面、透過的なエンドツーエンドのパケット交換ストリーミングサービス（PSS）;プロトコルとコーデック」、3GPP TS 26.234 8.4.0、2009年9月、<http： //www.3gpp.org/DynaReport/26234.htm>。
[T3GPP.26.346] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013, <http://www.3gpp.org/DynaReport/26346.htm>.
[T3GPP.26.346] 3GPP、「マルチメディアブロードキャスト/マルチキャストサービス（MBMS）;プロトコルとコーデック」、3GPP TS 26.346 10.7.0、2013年3月、<http://www.3gpp.org/DynaReport/26346.htm>。
[T3GPP.33.246] 3GPP, "3G Security; Security of Multimedia Broadcast/ Multicast Service (MBMS)", 3GPP TS 33.246 11.1.0, December 2012, <http://www.3gpp.org/DynaReport/33246.htm>.
[T3GPP.33.246] 3GPP、「3G Security; Security of Multimedia Broadcast / Multicast Service（MBMS）」、3GPP TS 33.246 11.1.0、2012年12月、<http://www.3gpp.org/DynaReport/33246.htm> 。
[T3GPP.33.328] 3GPP, "IP Multimedia Subsystem (IMS) media plane security", 3GPP TS 33.328 12.1.0, December 2012, <http://www.3gpp.org/DynaReport/33328.htm>.
[T3GPP.33.328] 3GPP、「IPマルチメディアサブシステム（IMS）メディアプレーンセキュリティ」、3GPP TS 33.328 12.1.0、2012年12月、<http://www.3gpp.org/DynaReport/33328.htm>。
[WebRTC-SEC] Rescorla, E., "WebRTC Security Architecture", Work in Progress, February 2014.
[WebRTC-SEC] Rescorla、E。、「WebRTC Security Architecture」、Work in Progress、2014年2月。
[WebRTC] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, February 2014.
[WebRTC] Alvestrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、2014年2月。
Authors' Addresses
著者のアドレス
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kistaスウェーデン
Phone: +46 10 714 82 87
EMail: magnus.westerlund@ericsson.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
コリン・パーキンスグラスゴー大学コンピューティングサイエンススクールグラスゴーG12 8QQイギリス
EMail: csp@csperkins.org
URI: http://csperkins.org/