of RFC 8855
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.
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 [RFC 7525
] 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".
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 RFC 8855
, with an error code with a value of 9 (Use TLS).
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.
In order to authorize the WebSocket connection, the BFCP WebSocket server SHOULD
inspect any cookie header fields [RFC 6265
] 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 [RFC 6455
] covers this usage in Section 4.1
If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC 7230] 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 RFC 7617) and digest authentication (mentioned in Section 5 of RFC 7616). To overcome some of these weaknesses, WebSocket clients can use the HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in [RFC 7486], for example.