[要約] RFC 5479は、メディアセキュリティ管理プロトコルの要件と分析に関するものであり、メディアセキュリティの管理に関するプロトコルの設計と実装に役立つ情報を提供することを目的としています。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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にメディアセキュリティの要件をリストします。ドキュメントの主な部分は、セキュリティに関する考慮事項セクション6で終了し、セクション7の承認で締めくくります。付録Aは、利用可能なソリューションの提案をリストおよび比較します。次の付録A.4は、付録Aで説明したSIPシグナル伝達シナリオに対する適合性に関するさまざまなアプローチを比較し、付録A.5はセキュリティの側面に関する比較を示します。付録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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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（record of-record）：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回のパッド：同じキーと同じキーストリームを使用して、異なるデータを暗号化します。SRTPの場合、2人の送信者が同じキーと同じRTP SSRC値を使用している場合、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.
Perfect Forward Secrecy（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アドレスとTCP/UDPポートのカルテットとIPルートによって定義されます。その他の場合、このパスには、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).
このセクションの説明は、要件R-Assoc（セクション5.1で指定）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:
このドキュメントは、アクセスと能力に応じて敵を分類します。敵がアクセスできるかもしれません：
1. only to the media path,
1. メディアパスのみ、
2. only to the signaling path,
2. シグナリングパスのみ、
3. to the media path and to the signaling path.
3. メディアパスとシグナリングパスへ。
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は、無署名のパッシブメディアに対して脆弱です。
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セキュリティの説明[RFC4568]は、TLS（一般的に実装および展開されているように）によって保護されている場合、敵はSDPセキュリティ記述キーを学ぶ必要があるため、パッシブシグナルのセキュリティ記述キーを学習する必要があるため、パッシブシグナルシグナルのパッシブメディアカテゴリに属します。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（SRTPのデータグラムトランスポートレイヤーセキュリティ拡張）は、DTLS-SRTPがセルフ署名証明書を持つパブリックキーベースのCipherSuiteで使用され、SIPアイデンティティなしで使用される場合、アクティブシグナルアクティブメディアカテゴリに分類されます[RFC4474]。敵は、信号経路に沿って送信される指紋を変更し、その後メディアパスに沿って移動するDTLSハンドシェイクにある証明書を変更する必要があります。DTLS-SRTPがSIP ID [RFC4474]とSIP Connected ID [RFC4916]の両方で使用されている場合、RFC-4474の署名はオファーと答えの両方を保護し、そのようなシステムはアクティブなシグナル特異的特異メディアに属します-TETECTカテゴリ（もちろん、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キーを知る必要があります。いずれかのEndPointが、関連する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.
SDPでAswerserのキーを送信するキー交換メカニズムの場合、183（セッションの進行状況）などのSIP暫定応答[RFC3261]が有用です。ただし、183のメッセージは、呼び出しと呼び出されたエンドポイントの両方が暫定応答承認（PRACK）[RFC3262]を使用して、すべてのSIPプロキシでTCPを使用し、セキュリティの前提条件を実装していない場合に信頼できません。また、答いは、氷に記載されている信頼できる暫定的な応答メカニズムを実装しています。残念ながら、これらの手法のいずれも幅広く展開されておらず、このセクションで説明されている問題を回避するためにこれらの手法を要求することは業界の抵抗があります。
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バインディングを開くためにメディアを送信する必要があります（詳細については、[Middlebox]を参照）。この場合、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-Fork-Retarget、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で、アリスはステップ2でボブに送信されるステップ1で招待状を送信します。ボブは、ステップ3でキャロルを指すリダイレクト（SIP応答コード3xx）で応答します。このリダイレクトは通常、アリスに戻るだけでなく、行くだけですステップ4でオリジナルの招待をキャロルに送信するプロキシ（つまり、リターゲティングプロキシ）に。
+-----+
|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）に電話をかけると、別の数に転送されるかどうか、リング時にラインをピックアップするなど、実際にはわかりません。ただし、呼び出された当事者を認証するための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 ID [RFC4474]です。ただし、リターゲティングの性質により、SIP IDは、呼び出しの当事者（つまり、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が複数回登録されている場合に発生します。フォーキングの例は、ユーザーがデスクフォン、PCクライアント、モバイルハンドセットがすべて同じAORに登録されている場合です。
+-----+
|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.
フォーキングを使用すると、BOB-1とBOB-2の両方が、SIP応答でSDPの回答を返送する可能性があります。アリスは、それらの中間（18x）および最終（200）の応答を見るでしょう。AliceがSIP応答を着信メディアストリームに関連付けることができるのは有用です。この関連性は氷[氷]で行うことができ、氷はこの関連を達成するために氷を要求することは望ましくありません。
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キーを知る必要があります。FROKEDおよびRetargeted Callsは、シグナリングメッセージにオファーを受け取っていないが応答しない当事者がアクセスできる機密情報（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のユニークな機能は、フォーキングが使用される場合、要求の送信者に配信される最終的なエラー応答が常に1つしかないことです。フォーキングプロキシは、フォーキングの場合に選択する最終応答を選択する責任があります。フォーキングプロキシによって複数の最終エラー応答が受信されます。これは、リクエストが拒否された場合、キーイング情報が拒否され、ファーエンドの資格情報を提供したという情報を使用して、拒否が送信者に届かない可能性が非常に高いことを意味します。不均一なエラー応答フォーキング問題（HERFP）[RFC3326]と呼ばれるこの問題は、SIPで解決するのが困難です。HERFPは予見可能な将来のSIPの問題であり続けることを期待しているため、HERFPの挙動の存在下でもメディアセキュリティシステムが機能するはずです。
The discussion in this section relates to requirement R-RECORDING.
このセクションの議論は、要件R録音に関するものです。
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.
コールの片方の脚がPSTNにある場合でも、コールのIPレッグがSRTPで保護されることが望ましいです。
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対応ネットワークを介してVoice over IP（VOIP）会話をしているメディアセキュリティを使用する典型的なケース。ただし、通信のもう一方の端がIP対応ネットワークに接続されていない場合があります。この種の設定では、VoIP会話を他のネットワークが理解している形式に変換するIPネットワークの端にある種のゲートウェイが必要です。このようなゲートウェイの例は、IPおよびPSTNネットワークの端にあるPSTNゲートウェイです（[RFC3372]で説明されているアーキテクチャなど）。
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 re-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操作を実行するのに十分な処理能力を欠いているか、すべての通話でそれらの操作を実行しないようにすることを好みます。以前の公開キーまたは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.
特定のデバイスでは、diffie-hellman操作を実行するために1〜2秒かかることがあります。これらのデバイスの例には、携帯電話、IPマルチメディアサービスIDモジュール（ISIM）、およびPSTNゲートウェイが含まれます。PSTNゲートウェイは通常、呼び出しの開始時に典型的なDSP操作にまだ関与していないデジタル信号プロセッサ（DSP）を利用します。したがって、DSPを使用して計算を実行することができ、中央のホストプロセッサに計算を実行させないようにします。ただし、すべてのPSTNゲートウェイがDSPを使用しているわけではありません（一部には中央のプロセッサのみがあるか、DSPは必要な公開キーまたはdiffie-hellman操作を実行できません）、携帯電話にはこれらの操作を実行するための別の未使用プロセッサがありません。
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-reuseが役立つ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.
一部の環境では、ネットワーク機器が1つのコーデック（たとえば、ワイヤレス帯域幅を効率的に使用する高度に圧縮されたコーデック）から別のコーデック（例えば、SIPピアリングインターフェイスへの標準化されたコーデック）にトランスコードする必要があります。RTPを使用すると、SIPバックツーバックユーザーエージェント（B2BUA）の組み合わせでトランスコーディング関数を実行して、SDPとプロセッサを変更してコーデック間のトランスコーディングを実行できます。ただし、エンドツーエンドの保護されたSRTPを使用すると、同じ方法で実装されたトランスコーディング関数が中間攻撃であり、重要な管理システムはその使用を防ぎます。
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回答の前に受信される場合があります。さまざまなシナリオの詳細については、[アーリーメディア]を参照してください。
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メディアを受信および再生する必要があります。
The discussion in this section relates to the requirement R-OTHER-SIGNALING.
このセクションの議論は、要件R-other-Signalingに関連しています。
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).
多くの環境では、一部のデバイスは、SIPのオファー/回答モデルを共有していないSIP以外のプロトコルで信号を送られています（例：[H.248.1]、またはSDP（例：H.323）を使用しません。SIPになりますが、異なる主要な管理システムを使用する場合があります（たとえば、1つはMikey-RSA、もう1つは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.
これらの環境では、2つのエンドポイントの間にRTPではなくSRTPを持つことが望ましいです。望ましくないものの、それらの異なるシグナル伝達システムまたは異なる主要な管理システムをインターワーキングすることは常に可能です。各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.
インターネットおよび一部のプライベートネットワークでは、別のピアの証明書を検証することは、信頼できる証明書当局のリストである信託anchorを通じて行われることがよくあります。ピアがこれらの証明書を取得することは困難または高価な場合があります。すべての場合において、コールの両当事者は、同じトラストアンカー（つまり、「認証局」）を信頼する必要があります。これらの理由により、メディアプレーンキー管理プロトコルが、サードパーティの信託ポイントから資格情報を取得せずに、事前の関連性を持たないエンドユーザーがお互いに認証することを可能にするメカニズムを提供することが重要です。これは、サーバーが証明書を持ち、エンドユーザーのアイデンティティを証明するメカニズムを除外していないことに注意してください。
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.1）に固有の要件、攻撃シナリオ（セクション5.2）、および主要な管理プロトコル内または主要な管理プロトコルの外側（セクション5.3）の外部（セクション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フォークリターゲット：メディアセキュリティキーマネジメントプロトコルは、すべてのエンドポイントがコールセットアップを失敗させずに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：Media Security Key Managementプロトコルは、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).
注：セキュリティコンテキストの再利用は、RTPパラメーターの再利用（ペイロードタイプまたは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クリッピング：メディアセキュリティキー管理プロトコルは、セキュリティの前提条件を必要とせずにSDPの回答の前にメディアの切り抜きを避ける必要があります[RFC5027]。この要件は、セクション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を消費する操作（diffie-hellmanや公開キー操作など）の実行を避けることを避けることができないため、キー管理メッセージをコールシグナリングメッセージに関連付けることが役立ちます。
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.
たとえば、20のエンドポイントに分岐するセキュリティの前提条件でdiffie-hellmanキーイング手法を使用すると、コールイニシエーターは20の署名されたdiffie-hellmanキーペアを含む20の暫定的な応答を取得します。20のdiffie-hellmanの秘密を計算し、署名を検証することは、一部のデバイスにとって難しい作業になる可能性があります。したがって、フォーキングの場合、すべてのパーティーでディフェヘルマンの操作を実行することは望ましいことではなく、むしろコールに応答する（そしていくつかのメディアクリッピングが発生する）パーティーとのみを使用することが望ましいです。これを行うには、シグナリングとメディアを関連付ける必要があります。そうすれば、呼び出し当事者がどのキーマネジメント交換を完了する必要があるかを知っています。これは、SDPに示されている輸送アドレスを使用して行われる場合がありますが、NATはこの関連性を複雑にする可能性があります。
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：Media Security Key Managementプロトコルは、SIPユーザーエージェントが個々のセッションごとにメディアセキュリティパラメーターをネゴシエートすることを許可する必要があります。このような交渉は、2回のパッドを引き起こしてはなりません（[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：Media Security Key Management Protocolは、Perfect Forward Secrecyをサポートできる必要があります。
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：Media Security Key Managementプロトコルは、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:
米国政府は、FIPS-140 [FIPS-140-2]プロセスによって検証された暗号実装のみを購入および使用できます。
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：Media Security Key Managementプロトコルは、暗号性、つまり進化する暗号化とセキュリティ要件に適応する能力を提供する必要があります（展開された実装を大幅に中断することなく、暗号化アルゴリズムの更新）。
R-DOWNGRADE: The media security key management protocol MUST protect cipher suite negotiation against downgrading attacks.
R-DownGrade：Media Security Key Management Protocolは、攻撃のダウングレードに対するCipher Suiteの交渉を保護する必要があります。
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：Media Security Key Management Protocolには、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バインディング：Media Security Key Management Protocolは、メディアセキュリティキーをエンドポイントのIDに暗号化するようにする必要があります。
Note: This allows domains to deploy SIP Identity [RFC4474].
注：これにより、ドメインはSIP ID [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.
注：R-act-actを満たさないと、プロトコルが安全なエンドツーエンドメディアを提供できないことを示します。
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対応エンドポイントおよび/または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、Media Gateway Control Protocol（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-Transcoder：エンドポイント間で中間ノード（トランスコダーなど）、終端または処理メディアをサポートするソリューションを説明する必要があります。
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が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.
このドキュメントの要件部分への貢献については、著者はRTPSEC BOFのアクティブな参加者とRTPSECメーリングリストに感謝したいと思います。
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.
著者はさらに、レビュー、提案、コメントについて次の人々に感謝したいと思います：フレミング・アンドレアーゼン、リチャード・バーンズ、マーク・ボーアー、ヴォルフガング・ブッカー、ヴェルナー・ディットマン、ラクシュミナス・ドンデティ、ジョン・エルウェル、マーティン・ユーッカー、ハンス・ハインリッチ・グリュス、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、Petetウォード、ダンヨーク、フィルジマーマン。
[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/ Publications/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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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.、McGrew、D.、Naslund、M.、Carrara、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] bundesamt fuer sicherheit in der InformationStechnik [連邦情報セキュリティオフィス - ドイツ]、「Anwendungshinweise und ritentationen（ais）zu itsec」、<http://www.bsi.de/zertifiz/zert/zerpr/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] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのキーを確立するためのキーを確立する」、2008年10月の作業。
[EARLY-MEDIA] Stucker, B., "Coping with Early Media in the Session Initiation Protocol (SIP)", Work in Progress, October 2006.
[アーリーメディア] Stucker、B。、「セッション開始プロトコル（SIP）の初期メディアへの対処」、2006年10月、進行中の作業。
[EKT] McGrew, D., "Encrypted Key Transport for Secure RTP", Work in Progress, July 2007.
[Ekt] McGrew、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] Rosenberg、J。、「Interactive Connectivity Indecivity Indecivity（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.
[Middlebox] Stucker、B。およびH. Tschofenig、「メディアパスに沿ったシグナリングプロトコル通信のためのミドルボックスインタラクションの分析」、2008年7月の進行中。
[MIKEY-ECC] Milne, A., "ECC Algorithms for MIKEY", Work in Progress, June 2007.
[Mikey-ECC] Milne、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キー管理、Revisited」、2007年3月、Work in Progress。
[MULTIPART] Wing, D. and C. Jennings, "Session Initiation Protocol (SIP) Offer/Answer with Multipart Alternative", Work in Progress, March 2006.
[MultiPart] Wing、D。およびC. Jennings、「セッション開始プロトコル（SIP）MultiPart Alternativeを使用したオファー/回答」、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.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）のヘッダーフィールドの理由」、RFC 3326、2002年12月。
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[RFC3372] Vemuri、A。およびJ. Peterson、「電話のセッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ」、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.、Frederick、R。、およびV. Jacobson、「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.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、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] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、 "楕円曲線暗号化（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] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（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-Authenticated Diffie-Hellman for Multimedia Internet Keying（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. Lin、「Mikey-RSA-R：マルチメディアインターネットキーイング（Mikey）のキー分布の追加モード」、RFC 4738、2006年11月。
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4771] Lehtovirta、V.、Naslund、M。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）のロールオーバーキャリングロールオーバーカウンター」、RFC 4771、2007年1月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、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] Andreasen、F。およびD. Wing、「セッション説明プロトコル（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] Fries、S。and D. Ignjatic、「さまざまなマルチメディアインターネットキーイング（Mikey）モードと拡張機能の適用性について」、RFC 5197、2008年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[SDP-CAP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2008.
[SDP-CAP] Andreasen、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. McGrew、「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] Jennings、C。and 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] Wing、D.、Audet、F.、Fries、S.、Tschofenig、H。、およびA. Johnston、「セッション開始プロトコルによる安全なメディア録音とトランスコーディング」、2008年10月の作業。
[ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, February 2009.
[Zrtp] Zimmermann、P.、Johnston、A。、およびJ. Callas、「Zrtp：Secure RTPのメディアパスキー契約」、2009年2月、Work in Progress。
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の重要な利点の1つは、SRTPが帯域幅効率であり、SRTPがRTPパケットのヘッダーを保持することです。アクセス帯域幅が制限または高価であり、RTPヘッダーを保持することがパケットの損失、遅延、およびジッターのトラブルシューティングに重要である多くのシナリオでは、帯域幅の効率が不可欠です。
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キーを確立するのに役立ちます。メディアパスを介してキーイングすることの欠点は、異なるキー交換を行うには、シグナリングパスだけでなく、メディアパスにインターワーキング機能が必要であることです。実際には、とにかくこの関与はおそらく避けられないでしょう。
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で暗号化されていない送信されます。つまり、SDPは暗号化されたホップバイホップ（たとえば、TLS（SIP）を使用して）またはエンドツーエンド（たとえば、Secure/Multipurpose Internet Mail Extensions（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は、OffererからResunser（半往復）への1つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。
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（Pre-Shared Key）[RFC3830]では、すべてのエンドポイントが1つの共通キーを共有する必要があります。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は、OffererからReswerer（半往復）への1つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。
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は、OffererからResunser（往復の半分）への1つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。Mikey-RSAは、提供者に意図した応答者の証明書を取得することを要求します。
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メッセージに証明書を送信することもできます。
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は、Offererから回答するために1つのメッセージを必要とし、AnswererからOfferer（完全な往復）へのメッセージを1つ必要とし、追加のメディアパスメッセージを追加しません。Mikey-RSA-Rは、提供者がAnswererの証明書を検証する必要があります。
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]では、提供者と回答者がDiffie-Hellman（DH）Exchangeからキーを導き出します。アクティブな中間者を防ぐために、DH Exchange自体は各エンドポイントの秘密キーを使用して署名され、関連するパブリックキーは標準の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は、OffererからReswererへの1つのメッセージと、ReswererからOfferer（完全な往復）への1つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。Mikey-Dhsignは、お互いの証明書を検証するために提供者と応答者に要求されます。Mikey-DHSignは、MikeyメッセージにAnswererの証明書を送信することもできます。
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]は、Diffie-Hellman ExchangeをHMACにするために事前に共有された秘密を使用し、基本的にMikey-DHSignとMikey-Dhsignの証明書認証の必要性はありません。
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は、オファーから応答するために1つのメッセージを必要とし、応答者からOfferer（完全な往復）への1つのメッセージが必要であり、追加のメディアパスメッセージは追加されません。
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アルゴリズムは、Mikey-RSA（Elliptic Curve Digital Signature Algorithm（ECDSA）署名を使用）およびMikey-DHSign（新しいDHグループを使用）でECCを使用する方法を説明し、2つの2つを定義します。新しいECCベースのアルゴリズム、楕円曲線統合暗号化スキーム（ECIE）および楕円曲線Menezes-QU-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.
この提案により、ECDSAの署名、Mikey-Ecies、およびMikey-ECMQVはMikey-RSAとまったく同じように機能し、新しいDHグループコードはMikey-DHSignとまったく同じように機能します。したがって、これらのECCメカニズムは、このドキュメントで個別に説明されていません。
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セキュリティの説明には、OffererからReswererへの1つのメッセージ、およびReswererからOfferer（完全な往復）への1つのメッセージが必要であり、追加のメディアパスメッセージは追加されません。
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と同一です。
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 Diffie-Hellman [SDP-DH]は、セッションキーを確立するためのシグナリングパスでDiffie-Hellmanメッセージを交換します。積極的な中間者攻撃から保護するには、Diffie-Hellman ExchangeをS/MIME、SIP、またはSIP ID [RFC4474]およびSIP接続アイデンティティ[RFC4916]で保護する必要があります。
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は、OffererからReswererへの1つのメッセージと、ReswererからOfferer（完全な往復）への1つのメッセージを必要とし、追加のメディアパスメッセージを追加しません。
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回のラウンド旅行が必要になりました。最初のラウンド旅行では、通信当事者はお互いのアイデンティティを学び、マイキーモード、暗号アルゴリズム、SRTPポリシーに同意し、リプレイ保護のためにノンセスを交換します。2回目のラウンド旅行では、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を参照）。
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 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.
ZRTP [ZRTP]は、シグナリングパスで情報を交換しません（ただし、整合性保護されたシグナリングチャネルを介して送信された場合、ZRTP Helloメッセージのハッシュを「A = Zrtp-Hash」と「A = Zrtp-Hash」と交換することは可能です。信号層とメディアレイヤーの間にいくつかの有用な相関関係を提供します）。ZRTPでは、キーはDiffie-Hellman Exchangeを使用してメディアパスで完全に交換されます。このメカニズムの利点は、シグナリングチャネルがコールセットアップにのみ使用され、メディアチャネルが使用されて、PSTNの暗号化デバイスと同様に暗号化されたチャネルを確立するために使用されることです。Zrtpは、各人に他の人に数字または単語を読ませることにより、Diffie-Hellman Exchangeの音声認証を使用します。同じZRTPエンドポイントを使用した後続のセッションは、音声認証ではなく、以前に交渉されたキーの保存されたハッシュを使用して認証できます。Zrtpは、4つのメディアパスメッセージ（Hello、Commit、DHPART1、およびDHPART2）を使用して、SRTPキーと3つのメディアパス確認メッセージを確立します。これらの初期メッセージはすべて、非RTPパケットとして送信されます。
Note: that when ZRTP probing is used, unencrypted RTP can be exchanged until the SRTP keys are established.
注：ZRTPプロービングを使用すると、SRTPキーが確立されるまで、暗号化されていないRTPを交換できること。
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キーエクスチェンジプロトコルに依存しています。初期段階では、会議の各メンバーがSRTPキー交換プロトコルを使用して、共通のキー暗号化キー（KEK）を確立します。各メンバーは、KEKを使用して、RTCPを介してSRTPマスターキーと現在のSRTPロールオーバーカウンター（ROC）をセッションの他の参加者に安全に輸送できます。
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_CIPHE、セキュリティパラメーターインデックス（SPI））を送信する必要があります。各回答者は、AnswererのSRTPマスターキー、ロールオーバーカウンター、およびSRTPシーケンス番号を含むSRTCPメッセージを送信します。再キーイングは、新しいSRTCPメッセージを送信することで行われます。信頼できる輸送のために、複数のRTCPメッセージを送信する必要があります。
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セッションを確立します。エンドポイントは、DTLSハンドシェイクを使用して暗号スイートに同意し、SRTPセッションキーを確立します。その後、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は、OffererからResunser（Half Round Trip）への1つのメッセージと、応答者からOfferer（完全な往復）への1つのメッセージを必要とします。DTLS-SRTPは、4つのメディアパスメッセージを使用して、SRTPキーを確立します。
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_RSA_WITH_AES_128_CBC_SHAを暗号スイートとして使用すると想定しています。
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など）について、まだドキュメントで整理されていません。
This section considers how each keying mechanism interacts with SIP features.
このセクションでは、各キーイングメカニズムがSIP機能とどのように相互作用するかを検討します。
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 Secure Forking：いいえ、すべてのAORSは、オファーと応答者の鍵を見ます。答えは、マイキーのSSRCによるメディアに関連付けられています。さらに、2つの分岐が同じ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 Secure Forking：いいえ、すべてのAORSは提供者と応答者の鍵を見ます。答えは、マイキーのSSRCによるメディアに関連付けられています。フォーキングがMikey-PSKで作業するためには、すべてのAORが同じ共有キーを共有する必要があることに注意してください。さらに、2つの分岐が同じ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 Secure Forking：いいえ、すべてのAORSは提供者と応答者の鍵を見ます。答えは、マイキーのSSRCによるメディアに関連付けられています。フォーキングがMikey-RSAと連携するためには、すべてのAORが同じ秘密鍵を共有する必要があることに注意してください。さらに、2つの分岐が同じ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セキュアフォーキング：はい、フォークされた各エンドポイントは、両方向のオファーとユニークな鍵を交渉します。答えは、マイキーの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 Secure Forking：はい、フォークされた各エンドポイントは、両方向に提供者とユニークな鍵を交渉します。答えは、マイキーの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キーを計算します。「a = zrtp-hash」属性を使用すると、メディアは答えに関連付けられます。
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 inband動作は、どのモードが選択されるかによって異なります。
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のエンドポイントに分岐するセキュリティの前提条件でdiffie-hellmanキーイング手法を使用すると、コールイニシエーターは20の署名されたdiffie-hellman半キーを含む20の暫定的な応答を取得します。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がクリップされました。回答には、Answererの暗号化キーが含まれています。
MIKEY-DHSIGN Clipped. The answer contains the answerer's Diffie-Hellman response.
Mikey-dhsignがクリップされました。答えには、AnswererのDiffie-Hellman Responseが含まれています。
MIKEY-DHHMAC Clipped. The answer contains the answerer's Diffie-Hellman response.
Mikey-dhhmacがクリップされました。答えには、AnswererのDiffie-Hellman Responseが含まれています。
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.
SIPが切り取られたSDPセキュリティの説明。回答には、Answererの暗号化キーが含まれています。
SDP Security Descriptions with S/MIME Clipped. The answer contains the answerer's encryption key.
S/MIMEを使用したSDPセキュリティの説明。回答には、Answererの暗号化キーが含まれています。
SDP-DH Clipped. The answer contains the answerer's Diffie-Hellman response.
SDP-DHがクリップされました。答えには、AnswererのDiffie-Hellman Responseが含まれています。
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.
最初のRTCPパケット（Answerer's Keyを含む）が輸送中に失われない限り、EKTは切り取られていません。回答者は、暗号化キーをRTCPに送信します。RTCPは、そのキーで暗号化された最初のSRTPパケットを同時に（または前に）到着します。
Note: RTCP needs to work, in the answerer-to-offerer direction, before the offerer can decrypt SRTP media.
注：RTCPは、オファーがSRTPメディアを復号化できるようにする前に、回答者の方向で動作する必要があります。
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 inbandがクリップされていません。キーは、信号パスに頼らずにメディアパスで交換されます。
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モードで使用される1つは、SSRCをMikey Exchangeのピアに伝えることです。SDPセキュリティの説明で使用されるもう1つは、「遅いバインディング」を適用することです。つまり、以前に見えないSSRC（同じ宛先ネットワークアドレスと宛先輸送ポート番号に到着）を含む新しいパケットが新しい暗号化コンテキストを作成します。Media-Path SRTPキー設立を備えたテクニックの中で一般的な別のアプローチは、SRTPパケットが送信される前にそのメディアパスを握手する必要があることです。Mikeyのアプローチは、RTPが各セッションのSSRC値を事前に確立することを要求することにより、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がロールオーバーカウンター（ROC）を導入することです。これは、SRTPシーケンス番号がロールオーバーした回数を記録します。シーケンス番号は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.
注：すべてのNTH 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パケットのSSRCとROCのセットを示します。
MIKEY-PSK Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
Mikey-PSK各エンドポイントは、送信するSRTPパケットのSSRCとROCのセットを示します。
MIKEY-RSA Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
Mikey-RSA各エンドポイントは、送信するSRTPパケットのSSRCとROCのセットを示します。
MIKEY-RSA-R Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
Mikey-RSA-R各エンドポイントは、SSRCのセットと送信されるSRTPパケットのROCを示します。
MIKEY-DHSIGN Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
mikey-dhsign各エンドポイントは、送信するSRTPパケットのSSRCとROCのセットを示します。
MIKEY-DHHMAC Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
Mikey-DHHMAC各エンドポイントは、SSRCのセットと、送信するSRTPパケットのROCを示します。
MIKEYv2 in SDP Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
SDPのMikeyv2各エンドポイントは、SSRCのセットと送信されるSRTPパケットのROCを示しています。
SDP Security Descriptions with SIPS Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
SIPを使用したSDPセキュリティの説明SSRCもROCも知らない。SSRC「後期バインディング」が使用されます。
SDP Security Descriptions with S/MIME Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
S/MIMEを使用したSDPセキュリティの説明は、SSRCもROCも知られていません。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パケットのSSRCは、そのパケット内のSRTPマスターキーおよびその他のパラメーターに対応しています。
DTLS-SRTP Neither SSRC nor ROC are signaled. SSRC "late binding" is used.
DTLS-SRTP SSRCもROCも知られていません。SSRC「後期バインディング」が使用されます。
MIKEYv2 Inband Each endpoint indicates a set of SSRCs and the ROC for SRTP packets it transmits.
Mikeyv2 Inband各エンドポイントは、SSRCのセットと送信されるSRTPパケットのROCを示しています。
This section evaluates each keying mechanism on the basis of their security properties.
このセクションでは、セキュリティプロパティに基づいて各キーイングメカニズムを評価します。
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.
保存されたパブリックキーを機密性と認証に使用すると、証明書を使用して実装されることが多い2種類のシステムの要件を導入できます。（1）それらの永続的なパブリックキー証明書を配布するシステム、および（2）それらの永続的なパブリックキーを検証するシステム。前者を重要な配信システムと呼び、後者は認証インフラストラクチャと呼びます。多くの場合、これらの両方の役割を満たすために、モノリシックな公開キーインフラストラクチャ（PKI）が使用されます。ただし、これらの機能は他の多くのシステムで提供できます。たとえば、キーの公開リポジトリによってキーディストリビューションが達成される場合があります。2つのエンドポイントがトラストアンカーと中間CA証明書にアクセスできるシステムは、他のエンドポイントの証明書（自己署名証明書のシステムを含む）を検証するために使用できる中間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-Certs [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 Public-Key暗号化は使用されていません。
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オファーにはオファーの証明書が含まれており、答えには回答者の証明書が含まれています。Answererは、証明書の公開キーを使用して、提供者とAnswererが使用するSRTPキーを暗号化します。証明書を検証するには、認証インフラストラクチャが必要です。
MIKEY-DHSIGN An authentication infrastructure is used to authenticate the public key that is included in the MIKEY message.
mikey-dhsign認証インフラストラクチャは、Mikeyメッセージに含まれる公開キーを認証するために使用されます。
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.
SIPを使用した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パブリックキー暗号化が使用されます（Diffie-Hellman）が、永続的なパブリックキーに依存することはありません。したがって、証明書は取得または検証されません。
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パブリックキー暗号化はそれ自体では使用されませんが、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 inband動作は、どのモードが選択されるかによって異なります。
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のコンテキストでは、Perfect Forward Secrecyは、エンドポイントに属する静的キーが侵害された場合、前のセッションを保護した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 no pfs。
MIKEY-RSA No PFS.
Mikey-rsa no pfs。
MIKEY-RSA-R No PFS.
mikey-rsa-r no pfs。
MIKEY-DHSIGN PFS is provided with the Diffie-Hellman exchange.
Mikey-DHSign PFSは、Diffie-Hellman Exchangeで提供されます。
MIKEY-DHHMAC PFS is provided with the Diffie-Hellman exchange.
Mikey-DHHMAC PFSは、Diffie-Hellman Exchangeで提供されています。
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.
SIPを使用した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 Exchangeで提供されます。
ZRTP PFS is provided with the Diffie-Hellman exchange.
ZRTP PFSは、Diffie-Hellman Exchangeで提供されます。
EKT No PFS.
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は、交渉された暗号スイートがはかないキー（例：Diffie-Hellman（DHE_RSA [RFC5246]）または楕円曲線Diffie-Hellman [RFC4492]）を使用している場合に提供されます。
MIKEYv2 Inband The behavior will depend on which mode is picked.
mikeyv2 inband動作は、どのモードが選択されるかによって異なります。
With best effort encryption, SRTP is used with endpoints that support SRTP, otherwise RTP is used.
最良の努力暗号化により、SRTPはSRTPをサポートするエンドポイントで使用されます。それ以外の場合はRTPが使用されます。
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.
SIPは、SRTPがSRTPをサポートし、SRTPをサポートしないフォークまたはリターゲティングデバイスが混在している場合に、SRTPが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をサポートするボイスメールシステムのみを行う電話で、Bobのケースを考えてみましょう。AliceがSRTPオファーでボブに電話する場合、ボブの携帯電話がSRTP（RTP/SAVP）を理解していないため、ボブのRTPのみの電話がメディアストリームを拒否します（空の「M =」行を拒否します。Aliceの電話はこの拒否されたメディアストリームを表示し、コール全体（Bye）を終了し、RTPのみとして呼び出しを再挿入する可能性があります。または、Aliceの電話はSRTP対応脚（ボイスメールシステム）でコールセットアップを続行することを決定する場合があります。。Aliceの電話は、コールをRTPのみとして再誘導することを決定し、ボブが電話に応答しない場合、アリスは予想どおりSRTPではなくRTPのみを使用してボイスメールを残します。
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/Alternative [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].
セッション属性この手法では、エンドポイントは、RTP（RTP/AVP）をシグナルにし、SDPで属性（ "a ="）を使用して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です。これは、プロービング（メディアパスでZRTPメッセージを送信）またはセッション属性（[Zrtp]の「a = zrtp-hash」を参照）によって最善の努力暗号化を達成できます。ZRTPの現在の実装は、プロービングを使用します。
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のオファー/回答モデルを使用すると、これは、オファーにキー交換メカニズム（すべてのマイキーモード、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 Crypto Suiteを提供しているため、TGK（TEK Generation Key）を暗号化するためにRSA操作を実行する必要があります。
MIKEY-RSA-R For each offered SRTP crypto suite, the offerer has to perform public key operation to sign the MIKEY message.
Mikey-RSA-Rはそれぞれ提供されているSRTP Crypto Suiteを提供しているため、オファーは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.
Mikey-dhsignはそれぞれ提供されているSRTP Crypto Suite、提供者はDiffie-Hellman操作を実行する必要があり、Diffie-Hellman出力に署名する公開キー操作が必要です。
MIKEY-DHHMAC For each offered SRTP crypto suite, the offerer has to perform Diffie-Hellman operation.
Mikey-DHHMACはそれぞれ提供されているSRTP Crypto Suiteを提供しているため、提供者はDiffie-Hellman操作を実行する必要があります。
MIKEYv2 in SDP The behavior will depend on which mode is picked.
SDPのmikeyv2動作は、どのモードが選択されるかによって異なります。
SDP Security Descriptions with SIPS No significant computational expense.
SIPを使用した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.
SDP-DHはそれぞれ提供されているSRTP Crypto Suiteを提供するため、提供者はDiffie-Hellman操作を実行する必要があります。
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オファーにはZRTPに関する情報が含まれていないか、「a = Zrtp-hash」が含まれている可能性があるため、提供者には追加の計算費用はまったくありません。
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ブートストラップメカニズム（1つ以上の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-SRTPオファーには、DTLS Exchangeで提示される証明書の指紋のみが含まれているため、追加の計算費用はまったくありません。
MIKEYv2 Inband The behavior will depend on which mode is picked.
mikeyv2 inband動作は、どのモードが選択されるかによって異なります。
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ユーザーエージェント、トランスコダー、レコーダーなど）にアクセスできるエンドポイントの妥協は、このドキュメントの範囲外です。このような妥協は、特権のエスカレーション、ウイルスまたはトロイの木馬の設置、または同様の攻撃によってある可能性があります。
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はアリス、ボブ、キャロルからのRTPメディアの貢献と2、4、および6は、「混合」メディアを運ぶデバイスへの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は、同じ（Multi-Unicast）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）をサポートするために、ミキサーは参加者に暗号化キーを指示する必要があります。いくつかのキーイングメカニズムにより、送信機は独自のキーを決定することができ、他のメカニズムは提供者が提供者と回答者の鍵を決定することを可能にします。通話の確立方法に応じて、提供者は参加者（参加者がカンファレンスブリッジにダイヤルするなど）であるか、オファーがミキサー（参加者を呼び出すカンファレンスブリッジなど）である可能性があります。オファーレスの招待状を使用すると、一部のキーイングメカニズムがオファー/応答者の役割を逆転させるのに役立ちます。ただし、特定の呼び出しで役割を逆転させる必要がある場合、アプリオリを知ることは難しいことです。単一のアウトバウンドセッションの重要な利点は、参加者の数が増加してもSRTP暗号化操作の数が一定のままであることです。ただし、不利な点は、データの起源認証が失われ、参加者が送信者をスプーフィングできるようにすることです（すべての参加者が送信者のSRTPキーを知っているため）。
Authors' Addresses
著者のアドレス
Dan Wing (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ダンウィング（編集者）Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USA
EMail: dwing@cisco.com
Steffen Fries Siemens AG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Steffen Fries Siemens AG Otto-Hahn-Ring6 Munich、Bavaria 81739ドイツ
EMail: steffen.fries@siemens.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo, 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo、02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Francois Audet Nortel 4655 Great America Parkway Santa Clara, CA 95054 USA
フランソワ・オーデット・ノルテル4655グレート・アメリカ・パークウェイ・サンタ・クララ、カリフォルニア州95054 USA
EMail: audet@nortel.com