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