[要約] RFC 8870は、DTLS (Datagram Transport Layer Security) および Secure RTP (SRTP) における暗号化されたキー輸送のための標準を定めています。この文書の目的は、通信のセキュリティを強化するために、キー交換プロセス中にキーを暗号化して輸送する方法を提供することです。主に、リアルタイム通信を行うアプリケーションやシステムで利用され、通信の機密性と完全性を保証するために重要です。関連するRFCには、RFC 5764 (DTLSのSRTPへの適用)、RFC 6347 (DTLS 1.2の定義)、RFC 3711 (SRTPの仕様) などがあります。これらの技術は、特にVoIPやビデオ会議システムなど、セキュアなリアルタイム通信が求められる場面で広く利用されています。
Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 8870 Cisco Systems
Category: Standards Track J. Mattsson
ISSN: 2070-1721 Ericsson AB
D. McGrew
Cisco Systems
D. Wing
Citrix
F. Andreasen
Cisco Systems
January 2021
Encrypted Key Transport for DTLS and Secure RTP
DTLSとセキュアRTPのための暗号化されたキートランスポート
Abstract
概要
Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and the Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints.
暗号化されたキートランスポート（EKT）は、SRTPマスターキー、ロールオーバーカウンタ、およびSRTP内の他の情報の安全なトランスポートを提供するDTLS（データグラムトランスポートレイヤセキュリティ）およびセキュアリアルタイムトランスポートプロトコル（SRTP）の拡張です。この施設では、共通鍵をすべての会議エンドポイントに配布することで、分散会議用のSRTPを有効にします。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8870.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8870で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Overview
3. Conventions Used in This Document
4. Encrypted Key Transport
4.1. EKTField Formats
4.2. SPIs and EKT Parameter Sets
4.3. Packet Processing and State Machine
4.3.1. Outbound Processing
4.3.2. Inbound Processing
4.4. Ciphers
4.4.1. AES Key Wrap
4.4.2. Defining New EKT Ciphers
4.5. Synchronizing Operation
4.6. Timing and Reliability Considerations
5. Use of EKT with DTLS-SRTP
5.1. DTLS-SRTP Recap
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
5.2.1. Negotiating an EKTCipher
5.2.2. Establishing an EKT Key
5.3. Offer/Answer Considerations
5.4. Sending the DTLS EKTKey Reliably
6. Security Considerations
7. IANA Considerations
7.1. EKT Message Types
7.2. EKT Ciphers
7.3. TLS Extensions
7.4. TLS Handshake Type
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
The Real-time Transport Protocol (RTP) is designed to allow decentralized groups with minimal control to establish sessions, such as for multimedia conferences. Unfortunately, Secure RTP (SRTP) [RFC3711] cannot be used in many minimal-control scenarios, because it requires that synchronization source (SSRC) values and other data be coordinated among all of the participants in a session. For example, if a participant joins a session that is already in progress, that participant needs to be informed of the SRTP keys along with the SSRC, rollover counter (ROC), and other details of the other SRTP sources.
リアルタイムトランスポートプロトコル（RTP）は、マルチメディアカンファレンスなどのセッションを確立するための最小限の制御で分散グループを可能にするように設計されています。残念ながら、Secure RTP（SRTP）[RFC3711]は、シンクロー化ソース（SSRC）の値やその他のデータがセッション内のすべての参加者間で調整される必要があるため、さまざまなコントロールシナリオで使用できません。たとえば、参加者がすでに進行中のセッションを参加させた場合、その参加者はSSRC、ロールオーバーカウンタ（ROC）、および他のSRTPソースのその他の詳細とともに、SRTPキーを通知する必要があります。
The inability of SRTP to work in the absence of central control was well understood during the design of the protocol; the omission was considered less important than optimizations such as bandwidth conservation. Additionally, in many situations, SRTP is used in conjunction with a signaling system that can provide the central control needed by SRTP. However, there are several cases in which conventional signaling systems cannot easily provide all of the coordination required.
SRTPが中心対照の不在下で機能することができないことは、プロトコルの設計中によく理解されていた。省略は、帯域幅保全などの最適化よりも重要ではありません。さらに、多くの状況では、SRTPはSRTPによって必要とされる中心的な制御を提供することができるシグナリングシステムと組み合わせて使用される。しかしながら、従来のシグナリングシステムが必要とされるすべての調整システムを容易に提供することができない場合がいくつかある。
This document defines Encrypted Key Transport (EKT) for SRTP and reduces the amount of external signaling control that is needed in an SRTP session with multiple receivers. EKT securely distributes the SRTP master key and other information for each SRTP source. With this method, SRTP entities are free to choose SSRC values as they see fit and to start up new SRTP sources with new SRTP master keys within a session without coordinating with other entities via external signaling or other external means.
この文書はSRTPの暗号化された鍵トランスポート（EKT）を定義し、複数の受信者とのSRTPセッションで必要とされる外部シグナリング制御の量を削減します。EKTはSRTPマスターキーおよび各SRTPソースについて安全に配布されます。このメソッドを使用すると、SRTPエンティティは、外部シグナリングまたは他の外部手段を介して他のエンティティを調整することなく、セッション内の新しいSRTPマスターキーを使用して新しいSRTPマスターキーを使用して新しいSRTPソースを起動するようにSRTPエンティティを選択できます。
EKT extends DTLS and SRTP to enable a common key encryption key (called an "EKTKey") to be distributed to all endpoints, so that each endpoint can securely send its SRTP master key and current SRTP ROC to the other participants in the session. This data furnishes the information needed by the receiver to instantiate an SRTP receiver context.
EKTはDTLSとSRTPを拡張して、すべてのエンドポイントに共通のキー暗号化キー（ "EKTKEY"と呼びます）をすべてのエンドポイントに分散させることができます。そのため、各エンドポイントはSRTPマスターキーと現在のSRTP ROCをセッション内の他の参加者に安全に送信できます。このデータは、SRTP受信者コンテキストをインスタンス化するために受信機によって必要とされる情報を提供する。
EKT can be used in conferences where the central Media Distributor or conference bridge cannot decrypt the media, such as the type defined in [RFC8871]. It can also be used for large-scale conferences where the conference bridge or Media Distributor can decrypt all the media but wishes to encrypt the media it is sending just once and then send the same encrypted media to a large number of participants. This reduces encryption CPU time in general and is necessary when sending multicast media.
EKTは、[RFC8871]で定義されているタイプなど、中央メディアディストリビュータまたは会議ブリッジがメディアを復号化できない会議で使用できます。また、会議ブリッジまたはメディアディストリビュータがすべてのメディアを復号化できるが、それが一度だけ送信してから同じ暗号化メディアを多数の参加者に送信しているメディアを暗号化することができる大規模な会議にも使用できます。これにより、暗号化CPU時間が一般的に減少し、マルチキャストメディアを送信するときに必要です。
EKT does not control the manner in which the SSRC is generated. It is only concerned with distributing the security parameters that an endpoint needs to associate with a given SSRC in order to decrypt SRTP packets from that sender.
EKTは、SSRCが生成される方法を制御しません。それは、その送信者からSRTPパケットを復号化するために、エンドポイントが特定のSSRCと関連付ける必要があるセキュリティパラメータを分散させることにのみ関係する。
EKT is not intended to replace external key establishment mechanisms. Instead, it is used in conjunction with those methods, and it relieves those methods of the burden of delivering the context for each SRTP source to every SRTP participant. This document defines how EKT works with the DTLS-SRTP approach to key establishment, by using keys derived from the DTLS-SRTP handshake to encipher the EKTKey in addition to the SRTP media.
EKTは、外部キー確立メカニズムを置き換えることを意図していません。代わりに、それはそれらの方法と組み合わせて使用されており、各SRTPソースのコンテキストをすべてのSRTP参加者に提供する負担のどちらの方法を軽減します。このドキュメントでは、SRTPメディアに加えてEKTKEYを暗号化するためにDTLS-SRTPハンドシェイクから派生したキーを使用して、EKTがキー・セッション・アプローチでEKTがどのように機能するかを定義します。
This specification defines a way for the server in a DTLS-SRTP negotiation (see Section 5) to provide an EKTKey to the client during the DTLS handshake. The EKTKey thus obtained can be used to encrypt the SRTP master key that is used to encrypt the media sent by the endpoint. This specification also defines a way to send the encrypted SRTP master key (with the EKTKey) along with the SRTP packet (see Section 4). Endpoints that receive this packet and know the EKTKey can use the EKTKey to decrypt the SRTP master key, which can then be used to decrypt the SRTP packet.
この仕様は、DTLS-SRTPネゴシエーション（セクション5参照）内のサーバーの方法を定義して、DTLSハンドシェイク中にクライアントにEKTKEYを提供します。このようにして得られたEktkeyを使用して、エンドポイントによって送信されたメディアの暗号化に使用されるSRTPマスターキーを暗号化することができます。この仕様は、SRTPパケットとともに暗号化されたSRTPマスターキーを（EKTKEYと）送信する方法も定義します（セクション4を参照）。このパケットを受信してEktkeyを知っているエンドポイントは、Ektkeyを使用してSRTPマスターキーを復号化できます。これはSRTPパケットの復号化に使用できます。
One way to use this specification is described in the architecture defined by [RFC8871]. Each participant in the conference forms a DTLS-SRTP connection to a common Key Distributor that distributes the same EKTKey to all the endpoints. Then, each endpoint picks its own SRTP master key for the media it sends. When sending media, the endpoint may also include the SRTP master key encrypted with the EKTKey in the SRTP packet. This allows all the endpoints to decrypt the media.
この仕様を使用する1つの方法は、[RFC8871]によって定義されたアーキテクチャに記載されています。会議の各参加者は、同じEKTKEYをすべてのエンドポイントに配布する共通のキーディストリビュータへのDTLS-SRTP接続を形成します。それから、各エンドポイントはそれが送信するメディアの独自のSRTPマスターキーを選択します。メディアを送信するとき、エンドポイントはSRTPパケット内のEKTKEYで暗号化されたSRTPマスターキーも含み得る。これにより、すべてのエンドポイントがメディアを復号化できます。
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.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
EKT defines a new method of providing SRTP master keys to an endpoint. In order to convey the ciphertext corresponding to the SRTP master key, and other additional information, an additional field, called the "EKTField", is added to the SRTP packets. The EKTField appears at the end of the SRTP packet. It appears after the optional authentication tag, if one is present; otherwise, the EKTField appears after the ciphertext portion of the packet.
EKTは、SRTPマスターキーをエンドポイントに提供する新しい方法を定義します。SRTPマスターキーに対応する暗号文を伝達するために、「EktField」と呼ばれる追加のフィールドがSRTPパケットに追加されます。EktFieldはSRTPパケットの最後に表示されます。存在する場合は、オプションの認証タグの後に表示されます。それ以外の場合、EktFieldはパケットの暗号文部分の後に表示されます。
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP features duplicate some of the functions of EKT. Senders MUST NOT include the MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use.
EKTはSRTPのMKI（マスターキー識別子）またはSRTPの<from、> [RFC3711]と共に使用してはいけません（これらのSRTP機能はEKTの関数のいくつかを複製してください。送信者は、EKTを使用するときにMKIを含めるべきではありません。受信者は、EKTが使用されている場合に受信したMKIフィールドを単に無視する必要があります。
This document defines the use of EKT with SRTP. Its use with the Secure Real-time Transport Control Protocol (SRTCP) would be similar, but that topic is left for a future specification. SRTP is preferred for transmitting keying material because (1) it shares fate with the transmitted media, (2) SRTP rekeying can occur without concern for RTCP transmission limits, and (3) it avoids the need for SRTCP compound packets with RTP translators and mixers.
このドキュメントはSRTPを使用したEKTの使用を定義します。安全なリアルタイムトランスポートコントロールプロトコル（SRTCP）との使用は似ていますが、そのトピックは将来の仕様のために残されています。SRTPはキーイング資料を送信するのに好ましいため、（1）送信されたメディアとの運命を共有するため、（2）RTCP送信制限を気にせずに発生する可能性があり、（3）RTP翻訳者とミキサーを備えたSRTCP複合パケットの必要性を回避する。
The EKTField uses the formats defined in Figures 1 and 2 for the FullEKTField and ShortEKTField. The EKTField appended to an SRTP packet can be referred to as an "EKT Tag".
EktFieldは、FullektFieldとShortektFieldの図1と図2に定義されているフォーマットを使用します。SRTPパケットに追加されたEktFieldは、「EKTタグ」と呼ぶことができる。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: EKT Ciphertext :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FullEKTField Format
図1：FullektFieldフォーマット
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
Figure 2: ShortEKTField Format
図2：ShortektFieldフォーマット
Figure 3 shows the syntax of the EKTField, expressed in ABNF [RFC5234]. The EKTField is added to the end of an SRTP packet. The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC, in that order. The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey. Future extensions to the EKTField MUST conform to the syntax of the ExtensionEKTField.
図3は、ABNF [RFC5234]で表されるEktfieldの構文を示しています。EktFieldがSRTPパケットの末尾に追加されます。EktpleAntextは、SRTPMasterKeyLength、SRTPMasterKey、SSRC、およびROCの連結で、その順序で。ektCipherTextは、Ektkeyを使用してEktpleAntextを暗号化することによって計算されます。EktFieldへの将来の拡張は、ExtenseEktFieldの構文に準拠している必要があります。
BYTE = %x00-FF
EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF ; Message Type %x01 is not available
; for assignment due to its usage by
; legacy implementations.
EKTMsgLength = 2BYTE
SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1*242BYTE
SSRC = 4BYTE ; SSRC from RTP
ROC = 4BYTE ; ROC from SRTP for the given SSRC
EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
EktpleAntext = SRTPMasterKeyLength SRTPMasterKey SSRC Roc.
EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
Epoch = 2BYTE
SPI = 2BYTE
FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull
FullektField = EktCipherText Spi Epoch EktmSGlength EktMSGtypeFull.
ShortEKTField = EKTMsgTypeShort
ExtensionData = 1*1024BYTE
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
Figure 3: EKTField Syntax
図3：EktField構文
These fields and data elements are defined as follows:
これらのフィールドとデータ要素は次のように定義されています。
EKTPlaintext: This is the data that is input to the EKT encryption operation. This data never appears on the wire; it is used only in computations internal to EKT. This is the concatenation of the SRTP master key and its length, the SSRC, and the ROC.
EktpleAntext：これはEKT暗号化操作に入力されるデータです。このデータはワイヤーに表示されません。EKTの内部の計算にのみ使用されます。これは、SRTPマスターキーとその長さ、SSRC、およびROCの連結です。
EKTCiphertext: This is the data that is output from the EKT encryption operation (see Section 4.4). This field is included in SRTP packets when EKT is in use. The length of the EKTCiphertext can be larger than the length of the EKTPlaintext that was encrypted.
EktCipherText：これはEKT暗号化操作から出力されるデータです（セクション4.4を参照）。このフィールドは、EKTが使用されているときにSRTPパケットに含まれています。EktCipherTextの長さは、暗号化されたEktpleAntextの長さよりも大きくなる可能性があります。
SRTPMasterKey: On the sender side, this is the SRTP master key associated with the indicated SSRC.
SRTPMasterKey：送信側では、これは示されたSSRCに関連付けられているSRTPマスターキーです。
SRTPMasterKeyLength: This is the length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated for SRTP using Session Description Protocol (SDP) Offer/Answer [RFC3264].
SRTPMasterKeyLength：これは、SRTPMasterKeyの長さがバイト単位である。これは、セッション記述プロトコル（SDP）オファー/アンサー[RFC3264]を使用して、SRTPに対してネゴシエートされた暗号スイートによって異なります。
SSRC: On the sender side, this is the SSRC for this SRTP source. The length of this field is 32 bits. The SSRC value in the EKT Tag MUST be the same as the one in the header of the SRTP packet to which the tag is appended.
SSRC：送信者側では、これがこのSRTPソースのSSRCです。このフィールドの長さは32ビットです。EKTタグのSSRC値は、タグが追加されているSRTPパケットのヘッダー内のものと同じでなければなりません。
Rollover Counter (ROC): On the sender side, this is set to the current value of the SRTP ROC in the SRTP context associated with the SSRC in the SRTP packet. The length of this field is 32 bits.
ロールオーバーカウンタ（ROC）：送信側では、これはSRTPパケット内のSSRCに関連付けられているSRTPコンテキスト内のSRTP ROCの現在の値に設定されます。このフィールドの長さは32ビットです。
Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing the packet, within a given conference. The length of this field is 16 bits, representing a two-byte integer in network byte order. The parameters identified by this field are as follows:
セキュリティパラメータ索引（SPI）：このフィールドは、与えられた会議内でパケットを処理するときに使用する受信側の適切なEKTKEYおよびその他のパラメータを示します。このフィールドの長さは16ビットで、ネットワークバイト順に2バイトの整数を表します。このフィールドによって識別されるパラメータは次のとおりです。
* The EKT Cipher used to process the packet.
* パケットの処理に使用されるEKT暗号。
* The EKTKey used to process the packet.
* パケットの処理に使用されるEktKey。
* The SRTP master salt associated with any master key encrypted with this EKT Key. The master salt is communicated separately, via signaling, typically along with the EKTKey. (Recall that the SRTP master salt is used in the formation of Initialization Vectors (IVs) / nonces.)
* このEKTキーで暗号化されたマスターキーに関連するSRTPマスターソルト。マスターソルトは、シグナリングを介して、通常はEktkeyと共に別々に通信されます。（SRTPマスター塩が初期化ベクター（IVS）/ Noncesの形成に使用されることを思い出す。）
Epoch: This field indicates how many SRTP keys have been sent for this SSRC under the current EKTKey, prior to the current key, as a two-byte integer in network byte order. It starts at zero at the beginning of a session and resets to zero whenever the EKTKey is changed (i.e., when a new SPI appears). The epoch for an SSRC increments by one every time the sender transmits a new key. The recipient of a FullEKTField MUST reject any future FullEKTField for this SPI and SSRC that has an epoch value equal to or lower than an epoch already seen.
EPOCH：このフィールドは、現在のektkeyの前に、現在のキーの前に、ネットワークバイト順序の2バイトの整数として、このSSRCに対していくつのSRTPキーが送信されたかを示します。それはセッションの開始時にゼロから始まり、Ektkeyが変更されたときはいつでも（すなわち、新しいSPIが現れるとき）にリセットされます。SSRCのEPOCHは、送信者が新しいキーを送信するたびに1つずつ増加します。Fullektfieldの受信者は、このSPIおよびSSRCのための将来のFullektFieldを拒否しなければなりません。
Together, these data elements are called an "EKT parameter set". To avoid ambiguity, each distinct EKT parameter set that is used MUST be associated with a distinct SPI value.
まとめると、これらのデータ要素は「EKTパラメータセット」と呼ばれます。あいまいさを避けるために、使用される各異なるEKTパラメータセットは、異なるSPI値と関連付けられている必要があります。
EKTMsgLength: All EKT Message Types other than the ShortEKTField include a length in octets (in network byte order) of either the FullEKTField or the ExtensionEKTField, including this length field and the EKT Message Type (as defined in the next paragraph).
EKTMSGLength：ShortektField以外のすべてのEKTメッセージタイプには、この長さフィールドとEKTメッセージタイプ（次の段落で定義されているように）FullektFieldまたはExtenseEktFieldのいずれかのオクテット（ネットワークバイト順）の長さが含まれています。
Message Type: The last byte is used to indicate the type of the EKTField. This MUST be 2 for the FullEKTField format and 0 for the ShortEKTField format. If a received EKT Tag has an unknown Message Type, then the receiver MUST discard the whole EKT Tag.
メッセージタイプ：最後のバイトは、EktFieldの型を示すために使用されます。これは、FullektFieldフォーマットの場合は2、ShortektFieldフォーマットの場合は0でなければなりません。受信したEKTタグが未知のメッセージタイプを持つ場合、受信者はEKTタグ全体を破棄しなければなりません。
The SPI identifies the parameters for how the EKT Tag should be processed:
SPIは、EKTタグを処理する方法のパラメータを識別します。
* The EKTKey and EKT Cipher used to process the packet.
* パケットの処理に使用されるEktkeyとEkt暗号。
* The SRTP master salt associated with any master key encrypted with this EKT Key. The master salt is communicated separately, via signaling, typically along with the EKTKey.
* このEKTキーで暗号化されたマスターキーに関連するSRTPマスターソルト。マスターソルトは、シグナリングを介して、通常はEktkeyと共に別々に通信されます。
Together, these data elements are called an "EKT parameter set". To avoid ambiguity, each distinct EKT parameter set that is used MUST be associated with a distinct SPI value. The association of a given parameter set with a given SPI value is configured by some other protocol, e.g., the DTLS-SRTP extension defined in Section 5.
まとめると、これらのデータ要素は「EKTパラメータセット」と呼ばれます。あいまいさを避けるために、使用される各異なるEKTパラメータセットは、異なるSPI値と関連付けられている必要があります。特定のSPI値を有する所与のパラメータセットの関連付けは、他のプロトコル、例えばセクション5で定義されたDTLS - SRTP拡張によって構成される。
At any given time, the SSRC for each SRTP source has associated with it a single EKT parameter set. This parameter set is used to process all outbound packets and is called the "outbound parameter set" for that SSRC. There may be other EKT parameter sets that are used by other SRTP sources in the same session, including other SRTP sources on the same endpoint (e.g., one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on an endpoint, each with their own EKT parameter set). All of the received EKT parameter sets SHOULD be stored by all of the participants in an SRTP session, for use in processing inbound SRTP traffic. If a participant deletes an EKT parameter set (e.g., because of space limitations), then it will be unable to process Full EKT Tags containing updated media keys and thus will be unable to receive media from a participant that has changed its media key.
任意の時点で、各SRTPソースのSSRCはそれに関連付けられています。単一のEKTパラメータセット。このパラメータセットは、すべてのアウトバウンドパケットを処理するために使用され、そのSSRCの「アウトバウンドパラメータセット」と呼ばれます。同じエンドポイント上の他のSRTPソース（例えば、VoiceとVideoの1つのエンドポイントには2つのEKTパラメータセットがある場合、または複数のビデオソースがある可能性がある場合、または複数のビデオソースがある可能性がある場合、または複数のビデオソースがある場合があります）の他のSRTPソースによって使用される他のEKTパラメータセットがあります。エンドポイントで、それぞれ独自のEKTパラメータセットを設定します。受信したすべてのEKTパラメータセットは、インバウンドSRTPトラフィックの処理の処理に使用するために、SRTPセッション内のすべての参加者によって保存されるべきです。参加者がEKTパラメータセットを（例えば、スペースの制限のために）EKTパラメータセットを削除すると、更新されたメディアキーを含むフルEKTタグを処理することができず、したがってメディアキーを変更した参加者からメディアを受信できなくなります。
Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets. The decision regarding which parameter to send and when is specified in Section 4.6.
FulleKtFieldまたはShortektFieldがすべてのSRTPパケットの末尾に追加されています。セクション4.6で送信するかとどのパラメータを送信するかに関する決定。
See Section 4.6, which describes when to send an SRTP packet with a FullEKTField. If a FullEKTField is not being sent, then a ShortEKTField is sent so the receiver can correctly determine how to process the packet.
SRTPパケットをFullektFieldで送信するかどうかを説明するセクション4.6を参照してください。FullektFieldが送信されていない場合、ShortektFieldが送信され、受信側がパケットの処理方法を正しく決定できます。
When an SRTP packet is sent with a FullEKTField, the EKTField for that packet is created per either the steps below or an equivalent set of steps.
SRTPパケットがFullektFieldと共に送信されると、そのパケットのEKTFIELSは以下のステップまたは同等のステップのセットごとに作成されます。
1. The Security Parameter Index (SPI) field is set to the value of the SPI that is associated with the outbound parameter set.
1. セキュリティパラメータインデックス（SPI）フィールドは、アウトバウンドパラメータセットに関連付けられているSPIの値に設定されます。
2. The EKTPlaintext field is computed from the SRTP master key, SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP master key, and SSRC used in EKT processing MUST be the same as the one used in SRTP processing.
2. EKTPleAntextフィールドは、セクション4.1に示すように、SRTPマスターキー、SSRC、およびROCフィールドから計算されます。EKT処理で使用されるROC、SRTPマスターキー、およびSSRCは、SRTP処理で使用されているものと同じでなければなりません。
3. The EKTCiphertext field is set to the ciphertext created by encrypting the EKTPlaintext with the EKTCipher using the EKTKey as the encryption key. The encryption process is detailed in Section 4.4.
3. EktCiphtTextフィールドは、EktkeyをEktkeyを暗号化キーとしてEktCipherと暗号化することによって作成された暗号文に設定されます。暗号化プロセスはセクション4.4に詳述されています。
4. Then, the FullEKTField is formed using the EKTCiphertext and the SPI associated with the EKTKey used above. Also appended are the length and Message Type using the FullEKTField format.
4. そして、FullektFieldは、上記のEktkeyに関連付けられているEktCipherTextとSPIを使用して形成されます。FullektFieldフォーマットを使用した長さとメッセージタイプも追加されています。
| Note: The value of the EKTCiphertext field is identical in
| successive packets protected by the same EKTKey and SRTP master
| key. This value MAY be cached by an SRTP sender to minimize
| computational effort.
The computed value of the FullEKTField is appended to the end of the SRTP packet, after the encrypted payload.
暗号化されたペイロードの後、FullektFieldの計算値はSRTPパケットの最後に追加されます。
When a packet is sent with the ShortEKTField, the ShortEKTField is simply appended to the packet.
パケットがShortektFieldで送信されると、ShortektFieldは単にパケットに追加されます。
Outbound packets SHOULD continue to use the old SRTP master key for 250 ms after sending any new key in a FullEKTField value. This gives all the receivers in the system time to get the new key before they start receiving media encrypted with the new key. (The specific value of 250 ms is chosen to represent a reasonable upper bound on the amount of latency and jitter that is tolerable in a real-time context.)
発信パケットは、FullektField値で新しいキーを送信した後、250ミリ秒で古いSRTPマスターキーを使用し続けるべきです。これにより、新しいキーを使用して暗号化されたメディアの受信を開始する前に、新しいキーを取得する前に、システム時間内にすべての受信機が得られます。（250 msの特定の値は、リアルタイムのコンテキストで許容される待ち時間およびジッタの妥当な上限を表すように選択されます。）
When receiving a packet on an RTP stream, the following steps are applied for each received SRTP packet.
RTPストリーム上のパケットを受信すると、受信した各SRTPパケットに対して以下のステップが適用される。
1. The final byte is checked to determine which EKT format is in use. When an SRTP packet contains a ShortEKTField, the ShortEKTField is removed from the packet and then normal SRTP processing occurs. If the packet contains a FullEKTField, then processing continues as described below. The reason for using the last byte of the packet to indicate the type is that the length of the SRTP part is not known until the decryption has occurred. At this point in the processing, there is no easy way to know where the EKTField would start. However, the whole SRTP packet has been received, so instead of starting at the front of the packet, the parsing works backwards at the end of the packet, and thus the type is placed at the very end of the packet.
1. 最後のバイトは、どのEKTフォーマットが使用されているかを判断するためにチェックされます。SRTPパケットがShortektFieldを含む場合、ShortektFieldはパケットから削除され、通常のSRTP処理が行われます。パケットにFullektFieldが含まれている場合、処理は以下のように続行されます。タイプを示すためにパケットの最後のバイトを使用する理由は、復号化が発生するまでSRTP部分の長さがわからないことです。処理中のこの時点で、EktFieldがどこに起動するかを知る簡単な方法はありません。ただし、SRTPパケット全体が受信されているので、パケットの前面から始める代わりに、解析はパケットの最後で後方に動作し、したがって型はパケットの最後に配置されます。
2. The Security Parameter Index (SPI) field is used to find the right EKT parameter set to be used for processing the packet. If there is no matching SPI, then the verification function MUST return an indication of authentication failure, and the steps described below are not performed. The EKT parameter set contains the EKTKey, the EKTCipher, and the SRTP master salt.
2. セキュリティパラメータインデックス（SPI）フィールドは、パケットの処理に使用されるべき正しいEKTパラメータセットを見つけるために使用されます。一致するSPIがない場合、検証機能は認証失敗の指示を返す必要があり、以下の手順は実行されません。EKTパラメータセットには、Ektkey、EktCipher、およびSRTPマスターソルトが含まれています。
3. The EKTCiphertext is authenticated and decrypted, as described in Section 4.4, using the EKTKey and EKTCipher found in the previous step. If the EKT decryption operation returns an authentication failure, then EKT processing MUST be aborted. The receiver SHOULD discard the whole SRTP packet.
3. EktCipherTextは、前のステップで見つかったEktkeyとEktCipherを使用して、4.4節で説明されているように、認証および復号化されています。EKT復号化操作が認証失敗を返す場合、EKT処理は中止されなければなりません。受信機はSRTPパケット全体を破棄する必要があります。
4. The resulting EKTPlaintext is parsed as described in Section 4.1, to recover the SRTP master key, SSRC, and ROC fields. The SRTP master salt that is associated with the EKTKey is also retrieved. If the value of the srtp_master_salt (see Section 5.2.2) sent as part of the EKTKey is longer than needed by SRTP, then it is truncated by taking the first N bytes from the srtp_master_salt field.
4. 結果のEktpleAntextは、SRTPマスターキー、SSRC、およびROCフィールドを回復するために、4.1項で説明されているように解析されます。Ektkeyに関連付けられているSRTPマスターソルトも取得されます。Ektkeyの一部として送信されたsrtp_master_salt（セクション5.2.2参照）の値がSRTPによって必要以上に長い場合は、SRTP_MASTER_SALTフィールドから最初のNバイトを取得することで切り捨てられます。
5. If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet received, then this FullEKTField MUST be discarded and the subsequent steps in this list skipped. After stripping the FullEKTField, the remainder of the SRTP packet MAY be processed as normal.
5. EktpleintextのSSRCが受信されたSRTPパケットのSSRCと一致しない場合、このFullektFieldは破棄され、このリストの後続の手順をスキップする必要があります。FullektFieldを削除した後、残りのSRTPパケットは通常として処理されてもよい。
6. The SRTP master key, ROC, and SRTP master salt from the previous steps are saved in a map indexed by the SSRC found in the EKTPlaintext and can be used for any future crypto operations on the inbound packets with that SSRC.
6. 前の手順からのSRTPマスターキー、ROC、およびSRTPマスターソルトは、EktpleAntextにあるSSRCによって索引付けされたマップに保存され、そのSSRCの受信パケットの将来の暗号操作に使用できます。
* Unless the transform specifies other acceptable key lengths, the length of the SRTP master key MUST be the same as the master key length for the SRTP transform in use. If this is not the case, then the receiver MUST abort EKT processing and SHOULD discard the whole SRTP packet.
* 変換が他の許容できるキー長を指定しない限り、SRTPマスターキーの長さは使用中のSRTP変換のマスターキー長と同じでなければなりません。そうでない場合、受信機はEKT処理を中止し、SRTPパケット全体を破棄する必要があります。
* If the length of the SRTP master key is less than the master key length for the SRTP transform in use and the transform specifies that this length is acceptable, then the SRTP master key value is used to replace the first bytes in the existing master key. The other bytes remain the same as in the old key. For example, the double GCM transform [RFC8723] allows replacement of the first ("end-to-end") half of the master key.
* 使用中のSRTP変換のSRTPトランスフォームのマスターキー長より小さい場合、この長さが許容できることを指定すると、SRTPマスターキーの値が既存のマスターキーの最初のバイトを置き換えるために使用されます。他のバイトは古いキーと同じままです。たとえば、Double GCM変換[RFC8723]は、マスターキーの最初の（「エンドツーエンド」）の半分を置き換えることができます。
7. At this point, EKT processing has successfully completed, and the normal SRTP processing takes place.
7. この時点で、EKT処理は成功しましたが、通常のSRTP処理が行われます。
The value of the EKTCiphertext field is identical in successive packets protected by the same EKT parameter set, SRTP master key, and ROC. SRTP senders and receivers MAY cache an EKTCiphertext value to optimize processing in cases where the master key hasn't changed. Instead of encrypting and decrypting, senders can simply copy the precomputed value and receivers can compare a received EKTCiphertext to the known value.
EktCipherTextフィールドの値は、同じEKTパラメータセット、SRTPマスターキー、およびROCによって保護された連続したパケットで同じです。SRTP送信者および受信者は、マスターキーが変更されていない場合に処理を最適化するためにEktCipherText値をキャッシュすることができる。暗号化および復号化の代わりに、送信者は事前計算値をコピーすることができ、受信者は受信したEKTCipherTextを既知の値と比較することができます。
Section 4.3.1 recommends that SRTP senders continue using an old key for some time after sending a new key in an EKT Tag. Receivers that wish to avoid packet loss due to decryption failures MAY perform trial decryption with both the old key and the new key, keeping the result of whichever decryption succeeds. Note that this approach is only compatible with SRTP transforms that include integrity protection.
セクション4.3.1は、EKTタグで新しいキーを送信した後しばらくの間、SRTP送信側が古いキーを使用し続けることをお勧めします。復号化の失敗によるパケット損失を回避したい受信機は、古いキーと新しいキーの両方で試行復号化を実行し、その結果を復号化した結果を成功させる可能性があります。このアプローチは、Integrity Protectionを含むSRTP変換とのみ互換性があります。
When receiving a new EKTKey, implementations need to use the ekt_ttl field (see Section 5.2.2) to create a time after which this key cannot be used, and they also need to create a counter that keeps track of how many times the key has been used to encrypt data, to ensure that it does not exceed the T value for that cipher (see Section 4.4). If either of these limits is exceeded, the key can no longer be used for encryption. At this point, implementations need to either use call signaling to renegotiate a new session or terminate the existing session. Terminating the session is a reasonable implementation choice because these limits should not be exceeded, except under an attack or error condition.
新しいEktkeyを受信すると、実装はEKT_TTLフィールド（セクション5.2.2を参照）を使用してこのキーを使用できない時間を作成する必要があります。また、キーの回数を追跡するカウンタも作成する必要があります。データを暗号化するために使用され、その暗号のT値を超えないようにします（セクション4.4を参照）。これらの制限のどちらかを超えると、キーは暗号化に使用できなくなります。この時点で、実装は、新しいセッションを再ネゴシエートするか既存のセッションを終了するために呼び出しシグナリングを使用する必要があります。セッションを終了するのは、攻撃やエラー状態の下では、これらの制限を超えてはいけませんので、合理的な実装の選択です。
EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. This specification defines the interface to the cipher, in order to abstract the interface away from the details of that function. This specification also defines the default cipher that is used in EKT. The default cipher described in Section 4.4.1 MUST be implemented, but another cipher that conforms to this interface MAY be used. The cipher used for a given EKTCiphertext value is negotiated using the supported_ekt_ciphers extension (see Section 5.2) and indicated with the SPI value in the FullEKTField.
EKTは認証された暗号を使用してEktpleAntextを暗号化して認証します。この仕様は、その機能の詳細からインターフェイスを抽象化するために、暗号へのインタフェースを定義します。この仕様は、EKTで使用されるデフォルト暗号も定義しています。セクション4.4.1で説明されているデフォルトの暗号を実装する必要がありますが、このインターフェイスに適合する別の暗号を使用できます。特定のEktCipherText値に使用される暗号は、supported_ekt_ciphers拡張子を使用してネゴシエートされ（セクション5.2を参照）、FullektFieldのSPI値で示されます。
An EKTCipher consists of an encryption function and a decryption function. The encryption function E(K, P) takes the following inputs:
EktCiphiceは暗号化機能と復号化機能で構成されています。暗号化関数E（k、p）は次の入力を取ります。
* a secret key K with a length of L bytes, and
* Lバイトの長さの秘密鍵Kと
* a plaintext value P with a length of M bytes.
* 長さのmバイトの平文値p。
The encryption function returns a ciphertext value C whose length is N bytes, where N may be larger than M. The decryption function D(K, C) takes the following inputs:
暗号化関数は、その長さがnバイトである暗号文値cを返し、ここでnはMより大きくてもよい。復号機能D（k、c）は以下の入力をとる。
* a secret key K with a length of L bytes, and
* Lバイトの長さの秘密鍵Kと
* a ciphertext value C with a length of N bytes.
* nバイトの長さの暗号文の値c。
The decryption function returns a plaintext value P that is M bytes long, or it returns an indication that the decryption operation failed because the ciphertext was invalid (i.e., it was not generated by the encryption of plaintext with the key K).
復号化関数は、mバイトの平文値pを返し、暗号文が無効であるために復号化操作が失敗したという指示を返します（すなわち、鍵kで平文の暗号化によって生成されなかった）。
These functions have the property that D(K, E(K, P)) = P for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used for encryption more than T times. Note that if the same FullEKTField is retransmitted three times, that only counts as one encryption.
これらの関数は、kおよびpのすべての値に対してd（k、e（k、p））= pがあるという性質を有する。各暗号は、それがいかなる固定鍵値で使用できる回数も制限tを有する。EktkeyはT回以上の暗号化に使用しないでください。同じFullektFieldが3回再送信される場合、1つの暗号化としてのみカウントされます。
Security requirements for EKT Ciphers are discussed in Section 6.
EKT暗号化のためのセキュリティ要件については、第6章で説明します。
The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding algorithm [RFC5649]. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. It can be used with key sizes of L = 16 octets or L = 32 octets, and its use with those key sizes is indicated as AESKW128 or AESKW256, respectively. The key size determines the length of the AES key used by the Key Wrap algorithm. With this cipher, T=2^(48).
デフォルトのEKT暗号は、パディングアルゴリズム[RFC5649]を備えた高度な暗号化標準（AES）キーラップです。それは少なくとも1つのオクテットの平文長さmを必要とし、長さn = m（m mod 8）8オクテットの暗号文を返します。L = 16オクテットまたはL = 32オクテットのキーサイズで使用でき、それらのキーサイズとの使用はそれぞれAESKW128またはAESKW256として示されています。キーサイズは、キーラップアルゴリズムによって使用されるAESキーの長さを決定します。この暗号を使用すると、t = 2 ^（48）。
+==========+====+========+
| Cipher | L | T |
+==========+====+========+
| AESKW128 | 16 | 2^(48) |
+----------+----+--------+
| AESKW256 | 32 | 2^(48) |
+----------+----+--------+
Table 1: EKT Ciphers
表1：EKT暗号
As AES-128 is the mandatory-to-implement transform in SRTP, AESKW128 MUST be implemented for EKT. AESKW256 MAY be implemented.
AES-128がSRTPの必須の実装変換であるため、AESKW128はEKT用に実装されなければなりません。AESKW256が実施されてもよい。
Other specifications may extend this document by defining other EKTCiphers, as described in Section 7. This section defines how those ciphers interact with this specification.
その他の仕様は、セクション7に記載されているように、他のEktciphersを定義することによってこの文書を拡張することができます。このセクションでは、それらの暗号との対話方法を定義します。
An EKTCipher determines how the EKTCiphertext field is written and how it is processed when it is read. This field is opaque to the other aspects of EKT processing. EKT Ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. The values of the parameters L and T MUST be defined by each EKTCipher. The cipher MUST provide integrity protection.
EktCipherは、EktCipherTextフィールドの書き込み方法と、読み取られたときにどのように処理されるかを決定します。このフィールドはEKT処理の他の側面に不透明です。EKT暗号は任意の方法でこのフィールドを使用できますが、入力として他のEKTまたはSRTPフィールドを使用しないでください。パラメータLおよびTの値は、各EktCipherによって定義されなければなりません。暗号は完全性保護を提供しなければなりません。
If a source has its EKTKey changed by key management, it MUST also change its SRTP master key, which will cause it to send out a new FullEKTField and eventually begin encrypting with it, as described in Section 4.3.1. This ensures that if key management thought the EKTKey needs changing (due to a participant leaving or joining) and communicated that to a source, the source will also change its SRTP master key, so that traffic can be decrypted only by those who know the current EKTKey.
ソースにEKTKEYがキー管理によって変更された場合は、セクション4.3.1で説明されているように、SRTPマスターキーもそのSRTPマスターキーを変更する必要があります。これにより、鍵管理がEktkeyが（参加者の退席または参加または参加している）が変更され、それをソースに伝達する必要があると考えられるように、ソースはそのSRTPマスターキーも変更されます。Ektkey。
A system using EKT learns the SRTP master keys distributed with the FullEKTField sent with SRTP, rather than with call signaling. A receiver can immediately decrypt an SRTP packet, provided the SRTP packet contains a FullEKTField.
EKTを使用するシステムは、呼シグナリングではなく、SRTPで送信されたFullektFieldで配布されたSRTPマスターキーを学習します。SRTPパケットがFullektFieldを含む場合、受信機は直ちにSRTPパケットを復号化することができる。
This section describes how to reliably and expediently deliver new SRTP master keys to receivers.
このセクションでは、Receiversに新しいSRTPマスターキーを確実かつ便利に提供する方法について説明します。
There are three cases to consider. In the first case, a new sender joins a session and needs to communicate its SRTP master key to all the receivers. In the second case, a sender changes its SRTP master key, which needs to be communicated to all the receivers. In the third case, a new receiver joins a session already in progress and needs to know the sender's SRTP master key.
考慮すべき3つのケースがあります。最初のケースでは、新しい送信者がセッションに参加し、そのSRTPマスターキーをすべての受信機に通信する必要があります。2番目のケースでは、送信者はそのSRTPマスターキーを変更します。これはすべての受信機に伝達される必要があります。3番目のケースでは、新しい受信側がすでに進行中のセッションを結合し、送信者のSRTPマスターキーを知る必要があります。
The three cases are as follows:
3つのケースは次のとおりです。
New sender: A new sender SHOULD send a packet containing the FullEKTField as soon as possible, ideally in its initial SRTP packet. To accommodate packet loss, it is RECOMMENDED that the FullEKTField be transmitted in three consecutive packets. If the sender does not send a FullEKTField in its initial packets and receivers have not otherwise been provisioned with a decryption key, then decryption will fail and SRTP packets will be dropped until the receiver receives a FullEKTField from the sender.
新しい送信者：新しい送信者は、FullektFieldを含むパケットをできるだけ早く、理想的には初期SRTPパケットに送信する必要があります。パケット損失に対応するために、FullektFieldは3つの連続したパケットで送信されることをお勧めします。送信者が最初のパケットにFulleKtFieldを送信しない場合、受信者が復号化キーでプロビジョニングされていない場合、復号化は失敗し、SRTPパケットは送信者からFullektFieldを受信するまでSRTPパケットが削除されます。
Rekey: By sending an EKT Tag over SRTP, the rekeying event shares fate with the SRTP packets protected with that new SRTP master key. To accommodate packet loss, it is RECOMMENDED that three consecutive packets containing the FullEKTField be transmitted.
Rekey：SRTPを介してEKTタグを送信することによって、Rekingイベントはその新しいSRTPマスターキーで保護されているSRTPパケットと共有します。パケット損失に対応するために、FullektFieldを含む3つの連続したパケットを送信することをお勧めします。
New receiver: When a new receiver joins a session, it does not need to communicate its sending SRTP master key (because it is a receiver). Also, when a new receiver joins a session, the sender is generally unaware of the receiver joining the session; thus, senders SHOULD periodically transmit the FullEKTField. That interval depends on how frequently new receivers join the session, the acceptable delay before those receivers can start processing SRTP packets, and the acceptable overhead of sending the FullEKTField. If sending audio and video, the RECOMMENDED frequency is the same as the rate of intra-coded video frames. If only sending audio, the RECOMMENDED frequency is every 100 ms.
新しい受信機：新しい受信側がセッションに参加すると、送信SRTPマスターキーを通信する必要はありません（受信者であるため）。また、新しい受信側がセッションに参加すると、送信者は一般にセッションに参加する受信側に認識されません。したがって、送信者はFullektFieldを定期的に送信する必要があります。その間隔は、新しい受信機がセッションに参加する頻度、それらの受信者の処理がSRTPパケットの処理を開始する前の許容遅延、およびFulleKtFieldを送信することができる過度の遅延に依存します。オーディオとビデオを送信すると、推奨される周波数は符号化されたビデオフレームのレートと同じです。オーディオのみを送信する場合は、推奨周波数は100 msごとです。
If none of the above three cases apply, a ShortEKTField SHOULD be sent.
上記の3つのケースのどれも適用されない場合は、ShortektFieldを送信する必要があります。
In general, sending FullEKTField tags less frequently will consume less bandwidth but will increase the time it takes for a join or rekey to take effect. Applications should schedule the sending of FullEKTField tags in a way that makes sense for their bandwidth and latency requirements.
一般に、FullektFieldタグを送信することは頻繁に頻繁に帯域幅を消費しますが、結合や再生が有効になるのにかかる時間が長くなります。アプリケーションは、それらの帯域幅および待ち時間の要件を理解するような方法でFullektFieldタグの送信をスケジュールする必要があります。
This document defines an extension to DTLS-SRTP called "SRTP EKTKey Transport", which enables secure transport of EKT keying material from the DTLS-SRTP peer in the server role to the client. This allows such a peer to process EKT keying material in SRTP and retrieve the embedded SRTP keying material. This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multi-party RTP with loose coordination and efficient communication of per-source keys.
このドキュメントは、「srtp ektkey transport」というDTLS-SRTPへの拡張子を定義します。これにより、サーバーの役割のDTLS-SRTPピアからクライアントへのEKTキーインピータイヤーの安全なトランスポートができます。これにより、このようなピアはSRTP内のEKTキーイングマテリアルを処理し、埋め込みSRTPキーイングマテリアルを検索することができます。このプロトコルの組み合わせは、エンドポイントと柔軟性の強い認証を持つDTLの利点と、ソースごとのキーの効率的な通信を可能にするとともに、エンドポイントと柔軟性の高さを兼ね備えているため、価値があります。
In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT keying material can allow EKT Keys to be tunneled through an untrusted relay such as a centralized conference bridge. For more details, see [RFC8871].
DTLS終端点がメディアリレーよりも信頼されている場合、DTLSがEKTキーイング材料に与える保護は、集中会議ブリッジのような信頼できないリレーを通してEKTキーをトンネリングすることを可能にすることができる。詳細については、[RFC8871]を参照してください。
DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers to exchange keying material, algorithms, and parameters for SRTP. The SRTP flow operates over the same transport as the DTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP 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 as a new RTP-specific data format for DTLS.
DTLS-SRTP [RFC5764]は、2つのピア間で拡張DTLS Exchangeを使用して、SRTPのキーイングマテリアル、アルゴリズム、およびパラメータを交換します。SRTPフローは、DTLS-SRTP交換（すなわち、同じ5タプル）と同じトランスポートで動作します。DTLS-SRTPは、SRTPのパフォーマンスと暗号化の柔軟性の利点を、DTLS統合キーと関連管理の柔軟性と利便性を兼ね備えています。DTLS-SRTPは、SRTPの新しいキー管理方法として、およびDTLSの新しいRTP固有のデータ形式としての2つの同等の方法で表示できます。
This document defines a new TLS negotiated extension called "supported_ekt_ciphers" and a new TLS handshake message type called "ekt_key". The extension negotiates the cipher to be used in encrypting and decrypting EKTCiphertext values, and the handshake message carries the corresponding key.
このドキュメントは、 "supported_ekt_ciphers"という名前の新しいTLSネゴシエートされた拡張子と "ekt_key"という名前の新しいTLSハンドシェイクメッセージタイプを定義しています。拡張子は、EktCipheText値の暗号化と復号化に使用される暗号を交渉し、ハンドシェイクメッセージは対応するキーを搬送します。
Figure 4 shows a message flow between a DTLS 1.3 client and server using EKT configured using the DTLS extensions described in this section. (The initial cookie exchange and other normal DTLS messages are omitted.) To be clear, EKT can be used with versions of DTLS prior to 1.3. The only difference is that in pre-1.3 TLS, stacks will not have built-in support for generating and processing ACK messages.
図4は、このセクションで説明されているDTLS拡張機能を使用して構成されたEKTを使用したDTLS 1.3クライアントとサーバー間のメッセージフローを示しています。（最初のCookie Exchangeおよび他の通常のDTLSメッセージは省略されています。）明確にするには、1.3より前のDTLSのバージョンでEKTを使用できます。唯一の違いは、前に1.3 TLSで、ACKメッセージを生成し処理するためのスタックにスタックが内蔵されていないことです。
Client Server
クライアントサーバー
ClientHello
+ use_srtp
+ supported_ekt_ciphers
-------->
ServerHello
{EncryptedExtensions}
+ use_srtp
+ supported_ekt_ciphers
{... Finished}
<--------
{... Finished} -------->
[ACK]
<-------- [EKTKey]
[ACK] -------->
|SRTP packets| <-------> |SRTP packets|
+ <EKT Tags> + <EKT Tags>
{} Messages protected using DTLS handshake keys
DTLSハンドシェイクキーを使用して保護されているメッセージ
[] Messages protected using DTLS application traffic keys
[] DTLSアプリケーショントラフィックキーを使用して保護されているメッセージ
<> Messages protected using the EKTKey and EKT Cipher
<> EKTKEYおよびEKT暗号を使用して保護されたメッセージ
|| Messages protected using the SRTP master key sent in a Full EKT Tag
Figure 4: DTLS 1.3 Message Flow
図4：DTLS 1.3メッセージフロー
In the context of a multi-party SRTP session in which each endpoint performs a DTLS handshake as a client with a central DTLS server, the extensions defined in this document allow the DTLS server to set a common EKTKey for all participants. Each endpoint can then use EKT Tags encrypted with that common key to inform other endpoints of the keys it uses to protect SRTP packets. This avoids the need for many individual DTLS handshakes among the endpoints, at the cost of preventing endpoints from directly authenticating one another.
各エンドポイントがCentral DTLSサーバーを持つクライアントとしてDTLSハンドシェイクを実行するマルチパーティSRTPセッションのコンテキストでは、このドキュメントで定義されている拡張機能により、DTLSサーバーはすべての参加者に共通のEKTKEYを設定できます。各エンドポイントは、その共通鍵で暗号化されたEKTタグを使用して、SRTPパケットの保護に使用するキーの他のエンドポイントに通知できます。これにより、エンドポイントの中でエンドポイントの中で多くの個々のDTLSハンドシェイクが必要とされることが回避されます。エンドポイントが直接認証されるのを防ぐために。
Client A Server Client B
クライアントサーバークライアントB
<----DTLS Handshake---->
<--------EKTKey---------
<----DTLS Handshake---->
---------EKTKey-------->
-------------SRTP Packet + EKT Tag------------->
<------------SRTP Packet + EKT Tag--------------
To indicate its support for EKT, a DTLS-SRTP client includes in its ClientHello an extension of type supported_ekt_ciphers listing the ciphers used for EKT by the client, in preference order, with the most preferred version first. If the server agrees to use EKT, then it includes a supported_ekt_ciphers extension in its EncryptedExtensions (or ServerHello for DTLS 1.2) containing a cipher selected from among those advertised by the client.
EKTのサポートを示すために、DTLS-SRTPクライアントには、ClientHelloにClientHelloが含まれています。サーバーがEKTを使用することに同意した場合、それはクライアントによって広告されたものの中から選択された暗号化された暗号化された暗号化された文字（またはDTLS 1.2のServerHello）のSupported_EKT_CIPHERS拡張子を含みます。
The extension_data field of this extension contains an "EKTCipher" value, encoded using the syntax defined in [RFC8446]:
この拡張子のextension_dataフィールドには、[RFC8446]で定義されている構文を使用してエンコードされた "EktCipher"値が含まれています。
enum {
reserved(0),
aeskw_128(1),
aeskw_256(2),
} EKTCipherType;
struct {
select (Handshake.msg_type) {
case client_hello:
EKTCipherType supported_ciphers<1..255>;
case server_hello: EKTCipherType selected_cipher;
case server_hello：EktCipherType selected_cipher;
case encrypted_extensions: EKTCipherType selected_cipher;
case encrypted_extensions：EKTCipherType selected_cipher;
};
} EKTCipher;
Once a client and server have concluded a handshake that negotiated an EKTCipher, the server MUST provide to the client a key to be used when encrypting and decrypting EKTCiphertext values. EKTKeys are sent in encrypted handshake records, using handshake type ekt_key(26). The body of the handshake message contains an EKTKey structure as follows:
クライアントとサーバーがEktCiphiperをネゴシエートしたハンドシェイクを締めくくら、サーバーはEktCipheText値を暗号化および復号化するときに使用されるキーをクライアントに提供する必要があります。EKTKEYSは、ハンドシェイクタイプEKT_KEY（26）を使用して、暗号化ハンドシェイクレコードで送信されます。ハンドシェイクメッセージの本体には、次のようなEKTKEY構造が含まれています。
struct {
opaque ekt_key_value<1..256>;
opaque srtp_master_salt<1..256>;
uint16 ekt_spi;
uint24 ekt_ttl;
} EKTKey;
The contents of the fields in this message are as follows:
このメッセージ内のフィールドの内容は次のとおりです。
ekt_key_value The EKTKey that the recipient should use when generating EKTCiphertext values
ekt_key_value ektCipherText値を生成するときに受信者が使用するべきEKTKEY
srtp_master_salt The SRTP master salt to be used with any master key encrypted with this EKT Key
SRTP_MASTER_SALTこのEKTキーで暗号化されたマスターキーで使用されるSRTPマスターソルト
ekt_spi The SPI value to be used to reference this EKTKey and SRTP master salt in EKT Tags (along with the EKT Cipher negotiated in the handshake)
EKT_SPI EKTキーとSRTPマスターソルトの参照に使用されるSPI値（ハンドシェイクで交渉されたEKT暗号と共に）
ekt_ttl The maximum amount of time, in seconds, that this EKTKey can be used. The ekt_key_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
EKT_TTLこのEKTKEYを使用できる最大時間（秒単位）。このメッセージ内のEKT_KEY_VALUEは、TTLが期限切れになった後に情報を暗号化または復号化するために使用してはいけません。
If the server did not provide a supported_ekt_ciphers extension in its EncryptedExtensions (or ServerHello for DTLS 1.2), then EKTKey messages MUST NOT be sent by the client or the server.
サーバーがEncryptedExtensions（またはDTLS 1.2のServerHello）でサポートされている_ekt_ciphers拡張機能を提供しなかった場合、Ektkeyメッセージはクライアントまたはサーバーによって送信されてはいけません。
When an EKTKey is received and processed successfully, the recipient MUST respond with an ACK message as described in Section 7 of [TLS-DTLS13]. The EKTKey message and ACK MUST be retransmitted following the rules of the negotiated version of DTLS.
EKTKEYが正常に受信されて処理されると、[TLS-DTLS13]のセクション7で説明されているように受信者はACKメッセージで応答する必要があります。EktkeyメッセージとACKは、NegotiatedバージョンのDTLSの規則に従って再送信されなければなりません。
EKT MAY be used with versions of DTLS prior to 1.3. In such cases, to provide reliability, the ACK message is still used. Thus, DTLS implementations supporting EKT with pre-1.3 versions of DTLS will need to have explicit affordances for sending the ACK message in response to an EKTKey message and for verifying that an ACK message was received. The retransmission rules for both sides are otherwise defined by the negotiated version of DTLS.
EKTは1.3より前のDTLSのバージョンで使用されることがあります。そのような場合、信頼性を提供するために、ACKメッセージはまだ使用されています。したがって、EKTをサポートするDTLS実装DTLSのバージョンのDTLSをサポートするDTLは、EKTKEYメッセージに応答してACKメッセージを送信し、ACKメッセージが受信されたことを検証するための明示的な強度を持つ必要があります。両側の再送信規則は、NegotiatedバージョンのDTLSによって定義されます。
If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert.
処理できないEKTKEYメッセージを受信した場合、受信者は適切なDTLSアラートで応答する必要があります。
When using EKT with DTLS-SRTP, the negotiation to use EKT is done at the DTLS handshake level and does not change the SDP Offer/Answer messaging [RFC3264].
DTLS-SRTPでEKTを使用する場合、EKTを使用するためのネゴシエーションはDTLSハンドシェイクレベルで行われ、SDPオファー/アンサーメッセージング[RFC3264]を変更しません。
The DTLS EKTKey message is sent using the retransmissions specified in Section 4.2.4 of DTLS [RFC6347]. Retransmission is finished with an ACK message, or an alert is received.
DTLS EKTKEYメッセージは、DTLS [RFC6347]のセクション4.2.4で指定された再送信を使用して送信されます。再送はACKメッセージで終了し、またはアラートが受信されます。
EKT inherits the security properties of the key management protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP extension defined in this document.
EKTは、このドキュメントで定義されたEKTKEY、例えばDTLS-SRTP拡張機能を確立するために使用される鍵管理プロトコルのセキュリティプロパティを継承します。
With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property avoids any security concerns over the reuse of keys, by empowering the SRTP layer to create keys on demand. Note that the inputs of EKT are the same as for SRTP with key-sharing: a single key is provided to protect an entire SRTP session. However, EKT remains secure even when SSRC values collide.
EKTでは、各SRTP送信者と受信者は異なるSRTPマスターキーを生成する必要があります。このプロパティは、SRTPレイヤーをオンデマンドで作成するためにSRTPレイヤーを作成することによって、鍵の再利用に関するセキュリティ上の懸念を回避します。EKTの入力は、鍵共有を伴うSRTPと同じです.SRTPセッション全体を保護するための単一のキーが提供されています。ただし、SSRC値が衝突してもEKTは安全です。
SRTP master keys MUST be randomly generated, and [RFC4086] offers some guidance about random number generation. SRTP master keys MUST NOT be reused for any other purpose, and SRTP master keys MUST NOT be derived from other SRTP master keys.
SRTPマスターキーはランダムに生成されなければならず、[RFC4086]は乱数生成に関するいくつかのガイダンスを提供します。SRTPマスターキーは他の目的のために再利用されてはならず、SRTPマスターキーは他のSRTPマスターキーから派生してはいけません。
The EKT Cipher includes its own authentication/integrity check.
EKT暗号には独自の認証/整合性チェックが含まれています。
The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another SRTP stream. This mitigates the impact of cut-and-paste attacks that arise due to the lack of a cryptographic binding between the EKT Tag and the rest of the SRTP packet. SRTP tags can only be cut-and-pasted within the stream of packets sent by a given RTP endpoint; an attacker cannot "cross the streams" and use an EKT Tag from one SSRC to reset the key for another SSRC. The Epoch field in the FullEKTField also prevents an attacker from rolling back to a previous key.
EktpleAntext内のSSRCの存在は、攻撃者が1つのSRTPストリームから別のSRTPストリームにEktCipherTextを置換できないことを保証します。これにより、EKTタグと他のSRTPパケットとの間の暗号化バインディングがないために発生するカットアンドペースト攻撃の影響を軽減します。SRTPタグは、特定のRTPエンドポイントによって送信されたパケットのストリーム内でのみカットアンドペーストできます。攻撃者は「ストリームを渡る」ことはできず、あるSSRCからEKTタグを使用して別のSSRCのキーをリセットします。FullektFieldのエポックフィールドはまた、攻撃者が前のキーに転がるのを防ぎます。
An attacker could send packets containing a FullEKTField, in an attempt to consume additional CPU resources of the receiving system by causing the receiving system to decrypt the EKT ciphertext and detect an authentication failure. In some cases, caching the previous values of the ciphertext as described in Section 4.3.2 helps mitigate this issue.
攻撃者は、受信システムにEKT暗号文を復号化させ、認証失敗を検出させることによって、受信システムの追加のCPUリソースを消費しようとする試みで、FullektFieldを含むパケットを送信することができる。場合によっては、セクション4.3.2に記載されているように、CipherTextの以前の値をキャッシュすると、この問題を軽減できます。
In a similar vein, EKT has no replay protection, so an attacker could implant improper keys in receivers by capturing EKTCiphertext values encrypted with a given EKTKey and replaying them in a different context, e.g., from a different sender. When the underlying SRTP transform provides integrity protection, this attack will just result in packet loss. If it does not, then it will result in random data being fed to RTP payload processing. An attacker that is in a position to mount these attacks, however, could achieve the same effects more easily without attacking EKT.
同様の静脈では、EKTは再生保護はありませんので、攻撃者は特定のEktkeyで暗号化されたEktCiphyText値をキャプチャし、異なる送信者からの異なるコンテキストでそれらを再生することによって、受信機で不適切なキーをインプラントすることができます。基礎となるSRTP変換が完全性保護を提供するとき、この攻撃はパケットの損失をもたらすだけです。そうでなければ、RTPペイロード処理にランダムなデータが供給されます。しかしながら、これらの攻撃を取り付ける立場にある攻撃者は、EKTを攻撃することなく同じ効果をより簡単に達成することができる。
The key encryption keys distributed with EKTKey messages are group shared symmetric keys, which means they do not provide protection within the group. Group members can impersonate each other; for example, any group member can generate an EKT Tag for any SSRC. The entity that distributes EKTKeys can decrypt any keys distributed using EKT and thus any media protected with those keys.
Ektkeyメッセージで配布されたキー暗号化キーは、グループ共有対称キーです。これは、それらがグループ内で保護を提供しないことを意味します。グループメンバーはお互いに偽装することができます。たとえば、任意のグループメンバーは任意のSSRCのEKTタグを生成できます。EKTKEYSを配布するエンティティは、EKTとしたがってこれらのキーで保護されているメディアを使用して配布されたキーを復号化できます。
Each EKT Cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 5.2.
各EKT暗号は、特定のキーを使用できる最大回数である値Tを指定します。エンドポイントは、同じEKTKEYを使用してTの異なるFullektField値を暗号化してはいけません。さらに、EKTKEYは、セクション5.2で説明されているTTLによって提供されるLifeTimeを超えて使用されてはならない。
The key length of the EKT Cipher MUST be at least as long as the SRTP cipher and at least as long as the DTLS-SRTP ciphers.
EKT暗号の鍵長は、少なくともSRTP暗号でなければならず、少なくともDTLS-SRTPが暗号化されている必要があります。
Part of the EKTPlaintext is known or is easily guessable to an attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. In practice, this requirement does not impose any restrictions on our choices, since the ciphers in use provide high security even when much plaintext is known.
EktpleAntextの一部は既知または攻撃者に簡単に推測可能です。したがって、EKT暗号は既知の平文攻撃に抵抗する必要があります。実際には、この要件は、使用中の暗号が知られている場合でも、使用する暗号化が高いセキュリティを提供するため、この要件は私たちの選択に制限を課しません。
An EKT Cipher MUST resist attacks in which both ciphertexts and plaintexts can be adaptively chosen by an attacker querying both the encryption and decryption functions.
EKT暗号は、暗号化関数と復号化関数の両方を問い合わせる攻撃者によって暗号文と平文の両方を適応的に選択できる攻撃に耐える必要があります。
In some systems, when a member of a conference leaves the conference, that conference is rekeyed so that the member who left the conference no longer has the key. When changing to a new EKTKey, it is possible that the attacker could block the EKTKey message getting to a particular endpoint and that endpoint would keep sending media encrypted using the old key. To mitigate that risk, the lifetime of the EKTKey MUST be limited by using the ekt_ttl.
一部のシステムでは、会議のメンバーが会議を離れたときに、その会議は再確認され、会議を残したメンバーがもう鍵がありません。新しいEktkeyに変更すると、攻撃者が特定のエンドポイントに到達するEKTKEYメッセージをブロックし、そのエンドポイントが古いキーを使用して暗号化されたメディアを送信し続ける可能性があります。そのリスクを軽減するには、EKTKEYの寿命はekt_ttlを使用することによって制限されなければなりません。
IANA has created a new table for "EKT Message Types" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are as follows:
IANAは、「リアルタイムトランスポートプロトコル（RTP）パラメータ」レジストリの「EKTメッセージタイプ」の新しいテーブルを作成しました。このレジストリの初期値は次のとおりです。
+==============+=======+===============+
| Message Type | Value | Specification |
+==============+=======+===============+
| Short | 0 | RFC 8870 |
+--------------+-------+---------------+
| Unassigned | 1 | |
+--------------+-------+---------------+
| Full | 2 | RFC 8870 |
+--------------+-------+---------------+
| Unassigned | 3-254 | |
+--------------+-------+---------------+
| Reserved | 255 | RFC 8870 |
+--------------+-------+---------------+
Table 2: EKT Message Types
表2：EKTメッセージの種類
New entries in this table can be added via "Specification Required" as defined in [RFC8126]. To avoid conflicts with pre-standard versions of EKT that have been deployed, IANA SHOULD give preference to the allocation of even values over odd values until the even code points are consumed. Allocated values MUST be in the range of 0 to 254.
このテーブルの新規エントリは、[RFC8126]で定義されている「指定必須」を介して追加できます。展開されているEKTの事前標準バージョンとの競合を回避するために、IANAは偶数コードポイントが消費されるまで、奇数値にわたって偶数の値の割り当てを優先する必要があります。割り当て値は0から254の範囲内でなければなりません。
All new EKT messages MUST be defined to include a length parameter, as specified in Section 4.1.
すべての新しいEKTメッセージは、セクション4.1で指定されているように、長さパラメータを含めるように定義する必要があります。
IANA has created a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are as follows:
IANAは、「リアルタイムトランスポートプロトコル（RTP）パラメータ」レジストリの「EKT暗号」の新しいテーブルを作成しました。このレジストリの初期値は次のとおりです。
+============+=======+===============+
| Name | Value | Specification |
+============+=======+===============+
| AESKW128 | 0 | RFC 8870 |
+------------+-------+---------------+
| AESKW256 | 1 | RFC 8870 |
+------------+-------+---------------+
| Unassigned | 2-254 | |
+------------+-------+---------------+
| Reserved | 255 | RFC 8870 |
+------------+-------+---------------+
Table 3: EKT Cipher Types
表3：EKT暗号の種類
New entries in this table can be added via "Specification Required" as defined in [RFC8126]. The expert SHOULD ensure that the specification defines the values for L and T as required in Section 4.4 of this document. Allocated values MUST be in the range of 0 to 254.
このテーブルの新規エントリは、[RFC8126]で定義されている「指定必須」を介して追加できます。エキスパートは、この文書のセクション4.4で必要に応じて、指定がLおよびTの値を定義することを確認する必要があります。割り当て値は0から254の範囲内でなければなりません。
IANA has added supported_ekt_ciphers as a new extension name to the "TLS ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry:
IANAは、「TRS ExtenctType値」という新しい拡張子名として「Transport Layer Security（TLS）拡張機能」レジストリに追加しました。
Value: 39
値：39
Extension Name: supported_ekt_ciphers
拡張子名：supported_ekt_ciphers.
TLS 1.3: CH, EE
TLS 1.3：CH、EE
Recommended: Y
おすすめ：Y
Reference: RFC 8870
参照：RFC 8870
IANA has added ekt_key as a new entry in the "TLS HandshakeType" table of the "Transport Layer Security (TLS) Parameters" registry:
IANAは、「TLS Handshaketype」の「TRS Handshaketype」テーブルとしてEKT_Keyを追加しました。「Transport Layer Security（TLS）パラメータ」レジストリ：
Value: 26
値：26
Description: ekt_key
説明：ekt_key
DTLS-OK: Y
DTLS-OK：Y
Reference: RFC 8870
参照：RFC 8870
Comment:
コメント：
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[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] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[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] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, <https://www.rfc-editor.org/info/rfc5649>.
[RFC5649]ハウスリー、R.およびM. DWIRING、「パディングアルゴリズム付き高度な暗号化標準（AES）キーラップ」、RFC 5649、DOI 10.17487 / RFC5649、2009年9月、<https：//www.rfc-editor.org/情報/ RFC5649>。
[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、セキュアリアルタイムトランスポートプロトコル（SRTP） "、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<HTTPS）：//www.rfc-editor.org/info/rfc5764>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] RESCORLA、E.およびN. MODADUGU、「データグラムトランスポートレイヤセキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.org / info / rfc4086>。
[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, "Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)", RFC 8723, DOI 10.17487/RFC8723, April 2020, <https://www.rfc-editor.org/info/rfc8723>.
[RFC8723]ジェニングニング、C、Jones、P.、Barnes、R.、およびA.B.ROACH、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 8723、DOI 10.17487 / RFC8723、<https://www.rfc-editor.org/info/rfc8723>。
[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, January 2021, <https://www.rfc-editor.org/info/rfc8871>.
[RFC8871] Jones、P.、Benham、D.、C. Groves、「プライバシー強化RTP会議（PERC）」、RFC 8871、DOI 10.17487 / RFC8871、<https：//www.rfc-editor.org/info/rfc8871>。
[TLS-DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-39, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
[TLS-DTLS13] RescoRLA、E.、TSCHOFENIG、H。、およびN. MODADUGU、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-DTLS13-2020年11月2日、<https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>。
Acknowledgments
謝辞
Thank you to Russ Housley, who provided a detailed review and significant help with crafting text for this document. Thanks to David Benham, Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, comments, and contributions to this document.
Russ Housleyを提供していただきありがとうございました。David Benham、Yi Cheng、Lakshminath Dondeti、Kai Fischer、Nermeen Ismail、Paul Jones、Eddy Lem、Jonathan Lennox、Michael Peck、Rob Raymond、Sean Turner、Magnus Westerlund、Felix Westerlund、Felix Wests、Complet Firs Wyssこのドキュメント。
Authors' Addresses
著者の住所
Cullen Jennings Cisco Systems
Cullen Jennings Cisco Systems.
Email: fluffy@iii.ca
John Mattsson Ericsson AB
John Mattsson Ericsson AB.
Email: john.mattsson@ericsson.com
David A. McGrew Cisco Systems
David A. McGrewシスコシステムズ
Email: mcgrew@cisco.com
Dan Wing Citrix Systems, Inc.
Dan Wing Citrix Systems、Inc。
Email: dwing-ietf@fuggles.com
Flemming Andreasen Cisco Systems
Cisco SystemsのFlemming Andreasen.
Email: fandreas@cisco.com