idnits 2.17.1 draft-ietf-xcon-bfcp-connection-01.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 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 571. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (June 23, 2006) is 6516 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) -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 481 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '1') ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3280 (ref. '5') (Obsoleted by RFC 5280) Summary: 6 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: December 25, 2006 June 23, 2006 5 Connection Establishment in the Binary Floor Control Protocol (BFCP) 6 draft-ietf-xcon-bfcp-connection-01.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 December 25, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 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. This document also 42 specifies a digest authentication mechanism for BFCP based on shared 43 secrets. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 3 50 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 4 52 5.1. Certificate-based Mutual Authentication . . . . . . . . . 4 53 5.2. Digest-based Client Authentication . . . . . . . . . . . . 5 54 5.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 5 55 5.2.2. Floor Control Server Behavior . . . . . . . . . . . . 6 56 5.3. Attribute Definitions . . . . . . . . . . . . . . . . . . 7 57 5.3.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5.3.2. DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.4. Error Code Definitions . . . . . . . . . . . . . . . . . . 9 60 5.5. Security Considerations . . . . . . . . . . . . . . . . . 9 61 5.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 62 5.6.1. Attribute Registration . . . . . . . . . . . . . . . . 11 63 5.6.2. Error Code Registration . . . . . . . . . . . . . . . 11 64 5.6.3. Digest Algorithm Subregistry . . . . . . . . . . . . . 11 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 Intellectual Property and Copyright Statements . . . . . . . . . . 14 70 1. Introduction 72 As discussed in the BFCP (Binary Floor Control Protocol) 73 specification [6], a given BFCP client needs a set of data in order 74 to establish a BFCP connection to a floor control server. These data 75 include the transport address of the server, the conference 76 identifier, and the user identifier. 78 Once a client obtains this information, it needs to establish a BFCP 79 connection to the floor control server. The way this connection is 80 established depends on the context of the client and the floor 81 control server. How to establish such a connection in the context of 82 an offer/answer [4] exchange between a client and a floor control 83 server is specified in [7]. This document specifies how a client 84 establishes a connection to a floor control server outside the 85 context of an offer/answer exchange. 87 BFCP entities establishing a connection outside an offer/answer 88 exchange need different authentication mechanisms than entities using 89 offer/answer exchanges. This is because offer/answer exchanges 90 provide parties with an initial integrity-protected channel that 91 clients and floor control servers can use to exchange the 92 fingerprints of their self-signed certificates. Outside the offer/ 93 answer model, such a channel is not typically available. This 94 document defines a digest mechanism for BFCP that is based on shared 95 secrets. 97 2. Terminology 99 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 100 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 101 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 102 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 103 compliant implementations. 105 3. TCP Connection Establishment 107 A given BFCP client needs a set of data in order to establish a BFCP 108 connection to a floor control server. These data include the 109 transport address of the server, the conference identifier, and the 110 user identifier. It is outside the scope of this document to specify 111 how a client obtains this information. This document assumes that 112 the client obtains this information using an out-of-band method. 114 Once the client has the transport address of the floor control 115 server, it initiates a TCP connection towards it. That is, the 116 client performs an active TCP open. 118 OPEN ISSUE: do we want to define DNS procedures here? If so, do we 119 want to define SRV procedures or are A and AAAA RRs enough? 121 The BFCP specification [6] describes a number of situations when the 122 TCP connection between a client and the floor control server needs to 123 be reestablished. However, that specification does not describe the 124 reestablishment process because this process depends on how the 125 connection was established in the first place. 127 When the existing TCP connection is reseted following the rules in 128 [6], the client SHOULD reestablish the connection towards the floor 129 control server. If a TCP connection cannot deliver a BFCP message 130 from the client to the floor control server and times out, the client 131 SHOULD reestablish the TCP connection. 133 OPEN ISSUE: do we want to have floor control servers reestablish 134 connections as well? 136 4. TLS Usage 138 All BFCP entities implement TLS and SHOULD use it in all their 139 connections. TLS provides integrity and replay protection, and 140 optional confidentiality. The floor control server MUST always act 141 as the TLS server. 143 A floor control server that receives a BFCP message over TCP (no TLS) 144 can request the use of TLS by generating an Error message with an 145 Error code with a value of 9 (Use TLS) 147 5. Authentication 149 BFCP supports certificate-based mutual authentication between clients 150 and floor control servers, as specified in Section 5.1. 151 Additionally, BFCP also provides a digest mechanism based on a shared 152 secret to provide client authentication for clients without 153 certificates. This digest mechanism is described in Section 5.2. 155 5.1. Certificate-based Mutual Authentication 157 At TLS connection establishment, the floor control server MUST 158 present its certificate to the client. Clients with certificates 159 SHOULD also present their certificates to the floor control server. 161 The certificates provided at the TLS-level MUST either be directly 162 signed by one of the other party's trust anchors or be validated 163 using a certification path that terminates at one of the other 164 party's trust anchors [5]. 166 5.2. Digest-based Client Authentication 168 Clients without certificates can authenticate themselves to the floor 169 control servers using a digest-based mechanism instead. BFCP 170 supports digest-based client authentication based on a shared secret 171 between a client and the floor control server. The floor control 172 server of a conference shares a secret with each of the participants 173 in the conference and can request them to sign their messages using 174 that shared secret. Consequently, there is a need for a mechanism to 175 generate such a shared secret. However, such mechanism is outside 176 the scope of this document. This document assumes that shared 177 secrets are generated and exchanged using out-of-band means. 179 Digest-based client authentication in BFCP is based on the DIGEST 180 attribute, which is defined in Section 5.3.2. This attribute, which 181 always appears as the last attribute in a message, contains an 182 algorithm identifier and a keyed digest of the BFCP message using 183 that algorithm. The text used as input to the digest algorithm is 184 the BFCP message, including the common header, up to and including 185 the attribute preceding the DIGEST attribute. Depending on the 186 algorithm, this text may need to be padded with zeroes. 187 Section 5.3.2 lists the algorithms specified in BFCP. 189 The key used as input to the keyed digest is the secret shared 190 between the server and the user identified by the User ID in the 191 common header of the message. 193 Section 5.2.1 and Section 5.2.2 discuss how to achieve client 194 authentication using the DIGEST attribute. 196 5.2.1. Client Behavior 198 To achieve client authentication, a client needs to prove to the 199 floor control server that the client can produce a DIGEST attribute 200 for a message using their shared secret and that the message is fresh 201 (to avoid replay attacks). Clients prove the freshness of a message 202 by including a NONCE attribute in the message. 204 Clients can obtain the digest algorithms supported by the floor 205 control server in an Error response from the floor control server 206 with Error Code 10 (DIGEST Attribute Required). A client SHOULD use 207 the first digest algorithm in the list that it supports. 209 The nonce to be placed in the NONCE attribute by the client is 210 typically provided by the floor control server in an Error response 211 -- typically with Error Code 10 (DIGEST Attribute Required) or 6 212 (Invalid Nonce). If a client generates a message without a DIGEST 213 attribute and receives an Error response with Error Code 10 (DIGEST 214 Attribute Required), the client SHOULD re-send the message with a 215 DIGEST attribute and a NONCE attribute with the nonce received in the 216 Error response. 218 If after sending a message with a DIGEST attribute, a client receives 219 an Error response with Error Code 11 (Invalid Nonce), the client 220 SHOULD re-send the message using the new nonce received in the Error 221 response. If the Error Code is 12 (Authentication Failed) instead, 222 the client MUST NOT send further messages to the floor control server 223 until it has obtained a different (hopefully valid) shared secret 224 than the one used in the original message. 226 If a client receives a nonce in a message from the floor control 227 server, the client SHOULD add a NONCE attribute with this nonce and a 228 DIGEST attribute to its next message to the floor control server. 230 5.2.2. Floor Control Server Behavior 232 If the floor control server receives a message without DIGEST 233 attribute from an unauthenticated client, the floor control server 234 responds with an Error message with Error Code 10 (DIGEST Attribute 235 Required). The floor control message MUST include a list with the 236 digest algorithms supported by the floor control server in order of 237 preference (i.e., the first algorithm is the most preferred) and a 238 NONCE attribute with a nonce value that is unguessable by attackers. 240 When a floor control server receives a BFCP message with a DIGEST 241 attribute, it checks whether the Algorithm identifier in the DIGEST 242 attribute corresponds to an algorithm that is supported by the floor 243 control server. If it does not, the floor control server SHOULD 244 return an Error message with Error Code 10 (DIGEST Attribute 245 Required) with a list with the digest algorithms supported by the 246 floor control server. 248 If the algorithm identifier is valid, the floor control server checks 249 whether the NONCE attribute carries a nonce which was generated by 250 the floor control server for this client and which still has not 251 expired. If the nonce is not valid, authentication is considered to 252 have failed, in which case the floor control server SHOULD return an 253 Error message with Error Code 11 (Invalid Nonce) with a new nonce in 254 a NONCE attribute. 256 If the nonce is valid, the floor control server calculates the keyed 257 digest of the message using the algorithm identified by the DIGEST 258 attribute. The key used as input to the keyed digest is the secret 259 shared between the server and the user identified by the User ID in 260 the common header of the message. If the resulting value is the same 261 as the one in the DIGEST attribute, authentication is considered 262 successful. 264 If the resulting value is different than the one in the DIGEST 265 attribute, authentication is considered to have failed, in which case 266 the server SHOULD return an Error message with Error Code 12 267 (Authentication Failed). Messages from a client that cannot be 268 authenticated MUST NOT be processed further. 270 Floor control servers MAY include a NONCE attribute in their 271 responses to provide the nonce to be used in the next message by the 272 client. However, when TLS is used, floor control servers typically 273 authenticate only the first message sent over the TLS connection. 275 OPEN ISSUE: do we want to state that servers typically authenticate 276 only the first message sent over the TLS connection? 278 5.3. Attribute Definitions 280 The following new attribute types are defined: 282 +------+-----------+-------------+ 283 | Type | Attribute | Format | 284 +------+-----------+-------------+ 285 | 17 | NONCE | Unsigned16 | 286 | 18 | DIGEST | OctetString | 287 +------+-----------+-------------+ 289 Table 1: BFCP attributes 291 Both are EXTENSION-ATTRIBUTES are specified in [6]. 293 5.3.1. NONCE 295 The NONCE attribute can appear in any message. The following is the 296 format of the NONCE attribute. 298 0 1 2 3 299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |0 0 1 0 0 0 1|M|0 0 0 0 0 1 0 0| Nonce Value | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 1: NONCE format 305 Nonce Value: this 16-bit field contains a nonce. 307 5.3.2. DIGEST 309 The DIGEST attribute can only appear in messages sent by clients. 310 The DIGEST attribute MUST be the last attribute of the message in 311 which it appears. The following is the format of the DIGEST 312 attribute. 314 0 1 2 3 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |0 0 1 0 0 1 0|M|0 0 0 1 1 0 0 0| Algorithm | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 319 | | 320 | | 321 | | 322 / Digest / 323 / / 324 | | 325 | | 326 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | Padding | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 2: DIGEST format 332 Algorithm: this 8-bit field contains the identifier of the algorithm 333 used to calculate the keyed digest. The following are the algorithm 334 identifiers defined: 336 +------------+-----------+---------------+--------------+ 337 | Identifier | Algorithm | Digest Length | Reference | 338 +------------+-----------+---------------+--------------+ 339 | 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] | 340 +------------+-----------+---------------+--------------+ 342 Table 2: Digest algorithms 344 The text used as input to the digest algorithm is the BFCP 345 message, including the common header, up to and including the 346 attribute preceding the DIGEST attribute. Depending on the 347 algorithm, this text may need to be padded with zeroes. When 348 HMAC-SHA1 is used, the input text needs to be padded so as to be a 349 multiple of 64 bytes. 351 The key used as input to the keyed digest is the secret shared 352 between the server and the user identified by the User ID in the 353 common header of the message. 355 Digest: this field contains a keyed digest of the BFCP message. Its 356 calculation is described in Section 5.2. 358 Padding: padding added so that the contents of the DIGEST attribute 359 is 32-bit aligned. The Padding bits SHOULD be set to zero by the 360 sender and MUST be ignored by the receiver. 362 5.4. Error Code Definitions 364 +-------+---------------------------+ 365 | Value | Meaning | 366 +-------+---------------------------+ 367 | 10 | DIGEST Attribute Required | 368 | 11 | Invalid Nonce | 369 | 12 | Authentication Failed | 370 +-------+---------------------------+ 372 Table 3: Error Code meaning 374 The following is the definition of Error Specific Details for Error 375 Code 10 (DIGEST Attribute Needed) 377 0 1 2 3 378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | Algorithm ID | Algorithm ID | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Algorithm ID | Algorithm ID | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 3: Digest algorithms format 391 Algorithm ID: these 8-bit fields contain the identifiers of the 392 digest algorithms supported by the floor control server in order of 393 preference (i.e., the first algorithm is the most preferred). 395 5.5. Security Considerations 397 BFCP can use TLS or message signatures to provide client 398 authentication. Floor control server authentication is based on TLS, 399 which also provides replay and integrity protection, and 400 confidentiality. It is RECOMMENDED that TLS with non-null encryption 401 is always used and that the first message from an unauthenticated 402 client over a given TLS connection is signed using the DIGEST 403 attribute. Clients and floor control servers MAY use other security 404 mechanisms as long as they provide similar security properties. 406 OPEN ISSUE: same as before. Do we want to say that we recommend to 407 sign only the first message over a TLS connection? 409 The remainder of this Section analyzes some of the threats against 410 BFCP and how they are addressed. 412 An attacker may attempt to impersonate a client (a floor participant 413 or a floor chair) in order to generate forged floor requests or to 414 grant or deny existing floor requests. Client impersonation is 415 avoided by having clients sign their messages. A nonce is included 416 in the signature to ensure the freshness of the message. If the 417 client is using a TLS connection to communicate with the floor 418 control server, it is enough that the client signs its first message 419 over the TLS connection. The floor control server assumes that 420 attackers cannot hickjack the TLS connection and, therefore, that 421 subsequent messages over the TLS connection come from the client that 422 was initially authenticated. If TLS-based client authentication is 423 used, there is not need for the client to sign BFCP messages over the 424 connection. 426 An attacker may attempt to impersonate a floor control server. A 427 successful attacker would be able to make clients think that they 428 hold a particular floor so that they would try to access a resource 429 (e.g., sending media) without having legitimate rights to access it. 430 Floor control server impersonation is avoided by having floor control 431 servers present their server certificates at TLS connection 432 establishment time. 434 Attackers may attempt to modify messages exchanged by a client and a 435 floor control server. The integrity protection provided by TLS 436 connections prevents this attack. 438 An attacker may attempt to fetch a valid message sent by a client to 439 a floor control server and replay it at a later point. If the 440 message was signed, the attacker may attempt to establish a new TLS 441 connection with the floor control server and replay the message over 442 the new connection. Using TLS confidentiality prevents this attack 443 because the attacker cannot access the contents of the message in the 444 first place. Additionally, TLS provides replay protection for a 445 given connection. Therefore, it is strongly RECOMMENDED that TLS is 446 used with a non-null encryption algorithm. 448 Attackers may attempt to pick messages from the network to get access 449 to confidential information between the floor control server and a 450 client (e.g., why a floor request was denied). TLS confidentiality 451 prevents this attack. 453 5.6. IANA Considerations 455 The following sections instruct the IANA to perform a set of actions. 457 5.6.1. Attribute Registration 459 The IANA is instructed to register the following new values under the 460 Attribute subregistry under the BFCP Parameters registry. 462 +------+-----------+------------+ 463 | Type | Attribute | Reference | 464 +------+-----------+------------+ 465 | 17 | NONCE | [RFC XXXX] | 466 | 18 | DIGEST | [RFC XXXX] | 467 +------+-----------+------------+ 469 Table 4: New values of the BFCP Attribute subregistry 471 5.6.2. Error Code Registration 473 The IANA is instructed to register the following new values under the 474 Error Code subregistry under the BFCP Parameters registry. 476 +-------+---------------------------+------------+ 477 | Value | Meaning | Reference | 478 +-------+---------------------------+------------+ 479 | 10 | DIGEST Attribute Required | [RFC XXXX] | 480 | 11 | Invalid Nonce | [RFC XXXX] | 481 | 12 | Authentication Failed | [RFC XXXX] | 482 +-------+---------------------------+------------+ 484 Table 5: New Values of the Error Code subregistry 486 5.6.3. Digest Algorithm Subregistry 488 This Section establishes the Digest Algorithm subregistry under the 489 BFCP Parameters registry. As per the terminology in RFC 2434 [3], 490 the registration policy for BFCP digest algorithms shall be 491 "Specification Required". For the purposes of this subregistry, the 492 BFCP error codes for which IANA registration is requested MUST be 493 defined by a standards-track RFC. Such RFC MUST specify the value 494 and the semantics of the error code, and any Error Specific Details 495 that apply to it. 497 For each BFCP digest algorithm, the IANA registers its numeric 498 identifier, its name, and the reference to the RFC where the 499 algorithm is defined. The following table contains the initial 500 values of this subregistry. 502 +------------+-----------+-----------+ 503 | Identifier | Algorithm | Reference | 504 +------------+-----------+-----------+ 505 | 0 | HMAC-SHA1 | RFC 2104 | 506 +------------+-----------+-----------+ 508 Table 6: Initial values of the Digest Algorithms subregistry 510 6. Acknowledgments 512 Sam Hartman provided useful comments on this document. 514 7. Normative References 516 [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 517 for Message Authentication", RFC 2104, February 1997. 519 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 520 Levels", BCP 14, RFC 2119, March 1997. 522 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 523 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 525 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 526 Session Description Protocol (SDP)", RFC 3264, June 2002. 528 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 529 Public Key Infrastructure Certificate and Certificate Revocation 530 List (CRL) Profile", RFC 3280, April 2002. 532 [6] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 533 draft-ietf-xcon-bfcp-06 (work in progress), December 2005. 535 [7] Camarillo, G., "Session Description Protocol (SDP) Format for 536 Binary Floor Control Protocol (BFCP) Streams", 537 draft-ietf-mmusic-sdp-bfcp-03 (work in progress), December 2005. 539 Author's Address 541 Gonzalo Camarillo 542 Ericsson 543 Hirsalantie 11 544 Jorvas 02420 545 Finland 547 Email: Gonzalo.Camarillo@ericsson.com 549 Intellectual Property Statement 551 The IETF takes no position regarding the validity or scope of any 552 Intellectual Property Rights or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; nor does it represent that it has 556 made any independent effort to identify any such rights. Information 557 on the procedures with respect to rights in RFC documents can be 558 found in BCP 78 and BCP 79. 560 Copies of IPR disclosures made to the IETF Secretariat and any 561 assurances of licenses to be made available, or the result of an 562 attempt made to obtain a general license or permission for the use of 563 such proprietary rights by implementers or users of this 564 specification can be obtained from the IETF on-line IPR repository at 565 http://www.ietf.org/ipr. 567 The IETF invites any interested party to bring to its attention any 568 copyrights, patents or patent applications, or other proprietary 569 rights that may cover technology that may be required to implement 570 this standard. Please address the information to the IETF at 571 ietf-ipr@ietf.org. 573 Disclaimer of Validity 575 This document and the information contained herein are provided on an 576 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 577 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 578 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 579 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 580 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 583 Copyright Statement 585 Copyright (C) The Internet Society (2006). This document is subject 586 to the rights, licenses and restrictions contained in BCP 78, and 587 except as set forth therein, the authors retain all their rights. 589 Acknowledgment 591 Funding for the RFC Editor function is currently provided by the 592 Internet Society.