[要約] RFC 8723は、Secure Real-Time Transport Protocol (SRTP) における二重暗号化手順に関する文書です。このRFCの目的は、SRTPのセキュリティを強化するために、メディアパス上でのデータの二重暗号化を可能にする手順を定義することにあります。これは、特にセンシティブな通信を保護するために、既存のSRTP実装に追加のセキュリティレイヤーを提供します。利用場面としては、高度なセキュリティが求められるビデオ会議やVoIP通信などが挙げられます。関連するRFCには、SRTPを定義するRFC 3711や、その他のセキュリティ拡張を提供するRFCが含まれます。
Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 8723 P. Jones
Category: Standards Track R. Barnes
ISSN: 2070-1721 Cisco Systems
A.B. Roach
Mozilla
April 2020
Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
Secure Real-Time Transport Protocol（SRTP）の二重暗号化手順
Abstract
概要
In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.
一部の会議シナリオでは、中間者がリアルタイムトランスポートプロトコル（RTP）パケットの一部のパラメーターを操作しながら、強力なエンドツーエンドのセキュリティを保証できることが望ましいです。このドキュメントでは、ホップバイホップおよびエンドツーエンドのセキュリティ保証を提供するために、2つの独立しているが関連する暗号化操作を使用するSecure Real-time Transport Protocol（SRTP）の暗号化トランスフォームを定義します。エンドツーエンドとホップバイホップの両方の暗号化アルゴリズムは、認証済み暗号化と関連データ（AEAD）アルゴリズムを利用したり、異なるプロパティを持つ将来のSRTP変換を利用したりできます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8723.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8723で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよび文書の作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 2. Terminology 3. Cryptographic Context 3.1. Key Derivation 4. Original Header Block 5. RTP Operations 5.1. Encrypting a Packet 5.2. Relaying a Packet 5.3. Decrypting a Packet 6. RTCP Operations 7. Use with Other RTP Mechanisms 7.1. RTP Retransmission (RTX) 7.2. Redundant Audio Data (RED) 7.3. Forward Error Correction (FEC) 7.4. DTMF 8. Recommended Inner and Outer Cryptographic Algorithms 9. Security Considerations 10. IANA Considerations 10.1. DTLS-SRTP 11. References 11.1. Normative References 11.2. Informative References Appendix A. Encryption Overview Acknowledgments Authors' Addresses
1. はじめに2.用語3.暗号コンテキスト3.1。キーの導出4.元のヘッダーブロック5. RTP操作5.1。パケットの暗号化5.2。パケットの中継5.3。パケットの復号化6. RTCP操作7.他のRTPメカニズムとの使用7.1。 RTP再送信（RTX）7.2。冗長音声データ（RED）7.3。前方誤り訂正（FEC）7.4。 DTMF 8.推奨される内部および外部暗号化アルゴリズム9.セキュリティに関する考慮事項10. IANAに関する考慮事項10.1 DTLS-SRTP 11.リファレンス11.1規範的な参考資料11.2。参考資料付録A.暗号化の概要謝辞著者のアドレス
Cloud conferencing systems that are based on switched conferencing have a central Media Distributor (MD) device that receives media from endpoints and distributes it to other endpoints, but does not need to interpret or change the media content. For these systems, it is desirable to have one cryptographic key that enables encryption and authentication of the media end-to-end while still allowing certain information in the header of an RTP packet to be changed by the MD. At the same time, a separate cryptographic key provides integrity and optional confidentiality for the media flowing between the MD and the endpoints. The framework document [PRIVATE-MEDIA-FRAMEWORK] describes this concept in more detail.
スイッチドコンファレンシングに基づくクラウド会議システムには、エンドポイントからメディアを受信して他のエンドポイントに配信する中央メディアディストリビューター（MD）デバイスがありますが、メディアコンテンツを解釈または変更する必要はありません。これらのシステムでは、RTPパケットのヘッダー内の特定の情報をMDが変更できるようにしながら、エンドツーエンドでメディアの暗号化と認証を可能にする1つの暗号化キーが望ましいです。同時に、別の暗号化キーにより、MDとエンドポイント間を流れるメディアの整合性とオプションの機密性が提供されます。フレームワークドキュメント[PRIVATE-MEDIA-FRAMEWORK]は、この概念をより詳細に説明しています。
This specification defines a transform for SRTP that uses 1) the AES Galois/Counter Mode (AES-GCM) algorithm [RFC7714] to provide encryption and integrity for an RTP packet for the end-to-end cryptographic key and 2) a hop-by-hop cryptographic encryption and integrity between the endpoint and the MD. The MD decrypts and checks integrity of the hop-by-hop security. The MD MAY change some of the RTP header information that would impact the end-to-end integrity. In that case, the original value of any RTP header field that is changed is included in an "Original Header Block" that is added to the packet. The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent. The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the MD changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity.
この仕様では、1）エンドツーエンドの暗号化キー用のRTPパケットに暗号化と整合性を提供するAES Galois / Counter Mode（AES-GCM）アルゴリズム[RFC7714]を使用するSRTPのトランスフォームを定義し、2）ホップエンドポイントとMD間のホップごとの暗号化暗号化と整合性。 MDは、ホップバイホップセキュリティの完全性を復号化してチェックします。 MDは、エンドツーエンドの整合性に影響を与えるRTPヘッダー情報の一部を変更する場合があります。その場合、変更されたRTPヘッダーフィールドの元の値は、パケットに追加される「元のヘッダーブロック」に含まれます。新しいRTPパケットは、送信される前にホップバイホップ暗号アルゴリズムで暗号化されます。受信エンドポイントは、ホップバイホップ暗号化アルゴリズムを使用して整合性を復号化およびチェックし、エンドツーエンドの整合性を復号化およびチェックする前に、元のヘッダーブロックの情報を使用してMDが変更したパラメーターを置き換えます。
One can think of the double transform as a normal SRTP transform for encrypting the RTP in a way such that things that only know half of the key, can decrypt and modify part of the RTP packet but not other parts, including the media payload.
ダブルトランスフォームは、RTPを暗号化するための通常のSRTPトランスフォームと考えることができます。これにより、キーの半分しかわからないものは、RTPパケットの一部を復号化および変更できますが、メディアペイロードを含む他の部分は復号化できません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Terms used throughout this document include:
このドキュメント全体で使用される用語は次のとおりです。
Media Distributor (MD): A device that receives media from endpoints and distributes it to other endpoints, but does not need to interpret or change the media content (see also [PRIVATE-MEDIA-FRAMEWORK]).
メディアディストリビューター（MD）：エンドポイントからメディアを受信して他のエンドポイントに配信するが、メディアコンテンツを解釈または変更する必要がないデバイス（[PRIVATE-MEDIA-FRAMEWORK]も参照）。
end-to-end: The path from one endpoint through one or more MDs to the endpoint at the other end.
エンドツーエンド：1つのエンドポイントから1つ以上のMDを経由して、もう一方のエンドポイントに至るパス。
hop-by-hop: The path from the endpoint to or from the MD.
ホップバイホップ：エンドポイントからMDへ、またはMDからのパス。
Original Header Block (OHB): An octet string that contains the original values from the RTP header that might have been changed by an MD.
Original Header Block（OHB）：MDによって変更された可能性があるRTPヘッダーからの元の値を含むオクテット文字列。
This specification uses a cryptographic context with two parts:
この仕様では、2つの部分からなる暗号化コンテキストを使用します。
* An inner (end-to-end) part that is used by endpoints that originate and consume media to ensure the integrity of media end-to-end, and
* メディアのエンドツーエンドの整合性を確保するためにメディアを生成および消費するエンドポイントによって使用される内部（エンドツーエンド）パーツ。
* An outer (hop-by-hop) part that is used between endpoints and MDs to ensure the integrity of media over a single hop and to enable an MD to modify certain RTP header fields. RTCP is also handled using the hop-by-hop cryptographic part.
* エンドポイントとMDの間で使用される外側（ホップバイホップ）の部分。単一のホップでメディアの整合性を確保し、MDが特定のRTPヘッダーフィールドを変更できるようにします。 RTCPも、ホップバイホップの暗号部分を使用して処理されます。
The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithms is AES-GCM. Other combinations of SRTP ciphers that support the procedures in this document can be added to the IANA registry.
ホップバイホップおよびエンドツーエンドのアルゴリズムに推奨される暗号は、AES-GCMです。このドキュメントの手順をサポートするSRTP暗号の他の組み合わせをIANAレジストリに追加できます。
The keys and salt for these algorithms are generated with the following steps:
これらのアルゴリズムのキーとソルトは、次の手順で生成されます。
* Generate key and salt values of the length required for the combined inner (end-to-end) and outer (hop-by-hop) algorithms.
* 組み合わせた内部（エンドツーエンド）アルゴリズムと外部（ホップバイホップ）アルゴリズムに必要な長さのキーとソルト値を生成します。
* Assign the key and salt values generated for the inner (end-to-end) algorithm to the first half of the key and the first half of the salt for the double algorithm.
* 内部（エンドツーエンド）アルゴリズム用に生成されたキーとソルトの値を、キーの前半とダブルアルゴリズムのソルトの前半に割り当てます。
* Assign the key and salt values for the outer (hop-by-hop) algorithm to the second half of the key and second half of the salt for the double algorithm. The first half of the key is referred to as the inner key while the second half is referred to as the outer key. When a key is used by a cryptographic algorithm, the salt that is used is the part of the salt generated with that key.
* 外部（ホップバイホップ）アルゴリズムのキーとソルトの値を、キーの後半とダブルアルゴリズムのソルトの後半に割り当てます。キーの前半は内部キーと呼ばれ、後半は外部キーと呼ばれます。暗号化アルゴリズムによってキーが使用される場合、使用されるソルトは、そのキーで生成されるソルトの一部です。
* the synchronization source (SSRC) is the same for both the inner and outer algorithms as it cannot be changed.
* 同期ソース（SSRC）は変更できないため、内部アルゴリズムと外部アルゴリズムの両方で同じです。
* The sequence number (SEQ) and rollover counter (ROC) are tracked independently for the inner and outer algorithms.
* シーケンス番号（SEQ）とロールオーバーカウンター（ROC）は、内部アルゴリズムと外部アルゴリズムで個別に追跡されます。
If the MD is to be able to modify header fields but not decrypt the payload, then it must have a cryptographic key for the outer algorithm but not the inner (end-to-end) algorithm. This document does not define how the MD should be provisioned with this information. One possible way to provide keying material for the outer (hop-by-hop) algorithm is to use [DTLS-TUNNEL].
MDがヘッダーフィールドを変更できるがペイロードを復号化できない場合、MDは外部アルゴリズム用の暗号化キーを持っている必要がありますが、内部（エンドツーエンド）アルゴリズムは持っていません。このドキュメントでは、この情報を使用してMDをプロビジョニングする方法を定義していません。外部（ホップバイホップ）アルゴリズムのキー情報を提供する1つの可能な方法は、[DTLS-TUNNEL]を使用することです。
Although SRTP uses a single master key to derive keys for an SRTP session, this transform requires separate inner and outer keys. In order to allow the inner and outer keys to be managed independently via the master key, the transforms defined in this document MUST be used with the following pseudorandom function (PRF), which preserves the separation between the two halves of the key. Given a positive integer "n" representing the desired output length, a master key "k_master", and an input "x":
SRTPは単一のマスターキーを使用してSRTPセッションのキーを導出しますが、このトランスフォームでは個別の内部キーと外部キーが必要です。内部キーと外部キーをマスターキーを介して個別に管理できるようにするには、このドキュメントで定義されている変換を、キーの2つの半分の間の分離を維持する次の疑似ランダム関数（PRF）と共に使用する必要があります。必要な出力長を表す正の整数「n」、マスターキー「k_master」、および入力「x」を指定します。
PRF_double_n(k_master,x) = PRF_(n/2)(inner(k_master),x) ||
PRF_(n/2)(outer(k_master),x)
Here "PRF_double_n(k_master, x)" represents the AES_CM PRF Key Derivation Function (KDF) (see Section 4.3.3 of [RFC3711]) for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm. The term "inner(k_master)" represents the first half of the key; "outer(k_master)" represents the second half of the key.
ここで、「PRF_double_n（k_master、x）」は、DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCMアルゴリズムの場合はAES_CM PRFキー導出関数（KDF）（[RFC3711]のセクション4.3.3を参照）を表し、DOUBLEの場合はAES_256_CM_PRF KDF [RF_A_ES_A_ES_CM_ES_G_G_AD_G_A_G_G_A_G_G_A_G_G_G_A_G_G_G_A_G_G_G_G_G_A_G_G_G_G_G_A_G_G_G_A_G_A_G_G_A_G_G_G_A_G_G_G_G_A_G_G_A_G_G_G_A_G_G_A_G_G_G_G_G_G 「inner（k_master）」という用語は、キーの前半を表します。 「outer（k_master）」はキーの後半を表します。
The OHB contains the original values of any modified RTP header fields. In the encryption process, the OHB is included in an SRTP packet as described in Section 5. In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header so that it can pass the proper additional authenticated data (AAD) value to the inner transform.
OHBには、変更されたRTPヘッダーフィールドの元の値が含まれています。セクション5で説明されているように、暗号化プロセスでは、OHBはSRTPパケットに含まれています。復号化プロセスでは、受信エンドポイントがOHBを使用して元のRTPヘッダーを再構築し、適切な追加認証データ（AAD）値を内部変換。
The OHB can reflect modifications to the following fields in an RTP header: the payload type (PT), the SEQ, and the marker bit. All other fields in the RTP header MUST remain unmodified; since the OHB cannot reflect their original values, the receiver will be unable to verify the end-to-end integrity of the packet.
OHBは、RTPヘッダーの次のフィールドへの変更を反映できます。ペイロードタイプ（PT）、SEQ、およびマーカービット。 RTPヘッダー内の他のすべてのフィールドは変更しないでください。 OHBは元の値を反映できないため、受信側はパケットのエンドツーエンドの整合性を確認できません。
The OHB has the following syntax (in ABNF [RFC5234]):
OHBの構文は次のとおりです（ABNF [RFC5234]）：
OCTET = %x00-FF
PT = OCTET
SEQ = 2OCTET
Config = OCTET
OHB = [ PT ] [ SEQ ] Config
If present, the PT and SEQ parts of the OHB contain the original payload type and sequence number fields, respectively. The final "Config" octet of the OHB specifies whether these fields are present, and the original value of the marker bit (if necessary):
存在する場合、OHBのPT部分とSEQ部分には、それぞれ元のペイロードタイプとシーケンス番号フィールドが含まれます。 OHBの最後の「Config」オクテットは、これらのフィールドが存在するかどうか、およびマーカービットの元の値（必要な場合）を指定します。
+-+-+-+-+-+-+-+-+
|R R R R B M P Q|
+-+-+-+-+-+-+-+-+
* P: PT is present
* P：PTが存在します
* Q: SEQ is present
* Q：SEQが存在します
* M: Marker bit is present
* M：マーカービットが存在する
* B: Value of marker bit
* B：マーカービットの値
* R: Reserved, MUST be set to 0
* R：予約済み、0に設定する必要があります
In particular, an all-zero OHB Config octet ("0x00") indicates that there have been no modifications from the original header.
特に、すべてゼロのOHB構成オクテット（ "0x00"）は、元のヘッダーからの変更がないことを示します。
If the marker bit is not present (M=0), then "B" MUST be set to zero. That is, if "C" represents the value of the Config octet, then the masked value "C & 0x0C" MUST NOT have the value "0x80".
マーカービットが存在しない場合（M = 0）、「B」はゼロに設定する必要があります。つまり、「C」が構成オクテットの値を表す場合、マスクされた値「C＆0x0C」は値「0x80」を持っていてはなりません。
As implied by the use of the word "double" above, this transform applies AES-GCM to the SRTP packet twice. This allows media distributors to be able to modify some header fields while allowing endpoints to verify the end-to-end integrity of a packet.
上記の「double」という単語の使用からわかるように、この変換では、AES-GCMをSRTPパケットに2回適用します。これにより、メディアディストリビューターは、一部のヘッダーフィールドを変更しながら、エンドポイントがパケットのエンドツーエンドの整合性を確認できるようになります。
The first, "inner" application of AES-GCM encrypts the SRTP payload and protects the integrity of a version of the SRTP header with extensions truncated. Omitting extensions from the inner integrity check means that they can be modified by an MD holding only the outer key.
AES-GCMの最初の「内部」アプリケーションは、SRTPペイロードを暗号化し、拡張子が切り捨てられたバージョンのSRTPヘッダーの整合性を保護します。内部整合性チェックから拡張機能を省略した場合、外部キーのみを保持するMDで拡張機能を変更できます。
The second, "outer" application of AES-GCM encrypts the ciphertext produced by the inner encryption (i.e., the encrypted payload and authentication tag), plus an OHB that expresses any changes made between the inner and outer transforms.
AES-GCMの2番目の「外部」アプリケーションは、内部暗号化（つまり、暗号化されたペイロードと認証タグ）によって生成された暗号文と、内部変換と外部変換の間で行われた変更を表すOHBを暗号化します。
An MD that has the outer key but not the inner key may modify the header fields that can be included in the OHB by decrypting, modifying, and re-encrypting the packet.
外部キーはあるが内部キーはないMDは、パケットを復号化、変更、および再暗号化することにより、OHBに含めることができるヘッダーフィールドを変更できます。
An endpoint encrypts a packet by using the inner (end-to-end) cryptographic key and then the outer (hop-by-hop) cryptographic key. The encryption also supports a mode for repair packets that only does the outer (hop-by-hop) encryption. The processes is as follows:
エンドポイントは、内部（エンドツーエンド）暗号化キーを使用してから、外部（ホップバイホップ）暗号化キーを使用してパケットを暗号化します。暗号化は、外部（ホップバイホップ）暗号化のみを行う修復パケットのモードもサポートします。プロセスは次のとおりです。
1. Form an RTP packet. If there are any header extensions, they MUST use [RFC8285].
1. RTPパケットを形成します。ヘッダー拡張がある場合は、[RFC8285]を使用する必要があります。
2. If the packet is for repair mode data, skip to step 6.
2. パケットが修復モードデータ用である場合は、手順6に進みます。
3. Form a synthetic RTP packet with the following contents:
3. 次の内容で合成RTPパケットを形成します。
* Header: The RTP header of the original packet with the following modifications:
* ヘッダー：次の変更を加えた元のパケットのRTPヘッダー：
- The X bit is set to zero.
- Xビットはゼロに設定されます。
- The header is truncated to remove any extensions (i.e., keep only the first 12 + 4 * CSRC count (CC) bytes of the header).
- ヘッダーは、拡張を削除するために切り捨てられます（つまり、ヘッダーの最初の12 + 4 * CSRCカウント（CC）バイトのみを保持します）。
* Payload: The RTP payload of the original packet (including padding when present).
* ペイロード：元のパケットのRTPペイロード（存在する場合はパディングを含む）。
4. Apply the inner cryptographic algorithm to the synthetic RTP packet from the previous step.
4. 前のステップの合成RTPパケットに内部暗号化アルゴリズムを適用します。
5. Replace the header of the protected RTP packet with the header of the original packet (to restore any header extensions and reset the X bit), and append an empty OHB ("0x00") to the encrypted payload (with the authentication tag) obtained from step 4.
5. 保護されたRTPパケットのヘッダーを元のパケットのヘッダーに置き換え（ヘッダー拡張を復元してXビットをリセットするため）、から取得した暗号化されたペイロード（認証タグ付き）に空のOHB（ "0x00"）を追加します。ステップ4。
6. Apply the outer cryptographic algorithm to the RTP packet. If encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST be used when encrypting the RTP packet using the outer cryptographic key.
6. 外部暗号アルゴリズムをRTPパケットに適用します。 RTPヘッダー拡張をホップバイホップで暗号化する場合は、外部暗号化キーを使用してRTPパケットを暗号化するときに[RFC6904]を使用する必要があります。
When using Encrypted Key Transport (EKT) [EKT-SRTP], the EKTField comes after the SRTP packet, exactly like using EKT with any other SRTP transform.
暗号化キー転送（EKT）[EKT-SRTP]を使用する場合、EKTFieldは、他のSRTPトランスフォームでEKTを使用するのとまったく同じように、SRTPパケットの後に続きます。
The MD has the part of the key for the outer (hop-by-hop) cryptographic algorithm, but it does not have the part of the key for the inner (end-to-end) cryptographic algorithm. The cryptographic algorithm and key used to decrypt a packet and any encrypted RTP header extensions would be the same as those used in the endpoint's outer algorithm and key.
MDには、外部（ホップバイホップ）暗号アルゴリズムの鍵の一部がありますが、内部（エンドツーエンド）暗号アルゴリズムの鍵の一部はありません。パケットの復号化に使用される暗号化アルゴリズムとキー、および暗号化されたRTPヘッダー拡張は、エンドポイントの外部アルゴリズムとキーで使用されるものと同じです。
In order to modify a packet, the MD decrypts the received packet, modifies the packet, updates the OHB with any modifications not already present in the OHB, and re-encrypts the packet using the outer (hop-by-hop) cryptographic key before transmitting using the following steps:
パケットを変更するために、MDは受信したパケットを復号化し、パケットを変更し、OHBにまだ存在しない変更でOHBを更新し、外部（ホップバイホップ）暗号化キーを使用してパケットを再暗号化します。次の手順を使用して送信します。
1. Apply the outer (hop-by-hop) cryptographic algorithm to decrypt the packet. If decrypting RTP header extensions hop-by-hop, then [RFC6904] MUST be used. Note that the RTP payload produced by this decryption operation contains the original encrypted payload with the tag from the inner transform and the OHB appended.
1. 外部（ホップバイホップ）暗号化アルゴリズムを適用して、パケットを復号化します。 RTPヘッダー拡張をホップバイホップで復号化する場合は、[RFC6904]を使用する必要があります。この復号化操作によって生成されたRTPペイロードには、内部変換のタグとOHBが付加された元の暗号化されたペイロードが含まれていることに注意してください。
2. Make any desired changes to the fields that are allowed to be changed, i.e., PT, SEQ, and M. The MD MAY also make modifications to header extensions, without the need to reflect these changes in the OHB.
2. 変更が許可されているフィールド（PT、SEQ、Mなど）に必要な変更を加えます。MDは、OHBにこれらの変更を反映する必要なく、ヘッダー拡張に変更を加えることもできます（MAY）。
3. Reflect any changes to header fields in the OHB:
3. OHBのヘッダーフィールドへの変更を反映します。
* If the MD changed a field that is not already in the OHB, then it MUST add the original value of the field to the OHB. Note that this might result in an increase in the size of the OHB.
* MDがまだOHBにないフィールドを変更した場合、フィールドの元の値をOHBに追加する必要があります。これにより、OHBのサイズが大きくなる可能性があることに注意してください。
* If the MD took a field that had previously been modified and reset to its original value, then it SHOULD drop the corresponding information from the OHB. Note that this might result in a decrease in the size of the OHB.
* MDが以前に変更されて元の値にリセットされたフィールドを取得した場合、対応する情報をOHBから削除する必要があります（SHOULD）。これにより、OHBのサイズが減少する可能性があることに注意してください。
* Otherwise, the MD MUST NOT modify the OHB.
* それ以外の場合、MDはOHBを変更してはなりません。
4. Apply the outer (hop-by-hop) cryptographic algorithm to the packet. If the RTP sequence number has been modified, SRTP processing happens as defined in SRTP and will end up using the new sequence number. If encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST be used.
4. 外部（ホップバイホップ）暗号化アルゴリズムをパケットに適用します。 RTPシーケンス番号が変更されている場合、SRTPの定義に従ってSRTP処理が行われ、最終的に新しいシーケンス番号を使用します。 RTPヘッダー拡張をホップバイホップで暗号化する場合は、[RFC6904]を使用する必要があります。
In order to avoid nonce reuse, the cryptographic contexts used in steps 1 and 4 MUST use different, independent master keys. Note that this means that the key used for decryption by the MD MUST be different from the key used for re-encryption to the end recipient.
ナンスの再利用を回避するために、ステップ1と4で使用される暗号化コンテキストは、異なる独立したマスターキーを使用する必要があります。これは、MDによる復号化に使用される鍵は、最終受信者への再暗号化に使用される鍵とは異なる必要があることを意味することに注意してください。
Note that if multiple MDs modify the same packet, then the first MD to alter a given header field is the one that adds it to the OHB. If a subsequent MD changes the value of a header field that has already been changed, then the original value will already be in the OHB, so no update to the OHB is required.
複数のMDが同じパケットを変更する場合、特定のヘッダーフィールドを変更する最初のMDは、それをOHBに追加するMDであることに注意してください。後続のMDがすでに変更されているヘッダーフィールドの値を変更する場合、元の値はすでにOHBにあるため、OHBの更新は必要ありません。
An MD that decrypts, modifies, and re-encrypts packets in this way MUST use an independent key for each recipient, and MUST NOT re-encrypt the packet using the sender's keys. If the MD decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of AES-GCM.
この方法でパケットを復号化、変更、再暗号化するMDは、受信者ごとに独立したキーを使用する必要があり、送信者のキーを使用してパケットを再暗号化してはなりません。 MDが同じキーとソルトで復号化および再暗号化すると、（キー、ノンス）ペアが再利用され、AES-GCMのセキュリティが損なわれます。
To decrypt a packet, the endpoint first decrypts and verifies using the outer (hop-by-hop) cryptographic key, then uses the OHB to reconstruct the original packet, which it decrypts and verifies with the inner (end-to-end) cryptographic key using the following steps:
パケットを復号化するために、エンドポイントは最初に外部（ホップバイホップ）暗号化キーを使用して復号化および検証し、次にOHBを使用して元のパケットを再構築し、それを復号化して内部（エンドツーエンド）暗号化で検証します次の手順を使用してキー：
1. Apply the outer cryptographic algorithm to the packet. If the integrity check does not pass, discard the packet. The result of this is referred to as the outer SRTP packet. If decrypting RTP header extensions hop-by-hop, then [RFC6904] MUST be used when decrypting the RTP packet using the outer cryptographic key.
1. パケットに外部暗号化アルゴリズムを適用します。整合性チェックに合格しない場合は、パケットを破棄します。この結果は、外部SRTPパケットと呼ばれます。 RTPヘッダー拡張をホップバイホップで復号化する場合は、外部暗号化キーを使用してRTPパケットを復号化するときに[RFC6904]を使用する必要があります。
2. If the packet is for repair mode data, skip the rest of the steps. Note that the packet that results from the repair algorithm will still have encrypted data that needs to be decrypted as specified by the repair algorithm sections.
2. パケットが修復モードデータ用である場合は、残りの手順をスキップします。修復アルゴリズムの結果であるパケットには、修復アルゴリズムのセクションで指定されているように復号化する必要がある暗号化されたデータが含まれていることに注意してください。
3. Remove the inner authentication tag and the OHB from the end of the payload of the outer SRTP packet.
3. 外部SRTPパケットのペイロードの最後から内部認証タグとOHBを削除します。
4. Form a new synthetic SRTP packet with:
4. 次のコマンドで新しい合成SRTPパケットを作成します。
* Header = Received header, with the following modifications:
* ヘッダー=次の変更を加えた受信ヘッダー：
- Header fields replaced with values from OHB (if any).
- ヘッダーフィールドは、OHBの値（存在する場合）に置き換えられます。
- The X bit is set to zero.
- Xビットはゼロに設定されます。
- The header is truncated to remove any extensions (i.e., keep only the first 12 + 4 * CC bytes of the header).
- ヘッダーは切り捨てられて拡張子が削除されます（つまり、ヘッダーの最初の12 + 4 * CCバイトのみを保持します）。
* Payload is the encrypted payload from the outer SRTP packet (after the inner tag and OHB have been stripped).
* ペイロードは、外部SRTPパケットからの暗号化されたペイロードです（内部タグとOHBが取り除かれた後）。
* Authentication tag is the inner authentication tag from the outer SRTP packet.
* 認証タグは、外部SRTPパケットからの内部認証タグです。
5. Apply the inner cryptographic algorithm to this synthetic SRTP packet. Note if the RTP sequence number was changed by the MD, the synthetic packet has the original sequence number. If the integrity check does not pass, discard the packet.
5. この合成SRTPパケットに内部暗号化アルゴリズムを適用します。 RTPシーケンス番号がMDによって変更された場合、合成パケットには元のシーケンス番号が含まれます。整合性チェックに合格しない場合は、パケットを破棄します。
Once the packet has been successfully decrypted, the application needs to be careful about which information it uses to get the correct behavior. The application MUST use only the information found in the synthetic SRTP packet and MUST NOT use the other data that was in the outer SRTP packet with the following exceptions:
パケットが正常に復号化されると、アプリケーションは、正しい動作を得るために使用する情報に注意する必要があります。アプリケーションは、合成SRTPパケットで見つかった情報のみを使用する必要があり、次の例外を除いて、外部SRTPパケットにあった他のデータを使用してはなりません（MUST NOT）。
* The PT from the outer SRTP packet is used for normal matching to Session Description Protocol (SDP) and codec selection.
* 外部SRTPパケットからのPTは、セッション記述プロトコル（SDP）とコーデックの通常の照合に使用されます。
* The sequence number from the outer SRTP packet is used for normal RTP ordering.
* 外部SRTPパケットからのシーケンス番号は、通常のRTP順序付けに使用されます。
The PT and sequence number from the inner SRTP packet can be used for collection of various statistics.
内部SRTPパケットからのPTおよびシーケンス番号は、さまざまな統計の収集に使用できます。
If the RTP header of the outer packet contains extensions, they MAY be used. However, because extensions are not protected end-to-end, implementations SHOULD reject an RTP packet containing headers that would require end-to-end protection.
外部パケットのRTPヘッダーに拡張が含まれている場合、それらが使用される場合があります。ただし、拡張機能はエンドツーエンドで保護されていないため、実装はエンドツーエンドの保護を必要とするヘッダーを含むRTPパケットを拒否する必要があります（SHOULD）。
Unlike RTP, which is encrypted both hop-by-hop and end-to-end using two separate cryptographic keys, RTCP is encrypted using only the outer (hop-by-hop) cryptographic key. The procedures for RTCP encryption are specified in [RFC3711], and this document introduces no additional steps.
2つの個別の暗号化キーを使用してホップバイホップとエンドツーエンドの両方で暗号化されるRTPとは異なり、RTCPは外部（ホップバイホップ）暗号化キーのみを使用して暗号化されます。 RTCP暗号化の手順は[RFC3711]で指定されており、このドキュメントでは追加の手順を紹介していません。
MDs sometimes interact with RTP media packets sent by endpoints, e.g., to provide recovery or receive commands via dual-tone multi-frequency (DTMF) signaling. When media packets are encrypted end-to-end, these procedures require modification. (End-to-end interactions, including end-to-end recovery, are not affected by end-to-end encryption.)
MDは、エンドポイントから送信されたRTPメディアパケットとやり取りして、たとえば、デュアルトーンマルチ周波数（DTMF）シグナリングを介してリカバリコマンドや受信コマンドを提供することがあります。メディアパケットがエンドツーエンドで暗号化される場合、これらの手順を変更する必要があります。 （エンドツーエンドのリカバリーを含むエンドツーエンドの相互作用は、エンドツーエンドの暗号化の影響を受けません。）
Repair mechanisms, in general, will need to perform recovery on encrypted packets (double-encrypted when using this transform), since the MD does not have access to the plaintext of the packet, only an intermediate, E2E-encrypted form.
MDはパケットのプレーンテキストにアクセスできず、中間のE2E暗号化フォームのみにアクセスできるため、一般に、修復メカニズムは暗号化されたパケット（この変換を使用する場合は二重暗号化）でリカバリを実行する必要があります。
When the recovery mechanism calls for the recovery packet itself to be encrypted, it is encrypted with only the outer, hop-by-hop key. This allows an MD to generate recovery packets without having access to the inner, end-to-end keys. However, it also results in recovery packets being triple-encrypted, twice for the base transform, and once for the recovery protection.
回復メカニズムが回復パケット自体の暗号化を要求する場合、外部のホップバイホップキーのみで暗号化されます。これにより、MDは内部のエンドツーエンドキーにアクセスせずに回復パケットを生成できます。ただし、その結果、リカバリパケットはトリプル暗号化され、ベーストランスフォームには2回、リカバリ保護には1回になります。
When using RTX [RFC4588] with the double transform, the cached payloads MUST be the double-encrypted packets, i.e., the bits that are sent over the wire to the other side. When encrypting a retransmission packet, it MUST be encrypted like a packet in repair mode (i.e., with only the hop-by-hop key).
RTX [RFC4588]を二重変換で使用する場合、キャッシュされたペイロードは、二重に暗号化されたパケット、つまり、回線を介して相手側に送信されるビットである必要があります。再送信パケットを暗号化するときは、修復モードのパケットのように（つまり、ホップバイホップキーのみで）暗号化する必要があります。
If the MD were to cache the inner, E2E-encrypted payload and retransmit it with an RTX original sequence number field prepended, then the modifications to the payload would cause the inner integrity check to fail at the receiver.
MDが内部のE2Eで暗号化されたペイロードをキャッシュし、RTXの元のシーケンス番号フィールドを前に付けて再送信する場合、ペイロードを変更すると、受信側で内部の整合性チェックが失敗します。
A typical RTX receiver would decrypt the packet, undo the RTX transformation, then process the resulting packet normally by using the steps in Section 5.3.
一般的なRTX受信機は、パケットを復号化し、RTX変換を元に戻し、セクション5.3の手順を使用して、通常、結果のパケットを処理します。
When using RED [RFC2198] with the double transform, the processing at the sender and receiver is the same as when using RED with any other SRTP transform.
RED [RFC2198]を二重変換とともに使用する場合、送信側と受信側での処理は、REDを他のSRTP変換とともに使用する場合と同じです。
The main difference between the double transform and any other transform is that in an intermediated environment, usage of RED must be end-to-end. An MD cannot synthesize RED packets, because it lacks access to the plaintext media payloads that are combined to form a RED payload.
double変換と他の変換の主な違いは、中間環境では、REDの使用はエンドツーエンドでなければならないことです。 MDは、REDペイロードを形成するために結合されるプレーンテキストメディアペイロードへのアクセスがないため、REDパケットを合成できません。
Note that Flexible Forward Error Correction (Flex FEC) may often provide similar or better repair capabilities compared to RED. For most applications, Flex FEC is a better choice than RED; in particular, Flex FEC has modes in which the MD can synthesize recovery packets.
フレキシブルフォワードエラー訂正（Flex FEC）は、REDと比較して、同等またはそれ以上の修復機能を提供することが多いことに注意してください。ほとんどのアプリケーションでは、REDよりもFlex FECの方が適しています。特に、Flex FECには、MDが回復パケットを合成できるモードがあります。
When using Flex FEC [RFC8627] with the double transform, repair packets MUST be constructed by first double-encrypting the packet, then performing FEC. Processing of repair packets proceeds in the opposite order, performing FEC recovery and then decrypting. This ensures that the original media is not revealed to the MD but, at the same time, allows the MD to repair media. When encrypting a packet that contains the Flex FEC data, which is already encrypted, it MUST be encrypted with only the outer, hop-by-hop transform.
二重変換でFlex FEC [RFC8627]を使用する場合、最初にパケットを二重暗号化してからFECを実行することにより、修復パケットを構築する必要があります。修復パケットの処理は逆の順序で進行し、FEC回復を実行してから復号化します。これにより、元のメディアがMDに公開されなくなり、同時にMDがメディアを修復できるようになります。すでに暗号化されているFlex FECデータを含むパケットを暗号化する場合、外部のホップバイホップ変換のみで暗号化する必要があります。
The algorithm recommended in [WEBRTC-FEC] for repair of video is Flex FEC [RFC8627]. Note that for interoperability with WebRTC, [WEBRTC-FEC] recommends not using additional FEC-only "m=" lines in SDP for the repair packets.
[WEBRTC-FEC]でビデオの修復に推奨されているアルゴリズムは、Flex FEC [RFC8627]です。 WebRTCとの相互運用性のために、[WEBRTC-FEC]は、修復パケットにSDPで追加のFECのみの「m =」行を使用しないことをお勧めします。
When DTMF is sent using the mechanism in [RFC4733], it is end-to-end encrypted; the relay cannot read it, so it cannot be used to control the relay. Other out-of-band methods to control the relay need to be used instead.
[RFC4733]のメカニズムを使用してDTMFが送信される場合、DTMFはエンドツーエンドで暗号化されます。リレーはそれを読み取ることができないため、リレーの制御には使用できません。代わりに、リレーを制御する他のアウトオブバンド方式を使用する必要があります。
This specification recommends and defines AES-GCM as both the inner and outer cryptographic algorithms, identified as DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithms provide for authenticated encryption and will consume additional processing time double-encrypting for hop-by-hop and end-to-end. However, the approach is secure and simple; thus, it is viewed as an acceptable trade-off in processing efficiency.
この仕様では、DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCMおよびDOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCMとして識別される内部および外部暗号化アルゴリズムの両方として、AES-GCMを推奨および定義しています。これらのアルゴリズムは認証された暗号化を提供し、ホップバイホップおよびエンドツーエンドの二重暗号化に追加の処理時間を消費します。ただし、このアプローチは安全でシンプルです。したがって、これは処理効率の許容できるトレードオフと見なされます。
Note that names for the cryptographic transforms are of the form DOUBLE_(inner algorithm)_(outer algorithm).
暗号変換の名前は、DOUBLE_（内部アルゴリズム）_（外部アルゴリズム）の形式であることに注意してください。
While this document only defines a profile based on AES-GCM, it is possible for future documents to define further profiles with different inner and outer algorithms in this same framework. For example, if a new SRTP transform were defined that encrypts some or all of the RTP header, it would be reasonable for systems to have the option of using that for the outer algorithm. Similarly, if a new transform were defined that provided only integrity, that would also be reasonable to use for the outer transform as the payload data is already encrypted by the inner transform.
このドキュメントではAES-GCMに基づくプロファイルのみを定義していますが、将来のドキュメントでは、この同じフレームワークで異なる内部アルゴリズムと外部アルゴリズムを使用してさらにプロファイルを定義することが可能です。たとえば、RTPヘッダーの一部またはすべてを暗号化する新しいSRTPトランスフォームが定義されている場合、システムが外部アルゴリズムにそれを使用するオプションを持つことは合理的です。同様に、整合性のみを提供する新しい変換が定義された場合、ペイロードデータは既に内部変換によって暗号化されているため、外部変換に使用することも妥当です。
The AES-GCM cryptographic algorithm introduces an additional 16 octets to the length of the packet. When using AES-GCM for both the inner and outer cryptographic algorithms, the total additional length is 32 octets. The OHB will consume an additional 1-4 octets. Packets in repair mode will carry additional repair data, further increasing their size.
AES-GCM暗号化アルゴリズムでは、パケットの長さに16オクテットが追加されます。内部暗号化アルゴリズムと外部暗号化アルゴリズムの両方にAES-GCMを使用する場合、追加の長さの合計は32オクテットです。 OHBはさらに1〜4オクテットを消費します。修復モードのパケットには、追加の修復データが含まれ、サイズがさらに大きくなります。
This SRTP transform provides protection against two classes of attacker: a network attacker that knows neither the inner nor outer keys and a malicious MD that knows the outer key. Obviously, it provides no protections against an attacker that holds both the inner and outer keys.
このSRTPトランスフォームは、2つのクラスの攻撃者（内部キーも外部キーも知らないネットワーク攻撃者と外部キーを知っている悪意のあるMD）に対する保護を提供します。明らかに、内部キーと外部キーの両方を保持する攻撃者に対する保護は提供されません。
The protections with regard to the network are the same as with the normal SRTP AES-GCM transforms. The major difference is that the double transforms are designed to work better in a group context. In such contexts, it is important to note that because these transforms are symmetric, they do not protect against attacks within the group. Any member of the group can generate valid SRTP packets for any SSRC in use by the group.
ネットワークに関する保護は、通常のSRTP AES-GCMトランスフォームと同じです。主な違いは、二重変換はグループコンテキストでより適切に機能するように設計されていることです。このような状況では、これらの変換は対称的であるため、グループ内の攻撃から保護されないことに注意することが重要です。グループのメンバーは、グループが使用しているSSRCの有効なSRTPパケットを生成できます。
With regard to a malicious MD, the recipient can verify the integrity of the base header fields and confidentiality and integrity of the payload. The recipient has no assurance, however, of the integrity of the header extensions in the packet.
悪意のあるMDに関して、受信者はベースヘッダーフィールドの整合性とペイロードの機密性と整合性を確認できます。ただし、受信者はパケット内のヘッダー拡張の整合性を保証できません。
The main innovation of this transform relative to other SRTP transforms is that it allows a partly trusted MD to decrypt, modify, and re-encrypt a packet. When this is done, the cryptographic contexts used for decryption and re-encryption MUST use different, independent master keys. If the same context is used, the nonce formation rules for SRTP will cause the same key and nonce to be used with two different plaintexts, which substantially degrades the security of AES-GCM.
他のSRTP変換と比較したこの変換の主な革新は、部分的に信頼されたMDがパケットを復号化、変更、および再暗号化できることです。これが行われるとき、復号化と再暗号化に使用される暗号化コンテキストは、異なる独立したマスターキーを使用する必要があります。同じコンテキストが使用される場合、SRTPのナンス形成ルールにより、同じキーとナンスが2つの異なるプレーンテキストで使用され、AES-GCMのセキュリティが大幅に低下します。
In other words, from the perspective of the MD, re-encrypting packets using this protocol will involve the same cryptographic operations as if it had established independent AES-GCM crypto contexts with the sender and the receiver. This property allows the use of an MD that supports AES-GCM but does not modify any header fields, without requiring any modification to the MD.
つまり、MDの観点から見ると、このプロトコルを使用したパケットの再暗号化には、送信側と受信側で独立したAES-GCM暗号コンテキストを確立した場合と同じ暗号操作が含まれます。このプロパティは、AES-GCMをサポートするMDの使用を許可しますが、MDを変更することなく、ヘッダーフィールドを変更しません。
IANA has added the following protection profiles to the "DTLS-SRTP Protection Profiles" registry defined in [RFC5764].
IANAは、[RFC5764]で定義されている「DTLS-SRTP保護プロファイル」レジストリに次の保護プロファイルを追加しました。
+--------+------------------------------------------+-----------+
| Value | Profile | Reference |
+========+==========================================+===========+
| {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFC 8723 |
| 0x09} | | |
+--------+------------------------------------------+-----------+
| {0x00, | DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM | RFC 8723 |
| 0x0A} | | |
+--------+------------------------------------------+-----------+
Table 1: Updates to the DTLS-SRTP Protection Profiles Registry
表1：DTLS-SRTP保護プロファイルレジストリの更新
The SRTP transform parameters for each of these protection profiles are:
これらの各保護プロファイルのSRTP変換パラメータは次のとおりです。
+---------------------------------------------------------+
| DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM |
+-----------------------+---------------------------------+
| cipher: | AES_128_GCM then AES_128_GCM |
+-----------------------+---------------------------------+
| cipher_key_length: | 256 bits |
+-----------------------+---------------------------------+
| cipher_salt_length: | 192 bits |
+-----------------------+---------------------------------+
| aead_auth_tag_length: | 256 bits |
+-----------------------+---------------------------------+
| auth_function: | NULL |
+-----------------------+---------------------------------+
| auth_key_length: | N/A |
+-----------------------+---------------------------------+
| auth_tag_length: | N/A |
+-----------------------+---------------------------------+
| maximum lifetime: | at most 2^(31) SRTCP packets |
| | and at most 2^(48) SRTP packets |
+-----------------------+---------------------------------+
Table 2: SRTP Transform Parameters for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM
表2：DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCMのSRTP変換パラメーター
+---------------------------------------------------------+
| DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM |
+-----------------------+---------------------------------+
| cipher: | AES_256_GCM then AES_256_GCM |
+-----------------------+---------------------------------+
| cipher_key_length: | 512 bits |
+-----------------------+---------------------------------+
| cipher_salt_length: | 192 bits |
+-----------------------+---------------------------------+
| aead_auth_tag_length: | 256 bits |
+-----------------------+---------------------------------+
| auth_function: | NULL |
+-----------------------+---------------------------------+
| auth_key_length: | N/A |
+-----------------------+---------------------------------+
| auth_tag_length: | N/A |
+-----------------------+---------------------------------+
| maximum lifetime: | at most 2^(31) SRTCP packets |
| | and at most 2^(48) SRTP packets |
+-----------------------+---------------------------------+
Table 3: SRTP Transform Parameters for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM
表3：DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCMのSRTP変換パラメーター
The first half of the key and salt is used for the inner (end-to-end) algorithm and the second half is used for the outer (hop-by-hop) algorithm.
キーとソルトの前半は内部（エンドツーエンド）アルゴリズムに使用され、後半は外部（ホップバイホップ）アルゴリズムに使用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] McGrew、D。およびE. Rescorla、「Secure Real-time Transport Protocol（SRTP）のキーを確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張」、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<https ：//www.rfc-editor.org/info/rfc5764>。
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011, <https://www.rfc-editor.org/info/rfc6188>.
[RFC6188] McGrew、D。、「Secure RTPでのAES-192およびAES-256の使用」、RFC 6188、DOI 10.17487 / RFC6188、2011年3月、<https://www.rfc-editor.org/info/ rfc6188>。
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <https://www.rfc-editor.org/info/rfc6904>.
[RFC6904] Lennox、J。、「Secure Real-time Transport Protocol（SRTP）のヘッダー拡張の暗号化」、RFC 6904、DOI 10.17487 / RFC6904、2013年4月、<https://www.rfc-editor.org/ info / rfc6904>。
[RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", RFC 7714, DOI 10.17487/RFC7714, December 2015, <https://www.rfc-editor.org/info/rfc7714>.
[RFC7714] McGrew、D。およびK. Igoe、「Secure Real-time Transport Protocol（SRTP）でのAES-GCM認証済み暗号化」、RFC 7714、DOI 10.17487 / RFC7714、2015年12月、<https：//www.rfc -editor.org/info/rfc7714>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, <https://www.rfc-editor.org/info/rfc8285>.
[RFC8285] Singer、D.、Desieneni、H。、およびR. Even、編、「RTPヘッダー拡張の一般的なメカニズム」、RFC 8285、DOI 10.17487 / RFC8285、2017年10月、<https：//www.rfc -editor.org/info/rfc8285>。
[DTLS-TUNNEL] Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange", Work in Progress, Internet-Draft, draft-ietf-perc-dtls-tunnel-06, 16 October 2019, <https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel-06>.
[DTLS-TUNNEL] Jones、P.、Ellenbogen、P。、およびN. Ohlmeier、「メディアディストリビューターとキーディストリビューター間のDTLSトンネルによるキー交換の促進」、進行中の作業、インターネットドラフト、draft-ietf-perc- dtls-tunnel-06、2019年10月16日、<https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel-06>。
[EKT-SRTP] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure RTP", Work in Progress, Internet-Draft, draft-ietf-perc-srtp-ekt-diet-10, 8 July 2019, <https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-10>.
[EKT-SRTP] Jennings、C.、Mattsson、J.、McGrew、D.、Wing、D。、およびF. Andreasen、「DTLSおよびSecure RTPの暗号化キー転送」、進行中の作業、インターネットドラフト、ドラフト-ietf-perc-srtp-ekt-diet-10、2019年7月8日、<https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-10>。
[PRIVATE-MEDIA-FRAMEWORK] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC)", Work in Progress, Internet-Draft, draft-ietf-perc-private-media-framework-12, 5 June 2019, <https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-12>.
[PRIVATE-MEDIA-FRAMEWORK]ジョーンズ、P。、ベンハム、D。、およびC.グローブス、「プライバシー強化RTP会議（PERC）におけるプライベートメディアのソリューションフレームワーク」、作業中、インターネットドラフト、ドラフトietf -perc-private-media-framework-12、2019年6月5日、<https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-12>。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, <https://www.rfc-editor.org/info/rfc2198>.
[RFC2198]パーキンス、C。、コウベラス、I。、ホドソン、O。、ハードマン、V。、ハンドラリー、M。、ボロット、JC、ベガガルシア、A。、およびS.フォセパリシス、「RTP Payload for Redundant Audio Data」、RFC 2198、DOI 10.17487 / RFC2198、1997年9月、<https://www.rfc-editor.org/info/rfc2198>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<https：/ /www.rfc-editor.org/info/rfc4588>。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, <https://www.rfc-editor.org/info/rfc4733>.
[RFC4733] Schulzrinne、H。およびT. Taylor、「DTMFディジット、テレフォニートーン、およびテレフォニーシグナルのRTPペイロード」、RFC 4733、DOI 10.17487 / RFC4733、2006年12月、<https://www.rfc-editor.org / info / rfc4733>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019, <https://www.rfc-editor.org/info/rfc8627>.
[RFC8627] Zanaty、M.、Singh、V.、Begen、A。、およびG. Mandyam、「柔軟な前方誤り訂正（FEC）のRTPペイロード形式」、RFC 8627、DOI 10.17487 / RFC8627、2019年7月、<https ：//www.rfc-editor.org/info/rfc8627>。
[WEBRTC-FEC] Uberti, J., "WebRTC Forward Error Correction Requirements", Work in Progress, Internet-Draft, draft-ietf-rtcweb-fec-10, 16 July 2019, <https://tools.ietf.org/html/draft-ietf-rtcweb-fec-10>.
[WEBRTC-FEC] Uberti、J。、「WebRTC Forward Error Correction Requirements」、Work in Progress、Internet-Draft、draft-ietf-rtcweb-fec-10、2019年7月16日、<https://tools.ietf.org / html / draft-ietf-rtcweb-fec-10>。
The following figures show a double-encrypted SRTP packet. The sides indicate the parts of the packet that are encrypted and authenticated by the hop-by-hop and end-to-end operations.
次の図は、二重に暗号化されたSRTPパケットを示しています。サイドは、ホップバイホップおよびエンドツーエンド操作によって暗号化および認証されるパケットの部分を示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP extension (OPTIONAL) ... |
+>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O I | payload ... |
O I | +-------------------------------+
O I | | RTP padding | RTP pad count |
O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O | | E2E authentication tag |
O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O | | OHB ... |
+>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | HBH authentication tag |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| +- E2E Encrypted Portion
|
+--- HBH Encrypted Portion
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
|V=2|P|X| CC |M| PT | sequence number | I O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I O
| timestamp | I O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I O
| synchronization source (SSRC) identifier | I O
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ I O
| contributing source (CSRC) identifiers | I O
| .... | I O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O
| RTP extension (OPTIONAL) ... | | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O
| payload ... | I O
| +-------------------------------+ I O
| | RTP padding | RTP pad count | I O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O
| E2E authentication tag | | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O
| OHB ... | | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<+
| HBH authentication tag | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| |
E2E Authenticated Portion ---+ |
|
HBH Authenticated Portion -----+
Acknowledgments
謝辞
Thank you to Alex Gouaillard, David Benham, Magnus Westerlund, Nils Ohlmeier, Roni Even, and Suhas Nandakumar for reviews and improvements to this specification. In addition, thank you to Sergio Garcia Murillo, who proposed the change of transporting the OHB information in the RTP payload instead of the RTP header.
この仕様のレビューと改善について、Alex Gouaillard、David Benham、Magnus Westerlund、Nils Ohlmeier、Roni Even、およびSuhas Nandakumarに感謝します。さらに、RTBヘッダーではなくRTPペイロードでOHB情報を転送する変更を提案したSergio Garcia Murilloに感謝します。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco Systems
カレンジェニングスシスコシステムズ
Email: fluffy@iii.ca
Paul E. Jones Cisco Systems
ポールE.ジョーンズシスコシステムズ
Email: paulej@packetizer.com
Richard Barnes Cisco Systems
Richard Barnes Cisco Systems
Email: rlb@ipv.sx
Adam Roach Mozilla
アダムローチモジラ
Email: adam@nostrum.com