idnits 2.17.1 draft-ietf-xcon-bfcp-connection-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 391. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2007) is 6236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2898 (ref. '2') (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3280 (ref. '4') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3484 (ref. '5') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4346 (ref. '7') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4566 (ref. '8') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4582 (ref. '9') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (ref. '10') (Obsoleted by RFC 8856) -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: September 4, 2007 March 3, 2007 6 Connection Establishment in the Binary Floor Control Protocol (BFCP) 7 draft-ietf-xcon-bfcp-connection-04.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 4, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document specifies how a Binary Floor Control Protocol (BFCP) 41 client establishes a connection to a BFCP floor control server 42 outside the context of an offer/answer exchange. Client and server 43 authentication are based on Transport Layer Security (TLS). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 3 50 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 5 52 5.1. Certificate-based Server Authentication . . . . . . . . . 5 53 5.2. Client Authentication based on a Pre-shared Secret . . . . 6 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 Intellectual Property and Copyright Statements . . . . . . . . . . 10 63 1. Introduction 65 As discussed in the BFCP (Binary Floor Control Protocol) 66 specification [9], a given BFCP client needs a set of data in order 67 to establish a BFCP connection to a floor control server. These data 68 include the transport address of the server, the conference 69 identifier, and the user identifier. 71 Once a client obtains this information, it needs to establish a BFCP 72 connection to the floor control server. The way this connection is 73 established depends on the context of the client and the floor 74 control server. How to establish such a connection in the context of 75 an SDP (Session Description Protocol) [8] offer/answer [3] exchange 76 between a client and a floor control server is specified in RFC 4583 77 [10]. This document specifies how a client establishes a connection 78 to a floor control server outside the context of an SDP offer/answer 79 exchange. 81 BFCP entities establishing a connection outside an SDP offer/answer 82 exchange need different authentication mechanisms than entities using 83 offer/answer exchanges. This is because offer/answer exchanges 84 provide parties with an initial integrity-protected channel that 85 clients and floor control servers can use to exchange the 86 fingerprints of their self-signed certificates. Outside the offer/ 87 answer model, such a channel is not typically available. This 88 document specifies how to authenticate clients using PSK (Pre-Shared 89 Key)-TLS (Transport Layer Security) [6] and how to authenticate 90 servers using server certificates. 92 2. Terminology 94 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 95 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 96 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 97 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 98 compliant implementations. 100 3. TCP Connection Establishment 102 As stated in Section 1, a given BFCP client needs a set of data in 103 order to establish a BFCP connection to a floor control server. 104 These data include the transport address of the server, the 105 conference identifier, and the user identifier. It is outside the 106 scope of this document to specify how a client obtains this 107 information. This document assumes that the client obtains this 108 information using an out-of-band method. 110 Once the client has the transport address (i.e., IP address and port) 111 of the floor control server, it initiates a TCP connection towards 112 it. That is, the client performs an active TCP open. 114 If the client is provided with the floor control server's host name 115 instead of with its IP address, the client MUST perform a DNS lookup 116 in order to resolve the host name into an IP address. Clients 117 eventually perform an A or AAAA DNS lookup (or both) on the host 118 name. 120 In order to translate the target to the corresponding set of IP 121 addresses, IPv6-only or dual-stack clients MUST use name resolution 122 functions that implement the Source and Destination Address Selection 123 algorithms specified in RFC3484 [5] (on many hosts that support IPv6, 124 APIs like getaddrinfo() provide this functionality and subsume 125 existing APIs like gethostbyname().) 127 The advantage of the additional complexity is that this technique 128 will output an ordered list of IPv6/IPv4 destination addresses based 129 on the relative merits of the corresponding source/destination pairs. 130 This will result in the selection of a preferred destination address. 131 However, the Source and Destination Selection algorithms of [5] are 132 dependent on broad operating system support and uniform 133 implementation of the application programming interfaces that 134 implement this behavior. 136 Developers should carefully consider the issues described by Roy 137 et al. [12] with respect to address resolution delays and address 138 selection rules. For example, implementations of getaddrinfo() 139 may return address lists containing IPv6 global addresses at the 140 top of the list and IPv4 addresses at the bottom, even when the 141 host is only configured with an IPv6 local scope (e.g., link- 142 local) and an IPv4 address. This will, of course, introduce a 143 delay in completing the connection. 145 The BFCP specification [9] describes a number of situations when the 146 TCP connection between a client and the floor control server needs to 147 be reestablished. However, that specification does not describe the 148 reestablishment process because this process depends on how the 149 connection was established in the first place. 151 When the existing TCP connection is closed following the rules in RFC 152 4582 [9], the client SHOULD reestablish the connection towards the 153 floor control server. If a TCP connection cannot deliver a BFCP 154 message from the client to the floor control server and times out, 155 the client SHOULD reestablish the TCP connection. 157 4. TLS Usage 159 All BFCP entities implement TLS [7] and SHOULD use it in all their 160 connections. TLS provides integrity and replay protection, and 161 optional confidentiality. The floor control server MUST always act 162 as the TLS server. 164 A floor control server that receives a BFCP message over TCP (no TLS) 165 can request the use of TLS by generating an Error message with an 166 Error code with a value of 9 (Use TLS). 168 5. Authentication 170 BFCP supports client authentication based on pre-shared secrets and 171 server authentication based on server certificates. 173 5.1. Certificate-based Server Authentication 175 At TLS connection establishment, the floor control server MUST 176 present its certificate to the client. The certificate provided at 177 the TLS-level MUST either be directly signed by one of the other 178 party's trust anchors or be validated using a certification path that 179 terminates at one of the other party's trust anchors [4]. 181 A client establishing a connection to a server knows the server's 182 hostname or IP address. If the client knows the server's hostname, 183 the client MUST check it against the server's identity as presented 184 in the server's Certificate message, in order to prevent man-in-the- 185 middle attacks. 187 If a subjectAltName extension of type dNSName is present, that MUST 188 be used as the identity. Otherwise, the (most specific) Common Name 189 field in the Subject field of the certificate MUST be used. Although 190 the use of the Common Name is existing practice, it is deprecated and 191 Certification Authorities are encouraged to use the subjectAltName 192 instead. 194 Matching is performed using the matching rules specified by RFC 3280 195 [4]. If more than one identity of a given type is present in the 196 certificate (e.g., more than one dNSName name), a match in any one of 197 the set is considered acceptable. Names in Common Name fields may 198 contain the wildcard character *, which is considered to match any 199 single domain name component or component fragment (e.g., *.a.com 200 matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but 201 not bar.com). 203 If the client knows the server's IP address, the iPAddress 204 subjectAltName must be present in the certificate and must exactly 205 match the IP address known to the client. 207 If the hostname or IP address known to the client does not match the 208 identity in the certificate, user oriented clients MUST either notify 209 the user (clients MAY give the user the opportunity to continue with 210 the connection in any case) or terminate the connection with a bad 211 certificate error. Automated clients MUST log the error to an 212 appropriate audit log (if available) and SHOULD terminate the 213 connection (with a bad certificate error). Automated clients MAY 214 provide a configuration setting that disables this check, but MUST 215 provide a setting which enables it. 217 5.2. Client Authentication based on a Pre-shared Secret 219 Client authentication is based on a pre-shared secret between client 220 and server. Authentication is performed using PSK-TLS [6]. 222 The BFCP specification mandates support for the 223 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. Additionally, clients and 224 servers supporting this specification MUST support the 225 TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite as well. 227 6. Security Considerations 229 Client and server authentication as specified in this document are 230 based on the use of TLS. Therefore, it is strongly RECOMMENDED that 231 TLS with non-null encryption is always used. Clients and floor 232 control servers MAY use other security mechanisms as long as they 233 provide similar security properties (i.e., replay and integrity 234 protection, confidentiality, and client and server authentication). 236 TLS PSK mode is subject to offline dictionary attacks. In DHE and 237 RSA modes, an attacker who can mount a single man-in-the-middle 238 attack on a client/server pair can then mount a dictionary attack on 239 the password. In modes without DHE or RSA, an attacker who can 240 record communications between a client/server pair can mount a 241 dictionary attack on the password. Accordingly, it is RECOMMENDED 242 that where possible clients use certificate-based server 243 authentication ciphersuites with PSK in order to defend against 244 dictionary attacks. 246 In addition, passwords SHOULD be chosen with enough entropy to 247 provide some protection against dictionary attacks. Because the 248 entropy of text varies dramatically and is generally far less than 249 that of an equivalent random bitstring, no hard and fast rules about 250 password length are possible. However, in general passwords SHOULD 251 be chosen to be at least 8 characters and selected from a pool 252 containing both upper and lower case, numbers, and special keyboard 253 characters (note that an 8-character ASCII password has a maximum 254 entropy of 56 bits and in general far lower). FIPS PUB 112 [11] 255 provides some guidance on the relevant issues. If possible, 256 passphrases are preferable to passwords. In addition, a cooperating 257 client and server pair MAY choose to derive the TLS PSK shared key 258 from the passphrase via a password-based key derivation function such 259 as PBKDF2 [2]. 261 The remainder of this Section analyzes some of the threats against 262 BFCP and how they are addressed. 264 An attacker may attempt to impersonate a client (a floor participant 265 or a floor chair) in order to generate forged floor requests or to 266 grant or deny existing floor requests. Client impersonation is 267 avoided by using TLS. The floor control server assumes that 268 attackers cannot hickjack TLS connections from authenticated clients. 270 An attacker may attempt to impersonate a floor control server. A 271 successful attacker would be able to make clients think that they 272 hold a particular floor so that they would try to access a resource 273 (e.g., sending media) without having legitimate rights to access it. 274 Floor control server impersonation is avoided by having floor control 275 servers present their server certificates at TLS connection 276 establishment time. 278 Attackers may attempt to modify messages exchanged by a client and a 279 floor control server. The integrity protection provided by TLS 280 connections prevents this attack. 282 Attackers may attempt to pick messages from the network to get access 283 to confidential information between the floor control server and a 284 client (e.g., why a floor request was denied). TLS confidentiality 285 prevents this attack. Therefore, it is RECOMMENDED that TLS is used 286 with a non-null encryption algorithm. 288 7. IANA Considerations 290 This specification does not contain any actions for the IANA. 292 8. Acknowledgments 294 Sam Hartman, Karim El Malki, and Vijay Gurbani provided useful 295 comments on this document. Eric Rescorla performed a detailed 296 security analysis of this document. 298 9. References 300 9.1. Normative References 302 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 303 Levels", BCP 14, RFC 2119, March 1997. 305 [2] Kaliski, B., "PKCS #5: Password-Based Cryptography 306 Specification Version 2.0", RFC 2898, September 2000. 308 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 309 Session Description Protocol (SDP)", RFC 3264, June 2002. 311 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 312 Public Key Infrastructure Certificate and Certificate 313 Revocation List (CRL) Profile", RFC 3280, April 2002. 315 [5] Draves, R., "Default Address Selection for Internet Protocol 316 version 6 (IPv6)", RFC 3484, February 2003. 318 [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 319 Transport Layer Security (TLS)", RFC 4279, December 2005. 321 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 322 Protocol Version 1.1", RFC 4346, April 2006. 324 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 325 Description Protocol", RFC 4566, July 2006. 327 [9] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 328 Protocol (BFCP)", RFC 4582, November 2006. 330 [10] Camarillo, G., "Session Description Protocol (SDP) Format for 331 Binary Floor Control Protocol (BFCP) Streams", RFC 4583, 332 November 2006. 334 [11] National Institute of Standards and Technology (NIST), 335 "Password Usage", FIPS PUB 112, May 1985. 337 9.2. Informative References 339 [12] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered 340 Harmful", draft-ietf-v6ops-onlinkassumption-04 (work in 341 progress), January 2006. 343 Author's Address 345 Gonzalo Camarillo 346 Ericsson 347 Hirsalantie 11 348 Jorvas 02420 349 Finland 351 Email: Gonzalo.Camarillo@ericsson.com 353 Full Copyright Statement 355 Copyright (C) The IETF Trust (2007). 357 This document is subject to the rights, licenses and restrictions 358 contained in BCP 78, and except as set forth therein, the authors 359 retain all their rights. 361 This document and the information contained herein are provided on an 362 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 363 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 364 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 365 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 366 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Intellectual Property 371 The IETF takes no position regarding the validity or scope of any 372 Intellectual Property Rights or other rights that might be claimed to 373 pertain to the implementation or use of the technology described in 374 this document or the extent to which any license under such rights 375 might or might not be available; nor does it represent that it has 376 made any independent effort to identify any such rights. Information 377 on the procedures with respect to rights in RFC documents can be 378 found in BCP 78 and BCP 79. 380 Copies of IPR disclosures made to the IETF Secretariat and any 381 assurances of licenses to be made available, or the result of an 382 attempt made to obtain a general license or permission for the use of 383 such proprietary rights by implementers or users of this 384 specification can be obtained from the IETF on-line IPR repository at 385 http://www.ietf.org/ipr. 387 The IETF invites any interested party to bring to its attention any 388 copyrights, patents or patent applications, or other proprietary 389 rights that may cover technology that may be required to implement 390 this standard. Please address the information to the IETF at 391 ietf-ipr@ietf.org. 393 Acknowledgment 395 Funding for the RFC Editor function is provided by the IETF 396 Administrative Support Activity (IASA).