[要約] RFC 5763は、Datagram Transport Layer Security（DTLS）を使用してSecure Real-time Transport Protocol（SRTP）セキュリティコンテキストを確立するためのフレームワークです。このRFCの目的は、SRTP通信のセキュリティを向上させるために、DTLSを使用してセキュリティコンテキストを確立する方法を提供することです。
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.
このドキュメントは、セッション開始プロトコル（SIP）を使用して、データグラムトランスポートレイヤーセキュリティ（DTLS）プロトコルを使用して、安全なリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立する方法を指定しています。これは、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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]の上にリアルタイムメディアを送信するために使用されます。Datagram TLS [RFC4347]が導入され、UDPやDCCPなどのTLS機能をデータグラム輸送プロトコルに適用できるようにしました。このドキュメントは、DTLSへの拡張機能を使用してUDPを介してSRTP [RFC3711]セキュリティを確立する方法に関するガイドラインを提供します（[RFC5764]を参照）。
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セッションで輸送されます。証明書は、純粋にピアの公開鍵の運送業者として使用されていることに注意することが非常に重要です。これは、DTLには裸のキーを運ぶためのモードがないため、これが必要ですが、純粋にフォーマットの問題です。証明書は自己署名し、完全に自己生成される可能性があります。すべての主要なTLSスタックには、そのような証明書をオンデマンドで生成する機能があります。ただし、ピアがそれらを持っている場合、サードパーティの証明書も使用できます（したがって、仲介者を信頼する必要性を減らします）。証明書の指紋は、オファー/回答の交換の一環として、SDPでSIPで送信されます。
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ハンドシェイクに提示された証明書が信号で使用される証明書と一致することを確認できます。ただし、これには、シグナリングに何らかの形の整合性保護が必要です。[RFC4474]に記載されているRFC 3261またはSIP IDで説明されているS/MIMEシグネチャは、悪意のある仲介者による修正の影響を受けないため、最高レベルのセキュリティを提供します。ただし、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では、通常、発信者はオファーを送信し、Calleeはその後、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台形のDTLの使用
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つの任意のエンドポイント間で相互認証を提供することは問題がある傾向があるため、より展開に優しい代替案を考慮しています。このドキュメントでは1つのアプローチを使用し、他のいくつかについてセクション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.
アリスはSDPオファーをBob Over SIPに送信します。アリスがボブとの通信に自己署名証明書のみを使用している場合、指紋は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認証（つまり、両側が証明書を提供する）で（メディアセッションの数に応じて）少数のDTL接続を確立します（メディアセッションの数に応じて）。この時点で、ボブはTLSで提供されているアリスの資格情報が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:
この分野ではすでに事前の作業がありますが（例：SDPのセキュリティ説明[RFC4568]、主要な管理拡張機能[RFC4567]と認証とキー交換のためにMikey [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.
o このアプローチでは、暫定的な対応承認（PRACK）[RFC3262]のサポートを必要とせずに、フォーキングと初期のメディアを扱い、提供者がメディアを暗号化するためのキーイング資料を選択できるようにする重要なセキュリティプロパティを維持します。
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.
o RFC 4474を使用すると、このソリューションは、認証サービスの下流のSIPプロキシが信頼されていない場合でも機能します。SDEScriptions [RFC4568]で行われるように、SIPシグナリングまたはSDPメッセージ交換でキーを明らかにする必要はありません。ダイアログ形成リクエストのリターゲティング（リクエスト-URIの値の変更）、それを受信するユーザーエージェント（UA）（ユーザーエージェントサーバー、UAS）は、ヘッダーフィールドとは異なるアイデンティティを持つことができます。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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使用法との一貫性のために、参照されているのが特別にDTLS/TLSではないマルチメディアストリームである場合、「接続」という用語を使用します。
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.
このドキュメントでは、「相互DTL」という用語は、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].
Exchangeの2つのエンドポイントは、証明書を使用したDTLSハンドシェイク手順の一部としてIDを提示します。このドキュメントでは、「セッション説明プロトコル（SDP）のトランスポートレイヤーセキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」で説明されているのと同じスタイルの証明書を使用します[RFC4572]。
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].
[RFC4566]メッセージ、各メディアの説明（ "m ="行および関連パラメーター）には、[RFC5764]、[RFC4145]、および[RFC4572]で指定されているいくつかの属性も含まれます。
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]で概説されている手順に従ってIDヘッダーフィールドを追加する必要があります。オファーを含むSIPメッセージは、整合性保護チャネルを介してオファーのSIPプロキシに送信する必要があります。Far EndpointがSIPメッセージを受信すると、IDヘッダーフィールドを使用して送信者のIDを確認できます。IDヘッダーフィールドは、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.
Far Endpoint（Answerer）は、提供者との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.
Answererがオファーを受け入れると、Answererの証明書指紋を含むOffererに回答を提供します。この時点で、提供者はピアの証明書を受け入れるか拒否することができ、オファーはメディアが保護されていることをエンドユーザーに示すことができます。
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.
メディアトラフィックを保護するための認証と重要な交換全体は、DTLを介したメディアパスで処理されることに注意してください。シグナリングパスは、ピアの証明書指紋を検証するためにのみ使用されます。
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]で定義されているセットアップ属性を使用する必要があります。オファーであるエンドポイントは、セットアップのセットアップ属性値を使用する必要があります。回答者は、セットアップのセットアップ属性値を使用する必要があります。アクティブまたはセットアップ：パッシブ。Answererがセットアップを使用している場合、Passiveを使用すると、DTLSハンドシェイクは回答者が受信されるまで開始されないため、追加のレイテンシが追加されます。セットアップ：Activeを使用すると、回答とDTLSハンドシェイクが並行して発生します。したがって、セットアップ：アクティブをお勧めします。どちらのパーティーがアクティブであっても、各フロー（ホスト/ポートカルテット）にクライアントヘロを送信することにより、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].
o エンドポイントは、[RFC4572]で指定されているように、証明書指紋属性を使用する必要があります。
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が使用される場合は、匿名の呼び出しを説明できる場合があります。匿名の呼び出しが行われている場合、次の手順を使用して、承認を防ぐ必要があります。
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 IDメカニズムと組み合わせて使用され、匿名の呼び出しを有効にするときにユーザーのIDが主張されないようにします。さらに、証明書内の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リクエストを送信する場合があります。これが発生すると、招待の受信者は応答でオファーを提供し、オリジネーターはその後のACKリクエストまたはプラックリクエスト[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.
応答が提供者に提供されると、いずれかのエンドポイントが更新されたオファーを含むセッションの変更を要求する場合があります。このセッションの変更は、招待状または更新リクエストのいずれかで伝えることができます。ピアは、既存の関連付けが互換性がある場合（つまり、同じ重要な指紋と輸送パラメーターを持っている場合）、同じ規則に従って新しいものを確立することができます。回答交換が完了しました。エンドポイントのアクティブ/パッシブステータスが変更された場合、新しい接続を確立する必要があることに注意してください。
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）は、マルチメディアセッションの参加者が相互接続を検証できるようにする方法論を提供します。氷が使用されると、DTLSの握手が始まる前に氷の接続性チェックが実行されます。積極的な指名モードを使用する場合、ICEが最終的に単一の候補ペアに収束する前に、複数の候補ペアが有効にマークされる可能性があることに注意してください。実装は、同じDTLS協会の一部として、単一のコンポーネントに関連するすべてのICE候補ペアを扱う必要があります。したがって、複数の有効な候補ペアがある場合でも、DTLSハンドシェイクは1つだけです。これは、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（STUN）パケットを介したUDPプロトコルの単純なトラバーサルは、DTLではなくUDP上に直接送信されることに注意してください。[RFC5764]は、DTLSパケットとSRTPパケットからスタンパケットを非難する方法について説明します。
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メディア]に記載されているように、「ラッチ」を介してセッションボーダーコントローラー（SBCS）との悪い相互作用の可能性があります。この問題を回避するために、ICEが使用されておらず、DTLSの握手が反対側のSDPを受信したときに完了していない場合、パッシブ側は適切なピンホールを開くために1つの認証されていないスタン[RFC5389]接続チェックを行う必要があります。。すべての実装は、そうでなければ氷をしていなくても、握手期間中にこの要求に答えるために準備する必要があります。ただし、アクティブ側は、そのようなスタンチェックが受信されず、ServerHelloを送信する前にパッシブがスタン回答を待ってはならない場合でも、必要に応じて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ハンドシェイクをやり直すことでいつでも再キーできます。Rekeyが進行中ですが、エンドポイントは、以前に確立されたキーイング素材を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セキュリティコンテキストがDTLで確立されている場合の再キーイングに関するさらなる考慮事項は、[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.
会議サーバーは、会議のすべての参加者に同じ暗号化コンテキストを使用する可能性があることが提案されています。このアプローチの利点は、会議サーバーが参加者ごとに1回ではなく、すべてのスピーカーの出力を暗号化するだけであることです。
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ソフトウェアとハードウェアの実装を再利用する機能は、DTLを介してRTPの代わりにDTLS-SRTPを使用するための別の重要な動機を提供する場合があります。この仕様の実装は、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メッセージフローを示しています。つまり、ボブがアリスから招待状を受け取るとすぐに、DTLがオファーの「M =」行で指定されているため、ボブはRTPストリームとRTCPストリームの両方でアリスとのDTLS関連の交渉を開始します。Early Media（RTPとRTCP）は、ボブがDTLS完成したメッセージをアリスに送信するとすぐに、ボブからアリスに流れ始めます。AliceがSIP 200応答を受け取り、Aliceが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 IDが使用されていない場合は、プロキシ間の輸送も何らかの形で保護する必要があります。
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
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トランスポートプロトコルを引き継いで、アリスとアリスのアイデンティティサービスとして機能する彼女のプロキシとの間の整合性保護チャネルを確保することを示しています。アリスは、a = setup：actpass in the SDPを指定することにより、アクティブまたはパッシブエンドポイントのいずれかを要求しました。ボブは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
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
Message (2): INVITE Proxy -> Bob
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.
これは、アリス（およびボブの）プロキシからボブに中継されている招待状を示しています。Aliceの代理人がアイデンティティとアイデンティティINFOヘッダーを挿入したことに注意してください。この例は、単純化の目的で両方のプロキシの1つの要素のみを示しています。ボブは、招待状で提供されたアイデンティティを検証します。
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
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
Message (3): ClientHello Bob -> Alice
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（s）をアリスに直接送信することを示しています。この場合、2つのDTLS ClientHelloメッセージがAliceに送信されます。1つはua1.example.com:6056にRTPの場合は、もう1つはRTCPのポート6057に送信されますが、図のコンパクトさのために1つの矢印のみが描かれています。
Message (4): ServerHello+Certificate Alice -> Bob
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.
Aliceは、RTPとRTCPの両方の関連付けにServerHello、証明書、およびサーバーヘロドンを送り返します。同じ証明書がRTPとRTCPの両方の協会に使用されることに注意してください。RTP/RTCP多重化[RFC5761]が使用されている場合、単一の関連付けのみが必要です。
Message (5): Certificate Bob -> Alice
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の両方の協会の両方で終了します。繰り返しますが、Bobは両方の関連付けに同じサーバー証明書を使用していることに注意してください。
Message (6): Early Media Bob -> Alice
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
After Message 7 is received by Bob, Alice sends change_cipher_spec and Finished.
メッセージ7がボブによって受信された後、アリスはchange_cipher_specを送信して終了します。
Message (8): 200 OK Bob -> Alice
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メッセージを送信します。BOBは、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
Message (9): 200 OK Proxy -> Alice
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に示されている証明書を検証します。エンドポイントは、アリスがCallsが保護されていることを示しています。
Message (10): RTP+RTCP Alice -> Bob
At this point, Alice can also start sending RTP and RTCP to Bob.
この時点で、アリスはRTPとRTCPの送信をBOBに開始することもできます。
Message (11): ACK Alice -> Bob
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:
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アップデートを実行するメッセージ10-13は新しいものです。
Message (10): UPDATE Bob -> Proxy
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.
ボブはAliceにRFC 4916アップデートを送信します。この更新には、彼の指紋が含まれています。ボブの更新には、200 OK（メッセージ8）で提供されたのと同じセッション情報が含まれています。原則として、ここで更新を使用してセッションパラメーターを変更できることに注意してください。ただし、この場合、指紋を確認するためだけに使用されています。
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
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
Message (11): UPDATE Proxy -> Alice
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.)
これは、ボブ（およびアリスの代理）からアリスに中継されているアップデートが示されています。ボブの代理人がアイデンティティとアイデンティティINFOヘッダーを挿入したことに注意してください。上記のように、単純化の目的で両方のプロキシに対して1つの要素のみを表示します。アリスは、提供されたアイデンティティを検証します。（注：ここでの実際のID署名は正しくなく、単に例として提供されます。）
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
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
Message (12): 200 OK Alice -> Bob
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.
これは、ボブの更新に対するアリスの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
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
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:
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つの新しいメッセージを使用して：
Message (5): STUN connectivity-check Alice -> Bob
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相互作用の問題を回避するためのアプローチについて説明します。アリス（パッシブエンドポイント）は、スタン接続チェックをボブに送信します。これにより、アリスのNAT/ファイアウォールにピンホールが開きます。
Message (6): STUN connectivity-check response Bob -> Alice
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.
ボブ（アクティブエンドポイント）は、スタン接続チェック（メッセージ3）への応答をアリスに送信します。これにより、アリスは、彼女の接続チェックが成功し、再送信状態マシンを停止できることを示しています。
Message (7): Hello (retransmit) Bob -> Alice
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.
SIPで合図されたDTLSまたはTLSメディアには、通信ピアの証明書が正しいことを確認する方法が必要です。
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の握手は中間の攻撃でハイジャックすることはできません。この整合性保護は、SIP ID [RFC4474]メカニズムを介して、Calleeに呼び出し元によってCalleeに簡単に提供されます（セクション7のAliceからBobを参照）。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 IDは、応答の署名をサポートしていません。理想的には、アリスは、ボブのSDPが改ざんされておらず、それが誰であるかを知りたいと思うでしょう。[RFC4916]は、UAがそのアイデンティティを同業者に提供するアプローチを定義し、このアイデンティティが認証サービスによって署名されるようにします。たとえば、このアプローチを使用して、ボブは回答を送信し、その後、指紋を含む更新をすぐにフォローアップし、SIP IDメカニズムを使用してメッセージがbob@example.comからのものであると主張します。このアプローチの欠点は、アップデートの追加の往復が必要であることです。ただし、すべてのプロキシが信頼されているわけではない場合でも、シンプルで安全です。この例では、ボブは彼の代理を信頼するだけであるだけです。提供者はこのメカニズムをサポートする必要があり、応答者はそれを使用する必要があります。
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.
場合によっては、応答者は更新を送信せず、多くの電話で、更新が受信される前に一部のメディアが送信されます。これらの場合、ボブからアリスへの指紋に完全性は提供されていません。このアプローチでは、信号経路にあった攻撃者が指紋を改ざんし、メディアの中間の男として自分自身を挿入することができます。アリスは、彼女が誰かと安全な電話をかけたことを知っているでしょうが、それがボブと一緒にいたのか、それとも中間の男かはわかりません。ボブは攻撃が起こっていることを知っているでしょう。片側がこの攻撃を検出できるという事実は、ほとんどの場合、アリスとボブがコミュニケーションを暗号化することを望んでいることを意味します。問題はないことです。考えられるアプローチのいずれかで、ボブは誰にでも受け取られたメディアを常に明らかにすることができることに留意してください。私たちは、ボブも安全なコミュニケーションを望んでいると仮定しています。これは何もしないことで、ボブはメディアが第三者に改ざんされておらず、傍受されていないことを知っており、それは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 IDが使用されていないが、シグナリングがSIPによって保護されている場合、セキュリティ保証は弱くなります。すべてのプロキシが信頼されている限り、一部のセキュリティはまだ提供されています。これにより、トラストチェーンセキュリティモデルの指紋に完全性が提供されます。ただし、プロキシが信頼されていない場合、提供されるセキュリティのレベルは限られていることに注意してください。
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]は、指紋がBOBからのものであることに署名するために使用できる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.
安全なメディアシステムの望ましいプロパティの1つは、認証の継続性を提供することです。以前と同じ人と話していることを暗号化することができることです。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シグナリングに結合するために使用される場合、メディアの出所とセキュリティに関する保証は、シグナリングのものと同じくらい良いものです。ここに注意すべき2つの重要なケースがあります。
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 電話番号uris（例： 'sip：17005551008@chicago.example.com'または 'sip：17005551008@chicago.example.com; user =電話'）が使用される場合、ドメイン名が個々のプロキシとUASには、他のドメインを信頼できるプライベートアレンジメントがある場合がありますが、特定の電話番号の権威があります。これは、公開された電話ネットワーク（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がデータ起源の整合性と機密性の観点から提供する保証は、RFC 4474が使用される場合にSIPがシグナリングの整合性を提供するよりも必ずしも優れていません。したがって、実装者は、ユーザーインターフェイスに誤解を招くピアアイデンティティ情報を示さないように注意する必要があります。つまり、ピアの身元がsip：17005551008@chicago.example.comである場合、ドメインが「chicago.example.com」と述べているポリシーがない限り、ピアのアイデンティティが17005551008としてのアイデンティティを表示するだけでは不十分です。ASRETの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メッセージの部分を変更して、署名を破壊することが知られています。この種の中間操作は、まさにRFC 4474が検出することを目的としている一種のメッセージ変更です。ミドルボックス自体が有効なRFC 4474署名を生成することが許可されている場合（たとえば、RFC 4474認証サービスと同じ管理ドメイン内にあります）、変更されたメッセージに新しい署名を生成する場合があります。あるいは、ミドルボックスは、主張することが許可されている他のアイデンティティで署名できる場合があります。それ以外の場合、受信者はRFC 4474 IDアサーションに依存することはできず、UAは、請求されたIDに対して安全な呼び出しが確立されていることをユーザーに示してはなりません。安全な呼び出しのみを確立するように構成されている実装は、この場合に呼び出しを終了するはずです。
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.
この仕様は、独立して検証可能であるエンドポイントによって保持されている証明書に依存しません（たとえば、信頼できるサードパーティによって発行されます）。ただし、そのような証明書が使用されていることに制限はありません。そのような証明書を取得するのが難しいことは別として、これらの証明書にどのようなアイデンティティが含まれるかは明確ではありません。RFC3261は、ここでも使用できるS/MIME証明書の条約を指定しますが、最小限の展開のみが見られます。ただし、このような慣習を確立できる閉鎖または半閉鎖のコンテキストでは、サードパーティの証明書は、エンドポイントのドメインでのプロキシさえ信頼することへの依存を減らすことができます。
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.
長期的な鍵の使用に関する懸念の1つは、その鍵の妥協が過去のコミュニケーションの妥協につながる可能性があることです。この攻撃を防ぐために、DTLSは、Diffie-HellmanおよびElliptic-Curve Diffie-Hellman cipherスイートを使用して、完全な前方秘密を備えたモードをサポートしています。これらのモードが使用されている場合、システムはそのような攻撃に対して安全です。長期キーの妥協は、将来の積極的な攻撃につながる可能性があることに注意してください。これが懸念の場合、手動指紋の確立や短い認証文字列などのバックアップ認証チャネルを使用する必要があります。
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.
Cullen Jenningsは、この文書にかなりのテキストとコメントを提供しました。この文書は、フランソワ・オーデット、ナゲンドラ・モダドゥグ、ダン・ウィングとの議論の恩恵を受けました。フレミング・アンドレアセン、ジョナサン・ローゼンバーグ、ロハン・マヒー、デビッド・マクグリュー、ミゲル・ガルシア、ステフェン・フライス、ブライアン・スタッカー、ロバート・ギルマン、デビッド・オラン、ピーター・シュナイダーによる有用なコメントもありがとう。
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.
Thomas Belling、Guenther Horn、Steffen Fries、Brian Stucker、Francois Audet、Dan Wing、Jari Arkko、およびVesa Lehtovirtaに、SBCSのトラバーサルに関する意見に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet 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。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、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] Lennox、J。、「セッション説明プロトコル（SDP）の輸送層セキュリティ（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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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] Lazzaro、J。、「接続指向の輸送上のリアルタイム輸送プロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットのフレーミング」、RFC 4571、2006年7月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（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] Rosenberg、J。、「Interactive Connectivity Indecivity（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.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（SDP）メディアストリームのセキュリティ説明」、RFC 4568、2006年7月。
[AVT-ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, March 2009.
[AVT-ZRTP] Zimmermann、P.、Johnston、A。、およびJ. Callas、「ZRTP：Secure 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] McGrew、D。、Andreasen、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] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのキーを確立するためのキーを確立する」、2010年5月、RFC 5764。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, March 2009.
[RFC5479] Wing、D.、Fries、S.、Tschofenig、H。、およびF. Audet、「メディアセキュリティ管理プロトコルの要件と分析」、RFC 5479、2009年3月。
[MMUSIC-SDP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, February 2010.
[MMUSIC-SDP] Andreasen、F。、「SDP Capability Negotiation」、Work in Progress、2010年2月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761] Perkins、C。およびM. Westerlund、「単一のポートの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] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定応答の信頼性」、RFC 3262、2002年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[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] Wing、D.、Audet、F.、Fries、S.、Tschofenig、H。、およびA. Johnston、「セッション開始プロトコルによる安全なメディア録音とトランスコーディング」、2008年10月の作業。
[KEY-TRANSPORT] Wing, D., "DTLS-SRTP Key Transport (KTR)", Work in Progress, March 2009.
[Key-Transport] Wing、D。、「DTLS-SRTP Key Transport（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] Munakata、M.、Schubert、S。、およびT. Ohba、「SIPのユーザーエージェント主導のプライバシーメカニズム」、RFC 5767、2010年4月。
[RFC5479] describes security requirements for media keying. This section evaluates this proposal with respect to each requirement.
[RFC5479]は、メディアキーイングのセキュリティ要件を説明しています。このセクションでは、各要件に関するこの提案を評価します。
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オファー（招待状）は、単にセキュリティを行う機能の広告です。この広告は通信仲間の身元に依存していないため、すべてのエンドポイントがSRTPを実行する場合、フォーキングとリターゲティング作業を行います。SRTPと非SRTPエンドポイントの組み合わせが存在する場合、現在定義中のSDP機能メカニズムを使用して[MMUSIC-SDP]を使用して、可能な場合はセキュリティを透過的に交渉します。DTLSは各セッションの新しいキーを確立するため、コールが最終的に確立されるエンティティのみがメディア暗号化キー（R3）を取得します。
DTLS performs a new DTLS handshake with each endpoint, which establishes distinct keys and cryptographic contexts for each endpoint.
DTLSは、各エンドポイントで新しいDTLSハンドシェイクを実行し、各エンドポイントの異なるキーと暗号化コンテキストを確立します。
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]を参照してください。
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の回答を受ける前にメディアをクリップする必要はありません。ただし、提供者が回答を受信するまで機密性のみが提供されることに注意してください。応答者は、攻撃者にデータを送信していないことを知っていますが、提供者は回答者からデータを受信していることを知ることができません。
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、Elliptic Curve Diffie-HellmanなどのDTLS暗号スイートで使用される公開キーアルゴリズムは、パッシブ攻撃に対して安全です。
DTLS provides protection against passive attacks by adversaries on the signaling path since only a fingerprint is exchanged using SIP signaling.
DTLSは、SIP信号を使用して指紋のみが交換されるため、信号経路での敵による受動的攻撃に対する保護を提供します。
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 IDまたは同等のメカニズムが使用されている場合、ID署名を実行するプロキシ間の任意のポイントでシグナリングチャネルを制御する攻撃者は、署名を無効にすることなく指紋を変更できません。したがって、シグナリングパスとメディアパスの両方を制御する攻撃者でさえ、メディアトラフィックを正常に攻撃することはできません。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 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-Identity [RFC4474]やSIPに接続されたアイデンティティ[RFC4916]またはS/MIMEなどのエンドツーエンドメカニズムが使用されると、エンドポイントの証明書指紋をFROMに結合します。指紋は、ID署名によって覆われています。他のメカニズム（SIPなど）を使用すると、結合はそれに応じて弱くなります。
DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher suites that provide PFS.
DTLSは、PFSを提供するDiffie-HellmanおよびElliptic Curve Diffie-Hellman暗号スイートをサポートしています。
DTLS negotiates cipher suites before performing significant cryptographic computation and therefore supports algorithm negotiation and multiple cipher suites without additional computational expense.
DTLSは、重要な暗号化計算を実行する前に暗号スイートを交渉し、したがって、追加の計算費用なしでアルゴリズムの交渉と複数の暗号スイートをサポートします。
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コンテンツタイプは最初の2つのビットがゼロに設定されているため、ゼロのバージョンになります。したがって、最初の妥当性チェックに失敗します。DTLSパケットは、スタンパケットと区別することもできます。Demultiplexingの詳細については、[RFC5764]を参照してください。
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.
DTLSが使用する証明書を認証するためにシグナリング（[RFC4474]など）を使用するため、サードパーティの証明書は必要ありません。ただし、当事者がTLS（サードパーティの証明書または共有キー）と互換性のある認証インフラストラクチャを共有する場合、使用できます。
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の承認と一致しています。
The signaling exchange is linked to the key management exchange using the fingerprints carried in SIP and the certificates are exchanged in DTLS.
シグナリング交換は、SIPで運ばれた指紋を使用して主要な管理交換にリンクされ、証明書はDTLで交換されます。
DTLS offers some degree of Denial-of-Service (DoS) protection as a built-in feature (see Section 4.2.1 of [RFC4347]).
DTLSは、組み込み機能としてある程度のサービス拒否（DOS）保護を提供します（[RFC4347]のセクション4.2.1を参照）。
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.
DTLでは、暗号スイートを交渉できるため、新しいアルゴリズムを段階的に展開できます。固定されたMD5/SHA-1キー派生関数の交換に関する作業が進行中です。
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にコールをダウングレードするのを防ぐことができます。
DTLS allows a User Agent to negotiate media security parameters for each individual session.
DTLSを使用すると、ユーザーエージェントは個々のセッションごとにメディアセキュリティパラメーターをネゴシエートできます。
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に依存していません。指紋を交換できるすべてのプロトコルとメディアの説明を確保できます。
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として行動する必要があります。
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.
メディアをトランスコードする仲介者とインターフェイスするには、トランスコダーはキーイング素材にアクセスし、このドキュメントの目的のためにエンドポイントとして扱われる必要があります。
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ネームスペースについて話すことが許可されているため、このフレームワークのセキュリティ目標と一致しています。
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がAnswererと交渉されるまで、RTPメディアを呼び出し当事者が受信できます。その後、SRTPはRTPよりも優先されます。
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
Jason Fischl Skype、Inc。2145 Hamilton Ave. San Jose、CA 95135 USA
Phone: +1-415-692-1760
EMail: jason.fischl@skype.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo, 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo、02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM、Inc。2064 Edgewood Drive Palo Alto、CA 94303 USA
EMail: ekr@rtfm.com