idnits 2.17.00 (12 Aug 2021) /tmp/idnits6468/draft-ietf-bfcpbis-bfcp-websocket-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 8, 2017) is 1921 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7616' is defined on line 573, but no explicit reference was found in the text == Outdated reference: draft-ietf-bfcpbis-rfc4582bis has been published as RFC 8855 == Outdated reference: draft-ietf-bfcpbis-rfc4583bis has been published as RFC 8856 == Outdated reference: draft-ietf-bfcpbis-sdp-ws-uri has been published as RFC 8124 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPBIS Working Group V. Pascual 3 Internet-Draft Oracle 4 Intended status: Standards Track A. Roman 5 Expires: August 12, 2017 Quobis 6 S. Cazeaux 7 France Telecom Orange 8 G. Salgueiro 9 R. Ravindranath 10 Cisco 11 February 8, 2017 13 The WebSocket Protocol as a Transport for the Binary Floor Control 14 Protocol (BFCP) 15 draft-ietf-bfcpbis-bfcp-websocket-15 17 Abstract 19 The WebSocket protocol enables two-way realtime communication between 20 clients and servers. This document specifies the use of Binary Floor 21 Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a 22 reliable transport mechanism between BFCP entities in new scenarios. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 12, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 3 62 4. The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . . 4 63 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. BFCP Encoding . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Transport Reliability . . . . . . . . . . . . . . . . . . . . 5 66 6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Transport Negotiation . . . . . . . . . . . . . . . . . . 6 68 6.2. SDP Media Attributes . . . . . . . . . . . . . . . . . . 6 69 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 70 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.2. Example Usage of 'websocket-uri' SDP Attribute . . . . . 7 72 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 10 76 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 77 'proto' Values . . . . . . . . . . . . . . . . . . . . . 11 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 12.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The WebSocket(WS) [RFC6455] protocol enables two-way message exchange 87 between clients and servers on top of a persistent TCP connection, 88 optionally secured with Transport Layer Security (TLS) [RFC5246]. 89 The initial protocol handshake makes use of Hypertext Transfer 90 Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol 91 to reuse existing HTTP infrastructure. 93 The Binary Floor Control Protocol (BFCP) is a protocol to coordinate 94 access to shared resources in a conference. It is defined in 95 [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants 96 and floor control servers, and between floor chairs (i.e., 97 moderators) and floor control servers. 99 Modern web browsers include a WebSocket client stack complying with 100 the WebSocket API [WS-API] as specified by the W3C. It is expected 101 that other client applications (those running in personal computers 102 and devices such as smartphones) will also make a WebSocket client 103 stack available. This document extends the applicability of 104 [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis] to 105 enable the usage of BFCP in these scenarios. 107 The transport over which BFCP entities exchange messages depends on 108 how the clients obtain information to contact the floor control 109 server (e.g. using an Session Description Protocol (SDP) offer/answer 110 exchange per [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described 111 in RFC5018 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two 112 transports for BFCP: TCP and UDP. This specification defines a new 113 WebSocket sub-protocol (as defined in Section 1.9 in [RFC6455]) for 114 transporting BFCP messages between a WebSocket client and server. 115 This sub-protocol provides a reliable and boundary preserving 116 transport for BFCP when run on top of TCP. Since WebSocket provides 117 a reliable transport, the extensions defined in 118 [I-D.ietf-bfcpbis-rfc4582bis] for sending BFCP over unreliable 119 transports are not applicable. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2.1. Definitions 129 BFCP WebSocket Client: Any BFCP entity capable of opening outbound 130 connections to WebSocket servers and communicating using the 131 WebSocket BFCP sub-protocol as defined by this document. 133 BFCP WebSocket Server: Any BFCP entity capable of listening for 134 inbound connections from WebSocket clients and communicating 135 using the WebSocket BFCP sub-protocol as defined by this 136 document. 138 3. The WebSocket Protocol 140 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 141 (optionally secured with TLS [RFC5246]) in which both client and 142 server exchange message units in both directions. The protocol 143 defines a connection handshake, WebSocket sub-protocol and extensions 144 negotiation, a frame format for sending application and control data, 145 a masking mechanism, and status codes for indicating disconnection 146 causes. 148 The WebSocket connection handshake is based on HTTP [RFC7230] and 149 utilizes the HTTP GET method with an "Upgrade" request. This is sent 150 by the client and then answered by the server (if the negotiation 151 succeeded) with an HTTP 101 status code. Once the handshake is 152 completed the connection upgrades from HTTP to the WebSocket 153 protocol. This handshake procedure is designed to reuse the existing 154 HTTP infrastructure. During the connection handshake, client and 155 server agree on the application protocol to use on top of the 156 WebSocket transport. Such an application protocol (also known as a 157 "WebSocket sub-protocol") defines the format and semantics of the 158 messages exchanged by the endpoints. This could be a custom protocol 159 or a standardized one (as the WebSocket BFCP sub-protocol defined in 160 this document). Once the HTTP 101 response is processed both client 161 and server reuse the underlying TCP connection for sending WebSocket 162 messages and control frames to each other. Unlike plain HTTP, this 163 connection is persistent and can be used for multiple message 164 exchanges. 166 The WebSocket protocol defines message units to be used by 167 applications for the exchange of data, so it provides a message 168 boundary-preserving transport layer. 170 4. The WebSocket BFCP Sub-Protocol 172 The term WebSocket sub-protocol refers to an application-level 173 protocol layered on top of a WebSocket connection. This document 174 specifies the WebSocket BFCP sub-protocol for carrying BFCP messages 175 over a WebSocket connection. 177 4.1. Handshake 179 The BFCP WebSocket Client and BFCP WebSocket Server negotiate usage 180 of the WebSocket BFCP sub-protocol during the WebSocket handshake 181 procedure as defined in Section 1.3 of [RFC6455]. The Client MUST 182 include the value "BFCP" in the Sec-WebSocket-Protocol header in its 183 handshake request. The 101 reply from the Server MUST contain "BFCP" 184 in its corresponding Sec-WebSocket-Protocol header. 186 Below is an example of a WebSocket handshake in which the Client 187 requests the WebSocket BFCP sub-protocol support from the Server: 189 GET / HTTP/1.1 190 Host: bfcp-ws.example.com 191 Upgrade: websocket 192 Connection: Upgrade 193 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 194 Origin: http://www.example.com 195 Sec-WebSocket-Protocol: BFCP 196 Sec-WebSocket-Version: 13 198 The handshake response from the Server accepting the WebSocket BFCP 199 sub-protocol would look as follows: 201 HTTP/1.1 101 Switching Protocols 202 Upgrade: websocket 203 Connection: Upgrade 204 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 205 Sec-WebSocket-Protocol: BFCP 207 Once the negotiation has been completed, the WebSocket connection is 208 established and can be used for the transport of BFCP messages. 210 4.2. BFCP Encoding 212 BFCP messages use a TLV (Type-Length-Value) binary encoding, 213 therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be 214 transported in unfragmented binary WebSocket frames 215 (FIN:1,opcode:%x2) to exchange BFCP messages. The WebSocket frame 216 data MUST be a valid BCFP message, so the length of the payload of 217 the WebSocket frame MUST be lower than the maximum size allowed (2^16 218 +12 bytes) for a BCFP message as described in 219 [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for 220 reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be 221 followed. 223 While this specification assumes that BFCP encoding is only TLV 224 binary, future documents may define other mechanisms like JSON 225 serialization. if encoding changes a new subprotocol identifier 226 would need to be selected. 228 Each BFCP message MUST be carried within a single WebSocket message, 229 and a WebSocket message MUST NOT contain more than one BFCP message. 231 5. Transport Reliability 233 WebSocket [RFC6455] provides a reliable transport and therefore the 234 BFCP WebSocket sub-protocol defined by this document also provides 235 reliable BFCP transport. Thus, client and server transactions using 236 WebSocket for transport MUST follow the procedures for reliable 237 transports as defined in [I-D.ietf-bfcpbis-rfc4582bis] and 238 [I-D.ietf-bfcpbis-rfc4583bis]. 240 BFCP WebSocket clients cannot receive incoming WebSocket connections 241 initiated by any other peer. This means that a BFCP WebSocket client 242 MUST actively initiate a connection towards a BFCP WebSocket server. 243 The BFCP server is a will have a globally routable address and thus 244 does not require ICE as clients always initiate connections to it. 246 6. SDP Considerations 248 6.1. Transport Negotiation 250 Rules to generate an 'm' line for a BFCP stream are described in 251 [I-D.ietf-bfcpbis-rfc4583bis], Section 3 253 New values are defined for the transport field: TCP/WS/BFCP and 254 TCP/WSS/BFCP. 256 TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn 257 runs on top of TCP. 259 TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn 260 runs on top of TLS and TCP. 262 The port field is set following the rules in Section 3 and 263 Section 8.1 of [I-D.ietf-bfcpbis-rfc4583bis]. Depending on the value 264 of the SDP 'setup' attribute defined in [RFC4145], the port field 265 contains the port to which the remote endpoint will direct BFCP 266 messages or is irrelevant (i.e., the endpoint will initiate the 267 connection towards the remote endpoint) and should be set to a value 268 of 9, which is the discard port. Connection attribute and port MUST 269 follow the rules of [RFC4145] 271 While this document recommends the use of secure WebSockets (i.e.TCP/ 272 WSS) for security reasons, TCP/WS is also permitted so as to achieve 273 maximum compatibility among clients. 275 6.2. SDP Media Attributes 277 [I-D.ietf-bfcpbis-sdp-ws-uri] defines a new SDP attribute to indicate 278 the connection Uniform Resource Identifier (URI) for the WebSocket 279 Client. The SDP attribute 'websocket-uri' defined in Section 3 of 280 [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of 281 WS or WSS. When the 'websocket-uri' attribute is present in the 282 media section of the SDP, the procedures mentioned in Section 4 of 283 [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be followed. 285 7. SDP Offer/Answer Procedures 287 7.1. General 289 An endpoint (i.e., both the offerer and the answerer) MUST create an 290 SDP media description ("m=" line) for each BFCP-over-WebSocket media 291 stream and MUST assign either TCP/WSS/BFCP or TCP/WS/BFCP value to 292 the "proto" field of the "m=" line depending on whether the endpoint 293 wishes to use secure WebSocket or WebSocket. Furthermore, the server 294 side, which could be either the offerer or answerer, MUST add an 295 "a=websocket-uri" attribute in the media section depending on whether 296 it wishes to use WebSocket or secure WebSocket. This new attribute 297 MUST follow the syntax defined in [I-D.ietf-bfcpbis-sdp-ws-uri]. 298 Additionally, the SDP Offer/Answer procedures defined in Section 4 of 299 [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be followed for the "m=" line 300 associated with a BFCP-over-WebSocket media stream. 302 7.2. Example Usage of 'websocket-uri' SDP Attribute 304 The following is an example of an "m=" line for a BFCP connection. 305 In this example, the offerer sends the SDP with the "proto" field 306 having a value of TCP/WSS/BFCP * indicating that the offerer wishes 307 to use secure WebSocket as a transport for the media stream. 309 Offer (browser): 310 m=application 9 TCP/WSS/BFCP * 311 a=setup:active 312 a=connection:new 313 a=floorctrl:c-only 314 m=audio 55000 RTP/AVP 0 315 m=video 55002 RTP/AVP 31 317 Answer (server): 318 m=application 50000 TCP/WSS/BFCP * 319 a=setup:passive 320 a=connection:new 321 a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312 322 a=floorctrl:s-only 323 a=confid:4321 324 a=userid:1234 325 a=floorid:1 m-stream:10 326 a=floorid:2 m-stream:11 327 m=audio 50002 RTP/AVP 0 328 a=label:10 329 m=video 50004 RTP/AVP 31 330 a=label:11 331 It is possible that an endpoint (e.g., a browser) sends an offerless 332 INVITE to the server. In such cases the server will act as SDP 333 offerer. The server MUST assign the SDP "setup" attribute with a 334 value of "passive". The server MUST have an "a=websocket-uri" 335 attribute with a "ws-URI" or "wss-URI" value depending on whether the 336 server wishes to use WebSocket or secure WebSocket. This attribute 337 MUST follow the syntax defined in Section 3 of 338 [I-D.ietf-bfcpbis-sdp-ws-uri] . For BFCP application, the "proto" 339 value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, 340 else it MUST be TCP/WS/BFCP. 342 8. Authentication 344 Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients 345 and floor control servers SHOULD authenticate each other prior to 346 accepting messages, and RECOMMENDS that mutual TLS/DTLS 347 authentication be used. However, browser-based WebSocket clients 348 have no control over the use of TLS in the WebSocket API [WS-API], so 349 it is RECOMMENDED that standard Web-based methods for client and 350 server authentication are used, as follows. 352 When a BFCP WebSocket client connects to a BFCP WebSocket server, it 353 SHOULD use TCP/WSS as its transport. If the signaling or control 354 protocol traffic used to set up the conference is authenticated and 355 confidentiality and integrity protected, Secure WebSocket (WSS) MUST 356 be used, and the floor control server MUST authenticate the client.. 357 The WebSocket client MUST follow the procedures in [RFC7525] while 358 setting up TLS connection with the WebSocket server. The BFCP client 359 validates the server by means of verifying the server certificate. 360 This means the "websocket-uri" value MUST contain a hostname. The 361 verification process does not use a=fingerprint. 363 A floor control server that receives a message over TCP/WS can 364 mandate the use of TCP/WSS by generating an Error message, as 365 described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an 366 Error code with a value of 9 (use TLS). 368 Prior to sending BFCP requests, a BFCP WebSocket client connects to a 369 BFCP WebSocket server and performs the connection handshake. As 370 described in Section 3 the handshake procedure involves a HTTP GET 371 method request from the client and a response from the server 372 including an HTTP 101 status code. 374 In order to authorize the WebSocket connection, the BFCP WebSocket 375 server SHOULD inspect any cookie [RFC6265] headers present in the 376 HTTP GET request. For many web applications the value of such a 377 cookie is provided by the web server once the user has authenticated 378 themselves to the web server, which could be done by many existing 379 mechanisms. As an alternative method, the BFCP WebSocket Server 380 could request HTTP authentication by replying to the Client's GET 381 method request with a HTTP 401 status code. The WebSocket protocol 382 [RFC6455] covers this usage in Section 4.1: 384 If the status code received from the server is not 101, the 385 WebSocket client stack handles the response per HTTP [RFC7230] 386 procedures, in particular the client might perform authentication 387 if it receives 401 status code. 389 If the status code received from the server is not 101, the 390 WebSocket client stack handles the response per HTTP [RFC7230] 391 procedures, in particular the client might perform authentication 392 if it receives 401 status code. The WebSocket clients are 393 vulnerable to the attacks of basic authentication (mentioned in 394 Section 4 of [RFC7617]) and digest authentication (mentioned in 395 Section 5 of [RFC7616]]). To overcome some of these weakness, the 396 WebSocket clients for example can use HTTP Origin-Bound 397 Authentication (HOBA) mechanism mentioned in [RFC7486]. 399 9. Security Considerations 401 Considerations from [I-D.ietf-bfcpbis-rfc4582bis], 402 [I-D.ietf-bfcpbis-rfc4583bis] and RFC5018 [RFC5018] apply. 404 BFCP relies on lower-layer security mechanisms to provide replay and 405 integrity protection and confidentiality. It is RECOMMENDED that the 406 BFCP traffic transported over a WebSocket communication be protected 407 by using a secure WebSocket connection (using TLS [RFC5246] over 408 TCP). The security considerations in [RFC6455] apply for BFCP over 409 WebSocket as well. The security model here is a typical webserver- 410 client model where the client validates the server certificate and 411 then connects to the server. Section 8 describes the authentication 412 procedures between client and server. 414 When using BFCP over websockets, the security mechanisms defined in 415 [I-D.ietf-bfcpbis-rfc4582bis] are not used. Instead, the application 416 is required to build and rely on the security mechanisms in 417 [RFC6455]. 419 The rest of this section analyses the threats described in Section 14 420 of [I-D.ietf-bfcpbis-rfc4582bis] when WebSocket is used as transport 421 protocol for BFCP. 423 An attacker attempting to impersonate a floor control server is 424 avoided by having servers accept BFCP messages over WSS only. As 425 with any other web connection, the clients will verify the servers 426 certificate. The floor control WebSocket client MUST follow the 427 procedures in [RFC7525] (including hostname verification as per 428 Section 6.1 in [RFC7525]) while setting up TLS connection with floor 429 control webSocket server. 431 An attacker attempting to impersonate a floor control client is 432 avoided by having servers accept BFCP messages over WSS only. As 433 described in Section 10.5 of [RFC6455] the floor control server can 434 use any client authentication mechanism and follow the steps in 435 Section 8 of this document. 437 Attackers may attempt to modify messages exchanged by a client and a 438 floor control server. This can be prevented by having WSS between 439 client and server. 441 An attacker trying to replay the messages is prevented by having 442 floor control servers check that messages arriving over a given WSS 443 connection use an authorized user ID. 445 Attackers may may eavesdrop on the network to get access to 446 confidential information between the floor control server and a 447 client (e.g., why a floor request was denied). In order to ensure 448 that BFCP users are getting the level of protection that they would 449 get using the BFCP protocol directly, applications need to have a way 450 to control the websocket libraries to use encryption algorithms 451 specified in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis] . Since the 452 WebSocket API [WS-API] does not have a way to allow an application to 453 select the encryption algorithm to be used, the protection level 454 provided when WSS is used is limited to the underlying TLS algorithm 455 used by WebSocket library. 457 10. IANA Considerations 459 10.1. Registration of the WebSocket BFCP Sub-Protocol 461 This specification requests IANA to register the WebSocket BFCP sub- 462 protocol under the "WebSocket Subprotocol Name" Registry with the 463 following data: 465 Subprotocol Identifier: BFCP 467 Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor 468 Control Protocol) 470 Subprotocol Definition: RFCXXXX 472 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 473 this specification, and remove this paragraph on publication.]] 475 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' 476 Values 478 This document defines two new values for the SDP 'proto' field under 479 the Session Description Protocol (SDP) Parameters registry. The 480 resulting entries are shown in Figure 1 below: 482 Value Reference 483 ---------- ----------- 484 TCP/WS/BFCP RFCXXXX; 485 TCP/WSS/BFCP RFCXXXX; 487 Figure 1: Values for the SDP 'proto' Field 489 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 490 this specification, and remove this paragraph on publication.]] 492 11. Acknowledgements 494 The authors want to thank Robert Welbourn, from Acme Packet and 495 Sergio Garcia Murillo who made significant contributions to the first 496 version of this document. This work benefited from the thorough 497 review and constructive comments of Charles Eckel, Christer Holmberg, 498 Paul Kyzivat, Dan Wing and Alissa Cooper. Thanks to Bert Wijnen, 499 Robert Sparks and Mirja Kuehlewind for their reviews and comments on 500 this document. 502 Thanks for Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey 503 Melnikov, Jari Arkko and Stephen Farrell for their feedback and 504 comments during IESG reviews. 506 12. References 508 12.1. Normative References 510 [I-D.ietf-bfcpbis-rfc4582bis] 511 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 512 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 513 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 514 2015. 516 [I-D.ietf-bfcpbis-rfc4583bis] 517 Camarillo, G., Kristensen, T., and P. Jones, "Session 518 Description Protocol (SDP) Format for Binary Floor Control 519 Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-16 520 (work in progress), September 2016. 522 [I-D.ietf-bfcpbis-sdp-ws-uri] 523 R, R. and G. Salgueiro, "Session Description Protocol 524 (SDP) WebSocket Connection URI Attribute", draft-ietf- 525 bfcpbis-sdp-ws-uri-09 (work in progress), February 2017. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 533 the Session Description Protocol (SDP)", RFC 4145, 534 DOI 10.17487/RFC4145, September 2005, 535 . 537 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 538 Floor Control Protocol (BFCP)", RFC 5018, 539 DOI 10.17487/RFC5018, September 2007, 540 . 542 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 543 RFC 6455, DOI 10.17487/RFC6455, December 2011, 544 . 546 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 547 "Recommendations for Secure Use of Transport Layer 548 Security (TLS) and Datagram Transport Layer Security 549 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 550 2015, . 552 12.2. Informative References 554 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 555 (TLS) Protocol Version 1.2", RFC 5246, 556 DOI 10.17487/RFC5246, August 2008, 557 . 559 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 560 DOI 10.17487/RFC6265, April 2011, 561 . 563 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 564 Protocol (HTTP/1.1): Message Syntax and Routing", 565 RFC 7230, DOI 10.17487/RFC7230, June 2014, 566 . 568 [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- 569 Bound Authentication (HOBA)", RFC 7486, 570 DOI 10.17487/RFC7486, March 2015, 571 . 573 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 574 Digest Access Authentication", RFC 7616, 575 DOI 10.17487/RFC7616, September 2015, 576 . 578 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 579 RFC 7617, DOI 10.17487/RFC7617, September 2015, 580 . 582 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 584 Authors' Addresses 586 Victor Pascual 587 Oracle 589 Email: victor.pascual.avila@oracle.com 591 Anton Roman 592 Quobis 594 Email: anton.roman@quobis.com 596 Stephane Cazeaux 597 France Telecom Orange 599 Email: stephane.cazeaux@orange.com 601 Gonzalo Salgueiro 602 Cisco Systems, Inc. 603 7200-12 Kit Creek Road 604 Research Triangle Park, NC 27709 605 US 607 Email: gsalguei@cisco.com 608 Ram Mohan Ravindranath 609 Cisco Systems, Inc. 610 Cessna Business Park, 611 Kadabeesanahalli Village, Varthur Hobli, 612 Sarjapur-Marathahalli Outer Ring Road 613 Bangalore, Karnataka 560103 614 India 616 Email: rmohanr@cisco.com