datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

Connection Establishment in the Binary Floor Control Protocol (BFCP)
RFC 5018

Document type: RFC - Proposed Standard (September 2007)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5018 (Proposed Standard)
Responsible AD: Cullen Jennings
Send notices to: xcon-chairs@tools.ietf.org, Gonzalo.Camarillo@ericsson.com

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

[include full document text]