diff options
Diffstat (limited to 'doc/rfc/rfc5018.txt')
| -rw-r--r-- | doc/rfc/rfc5018.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5018.txt b/doc/rfc/rfc5018.txt new file mode 100644 index 0000000..c6202fd --- /dev/null +++ b/doc/rfc/rfc5018.txt @@ -0,0 +1,507 @@ + + + + + + +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 + + + If the client is provided with the floor control server's host name + instead of with its IP address, the client MUST perform a DNS lookup + in order to resolve the host name into an IP address. Clients + eventually perform an A or AAAA DNS lookup (or both) on the host + name. + + In order to translate the target to the corresponding set of IP + addresses, IPv6-only or dual-stack clients MUST use name resolution + functions that implement the Source and Destination Address Selection + algorithms specified in [RFC3484]. (On many hosts that support IPv6, + APIs like getaddrinfo() provide this functionality and subsume + existing APIs like gethostbyname().) + + The advantage of the additional complexity is that this technique + will output an ordered list of IPv6/IPv4 destination addresses based + on the relative merits of the corresponding source/destination pairs. + This will result in the selection of a preferred destination address. + However, the Source and Destination Selection algorithms of [RFC3484] + are dependent on broad operating system support and uniform + implementation of the application programming interfaces that + implement this behavior. + + 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 specification [RFC4582] describes a number of situations + when the TCP connection between a client and the floor control server + needs to be reestablished. However, that specification does not + describe the reestablishment process because this process depends on + how the connection was established in the first place. + + When the existing TCP connection is closed following the rules in + [RFC4582], the client SHOULD reestablish the connection towards the + floor control server. If a TCP connection cannot deliver a BFCP + message from the client to the floor control server and times out, + the client SHOULD reestablish the TCP connection. + + + + + + + + + +Camarillo Standards Track [Page 3] + +RFC 5018 BFCP September 2007 + + +4. TLS Usage + + [RFC4582] requires that all BFCP entities implement TLS [RFC4346] and + recommends that they use it in all their connections. TLS provides + integrity and replay protection, and optional confidentiality. The + floor control server MUST always act as the TLS server. + + A floor control server that receives a BFCP message over TCP (no TLS) + SHOULD request the use of TLS by generating an Error message with an + Error code with a value of 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 provided 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 + terminates at one of the other party's trust anchors [RFC3280]. + + A client establishing a connection 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, in order 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. Although + the use of the Common Name is existing practice, it is deprecated and + Certification Authorities are encouraged to use the subjectAltName + instead. + + Matching is performed using the matching rules specified by + [RFC3280]. If more than one identity of a given type is present in + the certificate (e.g., more than one dNSName name), a match in any + one of the set is considered acceptable. Names in Common Name fields + may contain the wildcard character *, which is considered to match + 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). + + + + + + +Camarillo Standards Track [Page 4] + +RFC 5018 BFCP September 2007 + + + If the client does not know the server's host name and contacts the + server directly using the server's IP address, the iPAddress + subjectAltName must be present in the certificate and must exactly + match the IP address known to the client. + + If the host name or IP address known to the client does not match the + identity in the certificate, user-oriented clients MUST either notify + the user (clients MAY give the user the opportunity to continue with + the connection in any case) or terminate the connection with a bad + certificate error. Automated clients MUST log the error to an + appropriate audit log (if available) and SHOULD terminate the + connection (with a bad certificate error). Automated clients MAY + provide a configuration setting that disables this check, but 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 performed using PSK-TLS [RFC4279]. + + The BFCP specification mandates support for the + TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. Additionally, clients and + servers supporting this specification MUST support the + TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite as well. + +6. Security Considerations + + Client and server authentication as specified in this document are + based on the use of TLS. Therefore, it is strongly RECOMMENDED that + TLS with non-null encryption is always used. Clients and floor + control servers MAY use other security mechanisms as long as they + provide similar security properties (i.e., replay and integrity + protection, confidentiality, and client and server authentication). + + TLS PSK simply relies on a pre-shared key without specifying the + nature of the key. In practice, such keys have two sources: text + passwords and randomly generated binary keys. When keys are derived + from passwords, TLS PSK mode is subject to offline dictionary + attacks. In DHE (Diffie-Hellman Exchange) and RSA modes, an attacker + who can mount a single man-in-the-middle attack on a client/server + pair can then mount a dictionary attack on the password. In modes + without DHE or RSA, an attacker who can record communications between + a client/server pair can mount a dictionary attack on the password. + Accordingly, it is RECOMMENDED that, where possible, clients use + certificate-based server authentication ciphersuites with password- + derived PSKs in order to defend against dictionary attacks. + + + + + +Camarillo Standards Track [Page 5] + +RFC 5018 BFCP September 2007 + + + In addition, passwords SHOULD be chosen with enough entropy to + provide some protection against dictionary attacks. Because the + entropy of text varies dramatically and is generally far less than + that of an equivalent random bitstring, no hard and fast rules about + password length are possible. However, in general passwords SHOULD + be chosen to be at least 8 characters and selected from a pool + containing both upper and lower case, numbers, and special keyboard + characters (note that an 8-character ASCII password has a maximum + entropy of 56 bits and in general far lower). FIPS PUB 112 [PUB112] + provides some guidance on the relevant issues. If possible, + passphrases are preferable to passwords. It is RECOMMENDED that + implementations support, at minimum, 16-character passwords or + passphrases. In addition, a cooperating client and server pair MAY + choose to derive the TLS PSK shared key from the passphrase via a + password-based key derivation function such as PBKDF2 [RFC2898]. + Because such key derivation functions may incorporate iteration + functions for key strengthening, they provide some additional + protection against dictionary attacks by increasing the amount of + work that the attacker must perform. + + When the keys are randomly generated and of sufficient length, + dictionary attacks are not effective because such keys are highly + unlikely to be in the attacker's dictionary. Where possible, keys + SHOULD be generated using a strong random number generator as + specified in [RFC4086]. A minimum key length of 80 bits SHOULD be + used. + + The remainder of this section analyzes some of the threats against + BFCP and how they are addressed. + + An attacker may attempt to impersonate a client (a floor participant + or a floor chair) in order to generate forged floor requests or to + grant or deny existing floor requests. Client impersonation is + avoided by using TLS. The floor control server assumes that + attackers cannot hijack TLS connections from authenticated clients. + + An attacker may attempt to impersonate a floor control server. A + successful attacker would be able to make clients think that they + hold a particular floor so that they would try to access a resource + (e.g., sending media) without having legitimate rights to access it. + Floor control server impersonation is avoided by having floor control + servers present their server certificates at TLS connection + establishment time. + + Attackers may attempt to modify messages exchanged by a client and a + floor control server. The integrity protection provided by TLS + connections prevents this attack. + + + + +Camarillo Standards Track [Page 6] + +RFC 5018 BFCP September 2007 + + + Attackers may attempt to pick messages from the network to get access + to confidential information between the floor control server and a + client (e.g., why a floor request was denied). TLS confidentiality + prevents this attack. Therefore, 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 provided + useful comments on this document. Eric Rescorla performed a detailed + security analysis of this document. + +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. + + + + + +Camarillo Standards Track [Page 7] + +RFC 5018 BFCP September 2007 + + + [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 + + + + + + + + + + + + + + + + + + + + + + + + + + +Camarillo Standards Track [Page 8] + +RFC 5018 BFCP September 2007 + + +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. + + + + + + + + + + + + +Camarillo Standards Track [Page 9] + |