Network Working Group A. Niemi Internet-Draft Nokia Expires: November 16, 2004 May 18, 2004 Conference Policy Authorization Rules draft-niemi-xcon-cpcp-rules-00 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 November 16, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Authorization is a key component in conference policy. Authorization rules specify who is allowed to join a conference, see floors and request them, subscribe to conference-information and so on. This document proposes an Extensible Markup Language (XML) document format for conference authorization rules. This draft is intended for discussion purposes only, and in case this approach is taken, it would need to be merged with the on-going Conference Policy Control Protocol (CPCP) work. Niemi Expires November 16, 2004 [Page 1] Internet-Draft Conference Authorization May 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions and Terminology . . . . . . . . . . . . . 3 3. Motivations for Using Common Policy Framework . . . . . . . . 3 4. Conference Permission Statements . . . . . . . . . . . . . . . 4 4.1 Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.2 Validity . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Actions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1 Conference State Events . . . . . . . . . . . . . . . 6 4.2.2 Floor Control Events . . . . . . . . . . . . . . . . . 6 4.2.3 Conference Join Handling . . . . . . . . . . . . . . . 6 4.3 Transformations . . . . . . . . . . . . . . . . . . . . . 7 4.3.1 Key Participant . . . . . . . . . . . . . . . . . . . 7 4.3.2 Floor Moderator . . . . . . . . . . . . . . . . . . . 7 4.3.3 Conference Information . . . . . . . . . . . . . . . . 7 4.3.4 Floor Holder . . . . . . . . . . . . . . . . . . . . . 8 4.3.5 Floor Requests . . . . . . . . . . . . . . . . . . . . 8 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 10.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Niemi Expires November 16, 2004 [Page 2] Internet-Draft Conference Authorization May 2004 1. Introduction A conference is an instance of a multi-party conversation. Each conference instance has an associated conference policy, which is the complete set of rules that govern the operation of the conference. One of the key components of conference policy is the set of authorization rules that specify who is allowed to join a conference, see floors and request/grant them, subscribe to conference-information notifications and so on. The current Conference Policy Control Protocol (CPCP) [5] defines the authorization policy as a combination of an Access Control List (ACL element), and a Privilege Control List (PCL element). This document proposes an alternate Extensible Markup Language (XML) document format for conference authorization rules that is based on the common policy framework [1]. It is intended that if the approach laid out in this document is acceptable to the XCON Working Group, that this Internet-Draft is then merged with CPCP [5], replacing the access control and privilege control rules defined therein. 2. Document Conventions and Terminology 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 BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations. 3. Motivations for Using Common Policy Framework The common policy framework is intended for setting policies that control access to application specific data. It has been developed in an effort to harmonise the development of both location authorization [6] and Session Initiation Protocol (SIP) presence authorization [7]. The framework includes an XML-based language for representing policy rules, and can be extended to other application domains. TBD: the below needs work... One aspect of conference authorization policy relates to participation, namely whether a particular user is allowed to join the conference or not. For example, a user would attempt to join a conference using the SIP session setup (INVITE request) at which point the conference focus would visit the authorization policy of the conference to see if that user is allowed to join. Niemi Expires November 16, 2004 [Page 3] Internet-Draft Conference Authorization May 2004 Another aspect of conference authorization policy relates to privileges within a conference. For example, a user would attempt to subscribe to the conference-information event package, at which point the conference focus would visit the authorization policy to see if that user is allowed to subscribe. Both of these modes of operation are supported by the common policy framework. In fact, the same policy language can be used to specify both types of authorization rules. The main advantage in using the common policy framework for authorization policy is that implementations of different applications can reuse a single policy language and engine. The common policy framework also includes a well-defined way of combining different rules in a manner which is privacy-safe. 4. Conference Permission Statements A conference permission statement is an XML document, formatted according to the XML schema defined in the common policy framework [1]. Each permission document is composed of three parts: conditions, actions and transformations. Conditions determine whether a particular rule applies to a request. Each action or transformation is a positive grant of permission to the conference participant, in case the conditions part evaluated to TRUE. Since each action or transformation is a positive grant of permission, different permissions can be combined in a well-defined way. As a result, the system is privacy-safe, since the lack of any actions of transformations can only result in less privileges to be granted or information to be provided to a conference participant. This section outlines the new conditions, actions and transformations defined by this document. 4.1 Conditions 4.1.1 Identity 4.1.1.1 Internpreting the "uri" Element The "identity" element is already defined in the common policy framework [1]. However, the rules for interpreting the identities in "uri" elements are left for each application to define separately. This section defines the rules for interpreting identities in "uri" elements in conferencing applications. Niemi Expires November 16, 2004 [Page 4] Internet-Draft Conference Authorization May 2004 OPEN ISSUE: Deriving user identities from the Digest authentication credentials needs further thinking. the "username" alone is not directly usable, since it may not be in a NAI format. For requests that are authenticated according to [8], the username and domain parts of the "uri" element are matched against the user and host parts of the SIP URI in the P-Asserted-Identity header field. For systems other than SIP, the identity of the user would be derived using a similar pattern. OPEN ISSUE: Do we need to state more than this? How are identities derived from users that join using POTS, H.323, etc.? 4.1.1.2 Anonymous The "anonymous" element is used to match anonymous participants. OPEN ISSUE: The CPCP requirements [3] requires that users be able to join a conference anonymously, yet anonymous Digest authentication is explicitly disallowed. Therefore it remains an open issue as to how anonymous users are identified for conference authorization purposes. 4.1.1.3 Matching Any Identity The "any" element is a new child element for the "identity" element. An "identity" condition that includes the "any" element will create a successful match for any authenticated identity. Zero or more "except" elements may also be present alongside the "any" element. A request MUST match all of the "except" element as well as the "any" element in an atomic fashion to be a sucessful match. 4.1.2 Validity The "validity" element can be set to implement conference timing. If the current time falls outside the "validity" the condition evaluates to FALSE. OPEN ISSUE: Is the "validity" element appropriate for the conferencing needs? 4.2 Actions Niemi Expires November 16, 2004 [Page 5] Internet-Draft Conference Authorization May 2004 4.2.1 Conference State Events The "allow-conference-state" element represents a boolean action. If set to TRUE, the focus is instructed to allow the subscription to conference state events, such as the SIP Event Package for Conference State [4]. If set to FALSE, the subscription to conference state events would be rejected. If this element is undefined it has a value of FALSE, causing the subscription to conference state events to be rejected. OPEN ISSUE: Is a simple block/allow sufficient here, or should the subscription handling be similar to e.g. presence, and have three states (block, confirm, allow), or possibly even four states (block, confirm, polite-block, allow)? 4.2.2 Floor Control Events The "allow-floor-events" element represents a boolean action. If set to TRUE, the focus is instructed to accept the subscription to floor control events. If set to FALSE, the focus is instructed to reject the subscription. If this element is undefined, it has a value of FALSE, causing the subscription to floor control events to be rejected. OPEN ISSUE: Is a simple block/allow sufficient here, or should the subscription handling be similar to e.g. presence, and have three states (block, confirm, allow), or possibly even four states (block, confirm, polite-block, allow)? 4.2.3 Conference Join Handling The "join-handling" element defines the actions used by the conferene focus to control conference participation. This element defines the action that the focus is to take when processing a particular request to join a conference. This element is an enumerated integer type, with defined values of: block: This action instructs the focus to deny access to the conference. This action has a value of zero and it is the lowest value of the "join-handling" element. This action is the default action taken in the absence of any other actions. confirm: This action instructs the focus to place the participant on a pending list (e.g., by parking the call on a music-on-hold server), awaiting moderator input for further actions. This action has a value of one. Niemi Expires November 16, 2004 [Page 6] Internet-Draft Conference Authorization May 2004 allow: This action instructs the focus to accept the conference join request and grant access to the conference within the instructions specified in the transformations of this rule. This action has a value of two. Note that placing a value of block for this element doesn't guarantee that a participant is blocked from joining the conference. Any other rule that might evaluate to true for this participant that carried an action whose value was higher than block would automatically grant confirm/allow permission to that participant. 4.3 Transformations 4.3.1 Key Participant When the "is-key-participant" element is set to TRUE, the joining participant is denoted as a key participant. Entry of a key-participant may trigger the conference focus to perform certain tasks, e.g., make a dial-out. If set to FALSE, the participant is not denoted as a key participant. If this element is undefined, it has a value of FALSE, causing no key participant status to be given to the participant. 4.3.2 Floor Moderator When the "is-floor-moderator" element is set to TRUE, the joining conference participant is denoted as floor moderator, meaning that they are privileged to control the floor in the conference. If set to FALSE, floor moderator privileges are not given to the conference participant. If this element is undefined, it has a value of FALSE, causing no floor moderator privileges to being granted. 4.3.3 Conference Information The "show-confeence-info" element is of type boolean transformation. If set to TRUE, conference information is shown to the conference participant. If set to FALSE, conference information is not shown to the participant. If this element is undefined, it has a value of FALSE, causing no conference information to being shown. OPEN ISSUE: Do we require more granularity for this element? Perhaps an enumerated integer type, with defined levels of information about the conference, or a set of boolean Niemi Expires November 16, 2004 [Page 7] Internet-Draft Conference Authorization May 2004 transformations, each granting a single piece of conference information, like the ability to see "sidebar" elements? 4.3.4 Floor Holder The "show-floor-holder" element is of type boolean transformation. If set to TRUE, the conference participant is able to see who is currently holding the floor. If set to FALSE, the participant is not able to see the floor holder. If this element is undefined, it has a value of FALSE, causing the floor holder to bot being shown to the participant. 4.3.5 Floor Requests The "show-floor-requests" element is of type boolean transformation. If set to TRUE, the conference participant is able to see the floor requests. If set to FALSE, the conference participant is not able to see floor requests. If this element is undefined, it has a value of FALSE, causing the floor requests to not being seen by the conference participant. 5. XML Schema ... 6. Examples This example shows a rule that would match all authenticated identities except "joe@example.com", and require moderator input before accepting them in the conference. joe@example.com confirm This example shows a rule that would match "lisa@example.com", permit access to the conference, and also name her as a key-participant and a floor moderator. Niemi Expires November 16, 2004 [Page 8] Internet-Draft Conference Authorization May 2004 lisa@example.com accept true 7. Security Considerations ... 8. IANA Considerations ... 9. Acknowledgements Hisham Khartabil, Petri Koskelainen provided useful comments and discussion. 10. References 10.1 Normative References [1] Schulzrinne, H., "Common Policy", draft-ietf-geopriv-common-policy-00 (work in progress), February 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Koskelainen, P., "Requirements for Conference Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-02 (work in progress), February 2004. [4] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-03 (work in progress), February 2004. Niemi Expires November 16, 2004 [Page 9] Internet-Draft Conference Authorization May 2004 10.2 Informative References [5] Khartabil, H. and P. Koskelainen, "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-xcap-00 (work in progress), May 2004. [6] Schulzrinne, H., "Geopriv Policy", draft-ietf-geopriv-policy-01 (work in progress), February 2004. [7] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-00 (work in progress), May 2004. [8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. Author's Address Aki Niemi Nokia P.O. Box 100 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Niemi Expires November 16, 2004 [Page 10] Internet-Draft Conference Authorization May 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. Niemi Expires November 16, 2004 [Page 11]