Connection Establishment in the Binary Floor Control Protocol (BFCP)
RFC 5018
|
| Document |
Type |
|
RFC - Proposed Standard
(September 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5018 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Cullen Jennings
|
|
Send notices to |
|
(None)
|
Network Working Group G. Camarillo
Request for Comments: 5018 Ericsson
Category: Standards Track September 2007
Connection Establishment in the Binary Floor Control Protocol (BFCP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies how a Binary Floor Control Protocol (BFCP)
client establishes a connection to a BFCP floor control server
outside the context of an offer/answer exchange. Client and server
authentication are based on Transport Layer Security (TLS).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 2
4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Certificate-Based Server Authentication . . . . . . . . . . 4
5.2. Client Authentication Based on a Pre-Shared Secret . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Camarillo Standards Track [Page 1]
RFC 5018 BFCP September 2007
1. Introduction
As discussed in the BFCP (Binary Floor Control Protocol)
specification [RFC4582], a given BFCP client needs a set of data in
order to establish a BFCP connection to a floor control server.
These data include the transport address of the server, the
conference identifier, and the user identifier.
Once a client obtains this information, it needs to establish a BFCP
connection to the floor control server. The way this connection is
established depends on the context of the client and the floor
control server. How to establish such a connection in the context of
an SDP (Session Description Protocol) [RFC4566] offer/answer
[RFC3264] exchange between a client and a floor control server is
specified in RFC 4583 [RFC4583]. This document specifies how a
client establishes a connection to a floor control server outside the
context of an SDP offer/answer exchange.
BFCP entities establishing a connection outside an SDP offer/answer
exchange need different authentication mechanisms than entities using
offer/answer exchanges. This is because offer/answer exchanges
provide parties with an initial integrity-protected channel that
clients and floor control servers can use to exchange the
fingerprints of their self-signed certificates. Outside the offer/
answer model, such a channel is not typically available. This
document specifies how to authenticate clients using PSK (Pre-Shared
Key)-TLS (Transport Layer Security) [RFC4279] and how to authenticate
servers using server certificates.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. TCP Connection Establishment
As stated in Section 1, a given BFCP client needs a set of data in
order to establish a BFCP connection to a floor control server.
These data include the transport address of the server, the
conference identifier, and the user identifier. It is outside the
scope of this document to specify how a client obtains this
information. This document assumes that the client obtains this
information using an out-of-band method.
Once the client has the transport address (i.e., IP address and port)
of the floor control server, it initiates a TCP connection towards
it. That is, the client performs an active TCP open.
Camarillo Standards Track [Page 2]
RFC 5018 BFCP September 2007
Show full document text