RFC 5018

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

okay bestie, this is RFC 5018 💖 written by G. Camarillo from Ericsson and dated September 2007. It's a Standards Track doc, which means it's an official Internet standards protocol spec 👑. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

---

Status of This Memo 📜

okay so this one is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Abstract 🌸

this doc explains how a Binary Floor Control Protocol (BFCP) client connects to a BFCP floor control server outside the context of an offer/answer exchange 🦋. Client and server authentication are both 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

1. Introduction 🧚

okay so the BFCP spec [RFC4582] says a BFCP client needs a set of data before it can connect to a floor control server 💅. That data includes the server's transport address, the conference identifier, and the user identifier 🍓.

once a client has that info, it needs to actually set up the BFCP connection to the floor control server 🌷. How that happens depends on the context of the client and the server. If it's happening inside an SDP (Session Description Protocol) [RFC4566] offer/answer [RFC3264] exchange between a client and a floor control server, that's covered in RFC 4583 [RFC4583] ✨. This document is about the other case: how a client connects to a floor control server outside the SDP offer/answer exchange 🦋.

BFCP entities that connect outside an SDP offer/answer exchange need different authentication mechanisms than the ones used in offer/answer exchanges 😭. The reason is that offer/answer exchanges give parties an initial integrity-protected channel they can use to swap the fingerprints of their self-signed certificates 🔥. Outside that model, that kind of channel usually isn't available 🙈. So this doc explains how to authenticate clients with PSK (Pre-Shared Key)-TLS (Transport Layer Security) [RFC4279] and how to authenticate servers with 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 🦋

so, like Section 1 said, a BFCP client needs a set of data to connect to a floor control server 💖. That's the server's transport address, the conference identifier, and the user identifier. This doc does not cover how a client gets that info, since that's out of scope 🙈. It assumes the client gets it through some out-of-band method 🫶.

once the client has the transport address (IP address and port) of the floor control server, it starts a TCP connection to it 🌸. In other words, the client does an active TCP open ✨.

if the client gets 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 🔍. Clients eventually do an A or AAAA DNS lookup (or both) on the host name 💅.

to turn the target into its matching set of IP addresses, IPv6-only or dual-stack clients MUST use name resolution functions that implement the Source and Destination Address Selection algorithms from [RFC3484] 👑. (On a lot of IPv6-capable hosts, APIs like getaddrinfo() provide this and cover existing APIs like gethostbyname() 🧚.)

the benefit of all that extra complexity is that this technique outputs an ordered list of IPv6/IPv4 destination addresses, ranked by how good each source/destination pair is 🌈. That means you end up picking a preferred destination address ⭐. The catch is that the Source and Destination Selection algorithms of [RFC3484] depend on broad OS support and on APIs that implement this behavior in the same way everywhere 🙈.

Developers should carefully consider the issues described by Roy et al. [RFC4943] with respect to address resolution delays and address selection rules. For example, implementations of getaddrinfo() may return address lists containing IPv6 global addresses at the top of the list and IPv4 addresses at the bottom, even when the host is only configured with an IPv6 local scope (e.g., link-local) and an IPv4 address. This will, of course, introduce a delay in completing the connection.

the BFCP spec [RFC4582] lists a bunch of situations where the TCP connection between a client and the floor control server needs to be re-established 🔁. It doesn't describe how to do the re-establishing, though, because that process depends on how the connection was set up in the first place 🤷‍♀️.

when the existing TCP connection gets closed under the rules in [RFC4582], the client SHOULD reestablish the connection to the floor control server 🔄. And if a TCP connection can't deliver a BFCP message from the client to the floor control server and times out, the client SHOULD reestablish the TCP connection 💫.

4. TLS Usage 🔐

[RFC4582] says all BFCP entities MUST implement TLS [RFC4346] and recommends they use it on all their connections 💜. TLS gives you integrity and replay protection, plus optional confidentiality ✨. The floor control server MUST always act as the TLS server 👑.

if a floor control server gets a BFCP message over plain TCP (no TLS), it SHOULD ask for TLS by sending an Error message with an Error code of value 9 (Use TLS) 🙋‍♀️.

5. Authentication 🎀

BFCP supports client authentication based on pre-shared secrets and server authentication based on server certificates 💖.

5.1. Certificate-Based Server Authentication 🪪

at TLS connection establishment, the floor control server MUST present its certificate to the client 📜. The certificate given at the TLS level MUST either be directly signed by one of the other party's trust anchors, or be validated using a certification path that ends at one of the other party's trust anchors [RFC3280] 🔗.

a client connecting to a server knows the server's host name or IP address 🌐. If the client knows the server's host name, the client MUST check it against the server's identity as presented in the server's Certificate message, to prevent man-in-the-middle attacks 🛡️.

if a subjectAltName extension of type dNSName is present, that MUST be used as the identity 🏷️. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used 🏷️. Using the Common Name is existing practice, but it's deprecated, and Certification Authorities are encouraged to use subjectAltName instead 📣.

matching uses the rules in [RFC3280] 📏. If more than one identity of a given type is in the certificate (e.g., more than one dNSName), a match on any one of them is acceptable ✅. Names in Common Name fields may contain the wildcard character *, which matches any single domain name component or component fragment (e.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com) 🃏.

if the client doesn't know the server's host name and connects to the server directly by IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address the client knows 🌟.

if the host name or IP address the client knows doesn't match the identity in the certificate, user-oriented clients MUST either notify the user (clients MAY give the user the chance to continue with the connection anyway) or terminate the connection with a bad certificate error 🙋‍♀️. Automated clients MUST log the error to an appropriate audit log (if one is available), and SHOULD terminate the connection (with a bad certificate error) 🤖. Automated clients MAY provide a configuration setting that disables this check, but they MUST provide a setting that enables it ⚙️.

5.2. Client Authentication Based on a Pre-Shared Secret 🗝️

client authentication is based on a pre-shared secret between client and server 💜. Authentication is done using PSK-TLS [RFC4279] ✨.

the BFCP spec mandates support for the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite 🔐. On top of that, clients and servers that support this spec MUST also support the TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite 💅.

6. Security Considerations 🔐💅

okay bestie, this section is the big one and it is NOT playing around 😭 the whole thing is built on TLS, so it is strongly RECOMMENDED that TLS with non-null encryption is always used 🎀. clients and floor control servers MAY use other security mechanisms too, as long as those give you similar security properties: replay and integrity protection, confidentiality, and client and server authentication. that is the vibe check 💜

TLS PSK just leans on a pre-shared key and doesn't say what the key actually is 🤷‍♀️. in real life there are two sources: text passwords and randomly generated binary keys. if your key comes from a password, PSK mode is open to offline dictionary attacks 💀. in DHE and RSA modes, an attacker who pulls off one man-in-the-middle attack on a client/server pair can then go after the password with a dictionary attack. in modes without DHE or RSA, an attacker who just records the communication between a client/server pair can run that dictionary attack. so, where possible, clients SHOULD... no wait, RECOMMENDED that clients use certificate-based server authentication ciphersuites together with password-derived PSKs to defend against dictionary attacks 🛡️✨

passwords also SHOULD be chosen with enough entropy to offer some protection against dictionary attacks 🧠. text entropy varies a LOT and is usually way lower than an equivalent random bitstring, so there are no hard and fast rules about password length 🙃. still, in general passwords SHOULD be at least 8 characters and drawn from a pool with upper and lower case, numbers, and special keyboard characters. heads up: an 8-character ASCII password has a maximum entropy of 56 bits and usually way less 😬. FIPS PUB 112 [PUB112] has some guidance on this stuff. if you can, passphrases are better than passwords 🌸. it is RECOMMENDED that implementations support, at minimum, 16-character passwords or passphrases. and a cooperating client and server pair MAY derive the TLS PSK shared key from the passphrase using a password-based key derivation function such as PBKDF2 [RFC2898]. those KDFs can use iteration for key strengthening, so they add a bit more protection against dictionary attacks by making the attacker do more work 💪

when the keys are randomly generated and long enough, dictionary attacks don't really work, because those keys are super unlikely to be in the attacker's dictionary 🦋. where possible, keys SHOULD be generated with a strong random number generator as specified in [RFC4086]. and a minimum key length of 80 bits SHOULD be used 🔑.

the rest of this section is a threat analysis of BFCP and how each threat gets handled 🕵️‍♀️✨

an attacker might try to impersonate a client (a floor participant or a floor chair) so they can send forged floor requests or grant or deny existing ones 😤. client impersonation is avoided by using TLS. the floor control server assumes attackers can't hijack TLS connections from authenticated clients 🙅‍♀️.

an attacker might also try to impersonate a floor control server 👀. a successful attacker could make clients think they hold a particular floor, so they'd go access a resource (like sending media) without actually having the rights 😭. floor control server impersonation is avoided by having floor control servers present their server certificates when the TLS connection is set up 📜.

attackers might try to modify messages between a client and a floor control server 🧌. the integrity protection from TLS connections stops that 💖.

attackers might try to pick messages off the network to get confidential info between the floor control server and a client, like why a floor request got denied 👂. TLS confidentiality stops that. so it is RECOMMENDED that TLS is used with a non-null encryption algorithm 🫶✨

---

7. Acknowledgments 🌷

Sam Hartman, David Black, Karim El Malki, and Vijay Gurbani gave useful comments on this document 🙌. Eric Rescorla did a detailed security analysis of it, iconic behavior 👑.

8. References 📚

8.1. Normative References

• [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3264]: Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
• [RFC3280]: Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
• [RFC3484]: Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
• [RFC4086]: Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
• [RFC4279]: Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
• [RFC4346]: Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
• [RFC4566]: Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
• [RFC4582]: Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
• [RFC4583]: Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
• [PUB112]: National Institute of Standards and Technology (NIST), "Password Usage", FIPS PUB 112, May 1985.

8.2. Informative References

• [RFC2898]: Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
• [RFC4943]: Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007.

Author's Address

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

EMail: Gonzalo.Camarillo@ericsson.com

Full Copyright Statement

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.