Network Working Group D. Wing, Ed.
Request for Comments: 5479 Cisco
Category: Informational S. Fries
Siemens AG
H. Tschofenig
Nokia Siemens Networks
F. Audet
Nortel
April 2009
Requirements and Analysis of Media Security Management Protocols
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document.
この文書は、SIPシグナリングセキュアRTP（SRTP）メディアのセキュリティコンテキストをネゴシエートするためのプロトコルのための要件を記述する。自然のセキュリティ要件に加えて、この交渉プロトコルは、特定の方法でSIPとうまく相互運用する必要があります。多くの提案が公表されており、これらの提案の概要は、この文書の付録にあります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios and Requirements Considerations . . . . . . . . 7
4.1. Clipping Media before Signaling Answer . . . . . . . . . . 7
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8
4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. PSTN Gateway . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 12
4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 13
4.8. Interworking with Other Signaling Protocols . . . . . . . 14
4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16
5.3. Requirements outside of the Key Management Protocol . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 25
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26
A.1.8. SDP Security Descriptions with SIPS . . . . . . . . . 26
A.1.9. SDP Security Descriptions with S/MIME . . . . . . . . 27
A.1.10. SDP-DH (Expired) . . . . . . . . . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (Expired) . . . . . . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 27
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 28
A.3.3. MIKEYv2 Inband (Expired) . . . . . . . . . . . . . . . 29
A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29
A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29
A.4.2. Clipping Media before SDP Answer . . . . . . . . . . . 31
A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33
A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 35
A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 35
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 39
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 40
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 42
The work on media security started when the Session Initiation Protocol (SIP) was still in its infancy. With the increased SIP deployment and the availability of new SIP extensions and related protocols, the need for end-to-end security was re-evaluated. The procedure of re-evaluating prior protocol work and design decisions is not an uncommon strategy and, to some extent, considered necessary to ensure that the developed protocols indeed meet the previously envisioned needs for the users on the Internet.
セッション開始プロトコル（SIP）はまだ始まったばかりでいたとき、メディアのセキュリティ上の作業が始まりました。増加したSIPの展開と新しいSIP拡張機能や関連プロトコルが利用可能で、エンドツーエンドのセキュリティの必要性が再評価されました。再評価する前に、プロトコルの仕事やデザイン決定の手順は、ある程度、開発されたプロトコルが実際にインターネット上のユーザーのために、以前に想定されるニーズを満たすことを保証するために必要と考え、珍しく戦略ではないと。
This document summarizes media security requirements, i.e., requirements for mechanisms that negotiate security context such as cryptographic keys and parameters for SRTP.
この文書は、SRTPのための暗号鍵とをパラメータとしてセキュリティコンテキストをネゴシエートするための機構、すなわち、要求、メディアセキュリティ要件をまとめたものです。
The organization of this document is as follows: Section 2 introduces terminology, Section 3 describes various attack scenarios against the signaling path and media path, Section 4 provides an overview about possible call scenarios, and Section 5 lists requirements for media security. The main part of the document concludes with the security considerations Section 6, and acknowledgements in Section 7. Appendix A lists and compares available solution proposals. The following Appendix A.4 compares the different approaches regarding their suitability for the SIP signaling scenarios described in Appendix A, while Appendix A.5 provides a comparison regarding security aspects. Appendix B lists non-goals for this document.
次のようにこのドキュメントの組織は次のとおりです。第2章では、用語を紹介し、第3節では、シグナリングパスとメディアパスに対する様々な攻撃シナリオを説明し、第4節では、可能なコールシナリオ、およびメディアのセキュリティについては、セクション5つのリストの要件について概要を説明します。文書の主要部分は、Security Considerations部6、及び第7付録Aリストの確認応答で終了し、利用可能なソリューション提案を比較します。付録A.5セキュリティ側面について比較を提供しながら、以下の付録A.4は、付録Aに記載のSIPシグナリング・シナリオのためのそれらの適合性に関する異なるアプローチを比較します。付録Bには、この文書の非目標を示しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the important qualification that, unless otherwise stated, these terms apply to the design of the media security key management protocol, not its implementation or application.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されるべきで、特に明記しない限り、重要な資格で、これらの用語は、メディアセキュリティ鍵管理プロトコルではなく、その実施またはアプリケーションの設計に適用されます。
Furthermore, the terminology described in SIP [RFC3261] regarding functions and components are used throughout the document.
また、機能およびコンポーネントに関するSIP [RFC3261]に記載された用語は、明細書を通して使用されます。
Additionally, the following items are used in this document:
また、以下の項目は、このドキュメントで使用されています。
AOR (Address-of-Record): A SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user.
AOR（アドレス・オブ・レコード）：ユーザが利用可能かもしれない別のURIにURIをマップすることができ、ロケーションサービスを使用してドメインを指すSIPまたはSIPS URI。典型的には、ロケーションサービスは、登録を介して取り込まれます。 AORはしばしばユーザーの「パブリックアドレス」との考えられています。
SSRC: The 32-bit value that defines the synchronization source, used in RTP. These are generally unique, but collisions can occur.
SSRC：RTPで使用される同期ソースを定義する32ビット値。これらは、一般的にユニークですが、衝突が発生する可能性があります。
two-time pad: The use of the same key and the same keystream to encrypt different data. For SRTP, a two-time pad occurs if two senders are using the same key and the same RTP SSRC value.
2タイムパッド：異なるデータを暗号化するために同じキーを使用すると、同じキーストリーム。 2つの送信者が同一の鍵と同一のRTP SSRC値を使用している場合、SRTPのために、2回のパッドが発生します。
Perfect Forward Secrecy (PFS): The property that disclosure of the long-term secret keying material that is used to derive an agreed ephemeral key does not compromise the secrecy of agreed keys from earlier runs.
完全転送秘密（PFS）：合意された短期キーを導出するために使用される長期秘密鍵情報の開示は、以前の実行から合意された鍵の機密性を損なわない財産。
active adversary: An active adversary is able to alter data communication to affect its operation (see also [RFC4949]).
アクティブ敵：アクティブ敵（また、[RFC4949]を参照）、その動作に影響を与えるためにデータ通信を変えることができます。
passive adversary: A passive adversary is able to learn information from data communication, but not alter that data communication (see also [RFC4949]).
受動的攻撃：受動的攻撃は、データ通信から情報を知るが、そのデータ通信を変更しないことができる（参照[RFC4949]）。
signaling path: The signaling path is the route taken by SIP signaling messages transmitted between the calling and called user agents. This can be either direct signaling between the calling and called user agents or, more commonly, involves the SIP proxy servers that were involved in the call setup.
パスシグナリング：シグナリングパスは、発呼と着呼ユーザエージェントとの間で送信されるメッセージをSIPシグナリングによって取られる経路です。これは、呼び出し元と呼ばれるユーザーエージェントまたは、より一般的に、コールセットアップに関与していたSIPプロキシサーバを必要との間の直接のシグナリングのいずれかになります。
media path: The media path is the route taken by media packets exchanged by the endpoints. In the simplest case, the endpoints exchange media directly, and the "media path" is defined by a quartet of IP addresses and TCP/UDP ports, along with an IP route. In other cases, this path may include RTP relays, mixers, transcoders, session border controllers, NATs, or media gateways.
メディアパス：メディアパスは、エンドポイントによって交換メディアパケットによって取られる経路です。最も単純なケースでは、直接エンドポイント交換媒体、及び「メディアパス」は、IP経路とともに、IPアドレス及びTCP / UDPポートのカルテットによって定義されます。他の例では、このパスはRTPリレー、ミキサー、トランスコーダ、セッションボーダーコントローラ、NATを、またはメディアゲートウェイを含むこともできます。
Moreover, as this document discusses requirements for media security, the nomenclature R-XXX is used to mark requirements, where XXX is the requirement, which needs to be met.
この文書はメディアセキュリティの要件について説明したようにまた、命名R-XXXは、XXXが満たされる必要がある要件、ある要件をマークするために使用されます。
The discussion in this section relates to requirements R-ASSOC (specified in Section 5.1) R-PASS-MEDIA, R-PASS-SIG, R-SIG-MEDIA, R-ACT-ACT, and R-ID-BINDING (specified in Section 5.2).
このセクションでの議論は、で指定された（要件（セクション5.1で指定される）R-ASSOC R-PASS-MEDIA、R-PASS-SIG、R-SIG-MEDIA、R-ACT-ACTに関し、R-ID結合します5.2節）。
This document classifies adversaries according to their access and their capabilities. An adversary might have access:
この文書では、彼らのアクセスとその機能に応じて敵を分類します。敵はアクセス権を持っているかもしれません。
An attacker that can solely be located along the signaling path, and does not have access to media (item 2), is not considered in this document.
単独シグナリング経路に沿って配置することができ、メディア（項目2）へのアクセス権を持っていない攻撃者は、この文書では考慮されていません。
There are two different types of adversaries: active and passive. An active adversary may need to be active with regard to the key exchange relevant information traveling along the media path or traveling along the signaling path.
アクティブおよびパッシブ：敵の2種類があります。アクティブ敵は媒体経路に沿って移動またはシグナル伝達経路に沿って走行鍵交換関連情報に関してアクティブである必要があり得ます。
Based on their robustness against the adversary capabilities described above, we can group security mechanisms using the following labels. This list is generally ordered from easiest to compromise (at the top) to more difficult to compromise:
前述した敵の能力に対する彼らの堅牢性に基づいて、我々はグループのセキュリティメカニズムは、次のラベルを使用することができます。このリストは、一般的に妥協することはより困難に（上部に）妥協するのが最も簡単に発注されています。
+---------------+---------+--------------------------------------+
| SIP signaling | media | abbreviation |
+---------------+---------+--------------------------------------+
| none | passive | no-signaling-passive-media |
| none | active | no-signaling-active-media |
| passive | passive | passive-signaling-passive-media |
| passive | active | passive-signaling-active-media |
| active | passive | active-signaling-passive-media |
| active | active | active-signaling-active-media |
| active | active | active-signaling-active-media-detect |
+---------------+---------+--------------------------------------+
no-signaling-passive-media: Access only to the media path is sufficient to reveal the content of the media traffic.
無シグナリング・パッシブ・メディア：専用メディアパスへのアクセスは、メディアトラフィックの内容を明らかにするのに十分です。
passive-signaling-passive-media: Passive attack on the signaling and passive attack on the media path is necessary to reveal the content of the media traffic.
パッシブ・シグナル・パッシブ・メディア：メディアパス上のシグナリングおよび受動的攻撃の受動的攻撃は、メディアトラフィックの内容を明らかにする必要があります。
passive-signaling-active-media: Passive attack on the signaling and active attack on the media path is necessary to reveal the content of the media traffic.
受動シグナリング活性メディア：メディアパス上のシグナリングとアクティブな攻撃に対する受動的攻撃は、メディアトラフィックの内容を明らかにすることが必要です。
active-signaling-passive-media: Active attack on the signaling path and passive attack on the media path is necessary to reveal the content of the media traffic.
アクティブ・シグナル・パッシブ・メディア：メディアパス上のシグナリングパスとパッシブ攻撃への積極的な攻撃は、メディアトラフィックの内容を明らかにする必要があります。
no-signaling-active-media: Active attack on the media path is sufficient to reveal the content of the media traffic.
無シグナリングアクティブメディア：メディアパス上のアクティブな攻撃は、メディアトラフィックの内容を明らかにするのに十分ではありません。
active-signaling-active-media: Active attack on both the signaling path and the media path is necessary to reveal the content of the media traffic.
アクティブ・シグナル・アクティブメディア：シグナリングパスとメディアパスの両方に積極的な攻撃は、メディアトラフィックの内容を明らかにする必要があります。
active-signaling-active-media-detect: Active attack on both signaling and media path is necessary to reveal the content of the media traffic (as with active-signaling-active-media), and the attack is detectable by protocol messages exchanged between the endpoints.
アクティブ・シグナリング活性メディア検出：両方のシグナリングおよびメディア経路上のアクティブな攻撃は、（アクティブシグナリング活性媒体と同様に）メディアトラフィックの内容を明らかにする必要があり、攻撃がプロトコルメッセージによって検出可能である間でやり取りエンドポイント。
For example, unencrypted RTP is vulnerable to no-signaling-passive-media.
例えば、暗号化されていないRTPがno-シグナリング受動メディアに対して脆弱です。
As another example, SDP Security Descriptions [RFC4568], when protected by TLS (as it is commonly implemented and deployed), belong in the passive-signaling-passive-media category since the adversary needs to learn the SDP Security Descriptions key by seeing the SIP signaling message at a SIP proxy (assuming that the adversary is in control of the SIP proxy). The media traffic can be decrypted using that learned key.
敵が見て、SDPセキュリティ記述キーを学習する必要があるので、別の例として、SDPセキュリティ記述TLSで保護された[RFC4568]は、（それは一般的に実装され、配備されると）、パッシブ・シグナル・パッシブ・メディアカテゴリに属しています（敵対者がSIPプロキシを制御していると仮定して）SIPプロキシにSIPシグナリングメッセージ。メディアトラフィックは、その学んだキーを使用して復号化することができます。
As another example, DTLS-SRTP (Datagram Transport Layer Security Extension for SRTP) falls into active-signaling-active-media category when DTLS-SRTP is used with a public-key-based ciphersuite with self-signed certificates and without SIP Identity [RFC4474]. An adversary would have to modify the fingerprint that is sent along the signaling path and subsequently to modify the certificates carried in the DTLS handshake that travel along the media path. If DTLS-SRTP is used with both SIP Identity [RFC4474] and SIP Connected Identity [RFC4916], the RFC-4474 signature protects both the offer and the answer, and such a system would then belong to the active-signaling-active-media-detect category (provided, of course, the signaling path to the RFC-4474 authenticator and verifier is secured as per RFC 4474, and the RFC-4474 authenticator and verifier are behaving as per RFC 4474).
[DTLS-SRTPが自己署名証明書とし、SIPアイデンティティなしで公開鍵ベースの暗号の組み合わせで使用された場合にアクティブシグナリング活性メディアカテゴリに分類（SRTPのためのデータグラムトランスポート層セキュリティ拡張）別の例として、DTLS、SRTP RFC4474]。敵はシグナリングパスに沿って送信された指紋を変更するために、その後、媒体経路に沿って移動DTLS握手で運ばれた証明書を変更する必要があります。 DTLS-SRTPがSIPアイデンティティ[RFC4474]とSIP接続アイデンティティ[RFC4916]の両方で使用される場合、RFC4474署名が申し出と答えの両方を保護し、そのようなシステムは、アクティブシグナリング活性メディアに属していることになります-detectカテゴリ（提供はもちろん、RFC-4474認証者と検証者へのシグナリングパスは、RFC 4474に従って固定され、RFC-4474認証者と検証者は、RFC 4474に従って動作しています）。
The above discussion of DTLS-SRTP demonstrates how a single security protocol can be in different classes depending on the mode in which it is operated. Other protocols can achieve a similar effect by adding functions outside of the on-the-wire key management protocol itself. Although it may be appropriate to deploy lower-classed mechanisms in some cases, the ultimate security requirement for a media security negotiation protocol is that it have a mode of operation available in which is detect-attack, which provides protection against the passive and active attacks and provides detection of such attacks. That is, there must be a way to use the protocol so that an active attack is required against both the signaling and media paths, and so that such attacks are detectable by the endpoints.
DTLS-SRTPの上記の議論は、単一のセキュリティプロトコルは、それが動作するモードに応じて異なるクラスにすることができる方法を示しています。他のプロトコルは、オン・ザ・ワイヤ鍵管理プロトコル自体の外に機能を追加することにより、同様の効果を得ることができます。それはいくつかの場合には低分類メカニズムを展開することが適切かもしれないが、メディアセキュリティネゴシエーションプロトコルのための究極のセキュリティ要件は、それが受動的および能動的攻撃に対する保護を提供し、攻撃を検出された利用可能な動作モードを有することですそしてこのような攻撃の検出を提供します。すなわち、アクティブな攻撃の両方シグナリングおよびメディアパスに対して必要な、そのような攻撃は、エンドポイントによって検出可能であるようにするようにプロトコルを使用する方法が必要です。
The following subsections describe call scenarios that pose the most challenge to the key management system for media data in cooperation with SIP signaling.
以下のサブセクションでは、SIPシグナリングと協力して、メディアデータのための鍵管理システムへの最も挑戦を提起コールシナリオについて説明します。
Throughout the subsections, requirements are stated by using the nomenclature R- to state an explicit requirement. All of the stated requirements are explained in detail in Section 5. They are listed according to their association to the key management protocol, to attack scenarios, and requirements that can be met inside the key management protocol or outside of the key management protocol.
サブセクションを通して、要件は、明示的な要件を述べるために命名R-を用いて記載されています。述べた要件のすべてが第5節で詳しく説明されている彼らは、シナリオ、および鍵管理プロトコルの鍵管理プロトコルや外部の内側に満たすことができる要件を攻撃するために、鍵管理プロトコルへの関連付けに応じて記載されています。
The discussion in this section relates to requirements R-AVOID-CLIPPING and R-ALLOW-RTP.
このセクションでの議論は、要件R-AVOIDクリッピング及びR-ALLOW-RTPに関する。
Per the Session Description Protocol (SDP) Offer/Answer Model [RFC3264]:
セッション記述プロトコル（SDP）オファー/アンサーモデル[RFC3264]あたり：
Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information).
オファー側が申し出を送信した後は、その申し出により記載される任意のがrecvonlyストリームのためにメディアを受け取る準備が必要です。送信し、提供中の任意のsendrecvストリームのメディアを受信し、提供中の任意sendonlyの流れ（ピアが必要なアドレスとポート情報との答えを提供するまで、もちろん、それは実際に送信することはできません）のためにメディアを送信するために準備しなければなりません。
To meet this requirement with SRTP, the offerer needs to know the SRTP key for arriving media. If either endpoint receives encrypted media before it has access to the associated SRTP key, it cannot play the media -- causing clipping.
SRTPでこの要件を満たすために、オファー側は、メディアの到着のためのSRTPキーを知る必要があります。原因クリッピング - どちらかのエンドポイントが暗号化されたメディアを受信した場合、それが関連するSRTPキーへのアクセス権を持つ前に、それはメディアを再生することはできません。
For key exchange mechanisms that send the answerer's key in SDP, a SIP provisional response [RFC3261], such as 183 (session progress), is useful. However, the 183 messages are not reliable unless both the calling and called endpoint support Provisional Response ACKnowledgement (PRACK) [RFC3262], use TCP across all SIP proxies, implement Security Preconditions [RFC5027], or both ends implement Interactive Connectivity Establishment [ICE] and the answerer implements the reliable provisional response mechanism described in ICE. Unfortunately, there is not wide deployment of any of these techniques and there is industry reluctance to require these techniques to avoid the problems described in this section.
例えば183のようなSDPで回答の鍵を送信する鍵交換メカニズム、SIP暫定応答[RFC3261]、（セッション進行）のために、有用です。しかし、183件のメッセージは、呼び出しの両方がない限り信頼性がないと、エンドポイントのサポート暫定応答確認（PRACK）[RFC3262]と呼ばれる、すべてのSIPプロキシ間でTCPを使用して、セキュリティの前提条件[RFC5027]を実装する、または両端には、インタラクティブな接続の確立[ICE]を実装しますそして、回答はICEで説明した信頼性のある暫定応答メカニズムを実装しています。残念ながら、これらの技術のいずれかの幅広い展開がないと、このセクションで説明する問題を回避するために、これらの技術を必要とする業界の抵抗があります。
Note that the receipt of an SDP answer is not always sufficient to allow media to be played to the offerer. Sometimes, the offerer must send media in order to open up firewall holes or NAT bindings before media can be received (for details, see [MIDDLEBOX]). In this case, even a solution that makes the key available before the SDP answer arrives will not help.
SDPの回答の受信は常にメディアがオファー側に対して再生することを可能にするのに十分ではないことに注意してください。時には、オファー側がメディアを受信することができます前に、ファイアウォールの穴やNATバインディングを開くためにメディアを送信する必要があります（詳細については、[ミドル]を参照）。この場合、SDPの答えが到着する前に、キーが利用できるようにしても解決策は助けにはなりません。
Preventing the arrival of early media (i.e., media that arrives at the SDP offerer before the SDP answer arrives) might obsolete the R-AVOID-CLIPPING requirement, but at the time of writing such early media exists in many normal call scenarios.
初期メディアの到着を防止（すなわち、SDPの答えが到着する前に、SDP提供者に到達したメディア）が廃止されたR-AVOIDクリッピング要件が、そのような初期メディアを書いている時点で、多くの通常のコールシナリオに存在する可能性があります。
The discussion in this section relates to requirements R-FORK-RETARGET, R-DISTINCT, R-HERFP, and R-BEST-SECURE.
このセクションでの議論は、要件R-フォークリターゲット、R-DISTINCT、R-HERFP、及びR-BEST-SECUREに関する。
In SIP, a request sent to a specific AOR but delivered to a different AOR is called a "retarget". A typical scenario is a "call forwarding" feature. In Figure 1, Alice sends an INVITE in step 1 that is sent to Bob in step 2. Bob responds with a redirect (SIP response code 3xx) pointing to Carol in step 3. This redirect typically does not propagate back to Alice but only goes to a proxy (i.e., the retargeting proxy) that sends the original INVITE to Carol in step 4.
SIPでは、特定のAORに送信されたが、別のAORに配信要求が「再ターゲット」と呼ばれています。典型的なシナリオは、「着信転送」機能です。図1では、アリスはこのリダイレクトは、典型的には、バックアリスに伝搬しないだけ進むステップ3で、ボブは、キャロルを指すリダイレクト（SIP応答コード3XX）で応答し、ステップ2で、ボブに送信され、ステップ1でINVITEを送信します元のステップ4でキャロルにINVITEを送信するプロキシ（すなわち、再標的化プロキシ）へ。
+-----+
|Alice|
+--+--+
|
| INVITE (1)
V
+----+----+
| proxy |
++-+-----++
| ^ |
INVITE (2) | | | INVITE (4)
& redirect (3) | | |
V | V
++-++ ++----+
|Bob| |Carol|
+---+ +-----+
Figure 1: Retargeting
図1：リターゲット
Using retargeting might lead to situations where the User Agent Client (UAC) does not know where its request will be going. This might not immediately seem like a serious problem; after all, when one places a telephone call on the Public Switched Telephone Network (PSTN), one never really knows if it will be forwarded to a different number, who will pick up the line when it rings, and so on. However, when considering SIP mechanisms for authenticating the called party, this function can also make it difficult to differentiate an intermediary that is behaving legitimately from an attacker. From this perspective, the main problems with retargeting are:
リターゲットを使用すると、その要求は予定される場所をユーザエージェントクライアント（UAC）が知らないような状況につながる可能性があります。これはすぐに深刻な問題のように思えないかもしれません。公衆交換電話網（PSTN）に1が電話コールをかけたとき、それはようにそれが鳴ったときにラインを拾う、となります別の番号に転送する場合は結局、1は本当に知っていることはありません。呼ばれるパーティを認証するためのSIPメカニズムを検討する際ただし、この機能はまた、それが困難な攻撃者から合法的に動作している仲介者を区別することができます。このような観点から、リターゲットとの主な問題は、次のとおりです。
Not detectable by the caller: The originating user agent has no means of anticipating that the condition will arise, nor any means of determining that it has occurred until the call has already been set up.
呼び出し側では検出できない：発信ユーザエージェントは状態が発生することを見越してのいかなる手段、またコールがすでに設定されているまで、それが発生したことを判断する任意の手段を持っていません。
Not preventable by the caller: There is no existing mechanism that might be employed by the originating user agent in order to guarantee that the call will not be retargeted.
呼び出し側によって予防可能ではない：呼び出しはリターゲットされないことを保証するために、元のユーザエージェントによって採用される可能性があります既存のメカニズムはありません。
The mechanism used by SIP for identifying the calling party is SIP Identity [RFC4474]. However, due to the nature of retargeting, SIP Identity can only identify the calling party (that is, the party that initiated the SIP request). Some key exchange mechanisms predate SIP Identity and include their own identity mechanism (e.g., Multimedia Internet KEYing (MIKEY)). However, those built-in identity mechanism also suffer from the SIP retargeting problem. While Connected Identity [RFC4916] allows positive identification of the called party, the primary difficulty still remains that the calling party does not know if a mismatched called party is legitimate (i.e., due to authorized retargeting) or illegitimate (i.e., due to unauthorized retargeting by an attacker above to modify SIP signaling).
発呼者を識別するためにSIPが使用するメカニズムは、SIPアイデンティティ[RFC4474]です。しかし、再標的の性質のために、SIPアイデンティティは、発信側（つまり、SIP要求を開始した当事者である）を識別することができます。いくつかの鍵交換メカニズムは、SIPのアイデンティティに先行して（例えば、マルチメディアインターネットキーイング（MIKEY））自分のアイデンティティ機構を含みます。しかし、これらの組み込みのアイデンティティメカニズムは、SIPのリターゲットの問題に苦しみます。接続されたアイデンティティ[RFC4916]は、着信側の正の同定を可能にする一方で、主な困難は、まだ不一致と呼ばれるパーティが（すなわち、原因権限の再ターゲットに）正当か非合法であれば、発呼者が原因の不正なリターゲットに、すなわち（知らないことに変わりはありません攻撃者が上記）SIPシグナリングを変更します。
In SIP, 'forking' is the delivery of a request to multiple locations. This happens when a single AOR is registered more than once. An example of forking is when a user has a desk phone, PC client, and mobile handset all registered with the same AOR.
SIPでは、「フォーク」は複数の場所への要求の送達です。単一AORが複数回登録されている場合に発生します。ユーザーがすべて同じAORに登録卓上電話、PCクライアント、および携帯電話を持っているとき、フォークの例があります。
+-----+
|Alice|
+--+--+
|
| INVITE
V
+-----+-----+
| proxy |
++---------++
| |
INVITE | | INVITE
V V
+--+--+ +--+--+
|Bob-1| |Bob-2|
+-----+ +-----+
Figure 2: Forking
図2：フォーク
With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP responses. Alice will see those intermediate (18x) and final (200) responses. It is useful for Alice to be able to associate the SIP response with the incoming media stream. Although this association can be done with ICE [ICE], and ICE is useful to make this association with RTP, it is not desirable to require ICE to accomplish this association.
フォークでは、ボブ-1とBob-2の両方がSIP応答のSDPの回答を返送することがあります。アリスは、これらの中間体（18X）と、最終的な（200）応答が表示されます。アリスは、着信メディア・ストリームとSIP応答を関連付けることができるようすることが有用です。この協会は、ICE [ICE]で行うことができ、かつICEはRTPでこの関連付けを行うことが有用であるが、この関連付けを実現するためにICEを要求することは望ましくありません。
Forking and retargeting are often used together. For example, a boss and secretary might have both phones ring (forking) and rollover to voice mail if neither phone is answered (retargeting).
フォークとリターゲットはしばしば一緒に使用されています。例えば、上司と秘書は電話リング（フォーク）とロールオーバーどちらの電話が応答された場合はボイスメールに（再ターゲット）の両方を持っているかもしれません。
To maintain the security of the media traffic, only the endpoint that answers the call should know the SRTP keys for the session. Forked and retargeted calls only reveal sensitive information to non-responders when the signaling messages contain sensitive information (e.g., SRTP keys) that is accessible by parties that receive the offer, but may not respond (i.e., the original recipients in a retargeted call, or non-answering endpoints in a forked call). For key exchange mechanisms that do not provide secure forking or secure retargeting, one workaround is to rekey immediately after forking or retargeting. However, because the originator may not be aware that the call forked this mechanism requires rekeying immediately after every session is established. This doubles the number of messages processed by the network.
メディアトラフィックのセキュリティを維持するには、呼び出しに応答する唯一のエンドポイントは、セッションのためのSRTP鍵を知っている必要があります。フォーク型とリターゲットの呼び出しは、再標的呼び出しで（すなわち、元の受信者を知らせるメッセージが提供を受ける当事者がアクセス可能である機密情報（例えば、SRTPキー）を含んでいたときに非応答者に機密情報を明らかにするが、応答しないことがありまたは）フォークコール内のエンドポイントを非答えます。安全なフォークや安全なリターゲットを提供していない鍵交換のメカニズムについては、1つの回避策は、フォークやリターゲットした直後リキーすることです。すべてのセッションが確立された直後ただし、発信者が呼び出しはこのメカニズムをフォークすることを認識していない可能性があるため、再入力が必要です。これは、ネットワークによって処理されたメッセージの数が2倍になります。
Further compounding this problem is a unique feature of SIP that, when forking is used, there is always only one final error response delivered to the sender of the request: the forking proxy is responsible for choosing which final response to choose in the event where forking results in multiple final error responses being received by the forking proxy. This means that if a request is rejected, say with information that the keying information was rejected and providing the far end's credentials, it is very possible that the rejection will never reach the sender. This problem, called the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326], is difficult to solve in SIP. Because we expect the HERFP to continue to be a problem in SIP for the foreseeable future, a media security system should function even in the presence of HERFP behavior.
さらに、この問題を配合すると、フォーク際には使用され、SIPのユニークな特徴である、リクエストの送信者に配信唯一の最後のエラー応答が常にある：フォークプロキシがフォークイベントで最終的な応答を選択することを選択する責任がありますフォーキングプロキシによって受信される複数の最終的なエラー応答をもたらします。これは、要求が拒否された場合、キー情報が拒否されたと遠端の資格情報を提供し、拒絶が送信者に到達することはありませんことを非常に可能性があるという情報を持って言うことを意味します。この問題は、ヘテロジニアスエラー応答フォーク問題（HERFP）[RFC3326]を呼ばれ、SIPに解決することは困難です。我々はHERFPは予見可能な将来のためのSIPに問題があることを続けることを期待しているので、メディアのセキュリティシステムは、HERFP行動の存在下でさえも機能するはずです。
The discussion in this section relates to requirement R-RECORDING.
このセクションでの議論は、要求R-RECORDINGに関する。
Some business environments, such as stock brokerages, banks, and catalog call centers, require recording calls with customers. This is the familiar "this call is being recorded for quality purposes" heard during calls to these sorts of businesses. In these environments, media recording is typically performed by an intermediate device (with RTP, this is typically implemented in a 'sniffer').
当該株式証券会社、銀行、およびカタログコールセンターなどの一部のビジネス環境では、顧客との記録のコールが必要です。これは、企業のこれらの種類の呼び出し時に聞いた「この呼び出しは、品質の目的のために記録されている」よく知られています。これらの環境では、メディア記録は、典型的には、（RTPと、これは典型的には「スニファ」に実装されている）中間デバイスによって実行されます。
When performing such call recording with SRTP, the end-to-end security is compromised. This is unavoidable, but necessary because the operation of the business requires such recording. It is desirable that the media security is not unduly compromised by the media recording. The endpoint within the organization needs to be informed that there is an intermediate device and needs to cooperate with that intermediate device.
SRTPで記録そのような呼び出しを行う場合、エンドツーエンドのセキュリティが危険にさらされます。ビジネスの操作は、このような記録を必要とするので、これは避けられないが、必要です。メディアセキュリティが不当にメディア記録によって損なわれないことが望ましいです。組織内のエンドポイントは、中間デバイスがあることを通知する必要があり、その中間デバイスと協力する必要があります。
This scenario does not place a requirement directly on the key management protocol. The requirement could be met directly by the key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an external out-of-band mechanism (e.g., [SRTP-KEY]).
このシナリオでは、鍵管理プロトコルで直接要件を置いていません。要件は、鍵管理プロトコル（たとえば、MIKEY-NULLまたは[RFC4568]）によって、または外部のアウトオブバンド機構（例えば、[SRTP-KEY]）を介して直接満たすことができました。
The discussion in this section relates to requirement R-PSTN.
このセクションで議論は必要R-PSTNに関する。
It is desirable, even when one leg of a call is on the PSTN, that the IP leg of the call be protected with SRTP.
コールの1つのレグは、コールのIPレッグがSRTPで保護されていることが、PSTN上にある場合でも、それは、望ましいです。
A typical case of using media security where two entities are having a Voice over IP (VoIP) conversation over IP-capable networks. However, there are cases where the other end of the communication is not connected to an IP-capable network. In this kind of setting, there needs to be some kind of gateway at the edge of the IP network that converts the VoIP conversation to a format understood by the other network. An example of such a gateway is a PSTN gateway sitting at the edge of IP and PSTN networks (such as the architecture described in [RFC3372]).
2つのエンティティは、IP対応のネットワーク上でボイスオーバーIP（VoIP）の会話をしているメディアのセキュリティを使用する典型的なケース。しかしながら、通信相手のIP対応のネットワークに接続されていない場合があります。設定のこの種では、他のネットワークによって理解されるフォーマットへのVoIP会話を変換するIPネットワークのエッジでのゲートウェイのいくつかの種類が存在する必要があります。そのようなゲートウェイの例は、（例えば、[RFC3372]に記載のアーキテクチャのような）IPとPSTNネットワークの縁に座ってPSTNゲートウェイです。
If media security (e.g., SRTP protection) is employed in this kind of gateway-setting, then media security and the related key management is terminated at the PSTN gateway. The other network (e.g., PSTN) may have its own measures to protect the communication, but this means that from media security point of view the media security is not employed truly end-to-end between the communicating entities.
メディアセキュリティ（例えば、SRTP保護）は、ゲートウェイ設定のこの種で使用される場合、メディアセキュリティと関連する鍵管理がPSTNゲートウェイで終端されています。他のネットワーク（例えば、PSTN）に通信を保護するための独自の対策を有していてもよく、これはビューのメディアセキュリティポイントからメディアセキュリティは、エンドツーエンド通信エンティティとの間の真の使用されないことを意味します。
The discussion in this section relates to requirement R-REUSE.
このセクションで議論は必要R-REUSEに関する。
Some devices lack sufficient processing power to perform public key operations or Diffie-Hellman operations for each call, or prefer to avoid performing those operations on every call. The ability to reuse previous public key or Diffie-Hellman operations can vastly decrease the call setup delay and processing requirements for such devices.
一部のデバイスは、各コールのための公開鍵の操作やのDiffie-Hellman操作を実行するのに十分な処理能力が不足している、またはすべての呼び出しでこれらの操作の実行を回避することを好みます。前回の公開鍵またはディフィー・ヘルマンの操作を再利用する能力が大幅にこのようなデバイスのための呼設定遅延と処理要件を減少させることができます。
In certain devices, it can take a second or two to perform a Diffie-Hellman operation. Examples of these devices include handsets, IP Multimedia Services Identity Modules (ISIMs), and PSTN gateways. PSTN gateways typically utilize a Digital Signal Processor (DSP) that is not yet involved with typical DSP operations at the beginning of a call; thus, the DSP could be used to perform the calculation, so as to avoid having the central host processor perform the calculation. However, not all PSTN gateways use DSPs (some have only central processors or their DSPs are incapable of performing the necessary public key or Diffie-Hellman operation), and handsets lack a separate, unused processor to perform these operations.
特定のデバイスでは、ディフィー - ヘルマン動作を実行するために1秒か2秒を取ることができます。これらのデバイスの例としては、携帯電話、IPマルチメディアサービス識別モジュール（ISIMs）、およびPSTNゲートウェイが含まれます。 PSTNゲートウェイは、典型的には、コールの開始時にはまだ一般的なDSP操作に関与していないデジタル信号プロセッサ（DSP）を利用します。従って、DSPは、中央ホストプロセッサが計算を行うことを回避するために、計算を実行するために使用することができます。しかし、すべてのPSTNゲートウェイ（一部のみが中央処理装置を有するか、またはそれらのDSPが必要な公開鍵またはディフィー・ヘルマン動作を行うことができない）DSPを使用し、携帯電話は、これらの操作を実行するために別の、未使用のプロセッサを欠いています。
Two scenarios where R-REUSE is useful are calls between an endpoint and its voicemail server or its PSTN gateway. In those scenarios, calls are made relatively often and it can be useful for the voicemail server or PSTN gateway to avoid public key operations for subsequent calls.
R-再利用が有用である2つのシナリオは、エンドポイントとそのボイスメール・サーバまたはPSTNゲートウェイとの間のコールです。これらのシナリオでは、呼び出しが比較的頻繁に行われており、それは以降の呼び出しのために、公開キー操作を避けるために、ボイスメールサーバまたはPSTNゲートウェイに役立ちます。
Storing keys across sessions often interferes with perfect forward secrecy (R-PFS).
セッション間でキーを格納することは、多くの場合、完全転送秘密（R-PFS）と干渉する。
The discussion in this section relates to requirement R-TRANSCODER.
このセクションでの議論は、要求Rトランスコーダに関する。
In some environments, it is necessary for network equipment to transcode from one codec (e.g., a highly compressed codec that makes efficient use of wireless bandwidth) to another codec (e.g., a standardized codec to a SIP peering interface). With RTP, a transcoding function can be performed with the combination of a SIP back-to-back user agent (B2BUA) to modify the SDP and a processor to perform the transcoding between the codecs. However, with end-to-end secured SRTP, a transcoding function implemented the same way is a man-in-the-middle attack, and the key management system prevents its use.
ネットワーク機器は、別のコーデック（例えば、インタフェースをピアリングSIPに標準化されたコーデック）1つのコーデック（例えば、無線帯域を効率的に利用する高圧縮コーデック）からトランスコードするためのいくつかの環境では、それが必要です。 RTPを用いて、トランスコーディング機能は、SDPとコーデック間のトランスコーディングを実行するためにプロセッサを変更するSIPバックツーバックユーザエージェント（B2BUA）の組み合わせを用いて行うことができます。しかし、エンドツーエンドのセキュリティで保護されたSRTPで、トランスコーディング機能は同じようにはman-in-the-middle攻撃で、鍵管理システムは、その使用を妨げる実装しました。
However, such a network-based transcoder can still be realized with the cooperation and approval of the endpoint, and can provide end-to-transcoder and transcoder-to-end security.
しかし、そのようなネットワークベースのトランスコーダは、まだエンドポイントの協力と承認を得て実現することができ、エンド・ツー・トランスコーダおよびトランスコーダ・ツー・エンドのセキュリティを提供することができます。
The discussion in this section relates to the requirement R-ALLOW-RTP.
このセクションで議論は必要R-ALLOW-RTPに関する。
Legitimate RTP media can be sent to an endpoint for announcements, colorful ringback tones (e.g., music), advertising, or normal call progress tones. The RTP may be received before an associated SDP answer. For details on various scenarios, see [EARLY-MEDIA].
正当なRTPメディアが発表、カラフルなリングバックトーン（例えば、音楽）、広告、または通常の呼出音のためのエンドポイントに送信することができます。 RTPは、関連するSDPアンサー前に受信することができます。様々なシナリオの詳細については、[EARLY-MEDIA]を参照してください。
While receiving such RTP exposes the calling party to a risk of receiving malicious RTP from an attacker, SRTP endpoints will need to receive and play out RTP media in order to be compatible with deployed systems that send RTP to calling parties.
こうしたRTPを受信すると、攻撃者からの悪質なRTPを受信するリスクへの発信者を公開しながら、SRTPエンドポイントは発呼者にRTPを送る展開のシステムと互換性があるために、RTPメディアを受信して再生する必要があります。
The discussion in this section relates to the requirement R-OTHER-SIGNALING.
このセクションでの議論は、要求R-OTHERシグナリングに関する。
In many environments, some devices are signaled with protocols other than SIP that do not share SIP's offer/answer model (e.g., [H.248.1] or do not utilize SDP (e.g., H.323). In other environments, both endpoints may be SIP, but may use different key management systems (e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R).
多くの環境では、一部のデバイスは、[H.248.1]、例えば（SIPのオファー/アンサーモデルを共有していないか、SDP（例えば、H.323）を利用していないSIP以外のプロトコルで通知されます。他の環境では、両方のエンドポイントがかもしれませんSIPであるが、異なる鍵管理システムを使用することができる（例えば、一方はMIKEY-RSA、他のMIKEY-RSA-Rを使用します）。
In these environments, it is desirable to have SRTP -- rather than RTP -- between the two endpoints. It is always possible, although undesirable, to interwork those disparate signaling systems or disparate key management systems by decrypting and re-encrypting each SRTP packet in a device in the middle of the network (often the same device performing the signaling interworking). This is undesirable due to the cost and increased attack area, as such an SRTP/SRTP interworking device is a valuable attack target.
むしろ、RTPより - - 2つのエンドポイント間でこれらの環境では、SRTPを有することが望ましいです。これは望ましくないが、復号化及びネットワーク（シグナリングインターワーキングを実行しばしば同じデバイス）の途中でデバイスの各SRTPパケットを再暗号化することによって、それらの異なるシグナル伝達系または異種の鍵管理システムを連動するように、常に可能です。そのようなSRTP / SRTPインターワーキング装置は、貴重な攻撃対象であるとしてこれは、コストおよび増加攻撃領域に望ましくありません。
At the time of this writing, interworking is considered important. Interworking without decryption/encryption of the SRTP, while useful, is not yet deemed critical because the scale of such SRTP deployments is, to date, relatively small.
この記事の執筆時点では、インターワーキングが重要であると考えられます。 SRTPの復号化/暗号化なしインターワーキング、そのようSRTP展開の規模は、現在までに、比較的小さいので有用ではあるが、まだ重要なものではありません。
The discussion in this section relates to R-CERTS.
このセクションでの議論は、R-CERTSに関する。
On the Internet and on some private networks, validating another peer's certificate is often done through a trust anchor -- a list of Certificate Authorities that are trusted. It can be difficult or expensive for a peer to obtain these certificates. In all cases, both parties to the call would need to trust the same trust anchor (i.e., "certificate authority"). For these reasons, it is important that the media plane key management protocol offer a mechanism that allows end-users who have no prior association to authenticate to each other without acquiring credentials from a third-party trust point. Note that this does not rule out mechanisms in which servers have certificates and attest to the identities of end-users.
信頼される認証局のリスト - インターネット上で、いくつかのプライベートネットワーク上で、他のピアの証明書を検証することは、多くの場合、トラストアンカーを介して行われます。ピアは、これらの証明書を取得することが困難または高価になることができます。すべての場合において、コールの両当事者は、同じトラストアンカー（すなわち、「認証局」）を信頼する必要があります。これらの理由から、メディアプレーンキー管理プロトコルは、サードパーティの信頼ポイントから資格を取得することなく、相互に認証するための事前の関連付けを持たないエンドユーザーを可能にするメカニズムを提供することが重要です。これは、サーバが証明書を持っており、エンドユーザーの身元を証明するメカニズムを排除しないことに注意してください。
This section is divided into several parts: requirements specific to the key management protocol (Section 5.1), attack scenarios (Section 5.2), and requirements that can be met inside the key management protocol or outside of the key management protocol (Section 5.3).
鍵管理プロトコルの内部またはキー管理プロトコル（セクション5.3）の外側に満たすことができる鍵管理プロトコルに固有の要件（セクション5.1）、攻撃シナリオ（セクション5.2）、および要件：このセクションでは、いくつかの部分に分割されます。
SIP Forking and Retargeting, from Section 4.2:
4.2節からSIPフォークとリターゲティング、：
R-FORK-RETARGET: The media security key management protocol MUST securely support forking and retargeting when all endpoints are willing to use SRTP without causing the call setup to fail. This requirement means the endpoints that did not answer the call MUST NOT learn the SRTP keys (in either direction) used by the answering endpoint.
R-FORK-再ターゲット：すべてのエンドポイントは、コールセットアップが失敗することなくSRTPを使用して喜んでいるときに、メディアのセキュリティキー管理プロトコルがしっかりフォークとリターゲットをサポートしなければなりません。この要件は、コールに応答しませんでしたエンドポイントは（どちらの方向に）答えるエンドポイントで使用するSRTP鍵を学ぶてはならないことを意味します。
R-DISTINCT: The media security key management protocol MUST be capable of creating distinct, independent cryptographic contexts for each endpoint in a forked session.
R-DISTINCT：メディアセキュリティ鍵管理プロトコルは、二股セッション内の各エンドポイントのために別個の、独立の暗号コンテキストを作成することができなければなりません。
R-HERFP: The media security key management protocol MUST function securely even in the presence of HERFP behavior, i.e., the rejection of key information does not reach the sender.
R-HERFP：メディアセキュリティ鍵管理プロトコル、すなわち、鍵情報の拒絶が送信者に到達しない、もHERFP挙動の存在下で確実に機能しなければなりません。
Performance considerations:
パフォーマンスの考慮事項：
R-REUSE: The media security key management protocol MAY support the reuse of a previously established security context.
R-REUSE：メディアセキュリティキー管理プロトコルは、以前に確立されたセキュリティコンテキストの再利用をサポートするかもしれません。
Note: reuse of the security context does not imply reuse of RTP
parameters (e.g., payload type or SSRC).
Media considerations:
メディアの考慮事項：
R-AVOID-CLIPPING: The media security key management protocol SHOULD avoid clipping media before SDP answer without requiring Security Preconditions [RFC5027]. This requirement comes from Section 4.1.
R-AVOIDクリッピング：メディアセキュリティキー管理プロトコルは、セキュリティの前提条件[RFC5027]を必要とせず、SDPアンサー前にメディアをクリッピングすることは避けてください。この要件は、4.1節から来ています。
R-RTP-CHECK: If SRTP key negotiation is performed over the media path (i.e., using the same UDP/TCP ports as media packets), the key negotiation packets MUST NOT pass the RTP validity check defined in Appendix A.1 of [RFC3550], so that SRTP negotiation packets can be differentiated from RTP packets.
R-RTP-CHECK：SRTPキーネゴシエーションがメディアパス上で実行された場合（すなわち、メディアパケットと同じUDP / TCPポートを使用して）、キーネゴシエーションパケットは、付録A.1で定義されたRTPの妥当性チェックを通過してはなりません[ RFC3550]、SRTPネゴシエーションパケットは、RTPパケットから区別することができるようになっています。
R-ASSOC: The media security key management protocol SHOULD include a mechanism for associating key management messages with both the signaling traffic that initiated the session and with protected media traffic. It is useful to associate key management messages with call signaling messages, as this allows the SDP offerer to avoid performing CPU-consuming operations (e.g., Diffie-Hellman or public key operations) with attackers that have not seen the signaling messages.
R-ASSOC：メディアセキュリティ鍵管理プロトコルは、セッションを開始し、保護されたメディアトラフィックとシグナリングトラフィックの両方を用いて鍵管理メッセージを関連付けるための機構を含むべきです。なお、これは、SDPオファーは、CPUを消費する操作を実行回避することを可能にするように、コールシグナリングメッセージと鍵管理メッセージを関連付けることが有用である（例えば、ディフィー・ヘルマン鍵または公開鍵操作）シグナリングメッセージを見ていない攻撃者です。
For example, if using a Diffie-Hellman keying technique
with security preconditions that forks to 20 endpoints, the
call initiator would get 20 provisional responses
containing 20 signed Diffie-Hellman key pairs. Calculating
20 Diffie-Hellman secrets and validating signatures can be
a difficult task for some devices. Hence, in the case of
forking, it is not desirable to perform a Diffie-Hellman
operation with every party, but rather only with the party
that answers the call (and incur some media clipping). To
do this, the signaling and media need to be associated so
the calling party knows which key management exchange needs
to be completed. This might be done by using the transport
address indicated in the SDP, although NATs can complicate
this association.
Note: due to RTP's design requirements, it is expected that SRTP receivers will have to perform authentication of any received SRTP packets.
注：原因RTPの設計要件に、SRTP受信機は、任意の受信SRTPパケットの認証を実行しなければならないことが予想されます。
R-NEGOTIATE: The media security key management protocol MUST allow a SIP User Agent to negotiate media security parameters for each individual session. Such negotiation MUST NOT cause a two-time pad (Section 9.1 of [RFC3711]).
R-NEGOTIATE：メディアセキュリティキー管理プロトコルは、個々のセッションのためのメディアセキュリティパラメータを交渉するSIPユーザエージェントを許容しなければなりません。このような交渉は、二度のパッド（[RFC3711]のセクション9.1）を引き起こしてはなりません。
R-PSTN: The media security key management protocol MUST support termination of media security in a PSTN gateway. This requirement is from Section 4.4.
R-PSTN：メディアセキュリティ鍵管理プロトコルは、PSTNゲートウェイにメディアセキュリティの終了をサポートしなければなりません。この要件は、4.4節からです。
This section describes overall security requirements and specific requirements from the attack scenarios (Section 3).
このセクションでは、全体的なセキュリティ要件と攻撃シナリオ（第3節）からの特定の要件について説明します。
Overall security requirements:
全体的なセキュリティ要件：
R-PFS: The media security key management protocol MUST be able to support perfect forward secrecy.
R-PFS：メディアセキュリティキー管理プロトコルは、完全転送秘密をサポートすることができなければなりません。
R-COMPUTE: The media security key management protocol MUST support offering additional SRTP cipher suites without incurring significant computational expense.
R-COMPUTE：メディアセキュリティキー管理プロトコルは、かなりの計算の費用を負担することなく、追加のSRTP暗号スイートを提供してサポートしなければなりません。
R-CERTS: The key management protocol MUST NOT require that end-users obtain credentials (certificates or private keys) from a third- party trust anchor.
R-CERTS：鍵管理プロトコルは、エンドユーザーがサードパーティのトラストアンカーから資格証明書（証明書や秘密鍵）を取得要求してはなりません。
R-FIPS: The media security key management protocol SHOULD use algorithms that allow FIPS 140-2 [FIPS-140-2] certification or similar country-specific certification (e.g., [AISITSEC]).
R-FIPS：メディアセキュリティ鍵管理プロトコルは、FIPS 140-2 [FIPS-140-2]認証または類似の国固有の認証（例えば、[AISITSEC]）を可能にするアルゴリズムを使用するべきです。
The United States Government can only purchase and use
crypto implementations that have been validated by the
FIPS-140 [FIPS-140-2] process:
The FIPS-140 standard is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems, including voice systems. The adoption and use of this standard is available to private and commercial organizations.
FIPS-140標準は、音声システムを含む、コンピュータや通信システム、で機密情報を保護するために、暗号化ベースのセキュリティシステムを使用するすべての連邦政府機関に適用されます。この規格の採用と使用は、プライベートや商業団体に提供されています。
Some commercial organizations, such as banks and defense contractors, require or prefer equipment that has received the same validation.
銀行や防衛請負業者などの一部の商業団体、同じ検証を受けた機器を必要とするか、または好みます。
R-DOS: The media security key management protocol MUST NOT introduce any new significant denial-of-service vulnerabilities (e.g., the protocol should not request the endpoint to perform CPU-intensive operations without the client being able to validate or authorize the request).
R-DOS：メディアセキュリティキー管理プロトコルは、任意の新しい重要なサービス拒否の脆弱性を導入してはならない（例えば、プロトコルは、クライアントが要求を検証したり承認することができることなしにCPU集中型の操作を実行するエンドポイントを要求するべきではありません） 。
R-EXISTING: The media security key management protocol SHOULD allow endpoints to authenticate using pre-existing cryptographic credentials, e.g., certificates or pre-shared keys.
R-既存：メディアセキュリティキー管理プロトコルは、エンドポイントは、既存の暗号の認証情報、例えば、証明書または事前共有キーを使用して認証できるようにする必要があります。
R-AGILITY: The media security key management protocol MUST provide crypto- agility, i.e., the ability to adapt to evolving cryptography and security requirements (update of cryptographic algorithms without substantial disruption to deployed implementations).
R-AGILITY：メディアセキュリティ鍵管理プロトコル、すなわち、暗号化およびセキュリティ要件（展開の実装に相当な中断なしに暗号アルゴリズムの更新）進化に適応する能力をクリプト敏捷性を提供しなければなりません。
R-DOWNGRADE: The media security key management protocol MUST protect cipher suite negotiation against downgrading attacks.
R-DOWNGRADE：メディアセキュリティキー管理プロトコルがダウングレード攻撃から暗号スイートのネゴシエーションを保護する必要があります。
R-PASS-MEDIA: The media security key management protocol MUST have a mode that prevents a passive adversary with access to the media path from gaining access to keying material used to protect SRTP media packets.
R-PASS-MEDIA：メディアセキュリティ鍵管理プロトコルは、SRTPメディアパケットを保護するために使用される鍵材料にアクセスするからメディアパスへのアクセスを受動攻撃を防止モードがなければなりません。
R-PASS-SIG: The media security key management protocol MUST have a mode in which it prevents a passive adversary with access to the signaling path from gaining access to keying material used to protect SRTP media packets.
R-PASS-SIG：メディアセキュリティ鍵管理プロトコルは、SRTPメディアパケットを保護するために使用される鍵材料にアクセスするからシグナリング経路へのアクセスを受動攻撃を防止するモードを持っていなければなりません。
R-SIG-MEDIA: The media security key management protocol MUST have a mode in which it defends itself from an attacker that is solely on the media path and from an attacker that is solely on the signaling path. A successful attack refers to the ability for the adversary to obtain keying material to decrypt the SRTP encrypted media traffic.
R-SIG-MEDIA：メディアセキュリティ鍵管理プロトコルは、単にメディア経路上とのみシグナリングパス上にある攻撃者からの攻撃者から自分自身を守るのモードを持たなければなりません。攻撃が成功すると、SRTP暗号化されたメディアトラフィックを復号化する鍵材料を得るために敵のための能力を指します。
R-ID-BINDING: The media security key management protocol MUST enable the media security keys to be cryptographically bound to an identity of the endpoint.
R-ID-BINDING：メディアセキュリティキー管理プロトコルは、暗号エンドポイントのアイデンティティにバインドするメディアのセキュリティキーを有効にする必要があります。
Note: This allows domains to deploy SIP Identity [RFC4474].
注意：これは、ドメインがSIPアイデンティティ[RFC4474]を展開することができます。
R-ACT-ACT: The media security key management protocol MUST support a mode of operation that provides active-signaling-active-media-detect robustness, and MAY support modes of operation that provide lower levels of robustness (as described in Section 3).
R-ACT-ACT：メディアセキュリティ鍵管理プロトコルは、ロバスト性をアクティブシグナリング活性メディア検出提供する動作モードをサポートしなければならない、そして（3章に記載されているように）堅牢性の低いレベルを提供する動作モードをサポートするかもしれ。
Note: Failing to meet R-ACT-ACT indicates the protocol cannot
provide secure end-to-end media.
The requirements in this section are for an overall VoIP security system. These requirements can be met within the key management protocol itself, or can be solved outside of the key management protocol itself (e.g., solved in SIP or in SDP).
このセクションの要件は、全体的なVoIPセキュリティシステムのためのものです。これらの要件は、鍵管理プロトコル自体の中で満たすことができる、又は（例えば、SIPまたはSDPに溶解）鍵管理プロトコル自体の外に解決することができます。
R-BEST-SECURE: Even when some endpoints of a forked or retargeted call are incapable of using SRTP, a solution MUST be described that allows the establishment of SRTP associations with SRTP-capable endpoints and/or RTP associations with non-SRTP-capable endpoints.
R-BEST-SECURE：二股又はリターゲットコールの一部のエンドポイントは、SRTPを使用することができない場合であっても、溶液が記載されなければならない非SRTP対応とSRTP対応エンドポイント及び/又はRTPの関連でSRTPアソシエーションの確立を可能にしますエンドポイント。
R-OTHER-SIGNALING: A solution SHOULD be able to negotiate keys for SRTP sessions created via different call signaling protocols (e.g., between Jabber, SIP, H.323, Media Gateway Control Protocol (MGCP).
R-OTHER-SIGNALING：溶液は、Jabberの、SIP、H.323、メディアゲートウェイ制御プロトコル（MGCP）の間で、例えば異なるコールシグナリングプロトコル（SRTPを介して作成されたセッションのための鍵を交渉することができるべきです。
R-RECORDING: A solution SHOULD be described that supports recording of decrypted media. This requirement comes from Section 4.3.
R-RECORDING：溶液を復号メディアの記録をサポートする記述されるべきです。この要件は、4.3節から来ています。
R-TRANSCODER: A solution SHOULD be described that supports intermediate nodes (e.g., transcoders), terminating or processing media, between the endpoints.
Rトランスコーダ：ソリューションは、エンドポイント間で、メディアを終了または処理、中間ノード（例えば、トランスコーダ）をサポートしていることを記載します。
R-ALLOW-RTP: A solution SHOULD be described that allows RTP media to be received by the calling party until SRTP has been negotiated with the answerer, after which SRTP is preferred over RTP.
R-ALLOW-RTP：SRTPは、SRTPは、RTP好まされた後に回答、と交渉されるまで、RTPメディアは、発呼者によって受信されることを可能にするという解決策が記述されるべきです。
This document lists requirements for securing media traffic. As such, it addresses security throughout the document.
この文書では、メディアトラフィックを保護するための要件を示します。このように、それは文書全体のセキュリティに対応しています。
For contributions to the requirements portion of this document, the authors would like to thank the active participants of the RTPSEC BoF and on the RTPSEC mailing list, and a special thanks to Steffen Fries and Dragan Ignjatic for their excellent MIKEY comparison [RFC5197] document.
このドキュメントの要件部分への貢献のために、著者は、その優れたMIKEY比較[RFC5197]ドキュメントのRTPSECのBoFとRTPSECメーリングリスト上、およびステファンフライドポテトに特別な感謝とドラガンIgnjaticの積極的な参加者に感謝したいと思います。
The authors would furthermore like to thank the following people for their review, suggestions, and comments: Flemming Andreasen, Richard Barnes, Mark Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath Dondeti, John Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer Holmberg, Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic, Cullen Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David McGrew, David Oran, Colin Perkins, Eric Raymond, Eric Rescorla, Peter Schneider, Frank Shearar, Srinath Thiruvengadam, Dave Ward, Dan York, and Phil Zimmermann.
フレミングAndreasenの、リチャード・バーンズ、マーク・Baugher、ヴォルフガングBuecker、ヴェルナーDittmann、Lakshminath Dondeti、ジョンエルウェル、マーティンEUCHNER、ハンス・ハインリッヒGrusdt、クリステルHolmbergの：著者は、さらに彼らのレビュー、提案、コメントについて以下の方々に感謝したいと思います、ギュンター・ホーン、ピーター・ハワード、レオ黄、ドラガンIgnjatic、カレン・ジェニングス、アラン・ジョンストン、のVesa Lehtovirta、マット・Lepinski、デビッドマグリュー、デヴィッドオラン、コリンパーキンス、エリック・レイモンド、エリックレスコラ、ピーター・シュナイダー、フランクShearar、Srinath Thiruvengadam、デイブウォード、ダン・ニューヨーク、そしてフィル・ジマーマン。
[FIPS-140-2] NIST, "Security Requirements for Cryptographic Modules", June 2005, <http://csrc.nist.gov/ publications/fips/fips140-2/fips1402.pdf>.
[FIPS-140-2] NIST、 "暗号モジュールのセキュリティ要件"、2005年6月、<http://csrc.nist.gov/出版/ FIPS / FIPS140-2 / fips1402.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[AISITSEC] Bundesamt fuer Sicherheit in der Informationstechnik [Federal Office of Information Security - Germany], "Anwendungshinweise und Interpretationen (AIS) zu ITSEC", January 2002, <http://www.bsi.de/zertifiz/zert/interpr/ aisitsec.htm>.
[AISITSEC]情報セキュリティのための連邦庁[情報セキュリティの連邦オフィス - ドイツ]「ITSECへのアプリケーションノートと解釈（AIS）」、2002年1月<http://www.bsi.de/zertifiz/zert/interpr/ > aisitsec.htm。
[DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, October 2008.
[DTLS-SRTP]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）拡張セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するために」、進歩、2008年10月の作業。
[EARLY-MEDIA] Stucker, B., "Coping with Early Media in the Session Initiation Protocol (SIP)", Work in Progress, October 2006.
[EARLY-MEDIA] Stucker、B.、進歩、2006年10月に作品 "セッション開始プロトコル（SIP）で早期のメディアへの対応"。
[EKT] McGrew, D., "Encrypted Key Transport for Secure RTP", Work in Progress, July 2007.
[EKT]マグリュー、D.、 "セキュアRTPのための暗号化キー交通"、進歩、2007年7月の作業。
[H.248.1] ITU, "Gateway control protocol", Recommendation H.248, June 2000, <http://www.itu.int/rec/T-REC-H.248/e>.
【H.248.1] ITU、 "ゲートウェイ制御プロトコル"、勧告H.248、2000年6月、<http://www.itu.int/rec/T-REC-H.248/e>。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書」、進歩、2007年10月の作業。
[MIDDLEBOX] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, July 2008.
[ミドル] Stucker、B.およびH. Tschofenig、「メディアの経路に沿ってシグナリングプロトコルの通信のためのミドル相互作用の分析」、進歩、2008年7月に作業。
[MIKEY-ECC] Milne, A., "ECC Algorithms for MIKEY", Work in Progress, June 2007.
[MIKEY-ECC]ミルン、A.、 "MIKEYのためのECCアルゴリズム"、進歩、2007年6月に作業。
[MIKEYv2] Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, revisited", Work in Progress, March 2007.
[MIKEYv2] Dondeti、L.、 "MIKEYv2：再訪MIKEYを使用して、SRTPキー管理"、進歩、2007年3月に作業。
[MULTIPART] Wing, D. and C. Jennings, "Session Initiation Protocol (SIP) Offer/Answer with Multipart Alternative", Work in Progress, March 2006.
[MULTIPART]ウイング、D.およびC.ジェニングス、 "マルチパートの代替とセッション開始プロトコル（SIP）オファー/回答"、進歩、2006年3月での作業。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326] Schulzrinneと、H.、オラン、D.、およびG.カマリロ、RFC 3326 "セッション開始プロトコル（SIP）理由ヘッダーフィールド" 2002年12月。
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
"電話用のセッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ" [RFC3372] Vemuri、A.およびJ.ピーターソン、BCP 63、RFC 3372、2002年9月。
[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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492]ブレイク・ウィルソン、S.、Bolyard、N.、グプタ、V.、ホーク、C.、およびB.メラー、 "楕円曲線暗号（ECC）暗号スイートトランスポート層セキュリティ（TLS）のための"、RFC 4492 、2006年5月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（SDP）のセキュリティの説明"、RFC 4568、2006年7月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650] EUCHNER、M.、 "マルチメディアインターネットキーイングのためのHMAC-認証済みのDiffie-Hellmanの（MIKEY）"、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.林、 "MIKEY-RSA-R：マルチメディアインターネットキーイング（マイキー）で鍵配布の追加モード"、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は、RFC 4771、2007年1月 "整合性は、セキュアリアルタイム転送プロトコル（SRTP）のためのロールオーバーカウンターを運ぶトランスフォーム"。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]エルウェル、J.、 "セッション開始プロトコル（SIP）に接続アイデンティティ"、RFC 4916、2007年6月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
[RFC4949] Shirey、R.、 "インターネットセキュリティ用語集、バージョン2"、FYI 36、RFC 4949、2007年8月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027]アンドレア、F.とD.ウィング、 "セキュリティの前提条件セッションの記述プロトコル（SDP）メディアストリーム"、RFC 5027、2007年10月。
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008.
[RFC5197]フリース、RFC 5197、2008年6月 "多様なマルチメディアインターネットキーイング（MIKEY）モードと拡張機能の適用について" S.及びD. Ignjatic、。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[SDP-CAP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2008.
[SDP-CAP]アンドレア、F.、 "SDP機能ネゴシエーション"、進歩、2008年7月に作業。
[SDP-DH] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", Work in Progress, February 2006.
[SDP-DH] Baugher、M.とD.マグリュー、 "マルチメディアセッションのためのDiffie-Hellman交換"、進歩、2006年2月に作業。
[SIP-CERTS] Jennings, C. and J. Fischl, "Certificate Management Service for The Session Initiation Protocol (SIP)", Work in Progress, November 2008.
[SIP-CERTS]ジェニングス、C.とJ. Fischl、 "セッション開始プロトコル（SIP）のための証明書管理サービス"、進歩、2008年11月の作業。
[SIP-DTLS] Fischl, J., "Datagram Transport Layer Security (DTLS) Protocol for Protection of Media Traffic Established with the Session Initiation Protocol", Work in Progress, July 2007.
[SIP-DTLS] Fischl、J.、「セッション開始プロトコルに設立メディアトラフィックの保護のためのデータグラムトランスポート層セキュリティ（DTLS）議定書」、進歩、2007年7月の作業。
[SRTP-KEY] Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Johnston, "Secure Media Recording and Transcoding with the Session Initiation Protocol", Work in Progress, October 2008.
[SRTP-KEY]ウイング、D.、Audet、F.、フライドポテト、S.、Tschofenig、H.、およびA.ジョンストン、 "セキュアメディアの記録とセッション開始プロトコルとトランスコーディング"、進歩、2008年10月の作業。
[ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, February 2009.
[ZRTP]ツィンマーマン、P.、ジョンストン、A.、およびJ.カラス、 "ZRTP：セキュアRTPのためのメディアパス鍵合意"、進歩、2009年2月に作業。
Appendix A. Overview and Evaluation of Existing Keying Mechanisms
既存のキーイング機構の付録A.概要と評価
Based on how the SRTP keys are exchanged, each SRTP key exchange mechanism belongs to one general category:
SRTPキーが交換されているかに基づいて、各SRTP鍵交換メカニズムは、1つの一般的なカテゴリに属します：
signaling path: All the keying is carried in the call signaling (SIP or SDP) path.
シグナリングパス：すべてのキーは、コールシグナリング（SIPやSDP）の経路で搬送されます。
media path: All the keying is carried in the SRTP/SRTCP media path, and no signaling whatsoever is carried in the call signaling path.
メディアパス：すべてのキーは、SRTP / SRTCPのメディアパスで運ばれ、そして何のシグナリングは一切コールシグナリングパスで運ばれていません。
signaling and media path: Parts of the keying are carried in the SRTP/SRTCP media path, and parts are carried in the call signaling (SIP or SDP) path.
シグナリングおよびメディアパス：キーの部分はSRTP / SRTCP媒体経路で搬送され、部品がコールシグナリング（SIPやSDP）パスで運ばれます。
One of the significant benefits of SRTP over other end-to-end encryption mechanisms, such as for example IPsec, is that SRTP is bandwidth efficient and SRTP retains the header of RTP packets. Bandwidth efficiency is vital for VoIP in many scenarios where access bandwidth is limited or expensive, and retaining the RTP header is important for troubleshooting packet loss, delay, and jitter.
例えばIPsecのような他のエンド・ツー・エンドの暗号化メカニズム、上SRTPの重要な利点の一つは、SRTPは、効率的な帯域幅であり、SRTPは、RTPパケットのヘッダを保持することです。帯域幅の効率がアクセス帯域幅が制限されたり、高価であり、RTPヘッダを保持することは、トラブルシューティングのパケット損失、遅延、およびジッタのために重要である多くのシナリオではVoIPに不可欠です。
Related to SRTP's characteristics is a goal that any SRTP keying mechanism to also be efficient and not cause additional call setup delay. Contributors to additional call setup delay include network or database operations: retrieval of certificates and additional SIP or media path messages, and computational overhead of establishing keys or validating certificates.
任意のSRTPキーイングメカニズムはまた、効率的で、追加のコールセットアップ遅延を起こさないための目標は、SRTPの特性にある関連します。証明書と追加のSIPまたはメディアパスメッセージの検索、およびキーを確立又は証明書を検証する計算オーバーヘッド：追加のコールセットアップ遅延に貢献は、ネットワークまたはデータベース操作を含みます。
When examining the choice between keying in the signaling path, keying in the media path, or keying in both paths, it is important to realize the media path is generally "faster" than the SIP signaling path. The SIP signaling path has computational elements involved that parse and route SIP messages. The media path, on the other hand, does not normally have computational elements involved, and even when computational elements such as firewalls are involved, they cause very little additional delay. Thus, the media path can be useful for exchanging several messages to establish SRTP keys. A disadvantage of keying over the media path is that interworking different key exchange requires the interworking function be in the media path, rather than just in the signaling path; in practice, this involvement is probably unavoidable anyway.
、シグナリングパスをキー入力メディアパスをキー入力、または両方のパスをキー入力の間の選択を検討する際には、メディアパスは、SIPシグナリング経路より一般的に「速い」であると認識することが重要です。 SIPシグナリング経路は、解析およびルートSIPメッセージことが関与する計算要素を有します。メディアパスは、他の一方で、正常に関与計算要素を持っていない、とファイアウォールなどの計算要素が関与している場合でも、彼らは非常に少ない追加の遅延を引き起こします。このように、メディアパスは、SRTPキーを確立するために、いくつかのメッセージを交換するのに役立ちます。媒体経路上キーイングの欠点は、異なる鍵交換を連動するインターワーキング機能ではなく単にシグナリングパスに比べて、媒体経路にある必要があることです。実際には、この関与はとにかくおそらく避けられません。
A.1. Signaling Path Keying Techniques
A.1。シグナリングパスキーイングテクニック
A.1.1. MIKEY-NULL
A.1.1。 MIKEY、NULL
MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both directions. The key is sent unencrypted in SDP, which means the SDP must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to-end (e.g., by using Secure/Multipurpose Internet Mail Extensions (S/MIME)).
MIKEY-NULL [RFC3830]は申出が両方向のためのSRTPキーを示しています。キーは、SDPは、セキュア/多目的インターネットメール拡張機能を使用することによって、またはエンドツーエンドの例（（TLS（SIPS）を使用することにより、例えば）ホップバイホップを暗号化しなければならないことを意味するSDP、（S /で暗号化されずに送信されますMIME））。
MIKEY-NULL requires one message from offerer to answerer (half a round trip), and does not add additional media path messages.
MIKEY-NULLは（半分往復）を回答するオファー側から一つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。
A.1.2. MIKEY-PSK
A.1.2。 MIKEY-PSK
MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints share one common key. MIKEY-PSK has the offerer encrypt the SRTP keys for both directions using this pre-shared key.
MIKEY-PSK（事前共有鍵）[RFC3830]は、すべてのエンドポイントは、一つの共通鍵を共有することを要求します。 MIKEY-PSKは、この事前共有キーを使用して、両方向のためのSRTP鍵暗号化オファーを有します。
MIKEY-PSK requires one message from offerer to answerer (half a round trip), and does not add additional media path messages.
MIKEY-PSKは、（半分往復）を回答するオファー側から一つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。
A.1.3. MIKEY-RSA
A.1.3。 MIKEY-RSA
MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both directions using the intended answerer's public key, which is obtained from a mechanism outside of MIKEY.
MIKEY-RSA [RFC3830]はMIKEYの外部機構から得られる意図回答者の公開鍵を使用して、両方向のキー暗号化オファーを有します。
MIKEY-RSA requires one message from offerer to answerer (half a round trip), and does not add additional media path messages. MIKEY-RSA requires the offerer to obtain the intended answerer's certificate.
MIKEY-RSAは（半分往復）を回答するオファー側から一つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。 MIKEY-RSAは、意図した回答者の証明書を取得するために、オファーを必要とします。
A.1.4. MIKEY-RSA-R
A.1.4。 MIKEY-RSA-R
MIKEY-RSA-R [RFC4738] is essentially the same as MIKEY-RSA but reverses the role of the offerer and the answerer with regards to providing the keys. That is, the answerer encrypts the keys for both directions using the offerer's public key. Both the offerer and answerer validate each other's public keys using a standard X.509 validation techniques. MIKEY-RSA-R also enables sending certificates in the MIKEY message.
MIKEY-RSA-R [RFC4738]は、本質的にMIKEY-RSAと同じであるが、キーを提供することに関して提供者の役割と回答を反転させます。つまり、回答は、オファー側の公開鍵を使用して、両方向のためのキーを暗号化します。オファー側とアンサーの両方が標準X.509検証技術を使用して、互いの公開鍵を検証します。 MIKEY-RSA-Rもマイキーメッセージで証明書を送信できます。
MIKEY-RSA-R requires one message from offerer to answer, and one message from answerer to offerer (full round trip), and does not add additional media path messages. MIKEY-RSA-R requires the offerer validate the answerer's certificate.
MIKEY-RSA-Rは、オファー（フル往復）に答えるために、オファーから一つのメッセージ、および回答から一つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。 MIKEY-RSA-Rは、オファー側は、回答者の証明書を検証が必要です。
A.1.5. MIKEY-DHSIGN
A.1.5。 MIKEY-DHSIGN
In MIKEY-DHSIGN [RFC3830], the offerer and answerer derive the key from a Diffie-Hellman (DH) exchange. In order to prevent an active man-in-the-middle, the DH exchange itself is signed using each endpoint's private key and the associated public keys are validated using standard X.509 validation techniques.
MIKEY-DHSIGN [RFC3830]において、申出と回答は、ディフィー・ヘルマン（DH）交換から鍵を導出します。アクティブのman-in-the-middleを防止するために、DH交換自体は、各エンドポイントの秘密鍵を用いて署名され、関連する公開鍵は、標準X.509検証技術を使用して検証されます。
MIKEY-DHSIGN requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages. MIKEY-DHSIGN requires the offerer and answerer to validate each other's certificates. MIKEY-DHSIGN also enables sending the answerer's certificate in the MIKEY message.
MIKEY-DHSIGNは、オファー（フル往復）に回答するオファー側から一つのメッセージ、および回答から一つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。 MIKEY-DHSIGNは、互いの証明書を検証するために、オファーや回答が必要です。 MIKEY-DHSIGNもマイキーメッセージで回答者の証明書を送信することができます。
A.1.6. MIKEY-DHHMAC
A.1.6。 MIKEY-DHHMAC
MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie-Hellman exchange, essentially combining aspects of MIKEY-PSK with MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for certificate authentication.
MIKEY-DHHMAC [RFC4650]は基本的になく、証明書認証のためのMIKEY-DHSIGNの必要がなく、MIKEY-DHSIGNとマイキー-PSKの態様を組み合わせた、のDiffie-Hellman交換HMACに事前共有秘密を使用しています。
MIKEY-DHHMAC requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
MIKEY-DHHMACは、オファー（フル往復）に回答するオファー側から一つのメッセージ、および回答から一つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC)
A.1.7。 MIKEY-ECIESとMIKEY-ECMQV（MIKEY-ECC）
ECC Algorithms For MIKEY [MIKEY-ECC] describes how ECC can be used with MIKEY-RSA (using Elliptic Curve Digital Signature Algorithm (ECDSA) signature) and with MIKEY-DHSIGN (using a new DH-Group code), and also defines two new ECC-based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) .
MIKEY [MIKEY-ECC]についてECCアルゴリズムは、ECCは、（新しいDHグループ・コードを使用して）MIKEY-DHSIGNとMIKEY-RSA（使用して楕円曲線デジタル署名アルゴリズム（ECDSA）署名）と一緒に使用することができる方法を説明し、また両者を定義します新しいECCベースのアルゴリズム、楕円曲線統合暗号化スキーム（ECIES）と楕円曲線メネゼス - ク-Vanstone著（ECMQV）。
With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group code function exactly like MIKEY-DHSIGN. Therefore, these ECC mechanisms are not discussed separately in this document.
この提案、正確MIKEY-RSAなどのECDSA署名、MIKEY-ECIES、およびMIKEY-ECMQV機能、および正確MIKEY-DHSIGNのような新しいDH-グループコード機能付。したがって、これらのECCメカニズムは、本書では別々に説明しません。
A.1.8. SDP Security Descriptions with SIPS
A.1.8。 SIPSとSDPセキュリティ記述
SDP Security Descriptions [RFC4568] have each side indicate the key they will use for transmitting SRTP media, and the keys are sent in the clear in SDP. SDP Security Descriptions rely on hop-by-hop (TLS via "SIPS:") encryption to protect the keys exchanged in signaling.
SDPセキュリティ記述[RFC4568]各側面を持っているが、彼らがSRTPメディアを送信するために使用するキーを示しており、キーはSDPに平文で送信されます。暗号化シグナリングに交換されたキーを保護するために：SDPセキュリティの説明（「SIPS」を介してTLS）をホップバイホップに頼っています。
SDP Security Descriptions requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
SDPセキュリティ記述は、回答するオファー側から一つのメッセージを必要とし、回答からオファー側（フル往復）への1つのメッセージ、および追加のメディアパスメッセージを追加しません。
A.1.9. SDP Security Descriptions with S/MIME
A.1.9。 S / MIMEとSDPセキュリティ記述
This keying mechanism is identical to Appendix A.1.8 except that, rather than protecting the signaling with TLS, the entire SDP is encrypted with S/MIME.
このキーイング機構ではなくTLS、全体SDPとのシグナリングがS / MIMEで暗号化され保護よりも、それ以外の付録A.1.8と同一です。
A.1.10. SDP-DH (Expired)
A.1.10。 SDP-DH（期限切れ）
SDP Diffie-Hellman [SDP-DH] exchanges Diffie-Hellman messages in the signaling path to establish session keys. To protect against active man-in-the-middle attacks, the Diffie-Hellman exchange needs to be protected with S/MIME, SIPS, or SIP Identity [RFC4474] and SIP Connected Identity [RFC4916].
セッションキーを確立するためのシグナリング経路におけるSDPディフィー - ヘルマン[SDP-DH]交換のDiffie-Hellmanメッセージ。アクティブman-in-the-middle攻撃から保護するために、のDiffie-Hellman交換は、S / MIME、SIPS、またはSIPアイデンティティ[RFC4474]とアイデンティティ[RFC4916]接続されたSIPで保護する必要があります。
SDP-DH requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
SDP-DHは、オファー（フル往復）に回答するオファー側から一つのメッセージ、および回答から一つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。
A.1.11. MIKEYv2 in SDP (Expired)
A.1.11。 SDPでMIKEYv2（期限切れ）
MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the time synchronization requirement. It therefore now takes 2 round trips to complete. In the first round trip, the communicating parties learn each other's identities, agree on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces for replay protection. In the second round trip, they negotiate unicast and/or group SRTP context for SRTP and/or SRTCP.
MIKEYv2は[MIKEYv2] MIKEYv1にモードネゴシエーションを追加し、時刻同期の要件を削除します。したがって、今、完了するまでに2ラウンドトリップを取ります。最初のラウンドトリップでは、通信当事者が互いのアイデンティティを学び、MIKEYモード、暗号化アルゴリズム、SRTPポリシーに同意し、リプレイ保護のためにナンスを交換します。第二ラウンドトリップで、それらは、SRTPおよび/またはSRTCPのためのユニキャスト及び/又はグループSRTPコンテキストをネゴシエート。
Furthermore, MIKEYv2 also defines an in-band negotiation mode as an alternative to SDP (see Appendix A.3.3).
さらに、MIKEYv2はまた、SDP（付録A.3.3を参照）の代替として、インバンドネゴシエーションモードを定義します。
A.2. Media Path Keying Technique
A.2。メディアパスの技術をキーイング
A.2.1. ZRTP
A.2.1。 ZRTP
ZRTP [ZRTP] does not exchange information in the signaling path (although it's possible for endpoints to exchange a hash of the ZRTP Hello message with "a=zrtp-hash" in the initial offer if sent over an integrity-protected signaling channel. This provides some useful correlation between the signaling and media layers). In ZRTP, the keys are exchanged entirely in the media path using a Diffie-Hellman exchange. The advantage to this mechanism is that the signaling channel is used only for call setup and the media channel is used to establish an encrypted channel -- much like encryption devices on the
ZRTPは[ZRTP]整合性が保護シグナリングチャネルを介して送信された場合、エンドポイントは、最初のオファーに「A = ZRTP-ハッシュ」とZRTP Helloメッセージのハッシュを交換することが可能ですが、（シグナリングパスで情報を交換しません。これを）シグナリングおよびメディア層の間にいくつかの有用な相関を提供します。 ZRTPでは、キーがのDiffie-Hellman交換を使用して、メディアパスに完全に交換されます。ずっと上の暗号化デバイスのように - このメカニズムの利点は、シグナリングチャネルのみコールセットアップのために使用され、メディア・チャネルは暗号化されたチャネルを確立するために使用されていることです
PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange by having each person read digits or words to the other person. Subsequent sessions with the same ZRTP endpoint can be authenticated using the stored hash of the previously negotiated key rather than voice authentication. ZRTP uses four media path messages (Hello, Commit, DHPart1, and DHPart2) to establish the SRTP key, and three media path confirmation messages. These initial messages are all sent as non-RTP packets.
PSTN。 ZRTPは、一人一人が他の人に数字や言葉を読むことによってそののDiffie-Hellman交換の音声認証を使用しています。同じZRTPエンドポイントとの後続のセッションは、以前にネゴシエートされたキーではなく、音声認証の格納されたハッシュを使用して認証することができます。 ZRTPは、SRTPキー、および3つのメディアパスの確認メッセージを確立するために、4つのメディアパスメッセージ（こんにちは、コミット、DHPart1、およびDHPart2）を使用しています。これらの初期のメッセージは、すべての非RTPパケットとして送信されます。
Note: that when ZRTP probing is used, unencrypted RTP can be exchanged until the SRTP keys are established.
注：ZRTPプロービングを使用する場合SRTPキーが確立されるまで、暗号化されていないRTPを交換することができます。
A.3. Signaling and Media Path Keying Techniques
A.3。シグナリングとメディアパスキーイングテクニック
A.3.1. EKT
A.3.1。 ERA
EKT [EKT] relies on another SRTP key exchange protocol, such as SDP Security Descriptions or MIKEY, for bootstrapping. In the initial phase, each member of a conference uses an SRTP key exchange protocol to establish a common key encryption key (KEK). Each member may use the KEK to securely transport its SRTP master key and current SRTP rollover counter (ROC), via RTCP, to the other participants in the session.
EKTは[EKT】ブートストラップのために、そのようなSDPセキュリティ記述又はMIKEYように、別のSRTP鍵交換プロトコルに依存しています。初期段階では、会議の各メンバーは、共通鍵暗号鍵（KEK）を確立するために、SRTP鍵交換プロトコルを使用します。各部材は、RTCPを介して、セッションの他の参加者に安全そのSRTPマスタ鍵と現在のSRTPロールオーバーカウンター（ROC）を輸送するためにKEKを使用してもよいです。
EKT requires the offerer to send some parameters (EKT_Cipher, KEK, and security parameter index (SPI)) via the bootstrapping protocol such as SDP Security Descriptions or MIKEY. Each answerer sends an SRTCP message that contains the answerer's SRTP Master Key, rollover counter, and the SRTP sequence number. Rekeying is done by sending a new SRTCP message. For reliable transport, multiple RTCP messages need to be sent.
EKTは、SDPセキュリティ記述又はMIKEYなどのブートストラッププロトコルを介していくつかのパラメータ（EKT_Cipher、KEK、およびセキュリティパラメータインデックス（SPI））を送信するオファーを必要とします。それぞれの回答は、回答者のSRTPマスターキー、ロールオーバーカウンタ、およびSRTPのシーケンス番号が含まれているSRTCPメッセージを送信します。鍵の再生成は、新たなSRTCPメッセージを送信することにより行われます。信頼性の高い輸送のために、複数のRTCPメッセージが送信される必要があります。
A.3.2. DTLS-SRTP
A.3.2。 DTLS、SRTP
DTLS-SRTP [DTLS-SRTP] exchanges public key fingerprints in SDP [SIP-DTLS] and then establishes a DTLS session over the media channel. The endpoints use the DTLS handshake to agree on crypto suites and establish SRTP session keys. SRTP packets are then exchanged between the endpoints.
DTLS-SRTP [DTLS-SRTP] SDPにおける公開鍵の指紋[SIP-DTLS]を交換した後、メディアチャネルを介してDTLSセッションを確立します。エンドポイントは、暗号スイートに同意し、SRTPセッション鍵を確立するためにDTLSハンドシェイクを使用します。 SRTPパケットはその後、エンドポイント間で交換されています。
DTLS-SRTP requires one message from offerer to answerer (half round trip), and one message from the answerer to offerer (full round trip) so the offerer can correlate the SDP answer with the answering endpoint. DTLS-SRTP uses four media path messages to establish the SRTP key.
DTLS-SRTPは、（半分往復）を回答するオファー側から一つのメッセージ、および回答からオファー側（フル往復）への1つのメッセージを必要とするので、オファー側は答えるエンドポイントとSDPの答えを関連付けることができます。 DTLS-SRTPは、SRTPキーを確立するために、4つのメディアパスメッセージを使用しています。
This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as its cipher suite, which is the mandatory-to-implement cipher suite in TLS [RFC5246].
この文書では、DTLSはTLS [RFC5246]に強制的に実装暗号スイートで、その暗号スイートとしてTLS_RSA_WITH_AES_128_CBC_SHAを使用する前提。
A.3.3. MIKEYv2 Inband (Expired)
A.3.3。 MIKEYv2インバンド（期限切れ）
As defined in Appendix A.1.11, MIKEYv2 also defines an in-band negotiation mode as an alternative to SDP (see Appendix A.3.3). The details are not sorted out in the document yet on what in-band actually means (i.e., UDP, RTP, RTCP, etc.).
付録A.1.11に定義されているように、MIKEYv2はまた、SDP（付録A.3.3を参照）の代替として、インバンドネゴシエーションモードを定義します。詳細はまだインバンド実際に（すなわち、UDP、RTP、RTCP、など）何を意味するのかについて文書で整理されていません。
A.4. Evaluation Criteria - SIP
A.4。評価基準 - SIP
This section considers how each keying mechanism interacts with SIP features.
このセクションでは、各キーのメカニズムは、SIP機能と対話する方法を考えています。
A.4.1. Secure Retargeting and Secure Forking
A.4.1。セキュアなリターゲットとセキュアフォーク
Retargeting and forking of signaling requests is described within Section 4.2. The following builds upon this description.
リターゲッティングおよびシグナリング要求のフォークはセクション4.2で記載されています。以下は、この説明に基づいて構築します。
The following list compares the behavior of secure forking, answering association, two-time pads, and secure retargeting for each keying mechanism.
以下のリストは、各キーイングメカニズムの関連付け、2回のパッド、およびセキュアなリターゲットに答える、安全なフォークの行動を比較します。
MIKEY-NULL Secure Forking: No, all AORs see offerer's and answerer's keys. Answer is associated with media by the SSRC in MIKEY. Additionally, a two-time pad occurs if two branches choose the same 32-bit SSRC and transmit SRTP packets.
MIKEY-NULLセキュアフォーク：いいえ、すべてのAORは、提供者の回答とのキーを参照してください。回答は、MIKEYでSSRCによってメディアに関連付けられています。二つの分岐は、同じ32ビットのSSRCを選択し、SRTPパケットを送信する場合に加えて、2回のパッドが発生します。
Secure Retargeting: No, all targets see offerer's and answerer's keys. Suffers from retargeting identity problem.
セキュアなリターゲティング：いいえ、すべてのターゲットは、提供者の回答とのキーを参照してください。アイデンティティの問題をリターゲッティングに苦しんでいます。
MIKEY-PSK Secure Forking: No, all AORs see offerer's and answerer's keys. Answer is associated with media by the SSRC in MIKEY. Note that all AORs must share the same pre-shared key in order for forking to work at all with MIKEY-PSK. Additionally, a two-time pad occurs if two branches choose the same 32-bit SSRC and transmit SRTP packets.
MIKEY-PSKセキュアフォーク：いいえ、すべてのAORは、提供者の回答とのキーを参照してください。回答は、MIKEYでSSRCによってメディアに関連付けられています。すべてのAORはMIKEY-PSKとは全く仕事にフォークために同じ事前共有キーを共有しなければならないことに注意してください。二つの分岐は、同じ32ビットのSSRCを選択し、SRTPパケットを送信する場合に加えて、2回のパッドが発生します。
Secure Retargeting: Not secure. For retargeting to work, the final target must possess the correct PSK. As this is likely in scenarios where the call is targeted to another device belonging to the same user (forking), it is very unlikely that other users will possess that PSK and be able to successfully answer that call.
セキュアなリターゲット：安全ではありません。再標的が機能するためには、最終的な目標は、正しいPSKを持っていなければなりません。これは、コールが同じユーザ（フォーク）に属する別のデバイスを対象としたシナリオでそうであるように、他のユーザーがそのPSKを保有し、成功しているコールに応答できるようになることはほとんどありません。
MIKEY-RSA Secure Forking: No, all AORs see offerer's and answerer's keys. Answer is associated with media by the SSRC in MIKEY. Note that all AORs must share the same private key in order for forking to work at all with MIKEY-RSA. Additionally, a two-time pad occurs if two branches choose the same 32-bit SSRC and transmit SRTP packets.
MIKEY-RSAセキュアフォーク：いいえ、すべてのAORは、提供者の回答とのキーを参照してください。回答は、MIKEYでSSRCによってメディアに関連付けられています。すべてのAORはMIKEY-RSAとまったく機能してフォークために同じ秘密鍵を共有しなければならないことに注意してください。二つの分岐は、同じ32ビットのSSRCを選択し、SRTPパケットを送信する場合に加えて、2回のパッドが発生します。
Secure Retargeting: No.
セキュアなリターゲット：いいえ。
MIKEY-RSA-R Secure Forking: Yes, answer is associated with media by the SSRC in MIKEY.
MIKEY-RSA-Rフォークを固定：はい、答えはMIKEYでSSRCによってメディアに関連付けられています。
Secure Retargeting: Yes.
セキュアなリターゲット：はい。
MIKEY-DHSIGN Secure Forking: Yes, each forked endpoint negotiates unique keys with the offerer for both directions. Answer is associated with media by the SSRC in MIKEY.
MIKEY-DHSIGNセキュアフォーク：はい、各フォークエンドポイントは、両方向のための申し出人とのユニークなキーをネゴシエートします。回答は、MIKEYでSSRCによってメディアに関連付けられています。
Secure Retargeting: Yes, each target negotiates unique keys with the offerer for both directions.
セキュアなリターゲティング：はい、各ターゲットが両方向のための申し出人とのユニークなキーをネゴシエートします。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDPでMIKEYv2挙動が選ばれているモードによって異なります。
MIKEY-DHHMAC Secure Forking: Yes, each forked endpoint negotiates unique keys with the offerer for both directions. Answer is associated with media by the SSRC in MIKEY.
MIKEY-DHHMACセキュアフォーク：はい、各フォークエンドポイントは、両方向のための申し出人とのユニークなキーをネゴシエートします。回答は、MIKEYでSSRCによってメディアに関連付けられています。
Secure Retargeting: Yes, each target negotiates unique keys with the offerer for both directions. Note that for the keys to be meaningful, it would require the PSK to be the same for all the potential intermediaries, which would only happen within a single domain.
セキュアなリターゲティング：はい、各ターゲットが両方向のための申し出人とのユニークなキーをネゴシエートします。キーは有意義であるために、それが唯一の単一ドメイン内で起こるすべての潜在的な仲介のために同じになるようにPSKを必要とすることに注意してください。
SDP Security Descriptions with SIPS Secure Forking: No, each forked endpoint sees the offerer's key. Answer is not associated with media.
SIPSセキュアフォークとSDPセキュリティ記述：いいえ、各フォークエンドポイントは、オファー側のキーを見ています。回答は、メディアに関連付けられていません。
Secure Retargeting: No, each target sees the offerer's key.
セキュアなリターゲティング：いいえ、各ターゲットは、オファー側のキーを見ています。
SDP Security Descriptions with S/MIME Secure Forking: No, each forked endpoint sees the offerer's key. Answer is not associated with media.
S / MIMEセキュアフォークとSDPセキュリティ記述：いいえ、各フォークエンドポイントは、オファー側のキーを見ています。回答は、メディアに関連付けられていません。
Secure Retargeting: No, each target sees the offerer's key. Suffers from retargeting identity problem.
セキュアなリターゲティング：いいえ、各ターゲットは、オファー側のキーを見ています。アイデンティティの問題をリターゲッティングに苦しんでいます。
SDP-DH Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. Answer is not associated with media.
SDP-DHフォークを固定：はい、各フォークエンドポイントは、ユニークSRTPキーを計算します。回答は、メディアに関連付けられていません。
Secure Retargeting: Yes, the final target calculates a unique SRTP key.
セキュアなリターゲティング：はい、最終的な目標は、ユニークSRTPキーを計算します。
ZRTP Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. With the "a=zrtp-hash" attribute, the media can be associated with an answer.
ZRTPセキュアフォーク：はい、各フォークエンドポイントはユニークSRTPキーを計算します。 「= ZRTP-ハッシュ」属性を使用すると、メディアはその答えに関連付けることができます。
Secure Retargeting: Yes, the final target calculates a unique SRTP key.
セキュアなリターゲティング：はい、最終的な目標は、ユニークSRTPキーを計算します。
EKT Secure Forking: Inherited from the bootstrapping mechanism (the specific MIKEY mode or SDP Security Descriptions). Answer is associated with media by the SPI in the EKT protocol. Answer is associated with media by the SPI in the EKT protocol.
EKTセキュアフォーク：ブートストラップ・メカニズム（特定MIKEYモードまたはSDPセキュリティ記述）から継承されます。答えはEKTプロトコルでSPIにより、メディアに関連付けられています。答えはEKTプロトコルでSPIにより、メディアに関連付けられています。
Secure Retargeting: Inherited from the bootstrapping mechanism (the specific MIKEY mode or SDP Security Descriptions).
セキュアなリターゲット：ブートストラップ・メカニズム（特定MIKEYモードまたはSDPセキュリティ記述）から継承されます。
DTLS-SRTP Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. Answer is associated with media by the certificate fingerprint in signaling and certificate in the media path.
DTLS-SRTPセキュアフォーク：はい、各フォークエンドポイントはユニークSRTPキーを計算します。答えは媒体経路におけるシグナリング及び証明書に証明書のフィンガープリントによってメディアに関連付けられています。
Secure Retargeting: Yes, the final target calculates a unique SRTP key.
セキュアなリターゲティング：はい、最終的な目標は、ユニークSRTPキーを計算します。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2インバンドは、行動を採取されたモードによって異なります。
A.4.2. Clipping Media before SDP Answer
A.4.2。 SDP回答の前にメディアをクリッピング
Clipping media before receiving the signaling answer is described within Section 4.1. The following builds upon this description.
シグナリングの回答を受信する前にクリッピングメディアは、4.1節の中に記述されています。以下は、この説明に基づいて構築します。
Furthermore, the problem of clipping gets compounded when forking is used. For example, if using a Diffie-Hellman keying technique with security preconditions that forks to 20 endpoints, the call initiator would get 20 provisional responses containing 20 signed Diffie-Hellman half keys. Calculating 20 DH secrets and validating signatures can be a difficult task depending on the device capabilities.
フォークが使用されている場合さらに、クリッピングの問題が配合されます。例えば、20のエンドポイントへのフォークは、コールの開始者が20を含む20の暫定応答になるだろう、セキュリティの前提条件とのDiffie-Hellmanの鍵技術を使用した場合のDiffie-Hellman半分鍵に署名しました。 20のDH秘密を計算し、署名を検証することは、デバイスの機能に応じて困難な作業であることができます。
The following list compares the behavior of clipping before SDP answer for each keying mechanism.
以下のリストには、各キーイングメカニズムのためのSDP応答の前にクリッピングの行動を比較します。
MIKEY-NULL Not clipped. The offerer provides the answerer's keys.
MIKEY-NULLクリップされていません。オファー側は、回答者のキーが用意されています。
MIKEY-PSK Not clipped. The offerer provides the answerer's keys.
MIKEY-PSKクリップされていません。オファー側は、回答者のキーが用意されています。
MIKEY-RSA Not clipped. The offerer provides the answerer's keys.
MIKEY-RSAクリップされていません。オファー側は、回答者のキーが用意されています。
MIKEY-RSA-R Clipped. The answer contains the answerer's encryption key.
MIKEY-RSA-Rクリップされました。答えは、回答者の暗号化キーが含まれています。
MIKEY-DHSIGN Clipped. The answer contains the answerer's Diffie-Hellman response.
MIKEY-DHSIGNクリップされました。答えは、回答者のDiffie-Hellman応答が含まれています。
MIKEY-DHHMAC Clipped. The answer contains the answerer's Diffie-Hellman response.
MIKEY-DHHMACクリップされました。答えは、回答者のDiffie-Hellman応答が含まれています。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDPでMIKEYv2挙動が選ばれているモードによって異なります。
SDP Security Descriptions with SIPS Clipped. The answer contains the answerer's encryption key.
SIPSクリップされたとSDPセキュリティ記述。答えは、回答者の暗号化キーが含まれています。
SDP Security Descriptions with S/MIME Clipped. The answer contains the answerer's encryption key.
S / MIMEクリップされたとのSDPセキュリティ記述。答えは、回答者の暗号化キーが含まれています。
SDP-DH Clipped. The answer contains the answerer's Diffie-Hellman response.
SDP-DHクリップされました。答えは、回答者のDiffie-Hellman応答が含まれています。
ZRTP Not clipped because the session initially uses RTP. While RTP is flowing, both ends negotiate SRTP keys in the media path and then switch to using SRTP.
セッションが最初にRTPを使用しているためZRTPはクリップされていません。 RTPが流れている間に、両端が媒体経路におけるSRTPキーを交渉した後、SRTPを使用するように切り替えます。
EKT Not clipped, as long as the first RTCP packet (containing the answerer's key) is not lost in transit. The answerer sends its encryption key in RTCP, which arrives at the same time (or before) the first SRTP packet encrypted with that key.
EKT限り（回答者のキーを含む）最初のRTCPパケットが転送中に失われないよう、クリップされていません。回答は、（前か）が同時に到着したRTCPでの暗号化キー、そのキーで暗号化された最初のSRTPパケットを送信します。
Note: RTCP needs to work, in the answerer-to-offerer
direction, before the offerer can decrypt SRTP media.
DTLS-SRTP No clipping after the DTLS-SRTP handshake has completed. SRTP keys are exchanged in the media path. Need to wait for SDP answer to ensure DTLS-SRTP handshake was done with an authorized party.
DTLS-SRTP DTLS-SRTPハンドシェイクが完了した後ではありませんクリッピング。 SRTPキーはメディアパスで交換されています。 DTLS-SRTPのハンドシェイクが許可されたパーティーで行われたことを確認するためにSDP応答を待つ必要があります。
If a middlebox interferes with the media path, there can be
clipping [MIDDLEBOX].
MIKEYv2 Inband Not clipped. Keys are exchanged in the media path without relying on the signaling path.
MIKEYv2インバンドクリップされていません。キーは、シグナリングパスに頼ることなく、メディアパスに交換されます。
A.4.3. SSRC and ROC
A.4.3。 SSRCとROC
In SRTP, a cryptographic context is defined as the SSRC, destination network address, and destination transport port number. Whereas RTP, a flow is defined as the destination network address and destination transport port number. This results in a problem -- how to communicate the SSRC so that the SSRC can be used for the cryptographic context.
SRTPは、暗号コンテキストはSSRC、宛先ネットワークアドレス、及び宛先のトランスポートポート番号として定義されます。 RTP一方、フローは、宛先ネットワークアドレス及び宛先のトランスポートポート番号として定義されます。 SSRCは、暗号コンテキストのために使用することができるようにSSRCを通信する方法 - これが問題になります。
Two approaches have emerged for this communication. One, used by all MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY exchange. Another, used by SDP Security Descriptions, is to apply "late binding" -- that is, any new packet containing a previously unseen SSRC (which arrives at the same destination network address and destination transport port number) will create a new cryptographic context. Another approach, common amongst techniques with media-path SRTP key establishment, is to require a handshake over that media path before SRTP packets are sent. MIKEY's approach changes RTP's SSRC collision detection behavior by requiring RTP to pre-establish the SSRC values for each session.
2つのアプローチが、この通信のために浮上しています。全てMIKEYモードで使用されるものは、MIKEY交換においてピアにSSRCsを伝達することです。もう一つは、SDPセキュリティ記述で使用される、適用する「レイトバインディング」である - つまり、（同じ宛先ネットワークアドレスと送信先トランスポートポート番号に到着する）前に目に見えないSSRCを含む任意の新しいパケットは、新しい暗号化コンテキストを作成します。メディアパスSRTPキーの確立と技術の間で共通するもう一つの方法は、SRTPパケットが送信される前に、そのメディアパスオーバーハンドシェイクを必要とすることです。 MIKEYのアプローチは、各セッションのためのSSRC値を事前に確立するために、RTPを要求することにより、RTPのSSRC衝突検出動作を変更します。
Another related issue is that SRTP introduces a rollover counter (ROC), which records how many times the SRTP sequence number has rolled over. As the sequence number is used for SRTP's default ciphers, it is important that all endpoints know the value of the ROC. The ROC starts at 0 at the beginning of a session.
別の関連する問題は、SRTPがSRTPシーケンス番号はロールオーバーした回数を記録したロールオーバーカウンター（ROC）を、紹介するということです。シーケンス番号がSRTPのデフォルトの暗号のために使用されているとして、すべてのエンドポイントは、ROCの値を知ることが重要です。 ROCは、セッションの開始時に0から始まります。
Some keying mechanisms cause a two-time pad to occur if two endpoints of a forked call have an SSRC collision.
いくつかのキーイングメカニズムはフォークコールの2つのエンドポイントは、SSRCの衝突を持っている場合に発生するには、2つのタイムパッドを引き起こします。
Note: A proposal has been made to send the ROC value on every Nth SRTP packet[RFC4771]. This proposal has not yet been incorporated into this document.
注：この提案は、すべてのN番目のSRTPパケット[RFC4771]にROC値を送信するために行われています。この提案は、まだこの文書に組み込まれていません。
The following list examines handling of SSRC and ROC:
以下のリストは、SSRCとROCの取り扱いを調べます。
MIKEY-NULL Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-NULL各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
MIKEY-PSK Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-PSKは、各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
MIKEY-RSA Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-RSAは、各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
MIKEY-RSA-R Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-RSA-Rは、各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
MIKEY-DHSIGN Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-DHSIGNは、各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
MIKEY-DHHMAC Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEY-DHHMACは、各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
MIKEYv2 in SDP Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
SDPでMIKEYv2各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
SDP Security Descriptions with SIPS Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
SIPS SSRCもROCどちらとSDPセキュリティ記述が通知されます。 SSRC「遅延バインディング」が使用されます。
SDP Security Descriptions with S/MIME Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
S / MIME SSRCもROCどちらとSDPセキュリティ記述が通知されます。 SSRC「遅延バインディング」が使用されます。
SDP-DH Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
SDP-DH SSRCもROCどちらが通知されます。 SSRC「遅延バインディング」が使用されます。
ZRTP Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
ZRTP SSRCもROCどちらが通知されます。 SSRC「遅延バインディング」が使用されます。
EKT The SSRC of the SRTCP packet containing an EKT update corresponds to the SRTP master key and other parameters within that packet.
EKT更新を含むSRTCPパケットのEKTザSSRCは、そのパケット内のSRTPマスタ鍵および他のパラメータに対応します。
DTLS-SRTP Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
SSRCもROC DTLS-SRTPどちらが通知されます。 SSRC「遅延バインディング」が使用されます。
MIKEYv2 Inband Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
MIKEYv2インバンドは、各エンドポイントは、それが送信するSRTPパケットのSSRCs及びROCの集合を示します。
A.5. Evaluation Criteria - Security
A.5。評価基準 - セキュリティ
This section evaluates each keying mechanism on the basis of their security properties.
このセクションでは、セキュリティ・プロパティに基づいて、各キーイングメカニズムを評価します。
A.5.1. Distribution and Validation of Persistent Public Keys and Certificates
A.5.1。永続的な公開鍵と証明書の配布と検証
Using persistent public keys for confidentiality and authentication can introduce requirements for two types of systems, often implemented using certificates: (1) a system to distribute those persistent public keys certificates, and (2) a system for validating those persistent public keys. We refer to the former as a key distribution system and the latter as an authentication infrastructure. In many cases, a monolithic public key infrastructure (PKI) is used to fulfill both of these roles. However, these functions can be provided by many other systems. For instance, key distribution may be accomplished by any public repository of keys. Any system in which the two endpoints have access to trust anchors and intermediate CA certificates that can be used to validate other endpoints' certificates (including a system of self-signed certificates) can be used to support certificate validation in the below schemes.
これらの永続的な公開鍵を検証するため、これらの永続的な公開鍵証明書を配布する（1）システム、および（2）システム：機密性と認証のために永続的な公開鍵を使用すると、2つのことが多いの証明書を使用して実装システムの種類、要件を導入することができます。我々は、認証基盤として暗号鍵配布システムとして、前者と後者を指します。多くの場合、モノリシック公開鍵基盤（PKI）は、これらの役割の両方を果たすために使用されます。しかし、これらの機能は、他の多くのシステムによって提供することができます。例えば、鍵配布は、キーのいずれかの公開リポジトリによって達成することができます。 2つのエンドポイントは、アンカーと（自己署名証明書のシステムを含む）他のエンドポイントの証明書を検証するために使用することができる中間CA証明書を信頼するアクセス権を持っている任意のシステムは、以下のスキームに証明書の検証をサポートするために使用することができます。
With real-time communications, it is desirable to avoid fetching or validating certificates that delay call setup. Rather, it is preferable to fetch or validate certificates in such a way that call setup is not delayed. For example, a certificate can be validated while the phone is ringing or can be validated while ring-back tones are being played or even while the called party is answering the phone and saying "hello". Even better is to avoid fetching or validating persistent public keys at all.
リアルタイム通信で、コールセットアップを遅らせる証明書を取得するか、検証しないようにすることが望ましいです。むしろ、フェッチまたはセットアップが遅延されない呼び出すような方法で証明書を検証するのが好ましいです。電話が鳴っているか、リングバックトーンが再生されている間に検証することができたり、着信側が電話に答えると、「こんにちは」と言っている間もしながら、例えば、証明書を検証することができます。さらに良いことに、すべての永続的な公開鍵を取得するか、検証しないようにすることです。
SRTP key exchange mechanisms that require a particular authentication infrastructure to operate (whether for distribution or validation) are gated on the deployment of a such an infrastructure available to both endpoints. This means that no media security is achievable until such an infrastructure exists. For SIP, something like sip-certs [SIP-CERTS] might be used to obtain the certificate of a peer.
（分布又は確認のためかどうか）を操作するために特定の認証インフラストラクチャを必要とSRTP鍵交換メカニズムは、両方のエンドポイントに利用可能なそのようなインフラストラクチャの展開にゲートされます。これは、このようなインフラが存在するまではメディアのセキュリティが達成されていないことを意味します。 SIPは、SIP-本命[SIP-CERTS]のようなものは、ピアの証明書を取得するために使用されるかもしれません。
Note: Even if sip-certs [SIP-CERTS] were deployed, the retargeting problem (Appendix A.4.1) would still prevent successful deployment of keying techniques which require the offerer to obtain the actual target's public key.
注意：SIP-certsの[SIP-CERTS]が展開された場合でも、再標的化の問題（付録A.4.1）は、まだ実際の対象者の公開鍵を取得するために、オファーを必要とする技術をキーイングの展開を成功を妨げます。
The following list compares the requirements introduced by the use of public-key cryptography in each keying mechanism, both for public key distribution and for certificate validation.
以下のリストは、公開鍵の配布のために、証明書の検証のために、両方の、各キーイングメカニズムにおける公開鍵暗号方式を使用することにより導入された要件を比較します。
MIKEY-NULL Public-key cryptography is not used.
MIKEY-NULL公開鍵暗号では使用されません。
MIKEY-PSK Public-key cryptography is not used. Rather, all endpoints must have some way to exchange per-endpoint or per-system pre-shared keys.
MIKEY-PSK公開鍵暗号では使用されません。むしろ、すべてのエンドポイントは、事前共有キーのエンドポイントごと、またはシステム交換するいくつかの方法を持っている必要があります。
MIKEY-RSA The offerer obtains the intended answerer's public key before initiating the call. This public key is used to encrypt the SRTP keys. There is no defined mechanism for the offerer to obtain the answerer's public key, although [SIP-CERTS] might be viable in the future.
MIKEY-RSAは、オファー側は、通話を開始する前に、意図した回答者の公開鍵を取得します。この公開鍵は、SRTP鍵を暗号化するために使用されます。 [SIP-CERTS]が、将来的に実行可能であるかもしれないが、回答者の公開鍵を取得するために、オファーのための定義されたメカニズムは、ありません。
The offer may also contain a certificate for the offerer, which would require an authentication infrastructure in order to be validated by the receiver.
オファーは、受信機によって検証するために、認証インフラストラクチャを必要とする申出のための証明書を含んでいてもよいです。
MIKEY-RSA-R The offer contains the offerer's certificate, and the answer contains the answerer's certificate. The answerer uses the public key in the certificate to encrypt the SRTP keys that will be used by the offerer and the answerer. An authentication infrastructure is necessary to validate the certificates.
MIKEY-RSA-Rは、オファーはオファー側の証明書が含まれている、との回答は回答者の証明書が含まれています。回答は、オファー側とアンサーが使用するSRTP鍵を暗号化するために証明書の公開鍵を使用しています。認証インフラストラクチャは、証明書を検証する必要があります。
MIKEY-DHSIGN An authentication infrastructure is used to authenticate the public key that is included in the MIKEY message.
MIKEY-DHSIGNアン認証インフラストラクチャは、マイキーメッセージに含まれている公開鍵を認証するために使用されます。
MIKEY-DHHMAC Public-key cryptography is not used. Rather, all endpoints must have some way to exchange per-endpoint or per-system pre-shared keys.
MIKEY-DHHMAC公開鍵暗号では使用されません。むしろ、すべてのエンドポイントは、事前共有キーのエンドポイントごと、またはシステム交換するいくつかの方法を持っている必要があります。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDPでMIKEYv2挙動が選ばれているモードによって異なります。
SDP Security Descriptions with SIPS Public-key cryptography is not used.
SIPS公開鍵暗号方式でSDPセキュリティ記述は使用されません。
SDP Security Descriptions with S/MIME Use of S/MIME requires that the endpoints be able to fetch and validate certificates for each other. The offerer must obtain the intended target's certificate and encrypts the SDP offer with the public key contained in target's certificate. The answerer must obtain the offerer's certificate and encrypt the SDP answer with the public key contained in the offerer's certificate.
S / MIMEのS / MIMEを使用するとSDPセキュリティ記述は、エンドポイントがお互いの証明書を取得し、検証することができることが必要です。オファー側が意図した対象者の証明書を取得し、ターゲットの証明書に含まれる公開鍵でSDPオファーを暗号化しなければなりません。回答は、オファー側の証明書を取得し、オファー側の証明書に含まれる公開鍵でSDP回答を暗号化する必要があります。
SDP-DH Public-key cryptography is not used.
SDP-DH公開鍵暗号では使用されません。
ZRTP Public-key cryptography is used (Diffie-Hellman), but without dependence on persistent public keys. Thus, certificates are not fetched or validated.
ZRTP公開鍵暗号方式は、（ディフィー・ヘルマン）が、永続的な公開鍵に依存することなく使用されています。このように、証明書がフェッチか検証されません。
EKT Public-key cryptography is not used by itself, but might be used by the EKT bootstrapping keying mechanism (such as certain MIKEY modes).
EKT公開鍵暗号は、それ自体で使用されていないが、（例えば、特定のMIKEYモードなど）EKTブートストラップキーイング機構によって使用されるかもしれません。
DTLS-SRTP Remote party's certificate is sent in media path, and a fingerprint of the same certificate is sent in the signaling path.
DTLS-SRTPリモートパーティの証明書は、メディアパスに送信され、同じ証明書のフィンガープリントは、シグナリングパスに送信されます。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2インバンドは、行動を採取されたモードによって異なります。
A.5.2. Perfect Forward Secrecy
A.5.2。完全転送秘密
In the context of SRTP, Perfect Forward Secrecy is the property that SRTP session keys that protected a previous session are not compromised if the static keys belonging to the endpoints are compromised. That is, if someone were to record your encrypted session content and later acquires either party's private key, that encrypted session content would be safe from decryption if your key exchange mechanism had perfect forward secrecy.
SRTPの文脈では、完全転送秘密は、エンドポイントに属している静的キーが侵害された場合は、前のセッションを保護SRTPセッション鍵が損なわれない特性があります。誰かがあなたの暗号化されたセッションの内容を記録していたと、後に当事者のいずれかの秘密鍵を取得した場合、あなたの鍵交換のメカニズムは完全転送秘密があった場合には、その暗号化されたセッション内容が解読から安全だろうさ。
The following list describes how each key exchange mechanism provides PFS.
以下のリストは、各キー交換メカニズムは、PFSを提供する方法について説明します。
MIKEY-NULL Not applicable; MIKEY-NULL does not have a long-term secret.
MIKEY-NULLは適用されません。 MIKEY-NULLは、長期的な秘密を持っていません。
MIKEY-PSK No PFS.
MIKEY-PSKませんPFS。
MIKEY-RSA No PFS.
MIKEY-RSAませんPFS。
MIKEY-RSA-R No PFS.
MIKEY-RSA-RはありませんPFS。
MIKEY-DHSIGN PFS is provided with the Diffie-Hellman exchange.
MIKEY-DHSIGN PFSはのDiffie-Hellman交換を備えています。
MIKEY-DHHMAC PFS is provided with the Diffie-Hellman exchange.
MIKEY-DHHMAC PFSはのDiffie-Hellman交換を備えています。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDPでMIKEYv2挙動が選ばれているモードによって異なります。
SDP Security Descriptions with SIPS Not applicable; SDP Security Descriptions does not have a long-term secret.
該当事項はありませんSIPSとSDPセキュリティ記述。 SDPセキュリティ記述は、長期的な秘密を持っていません。
SDP Security Descriptions with S/MIME Not applicable; SDP Security Descriptions does not have a long-term secret.
S / MIMEは適用されませんとSDPセキュリティ記述。 SDPセキュリティ記述は、長期的な秘密を持っていません。
SDP-DH PFS is provided with the Diffie-Hellman exchange.
SDP-DH PFSはのDiffie-Hellman交換が設けられています。
ZRTP PFS is provided with the Diffie-Hellman exchange.
ZRTP PFSはのDiffie-Hellman交換を備えています。
EKT No PFS.
えＫＴ の ＰＦＳ。
DTLS-SRTP PFS is provided if the negotiated cipher suite uses ephemeral keys (e.g., Diffie-Hellman (DHE_RSA [RFC5246]) or Elliptic Curve Diffie-Hellman [RFC4492]).
ネゴシエートされた暗号スイートは、短命のキーを使用している場合DTLS-SRTP PFSが設けられている（例えば、ディフィー・ヘルマン（DHE_RSA [RFC5246]）や楕円曲線ディフィ - ヘルマン[RFC4492]）。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2インバンドは、行動を採取されたモードによって異なります。
A.5.3. Best Effort Encryption
A.5.3。ベストエフォートの暗号化
With best effort encryption, SRTP is used with endpoints that support SRTP, otherwise RTP is used.
ベストエフォート暗号化では、SRTPは、そうでない場合はRTPが使用され、SRTPをサポートするエンドポイントで使用されます。
SIP needs a backwards-compatible best effort encryption in order for SRTP to work successfully with SIP retargeting and forking when there is a mix of forked or retargeted devices that support SRTP and don't support SRTP.
SRTPをサポートし、SRTPをサポートしていないフォークまたはリターゲットデバイスの混在がある場合にSRTPがSIPリターゲットとフォークで正常に動作するためにSIPを順番に下位互換性のベストエフォート型の暗号化を必要とします。
Consider the case of Bob, with a phone that only does RTP and a voice mail system that supports SRTP and RTP. If Alice calls Bob with an SRTP offer, Bob's RTP-only phone will reject the media stream (with an empty "m=" line) because Bob's phone doesn't understand SRTP (RTP/SAVP). Alice's phone will see this rejected media stream and may terminate the entire call (BYE) and re-initiate the call as RTP-only, or Alice's phone may decide to continue with call setup with the SRTP-capable leg (the voice mail system). If Alice's phone decided to re-initiate the call as RTP-only, and Bob doesn't answer his phone, Alice will then leave voice mail using only RTP, rather than SRTP as expected.
唯一のRTPおよびSRTPとRTPをサポートしてボイスメールシステムを行い、電話で、ボブの場合を考えてみましょう。アリスはSRTPの申し出でボブを呼び出す場合、ボブの電話がSRTP（RTP / SAVPを）理解していないので、ボブのRTP専用電話は（空の「M =」行で）メディアストリームを拒否します。アリスの電話は、これはメディアストリームを拒否し、全体のコール（BYE）を終了し、RTPのみ、またはアリスの電話として通話がSRTP対応レグ（ボイスメールシステム）とのコールセットアップを続行することを決定することを再開始することができるでしょう。アリスの電話がRTP専用としてコールを再起動することを決めた、とボブは彼の電話に応答しない場合は、予想通り、アリスはその後だけRTPはなく、SRTPを使用してボイスメールを残すだろう。
Currently, several techniques are commonly considered as candidates to provide opportunistic encryption:
現在、いくつかの技術は、一般的に日和見暗号化を提供するために、候補として考えられています。
multipart/alternative [MULTIPART] describes how to form a multipart/alternative body part in SIP. The significant issues with this technique are (1) that multipart MIME is incompatible with existing SIP proxies, firewalls, Session Border Controllers, and endpoints and (2) when forking, the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326] causes problems if such non-multipart-capable endpoints were involved in the forking.
代替/マルチ[MULTIPART】SIP代替/マルチ本体部を形成する方法について説明します。この技術の重要な問題は、（1）場合はマルチパートMIMEは、既存のSIPプロキシ、ファイアウォール、セッションボーダーコントローラ、およびエンドポイントと互換性がないとフォークとき（2）、ヘテロジニアスエラー応答フォーク問題（HERFP）[RFC3326]は問題を引き起こすことがありますこのような非マルチ対応エンドポイントは、フォークに関与していました。
session attribute With this technique, the endpoints signal their desire to do SRTP by signaling RTP (RTP/AVP), and using an attribute ("a=") in the SDP. This technique is entirely backwards compatible with non-SRT-aware endpoints, but doesn't use the RTP/SAVP protocol registered by SRTP [RFC3711].
この技術では、セッション属性は、エンドポイントは、SDPにおけるRTP（RTP / AVP）をシグナリング、および属性を使用して、SRTPを行う意欲を（「=」）信号。この技術は、非SRT対応エンドポイントと完全に後方互換性であるが、SRTP [RFC3711]によって登録RTP / SAVPプロトコルを使用していません。
SDP Capability Negotiation SDP Capability Negotiation [SDP-CAP] provides a backwards-compatible mechanism to allow offering both SRTP and RTP in a single offer. This is the preferred technique.
SDP機能ネゴシエーションSDP機能ネゴシエーション[SDP-CAP]は、単一のオファーでSRTPとRTPの両方を提供できるように下位互換性機構を提供します。これは好ましい技術です。
Probing With this technique, the endpoints first establish an RTP session using RTP (RTP/AVP). The endpoints send probe messages, over the media path, to determine if the remote endpoint supports their keying technique. A disadvantage of probing is an active attacker can interfere with probes, and until probing completes (and SRTP is established) the media is in the clear.
この技術でプロービング、エンドポイントは、最初のRTP（RTP / AVP）を使用してRTPセッションを確立します。エンドポイントは、リモートエンドポイントは、そのキー技術をサポートしているかどうかを判断するために、メディアパスを介して、プローブメッセージを送信します。プロービングの欠点は、アクティブ攻撃者はプローブと、メディアがクリアである完了をプロービング（およびSRTPが確立される）まで妨害する可能性があります。
The preferred technique, SDP Capability Negotiation [SDP-CAP], can be used with all key exchange mechanisms. What remains unique is ZRTP, which can also accomplish its best effort encryption by probing (sending ZRTP messages over the media path) or by session attribute (see "a=zrtp-hash" in [ZRTP]). Current implementations of ZRTP use probing.
好ましい技術、SDP機能ネゴシエーション[SDP-CAP]は、すべての鍵交換メカニズムを使用することができます。どのようなユニークなままにすることも（[ZRTP]に「A = ZRTP-ハッシュ」を参照）（メディアパスオーバーZRTPメッセージを送信する）プローブすることにより、またはセッションの属性によって、そのベストエフォート暗号化を達成することができますZRTP、です。 ZRTPの現在の実装では、プロービング使用しています。
A.5.4. Upgrading Algorithms
A.5.4。アップグレードアルゴリズム
It is necessary to allow upgrading SRTP encryption and hash algorithms, as well as upgrading the cryptographic functions used for the key exchange mechanism. With SIP's offer/answer model, this can be computationally expensive because the offer needs to contain all combinations of the key exchange mechanisms (all MIKEY modes, SDP Security Descriptions), all SRTP cryptographic suites (AES-128, AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256) that the offerer supports. In order to do this, the offerer has to expend CPU resources to build an offer containing all of this information that becomes computationally prohibitive.
SRTP暗号化およびハッシュアルゴリズムをアップグレードできるようにする必要があるだけでなく、鍵交換メカニズムに使用する暗号化機能をアップグレードします。 SIPのオファー/アンサーモデルで、これはオファーが鍵交換メカニズムのすべての組み合わせを含んでいる必要があるため、計算コストが高くなる（すべてMIKEYモード、SDPセキュリティ記述）、すべてのSRTP暗号スイート（AES-128、AES-256）と、すべてのことができますSRTP暗号ハッシュ関数（SHA-1、SHA-256）オファーをサポートしています。これを行うためには、オファー側は、計算上法外になり、この情報のすべてを含んだプランを構築するためにCPUリソースを消費する必要があります。
Thus, it is important to keep the offerer's CPU impact fixed so that offering multiple new SRTP encryption and hash functions incurs no additional expense.
したがって、複数の新しいSRTP暗号化およびハッシュ関数を提供する追加の費用を負担しないように固定オファー側のCPUへの影響を抑えることが重要です。
The following list describes the CPU effort involved in using each key exchange technique.
以下のリストには、各鍵交換技術の使用に関連するCPUの取り組みについて説明します。
MIKEY-NULL No significant computational expense.
MIKEY-NULL有意な計算費用。
MIKEY-PSK No significant computational expense.
MIKEY-PSK有意な計算費用。
MIKEY-RSA For each offered SRTP crypto suite, the offerer has to perform RSA operation to encrypt the TGK (TEK Generation Key).
MIKEY-RSAはそれぞれ提供SRTP暗号スイートの場合、提供者は、TGK（TEK生成Key）を暗号化するためにRSAの操作を実行しなければなりません。
MIKEY-RSA-R For each offered SRTP crypto suite, the offerer has to perform public key operation to sign the MIKEY message.
各提供SRTP暗号スイートのMIKEY-RSA-R、オファーはMIKEYメッセージに署名するための公開鍵操作を実行しなければなりません。
MIKEY-DHSIGN For each offered SRTP crypto suite, the offerer has to perform Diffie-Hellman operation, and a public key operation to sign the Diffie-Hellman output.
オファーは、ディフィー - ヘルマン操作を実行しなければならない各提供SRTP暗号スイート、およびDiffie-Hellmanの出力を署名する公開鍵操作についてMIKEY-DHSIGN。
MIKEY-DHHMAC For each offered SRTP crypto suite, the offerer has to perform Diffie-Hellman operation.
各提供SRTP暗号スイートのMIKEY-DHHMACは、オファーは、ディフィー - ヘルマン操作を実行しなければなりません。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDPでMIKEYv2挙動が選ばれているモードによって異なります。
SDP Security Descriptions with SIPS No significant computational expense.
SIPS有意な計算コストとSDPセキュリティ記述。
SDP Security Descriptions with S/MIME S/MIME requires the offerer and the answerer to encrypt the SDP with the other's public key, and to decrypt the received SDP with their own private key.
S / MIME S / MIMEとSDPセキュリティ記述は、オファー側と相手の公開鍵でSDPを暗号化し、そして自分自身の秘密鍵で受け取ったSDPを解読するために回答する必要があります。
SDP-DH For each offered SRTP crypto suite, the offerer has to perform a Diffie-Hellman operation.
各提供SRTP暗号スイートのSDP-DH、オファーは、ディフィー - ヘルマン操作を実行しなければなりません。
ZRTP The offerer has no additional computational expense at all, as the offer contains no information about ZRTP or might contain "a=zrtp-hash".
オファーはZRTPに関する情報が含まれていないか、「A = ZRTP-ハッシュ」が含まれている可能性があるとしてZRTPオファー側は、まったく追加の計算コストを持っていません。
EKT The offerer's computational expense depends entirely on the EKT bootstrapping mechanism selected (one or more MIKEY modes or SDP Security Descriptions).
EKTオファー側の計算コストは、選択したEKTブートストラップ・メカニズム（一つ以上のMIKEYモードまたはSDPセキュリティ記述）に完全に依存します。
DTLS-SRTP The offerer has no additional computational expense at all, as the offer contains only a fingerprint of the certificate that will be presented in the DTLS exchange.
オファーがDTLS交換に提示される証明書の指紋のみが含まれているとして、DTLS-SRTPは、オファー側は、まったく追加の計算コストを持っていません。
MIKEYv2 Inband The behavior will depend on which mode is picked.
MIKEYv2インバンドは、行動を採取されたモードによって異なります。
Appendix B. Out-of-Scope
付録B.範囲外の
The compromise of an endpoint that has access to decrypted media (e.g., SIP user agent, transcoder, recorder) is out of scope of this document. Such a compromise might be via privilege escalation, installation of a virus or trojan horse, or similar attacks.
復号化された媒体（例えば、SIPユーザエージェント、トランスコーダ、レコーダ）へのアクセスを有するエンドポイントの妥協は、この文書の範囲外です。このような妥協は、権限の昇格、ウイルスやトロイの木馬のインストール、または同様の攻撃を経由してかもしれません。
B.1. Shared Key Conferencing
B.1。共有キー会議
The consensus on the RTPSEC mailing list was to concentrate on unicast, point-to-point sessions. Thus, there are no requirements related to shared key conferencing. This section is retained for informational purposes.
RTPSECメーリングリストのコンセンサスは、ユニキャスト、ポイントツーポイントセッションに集中することでした。したがって、共有キー会議に関連する要件はありません。このセクションでは、情報提供の目的のために保持されます。
For efficient scaling, large audio and video conference bridges operate most efficiently by encrypting the current speaker once and distributing that stream to the conference attendees. Typically, inactive participants receive the same streams -- they hear (or see) the active speaker(s), and the active speakers receive distinct streams that don't include themselves. In order to maintain the confidentiality of such conferences where listeners share a common key, all listeners must rekeyed when a listener joins or leaves a conference.
効率的なスケーリングのために、大規模なオーディオおよびビデオ会議ブリッジはかつて、現在のスピーカーを暗号化し、会議参加者にそのストリームを配信することにより、最も効率的に動作します。一般的に、非アクティブな参加者が同じストリームを受信する - 彼らは聞いて（または参照）アクティブスピーカー（複数可）、およびアクティブスピーカー自体を含まない個別のストリームを受信します。リスナーが会議に参加するか、離れたときにリスナーが共通鍵を共有し、そのような会議の機密性を維持するために、すべてのリスナーがリキーしなければなりません。
An important use case for mixers/translators is a conference bridge:
ミキサー/翻訳者のための重要なユースケースは、会議ブリッジであります：
+----+
A --- 1 --->| |
<-- 2 ----| M |
| I |
B --- 3 --->| X |
<-- 4 ----| E |
| R |
C --- 5 --->| |
<-- 6 ----| |
+----+
Figure 3: Centralized Keying
図3：集中化キーイング
In the figure above, 1, 3, and 5 are RTP media contributions from Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those devices carrying the "mixed" media.
上記の図では、1、3、及び5は、アリス、ボブ、およびキャロル、および2,4、及び6からRTPメディア寄与しているRTPは、「混合」メディアを搬送するこれらのデバイスに流れています。
Several scenarios are possible:
いくつかのシナリオが考えられます。
a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions,
A。複数の受信セッション：1、3、および5は、個別のRTPセッションです
b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP sessions,
B。複数のアウトバウンドセッション：2、4、および6は、異なるRTPセッションであります
c. Single inbound session: 1, 3, and 5 are just different sources within the same RTP session,
C。シングルインバウンドセッション：1、3、および5同じRTPセッション内だけ異なる源です、
d. Single outbound session: 2, 4, and 6 are different flows of the same (multi-unicast) RTP session.
D。単一のアウトバウンドセッション：2、4、および6と同じ（マルチユニキャスト）RTPセッションの異なるフローです。
If there are multiple inbound sessions and multiple outbound sessions (scenarios a and b), then every keying mechanism behaves as if the mixer were an endpoint and can set up a point-to-point secure session between the participant and the mixer. This is the simplest situation, but is computationally wasteful, since SRTP processing has to be done independently for each participant. The use of multiple inbound sessions (scenario a) doesn't waste computational resources, though it does consume additional cryptographic context on the mixer for each participant and has the advantage of data origin authentication.
複数の着信セッションと複数の発信セッション（シナリオA及びB）がある場合、ミキサは、エンドポイントであり、参加者とミキサとの間のポイント・ツー・ポイントのセキュアセッションを設定することができるかのように、その後、すべてのキーイング機構が動作します。これは最も単純な状況ですが、SRTP処理は、各参加者のために独立して行わなければならないので、計算が無駄です。それは各参加者のためにミキサーに追加の暗号コンテキストを消費し、データ発信元認証の利点を持っていないにもかかわらず、複数の受信セッション（シナリオA）の使用は、計算リソースを無駄にしません。
To support a single outbound session (scenario d), the mixer has to dictate its encryption key to the participants. Some keying mechanisms allow the transmitter to determine its own key, and others allow the offerer to determine the key for the offerer and answerer. Depending on how the call is established, the offerer might be a participant (such as a participant dialing into a conference bridge) or the offerer might be the mixer (such as a conference bridge calling a participant). The use of offerless INVITEs may help some keying mechanisms reverse the role of offerer/answerer. A difficulty, however, is knowing a priori if the role should be reversed for a particular call. The significant advantage of a single outbound session is the number of SRTP encryption operations remains constant even as the number of participants increases. However, a disadvantage is that data origin authentication is lost, allowing any participant to spoof the sender (because all participants know the sender's SRTP key).
単一のアウトバウンドセッション（シナリオd）をサポートするために、ミキサーは、参加者への暗号化キーを指示する必要があります。いくつかのキーイングメカニズムは、送信機が、独自のキーを決定することができ、他のものは、オファーは、オファーとアンサーのキーを決定することができます。コールが確立される方法に応じて、オファー側は、（会議ブリッジにダイヤルイン参加者として）参加者であるかもしれないか、オファー側は、（参加者を呼び出して会議ブリッジなど）ミキサーかもしれません。 offerlessのINVITEの使用は、いくつかのキーイングメカニズムは、オファー/アンサーの役割を逆に助けるかもしれません。役割は、特定の呼び出しのために反転するかどう難しさは、しかし、演繹的に知っています。単一のアウトバウンドセッションの重要な利点は、SRTP暗号化操作の数が偶数の参加者数の増加に伴って一定のままです。 （すべての参加者が送信者のSRTPキーを知っているので）しかし、欠点は、任意の参加者が送信者を偽装することができ、データ発信元認証が失われることです。
Authors' Addresses
著者のアドレス
Dan Wing (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ダン・ウィング（エディタ）は、シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com
Steffen Fries Siemens AG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ステファンフライシーメンスAGオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: steffen.fries@siemens.com
メールアドレス：steffen.fries@siemens.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo, 02600 Finland
エスポー、フィンランド02600でハンネスTschofenigノキア・シーメンス・ネットワークスLinnoitustie 6
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@nsn.com URI：http://www.tschofenig.priv.at
Francois Audet Nortel 4655 Great America Parkway Santa Clara, CA 95054 USA
フランソワAudetノーテル4655グレートアメリカパークウェイサンタクララ、CA 95054 USA
EMail: audet@nortel.com
メールアドレス：audet@nortel.com