RFC 3703
Policy Core Lightweight Directory Access Protocol (LDAP) Schema
6. Extending the Classes Defined in This Document
The following subsections provide general guidance on how to create a domain-specific schema derived from this document, discuss how the vendor classes in the PCLS should be used, and explain how policyTimePeriodConditions are related to other policy conditions.6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass
In Section 4.4, there is a discussion of how, by representing policy conditions and policy actions as auxiliary classes in a schema, the flexibility is retained to instantiate a particular condition or action as either rule-specific or reusable. This flexibility is lost if a condition or action class is defined as structural rather than auxiliary. For standardized schemata, this document specifies that domain-specific information MUST be expressed in auxiliary subclasses of pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED that non-standardized schemata follow this practice as well.6.2. Using the Vendor Policy Attributes
As discussed Section 5.9, the attributes pcimVendorConstraintData and pcimVendorConstraintEncoding are included in the pcimConditionVendorAuxClass to provide a mechanism for representing vendor-specific policy conditions that are not amenable to being represented with the pcimCondition class (or its subclasses). The attributes pcimVendorActionData and pcimVendorActionEncoding in the pcimActionVendorAuxClass class play the same role with respect to actions. This enables interoperability between different vendors who could not otherwise interoperate.
For example, imagine a network composed of access devices from vendor A, edge and core devices from vendor B, and a policy server from vendor C. It is desirable for this policy server to be able to configure and manage all of the devices from vendors A and B. Unfortunately, these devices will in general have little in common (e.g., different mechanisms, different ways for controlling those mechanisms, different operating systems, different commands, and so forth). The extension conditions provide a way for vendor-specific commands to be encoded as octet strings, so that a single policy server can commonly manage devices from different vendors.6.3. Using Time Validity Periods
Time validity periods are defined as an auxiliary subclass of pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow their inclusion in the AND/OR condition definitions for a pcimRule. Care should be taken not to subclass pcimTPCAuxClass to add domain-specific condition properties. For example, it would be incorrect to add IPsec- or QoS-specific condition properties to the pcimTPCAuxClass class, just because IPsec or QoS includes time in its condition definition. The correct subclassing would be to create IPsec or QoS-specific subclasses of pcimConditionAuxClass and then combine instances of these domain-specific condition classes with the appropriate validity period criteria. This is accomplished using the AND/OR association capabilities for policy conditions in pcimRules.7. Security Considerations
The PCLS, presented in this document, provides a mapping of the object-oriented model for describing policy information (PCIM) into a data model that forms the basic framework for describing the structure of policy data, in the case where the policy repository takes the form of an LDAP-accessible directory. PCLS is not intended to represent any particular system design or implementation. PCLS is not directly useable in a real world system, without the discipline-specific mappings that are works in progress in the Policy Framework Working Group of the IETF. These other derivative documents, which use PCIM and its discipline-specific extensions as a base, will need to convey more specific security considerations (refer to RFC 3060 for more information.)
The reason that PCLS, as defined here, is not representative of any real-world system, is that its object classes were designed to be independent of any specific discipline, or policy domain. For example, DiffServ and IPsec represent two different policy domains. Each document that extends PCIM to one of these domains will derive subclasses from the classes and relationships defined in PCIM, in order to represent extensions of a generic model to cover specific technical domains. PCIM-derived documents will thus subclass the PCIM classes into classes specific to each technical policy domain (QOS, IPsec, etc.), which will, in turn, be mapped, to directory-specific schemata consistent with the PCLS documented here. Even though discipline-specific security requirements are not appropriate for PCLS, specific security requirements MUST be defined for each operational real-world application of PCIM. Just as there will be a wide range of operational, real-world systems using PCIM, there will also be a wide range of security requirements for these systems. Some operational, real-world systems that are deployed using PCLS may have extensive security requirements that impact nearly all object classes utilized by such a system, while other systems' security requirements might have very little impact. The derivative documents, discussed above, will create the context for applying operational, real-world, system-level security requirements against the various models that derive from PCIM, consistent with PCLS. In some real-world scenarios, the values associated with certain properties, within certain instantiated object classes, may represent information associated with scarce, and/or costly (and therefore valuable) resources. It may be the case that these values must not be disclosed to, or manipulated by, unauthorized parties. Since this document forms the basis for the representation of a policy data model in a specific format (an LDAP-accessible directory), it is herein appropriate to reference the data model-specific tools and mechanisms that are available for achieving the authentication and authorization implicit in a requirement that restricts read and/or read- write access to these values stored in a directory.
General LDAP security considerations apply, as documented in RFC 3377 [2]. LDAP-specific authentication and authorization tools and mechanisms are found in the following standards track documents, which are appropriate for application to the management of security applied to policy data models stored in an LDAP-accessible directory: - RFC 2829 (Authentication Methods for LDAP) - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security) Any identified security requirements that are not dealt with in the appropriate discipline-specific information model documents, or in this document, MUST be dealt with in the derivative data model documents which are specific to each discipline.8. IANA Considerations
Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [16].8.1. Object Identifiers
The IANA has registered an LDAP Object Identifier for use in this technical specification according to the following template: Subject: Request for LDAP OID Registration Person & email address to contact for further information: Bob Moore (remoore@us.ibm.com) Specification: RFC 3703 Author/Change Controller: IESG Comments: The assigned OID will be used as a base for identifying a number of schema elements defined in this document. IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema to this registration as recorded in the following registry: http://www.iana.org/assignments/smi-numbers8.2. Object Identifier Descriptors
The IANA has registered the LDAP Descriptors used in this technical specification as detailed in the following template: Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see comment Object Identifier: see comment
Person & email address to contact for further information:
Bob Moore (remoore@us.ibm.com)
Usage: see comment
Specification: RFC 3703
Author/Change Controller: IESG
Comments:
The following descriptors have been added:
NAME Type OID
-------------- ---- ------------
pcimPolicy O 1.3.6.1.1.6.1.1
pcimGroup O 1.3.6.1.1.6.1.2
pcimGroupAuxClass O 1.3.6.1.1.6.1.3
pcimGroupInstance O 1.3.6.1.1.6.1.4
pcimRule O 1.3.6.1.1.6.1.5
pcimRuleAuxClass O 1.3.6.1.1.6.1.6
pcimRuleInstance O 1.3.6.1.1.6.1.7
pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8
pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9
pcimRuleActionAssociation O 1.3.6.1.1.6.1.10
pcimConditionAuxClass O 1.3.6.1.1.6.1.11
pcimTPCAuxClass O 1.3.6.1.1.6.1.12
pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13
pcimActionAuxClass O 1.3.6.1.1.6.1.14
pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15
pcimPolicyInstance O 1.3.6.1.1.6.1.16
pcimElementAuxClass O 1.3.6.1.1.6.1.17
pcimRepository O 1.3.6.1.1.6.1.18
pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19
pcimRepositoryInstance O 1.3.6.1.1.6.1.20
pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21
pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22
pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23
pcimKeywords A 1.3.6.1.1.6.2.3
pcimGroupName A 1.3.6.1.1.6.2.4
pcimRuleName A 1.3.6.1.1.6.2.5
pcimRuleEnabled A 1.3.6.1.1.6.2.6
pcimRuleConditionListType A 1.3.6.1.1.6.2.7
pcimRuleConditionList A 1.3.6.1.1.6.2.8
pcimRuleActionList A 1.3.6.1.1.6.2.9
pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10
pcimRuleUsage A 1.3.6.1.1.6.2.11
pcimRulePriority A 1.3.6.1.1.6.2.12
pcimRuleMandatory A 1.3.6.1.1.6.2.13
pcimRuleSequencedActions A 1.3.6.1.1.6.2.14
pcimRoles A 1.3.6.1.1.6.2.15
pcimConditionGroupNumber A 1.3.6.1.1.6.2.16
NAME Type OID
-------------- ---- ------------
pcimConditionNegated A 1.3.6.1.1.6.2.17
pcimConditionName A 1.3.6.1.1.6.2.18
pcimConditionDN A 1.3.6.1.1.6.2.19
pcimValidityConditionName A 1.3.6.1.1.6.2.20
pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21
pcimActionName A 1.3.6.1.1.6.2.22
pcimActionOrder A 1.3.6.1.1.6.2.23
pcimActionDN A 1.3.6.1.1.6.2.24
pcimTPCTime A 1.3.6.1.1.6.2.25
pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26
pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27
pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28
pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29
pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30
pcimVendorConstraintData A 1.3.6.1.1.6.2.31
pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32
pcimVendorActionData A 1.3.6.1.1.6.2.33
pcimVendorActionEncoding A 1.3.6.1.1.6.2.34
pcimPolicyInstanceName A 1.3.6.1.1.6.2.35
pcimRepositoryName A 1.3.6.1.1.6.2.36
pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37
pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38
pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39
where Type A is Attribute, Type O is ObjectClass
These assignments are recorded in the following registry:
http://www.iana.org/assignments/ldap-parameters
9. Acknowledgments
We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg for doing a review of this document and making many helpful suggestions and corrections. Several of the policy classes in this model first appeared in early IETF drafts on IPsec policy and QoS policy. The authors of these drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. This document is closely aligned with the work being done in the Distributed Management Task Force (DMTF) Policy and Networks working groups. We would especially like to thank Lee Rafalow, Glenn Waters, David Black, Michael Richardson, Mark Stevens, David Jones, Hugh Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments.
10. Appendix: Constructing the Value of orderedCIMKeys
This appendix is non-normative, and is included in this document as a guide to implementers that wish to exchange information between CIM schemata and LDAP schemata. Within a CIM name space, the naming is basically flat; all instances are identified by the values of their key properties, and each combination of key values must be unique. A limited form of hierarchical naming is available in CIM, however, by using weak associations: since a weak association involves propagation of key properties and their values from the superior object to the subordinate one, the subordinate object can be thought of as being named "under" the superior object. Once they have been propagated, however, propagated key properties and their values function in exactly the same way that native key properties and their values do in identifying a CIM instance. The CIM mapping document [6] introduces a special attribute, orderedCIMKeys, to help map from the CIM_ManagedElement class to the LDAP class dlm1ManagedElement. This attribute SHOULD only be used in an environment where it is necessary to map between an LDAP-accessible directory and a CIM repository. For an LDAP environment, other LDAP naming attributes are defined (i.e., cn and a class-specific naming attribute) that SHOULD be used instead. The role of orderedCIMKeys is to represent the information necessary to correlate an entry in an LDAP-accessible directory with an instance in a CIM name space. Depending on how naming of CIM-related entries is handled in an LDAP directory, the value of orderedCIMKeys represents one of two things: - If the DIT hierarchy does not mirror the "weakness hierarchy" of the CIM name space, then orderedCIMKeys represents all the keys of the CIM instance, both native and propagated. - If the DIT hierarchy does mirror the "weakness hierarchy" of the CIM name space, then orderedCIMKeys may represent either all the keys of the instance, or only the native keys. Regardless of which of these alternatives is taken, the syntax of orderedCIMKeys is the same - a DirectoryString of the form <className>.<key>=<value>[,<key>=<value>]* where the <key>=<value> elements are ordered by the names of the key properties, according to the collating sequence for US ASCII. The only spaces allowed in the DirectoryString are those that fall within a <value> element. As with alphabetizing the key properties, the
goal of suppressing the spaces is once again to make the results of string operations predictable. The values of the <value> elements are derived from the various CIM syntaxes according to a grammar specified in [5].11. References
11.1. Normative References
[1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [2] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [3] Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [4] The Directory: Models. ITU-T Recommendation X.501, 2001. [5] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification", Version 2.2, June 14, 1999. This document is available on the following DMTF web page: http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf [6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the CIM v2.5 Core Information Model", April 15, 2002. This document is available on the following DMTF web page: http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [8] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 2001. [9] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Additional Matching Rules", RFC 3698, February 2004. [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [12] Strassner, J., policy architecture BOF presentation, 42nd IETF Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are available at the following location: http://www.ietf.org/proceedings/98aug/index.html. [13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [14] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000 [15] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. [16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
12. Authors' Addresses
John Strassner Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 Phone: +1.719.785.0648 Fax: +1.719.785.0644 EMail: john.strassner@intelliden.com Bob Moore IBM Corporation P. O. Box 12195, BRQA/B501/G206 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195 Phone: +1 919-254-4436 Fax: +1 919-254-6243 EMail: remoore@us.ibm.com Ryan Moats Lemur Networks, Inc. 15621 Drexel Circle Omaha, NE 68135 Phone: +1-402-894-9456 EMail: rmoats@lemurnetworks.net Ed Ellesson 3026 Carriage Trail Hillsborough, NC 27278 Phone: +1 919-644-3977 EMail: ellesson@mindspring.com
13. Full 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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.