idnits 2.17.1 draft-ietf-xcon-bfcp-connection-00.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 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. ** 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 (November 30, 2005) is 6722 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 482 ** 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) == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-05 == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-sdp-bfcp-02 Summary: 6 errors (**), 0 flaws (~~), 5 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: June 3, 2006 November 30, 2005 6 Connection Establishment in the Binary Floor Control Protocol (BFCP) 7 draft-ietf-xcon-bfcp-connection-00.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 June 3, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 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. This document also 43 specifies a digest authentication mechanism for BFCP based on shared 44 secrets. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 3 51 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 4 53 5.1. Certificate-based Mutual Authentication . . . . . . . . . 4 54 5.2. Digest-based Client Authentication . . . . . . . . . . . . 5 55 5.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 5 56 5.2.2. Floor Control Server Behavior . . . . . . . . . . . . 6 57 5.3. Attribute Definitions . . . . . . . . . . . . . . . . . . 7 58 5.3.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.3.2. DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.4. Error Code Definitions . . . . . . . . . . . . . . . . . . 9 61 5.5. Security Considerations . . . . . . . . . . . . . . . . . 9 62 5.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 63 5.6.1. Attribute Registration . . . . . . . . . . . . . . . . 11 64 5.6.2. Error Code Registration . . . . . . . . . . . . . . . 11 65 5.6.3. Digest Algorithm Subregistry . . . . . . . . . . . . . 11 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 67 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . . . 14 71 1. Introduction 73 As discussed in the BFCP (Binary Floor Control Protocol) 74 specification [6], a given BFCP client needs a set of data in order 75 to establish a BFCP connection to a floor control server. These data 76 include the transport address of the server, the conference 77 identifier, and the user identifier. 79 Once a client obtains this information, it needs to establish a BFCP 80 connection to the floor control server. The way this connection is 81 established depends on the context of the client and the floor 82 control server. How to establish such a connection in the context of 83 an offer/answer [4] exchange between a client and a floor control 84 server is specified in [7]. This document specifies how a client 85 establishes a connection to a floor control server outside the 86 context of an offer/answer exchange. 88 BFCP entities establishing a connection outside an offer/answer 89 exchange need different authentication mechanisms than entities using 90 offer/answer exchanges. This is because offer/answer exchanges 91 provide parties with an initial integrity-protected channel that 92 clients and floor control servers can use to exchange the 93 fingerprints of their self-signed certificates. Outside the offer/ 94 answer model, such a channel is not typically available. This 95 document defines a digest mechanism for BFCP that is based on shared 96 secrets. 98 2. Terminology 100 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 102 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 103 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 104 compliant implementations. 106 3. TCP Connection Establishment 108 A given BFCP client needs a set of data in order to establish a BFCP 109 connection to a floor control server. These data include the 110 transport address of the server, the conference identifier, and the 111 user identifier. It is outside the scope of this document to specify 112 how a client obtains this information. This document assumes that 113 the client obtains this information using an out-of-band method. 115 Once the client has the transport address of the floor control 116 server, it initiates a TCP connection towards it. That is, the 117 client performs an active TCP open. 119 OPEN ISSUE: do we want to define DNS procedures here? If so, do we 120 want to define SRV procedures or are A and AAAA RRs enough? 122 The BFCP specification [6] describes a number of situations when the 123 TCP connection between a client and the floor control server needs to 124 be reestablished. However, that specification does not describe the 125 reestablishment process because this process depends on how the 126 connection was established in the first place. 128 When the existing TCP connection is reseted following the rules in 129 [6], the client SHOULD reestablish the connection towards the floor 130 control server. If a TCP connection cannot deliver a BFCP message 131 from the client to the floor control server and times out, the client 132 SHOULD reestablish the TCP connection. 134 OPEN ISSUE: do we want to have floor control servers reestablish 135 connections as well? 137 4. TLS Usage 139 All BFCP entities implement TLS and SHOULD use it in all their 140 connections. TLS provides integrity and replay protection, and 141 optional confidentiality. The floor control server MUST always act 142 as the TLS server. 144 A floor control server that receives a BFCP message over TCP (no TLS) 145 can request the use of TLS by generating an Error message with an 146 Error code with a value of 9 (Use TLS) 148 5. Authentication 150 BFCP supports certificate-based mutual authentication between clients 151 and floor control servers, as specified in Section 5.1. 152 Additionally, BFCP also provides a digest mechanism based on a shared 153 secret to provide client authentication for clients without 154 certificates. This digest mechanism is described in Section 5.2. 156 5.1. Certificate-based Mutual Authentication 158 At TLS connection establishment, the floor control server MUST 159 present its certificate to the client. Clients with certificates 160 SHOULD also present their certificates to the floor control server. 162 The certificates provided at the TLS-level MUST either be directly 163 signed by one of the other party's trust anchors or be validated 164 using a certification path that terminates at one of the other 165 party's trust anchors [5]. 167 5.2. Digest-based Client Authentication 169 Clients without certificates can authenticate themselves to the floor 170 control servers using a digest-based mechanism instead. BFCP 171 supports digest-based client authentication based on a shared secret 172 between a client and the floor control server. The floor control 173 server of a conference shares a secret with each of the participants 174 in the conference and can request them to sign their messages using 175 that shared secret. Consequently, there is a need for a mechanism to 176 generate such a shared secret. However, such mechanism is outside 177 the scope of this document. This document assumes that shared 178 secrets are generated and exchanged using out-of-band means. 180 Digest-based client authentication in BFCP is based on the DIGEST 181 attribute, which is defined in Section 5.3.2. This attribute, which 182 always appears as the last attribute in a message, contains an 183 algorithm identifier and a keyed digest of the BFCP message using 184 that algorithm. The text used as input to the digest algorithm is 185 the BFCP message, including the common header, up to and including 186 the attribute preceding the DIGEST attribute. Depending on the 187 algorithm, this text may need to be padded with zeroes. 188 Section 5.3.2 lists the algorithms specified in BFCP. 190 The key used as input to the keyed digest is the secret shared 191 between the server and the user identified by the User ID in the 192 common header of the message. 194 Section 5.2.1 and Section 5.2.2 discuss how to achieve client 195 authentication using the DIGEST attribute. 197 5.2.1. Client Behavior 199 To achieve client authentication, a client needs to prove to the 200 floor control server that the client can produce a DIGEST attribute 201 for a message using their shared secret and that the message is fresh 202 (to avoid replay attacks). Clients prove the freshness of a message 203 by including a NONCE attribute in the message. 205 Clients can obtain the digest algorithms supported by the floor 206 control server in an Error response from the floor control server 207 with Error Code 10 (DIGEST Attribute Required). A client SHOULD use 208 the first digest algorithm in the list that it supports. 210 The nonce to be placed in the NONCE attribute by the client is 211 typically provided by the floor control server in an Error response 212 -- typically with Error Code 10 (DIGEST Attribute Required) or 6 213 (Invalid Nonce). If a client generates a message without a DIGEST 214 attribute and receives an Error response with Error Code 10 (DIGEST 215 Attribute Required), the client SHOULD re-send the message with a 216 DIGEST attribute and a NONCE attribute with the nonce received in the 217 Error response. 219 If after sending a message with a DIGEST attribute, a client receives 220 an Error response with Error Code 11 (Invalid Nonce), the client 221 SHOULD re-send the message using the new nonce received in the Error 222 response. If the Error Code is 12 (Authentication Failed) instead, 223 the client MUST NOT send further messages to the floor control server 224 until it has obtained a different (hopefully valid) shared secret 225 than the one used in the original message. 227 If a client receives a nonce in a message from the floor control 228 server, the client SHOULD add a NONCE attribute with this nonce and a 229 DIGEST attribute to its next message to the floor control server. 231 5.2.2. Floor Control Server Behavior 233 If the floor control server receives a message without DIGEST 234 attribute from an unauthenticated client, the floor control server 235 responds with an Error message with Error Code 10 (DIGEST Attribute 236 Required). The floor control message MUST include a list with the 237 digest algorithms supported by the floor control server in order of 238 preference (i.e., the first algorithm is the most preferred) and a 239 NONCE attribute with a nonce value that is unguessable by attackers. 241 When a floor control server receives a BFCP message with a DIGEST 242 attribute, it checks whether the Algorithm identifier in the DIGEST 243 attribute corresponds to an algorithm that is supported by the floor 244 control server. If it does not, the floor control server SHOULD 245 return an Error message with Error Code 10 (DIGEST Attribute 246 Required) with a list with the digest algorithms supported by the 247 floor control server. 249 If the algorithm identifier is valid, the floor control server checks 250 whether the NONCE attribute carries a nonce which was generated by 251 the floor control server for this client and which still has not 252 expired. If the nonce is not valid, authentication is considered to 253 have failed, in which case the floor control server SHOULD return an 254 Error message with Error Code 11 (Invalid Nonce) with a new nonce in 255 a NONCE attribute. 257 If the nonce is valid, the floor control server calculates the keyed 258 digest of the message using the algorithm identified by the DIGEST 259 attribute. The key used as input to the keyed digest is the secret 260 shared between the server and the user identified by the User ID in 261 the common header of the message. If the resulting value is the same 262 as the one in the DIGEST attribute, authentication is considered 263 successful. 265 If the resulting value is different than the one in the DIGEST 266 attribute, authentication is considered to have failed, in which case 267 the server SHOULD return an Error message with Error Code 12 268 (Authentication Failed). Messages from a client that cannot be 269 authenticated MUST NOT be processed further. 271 Floor control servers MAY include a NONCE attribute in their 272 responses to provide the nonce to be used in the next message by the 273 client. However, when TLS is used, floor control servers typically 274 authenticate only the first message sent over the TLS connection. 276 OPEN ISSUE: do we want to state that servers typically authenticate 277 only the first message sent over the TLS connection? 279 5.3. Attribute Definitions 281 The following new attribute types are defined: 283 +------+-----------+-------------+ 284 | Type | Attribute | Format | 285 +------+-----------+-------------+ 286 | 17 | NONCE | Unsigned16 | 287 | 18 | DIGEST | OctetString | 288 +------+-----------+-------------+ 290 Table 1: BFCP attributes 292 Both are EXTENSION-ATTRIBUTES are specified in [6]. 294 5.3.1. NONCE 296 The NONCE attribute can appear in any message. The following is the 297 format of the NONCE attribute. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |0 0 1 0 0 0 1|M|0 0 0 0 0 1 0 0| Nonce Value | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 1: NONCE format 306 Nonce Value: this 16-bit field contains a nonce. 308 5.3.2. DIGEST 310 The DIGEST attribute can only appear in messages sent by clients. 311 The DIGEST attribute MUST be the last attribute of the message in 312 which it appears. The following is the format of the DIGEST 313 attribute. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |0 0 1 0 0 1 0|M|0 0 0 1 1 0 0 0| Algorithm | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 320 | | 321 | | 322 | | 323 / Digest / 324 / / 325 | | 326 | | 327 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | Padding | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 2: DIGEST format 333 Algorithm: this 8-bit field contains the identifier of the algorithm 334 used to calculate the keyed digest. The following are the algorithm 335 identifiers defined: 337 +------------+-----------+---------------+--------------+ 338 | Identifier | Algorithm | Digest Length | Reference | 339 +------------+-----------+---------------+--------------+ 340 | 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] | 341 +------------+-----------+---------------+--------------+ 343 Table 2: Digest algorithms 345 The text used as input to the digest algorithm is the BFCP 346 message, including the common header, up to and including the 347 attribute preceding the DIGEST attribute. Depending on the 348 algorithm, this text may need to be padded with zeroes. When 349 HMAC-SHA1 is used, the input text needs to be padded so as to be a 350 multiple of 64 bytes. 352 The key used as input to the keyed digest is the secret shared 353 between the server and the user identified by the User ID in the 354 common header of the message. 356 Digest: this field contains a keyed digest of the BFCP message. Its 357 calculation is described in Section 5.2. 359 Padding: padding added so that the contents of the DIGEST attribute 360 is 32-bit aligned. The Padding bits SHOULD be set to zero by the 361 sender and MUST be ignored by the receiver. 363 5.4. Error Code Definitions 365 +-------+---------------------------+ 366 | Value | Meaning | 367 +-------+---------------------------+ 368 | 10 | DIGEST Attribute Required | 369 | 11 | Invalid Nonce | 370 | 12 | Authentication Failed | 371 +-------+---------------------------+ 373 Table 3: Error Code meaning 375 The following is the definition of Error Specific Details for Error 376 Code 10 (DIGEST Attribute Needed) 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | Algorithm ID | Algorithm ID | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Algorithm ID | Algorithm ID | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 3: Digest algorithms format 392 Algorithm ID: these 8-bit fields contain the identifiers of the 393 digest algorithms supported by the floor control server in order of 394 preference (i.e., the first algorithm is the most preferred). 396 5.5. Security Considerations 398 BFCP can use TLS or message signatures to provide client 399 authentication. Floor control server authentication is based on TLS, 400 which also provides replay and integrity protection, and 401 confidentiality. It is RECOMMENDED that TLS with non-null encryption 402 is always used and that the first message from an unauthenticated 403 client over a given TLS connection is signed using the DIGEST 404 attribute. Clients and floor control servers MAY use other security 405 mechanisms as long as they provide similar security properties. 407 OPEN ISSUE: same as before. Do we want to say that we recommend to 408 sign only the first message over a TLS connection? 410 The remainder of this Section analyzes some of the threats against 411 BFCP and how they are addressed. 413 An attacker may attempt to impersonate a client (a floor participant 414 or a floor chair) in order to generate forged floor requests or to 415 grant or deny existing floor requests. Client impersonation is 416 avoided by having clients sign their messages. A nonce is included 417 in the signature to ensure the freshness of the message. If the 418 client is using a TLS connection to communicate with the floor 419 control server, it is enough that the client signs its first message 420 over the TLS connection. The floor control server assumes that 421 attackers cannot hickjack the TLS connection and, therefore, that 422 subsequent messages over the TLS connection come from the client that 423 was initially authenticated. If TLS-based client authentication is 424 used, there is not need for the client to sign BFCP messages over the 425 connection. 427 An attacker may attempt to impersonate a floor control server. A 428 successful attacker would be able to make clients think that they 429 hold a particular floor so that they would try to access a resource 430 (e.g., sending media) without having legitimate rights to access it. 431 Floor control server impersonation is avoided by having floor control 432 servers present their server certificates at TLS connection 433 establishment time. 435 Attackers may attempt to modify messages exchanged by a client and a 436 floor control server. The integrity protection provided by TLS 437 connections prevents this attack. 439 An attacker may attempt to fetch a valid message sent by a client to 440 a floor control server and replay it at a later point. If the 441 message was signed, the attacker may attempt to establish a new TLS 442 connection with the floor control server and replay the message over 443 the new connection. Using TLS confidentiality prevents this attack 444 because the attacker cannot access the contents of the message in the 445 first place. Additionally, TLS provides replay protection for a 446 given connection. Therefore, it is strongly RECOMMENDED that TLS is 447 used with a non-null encryption algorithm. 449 Attackers may attempt to pick messages from the network to get access 450 to confidential information between the floor control server and a 451 client (e.g., why a floor request was denied). TLS confidentiality 452 prevents this attack. 454 5.6. IANA Considerations 456 The following sections instruct the IANA to perform a set of actions. 458 5.6.1. Attribute Registration 460 The IANA is instructed to register the following new values under the 461 Attribute subregistry under the BFCP Parameters registry. 463 +------+-----------+------------+ 464 | Type | Attribute | Reference | 465 +------+-----------+------------+ 466 | 17 | NONCE | [RFC XXXX] | 467 | 18 | DIGEST | [RFC XXXX] | 468 +------+-----------+------------+ 470 Table 4: New values of the BFCP Attribute subregistry 472 5.6.2. Error Code Registration 474 The IANA is instructed to register the following new values under the 475 Error Code subregistry under the BFCP Parameters registry. 477 +-------+---------------------------+------------+ 478 | Value | Meaning | Reference | 479 +-------+---------------------------+------------+ 480 | 10 | DIGEST Attribute Required | [RFC XXXX] | 481 | 11 | Invalid Nonce | [RFC XXXX] | 482 | 12 | Authentication Failed | [RFC XXXX] | 483 +-------+---------------------------+------------+ 485 Table 5: New Values of the Error Code subregistry 487 5.6.3. Digest Algorithm Subregistry 489 This Section establishes the Digest Algorithm subregistry under the 490 BFCP Parameters registry. As per the terminology in RFC 2434 [3], 491 the registration policy for BFCP digest algorithms shall be 492 "Specification Required". For the purposes of this subregistry, the 493 BFCP error codes for which IANA registration is requested MUST be 494 defined by a standards-track RFC. Such RFC MUST specify the value 495 and the semantics of the error code, and any Error Specific Details 496 that apply to it. 498 For each BFCP digest algorithm, the IANA registers its numeric 499 identifier, its name, and the reference to the RFC where the 500 algorithm is defined. The following table contains the initial 501 values of this subregistry. 503 +------------+-----------+-----------+ 504 | Identifier | Algorithm | Reference | 505 +------------+-----------+-----------+ 506 | 0 | HMAC-SHA1 | RFC 2104 | 507 +------------+-----------+-----------+ 509 Table 6: Initial values of the Digest Algorithms subregistry 511 6. Acknowledgments 513 Sam Hartman provided useful comments on this document. 515 7. Normative References 517 [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 518 for Message Authentication", RFC 2104, February 1997. 520 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 521 Levels", BCP 14, RFC 2119, March 1997. 523 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 524 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 526 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 527 Session Description Protocol (SDP)", RFC 3264, June 2002. 529 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 530 Public Key Infrastructure Certificate and Certificate Revocation 531 List (CRL) Profile", RFC 3280, April 2002. 533 [6] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 534 draft-ietf-xcon-bfcp-05 (work in progress), July 2005. 536 [7] Camarillo, G., "Session Description Protocol (SDP) Format for 537 Binary Floor Control Protocol (BFCP) Streams", 538 draft-ietf-mmusic-sdp-bfcp-02 (work in progress), July 2005. 540 Author's Address 542 Gonzalo Camarillo 543 Ericsson 544 Hirsalantie 11 545 Jorvas 02420 546 Finland 548 Email: Gonzalo.Camarillo@ericsson.com 550 Intellectual Property Statement 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed to 554 pertain to the implementation or use of the technology described in 555 this document or the extent to which any license under such rights 556 might or might not be available; nor does it represent that it has 557 made any independent effort to identify any such rights. Information 558 on the procedures with respect to rights in RFC documents can be 559 found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use of 564 such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository at 566 http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 this standard. Please address the information to the IETF at 572 ietf-ipr@ietf.org. 574 Disclaimer of Validity 576 This document and the information contained herein are provided on an 577 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 578 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 579 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 580 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 581 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 582 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 584 Copyright Statement 586 Copyright (C) The Internet Society (2005). This document is subject 587 to the rights, licenses and restrictions contained in BCP 78, and 588 except as set forth therein, the authors retain all their rights. 590 Acknowledgment 592 Funding for the RFC Editor function is currently provided by the 593 Internet Society.