idnits 2.17.1 draft-ietf-xcon-bfcp-connection-05.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 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 411. 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 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 (July 5, 2007) is 6138 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 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (Obsoleted by RFC 8856) -- Possible downref: Non-RFC (?) normative reference: ref. 'PUB112' -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 9 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: January 6, 2008 July 5, 2007 6 Connection Establishment in the Binary Floor Control Protocol (BFCP) 7 draft-ietf-xcon-bfcp-connection-05.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 January 6, 2008. 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 . . . . . . . . . . . . . . . . . . . . . 8 56 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Intellectual Property and Copyright Statements . . . . . . . . . . 10 63 1. Introduction 65 As discussed in the BFCP (Binary Floor Control Protocol) 66 specification [RFC4582], a given BFCP client needs a set of data in 67 order to establish a BFCP connection to a floor control server. 68 These data include the transport address of the server, the 69 conference 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) [RFC4566] offer/answer 76 [RFC3264] exchange between a client and a floor control server is 77 specified in RFC 4583 [RFC4583]. This document specifies how a 78 client establishes a connection to a floor control server outside the 79 context of an SDP offer/answer 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) [RFC4279] and how to authenticate 90 servers using server certificates. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. TCP Connection Establishment 100 As stated in Section 1, a given BFCP client needs a set of data in 101 order to establish a BFCP connection to a floor control server. 102 These data include the transport address of the server, the 103 conference identifier, and the user identifier. It is outside the 104 scope of this document to specify how a client obtains this 105 information. This document assumes that the client obtains this 106 information using an out-of-band method. 108 Once the client has the transport address (i.e., IP address and port) 109 of the floor control server, it initiates a TCP connection towards 110 it. That is, the client performs an active TCP open. 112 If the client is provided with the floor control server's host name 113 instead of with its IP address, the client MUST perform a DNS lookup 114 in order to resolve the host name into an IP address. Clients 115 eventually perform an A or AAAA DNS lookup (or both) on the host 116 name. 118 In order to translate the target to the corresponding set of IP 119 addresses, IPv6-only or dual-stack clients MUST use name resolution 120 functions that implement the Source and Destination Address Selection 121 algorithms specified in [RFC3484] (on many hosts that support IPv6, 122 APIs like getaddrinfo() provide this functionality and subsume 123 existing APIs like gethostbyname().) 125 The advantage of the additional complexity is that this technique 126 will output an ordered list of IPv6/IPv4 destination addresses based 127 on the relative merits of the corresponding source/destination pairs. 128 This will result in the selection of a preferred destination address. 129 However, the Source and Destination Selection algorithms of [RFC3484] 130 are dependent on broad operating system support and uniform 131 implementation of the application programming interfaces that 132 implement this behavior. 134 Developers should carefully consider the issues described by Roy 135 et al. [I-D.ietf-v6ops-onlinkassumption] with respect to address 136 resolution delays and address selection rules. For example, 137 implementations of getaddrinfo() may return address lists 138 containing IPv6 global addresses at the top of the list and IPv4 139 addresses at the bottom, even when the host is only configured 140 with an IPv6 local scope (e.g., link- local) and an IPv4 address. 141 This will, of course, introduce a delay in completing the 142 connection. 144 The BFCP specification [RFC4582] describes a number of situations 145 when the TCP connection between a client and the floor control server 146 needs to be reestablished. However, that specification does not 147 describe the reestablishment process because this process depends on 148 how the connection was established in the first place. 150 When the existing TCP connection is closed following the rules in 151 [RFC4582], the client SHOULD reestablish the connection towards the 152 floor control server. If a TCP connection cannot deliver a BFCP 153 message from the client to the floor control server and times out, 154 the client SHOULD reestablish the TCP connection. 156 4. TLS Usage 158 [RFC4582] requires that all BFCP entities implement TLS [RFC4346] and 159 recommends that they use it in all their connections. TLS provides 160 integrity and replay protection, and optional confidentiality. The 161 floor control server MUST always act as the TLS server. 163 A floor control server that receives a BFCP message over TCP (no TLS) 164 SHOULD request the use of TLS by generating an Error message with an 165 Error code with a value of 9 (Use TLS). 167 5. Authentication 169 BFCP supports client authentication based on pre-shared secrets and 170 server authentication based on server certificates. 172 5.1. Certificate-based Server Authentication 174 At TLS connection establishment, the floor control server MUST 175 present its certificate to the client. The certificate provided at 176 the TLS-level MUST either be directly signed by one of the other 177 party's trust anchors or be validated using a certification path that 178 terminates at one of the other party's trust anchors [RFC3280]. 180 A client establishing a connection to a server knows the server's 181 hostname or IP address. If the client knows the server's hostname, 182 the client MUST check it against the server's identity as presented 183 in the server's Certificate message, in order to prevent man-in-the- 184 middle attacks. 186 If a subjectAltName extension of type dNSName is present, that MUST 187 be used as the identity. Otherwise, the (most specific) Common Name 188 field in the Subject field of the certificate MUST be used. Although 189 the use of the Common Name is existing practice, it is deprecated and 190 Certification Authorities are encouraged to use the subjectAltName 191 instead. 193 Matching is performed using the matching rules specified by 194 [RFC3280]. If more than one identity of a given type is present in 195 the certificate (e.g., more than one dNSName name), a match in any 196 one of the set is considered acceptable. Names in Common Name fields 197 may contain the wildcard character *, which is considered to match 198 any single domain name component or component fragment (e.g., *.a.com 199 matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but 200 not bar.com). 202 If the client does not know the server's hostname and contacts the 203 server directly using 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 [RFC4279]. 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 simply relies on a pre-shared key without specifying the 237 nature of the key. In practice, such keys have two sources: text 238 passwords and randomly generated binary keys. When keys are derived 239 from passwords, TLS PSK mode is subject to offline dictionary 240 attacks. In DHE and RSA modes, an attacker who can mount a single 241 man-in-the-middle attack on a client/server pair can then mount a 242 dictionary attack on the password. In modes without DHE or RSA, an 243 attacker who can record communications between a client/server pair 244 can mount a dictionary attack on the password. Accordingly, it is 245 RECOMMENDED that where possible clients use certificate-based server 246 authentication ciphersuites with password-derived PSKs, in order to 247 defend against dictionary attacks. 249 In addition, passwords SHOULD be chosen with enough entropy to 250 provide some protection against dictionary attacks. Because the 251 entropy of text varies dramatically and is generally far less than 252 that of an equivalent random bitstring, no hard and fast rules about 253 password length are possible. However, in general passwords SHOULD 254 be chosen to be at least 8 characters and selected from a pool 255 containing both upper and lower case, numbers, and special keyboard 256 characters (note that an 8-character ASCII password has a maximum 257 entropy of 56 bits and in general far lower). FIPS PUB 112 [PUB112] 258 provides some guidance on the relevant issues. If possible, 259 passphrases are preferable to passwords. In addition, a cooperating 260 client and server pair MAY choose to derive the TLS PSK shared key 261 from the passphrase via a password-based key derivation function such 262 as PBKDF2 [RFC2898]. Because such key derivation functions may 263 incorporate iteration functions for key strengthening they provide 264 some additional protection against dictionary attacks by increasing 265 the amount of work that the attacker must perform. 267 When the keys are randomly generated and of sufficient length, 268 dictionary attacks are not effective because such keys are highly 269 unlikely to be in the attacker's dictionary. Where possible, keys 270 SHOULD be generated using a strong random number generator as 271 specified in [RFC4086]. A minimum key length of 80 bits SHOULD be 272 used. 274 The remainder of this Section analyzes some of the threats against 275 BFCP and how they are addressed. 277 An attacker may attempt to impersonate a client (a floor participant 278 or a floor chair) in order to generate forged floor requests or to 279 grant or deny existing floor requests. Client impersonation is 280 avoided by using TLS. The floor control server assumes that 281 attackers cannot hickjack TLS connections from authenticated clients. 283 An attacker may attempt to impersonate a floor control server. A 284 successful attacker would be able to make clients think that they 285 hold a particular floor so that they would try to access a resource 286 (e.g., sending media) without having legitimate rights to access it. 287 Floor control server impersonation is avoided by having floor control 288 servers present their server certificates at TLS connection 289 establishment time. 291 Attackers may attempt to modify messages exchanged by a client and a 292 floor control server. The integrity protection provided by TLS 293 connections prevents this attack. 295 Attackers may attempt to pick messages from the network to get access 296 to confidential information between the floor control server and a 297 client (e.g., why a floor request was denied). TLS confidentiality 298 prevents this attack. Therefore, it is RECOMMENDED that TLS is used 299 with a non-null encryption algorithm. 301 7. IANA Considerations 303 This specification does not contain any actions for the IANA. 305 8. Acknowledgments 307 Sam Hartman, David Black, Karim El Malki, and Vijay Gurbani provided 308 useful comments on this document. Eric Rescorla performed a detailed 309 security analysis of this document. 311 9. References 313 9.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 319 with Session Description Protocol (SDP)", RFC 3264, 320 June 2002. 322 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 323 X.509 Public Key Infrastructure Certificate and 324 Certificate Revocation List (CRL) Profile", RFC 3280, 325 April 2002. 327 [RFC3484] Draves, R., "Default Address Selection for Internet 328 Protocol version 6 (IPv6)", RFC 3484, February 2003. 330 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 331 Requirements for Security", BCP 106, RFC 4086, June 2005. 333 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 334 for Transport Layer Security (TLS)", RFC 4279, 335 December 2005. 337 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 338 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 340 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 341 Description Protocol", RFC 4566, July 2006. 343 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 344 Control Protocol (BFCP)", RFC 4582, November 2006. 346 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 347 for Binary Floor Control Protocol (BFCP) Streams", 348 RFC 4583, November 2006. 350 [PUB112] National Institute of Standards and Technology (NIST), 351 "Password Usage", FIPS PUB 112, May 1985. 353 9.2. Informative References 355 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 356 Specification Version 2.0", RFC 2898, September 2000. 358 [I-D.ietf-v6ops-onlinkassumption] 359 Roy, S., "IPv6 Neighbor Discovery On-Link Assumption 360 Considered Harmful", draft-ietf-v6ops-onlinkassumption-04 361 (work in progress), January 2006. 363 Author's Address 365 Gonzalo Camarillo 366 Ericsson 367 Hirsalantie 11 368 Jorvas 02420 369 Finland 371 Email: Gonzalo.Camarillo@ericsson.com 373 Full Copyright Statement 375 Copyright (C) The IETF Trust (2007). 377 This document is subject to the rights, licenses and restrictions 378 contained in BCP 78, and except as set forth therein, the authors 379 retain all their rights. 381 This document and the information contained herein are provided on an 382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 384 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 385 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 386 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 389 Intellectual Property 391 The IETF takes no position regarding the validity or scope of any 392 Intellectual Property Rights or other rights that might be claimed to 393 pertain to the implementation or use of the technology described in 394 this document or the extent to which any license under such rights 395 might or might not be available; nor does it represent that it has 396 made any independent effort to identify any such rights. Information 397 on the procedures with respect to rights in RFC documents can be 398 found in BCP 78 and BCP 79. 400 Copies of IPR disclosures made to the IETF Secretariat and any 401 assurances of licenses to be made available, or the result of an 402 attempt made to obtain a general license or permission for the use of 403 such proprietary rights by implementers or users of this 404 specification can be obtained from the IETF on-line IPR repository at 405 http://www.ietf.org/ipr. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights that may cover technology that may be required to implement 410 this standard. Please address the information to the IETF at 411 ietf-ipr@ietf.org. 413 Acknowledgment 415 Funding for the RFC Editor function is provided by the IETF 416 Administrative Support Activity (IASA).