XCON Working Group G. Camarillo Internet-Draft Ericsson Expires:
July 16,September 4, 2007 January 12,March 3, 2007 Connection Establishment in the Binary Floor Control Protocol (BFCP) draft-ietf-xcon-bfcp-connection-03.txtdraft-ietf-xcon-bfcp-connection-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 16,September 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 3 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Certificate-based Server Authentication . . . . . . . . . 5 5.2. Client Authentication based on a Pre-shared Secret . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 98 Intellectual Property and Copyright Statements . . . . . . . . . . 10 1. Introduction As discussed in the BFCP (Binary Floor Control Protocol) specification ,, 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)  offer/answer  exchange between a client and a floor control server is specified in RFC 4583 .. 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)  and how to authenticate servers using server certificates. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119  and indicate requirement levels for compliant implementations. 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. 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 guarantee optimal routing.result in the selection of a preferred destination address. However, the Source and Destination Selection algorithms of  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.  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  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 RFC 4582 ,, 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. 4. TLS Usage All BFCP entities implement TLS  and SHOULD 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) can 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 .. A client establishing a connection to a server knows the server's hostname or IP address. If the client knows the server's hostname, 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 dNSNamesubjectAltName instead. Matching is performed using the matching rules specified by RFC 2459 .3280 . If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name,name), a match in any one of the set is considered acceptable).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). If the client knows 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 hostname 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 which 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 .. 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 mode is subject to offline dictionary attacks. In DHE 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 PSK in order to defend against dictionary attacks. 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  provides some guidance on the relevant issues. If possible, passphrases are preferable to passwords. 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 .. 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 hickjack 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. 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. IANA Considerations This specification does not contain any actions for the IANA. 8. Acknowledgments Sam Hartman, Karim El Malki, and Vijay Gurbani provided useful comments on this document. Eric Rescorla performed a detailed security analysis of this document. 9. References 9.1. Normative References  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.  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.  Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.  Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.  National Institute of Standards and Technology (NIST), "Password Usage", FIPS PUB 112, May 1985. 9.2. Informative References  Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", draft-ietf-v6ops-onlinkassumption-04 (work in progress), January 2006. 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 firstname.lastname@example.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).