[要約] RFC 8857は、バイナリフロア制御プロトコル（BFCP）を輸送するためのWebSocketプロトコルに関する規格です。このRFCの目的は、BFCPをWebSocketを介して効果的に転送する方法を定義することです。
Internet Engineering Task Force (IETF) V. Pascual
Request for Comments: 8857 Nokia
Category: Standards Track A. Román
ISSN: 2070-1721 Quobis
S. Cazeaux
Orange
G. Salgueiro
R. Ravindranath
Cisco
January 2021
The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
バイナリフロア制御プロトコルのトランスポートとしてのWebSocketプロトコル（BFCP）
Abstract
概要
The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies the use of Binary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios.
WebSocketプロトコルは、クライアントとサーバー間の双方向リアルタイム通信を可能にします。このドキュメントは、新しいシナリオのBFCPエンティティ間の信頼できるトランスポートメカニズムを有効にする新しいWebSocketサブプロトコルとしてのバイナリフロア制御プロトコル（BFCP）の使用を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8857.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc8857で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Definitions
3. The WebSocket Protocol
4. The WebSocket BFCP Subprotocol
4.1. Handshake
4.2. BFCP Encoding
5. Transport Reliability
6. SDP Considerations
6.1. Transport Negotiation
6.2. SDP Media Attributes
7. SDP Offer/Answer Procedures
7.1. General
7.2. Example Usage of 'websocket-uri' SDP Attribute
8. Authentication
9. Security Considerations
10. IANA Considerations
10.1. Registration of the WebSocket BFCP Subprotocol
10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP
"proto" Values
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
The WebSocket (WS) protocol [RFC6455] enables two-way message exchange between clients and servers on top of a persistent TCP connection, optionally secured with Transport Layer Security (TLS) [RFC8446]. The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.
WebSocket（WS）プロトコル[RFC6455]は、トランスポートレイヤセキュリティ（TLS）[RFC8446]で任意選択で保護されている永続的TCP接続の上のクライアントとサーバー間の双方向メッセージ交換を可能にします。初期プロトコルハンドシェイクは、HyperText Transfer Protocol（HTTP）[RFC7230]セマンティクスを利用しており、WebSocketプロトコルは既存のHTTPインフラストラクチャを再利用することができます。
The Binary Floor Control Protocol (BFCP) is a protocol to coordinate access to shared resources in a conference. It is defined in [RFC8855] and is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
バイナリフロア制御プロトコル（BFCP）は、会議の共有リソースへのアクセスを調整するためのプロトコルです。それは[RFC8855]で定義され、フロア参加者とフロアコントロールサーバー、フロアチェア（すなわち、モデレータ）とフロアコントロールサーバーの間で使用されます。
Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. This document extends the applicability of [RFC8855] and [RFC8856] to enable the usage of BFCP in these scenarios.
最新のWebブラウザには、W3Cによって指定されているWebSocket API [WS-API]に準拠したWebSocketクライアントスタックが含まれます。他のクライアントアプリケーション（パソコンやスマートフォンなどのデバイスで実行されているもの）も、WebSocketクライアントスタックを使用可能にすることが予想されます。この文書では、[RFC8855]と[RFC8856]の適用性が拡張され、これらのシナリオでBFCPの使用を可能にします。
The transport over which BFCP entities exchange messages depends on how the clients obtain information to contact the floor control server (e.g., using a Session Description Protocol (SDP) offer/answer exchange per [RFC8856] or the procedure described in RFC 5018 [RFC5018]). [RFC8855] defines two transports for BFCP: TCP and UDP. This specification defines a new WebSocket subprotocol (as defined in Section 1.9 of [RFC6455]) for transporting BFCP messages between a WebSocket client and server. This subprotocol provides a reliable and boundary-preserving transport for BFCP when run on top of TCP. Since WebSocket provides a reliable transport, the extensions defined in [RFC8855] for sending BFCP over unreliable transports are not applicable.
BFCPエンティティを交換する輸送は、クライアントがフロアコントロールサーバーに連絡するための情報を取得する方法（例えば、RFC8856; RFC8856）またはRFC 5018 [RFC5018]に記載されている手順に依存します。）。[RFC8855] BFCP：TCPとUDPの2つのトランスポートを定義します。この仕様では、WebSocketクライアントとサーバー間でBFCPメッセージを転送するための新しいWebSocketサブプロトコル（[RFC6455]のセクション1.9で定義）を定義します。このサブプロトコルは、TCPの上に走るときにBFCPのための信頼性が高く境界保存されているトランスポートを提供します。WebSocketは信頼できるトランスポートを提供するので、信頼できないトランスポートでBFCPを送信するための[RFC8855]で定義されている拡張機能は適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきです。
BFCP WebSocket Client: Any BFCP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket BFCP subprotocol as defined by this document.
BFCP WebSocketクライアント：このドキュメントによって定義されているように、WebSocketサーバーへのアウトバウンド接続を開くことができ、WebSocket BFCPサブプロトコルを通信することができる任意のBFCPエンティティ。
BFCP WebSocket Server: Any BFCP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket BFCP subprotocol as defined by this document.
BFCP WebSocketサーバー：WebSocketクライアントからのインバウンド接続をリッスンし、このドキュメントで定義されているWebSocket BFCPサブプロトコルを使用して通信できるBFCPエンティティ。
The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC8446]) in which both client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket subprotocol and extensions negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes.
WebSocketプロトコル[RFC6455]は、クライアントとサーバーの両方のメッセージユニットの両方の方向にメッセージユニットの両方がメッセージユニットの両方を使用しているTCPの上にあるトランスポート層です。このプロトコルは、接続ハンドシェイク、WebSocketサブプロトコルおよび拡張ネゴシエーション、アプリケーションを送信するためのフレームフォーマット、マスキングメカニズム、および切断の原因を示すためのステータスコードを定義します。
The WebSocket connection handshake is based on HTTP [RFC7230] and utilizes the HTTP GET method with an Upgrade header field. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed, the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, the client and server agree on the application protocol to use on top of the WebSocket transport. Such an application protocol (also known as a "WebSocket subprotocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as the WebSocket BFCP subprotocol defined in this document). Once the HTTP 101 response is processed, both the client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges.
WebSocket接続ハンドシェイクはHTTP [RFC7230]に基づいており、アップグレードヘッダーフィールドを使用してHTTP GETメソッドを利用します。これはクライアントによって送信され、次にHTTP 101のステータスコードでサーバー（ネゴシエーションが成功した場合）によって回答されます。ハンドシェイクが完了すると、HTTPからWebSocketプロトコルへの接続がアップグレードされます。このハンドシェイク手順は、既存のHTTPインフラストラクチャを再利用するように設計されています。接続ハンドシェイクの間、クライアントとサーバーはWebSocketトランスポートの上で使用するアプリケーションプロトコルに同意します。そのようなアプリケーションプロトコル（「WebSocketサブプロトコル」とも呼ばれる）は、エンドポイントによって交換されるメッセージのフォーマットとセマンティクスを定義します。これは、カスタムプロトコルまたは標準化されたもの（この文書で定義されているWebSocket BFCPサブプロトコルとして）です。 HTTP101応答が処理されると、クライアントとサーバーの両方が基礎となるTCP接続を再利用して、WebSocketメッセージとコントロールフレームを互いに制御します。プレーンHTTPとは異なり、この接続は永続的であり、複数のメッセージ交換に使用できます。
The WebSocket protocol defines message units to be used by applications for the exchange of data, so it provides a message boundary-preserving transport layer.
WebSocketプロトコルは、データの交換のためのアプリケーションによって使用されるメッセージユニットを定義しているため、メッセージ境界保存トランスポート層を提供します。
The term WebSocket subprotocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket BFCP subprotocol for carrying BFCP messages over a WebSocket connection.
WebSocketサブプロトコルという用語は、WebSocket接続の上に階層化されたアプリケーションレベルプロトコルを指します。このドキュメントは、WebSocket接続を介してBFCPメッセージを伝送するためのWebSocket BFCPサブプロトコルを指定します。
The BFCP WebSocket client and BFCP WebSocket server negotiate usage of the WebSocket BFCP subprotocol during the WebSocket handshake procedure as defined in Section 1.3 of [RFC6455]. The client MUST include the value "bfcp" in the Sec-WebSocket-Protocol header field in its handshake request. The 101 reply from the server MUST contain "bfcp" in its corresponding Sec-WebSocket-Protocol header field.
BFCP WebSocketクライアントおよびBFCP WebSocketサーバーは、[RFC6455]のセクション1.3で定義されているWebSocketハンドシェイクプロシージャー中にWebSocket BFCPサブプロトコルの使用をネゴシエートします。クライアントは、ハンドシェイク要求のsec-websocket-protocolヘッダーフィールドに値 "bfcp"を含める必要があります。サーバーからの101の返信には、それぞれのSEC-WebSocket-Protocolヘッダーフィールドに "BFCP"を含める必要があります。
Below is an example of a WebSocket handshake in which the client requests the WebSocket BFCP subprotocol support from the server:
以下は、クライアントがサーバーからWebSocket BFCPサブプロトコルサポートを要求するWebSocketハンドシェイクの例です。
GET / HTTP/1.1
Host: bfcp-ws.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com
Sec-WebSocket-Protocol: bfcp
Sec-WebSocket-Version: 13
The handshake response from the server accepting the WebSocket BFCP subprotocol would look as follows:
WebSocket BFCPサブプロトコルを受け入れるサーバーからのハンドシェイクの応答は次のようになります。
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: bfcp
Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of BFCP messages.
ネゴシエーションが完了すると、WebSocket接続が確立され、BFCPメッセージのトランスポートに使用できます。
BFCP messages use a TLV (Type-Length-Value) binary encoding, therefore BFCP WebSocket clients and BFCP WebSocket servers MUST be transported in unfragmented binary WebSocket frames (FIN: 1, opcode: %x2) to exchange BFCP messages. The WebSocket frame data MUST be a valid BFCP message, so the length of the payload of the WebSocket frame MUST be lower than the maximum size allowed (2^(16) +12 bytes) for a BFCP message as described in [RFC8855]. In addition, the encoding rules for reliable protocols defined in [RFC8855] MUST be followed.
While this specification assumes that BFCP encoding is only TLV binary, future documents may define other mechanisms, like JSON serialization. If encoding changes, a new subprotocol identifier would need to be selected.
この仕様は、BFCPエンコーディングがTLVバイナリのみであると仮定しているが、JSONシリアル化のように将来の文書は他のメカニズムを定義することができる。エンコードが変更された場合は、新しいサブプロトコル識別子を選択する必要があります。
Each BFCP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one BFCP message.
各BFCPメッセージは単一のWebSocketメッセージ内で実行する必要があり、WebSocketメッセージに複数のBFCPメッセージを含める必要はありません。
The WebSocket protocol [RFC6455] provides a reliable transport, and therefore the BFCP WebSocket subprotocol defined by this document also provides reliable BFCP transport. Thus, client and server transactions using the WebSocket protocol for transport MUST follow the procedures for reliable transports as defined in [RFC8855] and [RFC8856].
WebSocketプロトコル[RFC6455]は信頼できるトランスポートを提供します。したがって、この文書によって定義されたBFCP WebSocketサブプロトコルは信頼できるBFCPトランスポートも提供します。したがって、トランスポート用のWebSocketプロトコルを使用したクライアントおよびサーバートランザクションは、[RFC8855]と[RFC8856]で定義されている信頼できるトランスポートの手順に従う必要があります。
BFCP WebSocket clients cannot receive incoming WebSocket connections initiated by any other peer. This means that a BFCP WebSocket client MUST actively initiate a connection towards a BFCP WebSocket server. The BFCP server will have a globally routable address and thus does not require ICE, as clients always initiate connections to it.
BFCP WebSocketクライアントは、他のピアによって開始された着信WebSocket接続を受信できません。これは、BFCP WebSocketクライアントがBFCP WebSocketサーバーへの接続を能動的に開始する必要があります。クライアントが常に接続を開始するため、BFCPサーバーはグローバルにルーティング可能なアドレスを持ちます。
Rules to generate an "m=" line for a BFCP stream are described in [RFC8856], Section 4.
BFCPストリームの「M =」行を生成するための規則は、[RFC8856]、セクション4で説明されています。
New values are defined for the SDP "proto" field: 'TCP/WS/BFCP' and 'TCP/WSS/BFCP'.
新しい値は、「TCP / WS / BFCP」と「TCP / WSS / BFCP」のSDPの「Proto」フィールドに定義されています。
'TCP/WS/BFCP' is used when BFCP runs on top of WS, which in turn runs on top of TCP.
'tcp / ws / bfcp'は、BFCPがWSの上で実行されている場合に使用されます。これはTCPの上に実行されます。
'TCP/WSS/BFCP' is used when BFCP runs on top of secure WebSocket (WSS), which in turn runs on top of TLS and TCP.
'tcp / wss / bfcp'は、BFCPがセキュアWebSocket（WSS）の上に実行されている場合に使用されます。これはTLSとTCPの上に実行されます。
The "port" field is set following the rules in Section 4 and Section 7.1 of [RFC8856]. Depending on the value of the SDP 'setup' attribute defined in [RFC4145], the "port" field contains the port to which the remote endpoint will direct BFCP messages, or it is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of '9', which is the discard port. The 'connection' attribute and port MUST follow the rules of [RFC4145].
「PORT」フィールドは、[RFC8856]のセクション4およびセクション7.1の規則に従って設定されています。[RFC4145]で定義されているSDP 'setup'属性の値に応じて、「Port」フィールドには、リモートエンドポイントがBFCPメッセージを転送するポートが含まれているか、または無関係です（つまり、エンドポイントに向けて接続が開始されます。リモートエンドポイント）および廃棄ポートである '9'の値に設定する必要があります。'connection'属性とポートは、[RFC4145]の規則に従う必要があります。
While this document recommends the use of secure WebSocket (i.e., TCP/WSS) for security reasons, TCP/WS is also permitted so as to achieve maximum compatibility among clients.
このドキュメントではセキュリティ上の理由から、セキュリティ上の理由からセキュアWebSocket（すなわちTCP / WSS）の使用を推奨しているが、クライアント間の最大の互換性を達成するようにTCP / WSも許可される。
[RFC8124] defines a new SDP attribute to indicate the connection Uniform Resource Identifier (URI) for the WebSocket client. The SDP attribute 'websocket-uri' defined in Section 3 of [RFC8124] MUST be used when BFCP runs on top of WS or WSS. When the 'websocket-uri' attribute is present in the media section of the SDP, the procedures mentioned in Section 4 of [RFC8124] MUST be followed.
[RFC8124] WebSocketクライアントの接続均一リソース識別子（URI）を示すための新しいSDP属性を定義します。[RFC8124]のセクション3で定義されているSDP属性 'WebSocket-URI'は、BFCPがWSまたはWSSの上に実行されている場合に使用する必要があります。'websocket-uri'属性がSDPのメディアセクションに存在する場合は、[RFC8124]のセクション4に記載されている手順に従う必要があります。
An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each BFCP-over-WebSocket media stream and MUST assign either a 'TCP/WSS/BFCP' or 'TCP/WS/BFCP' value to the "proto" field of the "m=" line depending on whether the endpoint wishes to use secure WebSocket or WebSocket. Furthermore, the server side, which could be either the offerer or answerer, MUST add a 'websocket-uri' attribute in the media section depending on whether it wishes to use WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in [RFC8124]. Additionally, the SDP offer/answer procedures defined in Section 4 of [RFC8124] MUST be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.
エンドポイント（すなわち、オファーと回答者の両方）は、各BFCP-over-websocketメディアストリームに対してSDPメディア記述（ "m =" "行）を作成しなければならず、 'TCP / WSS / BFCP'または 'TCP /を割り当てる必要があります。ws / bfcp '"m ="行の "Proto"フィールドに "M ="行の "Proto"フィールドに応じて、Secure WebScostonまたはWebScocketが使用されます。さらに、提供者または回答者のいずれかである可能性があるサーバー側は、WebSocketまたはSecure WebScocketを使用したいかどうかに応じて、メディアセクションに「WebSocket-URI」属性を追加する必要があります。この新しい属性は[RFC8124]で定義されている構文に従わなければなりません。さらに、[RFC8124]のセクション4で定義されているSDPオファー/アンサープロシージャに、BFCP-over-WebSocketメディアストリームに関連付けられている "M ="行を続ける必要があります。
The following is an example of an "m=" line for a BFCP connection. In this example, the offerer sends the SDP with the "proto" field having a value of 'TCP/WSS/BFCP', indicating that the offerer wishes to use secure WebSocket as a transport for the media stream, and the "fmt" field having a value of '*' (for details on the "fmt" field, see Section 4 of [RFC8856]).
以下は、BFCP接続の「M =」行の例です。この例では、オファーは 'TCP / WSS / BFCP'の値を持つ "Proto"フィールドをSDPに送信し、オファーがメディアストリームのトランスポートとしてセキュアWebScostを使用し、 "FMT"フィールドを望んでいることを示します。値が「*」の値を持つ（「FMT」フィールドの詳細については、[RFC8856]のセクション4を参照してください。
Offer (browser):
m=application 9 TCP/WSS/BFCP *
a=setup:active
a=connection:new
a=floorctrl:c-only
m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31
Answer (server):
m=application 50000 TCP/WSS/BFCP *
a=setup:passive
a=connection:new
a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
a=floorctrl:s-only
a=confid:4321
a=userid:1234
a=floorid:1 m-stream:10
a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0
a=label:10
m=video 50004 RTP/AVP 31
a=label:11
It is possible that an endpoint (e.g., a browser) sends an offerless INVITE to the server. In such cases, the server will act as SDP offerer. The server MUST assign the SDP 'setup' attribute with a value of 'passive'. The server MUST have a 'websocket-uri' attribute with a 'ws-URI' or 'wss-URI' value depending on whether the server wishes to use WebSocket or secure WebSocket. This attribute MUST follow the syntax defined in Section 3 of [RFC8124]. For BFCP application, the "proto" value in the "m=" line MUST be 'TCP/WSS/ BFCP' if WebSocket is over TLS, else it MUST be 'TCP/WS/BFCP'.
エンドポイント（例えば、ブラウザ）がオファーレスINVITEをサーバに送信することが可能である。そのような場合、サーバーはSDPオファーとして機能します。サーバーは、SDP 'Setup'属性を 'Passive'の値で割り当てる必要があります。サーバーは、サーバーがWebSocketまたはSecure WebScocketを使用したいのかによって、「WS-URI」または「WSS-URI」の値を持つ「WebSocket-URI」属性を持つ必要があります。この属性は[RFC8124]のセクション3で定義されている構文に従う必要があります。BFCPアプリケーションの場合、WebSocketがTLSを介している場合は、「M =」行の「PROTO」値が「TCP / WSS / BFCP」でなければなりません。そうでなければ、そうでなければ「TCP / WS / BFCP」でなければなりません。
Section 9 of [RFC8855] states that BFCP clients and floor control servers SHOULD authenticate each other prior to accepting messages, and RECOMMENDS that mutual TLS/DTLS authentication be used. However, browser-based WebSocket clients have no control over the use of TLS in the WebSocket API [WS-API], so it is RECOMMENDED that standard web-based methods for client and server authentication are used, as follows.
[RFC8855]のセクション9は、メッセージを受け入れる前にBFCPクライアントとフロアコントロールサーバーが互いに認証されるべきであり、相互TLS / DTLS認証を使用することをお勧めします。ただし、ブラウザベースのWebSocketクライアントはWebSocket API [WS-API]のTLSの使用を制御しないため、次のようにクライアントおよびサーバー認証の標準のWebベースのメソッドが使用されることをお勧めします。
When a BFCP WebSocket client connects to a BFCP WebSocket server, it SHOULD use TCP/WSS as its transport. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, secure WebSocket (WSS) MUST be used, and the floor control server MUST authenticate the client. The WebSocket client MUST follow the procedures in [RFC7525] while setting up TLS connection with the WebSocket server. The BFCP client validates the server by means of verifying the server certificate. This means the 'websocket-uri' value MUST contain a hostname. The verification process does not use "a=fingerprint".
BFCP WebSocketクライアントがBFCP WebSocketサーバーに接続すると、TCP / WSSをトランスポートとして使用する必要があります。会議の設定に使用されたシグナリングまたは制御プロトコルトラフィックが認証され、機密保持および保護された保護されている場合は、Secure WebSocket（WSS）を使用する必要があり、Floor Controlサーバーはクライアントを認証しなければなりません。WebSocketクライアントは、WebSocketサーバーとのTLS接続を設定しながら[RFC7525]の手順に従う必要があります。BFCPクライアントは、サーバー証明書を検証することによってサーバーを検証します。つまり、 'websocket-uri'値にホスト名を含める必要があります。検証プロセスは「A = FingerPrint」を使用しません。
A floor control server that receives a message over TCP/WS can mandate the use of TCP/WSS by generating an Error message, as described in Section 13.8 of [RFC8855], with an error code with a value of 9 (Use TLS).
TCP / WSを介してメッセージを受信するFloor Controlサーバーは、[RFC8855]のセクション13.8で説明されているように、エラーコードを9の値9のエラーコードを持つ、エラーメッセージを生成することでTCP / WSSの使用を義務付けます（
Prior to sending BFCP requests, a BFCP WebSocket client connects to a BFCP WebSocket server and performs the connection handshake. As described in Section 4.1, the handshake procedure involves an HTTP GET method request from the client and a response from the server including an HTTP 101 status code.
BFCP要求を送信する前に、BFCP WebSocketクライアントはBFCP WebSocketサーバーに接続して接続ハンドシェイクを実行します。セクション4.1で説明されているように、ハンドシェイク手順は、クライアントからのHTTP GETメソッド要求と、HTTP 101のステータスコードを含むサーバーからの応答です。
In order to authorize the WebSocket connection, the BFCP WebSocket server SHOULD inspect any cookie header fields [RFC6265] present in the HTTP GET request. For many web applications, the value of such a cookie is provided by the web server once the user has authenticated themselves to the web server, which could be done by many existing mechanisms. As an alternative method, the BFCP WebSocket server could request HTTP authentication by replying to the client's GET method request with an HTTP 401 status code. The WebSocket protocol [RFC6455] covers this usage in Section 4.1:
WebSocket接続を承認するために、BFCP WebSocketサーバーはHTTP GETリクエストに存在するCookieヘッダーフィールド[RFC6265]を検査する必要があります。多くのWebアプリケーションでは、ユーザーがWebサーバーに認証された後、そのようなCookieの値はWebサーバーによって提供されます。これは多くの既存のメカニズムによって実行できます。別の方法として、BFCP WebSocketサーバは、HTTP401ステータスコードを用いてクライアントの取得方法要求に返信することによってHTTP認証を要求することができる。WebSocketプロトコル[RFC6455]はセクション4.1のこの使用法をカバーしています。
If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures; in particular, the client might perform authentication if it receives an 401 status code. The WebSocket clients are vulnerable to the attacks of basic authentication (mentioned in Section 4 of [RFC7617]) and digest authentication (mentioned in Section 5 of [RFC7616]). To overcome some of these weaknesses, WebSocket clients can use the HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in [RFC7486], for example.
サーバーから受信したステータスコードが101ではない場合、WebSocketクライアントスタックはHTTP [RFC7230]プロシージャーごとの応答を処理します。特に、クライアントは401のステータスコードを受信した場合、認証を実行することがあります。WebSocketクライアントは、基本認証の攻撃（RFC7617のセクション4）とダイジェスト認証の攻撃に対して脆弱です（[RFC7616]のセクション5で述べた）。これらの弱点のいくつかを克服するために、WebSocketクライアントは、たとえば[RFC7486]に記載されているHTTP Origin-Bound認証（HOBA）メカニズムを使用できます。
Considerations from [RFC8855], [RFC8856], and [RFC5018] apply.
[RFC8855]、[RFC8856]、[RFC5018]からの考慮事項。
BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. It is RECOMMENDED that the BFCP traffic transported over WebSocket be protected by using a Secure WebSocket connection (using TLS [RFC8446] over TCP). The security considerations in [RFC6455] apply for BFCP over WebSocket as well. The security model here is a typical webserver-client model where the client validates the server certificate and then connects to the server. Section 8 describes the authentication procedures between client and server.
BFCPは、再生と整合性の保護と機密性を提供するために、より低層のセキュリティメカニズムに依存しています。WebSocketを介して転送されたBFCPトラフィックは、セキュアWebSocket接続（TLS [RFC8446]を介してTCPを使用）で保護されることをお勧めします。[RFC6455]のセキュリティ上の考慮事項は、WebSocketを介してBFCPにも適用されます。ここでのセキュリティモデルは、クライアントがサーバー証明書を検証してサーバーに接続する典型的なWebServer-Clientモデルです。セクション8では、クライアントとサーバー間の認証手順について説明します。
When using BFCP over WebSocket, the security mechanisms defined in [RFC8855] are not used. Instead, the application is required to build and rely on the security mechanisms in [RFC6455].
WebSocketを介してBFCPを使用する場合、[RFC8855]で定義されているセキュリティメカニズムは使用されません。代わりに、アプリケーションは[RFC6455]のセキュリティメカニズムを構築して頼る必要があります。
The rest of this section analyses the threats described in Section 14 of [RFC8855] when WebSocket is used as a transport protocol for BFCP.
このセクションの他のセクションでは、WebSocketがBFCPのトランスポートプロトコルとして使用される場合、[RFC8855]のセクション14の脅威を分析します。
An attacker attempting to impersonate a floor control server is avoided by having servers accept BFCP messages over WSS only. As with any other web connection, the clients will verify the server's certificate. The BFCP WebSocket client MUST follow the procedures in [RFC7525] (including hostname verification as per Section 6.1 of [RFC7525]) while setting up a TLS connection with floor control WebSocket server.
攻撃者は、Floor Control ServerがWSSを介してのみBFCPメッセージを受け入れることで、フロアコントロールサーバーを偽装しようとしています。他のWeb接続と同様に、クライアントはサーバーの証明書を確認します。BFCP WebSocketクライアントは、Floor Control WebSocket ServerとのTLS接続を設定している間、[RFC7525]（[RFC7525]のセクション6.1のホスト名検証を含む）の手順に従う必要があります。
An attacker attempting to impersonate a floor control client is avoided by having servers accept BFCP messages over WSS only. As described in Section 10.5 of [RFC6455] the floor control server can use any client authentication mechanism and follow the steps in Section 8 of this document.
攻撃者は、フロアコントロールクライアントを偽装しようとしている攻撃者は、WSSのみを介してBFCPメッセージをBFCPメッセージを受け付けることによって回避されます。[RFC6455のセクション10.5]で説明されているように、フロアコントロールサーバーは任意のクライアント認証メカニズムを使用し、このドキュメントのセクション8のステップに従います。
Attackers may attempt to modify messages exchanged by a client and a floor control server. This can be prevented by having WSS between client and server.
攻撃者は、クライアントとフロアコントロールサーバーによって交換されたメッセージを変更しようとします。これは、クライアントとサーバー間のWSSを持つことで防ぐことができます。
An attacker trying to replay the messages is prevented by having floor control servers check that messages arriving over a given WSS connection use an authorized user ID.
メッセージを再生しようとしている攻撃者は、所与のWSS接続を介して到着したメッセージが許可されたユーザIDを使用することを確認することによって、メッセージを妨げることが防止される。
Attackers may eavesdrop on the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). In order to ensure that BFCP users are getting the level of protection that they would get using BFCP directly, applications need to have a way to control the WebSocket libraries to use encryption algorithms specified in Section 7 of [RFC8855]. Since the WebSocket API [WS-API] does not have a way to allow an application to select the encryption algorithm to be used, the protection level provided when WSS is used is limited to the underlying TLS algorithm used by the WebSocket library.
攻撃者は、フロアコントロールサーバーとクライアントとの間の機密情報へのアクセスを取得するためにネットワーク上で盗聴されて（例えば、フロア要求が拒否された理由）。BFCPユーザーがBFCPを直接使用する保護レベルを確実に取得するために、アプリケーションは[RFC8855]のセクション7で指定された暗号化アルゴリズムを使用するようにWebSocketライブラリを制御する方法を持つ必要があります。WebSocket API [WS-API]は、アプリケーションが使用される暗号化アルゴリズムを選択できるような方法ではないので、WSSが使用されるときに提供される保護レベルは、WebSocketライブラリによって使用される基になるTLSアルゴリズムに制限される。
IANA has registered the WebSocket BFCP subprotocol under the "WebSocket Subprotocol Name Registry" as follows:
IANAは次のように「WebSocketサブプロタ名レジストリ」にあるWebSocket BFCPサブプロトコルを登録しました。
Subprotocol Identifier: bfcp
サブプロトコル識別子：BFCP.
Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor Control Protocol)
サブプロトコル共通名：BFCP用WebSocketトランスポート（バイナリフロア制御プロトコル）
Subprotocol Definition: RFC 8857
サブプロトコルの定義：RFC 8857
10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto"
Values
This document defines two new values for the SDP "proto" subregistry within the "Session Description Protocol (SDP) Parameters" registry. The resulting entries are shown in Table 1:
この文書は、「セッション記述プロトコル（SDP）パラメータ」レジストリ内のSDP "Proto"サブレイストの2つの新しい値を定義します。結果のエントリを表1に示します。
+==============+===========+
| Value | Reference |
+==============+===========+
| TCP/WS/BFCP | RFC 8857 |
+--------------+-----------+
| TCP/WSS/BFCP | RFC 8857 |
+--------------+-----------+
Table 1: Values for the SDP "proto" Field
表1：SDP "Proto"フィールドの値
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <https://www.rfc-editor.org/info/rfc4145>.
[RFC4145] YON、D.およびG. Camarillo、「セッション記述プロトコル（SDP）」、RFC 4145、DOI 10.17487 / RFC4145、2005年9月、<https：//www.rfc-編集者。org / info / rfc4145>。
[RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/RFC5018, September 2007, <https://www.rfc-editor.org/info/rfc5018>.
[RFC5018] Camarillo、G.、「バイナリフロアコントロールプロトコル（BFCP）」、RFC 5018、DOI 10.17487 / RFC5018、2007年9月、<https://www.rfc-editor.org/info/rfc5018>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I.およびA.Melnikov、「WebSocketプロトコル」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https：//www.rfc-editor.org/info/rfc6455>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[RFC8124] Ravindranath, R. and G. Salgueiro, "The Session Description Protocol (SDP) WebSocket Connection URI Attribute", RFC 8124, DOI 10.17487/RFC8124, March 2017, <https://www.rfc-editor.org/info/rfc8124>.
[RFC8124] Ravindranath、R.およびG.Salgueiro、「セッション記述プロトコル（SDP）WebSocket接続URI属性」、RFC 8124、DOI 10.17487 / RFC8124、2017年3月、<https：//www.rfc-editor.org/情報/ RFC8124>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8855] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", RFC 8855, DOI 10.17487/RFC8855, January 2021, <https://www.rfc-editor.org/info/rfc8855>.
[RFC8855] Camarillo、G.、Drage、K.、Kristensen、T.、OTT、J.、およびC. Eckel、「バイナリフロアコントロールプロトコル（BFCP）」、RFC 8855、DOI 10.17487 / RFC8855、2021年1月<https://www.rfc-editor.org/info/rfc8855>。
[RFC8856] Camarillo, G., Kristensen, T., and C. Holmberg, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 8856, DOI 10.17487/RFC8856, January 2021, <https://www.rfc-editor.org/info/rfc8856>.
[RFC8856] Camarillo、G.、Kristensen、T.、およびC.Holmberg、「セッション記述プロトコル（BFCP）ストリーム（BFCP）ストリーム（BFCP）ストリーム、RFC 8856、DOI 10.17487 / RFC8856、<HTTPS）//www.rfc-editor.org/info/rfc8856>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC6265] BARTH、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<https：//www.rfc-editor.org/info/rfc6265>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, <https://www.rfc-editor.org/info/rfc7486>.
[RFC7486] Farrell、S.、Hoffman、P.、およびM. Thomas、「HTTP起点認証（HOBA）」、RFC 7486、DOI 10.17487 / RFC7486、2015年3月、<https：///www.rfc-編集者.ORG / INFO / RFC7486>。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D.、およびS.ブレーマー、「HTTPダイジェスト認証」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<https：//www.rfc-editor.org/info/rfc7616>。
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.
[RFC7617] Reschke、J.、「基本的な「HTTP認証方式」、RFC 7617、DOI 10.17487 / RFC7617、2015年9月、<https：//www.rfc-editor.org/info/rfc7617>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[WS-API] Hickson, I., Ed., "The WebSocket API", W3C Candidate Recommendation, September 2012, <https://www.w3.org/TR/2012/CR-websockets-20120920/>.
[WS-API] Hickson、I。、「WebSocket API」、W3C候補勧告、2012年9月、<https：//www.w3.org/tr/2012/cr-websockets-20120920/>。
Acknowledgements
謝辞
The authors want to thank Robert Welbourn from Acme Packet and Sergio Garcia Murillo, who made significant contributions to the first draft version of this document. This work benefited from the thorough review and constructive comments of Charles Eckel, Christer Holmberg, Paul Kyzivat, Dan Wing, and Alissa Cooper. Thanks to Bert Wijnen, Robert Sparks, and Mirja Kühlewind for their reviews and comments on this document.
著者らは、この文書の最初のドラフト版に重要な貢献をしたAcme Packet and Sergio Garcia MurilloからRobert Welbournに感謝します。この作品は、Charles Eckel、Christer Holmberg、Paul Kyzivat、Dan Wing、およびAlissa Cooperの徹底的なレビューと建設的なコメントから恩恵を受けました。Bert Wijnen、Robert Sparks、およびMirjaKühlewindのおかげでこのドキュメントのレビューやコメント。
Thanks to Spencer Dawkins, Ben Campbell, Kathleen Moriarty, Alexey Melnikov, Jari Arkko, and Stephen Farrell for their feedback and comments during IESG reviews.
Spencer Dawkins、Ben Campbell、Kathleen Moriarty、Alexey Melnikov、Jari Arkko、Stephen FarrellのおかげでIESGのレビュー中にフィードバックやコメントをお寄せいただきありがとうございます。
Authors' Addresses
著者の住所
Victor Pascual Nokia Barcelona Spain
Victor Pascal Nokia Barcelonaスペイン
Email: victor.pascual_avila@nokia.com
Antón Román Quobis Pol. Ind. A Granxa, Casa de Pedra 36475 O Porriño Spain
AntónRománQuobis Pol。ind。granxa、casa de pedra 36475Porriñoスペイン
Email: anton.roman@quobis.com
Stéphane Cazeaux Orange 42 rue des Coutures 14000 Caen France
StéphaneCazeaux Orange 42 Rue des Coutures 14000 Caen France
Email: stephane.cazeaux@orange.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Gonzalo Salgueiro Cisco Systems、Inc。7200-12キットクリークロードリサーチトライアングルパーク、NC 27709アメリカ合衆国
Email: gsalguei@cisco.com
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore 560103 Karnataka India
Ram Mohan Ravindranath Cisco Systems、Inc。Cessna Business Park Kadabesanahalli Village、Varthur Hobli、Sarjapur-Marathahalliアウターリングロードバンガロール560103カルナタカインド
Email: rmohanr@cisco.com