idnits 2.17.1 draft-ietf-xcon-bfcp-connection-02.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 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. ** 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 (September 15, 2006) is 6433 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) == Missing Reference: '12' is mentioned on line 132, but not defined -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 524 ** 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) ** Obsolete normative reference: RFC 3484 (ref. '6') (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 4038 (ref. '7') ** Obsolete normative reference: RFC 4566 (ref. '8') (Obsoleted by RFC 8866) Summary: 9 errors (**), 0 flaws (~~), 4 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: March 19, 2007 September 15, 2006 6 Connection Establishment in the Binary Floor Control Protocol (BFCP) 7 draft-ietf-xcon-bfcp-connection-02.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 March 19, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 53 5.1. Certificate-based Mutual Authentication . . . . . . . . . 5 54 5.2. Digest-based Client Authentication . . . . . . . . . . . . 5 55 5.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 6 56 5.2.2. Floor Control Server Behavior . . . . . . . . . . . . 7 57 5.3. Attribute Definitions . . . . . . . . . . . . . . . . . . 8 58 5.3.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.3.2. DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.4. Error Code Definitions . . . . . . . . . . . . . . . . . . 10 61 5.5. Security Considerations . . . . . . . . . . . . . . . . . 10 62 5.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 63 5.6.1. Attribute Registration . . . . . . . . . . . . . . . . 12 64 5.6.2. Error Code Registration . . . . . . . . . . . . . . . 12 65 5.6.3. Digest Algorithm Subregistry . . . . . . . . . . . . . 12 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 As discussed in the BFCP (Binary Floor Control Protocol) 76 specification [9], a given BFCP client needs a set of data in order 77 to establish a BFCP connection to a floor control server. These data 78 include the transport address of the server, the conference 79 identifier, and the user identifier. 81 Once a client obtains this information, it needs to establish a BFCP 82 connection to the floor control server. The way this connection is 83 established depends on the context of the client and the floor 84 control server. How to establish such a connection in the context of 85 an SDP [8] offer/answer [4] exchange between a client and a floor 86 control server is specified in [10]. This document specifies how a 87 client establishes a connection to a floor control server outside the 88 context of an SDP offer/answer exchange. 90 BFCP entities establishing a connection outside an SDP offer/answer 91 exchange need different authentication mechanisms than entities using 92 offer/answer exchanges. This is because offer/answer exchanges 93 provide parties with an initial integrity-protected channel that 94 clients and floor control servers can use to exchange the 95 fingerprints of their self-signed certificates. Outside the offer/ 96 answer model, such a channel is not typically available. This 97 document defines a digest mechanism for BFCP that is based on shared 98 secrets. 100 2. Terminology 102 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 103 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 104 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 105 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 106 compliant implementations. 108 3. TCP Connection Establishment 110 As stated in Section 1, a given BFCP client needs a set of data in 111 order to establish a BFCP connection to a floor control server. 112 These data include the transport address of the server, the 113 conference identifier, and the user identifier. It is outside the 114 scope of this document to specify how a client obtains this 115 information. This document assumes that the client obtains this 116 information using an out-of-band method. 118 Once the client has the transport address (i.e., IP address and port) 119 of the floor control server, it initiates a TCP connection towards 120 it. That is, the client performs an active TCP open. 122 If the client is provided with the floor control server's host name 123 instead of with its IP address, the client MUST perform a DNS lookup 124 in order to resolve the host name into an IP address. Clients 125 eventually perform an A or AAAA DNS lookup (or both) on the host 126 name. 128 In order to translate the host name to the corresponding set of IP 129 addresses, IPv6-only or dual-stack clients MUST use the newer 130 getaddrinfo() name lookup function, instead of gethostbyname() [7]. 131 The new function implements the Source and Destination Address 132 Selection algorithms specified in [12], and is expected to be 133 supported by all IPv6 hosts. 135 The advantage of the additional complexity is that this technique 136 will output an ordered list of IPv6/IPv4 destination addresses based 137 on the relative merits of the corresponding source/destination pairs. 138 This will guarantee optimal routing. However, the Source and 139 Destination Selection algorithms of [6] are dependent on broad 140 operating system support and uniform implementation of the 141 application programming interfaces that implement this behavior. 143 Developers should carefully consider the issues described by Roy 144 et al. [11] with respect to address resolution delays and address 145 selection rules. For example, implementations of getaddrinfo() 146 may return address lists containing IPv6 global addresses at the 147 top of the list and IPv4 addresses at the bottom, even when the 148 host is only configured with an IPv6 local scope (e.g., link- 149 local) and an IPv4 address. This will, of course, introduce a 150 delay in completing the connection. 152 The BFCP specification [9] describes a number of situations when the 153 TCP connection between a client and the floor control server needs to 154 be reestablished. However, that specification does not describe the 155 reestablishment process because this process depends on how the 156 connection was established in the first place. 158 When the existing TCP connection is closed following the rules in 159 [9], the client SHOULD reestablish the connection towards the floor 160 control server. If a TCP connection cannot deliver a BFCP message 161 from the client to the floor control server and times out, the client 162 SHOULD reestablish the TCP connection. 164 4. TLS Usage 165 All BFCP entities implement TLS and SHOULD use it in all their 166 connections. TLS provides integrity and replay protection, and 167 optional confidentiality. The floor control server MUST always act 168 as the TLS server. 170 A floor control server that receives a BFCP message over TCP (no TLS) 171 can request the use of TLS by generating an Error message with an 172 Error code with a value of 9 (Use TLS). 174 5. Authentication 176 BFCP supports certificate-based mutual authentication between clients 177 and floor control servers, as specified in Section 5.1. 178 Additionally, BFCP also provides a digest mechanism based on a shared 179 secret to provide client authentication for clients without 180 certificates. This digest mechanism is described in Section 5.2. 182 5.1. Certificate-based Mutual Authentication 184 At TLS connection establishment, the floor control server MUST 185 present its certificate to the client. Clients with certificates 186 SHOULD also present their certificates to the floor control server. 188 The certificates provided at the TLS-level MUST either be directly 189 signed by one of the other party's trust anchors or be validated 190 using a certification path that terminates at one of the other 191 party's trust anchors [5]. 193 5.2. Digest-based Client Authentication 195 Clients without certificates can authenticate themselves to the floor 196 control server using a digest-based mechanism instead. BFCP supports 197 digest-based client authentication based on a shared secret between a 198 client and the floor control server. The floor control server of a 199 conference shares a secret with each of the participants in the 200 conference and can request them to sign their messages using that 201 shared secret. Consequently, there is a need for a mechanism to 202 generate such a shared secret. However, such mechanism is outside 203 the scope of this document. This document assumes that shared 204 secrets are generated and exchanged using out-of-band means. 205 However, shared secrets MUST be at least as long as the length of the 206 output of the digest algorithm used, as recommended in [1]. 208 Digest-based client authentication in BFCP is based on the DIGEST 209 attribute, which is defined in Section 5.3.2. This attribute, which 210 always appears as the last attribute in a message, contains an 211 algorithm identifier and a keyed digest of the BFCP message using 212 that algorithm. The text used as input to the digest algorithm is 213 the BFCP message, including the common header, up to and including 214 the attribute preceding the DIGEST attribute. Depending on the 215 algorithm, this text may need to be padded with zeroes. 216 Section 5.3.2 lists the algorithms specified in BFCP. 218 The key used as input to the keyed digest is the secret shared 219 between the server and the user identified by the User ID in the 220 common header of the message. 222 Section 5.2.1 and Section 5.2.2 discuss how to achieve client 223 authentication using the DIGEST attribute. 225 5.2.1. Client Behavior 227 To achieve client authentication, a client needs to prove to the 228 floor control server that the client can produce a DIGEST attribute 229 for a message using their shared secret and that the message is fresh 230 (to avoid replay attacks). Clients prove the freshness of a message 231 by including a NONCE attribute in the message. 233 Clients can obtain the digest algorithms supported by the floor 234 control server in an Error response from the floor control server 235 with Error Code 10 (DIGEST Attribute Required). A client SHOULD use 236 the first digest algorithm in the list that it supports. 238 The nonce to be placed in the NONCE attribute by the client is 239 typically provided by the floor control server in an Error response 240 with Error Code 10 (DIGEST Attribute Required) or 6 (Invalid Nonce). 241 If a client generates a message without a DIGEST attribute and 242 receives an Error response with Error Code 10 (DIGEST Attribute 243 Required), the client SHOULD resend the message with a DIGEST 244 attribute and a NONCE attribute with the nonce received in the Error 245 response. 247 If after sending a message with a DIGEST attribute, a client receives 248 an Error response with Error Code 11 (Invalid Nonce), the client 249 SHOULD resend the message using the new nonce received in the Error 250 response. If the Error Code is 12 (Authentication Failed) instead, 251 the client MUST NOT send further messages to the floor control server 252 until it has obtained a different (hopefully valid) shared secret 253 than the one used in the original message. 255 If a client receives a nonce in a message from the floor control 256 server, the client SHOULD add a NONCE attribute with this nonce and a 257 DIGEST attribute to its next message to the floor control server. 259 5.2.2. Floor Control Server Behavior 261 If the floor control server receives a message without DIGEST 262 attribute from an unauthenticated client, the floor control server 263 responds with an Error message with Error Code 10 (DIGEST Attribute 264 Required). The floor control message MUST include a list with the 265 digest algorithms supported by the floor control server in order of 266 preference (i.e., the first algorithm is the most preferred) and a 267 NONCE attribute with a nonce value. Floor control servers MUST NOT 268 use the same nonce for the same shared secret more than once. 270 When a floor control server receives a BFCP message with a DIGEST 271 attribute, it checks whether the Algorithm identifier in the DIGEST 272 attribute corresponds to an algorithm that is supported by the floor 273 control server. If it does not, the floor control server SHOULD 274 return an Error message with Error Code 10 (DIGEST Attribute 275 Required) with a list with the digest algorithms supported by the 276 floor control server. 278 If the algorithm identifier is valid, the floor control server checks 279 whether the NONCE attribute carries a nonce which was generated by 280 the floor control server for this client and which still has not 281 expired. If the nonce is not valid, authentication is considered to 282 have failed, in which case the floor control server SHOULD return an 283 Error message with Error Code 11 (Invalid Nonce) with a new nonce in 284 a NONCE attribute. 286 If the nonce is valid, the floor control server calculates the keyed 287 digest of the message using the algorithm identified by the DIGEST 288 attribute. The key used as input to the keyed digest is the secret 289 shared between the server and the user identified by the User ID in 290 the common header of the message. If the resulting value is the same 291 as the one in the DIGEST attribute, authentication is considered 292 successful. 294 If the resulting value is different than the one in the DIGEST 295 attribute, authentication is considered to have failed, in which case 296 the server SHOULD return an Error message with Error Code 12 297 (Authentication Failed). Messages from a client that cannot be 298 authenticated MUST NOT be processed further. 300 Floor control servers MAY include a NONCE attribute in their 301 responses to provide the nonce to be used in the next message by the 302 client. However, when TLS is used, floor control servers MAY choose 303 to only authenticate the first message sent over the TLS connection. 304 This way, the client does not need to sign every message it sends 305 (message signatures can be long when compared with BFCP messages). 306 Reducing the size of BFCP messages can considerably reduce 307 transmission times over low-bandwidth links. 309 5.3. Attribute Definitions 311 The following new attribute types are defined: 313 +------+-----------+-------------+ 314 | Type | Attribute | Format | 315 +------+-----------+-------------+ 316 | 19 | NONCE | Unsigned16 | 317 | 20 | DIGEST | OctetString | 318 +------+-----------+-------------+ 320 Table 1: BFCP attributes 322 Both are EXTENSION-ATTRIBUTES as specified in [9]. 324 5.3.1. NONCE 326 The NONCE attribute can appear in any message. The NONCE attribute 327 MUST be the last attribute of messages that do not contain a DIGEST 328 attribute and the second to last attribute of messages that contain a 329 DIGEST attribute (the DIGEST attribute is always the last). The 330 following is the format of the NONCE attribute. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |0 0 1 0 0 1 1|M|0 0 0 0 0 1 0 0| Nonce Value | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 1: NONCE format 340 Nonce Value: this 16-bit field contains a nonce. 342 5.3.2. DIGEST 344 The DIGEST attribute can only appear in messages sent by clients. 345 The DIGEST attribute MUST be the last attribute of the message in 346 which it appears. The following is the format of the DIGEST 347 attribute. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |0 0 1 0 1 0 0|M| Length | Algorithm | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 354 | | 355 | | 356 | | 357 / Digest / 358 / / 359 | | 360 | | 361 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | Padding | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 2: DIGEST format 367 Algorithm: this 8-bit field contains the identifier of the algorithm 368 used to calculate the keyed digest. The following are the 369 algorithm identifiers defined: 371 +------------+-----------+---------------+--------------+ 372 | Identifier | Algorithm | Digest Length | Reference | 373 +------------+-----------+---------------+--------------+ 374 | 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] | 375 +------------+-----------+---------------+--------------+ 377 Table 2: Digest algorithms 379 The text used as input to the digest algorithm is the BFCP 380 message, including the common header, up to and including the 381 attribute preceding the DIGEST attribute. Depending on the 382 algorithm, this text may need to be padded with zeroes. 384 The key used as input to the keyed digest is the secret shared 385 between the server and the user identified by the User ID in the 386 common header of the message. 388 Digest: this field contains a keyed digest of the BFCP message. Its 389 calculation is described in Section 5.2. 391 Padding: padding added so that the contents of the DIGEST attribute 392 is 32-bit aligned. The Padding bits SHOULD be set to zero by the 393 sender and MUST be ignored by the receiver. 395 5.4. Error Code Definitions 397 This specification defines the following new BFCP Error Codes: 399 +-------+---------------------------+ 400 | Value | Meaning | 401 +-------+---------------------------+ 402 | 10 | DIGEST Attribute Required | 403 | 11 | Invalid Nonce | 404 | 12 | Authentication Failed | 405 +-------+---------------------------+ 407 Table 3: Error Code meaning 409 The following is the definition of Error Specific Details for Error 410 Code 10 (DIGEST Attribute Needed) 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | Algorithm ID | Algorithm ID | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Algorithm ID | Algorithm ID | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 3: Digest algorithms format 426 Algorithm ID: these 8-bit fields contain the identifiers of the 427 digest algorithms supported by the floor control server in order 428 of preference (i.e., the first algorithm is the most preferred). 430 5.5. Security Considerations 432 BFCP can use TLS or message signatures to provide client 433 authentication. Floor control server authentication is based on TLS, 434 which also provides replay and integrity protection, and 435 confidentiality. It is RECOMMENDED that TLS with non-null encryption 436 is always used and that the first message from an unauthenticated 437 client over a given TLS connection is challenged by the floor control 438 server. Clients and floor control servers MAY use other security 439 mechanisms as long as they provide similar security properties (i.e., 440 replay and integrity protection, confidentiality, and server 441 authentication). 443 The remainder of this Section analyzes some of the threats against 444 BFCP and how they are addressed. 446 An attacker may attempt to impersonate a client (a floor participant 447 or a floor chair) in order to generate forged floor requests or to 448 grant or deny existing floor requests. Client impersonation is 449 avoided by having clients sign their messages. A nonce is included 450 in the signature to ensure the freshness of the message. If the 451 client is using a TLS connection to communicate with the floor 452 control server, it is enough that the client signs its first message 453 over the TLS connection. The floor control server assumes that 454 attackers cannot hickjack the TLS connection and, therefore, that 455 subsequent messages over the TLS connection come from the client that 456 was initially authenticated. If TLS-based client authentication is 457 used, there is not need for the client to sign BFCP messages over the 458 connection. 460 An attacker may attempt to impersonate a floor control server. A 461 successful attacker would be able to make clients think that they 462 hold a particular floor so that they would try to access a resource 463 (e.g., sending media) without having legitimate rights to access it. 464 Floor control server impersonation is avoided by having floor control 465 servers present their server certificates at TLS connection 466 establishment time. Clients MUST NOT send any signed BFCP message to 467 an unauthenticated floor control server in order to prevent man-in- 468 the-middle attacks. 470 Attackers may attempt to modify messages exchanged by a client and a 471 floor control server. The integrity protection provided by TLS 472 connections prevents this attack. 474 An attacker may attempt to fetch a valid message sent by a client to 475 a floor control server and replay it at a later point. If the 476 message was signed, the attacker may attempt to establish a new TLS 477 connection with the floor control server and replay the message over 478 the new connection. The use of nonces avoids this type of attack. 479 As stated in Section 5.2.2, floor control servers do not use the same 480 nonce for the same shared secret more than once. 482 Using TLS confidentiality also prevents that attack because the 483 attacker cannot access the contents of the message in the first 484 place. Additionally, TLS provides replay protection within a given 485 connection. Therefore, it is RECOMMENDED that TLS is used with a 486 non-null encryption algorithm. 488 Attackers may attempt to pick messages from the network to get access 489 to confidential information between the floor control server and a 490 client (e.g., why a floor request was denied). TLS confidentiality 491 prevents this attack. 493 5.6. IANA Considerations 495 The following sections instruct the IANA to perform a set of actions. 497 5.6.1. Attribute Registration 499 The IANA is instructed to register the following new values under the 500 Attribute subregistry under the BFCP Parameters registry. 502 +------+-----------+------------+ 503 | Type | Attribute | Reference | 504 +------+-----------+------------+ 505 | 19 | NONCE | [RFC XXXX] | 506 | 20 | DIGEST | [RFC XXXX] | 507 +------+-----------+------------+ 509 Table 4: New values of the BFCP Attribute subregistry 511 [Note to the RFC editor: please, replace RFCxxxx with the RFC number 512 that will be assigned to this document.] 514 5.6.2. Error Code Registration 516 The IANA is instructed to register the following new values under the 517 Error Code subregistry under the BFCP Parameters registry. 519 +-------+---------------------------+------------+ 520 | Value | Meaning | Reference | 521 +-------+---------------------------+------------+ 522 | 10 | DIGEST Attribute Required | [RFC XXXX] | 523 | 11 | Invalid Nonce | [RFC XXXX] | 524 | 12 | Authentication Failed | [RFC XXXX] | 525 +-------+---------------------------+------------+ 527 Table 5: New Values of the Error Code subregistry 529 [Note to the RFC editor: please, replace RFCxxxx with the RFC number 530 that will be assigned to this document.] 532 5.6.3. Digest Algorithm Subregistry 534 This Section establishes the Digest Algorithm subregistry under the 535 BFCP Parameters registry. As per the terminology in RFC 2434 [3], 536 the registration policy for BFCP digest algorithms shall be 537 "Specification Required". 539 For each BFCP digest algorithm, the IANA registers its numeric 540 identifier, its name, and the reference to the specification where 541 the algorithm is defined. The following table contains the initial 542 values of this subregistry. 544 +------------+-----------+-----------+ 545 | Identifier | Algorithm | Reference | 546 +------------+-----------+-----------+ 547 | 0 | HMAC-SHA1 | RFC 2104 | 548 +------------+-----------+-----------+ 550 Table 6: Initial values of the Digest Algorithms subregistry 552 6. Acknowledgments 554 Sam Hartman and Karim El Malki provided useful comments on this 555 document. 557 7. References 559 7.1. Normative References 561 [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 562 for Message Authentication", RFC 2104, February 1997. 564 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 565 Levels", BCP 14, RFC 2119, March 1997. 567 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 568 Considerations Section in RFCs", BCP 26, RFC 2434, 569 October 1998. 571 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 572 Session Description Protocol (SDP)", RFC 3264, June 2002. 574 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 575 Public Key Infrastructure Certificate and Certificate 576 Revocation List (CRL) Profile", RFC 3280, April 2002. 578 [6] Draves, R., "Default Address Selection for Internet Protocol 579 version 6 (IPv6)", RFC 3484, February 2003. 581 [7] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, 582 "Application Aspects of IPv6 Transition", RFC 4038, March 2005. 584 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 585 Description Protocol", RFC 4566, July 2006. 587 [9] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 588 draft-ietf-xcon-bfcp-06 (work in progress), December 2005. 590 [10] Camarillo, G., "Session Description Protocol (SDP) Format for 591 Binary Floor Control Protocol (BFCP) Streams", 592 draft-ietf-mmusic-sdp-bfcp-03 (work in progress), 593 December 2005. 595 7.2. Informative References 597 [11] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered 598 Harmful", draft-ietf-v6ops-onlinkassumption-04 (work in 599 progress), January 2006. 601 Author's Address 603 Gonzalo Camarillo 604 Ericsson 605 Hirsalantie 11 606 Jorvas 02420 607 Finland 609 Email: Gonzalo.Camarillo@ericsson.com 611 Intellectual Property Statement 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. Information 619 on the procedures with respect to rights in RFC documents can be 620 found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use of 625 such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository at 627 http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 Disclaimer of Validity 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 640 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 641 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 642 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Copyright Statement 647 Copyright (C) The Internet Society (2006). This document is subject 648 to the rights, licenses and restrictions contained in BCP 78, and 649 except as set forth therein, the authors retain all their rights. 651 Acknowledgment 653 Funding for the RFC Editor function is currently provided by the 654 Internet Society.