idnits 2.17.1 draft-ietf-mmusic-sdp-bfcp-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 736. ** 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 (July 18, 2005) is 6858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1750 (ref. '1') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3548 (ref. '6') (Obsoleted by RFC 4648) == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-04 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-comedia-tls-04 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-24 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-11 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: January 19, 2006 July 18, 2005 6 Session Description Protocol (SDP) Format for Binary Floor Control 7 Protocol (BFCP) Streams 8 draft-ietf-mmusic-sdp-bfcp-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 19, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document specifies how to describe BFCP streams in SDP session 42 descriptions. User agents using the offer/answer model to establish 43 BFCP streams use this format in their offers and their answers. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . . 3 50 4. Floor Control Server Determination . . . . . . . . . . . . . . 4 51 5. The 'confid' and 'userid' SDP Attributes . . . . . . . . . . . 6 52 6. Association between Streams and Floors . . . . . . . . . . . . 6 53 7. TCP Connection Management . . . . . . . . . . . . . . . . . . 7 54 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 7 55 8.1 Mutual Authentication Using Certificates and TLS . . . . . 8 56 8.2 Client Authentication at the BFCP Level . . . . . . . . . 8 57 8.2.1 Generating a Shared Secret . . . . . . . . . . . . . . 8 58 8.2.2 The 'nonce' Attribute . . . . . . . . . . . . . . . . 9 59 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 9.1 Example Using TLS . . . . . . . . . . . . . . . . . . . . 10 61 9.2 Example Using the 'crypto' Attribute . . . . . . . . . . . 11 62 10. Security Considerations . . . . . . . . . . . . . . . . . . 11 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 64 11.1 Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP' SDP 65 'proto' values . . . . . . . . . . . . . . . . . . . . . . 12 66 11.2 Registration of the SDP 'floorctrl' Attribute . . . . . . 12 67 11.3 Registration of the SDP 'confid' Attribute . . . . . . . . 13 68 11.4 Registration of the SDP 'userid' Attribute . . . . . . . . 13 69 11.5 Registration of the SDP 'floorid' Attribute . . . . . . . 14 70 11.6 Registration of the SDP 'nonce' Attribute . . . . . . . . 14 71 11.7 Registration of the crypto-suites for 'TCP/BFCP' . . . . . 15 72 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 73 13. Normative References . . . . . . . . . . . . . . . . . . . . 15 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 75 Intellectual Property and Copyright Statements . . . . . . . . 18 77 1. Introduction 79 As discussed in the BFCP (Binary Floor Control Protocol) 80 specification [8], a given BFCP client needs a set of data in order 81 to establish a BFCP connection to a floor control server. These data 82 include the transport address of the server, the conference 83 identifier, and the user identifier. 85 One way for clients to obtain this information consists of using an 86 offer/answer [5] exchange. This document specifies how to encode 87 this information in the SDP session descriptions which are part of 88 such an offer/answer exchange. 90 User agents typically use the offer/answer model to establish a 91 number of media streams of different types. Following this model, a 92 BFCP connection is described as any other media stream by using an 93 SDP 'm' line, possibly followed by a number of attributes encoded in 94 'a' lines. 96 2. Terminology 98 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 99 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 100 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 101 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 102 compliant implementations. 104 3. Fields in the 'm' Line 106 This Section describes how to generate an 'm' line for a BFCP stream. 108 According to the SDP specification [11], the 'm' line format is the 109 following: 111 m= ... 113 The media field MUST have a value of "application". 115 The port field is set following the rules in [7]. Depending on the 116 value of the 'setup' attribute (disccused in Section 7), the port 117 field contains the port the remote endpoint will initiate its TCP 118 connection to, or is irrelevant (i.e., the endpoint will initiate the 119 connection towards the remote endpoint) and should be set to a value 120 of 9, which is the discard port. Since BFCP only runs on top of TCP, 121 the port is always a TCP port. A port field value of zero has the 122 standard SDP meaning (i.e., rejection of the media stream). 124 We define two new values for the transport field: TCP/BFCP and TCP/ 125 TLS/BFCP. The former is used when BFCP runs directly on top of TCP 126 and the latter is used when BFCP runs on top of TLS, which in turn 127 runs on top of TCP. 129 The fmt (format) list is ignored for BFCP. The fmt list of BFCP m 130 lines SHOULD contain a single "*" character. 132 The following is an example of an 'm' line for a BFCP connection: 134 m=application 20000 TCP/TLS/BFCP * 136 4. Floor Control Server Determination 138 When two endpoints establish a BFCP stream, they need to determine 139 which of them acts as a floor control server. The most common 140 scenario consists of a client establishing a BFCP stream with 141 conference server that acts as the floor control server. Floor 142 control server determination is straight forward because one endpoint 143 can only act as a client and the other can only act as a floor 144 control server. 146 However, there are scenarios where both endpoints could act as a 147 floor control server. For example, is a two-party session that 148 involves an audio stream and a shared whiteboard, the endpoints need 149 to decide which party will be acting as the floor control server. 151 Furthermore, there are situations where both the offerer and the 152 answerer act as both clients and floor control servers in the same 153 session. For example, in a two-party session that involves an audio 154 stream and a shared whiteboard, one party acts as the floor control 155 server for the audio stream and the other acts as the floor control 156 server for the shared whiteboard. 158 We define the 'floorctrl' SDP media-level attribute to perform floor 159 control determination. Its Augmented BNF syntax [3] is: 161 floor-control-attribute = "a=floorctrl:" role *(SP role) 162 role = "c-only" / "s-only" / "c-s" 164 The offerer includes this attribute to state all the roles it would 165 be willing to perform: 167 c-only: The offerer would be willing to only act as a floor control 168 client. 169 s-only: The offerer would be willing to only act as a floor control 170 server. 171 c-s: The offerer would be willing to act both as a floor control 172 client and as a floor control server. 174 If an 'm' line in an offer contains a 'floorctrl' attribute, the 175 answerer MUST include one in the corresponding 'm' line in the 176 answer. The answerer includes this attribute to state which role the 177 answerer will perform. That is, the answerer chooses one of the 178 roles the offerer is willing to perform and generates an answer with 179 the corresponding role for the answerer. Table 1 shows the 180 corresponding roles for an answerer depending on the offerer's role. 182 +---------+----------+ 183 | Offerer | Answerer | 184 +---------+----------+ 185 | c-only | s-only | 186 | s-only | c-only | 187 | c-s | c-s | 188 +---------+----------+ 190 Table 1: Roles 192 The following are the description of the roles when chosen by an 193 answere:. 195 c-only: The answerer will act as a floor control client. 196 Consequently, the offerer will act as a floor control server. 197 s-only: The answerer will act as a floor control server. 198 Consequently, the offerer will act as a floor control client. 199 c-s: The answerer will act both as a floor control client and as a 200 floor control server. Consequently, the offerer will also act 201 both as a floor control client and as a floor control server as 202 well. 204 Endpoints which use the offer/answer model to establish BFCP 205 connections MUST support the 'floorctrl' attribute. A floor control 206 server acting as an offerer or as an answerers SHOULD include this 207 attribute in its session descriptions. 209 If the 'floorctrl' attribute is not used in an offer/answer exchange, 210 by default the offerer and the answerer will act as a floor control 211 client and as a floor control server respectively. 213 The following is an example of a 'floorctrl' attribute in an offer. 214 When this attribute appears in an answer, it only carries one role: 216 a=floorctrl:c-only s-only c-s 218 5. The 'confid' and 'userid' SDP Attributes 220 We define the 'confid' and the 'userid' SDP media-level attributes. 221 These attributes attributes are used by a floor control server to 222 provide a client with a conference ID and a user ID respectively. 223 Their Augmented BNF syntax [3] is: 225 confid-attribute = "a=confid:" conference-id 226 conference-id = token 228 userid-attribute = "a=userid:" user-id 229 user-id = token 231 The confid and the userid attributes carry the integer representation 232 of a conference ID and a user ID respectively. 234 Endpoints which use the offer/answer model to establish BFCP 235 connections MUST support the confid and the userid attributes. A 236 floor control server acting as an offerer or as an answerers SHOULD 237 include these attributes in its session descriptions. 239 6. Association between Streams and Floors 241 We define the floorid SDP media-level attribute. Its Augmented BNF 242 syntax [3] is: 244 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 246 The floorid attribute is used in BFCP 'm' lines. It defines a floor 247 identifier and, possibly, associates it with one or more media 248 streams. The token representing the floor ID is the integer 249 representation of the Floor ID to be used in BFCP. The token 250 representing the media stream is a pointer to the media stream, which 251 is identified by an SDP label attribute [9] 253 Endpoints which use the offer/answer model to establish BFCP 254 connections MUST support the 'floorid' and the 'label' attributes. A 255 floor control server acting as an offerer or as an answerer SHOULD 256 include these attributes in its session descriptions. 258 7. TCP Connection Management 260 The management of the TCP connection used to transport BFCP is 261 performed using the 'setup' and 'connection' attributes as defined in 262 [7]. 264 The 'setup' attribute indicates which of the endpoints (client or 265 floor control server) initiates the TCP connection. The 'connection' 266 attribute handles TCP connection reestablishment. 268 The BFCP specification [8] describes a number of situations when the 269 TCP connection between a client and the floor control server needs to 270 be reestablished. However, that specification does not describe the 271 reestablishment process because this process depends on how the 272 connection was established in the first place. BFCP entities using 273 the offer/answer model follow the following rules. 275 When the existing TCP connection is reseted following the rules in 276 [8], the client SHOULD generate an offer towards the floor control 277 server in order to reestablish the connection. If a TCP connection 278 cannot deliver a BFCP message and times out, the entity that 279 attempted to send the message (i.e., the one that detected the TCP 280 timeout) SHOULD generate an offer in order to reestablish the TCP 281 connection. 283 Endpoints which use the offer/answer model to establish BFCP 284 connections MUST support the 'setup' and the 'connection' attributes. 286 8. Authentication 288 When a BFCP connection is established using the offer/answer model, 289 it is assumed that the offerer and the answerer authenticate each 290 other using some mechanism. Once this mutual authentication takes 291 place, all the offerer and the answerer need to make sure is that the 292 entity they are receiving BFCP messages from is the same as the one 293 that generated the previous offer or answer. 295 When SIP is used to perform an offer/answer exchange, the initial 296 mutual authentication takes place at the SIP level. Additionally, 297 SIP uses S/MIME to provide an integrity protected channel with 298 optional confidentiality for the offer/answer exchange. BFCP takes 299 advantage of this integrity protected offer/answer exchange to 300 perform authentication. Within the offer/answer exchange, the 301 offerer and the answerer exchange the fingerprints of their self- 302 signed certificates. These self-signed certificates are then used to 303 establish the TLS connection that will carry BFCP traffic between the 304 offerer and the answerer. Of course, certificates signed by a 305 certificate authority known to both parties can also be used. 307 Section 8.1 describes mutual authentication using certificates and 308 TLS, which is the RECOMMENDED mechanism to perform mutual 309 authentication. 311 BFCP also provides a digest mechanism based on a shared secret to 312 provide client authentication in situations where TLS is not used for 313 some reason. Section 8.2 describes how to set up this mechanism 314 using an offer/answer model. Note that when mutual authentication is 315 performed using TLS, it is not necessary to use this digest 316 mechanism. 318 8.1 Mutual Authentication Using Certificates and TLS 320 BFCP clients and floor control servers follow the rules in [10] 321 regarding certificate choice and presentation. This implies that 322 unless a 'fingerprint' attribute is included in the session 323 description, the certificate provided at the TLS-level must be signed 324 by a certificate authority known to other party. Endpoints which use 325 the offer/answer model to establish BFCP connections MUST support the 326 'fingerprint' attribute and SHOULD include it in their session 327 descriptions. 329 When TLS is used, once the underlaying TCP connection is established, 330 the answerer acts as the TLS server regardless of its role (passive 331 or active) in the TCP establishment procedure. 333 8.2 Client Authentication at the BFCP Level 335 Digest authentication in BFCP is based on a shared secret between the 336 client and the floor control server. Section 8.2.1 describes how to 337 set up such a secret using an encrypted offer/answer exchange. 338 Section 8.2.2 describes how a floor control server can provide a 339 client with an initial nonce. 341 8.2.1 Generating a Shared Secret 343 This section describes how to generate a shared secret between a 344 client and a floor control server using SDP security descriptions and 345 the SDP 'crypto' attribute [12]. 347 The following is the format of the 'crypto' attribute as defined in 348 [12]: 350 a=crypto: [] 352 The use of the tag field is specified in [12]. 354 The possible values for the crypto-suite field are defined within the 355 context of a transport; TCP/BFCP in our case. Within the context of 356 TCP/BFCP, we define the following value for the crypto-suite field: 358 +-----------+-----------------+ 359 | Value | BFCP Identifier | 360 +-----------+-----------------+ 361 | HMAC-SHA1 | 0 | 362 +-----------+-----------------+ 364 Table 2: Values for the crypto-suite field in TCP/BFCP 366 The IANA registry for Digest Algorithms in BFCP contains references 367 to the specifications that describe the usage of each digest 368 algorithm (identified by its BFCP identifier) in BFCP. 370 The key-params field SHOULD use the 'inline' key method followed by a 371 base64-encoded [6] unguessable secret [1]. 373 The use of the optional session-params field is for further study. 375 The following is an example of a 'crypto' attribute: 377 a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== 379 The use of the 'crypto' attribute in an offer/answer exchange is 380 described in [12]. Additionally, when this attribute is used with 381 BFCP streams, the answerer MUST use the same value in the key-params 382 field as the one received in the offer. 384 Endpoints MAY use other mechanisms (including out-of-band mechanisms) 385 to generate a shared secret. However, if the mechanism described in 386 this section is used, the session descriptions MUST be encrypted. 388 8.2.2 The 'nonce' Attribute 390 We define the SDP media-level 'nonce' attribute. Its Augmented BNF 391 syntax [3] is: 393 nonce-attribute = "a=nonce:" nonce-value 394 nonce-value = token 396 The 'nonce' attribute carries the integer representation of the nonce 397 to be used by the client in its next BFCP message (typically the 398 first message from the client) towards the floor control server. 399 This is an optimization so that the client does not need to generate 400 an initial BFCP message only to have it rejected by the floor control 401 server with an Error response containing a nonce. 403 Endpoints which use the offer/answer model to establish BFCP 404 connections SHOULD support the 'nonce' attribute. A floor control 405 server acting as an offerer or as an answerers MAY include this 406 attribute in its session descriptions. 408 9. Examples 410 For the purpose of brevity, the main portion of the session 411 description is omitted in the examples, which only show 'm' lines and 412 their attributes. 414 9.1 Example Using TLS 416 The following is an example of an offer sent by a conference server 417 to a client. 419 m=application 20000 TCP/TLS/BFCP * 420 a=setup:passive 421 a=connection:new 422 a=fingerprint:SHA-1 \ 423 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 424 a=floorctrl:s-only 425 a=confid:4321 426 a=userid:1234 427 a=floorid:1 m-stream:10 428 a=floorid:2 m-stream:11 429 m=audio 20000 RTP/AVP 0 430 a=label:10 431 m=video 30000 RTP/AVP 31 432 a=label:11 434 Note that due to RFC formatting conventions, this document splits SDP 435 across lines whose content would exceed 72 characters. A backslash 436 character marks where this line folding has taken place. This 437 backslash and its trailing CRLF and whitespace would not appear in 438 actual SDP content. 440 The following is the answer returned by the user. 442 m=application 9 TCP/TLS/BFCP * 443 a=setup:active 444 a=connection:new 445 a=fingerprint:SHA-1 \ 446 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 447 a=floorctrl:c-only 448 m=audio 25000 RTP/AVP 0 449 m=video 35000 RTP/AVP 31 451 9.2 Example Using the 'crypto' Attribute 453 The following is an example of an offer sent by a client to a 454 conference server. In this case, TLS is not used to perform mutual 455 authentication. The 'crypto' attribute is used to generate a shared 456 secret between the client and the floor control server. 458 m=application 9 TCP/BFCP * 459 a=setup:active 460 a=connection:new 461 a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== 462 a=floorctrl:c-only 463 m=audio 25000 RTP/AVP 0 464 m=video 35000 RTP/AVP 31 466 The following is the answer returned by the conference server. 468 m=application 20000 TCP/BFCP * 469 a=setup:passive 470 a=connection:new 471 a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== 472 a=nonce:5736 473 a=floorctrl:s-only 474 a=confid:4321 475 a=userid:1234 476 a=floorid:1 m-stream:10 477 a=floorid:2 m-stream:11 478 m=audio 20000 RTP/AVP 0 479 a=label:10 480 m=video 30000 RTP/AVP 31 481 a=label:11 483 10. Security Considerations 485 The BFCP [8], SDP [11], and the offer/answer [5] specifications 486 discuss security issues related to BFCP, SDP, and the offer/answer 487 respectively. In addition, [7] and [10] discuss security issues 488 related to the establishment of TCP and TLS connections using an 489 offer/answer model. 491 An issue which is discussed in the previous specifications and is of 492 particular importance for this specification relates to the usage of 493 the SDP 'crypto' attribute to generate shared secrets. When the 494 'crypto' attribute is used, the session description carrying it must 495 be encrypted, as specified in Section 8.2.1. Otherwise, an attacker 496 could get access to the shared secret and impersonate the client. 497 For session descriptions carried in SIP [4], S/MIME is the natural 498 choice to provide such end-to-end encryption. Other applications MAY 499 use different encryption mechanisms. 501 11. IANA Considerations 503 The following sections instruct the IANA to perform a set of actions. 505 11.1 Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP' SDP 'proto' 506 values 508 This section instructs the IANA to register the following two new 509 values for the SDP 'proto' field under the Session Description 510 Protocol (SDP) Parameters registry: 512 +--------------+-----------+ 513 | Value | Reference | 514 +--------------+-----------+ 515 | TCP/BFCP | RFCxxxx | 516 | TCP/TLS/BFCP | RFCxxxx | 517 +--------------+-----------+ 519 Table 3: Values for the SDP 'proto' field 521 [Note to the RFC editor: please, replace RFCxxxx with the RFC number 522 that this document will be assigned.] 524 11.2 Registration of the SDP 'floorctrl' Attribute 526 This section instructs the IANA to register the following SDP att- 527 field under the Session Description Protocol (SDP) Parameters 528 registry: 530 Contact name: Gonzalo.Camarillo@ericsson.com 532 Attribute name: floorctrl 534 Long-form attribute name: Floor Control 536 Type of attribute Media level 538 Subject to charset: No 540 Purpose of attribute: The 'floorctrl' attribute is used to 541 perform floor control server determination. 543 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 545 11.3 Registration of the SDP 'confid' Attribute 547 This section instructs the IANA to register the following SDP att- 548 field under the Session Description Protocol (SDP) Parameters 549 registry: 551 Contact name: Gonzalo.Camarillo@ericsson.com 553 Attribute name: confid 555 Long-form attribute name: Conference Identifier 557 Type of attribute Media level 559 Subject to charset: No 561 Purpose of attribute: The 'confid' attribute carries the integer 562 representation of a Conference ID. 564 Allowed attribute values: A token 566 11.4 Registration of the SDP 'userid' Attribute 568 This section instructs the IANA to register the following SDP att- 569 field under the Session Description Protocol (SDP) Parameters 570 registry: 572 Contact name: Gonzalo.Camarillo@ericsson.com 573 Attribute name: userid 575 Long-form attribute name: User Identifier 577 Type of attribute Media level 579 Subject to charset: No 581 Purpose of attribute: The 'userid' attribute carries the integer 582 representation of a User ID. 584 Allowed attribute values: A token 586 11.5 Registration of the SDP 'floorid' Attribute 588 This section instructs the IANA to register the following SDP att- 589 field under the Session Description Protocol (SDP) Parameters 590 registry: 592 Contact name: Gonzalo.Camarillo@ericsson.com 594 Attribute name: floorid 596 Long-form attribute name: Floor Identifier 598 Type of attribute Media level 600 Subject to charset: No 602 Purpose of attribute: The 'floorid' attribute associates a floor 603 with one or more media streams. 605 Allowed attribute values: Tokens 607 11.6 Registration of the SDP 'nonce' Attribute 609 This section instructs the IANA to register the following SDP att- 610 field under the Session Description Protocol (SDP) Parameters 611 registry: 613 Contact name: Gonzalo.Camarillo@ericsson.com 615 Attribute name: nonce 616 Long-form attribute name: Nonce 618 Type of attribute Media level 620 Subject to charset: No 622 Purpose of attribute: The 'nonce' attribute carried a nonce to 623 be used in the media stream (e.g., in the BFCP connection). 625 Allowed attribute values: A token 627 11.7 Registration of the crypto-suites for 'TCP/BFCP' 629 This section instructs the IANA to register the 'TCP/BFCP' media 630 transport under the SDP Security Description registry. The key 631 methods supported is "inline". The reference for the SDP security 632 description for 'TCP/BFCP' is this document. 634 The following crypto-suite needs to be registered under the 'TCP/ 635 BFCP' transport: 637 +-----------+-----------------+ 638 | Value | BFCP Identifier | 639 +-----------+-----------------+ 640 | HMAC-SHA1 | 0 | 641 +-----------+-----------------+ 643 Table 4: Values for the crypto-suite field in TCP/BFCP 645 The IANA registry for Digest Algorithms in BFCP contains references 646 to the specifications that describe the usage of each digest 647 algorithm (identified by its BFCP identifier) in BFCP. 649 At this point, there are no session parameters defined for the 'TCP/ 650 BFCP' media transport. Consequently, the IANA does not need to 651 create a session parameter subregistry under 'TCP/BFCP'. 653 12. Acknowledgments 655 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 656 Oscar Novo provided useful ideas for this document. 658 13. Normative References 660 [1] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 661 Recommendations for Security", RFC 1750, December 1994. 663 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 664 Levels", BCP 14, RFC 2119, March 1997. 666 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 667 Specifications: ABNF", RFC 2234, November 1997. 669 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 670 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 671 Session Initiation Protocol", RFC 3261, June 2002. 673 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 674 Session Description Protocol (SDP)", RFC 3264, June 2002. 676 [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 677 RFC 3548, July 2003. 679 [7] Yon, D., "Connection-Oriented Media Transport in the Session 680 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10 681 (work in progress), November 2004. 683 [8] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 684 draft-ietf-xcon-bfcp-04 (work in progress), May 2005. 686 [9] Levin, O. and G. Camarillo, "The SDP (Session Description 687 Protocol) Label Attribute", 688 draft-levin-mmmusic-sdp-media-label-00 (work in progress), 689 July 2004. 691 [10] Lennox, J., "Connection-Oriented Media Transport over the 692 Transport Layer Security (TLS) Protocol in the Session 693 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-04 694 (work in progress), July 2005. 696 [11] Handley, M., "SDP: Session Description Protocol", 697 draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. 699 [12] Andreasen, F., "Session Description Protocol Security 700 Descriptions for Media Streams", 701 draft-ietf-mmusic-sdescriptions-11 (work in progress), 702 June 2005. 704 Author's Address 706 Gonzalo Camarillo 707 Ericsson 708 Hirsalantie 11 709 Jorvas 02420 710 Finland 712 Email: Gonzalo.Camarillo@ericsson.com 714 Intellectual Property Statement 716 The IETF takes no position regarding the validity or scope of any 717 Intellectual Property Rights or other rights that might be claimed to 718 pertain to the implementation or use of the technology described in 719 this document or the extent to which any license under such rights 720 might or might not be available; nor does it represent that it has 721 made any independent effort to identify any such rights. Information 722 on the procedures with respect to rights in RFC documents can be 723 found in BCP 78 and BCP 79. 725 Copies of IPR disclosures made to the IETF Secretariat and any 726 assurances of licenses to be made available, or the result of an 727 attempt made to obtain a general license or permission for the use of 728 such proprietary rights by implementers or users of this 729 specification can be obtained from the IETF on-line IPR repository at 730 http://www.ietf.org/ipr. 732 The IETF invites any interested party to bring to its attention any 733 copyrights, patents or patent applications, or other proprietary 734 rights that may cover technology that may be required to implement 735 this standard. Please address the information to the IETF at 736 ietf-ipr@ietf.org. 738 Disclaimer of Validity 740 This document and the information contained herein are provided on an 741 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 742 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 743 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 744 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 745 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Copyright Statement 750 Copyright (C) The Internet Society (2005). This document is subject 751 to the rights, licenses and restrictions contained in BCP 78, and 752 except as set forth therein, the authors retain all their rights. 754 Acknowledgment 756 Funding for the RFC Editor function is currently provided by the 757 Internet Society.