idnits 2.17.1 draft-ietf-mmusic-sdp-bfcp-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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 432. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (January 13, 2005) is 7042 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 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-09 == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-01 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-comedia-tls-02 Summary: 7 errors (**), 0 flaws (~~), 6 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: July 14, 2005 January 13, 2005 6 Session Description Protocol (SDP) Format for Binary Floor Control 7 Protocol (BFCP) Streams 8 draft-ietf-mmusic-sdp-bfcp-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 14, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document specifies how to describe BFCP streams in SDP session 44 descriptions. User agents using the offer/answer model to establish 45 BFCP streams use this format in their offers and their answers. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Fields in the m Line . . . . . . . . . . . . . . . . . . . . 3 52 4. The confid and userid SDP Attributes . . . . . . . . . . . . 4 53 5. The k line . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 6. The nonce Attribute . . . . . . . . . . . . . . . . . . . . 4 55 7. Association between Streams and Floors . . . . . . . . . . . 5 56 8. Certificate Choice and Presentation . . . . . . . . . . . . 5 57 9. TCP Connection Management . . . . . . . . . . . . . . . . . 6 58 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 11. Security Considerations . . . . . . . . . . . . . . . . . . 7 60 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 61 12.1 Registration of the confid Attribute . . . . . . . . . . 8 62 12.2 Registration of the userid Attribute . . . . . . . . . . 8 63 12.3 Registration of the floorid Attribute . . . . . . . . . 8 64 12.4 Registration of the nonce Attribute . . . . . . . . . . 9 65 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 66 14. Normative References . . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . 11 70 1. Introduction 72 As discussed in the BFCP specification [7], a given BFCP client needs 73 a set of data in order to establish a BFCP connection to a floor 74 control server. These data include the transport address of the 75 server, the conference identifier, and the user identifier. 77 One way for clients to obtain this information consists of using an 78 offer/answer [5] exchange. This document specifies how to encode 79 this information in the SDP session descriptions which are part of an 80 offer/answer exchange. 82 User agents typically use the offer/answer model to establish a 83 number of media streams of different types. Following this model, a 84 BFCP connection is described as any other media stream by using an 85 SDP 'm' line, possibly followed by a number of attributes encoded in 86 'a' lines. 88 2. Terminology 90 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 91 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 92 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 93 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 94 compliant implementations. 96 3. Fields in the m Line 98 According to RFC 2327 [3], the 'm'line format is the following: 100 m= 102 The media field MUST have a value of "application". 104 The port field is set following the rules in [6]. Depending on the 105 value of the 'setup' attribute (disccused in Section 9), the port 106 field contains the port the remote endpoint will initiate its TCP 107 connection to, or is irrelevant (i.e., the endpoint will initiate the 108 connection towards the remote endpoint) and should be set to a value 109 of 9, which is the discard port. Since BFCP only runs on top of TCP, 110 the port is always a TCP port. A port field value of zero has the 111 standard SDP meaning (i.e., rejection of the media stream). 113 We define two new values for the transport field: TCP/BFCP and TCP/ 114 TLS/BFCP. The former is used when BFCP runs directly on top of TCP 115 and the latter is used when BFCP runs on top of TLS, which in turn 116 runs on top of TCP. 118 The fmt (format) list is ignored for BFCP. The fmt list of BFCP m 119 lines SHOULD contain a single "*" character. 121 The following is an example of an m line for a BFCP connection: 123 m=application 20000 TCP/TLS/BFCP * 125 4. The confid and userid SDP Attributes 127 We define the 'confid' and the 'userid' SDP media-level attributes. 128 Their Augmented BNF syntax [2] is: 130 confid-attribute = "a=confid: " conference-id 131 conference-id = token 133 userid-attribute = "a=userid: " user-id 134 user-id = token 136 The confid and the userid attributes carry the integer representation 137 of a conference ID and a user ID respectively. 139 Endpoints which use the offer/answer model to establish BFCP 140 connections MUST support the confid and the userid attributes. A 141 floor control server acting as an offerer or as an answerers SHOULD 142 include these attributes in its session descriptions. 144 5. The k line 146 The floor control server MAY use an SDP 'k' line to provide clients 147 with a shared secret to be used to calculate the value of the DIGEST 148 TLVs. The following is an example of a 'k' line: 150 k=base64:c2hhcmVkLXNlY3JldA== 152 Endpoints MAY use other mechanisms (including out-of-band mechanisms) 153 to come up with a share secret. However, if the 'k' line is used in 154 the way just described, the session description containing the 'k' 155 line with the shared secret MUST be encrypted. 157 6. The nonce Attribute 159 We define the 'nonce' attribute. Its Augmented BNF syntax [2] is: 161 nonce-attribute = "a=nonce: " nonce-value 162 nonce-value = token 164 The 'nonce' attribute carries the integer representation of the nonce 165 to be used by the client in its next BFCP message (typically the 166 first message from the client) towards the floor control server. 167 This is an optimization so that the client does not need to generate 168 an initial BFCP message only to have it rejected by the floor control 169 server with an Error response containing a nonce. 171 Endpoints which use the offer/answer model to establish BFCP 172 connections SHOULD support the 'nonce' attribute. A floor control 173 server acting as an offerer or as an answerers MAY include this 174 attribute in its session descriptions. 176 7. Association between Streams and Floors 178 We define the floorid SDP media-level attribute. Its Augmented BNF 179 syntax [2] is: 181 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 183 The floorid attribute is used in BFCP 'm' lines. It defined a floor 184 identifier and, possibly, associates it with one or more media 185 streams. The token representing the floor ID is the integer 186 representation of the Floor ID to be used in BFCP. The token 187 representing the media stream is a pointer to the media stream, which 188 is identified by an SDP label attribute [8] 190 Endpoints which use the offer/answer model to establish BFCP 191 connections MUST support the 'floorid' and the 'label' attributes. A 192 floor control server acting as an offerer or as an answerer SHOULD 193 include these attributes in its session descriptions. 195 8. Certificate Choice and Presentation 197 Floor control servers follow the rules in [9] regarding certificate 198 choice and presentation. This implies that unless the floor control 199 server includes a 'fingerprint' attribute in its session description, 200 the certificate provided by the floor control server must be signed 201 by a certificate authority known to the client. 203 Endpoints which use the offer/answer model to establish BFCP 204 connections MUST support the 'fingerprint' attribute. Floor control 205 servers SHOULD include this attribute in their session descriptions 206 (no matter whether they are offers or answers). 208 When TLS is used, once the underlaying TCP connection is established, 209 the floor control server acts as the TLS server regardless of its 210 role (passive or active) in the TCP establishment procedure. 212 9. TCP Connection Management 214 The management of the TCP connection used to transport BFCP is 215 performed using the 'setup' and 'connection' attributes as defined in 216 [6]. 218 The setup attribute indicates which of the endpoints (client or floor 219 control server) initiates the TCP connection. The 'connection' 220 attribute handles TCP connection reestablishment. 222 The BFCP specification [7] describes a number of situations when the 223 TCP connection between a client and the floor control server needs to 224 be reestablished. However, that specification does not describe the 225 reestablishment process because this process depends on how the 226 connection was established in the first place. BFCP entities using 227 the offer/answer model follow the following rules. 229 When the existing TCP connection is reseted following the rules in 230 [7], the client SHOULD generate an offer towards the floor control 231 server in order to reestablish the connection. If a TCP connection 232 cannot deliver a BFCP message and times out, the entity that 233 attempted to send the message (i.e., the one that detected the TCP 234 timeout) SHOULD generate an offer in order to reestablish the TCP 235 connection. 237 Endpoints which use the offer/answer model to establish BFCP 238 connections MUST support the 'setup' and the 'connection' attributes. 240 10. Example 242 The following is an example of an offer sent by a conference server 243 to a client. For the purpose of brevity, the main portion of the 244 session description is omitted in the examples, which only show m= 245 lines and their attributes. 247 m=application 20000 TCP/TLS/BFCP * 248 k=base64:c2hhcmVkLXNlY3JldA== 249 a=setup:passive 250 a=connection:new 251 a=fingerprint:SHA-1 \ 252 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 253 a=nonce:5678 254 a=confid:4321 255 a=userid:1234 256 a=floorid:1 m-stream:10 257 a=floorid:2 m-stream:11 258 m=audio 20000 RTP/AVP 0 259 a=label:10 260 m=video 30000 RTP/AVP 31 261 a=label:11 263 Note that due to RFC formatting conventions, this document splits SDP 264 across lines whose content would exceed 72 characters. A backslash 265 character marks where this line folding has taken place. This 266 backslash and its trailing CRLF and whitespace would not appear in 267 actual SDP content. 269 The following is the answer returned by the user. 271 m=application 9 TCP/BFCP * 272 a=setup:active 273 a=connection:new 274 m=audio 25000 RTP/AVP 0 275 m=video 35000 RTP/AVP 31 277 11. Security Considerations 279 The BFCP [7], SDP [3], and the offer/answer [5] specifications 280 discuss security issues related to BFCP, SDP, and the offer/answer 281 respectively. In addition, [6] and [9] discuss security issues 282 related to the establishment of TCP and TLS connections using an 283 offer/answer model. 285 An issue which is discussed in the previous specifications and is of 286 particular importance for this specification relates to the usage of 287 the 'k' line to provide shared secrets to clients. When the 'k' line 288 is used in this way, the session description carrying it SHOULD be 289 encrypted. Otherwise, an attacker could get access to the shared 290 secret and impersonate the client. For session descriptions carried 291 in SIP [4], S/MIME is the natural choice to provide such end-to-end 292 encryption. Other applications MAY use different encryption 293 mechanisms. 295 12. IANA Considerations 297 This document instructs the IANA to register four new media-level SDP 298 attributes: 'confid', 'userid', 'floorid', and 'nonce'. 300 12.1 Registration of the confid Attribute 302 Contact name: Gonzalo.Camarillo@ericsson.com 304 Attribute name: confid 306 Type of attribute Media level 308 Subject to charset: No 310 Purpose of attribute: The 'confid' attribute carries the integer 311 representation of a Conference ID. 313 Allowed attribute values: A token 315 12.2 Registration of the userid Attribute 317 Contact name: Gonzalo.Camarillo@ericsson.com 319 Attribute name: userid 321 Type of attribute Media level 323 Subject to charset: No 325 Purpose of attribute: The 'userid' attribute carries the integer 326 representation of a User ID. 328 Allowed attribute values: A token 330 12.3 Registration of the floorid Attribute 332 Contact name: Gonzalo.Camarillo@ericsson.com 334 Attribute name: floorid 336 Type of attribute Media level 338 Subject to charset: No 340 Purpose of attribute: The 'floorid' attribute associates a floor 341 with one or more media streams. 343 Allowed attribute values: Tokens 345 12.4 Registration of the nonce Attribute 347 Contact name: Gonzalo.Camarillo@ericsson.com 349 Attribute name: nonce 351 Type of attribute Media level 353 Subject to charset: No 355 Purpose of attribute: The 'nonce' attribute carried a nonce to be 356 used in the media stream (e.g., in the BFCP connection). 358 Allowed attribute values: A token 360 13. Acknowledgments 362 Joerg Ott, Keith Drage, Alan Johnston, and Eric Rescorla provided 363 useful ideas for this document. 365 14 Normative References 367 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 368 Levels", BCP 14, RFC 2119, March 1997. 370 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 371 Specifications: ABNF", RFC 2234, November 1997. 373 [3] Handley, M. and V. Jacobson, "SDP: Session Description 374 Protocol", RFC 2327, April 1998. 376 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 377 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 378 Session Initiation Protocol", RFC 3261, June 2002. 380 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 381 Session Description Protocol (SDP)", RFC 3264, June 2002. 383 [6] Yon, D., "Connection-Oriented Media Transport in the Session 384 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-09 385 (work in progress), September 2004. 387 [7] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 388 draft-ietf-xcon-bfcp-01 (work in progress), October 2004. 390 [8] Levin, O. and G. Camarillo, "The SDP (Session Description 391 Protocol) Label Attribute", 392 draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 393 2004. 395 [9] Lennox, J., "Connection-Oriented Media Transport over the 396 Transport Layer Security (TLS) Protocol in the Session 397 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-02 398 (work in progress), October 2004. 400 Author's Address 402 Gonzalo Camarillo 403 Ericsson 404 Hirsalantie 11 405 Jorvas 02420 406 Finland 408 EMail: Gonzalo.Camarillo@ericsson.com 410 Intellectual Property Statement 412 The IETF takes no position regarding the validity or scope of any 413 Intellectual Property Rights or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; nor does it represent that it has 417 made any independent effort to identify any such rights. Information 418 on the procedures with respect to rights in RFC documents can be 419 found in BCP 78 and BCP 79. 421 Copies of IPR disclosures made to the IETF Secretariat and any 422 assurances of licenses to be made available, or the result of an 423 attempt made to obtain a general license or permission for the use of 424 such proprietary rights by implementers or users of this 425 specification can be obtained from the IETF on-line IPR repository at 426 http://www.ietf.org/ipr. 428 The IETF invites any interested party to bring to its attention any 429 copyrights, patents or patent applications, or other proprietary 430 rights that may cover technology that may be required to implement 431 this standard. Please address the information to the IETF at 432 ietf-ipr@ietf.org. 434 Disclaimer of Validity 436 This document and the information contained herein are provided on an 437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 439 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 440 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 441 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 444 Copyright Statement 446 Copyright (C) The Internet Society (2005). This document is subject 447 to the rights, licenses and restrictions contained in BCP 78, and 448 except as set forth therein, the authors retain all their rights. 450 Acknowledgment 452 Funding for the RFC Editor function is currently provided by the 453 Internet Society.