idnits 2.17.1 draft-ietf-xcon-cpcp-xcap-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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 487), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 90 characters in excess of 72. ** There are 18 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 372 has weird spacing: '...ocument and i...' -- 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 9, 2004) is 7168 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) -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-ietf-xcon-cpcp-req - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-07) exists of draft-ietf-sipping-cc-conferencing-03 == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-02 == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-conferencing-framework (ref. '8') ** Obsolete normative reference: RFC 2617 (ref. '9') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (ref. '10') (Obsoleted by RFC 9110) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON H. Khartabil 2 Internet-Draft Nokia 3 Expires: March 10, 2005 September 9, 2004 5 An Extensible Markup Language (XML) Configuration Access Protocol 6 (XCAP) Usages for Conference Policy Manipulation and Conference 7 Policy Privelges Manipulation 8 draft-ietf-xcon-cpcp-xcap-02 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-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 March 10, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The Conference Policy is defined as the complete set of rules for a 42 particular conference manipulated by the conference policy server. 43 The Conferece Policy Control Protocol (CPCP) is the protocol used by 44 client to manipulate the conference policy. This document defines an 45 XML Configuration Access Protocol (XCAP) application usage that may 46 be used to store and manipulate a conference policy. 48 There also exists an Extensible Markup Language (XML) Schema that 49 enumerates the conference policy meta data that enable a user to 50 assign privileges to users that enables them to read and/or 51 manipulate parts of or the entirety of a conference policy. This 52 document defines an XML Configuration Access Protocol (XCAP) 53 application usage that may be used to store and manipulate a 54 conference policy priveleges XML document. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. An XCAP Usage for Conference Policy Manipulation . . . . . . . 4 62 4.1 Application Unique ID . . . . . . . . . . . . . . . . . . 4 63 4.2 Resource Interdependencies . . . . . . . . . . . . . . . . 4 64 4.3 Additional Constraints . . . . . . . . . . . . . . . . . . 4 65 4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 4 66 4.5 Authorization Policies . . . . . . . . . . . . . . . . . . 4 67 4.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4 68 5. An XCAP Usage for Conference Policy Privileges Manipulation . 5 69 5.1 Application Unique ID . . . . . . . . . . . . . . . . . . 5 70 5.2 Resource Interdependencies . . . . . . . . . . . . . . . . 5 71 5.3 Additional Constraints . . . . . . . . . . . . . . . . . . 5 72 5.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 5 73 5.5 Authorization Policies . . . . . . . . . . . . . . . . . . 5 74 5.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 5 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 6.1 Conference Policy Manipulation . . . . . . . . . . . . . . 5 77 6.1.1 Creating a Conference . . . . . . . . . . . . . . . . 5 78 6.1.2 Expelling a User . . . . . . . . . . . . . . . . . . . 6 79 6.1.3 Allowing An Expelled Participant To Join Again . . . . 6 80 6.1.4 Allowing Sarah to Refer Users . . . . . . . . . . . . 7 81 6.1.5 Removing A Conference . . . . . . . . . . . . . . . . 7 82 6.2 Conference Policy Privileges Manipulation . . . . . . . . 8 83 6.2.1 Creating Conference Policy Privilegtes . . . . . . . . 8 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 8.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 9 87 8.1.1 conference-policies . . . . . . . . . . . . . . . . . 9 88 8.1.2 conference-policy-privielges . . . . . . . . . . . . . 9 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 90 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 92 Intellectual Property and Copyright Statements . . . . . . . . 11 94 1. Introduction 96 The SIP conferencing framework [8] defines the mechanisms for 97 multi-party centralized conferencing in a SIP environment. 99 Existing SIP mechanisms allow users, for example, to join and leave a 100 conference, as described in [5]. A centralised server, called focus, 101 can expel and invite users, and may have proprietary access control 102 lists and user privilege definitions. The Conference Policy Control 103 Protocol [1] defines an XML Schema that enumerates the conference 104 policy data elements that enable a user to define a conference 105 policy. This policy document may be given to a focus using a number 106 of transports. Mechanisms such as a web page or a voice response 107 system can also be used to manipulate conference policy data. 109 Similarily, Privileges for Manipulating a Conference Policy [2] 110 defines an Extensible Markup Language (XML) Schema that enumerates 111 the conference policy meta data that enable a user to assign 112 privileges to users that enables them to read and/or manipulate a 113 conference policy. Mechanims are also needed to manipulate such 114 data. 116 In many cases it is useful to have standardised means to manipulate 117 conference policy elements and conference policy privileges elements. 118 Two XML Configuration Access Protocol (XCAP) [6] application usages 119 are defined that allow for the real-time manipulation of conference 120 policy and conference policy privileges and meets the requirements in 121 [4] to store and manipulate a conference policy object and a 122 conference policy privileges object. 124 XCAP has many advantages in its use for conference policy control 125 protocol. It is a HTTP 1.1 based protocol that allows clients to 126 read, write, modify and delete application data stored in XML format 127 at a server. XCAP maps XML document elements and attributes to HTTP 128 URIs that can be directly accessed by HTTP. One application area 129 which has already adopted XCAP is the manipulation of event lists 130 [7]. 132 For manipulation of the Conference Policy XML object, the system MAY 133 support the XCAP usage defined in Section 4. For manipulation of the 134 Conference Policy Privileges XML object, the system MAY support the 135 XCAP usage defined in Section 5. 137 2. Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [3]. 143 3. Terminology 145 This document uses terminology from [8]. Some additional definitions 146 are introduced in [1]. 148 4. An XCAP Usage for Conference Policy Manipulation 150 4.1 Application Unique ID 152 XCAP requires application usages to define a unique application usage 153 ID (AUID) in either the IETF tree or a vendor tree. This 154 specification defines the "conference-policies" AUID within the IETF 155 tree, via the IANA registration in Section 8. 157 4.2 Resource Interdependencies 159 The conference policy server MAY fill the conference URI(s), but the 160 client MUST propose a conference URI. If the CPS does not allow 161 assignments of URIs by the client, it rejects the request with a 162 "409" response and SHOULD include a body in the response detailing 163 the error. XCAP Base document [6] section 7.2.1 explains how such a 164 response body is constructed. The CPS MAY assign multiple conference 165 URIs to a conference, one for each call signaling protocol that it 166 supports. Section xx of [1] (Conference Settings) discusses this is 167 more detail. 169 Sidebar URIs are subject to the same behaviour. 171 4.3 Additional Constraints 173 These are defined within the XML structure definition in [1]. 175 4.4 Naming Conventions 177 There are no naming conventions that need to be defined for this 178 application usage. 180 4.5 Authorization Policies 182 A server can allow privileged users to modify documents that they 183 don't own. The establishment and indication of such policies is done 184 by setting the authorization rules as described in [2]. 186 4.6 MIME Type for CPCP XML Document 188 The MIME type for the CPCP XML document is defined in [1]. 190 5. An XCAP Usage for Conference Policy Privileges Manipulation 192 5.1 Application Unique ID 194 XCAP requires application usages to define a unique application usage 195 ID (AUID) in either the IETF tree or a vendor tree. This 196 specification defines the "conference-policy-privileges" AUID within 197 the IETF tree, via the IANA registration in Section 8. 199 5.2 Resource Interdependencies 201 There are no resource interdependencies that need to be defined fo 202 this application usage. 204 5.3 Additional Constraints 206 These are defined within the XML structure definition in [2]. 208 5.4 Naming Conventions 210 There are no naming conventions that need to be defined for this 211 application usage. 213 5.5 Authorization Policies 215 This application usage does not modify the default XCAP authorization 216 policy, which is that only a user can read, write or modify their own 217 documents. 219 5.6 MIME Type for CPCP XML Document 221 The MIME type for the Conference Policy Privileges XML document is 222 defined in [2] 224 6. Examples 226 6.1 Conference Policy Manipulation 228 6.1.1 Creating a Conference 230 Continuing with the example in Section xx of [1], Alice's client uses 231 XCAP to transport the conference policy to the conference policy 232 server 234 PUT 235 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml HTTP/1.1 236 Content-Type: application/conference-policy+xml 238 [conference policy from [1] example goes here]. 240 At exactly 2004-12-17T09:30:00-05:00, the focus sends SIP INVITE 241 request to Alice and a SIP REFER request to Sarah. At 242 2004-12-17T09:25:00-05:00, SIP INVITE requests can be accepted from 243 anyone at domain example.com. Any attempts to join the conference by 244 users in other domains are rejected. 246 6.1.2 Expelling a User 248 After the conference has started, Alice decides to expel Bob who has 249 joined the conference. So she modifies the authorization rule that 250 allows everyone at example.com to join: 252 PUT 253 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1 255 Content-Type:text/plain 257 258 example.com 259 bob@example.com 260 262 At this point, the focus sends a SIP BYE request to Bob ending Bob's 263 participation in the conference. This also guarantees that Bob 264 cannot rejoin the conference since he is explicitly blocked. Any 265 attempt Bob makes in rejoining the conference will fail. 267 6.1.3 Allowing An Expelled Participant To Join Again 269 Continuing with the example above, Alice now decides to allow Bob to 270 join again after a period of time. She does so by rewriting parts of 271 the rule that blocks him from joining. 273 PUT 274 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1 276 Content-Type:text/plain 278 279 example.com 280 282 Bob can now rejoin the conference by sending a SIP INVITE request. 284 6.1.4 Allowing Sarah to Refer Users 286 Alice now decides that Sarah can ask the focus to refer users to the 287 conference: 289 PUT 290 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id="3"] HTTP/1.1 292 Content-Type:text/plain 294 295 296 297 sarah@example.com 298 299 300 301 true 302 303 304 306 6.1.5 Removing A Conference 308 Alice now decides she no longer wants this conference to exist and 309 therefore deletes the conference: 311 DELETE 312 http://xcap.example.com/services/conference-policies/users/Alice/conference.xml 314 As a result of this action, the focus sends SIP BYE requests to all 315 current participants in the conference. The conference server 316 terminates the focus thereafter. 318 6.2 Conference Policy Privileges Manipulation 320 6.2.1 Creating Conference Policy Privilegtes 322 Continuing with the example in Section xx of [2], Alice's client uses 323 XCAP to transport the conference policy privileges to the conference 324 policy server 326 PUT 327 http://xcap.example.com/services/conference-policy-privileges/users/Alice/cp-privileges.xml HTTP/1.1 329 Content-Type: application/privileges+xml 331 [conference policy privileges from [2] example goes here]. 333 7. Security Considerations 335 A conference document may contain information that is highly 336 sensitive. Its delivery to the conference server needs to happen 337 strictly, paying special attention to integrity and confidentiality. 338 Reading the document is also a security concern since the conference 339 policy contains sensitive information like the topic of the 340 conference, who is allowed to join and the URIs of the users that can 341 participate. 343 Manipulations of the conference policy have similar security issues. 344 Users with relevant privileges can manipulate parts of the conference 345 policy giving themselves and others privileges to manipulate the 346 conference policy, including the dial-out list and the security level 347 settings for a conference. This can happen because the conference 348 policy itself carries the identities and the authorization rules that 349 apply to those identities. Those authorization rules carry the 350 privileges that certain identities have. If an unauthorized user 351 gets access to this document (pretending to be someone else), s/he 352 can manipulate those rules giving himself and other unauthorized 353 users access to the conference policy. S/he can also manipulate 354 other parts of the conference policy under a false identity. Some of 355 the things that a malicious user can do include: denying users 356 certain privileges, giving himself floor moderation, removing users 357 from lists, removing rules for certain identities, giving privileges 358 to other malicious users, changing the media streams and changing 359 conference time. Therefore, it is very important that only 360 authorized clients are able to manipulate the conference policy. Any 361 conference policy transport protocol MUST provide authentication, 362 confidentiality and integrity. 364 In the case that XCAP is used to create and manipulate a conference 365 policy, the XCAP base specification mandates that all XCAP servers 366 MUST implement HTTP Authentication: Basic and Digest Access 367 Authentication [9]. Furthermore, XCAP servers MUST implement HTTP 368 over TLS [10]. It is recommended that administrators of XCAP servers 369 use an HTTPS URI as the XCAP root services URI, so that the digest 370 client authentication occurs over TLS. By using these means, XCAP 371 client and server can ensure the confidentiality and integrity of the 372 XCAP created conference policy document and its manipulation 373 operations, and that only authorized clients are allowed to perform 374 them. 376 8. IANA Considerations 378 8.1 XCAP Application Usage IDs 380 8.1.1 conference-policies 382 Name of the AUID: conference-policies 383 Description: Conference policy application manipulates conference 384 policy at a server. 386 8.1.2 conference-policy-privielges 388 Name of the AUID: conference-policy-privileges 389 Description: Conference policy privileges application manipulates 390 conference policy privielges at a server. 392 9. Acknowledgements 394 The authors would like to thank Alan Johnston and the IETF XCON 395 working group for their feedback and suggestions. 397 10 Normative References 399 [1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference 400 Policy Control Protocol (CPCP)", Internet-Draft 401 I-D.draft-ietf-xcon-cpcp, September 2004. 403 [2] Khartabil, H. and A. Niemi, "Privileges for Manipulating a 404 Conference Policy", Internet-Draft 405 I-D.draft-ietf-xcon-conference-policy-privileges, September 406 2004. 408 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 409 Levels", RFC 2119, BCD 14, March 1997. 411 [4] Koskelainen, P. and H. Khartabil, "Requirements for conference 412 policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in 413 progress), January 2004. 415 [5] Johnston, A. and O. Levin, "Session Initiation Protocol Call 416 Control - Conferencing for User Agents", 417 draft-ietf-sipping-cc-conferencing-03 (work in progress), 418 February 2004. 420 [6] Rosenberg, J., "The Extensible Markup Language (XML) 421 Configuration Access Protocol (XCAP)", 422 draft-ietf-simple-xcap-02 (work in progress), February 2004. 424 [7] Rosenberg, J., "An Extensible Markup Language (XML) 425 Configuration Access Protocol (XCAP) Usage for Presence Lists", 426 draft-ietf-simple-xcap-list-usage-02 (work in progress), 427 February 2004. 429 [8] Rosenberg, J., "A Framework for Conferencing with the Session 430 Initiation Protocol", 431 draft-ietf-sipping-conferencing-framework-01 (work in 432 progress), October 2003. 434 [9] Franks, J., "HTTP Authentication: Basic and Digest Access 435 Authentication", RFC 2617, June 1999. 437 [10] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 439 Author's Address 441 Hisham Khartabil 442 Nokia 443 P.O. Box 321 444 Helsinki FIN-00045 445 Finland 447 EMail: hisham.khartabil@nokia.com 449 Intellectual Property Statement 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at 471 ietf-ipr@ietf.org. 473 Disclaimer of Validity 475 This document and the information contained herein are provided on an 476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 478 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 479 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 480 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 483 Copyright Statement 485 Copyright (C) The Internet Society (2004). This document is subject 486 to the rights, licenses and restrictions contained in BCP 78, and 487 except as set forth therein, the authors retain all their rights. 489 Acknowledgment 491 Funding for the RFC Editor function is currently provided by the 492 Internet Society.