ietf-corpus

rfc-5018

Connection Establishment in the Binary Floor Control Protocol (BFCP)

G. Camarillo
date2007-09 streamIETF arearai wgxcon statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc5018 doi10.17487/RFC5018
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). [STANDARDS-TRACK]

updated by

Extracted elements (18)

design-rationale §1

BFCP entities connecting outside an SDP offer/answer exchange need different authentication mechanisms because the offer/answer model provides an initial integrity-protected channel to exchange self-signed certificate fingerprints, which is not available outside that model.

tls, security, realtime

interoperability-note §1

This document specifies connection establishment outside SDP offer/answer; RFC 4583 governs connection establishment within an SDP offer/answer exchange. The two mechanisms use different authentication approaches and are not interchangeable.

realtime, sip

normative-requirement §5.1 MUST

A client that knows the server's host name MUST check it against the server's identity as presented in the server's Certificate message to prevent man-in-the-middle attacks.

tls, pkix, security

normative-requirement §4 SHOULD

A floor control server that receives a BFCP message over TCP without TLS SHOULD request TLS by generating an Error message with Error code value 9 (Use TLS).

tls, realtime

normative-requirement §5.1 MUST

At TLS connection establishment, the floor control server MUST present its certificate to the client, and the certificate MUST either be directly signed by one of the other party's trust anchors or validated via a certification path terminating at a trust anchor.

tls, pkix, security

normative-requirement §5.2 MUST

Clients and servers supporting this specification MUST support the TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite in addition to the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite mandated by the base BFCP specification.

tls, crypto

normative-requirement §5.1 MUST

If a subjectAltName extension of type dNSName is present, it MUST be used as the server identity; otherwise the most specific Common Name field in the Subject MUST be used (though Common Name use is deprecated).

tls, pkix

normative-requirement §5.1 MUST

If the client contacts the server using an IP address directly, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client.

tls, pkix, security

normative-requirement §3 MUST

If the client is provided with the floor control server's host name instead of its IP address, the client MUST perform a DNS lookup to resolve the host name into an IP address, performing A or AAAA lookups (or both).

dns, ip

normative-requirement §5.1 MUST

If the host name or IP address does not match the certificate identity, user-oriented clients MUST notify the user or terminate the connection with a bad certificate error; automated clients MUST log the error and SHOULD terminate the connection.

tls, pkix, security

normative-requirement §3 MUST

IPv6-only or dual-stack clients MUST use name resolution functions that implement the Source and Destination Address Selection algorithms specified in RFC 3484 when translating a target to a set of IP addresses.

ip, v6ops

normative-requirement §4 MUST

The floor control server MUST always act as the TLS server in BFCP connections.

tls, realtime

normative-requirement §3 SHOULD

When an existing TCP connection is closed following RFC 4582 rules, the client SHOULD reestablish the connection towards the floor control server. If a TCP connection times out, the client SHOULD reestablish the TCP connection.

tcp, realtime

protocol-element §3

BFCP connection establishment outside SDP offer/answer requires three pieces of data obtained out-of-band: the transport address (IP address and port) of the floor control server, the conference identifier, and the user identifier.

realtime

protocol-element §5

Client authentication is performed using PSK-TLS (RFC 4279) based on a pre-shared secret between client and server. Server authentication uses certificate-based TLS.

tls, crypto, security

security-consideration §6

Client impersonation is mitigated by TLS (floor control server assumes attackers cannot hijack authenticated TLS connections); server impersonation is mitigated by requiring servers to present certificates at TLS connection establishment; message tampering is prevented by TLS integrity protection; eavesdropping is mitigated by TLS confidentiality.

tls, security

security-consideration §6

Passwords used for PSK SHOULD be at least 8 characters from a pool including upper/lower case, numbers, and special characters. Implementations MUST support at minimum 16-character passwords or passphrases. Randomly generated keys SHOULD be at least 80 bits and generated using a strong random number generator (RFC 4086).

security, crypto

security-consideration §6

TLS with non-null encryption is strongly RECOMMENDED for all BFCP connections. TLS PSK with password-derived keys is subject to offline dictionary attacks; it is RECOMMENDED that clients use certificate-based server authentication ciphersuites with password-derived PSKs to defend against such attacks.

tls, crypto, security