SIMPLE H. Nair Internet-Draft C-COR Intended status: Standards Track S. Channabasappa, Ed. Expires: April 25, 2007 CableLabs October 22, 2006 Specifying Access controls for XCAP data models draft-nair-simple-xcap-acl-01 Status of this Memo 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. 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 April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 1] Internet-Draft Access controls for XCAP data models October 2006 Abstract This document presents the need, and a proposal for defining access control definitions for data elements, defined using XML Schemas for use with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case for access control definitions . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Defining access controls . . . . . . . . . . . . . . . . . . . 7 4.1. Basic access permissions . . . . . . . . . . . . . . . . . 7 4.1.1. Relation to XCAP operations. . . . . . . . . . . . . . 7 4.1.2. Actors . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Illustration of basic permission usage. . . . . . . . 9 4.2. Pre-defined access controls: access levels . . . . . . . . 11 5. XML Schema for access controls . . . . . . . . . . . . . . . . 14 5.1. XML Schema definition for access specification . . . . . . 14 5.2. Description of schema definitions. . . . . . . . . . . . . 19 5.2.1. Types . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.2. Attributes . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. Elements . . . . . . . . . . . . . . . . . . . . . . . 21 6. Specifying access controls . . . . . . . . . . . . . . . . . . 24 6.1. Referencing access control definitions . . . . . . . . . . 24 6.2. Inline access specification . . . . . . . . . . . . . . . 24 6.3. Default access levels . . . . . . . . . . . . . . . . . . 24 7. Enforcing access controls . . . . . . . . . . . . . . . . . . 26 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 2] Internet-Draft Access controls for XCAP data models October 2006 1. Introduction XCAP ([ID-XCAP]) is a protocol specification presented in the IETF that can be used to manipulate per-user data in SIP User Agents (UAs). It is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Usage of XML in XCAP raises requirements beyond the scope of the actual protocol - like access control - the focus of this document. As a clarification, the focus of this document is purely document content level access controls. Standards such as the OASIS eXtensible Access Control Markup Language (XACML) specifications focus on authorization of requests and decision information and for those reasons are, considered too abstract and complex for document content level access controls. Access control definitions need to be clear, concise, and easy to specify and comprehend. Further, to accommodate existing XML Schema definitions, it may be necessary to specify ACL definitions that can be used with minimal or no modifications to such XML Schemas. However, this document also defines means for newly defined schemas to allow more concise / convenient access definitions. This document presents multiple options for defining access controls that can be employed by XML Schema ([XMLSchemaI] and [XMLSchemaII]) based data models used by XCAP deployments. Further, this document utilizes XPATH ( [XPath]) to identify specific elements within an XML document, when required. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 3] Internet-Draft Access controls for XCAP data models October 2006 2. Use Case for access control definitions Note: This use case is derived in part from "Use Case 2: Access Control Definitions and XML-based configuration methodologies" as illustrated in [ID-SIPUA-CFG-MGMT] Access control definitions allow data model designers to choose access rights and restrictions for the defined data elements. Most everyone is familiar with the UNIX ACL management associated with the file system: each file has read/write/execute access rights for the owner, group, and others. The View-based Access Control Model (VACM) for SNMP is also a good reference as it is applied to configuration ([RFC3415]). In this use case, we look at the change in data ownership that is introduced by XML-based configuration models used with XCAP and illustrate that access control definitions are a necessity. Use case description: A SIP client is configured using the SIPPING configuration framework [ID-SIPPING-CONFIG] and [ID-XCAP]. Changes in the configuration data elements may occur at multiple levels (write access): based on end- user settings on the SIP device, remote configuration changes (end- user accessing a web-based interface to change settings or a service operator updating the config), or other means (software updates from device manufacturer changing some default configuration parameters, etc.). Furthermore, the presentation of some configuration data (read access) may also have to be controlled: not all users of a client may be allowed to change the settings, some settings may be hidden by the protocol stacks, device manufacturers or service providers so that end-users may not misconfigure the device and disrupt the service. Note that the mechanism by which the configuration changes is not a factor in this use case: a configuration change may be made via a custom user interface on the SIP device or application, an end-user or operator controlled CLI, or remote web-based applications used by Customer Service Representatives (CSRs). Problem statement: How does the designer of the XML schema specify access rights (read, write, update, delete) for each data element and for each actor (end- user, client, network elements) in an interoperable manner? This is illustrated in Figure 1. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 4] Internet-Draft Access controls for XCAP data models October 2006 --------- ------------- | Network | | Application | | Element | | Server | --------- ------------- | | | | | | | | | | ----- | ________ | |(CSR)| | / \ | ----- | | XCAP | | | | | SERVER | | | | | | | | \ | -------- | / V ---> ||<>||<--- ------------ | -------- |<----------------- | Application| \________/ ------------ ^ ^ | | --- --- | | V | ------ ------ |SIP UA| |WEB-UI| ------ ------ \ / -------- |END-USER| -------- Figure 1: Illustration of an XCAP usage and the need for access controls There are no currently known access control specifications for XCAP. Thus, there is a need to propose access control definitions, keeping in mind various possible actors. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 5] Internet-Draft Access controls for XCAP data models October 2006 3. 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 RFC 2119 [RFC2119]. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 6] Internet-Draft Access controls for XCAP data models October 2006 4. Defining access controls 4.1. Basic access permissions This document defines the following basic access permissions that MUST be supported by all complying data models: o Create: Actor has the ability to create the element. o Read: Actor has the ability to read the contents of an existing element. o Update: Actor has the ability to modify the contents of an existing element. o Delete: Actor has the ability to delete an existing element. 4.1.1. Relation to XCAP operations. This section describes the meaning of the operations defined above to XCAP [ID-XCAP] operations. 4.1.1.1. Create or Replace a Document An XCAP operation that creates a document requires 'Create' permission for the root element of the document. An XCAP operation that replaces a document requires 'Update' permission for the root element of the document. Section 7.1 of [ID-XCAP] describes the conditions that distinguish an operation as a create or replace operation. 4.1.1.2. Delete a Document An XCAP operation that deletes a document requires 'Delete' permission for the root element of the document. 4.1.1.3. Fetch a Document An XCAP operation that fetches a document requires 'Read' permission for the root element of the document. 4.1.1.4. Create or Replace an Element An XCAP operation that creates an element requires 'Create' permission for the element being created. An XCAP operation that replaces an element requires 'Update' permission for the element being replaced. Section 7.4 of [ID-XCAP] describes the conditions that distinguish an operation as a create or replace operation. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 7] Internet-Draft Access controls for XCAP data models October 2006 4.1.1.5. Delete an Element An XCAP operation that deletes an element requires 'Delete' permission for the element being deleted. 4.1.1.6. Fetch an Element An XCAP operation that fetches an element requires 'Read' permission for the element being fetched. 4.1.1.7. Create or Replace an Attribute An XCAP operation that creates an attribute requires 'Create' permission for the attribute being created. In the absence of such a permission, it requires 'Update' permission for the containing element. An XCAP operation that replaces an attribute requires 'Update' permission for the attribute being created. Section 7.7 of [ID-XCAP] describes the conditions that distinguish an operation as a create or replace operation. 4.1.1.8. Delete an Attribute An XCAP operation that deletes an attribute requires 'Delete' permission for the attribute. In the absence of such a permission, it requires 'Update' permission for the containing element. 4.1.1.9. Fetch an Attribute An XCAP operation that fetches an attribute requires 'Read' permission for the attribute. 4.1.1.10. Fetch Namespace Bindings An XCAP operation that fetches the namespace bindings for an element requires 'Read' permission for the element. 4.1.1.11. Conditional Operations When a client invokes conditional operations, access controls SHOULD be performed before conditions specified are checked. 4.1.2. Actors As illustrated in the Use Case, there may be various actors, each with varying 'access control permissions'. The following are assumed in this document: Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 8] Internet-Draft Access controls for XCAP data models October 2006 o Given that actors may be specific to data models and supported architectures, this document neither defines nor constrains the definition of actors outside of an 'XCAPServer'. It is assumed that each actor specified refers to one or more 'entities' which have some characteristics and are defined in an external schema or document. o The actor termed as 'XCAPServer', in the context of this document is an actor representing an XCAP Server which, by default, has all possible access permissions and is the governing body enforcing the defined access controls It is assumed that the identity of the actor is established through authentication mechanisms used by the XCAP server. The specific authentication mechanisms used by an XCAP server are out of the scope of this document. 4.1.3. Illustration of basic permission usage. The following example illustrates a sample definition of the basic access controls for actors defined by another XML Schema (urn:ietf:params:xml:schema:xcap-acl) Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 9] Internet-Draft Access controls for XCAP data models October 2006 1. 2. 3. 4. 5. /ns1:Node1/ns1:Node2 7. 9. 11 13 15 17 18 19 .... 20 Figure 2: Sample access control definitions An explanation of the access specification is as follows: o Line 1 identifies the file as an XML 1.0 document using the UTF-8 character encoding. o Line 2 contains the top level element of the document and its namespace - it identifies the document as being an access declarations document. o Line 3 begins the access specifications for a particular document. It identifies the document referenced by a URL o Line 4 begins an access specification for the document referenced in line 3. o Lines 5, 6 define the part of the document that this access specification applies to. The contents of the 'acl:node' element is an XPath reference to the target node within the referenced document. o Lines 7, 8 define one permission for the node referenced in Line 6. It uses assigns the predefined 'read' permission to the predefined actor 'User'. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 10] Internet-Draft Access controls for XCAP data models October 2006 o Lines 9, 10 assign the predefined 'create' permission to the predefined actor 'UE'. o Lines 9-16 define more permissions. o Lines 17, 18 close the access and document elements respectively. This example only specifies one access definition for this document. o Line 20 closes the access specification document. 4.2. Pre-defined access controls: access levels While the access permissions as described in the example above, form building blocks for defining access controls, specific applications would tend to frequently use combinations of permissions. For example, The actor 'UserA' who has permissions for 'update' on element 'Node1', frequently also has permissions for, 'read' on element 'Node1' Additionally, in many cases it is beneficial to group actors together to assign them permissions. For example: o An element such as 'Node1', for the actor 'UserA', may have access permissions for 'create' and 'read' o An element such as 'Node2', for the actor 'NetworkElementA', may have access permissions for 'create', 'read', 'update' and 'delete' Additionally, in many scenarios, multiple actors may have the same permissions. For e.g: o 'UserA', 'UserB' and 'UserC' subscribe to the same service 'S1' and hence belong to the category 'XYZUsers' o 'ApplicationServer1' and 'ApplicationServer2' provide the same service 'S1' and hence belong to the category 'AppServersS1' Further, it is convenient to combine both these usages - assigning multiple permissions to users and assigning permissions to multiple users, to use a common notation. For example: o For certain elements of service 'S1', actors 'ApplicationServer1' and 'ApplicationServer2' have 'create' and 'read' permission when Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 11] Internet-Draft Access controls for XCAP data models October 2006 'ApplicationServer3' and 'ApplicationServer4' have only 'read' and 'update' permission o Service 'S2', frequently uses combinations of permissions where all actors of the category 'untrusted equipment' are treated equal with only 'read' permissions and all actors of the category 'trusted equipment' are treated equal with 'read' and 'update' Permissions. Allowing for such categories which combine multiple 'actors' and 'basic permissions' may not only be beneficial for data modeling, but also make access control definitions simpler to comprehend and enforce. This document allows for this by allowing pre-defined collections of permissions termed 'access levels' o For the purpose of this document, an access level is defined as a named collection of permissions. An access level may specify permissions for multiple operations and multiple actors. An example of such an aggregation is as shown in the example shown below. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 12] Internet-Draft Access controls for XCAP data models October 2006 1 3 4 7 10 13 16 19 22 23 Figure 3: Example of access levels The example defines a new access level termed 'S1NetworkElementACLS' which specifies access permissions for multiple network elements (A, B and C). Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 13] Internet-Draft Access controls for XCAP data models October 2006 5. XML Schema for access controls This document uses an XML Schema to define the format of access control specifications. 5.1. XML Schema definition for access specification This section describes the XML schema used in this document. Type of pricipal that an ACL applies to. Base type for actor entries Standard actor names Type of operation Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 14] Internet-Draft Access controls for XCAP data models October 2006 Base type for operations Standard operations Standard / predefined access levels. The value must be either an absolute URL or a URN. The semantics of the access level identified by a given URI are defined by the naming authority identified by the URI Access level for the containing element Attributes used in a permission definition Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 15] Internet-Draft Access controls for XCAP data models October 2006 The actor this access level specification applies to. The operation that is allowed. Each element describes the access allowed for a particular actor NetworkWriteable Access level declarations for a given node within the current document Node is an XPath reference to a node within the current document. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 16] Internet-Draft Access controls for XCAP data models October 2006 A reference to a predefined set of permissions. Schema complex type for a collection of access specifications Access level declarations for a given node within the current document Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 17] Internet-Draft Access controls for XCAP data models October 2006 The access control element specifies one of either an inline access control specification for the container document, or a reference to an external document. Top level element for an external access specification document Access definitions for a document Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 18] Internet-Draft Access controls for XCAP data models October 2006 Top level element for en external access level specification document Identifies the access level. This ID is to be used as fragment identifier for external references. 5.2. Description of schema definitions. This section describes the types, elements and attributes defined in this schema. 5.2.1. Types This section describes the major Schema types defined by this schema and their semantics. These types are used for the values of the Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 19] Internet-Draft Access controls for XCAP data models October 2006 elements defined below. 5.2.1.1. accessLevelType The XML Schema simple type accessLevelType denotes a URI that identified a predefined access level. It has a schema type of anyURI. The URI value used as an access level MUST be either an absolute URL or a URN. The semantics of a given URI value is defined by the naming authority identified by the URI. 5.2.1.2. baseOperationType The XML Schema simple type baseOperationType denotes a URI that identifies an operation. It has a schema type of anyURI. The URI value used to identify an operation MUST be either an absolute URL or a URN. The semantics of a given URI value is defined by the naming authority identified by the URI. 5.2.1.3. stdOperationsType The XML Schema simple type stdOperationsType is an extension of the baseOperationType that enumerates some predefined operations. The defined values consist of the namespace for this schema suffixed with a suffix. The defined values use suffix values of :create, :read, :update, and :delete that respectively identify operations that create a new node, reads a node, updates an existing node, or deletes a node. 5.2.1.4. operationsType The XML Schema type operationsType is a union of baseOperationType and stdOperationsType. That is, it is an 'open enumeration' of URI values with certain predefined values, but open to other values defined elsewhere. 5.2.1.5. baseActorType The XML Schema simple type baseActorType denotes a URI that identifies an actor. It has a schema type of anyURI. The URI value used to identify an actor MUST be either an absolute URL or a URN. The semantics of a given URI value are defined by the naming authority identified by the URI. 5.2.1.6. stdActorsType The XML Schema simple type stdActorsType is an extension of the baseActorType that enumerates some predefined operations. The defined values that consist of the namespace for this schema suffixed Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 20] Internet-Draft Access controls for XCAP data models October 2006 with a suffix of either :Network, :SipUA, :User , which identify the Network / service provider, the User equipment, and the end user respectively. 5.2.1.7. actorType The XML Schema type actorType is a union of baseActorType and stdActorsType. That is, it is an 'open enumeration' of URI values with certain predefined values, but is open to other values defined elsewhere. 5.2.1.8. documentAclType The XML Schema complex type documentAclType defines the common content of access control specifications within and external to the target documents. It consists of a sequence of 'access' elements that define the access for various nodes within that document. 5.2.2. Attributes This section describes the XML attributes defined in this schema. 5.2.2.1. my-access-level The attribute my-access-level is an attribute of type accessLevel. It is used to specify access levels for elements from this same schema. Elements from this schema can be used inline in other XML Schemas. Instances of this schema may be exposed via XCAP when used as standalone access control documents. In such cases this attribute provides a means to unambiguously specify the access controls on the access control specifications itself. 5.2.3. Elements This section describes the XML elements defined in this schema. 5.2.3.1. access The XML Schema element access describes the access permissions on a particular node. The node is identified through an XPath expression. The allowed permissions are specified by a combination of an access level reference an element 'access-level-ref' of type accessLevelType and a collection of 'permission' elements. 5.2.3.2. access-control The access-control element is the container element for inline access control specifications in other schemas. Schemas may include this Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 21] Internet-Draft Access controls for XCAP data models October 2006 element within their top level elements to provide a location to specify access control within the document. This element may also be used to provide an inline reference to an external access control specification document. This is done using the source attribute of this element. The source attribute is a URL that identifies the external document that contains the access control specifications. When used with XCAP, the source attribute SHOULD be a relative URL. If the value of this attribute is a relative URL it MUST be treated as relative to the XCAP ROOT of the document that contains it. The source attribute and the access elements within the access- control element are mutually exclusive. Documents SHOULD NOT contain both of these. Implementations MUST ignore the source attribute if the access-control element contains access elements. 5.2.3.3. access-declarations The access-declarations element is the top level element for a standalone access control specification document. It consists of multiple 'document' elements each of which identifies a document and the access restrictions that apply to it. The document element has a 'source' attribute that identifies the document to which the contained access specifications apply. This source attribute is mandatory. An access-declarations document MUST NOT contain multiple 'document' elements that refer to the same document. 5.2.3.4. access-level-declaration The element access-level-declarations is the top level element for a standalone access level definition document (See Section 4.2) This element contains multiple access-level elements, each of which have an ID attribute and contain permission elements. The access-level-declarations element may be used to define access level identifiers. For this use, the access-level-declarations document must be available at a URL accessible to all actors involved. Based on such a document accessLevel identifiers (URLs) may be constructed consisting of an absolute URL for the definition document and a fragment identifier that corresponds to the 'id' attribute of an access level specified within that document. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 22] Internet-Draft Access controls for XCAP data models October 2006 5.2.3.5. permission The permission element is used to specify a single permission. It has two attributes, an actor attribute of type actorType that identifies the actor for which an access for an operation is granted, and an operation attribute of type operationType that identifies the operation that is permitted. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 23] Internet-Draft Access controls for XCAP data models October 2006 6. Specifying access controls This section describes mechanisms to specify access controls. 6.1. Referencing access control definitions A person designing a new XML Schema for a document accessed through XCAP can incorporate support for access controls by including an '' element within the top-level element in the schema.: XML Schemas that include this element SHOULD include it as a single optional second level element (i.e. immediate child element of the top level element of the document). The element can contains multiple elements. Each access element references a node within the containing document and specifies permissions for it. The can also reference an external access control document through it's 'source' attribute. The value of the 'source' attribute is a URL that refers to an access definitions document (such as the one in the example shown in Figure 2 in section 4.1) 6.2. Inline access specification To allow inline access specifications, this document permits predefined access levels to be referenced directly in the element it applies to. This is done by including the acl:access-level attribute in the element it applies to. Note that utilizing this facility requires the schema to allow such an attribute. Many standard XML Schema definitions allow arbitrary attributes from other namespaces to be included in an element (through the use of the 'anyAttribute' declaration in their XML Schema definitions). 6.3. Default access levels XML Schema authors that wish to support access control MAY also want to specify suggested default values for access. This can be done by including elements in the element of a declaration in XML Schema. The following XML Schema snippet illustrates this. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 24] Internet-Draft Access controls for XCAP data models October 2006 ... ... ... Figure 5: Specifying default access levels Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 25] Internet-Draft Access controls for XCAP data models October 2006 7. Enforcing access controls As described earlier, permissions for a node in a document may be specified in several ways. They may be specified inline through the acl: access-level attribute on an element, they may be specified through inline permissions in an access-control element in the same document, or they may be specified externally in an access control specification document. In addition the schema of the document may itself recommend a default access level for its elements. Further, it is useful to allow / require that, the permissions defined on an element to also apply to its contents (i.e child elements) as it simplifies the specification of access by aggregation. It is therefore likely that multiple, potentially conflicting permissions may apply from these sources to a given node. For the purpose of this discussion, permissions specified in the XML schema for a document are called 'default permissions' and permissions defined through other means are called 'explicit permissions'. The node on which an operation is being performed is called 'the node in question'. A node may be an element, or attribute that is affected by an operation. This document recommends the following policy for combining multiple access specifications. The explicit permissions defined for a node are derived from each of the sources in the following order: 1. Access specified by an inline acl:access-level attribute has the highest precedence and is considered first. 2. If an inline acl:access-level attribute is not found, then the document is checked for an inline acl:access-control element that specifies access control for the node in question. 3. If no such element is found, and if the application uses an external access specification document at a well-known location, then this external access specification document is checked for an access specification that applies to the current document and the node in question. Note: the search among the various sources is for the presence of an explicit access control specification, not for a specific permission. This is because, the format is based on a default policy of deny with explicit permissions. Therefore the absence of a permission in an explicit access specification implies denial. The permission that apply to an operation are then determined as follows. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 26] Internet-Draft Access controls for XCAP data models October 2006 1. If the node in question has explicit permissions, those permissions apply. 2. Otherwise, the effective explicit permissions that apply to a node are the permissions defined to apply to the node closest to the node in question on the 'parent' axis starting from the node in question. (i.e the permission defined to apply on the closest parent node of the node in question applies.) *Explain, precendence between inline vs parent) If no explicit permission is found to apply to the node in question then the default permissions defined by its Schema is used. Here again, the permission that is defined for the node that is closest along the parent axis, to the node in question is used. Access controls are performed by checking permissions that apply to the node on which an XCAP operation is performed. Irrespective of the access specified, server policy MAY deny an attempt to create modify or delete the access control elements or attributes in a document through XCAP for some or all clients. (i.e. the server may disallow modification of permissions through XCAP, irrespective of the permissions that apply to that node.) Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 27] Internet-Draft Access controls for XCAP data models October 2006 8. Open Issues The following items are yet to be finished to complete this draft proposal: o We may need an exception to the 'denied unless explicitly permitted' rule for the 'Read' permission, as it may be in conflict with XCAP. o verify the XML Schema and examples for completeness o obtain feedback on default, inline and external specification methods and list the pros and cons o obtain feedback from the XCAP community for constraints not considered by this version o revisit the security considerations Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 28] Internet-Draft Access controls for XCAP data models October 2006 9. Acknowledgments The authors of this draft wish to thank members of the CableLabs PacketCable focus teams and various other IETF participants who contributed directly or indirectly to the content presented in this draft. Specifically, the following individuals are recognized (in alphabetical order): Jean-Francois Mule, Josh Littlefield and Thomas Clack. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 29] Internet-Draft Access controls for XCAP data models October 2006 10. Security Considerations This document specifies a way to define access control for XML Schema data elements for use with XCAP. Since the access controls are also defined using XML, and can be part of an external document (as a Schema), or part of the actual document whose access controls it defines, there is a need to ensure that only authorized elements can modify the access controls themselves. This can be accomplished by enforcing configured access controls on the XCAP Server or by specifying access controls for the access control elements. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 30] Internet-Draft Access controls for XCAP data models October 2006 11. IANA Considerations A namespace needs to be assigned for the schema in this document. This document uses the namespace 'urn:ietf:params:xml:schema:xcap-acl' as a place holder until one is assigned. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 31] Internet-Draft Access controls for XCAP data models October 2006 12. References 12.1. Normative References [ID-XCAP] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", May 2006. [XMLSchemaI] W3C Recommendation, "XML Schema Part 1: Structures Second Edition", Oct 2004. [XMLSchemaII] W3C Recommendation, "XML Schema Part 2: Datatypes Second Edition", Oct 2004. [XPath] W3C Recommendation, "XML Schema Part 1: Structures Second Edition", Oct 2004. 12.2. Informative References [ID-SIPPING-CONFIG] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", March 2006. [ID-SIPUA-CFG-MGMT] Channabasappa, S. and J-F. Mule, "Use Cases and Considerations for SIP Client Configuration and Management", Feb 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 32] Internet-Draft Access controls for XCAP data models October 2006 Authors' Addresses Harindranath P R Nair C-COR 1825 NW 167th Place Beaverton, OR 97006 USA Email: hnair@c-cor.com Sumanth Channabasappa (Editor) CableLabs 858 Coal Creek Circle Louisville, Co 80027 USA Email: sumanth@cablelabs.com Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 33] Internet-Draft Access controls for XCAP data models October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nair & Channabasappa, Ed. Expires April 25, 2007 [Page 34]