XCON H. Khartabil
Internet-Draft Nokia
Expires: March 10, 2005 September 9, 2004
An Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) Usages for Conference Policy Manipulation and Conference
Policy Privelges Manipulation
draft-ietf-xcon-cpcp-xcap-02
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Conference Policy is defined as the complete set of rules for a
particular conference manipulated by the conference policy server.
The Conferece Policy Control Protocol (CPCP) is the protocol used by
client to manipulate the conference policy. This document defines an
XML Configuration Access Protocol (XCAP) application usage that may
be used to store and manipulate a conference policy.
There also exists an Extensible Markup Language (XML) Schema that
Khartabil Expires March 10, 2005 [Page 1]
Internet-Draft Conferencing-XCAP September 2004
enumerates the conference policy meta data that enable a user to
assign privileges to users that enables them to read and/or
manipulate parts of or the entirety of a conference policy. This
document defines an XML Configuration Access Protocol (XCAP)
application usage that may be used to store and manipulate a
conference policy priveleges XML document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. An XCAP Usage for Conference Policy Manipulation . . . . . . . 4
4.1 Application Unique ID . . . . . . . . . . . . . . . . . . 4
4.2 Resource Interdependencies . . . . . . . . . . . . . . . . 4
4.3 Additional Constraints . . . . . . . . . . . . . . . . . . 4
4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 4
4.5 Authorization Policies . . . . . . . . . . . . . . . . . . 4
4.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4
5. An XCAP Usage for Conference Policy Privileges Manipulation . 5
5.1 Application Unique ID . . . . . . . . . . . . . . . . . . 5
5.2 Resource Interdependencies . . . . . . . . . . . . . . . . 5
5.3 Additional Constraints . . . . . . . . . . . . . . . . . . 5
5.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 5
5.5 Authorization Policies . . . . . . . . . . . . . . . . . . 5
5.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1 Conference Policy Manipulation . . . . . . . . . . . . . . 5
6.1.1 Creating a Conference . . . . . . . . . . . . . . . . 5
6.1.2 Expelling a User . . . . . . . . . . . . . . . . . . . 6
6.1.3 Allowing An Expelled Participant To Join Again . . . . 6
6.1.4 Allowing Sarah to Refer Users . . . . . . . . . . . . 7
6.1.5 Removing A Conference . . . . . . . . . . . . . . . . 7
6.2 Conference Policy Privileges Manipulation . . . . . . . . 8
6.2.1 Creating Conference Policy Privilegtes . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 9
8.1.1 conference-policies . . . . . . . . . . . . . . . . . 9
8.1.2 conference-policy-privielges . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Khartabil Expires March 10, 2005 [Page 2]
Internet-Draft Conferencing-XCAP September 2004
1. Introduction
The SIP conferencing framework [8] defines the mechanisms for
multi-party centralized conferencing in a SIP environment.
Existing SIP mechanisms allow users, for example, to join and leave a
conference, as described in [5]. A centralised server, called focus,
can expel and invite users, and may have proprietary access control
lists and user privilege definitions. The Conference Policy Control
Protocol [1] defines an XML Schema that enumerates the conference
policy data elements that enable a user to define a conference
policy. This policy document may be given to a focus using a number
of transports. Mechanisms such as a web page or a voice response
system can also be used to manipulate conference policy data.
Similarily, Privileges for Manipulating a Conference Policy [2]
defines an Extensible Markup Language (XML) Schema that enumerates
the conference policy meta data that enable a user to assign
privileges to users that enables them to read and/or manipulate a
conference policy. Mechanims are also needed to manipulate such
data.
In many cases it is useful to have standardised means to manipulate
conference policy elements and conference policy privileges elements.
Two XML Configuration Access Protocol (XCAP) [6] application usages
are defined that allow for the real-time manipulation of conference
policy and conference policy privileges and meets the requirements in
[4] to store and manipulate a conference policy object and a
conference policy privileges object.
XCAP has many advantages in its use for conference policy control
protocol. It is a HTTP 1.1 based protocol that allows clients to
read, write, modify and delete application data stored in XML format
at a server. XCAP maps XML document elements and attributes to HTTP
URIs that can be directly accessed by HTTP. One application area
which has already adopted XCAP is the manipulation of event lists
[7].
For manipulation of the Conference Policy XML object, the system MAY
support the XCAP usage defined in Section 4. For manipulation of the
Conference Policy Privileges XML object, the system MAY support the
XCAP usage defined in Section 5.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
Khartabil Expires March 10, 2005 [Page 3]
Internet-Draft Conferencing-XCAP September 2004
3. Terminology
This document uses terminology from [8]. Some additional definitions
are introduced in [1].
4. An XCAP Usage for Conference Policy Manipulation
4.1 Application Unique ID
XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "conference-policies" AUID within the IETF
tree, via the IANA registration in Section 8.
4.2 Resource Interdependencies
The conference policy server MAY fill the conference URI(s), but the
client MUST propose a conference URI. If the CPS does not allow
assignments of URIs by the client, it rejects the request with a
"409" response and SHOULD include a body in the response detailing
the error. XCAP Base document [6] section 7.2.1 explains how such a
response body is constructed. The CPS MAY assign multiple conference
URIs to a conference, one for each call signaling protocol that it
supports. Section xx of [1] (Conference Settings) discusses this is
more detail.
Sidebar URIs are subject to the same behaviour.
4.3 Additional Constraints
These are defined within the XML structure definition in [1].
4.4 Naming Conventions
There are no naming conventions that need to be defined for this
application usage.
4.5 Authorization Policies
A server can allow privileged users to modify documents that they
don't own. The establishment and indication of such policies is done
by setting the authorization rules as described in [2].
4.6 MIME Type for CPCP XML Document
The MIME type for the CPCP XML document is defined in [1].
Khartabil Expires March 10, 2005 [Page 4]
Internet-Draft Conferencing-XCAP September 2004
5. An XCAP Usage for Conference Policy Privileges Manipulation
5.1 Application Unique ID
XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "conference-policy-privileges" AUID within
the IETF tree, via the IANA registration in Section 8.
5.2 Resource Interdependencies
There are no resource interdependencies that need to be defined fo
this application usage.
5.3 Additional Constraints
These are defined within the XML structure definition in [2].
5.4 Naming Conventions
There are no naming conventions that need to be defined for this
application usage.
5.5 Authorization Policies
This application usage does not modify the default XCAP authorization
policy, which is that only a user can read, write or modify their own
documents.
5.6 MIME Type for CPCP XML Document
The MIME type for the Conference Policy Privileges XML document is
defined in [2]
6. Examples
6.1 Conference Policy Manipulation
6.1.1 Creating a Conference
Continuing with the example in Section xx of [1], Alice's client uses
XCAP to transport the conference policy to the conference policy
server
PUT
http://xcap.example.com/services/conference-policies/users/Alice/conference.xml HTTP/1.1
Khartabil Expires March 10, 2005 [Page 5]
Internet-Draft Conferencing-XCAP September 2004
Content-Type: application/conference-policy+xml
[conference policy from [1] example goes here].
At exactly 2004-12-17T09:30:00-05:00, the focus sends SIP INVITE
request to Alice and a SIP REFER request to Sarah. At
2004-12-17T09:25:00-05:00, SIP INVITE requests can be accepted from
anyone at domain example.com. Any attempts to join the conference by
users in other domains are rejected.
6.1.2 Expelling a User
After the conference has started, Alice decides to expel Bob who has
joined the conference. So she modifies the authorization rule that
allows everyone at example.com to join:
PUT
http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1
Content-Type:text/plain
example.com
bob@example.com
At this point, the focus sends a SIP BYE request to Bob ending Bob's
participation in the conference. This also guarantees that Bob
cannot rejoin the conference since he is explicitly blocked. Any
attempt Bob makes in rejoining the conference will fail.
6.1.3 Allowing An Expelled Participant To Join Again
Continuing with the example above, Alice now decides to allow Bob to
join again after a period of time. She does so by rewriting parts of
the rule that blocks him from joining.
PUT
http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1
Content-Type:text/plain
Khartabil Expires March 10, 2005 [Page 6]
Internet-Draft Conferencing-XCAP September 2004
example.com
Bob can now rejoin the conference by sending a SIP INVITE request.
6.1.4 Allowing Sarah to Refer Users
Alice now decides that Sarah can ask the focus to refer users to the
conference:
PUT
http://xcap.example.com/services/conference-policies/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id="3"] HTTP/1.1
Content-Type:text/plain
sarah@example.com
true
6.1.5 Removing A Conference
Alice now decides she no longer wants this conference to exist and
therefore deletes the conference:
DELETE
http://xcap.example.com/services/conference-policies/users/Alice/conference.xml
As a result of this action, the focus sends SIP BYE requests to all
current participants in the conference. The conference server
Khartabil Expires March 10, 2005 [Page 7]
Internet-Draft Conferencing-XCAP September 2004
terminates the focus thereafter.
6.2 Conference Policy Privileges Manipulation
6.2.1 Creating Conference Policy Privilegtes
Continuing with the example in Section xx of [2], Alice's client uses
XCAP to transport the conference policy privileges to the conference
policy server
PUT
http://xcap.example.com/services/conference-policy-privileges/users/Alice/cp-privileges.xml HTTP/1.1
Content-Type: application/privileges+xml
[conference policy privileges from [2] example goes here].
7. Security Considerations
A conference document may contain information that is highly
sensitive. Its delivery to the conference server needs to happen
strictly, paying special attention to integrity and confidentiality.
Reading the document is also a security concern since the conference
policy contains sensitive information like the topic of the
conference, who is allowed to join and the URIs of the users that can
participate.
Manipulations of the conference policy have similar security issues.
Users with relevant privileges can manipulate parts of the conference
policy giving themselves and others privileges to manipulate the
conference policy, including the dial-out list and the security level
settings for a conference. This can happen because the conference
policy itself carries the identities and the authorization rules that
apply to those identities. Those authorization rules carry the
privileges that certain identities have. If an unauthorized user
gets access to this document (pretending to be someone else), s/he
can manipulate those rules giving himself and other unauthorized
users access to the conference policy. S/he can also manipulate
other parts of the conference policy under a false identity. Some of
the things that a malicious user can do include: denying users
certain privileges, giving himself floor moderation, removing users
from lists, removing rules for certain identities, giving privileges
to other malicious users, changing the media streams and changing
conference time. Therefore, it is very important that only
authorized clients are able to manipulate the conference policy. Any
conference policy transport protocol MUST provide authentication,
Khartabil Expires March 10, 2005 [Page 8]
Internet-Draft Conferencing-XCAP September 2004
confidentiality and integrity.
In the case that XCAP is used to create and manipulate a conference
policy, the XCAP base specification mandates that all XCAP servers
MUST implement HTTP Authentication: Basic and Digest Access
Authentication [9]. Furthermore, XCAP servers MUST implement HTTP
over TLS [10]. It is recommended that administrators of XCAP servers
use an HTTPS URI as the XCAP root services URI, so that the digest
client authentication occurs over TLS. By using these means, XCAP
client and server can ensure the confidentiality and integrity of the
XCAP created conference policy document and its manipulation
operations, and that only authorized clients are allowed to perform
them.
8. IANA Considerations
8.1 XCAP Application Usage IDs
8.1.1 conference-policies
Name of the AUID: conference-policies
Description: Conference policy application manipulates conference
policy at a server.
8.1.2 conference-policy-privielges
Name of the AUID: conference-policy-privileges
Description: Conference policy privileges application manipulates
conference policy privielges at a server.
9. Acknowledgements
The authors would like to thank Alan Johnston and the IETF XCON
working group for their feedback and suggestions.
10 Normative References
[1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference
Policy Control Protocol (CPCP)", Internet-Draft
I-D.draft-ietf-xcon-cpcp, September 2004.
[2] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
Conference Policy", Internet-Draft
I-D.draft-ietf-xcon-conference-policy-privileges, September
2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997.
Khartabil Expires March 10, 2005 [Page 9]
Internet-Draft Conferencing-XCAP September 2004
[4] Koskelainen, P. and H. Khartabil, "Requirements for conference
policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
progress), January 2004.
[5] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-03 (work in progress),
February 2004.
[6] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-02 (work in progress), February 2004.
[7] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence Lists",
draft-ietf-simple-xcap-list-usage-02 (work in progress),
February 2004.
[8] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-01 (work in
progress), October 2003.
[9] Franks, J., "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[10] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Author's Address
Hisham Khartabil
Nokia
P.O. Box 321
Helsinki FIN-00045
Finland
EMail: hisham.khartabil@nokia.com
Khartabil Expires March 10, 2005 [Page 10]
Internet-Draft Conferencing-XCAP September 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Khartabil Expires March 10, 2005 [Page 11]