[要約] RFC 5764は、SRTPのための鍵を確立するためのDTLS拡張に関するものです。このRFCの目的は、SRTPセッションのセキュリティを向上させるために、DTLSを使用して鍵を交換する方法を提供することです。
Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 5764 Cisco Systems
Category: Standards Track E. Rescorla
ISSN: 2070-1721 RTFM, Inc.
May 2010
Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
データグラムトランスポートレイヤーセキュリティ（DTLS）セキュアリアルタイムトランスポートプロトコル（SRTP）のキーを確立するための拡張
Abstract
概要
This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present.
このドキュメントでは、Datagram Transport Layer Security（DTLS）拡張機能を説明して、セキュアRTP（SRTP）およびセキュアRTP制御プロトコル（SRTCP）フローのキーを確立します。DTLSキーイングは、存在する帯域外シグナリングチャネルとは無関係に、メディアパスで発生します。
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/rfc5764.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5764で取得できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4
4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5
4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5
4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7
4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8
4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9
4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12
5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13
5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16
6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17
7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17
7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18
7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18
7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19
8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23
Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24
The Secure RTP (SRTP) profile [RFC3711] can provide confidentiality, message authentication, and replay protection to RTP data and RTP Control (RTCP) traffic. SRTP does not provide key management functionality, but instead depends on external key management to exchange secret master keys, and to negotiate the algorithms and parameters for use with those keys.
Secure RTP（SRTP）プロファイル[RFC3711]は、RTPデータとRTPコントロール（RTCP）トラフィックに機密性、メッセージ認証、およびリプレイ保護を提供できます。SRTPはキー管理機能を提供するのではなく、外部キー管理に依存して、シークレットマスターキーを交換し、それらのキーで使用するアルゴリズムとパラメーターをネゴシエートします。
Datagram Transport Layer Security (DTLS) [RFC4347] is a channel security protocol that offers integrated key management, parameter negotiation, and secure data transfer. Because DTLS data transfer protocol is generic, it is less highly optimized for use with RTP than is SRTP, which has been specifically tuned for that purpose.
Datagram Transport Layer Security（DTLS）[RFC4347]は、統合されたキー管理、パラメーターネゴシエーション、安全なデータ転送を提供するチャネルセキュリティプロトコルです。DTLSデータ転送プロトコルは汎用であるため、その目的のために特別に調整されているSRTPよりもRTPで使用するためにあまり最適化されていません。
This document describes DTLS-SRTP, a SRTP extension for DTLS that combines the performance and encryption flexibility benefits of SRTP with the flexibility and convenience of DTLS-integrated key and association management. DTLS-SRTP can be viewed in two equivalent ways: as a new key management method for SRTP, and a new RTP-specific data format for DTLS.
このドキュメントでは、SRTPのパフォーマンスと暗号化の柔軟性の利点を、DTLS統合キーおよび関連管理の柔軟性と利便性と便利さを組み合わせたDTLのSRTP拡張機能であるDTLS-SRTPについて説明します。DTLS-SRTPは、SRTPの新しいキー管理方法として、およびDTLの新しいRTP固有のデータ形式として、2つの同等の方法で表示できます。
The key points of DTLS-SRTP are that:
DTLS-SRTPの重要なポイントは次のとおりです。
o application data is protected using SRTP,
o アプリケーションデータはSRTPを使用して保護されています、
o the DTLS handshake is used to establish keying material, algorithms, and parameters for SRTP,
o DTLSの握手は、srtpのキーイング材料、アルゴリズム、およびパラメーターを確立するために使用されます。
o a DTLS extension is used to negotiate SRTP algorithms, and
o DTLS拡張機能は、SRTPアルゴリズムをネゴシエートするために使用されます。
o other DTLS record-layer content types are protected using the ordinary DTLS record format.
o 他のDTLSレコード層コンテンツタイプは、通常のDTLSレコード形式を使用して保護されています。
The remainder of this memo is structured as follows. Section 2 describes conventions used to indicate normative requirements. Section 3 provides an overview of DTLS-SRTP operation. Section 4 specifies the DTLS extensions, while Section 5 discusses how RTP and RTCP are transported over a DTLS-SRTP channel. Section 6 describes use with multi-party sessions. Section 7 and Section 9 describe Security and IANA considerations.
このメモの残りは次のように構成されています。セクション2では、規範的要件を示すために使用される規則について説明します。セクション3では、DTLS-SRTP操作の概要を説明します。セクション4では、DTLS拡張機能を指定し、セクション5では、RTPとRTCPがDTLS-SRTPチャネルでどのように輸送されるかについて説明します。セクション6では、マルチパーティセッションでの使用について説明します。セクション7およびセクション9では、セキュリティとIANAの考慮事項について説明します。
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-SRTP is defined for point-to-point media sessions, in which there are exactly two participants. Each DTLS-SRTP session contains a single DTLS association (called a "connection" in TLS jargon), and either two SRTP contexts (if media traffic is flowing in both directions on the same host/port quartet) or one SRTP context (if media traffic is only flowing in one direction). All SRTP traffic flowing over that pair in a given direction uses a single SRTP context. A single DTLS-SRTP session only protects data carried over a single UDP source and destination port pair.
DTLS-SRTPは、ポイントツーポイントメディアセッションに対して定義されており、この参加者は正確に2人の参加者がいます。各DTLS-SRTPセッションには、単一のDTLSアソシエーション（TLS専門用語の「接続」と呼ばれる）と、2つのSRTPコンテキスト（同じホスト/ポートカルテットの両方向にメディアトラフィックが流れる場合）または1つのSRTPコンテキスト（メディアの場合）が含まれています（メディアの場合）トラフィックは一方向にのみ流れています）。特定の方向にそのペアに流れるすべてのSRTPトラフィックは、単一のSRTPコンテキストを使用します。単一のDTLS-SRTPセッションは、単一のUDPソースと宛先ポートペアに搭載されたデータのみを保護します。
The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP flow the peers do a DTLS handshake on the same source and destination port pair to establish a DTLS association. Which side is the DTLS client and which side is the DTLS server must be established via some out-of-band mechanism such as SDP. The keying material from that handshake is fed into the SRTP stack. Once that association is established, RTP packets are protected (becoming SRTP) using that keying material.
DTLS-SRTPの一般的なパターンは次のとおりです。各RTPまたはRTCPフローについて、ピアは同じソースと宛先ポートペアでDTLSハンドシェイクを行い、DTLSアソシエーションを確立します。どちら側がDTLSクライアントであり、どの側がDTLSサーバーがSDPなどの帯域外のメカニズムを介して確立する必要があります。その握手からのキーイング素材は、SRTPスタックに供給されます。その関連付けが確立されると、RTPパケットはそのキーイン素材を使用して保護されます（SRTPになります）。
RTP and RTCP traffic is usually sent on two separate UDP ports. When symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions are needed, one for the RTP port, one for the RTCP port. When RTP flows are not symmetric, four unidirectional DTLS-SRTP sessions are needed (for inbound and outbound RTP, and inbound and outbound RTCP).
RTPおよびRTCPトラフィックは通常、2つの別々のUDPポートで送信されます。対称RTP [RFC4961]を使用する場合、2つの双方向DTLS-SRTPセッションが必要です。1つはRTCPポート用です。RTPフローが対称でない場合、4つの単方向DTLS-SRTPセッションが必要です（インバウンドおよびアウトバウンドRTP、およびインバウンドおよびアウトバウンドRTCPの場合）。
Symmetric RTP [RFC4961] is the case in which there are two RTP sessions that have their source and destination ports and addresses reversed, in a manner similar to the way that a TCP connection uses its ports. Each participant has an inbound RTP session and an outbound RTP session. When symmetric RTP is used, a single DTLS-SRTP session can protect both of the RTP sessions. It is RECOMMENDED that symmetric RTP be used with DTLS-SRTP.
対称RTP [RFC4961]は、TCP接続がポートを使用する方法と同様の方法で、ソースと宛先ポートとアドレスを逆にする2つのRTPセッションがある場合です。各参加者には、インバウンドRTPセッションとアウトバウンドRTPセッションがあります。対称RTPを使用すると、単一のDTLS-SRTPセッションが両方のRTPセッションを保護できます。対称RTPをDTLS-SRTPで使用することをお勧めします。
RTP and RTCP traffic MAY be multiplexed on a single UDP port [RFC5761]. In this case, both RTP and RTCP packets may be sent over the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions needed. This improves the cryptographic performance of DTLS, but may cause problems when RTCP and RTP are subject to different network treatment (e.g., for bandwidth reservation or scheduling reasons).
RTPおよびRTCPトラフィックは、単一のUDPポート[RFC5761]で多重化される場合があります。この場合、RTPパケットとRTCPパケットの両方が同じDTLS-SRTPセッションで送信され、必要なDTLS-SRTPセッションの数を半分にすることができます。これにより、DTLの暗号化パフォーマンスが向上しますが、RTCPとRTPが異なるネットワーク処理の対象となる場合に問題を引き起こす可能性があります（例：帯域幅の予約やスケジューリングの理由など）。
Between a single pair of participants, there may be multiple media sessions. There MUST be a separate DTLS-SRTP session for each distinct pair of source and destination ports used by a media session (though the sessions can share a single DTLS session and hence amortize the initial public key handshake!).
参加者のペアの間には、複数のメディアセッションがある場合があります。メディアセッションで使用されるソースポートと宛先ポートの個別のペアごとに個別のDTLS-SRTPセッションが必要です（ただし、セッションでは単一のDTLSセッションを共有して、最初の公開キーハンドシェイクを償却できます！）。
A DTLS-SRTP session may be indicated by an external signaling protocol like SIP. When the signaling exchange is integrity-protected (e.g., when SIP Identity protection via digital signatures is used), DTLS-SRTP can leverage this integrity guarantee to provide complete security of the media stream. A description of how to indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to authenticate the endpoints using fingerprints can be found in [RFC5763].
DTLS-SRTPセッションは、SIPのような外部シグナル伝達プロトコルによって示される場合があります。シグナリング交換が整合性で保護されている場合（たとえば、デジタル署名を介したSIP ID保護を使用する場合）、DTLS-SRTPはこの整合性保証を活用して、メディアストリームの完全なセキュリティを提供できます。SIPおよびSDP [RFC4566]でDTLS-SRTPセッションを示す方法の説明、および指紋を使用してエンドポイントを認証する方法は[RFC5763]に記載しています。
In a naive implementation, when there are multiple media sessions, there is a new DTLS session establishment (complete with public key cryptography) for each media channel. For example, a videophone may be sending both an audio stream and a video stream, each of which would use a separate DTLS session establishment exchange, which would proceed in parallel. As an optimization, the DTLS-SRTP implementation SHOULD use the following strategy: a single DTLS association is established, and all other DTLS associations wait until that connection is established before proceeding with their handshakes. This strategy allows the later sessions to use DTLS session resumption, which allows the amortization of the expensive public key cryptography operations over multiple DTLS handshakes.
素朴な実装では、複数のメディアセッションがある場合、各メディアチャネルに新しいDTLSセッションの確立（公開キーの暗号化を備えています）があります。たとえば、ビデオフォンはオーディオストリームとビデオストリームの両方を送信している場合があります。それぞれが別のDTLSセッション確立交換を使用し、並行して進行します。最適化として、DTLS-SRTP実装は次の戦略を使用する必要があります。単一のDTLSアソシエーションが確立され、他のすべてのDTLSアソシエーションは、握手を進める前にその接続が確立されるまで待ちます。この戦略により、後のセッションがDTLSセッション再開を使用することができます。これにより、複数のDTLハンドシェイクにわたって高価な公開キー暗号操作の償却が可能になります。
The SRTP keys used to protect packets originated by the client are distinct from the SRTP keys used to protect packets originated by the server. All of the RTP sources originating on the client for the same channel use the same SRTP keys, and similarly, all of the RTP sources originating on the server for the same channel use the same SRTP keys. The SRTP implementation MUST ensure that all of the synchronization source (SSRC) values for all of the RTP sources originating from the same device over the same channel are distinct, in order to avoid the "two-time pad" problem (as described in Section 9.1 of RFC 3711). Note that this is not an issue for separate media streams (on different host/port quartets) that use independent keying material even if an SSRC collision occurs.
クライアントが起源とするパケットを保護するために使用されるSRTPキーは、サーバーが起源とするパケットを保護するために使用されるSRTPキーとは異なります。同じチャネルのクライアントに発信されるすべてのRTPソースは、同じSRTPキーを使用し、同様に、同じチャネルのサーバー上に発信されるすべてのRTPソースが同じSRTPキーを使用します。SRTP実装は、「2回のパッド」の問題を回避するために、同じチャネル上の同じデバイスから発信されるすべてのRTPソースのすべての同期ソース（SSRC）値が異なることを確認する必要があります（セクションで説明されているようにRFC 3711の9.1）。これは、SSRCの衝突が発生した場合でも独立したキーイング材料を使用する個別のメディアストリーム（異なるホスト/ポートカルテット）の問題ではないことに注意してください。
In order to negotiate the use of SRTP data protection, clients include an extension of type "use_srtp" in the DTLS extended client hello. This extension MUST only be used when the data being transported is RTP or RTCP [RFC3550]. The "extension_data" field of this extension contains the list of acceptable SRTP protection profiles, as indicated below.
SRTPデータ保護の使用を交渉するために、クライアントには、DTLS拡張クライアントのHelloにタイプ「use_srtp」の拡張が含まれています。この拡張機能は、輸送されるデータがRTPまたはRTCP [RFC3550]である場合にのみ使用する必要があります。この拡張機能の「Extension_Data」フィールドには、以下に示すように、許容可能なSRTP保護プロファイルのリストが含まれています。
Servers that receive an extended hello containing a "use_srtp" extension can agree to use SRTP by including an extension of type "use_srtp", with the chosen protection profile in the extended server hello. This process is shown below.
「use_srtp」拡張機能を含む拡張helloを受信するサーバーは、拡張サーバーに選択された保護プロファイルを持つタイプ「use_srtp」の拡張機能を含めることにより、srtpを使用することに同意できます。このプロセスを以下に示します。
Client Server
クライアントサーバー
ClientHello + use_srtp -------->
ServerHello + use_srtp
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packets
Note that '*' indicates messages that are not always sent in DTLS. The CertificateRequest, client and server Certificates, and CertificateVerify will be sent in DTLS-SRTP.
「*」は、常にDTLで送信されるとは限らないメッセージを示していることに注意してください。CertificateRequest、クライアントおよびサーバーの証明書、および証明書がDTLS-SRTPで送信されます。
Once the "use_srtp" extension is negotiated, the RTP or RTCP application data is protected solely using SRTP. Application data is never sent in DTLS record-layer "application_data" packets. Rather, complete RTP or RTCP packets are passed to the DTLS stack, which passes them to the SRTP stack, which protects them appropriately. Note that if RTP/RTCP multiplexing [RFC5761] is in use, this means that RTP and RTCP packets may both be passed to the DTLS stack. Because the DTLS layer does not process the packets, it does not need to distinguish them. The SRTP stack can use the procedures of [RFC5761] to distinguish RTP from RTCP.
「use_srtp」拡張機能が交渉されると、RTPまたはRTCPアプリケーションデータはSRTPを使用して保護されます。アプリケーションデータは、DTLS Record-Layer "Application_Data"パケットで送信されることはありません。むしろ、完全なRTPまたはRTCPパケットがDTLSスタックに渡され、SRTPスタックに渡され、適切に保護されます。RTP/RTCP多重化[RFC5761]が使用されている場合、これはRTPとRTCPパケットが両方ともDTLSスタックに渡される可能性があることを意味することに注意してください。DTLSレイヤーはパケットを処理しないため、それらを区別する必要はありません。SRTPスタックは[RFC5761]の手順を使用して、RTPとRTCPを区別できます。
When the "use_srtp" extension is in effect, implementations must not place more than one application data "record" per datagram. (This is only meaningful from the perspective of DTLS because SRTP is inherently oriented towards one payload per packet, but this is stated purely for clarification.)
「use_srtp」拡張機能が有効な場合、実装はデータグラムごとに複数のアプリケーションデータ「レコード」を配置してはなりません。（これは、SRTPが本質的にパケットごとに1つのペイロードに向けられているため、DTLSの観点からのみ意味がありますが、これは純粋に明確化のために述べられています。）
Data other than RTP/RTCP (i.e., TLS control messages) MUST use ordinary DTLS framing and MUST be placed in separate datagrams from SRTP data.
RTP/RTCP以外のデータ（つまり、TLS制御メッセージ）は、通常のDTLSフレーミングを使用する必要があり、SRTPデータから個別のデータグラムに配置する必要があります。
A DTLS-SRTP handshake establishes one or more SRTP crypto contexts; however, they all have the same SRTP Protection Profile and Master Key Identifier (MKI), if any. MKIs are used solely to distinguish the keying material and protection profiles between distinct handshakes, for instance, due to rekeying. When an MKI is established in a DTLS-SRTP session, it MUST apply for all of the SSRCs within that session -- though a single endpoint may negotiate multiple DTLS-SRTP sessions due, for instance, to forking. (Note that RFC 3711 allows packets within the same session but with different SSRCs to use MKIs differently; in contrast, DTLS-SRTP requires that MKIs and the keys that they are associated with have the same meaning and are uniform across the entire SRTP session.)
DTLS-SRTPハンドシェイクは、1つ以上のSRTP暗号コンテキストを確立します。ただし、それらはすべて同じSRTP保護プロファイルとマスターキー識別子（MKI）がある場合です。MKIは、たとえば再キーリングのために、別個の握手の間でキーイング材料と保護プロファイルを区別するためだけに使用されます。MKIがDTLS-SRTPセッションで確立される場合、そのセッション内のすべてのSSRCに適用する必要がありますが、単一のエンドポイントは、たとえばフォーキングのために複数のDTLS-SRTPセッションをネゴシエートする場合があります。（RFC 3711は同じセッション内のパケットを許可しているが、異なるSSRCがMKIを異なる方法で使用できることに注意してください。対照的に、DTLS-SRTPでは、MKIと関連付けられているキーが同じ意味を持ち、SRTPセッション全体で均一であることが必要です。））
The client MUST fill the extension_data field of the "use_srtp" extension with an UseSRTPData value (see Section 9 for the registration):
クライアントは、usesrtpdata値で「use_srtp」拡張機能のextension_dataフィールドを埋める必要があります（登録についてはセクション9を参照）：
uint8 SRTPProtectionProfile[2];
uint8 srtpprotectionprofile [2];
struct {
SRTPProtectionProfiles SRTPProtectionProfiles;
opaque srtp_mki<0..255>;
} UseSRTPData;
SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;
The SRTPProtectionProfiles list indicates the SRTP protection profiles that the client is willing to support, listed in descending order of preference. The srtp_mki value contains the SRTP Master Key Identifier (MKI) value (if any) that the client will use for his SRTP packets. If this field is of zero length, then no MKI will be used.
SRTPPROTECTIONPROFILESリストは、クライアントが喜んでサポートしているSRTP保護プロファイルを示し、優先順位の降順でリストされています。SRTP_MKI値には、クライアントがSRTPパケットに使用するSRTPマスターキー識別子（MKI）値（もしあれば）が含まれています。このフィールドの長さがゼロの場合、MKIは使用されません。
Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>" indicates a variable-length value with a length between 0 and 255 (inclusive). Thus, the MKI may be up to 255 bytes long.
注：TLS構文に不慣れな人の場合、「srtp_mki <0..255>」は、長さが0〜255（包括的）の変数長値を示します。したがって、MKIの長さは最大255バイトです。
If the server is willing to accept the use_srtp extension, it MUST respond with its own "use_srtp" extension in the ExtendedServerHello. The extension_data field MUST contain a UseSRTPData value with a single SRTPProtectionProfile value that the server has chosen for use with this connection. The server MUST NOT select a value that the client has not offered. If there is no shared profile, the server SHOULD NOT return the use_srtp extension at which point the connection falls back to the negotiated DTLS cipher suite. If that is not acceptable, the server SHOULD return an appropriate DTLS alert.
サーバーがuse_srtp拡張機能を受け入れることをいとわない場合、拡張Serverhelloの独自の「use_srtp」拡張機能で応答する必要があります。extension_Dataフィールドには、サーバーがこの接続で使用するために選択した単一のsrtpprotectionprofile値を持つuseSrtpdata値を含める必要があります。サーバーは、クライアントが提供していない値を選択してはなりません。共有プロファイルがない場合、サーバーはuse_srtp拡張機能を返すべきではありません。それが受け入れられない場合、サーバーは適切なDTLSアラートを返す必要があります。
A DTLS-SRTP SRTP Protection Profile defines the parameters and options that are in effect for the SRTP processing. This document defines the following SRTP protection profiles.
DTLS-SRTP SRTP保護プロファイルは、SRTP処理に有効なパラメーターとオプションを定義します。このドキュメントでは、次のSRTP保護プロファイルを定義します。
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06};
The following list indicates the SRTP transform parameters for each protection profile. The parameters cipher_key_length, cipher_salt_length, auth_key_length, and auth_tag_length express the number of bits in the values to which they refer. The maximum_lifetime parameter indicates the maximum number of packets that can be protected with each single set of keys when the parameter profile is in use. All of these parameters apply to both RTP and RTCP, unless the RTCP parameters are separately specified.
次のリストは、各保護プロファイルのSRTP変換パラメーターを示しています。パラメーターcipher_key_length、cipher_salt_length、auth_key_length、およびauth_tag_lengthは、参照する値のビット数を表します。Maximum_lifetimeパラメーターは、パラメータープロファイルが使用されているときに各単一のキーセットで保護できるパケットの最大数を示します。これらのパラメーターはすべて、RTCPパラメーターが個別に指定されていない限り、RTPとRTCPの両方に適用されます。
All of the crypto algorithms in these profiles are from [RFC3711].
これらのプロファイルの暗号アルゴリズムはすべて[RFC3711]からのものです。
SRTP_AES128_CM_HMAC_SHA1_80 cipher: AES_128_CM cipher_key_length: 128 cipher_salt_length: 112 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80 SRTP_AES128_CM_HMAC_SHA1_32 cipher: AES_128_CM cipher_key_length: 128 cipher_salt_length: 112 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 32 RTCP auth_tag_length: 80 SRTP_NULL_HMAC_SHA1_80 cipher: NULL cipher_key_length: 0 cipher_salt_length: 0 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80
：32 rtcp auth_tag_length：80 srtp_null_hmac_sha1_80 cipher：null cipher_key_length：0 cipher_salt_lifetime：0 maximing_lifetime：2^31 auth_function：hmac-sha1 auth_key_length：160 auth_tag_length：80
SRTP_NULL_HMAC_SHA1_32 cipher: NULL cipher_key_length: 0 cipher_salt_length: 0 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 32 RTCP auth_tag_length: 80
srtp_null_hmac_sha1_32 cipher：null cipher_key_length：0 cipher_salt_lentime：0 maximing_lifetime：2^31 auth_function：hmac-sha1 auth_key_length：160 auth_tag_length：32 rtcp auth_tag_length：80
With all of these SRTP Parameter profiles, the following SRTP options are in effect:
これらすべてのSRTPパラメータープロファイルを使用すると、次のSRTPオプションが有効です。
o The TLS PseudoRandom Function (PRF) is used to generate keys to feed into the SRTP Key Derivation Function (KDF). When DTLS 1.2 [DTLS1.2] is in use, the PRF is the one associated with the cipher suite. Note that this specification is compatible with DTLS 1.0 or DTLS 1.2
o TLS擬似ランダム関数（PRF）は、SRTPキー誘導関数（KDF）にフィードするキーを生成するために使用されます。DTLS 1.2 [DTLS1.2]が使用されている場合、PRFは暗号スイートに関連するものです。この仕様はDTLS 1.0またはDTLS 1.2と互換性があることに注意してください
o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are not re-derived based on the SRTP sequence number.
o キー誘導速度（KDR）はゼロに等しくなります。したがって、キーはSRTPシーケンス番号に基づいて再編成されません。
o The key derivation procedures from Section 4.3 with the AES-CM PRF from RFC 3711 are used.
o RFC 3711のAES-CM PRFを使用したセクション4.3からの主要な派生手順が使用されます。
o For all other parameters (in particular, SRTP replay window size and FEC order), the default values are used.
o 他のすべてのパラメーター（特に、SRTPリプレイウィンドウサイズとFEC順序）では、デフォルト値が使用されます。
If values other than the defaults for these parameters are required, they can be enabled by writing a separate specification specifying SDP syntax to signal them.
これらのパラメーターのデフォルト以外の値が必要な場合、SDP構文を指定する別の仕様を作成してそれらを信号にすることで有効にできます。
Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection Profiles between the DTLS-SRTP session that protects an RTP flow and the DTLS-SRTP session that protects the associated RTCP flow (in those cases in which the RTP and RTCP are not multiplexed over a common port). In particular, identical ciphers SHOULD be used.
DTLS-SRTPを使用したアプリケーションは、RTPフローを保護するDTLS-SRTPセッションと、関連するRTCPフローを保護するDTLS-SRTPセッションの間のSRTP保護プロファイルを調整する必要があります（RTPとRTCPが一般的な共通の場合に多重化されない場合にはポート）。特に、同一の暗号を使用する必要があります。
New SRTPProtectionProfile values must be defined according to the "Specification Required" policy as defined by RFC 5226 [RFC5226]. See Section 9 for IANA Considerations.
新しいSRTPPROTECTIONPROFILE値は、RFC 5226 [RFC5226]で定義されている「必要な仕様」ポリシーに従って定義する必要があります。IANAの考慮事項については、セクション9を参照してください。
The srtp_mki value MAY be used to indicate the capability and desire to use the SRTP Master Key Identifier (MKI) field in the SRTP and SRTCP packets. The MKI field indicates to an SRTP receiver which key was used to protect the packet that contains that field. The srtp_mki field contains the value of the SRTP MKI which is associated with the SRTP master keys derived from this handshake. Each SRTP session MUST have exactly one master key that is used to protect packets at any given time. The client MUST choose the MKI value so that it is distinct from the last MKI value that was used, and it SHOULD make these values unique for the duration of the TLS session.
SRTP_MKI値を使用して、SRTPおよびSRTCPパケットでSRTPマスターキー識別子（MKI）フィールドを使用する能力と欲求を示すことができます。MKIフィールドは、SRTPレシーバーに、そのフィールドを含むパケットを保護するために使用されたキーを示します。SRTP_MKIフィールドには、このハンドシェイクから派生したSRTPマスターキーに関連するSRTP MKIの値が含まれています。各SRTPセッションには、いつでもパケットを保護するために使用されるマスターキーが正確に1つ必要です。クライアントは、使用された最後のMKI値とは異なるようにMKI値を選択する必要があり、TLSセッションの期間中、これらの値を一意にする必要があります。
Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, the server MUST either (assuming it accepts the extension at all):
「srtp_mki」フィールドを含む「use_srtp」拡張子を受信すると、サーバーは（拡張機能をまったく受け入れていると仮定します）が必要です。
1. include a matching "srtp_mki" value in its "use_srtp" extension to indicate that it will make use of the MKI, or 2. return an empty "srtp_mki" value to indicate that it cannot make use of the MKI.
1. 「use_srtp」拡張機能に一致する「srtp_mki」値を含めて、mkiまたは2を使用することを示します。
If the client detects a nonzero-length MKI in the server's response that is different than the one the client offered, then the client MUST abort the handshake and SHOULD send an invalid_parameter alert. If the client and server agree on an MKI, all SRTP packets protected under the new security parameters MUST contain that MKI.
クライアントが提供するサーバーの応答とは異なるサーバーの応答でゼロ以外のMKIを検出した場合、クライアントはハンドシェイクを中止し、InvalID_PARAMETERアラートを送信する必要があります。クライアントとサーバーがMKIに同意する場合、新しいセキュリティパラメーターで保護されているすべてのSRTPパケットはそのMKIを含める必要があります。
Note that any given DTLS-SRTP session only has a single active MKI (if any). Thus, at any given time, a set of endpoints will generally only be using one MKI (the major exception is during rehandshakes).
指定されたDTLS-SRTPセッションには、単一のアクティブMKIのみがあることに注意してください（もしあれば）。したがって、いつでも、エンドポイントのセットは通常、1つのMKIのみを使用しています（主要な例外は再ハンドシェイク中です）。
When SRTP mode is in effect, different keys are used for ordinary DTLS record protection and SRTP packet protection. These keys are generated using a TLS exporter [RFC5705] to generate
SRTPモードが有効になっている場合、通常のDTLSレコード保護とSRTPパケット保護に異なるキーが使用されます。これらのキーは、TLS輸出業者[RFC5705]を使用して生成され、生成されます
2 * (SRTPSecurityParams.master_key_len + SRTPSecurityParams.master_salt_len) bytes of data
2 *（srtpsecurityParams.master_key_len srtpsecurityparams.master_salt_len）データのバイト
which are assigned as shown below. The per-association context value is empty.
以下に示すように割り当てられます。同類ごとのコンテキスト値は空です。
client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
The exporter label for this usage is "EXTRACTOR-dtls_srtp". (The "EXTRACTOR" prefix is for historical compatibility.)
この使用法の輸出ラベルは「Extractor-DTLS_SRTP」です。（「抽出器」プレフィックスは、履歴互換性のためのものです。）
The four keying material values (the master key and master salt for each direction) are provided as inputs to the SRTP key derivation mechanism, as shown in Figure 1 and detailed below. By default, the mechanism defined in Section 4.3 of [RFC3711] is used, unless another key derivation mechanism is specified as part of an SRTP Protection Profile.
図1に示すように、以下に示すように、4つのキーイング材料値（各方向のマスターキーとマスターソルト）は、SRTPキー導出メカニズムへの入力として提供されます。デフォルトでは、[RFC3711]のセクション4.3で定義されたメカニズムが使用されます。
The client_write_SRTP_master_key and client_write_SRTP_master_salt are provided to one invocation of the SRTP key derivation function, to generate the SRTP keys used to encrypt and authenticate packets sent by the client. The server MUST only use these keys to decrypt and to check the authenticity of inbound packets.
client_write_srtp_master_keyとclient_write_srtp_master_saltは、クライアントが送信したパケットを暗号化および認証するために使用されるSRTPキーを生成するために、SRTPキー派生関数の1つの呼び出しに提供されます。サーバーは、これらのキーのみを使用して、インバウンドパケットの信頼性を確認し、確認する必要があります。
The server_write_SRTP_master_key and server_write_SRTP_master_salt are provided to one invocation of the SRTP key derivation function, to generate the SRTP keys used to encrypt and authenticate packets sent by the server. The client MUST only use these keys to decrypt and to check the authenticity of inbound packets.
server_write_srtp_master_keyおよびserver_write_srtp_master_saltは、サーバーが送信したパケットを暗号化および認証するために使用されるSRTPキーを生成するために、SRTPキー派生関数の1つの呼び出しに提供されます。クライアントは、これらのキーのみを使用して、インバウンドパケットの信ity性を確認し、確認する必要があります。
TLS master
secret label
| |
v v
+---------------+
| TLS extractor |
+---------------+
| +------+ SRTP
+-> client_write_SRTP_master_key ----+--->| SRTP |-> client
| | +->| KDF | write
| | | +------+ keys
| | |
+-> server_write_SRTP_master_key -- | | +------+ SRTCP
| \ \--->|SRTCP |-> client
| \ +->| KDF | write
| | | +------+ keys
+-> client_write_SRTP_master_salt ---|-+
| |
| | +------+ SRTP
| +--->| SRTP |-> server
+-> server_write_SRTP_master_salt -+-|--->| KDF | write
| | +------+ keys
| |
| | +------+ SRTCP
| +--->|SRTCP |-> server
+----->| KDF | write
+------+ keys
Figure 1: The derivation of the SRTP keys.
図1：SRTPキーの導出。
When both RTCP and RTP use the same source and destination ports, then both the SRTP and SRTCP keys are needed. Otherwise, there are two DTLS-SRTP sessions, one of which protects the RTP packets and one of which protects the RTCP packets; each DTLS-SRTP session protects the part of an SRTP session that passes over a single source/ destination transport address pair, as shown in Figure 2, independent of which SSRCs are used on that pair. When a DTLS-SRTP session is protecting RTP, the SRTCP keys derived from the DTLS handshake are not needed and are discarded. When a DTLS-SRTP session is protecting RTCP, the SRTP keys derived from the DTLS handshake are not needed and are discarded.
RTCPとRTPの両方が同じソースポートと宛先ポートを使用する場合、SRTPとSRTCPキーの両方が必要です。それ以外の場合は、2つのDTLS-SRTPセッションがあり、そのうちの1つはRTPパケットを保護し、そのうちの1つはRTCPパケットを保護します。各DTLS-SRTPセッションは、図2に示すように、単一のソース/宛先輸送アドレスペアを通過するSRTPセッションの部分を保護します。DTLS-SRTPセッションがRTPを保護している場合、DTLSハンドシェイクから派生したSRTCPキーは必要ありません。DTLS-SRTPセッションがRTCPを保護している場合、DTLSハンドシェイクから派生したSRTPキーは必要なく、廃棄されます。
Client Server
(Sender) (Receiver)
(1) <----- DTLS ------> src/dst = a/b and b/a
------ SRTP ------> src/dst = a/b, uses client write keys
(2) <----- DTLS ------> src/dst = c/d and d/c
------ SRTCP -----> src/dst = c/d, uses client write keys
<----- SRTCP ------ src/dst = d/c, uses server write keys
Figure 2: A DTLS-SRTP session protecting RTP (1) and another one protecting RTCP (2), showing the transport addresses and keys used.
図2：RTP（1）を保護するDTLS-SRTPセッションと、使用されている輸送アドレスとキーを示すRTCP（2）を保護する別のセッション。
Because of the possibility of packet reordering, DTLS-SRTP implementations SHOULD store multiple SRTP keys sets during a rekey in order to avoid the need for receivers to drop packets for which they lack a key.
パケットの並べ替えの可能性があるため、DTLS-SRTP実装では、レシーがキーを欠いているパケットをドロップする必要性を回避するために、REKEY中に複数のSRTPキーセットを保存する必要があります。
The maximum_lifetime parameter in the SRTP protection profile indicates the maximum number of packets that can be protected with each single encryption and authentication key. (Note that, since RTP and RTCP are protected with independent keys, those protocols are counted separately for the purposes of determining when a key has reached the end of its lifetime.) Each profile defines its own limit. When this limit is reached, a new DTLS session SHOULD be used to establish replacement keys, and SRTP implementations MUST NOT use the existing keys for the processing of either outbound or inbound traffic.
SRTP保護プロファイルのMaximum_lifetimeパラメーターは、各単一の暗号化と認証キーで保護できるパケットの最大数を示します。（RTPとRTCPは独立したキーで保護されているため、これらのプロトコルは、キーが寿命の終わりに到達した時期を決定する目的で個別にカウントされます。）各プロファイルは独自の制限を定義します。この制限に到達した場合、新しいDTLSセッションを使用して交換キーを確立する必要があり、SRTP実装は、アウトバウンドトラフィックまたはインバウンドトラフィックの処理に既存のキーを使用してはなりません。
Once the DTLS handshake has completed, the peers can send RTP or RTCP over the newly created channel. We describe the transmission process first followed by the reception process.
DTLSハンドシェイクが完了すると、ピアは新しく作成されたチャネル上でRTPまたはRTCPを送信できます。最初に受信プロセスが続く送信プロセスについて説明します。
Within each RTP session, SRTP processing MUST NOT take place before the DTLS handshake completes.
各RTPセッション内で、DTLSハンドシェイクが完了する前にSRTP処理を行わないでください。
DTLS and TLS define a number of record content types. In ordinary TLS/DTLS, all data is protected using the same record encoding and mechanisms. When the mechanism described in this document is in effect, this is modified so that data written by upper-level protocol clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP rather than the standard TLS record encoding.
DTLSとTLSは、多くのレコードコンテンツタイプを定義します。通常のTLS/DTLでは、すべてのデータが同じレコードエンコードとメカニズムを使用して保護されています。このドキュメントで説明されているメカニズムが有効になると、これはDTLSの上位レベルのプロトコルクライアントによって書かれたデータがRTP/RTPであると想定され、標準のTLSレコードエンコードではなくSRTPを使用して暗号化されるように変更されます。
When a user of DTLS wishes to send an RTP packet in SRTP mode, it delivers it to the DTLS implementation as an ordinary application data write (e.g., SSL_write()). The DTLS implementation then invokes the processing described in RFC 3711, Sections 3 and 4. The resulting SRTP packet is then sent directly on the wire as a single datagram with no DTLS framing. This provides an encapsulation of the data that conforms to and interoperates with SRTP. Note that the RTP sequence number rather than the DTLS sequence number is used for these packets.
DTLSのユーザーがSRTPモードでRTPパケットを送信したい場合、通常のアプリケーションデータ書き込み（ssl_write（）など）としてDTLS実装に配信します。DTLS実装は、RFC 3711、セクション3および4で説明されている処理を呼び出します。結果のSRTPパケットは、DTLSフレーミングなしの単一のデータグラムとしてワイヤに直接送信されます。これにより、SRTPに適合して相互運用するデータのカプセル化が提供されます。DTLSシーケンス番号ではなく、RTPシーケンス番号がこれらのパケットに使用されることに注意してください。
When DTLS-SRTP is used to protect an RTP session, the RTP receiver needs to demultiplex packets that are arriving on the RTP port. Arriving packets may be of types RTP, DTLS, or STUN [RFC5389]. If these are the only types of packets present, the type of a packet can be determined by looking at its first byte.
DTLS-SRTPを使用してRTPセッションを保護する場合、RTPレシーバーはRTPポートに到着しているパケットをDemultiplexパケットにする必要があります。到着パケットは、RTP、DTL、またはスタン[RFC5389]のタイプである場合があります。これらが存在する唯一のタイプのパケットである場合、パケットのタイプは、最初のバイトを見ることで決定できます。
The process for demultiplexing a packet is as follows. The receiver looks at the first byte of the packet. If the value of this byte is 0 or 1, then the packet is STUN. If the value is in between 128 and 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and RTP are being multiplexed over the same destination port). If the value is between 20 and 63 (inclusive), the packet is DTLS. This process is summarized in Figure 3.
パケットを非難するプロセスは次のとおりです。受信者は、パケットの最初のバイトを見ます。このバイトの値が0または1の場合、パケットはスタンです。値が128から191（包括的）の間にある場合、パケットはRTP（またはRTCP、RTCPとRTPの両方が同じ宛先ポートで多重化されている場合）です。値が20〜63（包括的）の場合、パケットはDTLSです。このプロセスを図3にまとめます。
+----------------+
| 127 < B < 192 -+--> forward to RTP
| |
packet --> | 19 < B < 64 -+--> forward to DTLS
| |
| B < 2 -+--> forward to STUN
+----------------+
Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. Here the field B denotes the leading byte of the packet.
図3：DTLS-SRTPレシーバーのパケット脱ultiplexingアルゴリズム。ここで、フィールドBはパケットの主要なバイトを示します。
If other packet types are to be multiplexed as well, implementors and/or designers SHOULD ensure that they can be demultiplexed from these three packet types.
他のパケットタイプも多重化される場合、実装者および/またはデザイナーは、これら3つのパケットタイプから非gultiplexを確実に行えるようにする必要があります。
In some cases, there will be multiple DTLS-SRTP associations for a given SRTP endpoint. For instance, if Alice makes a call that is SIP forked to both Bob and Charlie, she will use the same local host/port pair for both of them, as shown in Figure 4, where XXX and YYY represent different DTLS-SRTP associations. (The SSRCs shown are the ones for data flowing to Alice.)
場合によっては、特定のSRTPエンドポイントに複数のDTLS-SRTP関連があります。たとえば、アリスがボブとチャーリーの両方に分岐した呼び出しを行うと、XXXとYYYが異なるDTLS-SRTP関連を表す図4に示すように、両方に同じローカルホスト/ポートペアを使用します。（示されているSSRCは、アリスに流れるデータのものです。）
Bob (192.0.2.1:6666)
/
/
/ SSRC=1
/ DTLS-SRTP=XXX
/
v
Alice (192.0.2.0:5555)
^
\
\ SSRC=2
\ DTLS-SRTP=YYY
\
\
Charlie (192.0.2.2:6666)
Figure 4: RTP sessions with SIP forking.
図4：SIPフォーキング付きのRTPセッション。
Because DTLS operates on the host/port quartet, the DTLS association will still complete correctly, with the foreign host/port pair being used, to distinguish the associations. However, in RTP the source host/port is not used and sessions are identified by the destination host/port and the SSRC. Thus, some mechanism is needed to determine which SSRCs correspond to which DTLS associations. The following method SHOULD be used.
DTLSはホスト/ポートカルテットで動作するため、DTLS協会はまだ正しく完了し、外国のホスト/ポートペアが使用され、協会を区別します。ただし、RTPでは、ソースホスト/ポートは使用されず、セッションは宛先ホスト/ポートとSSRCによって識別されます。したがって、どのSSRCがどのdtls関連付けに対応するかを決定するために、いくつかのメカニズムが必要です。次の方法を使用する必要があります。
For each local host/port pair, the DTLS-SRTP implementation maintains a table listing all the SSRCs it knows about and the DTLS-SRTP associations they correspond to. Initially, this table is empty. When an SRTP packet is received for a given RTP endpoint (destination IP/port pair), the following procedure is used:
ローカルホスト/ポートペアごとに、DTLS-SRTP実装は、それが知っているすべてのSSRCとそれらに対応するDTLS-SRTPアソシエーションをリストするテーブルを維持しています。最初は、このテーブルは空です。特定のRTPエンドポイント（宛先IP/ポートペア）に対してSRTPパケットが受信されると、次の手順が使用されます。
1. If the SSRC is already known for that endpoint, then the corresponding DTLS-SRTP association and its keying material is used to decrypt and verify the packet. 2. If the SSRC is not known, then the receiver tries to decrypt it with the keying material corresponding to each DTLS-SRTP association for that endpoint. 3. If the decryption and verification succeeds (the authentication tag verifies), then an entry is placed in the table mapping the SSRC to that association. 4. If the decryption and verification fails, then the packet is silently discarded. 5. When a DTLS-SRTP association is closed (for instance, because the fork is abandoned), its entries MUST be removed from the mapping table.
1. SSRCがそのエンドポイントで既に知られている場合、対応するDTLS-SRTPアソシエーションとそのキーイング材料を使用して、パケットを復号化および検証します。2. SSRCが不明な場合、受信者は、そのエンドポイントの各DTLS-SRTP関連に対応するキーイング材料でそれを復号化しようとします。3.復号化と検証が成功した場合（認証タグが検証されます）、エントリがテーブルに配置され、SSRCをその関連付けにマッピングします。4.復号化と検証が失敗した場合、パケットは静かに破棄されます。5. DTLS-SRTPアソシエーションが閉じられている場合（たとえば、フォークが放棄されるため）、マッピングテーブルからエントリを削除する必要があります。
The average cost of this algorithm for a single SSRC is the decryption and verification time of a single packet times the number of valid DTLS-SRTP associations corresponding to a single receiving port on the host. In practice, this means the number of forks; so in the case shown in Figure 4, that would be two. This cost is only incurred once for any given SSRC, since afterwards that SSRC is placed in the map table and looked up immediately. As with normal RTP, this algorithm allows new SSRCs to be introduced by the source at any time. They will automatically be mapped to the correct DTLS association.
単一のSSRCのこのアルゴリズムの平均コストは、ホストの単一の受信ポートに対応する有効なDTLS-SRTP関連の数の単一パケット時間の復号化と検証時間です。実際には、これはフォークの数を意味します。したがって、図4に示す場合、それは2つになります。このコストは、特定のSSRCに対して1回しか発生しません。その後、SSRCがマップテーブルに配置され、すぐに検索されるためです。通常のRTPと同様に、このアルゴリズムにより、新しいSSRCをいつでもソースによって導入できます。それらは自動的に正しいDTLS協会にマッピングされます。
Note that this algorithm explicitly allows multiple SSRCs to be sent from the same address/port pair. One way in which this can happen is an RTP translator. This algorithm will automatically assign the SSRCs to the correct associations. Note that because the SRTP packets are cryptographically protected, such a translator must either share keying material with one endpoint or refrain from modifying the packets in a way which would cause the integrity check to fail. This is a general property of SRTP and is not specific to DTLS-SRTP.
このアルゴリズムにより、複数のSSRCを同じアドレス/ポートペアから送信できるようにすることに注意してください。これが起こる可能性のある方法の1つは、RTP翻訳者です。このアルゴリズムは、SSRCを正しい関連付けに自動的に割り当てます。SRTPパケットは暗号化されているため、そのような翻訳者はキーイングを1つのエンドポイントと共有するか、整合性チェックを失敗させる方法でパケットの変更を控える必要があることに注意してください。これはSRTPの一般的な特性であり、DTLS-SRTPに固有のものではありません。
There are two error cases that should be considered. First, if an SSRC collision occurs, then only the packets from the first source will be processed. When the packets from the second source arrive, the DTLS association with the first source will be used for decryption and verification, which will fail, and the packet will be discarded. This is consistent with [RFC3550], which permits the receiver to keep the packets from one source and discard those from the other. Of course the RFC 3550 SSRC collision detection and handling procedures MUST also be followed.
考慮すべき2つのエラーケースがあります。まず、SSRC衝突が発生した場合、最初のソースからのパケットのみが処理されます。2番目のソースからのパケットが到着すると、最初のソースとのDTLS関連が復号化と検証に使用され、故障し、パケットが破棄されます。これは[RFC3550]と一致しています。これにより、受信機はパケットを1つのソースから維持し、他のソースからパケットを破棄できます。もちろん、RFC 3550 SSRC衝突検出および処理手順にも従わなければなりません。
Second, there may be cases where a malfunctioning source is sending corrupt packets that cannot be decrypted and verified. In this case, the SSRC will never be entered into the mapping table because the decryption and verification always fails. Receivers MAY keep records of unmapped SSRCs that consistently fail decryption and verification and abandon attempts to process them once they reach some limit. That limit MUST be large enough to account for the effects of transmission errors. Entries MUST be pruned from this table when the relevant SRTP endpoint is deleted (e.g., the call ends) and SHOULD time out faster than that (we do not offer a hard recommendation but 10 to 30 seconds seems appropriate) in order to allow for the possibility that the peer implementation has been corrected.
第二に、誤動作しているソースが、復号化されて検証できない破損したパケットを送信している場合があります。この場合、復号化と検証が常に失敗するため、SSRCはマッピングテーブルに入力されることはありません。受信者は、復号化と検証に一貫して失敗し、制限に達したら処理する試みを放棄するマップされていないSSRCの記録を保持する場合があります。その制限は、送信エラーの影響を説明するのに十分な大きさでなければなりません。関連するsrtpエンドポイントが削除されている場合（コールエンドなど）、エントリは、それよりも速くタイムアウトする必要があります（ハード推奨は提供されませんが、10〜30秒が適切と思われます）。ピアの実装が修正された可能性。
Rekeying in DTLS is accomplished by performing a new handshake over the existing DTLS channel. That is, the handshake messages are protected by the existing DTLS cipher suite. This handshake can be performed in parallel with data transport, so no interruption of the data flow is required. Once the handshake is finished, the newly derived set of keys is used to protect all outbound packets, both DTLS and SRTP.
DTLSでの再キーイングは、既存のDTLSチャネルで新しい握手を実行することで達成されます。つまり、握手メッセージは既存のDTLS暗号スイートによって保護されています。この握手は、データトランスポートと並行して実行できるため、データフローの中断は必要ありません。握手が終了すると、新しく導き出されたキーのセットを使用して、DTLとSRTPの両方のすべてのアウトバウンドパケットを保護します。
Because of packet reordering, packets protected by the previous set of keys can appear on the wire after the handshake has completed. To compensate for this fact, receivers SHOULD maintain both sets of keys for some time in order to be able to decrypt and verify older packets. The keys should be maintained for the duration of the maximum segment lifetime (MSL).
パケットの並べ替えにより、握手が完了した後、以前のキーセットによって保護されたパケットがワイヤーに表示される可能性があります。この事実を補うために、レシーバーは、古いパケットを復号化して検証できるように、しばらくの間、両方のキーセットを維持する必要があります。キーは、最大セグメント寿命（MSL）の期間中に維持する必要があります。
If an MKI is used, then the receiver should use the corresponding set of keys to process an incoming packet. If no matching MKI is present, the packet MUST be rejected. Otherwise, when a packet arrives after the handshake completed, a receiver SHOULD use the newly derived set of keys to process that packet unless there is an MKI. (If the packet was protected with the older set of keys, this fact will become apparent to the receiver as an authentication failure will occur.) If the authentication check on the packet fails and no MKI is being used, then the receiver MAY process the packet with the older set of keys. If that authentication check indicates that the packet is valid, the packet should be accepted; otherwise, the packet MUST be discarded and rejected.
MKIを使用する場合、レシーバーは対応するキーのセットを使用して、着信パケットを処理する必要があります。一致するMKIが存在しない場合、パケットを拒否する必要があります。それ以外の場合、握手が完了した後にパケットが到着したとき、受信者は、MKIがない限り、新しく派生したキーのセットを使用してそのパケットを処理する必要があります。（パケットが古いキーセットで保護されている場合、この事実は認証障害が発生すると受信機に明らかになります。）パケットの認証チェックが失敗し、MKIが使用されない場合、受信機は処理できます。古いキーセットのパケット。その認証チェックがパケットが有効であることを示している場合、パケットを受け入れる必要があります。それ以外の場合、パケットを破棄して拒否する必要があります。
Receivers MAY use the SRTP packet sequence number to aid in the selection of keys. After a packet has been received and authenticated with the new key set, any packets with sequence numbers that are greater will also have been protected with the new key set.
受信機は、SRTPパケットシーケンス番号を使用して、キーの選択を支援できます。新しいキーセットでパケットを受信し、認証された後、シーケンス番号が大きいパケットは、新しいキーセットでも保護されます。
Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only to protect unicast RTP sessions. This does not preclude its use with RTP mixers. For example, a conference bridge may use DTLS-SRTP to secure the communication to and from each of the participants in a conference. However, because each flow between an endpoint and a mixer has its own key, the mixer has to decrypt and then reencrypt the traffic for each recipient.
DTLSはポイントツーポイントプロトコルであるため、DTLS-SRTPはユニキャストRTPセッションのみを保護することを目的としています。これは、RTPミキサーでの使用を妨げるものではありません。たとえば、会議ブリッジはDTLS-SRTPを使用して、会議の各参加者との間の通信を確保することができます。ただし、エンドポイントとミキサーの間の各フローには独自のキーがあるため、ミキサーは各受信者のトラフィックを復号化してから再クリップする必要があります。
A future specification may describe methods for sharing a single key between multiple DTLS-SRTP associations thus allowing conferencing systems to avoid the decrypt/reencrypt stage. However, any system in which the media is modified (e.g., for level balancing or transcoding) will generally need to be performed on the plaintext and will certainly break the authentication tag, and therefore will require a decrypt/reencrypt stage.
将来の仕様では、複数のDTLS-SRTP関連の間で単一のキーを共有する方法を説明する場合があります。これにより、会議システムが復号化/再クリップステージを回避できるようになります。ただし、メディアが変更されたシステム（たとえば、レベルバランスやトランスコーディングなど）は、一般にプレーンテキストで実行する必要があり、認証タグを確実に破壊するため、復号化/再クリップステージが必要になります。
The use of multiple data protection framings negotiated in the same handshake creates some complexities, which are discussed here.
同じ握手で交渉された複数のデータ保護フレーミングの使用は、ここで説明する複雑さを生み出します。
One concern here is that attackers might be able to implement a bid-down attack forcing the peers to use ordinary DTLS rather than SRTP. However, because the negotiation of this extension is performed in the DTLS handshake, it is protected by the Finished messages. Therefore, any bid-down attack is automatically detected, which reduces this to a denial-of-service attack -- which can be mounted by any attacker who can control the channel.
ここでの懸念の1つは、攻撃者がSRTPではなく通常のDTLを使用するようにピアを強制する入札攻撃を実装できる可能性があることです。ただし、この拡張機能の交渉はDTLSハンドシェイクで実行されるため、完成したメッセージによって保護されます。したがって、入札ダウン攻撃は自動的に検出され、これをサービス拒否攻撃に減らします。これは、チャネルを制御できる攻撃者が取り付けることができます。
Because two different framing formats are used, there is concern that an attacker could convince the receiver to treat an SRTP-framed RTP packet as a DTLS record (e.g., a handshake message) or vice versa. This attack is prevented by using different keys for Message Authentication Code (MAC) verification for each type of data. Therefore, this type of attack reduces to being able to forge a packet with a valid MAC, which violates a basic security invariant of both DTLS and SRTP.
2つの異なるフレーミング形式が使用されるため、攻撃者が受信者にSRTPフレームのRTPパケットをDTLSレコード（ハンドシェイクメッセージなど）または逆として扱うよう説得できるという懸念があります。この攻撃は、各タイプのデータに対してメッセージ認証コード（MAC）検証に異なるキーを使用することにより防止されます。したがって、このタイプの攻撃により、有効なMACでパケットを鍛造できるようになり、DTLとSRTPの両方の基本的なセキュリティ不変型に違反します。
As an additional defense against injection into the DTLS handshake channel, the DTLS record type is included in the MAC. Therefore, an SRTP record would be treated as an unknown type and ignored. (See Section 6 of [RFC5246].)
DTLSハンドシェイクチャネルへの注入に対する追加の防御として、DTLSレコードタイプはMACに含まれています。したがって、SRTPレコードは未知のタイプとして扱われ、無視されます。（[RFC5246]のセクション6を参照してください。）
As described in Section 5.1.1, the SRTP and DTLS sequence number spaces are distinct. This means that it is not possible to unambiguously order a given DTLS control record with respect to an SRTP packet. In general, this is relevant in two situations: alerts and rehandshake.
セクション5.1.1で説明されているように、SRTPおよびDTLSシーケンス番号スペースは異なります。これは、SRTPパケットに関して特定のDTLS制御レコードを明確に注文することができないことを意味します。一般に、これは2つの状況で関連しています：アラートと再ハンドシェイク。
Because DTLS handshake and change_cipher_spec messages share the same sequence number space as alerts, they can be ordered correctly. Because DTLS alerts are inherently unreliable and SHOULD NOT be generated as a response to data packets, reliable sequencing between SRTP packets and DTLS alerts is not an important feature. However, implementations that wish to use DTLS alerts to signal problems with the SRTP encoding SHOULD simply act on alerts as soon as they are received and assume that they refer to the temporally contiguous stream. Such implementations MUST check for alert retransmission and discard retransmitted alerts to avoid overreacting to replay attacks.
dtlsハンドシェイクとchange_cipher_specメッセージは、アラートと同じシーケンス番号容量を共有するため、正しく順序付けることができます。DTLSアラートは本質的に信頼できず、データパケットへの応答として生成されるべきではないため、SRTPパケットとDTLSアラート間の信頼できるシーケンスは重要な機能ではありません。ただし、DTLSアラートを使用してSRTPエンコードの問題を示す実装は、受信したらすぐにアラートに作用し、一時的に連続したストリームを参照すると仮定する必要があります。このような実装は、アラートの再送信をチェックし、攻撃を再生するための過剰反応を避けるために、再送信されたアラートを破棄する必要があります。
Because the rehandshake transition algorithm specified in Section 5.2 requires trying multiple sets of keys if no MKI is used, it slightly weakens the authentication. For instance, if an n-bit MAC is used and k different sets of keys are present, then the MAC is weakened by log_2(k) bits to n - log_2(k). In practice, since the number of keys used will be very small and the MACs in use are typically strong (the default for SRTP is 80 bits), the decrease in security involved here is minimal.
セクション5.2で指定された再ハンドシェイク遷移アルゴリズムでは、MKIが使用されない場合に複数のキーセットを試す必要があるため、認証がわずかに弱まります。たとえば、NビットMACが使用され、K異なるキーセットが存在する場合、MACはlog_2（k）ビットによってn -log_2（k）に弱まります。実際には、使用されるキーの数は非常に小さく、使用中のMacは通常強いため（SRTPのデフォルトは80ビットです）、ここに関係するセキュリティの減少は最小限です。
Another concern here is that this algorithm slightly increases the work factor on the receiver because it needs to attempt multiple validations. However, again, the number of potential keys will be very small (and the attacker cannot force it to be larger) and this technique is already used for rollover counter management, so the authors do not consider this to be a serious flaw.
ここでのもう1つの懸念は、このアルゴリズムが複数の検証を試みる必要があるため、受信機の作業要因をわずかに増加させることです。ただし、繰り返しますが、潜在的なキーの数は非常に少なくなり（攻撃者はそれを強制することはできません）、この手法はすでにロールオーバーカウンター管理に使用されているため、著者はこれを深刻な欠陥とは考えていません。
An attacker can impose computational costs on the receiver by sending superficially valid SRTP packets that do not decrypt correctly. In general, encryption algorithms are so fast that this cost is extremely small compared to the bandwidth consumed. The SSRC-DTLS mapping algorithm described in Section 5.1.2 gives the attacker a slight advantage here because he can force the receiver to do more then one decryption per packet. However, this advantage is modest because the number of decryptions that the receiver does is limited by the number of associations he has corresponding to a given destination host/port, which is typically quite small. For comparison, a single 1024-bit RSA private key operation (the typical minimum cost to establish a DTLS-SRTP association) is hundreds of times as expensive as decrypting an SRTP packet.
攻撃者は、正確に復号化されない表面的に有効なSRTPパケットを送信することにより、受信機に計算コストを課すことができます。一般に、暗号化アルゴリズムは非常に速いため、このコストは消費される帯域幅と比較して非常に少ないです。セクション5.1.2で説明したSSRC-DTLSマッピングアルゴリズムは、パケットごとに1つ以上の復号化を受信者に強制することができるため、ここで攻撃者にわずかな利点を与えます。ただし、この利点は控えめです。これは、受信者が行う復号の数は、特定の宛先ホスト/ポートに対応する関連付けの数によって制限されるため、通常は非常に少ないためです。比較のために、単一の1024ビットRSA秘密キー操作（DTLS-SRTPアソシエーションを確立するための一般的な最低コスト）は、SRTPパケットを復号化する数百倍高価です。
Implementations can detect this form of attack by keeping track of the number of SRTP packets that are observed with unknown SSRCs and that fail the authentication tag check. If under such attack, implementations SHOULD prioritize decryption and verification of packets that either have known SSRCs or come from source addresses that match those of peers with which it has DTLS-SRTP associations.
実装は、未知のSSRCで観察され、認証タグチェックに失敗するSRTPパケットの数を追跡することにより、この形式の攻撃を検出できます。そのような攻撃の下で、実装は、SSRCを知っているか、DTLS-SRTP関連を持っているピアのアドレスと一致するソースアドレスから来るパケットの復号化と検証に優先順位を付ける必要があります。
This specification defines new tokens to describe the protocol used in SDP media descriptions ("m=" lines and their associated parameters). The new values defined for the proto field are:
この仕様では、SDPメディアの説明で使用されるプロトコル（ "m ="行と関連するパラメーター）を説明する新しいトークンを定義します。Protoフィールドで定義された新しい値は次のとおりです。
o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over DTLS with the Datagram Congestion Control Protocol (DCCP), then the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF respectively.
o RTP/SAVPまたはRTP/SAVPF [RFC5124]ストリームがDATAGRAMの混雑制御プロトコル（DCCP）を使用してDTLSを介して輸送される場合、トークンはDCCP/TLS/RTP/SAVPまたはDCCP/TLS/RTP/SAVPFでなければなりません。
o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF respectively.
o RTP/SAVPまたはRTP/SAVPFストリームがUDPを使用してDTLSを介して輸送される場合、トークンはそれぞれUDP/TLS/RTP/SAVPまたはUDP/TLS/RTP/SAVPFでなければなりません。
The "fmt" parameter SHALL be as defined for RTP/SAVP.
「FMT」パラメーターは、RTP/SAVPに対して定義されています。
See [RFC5763] for how to use offer/answer with DTLS-SRTP.
[RFC5763]を参照してください。DTLS-SRTPを使用してオファー/回答を使用する方法。
This document does not specify how to protect RTP data transported over TCP. Potential approaches include carrying the RTP over TLS over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that in this document over TCP, either via TLS or DTLS, with DTLS being used for consistency between reliable and unreliable transports. In the latter case, it would be necessary to profile DTLS so that fragmentation and retransmissions no longer occurred. In either case, a new document would be required.
このドキュメントでは、TCPを介して輸送されたRTPデータを保護する方法を指定していません。潜在的なアプローチには、TCPを介してTLSを介してRTPを運ぶ（[srtp-not-mand]を参照）、またはTCPを介したこのドキュメントのメカニズムを使用して、TLSまたはDTLSを介して、信頼性の高いトランスポートと信頼性の低い輸送間の一貫性に使用されるメカニズムを使用することが含まれます。。後者の場合、断片化と再送信が発生しなくなるようにDTLをプロファイルする必要があります。どちらの場合でも、新しいドキュメントが必要になります。
This document adds a new extension for DTLS, in accordance with
[RFC5246]:
enum { use_srtp (14) } ExtensionType;
This extension MUST only be used with DTLS, and not with TLS [RFC4572], which specifies that TLS can be used over TCP but does not address TCP for RTP/SAVP.
この拡張機能は、TLS [RFC4572]ではなくDTLSでのみ使用する必要があります。これは、TLSをTCPで使用できるが、RTP/SAVPのTCPに対処しないことを指定しています。
Section 4.1.2 requires that all SRTPProtectionProfile values be defined by RFC 5226 "Specification Required". IANA has created a DTLS SRTPProtectionProfile registry initially populated with values from Section 4.1.2 of this document. Future values MUST be allocated via the "Specification Required" profile of [RFC5226].
セクション4.1.2では、すべてのsrtpprotectionprofile値をRFC 5226「必要な仕様」で定義する必要があります。IANAは、最初にこのドキュメントのセクション4.1.2から値を入力したDTLS SRTPPROTECTIONPROFILEレジストリを作成しました。将来の値は、[RFC5226]の「必要な仕様」プロファイルを介して割り当てる必要があります。
This specification updates the "Session Description Protocol (SDP) Parameters" registry as defined in Section 8.2.2 of [RFC4566]. Specifically, it adds the following values to the table for the "proto" field.
この仕様は、[RFC4566]のセクション8.2.2で定義されている「セッション説明プロトコル（SDP）パラメーター」レジストリを更新します。具体的には、「プロト」フィールドのテーブルに次の値を追加します。
Type SDP Name Reference
---- ------------------ ---------
proto UDP/TLS/RTP/SAVP [RFC5764]
proto DCCP/TLS/RTP/SAVP [RFC5764]
proto UDP/TLS/RTP/SAVPF [RFC5764]
proto DCCP/TLS/RTP/SAVPF [RFC5764]
IANA has registered the "EXTRACTOR-dtls_srtp" value in the TLS Extractor Label Registry to correspond to this specification.
IANAは、この仕様に対応するために、TLS抽出ラベルレジストリに「Extractor-DTLS_SRTP」値を登録しています。
Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen, Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing, and Ben Campbell for input, discussions, and guidance. Pasi Eronen provided Figure 1.
フレミング・アンドレアセン、フランソワ・オーデット、パシ・エロネン、ロニ・イヴ・イ・イ・イ・イ・イ・イ・イ・イヴー、カレン・ジェニングス、コリン・パーキンス、ダン・ウィング、ベン・キャンベルに意見、討論、ガイダンスに感謝します。Pasi Eronenは図1に記載されています。
[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月。
[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月。
[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月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961] Wing、D。、「対称RTP / RTP制御プロトコル（RTCP）」、BCP 131、RFC 4961、2007年7月。
[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月。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[RFC5705] Rescorla、E。、「輸送層のセキュリティのためのキーキーリングマテリアル輸出業者（TLS）」、RFC 5705、2010年3月。
[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月。
[DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security version 1.2", Work in Progress, October 2009.
[DTLS1.2] Rescorla、E。およびN. Modadugu、「Datagram Transport Lay Securityバージョン1.2」、2009年10月の作業。
[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月。
[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月。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5124] OTT、J。およびE. Carrara、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック（RTP/SAVPF）のセキュアーRTPプロファイル拡張」、RFC 5124、2008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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月。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763] Fischl、J.、Tschofenig、H.、およびE. Rescorla、「データグラム輸送層セキュリティ（DTLS）を使用した安全なリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、2010年5月。
[SRTP-NOT-MAND] Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a Single Security Mechanism", Work in Progress, January 2010.
[srtp-not-mand] Perkins、C。and M. Westerlund、「RTPが単一のセキュリティメカニズムを義務付けていない理由」、2010年1月の進行中。
This section provides a brief overview of Datagram TLS (DTLS) for those who are not familiar with it. DTLS is a channel security protocol based on the well-known Transport Layer Security (TLS) [RFC5246] protocol. Where TLS depends on a reliable transport channel (typically TCP), DTLS has been adapted to support unreliable transports such as UDP. Otherwise, DTLS is nearly identical to TLS and generally supports the same cryptographic mechanisms.
このセクションでは、慣れていない人向けのDatagram TLS（DTLS）の概要を説明します。DTLSは、よく知られている輸送層セキュリティ（TLS）[RFC5246]プロトコルに基づくチャネルセキュリティプロトコルです。TLSが信頼できる輸送チャネル（通常はTCP）に依存している場合、DTLSはUDPなどの信頼できない輸送をサポートするように適合しています。それ以外の場合、DTLはTLSとほぼ同じであり、一般に同じ暗号化メカニズムをサポートします。
Each DTLS association begins with a handshake exchange (shown below) during which the peers authenticate each other and negotiate algorithms, modes, and other parameters and establish shared keying material, as shown below. In order to support unreliable transport, each side maintains retransmission timers to provide reliable delivery of these messages. Once the handshake is completed, encrypted data may be sent.
各DTLS協会は、以下に示すように、ピアが互いに認証し、アルゴリズム、モード、およびその他のパラメーターを交渉し、共有キーイング材料を確立する握手交換（以下を参照）から始まります。信頼できない輸送をサポートするために、両側は再送信タイマーを維持して、これらのメッセージの信頼できる配信を提供します。握手が完了すると、暗号化されたデータが送信される場合があります。
Client Server
クライアントサーバー
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
'*' indicates messages that are not always sent.
'*'は、常に送信されていないメッセージを示します。
Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]).
図5：基本的なDTLSハンドシェイク交換（[RFC4347]後）。
Application data is protected by being sent as a series of DTLS "records". These records are independent and can be processed correctly even in the face of loss or reordering. In DTLS-SRTP, this record protocol is replaced with SRTP [RFC3711]
アプリケーションデータは、一連のDTLS「レコード」として送信されることにより保護されます。これらのレコードは独立しており、損失や並べ替えに直面しても正しく処理できます。DTLS-SRTPでは、このレコードプロトコルはSRTP [RFC3711]に置き換えられます
Standard practice for security protocols such as TLS, DTLS, and SSH, which do inline key management, is to create a separate security association for each underlying network channel (TCP connection, UDP host/port quartet, etc.). This has dual advantages of simplicity and independence of the security contexts for each channel.
インラインキー管理を行うTLS、DTLS、SSHなどのセキュリティプロトコルの標準的な実践は、基礎となる各ネットワークチャネル（TCP接続、UDPホスト/ポートカルテットなど）の個別のセキュリティ関連を作成することです。これには、各チャネルのセキュリティコンテキストのシンプルさと独立性の二重の利点があります。
Three concerns have been raised about the overhead of this strategy in the context of RTP security. The first concern is the additional performance overhead of doing a separate public key operation for each channel. The conventional procedure here (used in TLS and DTLS) is to establish a master context that can then be used to derive fresh traffic keys for new associations. In TLS/DTLS, this is called "session resumption" and can be transparently negotiated between the peers.
RTPセキュリティのコンテキストで、この戦略のオーバーヘッドについて3つの懸念が提起されています。最初の懸念は、各チャネルに対して個別の公開キー操作を行うことの追加のパフォーマンスオーバーヘッドです。ここでの従来の手順（TLSおよびDTLSで使用）は、マスターコンテキストを確立することで、新しい関連性のための新しいトラフィックキーを導き出すために使用できます。TLS/DTLSでは、これは「セッション再開」と呼ばれ、ピア間で透過的に交渉できます。
The second concern is network bandwidth overhead for the establishment of subsequent connections and for rehandshake (for rekeying) for existing connections. In particular, there is a concern that the channels will have very narrow capacity requirements allocated entirely to media that will be overflowed by the rehandshake. Measurements of the size of the rehandshake (with resumption) in TLS indicate that it is about 300-400 bytes if a full selection of cipher suites is offered. (The size of a full handshake is approximately 1-2 kilobytes larger because of the certificate and keying material exchange.)
2番目の懸念は、後続の接続の確立および既存の接続の再ハンドシェイク（再キーイングのために）のためのネットワーク帯域幅オーバーヘッドです。特に、チャネルが非常に狭い容量要件をメディアに完全に割り当てる懸念があり、それは再ハンドシェイクによってオーバーフローされるでしょう。TLSの再ハンドシェイクのサイズ（再開付き）の測定は、暗号スイートの完全な選択が提供されている場合、約300〜400バイトであることを示しています。（完全な握手のサイズは、証明書とキーイングマテリアル交換のために約1〜2キロバイトが大きいです。）
The third concern is the additional round-trips associated with
establishing the second, third, ... channels. In TLS/DTLS, these can
all be done in parallel, but in order to take advantage of session
resumption they should be done after the first channel is
established. For two channels, this provides a ladder diagram
something like this (parenthetical numbers are media channel numbers)
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
<- ClientHello (2)
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
Figure 6: Parallel DTLS-SRTP negotiations.
図6：並列DTLS-SRTP交渉。
So, there is an additional 1 RTT (round-trip time) after Channel 1 is
ready before Channel 2 is ready. If the peers are potentially
willing to forego resumption, they can interlace the handshakes, like
so:
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
<- ClientHello (2)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
Figure 7: Interlaced DTLS-SRTP negotiations.
図7：Interlaced DTLS-SRTP交渉。
In this case, the channels are ready contemporaneously, but if a message in handshake (1) is lost, then handshake (2) requires either a full rehandshake or that Alice be clever and queue the resumption attempt until the first handshake completes. Note that just dropping the packet works as well, since Bob will retransmit.
この場合、チャンネルは同時に準備ができていますが、ハンドシェイク（1）のメッセージが失われた場合、ハンドシェイク（2）は完全なハンドシェイクを必要とするか、アリスが賢く、最初のハンドシェイクが完了するまで再開の試みを行います。ボブが再送信されるため、パケットをドロップするだけでも機能することに注意してください。
Authors' Addresses
著者のアドレス
David McGrew Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95305 USA
David McGrew Cisco Systems 510 McCarthy Blvd.Milpitas、CA 95305 USA
EMail: mcgrew@cisco.com
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