[要約] RFC 9335 は、SRTPのメディアパケットの内容を保護する一方、RTPヘッダー拡張とCSRCなどのメタデータを保護する新しいメカニズムであるCryptexを導入し、展開を容易にすることを目的としています。
Internet Engineering Task Force (IETF) J. Uberti
Request for Comments: 9335
Updates: 3711 C. Jennings
Category: Standards Track Cisco
ISSN: 2070-1721 S. Garcia Murillo
Millicast
January 2023
Completely Encrypting RTP Header Extensions and Contributing Sources
RTPヘッダー拡張機能と寄与源を完全に暗号化します
Abstract
概要
While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations.
安全なリアルタイムトランスポートプロトコル（SRTP）は、メディアパケットの内容の機密性を提供しますが、RTPヘッダー拡張機能や寄稿ソース（CSRC）など、かなりの量のメタデータが保護されていません。ただし、このデータは多くのアプリケーションで適度に感度が高い場合があります。このデータを保護するための以前の試みはありましたが、複雑さと技術的な制限により、展開は限られていました。
This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment.
このドキュメントは、SRTP仕様であるRFC 3711を更新し、Cryptexをヘッダー拡張機能とCSRCを完全に暗号化し、よりシンプルなセッション説明プロトコル（SDP）シグナリングを使用して展開を促進する新しいメカニズムとして定義します。
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/rfc9335.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9335で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2023 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Problem Statement
1.2. Previous Solutions
1.3. Goals
2. Terminology
3. Design
4. SDP Considerations
5. RTP Header Processing
5.1. Sending
5.2. Receiving
6. Encryption and Decryption
6.1. Packet Structure
6.2. Encryption Procedure
6.3. Decryption Procedure
7. Backward Compatibility
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Test Vectors
A.1. AES-CTR
A.1.1. RTP Packet with One-Byte Header Extension
A.1.2. RTP Packet with Two-Byte Header Extension
A.1.3. RTP Packet with One-Byte Header Extension and CSRC
Fields
A.1.4. RTP Packet with Two-Byte Header Extension and CSRC
Fields
A.1.5. RTP Packet with Empty One-Byte Header Extension and
CSRC Fields
A.1.6. RTP Packet with Empty Two-Byte Header Extension and
CSRC Fields
A.2. AES-GCM
A.2.1. RTP Packet with One-Byte Header Extension
A.2.2. RTP Packet with Two-Byte Header Extension
A.2.3. RTP Packet with One-Byte Header Extension and CSRC
Fields
A.2.4. RTP Packet with Two-Byte Header Extension and CSRC
Fields
A.2.5. RTP Packet with Empty One-Byte Header Extension and
CSRC Fields
A.2.6. RTP Packet with Empty Two-Byte Header Extension and
CSRC Fields
Acknowledgements
Authors' Addresses
The Secure Real-time Transport Protocol (SRTP) [RFC3711] mechanism provides message authentication for the entire RTP packet but only encrypts the RTP payload. This has not historically been a problem, as much of the information carried in the header has minimal sensitivity (e.g., RTP timestamp); in addition, certain fields need to remain as cleartext because they are used for key scheduling (e.g., RTP synchronization source (SSRC) and sequence number).
安全なリアルタイムトランスポートプロトコル（SRTP）[RFC3711]メカニズムは、RTPパケット全体にメッセージ認証を提供しますが、RTPペイロードのみを暗号化します。これは歴史的には問題ではありませんでした。ヘッダーで運ばれる情報の多くは感度が最小限であるためです（RTPタイムスタンプなど）。さらに、特定のフィールドは、キースケジューリングに使用されるため、クリアテキストとして留まる必要があります（たとえば、RTP同期ソース（SSRC）およびシーケンス番号）。
However, as noted in [RFC6904], the security requirements can be different for information carried in RTP header extensions, including the per-packet sound levels defined in [RFC6464] and [RFC6465], which are specifically noted as being sensitive in the Security Considerations sections of those RFCs.
ただし、[RFC6904]で述べたように、セキュリティ要件は、[RFC6464]および[RFC6465]で定義されているパケットごとのサウンドレベルを含むRTPヘッダー拡張機能で伝えられる情報に対して異なる場合があります。これらのRFCの考慮事項セクション。
In addition to the contents of the header extensions, there are now enough header extensions in active use that the header extension identifiers themselves can provide meaningful information in terms of determining the identity of the endpoint and/or application. Accordingly, these identifiers can be considered a fingerprinting issue.
ヘッダー拡張機能の内容に加えて、ヘッダー拡張識別子自体がエンドポイントおよび/またはアプリケーションのIDを決定するという点で意味のある情報を提供できるように、アクティブな使用に十分なヘッダー拡張機能があります。したがって、これらの識別子はフィンガープリントの問題と見なすことができます。
Finally, the CSRCs included in RTP packets can also be sensitive, potentially allowing a network eavesdropper to determine who was speaking and when during an otherwise secure conference call.
最後に、RTPパケットに含まれるCSRCは敏感であり、ネットワーク盗聴者が誰が話しているのか、そしてそれ以外の場合は安全な電話会議中を判断できるようにする可能性があります。
Encryption of Header Extensions in SRTP [RFC6904] was proposed in 2013 as a solution to the problem of unprotected header extension values. However, it has not seen significant adoption and has a few technical shortcomings.
SRTP [RFC6904]のヘッダー拡張機能の暗号化は、保護されていないヘッダー拡張値の問題の解決策として2013年に提案されました。しかし、それは重要な採用を見ていないため、いくつかの技術的な欠点があります。
First, the mechanism is complicated. Since it allows encryption to be negotiated on a per-extension basis, a fair amount of signaling logic is required. And in the SRTP layer, a somewhat complex transform is required to allow only the selected header extension values to be encrypted. One of the most popular SRTP implementations had a significant bug in this area that was not detected for five years.
まず、メカニズムは複雑です。暗号化を拡張ごとに交渉できるため、かなりの量のシグナル伝達ロジックが必要です。また、SRTPレイヤーでは、選択したヘッダー拡張値のみを暗号化できるようにするには、やや複雑な変換が必要です。最も人気のあるSRTP実装の1つは、5年間検出されなかったこの分野で大きなバグを持っていました。
Second, the mechanism only protects the header extension values and not their identifiers or lengths. It also does not protect the CSRCs. As noted above, this leaves a fair amount of potentially sensitive information exposed.
第二に、メカニズムはヘッダー拡張値のみを保護し、識別子または長さではありません。また、CSRCを保護しません。上記のように、これはかなりの量の潜在的に機密情報が公開されています。
Third, the mechanism bloats the header extension space. Because each extension must be offered in both unencrypted and encrypted forms, twice as many header extensions must be offered, which will in many cases push implementations past the 14-extension limit for the use of one-byte extension headers defined in [RFC8285]. Accordingly, in many cases, implementations will need to use two-byte headers, which are not supported well by some existing implementations.
第三に、メカニズムはヘッダー拡張スペースを膨らませます。各拡張機能は暗号化されていないフォームと暗号化されたフォームの両方で提供される必要があるため、[RFC8285]で定義された1バイトの拡張ヘッダーの使用のために、多くの場合、実装を14拡張制限を超えて実装をプッシュする必要があります。したがって、多くの場合、実装は2バイトのヘッダーを使用する必要がありますが、これは既存の実装ではうまくサポートされていません。
Finally, the header extension bloat combined with the need for backward compatibility results in additional wire overhead. Because two-byte extension headers may not be handled well by existing implementations, one-byte extension identifiers will need to be used for the unencrypted (backward-compatible) forms, and two-byte for the encrypted forms. Thus, deployment of encryption for header extensions [RFC6904] will typically result in multiple extra bytes in each RTP packet, compared to the present situation.
最後に、ヘッダー拡張剤が後方互換性の必要性と組み合わされて、追加のワイヤオーバーヘッドが得られます。2バイトの拡張ヘッダーは既存の実装によってうまく処理されない可能性があるため、1バイトの拡張機能識別子は、暗号化されていない（後方互換性のある）フォームに、および暗号化されたフォームに2バイトに使用する必要があります。したがって、ヘッダーエクステンション[RFC6904]の暗号化の展開は、通常、現在の状況と比較して、各RTPパケットに複数の追加バイトをもたらします。
From the previous analysis, the desired properties of a solution are:
以前の分析から、ソリューションの目的の特性は次のとおりです。
* Built on the existing SRTP framework [RFC3711] (simple to understand)
* 既存のSRTPフレームワーク[RFC3711]に基づいて構築されています（理解しやすい）
* Built on the existing header extension framework [RFC8285] (simple to implement)
* 既存のヘッダー拡張フレームワーク[RFC8285]に基づいて構築されています（実装が簡単）
* Protection of header extension identifiers, lengths, and values
* ヘッダー拡張識別子、長さ、および値の保護
* Protection of CSRCs when present
* 存在する場合のCSRCの保護
* Simple signaling
* 単純なシグナリング
* Simple crypto transform and SRTP interactions
* 単純な暗号変換とSRTP相互作用
* Backward compatibility with unencrypted endpoints, if desired
* 必要に応じて、暗号化されていないエンドポイントとの後方互換性
* Backward compatibility with existing RTP tooling
* 既存のRTPツールとの後方互換性
The last point deserves further discussion. While other possible solutions that would have encrypted more of the RTP header (e.g., the number of CSRCs) were considered, the inability to parse the resultant packets with current tools and a generally higher level of complexity outweighed the slight improvement in confidentiality in these solutions. Hence, a more pragmatic approach was taken to solve the problem described in Section 1.1.
最後のポイントは、さらなる議論に値します。より多くのRTPヘッダー（たとえば、CSRCの数）を暗号化する他の可能なソリューションが考慮されましたが、結果のパケットを現在のツールで解析できないため、一般的に高いレベルの複雑さは、これらのソリューションの機密性のわずかな改善を上回りました。したがって、セクション1.1で説明した問題を解決するために、より実用的なアプローチが採用されました。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This specification proposes a mechanism to negotiate encryption of all RTP header extensions (ids, lengths, and values) as well as CSRC values. It reuses the existing SRTP framework, is accordingly simple to implement, and is backward compatible with existing RTP packet parsing code, even when support for the mechanism has been negotiated.
この仕様では、すべてのRTPヘッダー拡張機能（ID、長さ、値）の暗号化とCSRC値を交渉するメカニズムを提案します。既存のSRTPフレームワークを再利用し、それに応じて実装が簡単であり、メカニズムのサポートがネゴシエートされた場合でも、既存のRTPパケット解析コードと後方互換性があります。
Except when explicitly stated otherwise, Cryptex reuses all the framework procedures, transforms, and considerations described in [RFC3711].
特に明示的に記載されている場合を除き、Cryptexは[RFC3711]で説明されているすべてのフレームワーク手順、変換、および考慮事項を再利用します。
Cryptex support is indicated via a new "a=cryptex" SDP attribute defined in this specification.
Cryptexサポートは、この仕様で定義されている新しい「an = cryptex」SDP属性によって示されます。
The new "a=cryptex" attribute is a property attribute as defined in Section 5.13 of [RFC8866]; it therefore takes no value and can be used at the session level or media level.
新しい「a = cryptex」属性は、[rfc8866]のセクション5.13で定義されているプロパティ属性です。したがって、価値はなく、セッションレベルまたはメディアレベルで使用できます。
The presence of the "a=cryptex" attribute in the SDP (in either an offer or an answer) indicates that the endpoint is capable of receiving RTP packets encrypted with Cryptex, as defined below.
SDPに「A = Cryptex」属性が存在する（オファーまたは回答のいずれか）は、エンドポイントがCryptexで暗号化されたRTPパケットを受信できることを示しています。
Once each peer has verified that the other party supports receiving RTP packets encrypted with Cryptex, senders can unilaterally decide whether or not to use the Cryptex mechanism on a per-packet basis.
各ピアがCryptexで暗号化されたRTPパケットの受信をサポートすることを確認すると、送信者はパケットごとにCryptexメカニズムを使用するかどうかを一方的に決定できます。
If BUNDLE is in use as per [RFC9143] and the "a=cryptex" attribute is present for a media line, it MUST be present for all RTP-based "m=" sections belonging to the same bundle group. This ensures that the encrypted Media Identifier (MID) header extensions can be processed, allowing RTP streams to be associated with the correct "m=" section in each BUNDLE group as specified in Section 9.2 of [RFC9143]. When used with BUNDLE, this attribute is assigned to the TRANSPORT category [RFC8859].
[RFC9143]に従ってバンドルが使用されており、メディアラインに「a = cryptex」属性が存在する場合、同じバンドルグループに属するすべてのRTPベースの「m =」セクションに存在する必要があります。これにより、暗号化されたメディア識別子（MID）ヘッダー拡張機能を処理できるようになり、[RFC9143]のセクション9.2で指定されているように、各バンドルグループの正しい「M =」セクションにRTPストリームを関連付けることができます。バンドルで使用する場合、この属性は輸送カテゴリ[RFC8859]に割り当てられます。
Both endpoints can change the Cryptex support status by modifying the session as specified in Section 8 of [RFC3264]. Generating subsequent SDP offers and answers MUST use the same procedures for including the "a=cryptex" attribute as the ones on the initial offer and answer.
両方のエンドポイントは、[RFC3264]のセクション8で指定されているようにセッションを変更することにより、Cryptexサポートステータスを変更できます。後続のSDPオファーと回答を生成すると、「a = cryptex」属性を最初のオファーと回答の属性と含めるために同じ手順を使用する必要があります。
A General Mechanism for RTP Header Extensions [RFC8285] defines two values for the "defined by profile" field for carrying one-byte and two-byte header extensions. In order to allow a receiver to determine if an incoming RTP packet is using the encryption scheme in this specification, two new values are defined:
RTPヘッダーエクステンション[RFC8285]の一般的なメカニズムは、1バイトおよび2バイトヘッダー拡張機能を運ぶための「プロファイルで定義された」フィールドの2つの値を定義します。受信機がこの仕様で着信RTPパケットが暗号化スキームを使用しているかどうかを判断できるようにするために、2つの新しい値が定義されています。
* 0xC0DE for the encrypted version of the one-byte header extensions (instead of 0xBEDE).
* 0XC0DE 1バイトヘッダー拡張機能の暗号化バージョン（0xBedeの代わりに）。
* 0xC2DE for the encrypted versions of the two-byte header extensions (instead of 0x100).
* 0xc2DE 2バイトヘッダー拡張機能の暗号化されたバージョン（0x100ではなく）。
In the case of using two-byte header extensions, the extension identifier with value 256 MUST NOT be negotiated, as the value of this identifier is meant to be contained in the "appbits" of the "defined by profile" field, which are not available when using the values above.
2バイトヘッダー拡張機能を使用する場合、この識別子の値は「プロファイル」フィールドの「アプリ」に含まれることを意図しているため、値256の拡張識別子を交渉してはなりません。上記の値を使用するときに利用可能。
Note that as per [RFC8285], it is not possible to mix one-byte and two-byte headers on the same RTP packet. Mixing one-byte and two-byte headers on the same RTP stream requires negotiation of the "extmap-allow-mixed" SDP attribute as defined in Section 6 of [RFC8285].
[RFC8285]に従って、同じRTPパケットに1バイトと2バイトのヘッダーを混合することはできないことに注意してください。同じRTPストリームで1バイトと2バイトのヘッダーを混合するには、[RFC8285]のセクション6で定義されている「extmap-allow混合」SDP属性のネゴシエーションが必要です。
Peers MAY negotiate both Cryptex and the Encryption of Header Extensions mechanism defined in [RFC6904] via SDP offer/answer as described in Section 4, and if both mechanisms are supported, either one can be used for any given packet. However, if a packet is encrypted with Cryptex, it MUST NOT also use header extension encryption [RFC6904], and vice versa.
ピアは、セクション4で説明されているように、SDPオファー/回答を介して[RFC6904]で定義されているヘッダー拡張メカニズムの暗号化の両方をCryptexと暗号化の両方を交渉する場合があり、両方のメカニズムがサポートされている場合、どちらかを特定のパケットに使用できます。ただし、パケットがCryptexで暗号化されている場合、ヘッダー拡張暗号化[RFC6904]を使用してはなりません。その逆も同様です。
If one of the peers has advertised the ability to receive both Cryptex and header extensions encrypted as per [RFC6904] in the SDP exchange, it is RECOMMENDED that the other peer use Cryptex rather than the mechanism in [RFC6904] when sending RTP packets so that all the header extensions and CSRCS are encrypted. However, if there is a compelling reason to use the mechanism in [RFC6904] (e.g., a need for some header extensions to be sent in the clear so that so they are processable by RTP middleboxes), the other peer SHOULD use the mechanism in [RFC6904] instead.
ピアの1人がSDP交換で[RFC6904]に従って暗号化されたCryptexとHeader拡張機能の両方を受け取る機能を宣伝している場合、RTPパケットを送信するときに[RFC6904]のメカニズムではなく、他のピアがCryptexを使用することをお勧めします。すべてのヘッダー拡張機能とCSRCは暗号化されます。ただし、[RFC6904]でメカニズムを使用する説得力のある理由がある場合（たとえば、RTPミドルボックスが処理できるようにヘッダー拡張機能をクリアで送信する必要がある場合）、他のピアはメカニズムを使用する必要があります。[RFC6904]代わりに。
When the mechanism defined by this specification has been negotiated, sending an RTP packet that has any CSRCs or contains any header extensions [RFC8285] follows the steps below. This mechanism MUST NOT be used with header extensions other than the variety described in [RFC8285].
この仕様で定義されたメカニズムがネゴシエートされた場合、CSRCを備えたRTPパケットまたはヘッダー拡張機能[RFC8285]を含むRTPパケットを送信します。このメカニズムは、[RFC8285]に記載されている品種以外のヘッダー拡張機能で使用してはなりません。
If the RTP packet contains one-byte headers, the 16-bit RTP header extension tag MUST be set to 0xC0DE to indicate that the encryption has been applied and the one-byte framing is being used. If the RTP packet contains two-byte headers, the header extension tag MUST be set to 0xC2DE to indicate encryption has been applied and the two-byte framing is being used.
RTPパケットに1バイトヘッダーが含まれている場合、暗号化が適用され、1バイトのフレーミングが使用されていることを示すために、16ビットRTPヘッダー拡張タグを0xC0DEに設定する必要があります。RTPパケットに2バイトヘッダーが含まれている場合、暗号化が適用され、2バイトフレーミングが使用されていることを示すために、ヘッダー拡張タグを0xc2DEに設定する必要があります。
If the packet contains CSRCs but no header extensions, an empty extension block consisting of the 0xC0DE tag and a 16-bit length field set to zero (explicitly permitted by [RFC3550]) MUST be appended, and the X bit MUST be set to 1 to indicate an extension block is present. This is necessary to provide the receiver an indication that the CSRCs in the packet are encrypted.
パケットにCSRCが含まれているがヘッダー拡張機能がない場合、0xc0DEタグと16ビットの長さフィールドで構成される空の拡張ブロックとゼロに設定された16ビットの長さフィールド（[RFC3550]で明示的に許可されている）を追加する必要があり、Xビットは1に設定する必要があります。拡張ブロックが存在することを示すために。これは、受信機にパケット内のCSRCが暗号化されていることを示すために必要です。
The RTP packet MUST then be encrypted as described in Section 6.2 ("Encryption Procedure").
次に、RTPパケットは、セクション6.2（「暗号化手順」）で説明されているように暗号化する必要があります。
When receiving an RTP packet that contains header extensions, the "defined by profile" field MUST be checked to ensure the payload is formatted according to this specification. If the field does not match one of the values defined above, the implementation MUST instead handle it according to the specification that defines that value.
ヘッダー拡張機能を含むRTPパケットを受信する場合、「プロファイルで定義された」フィールドをチェックして、この仕様に従ってペイロードがフォーマットされていることを確認する必要があります。フィールドが上記の値のいずれかと一致しない場合、その値を定義する仕様に従って実装は代わりに処理する必要があります。
Alternatively, if the implementation considers the use of this specification mandatory and the "defined by profile" field does not match one of the values defined above, it MUST stop the processing of the RTP packet and report an error for the RTP stream.
あるいは、実装がこの仕様の使用を必須であると考慮し、「プロファイルで定義された」フィールドが上記の値のいずれかと一致しない場合、RTPパケットの処理を停止し、RTPストリームのエラーを報告する必要があります。
If the RTP packet passes this check, it is then decrypted as described in Section 6.3 ("Decryption Procedure") and passed to the next layer to process the packet and its extensions. In the event that a zero-length extension block was added as indicated above, it can be left as is and will be processed normally.
RTPパケットがこのチェックに合格した場合、セクション6.3（「復号化手順」）で説明されているように復号化され、パケットとその拡張機能を処理するために次のレイヤーに渡されます。上記のようにゼロの長さの拡張ブロックが追加された場合、それはそのまま残され、正常に処理される可能性があります。
When this mechanism is active, the SRTP packet is protected as follows:
このメカニズムがアクティブな場合、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 | |
| | .... | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
X | 0xC0 or 0xC2 | 0xDE | length | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RFC 8285 header extensions | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP Master Key Identifier (MKI) (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portion Authenticated Portion ---+
Figure 1: A Protected SRTP Packet
図1：保護されたSRTPパケット
Note that, as required by [RFC8285], the 4 bytes at the start of the extension block are not encrypted.
[RFC8285]で要求されるように、拡張ブロックの開始時の4バイトは暗号化されていないことに注意してください。
Specifically, the Encrypted Portion MUST include any CSRC identifiers, any RTP header extension (except for the first 4 bytes), and the RTP payload.
具体的には、暗号化された部分には、CSRC識別子、RTPヘッダー拡張機能（最初の4バイトを除く）、およびRTPペイロードを含める必要があります。
The encryption procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet. The plaintext input to the cipher is as follows:
暗号化手順は、SRTPパケットの暗号化された部分を除き、[RFC3711]の暗号化手順と同じです。暗号へのプレーンテキスト入力は次のとおりです。
Plaintext = CSRC identifiers (if used) || header extension data || RTP payload || RTP padding (if used) || RTP pad count (if used)
plantext = csrc識別子（使用する場合）||ヘッダー拡張データ||RTPペイロード||RTPパディング（使用する場合）||RTPパッドカウント（使用する場合）
Here "header extension data" refers to the content of the RTP extension field, excluding the first four bytes (the extension header [RFC8285]). The first 4 * CSRC count (CC) bytes of the ciphertext are placed in the CSRC field of the RTP header. The remainder of the ciphertext is the RTP payload of the encrypted packet.
ここでは、「ヘッダー拡張データ」とは、最初の4バイト（拡張ヘッダー[RFC8285]）を除くRTP拡張フィールドのコンテンツを指します。暗号文の最初の4 * CSRCカウント（CC）バイトは、RTPヘッダーのCSRCフィールドに配置されます。暗号文の残りの部分は、暗号化されたパケットのRTPペイロードです。
To minimize changes to surrounding code, the encryption mechanism can choose to replace a "defined by profile" field from [RFC8285] with its counterpart defined in Section 5 ("RTP Header Processing") and encrypt at the same time.
周囲のコードの変更を最小限に抑えるために、暗号化メカニズムは、[RFC8285]の[RFC8285]の「プロファイルによって定義された」フィールドをセクション5（「RTPヘッダー処理」）で定義した対応物を同時に置き換えることを選択できます。
For Authenticated Encryption with Associated Data (AEAD) ciphers (e.g., AES-GCM), the 12-byte fixed header and the four-byte header extension header (the "defined by profile" field and the length) are considered additional authenticated data (AAD), even though they are non-contiguous in the packet if CSRCs are present.
関連するデータ（AEAD）暗号（AES-GCMなど）を使用した認証された暗号化の場合、12バイト固定ヘッダーと4バイトヘッダー拡張ヘッダー（「プロファイルで定義された」フィールドと長さ）は、追加の認証データ（追加の認証データ）と見なされます。aad）、CSRCが存在する場合、それらはパケットに依存していませんが。
Associated Data: fixed header || extension header (if X=1)
関連データ：固定ヘッダー||拡張ヘッダー（x = 1の場合）
Here "fixed header" refers to the 12-byte fixed portion of the RTP header, and "extension header" refers to the four-byte extension header [RFC8285] ("defined by profile" and extension length).
ここでは、「固定ヘッダー」とは、RTPヘッダーの12バイト固定部分を指し、「拡張ヘッダー」は4バイト拡張ヘッダー[RFC8285]（「プロファイルで定義された」と拡張長さ）を指します。
Implementations can rearrange a packet so that the AAD and plaintext are contiguous by swapping the order of the extension header and the CSRC identifiers, resulting in an intermediate representation of the form shown in Figure 2. After encryption, the CSRCs (now encrypted) and extension header would need to be swapped back to their original positions. A similar operation can be done when decrypting to create contiguous ciphertext and AAD inputs.
実装はパケットを再配置できるため、AADとプレーンテキストが拡張ヘッダーとCSRC識別子の順序を交換し、図2に示す形式の中間表現をもたらすことができます。暗号化後、CSRC（現在は暗号化）と拡張機能ヘッダーは元の位置に交換する必要があります。同様の操作は、隣接する暗号文とAAD入力を作成するために復号化するときに実行できます。
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0xC0 or 0xC2 | 0xDE | length | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+
| | contributing source (CSRC) identifiers | |
| | .... | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | RFC 8285 header extensions | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Plaintext Input AAD Input ---+
Figure 2: An RTP Packet Transformed to Make Cryptex Cipher Inputs Contiguous
図2：cryptex暗号入力を隣接するように変換されたRTPパケット
Note that this intermediate representation is only displayed as reference for implementations and is not meant to be sent on the wire.
この中間表現は、実装の参照としてのみ表示され、ワイヤーに送信されることを意図していないことに注意してください。
The decryption procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet, which is as shown in the section above.
復号化手順は、上記のセクションに示すように、SRTPパケットの暗号化された部分を除き、[RFC3711]の復号化手順と同一です。
To minimize changes to surrounding code, the decryption mechanism can choose to replace the "defined by profile" field with its no-encryption counterpart from [RFC8285] and decrypt at the same time.
周囲のコードの変更を最小限に抑えるために、復号化メカニズムは、[RFC8285]の非暗号化の対応物に「プロファイルで定義された」フィールドを置き換え、同時に復号化することを選択できます。
This specification attempts to encrypt as much as possible without interfering with backward compatibility for systems that expect a certain structure from an RTPv2 packet, including systems that perform demultiplexing based on packet headers. Accordingly, the first two bytes of the RTP packet are not encrypted.
この仕様は、パケットヘッダーに基づいて非難を実行するシステムを含む、RTPV2パケットから特定の構造を期待するシステムの後方互換性を妨げることなく、可能な限り暗号化しようとします。したがって、RTPパケットの最初の2バイトは暗号化されていません。
This specification also attempts to reuse the key scheduling from SRTP, which depends on the RTP packet sequence number and SSRC identifier. Accordingly, these values are also not encrypted.
この仕様は、RTPパケットシーケンス番号とSSRC識別子に依存するSRTPからのキースケジューリングを再利用しようとします。したがって、これらの値も暗号化されていません。
All security considerations in Section 9 of [RFC3711] are applicable to this specification; the exception is Section 9.4, because confidentiality of the RTP Header is the purpose of this specification.
[RFC3711]のセクション9のすべてのセキュリティ上の考慮事項は、この仕様に適用できます。RTPヘッダーの機密性がこの仕様の目的であるため、例外はセクション9.4です。
The risks of using weak or NULL authentication with SRTP, described in Section 9.5 of [RFC3711], apply to encrypted header extensions as well.
[RFC3711]のセクション9.5で説明されているSRTPで弱いまたはヌル認証を使用するリスクは、暗号化されたヘッダー拡張機能にも適用されます。
This specification extends SRTP by expanding the Encrypted Portion of the RTP packet, as shown in Section 6.1 ("Packet Structure"). It does not change how SRTP authentication works in any way. Given that more of the packet is being encrypted than before, this is necessarily an improvement.
この仕様は、セクション6.1（「パケット構造」）に示すように、RTPパケットの暗号化された部分を拡張することにより、SRTPを拡張します。SRTP認証がどのように機能するかは変わりません。パケットの多くが以前よりも暗号化されていることを考えると、これは必然的に改善です。
The RTP fields that are left unencrypted (see rationale above) are as follows:
暗号化されていないままのRTPフィールド（上記の理論的根拠を参照）は次のとおりです。
* RTP version
* RTPバージョン
* padding bit
* パディングビット
* extension bit
* 拡張ビット
* number of CSRCs
* CSRCの数
* marker bit
* マーカービット
* payload type
* ペイロードタイプ
* sequence number
* シーケンス番号
* timestamp
* タイムスタンプ
* SSRC identifier
* SSRC識別子
* number of header extensions [RFC8285]
* ヘッダー拡張機能の数[RFC8285]
These values contain a fixed set (i.e., one that won't be changed by extensions) of information that, at present, is observed to have low sensitivity. In the event any of these values need to be encrypted, SRTP is likely the wrong protocol to use and a fully encapsulating protocol such as DTLS is preferred (with its attendant per-packet overhead).
これらの値には、現在、感度が低いことが観察されている情報の固定セット（つまり、拡張機能によって変更されないもの）が含まれています。これらの値のいずれかを暗号化する必要がある場合、SRTPは使用するための間違ったプロトコルである可能性が高く、DTLSなどの完全にカプセル化するプロトコルが推奨されます（パケットごとのオーバーヘッドを使用して）。
This document updates the "attribute-name (formerly "att-field")" subregistry of the "Session Description Protocol (SDP) Parameters" registry (see Section 8.2.4 of [RFC8866]). Specifically, it adds the SDP "a=cryptex" attribute for use at both the media level and the session level.
このドキュメントは、「属性名（以前の「attfield」）」「セッション説明プロトコル（SDP）パラメーター」のサブレジストリを更新します（[RFC8866]のセクション8.2.4を参照）。具体的には、メディアレベルとセッションレベルの両方で使用するためのSDP "a = cryptex"属性を追加します。
Contact name: IETF AVT Working Group or IESG if the AVT Working Group is closed
連絡先名：IETF AVTワーキンググループまたはIESG AVTワーキンググループが閉じている場合
Contact email address: avt@ietf.org
メールアドレスに連絡してください：avt@ietf.org
Attribute name: cryptex
属性名：cryptex
Attribute syntax: This attribute takes no values.
属性構文：この属性には値がかかりません。
Attribute semantics: N/A
属性セマンティクス：n/a
Attribute value: N/A
属性値：n/a
Usage level: session, media
使用レベル：セッション、メディア
Charset dependent: No
charset依存関係：いいえ
Purpose: The presence of this attribute in the SDP indicates that the endpoint is capable of receiving RTP packets encrypted with Cryptex as described in this document.
目的：SDPにこの属性が存在することは、エンドポイントがこのドキュメントで説明されているようにCryptexで暗号化されたRTPパケットを受信できることを示しています。
O/A procedures: SDP O/A procedures are described in Section 4 of this document.
O/A手順：SDP O/A手順については、このドキュメントのセクション4で説明しています。
Mux Category: TRANSPORT
MUXカテゴリ：輸送
[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>。
[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：//www.rfc-editor.org/info/rfc3264>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487/RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[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>。
[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]シンガー、D。、Desineni、H。、およびR. ed。、「RTPヘッダー拡張の一般的なメカニズム」、RFC 8285、DOI 10.17487/RFC8285、2017年10月、<https：//www.rfcc-editor.org/info/rfc8285>。
[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.
[RFC8859] Nandakumar、S。、「マルチプレックス時のセッション説明プロトコル（SDP）属性のフレームワーク」、RFC 8859、DOI 10.17487/RFC8859、2021年1月、<https：//www.rfc-ed.org/fo/rfc888899>。
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.
[RFC8866] Begen、A.、Kyzivat、P.、Perkins、C.、およびM. Handley、「SDP：SESSION説明プロトコル」、RFC 8866、DOI 10.17487/RFC866、2021年1月、<https：//www.rfc8866-editor.org/info/rfc8866>。
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, February 2022, <https://www.rfc-editor.org/info/rfc9143>.
[RFC9143] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「セッション説明プロトコル（SDP）を使用したメディア多重化の交渉」、RFC 9143、DOI 10.17487/RFC9143、2月2022年2月、<https：// www。rfc-editor.org/info/rfc9143>。
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, <https://www.rfc-editor.org/info/rfc6464>.
[RFC6464] Lennox、J.、Ed。、Ivov、E.、およびE. Marocco、「クライアント間オーディオレベルの表示用のリアルタイムトランスポートプロトコル（RTP）ヘッダー拡張」、RFC 6464、DOI 10.17487/RFC6464、2011年12月、<https://www.rfc-editor.org/info/rfc6464>。
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, <https://www.rfc-editor.org/info/rfc6465>.
[RFC6465] Ivov、E.、Ed。、Marocco、E.、Ed。、およびJ. Lennox、「ミキサーからクライアントのオーディオレベルの表示用のリアルタイムトランスポートプロトコル（RTP）ヘッダー拡張」、RFC 6465、doi 10.17487/rfc6465、2011年12月、<https://www.rfc-editor.org/info/rfc6465>。
[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。、「安全なリアルタイム輸送プロトコル（SRTP）におけるヘッダー拡張の暗号化」、RFC 6904、DOI 10.17487/RFC6904、2013年4月、<https：//www.rfc-editor.org/情報/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、「安全なリアルタイム輸送プロトコル（SRTP）のAES-GCM認証暗号化」、RFC 7714、DOI 10.17487/RFC7714、2015年12月、<https：//www.rfc-editor.org/info/rfc7714>。
All values are in hexadecimal and represented in network order (big endian).
すべての値は16進数であり、ネットワーク順序で表されます（Big Endian）。
The following subsections list the test vectors for using Cryptex with AES-CTR as per [RFC3711].
次のサブセクションには、[RFC3711]に従って、AES-CTRでCryptexを使用するためのテストベクトルがリストされています。
Common values are organized as follows:
共通の値は次のように編成されます。
Rollover Counter: 00000000
Master Key: e1f97a0d3e018be0d64fa32c06de4139
Master Salt: 0ec675ad498afeebb6960b3aabe6
Crypto Suite: AES_CM_128_HMAC_SHA1_80
Session Key: c61e7a93744f39ee10734afe3ff7a087
Session Salt: 30cbbc08863d8c85d49db34a9ae1
Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4
RTP Packet:
RTPパケット：
900f1235 decafbad cafebabe bede0001 51000200 abababab abababab abababab abababab
900F1235 DECAFBAD CAFEBABE BEDE0001 51000200 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
900f1235 decafbad cafebabe c0de0001 eb923652 51c3e036 f8de27e9 c27ee3e0 b4651d9f bc4218a7 0244522f 34a5
900F1235 DECAFBAD CAFEBABE C0DE0001 EB923652 51C3E036 F8DE27E9 C27EE3E0 B4651D9F BC4218A7 0244522F 34A5
RTP Packet:
RTPパケット：
900f1236 decafbad cafebabe 10000001 05020002 abababab abababab abababab abababab
900F1236 DECAFBAD CAFEBABE 10000001 05020002 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
900f1236 decafbad cafebabe c2de0001 4ed9cc4e 6a712b30 96c5ca77 339d4204 ce0d7739 6cab6958 5fbce381 94a5
900F1236 DECAFBAD CAFEBABE C2DE0001 4ED9CC4E 6A712B30 96C5CA77 339D4204 CE0D7739 6CAB6958 5FBCE381 94A5
RTP Packet:
RTPパケット：
920f1238 decafbad cafebabe 0001e240 0000b26e bede0001 51000200 abababab abababab abababab abababab
920F1238 DECAFBAD CAFEBABE 0001E240 0000B26E BEDE0001 51000200 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f1238 decafbad cafebabe 8bb6e12b 5cff16dd c0de0001 92838c8c 09e58393 e1de3a9a 74734d67 45671338 c3acf11d a2df8423 bee0
920F1238 DECAFBAD CAFEBABE 8BB6E12B 5CFF16DD C0DE0001 92838C8C 09E58393 E1DE3A9A 74734D67 45671338 C3ACF11D A2DF8423 BEE0
RTP Packet:
RTPパケット：
920f1239 decafbad cafebabe 0001e240 0000b26e 10000001 05020002 abababab abababab abababab abababab
920F1239 DECAFBAD CAFEBABE 0001E240 0000B26E 10000001 05020002 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f1239 decafbad cafebabe f70e513e b90b9b25 c2de0001 bbed4848 faa64466 5f3d7f34 125914e9 f4d0ae92 3c6f479b 95a0f7b5 3133
920F1239 DECAFBAD CAFEBABE F70E513E B90B9B25 C2DE0001 BBED4848 FAA64466 5F3D7F34 125914E9 F4D0AE92 3C6F479B 95A0F7B5313333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333チため向ってあり
RTP Packet:
RTPパケット：
920f123a decafbad cafebabe 0001e240 0000b26e bede0000 abababab abababab abababab abababab
920F123A DECAFBAD CAFEBABE 0001E240 0000B26E BEDE0000 ABABABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f123a decafbad cafebabe 7130b6ab fe2ab0e3 c0de0000 e3d9f64b 25c9e74c b4cf8e43 fb92e378 1c2c0cea b6b3a499 a14c
920F123A DECAFBAD CAFEBABE 7130B6AB FE2AB0E3 C0DE0000 E3D9F64B 25C9E74C B4CF8E43 FB92E378 1C2CEA B6B3A499 A14C
RTP Packet:
RTPパケット：
920f123b decafbad cafebabe 0001e240 0000b26e 10000000 abababab abababab abababab abababab
920F123B DECAFBAD CAFEBABE 0001E240 0000B26E 10000000 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f123b decafbad cafebabe cbf24c12 4330e1c8 c2de0000 599dd45b c9d687b6 03e8b59d 771fd38e 88b170e0 cd31e125 eabe
920F123B DECAFBAD CAFEBABE CBF24C12 4330E1C8 C2DE0000 599DD45B C9D687B6 03E8B59D 771FD38E 88B170E0 CD31E125 EABEEBE
The following subsections list the test vectors for using Cryptex with AES-GCM as per [RFC7714].
次のサブセクションには、[RFC7714]に従って、AES-GCMを使用してCryptexを使用するためのテストベクトルがリストされています。
Common values are organized as follows:
共通の値は次のように編成されます。
Rollover Counter: 00000000 Master Key: 000102030405060708090a0b0c0d0e0f Master Salt: a0a1a2a3a4a5a6a7a8a9aaab Crypto Suite: AEAD_AES_128_GCM Session Key: 077c6143cb221bc355ff23d5f984a16e Session Salt: 9af3e95364ebac9c99c5a7c4
Rollover Counter: 00000000 Master Key: 000102030405060708090a0b0c0d0e0f Master Salt: a0a1a2a3a4a5a6a7a8a9aaab Crypto Suite: AEAD_AES_128_GCM Session Key: 077c6143cb221bc355ff23d5f984a16e Session Salt: 9af3e95364ebac9c99c5a7c4
RTP Packet:
RTPパケット：
900f1235 decafbad cafebabe bede0001 51000200 abababab abababab abababab abababab
900F1235 DECAFBAD CAFEBABE BEDE0001 51000200 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
900f1235 decafbad cafebabe c0de0001 39972dc9 572c4d99 e8fc355d e743fb2e 94f9d8ff 54e72f41 93bbc5c7 4ffab0fa 9fa0fbeb
900F1235 DECAFBAD CAFEBABE C0DE0001 39972DC9 572C4D99 E8FC355D E743FB2E 94F9D8FF 54E72FF41 93BBC5C7 4FFAB0FA 9FA0FBEBBEBBBEBBEBBEBBEB
RTP Packet:
RTPパケット：
900f1236 decafbad cafebabe 10000001 05020002 abababab abababab abababab abababab
900F1236 DECAFBAD CAFEBABE 10000001 05020002 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
900f1236 decafbad cafebabe c2de0001 bb75a4c5 45cd1f41 3bdb7daa 2b1e3263 de313667 c9632490 81b35a65 f5cb6c88 b394235f
900F1236 DECAFBAD CAFEBABE C2DE0001 BB75A4C5 45CD1F41 3BDB7DAA 2B1E3263 DE313667 C9632490 81B35A65 F5CB6C88 B3942355FF
RTP Packet:
RTPパケット：
920f1238 decafbad cafebabe 0001e240 0000b26e bede0001 51000200 abababab abababab abababab abababab
920F1238 DECAFBAD CAFEBABE 0001E240 0000B26E BEDE0001 51000200 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f1238 decafbad cafebabe 63bbccc4 a7f695c4 c0de0001 8ad7c71f ac70a80c 92866b4c 6ba98546 ef913586 e95ffaaf fe956885 bb0647a8 bc094ac8
920F1238 DECAFBAD CAFEBABE 63BBCCC4 A7F695C4 C0DE0001 8AD7C71F AC70A80C 92866B4C 6BA98546 EF913586 E95FFAAF FE956888 BB067A8 BC094AC8
RTP Packet:
RTPパケット：
920f1239 decafbad cafebabe 0001e240 0000b26e 10000001 05020002 abababab abababab abababab abababab
920F1239 DECAFBAD CAFEBABE 0001E240 0000B26E 10000001 05020002 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f1239 decafbad cafebabe 3680524f 8d312b00 c2de0001 c78d1200 38422bc1 11a7187a 18246f98 0c059cc6 bc9df8b6 26394eca 344e4b05 d80fea83
920F1239 DECAFBAD CAFEBABE 3680524F 8D312B00 C2DE0001 C78D1200 384222BC1 11A7187A 18246F98 0C059CC6 BC9DF8B6 26394ECA 344E4B05 D80FEA83
RTP Packet:
RTPパケット：
920f123a decafbad cafebabe 0001e240 0000b26e bede0000 abababab abababab abababab abababab
920F123A DECAFBAD CAFEBABE 0001E240 0000B26E BEDE0000 ABABABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f123a decafbad cafebabe 15b6bb43 37906fff c0de0000 b7b96453 7a2b03ab 7ba5389c e9331712 6b5d974d f30c6884 dcb651c5 e120c1da
920F123A DECAFBAD CAFEBABE 15B6BB43 37906FFF C0DE0000 B7B96453 7A2B03AB 7BA5389C E9331712 6B5D974D F30C6884 DCB651C5 E120C1DA
RTP Packet:
RTPパケット：
920f123b decafbad cafebabe 0001e240 0000b26e 10000000 abababab abababab abababab abababab
920F123B DECAFBAD CAFEBABE 0001E240 0000B26E 10000000 ABABABABABABABABABABABABABAB
Encrypted RTP Packet:
暗号化されたRTPパケット：
920f123b decafbad cafebabe dcb38c9e 48bf95f4 c2de0000 61ee432c f9203170 76613258 d3ce4236 c06ac429 681ad084 13512dc9 8b5207d8
920F123B DECAFBAD CAFEBABE DCB38C9E 48BF95F4 C2DE0000 61EE432C F9203170 76613258 D3CE4236 C06AC429 681AD084 13512DC9 8B5207D8D8D8
Acknowledgements
謝辞
The authors wish to thank Lennart Grahl for pointing out many of the issues with the existing header encryption mechanism, as well as suggestions for this proposal. Thanks also to Jonathan Lennox, Inaki Castillo, and Bernard Aboba for their reviews and suggestions.
著者は、既存のヘッダー暗号化メカニズムに関する多くの問題と、この提案の提案を指摘してくれたLennart Grahlに感謝したいと考えています。ジョナサン・レノックス、イナキ・カスティージョ、バーナード・アボバにも感謝します。
Authors' Addresses
著者のアドレス
Justin Uberti Email: justin@uberti.name
Justin Ubertiメール：justin@uberti.name
Cullen Jennings Cisco Email: fluffy@iii.ca
Cullen Jennings Cisco Email：Fluffy@iii.ca
Sergio Garcia Murillo Millicast Email: sergio.garcia.murillo@cosmosoftware.io
Sergio Garcia Murillo Millicastメール：sergio.garcia.murillo@cosmosoftware.io