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)
セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張
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.
この文書では、Secure RTP（SRTP）およびSecure RTP制御プロトコル（SRTCP）が流れるためのキーを確立するために、データグラムトランスポート層セキュリティ（DTLS）の拡張について説明します。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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.
セキュア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.
データグラムトランスポート層セキュリティ（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.
この文書では、DTLS、SRTP、DTLS統合キーおよび関連管理の柔軟性と利便性SRTPの性能と暗号化の柔軟性の利点を兼ね備えDTLSためのSRTP拡張を説明しています。 SRTPのための新たな鍵管理方式として、及びDTLSのための新たなRTP固有のデータフォーマット：DTLS-SRTPは、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
DTLS拡張子がSRTPアルゴリズムを交渉するために使用されるO、及び
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操作の概要を説明します。第5節で議論し、どのようRTPとRTCPは、DTLS、SRTPチャネルを介して輸送される間、第4節では、DTLSの拡張子を指定します。第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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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人の参加者がありその中で、ポイントツーポイントメディアセッションのために定義されています。または1つのSRTPコンテキスト（メディアトラフィックは両方とも同じホスト/ポートカルテット上方向に流れている場合）、各DTLS-SRTPセッションは、メディア場合（（TLS用語の「接続」と呼ばれる）は、単一のDTLSアソシエーションを含み、いずれか2つの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セッションは、RTPポートのための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]は逆に、その送信元ポートと宛先ポートとアドレスを有する2つのRTPセッションがTCP接続がそのポートを使用する方法と同様に、ある場合です。各参加者は、インバウンド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セッションを介して送信されてもよいです。これは、DTLSの暗号化性能を改善するが、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アイデンティティ保護が使用されている）である場合は、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アソシエーションが確立され、その接続が彼らの握手を進める前に確立されるまで、他のすべてのDTLS団体は待つ：最適化として、DTLS、SRTPの実装には、次の戦略を使用すべきです。この戦略は、後のセッションが複数のDTLSハンドシェイクを超える高価な公開鍵暗号操作の償却を可能にDTLSセッションの再開を、使用することができます。
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実装はセクションで説明したように同じチャネル上に同じデバイスから発信RTPソースのすべての同期ソースのすべて（SSRC）値「は、2つのタイムパッド」問題を（避けるために、異なっていることを確認しなければなりません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データ保護の使用を交渉するためには、クライアントは、クライアントのhelloを拡張DTLSで「use_srtp」タイプの拡張子を含めます。データが搬送されるとき、この拡張にのみ使用されなければならないRTPまたはRTCP [RFC3550]です。以下に示すように、この拡張機能の「拡大」フィールドは、許容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」拡張を含む拡張こんにちはを受け取るサーバーは、拡張されたサーバーハローで選ばれたプロテクションプロファイルで、「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.
「*」は常にDTLSで送信されないメッセージを示すことに注意してください。 CertificateRequest、クライアントとサーバ証明書、およびCertificateVerifyは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記録層「application_data」パケットで送信されることはありません。むしろ、完全なRTPまたはRTCPパケットは、それらを適切に保護しSRTPスタック、に渡すDTLSスタックに渡されます。 RTP / RTCP多重[RFC5761]が使用されている場合、これはRTPとRTCPパケットが両方DTLSスタックに渡されてもよいことを意味することに留意されたいです。 DTLS層がパケットを処理しないので、それはそれらを区別する必要はありません。 SRTPスタックは、RTCPからRTPを区別するために、[RFC5761]の手順を使用することができます。
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は、本質的にパケットごとにペイロードに向いているが、これは明確化のために純粋に記述されているので、これは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ハンドシェイクは、一つ以上のSRTP暗号コンテキストを確立します。いずれの場合しかし、それらはすべて、同じSRTPプロテクションプロファイルとマスターキー識別子（MKI）を持っています。 MKIs起因リキーに、例えば、別個のハンドシェイクの間のキーイング材料と保護プロファイルを区別するためにのみ使用されます。 MKIがDTLS-SRTPセッションで確立されると、そのセッション内SSRCsの全てに適用しなければならない - シングルエンドポイントはフォークに、例えば、による複数DTLS-SRTPセッションを交渉するかもしれません。 （そのRFC 3711は、同じセッション内で異なるSSRCs有するパケットが異なるMKIsを使用することを可能に注意してください。対照的に、DTLS-SRTPはMKIs、それらが関連付けられているキーは、同一の意味を有し、全体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」拡張子の拡フィールドを埋める必要があります（登録のセクション9を参照してください）：
uint8 SRTPProtectionProfile[2];
UINT8 SRTPProtectionProfile [2]。
struct {
SRTPProtectionProfiles SRTPProtectionProfiles;
opaque srtp_mki<0..255>;
} UseSRTPData;
SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;
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）値を（もしあれば）が含まれています。このフィールドの長さが0であれば、何も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エクステンション受け入れる意志があるならば、それはExtendedServerHelloで、独自の「use_srtp」拡張子で応じなければなりません。拡フィールドは、サーバーがこの接続で使用するために選択した単一SRTPProtectionProfile値とUseSRTPData値を含まなければなりません。サーバーは、クライアントが提供されていない値を選択してはなりません。何も共有プロファイルがない場合、サーバは接続が戻って交渉さDTLS暗号スイートにフォールその時点で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
SRTP_AES128_CM_HMAC_SHA1_80暗号：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暗号：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暗号：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
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暗号：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
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
TLS擬似ランダム関数（PRF）O 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.
鍵導出レート（KDR）Oはゼロに等しいです。このように、キーが再由来SRTPシーケンス番号に基づいていません。
o The key derivation procedures from Section 4.3 with the AES-CM PRF from RFC 3711 are used.
RFC 3711からAES-CM PRFと第4.3節から鍵導出手続きoを使用しています。
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.
RTPフローとRTPとRTCPは、一般的に多重されていないような場合に関連したRTCPフローを（保護DTLS-SRTPセッションを保護DTLS-SRTPセッション間SRTPプロテクションプロファイルを調整すべきであるDTLS-SRTPを使用するアプリケーション港）。具体的には、同一の暗号が使用されるべきです。
New SRTPProtectionProfile values must be defined according to the "Specification Required" policy as defined by RFC 5226 [RFC5226]. See Section 9 for IANA Considerations.
RFC 5226 [RFC5226]で定義されている新SRTPProtectionProfile値は「仕様が必要である」というポリシーに応じて定義する必要があります。 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セッションは、任意の時点でパケットを保護するために使用される正確に一つのマスターキーを持たなければなりません。それが使用された最後の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.それはMKIを利用するであろうことを示すためにその「use_srtp」拡張子で一致「srtp_mki」値、または2リターンがMKIを使用することができないことを示すために空の「srtp_mki」値を含みます。
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（もしあれば）を有していることに留意されたいです。したがって、任意の時点で、エンドポイントのセットは、一般的に一つだけMKIを（主要な例外はrehandshakes中にある）を使用します。
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」です。 （「EXTRACTOR」接頭辞は、歴史的互換性のためです。）
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鍵導出メカニズムへの入力として提供されます。別の鍵導出メカニズムを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鍵導出関数の呼び出しに設けられています。クライアントは解読すると、着信パケットの正当性をチェックするためにこれらのキーを使用しなければなりません。
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両方のキーが必要です。そうでない場合には、RTPパケットと一つがRTCPパケットを保護する保護一方が2つのDTLS-SRTPセッションがあります。各DTLS-SRTPセッションはSSRCsがそのペアで使用される独立したそのうち、図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）及び使用されるトランスポート・アドレスとキーを示す（2）RTCPを保護する別のものを、保護DTLS-SRTPセッション。
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実装は、受信機は、彼らがキーを欠くためにパケットを廃棄するために必要性を回避するために、キーの再生成中の複数の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.
DTLSハンドシェイクが完了する前に、各RTPセッション内では、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 / DTLSでは、すべてのデータが同じレコード符号化および機構を使用して保護されています。本書で説明されたメカニズムが有効な場合DTLSの上位プロトコルクライアントによって書き込まれたデータをRTP / RTPおよびSRTPはなく、標準的なTLSレコード・エンコーディングを使用して暗号化されることを想定しているように、これが修正されます。
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パケットを送信したい場合には、通常のアプリケーションデータ書き込みとしてDTLS実装に渡す（例えば、SSL_write（））。 DTLS実装は、その後RFC 3711で説明した処理を起動し、セクション3,4得SRTPパケットは、その後、無DTLSフレーミングを有する単一のデータグラムとしてワイヤ上に直接送られます。これは、に準拠し、SRTPと相互運用データのカプセル化を提供します。 RTPシーケンス番号ではなくDTLSシーケンス番号がこれらのパケットのために使用されることに留意されたいです。
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ポートに到着したパケットを分離する必要があります。到着するパケットは、タイプのものであってもよいRTP、DTLS、またはSTUN [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の場合、パケットがSTUNです。値が128と191（両端を含む）の間にある場合（RTCPとRTPの両方が同一の宛先ポート上で多重化されている場合、または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受信機のパケット分離アルゴリズム。ここでは、フィールド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.
他のパケットタイプも同様に多重化されている場合、実装および/または設計者は、彼らはこれら三つのパケットタイプから多重分離することができることを確認する必要があります。
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に示すように、SIPは、ボブとチャーリーの両方が、彼女はそれらの両方に同じローカルホスト/ポートのペアを使用するためにフォーク状で呼び出しを行う場合。 （図示SSRCsアリスに流れるデータのためのものです。）
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によって識別されます。したがって、いくつかのメカニズムが関連をDTLSにどの対応するSSRCs決定するのに必要とされます。以下の方法を使用する必要があります。
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の実装は、すべてのそれは知っているSSRCsとそれらが対応DTLS-SRTP団体の一覧表を維持します。最初は、このテーブルは空です。 SRTPパケットが所与のRTPエンドポイント（宛先IP /ポートのペア）のために受信される場合、以下の手順が使用されます。
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アソシエーションとキーイングマテリアルは、パケットを復号化し、検証するために使用されます。 SSRCが知られていない場合は2、受信機は、そのエンドポイントの各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は、マップテーブルに置かれているとすぐに見えたので、このコストは、のみ、任意のSSRCのために一回発生しています。通常のRTPと同様に、このアルゴリズムは、新しいSSRCsはいつでもソースによって導入することができます。彼らは、自動的に正しい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.
このアルゴリズムは、明示的に複数のSSRCsが同じアドレス/ポートのペアから送信されることを可能にすることに注意してください。これが起こることができる1つの方法は、RTPトランスレータです。このアルゴリズムは、自動的に正しい団体にSSRCsを割り当てます。 SRTPパケットが暗号で保護されているため、そのような翻訳者がいずれかの共有一方のエンドポイントで材料をキーイングや整合性チェックが失敗する原因となるように、パケットを変更控える必要があることに注意してください。これは、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
考慮すべき2つのエラーケースがあります。 SSRC衝突が発生した場合、まず、最初のソースからのパケットだけが処理されます。第2のソースからのパケットが到着したとき、第一源とDTLSの関連付けは失敗し、復号及び検証のために使用され、パケットは破棄されます。これが可能に[RFC3550]と一致しています
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.
受信機は、一つのソースからのパケットを維持し、他からそれらを廃棄します。もちろん、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は、マッピングテーブルに入力されることはありません。レシーバは一貫して解読と検証を失敗し、彼らはいくつかの限界に達するとそれらを処理しようとする試みを放棄マッピングされていないSSRCsの記録を保持してもよいです。その制限は、伝送エラーの影響を考慮するのに十分な大きさでなければなりません。エントリーは、（適切なようだ、我々はハード勧告を提供していませんが、10〜30秒）関連SRTPエンドポイントが削除された（例えば、通話の終了）と高速よりもタイムアウトになる必要があるときに、この表からプルーニングされなければならないために可能にするためにピアの実装が修正されている可能性。
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暗号スイートによって保護されています。このハンドシェークは、データ転送と並行して行うことができるので、データの流れが中断が必要とされません。ハンドシェイクが完了すると、キーの新たな派生するセットは、すべてのアウトバウンドパケット、DTLSおよび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.
ここで一つの懸念は、攻撃者が通常のDTLSではなく、SRTPを使用するようにピアを強制的に入札ダウン攻撃を実装することができるかもしれないということです。この拡張機能のネゴシエーションがDTLSハンドシェイクで行われているのでしかし、それはFinishedメッセージによって保護されています。チャネルを制御することができる任意の攻撃者によって装着することができる - 従って、任意のビッドダウン攻撃を自動的にサービス拒否攻撃にこれを低減する、検出されます。
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.
二つの異なるフレーミングフォーマットが使用されるので、攻撃者がDTLSレコード（例えば、ハンドシェイクメッセージ）またはその逆としてSRTP-フレームRTPパケットを処理するために受信機を納得させる可能性が懸念されます。この攻撃は、メッセージ認証コード（MAC）データの種類ごとに検証するための異なる鍵を使用することによって防止されます。したがって、この種の攻撃は、DTLSとSRTPの両方の基本的なセキュリティ不変に違反し、有効なMAC、とのパケットを偽造することができることに帰着します。
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アラートの間に信頼性の高い配列決定は重要な機能ではありません。しかし、SRTPエンコーディングで問題を知らせるためにDTLSアラートを使用したいの実装は単に、すぐにそれらが受信されると、アラートに作用し、それらが一時的に連続したストリームを参照することを前提とすべきです。このような実装は、アラート再送信のためにチェックして、リプレイ攻撃するために過剰反応を避けるために再送されたアラートを捨てなければなりません。
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.
何MKIが使用されていない場合は、セクション5.2で指定された再ハンドシェイク遷移アルゴリズムは、キーの複数のセットをしようとして必要なので、それがわずか認証を弱めます。 log_2（K） - nビットMACを使用し、キーのk個の異なるセットが存在している場合、例えば、その後、MACは、nにlog_2（K）ビットで弱められます。実際には、（SRTPのデフォルトは80ビットである）使用するキーの数が非常に小さくなり、使用中のMACが一般的に強いているので、ここでは関係するセキュリティの低下は最小限です。
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.
ここでもう一つの懸念は、それが複数の検証を試みる必要があるため、このアルゴリズムは、わずかに受信機に仕事率を増加させることです。しかし、再び、潜在的なキーの数が非常に小さくなります（と攻撃者が大きくなるためにそれを強制することはできません）と、この技術はすでにロールオーバーカウンタ管理のために使用されているので、著者らは、これは重大な欠陥であることを考慮していません。
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パケットを送信することにより、受信機の計算コストを課すことができます。一般的には、暗号化アルゴリズムは、このコストが消費する帯域幅に比べて非常に小さいことを非常に高速です。彼は、パケットごとにもっとして1つの復号化を行うために受信機を強制することができますので、セクション5.1.2で説明したSSRC-DTLSマッピングアルゴリズムは、ここでは、攻撃者はわずかな利点を提供します。受信機が行うデクリプションの数が、彼は一般的に非常に小さい特定の宛先ホスト/ポートに対応している団体の数によって制限されているのでしかし、この利点は控えめです。比較のために、単一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.
実装は、未知のSSRCsで観察し、それが認証タグチェックに失敗しているSRTPパケットの数を追跡することにより、この形式の攻撃を検出することができます。そのような攻撃を受けている場合、実装はどちらかがSSRCsを知られているか、それは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.
RTP / SAVP又はRTP / SAVPF [RFC5124]のストリームがデータグラム輻輳制御プロトコル（DCCP）とDTLS上に搬送されると、O、次いでトークンは、それぞれ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.
RTP / SAVP又はRTP / SAVPFストリームはUDPとDTLS上に搬送されると、O、トークンは、それぞれUDP / TLS / RTP / SAVP又はUDP / TLS / RTP / SAVPFでなければなりません。
The "fmt" parameter SHALL be as defined for RTP/SAVP.
RTP / SAVPのために定義された「FMT」パラメータがされなければなりません。
See [RFC5763] for how to use offer/answer with DTLS-SRTP.
DTLS-SRTPとオファー/アンサーを使用する方法については、[RFC5763]を参照してください。
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を介して、DTLSは、信頼性が高く、信頼性の低いトランスポートとの間の一貫性を保つために使用されていると共に含みます。後者の場合には、フラグメンテーションと再送信がもはや発生するようにDTLSプロファイルないことが必要であろう。いずれの場合も、新しい文書が必要とされるであろう。
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.
この拡張はDTLSではなく、TLSはTCP上で使用することができますが、RTP / SAVPのためのTCPに対処していないことを指定するTLS [RFC4572]、一緒に使用しなければなりません。
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]
プロトUDP / TLS / RTP / SAVPF [RFC5764]プロト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.
入力、ディスカッション、指導のためのフレミングAndreasenの、フランソワAudet、パシEronen、ロニでも、ジェイソンFischl、カレン・ジェニングス、コリンパーキンス、ダン・ウィング、そしてベン・キャンベルに感謝します。パシEronen、図1を提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]ウイング、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[RFC5705]レスコラ、E.、RFC 5705 "トランスポート層セキュリティ（TLS）のための鍵材料輸出"、2010年3月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]パーキンス、C.とM.ウェスター、 "シングルポートの多重化RTPデータおよび制御パケット"、RFC 5761、2010年4月。
[DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security version 1.2", Work in Progress, October 2009.
[DTLS1.2]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティバージョン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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]レノックス、J.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（TLS）プロトコルを介してメディアトランスポート"、RFC 4572、2006年7月。
[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]オット、J.およびE.カララ、 "リアルタイムトランスポート制御プロトコル（RTCP）にSecure RTPプロファイルを拡張 - ベースのフィードバック（RTP / SAVPF）"、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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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.レスコラ、RFC 5763、2010年5月 "セキュアリアルタイム転送プロトコル（SRTP）データグラムトランスポート層セキュリティ（DTLS）を使用して、セキュリティコンテキストを確立するためのフレームワーク"。
[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]パーキンス、C.とM.ウェスター、進歩、2010年1月の作業、 "なぜ、RTPは、単一のセキュリティメカニズムを強制しません"。
Appendix A. Overview of DTLS
DTLSの付録A.概要
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.
このセクションでは、それに慣れていない人のためのデータグラムTLS（DTLS）の概要を説明します。 DTLSは、よく知られているトランスポート層セキュリティ（TLS）[RFC5246]プロトコルに基づいて、チャネルセキュリティプロトコルです。 TLSは、信頼性の高いトランスポートチャネル（通常はTCP）に依存する場合、DTLSはUDPなどの信頼性の低いトランスポートをサポートするようになってきました。それ以外の場合は、DTLSは、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]で置換されています
Appendix B. Performance of Multiple DTLS Handshakes
複数のDTLS握手の付録B.パフォーマンス
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セキュリティのコンテキストでこの戦略のオーバーヘッドについて提起されています。最初の懸念は、各チャンネルごとに独立した公開鍵の操作を行うための追加のパフォーマンス・オーバーヘッドです。 （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.)
第二の懸念は、後続の接続の確立のために、既存の接続のために（キー更新のために）再ハンドシェイクのためにネットワーク帯域幅のオーバーヘッドです。具体的には、チャネルは再ハンドシェイクであふれたされるメディアに完全に割り当てられた非常に狭い容量要件を持つことが懸念されます。 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)
第三の懸念は、第二、第三、...のチャネルを確立するに関連する追加のラウンドトリップです。 TLS / DTLSでは、これらはすべて並列に行うことができますが、最初のチャネルが確立された後にセッションの再開を利用するために彼らが行うべきです。二つのチャンネルのために、これは、このようなラダー図の何かを（括弧内の数字は、メディアチャンネル番号である）を提供します
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のforhandlinger。
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:
だから、チャンネル1の後に追加の1 RTT（ラウンドトリップ時間）があっチャンネル2の準備が整う前に準備されています。ピアが潜在的に再開を見送るために喜んでいる場合は、彼らのようなので、握手をインターレースすることができます：
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：インターレースDTLS-SRTPのforhandlinger。
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
デビッドマグリューシスコシステムズ510マッカーシーブルバードミルピタス、CA 95305 USA
EMail: mcgrew@cisco.com
メールアドレス：mcgrew@cisco.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
エリックレスコラRTFM、Inc.の2064エッジウッドドライブパロアルト、CA 94303 USA
EMail: ekr@rtfm.com
メールアドレス：ekr@rtfm.com