RFC 6904 - Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6904
タイトル : RFC 6904 - Secure Real-time Transport Protocol（SRTP）のヘッダー拡張の暗号化
翻訳編集 : 自動生成

[要約] RFC 6904は、セキュアリアルタイムトランスポートプロトコル（SRTP）におけるヘッダ拡張の暗号化に関する技術仕様を定めた文書です。このRFCの目的は、SRTPで保護された通信において、ヘッダ拡張部分も内容の秘匿性を保ちながら安全に送受信する方法を提供することにあります。利用場面としては、VoIP（Voice over IP）やビデオ会議システムなど、リアルタイムでのメディアストリームを安全に交換する必要があるアプリケーションが挙げられます。関連するRFCとしては、RFC 3711（SRTPの基本仕様を定める）、RFC 3550（RTPの仕様）、RFC 5285（RTPヘッダ拡張の一般的な使用法を定める）などがあります。

Internet Engineering Task Force (IETF)                         J. Lennox
Request for Comments: 6904                                         Vidyo
Updates: 3711                                                 April 2013
Category: Standards Track
ISSN: 2070-1721

Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)

Secure Real-time Transport Protocol（SRTP）のヘッダー拡張の暗号化

Abstract

概要

The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.

セキュアリアルタイムトランスポートプロトコル（SRTP）は、リアルタイムトランスポートプロトコル（RTP）パケットのヘッダーの認証を提供しますが、暗号化は提供しません。ただし、RTPヘッダー拡張には、マルチメディアセッションの参加者が機密性を必要とする機密情報が含まれている場合があります。このドキュメントは、SRTPのメカニズムを拡張して、SRTPのRTPヘッダー拡張を選択的に暗号化するメカニズムを提供します。

This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.

このドキュメントは、Secure Real-time Transport Protocol仕様であるRFC 3711を更新し、将来のすべてのSRTP暗号化トランスフォームがRTPヘッダー拡張の暗号化方法を指定することを要求します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6904.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6904で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Encryption Mechanism  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Example Encryption Mask . . . . . . . . . . . . . . . . .   6
     3.2.  Header Extension Keystream Generation for Existing
           Encryption Transforms . . . . . . . . . . . . . . . . . .   7
     3.3.  Header Extension Keystream Generation for Future
           Encryption Transforms . . . . . . . . . . . . . . . . . .   8
   4.  Signaling (Setup) Information . . . . . . . . . . . . . . . .   8
     4.1.  Backward Compatibility  . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  13
     A.1.  Key Derivation Test Vectors . . . . . . . . . . . . . . .  13
     A.2.  Header Encryption Test Vectors Using AES-CM . . . . . . .  14

1. Introduction

1. はじめに

The Secure Real-time Transport Protocol [RFC3711] specification provides confidentiality, message authentication, and replay protection for multimedia payloads sent using the Real-time Protocol (RTP) [RFC3550]. However, in order to preserve RTP header compression efficiency, SRTP provides only authentication and replay protection for the headers of RTP packets, not confidentiality.

セキュアリアルタイムトランスポートプロトコル[RFC3711]仕様は、リアルタイムプロトコル（RTP）[RFC3550]を使用して送信されるマルチメディアペイロードの機密性、メッセージ認証、および再生保護を提供します。ただし、RTPヘッダーの圧縮効率を維持するために、SRTPはRTPパケットのヘッダーに認証と再生の保護のみを提供し、機密性は提供しません。

For the standard portions of an RTP header, providing only authentication and replay protection does not normally present a problem, as the information carried in an RTP header does not provide much information beyond that which an attacker could infer by observing the size and timing of RTP packets. Thus, there is little need for confidentiality of the header information.

RTPヘッダーの標準部分では、RTPのサイズとタイミングを観察することで攻撃者が推測できる以上の情報はRTPヘッダーで運ばれる情報では提供されないため、認証と再生の保護のみを提供しても問題は通常発生しません。パケット。したがって、ヘッダー情報の機密性はほとんど必要ありません。

However, the security requirements can be different for information carried in RTP header extensions. A number of recent proposals for header extensions using the mechanism described in "A General Mechanism for RTP Header Extensions" [RFC5285] carry information for which confidentiality could be desired or essential. Notably, two recent specifications ([RFC6464] and [RFC6465]) contain information about per-packet sound levels of the media data carried in the RTP payload and specify that exposing this information to an eavesdropper is unacceptable in many circumstances (as described in the Security Considerations sections of those RFCs).

ただし、RTPヘッダー拡張で伝送される情報のセキュリティ要件は異なる場合があります。「RTPヘッダー拡張の一般的なメカニズム」[RFC5285]で説明されているメカニズムを使用したヘッダー拡張に関する最近の提案の多くは、機密性が望まれる、または不可欠である可能性のある情報を含んでいます。特に、最近の2つの仕様（[RFC6464]と[RFC6465]）には、RTPペイロードで運ばれるメディアデータのパケットごとのサウンドレベルに関する情報が含まれており、この情報を盗聴者に公開することは多くの状況で受け入れられないことを指定しています（これらのRFCのセキュリティに関する考慮事項のセクション）。

This document, therefore, defines a mechanism by which encryption can be applied to RTP header extensions when they are transported using SRTP. As an RTP sender may wish some extension information to be sent in the clear (for example, it may be useful for a network monitoring device to be aware of RTP transmission time offsets [RFC5450]), this mechanism can be selectively applied to a subset of the header extension elements carried in an SRTP packet.

したがって、このドキュメントでは、SRTPを使用してトランスポートするときに、RTPヘッダー拡張に暗号化を適用できるメカニズムを定義しています。 RTP送信者は、一部の拡張情報を平文で送信することを望んでいる可能性があるため（たとえば、ネットワーク監視デバイスがRTP送信時間オフセット[RFC5450]を認識していると役立つ場合があります）、このメカニズムをサブセットに選択的に適用できますSRTPパケットで運ばれるヘッダー拡張要素の。

The mechanism defined by this document encrypts packets' header extensions using the same cryptographic algorithms and parameters as are used to encrypt the packets' RTP payloads. This document defines how this is done for the encryption transforms defined in [RFC3711], [RFC5669], and [RFC6188], which are the SRTP encryption transforms defined by Standards Track RFCs at the time of this writing. It also updates [RFC3711] to indicate that specifications of future SRTP encryption transforms must define how header extension encryption is to be performed.

このドキュメントで定義されているメカニズムは、パケットのRTPペイロードの暗号化に使用されるものと同じ暗号化アルゴリズムとパラメーターを使用して、パケットのヘッダー拡張を暗号化します。このドキュメントでは、[RFC3711]、[RFC5669]、および[RFC6188]で定義された暗号化トランスフォームでこれがどのように行われるかを定義しています。また、[RFC3711]を更新して、将来のSRTP暗号化トランスフォームの仕様でヘッダー拡張暗号化の実行方法を定義する必要があることを示します。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。

3. Encryption Mechanism

3. 暗号化メカニズム

Encrypted header extension elements are carried in the same manner as non-encrypted header extension elements, as defined by [RFC5285]. The one- or two-byte header of the extension elements is not encrypted, nor is any of the header extension padding. If multiple different header extension elements are being encrypted, they have separate element identifier values, just as they would if they were not encrypted. Similarly, encrypted and non-encrypted header extension elements have separate identifier values.

暗号化されたヘッダー拡張要素は、[RFC5285]で定義されているように、非暗号化ヘッダー拡張要素と同じ方法で運ばれます。拡張要素の1バイトまたは2バイトのヘッダーは暗号化されず、ヘッダー拡張パディングも暗号化されません。複数の異なるヘッダー拡張要素が暗号化されている場合は、暗号化されていない場合と同様に、要素識別子の値が異なります。同様に、暗号化および非暗号化ヘッダー拡張要素には、個別の識別子値があります。

Encrypted header extension elements are carried only in packets encrypted using the Secure Real-time Transport Protocol [RFC3711]. To encrypt (or decrypt) encrypted header extension elements, an SRTP participant first uses the SRTP key derivation algorithm, specified in Section 4.3.1 of [RFC3711], to generate header encryption and header salting keys, using the same pseudorandom function family as is used for the key derivation for the SRTP session. These keys are derived as follows:

暗号化されたヘッダー拡張要素は、Secure Real-time Transport Protocol [RFC3711]を使用して暗号化されたパケットでのみ伝送されます。暗号化されたヘッダー拡張要素を暗号化（または復号化）するために、SRTP参加者は最初に[RFC3711]のセクション4.3.1で指定されたSRTP鍵導出アルゴリズムを使用して、同じ擬似ランダム関数ファミリーをそのまま使用して、ヘッダー暗号化およびヘッダーソルティング鍵を生成しますSRTPセッションの鍵導出に使用されます。これらのキーは次のように導出されます。

o k_he (SRTP header encryption): <label> = 0x06, n=n_e.

o k_he（SRTPヘッダー暗号化）：<ラベル> = 0x06、n = n_e。

o k_hs (SRTP header salting key): <label> = 0x07, n=n_s.

o k_hs（SRTPヘッダーソルトキー）：<ラベル> = 0x07、n = n_s。

where n_e and n_s are from the cryptographic context: the same size encryption key and salting key are used as are used for the SRTP payload. Additionally, the same master key, master salt, index, and key_derivation_rate are used as for the SRTP payload. (Note that since RTP headers, including header extensions, are authenticated in SRTP, no new authentication key is needed for header extensions.)

ここで、n_eおよびn_sは暗号化コンテキストからのものです。SRTPペイロードで使用されるのと同じサイズの暗号化キーとソルティングキーが使用されます。さらに、SRTPペイロードと同じマスターキー、マスターソルト、インデックス、およびkey_derivation_rateが使用されます。（ヘッダー拡張を含むRTPヘッダーはSRTPで認証されるため、ヘッダー拡張に新しい認証キーは必要ありません。）

A header extension keystream is generated for each packet containing encrypted header extension elements. The details of how this header extension keystream is generated depend on the encryption transform that is used for the SRTP packet. For encryption transforms that have been standardized as of the date of publication of this document, see Section 3.2; for requirements for new transforms, see Section 3.3.

ヘッダー拡張キーストリームは、暗号化されたヘッダー拡張要素を含む各パケットに対して生成されます。このヘッダー拡張キーストリームの生成方法の詳細は、SRTPパケットに使用される暗号化トランスフォームによって異なります。このドキュメントの発行日時点で標準化されている暗号化トランスフォームについては、セクション3.2を参照してください。新しい変換の要件については、セクション3.3を参照してください。

After the header extension keystream is generated, the SRTP participant then computes an encryption mask for the header extension, identifying the portions of the header extension that are, or are to be, encrypted. (For an example of this procedure, see Section 3.1.) This encryption mask corresponds to the entire payload of each header extension element that is encrypted. It does not include any non-encrypted header extension elements, any extension element headers, or any padding octets. The encryption mask has all-bits-1 octets (i.e., hexadecimal 0xff) for header extension octets that are to be encrypted and all-bits-0 octets for header extension octets that are not to be encrypted. The set of extension elements to be encrypted is communicated between the sender and the receiver using the signaling mechanisms described in Section 4.

ヘッダー拡張キーストリームが生成された後、SRTP参加者はヘッダー拡張の暗号化マスクを計算し、暗号化される、または暗号化されるヘッダー拡張の部分を識別します。（この手順の例については、セクション3.1を参照してください。）この暗号化マスクは、暗号化される各ヘッダー拡張要素のペイロード全体に対応します。暗号化されていないヘッダー拡張要素、拡張要素ヘッダー、パディングオクテットは含まれません。暗号化マスクには、暗号化するヘッダー拡張オクテットのall-bits-1オクテット（つまり、16進数の0xff）と、暗号化しないヘッダー拡張オクテットのall-bits-0オクテットがあります。暗号化される拡張要素のセットは、セクション4で説明されているシグナリングメカニズムを使用して、送信者と受信者の間で通信されます。

This encryption mask is computed separately for every packet that carries a header extension. Based on the non-encrypted portions of the headers and the signaled list of encrypted extension elements, a receiver can always determine the correct encryption mask for any encrypted header extension.

この暗号化マスクは、ヘッダー拡張を伝送するすべてのパケットに対して個別に計算されます。ヘッダーの非暗号化部分と、暗号化された拡張要素のシグナリングされたリストに基づいて、受信者は常に、暗号化されたヘッダー拡張の正しい暗号化マスクを決定できます。

The SRTP participant bitwise-ANDs the encryption mask with the keystream to produce a masked keystream. It then bitwise exclusive-ORs the header extension with this masked keystream to produce the ciphertext version of the header extension. (Thus, octets indicated as all-bits-1 in the encrypted mask are encrypted, whereas those indicated as all-bits-0 are not.)

SRTP参加者は、暗号化マスクとキーストリームの論理積をとって、マスクされたキーストリームを生成します。次に、このマスクされたキーストリームとヘッダー拡張のビット単位の排他的論理和を取り、ヘッダー拡張の暗号文バージョンを生成します。（したがって、暗号化されたマスクでall-bits-1として示されるオクテットは暗号化されますが、all-bits-0として示されるオクテットは暗号化されません。）

The header extension encryption process does not include the "defined by profile" or "length" fields of the header extension, only the field that Section 5.3.1 of [RFC3550] calls "header extension" proper, starting with the first [RFC5285] ID and length. Thus, both the encryption mask and the keystream begin at this point.

ヘッダー拡張の暗号化プロセスには、ヘッダー拡張の「プロファイルによって定義」または「長さ」フィールドは含まれず、[RFC3550]のセクション5.3.1が最初の[RFC5285]から始まる「適切なヘッダー拡張」を呼び出すフィールドのみが含まれますIDと長さ。したがって、暗号化マスクとキーストリームの両方がこの時点で始まります。

This header extension encryption process could, equivalently, be computed by considering the encryption mask as a mixture of the encrypted and unencrypted headers, i.e., as

このヘッダー拡張の暗号化プロセスは、同等に、暗号化マスクを暗号化されたヘッダーと暗号化されていないヘッダーの混合と見なすことで計算できます。

       EncryptedHeader = (Encrypt(Key, Plaintext) AND MASK) OR
                         (Plaintext AND (NOT MASK))

where Encrypt is the encryption function, MASK is the encryption mask, and AND, OR, and NOT are bitwise operations. This formulation of the encryption process might be preferred by implementations for which encryption is performed by a separate module and cannot be modified easily.

ここで、Encryptは暗号化関数、MASKは暗号化マスク、AND、OR、およびNOTはビット単位の演算です。暗号化プロセスのこの定式化は、暗号化が別のモジュールによって実行され、簡単に変更できない実装によって好まれる場合があります。

The SRTP authentication tag is computed across the encrypted header extension, i.e., the data that is actually transmitted on the wire. Thus, header extension encryption MUST be done before the authentication tag is computed, and authentication tag validation MUST be done on the encrypted header extensions. For receivers, header extension decryption SHOULD be done only after the receiver has validated the packet's message authentication tag, and the receiver MUST NOT take any actions based on decrypted headers, prior to validating the authentication tag, that could affect the security or proper functioning of the system.

SRTP認証タグは、暗号化されたヘッダー拡張、つまり実際に回線上で送信されるデータ全体で計算されます。したがって、ヘッダー拡張の暗号化は、認証タグが計算される前に行わなければならず、認証タグの検証は、暗号化されたヘッダー拡張で行わなければなりません（MUST）。受信者の場合、ヘッダー拡張の復号化は、受信者がパケットのメッセージ認証タグを検証した後にのみ行う必要があり、受信者は、認証タグを検証する前に、復号化されたヘッダーに基づいて、セキュリティまたは適切な機能に影響を与える可能性のあるアクションを実行してはなりません（MUST NOT）。システム。

3.1. Example Encryption Mask

3.1. 暗号化マスクの例

If a sender wished to send a header extension containing an encrypted SMPTE timecode [RFC5484] with ID 1, a plaintext transmission time offset [RFC5450] with ID 2, an encrypted audio level indication [RFC6464] with ID 3, and an encrypted NTP timestamp [RFC6051] with ID 4, the plaintext RTP header extension might look like this:

送信者がID 1の暗号化されたSMPTEタイムコード[RFC5484]、ID 2の平文送信時間オフセット[RFC5450]、ID 3の暗号化された音声レベル表示[RFC6464]、および暗号化されたNTPタイムスタンプを含むヘッダー拡張を送信したい場合[RFC6051] ID 4の場合、プレーンテキストRTPヘッダー拡張は次のようになります。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID=1 | len=7 |     SMTPE timecode (long form)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       SMTPE timecode (continued)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SMTPE (cont'd)|  ID=2 | len=2 | toffset                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | toffset (ct'd)|  ID=3 | len=0 | audio level   |  ID=4 | len=6 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       NTP timestamp (Variant B)                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       NTP timestamp (Variant B, cont'd)       | padding = 0   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Structure of Plaintext Example Header Extension

図1：プレーンテキストの例の構造ヘッダー拡張

The corresponding encryption mask would then be:

その場合、対応する暗号化マスクは次のようになります。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Encryption Mask for Example Header Extension

図2：ヘッダー拡張の例の暗号化マスク

In the mask, the octets corresponding to the payloads of the encrypted header extension elements are set to all-1 values, and the octets corresponding to non-encrypted header extension elements, element headers, and header extension padding are set to all-zero values.

マスクでは、暗号化ヘッダー拡張要素のペイロードに対応するオクテットはすべて1の値に設定され、非暗号化ヘッダー拡張要素、要素ヘッダー、およびヘッダー拡張パディングに対応するオクテットはすべてゼロの値に設定されます。

3.2. Header Extension Keystream Generation for Existing Encryption Transforms

3.2. 既存の暗号化変換用のヘッダー拡張キーストリーム生成

For the AES-CM and AES-f8 transforms [RFC3711], the SEED-CTR transform [RFC5669], and the AES_192_CM and AES_256_CM transforms [RFC6188], the header extension keystream SHALL be generated for each packet containing encrypted header extension elements using the same encryption transform and Initialization Vector (IV) as are used for that packet's SRTP payload, except that the SRTP encryption and salting keys k_e and k_s are replaced by the SRTP header encryption and header salting keys k_he and k_hs, respectively, as defined above.

AES-CMおよびAES-f8トランスフォーム[RFC3711]、SEED-CTRトランスフォーム[RFC5669]、およびAES_192_CMおよびAES_256_CMトランスフォーム[RFC6188]の場合、ヘッダー拡張キーストリームは、 SRTP暗号化およびソルティングキーk_eおよびk_sが、それぞれ上記で定義したSRTPヘッダー暗号化およびヘッダーソルティングキーk_heおよびk_hsに置き換えられていることを除いて、そのパケットのSRTPペイロードに使用されるものと同じ暗号化トランスフォームおよび初期化ベクトル（IV）。

For the SEED-CCM and SEED-GCM transforms [RFC5669], the header extension keystream SHALL be generated using the algorithm specified above for the SEED-CTR algorithm. (Because the Authenticated Encryption with Associated Data (AEAD) transform used on the payload in these algorithms includes the RTP header, including the RTP header extension, in its Associated Authenticated Data (AAD), counter-mode encryption for the header extension is believed to be of equivalent cryptographic strength to the CCM and GCM transforms.) For the NULL encryption transform [RFC3711], the header extension keystream SHALL be all-zero.

SEED-CCMおよびSEED-GCM変換[RFC5669]の場合、ヘッダー拡張キーストリームは、SEED-CTRアルゴリズムについて上記で指定されたアルゴリズムを使用して生成される必要があります。（これらのアルゴリズムのペイロードで使用されるAuthenticated Encryption with Associated Data（AEAD）トランスフォームは、RTPヘッダー拡張を含むRTPヘッダーをその関連認証データ（AAD）に含むため、ヘッダー拡張のカウンターモード暗号化は、 CCMおよびGCMトランスフォームと同等の暗号強度である。）NULL暗号化トランスフォーム[RFC3711]の場合、ヘッダー拡張キーストリームはすべてゼロである必要があります。

3.3. Header Extension Keystream Generation for Future Encryption Transforms

3.3. 将来の暗号化変換のためのヘッダー拡張キーストリーム生成

When new SRTP encryption transforms are defined, this document updates [RFC3711] as follows: in addition to the rules specified in Section 6 of RFC 3711, the Standards Track RFC defining the new transform MUST specify how the encryption transform is to be used with header extension encryption.

新しいSRTP暗号化トランスフォームが定義されると、このドキュメントは[RFC3711]を次のように更新します。RFC3711のセクション6で指定されたルールに加えて、新しいトランスフォームを定義するStandards Track RFCは、暗号化トランスフォームをヘッダーと共に使用する方法を指定する必要があります拡張暗号化。

It is RECOMMENDED that new transformations follow the same mechanisms as are defined in Section 3.2 of this document if they are applicable and are believed to be cryptographically adequate for the transform in question.

新しい変換が適用可能であり、問題の変換に暗号的に適切であると考えられる場合、新しい変換はこのドキュメントのセクション3.2で定義されているのと同じメカニズムに従うことが推奨されます。

4. Signaling (Setup) Information

4. シグナリング（セットアップ）情報

Encrypted header extension elements are signaled in the Session Description Protocol (SDP) extmap attribute using the URI "urn:ietf:params:rtp-hdrext:encrypt" followed by the URI of the header extension element being encrypted, as well as any extensionattributes that extension normally takes. Figure 3 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this grammar extension, extending the grammar defined in [RFC5285].

暗号化されたヘッダー拡張要素は、URI「urn：ietf：params：rtp-hdrext：encrypt」に続いて暗号化されているヘッダー拡張要素のURIを使用して、Session Description Protocol（SDP）extmap属性で通知されます。拡張子は通常かかります。図3は、この文法拡張を示し、[RFC5285]で定義されている文法を拡張した正式な拡張バッカスナウアフォーム（ABNF）[RFC5234]を示しています。

   enc-extensionname = %x75.72.6e.3a.69.65.74.66.3a.70.61.72.61.6d.73.3a
       %x72.74.70.2d.68.64.72.65.78.74.3a.65.6e.63.72.79.70.74
       ; "urn:ietf:params:rtp-hdrext:encrypt" in lower case

extmap =/ mapentry SP enc-extensionname SP extensionname [SP extensionattributes]

extmap = / mapentry SP enc-extensionname SP extensionname [SP extensionattributes]

; extmap, mapentry, extensionname, and extensionattributes ; are defined in [RFC5285]

; extmap、mapentry、extensionname、extensionattributes。 [RFC5285]で定義されています

Figure 3: Syntax of the "encrypt" extmap

図3：「暗号化」extmapの構文

Thus, for example, to signal an SRTP session using encrypted SMPTE timecodes [RFC5484], while simultaneously signaling plaintext transmission time offsets [RFC5450], an SDP document could contain the text shown in Figure 4 (line breaks have been added for formatting).

したがって、たとえば、暗号化されたSMPTEタイムコード[RFC5484]を使用してSRTPセッションを通知し、同時にプレーンテキストの送信時間オフセット[RFC5450]を通知するには、SDPドキュメントに図4に示すテキストを含めることができます（フォーマットのために改行が追加されています）。

   m=audio 49170 RTP/SAVP 0
   a=crypto:1 AES_CM_128_HMAC_SHA1_32 \
     inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
   a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt \
       urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24
   a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

Figure 4: Sample SDP Document Offering Encrypted Headers

図4：暗号化されたヘッダーを提供するサンプルSDPドキュメント

This example uses SDP security descriptions [RFC4568] for SRTP keying, but this is merely for illustration. Any SRTP keying mechanism to establish session keys will work.

この例ではSRTPキーイングにSDPセキュリティ記述[RFC4568]を使用していますが、これは単に説明のためのものです。セッションキーを確立するSRTPキーイングメカニズムはすべて機能します。

The extmap SDP attribute is defined in [RFC5285] as being either a session or media attribute. If the extmap for an encrypted header extension is specified as a media attribute, it MUST be specified only for media that use SRTP-based RTP profiles. If such an extmap is specified as a session attribute, there MUST be at least one media in the SDP session that uses an SRTP-based RTP profile. The session-level extmap applies to all the SRTP-based media in the session and MUST be ignored for all other (non-SRTP or non-RTP) media.

extmap SDP属性は、セッションまたはメディア属性のいずれかとして[RFC5285]で定義されています。暗号化されたヘッダー拡張のextmapがメディア属性として指定されている場合は、SRTPベースのRTPプロファイルを使用するメディアに対してのみ指定する必要があります。そのようなextmapがセッション属性として指定されている場合、SRTPベースのRTPプロファイルを使用するSDPセッションに少なくとも1つのメディアが存在する必要があります。セッションレベルのextmapは、セッション内のすべてのSRTPベースのメディアに適用され、他のすべての（非SRTPまたは非RTP）メディアでは無視する必要があります。

The "urn:ietf:params:rtp-hdrext:encrypt" extension MUST NOT be recursively applied to itself.

「urn：ietf：params：rtp-hdrext：encrypt」拡張は、それ自体に再帰的に適用してはなりません。

4.1. Backward Compatibility

4.1. 下位互換性

Following the procedures in [RFC5285], an SDP endpoint that does not understand the "urn:ietf:params:rtp-hdrext:encrypt" extension URI will ignore the extension and, for SDP offer/answer, will negotiate not to use it.

[RFC5285]の手順に従って、「urn：ietf：params：rtp-hdrext：encrypt」拡張URIを理解しないSDPエンドポイントは拡張を無視し、SDPオファー/アンサーの場合、それを使用しないように交渉します。

For backward compatibility with endpoints that do not implement this specification, in a negotiated session (whether using offer/answer or some other means), best-effort encryption of a header extension element is possible: an endpoint MAY offer the same header extension element both encrypted and unencrypted. An offerer MUST offer only best-effort negotiation when lack of confidentiality would be acceptable in the backward-compatible case. Answerers (or equivalent peers in a negotiation) that understand header extension encryption SHOULD choose the encrypted form of the offered header extension element and mark the unencrypted form "inactive", unless they have an explicit reason to prefer the unencrypted form. In all cases, answerers MUST NOT negotiate the use of, and senders MUST NOT send, both encrypted and unencrypted forms of the same header extension.

この仕様を実装していないエンドポイントとの下位互換性のために、ネゴシエートされたセッション（オファー/アンサーまたはその他の手段を使用しているかどうか）では、ヘッダー拡張要素のベストエフォート暗号化が可能です。エンドポイントは同じヘッダー拡張要素の両方を提供できます（MAY）。暗号化および非暗号化。提供者は、下位互換性のあるケースで機密性の欠如が許容される場合、ベストエフォートの交渉のみを提供しなければなりません。ヘッダー拡張の暗号化を理解する回答者（またはネゴシエーションの同等のピア）は、提供されたヘッダー拡張要素の暗号化された形式を選択し、暗号化されていない形式を好む明確な理由がない限り、暗号化されていない形式を「非アクティブ」としてマークする必要があります。すべての場合において、同じヘッダー拡張の暗号化された形式と暗号化されていない形式の両方について、応答者は使用をネゴシエートしてはならず、送信者は送信してはなりません。

Note that, as always, users of best-effort encryption MUST be cautious of bid-down attacks, where a man-in-the-middle attacker removes a higher-security option, forcing endpoints to negotiate a lower-security one. Appropriate countermeasures depend on the signaling protocol in use, but users can ensure, for example, that signaling is integrity-protected.

いつものように、ベストエフォート暗号化のユーザーは、中間者攻撃者が高セキュリティオプションを削除し、エンドポイントに低セキュリティオプションをネゴシエートさせる強制ダウン攻撃に注意する必要があることに注意してください。適切な対策は、使用中のシグナリングプロトコルによって異なりますが、たとえば、シグナリングが整合性保護されていることを確認できます。

5. Security Considerations

5. セキュリティに関する考慮事項

The security properties of header extension elements protected by the mechanism in this document are equivalent to those for SRTP payloads.

このドキュメントのメカニズムで保護されているヘッダー拡張要素のセキュリティプロパティは、SRTPペイロードのセキュリティプロパティと同等です。

The mechanism defined in this document does not provide confidentiality about which header extension elements are used for a given SRTP packet, only for the content of those header extension elements. This appears to be in the spirit of SRTP itself, which does not encrypt RTP headers. If this is a concern, an alternate mechanism would be needed to provide confidentiality.

このドキュメントで定義されているメカニズムでは、特定のSRTPパケットにどのヘッダー拡張要素が使用されるかについての機密性は提供されません。これらのヘッダー拡張要素のコンテンツに対してのみです。これは、RTPヘッダーを暗号化しないSRTP自体の精神にあるようです。これが問題になる場合は、機密性を提供するための代替メカニズムが必要になります。

For the two-byte-header form of header extension elements (0x100N, where "N" is the appbits field), this mechanism does not provide any protection to zero-length header extension elements (for which their presence or absence is the only information they carry). It also does not provide any protection for the appbits (field 256, the lowest four bits of the "defined by profile" field) of the two-byte headers. Neither of these features is present in the one-byte-header form of header extension elements (0xBEDE), so these limitations do not apply in that case.

2バイトヘッダー形式のヘッダー拡張要素（0x100N、 "N"はappbitsフィールド）の場合、このメカニズムは、長さゼロのヘッダー拡張要素（存在または不在が唯一の情報である）を保護しません。彼らは運ぶ）。また、2バイトヘッダーのappbits（フィールド256、「プロファイルによって定義」フィールドの最下位4ビット）に対する保護も提供しません。これらの機能はどちらも、ヘッダー拡張要素の1バイトヘッダー形式（0xBEDE）には存在しないため、これらの制限はその場合には適用されません。

This mechanism cannot protect RTP header extensions that do not use the mechanism defined in [RFC5285].

このメカニズムは、[RFC5285]で定義されたメカニズムを使用しないRTPヘッダー拡張を保護できません。

This document does not specify the circumstances in which extension header encryption should be used. Documents defining specific header extension elements should provide guidance on when encryption is appropriate for these elements.

このドキュメントでは、拡張ヘッダー暗号化を使用する必要がある状況を指定していません。特定のヘッダー拡張要素を定義するドキュメントは、暗号化がこれらの要素に適切である場合のガイダンスを提供する必要があります。

If a middlebox does not have access to the SRTP authentication keys, it has no way to verify the authenticity of unencrypted RTP header extension elements (or the unencrypted RTP header), even though it can monitor them. Therefore, such middleboxes MUST treat such headers as untrusted and potentially generated by an attacker, in the same way as they treat unauthenticated traffic. (This does not mean that middleboxes cannot view and interpret such traffic, of course, only that appropriate skepticism needs to be maintained about the results of such interpretation.) There is no mechanism defined to protect header extensions with different algorithms or encryption keys than are used to protect the RTP payloads. In particular, it is not possible to provide confidentiality for a header extension while leaving the payload in cleartext.

ミドルボックスがSRTP認証キーにアクセスできない場合、ミドルボックスはそれらを監視できますが、暗号化されていないRTPヘッダー拡張要素（または暗号化されていないRTPヘッダー）の信頼性を検証する方法はありません。したがって、このようなミドルボックスは、認証されていないトラフィックを処理するのと同じ方法で、そのようなヘッダーを信頼できないものとして扱い、攻撃者によって生成される可能性があります。（これは、ミドルボックスがそのようなトラフィックを表示および解釈できないことを意味しません。もちろん、そのような解釈の結果について適切な懐疑論を維持する必要があるだけです。）異なるアルゴリズムまたは暗号化キーでヘッダー拡張を保護するメカニズムは定義されていません。 RTPペイロードの保護に使用されます。特に、ペイロードをクリアテキストのままにしながら、ヘッダー拡張の機密性を提供することはできません。

The dangers of using weak or NULL authentication with SRTP, described in Section 9.5 of [RFC3711], apply to encrypted header extensions as well. In particular, since some header extension elements will have some easily guessed plaintext bits, strong authentication is REQUIRED if an attacker setting such bits could have a meaningful effect on the behavior of the system.

[RFC3711]のセクション9.5で説明されている、SRTPで弱い認証またはNULL認証を使用することの危険性は、暗号化されたヘッダー拡張にも適用されます。特に、一部のヘッダー拡張要素には簡単に推測できるプレーンテキストビットが含まれるため、攻撃者がそのようなビットを設定してシステムの動作に意味のある影響を与える可能性がある場合は、強力な認証が必要です。

The technique defined in this document can be applied only to encryption transforms that work by generating a pseudorandom keystream and bitwise exclusive-ORing it with the plaintext, such as CTR or f8. It will not work with ECB, CBC, or any other encryption method that does not use a keystream.

このドキュメントで定義されている手法は、疑似ランダムキーストリームを生成し、それをCTRやf8などの平文とビット単位で排他的論理和することによって機能する暗号化変換にのみ適用できます。 ECB、CBC、またはキーストリームを使用しないその他の暗号化方法では機能しません。

6. IANA Considerations

6. IANAに関する考慮事項

This document defines a new extension URI to the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:

このドキュメントでは、次のデータに従って、リアルタイム転送プロトコル（RTP）パラメータレジストリのRTPコンパクトヘッダー拡張サブレジストリへの新しい拡張URIを定義します。

      Extension URI:  urn:ietf:params:rtp-hdrext:encrypt
      Description:    Encrypted header extension element
      Contact:        jonathan@vidyo.com
      Reference:      RFC 6904

7. Acknowledgments

7. 謝辞

Thanks to Benoit Claise, Roni Even, Stephen Farrell, Kevin Igoe, Joel Jaeggli, David McGrew, David Singer, Robert Sparks, Magnus Westerlund, Qin Wu, and Felix Wyss for their comments and suggestions in the development of this specification.

この仕様の開発に関するコメントと提案を提供してくれたBenoit Claise、Roni Even、Stephen Farrell、Kevin Igoe、Joel Jaeggli、David McGrew、David Singer、Robert Sparks、Magnus Westerlund、Qin Wu、Felix Wyssに感謝します。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。

[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.

[RFC5285]シンガー、D。およびH.デジニーニ、「RTPヘッダー拡張の一般的なメカニズム」、RFC 5285、2008年7月。

[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)", RFC 5669, August 2010.

[RFC5669] Yoon、S.、Kim、J.、Park、H.、Jeong、H。、およびY. Won、「SEED暗号アルゴリズムとセキュアリアルタイムトランスポートプロトコル（SRTP）でのその使用」、RFC 5669、2010年8月。

[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, March 2011.

[RFC6188] McGrew、D。、「Secure RTPでのAES-192およびAES-256の使用」、RFC 6188、2011年3月。

8.2. Informative References

8.2. 参考引用

[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.

[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「メディアストリームのセッション記述プロトコル（SDP）セキュリティ記述」、RFC 4568、2006年7月。

[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, March 2009.

[RFC5450] Singer、D。およびH. Desineni、「RTPストリームの伝送時間オフセット」、RFC 5450、2009年3月。

[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, March 2009.

[RFC5484] Singer、D。、「Associating Time-Codes with RTP Streams」、RFC 5484、2009年3月。

[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.

[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、2010年11月。

[RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, December 2011.

[RFC6464] Lennox、J.、Ivov、E。、およびE. Marocco、「クライアントからミキサーへのオーディオレベル表示のためのリアルタイムトランスポートプロトコル（RTP）ヘッダー拡張」、RFC 6464、2011年12月。

[RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, December 2011.

[RFC6465] Ivov、E.、Marocco、E。、およびJ. Lennox、「ミキサーからクライアントへのオーディオレベル表示のためのリアルタイムトランスポートプロトコル（RTP）ヘッダー拡張」、RFC 6465、2011年12月。

Appendix A. Test Vectors

付録A.テストベクトル

A.1. Key Derivation Test Vectors

A.1. 鍵導出テストベクトル

This section provides test data for the header extension key derivation function, using AES-128 in Counter Mode. (The algorithms and keys used are the same as those for the test vectors in Appendix B.3 of [RFC3711].)

このセクションでは、AES-128をカウンターモードで使用して、ヘッダー拡張キー導出関数のテストデータを提供します。（使用されるアルゴリズムとキーは、[RFC3711]の付録B.3にあるテストベクトルのものと同じです。）

The inputs to the key derivation function are the 16-octet master key and the 14-octet master salt:

キー導出関数への入力は、16オクテットのマスターキーと14オクテットのマスターソルトです。

      master key: E1F97A0D3E018BE0D64FA32C06DE4139

master salt: 0EC675AD498AFEEBB6960B3AABE6

マスターソルト：0EC675AD498AFEEBB6960B3AABE6

Following [RFC3711], the input block for AES-CM is generated by exclusive-ORing the master salt with the concatenation of the encryption key label 0x06 with (index DIV kdr), then padding on the right with two null octets, which implements the multiply-by-2^16 operation (see Section 4.3.3 of [RFC3711]). The resulting value is then AES-CM-encrypted using the master key to get the cipher key.

[RFC3711]に続いて、AES-CMの入力ブロックは、マスターソルトと暗号化キーラベル0x06の（インデックスDIV kdr）の連結との排他的論理和をとることによって生成され、次に2つのヌクオクテットで右側にパディングされます。 multiply-by-2 ^ 16演算（[RFC3711]のセクション4.3.3を参照）。結果の値は、マスターキーを使用してAES-CMで暗号化され、暗号キーが取得されます。

     index DIV kdr:                    000000000000
     label:                          06
     master salt:      0EC675AD498AFEEBB6960B3AABE6
     --------------------------------------------------
     XOR:              0EC675AD498AFEEDB6960B3AABE6     (x, PRF input)

     x*2^16:           0EC675AD498AFEEDB6960B3AABE60000 (AES-CM input)

hdr. cipher key: 549752054D6FB708622C4A2E596A1B93 (AES-CM output)

hdr。暗号キー：549752054D6FB708622C4A2E596A1B93（AES-CM出力）

Next, we show how the cipher salt is generated. The input block for AES-CM is generated by exclusive-ORing the master salt with the concatenation of the encryption salt label. That value is padded and encrypted as above.

次に、暗号ソルトがどのように生成されるかを示します。 AES-CMの入力ブロックは、マスターソルトと暗号化ソルトラベルの連結の排他的論理和によって生成されます。その値は上記のように埋め込まれ、暗号化されます。

index DIV kdr: 000000000000 label: 07 master salt: 0EC675AD498AFEEBB6960B3AABE6

インデックスDIV kdr：000000000000ラベル：07マスターソルト：0EC675AD498AFEEBB6960B3AABE6

     --------------------------------------------------
     XOR:              0EC675AD498AFEECB6960B3AABE6     (x, PRF input)

     x*2^16:           0EC675AD498AFEECB6960B3AABE60000 (AES-CM input)

AB01818174C40D39A3781F7C2D270733 (AES-CM ouptut)

AB01818174C40D39A3781F7C2D270733（AES-GCM出力）

hdr. cipher salt: AB01818174C40D39A3781F7C2D27

hdr。暗号塩：AB01818174C40D39A3781F7C2D27

A.2. Header Encryption Test Vectors Using AES-CM

A.2. AES-CMを使用したヘッダー暗号化テストベクトル

This section provides test vectors for the encryption of a header extension using the AES_CM cryptographic transform.

このセクションでは、AES_CM暗号変換を使用してヘッダー拡張を暗号化するためのテストベクタを提供します。

The header extension is encrypted using the header cipher key and header cipher salt computed in Appendix A.1. The header extension is carried in an SRTP-encrypted RTP packet with SSRC 0xCAFEBABE, sequence number 0x1234, and an all-zero rollover counter.

ヘッダー拡張は、付録A.1で計算されたヘッダー暗号鍵とヘッダー暗号ソルトを使用して暗号化されます。ヘッダー拡張は、SSRC 0xCAFEBABE、シーケンス番号0x1234、およびすべてゼロのロールオーバーカウンターを備えたSRTP暗号化RTPパケットで伝送されます。

Session Key: 549752054D6FB708622C4A2E596A1B93 Session Salt: AB01818174C40D39A3781F7C2D27

セッションキー：549752054D6FB708622C4A2E596A1B93セッションソルト：AB01818174C40D39A3781F7C2D27

       SSRC:                     CAFEBABE
       Rollover Counter:                 00000000
       Sequence Number:                          1234
       ----------------------------------------------
       Init. Counter:    AB018181BE3AB787A3781F7C3F130000

The SRTP session was negotiated to indicate that header extension ID values 1, 3, and 4 are encrypted.

SRTPセッションは、ヘッダー拡張ID値1、3、および4が暗号化されていることを示すためにネゴシエートされました。

In hexadecimal, the header extension being encrypted is as follows (spaces have been added to show the internal structure of the header extension):

16進数では、暗号化されるヘッダー拡張は次のようになります（ヘッダー拡張の内部構造を示すためにスペースが追加されています）。

17 414273A475262748 22 0000C8 30 8E 46 55996386B395FB 00

This header extension is 24 bytes long. (Its values are intended to represent plausible values of the header extension elements shown in Section 3.1, but their specific meaning is not important for the example.) The header extension "defined by profile" and "length" fields, which in this case are BEDE 0006 in hexadecimal, are not included in the encryption process.

このヘッダー拡張は24バイトの長さです。（その値は、セクション3.1に示すヘッダー拡張要素のもっともらしい値を表すことを目的としていますが、例では特定の意味は重要ではありません。）ヘッダー拡張の「プロファイルによって定義された」フィールドと「長さ」フィールドは、この場合は16進数のBEDE 0006は暗号化プロセスに含まれていません。

In hexadecimal, the corresponding encryption mask selecting the bodies of header extensions 1, 2, and 4 (corresponding to the mask in Figure 2) is:

16進数では、ヘッダー拡張1、2、および4の本体を選択する対応する暗号化マスク（図2のマスクに対応）は次のとおりです。

00 FFFFFFFFFFFFFFFF 00 000000 00 FF 00 FFFFFFFFFFFFFF 00

Finally, we compute the keystream from the session key and the initial counter, apply the mask to the keystream, and then exclusive-OR the keystream with the plaintext:

最後に、セッションキーと初期カウンターからキーストリームを計算し、マスクをキーストリームに適用してから、キーストリームとプレーンテキストの排他的論理和をとります。

Initial keystream: 1E19C8E1D481C779549ED1617AAA1B7A FC0D933AE7ED6CC8 Mask (hex): 00FFFFFFFFFFFFFFFF0000000000FF00 FFFFFFFFFFFFFF00 Masked keystream: 0019C8E1D481C7795400000000001B00 FC0D933AE7ED6C00 Plaintext: 17414273A475262748220000C8308E46 55996386B395FB00 Ciphertext: 17588A9270F4E15E1C220000C8309546 A994F0BC54789700

初期キーストリーム：1E19C8E1D481C779549ED1617AAA1B7A FC0D933AE7ED6CC8マスク（16進数）：00FFFFFFFFFFFFFFFF0000000000FF00 FFFFFFFFFFFFFF00仮面のキーストリーム：0019C8E1D481C7795400000000001B00 FC0D933AE7ED6C00平文：17414273A475262748220000C8308E46 55996386B395FB00暗号文：17588A9270F4E15E1C220000C8309546 A994F0BC54789700

Author's Address

著者のアドレス

Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US

Jonathan Lennox Vidyo、Inc. 433 Hackensack Avenue Seventh Floor Hackensack、NJ 07601 US

   EMail: jonathan@vidyo.com