[要約] RFC 7425は、AdobeのRTMFPプロファイルに関する仕様であり、Flash Communicationのためのものです。このRFCの目的は、RTMFPプロトコルの機能と動作を定義し、Flashベースのコミュニケーションアプリケーションの開発を支援することです。
Independent Submission M. Thornburgh
Request for Comments: 7425 Adobe
Category: Informational December 2014
ISSN: 2070-1721
Adobe's RTMFP Profile for Flash Communication
フラッシュ通信用のアドビのRTMFPプロファイル
Abstract
概要
This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.
このメモでは、Adobeのセキュアリアルタイムメディアフロープロトコル（RTMFP）を使用して、Adobe Flashプラットフォーム通信のビデオ、オーディオ、およびデータメッセージを転送する方法について説明します。このアプリケーションプロファイルの側面には、暗号化方式とデータ形式、フローメタデータ形式、およびクライアントサーバーとピアツーピア通信のプロトコルの詳細が含まれます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7425.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7425で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントは、RFCとして公開するためにフォーマットしたり、英語以外の言語に翻訳したりする場合を除き、変更したり、その派生物を作成したりすることはできません。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Common Syntax Elements ..........................................4
4. Cryptography Profile ............................................5
4.1. Default Session Key ........................................5
4.2. Diffie-Hellman Groups ......................................6
4.3. Certificates ...............................................6
4.3.1. Format ..............................................6
4.3.2. Fingerprint .........................................7
4.3.3. Options .............................................7
4.3.3.1. Hostname ...................................8
4.3.3.2. Accepts Ancillary Data .....................8
4.3.3.3. Extra Randomness ...........................8
4.3.3.4. Supported Ephemeral Diffie-Hellman Group ...9
4.3.3.5. Static Diffie-Hellman Public Key ...........9
4.3.4. Authenticity .......................................10
4.3.5. Signing and Verifying Messages .....................10
4.3.5.1. Options ...................................11
4.3.5.1.1. Simple Password ................11
4.3.6. Glare Resolution ...................................13
4.3.7. Session Override ...................................13
4.4. Endpoint Discriminators ...................................13
4.4.1. Format .............................................14
4.4.2. Options ............................................14
4.4.2.1. Required Hostname .........................15
4.4.2.2. Ancillary Data ............................15
4.4.2.3. Fingerprint ...............................16
4.4.3. Certificate Selection ..............................16
4.4.4. Canonical Endpoint Discriminator ...................17
4.5. Session Keying Components .................................18
4.5.1. Format .............................................19
4.5.2. Options ............................................19
4.5.2.1. Ephemeral Diffie-Hellman Public Key .......20
4.5.2.2. Extra Randomness ..........................20
4.5.2.3. Diffie-Hellman Group Select ...............21
4.5.2.4. HMAC Negotiation ..........................21
4.5.2.5. Session Sequence Number Negotiation .......22
4.6. Session Key Computation ...................................23
4.6.1. Public Key Selection ...............................23
4.6.1.1. Initiator and Responder Ephemeral .........23
4.6.1.2. Initiator Ephemeral and Responder Static ..23
4.6.1.3. Initiator Static and Responder Ephemeral ..24
4.6.1.4. Initiator and Responder Static ............24
4.6.2. Diffie-Hellman Shared Secret .......................24
4.6.3. Packet Encrypt/Decrypt Keys ........................25
4.6.4. Packet HMAC Send/Receive Keys ......................25
4.6.5. Session Nonces .....................................26
4.6.6. Session Sequence Number ............................26
4.7. Packet Encryption .........................................27
4.7.1. Cipher .............................................27
4.7.2. Format .............................................27
4.7.3. Verification .......................................29
4.7.3.1. Simple Checksum ...........................30
4.7.3.2. HMAC ......................................30
4.7.3.3. Session Sequence Number ...................31
5. Flash Communication ............................................31
5.1. RTMP Messages .............................................31
5.1.1. Flow Metadata ......................................32
5.1.2. Message Mapping ....................................34
5.2. Flow Synchronization ......................................35
5.3. Client-to-Server Connection ...............................36
5.3.1. Connecting .........................................36
5.3.2. Server-to-Client Return Control Flow ...............37
5.3.3. setPeerInfo Command ................................37
5.3.4. Set Keepalive Timers Command .......................39
5.3.5. Additional Flows for Streams .......................40
5.3.5.1. To Server .................................40
5.3.5.2. From Server ...............................40
5.3.5.3. Closing Stream Flows ......................41
5.3.6. Closing the Connection .............................41
5.3.7. Example ............................................42
5.4. Direct Peer-to-Peer Streams ...............................43
5.4.1. Connecting .........................................43
5.4.2. Return Flows for Stream ............................43
5.4.3. Closing the Connection .............................44
6. IANA Considerations ............................................44
6.1. RTMFP URI Scheme Registration .............................44
7. Security Considerations ........................................46
8. References .....................................................47
8.1. Normative References ......................................47
8.2. Informative References ....................................49
Acknowledgements ..................................................49
Author's Address ..................................................49
Adobe's Secure Real-Time Media Flow Protocol (RTMFP) [RFC7016] is a general-purpose transport service for real-time media and bulk data in IP networks, and it is suited to client-server and peer-to-peer (P2P) communication. RTMFP provides a generalized framework for securing its communications according to the needs of its application.
アドビのセキュアリアルタイムメディアフロープロトコル（RTMFP）[RFC7016]は、IPネットワークのリアルタイムメディアとバルクデータ用の汎用トランスポートサービスであり、クライアントサーバーとピアツーピア（P2P）に適していますコミュニケーション。 RTMFPは、アプリケーションのニーズに応じて通信を保護するための一般的なフレームワークを提供します。
The Flash platform comprises the Flash runtime (including Flash Player) from Adobe Systems Incorporated, communication servers such as Adobe Media Server, and interoperable clients and servers provided by other parties.
Flashプラットフォームは、Adobe Systems IncorporatedのFlashランタイム（Flash Playerを含む）、Adobe Media Serverなどの通信サーバー、および他の関係者が提供する相互運用可能なクライアントとサーバーで構成されます。
Real-time streaming network communication for the Flash platform of video, audio, and data typically uses Adobe's Real-Time Messaging Protocol (RTMP) [RTMP] messages. RTMP messages were originally designed to be transported over RTMP Chunk Stream in TCP [RTMP]; however, other transports (such as the one described in this memo) are possible.
ビデオ、オーディオ、およびデータのFlashプラットフォーム用のリアルタイムストリーミングネットワーク通信は、通常、Adobeのリアルタイムメッセージングプロトコル（RTMP）[RTMP]メッセージを使用します。 RTMPメッセージはもともと、TCP [RTMP]のRTMPチャンクストリームを介して転送されるように設計されていました。ただし、他のトランスポート（このメモで説明されているものなど）も可能です。
This memo specifies the syntax and semantics for transporting RTMP messages over RTMFP, and it extends Flash communication semantics to include direct P2P communication. This memo further specifies a concrete Cryptography Profile for RTMFP tailored to the application and cryptographic needs of Flash platform client-server and P2P communications.
このメモは、RTMFPを介してRTMPメッセージを転送するための構文とセマンティクスを指定し、直接P2P通信を含めるようにFlash通信セマンティクスを拡張します。このメモはさらに、アプリケーションとFlashプラットフォームのクライアント/サーバーおよびP2P通信の暗号化のニーズに合わせたRTMFPの具体的な暗号化プロファイルを指定します。
These protocols and profiles were developed by Adobe Systems Incorporated and are not the product of an IETF activity.
これらのプロトコルとプロファイルはAdobe Systems Incorporatedによって開発されたものであり、IETFアクティビティの製品ではありません。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
"HMAC" means the Keyed-Hash Message Authentication Code (HMAC) algorithm [RFC2104].
「HMAC」とは、キー付きハッシュメッセージ認証コード（HMAC）アルゴリズム[RFC2104]を意味します。
"HMAC-SHA256" means HMAC using the SHA-256 Secure Hash Algorithm [SHA256] [RFC6234].
「HMAC-SHA256」とは、SHA-256セキュアハッシュアルゴリズム[SHA256] [RFC6234]を使用するHMACを意味します。
"HMAC-SHA256(K, M)" means the calculation of the HMAC-SHA256 of message M using key K.
「HMAC-SHA256（K、M）」は、キーKを使用したメッセージMのHMAC-SHA256の計算を意味します。
Definitions of types and structures in this specification use traditional text diagrams paired with procedural descriptions using a C-like syntax. The C-like procedural descriptions SHALL be construed as definitive.
この仕様のタイプと構造の定義では、Cのような構文を使用した手続き型の説明と対になっている従来のテキスト図を使用します。 Cのような手続き型の記述は、決定的なものとして解釈されるべきです。
Structures are packed to take only as many bytes as explicitly indicated. There is no 32-bit alignment constraint, and fields are not padded for alignment unless explicitly indicated or described. Text diagrams may include a bit ruler across the top; this is a convenience for counting bits in individual fields and does not necessarily imply field alignment on a multiple of the ruler width.
構造体は、明示的に示されているバイト数だけを使用するようにパックされます。 32ビットのアライメント制約はなく、明示的に指定または説明されていない限り、フィールドはアライメントのためにパディングされません。テキスト図には上部にビット定規が含まれている場合があります。これは、個々のフィールドのビットをカウントするのに便利であり、ルーラー幅の倍数でのフィールドの整列を必ずしも意味しません。
Unless specified otherwise, reserved fields SHOULD be set to 0 by a sender and MUST be ignored by a receiver.
特に明記しない限り、予約済みフィールドは送信者によって0に設定されるべきで（SHOULD）、受信者によって無視されなければならない（MUST）。
The procedural syntax of this specification defines correct and error-free encoded inputs to a parser. The procedural syntax does not describe a fully featured parser, including error detection and handling. Implementations MUST include means to identify error circumstances, including truncations causing elementary or composed types not to fit inside containing structures, fields, or elements. Unless specified otherwise, an error circumstance SHALL abort the parsing and processing of an element and its enclosing elements.
この仕様の手続き型構文は、パーサーへの正しくエラーのないエンコードされた入力を定義します。手続き型構文は、エラーの検出と処理を含む、完全に機能するパーサーを記述していません。実装には、エラーの状況を特定する手段を含める必要があります。これには、基本型または構成型が、含まれている構造、フィールド、または要素の内部に収まらない原因となる切り捨てが含まれます。特に明記されていない限り、エラー状況は、要素とその要素の解析と処理を中止するものとします（SHALL）。
This memo uses the elementary and composed types described in Section 2.1 of RFC 7016. The definitions of that section are incorporated by reference as though fully set forth here.
このメモは、RFC 7016のセクション2.1で説明されている基本タイプと構成タイプを使用しています。そのセクションの定義は、ここで完全に説明されているかのように、参照により組み込まれます。
RTMFP defines a general security framework but delegates specifics, such as packet encryption ciphers and key agreement algorithms, to an application-defined Cryptography Profile.
RTMFPは、一般的なセキュリティフレームワークを定義しますが、パケット暗号化暗号やキー合意アルゴリズムなどの詳細を、アプリケーション定義の暗号化プロファイルに委任します。
This section defines the RTMFP Cryptography Profile for Flash platform communication.
このセクションでは、Flashプラットフォーム通信用のRTMFP暗号化プロファイルを定義します。
RTMFP uses a Default Session Key and associated default cipher configuration during session startup handshaking, where session-specific keys and ciphers are negotiated.
RTMFPは、セッション固有のキーと暗号がネゴシエートされるセッション起動ハンドシェイク中に、デフォルトセッションキーと関連するデフォルト暗号構成を使用します。
The default cipher is the Advanced Encryption Standard [AES] with 128-bit keys operating in Cipher Block Chaining [CBC] mode, as described in Section 4.7.1. The Default Session Key is the 16 bytes of the string "Adobe Systems 02" encoded in UTF-8 [RFC3629]:
デフォルトの暗号は、セクション4.7.1で説明されているように、暗号ブロックチェーン[CBC]モードで動作する128ビットキーを備えたAdvanced Encryption Standard [AES]です。デフォルトのセッションキーは、UTF-8 [RFC3629]でエンコードされた「Adobe Systems 02」という文字列の16バイトです。
Hex: 41 64 6F 62 65 20 53 79 73 74 65 6D 73 20 30 32
六角：41 64 6F 62 65 20 53 79 73 74 65 6D 73 20 30 32
The Default Session Key uses checksum mode for packet verification and does not use session sequence numbers (Section 4.7.3).
デフォルトセッションキーは、パケット検証にチェックサムモードを使用し、セッションシーケンス番号を使用しません（セクション4.7.3）。
Implementations conforming to this profile MUST support Diffie-Hellman [DH] modular exponentiation (MODP) group 2 (1024 bits) as defined in [RFC7296], and SHOULD support Diffie-Hellman MODP group 5 (1536 bits) and group 14 (2048 bits) as defined in [RFC3526]. Implementations MAY support additional groups.
このプロファイルに準拠する実装は、[RFC7296]で定義されているDiffie-Hellman [DH]モジュラ指数（MODP）グループ2（1024ビット）をサポートする必要があり、Diffie-Hellman MODPグループ5（1536ビット）とグループ14（2048ビット）をサポートする必要があります（SHOULD）。 ）[RFC3526]で定義されています。実装は追加のグループをサポートしてもよい（MAY）。
This section defines the certificate format for this Cryptography Profile, and the mapping to the abstract properties and semantics for RTMFP endpoint identities.
このセクションでは、この暗号化プロファイルの証明書形式と、RTMFPエンドポイントIDの抽象プロパティおよびセマンティクスへのマッピングを定義します。
A certificate in this profile is encoded as a sequence of zero or more RTMFP Options and Markers (Section 2.1.3 of RFC 7016). The first marker (if any) in the certificate separates the canonical section of the certificate from the remainder. Some options are ignored if they occur outside of the canonical section (that is, after the first marker).
このプロファイルの証明書は、0個以上のRTMFPオプションとマーカーのシーケンスとしてエンコードされます（RFC 7016のセクション2.1.3）。証明書の最初のマーカー（存在する場合）は、証明書の正規セクションを残りのセクションから分離します。一部のオプションは、正規セクションの外（つまり、最初のマーカーの後）にある場合は無視されます。
+~~~/~~~/~~~+ +~~~/~~~/~~~+~~~~~+~~~/~~~/~~~+ +~~~/~~~/~~~+
| L \ T \ V |...| L \ T \ V | 0 | L \ T \ V |...| L \ T \ V |
+~~~/~~~/~~~+ +~~~/~~~/~~~+~~~~~+~~~/~~~/~~~+ +~~~/~~~/~~~+
^ ^ ^ ^ ^
| Zero or more non-empty | | | Zero or more Options |
| Options | | +------ or Markers -------+
| | |
+--- Canonical Section ---+ +---- First Marker
(if present)
struct certificate_t
{
canonicalStart = remainder();
canonicalEnd = remainder();
markerFound = false;
while(remainder() > 0)
{
option_t option :variable*8;
if(0 == option.length)
markerFound = true;
else if(!markerFound)
canonicalEnd = remainder();
};
canonicalSectionLength = canonicalStart - canonicalEnd;
} :variable*8;
A certificate's fingerprint is the SHA-256 hash [SHA256] of the canonical section of the certificate (that is, the hash of the first canonicalSectionLength bytes of the certificate).
証明書のフィンガープリントは、証明書の正規セクションのSHA-256ハッシュ[SHA256]（つまり、証明書の最初のcanonicalSectionLengthバイトのハッシュ）です。
The certificate's fingerprint is also called the "peer ID".
証明書のフィンガープリントは、「ピアID」とも呼ばれます。
This section lists options that can appear in a certificate. The following option type codes are defined:
このセクションには、証明書に表示されるオプションがリストされています。次のオプションタイプコードが定義されています。
0x00: Hostname (must be in canonical section) (Section 4.3.3.1)
0x00：ホスト名（正規セクションにある必要があります）（セクション4.3.3.1）
0x0a: Accepts Ancillary Data (must be in canonical section) (Section 4.3.3.2)
0x0a：補助データを受け入れます（正規セクションにある必要があります）（セクション4.3.3.2）
0x0e: Extra Randomness (Section 4.3.3.3)
0x0e：追加のランダム性（セクション4.3.3.3）
0x15: Supported Ephemeral Diffie-Hellman Group (must be in canonical section) (Section 4.3.3.4)
0x15：サポートされているエフェメラルDiffie-Hellmanグループ（正規セクションにある必要があります）（セクション4.3.3.4）
0x1d: Static Diffie-Hellman Public Key (must be in canonical section) (Section 4.3.3.5)
0x1d：静的Diffie-Hellman公開鍵（正規セクションにある必要があります）（セクション4.3.3.5）
An implementation MUST ignore a certificate option type that is not understood.
実装は、理解されていない証明書オプションタイプを無視する必要があります。
This option gives an optional hostname for the endpoint. This option MUST be ignored if is not in the canonical section. This option MUST NOT occur more than once in a certificate.
このオプションは、エンドポイントのオプションのホスト名を提供します。正規セクションにない場合、このオプションは無視する必要があります。このオプションは、証明書で複数回使用してはなりません。
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | 0x00 \ | hostname |
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct hostnameCertOptionValue_t
{
uint8_t hostname[remainder()];
} :remainder()*8;
This option indicates that the endpoint will accept an Endpoint Discriminator encoding an Ancillary Data option (Section 4.4.2.2). This option MUST be ignored if it is not in the canonical section.
このオプションは、エンドポイントが補助データオプションをエンコードするEndpoint Discriminatorを受け入れることを示します（セクション4.4.2.2）。このオプションが正規セクションにない場合は、無視する必要があります。
+-------------/-+-------------/-+
| length \ | 0x0a \ |
+-------------/-+-------------/-+
This option can be used to add extra entropy or randomness to a certificate that doesn't have any other cryptographic pseudorandom members (such as a public key). This option is typically used so that endpoints using ephemeral Diffie-Hellman keying can have a unique certificate fingerprint.
このオプションを使用すると、他の暗号化疑似ランダムメンバー（公開キーなど）がない証明書に、エントロピーまたはランダム性を追加できます。このオプションは通常、一時的なDiffie-Hellmanキーを使用するエンドポイントが一意の証明書フィンガープリントを持つことができるように使用されます。
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | 0x0e \ | extra randomness |
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct extraRandomnessCertOptionValue_t
{
uint_t extraRandomness[remainder()];
} :remainder()*8;
This option specifies a Diffie-Hellman group ID that is supported for ephemeral keying. This option MUST be ignored if it is not in the canonical section. This option may occur more than once in the certificate; each instance indicates an additional group that is supported for key agreement.
このオプションは、一時キーイングでサポートされるDiffie-HellmanグループIDを指定します。このオプションが正規セクションにない場合は、無視する必要があります。このオプションは、証明書で複数回発生する場合があります。各インスタンスは、鍵合意でサポートされる追加のグループを示します。
+-------------/-+-------------/-+-------------/-+
| length \ | 0x15 \ | group ID \ |
+-------------/-+-------------/-+-------------/-+
struct ephemeralDHGroupCertOptionValue_t
{
vlu_t groupID :variable*8;
} :variable*8;
The presence of this option means that the certificate uses ephemeral Diffie-Hellman public keys only. The certificate MUST NOT contain a Static Diffie-Hellman public key (Section 4.3.3.5).
このオプションの存在は、証明書が一時的なDiffie-Hellman公開鍵のみを使用することを意味します。証明書には、静的Diffie-Hellman公開鍵が含まれていてはなりません（セクション4.3.3.5）。
This option specifies a Diffie-Hellman group ID and static public key in that group. This option MUST be ignored if it is not in the canonical section. This option MAY occur more than once in the certificate; however, this option SHOULD NOT occur more than once for each group ID. The behavior for specifying more than one public key per group ID is not defined.
このオプションは、Diffie-HellmanグループIDとそのグループの静的公開鍵を指定します。このオプションが正規セクションにない場合は、無視する必要があります。このオプションは、証明書で複数回発生する場合があります。ただし、このオプションは、グループIDごとに複数回使用してはなりません（SHOULD NOT）。グループIDごとに複数の公開鍵を指定する動作は定義されていません。
+-------------/-+-------------/-+-------------/-+
| length \ | 0x1d \ | group ID \ |
+-------------/-+-------------/-+-------------/-+
+------------------------------------------------------------------+
| Diffie-Hellman Public Key |
+------------------------------------------------------------------/
struct staticDHPublicKeyCertOptionValue_t
{
vlu_t groupID :variable*8;
uintn_t publicKey :remainder()*8; // network byte order
} :remainder()*8;
The presence of this option means that the certificate uses static Diffie-Hellman public keys only. The certificate MUST NOT contain any Supported Ephemeral Diffie-Hellman Group options (Section 4.3.3.4).
このオプションの存在は、証明書が静的Diffie-Hellman公開鍵のみを使用することを意味します。証明書には、サポートされているエフェメラルDiffie-Hellmanグループオプションを含めてはなりません（セクション4.3.3.4）。
This profile does not use a public key infrastructure, nor are there signing keys present in certificates. Therefore, any properly encoded certificate is considered authentic according to Section 3.2 of RFC 7016.
このプロファイルは公開鍵インフラストラクチャを使用せず、証明書に署名鍵も存在しません。したがって、適切にエンコードされた証明書は、RFC 7016のセクション3.2に従って、真正であると見なされます。
A certificate containing a static public key can only be used successfully for session communication if the holder of the certificate actually holds the private key associated with the public key. Authenticity of an identity and its peer ID (Section 4.3.2) having a certificate containing a static public key is implied by successful encrypted communication with the associated endpoint (Section 4.6).
静的公開鍵を含む証明書は、証明書の所有者が実際に公開鍵に関連付けられた秘密鍵を保持している場合にのみ、セッション通信に正常に使用できます。 IDとそのピアID（セクション4.3.2）の信頼性は、静的な公開鍵を含む証明書を持っていることは、関連するエンドポイント（セクション4.6）との暗号化された通信の成功によって暗示されます。
See Section 7 for further discussion of security issues related to identities.
IDに関連するセキュリティ問題の詳細については、セクション7を参照してください。
RTMFP Initiator Initial Keying and Responder Initial Keying messages have a field for the sender's digital signature of the keying parameters (Sections 2.3.7 and 2.3.8 of RFC 7016). In this profile, the signature field of those messages is encoded as a sequence of zero or more RTMFP Options.
RTMFP Initiator Initial KeyingおよびResponder Initial Keyingメッセージには、送信者のキーイングパラメータのデジタル署名のフィールドがあります（RFC 7016のセクション2.3.7および2.3.8）。このプロファイルでは、それらのメッセージの署名フィールドは、0個以上のRTMFPオプションのシーケンスとしてエンコードされます。
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
| L \ T \ V |...............| L \ T \ V |
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
^ ^
+------------- Zero or more Options ----------+
struct initialKeyingSignature_t
{
while(remainder() > 0)
option_t option :variable*8;
} :remainder()*8;
If a signer has no signature options to send, it MAY encode a signature as a UTF-8 capital "X" (hex 58) or as empty. A verifier MUST interpret a malformed signature field or a signature field consisting only of a UTF-8 capital "X" as though it was empty.
署名者に送信する署名オプションがない場合は、署名をUTF-8の大文字の「X」（16進数の58）または空としてエンコードしてもかまいません（MAY）。検証者は、不正な形式の署名フィールド、またはUTF-8の大文字の「X」のみで構成される署名フィールドを、空であるかのように解釈する必要があります。
If a verifier does not require a signature, it SHALL consider any signature field (including an empty or malformed one) to be valid. A verifier MAY require a signature comprising one or more non-empty options that are valid according to their respective types.
検証者が署名を必要としない場合、検証者は署名フィールド（空または不正な形式のフィールドを含む）が有効であると見なします。検証者は、それぞれのタイプに応じて有効な1つ以上の空でないオプションを含む署名を必要とする場合があります。
This profile does not use a public key infrastructure, nor are there signing keys present in certificates. Section 4.3.5.1.1 defines a simple ID/password credential system.
このプロファイルは公開鍵インフラストラクチャを使用せず、証明書に署名鍵も存在しません。セクション4.3.5.1.1は、単純なID /パスワード資格情報システムを定義しています。
This section lists options that can appear in an RTMFP Initial Keying signature field. The following option type code is defined:
このセクションでは、RTMFP Initial Keying署名フィールドに表示されるオプションを示します。次のオプションタイプコードが定義されています。
0x1d: Simple Password (Section 4.3.5.1.1)
0x1d：単純なパスワード（セクション4.3.5.1.1）
Future or derived profiles may define additional signature field options and semantics; therefore, a verifier SHOULD ignore option types that are not understood.
将来のプロファイルまたは派生プロファイルは、追加の署名フィールドオプションとセマンティクスを定義する場合があります。したがって、ベリファイアは、理解できないオプションタイプを無視する必要があります（SHOULD）。
This option encodes a password identifier (such as a user name, or an application-specific or implementation-specific selector) and an HMAC over the signed parameters using the identified password as the HMAC key. This option can occur more than once (for example, to allow interoperation between a current and a previous version of an implementation using implementation-specific passwords).
このオプションは、識別されたパスワードをHMACキーとして使用して、パスワード識別子（ユーザー名、アプリケーション固有または実装固有のセレクターなど）とHMACを署名済みパラメーターでエンコードします。このオプションは複数回発生する可能性があります（たとえば、実装固有のパスワードを使用して、実装の現在のバージョンと以前のバージョンの間の相互運用を可能にするため）。
To support the versioning use case, a verifier SHOULD ignore a Simple Password option encoding an unrecognized password identifier. A verifier SHOULD treat the entire signature as invalid if any Simple Password option encodes a recognized password identifier with an invalid password HMAC.
バージョン管理の使用例をサポートするために、検証者は、認識されないパスワード識別子をエンコードするシンプルパスワードオプションを無視する必要があります（SHOULD）。検証者は、Simple Passwordオプションが認識されたパスワード識別子を無効なパスワードHMACでエンコードする場合、署名全体を無効として扱う必要があります（SHOULD）。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-------------/-+-------------/-+
| length \ | 0x1d \ |
+-------------/-+-------------/-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| hmacSHA256 |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| passwordID |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct simplePasswordSignatureOptionValue_t
{
uint8_t hmacSHA256[32];
uint8_t passwordID[remainder()];
} :remainder()*8;
hmacSHA256: HMAC-SHA256(K, M), where K is the password associated with passwordID, and M is the signed parameters.
hmacSHA256：HMAC-SHA256（K、M）。ここで、KはpasswordIDに関連付けられたパスワード、Mは署名付きパラメーターです。
passwordID: The identifier (such as a user name) for the password used as the HMAC key.
passwordID：HMACキーとして使用されるパスワードの識別子（ユーザー名など）。
Glare occurs when two endpoints initiate a session each to the other concurrently.
グレアは、2つのエンドポイントが同時に相互にセッションを開始したときに発生します。
Compare the near end's certificate to the far end's with a binary lexicographic comparison, one byte at a time, up to the length of the shorter certificate. At the first corresponding byte from each certificate that is different, the certificate having the differing byte (treated as an unsigned 8-bit integer) with the lower value is ordered before the other certificate. If the certificates are not the same length and they are identical up to the length of the shorter certificate, then the shorter certificate is ordered before the longer.
近端の証明書と遠端の証明書を、短い方の証明書の長さまで、一度に1バイトずつ、バイナリの辞書編集比較で比較します。異なる各証明書の最初の対応するバイトでは、値が小さい（バイトが符号なし8ビット整数として扱われる）異なるバイトを持つ証明書が、他の証明書の前に並べられます。証明書が同じ長さではなく、短い証明書の長さまで同じである場合、短い証明書が長い証明書の前に注文されます。
The near end prevails as the Initiator in case of glare if its certificate is ordered before, or is identical to, the certificate of the far end. Otherwise, the near end's certificate is ordered after the far end's certificate, and the near end assumes the role of Responder.
グレアが発生した場合、その証明書が遠端の証明書より前に注文されているか、または同じである場合、近端がイニシエーターとして優先されます。それ以外の場合、近端の証明書は遠端の証明書の後に注文され、近端はレスポンダの役割を引き受けます。
A new incoming session overrides an existing session only if the certificate for the new session is identical to the certificate for the existing session.
新しい着信セッションが既存のセッションを上書きするのは、新しいセッションの証明書が既存のセッションの証明書と同一である場合のみです。
This section describes the Endpoint Discriminator (EPD) (Section 3.2 of RFC 7016) format and semantics for this Cryptography Profile, and the mapping to RTMFP's abstract certificate and identity selection semantics.
このセクションでは、この暗号化プロファイルのEndpoint Discriminator（EPD）（RFC 7016のセクション3.2）形式とセマンティクス、およびRTMFPの抽象証明書とID選択セマンティクスへのマッピングについて説明します。
An EPD in this profile is encoded as a sequence of zero or more RTMFP Options.
このプロファイルのEPDは、0個以上のRTMFPオプションのシーケンスとしてエンコードされます。
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
| L \ T \ V |...............| L \ T \ V |
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
^ ^
+------------- Zero or more Options ----------+
struct endpointDiscriminator_t
{
while(remainder() > 0)
option_t option :variable*8;
} :remainder()*8;
This section lists options that can appear in an EPD. The following option type codes are defined:
このセクションでは、EPDに表示されるオプションを示します。次のオプションタイプコードが定義されています。
0x00: Required Hostname (Section 4.4.2.1)
0x00：必要なホスト名（セクション4.4.2.1）
0x0a: Ancillary Data (Section 4.4.2.2)
0x0a：補助データ（セクション4.4.2.2）
0x0f: Fingerprint (Section 4.4.2.3)
0x0f：指紋（セクション4.4.2.3）
The use of these options for selecting certificates is described in Section 4.4.3.
証明書を選択するためのこれらのオプションの使用については、セクション4.4.3で説明します。
An implementation MUST ignore EPD option types that are not understood.
実装は、理解されていないEPDオプションタイプを無視する必要があります。
This option indicates the hostname to match against the certificate's Hostname option (Section 4.3.3.1).
このオプションは、証明書のホスト名オプション（セクション4.3.3.1）と照合するホスト名を示します。
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | 0x00 \ | hostname |
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct hostnameEPDOptionValue_t
{
uint8_t hostname[remainder()];
} :remainder()*8;
This option MUST NOT occur more than once in an EPD.
このオプションは、EPDで複数回使用してはなりません。
In this profile, this option indicates the server Uniform Resource Identifier (URI) [RFC3986] encoded in UTF-8 to which a client is connecting on this session, for example, "rtmfp://server.example.com/app/instance".
このプロファイルでは、このオプションは、クライアントがこのセッションで接続しているUTF-8でエンコードされたサーバーのUniform Resource Identifier（URI）[RFC3986]を示します。たとえば、「rtmfp：//server.example.com/app/instance 」
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | 0x0a \ | ancillary data |
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct ancillaryDataEPDOptionValue_t
{
uint8_t ancillaryData[remainder()];
} :remainder()*8;
This option MUST NOT occur more than once in an EPD.
このオプションは、EPDで複数回使用してはなりません。
This option indicates the 256-bit (32-byte) fingerprint (Section 4.3.2) of a certificate.
このオプションは、証明書の256ビット（32バイト）フィンガープリント（セクション4.3.2）を示します。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-------------/-+-------------/-+
| length \ | 0x0f \ |
+-------------/-+-------------/-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| fingerprint |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct fingerprintEPDOptionValue_t
{
uint8_t fingerprint[32];
} :256;
This option MUST NOT occur more than once in an EPD.
このオプションは、EPDで複数回使用してはなりません。
This section describes the REQUIRED method of determining whether an EPD selects a certificate.
このセクションでは、EPDが証明書を選択するかどうかを決定する必須の方法について説明します。
An EPD MUST contain at least one of Fingerprint, Required Hostname, or Ancillary Data options to select any certificate.
EPDには、任意の証明書を選択するために、指紋、必須のホスト名、または補助データのオプションの少なくとも1つを含める必要があります。
A Fingerprint EPD option selects or rejects a certificate no matter what other options are present.
指紋EPDオプションは、他にどのようなオプションが存在していても、証明書を選択または拒否します。
Without a Fingerprint option, a Required Hostname EPD option, if present, REQUIRES an identical Hostname option in the certificate.
指紋オプションがない場合、必須のホスト名EPDオプションが存在する場合、証明書に同じホスト名オプションが必要です。
Without a Fingerprint option, an Ancillary Data EPD option, if present, REQUIRES that the certificate has an Accepts Ancillary Data option.
指紋オプションがない場合、補助データEPDオプション（存在する場合）は、証明書に補助データを受け入れるオプションがあることを要求します。
if EPD contains a Fingerprint option: if certificate.fingerprint == option.fingerprint: certificate is selected. stop. else: certificate is not selected. stop. else: if EPD contains a Required Hostname option: if certificate contains a Hostname option: if certificate.hostname != option.hostname: certificate is not selected. stop. else: certificate is not selected. stop. if EPD contains an Ancillary Data option: if certificate doesn't have an Accepts Ancillary Data option: certificate is not selected. stop. else if EPD does not contain a Required Hostname option: certificate is not selected. stop. certificate is selected. stop.
EPDに指紋オプションが含まれている場合：certificate.fingerprint == option.fingerprintの場合：証明書が選択されています。やめる。 else：証明書は選択されていません。やめる。 else：EPDに必須のホスト名オプションが含まれている場合：証明書にホスト名オプションが含まれている場合：certificate.hostname！= option.hostnameの場合：証明書は選択されていません。やめる。 else：証明書は選択されていません。やめる。 EPDに補助データオプションが含まれている場合：証明書に補助データを受け入れるオプションがない場合：証明書は選択されていません。やめる。 EPDに必須のホスト名オプションが含まれていない場合：証明書は選択されません。やめる。証明書が選択されています。やめる。
Figure 1: Algorithm to Test Whether an EPD Selects a Certificate
図1：EPDが証明書を選択するかどうかをテストするアルゴリズム
In this profile, a Canonical Endpoint Discriminator (Section 3.2 of RFC 7016) contains only a Fingerprint option (Section 4.4.2.3) and no other options. The option length and type code MUST be encoded as 1-byte VLUs, even though VLU encoding allows those fields to be encoded in an arbitrary number of bytes. That is, the Canonical Endpoint Discriminator MUST be exactly 34 bytes long, with a length field of 0x21 encoded as one byte, a type code of 0x0f encoded as one byte, and 32 bytes of fingerprint.
このプロファイルでは、Canonical Endpoint Discriminator（RFC 7016のセクション3.2）には指紋オプション（セクション4.4.2.3）のみが含まれ、その他のオプションは含まれていません。オプションの長さとタイプコードは、1バイトのVLUとしてエンコードする必要があります。ただし、VLUエンコーディングでは、これらのフィールドを任意のバイト数でエンコードできます。つまり、Canonical Endpoint Discriminatorは正確に34バイト長でなければならず、長さフィールド0x21が1バイトとしてエンコードされ、タイプコード0x0fが1バイトとしてエンコードされ、32バイトのフィンガープリントが必要です。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x21 | 0x0f |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| fingerprint |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+ - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct canonicalEndpointDiscriminator_t
{
uint8_t length = 0x21;
uint8_t type = 0x0f;
uint8_t fingerprint[32];
} :272;
This section describes the format of the Session Key Initiator Component of the Initiator Initial Keying RTMFP chunk and the Session Key Responder Component of the Responder Initial Keying RTMFP chunk (Sections 2.3.7 and 2.3.8 of RFC 7016). The Initiator and Responder Session Keying Components have the same format.
このセクションでは、イニシエーター初期キーイングRTMFPチャンクのセッションキーイニシエーターコンポーネントと、レスポンダー初期キーイングRTMFPチャンクのセッションキーレスポンダーコンポーネント（RFC 7016のセクション2.3.7および2.3.8）の形式について説明します。イニシエーターとレスポンダーのセッションキーイングコンポーネントの形式は同じです。
A Session Keying Component in this profile is encoded as a sequence of zero or more RTMFP Options.
このプロファイルのセッションキーイングコンポーネントは、0個以上のRTMFPオプションのシーケンスとしてエンコードされます。
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
| L \ T \ V |...............| L \ T \ V |
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
^ ^
+------------- Zero or more Options ----------+
struct sessionKeyingComponent_t
{
while(remainder() > 0)
option_t option :variable*8;
} :remainder()*8;
This section lists options that can appear in a Session Keying Component. The following option type codes are defined:
このセクションでは、セッションキーイングコンポーネントに表示されるオプションを示します。次のオプションタイプコードが定義されています。
0x0d: Ephemeral Diffie-Hellman Public Key (Section 4.5.2.1)
0x0d：エフェメラルDiffie-Hellman公開鍵（セクション4.5.2.1）
0x0e: Extra Randomness (Section 4.5.2.2)
0x0e：追加のランダムネス（セクション4.5.2.2）
0x1d: Diffie-Hellman Group Select (Section 4.5.2.3)
0x1d：Diffie-Hellman Group Select（セクション4.5.2.3）
0x1a: HMAC Negotiation (Section 4.5.2.4)
0x1a：HMACネゴシエーション（セクション4.5.2.4）
0x1e: Session Sequence Number Negotiation (Section 4.5.2.5)
0x1e：セッションシーケンス番号ネゴシエーション（セクション4.5.2.5）
An implementation MUST ignore a session keying component option type that is not understood.
実装は、理解できないセッションキーイングコンポーネントオプションタイプを無視する必要があります。
This option specifies a Diffie-Hellman group ID and public key in that group. This option MUST NOT be sent if the sender's certificate has a static Diffie-Hellman public key. This option MUST be sent if the sender's certificate does not have a static Diffie-Hellman public key. This option MUST NOT be sent more than once.
このオプションは、Diffie-HellmanグループIDとそのグループの公開鍵を指定します。送信者の証明書に静的Diffie-Hellman公開鍵がある場合、このオプションを送信してはなりません（MUST NOT）。このオプションは、送信者の証明書に静的Diffie-Hellman公開鍵がない場合に送信する必要があります。このオプションを複数回送信してはなりません。
+-------------/-+-------------/-+-------------/-+
| length \ | 0x0d \ | group ID \ |
+-------------/-+-------------/-+-------------/-+
+------------------------------------------------------------------+
| Diffie-Hellman Public Key |
+------------------------------------------------------------------/
struct ephemeralDHPublicKeyKeyingOptionValue_t
{
vlu_t groupID :variable*8;
uintn_t publicKey :remainder()*8; // network byte order
} :remainder()*8;
This option can be used to add extra entropy or randomness to a keying component, particularly when the sender uses a static public key. When used for that purpose, the extra randomness SHOULD be cryptographically strong pseudorandom bytes not less than 16 bytes (for cryptographically significant entropy) and not more than 64 bytes (the length of a SHA-256 input block) in length. The extra randomness serves as a salt when computing the session keys (Section 4.6).
このオプションは、特に送信者が静的公開鍵を使用する場合に、キーイングコンポーネントに追加のエントロピーまたはランダム性を追加するために使用できます。その目的で使用する場合、追加のランダム性は、長さが16バイト（暗号的に重要なエントロピーの場合）以上64バイト（SHA-256入力ブロックの長さ）以下の強力な疑似ランダムバイトである必要があります（SHOULD）。余分なランダム性は、セッションキーを計算するときにソルトとして機能します（セクション4.6）。
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | 0x0e \ | extra randomness |
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct extraRandomnessKeyingOptionValue_t
{
uint_t extraRandomness[remainder()];
} :remainder()*8;
This option is sent by the Initiator to specify which Diffie-Hellman group to use for key agreement. The Initiator MUST send this option when it advertises a static Diffie-Hellman public key in its certificate and MUST NOT send this option if it sends an ephemeral Diffie-Hellman public key. This option MUST NOT be sent more than once.
このオプションは、キー合意に使用するDiffie-Hellmanグループを指定するためにイニシエーターによって送信されます。イニシエーターは、証明書で静的Diffie-Hellman公開キーをアドバタイズするときにこのオプションを送信する必要があり、一時的なDiffie-Hellman公開キーを送信する場合はこのオプションを送信してはなりません。このオプションを複数回送信してはなりません。
+-------------/-+-------------/-+-------------/-+
| length \ | 0x1d \ | group ID \ |
+-------------/-+-------------/-+-------------/-+
struct staticDHGroupSelectKeyingOptionValue_t
{
vlu_t groupID :variable*8;
} :variable*8;
This option is used to negotiate sending and receiving of an HMAC field for packet verification.
このオプションは、パケット検証のためにHMACフィールドの送受信をネゴシエートするために使用されます。
|0 1 2 3 4 5 6 7|
+-------------/-+-------------/-+-+-+-+-+-+-+-+-+-------------/-+
| \ | \ | |S|S|R| \ |
| length / | 0x1a / | rsv |N|O|E| hmacLength / |
| \ | \ | |D|R|Q| \ |
+-------------/-+-------------/-+-+-+-+-+-+-+-+-+-------------/-+
struct hmacNegotiationKeyingOptionValue_t
{
uintn_t reserved :5; // rsv
bool_t willSendAlways :1; // SND
bool_t willSendOnRequest :1; // SOR
bool_t request :1; // REQ
vlu_t hmacLength :variable*8;
} :variable*8;
willSendAlways: If set, the sender will send an HMAC on packets in this session.
willSendAlways：設定されている場合、送信者はこのセッションのパケットでHMACを送信します。
willSendOnRequest: If set, the sender will send an HMAC on packets in this session if the other end sets the request flag in its HMAC Negotiation.
willSendOnRequest：設定されている場合、相手側がHMACネゴシエーションで要求フラグを設定すると、送信者はこのセッションのパケットでHMACを送信します。
request: If set, the sender would very much like the receiver to send an HMAC on its packets. If the other end doesn't send an HMAC on its packets, the session can fail.
リクエスト：設定されている場合、送信者は受信者がパケットでHMACを送信することを非常に望んでいます。もう一方の端がパケットでHMACを送信しない場合、セッションは失敗する可能性があります。
hmacLength: If the sender negotiates to send an HMAC on its packets, the HMAC field will be this many bytes long. This value MUST be between 4 and 32 inclusive, or 0 if and only if willSendAlways and willSendOnRequest are clear.
hmacLength：送信者がパケットでHMACを送信するようにネゴシエートする場合、HMACフィールドはこれだけ多くのバイト長になります。この値は、4から32までの値でなければならず、willSendAlwaysとwillSendOnRequestが明確な場合に限り0でなければなりません。
The handshake operational semantics for this option are described in Section 4.6.4.
このオプションのハンドシェイク操作セマンティクスは、セクション4.6.4で説明されています。
This option is used to negotiate sending and receiving of the Session Sequence Number field for packet verification.
このオプションは、パケット検証のためにセッションシーケンス番号フィールドの送受信をネゴシエートするために使用されます。
|0 1 2 3 4 5 6 7|
+-------------/-+-------------/-+-+-+-+-+-+-+-+-+
| \ | \ | |S|S|R|
| length / | 0x1e / | rsv |N|O|E|
| \ | \ | |D|R|Q|
+-------------/-+-------------/-+-+-+-+-+-+-+-+-+
struct sseqNegotiationKeyingOptionValue_t
{
uintn_t reserved :5; // rsv
bool_t willSendAlways :1; // SND
bool_t willSendOnRequest :1; // SOR
bool_t request :1; // REQ
} :8;
willSendAlways: If set, the sender will send a session sequence number in packets in this session.
willSendAlways：設定されている場合、送信者はこのセッションのパケットにセッションシーケンス番号を送信します。
willSendOnRequest: If set, the sender will send a session sequence number in packets in this session if the other end sets the request flag in its Session Sequence Number Negotiation.
willSendOnRequest：設定されている場合、送信先は、セッションシーケンス番号ネゴシエーションで相手側が要求フラグを設定している場合、このセッションのパケットでセッションシーケンス番号を送信します。
request: If set, the sender would very much like the receiver to send a session sequence number in its packets. If the other end doesn't send a session sequence number in its packets, the session can fail.
要求：設定されている場合、送信者は受信者がパケットでセッションシーケンス番号を送信することを非常に望んでいます。相手側がパケットのセッションシーケンス番号を送信しない場合、セッションは失敗する可能性があります。
The handshake operational semantics for this option are described in Section 4.6.6.
このオプションのハンドシェイク操作セマンティクスは、セクション4.6.6で説明されています。
This section describes how to compute the cryptographic keys and other settings for packet encryption and verification.
このセクションでは、パケットの暗号化と検証のための暗号化キーとその他の設定を計算する方法について説明します。
The Session Key Near Component (SKNC) means the keying component sent by the near end of the session; that is, it is the Session Key Initiator Component at the Initiator and the Session Key Responder Component at the Responder.
セッションキーのニアコンポーネント（SKNC）は、セッションのニアエンドによって送信されたキーイングコンポーネントを意味します。つまり、イニシエーターのセッションキーイニシエーターコンポーネントと、レスポンダのセッションキーレスポンダーコンポーネントです。
The Session Key Far Component (SKFC) means the keying component sent by the far end of the session; that is, it is the Session Key Responder Component at the Initiator and the Session Key Initiator Component at the Responder.
Session Key Far Component（SKFC）は、セッションの遠端から送信されるキーイングコンポーネントを意味します。つまり、イニシエータのセッションキーレスポンダコンポーネントとレスポンダのセッションキーイニシエータコンポーネントです。
This section enumerates the public key selection methods for all possible combinations of static or ephemeral public key modes for each endpoint according to their certificate options (Section 4.3.3).
このセクションでは、証明書オプション（セクション4.3.3）に従って、各エンドポイントの静的または一時的な公開鍵モードの可能なすべての組み合わせに対する公開鍵の選択方法を列挙します。
The Initiator and Responder list one or more Supported Ephemeral Diffie-Hellman Group options (Section 4.3.3.4) in their certificates. The Initiator sends exactly one Ephemeral Diffie-Hellman Public Key option (Section 4.5.2.1) in its Session Key Initiator Component, which selects one group from among those supported by the Responder and Initiator. Responder sends exactly one Ephemeral Diffie-Hellman Public Key option in its Session Key Responder Component, in the same group as indicated by the Initiator.
イニシエーターとレスポンダーは、証明書に1つ以上のサポートされているエフェメラルDiffie-Hellmanグループオプション（セクション4.3.3.4）をリストします。イニシエーターは、セッションキーイニシエーターコンポーネントで1つのエフェメラルDiffie-Hellman公開キーオプション（セクション4.5.2.1）を送信します。これにより、レスポンダとイニシエーターがサポートするグループから1つのグループが選択されます。レスポンダは、セッションキーレスポンダコンポーネントで、イニシエータによって示されているのと同じグループ内の1つのエフェメラルDiffie-Hellman公開キーオプションを送信します。
The Responder lists one or more Static Diffie-Hellman Public Key options (Section 4.3.3.5) in its certificate. The Initiator lists one or more Supported Ephemeral Diffie-Hellman Group options in its certificate. The Initiator sends exactly one Ephemeral Diffie-Hellman Public Key option in its Session Key Initiator Component, which selects one group from among those supported by the Responder and Initiator and the corresponding public key for the Responder. Responder uses its public key from the indicated group, and sends only an Extra Randomness option (Section 4.5.2.2) in its Session Key Responder Component to salt the session keys.
レスポンダは、証明書に1つ以上の静的Diffie-Hellman公開鍵オプション（4.3.3.5項）をリストします。イニシエーターは、証明書に1つ以上のサポートされているエフェメラルDiffie-Hellmanグループオプションをリストします。イニシエーターは、セッションキーイニシエーターコンポーネントで1つのエフェメラルDiffie-Hellman公開キーオプションを正確に送信します。これにより、レスポンダーとイニシエーターがサポートするグループと、レスポンダーの対応する公開キーから1つのグループが選択されます。レスポンダは、指定されたグループの公開鍵を使用し、セッションキーレスポンダコンポーネントで追加のランダムオプション（4.5.2.2項）のみを送信して、セッションキーをソルトします。
The Responder lists one or more Supported Ephemeral Diffie-Hellman Group options in its certificate. The Initiator lists one or more Static Diffie-Hellman Public Key options in its certificate. The Initiator sends exactly one Diffie-Hellman Group Select option (Section 4.5.2.3) in its Session Key Initiator Component, which selects one group from among those supported by the Responder and Initiator and the corresponding public key for the Initiator, plus an Extra Randomness option to salt the session keys. The Responder sends an Ephemeral Diffie-Hellman Public Key option in its Session Key Responder Component in the same group as indicated by the Initiator.
レスポンダは、証明書に1つ以上のサポートされているエフェメラルDiffie-Hellmanグループオプションをリストします。イニシエーターは、証明書に1つ以上の静的Diffie-Hellman公開鍵オプションをリストします。イニシエーターは、セッションキーイニシエーターコンポーネントで1つのDiffie-Hellmanグループ選択オプション（セクション4.5.2.3）を送信します。これは、レスポンダーとイニシエーターによってサポートされるグループ、およびイニシエーターの対応する公開キー、および追加のランダム性から1つのグループを選択します。セッションキーをソルトするオプション。レスポンダは、イニシエータによって示されているのと同じグループのセッションキーレスポンダコンポーネントで、エフェメラルDiffie-Hellman公開キーオプションを送信します。
The Initiator and Responder each list one or more Static Diffie-Hellman Public Key options in their certificates. The Initiator sends exactly one Diffie-Hellman Group Select option in its Session Key Initiator Component, which selects one group and corresponding public keys from among those supported by the Responder and Initiator, and an Extra Randomness option to salt the session keys. The Responder sends an Extra Randomness option in its Session Key Responder Component to add its own salt to the session keys.
イニシエーターとレスポンダーはそれぞれ、証明書に1つ以上の静的Diffie-Hellman公開鍵オプションをリストします。イニシエーターは、セッションキーイニシエーターコンポーネントで1つのDiffie-Hellmanグループ選択オプションを1つ送信します。これは、レスポンダーとイニシエーターがサポートするものから1つのグループと対応する公開キーを選択し、追加のランダムオプションを使用してセッションキーをソルトします。レスポンダは、セッションキーレスポンダコンポーネントで追加のランダムオプションを送信して、独自のソルトをセッションキーに追加します。
To be acceptable, a Diffie-Hellman public key MUST have all of the following properties:
受け入れられるようにするには、Diffie-Hellman公開鍵に次のすべてのプロパティが必要です。
o Be at least 16777216 (2^24);
o 少なくとも16777216（2 ^ 24）であること。
o Be at most the group's prime modulus minus 16777216;
o せいぜいグループのプライムモジュラスから16777216を引いた値である。
o Have at least 16 "1" bits;
o 少なくとも16の「1」ビットが必要です。
o Have at least 16 "0" bits, not including leading zeros.
o 先行ゼロを含まない、少なくとも16個の「0」ビットを持っている。
An endpoint MUST NOT complete to an S_OPEN session with a far endpoint using a public key that is not acceptable according to these criteria.
エンドポイントは、これらの基準に従って受け入れられない公開鍵を使用するファーエンドポイントとのS_OPENセッションを完了してはなりません（MUST NOT）。
Once the group and corresponding public key of the far end is determined, the far end's public key and the near end's private key are combined according to Diffie-Hellman [DH] to compute the Diffie-Hellman Shared Secret, an integer.
遠端のグループと対応する公開鍵が決定したら、遠端の公開鍵と近端の秘密鍵をDiffie-Hellman [DH]に従って組み合わせて、整数であるDiffie-Hellman共有秘密を計算します。
In the following sections, DH_SECRET means the Diffie-Hellman Shared Secret encoded as a byte-aligned unsigned integer in network byte order with no leading zero bytes. For example, if the shared secret is 4886718345, DH_SECRET would be the five bytes:
以下のセクションでは、DH_SECRETは、先頭にゼロバイトがなく、ネットワークバイトオーダーでバイトアラインされた符号なし整数としてエンコードされたDiffie-Hellman共有秘密を意味します。たとえば、共有シークレットが4886718345の場合、DH_SECRETは5バイトになります。
Hex: 01 23 45 67 89
16進数：01 23 45 67 89
Packets are encrypted using a symmetric cipher, such as the Advanced Encryption Standard [AES]. Distinct keys are used for sending and receiving packets. Each end's sending (encrypt) key is the other end's receiving (decrypt) key.
パケットは、Advanced Encryption Standard [AES]などの対称暗号を使用して暗号化されます。個別のキーは、パケットの送受信に使用されます。両端の送信（暗号化）キーは、もう一方の端の受信（復号）キーです。
The raw keys computed in this section for encryption and decryption are transformed in a manner specific to the cipher with which they are to be used. In this profile, AES-128 is the only currently defined cipher. For this cipher, the first 128 bits (16 bytes) of the 256-bit output of the calculation are taken to be the AES-128 key.
このセクションで暗号化と復号化のために計算された未加工の鍵は、使用される暗号に固有の方法で変換されます。このプロファイルでは、AES-128が現在定義されている唯一の暗号です。この暗号では、計算の256ビット出力の最初の128ビット（16バイト）がAES-128キーと見なされます。
Set ENCRYPT_KEY = HMAC-SHA256(DH_SECRET, HMAC-SHA256(SKFC, SKNC));
Set DECRYPT_KEY = HMAC-SHA256(DH_SECRET, HMAC-SHA256(SKNC, SKFC));
The full 256 bits of ENCRYPT_KEY and DECRYPT_KEY are used in the computations in the following sections.
ENCRYPT_KEYおよびDECRYPT_KEYの完全な256ビットは、以下のセクションの計算で使用されます。
Packets can be verified that they were not corrupted or modified by appending an HMAC to the packet. Whether to use an HMAC or a simple checksum is determined during the initial keying phase using the HMAC Negotiation option (Section 4.5.2.4). Distinct HMAC keys are used for sending and receiving packets. Each end's sending key is the other end's receiving key, and vice versa.
パケットにHMACを追加することにより、パケットが破損または変更されていないことを確認できます。 HMACを使用するか、単純なチェックサムを使用するかは、HMACネゴシエーションオプション（セクション4.5.2.4）を使用して、最初のキーイング段階で決定されます。個別のHMACキーは、パケットの送受信に使用されます。両端の送信キーは、もう一方の端の受信キーであり、その逆も同様です。
Set HMAC_SEND_KEY = HMAC_SHA256(DH_SECRET, ENCRYPT_KEY);
Set HMAC_RECV_KEY = HMAC_SHA256(DH_SECRET, DECRYPT_KEY);
If an endpoint sets the willSendAlways flag in its HMAC Negotiation option, then it MUST send an HMAC on packets it sends with this session key.
エンドポイントがHMACネゴシエーションオプションでwillSendAlwaysフラグを設定する場合、エンドポイントはこのセッションキーで送信するパケットにHMACを送信する必要があります。
If an endpoint's willSendAlways flag is clear but its willSendOnRequest flag is set, then it MUST send an HMAC on packets it sends with this session key if and only if the other endpoint's request flag is set.
エンドポイントのwillSendAlwaysフラグがクリアされているが、willSendOnRequestフラグが設定されている場合、他のエンドポイントの要求フラグが設定されている場合にのみ、このセッションキーで送信するパケットにHMACを送信する必要があります。
If a sending endpoint's willSendAlways and willSendOnRequest flags are clear, then the receiving endpoint SHOULD reject that keying component if the receiving endpoint is configured to require the sending endpoint to send HMAC.
送信側エンドポイントのwillSendAlwaysおよびwillSendOnRequestフラグがクリアされている場合、受信側エンドポイントがHMACの送信を要求するように構成されている場合、受信側エンドポイントはそのキーイングコンポーネントを拒否する必要があります（SHOULD）。
If HMAC is negotiated to be used, the corresponding hmacLength MUST be between 4 and 32 inclusive.
HMACが使用されるようにネゴシエートされる場合、対応するhmacLengthは4から32の間でなければなりません（MUST）。
If HMAC is negotiated not to be used, a simple checksum is used for packet verification.
HMACが使用されないようにネゴシエートされた場合、パケット検証に単純なチェックサムが使用されます。
The Default Session Key uses the simple checksum and does not use HMAC.
デフォルトセッションキーは単純なチェックサムを使用し、HMACは使用しません。
Session nonces are per-session, cryptographically strong secret values known only to the two endpoints of the session. They can be used for application-layer cryptographic challenges (such as signing or password verification). These nonces are a convenience being pre-shared and pre-agreed-upon in a secure manner during the initial keying handshake.
セッションナンスは、セッションごとの暗号的に強力な秘密の値であり、セッションの2つのエンドポイントだけが認識します。アプリケーション層の暗号化の課題（署名やパスワードの検証など）に使用できます。これらのナンスは、最初のキーイングハンドシェイク中に安全に事前共有および事前合意されるため便利です。
Each end's near nonce is the other end's far nonce, and vice versa.
各端の近いnonceは、もう一方の端のfar nonceであり、その逆も同様です。
Set NEAR_NONCE = HMAC_SHA256(DH_SECRET, SKNC);
Set FAR_NONCE = HMAC_SHA256(DH_SECRET, SKFC);
Duplicate packets can be detected and rejected by using an optional session sequence number inside the encrypted packets. The session sequence number is a monotonically increasing unbounded integer and does not wrap. Session sequence numbers SHOULD start at zero and SHOULD increment by one for each packet sent using that session key. Implementations MUST handle session sequence numbers with no less than 64 bits of range.
重複するパケットは、暗号化されたパケット内のオプションのセッションシーケンス番号を使用して検出および拒否できます。セッションシーケンス番号は、単調に増加する無制限の整数であり、折り返されません。セッションシーケンス番号はゼロから始まり、そのセッションキーを使用して送信されるパケットごとに1ずつ増加する必要があります（SHOULD）。実装は、64ビット以上の範囲のセッションシーケンス番号を処理する必要があります。
If an endpoint's willSendAlways flag in its Session Sequence Number Negotiation option (Section 4.5.2.5) is set, then it MUST send a session sequence number in packets it sends with this session key.
エンドポイントのセッションシーケンス番号ネゴシエーションオプション（セクション4.5.2.5）でエンドポイントのwillSendAlwaysフラグが設定されている場合、エンドポイントはこのセッションキーで送信するパケットでセッションシーケンス番号を送信する必要があります。
If an endpoint's willSendAlways flag is clear but its willSendOnRequest flag is set, then it MUST send a session sequence number on packets it sends with this session key if and only if the other endpoint's request flag is set.
エンドポイントのwillSendAlwaysフラグがクリアされているが、そのwillSendOnRequestフラグが設定されている場合、他のエンドポイントのリクエストフラグが設定されている場合にのみ、このセッションキーで送信するパケットにセッションシーケンス番号を送信する必要があります。
If a sending endpoint's willSendAlways and willSendOnRequest flags are clear, then the receiving endpoint SHOULD reject that keying component if the receiving endpoint is configured to require the sending endpoint to send session sequence numbers.
送信エンドポイントのwillSendAlwaysとwillSendOnRequestフラグがクリアされている場合、受信エンドポイントがセッションシーケンス番号の送信を要求するように構成されている場合、受信エンドポイントはそのキーイングコンポーネントを拒否する必要があります（SHOULD）。
The Default Session Key does not use session sequence numbers.
デフォルトセッションキーは、セッションシーケンス番号を使用しません。
This section describes the concrete syntax and operational semantics of RTMFP packet encryption for this Cryptography Profile.
このセクションでは、この暗号化プロファイルのRTMFPパケット暗号化の具体的な構文と運用上のセマンティクスについて説明します。
This profile defines AES-128 [AES] in CBC [CBC] mode as the only cipher. Extensions to this profile can specify and negotiate additional ciphers and modes by defining certificate and keying component options and associated semantics.
このプロファイルは、CBC [CBC]モードのAES-128 [AES]を唯一の暗号として定義します。このプロファイルの拡張機能では、証明書とキーコンポーネントのオプションおよび関連するセマンティクスを定義することにより、追加の暗号とモードを指定してネゴシエートできます。
For AES-128-CBC, the initialization vector (IV) for each packet is 16 zero bytes. The IV is not included in the packet.
AES-128-CBCの場合、各パケットの初期化ベクトル（IV）は16個のゼロバイトです。 IVはパケットに含まれていません。
The Encrypted Packet is the encryptedPacket field of an RTMFP Multiplex packet (Section 2.2.2 of RFC 7016); that is, the portion of the Multiplex packet following the scrambled session ID. The Encrypted Packet has the following format:
暗号化されたパケットは、RTMFPマルチプレックスパケットの暗号化されたパケットフィールドです（RFC 7016のセクション2.2.2）。つまり、スクランブルされたセッションIDに続くマルチプレックスパケットの部分です。暗号化パケットの形式は次のとおりです。
+----------------+ +----------------+~~~~~~~~~~~~~~~~~~~~~~~+
| CBC Block 1 | ... | CBC Block N | truncatedHMAC |
+----------------+ +----------------+~~~~~~~~~~~~~~~~~~~~~~~+
^ ^ ^
| Zero or more AES-128 chained | hmacLength bytes long |
+-------- cipher blocks -----------+--- (may be zero) ---+
struct flashProfileEncryptedPacket_t
{
if(HMAC is being used)
hmacLength = negotiated length;
else
hmacLength = 0;
struct
{
iv[16 bytes] = { 0 };
blockCount = 0;
while((remainder() > hmacLength) && (remainder() >= 16))
{
uint8_t cbcBlock[16];
blockCount++;
}
} chainedCipherBlocks :variable*16*8;
if(HMAC is being used)
{
if(remainder() == hmacLength)
uint8_t truncatedHMAC[hmacLength];
else
packetVerificationFailed();
}
else if(remainder() > 0)
packetVerificationFailed();
} :encryptedPacket.length*8;
cbcBlock: The next AES-128-CBC block.
cbcBlock：次のAES-128-CBCブロック。
chainedCipherBlocks: The concatenation of every cipher block in the packet (over which the HMAC is computed).
chainedCipherBlocks：（HMACが計算される）パケット内のすべての暗号ブロックの連結。
truncatedHMAC: If HMAC was negotiated to be used (Section 4.5.2.4), this field is set to the first negotiated hmacLength bytes of the HMAC of the chainedCipherBlocks.
truncatedHMAC：HMACが使用されるようにネゴシエートされた場合（セクション4.5.2.4）、このフィールドはchainedCipherBlocksのHMACの最初のネゴシエートされたhmacLengthバイトに設定されます。
The plaintext data before encryption or after decryption has the following format:
暗号化前または復号化後のプレーンテキストデータの形式は次のとおりです。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+~~~~~~~~~~~~~/~+
| SSEQ (opt.) \ |
+~~~~~~~~~~~~~/~+
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
| Checksum (opt.) |
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Plain RTMFP Packet |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct flashProfilePlainPacket_t
{
if(session sequence numbers being used)
vlu_t sessionSequenceNumber :variable*8; // SSEQ
if(HMAC not being used)
uint16_t checksum;
packet_t plainRTMFPPacket :variable*8;
} :chainedCipherBlocks.blockCount*16*8;
sessionSequenceNumber: If session sequence numbers were negotiated to be used (Section 4.6.6), this field is present and is the VLU session sequence number of this packet.
sessionSequenceNumber：セッションシーケンス番号が使用されるようにネゴシエートされた場合（セクション4.6.6）、このフィールドが存在し、このパケットのVLUセッションシーケンス番号です。
checksum: If HMAC was not negotiated to be used, this field is present and is the simple checksum (Section 4.7.3.1) of the remaining bytes of this structure.
チェックサム：HMACが使用されるようにネゴシエートされなかった場合、このフィールドは存在し、この構造の残りのバイトの単純なチェックサム（セクション4.7.3.1）です。
plainRTMFPPacket: The (plain, unencrypted) RTMFP Packet (Section 2.2.4 of RFC 7016) plus any necessary padding.
plainRTMFPPacket：（プレーン、暗号化されていない）RTMFPパケット（RFC 7016のセクション2.2.4）と必要なパディング。
When assembling this structure and prior to calculating the checksum (if present), if the structure's total length is not an integer multiple of 16 bytes (the AES cipher block size), pad the end of plainRTMFPPacket with as many bytes having a value of 0xff as are needed to bring the structure's total length to an integer multiple of 16 bytes. The receiver's RTMFP Packet parser (Section 2.2.4 of RFC 7016) will consume this padding.
この構造をアセンブルするとき、チェックサム（存在する場合）を計算する前に、構造の全長が16バイトの整数倍（AES暗号ブロックサイズ）でない場合は、plainRTMFPPacketの終わりに0xffの値を持つバイトを埋め込みます構造体の全長を16バイトの整数倍にするために必要です。受信者のRTMFPパケットパーサー（RFC 7016のセクション2.2.4）がこのパディングを使用します。
In RTMFP, the Cryptography Profile is responsible for packet verification. In this profile, packets are verified with an HMAC or a simple checksum, depending on the configuration of the endpoints, and optionally verified against replay or duplication using session sequence numbers. The simple checksum is inside the encrypted packet, so it becomes essentially a 16-bit cryptographic checksum.
RTMFPでは、暗号化プロファイルがパケット検証を担当します。このプロファイルでは、エンドポイントの構成に応じて、パケットがHMACまたは単純なチェックサムで検証され、オプションで、セッションシーケンス番号を使用して再生または複製に対して検証されます。単純なチェックサムは暗号化されたパケット内にあるため、本質的に16ビットの暗号化チェックサムになります。
The simple checksum is the 16-bit ones' complement of the 16-bit ones' complement sum of all 16-bit (2 bytes in network byte order) words to be checked. If there are an odd number of bytes to be checked, then for purposes of this checksum, treat the last byte as the lower 8 bits of a 16-bit word whose upper 8 bits are 0. This is also known as the "Internet Checksum" [RFC1071].
単純なチェックサムは、チェックされるすべての16ビット（ネットワークバイトオーダーで2バイト）ワードの16ビットの1の補数の合計の16ビットの1の補数です。チェックするバイト数が奇数の場合、このチェックサムでは、最後のバイトを上位8ビットが0である16ビットワードの下位8ビットとして扱います。これは「インターネットチェックサム」とも呼ばれます。 「[RFC1071]。
When present, the checksum is calculated over all bytes of the plaintext packet starting after the checksum field through the end of the plain packet. It cannot be calculated until the plain packet is padded, if necessary, to bring its length to an integer multiple of 16 bytes (the AES cipher block size). The session sequence number field, if present, and the checksum field itself are not included in the checksum.
チェックサムが存在する場合、チェックサムは、チェックサムフィールドの後からプレーンパケットの終わりまで、プレーンテキストパケットのすべてのバイトに対して計算されます。必要に応じて、プレーンパケットがパディングされて長さが16バイトの整数倍（AES暗号ブロックサイズ）になるまで計算できません。セッションシーケンス番号フィールド（存在する場合）およびチェックサムフィールド自体は、チェックサムに含まれません。
On receiving a packet being verified with a checksum: calculate the checksum over all the bytes of the plaintext packet following the checksum field and compare the checksum to the value in the checksum field. If they match, the packet is verified; if they do not match, the packet is corrupt and MUST be discarded as though it was never received.
チェックサムで検証されるパケットを受信したら、チェックサムフィールドに続くプレーンテキストパケットのすべてのバイトでチェックサムを計算し、チェックサムをチェックサムフィールドの値と比較します。それらが一致する場合、パケットは検証されます。それらが一致しない場合、パケットは破損しているため、受信されなかったかのように破棄する必要があります。
When present, the HMAC field is the last hmacLength bytes of the packet and is calculated over all of the encrypted cipher blocks of the packet preceding the HMAC field. The value of the HMAC field is the first hmacLength bytes of the HMAC-SHA256 of the checked data, using the computed HMAC keys (Section 4.6.4) and negotiated hmacLength (Section 4.5.2.4). Note each endpoint independently specifies the length of the HMAC it will send via its hmacLength field.
存在する場合、HMACフィールドはパケットの最後のhmacLengthバイトであり、HMACフィールドに先行するパケットのすべての暗号化された暗号ブロックに対して計算されます。 HMACフィールドの値は、計算されたHMACキー（セクション4.6.4）とネゴシエートされたhmacLength（セクション4.5.2.4）を使用した、チェックされたデータのHMAC-SHA256の最初のhmacLengthバイトです。各エンドポイントは、hmacLengthフィールドを介して送信するHMACの長さを個別に指定することに注意してください。
When an endpoint has negotiated to send an HMAC, it encrypts the data blocks, computes the HMAC over the encrypted data blocks using its HMAC_SEND_KEY, and appends the first hmacLength bytes of that hash after the final encrypted data block.
エンドポイントがHMACを送信するようにネゴシエートすると、データブロックを暗号化し、HMAC_SEND_KEYを使用して暗号化されたデータブロックに対してHMACを計算し、最後の暗号化されたデータブロックの後にそのハッシュの最初のhmacLengthバイトを追加します。
When an endpoint has negotiated to receive an HMAC, the endpoint computes the HMAC over the encrypted data blocks using its HMAC_RECV_KEY and then compares the first receive hmacLength bytes of the computed HMAC to the HMAC field in the packet. If they are identical, the packet is verified; if they are not identical, the packet is corrupt and MUST be discarded as though it was never received.
エンドポイントがHMACを受信するようにネゴシエートすると、エンドポイントはHMAC_RECV_KEYを使用して暗号化されたデータブロックでHMACを計算し、計算されたHMACの最初の受信hmacLengthバイトをパケットのHMACフィールドと比較します。それらが同一である場合、パケットは検証されます。それらが同一でない場合、パケットは破損しているため、受信されなかったかのように廃棄する必要があります。
HMAC and simple checksum verification are mutually exclusive.
HMAC and simple checksum verification are mutually exclusive.
Session sequence numbers are used to detect and reject a packet that was duplicated in the network or replayed by an attacker and to ensure the first chained cipher block of every packet is unique, in lieu of a full-block initialization vector. Sequence numbers start at zero, increase by one for each packet sent in the session, do not wrap, and do not repeat.
セッションシーケンス番号は、ネットワークで複製されたパケットや攻撃者によって再生されたパケットを検出して拒否し、フルブロックの初期化ベクトルの代わりに、すべてのパケットの最初のチェーン暗号ブロックが一意であることを確認するために使用されます。シーケンス番号はゼロから始まり、セッションで送信されるパケットごとに1ずつ増加し、折り返さず、繰り返されません。
When session sequence numbers are negotiated to be used, the receiver MUST allow for packets to be reordered in the network by up to at least 32 sequence numbers; note, however, that reordering by more than three packets can trigger loss detection and retransmission by negative acknowledgement, just as with TCP, and is therefore not likely to occur in the real Internet.
セッションシーケンス番号が使用されるようにネゴシエートされる場合、受信者は、少なくとも32シーケンス番号までネットワーク内でパケットを並べ替えることを許可する必要があります。ただし、4つ以上のパケットによる並べ替えは、TCPと同様に、否定検出による損失検出と再送信をトリガーする可能性があるため、実際のインターネットでは発生しない可能性があることに注意してください。
[RFC4302], [RFC4303], and [RFC6479] describe Anti-Replay Window methods that can be employed to detect duplicate sequence numbers. Other methods are possible.
[RFC4302]、[RFC4303]、および[RFC6479]は、重複するシーケンス番号を検出するために使用できるアンチリプレイウィンドウメソッドについて説明しています。他の方法も可能です。
Any packet received having a session sequence number that was already seen in that session, either directly or by being less than the lowest sequence number in the Anti-Replay Window, is a duplicate and MUST be discarded as though never received.
直接またはアンチリプレイウィンドウの最小シーケンス番号よりも小さいことにより、そのセッションですでに見られたセッションシーケンス番号を持つ受信パケットは重複しており、決して受信されなかったかのように廃棄する必要があります。
The Flash platform uses RTMP [RTMP] messages for media streaming and communication. This section describes how to transport RTMP messages over RTMFP flows and additional messages and semantics unique to this transport.
Flashプラットフォームは、メディアのストリーミングと通信にRTMP [RTMP]メッセージを使用します。このセクションでは、RTMFPフローを介してRTMPメッセージを転送する方法と、この転送に固有の追加のメッセージとセマンティクスについて説明します。
An RTMP message comprises a virtual header and a payload. The virtual header comprises a Message Type, a Payload Length, a Timestamp, and a Stream ID. The format of the payload is dependent on the type of message.
RTMPメッセージは、仮想ヘッダーとペイロードで構成されます。仮想ヘッダーは、メッセージタイプ、ペイロード長、タイムスタンプ、およびストリームIDで構成されます。ペイロードの形式は、メッセージのタイプによって異なります。
An RTMP message is mapped onto a lower transport layer, such as RTMP Chunk Stream [RTMP] or RTMFP. RTMP messages were initially designed along with, and for transport on, RTMP Chunk Stream. This design constrains the possible values of RTMP message header fields. In particular:
RTMPメッセージは、RTMP Chunk Stream [RTMP]やRTMFPなどの下位トランスポート層にマッピングされます。 RTMPメッセージは、当初、RTMPチャンクストリームと一緒に、およびRTMPチャンクストリームでの転送用に設計されました。この設計は、RTMPメッセージヘッダーフィールドの可能な値を制限します。特に：
Message Type is 8 bits wide, and is therefore constrained to values from 0 to 255 inclusive;
メッセージタイプは8ビット幅であるため、0〜255の値に制限されます。
Payload Length is 24 bits wide, so messages can be at most 16777215 bytes long;
ペイロードの長さは24ビット幅であるため、メッセージの長さは最大で16777215バイトです。
Timestamp is 32 bits wide, so timestamps range from 0 to 4294967295 and wrap around;
タイムスタンプは32ビット幅であるため、タイムスタンプの範囲は0〜4294967295であり、ラップアラウンドします。
Stream ID is 24 bits wide, and is therefore constrained to values from 0 to 16777215 inclusive.
ストリームIDは24ビット幅であるため、0から16777215までの値に制限されます。
RTMP Chunk Stream Protocol Control messages (message types 1, 2, 3, 5, and 6) are not used when transporting RTMP messages in RTMFP flows. Messages of those types SHOULD NOT be sent and MUST be ignored.
RTMFPフローでRTMPメッセージを転送する場合、RTMPチャンクストリームプロトコル制御メッセージ（メッセージタイプ1、2、3、5、および6）は使用されません。これらのタイプのメッセージは送信してはならず（SHOULD NOT）、無視する必要があります（MUST）。
All messages in RTMFP are transported in flows. In this profile, an RTMFP flow for RTMP messages carries the messages for exactly one RTMP Stream ID. Multiple flows can carry messages for the same Stream ID; for example, the video and audio messages of a stream could be sent on separate flows, allowing the audio to be given higher transmission priority.
RTMFPのすべてのメッセージはフローで転送されます。このプロファイルでは、RTMPメッセージのRTMFPフローは、1つのRTMPストリームIDのメッセージを伝送します。複数のフローが同じストリームIDのメッセージを運ぶことができます。たとえば、ストリームのビデオメッセージとオーディオメッセージを別々のフローで送信して、オーディオの送信優先度を高くすることができます。
The User Metadata for flows in this profile begins with a distinct signature to distinguish among different kinds of flows. The User Metadata for a flow used for RTMP messages begins with the two-character signature "TC".
このプロファイルのフローのユーザーメタデータは、異なる種類のフローを区別するための個別のシグネチャで始まります。 RTMPメッセージに使用されるフローのユーザーメタデータは、2文字の署名「TC」で始まります。
The Stream ID is encoded in the flow's User Metadata so that it doesn't need to be sent with each message.
ストリームIDはフローのユーザーメタデータにエンコードされるため、メッセージごとに送信する必要はありません。
The sender can have a priori knowledge about the kind of media it intends to send on a flow and its intended use and can give the receiver a hint as to whether messages should be delivered as soon as possible or in their original queuing order. For example, the sender might be sending real-time, delay-sensitive audio messages on a flow, and hint that the receiver should take delivery of the messages on that flow as soon as they arrive in the network, to reduce the end-to-end latency of the audio.
送信者は、フローで送信する予定のメディアの種類とその使用目的について事前に知ることができ、メッセージをできるだけ早く配信するか、元のキューイング順序で配信するかについて受信者にヒントを与えることができます。たとえば、送信者はリアルタイムで遅延の影響を受けやすいオーディオメッセージをフローで送信していて、受信者がネットワークに到着したらすぐにそのフローでメッセージを配信して、エンドツーオーディオの終了遅延。
The receiver can choose to take delivery of messages on flows as soon as they arrive in the network or in the messages' original queuing order. A receiver that chooses to take delivery of messages as soon as they arrive in the network MUST be prepared for the messages to arrive out-of-order. For example, a receiver may choose not to render a newly received audio message having a timestamp earlier than the most recently rendered audio timestamp.
The receiver can choose to take delivery of messages on flows as soon as they arrive in the network or in the messages' original queuing order. A receiver that chooses to take delivery of messages as soon as they arrive in the network MUST be prepared for the messages to arrive out-of-order. For example, a receiver may choose not to render a newly received audio message having a timestamp earlier than the most recently rendered audio timestamp.
The sender can choose to abandon a message that it has queued in a flow before the message has been delivered to the receiver. For example, the sender may abandon a real-time, delay-sensitive audio message that has not been delivered within one second, to avoid spending transmission resources on stale media that is no longer relevant.
送信者は、メッセージが受信者に配信される前にフローでキューに入れられたメッセージを放棄することを選択できます。たとえば、送信者は、1秒以内に配信されなかったリアルタイムの遅延の影響を受けやすいオーディオメッセージを放棄して、関係のなくなった古いメディアに送信リソースを費やすことを回避できます。
Note: A gap will cause a delay at the receiver of at least one round-trip time if the receiver is taking delivery of messages in original queuing order.
注：受信側が元のキューイング順序でメッセージの配信を行っている場合、ギャップにより、受信側で少なくとも1往復の遅延が発生します。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+
| | | |S|r|R| \ |
| 0x54 'T' | 0x43 'C' | rsv |I|s|X| streamID / |
| | | |D|v|I| \ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+
struct RTMPMetadata_t
{
uint8_t signature[2] == { 'T', 'C' };
uintn_t reserved1 :5; // rsv
bool_t streamIDPresent :1; // SID
uintn_t reserved2 :1; // rsv
uintn_t receiveIntent :1; // RXI
// 0: original queuing order, 1: network arrival order
if(streamIDPresent)
vlu_t streamID :variable*8;
} :variable*8;
signature: Metadata signature for RTMP message flows, being the two UTF-8 coded characters "TC".
署名：RTMPメッセージフローのメタデータ署名。2つのUTF-8コード化文字「TC」です。
streamIDPresent: A boolean flag indicating whether the streamID field is present. In this profile, this flag MUST be set.
streamIDPresent：streamIDフィールドが存在するかどうかを示すブールフラグ。このプロファイルでは、このフラグを設定する必要があります。
receiveIntent: A hint by the sender as to the best order in which to take delivery of messages from the flow. A value of zero indicates a hint that the flow's messages should be received in the order they were originally queued by the sender (that is, in ascending sequence number order); a value of one indicates a hint that the flow's messages should be received in the order they arrive in the network, even if there are sequence number gaps or reordering. Network arrival order is typically hinted for live, delay-sensitive flows, such as for audio media. To take delivery of a message as soon as it arrives in the network: receive it from the receiving flow's RECV_BUFFER as soon as it becomes complete (Section 3.6.3.3 of RFC 7016), and remove it from the RECV_BUFFER. Section 3.6.3.3 of RFC 7016 describes how to take delivery of messages in original queuing order.
receiveIntent：フローからメッセージの配信を取得するための最適な順序に関する送信者によるヒント。ゼロの値は、フローのメッセージが送信者によって最初にキューに入れられた順序で（つまり、昇順のシーケンス番号で）受信される必要があるというヒントを示します。値1は、フローのメッセージがシーケンス番号のギャップや並べ替えがある場合でも、ネットワークに到着した順序で受信される必要があるというヒントを示します。ネットワークの到着順序は、通常、オーディオメディアなど、遅延の影響を受けやすいライブフローの場合に示唆されます。メッセージがネットワークに到着したらすぐに配信するには、メッセージが完了するとすぐに受信フローのRECV_BUFFERから受信し（RFC 7016のセクション3.6.3.3）、RECV_BUFFERから削除します。 RFC 7016のセクション3.6.3.3は、元のキュー順でメッセージを配信する方法を説明しています。
streamID: If the streamIDPresent flag is set, this field is present and is the RTMP stream ID to which the messages in this flow belong. In this profile, this field MUST be present.
streamID：streamIDPresentフラグが設定されている場合、このフィールドは存在し、このフローのメッセージが属するRTMPストリームIDです。このプロファイルでは、このフィールドが存在する必要があります。
A receiver SHOULD reject an RTMP message flow if its streamIDPresent flag is clear. This profile doesn't define a stream mapping for this case.
streamIDPresentフラグがクリアされている場合、受信者はRTMPメッセージフローを拒否する必要があります（SHOULD）。このプロファイルは、このケースのストリームマッピングを定義していません。
Derived or composed profiles can define additional flow types and corresponding metadata signatures. A receiver SHOULD reject a flow having an unrecognized metadata signature.
派生または構成されたプロファイルは、追加のフロータイプと対応するメタデータシグネチャを定義できます。受信者は、認識できないメタデータ署名を持つフローを拒否する必要があります（SHOULD）。
This section describes the format of an RTMP message (Section 5.1) in an RTMFP flow.
このセクションでは、RTMFPフローのRTMPメッセージ（セクション5.1）のフォーマットについて説明します。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| messageType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| messagePayload |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct RTMPMessage_t
{
uint8_t messageType;
uint32_t timestamp;
uint8_t messagePayload[remainder()];
} :flowMessageLength*8;
messageType: The RTMP Message Type;
messageType：RTMPメッセージタイプ。
timestamp: The RTMP Timestamp, in network byte order;
timestamp：ネットワークバイトオーダーのRTMPタイムスタンプ。
messagePayload: The payload of the RTMP message;
messagePayload：RTMPメッセージのペイロード。
payload length: The RTMP message payload length is inferred from the length of the RTMFP message;
ペイロード長：RTMPメッセージのペイロード長は、RTMFPメッセージの長さから推測されます。
Stream ID: The Stream ID for this message is taken from the metadata of the flow on which this message was received.
ストリームID：このメッセージのストリームIDは、このメッセージが受信されたフローのメタデータから取得されます。
RTMFP flows are independent and have no inter-flow ordering guarantee. RTMP was designed for transport over a single, reliable, strictly ordered byte stream. Some RTMP message semantics take advantage of this ordering; for example, a Stream EOF User Control event must not be processed until after all media messages for the corresponding stream have been received. Flow Synchronization messages provide a barrier to align message delivery across flows when required by RTMP semantics.
RTMFPフローは独立しており、フロー間の順序付けは保証されません。 RTMPは、単一の信頼性の高い厳密に順序付けられたバイトストリームで転送するように設計されています。一部のRTMPメッセージセマンティクスでは、この順序を利用しています。たとえば、対応するストリームのすべてのメディアメッセージが受信されるまで、ストリームEOFユーザーコントロールイベントを処理しないでください。フロー同期メッセージは、RTMPセマンティクスで必要な場合に、フロー全体でメッセージ配信を調整するためのバリアを提供します。
A Flow Synchronization message is coded as a User Control event message (Type 4) having Event Type 34. Message timestamps are ignored and MAY be set to 0.
フロー同期メッセージは、イベントタイプ34のユーザーコントロールイベントメッセージ（タイプ4）としてコード化されます。メッセージのタイムスタンプは無視され、0に設定される場合があります。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| eventType = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| syncID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct flowSyncUserControlMessagePayload_t
{
uint16_t eventType = 34;
uint32_t syncID;
uint32_t count;
} :10*8;
eventType: The RTMP User Control Message Event Type. Flow Synchronization messages have type 34 (0x22);
eventType：RTMPユーザーコントロールメッセージのイベントタイプ。フロー同期メッセージのタイプは34（0x22）です。
syncID: The identifier for this barrier;
syncID：このバリアの識別子。
count: The number of flows being synchronized by syncID. This field MUST be at least 1 and SHOULD be at least 2.
count：syncIDによって同期されているフローの数。このフィールドは少なくとも1でなければならず、少なくとも2である必要があります。
On receipt of a Flow Synchronization message, a receiver SHOULD suspend receipt of further messages on that flow until count Flow Synchronization messages (including this one) with the same syncID have been received on flows in the same flow association tree.
フロー同期メッセージを受信すると、受信者は、同じフローIDを持つフロー同期メッセージ（このメッセージを含む）が同じフローアソシエーションツリーのフローで受信されるまで、そのフローでの以降のメッセージの受信を中断する必要があります（SHOULD）。
Example: Consider flows F1 and F2 in the same NetConnection carrying messages M, and let Sync(syncID,count) denote a Flow Synchronization message.
例：メッセージMを運ぶ同じNetConnection内のフローF1とF2を検討し、Sync（syncID、count）にフロー同期メッセージを示します。
| |
F1: M1 M2 M4 Sync(8,2) | Sync(13,2).....| M7
| |
F2: M3 Sync(8,2).......| M5 Sync(13,2) | M6
| |
Barrier 8 Barrier 13
Figure 2: Example Flow Synchronization Barriers
図2：フロー同期バリアの例
Flow Synchronization messages form a delivery barrier to impart at least a partial message ordering across flows. In this example, message M5 comes after M1..4 and before M6..7; however, M3 could be delivered before or after any of M1, M2, or M4, and M6 could come before or after M7.
フロー同期メッセージは、フロー全体に少なくとも部分的なメッセージの順序付けを与えるための配信バリアを形成します。この例では、メッセージM5はM1..4の後、M6..7の前に来ます。ただし、M3はM1、M2、またはM4の前または後に配信でき、M6はM7の前または後に配信できます。
Flow Synchronization can cause a priority inversion; therefore, it SHOULD NOT be used except when necessary to preserve RTMP ordering semantics.
フローの同期により、優先順位が逆転する可能性があります。したがって、RTMPの順序付けの意味を保持する必要がある場合を除いて、使用しないでください。
The client connects to a server. The connection comprises one main control flow in each direction from client to server and from server to client for NetConnection messages, and zero or more flows in each direction for NetStream media messages. NetStream flows may come and go naturally over time according to media transport needs. An exception on a NetConnection control sending flow indicates the closure by the other end of the NetConnection and all associated NetStreams.
クライアントはサーバーに接続します。接続は、NetConnectionメッセージの場合、クライアントからサーバーへ、サーバーからクライアントへの各方向の1つのメイン制御フローと、NetStreamメディアメッセージの各方向のゼロ以上のフローで構成されます。 NetStreamフローは、メディアトランスポートのニーズに応じて、時間の経過とともに自然に行き来します。 NetConnectionコントロールの送信フローの例外は、NetConnectionのもう一方の端と関連するすべてのNetStreamによるクローズを示します。
The client MUST NOT use the same client certificate for more than one server connection; that is, a client's peer ID MUST NOT be reused.
クライアントは、複数のサーバー接続に同じクライアント証明書を使用してはなりません（MUST NOT）。つまり、クライアントのピアIDを再利用してはいけません。
The client desires a connection to a server having an RTMFP URI, for example, "rtmfp://server.example.com/app/instance". The client gathers one or more initial candidate addresses for the server named in the URI (for example, by using the Domain Name System (DNS)
クライアントは、RTMFP URI（たとえば、「rtmfp：//server.example.com/app/instance」）を持つサーバーへの接続を望んでいます。クライアントは、URIで指定されたサーバーの1つ以上の初期候補アドレスを収集します（たとえば、ドメインネームシステム（DNS）を使用して）
[RFC1035]). The client creates an EPD having an Ancillary Data option (Section 4.4.2.2) encoding the URI. The client initiates an RTMFP session to the one or more candidate addresses using the EPD.
[RFC1035]）。クライアントは、URIをエンコードする補助データオプション（4.4.2.2項）を持つEPDを作成します。クライアントは、EPDを使用して1つ以上の候補アドレスへのRTMFPセッションを開始します。
When the session transitions to the S_OPEN state, the client opens a new flow in that session for Stream ID 0 and Receive Intent 0 "original queuing order". This is the client's NetConnection main control flow. The client sends an RTMP "connect" command on the flow and waits for a response or exception.
セッションがS_OPEN状態に遷移すると、クライアントは、そのセッションでストリームID 0および受信インテント0「元のキューイング順序」の新しいフローを開きます。これは、クライアントのNetConnectionメイン制御フローです。クライアントはフローでRTMP "connect"コマンドを送信し、応答または例外を待ちます。
The server, on accepting the client's NetConnection control flow, and receiving and accepting the "connect" command, opens one or more return flows to the client having Stream ID 0 and associated to the control flow from the client. Flows for Stream ID 0 are the server's NetConnection control flows. The server sends a "_result" or "_error" transaction response for the client's connect command.
サーバーは、クライアントのNetConnection制御フローを受け入れ、「connect」コマンドを受信して受け入れると、ストリームID 0を持ち、クライアントからの制御フローに関連付けられたクライアントへの1つ以上のリターンフローを開きます。ストリームID 0のフローは、サーバーのNetConnection制御フローです。サーバーは、クライアントの接続コマンドに対して「_result」または「_error」トランザクション応答を送信します。
When the client receives the first return flow from the server for Stream ID 0 and associated to the client's NetConnection control flow, the client assumes that flow is the canonical return NetConnection control flow from the server, to which all new client-to-server flows should be associated.
クライアントがサーバーからストリームID 0の最初のリターンフローを受信し、クライアントのNetConnection制御フローに関連付けられている場合、クライアントは、フローがサーバーからの正規のリターンNetConnection制御フローであると想定します。関連付ける必要があります。
On receipt of a "_result" transaction response on Stream ID 0 for the client's connect command, the connection is up.
クライアントの接続コマンドのストリームID 0で「_result」トランザクション応答を受信すると、接続が確立されます。
The client MAY open additional return control flows to the server on Stream ID 0, associated to the server's canonical NetConnection control flow.
クライアントは、サーバーの正規のNetConnection制御フローに関連付けられた、ストリームID 0でサーバーへの追加の戻り制御フローを開くことができます（MAY）。
The "setPeerInfo" command is sent by the client to the server over the NetConnection control flow to inform the server of candidate socket addresses through which the client might be reachable. This list SHOULD include all directly connected interface addresses and proxy addresses except as provided below. The list MAY be empty. The list need not include the address of the server, even if the server is to act as an introducer for the client. The list SHOULD NOT include link-local or loopback addresses.
「setPeerInfo」コマンドは、NetConnection制御フローを介してクライアントからサーバーに送信され、クライアントが到達可能なソケットアドレス候補をサーバーに通知します。このリストには、以下に記載されている場合を除き、直接接続されているすべてのインターフェースアドレスとプロキシアドレスを含める必要があります（SHOULD）。リストは空でもかまいません。サーバーがクライアントの紹介者として機能する場合でも、リストにサーバーのアドレスを含める必要はありません。リストには、リンクローカルアドレスまたはループバックアドレスを含めないでください。
This command is sent as a regular RTMP NetConnection command; that is, as an RTMP Type 20 Command Message or an RTMP Type 17 Command Extended Message on Stream ID 0. A Type 20 Command Message SHOULD be used if the object encoding negotiated during the "connect" and
このコマンドは、通常のRTMP NetConnectionコマンドとして送信されます。つまり、ストリームID 0のRTMPタイプ20コマンドメッセージまたはRTMPタイプ17コマンド拡張メッセージとして。タイプ20コマンドメッセージは、オブジェクトのエンコーディングが「接続」中にネゴシエートされた場合に使用する必要があります。
"_result" handshake is AMF0 [AMF0], and a Type 17 Command Extended Message SHOULD be used if the negotiated object encoding is AMF3 [AMF3].
「_result」ハンドシェイクはAMF0 [AMF0]であり、ネゴシエートされたオブジェクトエンコーディングがAMF3 [AMF3]の場合は、タイプ17コマンド拡張メッセージを使用する必要があります。
Note: A Type 20 Command Message payload is a sequence of AMF objects encoded in AMF0.
注：タイプ20コマンドメッセージのペイロードは、AMF0でエンコードされたAMFオブジェクトのシーケンスです。
Note: A Type 17 Command Extended Message payload begins with a format selector byte, followed by a sequence of objects in a format-specific encoding. At the time of writing, only format 0 is defined; therefore, the format selector byte MUST be 0. Format 0 is a sequence of AMF objects, each encoded in AMF0 by default; AMF3 encoding for an object can be selected by prefixing it with an "avmplus-object-marker" (0x11) as defined in [AMF0].
注：タイプ17コマンド拡張メッセージのペイロードは、フォーマットセレクターバイトで始まり、その後に、フォーマット固有のエンコーディングのオブジェクトのシーケンスが続きます。執筆時点では、フォーマット0のみが定義されています。したがって、フォーマットセレクターバイトは0である必要があります。フォーマット0はAMFオブジェクトのシーケンスであり、それぞれデフォルトでAMF0にエンコードされます。オブジェクトのAMF3エンコーディングは、[AMF0]で定義されている「avmplus-object-marker」（0x11）を前に付けることで選択できます。
To complete the RTMFP NetConnection handshake, an RTMFP client MUST send a setPeerInfo command to the server after receiving a successful response to the "connect" command.
RTMFP NetConnectionハンドシェイクを完了するには、RTMFPクライアントが「connect」コマンドへの正常な応答を受信した後、サーバーにsetPeerInfoコマンドを送信する必要があります。
(
"setPeerInfo", // AMF String, command name
0.0, // AMF Number, transaction ID
NULL, // AMF Null, no command object
... // zero or more AMF Strings, each an address
)
Each listed socket address includes an IPv4 or IPv6 address in presentation format and a UDP port number in decimal, separated by a colon. Since the IPv6 address presentation format uses colons, IPv6 addresses are enclosed in square brackets [RFC3986].
リストされた各ソケットアドレスには、コロンで区切られた、プレゼンテーション形式のIPv4またはIPv6アドレスと10進数のUDPポート番号が含まれます。 IPv6アドレス表示形式はコロンを使用するため、IPv6アドレスは角括弧[RFC3986]で囲まれています。
( "setPeerInfo", 0.0, NULL, "192.0.2.129:50001", "[2001:db8:1::2]:50002" )
（ "setPeerInfo"、0.0、NULL、 "192.0.2.129:50001"、 "[2001：db8：1 :: 2]：50002"）
Figure 3: Example setPeerInfo Command
図3：setPeerInfoコマンドの例
A server SHOULD assume that the client is behind a Network Address Translator (NAT) if and only if the observed far endpoint address of the session for the flow on which this command was received does not appear in the setPeerInfo address list.
サーバーは、このコマンドが受信されたフローのセッションの観測された遠端のアドレスがsetPeerInfoアドレスリストに表示されない場合に限り、クライアントがネットワークアドレス変換（NAT）の背後にあると想定する必要があります。
The server can advise the client to set or change the client's session keepalive timer periods for its connection to the server and for its P2P connections. The server MAY choose keepalive periods based on static configuration, application- or deployment-specific circumstances, whether the client appears to be behind a NAT, or for any other reason.
サーバーは、サーバーへの接続とP2P接続のクライアントのセッションキープアライブタイマー期間を設定または変更するようにクライアントにアドバイスできます。サーバーは、クライアントがNATの背後にあるように見えるかどうか、またはその他の理由のために、静的構成、アプリケーションまたはデプロイメント固有の状況に基づいてキープアライブ期間を選択できます（MAY）。
The Set Keepalive Timers command is sent by the server to the client on Stream ID 0 as a User Control event message (Type 4) having Event Type 41. Message timestamps are ignored and MAY be set to 0.
Set Keepalive Timersコマンドは、サーバーからストリームID 0のクライアントに、イベントタイプ41のユーザーコントロールイベントメッセージ（タイプ4）として送信されます。メッセージのタイムスタンプは無視され、0に設定される場合があります。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| eventType = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| serverKeepalivePeriodMsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peerKeepalivePeriodMsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct setKeepaliveUserControlMessagePayload_t
{
uint16_t eventType = 41;
uint32_t serverKeepalivePeriodMsec;
uint32_t peerKeepalivePeriodMsec;
} :10*8;
eventType: The RTMP User Control Message Event Type. Set Keepalive Timers messages have type 41 (0x29);
eventType：RTMPユーザーコントロールメッセージのイベントタイプ。キープアライブタイマーの設定メッセージのタイプは41（0x29）です。
serverKeepalivePeriodMsec: The keepalive period, in milliseconds, that the client is advised to set on its RTMFP session with the server;
serverKeepalivePeriodMsec：キープアライブ期間（ミリ秒単位）。サーバーとのRTMFPセッションでクライアントに設定するようにアドバイスされます。
peerKeepalivePeriodMsec: The keepalive period, in milliseconds, that the client is advised to use on its RTMFP sessions with any peer that is not the server.
peerKeepalivePeriodMsec：サーバーではないピアとのRTMFPセッションでクライアントに使用するようにアドバイスされているキープアライブ期間（ミリ秒単位）。
The client MUST define minimum values for these keepalive periods, below which it will not set them, regardless of the values in this message. The minimum keepalive timer periods SHOULD be at least five seconds. The client MAY define maximum values for these keepalive periods, above which it will not set them.
クライアントは、これらのキープアライブ期間の最小値を定義する必要があります。この値を下回ると、このメッセージの値に関係なく、キープアライブは設定されません。キープアライブタイマーの最小期間は5秒以上にする必要があります。クライアントはこれらのキープアライブ期間の最大値を定義できますが、それを超えると設定されません。
On receipt of this message from the server, a client SHOULD set its RTMFP server and peer keepalive timer periods to the indicated values subject to the client's minimum and maximum values. The server MAY send this message more than once, particularly if conditions that it uses to determine the timer periods change.
サーバーからこのメッセージを受信すると、クライアントは、RTMFPサーバーとピアキープアライブタイマーの期間を、クライアントの最小値と最大値に従って、示された値に設定する必要があります（SHOULD）。サーバーはこのメッセージを複数回送信する場合があります（特に、タイマーの期間を決定するために使用する条件が変更された場合）。
The client or server opens additional flows to the other side to carry messages for any stream. Additional flows are associated to the canonical NetConnection control flow from the other side.
クライアントまたはサーバーは、反対側への追加のフローを開いて、任意のストリームのメッセージを伝送します。追加のフローは、反対側からの正規のNetConnection制御フローに関連付けられています。
Client Server
------>--C2S-Control-Flow------------------------->--+
|
+--<------------------------S2C-Control-Flow---<--+
| |
| <------------------------S2C-Stream-Flow-1--<--+
| : |
| <------------------------S2C-Stream-Flow-M--<--+
|
+-->--C2S-Stream-Flow-1------------------------>
| :
+-->--C2S-Stream-Flow-N------------------------>
Figure 4: Schematic Flow Association Tree for a NetConnection
図4：NetConnectionの回路図フローアソシエーションツリー
Additional flows from the client to the server for stream messages are opened with the Stream ID for that stream and associated in return to the server's canonical NetConnection control flow.
クライアントからサーバーへのストリームメッセージの追加のフローは、そのストリームのストリームIDで開かれ、サーバーの正規のNetConnection制御フローに関連付けられて関連付けられます。
The client MAY create as many flows as desired for any Stream ID (including Stream ID 0) at any time.
クライアントは、任意のストリームID（ストリームID 0を含む）に必要な数のフローをいつでも作成できます（MAY）。
Additional flows from the server to the client for stream messages are opened with the Stream ID for that stream, and associated in return to the client's NetConnection control flow.
サーバーからクライアントへのストリームメッセージの追加のフローは、そのストリームのストリームIDで開かれ、クライアントのNetConnection制御フローに関連付けられて関連付けられます。
The server MAY create as many flows as desired for any Stream ID (including Stream ID 0) at any time.
サーバーは、任意のストリームID（ストリームID 0を含む）に必要な数のフローをいつでも作成できます（MAY）。
Either end MAY close a sending flow that is not for Stream ID 0 at any time with no semantic meaning for the stream.
どちらの側でも、ストリームに意味のないストリームID 0でない送信フローをいつでも閉じることができます（MAY）。
At any time, either end MAY reject a receiving flow that is not one of the other end's NetConnection control flows. No flow exception codes are defined by this profile, so the receiving end SHOULD use exception code 0 when rejecting the flow. The sending end, on notification of any exception for a stream flow, SHOULD NOT open a new flow to take the rejected flow's place for transport of messages for that stream. If an end rejects any flow for a stream, it SHOULD reject all the flows for that stream, otherwise Flow Synchronization messages (Section 5.2) that were in flight could be discarded and some flows might become or remain stuck in a suspended state.
いつでも、どちらの端も、もう一方の端のNetConnection制御フローではない受信フローを拒否できます（MAY）。このプロファイルではフロー例外コードが定義されていないため、受信側はフローを拒否するときに例外コード0を使用する必要があります（SHOULD）。送信側は、ストリームフローの例外の通知時に、拒否されたフローの代わりにそのストリームのメッセージを転送するために新しいフローを開かないでください（SHOULD NOT）。エンドがストリームのフローを拒否する場合、そのストリームのすべてのフローを拒否する必要があります。そうしないと、実行中だったフロー同期メッセージ（セクション5.2）が破棄され、一部のフローが中断状態になるか、停止したままになる場合があります。
The client or server can signal an orderly close of the connection by closing its NetConnection control sending flows and all stream sending flows. The other end, on receiving a close/complete notification for the canonical NetConnection control receiving flow, closes its sending flows. When both ends observe all receiving flows have closed and completed, the connection has cleanly terminated.
クライアントまたはサーバーは、NetConnectionコントロールの送信フローとすべてのストリーム送信フローを閉じることにより、接続を正常に閉じるように通知できます。もう一方の端は、正規のNetConnectionコントロール受信フローのクローズ/完了通知を受信すると、送信フローを閉じます。両端がすべての受信フローが閉じて完了したことを確認すると、接続は正常に終了しました。
Either end can abruptly terminate the connection by rejecting the NetConnection control receiving flows or by closing the underlying RTMFP session. On notification of any exception on a NetConnection control sending flow, the end seeing the exception knows the other end has terminated abruptly, and can immediately close all sending and receiving flows for that connection.
どちらの側も、NetConnectionコントロールの受信フローを拒否するか、基になるRTMFPセッションを閉じることにより、接続を突然終了できます。 NetConnectionコントロールの送信フローで例外が通知されると、例外を確認した側は、もう一方の端が突然終了したことを認識し、その接続のすべての送信および受信フローをすぐに閉じることができます。
Client Server
|IHello (EPD:anc=URI) |
-+- |------------------------>|
| | |
| | RHello (RCert:anc)|
RTMFP | |<------------------------|
Session| | |
Hand- | |IIKeying |
shake | |------------------------>|
| | |
| | RIKeying|
-+- |<------------------------|
| |
-+- |"connect" command |
(Str.ID=0)|-CFlow-0---------------->|
| | |
| | "_result" response|
RTMP | |<----------------SFlow-0-|(Str.ID=0,
Connect| | | Assoc=CFlow-0)
Hand- | |"setPeerInfo" command |
shake | |-CFlow-0---------------->|
-+- | |
|"createStream" command |
-+- |-CFlow-0---------------->|
| | |
| | "_result" (str.ID=5)|
| |<----------------SFlow-0-|
| | |
| |"play" command |
(Str.ID=5,|-CFlow-1---------------->|
Assoc=SFlow-0)| |
| | StreamBegin User Control|
| |<----------------SFlow-1-|(Str.ID=5,
| | | Assoc=CFlow-0)
| | (RTMP stream events) |
Streaming | |<----------------SFlow-1-|
| | |
| | Audio Data |
| |<----------------SFlow-2-|(Str.ID=5,
| | | Assoc=CFlow-0)
| | Video Data |
| |<----------------SFlow-3-|(Str.ID=5,
| | : | Assoc=CFlow-0)
| : |
Figure 5: Example NetConnection Message Exchange
図5：NetConnectionメッセージ交換の例
Clients can connect directly to other clients for P2P streaming and data exchange. A client MAY have multiple separate P2P NetStreams with a peer in one RTMFP session, each a separate logical connection. P2P NetStreams are unidirectional, initiated by a subscriber (the side issuing the "play" command) to a publisher. The subscribing peer has a control flow to the publisher. The publisher has zero or more return flows to the subscriber associated to the subscriber's control flow, for the stream media and data.
クライアントは、P2Pストリーミングおよびデータ交換のために他のクライアントに直接接続できます。クライアントは、1つのRTMFPセッションにピアを持つ複数の個別のP2P NetStreamを持つことができます（それぞれ個別の論理接続）。 P2P NetStreamは一方向であり、サブスクライバー（ "play"コマンドを発行する側）によってパブリッシャーに開始されます。サブスクライブするピアには、パブリッシャーへの制御フローがあります。パブリッシャーは、ストリームメディアとデータについて、サブスクライバーの制御フローに関連付けられたサブスクライバーへの0以上のリターンフローを持っています。
A client desires to subscribe directly to a stream being published in P2P mode by a publishing peer. The client learns the peer ID of the publisher and the stream name through application-specific means.
クライアントは、公開ピアによってP2Pモードで公開されているストリームに直接サブスクライブすることを望んでいます。クライアントは、アプリケーション固有の方法でパブリッシャーのピアIDとストリーム名を学習します。
If the client does not already have an RTMFP session with that peer ID, it initiates a new session, creating an EPD containing a Fingerprint option (Section 4.4.2.3) for the publisher's peer ID and using the server session's DESTADDR as the initial candidate address for the session to the peer. The server acts as an Introducer (Section 3.5.1.6 of RFC 7016), using forward and redirect messages to help the client and the peer establish a session.
クライアントがそのピアIDのRTMFPセッションをまだ持っていない場合、クライアントは新しいセッションを開始し、発行者のピアIDの指紋オプション（4.4.2.3節）を含むEPDを作成し、サーバーセッションのDESTADDRを初期候補アドレスとして使用します。ピアへのセッションのため。サーバーはイントロデューサーとして機能し（RFC 7016のセクション3.5.1.6）、転送メッセージとリダイレクトメッセージを使用して、クライアントとピアがセッションを確立するのに役立ちます。
When an S_OPEN session exists to the desired peer, the client creates a new independent flow to that peer. The flow MUST have a non-zero Stream ID. The client sends an RTMP "play" command over the flow, giving the name of the desired stream at the publisher. This flow is the subscriber's control flow.
S_OPENセッションが目的のピアに存在する場合、クライアントはそのピアへの新しい独立したフローを作成します。フローにはゼロ以外のストリームIDが必要です。クライアントは、フローを介してRTMP "play"コマンドを送信し、パブリッシャーで目的のストリームの名前を指定します。このフローは、サブスクライバーの制御フローです。
The publisher, on accepting a new flow not indicating a return association with any of its sending flows and having a non-zero Stream ID, receives and processes the "play" command. If and when the request is acceptable to the publisher, it opens one or more return flows to the subscribing peer, associated to the subscriber's control flow and having the same Stream ID. The publisher sends a StreamBegin User Control message, appropriate RTMP status events, and the stream media over the one or more return flows.
パブリッシャーは、その送信フローのいずれかとの戻り関連付けを示さず、ゼロ以外のストリームIDを持つ新しいフローを受け入れると、「play」コマンドを受信して処理します。リクエストがパブリッシャーに受け入れ可能である場合、サブスクライバーの制御フローに関連付けられ、同じストリームIDを持つ1つ以上のリターンフローをサブスクライブピアに開きます。パブリッシャーは、1つ以上のリターンフローを介して、StreamBeginユーザーコントロールメッセージ、適切なRTMPステータスイベント、およびストリームメディアを送信します。
The subscriber uses the return association of the media flows to the subscriber control flow to determine the stream to which the media belongs.
加入者は、加入者制御フローへのメディアフローのリターンアソシエーションを使用して、メディアが属するストリームを決定します。
The publisher MAY open any number of media flows for the stream and close them at any time. The opening and closing of media flows has no semantic meaning for the stream, except that the opening of at least one flow and the reception of at least one media message or a StreamBegin User Control message indicates that the publisher is publishing the requested stream to the subscriber.
パブリッシャーは、ストリームの任意の数のメディアフローを開き、いつでも閉じることができます。メディアフローの開始と終了は、ストリームに対して意味を持ちません。ただし、少なくとも1つのフローの開始と少なくとも1つのメディアメッセージまたはStreamBeginユーザーコントロールメッセージの受信は、パブリッシャーが要求されたストリームをパブリッシュしていることを示します。加入者。
Subscriber Publisher
------>--Subscriber-Control-Flow------------------>--+
|
<------------------Publisher-Stream-Flow-1--<--+
: |
<------------------Publisher-Stream-Flow-N--<--+
Figure 6: Schematic Flow Association Tree for a P2P Direct Connection
図6：P2P直接接続の回路図フローアソシエーションツリー
Either end can close the stream by closing or rejecting the subscriber's control flow. The publisher SHOULD close and unpublish to the subscriber on receipt of a close/complete of the control flow. The subscriber SHOULD consider the stream closed on notification of any exception on the control flow.
どちらの側も、サブスクライバーの制御フローを閉じるか拒否することにより、ストリームを閉じることができます。パブリッシャーは、制御フローのクローズ/完了を受信すると、サブスクライバーに対してクローズして非公開にする必要があります（SHOULD）。サブスクライバーは、制御フローでの例外の通知時にストリームが閉じられたと考える必要があります。
This memo specifies option type code values for Certificate fields (Section 4.3.3), Endpoint Discriminator fields (Section 4.4.2), and Session Keying Component fields (Section 4.5.2). It also specifies a flow metadata signature (Section 5.1.1). The type code values and signatures for this profile are assigned and maintained by Adobe, and therefore require no action from IANA.
このメモは、証明書フィールド（セクション4.3.3）、エンドポイント識別フィールド（セクション4.4.2）、およびセッションキーイングコンポーネントフィールド（セクション4.5.2）のオプションタイプコード値を指定します。また、フローメタデータシグネチャも指定します（セクション5.1.1）。このプロファイルのタイプコード値と署名はアドビによって割り当てられ維持されるため、IANAからのアクションは必要ありません。
This memo describes use of an RTMFP URI scheme (Section 4.4.2.2, Section 5.3.1, Figure 5). Per this section, the "rtmfp" URI scheme has been registered by IANA.
このメモは、RTMFP URIスキームの使用について説明しています（セクション4.4.2.2、セクション5.3.1、図5）。このセクションに従って、「rtmfp」URIスキームはIANAによって登録されています。
The syntax and semantics of this URI scheme are described using the Augmented Backus-Naur Form (ABNF) [RFC5234] rules from RFC 3986.
このURIスキームの構文とセマンティクスは、RFC 3986のAugmented Backus-Naur Form（ABNF）[RFC5234]ルールを使用して記述されています。
URI scheme name: rtmfp
URIスキーム名：rtmfp
Status: provisional
ステータス：暫定
URI scheme syntax:
URIスキームの構文：
rtmfp-uri-scheme = "rtmfp:"
/ "rtmfp://" host [ ":" port ] path-abempty
URI scheme semantics: The first form is used in the APIs of some implementations to indicate instantiation of an RTMFP client according to this memo, but without connecting to a server. Such an instantiation might be used for pure peer-to-peer communication.
URIスキームのセマンティクス：最初の形式は、このメモに従ってRTMFPクライアントのインスタンス化を示すために一部の実装のAPIで使用されますが、サーバーに接続しません。このようなインスタンス化は、純粋なピアツーピア通信に使用できます。
The second form provides location information for the server to which to connect and optional additional information to pass to the server. The only operation for this URI form is to connect to a server (initial candidate address(es) for which are named by host and port) according to Section 5.3. The UDP port for initial candidate addresses, if not specified, is 1935. If the host is a reg-name, the initial candidate address set SHOULD comprise all IPv4 and IPv6 addresses to which reg-name resolves. The semantics of path-abempty are specific to the server. Connections are made using RTMFP as specified by this memo.
2番目のフォームは、接続するサーバーの場所情報と、サーバーに渡すオプションの追加情報を提供します。このURIフォームの唯一の操作は、セクション5.3に従ってサーバー（ホストとポートによって名前が付けられた最初の候補アドレス）に接続することです。指定されていない場合、最初の候補アドレスのUDPポートは1935です。ホストがreg-nameの場合、最初の候補アドレスセットは、reg-nameが解決するすべてのIPv4およびIPv6アドレスを含む必要があります（SHOULD）。パスが空であることのセマンティクスはサーバーに固有です。接続は、このメモで指定されたRTMFPを使用して行われます。
Encoding considerations: The path-abempty component represents textual data consisting of characters from the Universal Character Set. This component SHOULD be encoded according to Section 2.5 of RFC 3986.
エンコードに関する考慮事項：パスが空のコンポーネントは、ユニバーサル文字セットの文字で構成されるテキストデータを表します。このコンポーネントは、RFC 3986のセクション2.5に従ってエンコードする必要があります（SHOULD）。
Applications/protocols that use this URI scheme name: The Flash runtime (including Flash Player) from Adobe Systems Incorporated, communication servers such as Adobe Media Server, and interoperable clients and servers provided by other parties, using RTMFP according to this memo.
このURIスキーム名を使用するアプリケーション/プロトコル：Adobe Systems IncorporatedのFlashランタイム（Flash Playerを含む）、Adobe Media Serverなどの通信サーバー、および他の関係者が提供する相互運用可能なクライアントとサーバー。このメモに従ってRTMFPを使用します。
Interoperability considerations: This scheme requires use of RTMFP as defined by RFC 7016 in the manner described by this memo.
相互運用性に関する考慮事項：このスキームでは、RFC 7016で定義されているRTMFPをこのメモで説明されている方法で使用する必要があります。
Security considerations: See Security Considerations (Section 7) in this memo.
セキュリティに関する考慮事項：このメモのセキュリティに関する考慮事項（セクション7）を参照してください。
Contact: Michael Thornburgh, Adobe Systems Incorporated, <mthornbu@adobe.com>.
連絡先：Michael Thornburgh、Adobe Systems Incorporated、<mthornbu@adobe.com>。
Author/Change controller: Michael Thornburgh, Adobe Systems Incorporated, <mthornbu@adobe.com>.
著者/変更コントローラ：Michael Thornburgh、Adobe Systems Incorporated、<mthornbu@adobe.com>。
References: Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol", RFC 7016, November 2013.
参考資料：Thornburgh、M。、「AdobeのSecure Real-Time Media Flow Protocol」、RFC 7016、2013年11月。
This memo.
このメモ。
Section 4 details the cryptographic aspects of this profile.
セクション4では、このプロファイルの暗号化の側面について詳しく説明します。
This profile does not define or use a Public Key Infrastructure (PKI). Clients SHOULD use static Diffie-Hellman keys in their certificates (Section 4.3.3.5). Clients MUST create a new certificate with a distinct fingerprint for each new NetConnection (Section 5.3). These constraints make client identities ephemeral but unable to be forged. A man-in-the-middle cannot successfully interpose itself in a connection to a target client addressed by its fingerprint/peer ID if the target client uses a static Diffie-Hellman public key.
このプロファイルは、公開鍵基盤（PKI）を定義または使用しません。クライアントは、証明書で静的Diffie-Hellmanキーを使用する必要があります（セクション4.3.3.5）。クライアントは、新しいNetConnectionごとに異なるフィンガープリントを使用して新しい証明書を作成する必要があります（セクション5.3）。これらの制約により、クライアントIDは短命になりますが、偽造することはできません。中間者は、ターゲットクライアントが静的Diffie-Hellman公開鍵を使用している場合、フィンガープリント/ピアIDでアドレス指定されたターゲットクライアントへの接続に自分自身をうまく挿入できません。
Servers can have long-lived RTMFP instances, so they SHOULD use ephemeral Diffie-Hellman public keys for forward secrecy. This allows server peer IDs to be forged; however, clients do not connect to servers by peer ID, so this is irrelevant.
サーバーは、存続期間の長いRTMFPインスタンスを持つことができるため、転送の秘密性のために一時的なDiffie-Hellman公開鍵を使用する必要があります。これにより、サーバーピアIDを偽造できます。ただし、クライアントはピアIDでサーバーに接続しないため、これは無関係です。
When a client connects to a server, the client will accept the response of any endpoint claiming to be "a server". It is assumed that an attacker that can passively observe traffic on a network segment can also inject its own packets with any source or destination and any payload. An attacker can trick a client into connecting to a rogue server or man-in-the-middle, either by observing Initiator Hello packets from the client and responding earliest with a matching Responder Hello or by using tricks such as DNS spoofing or poisoning to direct a client to connect directly to the rogue. A TCP-based transport would be vulnerable to similar attacks. Since there is no PKI, this profile gives no guarantee that the client has actually connected to the desired server, versus a rogue or man-in-the-middle. In circumstances where assurance is required that the connection is directly to the desired server, the client can use the Session Nonces (Section 4.6.5) to challenge the server, for example, over a different channel having acceptable security properties (such as an HTTPS) to transitively establish the server's identity and verify that the end-to-end communication is private and authentic.
クライアントがサーバーに接続すると、クライアントは「サーバー」であると主張するエンドポイントの応答を受け入れます。ネットワークセグメント上のトラフィックを受動的に監視できる攻撃者は、任意の送信元または宛先、および任意のペイロードを含む自身のパケットを挿入することもできると想定されています。攻撃者は、クライアントからのイニシエーターHelloパケットを監視し、一致するResponder Helloで最も早く応答するか、DNSスプーフィングやポイズニングなどのトリックを使用して、クライアントを不正サーバーまたは中間者に接続させることができます。不正に直接接続するクライアント。 TCPベースのトランスポートは、同様の攻撃に対して脆弱です。 PKIがないため、このプロファイルは、クライアントが悪意のあるまたは中間者ではなく、実際に目的のサーバーに接続していることを保証しません。目的のサーバーに直接接続することが保証されている必要がある状況では、クライアントはセッションナンス（セクション4.6.5）を使用して、たとえば、HTTPSなどの許容可能なセキュリティプロパティを持つ別のチャネルを介してサーバーにチャレンジできます。 ）サーバーのIDを推移的に確立し、エンドツーエンドの通信がプライベートで信頼できることを確認します。
When session sequence numbers (Section 4.7.3.3) are not used, it is possible for an attacker to use traffic analysis techniques and record encrypted packets containing the start of a new flow, and later to replay those packets after the flow has closed, which can look to the receiver like a brand new flow. In circumstances where this can be detrimental, session sequence numbers SHOULD be used. Replay of packets for existing flows is not detrimental as the receiver detects and discards duplicate flow sequence numbers, and flow sequence numbers do not wrap or otherwise repeat.
セッションシーケンス番号（セクション4.7.3.3）が使用されていない場合、攻撃者はトラフィック分析手法を使用して、新しいフローの開始を含む暗号化されたパケットを記録し、後でフローが閉じた後にそれらのパケットを再生することができます。まったく新しいフローのように受信機を見ることができます。これが有害になる可能性がある状況では、セッションシーケンス番号を使用する必要があります（SHOULD）。既存のフローのパケットの再生は、レシーバーが重複するフローシーケンス番号を検出して破棄するため有害ではなく、フローシーケンス番号は折り返されないか、または繰り返されません。
Packet encryption uses CBC with the same (null) initialization vector for each packet. This can reveal to an observer whether two packets contain identical plaintext. However, the maximum-length RTMFP common header and User Data or Data Acknowledgement header, including flow sequence number, always fit within the first 16-byte cipher block, so each initial cipher block for most packets will already be unique even if timestamps are suppressed. Sending identical messages in a flow uses unique flow sequence numbers, so cipher blocks will be unique in this case. Keepalive pings and retransmission of lost data can result in identical cipher blocks; however, traffic analysis can also reveal likely keepalives or retransmissions, and retransmission only occurs as a result of observable network loss, so this is usually irrelevant. In circumstances where any identical cipher block is unacceptable, session sequence numbers SHOULD be used as they guarantee each initial cipher block will be unique.
パケットの暗号化では、各パケットに同じ（null）初期化ベクトルを使用するCBCを使用します。これにより、2つのパケットに同一の平文が含まれているかどうかを観察者に明らかにすることができます。ただし、フローシーケンス番号を含む最大長のRTMFP共通ヘッダーとユーザーデータまたはデータ確認応答ヘッダーは常に最初の16バイトの暗号ブロック内に収まるため、タイムスタンプが抑制されていても、ほとんどのパケットの各初期暗号ブロックはすでに一意です。 。フローで同一のメッセージを送信する場合、一意のフローシーケンス番号が使用されるため、この場合、暗号ブロックは一意になります。キープアライブpingと失われたデータの再送信により、同一の暗号ブロックが生成される可能性があります。ただし、トラフィック分析ではキープアライブまたは再送信の可能性も明らかになる可能性があり、再送信は観測可能なネットワーク損失の結果としてのみ発生するため、これは通常は無関係です。同一の暗号ブロックが受け入れられない状況では、セッションシーケンス番号を使用する必要があります（SHOULD）。これにより、各初期暗号ブロックが一意になることが保証されます。
Packet verification can use a 16-bit simple checksum (Section 4.7.3.1). The checksum is inside the encrypted packet, so for external packet modifications the checksum is equivalent to a 16-bit cryptographic digest. In circumstances where this is insufficient, HMAC verification (Section 4.7.3.2) SHOULD be used.
パケット検証では、16ビットの単純なチェックサムを使用できます（セクション4.7.3.1）。チェックサムは暗号化されたパケット内にあるため、外部パケット変更の場合、チェックサムは16ビットの暗号化ダイジェストに相当します。これが不十分な状況では、HMAC検証（セクション4.7.3.2）を使用する必要があります（SHOULD）。
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
[AES]国立標準技術研究所、「Advanced Encryption Standard（AES）」、FIPS PUB 197、2001年11月、<http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>。
[AMF0] Adobe Systems Incorporated, "Action Message Format -- AMF 0", December 2007, <http://www.adobe.com/go/spec_amf0>.
[AMF0] Adobe Systems Incorporated、 "Action Message Format-AMF 0"、December 2007、<http://www.adobe.com/go/spec_amf0>。
[AMF3] Adobe Systems Incorporated, "Action Message Format -- AMF 3", January 2013, <http://www.adobe.com/go/spec_amf3>.
[AMF3] Adobe Systems Incorporated、「Action Message Format-AMF 3」、2013年1月、<http://www.adobe.com/go/spec_amf3>。
[CBC] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, December 2001, <http://csrc.nist.gov/publications/nistpubs/800-38a/ sp800-38a.pdf>.
[CBC] Dworkin、M。、「Block Cipher Modes of Operation」、NIST Special Publication 800-38A、December 2001、<http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a .pdf>。
[DH] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, V. IT-22, n. 6, June 1977.
[DH] Diffie、W.およびM. Hellman、「暗号化の新しい方向性」、IEEE Transactions on Information Theory、V。IT-22、n。 1977年6月6日。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月、<http://www.rfc-editor.org/info/ rfc2104>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003, <http://www.rfc-editor.org/info/rfc3526>.
[RFC3526] Kivinen、T。、およびM. Kojo、「インターネット鍵交換（IKE）のためのModular Exponential（MODP）Diffie-Hellmanグループ、RFC 3526、2003年5月、<http://www.rfc-editor.org / info / rfc3526>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月、<http://www.rfc-editor.org/info/rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、2011年5月、<http://www.rfc-editor.org/info/ rfc6234>。
[RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol", RFC 7016, November 2013, <http://www.rfc-editor.org/info/rfc7016>.
[RFC7016] Thornburgh、M。、「AdobeのSecure Real-Time Media Flow Protocol」、RFC 7016、2013年11月、<http://www.rfc-editor.org/info/rfc7016>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、2014年10月、< http://www.rfc-editor.org/info/rfc7296>。
[RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol (RTMP) specification", December 2012, <http://www.adobe.com/go/spec_rtmp>.
[RTMP] Adobe Systems Incorporated、「リアルタイムメッセージングプロトコル（RTMP）仕様」、2012年12月、<http://www.adobe.com/go/spec_rtmp>。
[SHA256] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[SHA256] National Institute of Standards and Technology、「Secure Hash Standard」、FIPS PUB 180-4、2012年3月、<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4。 pdf>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988, <http://www.rfc-editor.org/info/rfc1071>.
[RFC1071] Braden、R.、Borman、D.、Partridge、C。、およびW. Plummer、「Computing the Internet checksum」、RFC 1071、1988年9月、<http://www.rfc-editor.org/info / rfc1071>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月、<http://www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC6479] Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm without Bit Shifting", RFC 6479, January 2012, <http://www.rfc-editor.org/info/rfc6479>.
[RFC6479] Zhang、X。およびT. Tsou、「ビットシフトのないIPsecアンチリプレイアルゴリズム」、RFC 6479、2012年1月、<http://www.rfc-editor.org/info/rfc6479>。
Acknowledgements
謝辞
Special thanks go to Glenn Eguchi, Matthew Kaufman, and Adam Lane for their contributions to the design of this profile.
このプロファイルの設計に貢献してくれたGlenn Eguchi、Matthew Kaufman、Adam Laneに特に感謝します。
Thanks to Philipp Hancke, Kevin Igoe, Paul Kyzivat, and Milos Trboljevac for their detailed reviews of this memo.
このメモの詳細なレビューを提供してくれたPhilipp Hancke、Kevin Igoe、Paul Kyzivat、Milos Trboljevacに感謝します。
Author's Address
著者のアドレス
Michael C. Thornburgh Adobe Systems Incorporated 345 Park Avenue San Jose, CA 95110-2704 United States
Michael C. Thornburgh Adobe Systems Incorporated 345 Park Avenue San Jose、CA 95110-2704 United States
Phone: +1 408 536 6000
EMail: mthornbu@adobe.com
URI: http://www.adobe.com/