Internet Engineering Task Force (IETF) J. Fischl
Request for Comments: 5763 Skype, Inc.
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
E. Rescorla
RTFM, Inc.
May 2010
Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)
データグラムトランスポート層セキュリティ（DTLS）を使用してセキュアリアルタイム転送プロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク
Abstract
抽象
This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.
この文書では、データグラムトランスポート層セキュリティ（DTLS）プロトコルを使用してセキュアなリアルタイム転送プロトコル（SRTP）のセキュリティコンテキストを確立するために、セッション開始プロトコル（SIP）を使用する方法を指定します。これは、DTLSハンドシェイク中に提示されるキーを特定するセッション記述プロトコル（SDP）に指紋属性を輸送するメカニズムを説明しています。シグナル伝達経路とは対照的に、鍵交換は、媒体経路に沿って移動します。 SIPアイデンティティメカニズムは、中間プロキシによって変更から指紋属性の完全性を保護するために使用することができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5763.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5763で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
2. Overview ........................................................5
3. Motivation ......................................................7
4. Terminology .....................................................8
5. Establishing a Secure Channel ...................................8
6. Miscellaneous Considerations ...................................10
6.1. Anonymous Calls ...........................................10
6.2. Early Media ...............................................11
6.3. Forking ...................................................11
6.4. Delayed Offer Calls .......................................11
6.5. Multiple Associations .....................................11
6.6. Session Modification ......................................12
6.7. Middlebox Interaction .....................................12
6.7.1. ICE Interaction ....................................12
6.7.2. Latching Control without ICE .......................13
6.8. Rekeying ..................................................13
6.9. Conference Servers and Shared Encryptions Contexts ........13
6.10. Media over SRTP ..........................................14
6.11. Best Effort Encryption ...................................14
7. Example Message Flow ...........................................14
7.1. Basic Message Flow with Early Media and SIP Identity ......14
7.2. Basic Message Flow with Connected Identity (RFC 4916) .....19
7.3. Basic Message Flow with STUN Check for NAT Case ...........23
8. Security Considerations ........................................25
8.1. Responder Identity ........................................25
8.2. SIPS ......................................................26
8.3. S/MIME ....................................................26
8.4. Continuity of Authentication ..............................26
8.5. Short Authentication String ...............................27
8.6. Limits of Identity Assertions .............................27
8.7. Third-Party Certificates ..................................29
8.8. Perfect Forward Secrecy ...................................29
9. Acknowledgments ................................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Requirements Analysis ................................33
A.1. Forking and Retargeting (R-FORK-RETARGET,
R-BEST-SECURE, R-DISTINCT) ...............................33
A.2. Distinct Cryptographic Contexts (R-DISTINCT) .............33
A.3. Reusage of a Security Context (R-REUSE) ..................33
A.4. Clipping (R-AVOID-CLIPPING) ..............................33
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) .........33
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) .......34
A.7. (R-SIG-MEDIA, R-ACT-ACT) .................................34
A.8. Binding to Identifiers (R-ID-BINDING) ....................34
A.9. Perfect Forward Secrecy (R-PFS) ..........................34
A.10. Algorithm Negotiation (R-COMPUTE) ........................35
A.11. RTP Validity Check (R-RTP-VALID) .........................35
A.12. Third-Party Certificates (R-CERTS, R-EXISTING) ...........35
A.13. FIPS 140-2 (R-FIPS) ......................................35
A.14. Linkage between Keying Exchange and SIP Signaling
(R-ASSOC) ................................................35
A.15. Denial-of-Service Vulnerability (R-DOS) ..................35
A.16. Crypto-Agility (R-AGILITY) ...............................35
A.17. Downgrading Protection (R-DOWNGRADE) .....................36
A.18. Media Security Negotiation (R-NEGOTIATE) .................36
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) ......36
A.20. Media Recording (R-RECORDING) ............................36
A.21. Interworking with Intermediaries (R-TRANSCODER) ..........36
A.22. PSTN Gateway Termination (R-PSTN) ........................36
A.23. R-ALLOW-RTP ..............................................36
A.24. R-HERFP ..................................................37
The Session Initiation Protocol (SIP) [RFC3261] and the Session Description Protocol (SDP) [RFC4566] are used to set up multimedia sessions or calls. SDP is also used to set up TCP [RFC4145] and additionally TCP/TLS connections for usage with media sessions [RFC4572]. The Real-time Transport Protocol (RTP) [RFC3550] is used to transmit real-time media on top of UDP and TCP [RFC4571]. Datagram TLS [RFC4347] was introduced to allow TLS functionality to be applied to datagram transport protocols, such as UDP and DCCP. This document provides guidelines on how to establish SRTP [RFC3711] security over UDP using an extension to DTLS (see [RFC5764]).
セッション開始プロトコル（SIP）[RFC3261]及びセッション記述プロトコル（SDP）[RFC4566]は、マルチメディアセッションまたはコールをセットアップするために使用されます。 SDPはまた、TCP [RFC4145]とメディアセッション[RFC4572]での使用のためにさらにTCP / TLS接続を設定するために使用されます。リアルタイムトランスポートプロトコル（RTP）[RFC3550]はUDPとTCP [RFC4571]の上にリアルタイムメディアを送信するために使用されます。データグラムTLS [RFC4347]はTLSの機能は、UDPやDCCPなどのデータグラムトランスポートプロトコルに適用することを可能にするために導入されました。この文書では、（[RFC5764]を参照）DTLSの拡張機能を使用してUDP上SRTP [RFC3711]のセキュリティを確立する方法のガイドラインを提供します。
The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. It also does not require the devices to trust every call signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates that are signed by a well-known certificate authority to all devices.
この作業の目的は、事前の関係を持つデバイス間の暗号化通信を可能にする重要な交渉技術を提供することにあります。また、ルーティングまたはセッションセットアップに関わったすべてのコールシグナリング要素を信頼するようにデバイスを必要としません。このアプローチは、エンドユーザーが任意の余分な労力を必要とせず、すべてのデバイスにはよく知られた認証局によって署名された証明書の展開を必要としません。
The media is transported over a mutually authenticated DTLS session where both sides have certificates. It is very important to note that certificates are being used purely as a carrier for the public keys of the peers. This is required because DTLS does not have a mode for carrying bare keys, but it is purely an issue of formatting. The certificates can be self-signed and completely self-generated. All major TLS stacks have the capability to generate such certificates on demand. However, third-party certificates MAY also be used if the peers have them (thus reducing the need to trust intermediaries). The certificate fingerprints are sent in SDP over SIP as part of the offer/answer exchange.
メディアは、両側が証明書を持っている相互認証DTLSセッション上で転送されます。証明書がピアの公開鍵のためのキャリアとして純粋に使用されていることに注意することは非常に重要です。 DTLSは、裸の鍵を運ぶためのモードを持っていないので、これは必要ですが、それは純粋にフォーマットの問題です。証明書は自己署名、完全に自己生成することができます。すべての主要なTLSスタックはオンデマンドで、このような証明書を生成する機能を持っています。ピアが（したがって、仲介者を信頼する必要性を減らす）、それらを持っている場合は、サードパーティの証明書を使用してもよいです。証明書のフィンガープリントは、オファー/アンサー交換の一環として、SIPを介してSDPに送信されます。
The fingerprint mechanism allows one side of the connection to verify that the certificate presented in the DTLS handshake matches the certificate used by the party in the signaling. However, this requires some form of integrity protection on the signaling. S/MIME signatures, as described in RFC 3261, or SIP Identity, as described in [RFC4474], provide the highest level of security because they are not susceptible to modification by malicious intermediaries. However, even hop-by-hop security, such as provided by SIPS, offers some protection against modification by attackers who are not in control of on-path signaling elements. Because DTLS-SRTP only requires message integrity and not confidentiality for the signaling, the number of elements that must have credentials and be trusted is significantly reduced. In particular, if RFC 4474 is used, only the Authentication Service need have a certificate and be trusted. Intermediate elements cannot undetectably modify the message and therefore cannot mount a man-in-the-middle (MITM) attack. By comparison, because SDESCRIPTIONS [RFC4568] requires confidentiality for the signaling, all intermediate elements must be trusted.
指紋機構は、接続の一方の側は、DTLSハンドシェークに提示された証明書は、シグナル伝達のパーティによって使用される証明書と一致することを確認することを可能にします。しかし、これはシグナル伝達に対する完全性保護のいくつかのフォームが必要です。彼らは悪意のある仲介による修飾を受けないので、S / MIME署名、RFC 3261に記載されているように、またはSIPアイデンティティ、[RFC4474]に記載されているように、最高レベルのセキュリティを提供します。しかし、ホップバイホップSIPSによって提供されるこのようなセキュリティを、上のパスのシグナリング要素の制御に含まれていない攻撃者によって変更に対してある程度の保護を提供しています。 DTLS-SRTPのみシグナリングのためのメッセージの整合性と機密性はないが必要であるため、資格情報を持っている必要がありますし、信頼される要素の数が大幅に削減されます。 RFC 4474が使用されている場合は特に、唯一の認証サービスは、証明書を持っている必要がして信頼されます。中間要素は検出できないメッセージを変更することができず、従って、マン・イン・ザ・ミドル（MITM）攻撃を仕掛けることができません。 SDESCRIPTIONS [RFC4568]はシグナリングのための機密性を必要とするための比較により、全ての中間の要素は、信頼されなければなりません。
This approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., Multimedia Internet KEYing (MIKEY) [RFC3830]) is piggybacked in the signaling message exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints with only a cryptographic binding of the media keying to the SIP/SDP communication. It allows RTP and SIP to be used in the usual manner when there is no encrypted media.
このアプローチは、認証・鍵交換プロトコル（例えば、マルチメディアインターネットキーイング（MIKEY）[RFC3830]）がシグナリングメッセージ交換にピギーバックされたメディアトラフィックを保護する以前の試みとは異なります。 DTLS-SRTPと、エンドポイント間のメディアトラフィックの保護を確立するSIP / SDP通信にキーイング媒体のみ暗号結合でメディアエンドポイントによって行われます。何の暗号化されたメディアが存在しない場合には、RTPとSIPは、通常の方法で使用することができます。
In SIP, typically the caller sends an offer and the callee may subsequently send one-way media back to the caller before a SIP answer is received by the caller. The approach in this specification, where the media key negotiation is decoupled from the SIP signaling, allows the early media to be set up before the SIP answer is received while preserving the important security property of allowing the media sender to choose some of the keying material for the media. This also allows the media sessions to be changed, rekeyed, and otherwise modified after the initial SIP signaling without any additional SIP signaling.
SIPでは、一般的に、発信者が提供を送信し、SIPの答えは、発信者によって受信される前に呼び出される側はその後、呼び出し元に一方向のメディアを送信することができます。メディアキーのネゴシエーションがSIPシグナリングから切り離され、本明細書中のアプローチは、SIP応答が受信される前にメディア送信者が鍵素材の一部を選択することを可能にする重要なセキュリティ特性を維持しながら、早期のメディアを設定することができますメディアのため。これはまた、メディアセッションが、変更リキー、そうでなければ、追加のSIPシグナリングなしの初期SIPシグナリング後に変更されることを可能にします。
Design decisions that influence the applicability of this specification are discussed in Section 3.
この仕様の適用性に影響を与える設計上の決定は、第3節で議論されています。
Endpoints wishing to set up an RTP media session do so by exchanging offers and answers in SDP messages over SIP. In a typical use case, two endpoints would negotiate to transmit audio data over RTP using the UDP protocol.
RTPメディアセッションをセットアップしたいエンドポイントは、SIP上でSDPメッセージにオファーとアンサーを交換することによってそれを行います。典型的な使用例では、2つのエンドポイントは、UDPプロトコルを使用して、RTP上のオーディオデータを伝送するために交渉することになります。
Figure 1 shows a typical message exchange in the SIP trapezoid.
図1は、SIP台形における典型的なメッセージ交換を示します。
+-----------+ +-----------+
|SIP | SIP/SDP |SIP |
+------>|Proxy |----------->|Proxy |-------+
| |Server X | (+finger- |Server Y | |
| +-----------+ print, +-----------+ |
| +auth.id.) |
| SIP/SDP SIP/SDP |
| (+fingerprint) (+fingerprint,|
| +auth.id.) |
| |
| v
+-----------+ Datagram TLS +-----------+
|SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP |
|User Agent | Media |User Agent |
|Alice@X | <=================================> |Bob@Y |
+-----------+ +-----------+
Legend:
------>: Signaling Traffic
<-+-+->: Key Management Traffic
<=====>: Data Traffic
Figure 1: DTLS Usage in the SIP Trapezoid
図1：SIP台形でDTLSの使用
Consider Alice wanting to set up an encrypted audio session with Bob. Both Bob and Alice could use public-key-based authentication in order to establish a confidentiality protected channel using DTLS.
アリスはボブと暗号化されたオーディオセッションを設定したい考えてみましょう。ボブとアリスの両方がDTLSを使用して機密保護されたチャネルを確立するために、公開鍵ベースの認証を使用することができます。
Since providing mutual authentication between two arbitrary endpoints on the Internet using public-key-based cryptography tends to be problematic, we consider more deployment-friendly alternatives. This document uses one approach and several others are discussed in Section 8.
公開鍵ベースの暗号化を使用して、インターネット上の2つの任意のエンドポイント間の相互認証を提供することが問題となる傾向があるので、我々はより多くの展開に優しい代替案を検討してください。この文書では、一つのアプローチを使用し、他のいくつかは、セクション8で議論されています。
Alice sends an SDP offer to Bob over SIP. If Alice uses only self-signed certificates for the communication with Bob, a fingerprint is included in the SDP offer/answer exchange. This fingerprint binds the DTLS key exchange in the media plane to the signaling plane.
アリスはSIP上でボブにSDPのオファーを送ります。アリスはボブと通信するための唯一の自己署名証明書を使用している場合は、指紋がSDPオファー/アンサー交換に含まれています。この指紋は、シグナリングプレーンへのメディア面でのDTLSキー交換をバインドします。
The fingerprint alone protects against active attacks on the media but not active attacks on the signaling. In order to prevent active attacks on the signaling, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] may be used. When Bob receives the offer, the peers establish some number of DTLS connections (depending on the number of media sessions) with mutual DTLS authentication (i.e., both sides provide certificates). At this point, Bob can verify that Alice's credentials offered in TLS match the fingerprint in the SDP offer, and Bob can begin sending media to Alice. Once Bob accepts Alice's offer and sends an SDP answer to Alice, Alice can begin sending confidential media to Bob over the appropriate streams. Alice and Bob will verify that the fingerprints from the certificates received over the DTLS handshakes match with the fingerprints received in the SDP of the SIP signaling. This provides the security property that Alice knows that the media traffic is going to Bob and vice versa without necessarily requiring global Public Key Infrastructure (PKI) certificates for Alice and Bob. (See Section 8 for detailed security analysis.)
指紋だけでは、メディア上のアクティブな攻撃が、シグナリングのないアクティブな攻撃から保護します。シグナル伝達に対する活発な攻撃、「セッション開始プロトコル（SIP）で認証されたアイデンティティ管理の機能拡張」を防止するために、[RFC4474]は使用されてもよいです。ボブはオファーを受信すると、ピアは相互DTLS認証（即ち、両側が証明書を提供する）と（メディアセッションの数に応じて）DTLS接続のいくつかの数を確立します。この時点で、ボブは、TLSで提供Aliceの資格情報は、SDPオファー内の指紋と一致していることを確認することができ、ボブはアリスにメディアの送信を開始することができます。ボブがアリスの申し出を受け入れ、アリスにSDP回答を送信すると、アリスは、適切なストリームを介してボブに機密メディアの送信を開始することができます。アリスとボブは、証明書の指紋がSIPシグナリングのSDPで受信された指紋とDTLSハンドシェークマッチを介して受信することを確認します。これは、アリスがメディアトラフィックは必ずしもアリスとボブのためのグローバルな公開鍵基盤（PKI）証明書を必要とせずに、ボブとその逆に起こっていることを知っているセキュリティプロパティを提供します。 （詳細なセキュリティ分析については、セクション8を参照してください。）
Although there is already prior work in this area (e.g., Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combined with MIKEY [RFC3830] for authentication and key exchange), this specification is motivated as follows:
この分野における従来の研究（認証及び鍵交換用のMIKEYと組み合わせ例えば、セキュリティSDPの説明[RFC4568]、鍵管理拡張[RFC4567]、[RFC3830]）が既に存在するが、以下のように、本明細書に動機付けられています。
o TLS will be used to offer security for connection-oriented media. The design of TLS is well-known and implementations are widely available.
O TLSは接続指向のメディアのセキュリティを提供するために使用されます。 TLSのデザインはよく知られており、実装が広く利用可能です。
o This approach deals with forking and early media without requiring support for Provisional Response ACKnowledgement (PRACK) [RFC3262] while preserving the important security property of allowing the offerer to choose keying material for encrypting the media.
オファー側がメディアを暗号化するための鍵材料を選択することを可能にする重要なセキュリティ特性を維持しながら、[RFC3262]暫定応答確認（PRACK）のサポートを必要とせずにフォークと早期のメディアとOこのアプローチでは扱っています。
o The establishment of security protection for the media path is also provided along the media path and not over the signaling path. In many deployment scenarios, the signaling and media traffic travel along a different path through the network.
Oメディアパスのセキュリティ保護の確立はまた、媒体経路に沿っていないシグナリングパス上に設けられています。多くの展開シナリオでは、ネットワークを介して異なるパスに沿ってシグナリングおよびメディアトラフィックの旅。
o When RFC 4474 is used, this solution works even when the SIP proxies downstream of the authentication service are not trusted. There is no need to reveal keys in the SIP signaling or in the SDP message exchange, as is done in SDESCRIPTIONS [RFC4568]. Retargeting of a dialog-forming request (changing the value of the Request-URI), the User Agent (UA) that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. When RFC 4916 is used, then it is possible to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service.
RFC 4474を使用する場合は、O、このソリューションは、認証サービスの下流SIPプロキシが信頼されていない場合でも動作します。 SDESCRIPTIONS [RFC4568]に行われるようにSIPシグナリングまたはSDPメッセージ交換のキーを明らかにする必要はありません。ダイアログ形成要求（要求URIの値を変更する）の再標的化は、それを受信するユーザエージェント（UA）は、（ユーザエージェントサーバ、UAS）がToヘッダーフィールドとは異なるアイデンティティを有することができます。 RFC 4916が使用される場合、逆方向の要求によってピアUAにその識別情報を供給することが可能であり、そしてそのアイデンティティの認証サービスによって署名されます。
o In this method, synchronization source (SSRC) collisions do not result in any extra SIP signaling.
Oこの方法では、同期ソース（SSRC）衝突は余分なSIPシグナリングをもたらしません。
o Many SIP endpoints already implement TLS. The changes to existing SIP and RTP usage are minimal even when DTLS-SRTP [RFC5764] is used.
O多くのSIPエンドポイントがすでにTLSを実装します。既存のSIP及びRTPの使用への変更はDTLS-SRTP [RFC5764]を使用する場合でも最小です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
DTLS/TLS uses the term "session" to refer to a long-lived set of keying material that spans associations. In this document, consistent with SIP/SDP usage, we use it to refer to a multimedia session and use the term "TLS session" to refer to the TLS construct. We use the term "association" to refer to a particular DTLS cipher suite and keying material set that is associated with a single host/ port quartet. The same DTLS/TLS session can be used to establish the keying material for multiple associations. For consistency with other SIP/SDP usage, we use the term "connection" when what's being referred to is a multimedia stream that is not specifically DTLS/TLS.
DTLS / TLSは、関連付けをまたがる材料をキーイングの長寿命セットを参照するために用語「セッション」を使用しています。この文書では、SIP / SDP用法と一致し、我々は、マルチメディアセッションを参照して構築用語「TLSセッションは、」TLSを参照するために使用するためにそれを使用します。我々は、特定のDTLS暗号スイートおよび単一のホスト/ポートカルテットに関連付けられた鍵材料群を指すために「会合」という用語を使用します。同じDTLS / TLSセッションは、複数の関連付けのための鍵素材を確立するために使用することができます。他のSIP / SDP用法との一貫性を保つために、私たちは何と呼ばれていますが、具体的ではないTLS / DTLSマルチメディアストリームである「接続」を使用します。
In this document, the term "Mutual DTLS" indicates that both the DTLS client and server present certificates even if one or both certificates are self-signed.
この文書では、用語「相互DTLSは」DTLSクライアントとサーバの現在の証明書の両方があっても、一方または両方の証明書が自己署名であることを示しています。
The two endpoints in the exchange present their identities as part of the DTLS handshake procedure using certificates. This document uses certificates in the same style as described in "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572].
引き換えに、2つのエンドポイントは、証明書を使用してDTLSハンドシェイク手順の一部として彼らのアイデンティティを提示します。 [RFC4572]「セッション記述プロトコル（SDP）でTransport Layer Security（TLS）プロトコルを介して接続指向メディア交通」で説明したようにこの文書では、同じスタイルで証明書を使用します。
If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the uniform resource identifier (URI) of the user. This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. The integrity of the certificate is ensured through the fingerprint attribute in the SDP. The subjectAltName is not an important component of the certificate verification.
自己署名証明書を使用する場合、証明書のsubjectAltName内部属性の内容は、利用者のユニフォームリソース識別子（URI）を使用することができます。これはデバッグ目的のために有用であり、通信エンドポイントの1つに証明書をバインドする必要はありません。証明書の整合性は、SDPで指紋属性を使用して確保されています。 subjectAltNameは証明書の検証の重要なコンポーネントではありません。
The generation of public/private key pairs is relatively expensive. Endpoints are not required to generate certificates for each session.
公開鍵/秘密鍵ペアの生成は比較的高価です。エンドポイントは、各セッションの証明書を生成する必要はありません。
The offer/answer model, defined in [RFC3264], is used by protocols like the Session Initiation Protocol (SIP) [RFC3261] to set up multimedia sessions. In addition to the usual contents of an SDP
[RFC3264]で定義されたオファー/アンサーモデルは、マルチメディア・セッションを設定するために、セッション開始プロトコル（SIP）[RFC3261]のようなプロトコルによって使用されます。 SDPの通常の内容に加えて
[RFC4566] message, each media description ("m=" line and associated parameters) will also contain several attributes as specified in [RFC5764], [RFC4145], and [RFC4572].
[RFC5764]、[RFC4145]及び[RFC4572]で指定されるように[RFC4566]メッセージ、各メディア記述（ "M =" 行と関連するパラメータ）は、いくつかの属性を含むことになります。
When an endpoint wishes to set up a secure media session with another endpoint, it sends an offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, the fingerprint of the certificate that the endpoint wants to use. The endpoint SHOULD send the SIP message containing the offer to the offerer's SIP proxy over an integrity protected channel. The proxy SHOULD add an Identity header field according to the procedures outlined in [RFC4474]. The SIP message containing the offer SHOULD be sent to the offerer's SIP proxy over an integrity protected channel. When the far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header field. Since the Identity header field is a digital signature across several SIP header fields, in addition to the body of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was applied and added to the SIP message.
エンドポイントが別のエンドポイントとの安全なメディアセッションを設定したい場合、それは他のエンドポイントにSIPメッセージ内のオファーを送ります。このオファーは、SDPペイロード、エンドポイントが使用したい証明書のフィンガープリントの一部として、含まれています。エンドポイントは、完全性保護されたチャネルを介してオファー側のSIPプロキシへのオファーを含むSIPメッセージを送るべきです。プロキシは、[RFC4474]に概説された手順に従ってIdentityヘッダフィールドを追加する必要があります。プランを含むSIPメッセージは、完全性を保護チャネル上でオファー側のSIPプロキシに送信する必要があります。ファーエンドポイントがSIPメッセージを受信すると、それは、Identityヘッダフィールドを使用して送信者の身元を確認することができます。 Identityヘッダフィールドは、SIPメッセージの本体に加えて、いくつかのSIPヘッダフィールドを横切ってデジタル署名であるため、受信機は、デジタル署名をSIPに適用され、追加された後、メッセージが改ざんされていないことを確信することができメッセージ。
The far endpoint (answerer) may now establish a DTLS association with the offerer. Alternately, it can indicate in its answer that the offerer is to initiate the TLS association. In either case, mutual DTLS certificate-based authentication will be used. After completing the DTLS handshake, information about the authenticated identities, including the certificates, are made available to the endpoint application. The answerer is then able to verify that the offerer's certificate used for authentication in the DTLS handshake can be associated to the certificate fingerprint contained in the offer in the SDP. At this point, the answerer may indicate to the end user that the media is secured. The offerer may only tentatively accept the answerer's certificate since it may not yet have the answerer's certificate fingerprint.
これまでのエンドポイント（回答）は、現在、オファーでDTLSの関連付けを確立することができます。代わりに、それは、オファーがTLSの関連付けを開始することであると、その答えに示すことができます。いずれの場合も、相互DTLS証明書ベースの認証が使用されます。 、証明書を含む認証済みのアイデンティティに関する情報をDTLSハンドシェイクを完了した後に、エンドポイントのアプリケーションに使用可能になります。回答は、その後DTLSハンドシェイクで認証に使用されるオファーの証明書は、SDPオファー内に含まれる証明書のフィンガープリントに関連付けることができることを確認することができます。この時点で、回答は、メディアが固定され、エンドユーザーに示すことができます。それはまだ回答者の証明書のフィンガープリントを持っていないかもしれませんので、オファー側は暫定的に回答者の証明書を受け入れることができます。
When the answerer accepts the offer, it provides an answer back to the offerer containing the answerer's certificate fingerprint. At this point, the offerer can accept or reject the peer's certificate and the offerer can indicate to the end user that the media is secured.
回答を提示申し出を受け入れる場合は、回答者の証明書のフィンガープリントを含むオファー側に戻って答えを提供します。この時点で、オファー側が受け入れるか、ピアの証明書を拒否し、オファー側は、メディアが確保され、エンドユーザに示すことができます。
Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. The signaling path is only used to verify the peers' certificate fingerprints.
メディアトラフィックを確保するための全体の認証と鍵交換がDTLSを介してメディアパスで処理されることに留意されたいです。シグナル伝達経路は、ピアの証明書のフィンガープリントを確認するために使用されます。
The offer and answer MUST conform to the following requirements.
申し出と答えが次の要件に従わなければなりません。
o The endpoint MUST use the setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer. The answerer MUST use either a setup attribute value of setup:active or setup:passive. Note that if the answerer uses setup:passive, then the DTLS handshake will not begin until the answerer is received, which adds additional latency. setup:active allows the answer and the DTLS handshake to occur in parallel. Thus, setup:active is RECOMMENDED. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet).
Oエンドポイントは、[RFC4145]で定義された設定属性を使用しなければなりません。 actpassそれが答えを受け取る前にCLIENT_HELLOを受け取ることを準備する：オファー側は、セットアップの設定属性値を使用しなければならないであるエンドポイント。アクティブまたはセットアップ：：パッシブ回答は、セットアップの設定属性値のいずれかを使用しなければなりません。受動的な回答が受信されるまで、その後DTLSハンドシェークが追加のレイテンシが追加され、開始されません：回答がセットアップを使用している場合があります。セットアップ：アクティブ答えとDTLSハンドシェークが並行して発生することができます。このように、セットアップ：アクティブにすることをお勧めします。どちらの当事者各フロー（ホスト/ポートカルテット）上のClientHelloを送信することによってDTLSハンドシェイクを開始する必要があり、アクティブです。
o The endpoint MUST NOT use the connection attribute defined in [RFC4145].
Oエンドポイントは、[RFC4145]で定義された接続属性を使用してはなりません。
o The endpoint MUST use the certificate fingerprint attribute as specified in [RFC4572].
[RFC4572]で指定されたOエンドポイントは、証明書のフィンガープリント属性を使用しなければなりません。
o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. The security properties of this mechanism are described in Section 8.
O指紋と一致しなければならないDTLSハンドシェイク中に提示された証明書は、SDPにおけるシグナリング経路を介して交換しました。このメカニズムのセキュリティ・プロパティは、セクション8に記載されています。
o If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects.
指紋は、ハッシュ化された証明書と一致しない場合は、O、その後、エンドポイントは、すぐにメディアセッションを切断しなければなりません。相手側の指紋が接続を確立する前に受信されるまで待つことは許されないことに注意してください。しかし、これは望ましくない待ち時間の効果を有することができます。
The use of DTLS-SRTP does not provide anonymous calling; however, it also does not prevent it. However, if care is not taken when anonymous calling features, such as those described in [RFC3325] or [RFC5767] are used, DTLS-SRTP may allow deanonymizing an otherwise anonymous call. When anonymous calls are being made, the following procedures SHOULD be used to prevent deanonymization.
DTLS-SRTPを使用すると、匿名の呼び出しを提供していません。しかし、それはまた、それを防ぐことはできません。このような[RFC3325]または[RFC5767]に記載されているような匿名の発呼機能は、使用されている場合は注意が取られていない場合は、DTLS-SRTPは、そうでなければ、匿名の呼をdeanonymizing可能にすることができます。匿名の呼び出しが行われている場合は、次の手順はdeanonymizationを防ぐために使用されるべきです。
When making anonymous calls, a new self-signed certificate SHOULD be used for each call so that the calls cannot be correlated as to being from the same caller. In situations where some degree of correlation is acceptable, the same certificate SHOULD be used for a number of calls in order to enable continuity of authentication; see Section 8.4.
匿名の呼び出しを行うときにコールが同一の発信者からのものに関して相関させることができないように、新たな自己署名証明書は、各コールのために使用されるべきです。ある程度の相関が許容される状況では、同一の証明書は、認証の継続を可能にするためのコールの数のために使用されるべきです。 8.4節を参照してください。
Additionally, note that in networks that deploy [RFC3325], RFC 3325 requires that the Privacy header field value defined in [RFC3323] needs to be set to 'id'. This is used in conjunction with the SIP identity mechanism to ensure that the identity of the user is not asserted when enabling anonymous calls. Furthermore, the content of the subjectAltName attribute inside the certificate MUST NOT contain information that either allows correlation or identification of the user that wishes to place an anonymous call. Note that following this recommendation is not sufficient to provide anonymization.
また、[RFC3325]を展開するネットワークでは、RFC 3325は[RFC3323]で定義されたプライバシーヘッダフィールド値が「ID」に設定する必要があることを必要とすることに注意してください。これは、匿名の呼び出しを有効にする際、ユーザーのアイデンティティがアサートされていないことを確認するために、SIPアイデンティティメカニズムと組み合わせて使用されます。また、証明書の内部のsubjectAltName属性の内容は、匿名の電話をかけたいユーザの相関関係や同定を可能にするのどちらかという情報を含めることはできません。この勧告に従うことは匿名を提供するのに十分ではないことに注意してください。
If an offer is received by an endpoint that wishes to provide early media, it MUST take the setup:active role and can immediately establish a DTLS association with the other endpoint and begin sending media. The setup:passive endpoint may not yet have validated the fingerprint of the active endpoint's certificate. The security aspects of media handling in this situation are discussed in Section 8.
オファーは早期メディアを提供することを希望するエンドポイントによって受信された場合、それはセットアップ取る必要があります：積極的な役割をして、すぐに他のエンドポイントとDTLSアソシエーションを確立し、メディアの送信を開始することができます。セットアップ：パッシブエンドポイントがまだアクティブなエンドポイントの証明書のフィンガープリントを検証していない可能性があります。このような状況での取り扱いメディアのセキュリティの側面は、第8節で議論されています。
In SIP, it is possible for a request to fork to multiple endpoints. Each forked request can result in a different answer. Assuming that the requester provided an offer, each of the answerers will provide a unique answer. Each answerer will form a DTLS association with the offerer. The offerer can then securely correlate the SDP answer received in the SIP message by comparing the fingerprint in the answer to the hashed certificate for each DTLS association.
SIPにおいては、複数のエンドポイントにフォークに要求可能です。各フォーク要求が異なる答えを得ることができます。要求者が申し出を提供すると仮定すると、回答者のそれぞれがユニークな答えを提供します。それぞれの回答には、オファーとDTLSのアソシエーションを形成します。提供者は、その後、安全各DTLSアソシエーションのハッシュ化された証明書への回答でフィンガープリントを比較することによって、SIPメッセージで受信したSDPアンサーを相関させることができます。
An endpoint may send a SIP INVITE request with no offer in it. When this occurs, the receiver(s) of the INVITE will provide the offer in the response and the originator will provide the answer in the subsequent ACK request or in the PRACK request [RFC3262], if both endpoints support reliable provisional responses. In any event, the active endpoint still establishes the DTLS association with the passive endpoint as negotiated in the offer/answer exchange.
エンドポイントは、その中にいないオファーを含むSIP INVITE要求を送信することができます。これが発生すると、INVITEの受信機（複数可）は応答してオファーを提供し、両方のエンドポイントが信頼できる暫定的な応答をサポートしている場合、発信者は、後続のACK要求またはPRACK要求[RFC3262]に答えを提供するであろう。いずれにしても、アクティブなエンドポイントは、まだオファー/アンサー交換で交渉ような受動エンドポイントとDTLSの関連付けを確立します。
When there are multiple flows (e.g., multiple media streams, non-multiplexed RTP and RTCP, etc.) the active side MAY perform the DTLS handshakes in any order. Appendix B of [RFC5764] provides some guidance on the performance of parallel DTLS handshakes. Note that if the answerer ends up being active, it may only initiate handshakes on some subset of the potential streams (e.g., if audio and video are offered but it only wishes to do audio). If the offerer ends up being active, the complete answer will be received before the offerer begins initiating handshakes.
複数のフロー（例えば、複数のメディアストリーム、非多重RTPおよびRTCPなど）がある場合、アクティブ側は、任意の順序でDTLSハンドシェークを実行してもよいです。 [RFC5764]の付録Bは、並列DTLSハンドシェークの性能にいくつかのガイダンスを提供します。回答がアクティブで終わる場合、それは潜在的なストリーム（例えば、オーディオ及びビデオを提供するが、それは音声のみを行うことを希望している場合）の一部のサブセットにハンドシェークをのみ開始することができることに留意されたいです。オファー側がアクティブされて終わる場合はオファー側は握手を開始する開始する前に、完全な答えが受信されます。
Once an answer is provided to the offerer, either endpoint MAY request a session modification that MAY include an updated offer. This session modification can be carried in either an INVITE or UPDATE request. The peers can reuse the existing associations if they are compatible (i.e., they have the same key fingerprints and transport parameters), or establish a new one following the same rules are for initial exchanges, tearing down the existing association as soon as the offer/answer exchange is completed. Note that if the active/passive status of the endpoints changes, a new connection MUST be established.
その答えは、オファー側に提供された後、いずれかのエンドポイントは、更新のオファーを入れるかもしれセッションの変更を要求することができます。このセッションの変更は、いずれかのINVITEまたはUPDATEリクエストで実施することができます。彼らは互換性がある場合、ピアは、既存の関連付けを再利用することができます（つまり、彼らは同じ鍵指紋やトランスポートパラメータを持っている）、または提供するとすぐに既存の関連付けを切断、同じ規則が初期交換するためのもので、次の新しいものを確立/答え交換が完了しています。エンドポイントの変更のアクティブ/パッシブ状態ならば、新しい接続が確立されなければならないことに注意してください。
There are a number of potentially bad interactions between DTLS-SRTP and middleboxes, as documented in [MMUSIC-MEDIA], which also provides recommendations for avoiding such problems.
また、このような問題を回避するための推奨事項を提供する[MMUSIC-MEDIA]に記載されているようにDTLS-SRTPと中間装置との間の潜在的に悪い相互作用の数があります。
Interactive Connectivity Establishment (ICE), as specified in [RFC5245], provides a methodology of allowing participants in multimedia sessions to verify mutual connectivity. When ICE is being used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream.
インタラクティブ接続確立[RFC5245]で指定されるように（ICE）は、マルチメディアセッションの参加者は、相互接続性を検証することを可能にする方法を提供します。 ICEを使用している場合DTLSハンドシェークが始まる前に、ICE接続性チェックが実行されます。アグレッシブ指名モードが使用されている場合ICEが最終的に単一の候補ペアに収束する前に、複数の候補ペアが有効とマークすることができることに注意してください。実装は同じDTLSアソシエーションの一部として、単一の構成要素に関連付けられたすべてのICE候補ペアを扱わなければなりません。このように、複数の有効な候補対がある場合でも、一つだけDTLS握手が存在します。 DTLSパケットは通常のメディアストリームであるかのように、これは選択された候補ペアシフト場合、エンドポイントのIPアドレスを調整する意味するかもしれないことに注意してください。
Note that Simple Traversal of the UDP Protocol through NAT (STUN) packets are sent directly over UDP, not over DTLS. [RFC5764] describes how to demultiplex STUN packets from DTLS packets and SRTP packets.
NAT経由UDPプロトコル（STUN）パケットのシンプルなトラバーサルはUDP経由ではなく、DTLSを介して直接送信されていることに注意してください。 [RFC5764]はDTLSパケットおよびSRTPパケットからSTUNパケットを分離する方法について説明します。
If ICE is not being used, then there is potential for a bad interaction with Session Border Controllers (SBCs) via "latching", as described in [MMUSIC-MEDIA]. In order to avoid this issue, if ICE is not being used and the DTLS handshake has not completed upon receiving the other side's SDP, then the passive side MUST do a single unauthenticated STUN [RFC5389] connectivity check in order to open up the appropriate pinhole. All implementations MUST be prepared to answer this request during the handshake period even if they do not otherwise do ICE. However, the active side MUST proceed with the DTLS handshake as appropriate even if no such STUN check is received and the passive MUST NOT wait for a STUN answer before sending its ServerHello.
ICEが使用されていない場合は、[MMUSIC-MEDIA]に記載されているように、「ラッチ」を介して、セッションボーダーコントローラ（SBCS）との悪い相互作用の可能性があります。 ICEが使用されていないとDTLSハンドシェークは反対側のSDPを受信したときに完了していない場合は、この問題を回避するためには、受動側が適切なピンホールを開くために、単一の認証されていないSTUN [RFC5389]接続性チェックを行う必要があります。すべての実装は、彼らがそうでない場合はICEをしない場合でも、ハンドシェイク期間中にこの要求に答えるために準備しなければなりません。しかし、アクティブ側はそのようなSTUNのチェックが受信されないとパッシブはそののServerHelloを送る前に、STUNの答えを待つてはならない場合でも、必要に応じて、DTLSハンドシェイクを続行しなければなりません。
As with TLS, DTLS endpoints can rekey at any time by redoing the DTLS handshake. While the rekey is under way, the endpoints continue to use the previously established keying material for usage with DTLS. Once the new session keys are established, the session can switch to using these and abandon the old keys. This ensures that latency is not introduced during the rekeying process.
TLSと同様に、DTLSエンドポイントは、DTLSハンドシェイクをやり直すことにより、いつでもリキーすることができます。リキーが進行中ですが、エンドポイントがDTLSでの使用のために以前に確立された鍵素材を使用し続けています。新しいセッションキーが確立されると、セッションは、これらの使用に切り替えると、古いキーを放棄することができます。これは、レイテンシが鍵の再生成プロセスの間に導入されていないことを保証します。
Further considerations regarding rekeying in case the SRTP security context is established with DTLS can be found in Section 3.7 of [RFC5764].
SRTPセキュリティコンテキストがDTLSで確立された場合にリキーに関するさらなる考察は、[RFC5764]のセクション3.7に見出すことができます。
It has been proposed that conference servers might use the same encryption context for all of the participants in a conference. The advantage of this approach is that the conference server only needs to encrypt the output for all speakers instead of once per participant.
会議サーバは、会議の参加者のすべてに同じ暗号化コンテキストを使用するかもしれないことが提案されています。このアプローチの利点は、会議サーバのみすべてのスピーカーのための代わりに、参加者ごとに一度出力を暗号化する必要があるということです。
This shared encryption context approach is not possible under this specification because each DTLS handshake establishes fresh keys that are not completely under the control of either side. However, it is argued that the effort to encrypt each RTP packet is small compared to the other tasks performed by the conference server such as the codec processing.
各DTLSハンドシェークがどちらかの側の制御下に完全にない新鮮なキーを確立するため、この共有暗号コンテキストのアプローチは、本明細書の下では不可能です。しかし、各RTPパケットを暗号化するための努力は、このようなコーデック処理として、会議サーバによって実行される他のタスクに比べて小さいことを主張しています。
Future extensions, such as [SRTP-EKT] or [KEY-TRANSPORT], could be used to provide this functionality in concert with the mechanisms described in this specification.
このような[SRTP-EKT]または[KEY-TRANSPORT]などの将来の拡張が、本明細書で説明したメカニズムと協調してこの機能を提供するために使用することができます。
Because DTLS's data transfer protocol is generic, it is less highly optimized for use with RTP than is SRTP [RFC3711], which has been specifically tuned for that purpose. DTLS-SRTP [RFC5764] has been defined to provide for the negotiation of SRTP transport using a DTLS connection, thus allowing the performance benefits of SRTP with the easy key management of DTLS. The ability to reuse existing SRTP software and hardware implementations may in some environments provide another important motivation for using DTLS-SRTP instead of RTP over DTLS. Implementations of this specification MUST support DTLS-SRTP [RFC5764].
DTLSのデータ転送プロトコルは、汎用であるため、それは、具体的には、その目的のためにチューニングされたSRTP [RFC3711]よりも少ない非常にRTPで使用するために最適化されています。 DTLS-SRTP [RFC5764]はこのようにDTLSの簡単な鍵管理とSRTPのパフォーマンス上の利点をできるように、DTLS接続を使用してSRTP輸送の交渉を提供するために定義されています。既存のSRTPのソフトウェアとハードウェアの実装を再利用する機能は、一部の環境では、DTLS、SRTPを使用する代わりに、RTPのDTLSを超えるためにもう一つの重要な動機を提供することができますで。この仕様の実装は、DTLS、SRTP [RFC5764]をサポートしなければなりません。
[RFC5479] describes a requirement for best-effort encryption where SRTP is used and where both endpoints support it and key negotiation succeeds, otherwise RTP is used.
[RFC5479]はSRTPを使用し、どこの両方のエンドポイントがそれをサポートし、キーのネゴシエーションが成功した、そうでない場合はRTPが使用されているベストエフォート型の暗号化のための要件について説明します。
[MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP as an alternative. This allows an offerer to express a preference for SRTP, but RTP is the default and will be understood by endpoints that do not understand SRTP or this key exchange mechanism. Implementations of this document MUST support [MMUSIC-SDP].
[MMUSIC-SDP】代替としてRTPとSRTPの両方に信号を送ることができる機構を記載しています。これは、SRTPのための好みを表現するために、オファーを許可しますが、RTPはデフォルトで、SRTPやこの鍵交換メカニズムを理解していないエンドポイントによって理解されるであろう。このドキュメントの実装は、[MMUSIC-SDP]をサポートしなければなりません。
Prior to establishing the session, both Alice and Bob generate self-signed certificates that are used for a single session or, more likely, reused for multiple sessions. In this example, Alice calls Bob. In this example, we assume that Alice and Bob share the same proxy.
セッションを確立する前は、アリスとボブの両方が複数のセッションのために再利用する単一のセッションや、より多くの可能性が高いために使用されている自己署名証明書を生成します。この例では、アリスはボブを呼び出します。この例では、アリスとボブが同じプロキシを共有することを前提としています。
This example shows the SIP message flows where Alice acts as the passive endpoint and Bob acts as the active endpoint; meaning that as soon as Bob receives the INVITE from Alice, with DTLS specified in the "m=" line of the offer, Bob will begin to negotiate a DTLS association with Alice for both RTP and RTCP streams. Early media (RTP and RTCP) starts to flow from Bob to Alice as soon as Bob sends the DTLS finished message to Alice. Bi-directional media (RTP and RTCP) can flow after Alice receives the SIP 200 response and once Alice has sent the DTLS finished message.
この例では、アリスは、受動的エンドポイントとして機能し、ボブがアクティブエンドポイントとして機能する場合、SIPメッセージフローを示す図です。すぐに、ボブがアリスからのINVITEを受信すると、オファーの「M =」行で指定されたDTLSと、ボブはRTPとRTCPストリームの両方のためにアリスとDTLSアソシエーションをネゴシエートし始めること。意味早期メディア（RTPおよびRTCP）は、ボブがアリスにメッセージを終えDTLSを送信するとすぐにアリスにボブから流れ始めます。アリスは、SIP 200応答を受信し、アリスがDTLS終了メッセージを送信した後の後、双方向メディア（RTPおよびRTCP）が流れることができます。
The SIP signaling from Alice to her proxy is transported over TLS to ensure an integrity protected channel between Alice and her identity service. Transport between proxies should also be protected somehow, especially if SIP Identity is not in use.
彼女のプロキシにアリスからのSIPシグナリングは、アリスと彼女のアイデンティティサービスとの間の整合性保護されたチャネルを確保するために、TLS上で転送されます。プロキシ間の交通もSIPアイデンティティが使用されていない場合は特に、何とか保護すべきです。
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
| <------------------|
|(9) 200 OK | |
|<----------------| |
| |(10) media |
|<---------------------------------->|
|(11) ACK | |
|----------------------------------->|
Message (1): INVITE Alice -> Proxy
メッセージ（1）：INVITEアリス - >プロキシ
This shows the initial INVITE from Alice to Bob carried over the TLS transport protocol to ensure an integrity protected channel between Alice and her proxy that acts as Alice's identity service. Alice has requested to be either the active or passive endpoint by specifying a=setup:actpass in the SDP. Bob chooses to act as the DTLS client and will initiate the session. Also note that there is a fingerprint attribute in the SDP. This is computed from Alice's self-signed certificate.
これは、アリスとアリスのアイデンティティサービスとして動作し、彼女のプロキシ間の整合性保護されたチャネルを確保するために、TLSトランスポートプロトコル上で搬送される初期はアリスからボブにINVITEを示しています。 SDPでactpass：アリス=セットアップを指定することにより、能動的または受動的エンドポイントのいずれかであることが要求されています。ボブはDTLSクライアントとして動作するように選択し、セッションを開始します。また、SDPで指紋属性があることに注意してください。これは、アリスの自己署名証明書から計算されます。
This offer includes a default "m=" line offering RTP in case the answerer does not support SRTP. However, the potential configuration utilizing a transport of SRTP is preferred. See [MMUSIC-SDP] for more details on the details of SDP capability negotiation.
このオファーは、SRTPをサポートしていない場合には回答をRTPを提供するデフォルトの「M =」の行を含んでいます。しかし、SRTPのトランスポートを利用可能な構成が好ましいです。 SDP機能ネゴシエーションの詳細についての詳細は、[MMUSIC-SDP]を参照してください。
INVITE sip:bob@example.com SIP/2.0 To: <sip:bob@example.com> From: "Alice"<sip:alice@example.com>;tag=843c7b0b Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Contact: <sip:alice@ua1.example.com> Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Max-Forwards: 70 Content-Type: application/sdp Content-Length: xxxx Supported: from-change
<bob@example.com SIP：>： "アリス" をbob@example.com SIP / 2.0：SIPのINVITE <SIP：alice@example.com>;タグ= 843c7b0bのVia：SIP / 2.0 / TLS ua1.example .COM;ブランチ= z9hG4bK-0e53sadfkasldkfj連絡先：<SIP：alice@ua1.example.com>は、コールIDを：REVMTEpGのCSeq @ 6076913b1c39c212：UPDATEマックス転送し、BYE、INVITE、ACK、CANCEL、OPTIONS：70許可INVITE 1コンテンツタイプ：アプリケーション/ SDPのContent-Length：サポートされているXXXX：から変更
v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=setup:actpass a=fingerprint: SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 6056 RTP/AVP 0 a=sendrecv a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=pcfg:1 t=1
V = 0 0 = - 1181923068 1181923196 IN IP4 ua1.example.com S =例1 C = IN IP4 ua1.example.com A =セットアップ=指紋actpass：SHA-1 \ 4A：AD：B9：B1：3F： 82：18：3B：54：02：12：DF：3E：5D：49：6B：19：E5：7C：ABのT = 0、M =オーディオ6056 RTP / AVP 0 = SENDRECV A = TCAP：1 UDP / TLS / RTP / SAVP RTP / AVP A = PCFG：1 T = 1
Message (2): INVITE Proxy -> Bob
メッセージ（2）：プロキシをINVITE - >ボブ
This shows the INVITE being relayed to Bob from Alice (and Bob's) proxy. Note that Alice's proxy has inserted an Identity and Identity-Info header. This example only shows one element for both proxies for the purposes of simplification. Bob verifies the identity provided with the INVITE.
これは、アリス（とボブの）プロキシからボブに中継されるINVITEを示しています。アリスのプロキシがアイデンティティとアイデンティティ-Infoヘッダーを挿入していることに注意してください。この例では、簡略化の目的のために、両方のプロキシのための1つの要素を示しています。ボブは、INVITEを提供身元を確認します。
INVITE sip:bob@ua2.example.com SIP/2.0 To: <sip:bob@example.com> From: "Alice"<sip:alice@example.com>;tag=843c7b0b Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Record-Route: <sip:proxy.example.com;lr> Contact: <sip:alice@ua1.example.com> Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Max-Forwards: 69 Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= Identity-Info: https://example.com/cert Content-Type: application/sdp Content-Length: xxxx Supported: from-change
SIP INVITE：bob@ua2.example.comをSIP / 2.0 <SIP：bob@example.com>から： "アリス" <SIP：alice@example.com>;タグ= 843c7b0bのVia：SIP / 2.0 / TLSプロキシ.example.comと、ブランチ= z9hG4bK-0e53sadfkasldk経由：SIP / 2.0 / TLS ua1.example.com;ブランチ= z9hG4bK-0e53sadfkasldkfj録音-ルート：<SIP：proxy.example.com; LR>連絡先：<SIP：アリス@ ua1.example.com>コール-IDを：REVMTEpGのCSeq @ 6076913b1c39c212：UPDATEマックス転送し、BYE、INVITE、ACK、CANCEL、OPTIONS：69アイデンティティ：CyI4 + nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 3W + v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC HYWGCl0nB2sNsM9CG4hq + YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI =アイデンティティ情報の許可INVITE 1 ：https://example.com/certのContent-Type：アプリケーション/ SDPのContent-Length：サポートされているXXXX：から変更
v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=setup:actpass a=fingerprint: SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 6056 RTP/AVP 0 a=sendrecv a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=pcfg:1 t=1
V = 0 0 = - 1181923068 1181923196 IN IP4 ua1.example.com S =例1 C = IN IP4 ua1.example.com A =セットアップ=指紋actpass：SHA-1 \ 4A：AD：B9：B1：3F： 82：18：3B：54：02：12：DF：3E：5D：49：6B：19：E5：7C：ABのT = 0、M =オーディオ6056 RTP / AVP 0 = SENDRECV A = TCAP：1 UDP / TLS / RTP / SAVP RTP / AVP A = PCFG：1 T = 1
Message (3): ClientHello Bob -> Alice
メッセージ（3）：のClientHelloボブ - >アリス
Assuming that Alice's identity is valid, Line 3 shows Bob sending a DTLS ClientHello(s) directly to Alice. In this case, two DTLS ClientHello messages would be sent to Alice: one to ua1.example.com:6056 for RTP and another to port 6057 for RTCP, but only one arrow is drawn for compactness of the figure.
アリスのアイデンティティが有効であると仮定すると、3行目は、ボブが直接アリスにDTLSのClientHello（複数可）を送信示しています。 RTCPのポート6057にRTPと別のものua1.example.com:6056するために、1つ1つだけの矢印は、図のコンパクトさのために描かれている。この場合、2件のDTLSのClientHelloメッセージがアリスに送信されます。
Message (4): ServerHello+Certificate Alice -> Bob
メッセージ（4）：のServerHello +証明書アリス - >ボブ
Alice sends back a ServerHello, Certificate, and ServerHelloDone for both RTP and RTCP associations. Note that the same certificate is used for both the RTP and RTCP associations. If RTP/RTCP multiplexing [RFC5761] were being used only a single association would be required.
アリスはRTPとRTCP団体の両方のためのServerHello、証明書、およびServerHelloDoneを送り返します。同じ証明書は、RTPとRTCP団体の両方に使用されることに注意してください。 RTP / RTCP多重[RFC5761]は、単一の関連付けを使用されていた場合に必要とされるであろう。
Message (5): Certificate Bob -> Alice
メッセージ（5）：証明書ボブ - >アリス
Bob sends a Certificate, ClientKeyExchange, CertificateVerify, change_cipher_spec, and Finished for both RTP and RTCP associations. Again note that Bob uses the same server certificate for both associations.
ボブは、証明書、ClientKeyExchange、CertificateVerify、change_cipher_specを送信し、RTPとRTCP団体の両方のために完成しました。再びボブは、両方の団体のために同じサーバー証明書を使用することに注意してください。
Message (6): Early Media Bob -> Alice
メッセージ（6）：初期メディアボブ - >アリス
At this point, Bob can begin sending early media (RTP and RTCP) to Alice. Note that Alice can't yet trust the media since the fingerprint has not yet been received. This lack of trusted, secure media is indicated to Alice via the UA user interface.
この時点で、ボブはアリスに初期メディア（RTPおよびRTCP）の送信を開始することができます。指紋がまだ受信されていないので、アリスはまだメディアを信頼できないことに注意してください。信頼され、安全なメディアの欠如は、UAのユーザインタフェースを介してアリスに示されています。
Message (7): Finished Alice -> Bob
メッセージ（7）：完成アリス - >ボブ
After Message 7 is received by Bob, Alice sends change_cipher_spec and Finished.
メッセージ7は、ボブによって受信された後、アリスはchange_cipher_specと完成送信します。
Message (8): 200 OK Bob -> Alice
メッセージ（8）：200 OKボブ - >アリス
When Bob answers the call, Bob sends a 200 OK SIP message that contains the fingerprint for Bob's certificate. Bob signals the actual transport protocol configuration of SRTP over DTLS in the acfg parameter.
ボブが呼び出しに応答すると、ボブは、ボブの証明書のフィンガープリントが含まれている200 OK SIPメッセージを送信します。ボブはacfgパラメータでDTLS上SRTPの実際のトランスポート・プロトコル・コンフィギュレーションに信号を送ります。
SIP/2.0 200 OK To: <sip:bob@example.com>;tag=6418913922105372816 From: "Alice" <sip:alice@example.com>;tag=843c7b0b Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Record-Route: <sip:proxy.example.com;lr> Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Contact: <sip:bob@ua2.example.com> Content-Type: application/sdp Content-Length: xxxx Supported: from-change v=0 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com s=example2 c=IN IP4 ua2.example.com a=setup:active a=fingerprint: SHA-1 \ FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 12000 UDP/TLS/RTP/SAVP 0 a=acfg:1 t=1
SIP / 2.0 200 OKに<SIP：bob@example.com>;からタグ= 6418913922105372816： "アリス" <SIP：alice@example.com>;タグ= 843c7b0bのVia：SIP / 2.0 / TLS proxy.example.com ：; 5061経由ブランチ= z9hG4bK-0e53sadfkasldk：SIP / 2.0 / TLS ua1.example.com;ブランチ= z9hG4bK-0e53sadfkasldkfj録音-ルート：<SIP：proxy.example.com; LR>コールID：6076913b1c39c212 REVMTEpGのCSeq @： <一口：bob@ua2.example.com>のContent-Type：アプリケーション/ SDPのContent-Length：1連絡先をINVITEサポートXXXX：から変更V = 0 0 = - IP4、IN 6418913922105372816 2105372818 ua2.example.com S =例2 C = IN IP4 ua2.example.com A =セットアップ：アクティブA =指紋：SHA-1 \ FF：FF：FF：B1：3F：82：18：3B：54：02：12：DF：3E：5D： 49：6B：19：E5：7C：AB T = 0、M =オーディオ12000 UDP / TLS / RTP / SAVP 0 A = acfg：1、T = 1
Message (9): 200 OK Proxy -> Alice
メッセージ（9）：200 OKプロキシ - >アリス
Alice receives the message from her proxy and validates the certificate presented in Message 7. The endpoint now shows Alice that the call as secured.
アリスは、プロキシからのメッセージを受け取り、メッセージ7でエンドポイントを提示された証明書は、現在のコールが確保などというアリスを示して検証します。
Message (10): RTP+RTCP Alice -> Bob
メッセージ（10）：RTP + RTCPアリス - >ボブ
At this point, Alice can also start sending RTP and RTCP to Bob.
この時点で、アリスもボブにRTPとRTCPの送信を開始することができます。
Message (11): ACK Alice -> Bob
メッセージ（11）：ACKアリス - >ボブ
Finally, Alice sends the SIP ACK to Bob.
最後に、アリスはボブにSIP ACKを送信します。
The previous example did not show the use of RFC 4916 for connected identity. The following example does:
前の例では、接続のアイデンティティのためのRFC 4916の使用を示しませんでした。次の例ではありません。
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
|<-----------------------------------|
|(9) ACK | |
|----------------------------------->|
| |(10) UPDATE |
| |<-----------------|
|(11) UPDATE | |
|<----------------| |
|(12) 200 OK | |
|---------------->| |
| |(13) 200 OK |
| |----------------->|
| |(14) media |
|<---------------------------------->|
The first 9 messages of this example are the same as before. However, Messages 10-13, performing the RFC 4916 UPDATE, are new.
この例の最初の9つのメッセージは前と同じです。しかし、RFC 4916 UPDATEを実行するメッセージ10-13は、新しく追加されました。
Message (10): UPDATE Bob -> Proxy
メッセージ（10）：UPDATEボブ - >プロキシ
Bob sends an RFC 4916 UPDATE towards Alice. This update contains his fingerprint. Bob's UPDATE contains the same session information that he provided in his 200 OK (Message 8). Note that in principle an UPDATE here can be used to modify session parameters. However, in this case it's being used solely to confirm the fingerprint.
ボブは、アリスの方にRFC 4916 UPDATEを送信します。このアップデートは、彼の指紋が含まれています。ボブのUPDATEは、彼が彼の200 OK（メッセージ8）で提供することを同じセッション情報が含まれています。原則的に、ここでUPDATEがセッションパラメータを変更するために使用できることに注意してください。しかし、この場合には、指紋を確認するためだけに使用されています。
UPDATE sip:alice@ua1.example.com SIP/2.0 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj To: "Alice" <sip:alice@example.com>;tag=843c7b0b From <sip:bob@example.com>;tag=6418913922105372816 Route: <sip:proxy.example.com;lr> Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 2 UPDATE Contact: <sip:ua2.example.com> Content-Type: application/sdp Content-Length: xxxx Supported: from-change Max-Forwards: 70
UPDATEのSIP：alice@ua1.example.com SIP / 2.0経由：SIP / 2.0 / TLS ua2.example.com;への分岐= z9hG4bK-0e53sadfkasldkfj： "アリス"：;タグ= 843c7b0bから<一口alice@example.com> <一口：bob@example.com>;タグ= 6418913922105372816ルート：<SIP：proxy.example.com; LR>コールID：6076913b1c39c212 REVMTEpGのCSeq @：2 UPDATE連絡先：<SIP：ua2.example.com>のContentタイプ：application / SDPのContent-Length：サポートされているXXXX：から変更マックス - フォワード：70
v=0 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com s=example2 c=IN IP4 ua2.example.com a=setup:active a=fingerprint: SHA-1 \ FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 12000 UDP/TLS/RTP/SAVP 0 a=acfg:1 t=1
V = 0 0 = - 6418913922105372816 2105372818 IN IP4 ua2.example.com S =例2 C = IN IP4 ua2.example.com A =セットアップ：アクティブA =指紋：SHA-1 \ FF：FF：FF：B1：3F： 82：18：3B：54：02：12：DF：3E：5D：49：6B：19：E5：7C：= acfg AB T = 0、M =オーディオ12000 UDP / TLS / RTP / SAVP 0 A：1トン= 1
Message (11): UPDATE Proxy -> Alice
メッセージ（11）：UPDATEプロキシ - >アリス
This shows the UPDATE being relayed to Alice from Bob (and Alice's proxy). Note that Bob's proxy has inserted an Identity and Identity-Info header. As above, we only show one element for both proxies for purposes of simplification. Alice verifies the identity provided. (Note: the actual identity signatures here are incorrect and provided merely as examples.)
これは、ボブからアリスに中継されるUPDATE（とアリスのプロキシ）を示しています。ボブのプロキシがアイデンティティとアイデンティティ-Infoヘッダーを挿入していることに注意してください。上記のように、我々は唯一の簡略化の目的のために、両方のプロキシのための一つの要素を示しています。アリスは、提供アイデンティティを検証します。 （注：ここで実際のアイデンティティの署名が正しくないと、例としてのみ提供されます。）
UPDATE sip:alice@ua1.example.com SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj To: "Alice" <sip:alice@example.com>;tag=843c7b0b From <sip:bob@example.com>;tag=6418913922105372816 Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 2 UPDATE Contact: <sip:bob@ua2.example.com> Content-Type: application/sdp Content-Length: xxxx Supported: from-change Max-Forwards: 69 Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= Identity-Info: https://example.com/cert
UPDATEのSIP：alice@ua1.example.com SIP / 2.0経由：SIP / 2.0 / TLS proxy.example.com;分岐= z9hG4bK-0e53sadfkasldkfjのVia：SIP / 2.0 / TLS ua2.example.com;分岐= z9hG4bK-0e53sadfkasldkfjに： "アリス" <一口：alice@example.com>;からタグ= 843c7b0b <一口：bob@example.com>;タグ= 6418913922105372816のCall-ID：6076913b1c39c212 REVMTEpGのCSeq @：2 UPDATE連絡先：<SIP：ボブ@のUA2 .example.comと>のContent-Type：アプリケーション/ SDPのContent-Length：サポートされているXXXX：から変更マックス - フォワード：69アイデンティティ：CyI4 + nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 3W + v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC HYWGCl0nB2sNsM9CG4hq + YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI =アイデンティティ情報：https://example.com / CERT
v=0 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com s=example2 c=IN IP4 ua2.example.com a=setup:active a=fingerprint: SHA-1 \ FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 12000 UDP/TLS/RTP/SAVP 0 a=acfg:1 t=1
V = 0 0 = - 6418913922105372816 2105372818 IN IP4 ua2.example.com S =例2 C = IN IP4 ua2.example.com A =セットアップ：アクティブA =指紋：SHA-1 \ FF：FF：FF：B1：3F： 82：18：3B：54：02：12：DF：3E：5D：49：6B：19：E5：7C：= acfg AB T = 0、M =オーディオ12000 UDP / TLS / RTP / SAVP 0 A：1トン= 1
Message (12): 200 OK Alice -> Bob
メッセージ（12）：200 OKアリス - >ボブ
This shows Alice's 200 OK response to Bob's UPDATE. Because Bob has merely sent the same session parameters he sent in his 200 OK, Alice can simply replay her view of the session parameters as well.
これは、ボブのUPDATEにアリスの200 OK応答を示しています。ボブは単に彼が200 OKで送信された同じセッションパラメータを送信したので、アリスは、単に、同様のセッションパラメータの彼女のビューを再生することができます。
SIP/2.0 200 OK To: "Alice" <sip:alice@example.com>;tag=843c7b0b From <sip:bob@example.com>;tag=6418913922105372816 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 2 UPDATE Contact: <sip:bob@ua2.example.com> Content-Type: application/sdp Content-Length: xxxx Supported: from-change
SIP / 2.0 200 OK：を "アリス" <SIP：alice@example.com>;からタグ= 843c7b0b <SIP：bob@example.com>;タグ= 6418913922105372816のVia：SIP / 2.0 / TLS proxy.example.com。 2 UPDATE連絡先：：<SIP：bob@ua2.example.com> Content-TypeのREVMTEpGのCSeq @ 6076913b1c39c212：;：ブランチ= z9hG4bK-0e53sadfkasldkfj経由ブランチ= z9hG4bK-0e53sadfkasldkfjコール-ID SIP / 2.0 / TLS ua2.example.com ：アプリケーション/ SDPコンテンツの長さは：サポートされているXXXX：から変更
v=0 o=- 1181923068 1181923196 IN IP4 ua2.example.com s=example1 c=IN IP4 ua2.example.com a=setup:actpass a=fingerprint: SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 6056 RTP/AVP 0 a=sendrecv a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=pcfg:1 t=1
V = 0 0 = - 1181923068 1181923196 IN IP4 ua2.example.com S =例1 C = IN IP4 ua2.example.com A =セットアップ=指紋actpass：SHA-1 \ 4A：AD：B9：B1：3F： 82：18：3B：54：02：12：DF：3E：5D：49：6B：19：E5：7C：ABのT = 0、M =オーディオ6056 RTP / AVP 0 = SENDRECV A = TCAP：1 UDP / TLS / RTP / SAVP RTP / AVP A = PCFG：1 T = 1
In the previous examples, the DTLS handshake has already completed by the time Alice receives Bob's 200 OK (8). Therefore, no STUN check is sent. However, if Alice had a NAT, then Bob's ClientHello might get blocked by that NAT, in which case Alice would send the STUN check described in Section 6.7.1 upon receiving the 200 OK, as shown below:
前の例では、DTLSハンドシェイクはすでにアリスはボブの200 OK（8）を受信した時点で完了しました。そのため、STUNチェックは送信されません。アリスはNATを持っていた場合は、その後、ボブのClientHelloは、以下に示すように、アリスは、200 OKを受信すると、セクション6.7.1で説明STUNチェックを送信した場合には、そのNATによってブロックされる可能性があります：
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
| X<-----------------|
| |(4) 200 OK |
|<-----------------------------------|
| (5) conn-check | |
|----------------------------------->|
| |(6) conn-response |
|<-----------------------------------|
| |(7) hello (rtx) |
|<-----------------------------------|
|(8) hello | |
|----------------------------------->|
| |(9) finished |
|<-----------------------------------|
| |(10) media |
|<-----------------------------------|
|(11) finished | |
|----------------------------------->|
| |(11) media |
|----------------------------------->|
|(12) ACK | |
|----------------------------------->|
The messages here are the same as in the first example (for simplicity this example omits an UPDATE), with the following three new messages:
ここでのメッセージは、以下の3つの新しいメッセージで、（簡単にするため、この例では、UPDATEを省略）最初の例と同じです：
Message (5): STUN connectivity-check Alice -> Bob
メッセージ（5）：STUNの接続性チェックアリス - >ボブ
Section 6.7.1 describes an approach to avoid an SBC interaction issue where the endpoints do not support ICE. Alice (the passive endpoint) sends a STUN connectivity check to Bob. This opens a pinhole in Alice's NAT/firewall.
6.7.1項では、エンドポイントは、ICEをサポートしていないSBCの相互作用の問題を回避するためのアプローチを説明しています。アリス（パッシブエンドポイント）がボブにSTUNの接続性チェックを送信します。これは、アリスのNAT /ファイアウォールにピンホールを開きます。
Message (6): STUN connectivity-check response Bob -> Alice
メッセージ（6）：STUN接続チェック応答ボブ - >アリス
Bob (the active endpoint) sends a response to the STUN connectivity check (Message 3) to Alice. This tells Alice that her connectivity check has succeeded and she can stop the retransmit state machine.
ボブ（アクティブなエンドポイント）が、アリスにSTUN接続性チェック（メッセージ3）に応答を送信します。これは彼女の接続性チェックが成功したと、彼女は再送信ステートマシンを停止することができますことをアリスに伝えます。
Message (7): Hello (retransmit) Bob -> Alice
メッセージ（7）：こんにちは（再送）ボブ - >アリス
Bob retransmits his DTLS ClientHello, which now passes through the pinhole created in Alice's firewall. At this point, the DTLS handshake proceeds as before.
ボブは今、アリスのファイアウォールで作成されたピンホールを通過する彼のDTLSのClientHelloを、再送信します。この時点で、DTLSハンドシェークは以前のように進行します。
DTLS or TLS media signaled with SIP requires a way to ensure that the communicating peers' certificates are correct.
DTLSまたはTLS媒体は、SIPシグナリングと通信ピアの証明書が正しいことを確認する方法を必要とします。
The standard TLS/DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [RFC5280] certificate. The client then verifies the certificate and checks that the name in the certificate matches the server's domain name. This works because there are a relatively small number of servers with well-defined names; a situation that does not usually occur in the VoIP context.
通信当事者を認証するための標準的なTLS / DTLS戦略はPKIX [RFC5280]証明書をサーバに与える（およびクライアントを任意に）することです。クライアントは、証明書を検証し、証明書の名前は、サーバーのドメイン名と一致していることを確認します。明確に定義された名前を持つサーバの比較的少数があるので、これは動作します。通常のVoIPコンテキストで発生していない状況。
The design described in this document is intended to leverage the authenticity of the signaling channel (while not requiring confidentiality). As long as each side of the connection can verify the integrity of the SDP received from the other side, then the DTLS handshake cannot be hijacked via a man-in-the-middle attack. This integrity protection is easily provided by the caller to the callee (see Alice to Bob in Section 7) via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as the S/MIME mechanism described in RFC 3261, or perhaps future mechanisms yet to be defined could also serve this purpose.
本書で説明した設計は、（機密性を必要としないが）シグナリングチャネルの真正性を活用することを意図しています。 SDPの整合性を検証することができる接続のそれぞれの側が他方の側から受信する限り、その後DTLSハンドシェイクは、man-in-the-middle攻撃を介して、ハイジャックすることができません。この完全性保護を容易にSIPアイデンティティ[RFC4474]メカニズムを介して（セクション7でボブにアリス参照）被呼者に発呼者によって提供されます。まだ定義されるような、RFC 3261に記載のS / MIMEの機構のような他の機構、または、おそらく将来のメカニズムは、この目的を果たすことができました。
While this mechanism can still be used without such integrity mechanisms, the security provided is limited to defense against passive attack by intermediaries. An active attack on the signaling plus an active attack on the media plane can allow an attacker to attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).
このメカニズムは、まだ、このような整合性メカニズムなしで使用することができますが、提供されるセキュリティを仲介することにより、受動的攻撃に対する防御に限定されています。シグナリングプラスメディアプレーン上のアクティブな攻撃に活性な攻撃は、攻撃者が接続（[RFC5479]の表記でR-SIG-MEDIA）を攻撃することを可能にすることができます。
SIP Identity does not support signatures in responses. Ideally, Alice would want to know that Bob's SDP had not been tampered with and who it was from so that Alice's User Agent could indicate to Alice that there was a secure phone call to Bob. [RFC4916] defines an approach for a UA to supply its identity to its peer UA, and for this identity to be signed by an authentication service. For example, using this approach, Bob sends an answer, then immediately follows up with an UPDATE that includes the fingerprint and uses the SIP Identity mechanism to assert that the message is from Bob@example.com. The downside of this approach is that it requires the extra round trip of the UPDATE. However, it is simple and secure even when not all of the proxies are trusted. In this example, Bob only needs to trust his proxy. Offerers SHOULD support this mechanism and answerers SHOULD use it.
SIPアイデンティティは、応答に署名をサポートしていません。理想的には、アリスはボブのSDPが改ざんされていないと、それはアリスのユーザエージェントがボブに安全な電話があったことをアリスに知らせることができるようにしたから、誰ことを知りたいと思うだろう。 [RFC4916]はUAがそのピアUAにそのアイデンティティを供給するためのアプローチを定義し、このアイデンティティの認証サービスによって署名されます。例えば、このアプローチを使用して、ボブは、即座に指紋を含む、メッセージがBob@example.comからのものであることを主張するSIPアイデンティティ・メカニズムを使用UPDATEと追従次に、回答を送信します。このアプローチの欠点は、UPDATEの余分なラウンドトリップを必要とすることです。しかし、プロキシのすべてが信頼されていない場合でも、簡単かつ安全です。この例では、ボブは彼のプロキシを信頼する必要があります。申し出人は、このメカニズムをサポートすべきであると回答は、それを使用する必要があります。
In some cases, answerers will not send an UPDATE and in many calls, some media will be sent before the UPDATE is received. In these cases, no integrity is provided for the fingerprint from Bob to Alice. In this approach, an attacker that was on the signaling path could tamper with the fingerprint and insert themselves as a man-in-the-middle on the media. Alice would know that she had a secure call with someone, but would not know if it was with Bob or a man-in-the-middle. Bob would know that an attack was happening. The fact that one side can detect this attack means that in most cases where Alice and Bob both wish for the communications to be encrypted, there is not a problem. Keep in mind that in any of the possible approaches, Bob could always reveal the media that was received to anyone. We are making the assumption that Bob also wants secure communications. In this do nothing case, Bob knows the media has not been tampered with or intercepted by a third party and that it is from Alice@example.com. Alice knows that she is talking to someone and that whoever that is has probably checked that the media is not being intercepted or tampered with. This approach is certainly less than ideal but very usable for many situations.
UPDATEが受信される前に、いくつかのケースでは、回答者は、UPDATEを送信しませんし、多くのコールでは、いくつかのメディアが送信されます。これらのケースでは、何の整合性は、ボブからアリスへの指紋のために提供されていません。このアプローチでは、シグナリングパス上にあった攻撃者が指紋を改ざんでき、媒体上のman-in-the-middleとして自分自身を挿入します。アリスは彼女が誰かとの安全な呼び出しがあったことを知っているだろうが、それはボブかのman-in-the-middleとあったかどうかを知りません。ボブは攻撃が起こっていたことを知っているであろう。片側がこの攻撃を検出することができるという事実は、アリスとボブは、通信のために、両方の願いが暗号化されるほとんどの場合、問題がないことを意味します。可能なアプローチのいずれかで、ボブは常に誰に受信されたメディアを明らかにすることができることを覚えておいてください。私たちは、ボブはまた、セキュアな通信を望んでいるという仮定を作っています。この何もしない場合には、ボブは、メディアが改ざんまたは第三者に傍受されていない知っていて、それがAlice@example.comからのものであること。アリスは彼女が誰かと話をしていることを知っており、その誰でもそれはおそらくメディアが傍受や改ざんされていないことを確認しています。このアプローチは、多くの状況のための理想的なよりも確かに小さいが、非常に使用可能です。
If SIP Identity is not used, but the signaling is protected by SIPS, the security guarantees are weaker. Some security is still provided as long as all proxies are trusted. This provides integrity for the fingerprint in a chain-of-trust security model. Note, however, that if the proxies are not trusted, then the level of security provided is limited.
SIPアイデンティティが使用されていませんが、シグナリングはSIPSで保護されている場合は、セキュリティ保証は弱いです。一部のセキュリティは、まだすべてのプロキシが信頼している限り提供されます。これは、チェーン・オブ・信頼のセキュリティモデルに指紋のための整合性を提供します。プロキシが信頼されていない場合には、提供されるセキュリティのレベルが制限されていること、しかし、注意してください。
RFC 3261 [RFC3261] defines an S/MIME security mechanism for SIP that could be used to sign that the fingerprint was from Bob. This would be secure.
RFC 3261 [RFC3261]は、指紋がボブからのものであったことを署名するために使用することができるSIPのためのS / MIMEセキュリティメカニズムを定義します。これは、安全でしょう。
One desirable property of a secure media system is to provide continuity of authentication: being able to ensure cryptographically that you are talking to the same person as before. With DTLS, continuity of authentication is achieved by having each side use the same public key/self-signed certificate for each connection (at least with a given peer entity). It then becomes possible to cache the credential (or its hash) and verify that it is unchanged. Thus, once a single secure connection has been established, an implementation can establish a future secure channel even in the face of future insecure signaling.
あなたは前と同じ人に話をしていることを、暗号を保証することができること：安全なメディアシステムの一つの望ましい特性は、認証の継続性を提供することです。 DTLSと、認証の連続性は、各辺が（少なくとも所与のピア・エンティティとの）接続ごとに同じ公開鍵/自己署名証明書を使用することによって達成されます。その後、資格（またはそのハッシュ）をキャッシュし、それが変更されていないことを確認することが可能となります。単一の安全な接続が確立された後従って、実装があっても、将来の安全でないシグナル伝達の面で将来の安全なチャネルを確立することができます。
In order to enable continuity of authentication, implementations SHOULD attempt to keep a constant long-term key. Verifying implementations SHOULD maintain a cache of the key used for each peer identity and alert the user if that key changes.
認証の継続を可能にするために、実装は一定の長期キーを維持しようとすべきです。検証の実装は、各ピアのアイデンティティのために使用されるキーのキャッシュを維持し、そのキーが変更された場合、ユーザーに警告すべきです。
An alternative available to Alice and Bob is to use human speech to verify each other's identity and then to verify each other's fingerprints also using human speech. Assuming that it is difficult to impersonate another's speech and seamlessly modify the audio contents of a call, this approach is relatively safe. It would not be effective if other forms of communication were being used such as video or instant messaging. DTLS supports this mode of operation. The minimal secure fingerprint length is around 64 bits.
アリスとボブに利用可能な代替は、互いの身元を確認するために、その後も人間の音声を使用して、お互いの指紋を確認するために、人間の音声を使用することです。別の話を偽装し、シームレスに通話の音声内容を変更することは困難であると仮定すると、このアプローチは比較的安全です。通信の他の形態は、ビデオやインスタントメッセージングとして使用されていた場合、それは効果的ではないであろう。 DTLSは、この動作モードをサポートしています。最小限の安全な指紋の長さは約64ビットです。
ZRTP [AVT-ZRTP] includes Short Authentication String (SAS) mode in which a unique per-connection bitstring is generated as part of the cryptographic handshake. The SAS can be as short as 25 bits and so is somewhat easier to read. DTLS does not natively support this mode. Based on the level of deployment interest, a TLS extension [RFC5246] could provide support for it. Note that SAS schemes only work well when the endpoints recognize each other's voices, which is not true in many settings (e.g., call centers).
ZRTP [AVT-ZRTP]はショート認証文字列（SAS）固有の接続ごとのビット列を暗号化ハンドシェイクの一部として生成されるモードを含みます。 SASは、25ビットだけ短くするので、多少読みやすくなることができます。 DTLSは、ネイティブにこのモードをサポートしていません。展開の関心のレベルに基づいて、TLS拡張[RFC5246]は、それに対するサポートを提供することができます。エンドポイントは、多くの設定（例えば、コールセンター）には当てはまりませんお互いの声を認識するときSASスキームだけうまく機能することに注意してください。
When RFC 4474 is used to bind the media keying material to the SIP signaling, the assurances about the provenance and security of the media are only as good as those for the signaling. There are two important cases to note here:
RFC 4474は、SIPシグナリングに鍵材料メディアを結合するために使用された場合、メディアの出所及びセキュリティに関する保証は、シグナリングのためのものほど良好です。ここで注意すべき二つの重要なケースがあります。
o RFC 4474 assumes that the proxy with the certificate "example.com" controls the namespace "example.com". Therefore, the RFC 4474 authentication service that is authoritative for a given namespace can control which user is assigned each name. Thus, the authentication service can take an address formerly assigned to Alice and transfer it to Bob. This is an intentional design feature of RFC 4474 and a direct consequence of the SIP namespace architecture.
OのRFC 4474は、証明書「example.com」とプロキシは、名前空間「example.com」を制御していることを前提としています。したがって、所与の名前空間の権威であるRFC 4474認証サービスは、それぞれの名前が割り当てられたユーザを制御することができます。このように、認証サービスは、以前はアリスに割り当てられたアドレスを取得し、ボブに転送することができます。これは、RFC 4474の意図的な設計上の特徴およびSIP名前空間アーキテクチャの直接の結果です。
o When phone number URIs (e.g., 'sip:+17005551008@chicago.example.com' or 'sip:+17005551008@chicago.example.com;user=phone') are used, there is no structural reason to trust that the domain name is authoritative for a given phone number, although individual proxies and UAs may have private arrangements that allow them to trust other domains. This is a structural issue in that Public Switched Telephone Network (PSTN) elements are trusted to assert their phone number correctly and that there is no real concept of a given entity being authoritative for some number space.
O場合、電話番号のURI（例えば、「SIP：+17005551008@chicago.example.com」または「SIP：+17005551008@chicago.example.com;ユーザー=電話」）を使用するが、それを信頼する構造的理由はありません個々のプロキシとUAがそれらを他のドメインを信頼することができ、民間取決めを持っているかもしれないが、ドメイン名は、指定した電話番号の権威です。これは、公共の構造問題は（PSTN）の要素が正しくといくつかの番号空間のための権限があることを特定のエンティティの本当の概念が存在しないことを自分の電話番号を主張するために信頼されている交換電話網です。
In both of these cases, the assurances that DTLS-SRTP provides in terms of data origin integrity and confidentiality are necessarily no better than SIP provides for signaling integrity when RFC 4474 is used. Implementors should therefore take care not to indicate misleading peer identity information in the user interface. That is, if the peer's identity is sip:+17005551008@chicago.example.com, it is not sufficient to display that the identity of the peer as +17005551008, unless there is some policy that states that the domain "chicago.example.com" is trusted to assert the E.164 numbers it is asserting. In cases where the UA can determine that the peer identity is clearly an E.164 number, it may be less confusing to simply identify the call as encrypted but to an unknown peer.
これらの場合の両方において、DTLS-SRTPは、データ発信元の整合性と機密性の点で提供保証は、必ずしもSIPのRFC 4474を使用した場合の整合性シグナリングを提供するよりも良いではありません。実装者は、したがって、ユーザーインターフェイスの誤解を招くようなピア識別情報を示すためないように注意する必要があります。 +17005551008@chicago.example.comドメイン「chicago.exampleと述べているいくつかのポリシーがない限り、17005551008のようにピアのアイデンティティことを表示するのに十分ではない：それはピアの識別情報がSIPであれば、です。 COMは、」それがアサートされたE.164番号を主張するために信頼されています。単に暗号化されたとしてではなく、未知のピアにコールを識別するために、UAは、ピアのアイデンティティがE.164番号は明らかであると判断できる場合には、それはあまり混乱してもよいです。
In addition, some middleboxes (back-to-back user agents (B2BUAs) and Session Border Controllers) are known to modify portions of the SIP message that are included in the RFC 4474 signature computation, thus breaking the signature. This sort of man-in-the-middle operation is precisely the sort of message modification that RFC 4474 is intended to detect. In cases where the middlebox is itself permitted to generate valid RFC 4474 signatures (e.g., it is within the same administrative domain as the RFC 4474 authentication service), then it may generate a new signature on the modified message. Alternately, the middlebox may be able to sign with some other identity that it is permitted to assert. Otherwise, the recipient cannot rely on the RFC 4474 Identity assertion and the UA MUST NOT indicate to the user that a secure call has been established to the claimed identity. Implementations that are configured to only establish secure calls SHOULD terminate the call in this case.
加えて、いくつかの中間装置（バックツーバックユーザエージェント（型B2BUA）とセッションボーダーコントローラ）は、したがって、署名を破る、RFC 4474署名の計算に含まれるSIPメッセージの部分を変更することが知られています。 man-in-the-middle操作のこの種のは、正確にRFC 4474が検出するように意図されたメッセージの変更の一種です。ミドルボックス自体が有効なRFC 4474人のに署名を生成することが許可されている場合には、それは修正されたメッセージに新しい署名を生成することができる（例えば、それは、RFC 4474の認証サービスと同じ管理ドメイン内にあります）。代わりに、ミドルは、主張することが許されているいくつかの他のIDで署名することができるかもしれません。そうでなければ、受信者はRFC 4474 IDアサーションに依存することはできませんし、UAは、セキュアなコールが要求されたアイデンティティに確立されたことをユーザに示してはいけません。唯一のセキュアコールを確立するように構成されている実装は、この場合の通話を終了すべきです。
If SIP Identity or an equivalent mechanism is not used, then only protection against attackers who cannot actively change the signaling is provided. While this is still superior to previous mechanisms, the security provided is inferior to that provided if integrity is provided for the signaling.
SIPアイデンティティまたは同等のメカニズムが使用されていない場合は、積極的にシグナリングを変更することはできません攻撃者に対してのみ保護が提供されます。これはまだ前のメカニズムよりも優れているが、提供されるセキュリティは、整合性は、シグナリングのために提供された場合に提供されるものよりも劣っています。
This specification does not depend on the certificates being held by endpoints being independently verifiable (e.g., being issued by a trusted third party). However, there is no limitation on such certificates being used. Aside from the difficulty of obtaining such certificates, it is not clear what identities those certificates would contain -- RFC 3261 specifies a convention for S/MIME certificates that could also be used here, but that has seen only minimal deployment. However, in closed or semi-closed contexts where such a convention can be established, third-party certificates can reduce the reliance on trusting even proxies in the endpoint's domains.
この仕様は、（例えば、信頼できるサードパーティによって発行されている）、単独で検証されたエンドポイントによって保持された証明書には依存しません。しかし、使用されているような証明書には限定されません。 RFC 3261はまた、ここで使用することができ、S / MIME証明書の規則を指定しますが、それが唯一の最小限の展開を見ている - はさておき、このような証明書を取得することの難しさから、それらの証明書が含まれているだろうなIDを何クリアされていません。しかし、そのような規則を確立することができ、閉鎖または半閉鎖の状況で、サードパーティの証明書は、エンドポイントのドメインでも、プロキシを信頼への依存を減らすことができます。
One concern about the use of a long-term key is that compromise of that key may lead to compromise of past communications. In order to prevent this attack, DTLS supports modes with Perfect Forward Secrecy using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites. When these modes are in use, the system is secure against such attacks. Note that compromise of a long-term key may still lead to future active attacks. If this is a concern, a backup authentication channel, such as manual fingerprint establishment or a short authentication string, should be used.
長期キーの使用についての懸念の一つは、そのキーの妥協は過去の通信の妥協につながるかもしれないということです。この攻撃を防ぐために、DTLSは、ディフィー・ヘルマンと楕円曲線暗号のDiffie-Hellmanの暗号スイートを使用して完全転送秘密を持つモードをサポートしています。これらのモードが使用されている場合は、システムは、このような攻撃に対して安全です。まだ将来の能動的な攻撃につながる可能性があり、長期的なキーの妥協点に注意してください。これは、このような手動の指紋確立または短い認証文字列として懸念、バックアップ認証チャネルである場合には、使用すべきです。
Cullen Jennings contributed substantial text and comments to this document. This document benefited from discussions with Francois Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful comments by Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman, David Oran, and Peter Schneider.
カレンジェニングスは、本文書にかなりのテキストやコメントを貢献しました。この文書では、フランソワAudet、Nagendra Modadugu、そしてダン・ウィングとの議論の恩恵を受けました。また、フレミングAndreasenの、ジョナサン・ローゼンバーグ、ロハンマーイ、デビッドマグリュー、ミゲル・ガルシア、ステファンのフライドポテト、ブライアンStucker、ロバート・ギルマン、デヴィッドオラン、そしてピーター・シュナイダーによって有益なコメントをありがとう。
We would like to thank Thomas Belling, Guenther Horn, Steffen Fries, Brian Stucker, Francois Audet, Dan Wing, Jari Arkko, and Vesa Lehtovirta for their input regarding traversal of SBCs.
私たちは、SBCでのトラバースに関する彼らの入力のためのトーマス・ベリング、ギュンター・ホーン、ステファンのフライドポテト、ブライアンStucker、フランソワAudet、ダン・ウィング、ヤリArkko、とのVesa Lehtovirtaに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル（SDP）にメディアトランスポート"、RFC 4145、2005年9月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]レノックス、J.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（TLS）プロトコルを介してメディアトランスポート"、RFC 4572、2006年7月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]ラザロ、J.、RFC 4571、2006年7月 "リアルタイム転送プロトコル（RTP）およびRTP制御プロトコルコネクション型トランスポート・オーバー（RTCP）パケットをフレーミング"。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567] Arkko、J.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（SDP）のセキュリティの説明"、RFC 4568、2006年7月。
[AVT-ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, March 2009.
[AVT-ZRTP]ツィンマーマン、P.、ジョンストン、A.、およびJ.カラス、 "ZRTP：セキュアRTPのためのメディアパス鍵合意"、進歩、2009年3月での作業。
[SRTP-EKT] McGrew, D., Andreasen, F., and L. Dondeti, "Encrypted Key Transport for Secure RTP", Work in Progress, March 2009.
[SRTP-EKT]マグリュー、D.、アンドレア、F.、およびL. Dondeti、 "セキュアRTPのための暗号化キー交通"、進歩、2009年3月での作業。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]マグリュー、D.およびE.レスコラ、RFC 5764、2010年5月、「データグラムトランスポート層セキュリティ（DTLS）拡張は、セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立します」。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, March 2009.
[RFC5479]ウイング、D.、フライドポテト、S.、Tschofenig、H.、およびF. Audet、 "要件とメディアセキュリティ管理プロトコルの分析"、RFC 5479、2009年3月。
[MMUSIC-SDP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, February 2010.
[MMUSIC-SDP]アンドレア、F.、 "SDP機能ネゴシエーション"、進歩、2010年2月での作業。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]パーキンス、C.とM.ウェスター、 "シングルポートの多重化RTPデータおよび制御パケット"、RFC 5761、2010年4月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]エルウェル、J.、 "セッション開始プロトコル（SIP）に接続アイデンティティ"、RFC 4916、2007年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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[SIPPING-SRTP] 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.
[SIPPING-SRTP]ウイング、D.、Audet、F.、フライドポテト、S.、Tschofenig、H.、およびA.ジョンストン、 "セキュアメディアの記録とセッション開始プロトコルとトランスコーディング"、進歩、2008年10月の作業。
[KEY-TRANSPORT] Wing, D., "DTLS-SRTP Key Transport (KTR)", Work in Progress, March 2009.
[KEY-TRANSPORT]ウイング、D.、 "DTLS-SRTPキートランスポート（KTR）"、進歩、2009年3月での作業。
[MMUSIC-MEDIA] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, March 2009.
[MMUSIC-MEDIA] Stucker、B.およびH. Tschofenig、「メディアの経路に沿ってシグナリングプロトコルの通信のためのミドル相互作用の分析」、進歩、2009年3月での作業。
[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
[RFC5767]宗像、M.、シューベルト、S.、およびT.大場、 "SIPのためのユーザーエージェントドリブンプライバシーメカニズム"、RFC 5767、2010年4月。
Appendix A. Requirements Analysis
付録A.要件分析
[RFC5479] describes security requirements for media keying. This section evaluates this proposal with respect to each requirement.
[RFC5479]はメディアキーのセキュリティ要件について説明します。このセクションでは、各要件に対するこの提案を評価します。
A.1. Forking and Retargeting (R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT)
A.1。フォークとリターゲット（R-フォークリターゲット、R-BEST-SECURE、R-DISTINCT）
In this document, the SDP offer (in the INVITE) is simply an advertisement of the capability to do security. This advertisement does not depend on the identity of the communicating peer, so forking and retargeting work when all the endpoints will do SRTP. When a mix of SRTP and non-SRTP endpoints are present, we use the SDP capabilities mechanism currently being defined [MMUSIC-SDP] to transparently negotiate security where possible. Because DTLS establishes a new key for each session, only the entity with which the call is finally established gets the media encryption keys (R3).
この文書では、SDPオファーが（INVITEに）単にセキュリティを行うための能力の広告です。この広告はので、すべてのエンドポイントがSRTPを行いますとき、フォークとリターゲットの仕事、通信ピアのアイデンティティに依存しません。 SRTPの混合物および非SRTPエンドポイントが存在する場合、我々は可能な限り透過的にセキュリティをネゴシエートする[MMUSIC-SDP]現在定義されているSDP機能メカニズムを使用。 DTLSは、セッションごとに新しいキーを確立しているため、コールが最終的に確立されている唯一のエンティティは、メディア暗号化キー（R3）を取得します。
A.2. Distinct Cryptographic Contexts (R-DISTINCT)
A.2。異なる暗号コンテキスト（R-DISTINCT）
DTLS performs a new DTLS handshake with each endpoint, which establishes distinct keys and cryptographic contexts for each endpoint.
DTLSは、エンドポイントごとに異なる鍵および暗号コンテキストを確立し、各エンドポイントと新しいDTLSハンドシェイクを行います。
A.3. Reusage of a Security Context (R-REUSE)
A.3。セキュリティコンテキストの再使用（R-REUSE）
DTLS allows sessions to be resumed with the 'TLS session resumption' functionality. This feature can be used to lower the amount of cryptographic computation that needs to be done when two peers re-initiate the communication. See [RFC5764] for more on session resumption in this context.
DTLSは、セッションが「TLSセッション再開」機能で再開することができます。この機能は、2つのピアが通信を再開始するときに行われる必要がある暗号演算量を低下させるために使用することができます。この文脈でのセッション再開の詳細については、[RFC5764]を参照してください。
A.4. Clipping (R-AVOID-CLIPPING)
A.4。クリッピング（R-AVOIDクリッピング）
Because the key establishment occurs in the media plane, media need not be clipped before the receipt of the SDP answer. Note, however, that only confidentiality is provided until the offerer receives the answer: the answerer knows that they are not sending data to an attacker but the offerer cannot know that they are receiving data from the answerer.
鍵確立がメディア面で発生しているため、メディアは、SDPアンサーの受領前にクリッピングする必要はありません。回答は、彼らが攻撃者にデータを送信されるのではなく、オファーは、彼らが回答からデータを受信していることを知ることができないことを知っている：オファー側が答えを受け取るまでにのみ機密性が提供されていること、しかし、注意してください。
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA)
A.5。メディアパス上の受動的攻撃（R-PASS-MEDIA）
The public key algorithms used by DTLS cipher suites, such as RSA, Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against passive attacks.
こうしたRSA、ディフィー・ヘルマン、および楕円曲線のDiffie-HellmanのようDTLS暗号スイートによって使用される公開鍵アルゴリズムは、受動的攻撃に対して安全です。
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG)
A.6。シグナリングパス上の受動的攻撃（R-PASS-SIG）
DTLS provides protection against passive attacks by adversaries on the signaling path since only a fingerprint is exchanged using SIP signaling.
DTLSは、指紋がSIPシグナリングを使用して交換されるので、シグナリングパス上の敵によって受動的攻撃に対する保護を提供します。
A.7. (R-SIG-MEDIA, R-ACT-ACT)
A.7。 （R-SIG-MEDIA、R-ACT-ACT）
An attacker who controls the media channel but not the signaling channel can perform a MITM attack on the DTLS handshake but this will change the certificates that will cause the fingerprint check to fail. Thus, any successful attack requires that the attacker modify the signaling messages to replace the fingerprints.
シグナリングチャネルメディアチャネルを制御ではなく、攻撃者がDTLSハンドシェークにMITM攻撃を行うことができますが、これは指紋チェックが失敗します証明書が変更されます。このように、任意の成功した攻撃は、攻撃者が指紋を交換するシグナリングメッセージを変更する必要があります。
If RFC 4474 Identity or an equivalent mechanism is used, an attacker who controls the signaling channel at any point between the proxies performing the Identity signatures cannot modify the fingerprints without invalidating the signature. Thus, even an attacker who controls both signaling and media paths cannot successfully attack the media traffic. Note that the channel between the UA and the authentication service MUST be secured and the authentication service MUST verify the UA's identity in order for this mechanism to be secure.
RFC 4474の同一性または同等の機構が使用される場合、アイデンティティ署名を行うプロキシの間の任意の時点でシグナリングチャネルを制御する攻撃者は、署名を無効にせずに指紋を変更することはできません。このように、両方のシグナリングおよびメディアパスを制御しても攻撃者はメディアトラフィックを攻撃することはできません。 UAと認証サービスとの間のチャネルを確保しなければならないと認証サービスが安全であるために、このメカニズムのために、UAのIDを確認しなければならないことに注意してください。
Note that an attacker who controls the authentication service can impersonate the UA using that authentication service. This is an intended feature of SIP Identity -- the authentication service owns the namespace and therefore defines which user has which identity.
認証サービスを制御し、攻撃者がその認証サービスを使用してUAを偽装できることに注意してください。これは、SIPアイデンティティの意図した機能です - 認証サービスは、名前空間を所有しているため、そのアイデンティティを持っているユーザが定義されています。
A.8. Binding to Identifiers (R-ID-BINDING)
A.8。識別子（R-ID結合）に結合します
When an end-to-end mechanism such as SIP-Identity [RFC4474] and SIP-Connected-Identity [RFC4916] or S/MIME are used, they bind the endpoint's certificate fingerprints to the From: address in the signaling. The fingerprint is covered by the Identity signature. When other mechanisms (e.g., SIPS) are used, then the binding is correspondingly weaker.
シグナル伝達におけるアドレス：例えばSIP-IDとして、エンドツーエンドのメカニズム[RFC4474]とSIP接続アイデンティティ[RFC4916]またはS / MIMEを使用する場合、それらはないし、エンドポイントの証明書のフィンガープリントを結合します。指紋は、Identity署名で覆われています。他の機構（例えば、SIPS）を使用した場合、その後の結合は、相応弱いです。
A.9. Perfect Forward Secrecy (R-PFS)
A.9。完全転送秘密（R-PFS）
DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher suites that provide PFS.
DTLSは、PFSを提供ディフィー・ヘルマンと楕円曲線のDiffie-Hellmanの暗号スイートをサポートしています。
A.10. Algorithm Negotiation (R-COMPUTE)
A.10。アルゴリズムネゴシエーション（R-COMPUTE）
DTLS negotiates cipher suites before performing significant cryptographic computation and therefore supports algorithm negotiation and multiple cipher suites without additional computational expense.
DTLSは、重要な暗号計算を実行する前に暗号スイートをネゴシエートし、したがって、追加の計算費用なしアルゴリズムのネゴシエーションと複数の暗号スイートをサポートしています。
A.11. RTP Validity Check (R-RTP-VALID)
A.11。 RTPの妥当性チェック（R-RTP-VALID）
DTLS packets do not pass the RTP validity check. The first byte of a DTLS packet is the content type and all current DTLS content types have the first two bits set to zero, resulting in a version of zero; thus, failing the first validity check. DTLS packets can also be distinguished from STUN packets. See [RFC5764] for details on demultiplexing.
DTLSパケットは、RTPの妥当性チェックに合格しません。 DTLSパケットの最初のバイトは、コンテンツ・タイプであり、すべての現在のDTLSコンテンツタイプがゼロのバージョン、その結果、ゼロに設定された第1の2ビットを有しています。したがって、最初の妥当性チェックに失敗。 DTLSパケットはまた、STUNパケットを区別することができます。逆多重化の詳細については、[RFC5764]を参照してください。
A.12. Third-Party Certificates (R-CERTS, R-EXISTING)
A.12。サードパーティ証明書（R-CERTS、R-既存）
Third-party certificates are not required because signaling (e.g., [RFC4474]) is used to authenticate the certificates used by DTLS. However, if the parties share an authentication infrastructure that is compatible with TLS (third-party certificates or shared keys) it can be used.
シグナリング（例えば、[RFC4474]）はDTLSによって使用される証明書を認証するために使用されているため、サードパーティ証明書が必要とされません。しかし、当事者は、それが使用することができるTLS（サードパーティ証明書または共有鍵）と互換性のある認証インフラストラクチャを共有する場合。
A.13. FIPS 140-2 (R-FIPS)
A.13。 FIPS 140-2（R-FIPS）
TLS implementations already may be FIPS 140-2 approved and the algorithms used here are consistent with the approval of DTLS and DTLS-SRTP.
TLSの実装は、すでに承認されたFIPS 140-2でもよく、ここで使用されるアルゴリズムは、DTLSの承認およびDTLS-SRTPと一致しています。
A.14. Linkage between Keying Exchange and SIP Signaling (R-ASSOC)
A.14。キーイングExchangeおよびSIPシグナリング（R-ASSOC）との間の結合
The signaling exchange is linked to the key management exchange using the fingerprints carried in SIP and the certificates are exchanged in DTLS.
シグナリング交換は、SIPで運ば指紋を使用して鍵管理交換に連結され、証明書がDTLSで交換されています。
A.15. Denial-of-Service Vulnerability (R-DOS)
A.15。サービス拒否の脆弱性（R-DOS）
DTLS offers some degree of Denial-of-Service (DoS) protection as a built-in feature (see Section 4.2.1 of [RFC4347]).
DTLSは、（[RFC4347]のセクション4.2.1を参照）、内蔵機能としてサービス拒否（DoS）のある程度の保護を提供しています。
A.16. Crypto-Agility (R-AGILITY)
A.16。暗号アジリティ（R-AGILITY）
DTLS allows cipher suites to be negotiated and hence new algorithms can be incrementally deployed. Work on replacing the fixed MD5/SHA-1 key derivation function is ongoing.
DTLSは、暗号スイートが交渉することができますので、新しいアルゴリズムは、インクリメンタルに展開することができます。固定MD5 / SHA-1鍵導出関数の交換作業が進行中です。
A.17. Downgrading Protection (R-DOWNGRADE)
A.17。格下げ保護（R-DOWNGRADE）
DTLS provides protection against downgrading attacks since the selection of the offered cipher suites is confirmed in a later stage of the handshake. This protection is efficient unless an adversary is able to break a cipher suite in real-time. RFC 4474 is able to prevent an active attacker on the signaling path from downgrading the call from SRTP to RTP.
提供する暗号スイートの選択は握手の後の段階で確認されているので、DTLSはダウングレード攻撃に対する保護を提供します。敵対者がリアルタイムに暗号スイートを破ることができない限り、この保護は、効率的です。 RFC 4474は、SRTPからRTPへのコールをダウングレードからシグナリングパス上のアクティブな攻撃を防止することができます。
A.18. Media Security Negotiation (R-NEGOTIATE)
A.18。メディアセキュリティネゴシエーション（R-NEGOTIATE）
DTLS allows a User Agent to negotiate media security parameters for each individual session.
DTLSは、ユーザーエージェントは、個々のセッションのためのメディアセキュリティパラメータをネゴシエートすることができます。
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING)
A.19。シグナリングプロトコルインディペンデンス（R-OTHER-シグナリング）
The DTLS-SRTP framework does not rely on SIP; every protocol that is capable of exchanging a fingerprint and the media description can be secured.
DTLS-SRTPフレームワークは、SIPに依存しません。指紋とメディア記述を交換することが可能なすべてのプロトコルを確保することができます。
A.20. Media Recording (R-RECORDING)
A.20。メディア記録（R-RECORDING）
An extension, see [SIPPING-SRTP], has been specified to support media recording that does not require intermediaries to act as an MITM.
拡張子は、[SIPPING-SRTP]、MITMとして機能するように仲介を必要としないメディア記録をサポートするために指定されている参照してください。
When media recording is done by intermediaries, then they need to act as an MITM.
メディア記録を仲介することによって行われた場合、それらはMITMとして機能する必要があります。
A.21. Interworking with Intermediaries (R-TRANSCODER)
A.21。仲介（Rトランスコーダ）とのインターワーキング
In order to interface with any intermediary that transcodes the media, the transcoder must have access to the keying material and be treated as an endpoint for the purposes of this document.
メディアをトランスコードする任意の中間とインターフェースするために、トランスコーダは、鍵材料にアクセスする必要があり、この文書の目的のためのエンドポイントとして扱われます。
A.22. PSTN Gateway Termination (R-PSTN)
A.22。 PSTNゲートウェイ終端（R-PSTN）
The DTLS-SRTP framework allows the media security to terminate at a PSTN gateway. This does not provide end-to-end security, but is consistent with the security goals of this framework because the gateway is authorized to speak for the PSTN namespace.
DTLS-SRTPフレームワークは、メディアセキュリティは、PSTNゲートウェイで終端することを可能にします。これは、エンドツーエンドのセキュリティを提供していますが、ゲートウェイがPSTNの名前空間のために話すことを許可されているので、このフレームワークのセキュリティ目標と一致していません。
A.23. R-ALLOW-RTP
A.23。 R-ALLOW-RTP
DTLS-SRTP 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.
DTLS-SRTPは、SRTPがSRTPはRTPよりも優先された後アンサー、と交渉されるまで、RTPメディアは、発信者が受信することができます。
A.24. R-HERFP
A.24。 R-HERFP
The Heterogeneous Error Response Forking Problem (HERFP) is not applicable to DTLS-SRTP since the key exchange protocol will be executed along the media path and hence error messages are communicated along this path and proxies do not need to progress them.
鍵交換プロトコルは、媒体経路に沿って実行されますので、エラーメッセージがこのパスに沿って伝達されると、プロキシがそれらを進行する必要はありませんので、異機種混在エラー応答フォーク問題（HERFP）は、DTLS、SRTPには適用されません。
Authors' Addresses
著者のアドレス
Jason Fischl Skype, Inc. 2145 Hamilton Ave. San Jose, CA 95135 USA
ジェイソンFischlスカイプ社2145ハミルトンアベニュー。サンノゼ、CA 95135 USA
Phone: +1-415-692-1760 EMail: jason.fischl@skype.net
電話：+ 1-415-692-1760 Eメール：jason.fischl@skype.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo, 02600 Finland
エスポー、フィンランド02600でハンネスTschofenigノキア・シーメンス・ネットワークスLinnoitustie 6
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
エリックレスコラRTFM、Inc.の2064エッジウッドドライブパロアルト、CA 94303 USA
EMail: ekr@rtfm.com
メールアドレス：ekr@rtfm.com