Network Working Group D. Pluta Internet-Draft Technische Universitaet Muenchen Intended status: Standards Track W. Hommel Expires: September 26, 2010 Leibniz Supercomputing Centre March 25, 2010 Lightweight Directory Access Protocol (LDAP): Server Side Current Time Matching - Matching Rules and Syntaxes draft-pluta-ldap-srv-side-current-time-match-00.txt Abstract This document extends the Lightweight Directory Access Protocol (LDAP) to support server side current time matching. Matching of attribute values against an LDAP server's current time offers additional functionality with regard to authorization and fulfills enhanced data privacy requirements for restrictive environments. Therefore this specification defines four additional syntaxes and related matching rules useful for extensible matching in association with these syntaxes. In addition and for general use the matching rules defined in this document are also applicable to any attribute type definitions that are using the 'Generalized Time' syntax. This specification also contains restrictive attribute type definitions demonstrating the usage of the introduced syntaxes and matching rules. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. Pluta & Hommel Expires September 26, 2010 [Page 1] Internet-Draft LDAP Server Side Current Time Matching March 2010 This Internet-Draft will expire on September 26, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Pluta & Hommel Expires September 26, 2010 [Page 2] Internet-Draft LDAP Server Side Current Time Matching March 2010 Table of Contents 1. Background and Intended Use . . . . . . . . . . . . . . . 4 2. Syntaxes and Matching Rules Overview . . . . . . . . . . . 4 2.1. Syntax to Matching Rule Dependent Realationship . . . . . 5 2.2. Matching Rule Categories and Differentiations . . . . . . 6 3. Syntax Definitions . . . . . . . . . . . . . . . . . . . . 6 3.1. Matching Rule Assertion Value Syntaxes . . . . . . . . . . 7 3.1.1. now - LDAP Server's Current Time . . . . . . . . . . . . . 7 3.1.2. nowOffset - Chronological Offset Relative to the Server's Current Time . . . . . . . . . . . . . . . . . . 7 3.2. Attribute Value Syntaxes . . . . . . . . . . . . . . . . . 9 3.2.1. nowBefore . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. nowBeforeOffset . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. nowAfter . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. nowAfterOffset . . . . . . . . . . . . . . . . . . . . . . 10 4. Matching Rule Definitions . . . . . . . . . . . . . . . . 11 4.1. nowOrEarlierMatch . . . . . . . . . . . . . . . . . . . . 11 4.2. nowOrEarlierOffsetMatch . . . . . . . . . . . . . . . . . 11 4.3. nowOrLaterMatch . . . . . . . . . . . . . . . . . . . . . 12 4.4. nowOrLaterOffsetMatch . . . . . . . . . . . . . . . . . . 13 5. Schema: Attribute Types and Object Classes . . . . . . . . 14 5.1. Attribute Type: notValidBefore . . . . . . . . . . . . . . 14 5.2. Attribute Type: notValidAfter . . . . . . . . . . . . . . 15 5.3. Object Class: validity . . . . . . . . . . . . . . . . . . 15 6. Root DSE attributes . . . . . . . . . . . . . . . . . . . 15 6.1. supportedFeature . . . . . . . . . . . . . . . . . . . . . 15 6.2. serverTime . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Discovering and Using Server Side Current Time Matching Support . . . . . . . . . . . . . . . . . . . . . 16 7.1. Querying the supportedFeature root DSE attribute . . . . . 16 7.2. Querying the Schema . . . . . . . . . . . . . . . . . . . 16 7.3. Querying the root DSE for the Server's Current Time . . . 16 7.4. Operational Attribute 'serverTime' . . . . . . . . . . . . 16 7.5. Client using server side time matching . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . 17 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 10.1. Object Identifier Registration . . . . . . . . . . . . . . 17 10.2. LDAP Descriptors . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 20 Pluta & Hommel Expires September 26, 2010 [Page 3] Internet-Draft LDAP Server Side Current Time Matching March 2010 1. Background and Intended Use The LDAP Protocol [RFC4510] is extensible. Extensions include Schema, Syntaxes, and Matching Rules as well as extensions related to other aspects of the protocol. LDAP search filter expressions are used to match (compare) stored attribute values against search filter assertion values on the server side. The LDAP standard defines the 'Generalized Time' syntax and its associated matching rules ('generalizedTimeMatch' and 'generalizedTimeOrderingMatch') within [RFC4517]. Attribute type definitions using the 'Generalized Time' syntax do offer support for storing time-stamp values in compliance to the syntax's definition. During search operations the associated matching rules are used to compare these attributes' values against a constant attribute assertion value specified by the client. This document introduces dynamic matching possibilities for time- stamp attribute values. Dynamic comparison of time-stamp attributes' values against an LDAP server's current time offers enhanced features for various LDAP based system management use cases (e.g. authorization). Furthermore this feature builds the basis with regard to advanced LDAP server side data privacy requirements: in combination with appropriate access control definitions LDAP servers are enabled to temporarily mask distinct entries and inhibit their extradition to an LDAP client. As the LDAP server's current time (as used in this specification) the server-sided time-stamp at the instant of the incoming LDAP client request MUST be taken. That means this time-stamp value has to be constant for the whole request's operations. The time-stamp value MUST NOT change for the operations of a request, e.g. all entries contained in a request's result set are compared against a per operation constant time-stamp value. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]. 2. Syntaxes and Matching Rules Overview The matching rules associated with the 'Generalized Time' attribute value syntax (as specified in [RFC4517]) offer the possibility to match stored attribute time-stamp values against statically provided LDAP search filter expression values (matching rule assertion values). Pluta & Hommel Expires September 26, 2010 [Page 4] Internet-Draft LDAP Server Side Current Time Matching March 2010 Next to the four additional attribute value syntaxes (defined in Section 3) this document also specifies four dedicated matching rules (defined in Section 4). In addition these matching rules SHALL be applicable to attribute type definitions which are making use of the 'Generalized Time' syntax. The concerned matching rules are named 'nowOrEarlierMatch' (see Section 4.1), 'nowOrEarlierOffsetMatch' (see Section 4.2), 'nowOrLaterMatch' (see Section 4.3), and 'nowOrLaterOffsetMatch' (see Section 4.4). 2.1. Syntax to Matching Rule Dependent Realationship The dependencies between the matching rules and their supported syntaxes are illustrated by the following matrix: +-------+----------+---------+----------------+---------------+---+ |Syn/MR |nowBefore |nowAfter |nowBeforeOffset |nowAfterOffset |gT | +-------+----------+---------+----------------+---------------+---+ |nOEM | X | - | X | - | X | |nOLM | - | X | - | X | X | |nOEOM | - | - | X | - | X | |nOLOM | - | - | - | X | X | +-------+----------+---------+----------------+---------------+---+ |gTMatch| - | X | - | X | X | +-------+----------+---------+----------------+---------------+---+ +----------------------------------------+ | Legend: | | | | Matching Rules (MR): | | nOEM: nowOrEarlierMatch | | nOLM: nowOrLaterMatch | | nOEOM: nowOrEarlierOffsetMatch | | nOLOM: nowOrLaterOffsetMatch | | gTMatch: generalizedTimeMatch | +----------------------------------------+ | Syntaxes (Syn): | | gT: Generalized Time | +----------------------------------------+ | X: MR is applicable to Syn | | -: MR is not applicable to Syn | +----------------------------------------+ Figure 1 The matching rule names prefixed by nowOrEarlier (nOE) compose a Syntax/Matching Rule group whose members are dedicated to lower-than- or-equal comparison operations (bound to the nowBefore syntax and the nowBeforeOffset syntax respectively). The matching rule names Pluta & Hommel Expires September 26, 2010 [Page 5] Internet-Draft LDAP Server Side Current Time Matching March 2010 prefixed by nowOrLater (nOL) build another Syntax/Matching Rule group which is dedicated to greater-than-or-equal comparison operations (bound to the nowAfter syntax and the nowAfterOffset syntax respectively). The group of matching rules whose members contain Offset in their names provide support to calculate a client-side specified (negative or positve) chronological offset to the server's current time. These matching rules are bound to the respective Offset syntaxes. The matching rules without Offset infix within their names are restricted to only match against the server's current time. Additionally all matching rules specified in this document are also applicable to attributes of the Generalized Time (gT) syntax [RFC4517]. To support multi-valued attribute definitions (based on any of the syntaxes with After infix within their names) the generalizedTimeMatch (gTM) matching rule is associated to the "nowAfter" and the "nowAfterOffset" syntax. 2.2. Matching Rule Categories and Differentiations Both nowOrEarlier[Offset]Match matching rules offer support to match a time-stamp attribute's value(s) against the server's current time, whereas these matching rules are dedicated to chronological lower- than-or-equal matching. In contrast the nowOrLater[Offset]Match matching rules are dedicated to chronological greater-than-or-equal matching. Regarding server side current time matching the two matching rules nowOr[Earlier|Later]Match are the most restrictive ones. They are limited to just compare the servers current time to an time-stamp attributes value. A client cannot manipulate the matching criteria. The two matching rules called nowOr[Earlier|Later]OffsetMatch are less restrictive and more powerful. Clients are allowed to manipulate the matching criteria using arbitrary offsets. Both matching rules are capable of matching time-stamp attribute values using chronological offsets relative to the server's current time. 3. Syntax Definitions According to the previously illustrated syntax and the matching rule dependency matrix, four independent time-stamp attribute syntax definitions, called 'nowBefore' (Section 3.2.1), 'nowBeforeOffset' (Section 3.2.2), 'nowAfter' (Section 3.2.3), and 'nowAfterOffset' Pluta & Hommel Expires September 26, 2010 [Page 6] Internet-Draft LDAP Server Side Current Time Matching March 2010 (Section 3.2.4) are defined. All these syntaxes are derived from the 'Generalized Time' syntax. In contrast to the existing 'Generalized Time' syntax which is associated with the 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules (as defined in [RFC4517]), these four independent attribute value syntaxes are knowingly not associated with 'generalizedTimeOrderingMatch'. Therefore they SHALL be associated with 'nowOrEarlierMatch' (nowOrEarlierOffsetMatch respectively) and 'nowOrLaterMatch' (nowOrLaterOffsetMatch respectively) matching rules (see matching rule specification in Section 4 for details). Compared to 'generalizedTimeOrderingMatch' all the 'nowOr[Earlier| Later][Offset]Match' matching rules are extensible matching rules. In addition to the four herein defined attribute syntax definitions two related matching rule assertion value syntaxes called 'now' (Section 3.1.1) and 'nowOffset' (Section 3.1.2) are specified in this section. 3.1. Matching Rule Assertion Value Syntaxes 3.1.1. now - LDAP Server's Current Time A matching rule assertion value of the 'now' syntax represents an LDAP server's current time. The LDAP-specific encoding of this syntax is defined by the following ABNF: now = "NOW" A successfully validated 'now' matching rule assertion value will be dynamically replaced within the server using the server's current time as defined above, represented in 'generalizedTime' syntax. Regardless of the amount of entries of an LDAP query's result set, the server's internal time determination and matching rule assertion value replacement SHALL take place immediatly and exactly once after an LDAP request has been received. That means the resulting time- stamp value used for each comparison has to be constant for the whole result set's performed compare operations. The LDAP definition for the 'now' syntax is: ( 1.3.6.1.4.1.7650.6.2.3.1.1 DESC 'now Assertion' ) 3.1.2. nowOffset - Chronological Offset Relative to the Server's Current Time A matching rule assertion value of the 'nowOffset' syntax represents an LDAP server's current time determined by an offset which gets server internally added to or subtracted from the server's current Pluta & Hommel Expires September 26, 2010 [Page 7] Internet-Draft LDAP Server Side Current Time Matching March 2010 time. The LDAP-specific encoding of this syntax is defined by the following ABNF: nowOffset = tUnit sep tUnit sep tUnit sep tUnit sep tUnit sep = SHARP tUnit = year | month | day | hour | minute | second sign = PLUS | HYPHEN year = ( sign LDIGIT *DIGIT ) / number month = ( sign LDIGIT *DIGIT ) / number day = ( sign LDIGIT *DIGIT ) / number hour = ( sign LDIGIT *DIGIT ) / number minute = ( sign LDIGIT *DIGIT ) / number second = ( sign LDIGIT *DIGIT ) / number The , , , , , and rules are defined in [RFC4512]. An offset has to consist of exactly six t_unit fields; otherwise the 'nowOffset' syntax is invalid. Each t_unit field has to be separated by a '#' character. Each offset equally to zero (e.g. '0#0#0#0#0#0') SHALL be detected and processed according to Section 3.1.1 defined in this document. The first sign in front of an offset's t_unit field has to take precedence; optional multiple (redundant or varying) signs as well as all non-numeric values between the '#' separators MUST be ignored. A successfully validated 'nowOffset' matching rule assertion value will be dynamically replaced within the server using the server's current time (including the offset calculation), represented in 'Generalized Time' syntax. Regardless of the amount of entries of an LDAP query's result set, the server's internal time determination (including the offset calculation) and matching rule assertion value replacement MUST take place immediately and exactly once after an LDAP request has been received. That means the resulting time-stamp value used for each comparison MUST be constant for the whole result set's compare operations. Examples: '+1#0#0#0#0#0' '-1#-0#+6#-7#-9#+60' '-30#+75#+720#-30#+61#0' '-30Y#+75m#+720days#-30H#+61min#0sec.' same as '-30#75#-30#61#0' Pluta & Hommel Expires September 26, 2010 [Page 8] Internet-Draft LDAP Server Side Current Time Matching March 2010 '-+++30#+---75#+--720#-+30#+-+61#0' same as '-30#75#-30#61#0' '+0#-0#0#-0#-0#-0' same as 'NOW' (see Section 3.1.1) Each tUnit offset field value added to (subtracted from) the server's current time could cause an epoch time overflow (underflow). In case (e.g. using a 32bit time_t declaration) the server internally replaced matching rule assertion value (after offset calculation) results in a time-stamp out of the epoch time interval the matching rule assertion value's syntax SHALL become invalid. The LDAP definition for the nowOffset syntax is: ( 1.3.6.1.4.1.7650.6.2.3.1.2 DESC 'nowOffset Assertion' ) 3.2. Attribute Value Syntaxes The syntaxes defined in this section conform to increased data privacy requirements in restrictive environments and deployments, where ordering matching operations could be used to expose critical information. 3.2.1. nowBefore The 'nowBefore' attribute value syntax is equivalent to the 'Generalized Time' syntax (defined in [RFC4517]). In contrast to the 'Generalized Time' syntax the 'nowBefore' syntax SHALL NOT be associated with the 'generalizedTimeMatch' and 'generalizedTimeOrdering' matching rule. It SHALL be associated with the 'nowOrEarlierMatch' matching rule (Section 4.1) instead. This syntax offers the possibility to define restricted time-stamp like attributes which could not be used for generalizedTime and/or generalizedTimeOrdering matching but only for nowOrEarlier matching. The LDAP definition for the nowBefore syntax is: ( 1.3.6.1.4.1.7650.6.2.3.2.1 DESC 'nowBefore' ) 3.2.2. nowBeforeOffset The 'nowBeforeOffset' attribute value syntax is equivalent to the 'Generalized Time' syntax (defined in [RFC4517]). In contrast to the 'Generalized Time' syntax the 'nowBeforeOffset' syntax SHALL NOT be associated with the 'generalizedTimeMatch' and 'generalizedTimeOrdering' matching rule. It SHALL be associated with the 'nowOrEarlierMatch' and the 'nowOrEarlierOffsetMatch' matching rules (as defined in Section 4.1 and Section 4.2) instead. Pluta & Hommel Expires September 26, 2010 [Page 9] Internet-Draft LDAP Server Side Current Time Matching March 2010 This syntax offers the possibility to define flexible time-stamp like attributes which could not be used for generalizedTime and/or generalizedTimeOrdering matching but for nowOrEarlier and nowOrEarlierOffset matching. The LDAP definition for the nowBeforeOffset syntax is: ( 1.3.6.1.4.1.7650.6.2.3.2.2 DESC 'nowBeforeOffset' ) 3.2.3. nowAfter The 'nowAfter' attribute value syntax is equivalent to the 'Generalized Time' syntax (defined in [RFC4517]). In contrast to the 'Generalized Time' syntax the 'nowAfter' syntax SHALL NOT be associated with the 'generalizedTimeMatch' and 'generalizedTimeOrdering' matching rule. It SHALL be associated with the 'nowOrLaterMatch' matching rule (Section 4.3) instead. This syntax offers the possibility to define restricted time-stamp like attributes which could not be used for generalizedTime and/or generalizedTimeOrdering matching but only for nowOrLater matching. The LDAP definition for the nowAfter syntax is: ( 1.3.6.1.4.1.7650.6.2.3.2.3 DESC 'nowAfter' ) 3.2.4. nowAfterOffset The 'nowAfterOffset' attribute value syntax is equivalent to the 'Generalized Time' syntax (defined in [RFC4517]). In contrast to the 'Generalized Time' syntax the 'nowAfterOffset' syntax SHALL NOT be associated with the 'generalizedTimeMatch' and 'generalizedTimeOrdering' matching rule. It SHALL be associated with the 'nowOrLaterMatch' and the 'nowOrLaterOffsetMatch' matching rules (as defined in Section 4.3 and Section 4.4) instead. This syntax offers the possibility to define flexible time-stamp like attributes which could not be used for generalizedTime and/or generalizedTimeOrdering matching but for nowOrLater and nowOrLaterOffset matching. The LDAP definition for the nowAfterOffset syntax is: ( 1.3.6.1.4.1.7650.6.2.3.2.4 DESC 'nowAfterOffset' ) Pluta & Hommel Expires September 26, 2010 [Page 10] Internet-Draft LDAP Server Side Current Time Matching March 2010 4. Matching Rule Definitions 4.1. nowOrEarlierMatch The nowOrEarlierMatch compares an assertion value of the 'now' syntax (defined in Section 3.1.1) to an attribute value of a syntax (e.g., the 'Generalized Time' syntax) whose corresponding ASN.1 type is GeneralizedTime. The rule evaluates to TRUE if and only if the attribute's value is lower or equal (meaning earlier or just-in-time) compared to the server's current time (strictly speaking the point in time the server received the client's request). The LDAP definition for the 'nowOrEarlierMatch' matching rule is: ( 1.3.6.1.4.1.7650.6.2.3.3.1 NAME 'nowOrEarlierMatch' SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.1 ) According to the syntax to matching rule dependencies (illustrated in Figure 1) this matching rule SHALL be applicable to the nowBefore and the nowBeforeOffset syntaxes as well as to attributes of the Generalized Time syntax: ( 1.3.6.1.4.1.7650.6.2.3.3.1 NAME 'nowOrEarlierMatch' SYNTAX 1.3.6.1.4.1.7650.6.2.3.2.2 ) ( 1.3.6.1.4.1.7650.6.2.3.3.1 NAME 'nowOrEarlierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) The nowBefore (1.3.6.1.4.1.7650.6.2.3.2.1) syntax is described in Section 3.2.1 and the nowBeforeOffset (1.3.6.1.4.1.7650.6.2.3.2.2) syntax is described in Section 3.2.2, while the Generalized Time (1.3.6.1.4.1.1466.115.121.1.24) syntax is described in [RFC4517]. The nowOrEarlierMatch is an extensible matching rule. 4.2. nowOrEarlierOffsetMatch The nowOrEarlierOffsetMatch compares an assertion value of the 'nowOffset' syntax (defined in Section 3.1.2) to an attribute value of a syntax (e.g., the 'Generalized Time' syntax) whose corresponding ASN.1 type is GeneralizedTime. The rule evaluates to TRUE if and only if the attribute's time-stamp value is lower or equal (meaning earlier or just-in-time) compared to the server's current time (strictly speaking the point in time the Pluta & Hommel Expires September 26, 2010 [Page 11] Internet-Draft LDAP Server Side Current Time Matching March 2010 server received the client's request) including a given chronological offset. The LDAP definition for the nowOrEarlierOffsetMatch matching rule is: ( 1.3.6.1.4.1.7650.6.2.3.3.2 NAME 'nowOrEarlierOffsetMatch' SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.2 ) Due to the possibility to also consider a chronological offset to the server's current time this matching rule is more powerful (flexible) than the nowOrEarlierMatch which has been specified in Section 4.1. Therefore this matching rule SHALL NOT be applicable to all Generalized Time based (derived) attribute syntax definitions. In contrast to nowOrEarlierMatch the nowOrEarlierOffsetMatch SHALL be additionally only applicable to attributes of the 'Generalized Time' syntax: ( 1.3.6.1.4.1.7650.6.2.3.3.2 NAME 'nowOrEarlierOffsetMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) The Generalized Time (1.3.6.1.4.1.1466.115.121.1.24) syntax is described in [RFC4517]. The nowOrEarlierOffsetMatch is an extensible matching rule. 4.3. nowOrLaterMatch The nowOrLaterMatch compares an assertion value of the 'now' syntax (defined in Section 3.1.1) to an attribute value of a syntax (e.g., the 'Generalized Time' syntax) whose corresponding ASN.1 type is GeneralizedTime. The rule evaluates to TRUE if and only if the attribute's value is greater or equal (meaning earlier or just-in-time) compared to the server's current time (strictly speaking the point in time the server received the client's request). The LDAP definition for the 'nowOrLaterMatch' matching rule is: ( 1.3.6.1.4.1.7650.6.2.3.3.3 NAME 'nowOrLaterMatch' SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.1 ) According to the syntax to matching rule dependencies (illustrated in Figure 1) this matching rule SHALL be applicable to the nowAfter and the nowAfterOffset syntaxes as well as to attributes of the Generalized Time syntax: ( 1.3.6.1.4.1.7650.6.2.3.3.3 NAME 'nowOrLaterMatch' Pluta & Hommel Expires September 26, 2010 [Page 12] Internet-Draft LDAP Server Side Current Time Matching March 2010 SYNTAX 1.3.6.1.4.1.7650.6.2.3.2.4 ) ( 1.3.6.1.4.1.7650.6.2.3.3.3 NAME 'nowOrEarlierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) The nowAfter (1.3.6.1.4.1.7650.6.2.3.2.3) syntax is described in Section 3.2.3 and the nowAfterOffset (1.3.6.1.4.1.7650.6.2.3.2.4) syntax is described in Section 3.2.4, while the Generalized Time (1.3.6.1.4.1.1466.115.121.1.24) syntax is described in [RFC4517]. The nowOrLaterMatch is an extensible matching rule. 4.4. nowOrLaterOffsetMatch The nowOrLaterOffsetMatch compares an assertion value of the 'nowOffset' syntax (defined in Section 3.1.2) to an attribute value of a syntax (e.g., the 'Generalized Time' syntax) whose corresponding ASN.1 type is GeneralizedTime. The rule evaluates to TRUE if and only if the attribute's time-stamp value is greater or equal (meaning just-in-time or later) compared to the server's current time (strictly speaking the point in time the server received the client's request) including a given chronological offset. The LDAP definition for the nowOrLaterOffsetMatch matching rule is: ( 1.3.6.1.4.1.7650.6.2.3.3.4 NAME 'nowOrLaterOffsetMatch' SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.2 ) Due to the possibility to also consider a chronological offset to the server's current time this matching rule is more powerful (flexible) than the nowOrEarlierMatch which has been specified in Section 4.3. Therefore this matching rule SHALL NOT be applicable to all Generalized Time based (derived) attribute syntax definitions. In contrast to nowOrLaterMatch the nowOrLaterOffsetMatch SHALL additionally be only applicable to attributes of the 'Generalized Time' syntax: ( 1.3.6.1.4.1.7650.6.2.3.3.4 NAME 'nowOrLaterOffsetMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) The Generalized Time (1.3.6.1.4.1.1466.115.121.1.24) syntax is described in [RFC4517]. The nowOrLaterOffsetMatch is an extensible matching rule. Pluta & Hommel Expires September 26, 2010 [Page 13] Internet-Draft LDAP Server Side Current Time Matching March 2010 5. Schema: Attribute Types and Object Classes This section contains sample definitions for attribute types and an object class that are implementing the above introduced syntaxes and matching rules to achieve an LDAP server-side entry validity period checking feature. Similar to the definitions made within the Internet X.509 Public Key Infrastructure Certificate and CRL Profile (specified in [RFC2459]), it is a requirement to assign a validity period to LDAP entries in a broad range of scenarios. A validity period is defined by two time- stamps: The beginning (notValidBefore) and the end (notValidAfter). In contrast to the certificate profile's specification, an LDAP entry's validity period SHOULD be used LDAP server internally to prevent the delivery of outdated entries to clients, whereas the period definition (by means of two time-stamps) SHALL only be accessible for reading by privileged LDAP clients (subject to access control). The client-side (eventually manual) determination of the time-stamps, e.g. by applying a binary search using an ordering matching rule, SHALL be prohibited. An LDAP entry's validity period is the time interval during which the LDAP server warrants that it will deliver information about the entry. 5.1. Attribute Type: notValidBefore The 'notValidBefore' attribute type contains an entry's validity period's beginning time-stamp in Generalized Time syntax. The beginning time-stamp SHOULD be single-valued, due to the fact that the earliest point in time is critical for the beginning of the validity period. ( 1.3.6.1.4.1.7650.6.2.3.4.2 NAME 'notValidBefore' DESC 'Entry validity periods lower time-stamp' SYNTAX 1.3.6.1.4.1.7650.6.2.3.2.1 SINGLE-VALUE ) This attribute is defined as single-valued because an entry under normal circumstances only has one point in time that it has started to be valid. Pluta & Hommel Expires September 26, 2010 [Page 14] Internet-Draft LDAP Server Side Current Time Matching March 2010 5.2. Attribute Type: notValidAfter The 'notValidAfter' attribute type contains an entry's validity period's ending time-stamp in Generalized Time syntax. The ending time-stamp SHOULD support multi-valued content, to enable extension while still ensuring the entry's self-contained validity period documentation. ( 1.3.6.1.4.1.7650.6.2.3.4.3 NAME 'notValidAfter' DESC 'Entry validity periods upper time-stamp' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.7650.6.2.3.2.3 ) Due to the equality matching rule this attribute supports multi- valued content. Note that multiple time-stamps SHOULD only be used if an entry's validity-period is extended and this extension is supposed to be also documented in the entry (attribute) itself. 5.3. Object Class: validity According a certificate's validity period (specified in [RFC2459]) this object class bundles the two above defined attribute types to represent and limit a validity period. ( 1.3.6.1.4.1.7650.6.2.3.5.1 NAME 'validity' DESC 'Entry validity period' SUP top AUXILIARY MUST ( notValidBefore $ notValidAfter ) ) 6. Root DSE attributes 6.1. supportedFeature Servers supporting the server side current time match feature SHOULD publish the Object Identifier 1.3.6.1.4.1.7650.6.2.5.1 as a value of the 'supportedFeatures' [RFC4512] attribute in the root DSE. 6.2. serverTime This specification introduces a single-valued operational Root-DSE attribute, called 'serverTime'. Servers supporting the server side current time match feature SHALL publish a server's current time and Pluta & Hommel Expires September 26, 2010 [Page 15] Internet-Draft LDAP Server Side Current Time Matching March 2010 the timezone it is located in using the 'serverTime' attribute in the root DSE. This root DSE attribute's syntax SHALL be of the 'Generalized Time' syntax. Additionally the attribute's value SHALL be of the format '' (as specified in [RFC4517]). Due to the '' format the clients SHOULD be able to determine a server's current time as local time as well as in UTC. Additionally its global position (timezone) can be determined, too. This information is essential to meet requirements regarding global time- stamp replication while retaining the time information semantics relative to a replica server's local time. 7. Discovering and Using Server Side Current Time Matching Support As stated in [RFC4512] protocol extensions should provide adequate discovery mechanisms. 7.1. Querying the supportedFeature root DSE attribute Clients SHOULD be able to query the root DSE attribute 'supportedFeature' for the Object Identifier 1.3.6.1.4.1.7650.6.2.3.0.1 7.2. Querying the Schema Any LDAP server that supports server side current time matching SHALL implement all the syntaxes and matching rules specified in this document. LDAP server side current time matching support could be discovered querying the schema for the concerned matching rules and syntaxes OIDs, defined in this document. 7.3. Querying the root DSE for the Server's Current Time LDAP clients SHOULD be able to query an LDAP server's current time using LDAP itself. LDAP servers which support server side current time matching SHALL provide information about the current time and timezone via LDAP (as specified in Section 6.2). 7.4. Operational Attribute 'serverTime' If requested, an LDAP server optionally could return the request's time as operational attribute called 'serverTime' (syntax 'Generalized Time') contained in each entry of a result set. Pluta & Hommel Expires September 26, 2010 [Page 16] Internet-Draft LDAP Server Side Current Time Matching March 2010 7.5. Client using server side time matching Clients supporting this feature SHOULD NOT use the feature unless they know that the server supports it. 8. Security Considerations The introduction of server side current time matching is not believed to raise any new security considerations. General LDAP security considerations specified by [RFC4510] are applicable to the use of this document's specifications. 9. Acknowledgement TBD 10. IANA Considerations In accordance with [RFC4520] the following registrations are requested. 10.1. Object Identifier Registration The OIDs used in this specification are derived from iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) Leibniz Supercomputing Centre(7650) pub (6) LDAP(2) server side current time match (3). These OIDs have been in use since at least March 2003. All OIDs were assigned by the Leibniz Supercomputing Centre, under its IANA-assigned private enterprise allocation, for use in this specification. 10.2. LDAP Descriptors Registration of the descriptors specified in this document is requested. Subject: Request for LDAP Protocol Mechanism Registration Object Object Identifier: 1.3.6.1.4.1.7650.6.2.3.0.1 Description: LDAP server side current time matching Person & email address to contact for further information: Pluta & Hommel Expires September 26, 2010 [Page 17] Internet-Draft LDAP Server Side Current Time Matching March 2010 Daniel Pluta Usage: Feature Specification: (I-D) draft-pluta-ldap-srv-side-current-time-match Author/Change Controller: IESG Comments: none Subject: Request for LDAP Descriptor Registration Descriptor (short name): see Figure 2 Object Identifier: see Figure 2 Description: see Figure 2 Person & email address to contact for further information: Daniel Pluta Specification: (I-D) draft-pluta-ldap-srv-side-current-time-match Author/Change Controller: IESG Comments: Pluta & Hommel Expires September 26, 2010 [Page 18] Internet-Draft LDAP Server Side Current Time Matching March 2010 Descriptor Type OID ------------------------ ---- ------------------------------ now AS 1.3.6.1.4.1.7650.6.2.3.1.1 nowOffset AS 1.3.6.1.4.1.7650.6.2.3.1.2 nowBefore VS 1.3.6.1.4.1.7650.6.2.3.2.1 nowBeforeOffset VS 1.3.6.1.4.1.7650.6.2.3.2.2 nowAfter VS 1.3.6.1.4.1.7650.6.2.3.2.3 nowAfterOffset VS 1.3.6.1.4.1.7650.6.2.3.2.4 nowOrEarlierMatch MR 1.3.6.1.4.1.7650.6.2.3.3.1 nowOrEarlierOffsetMatch MR 1.3.6.1.4.1.7650.6.2.3.3.2 nowOrLaterMatch MR 1.3.6.1.4.1.7650.6.2.3.3.3 nowOrLaterOffsetMatch MR 1.3.6.1.4.1.7650.6.2.3.3.4 serverTime AT 1.3.6.1.4.1.7650.6.2.3.4.1 notValidBefore AT 1.3.6.1.4.1.7650.6.2.3.4.2 notValidAfter AT 1.3.6.1.4.1.7650.6.2.3.4.3 validity OC 1.3.6.1.4.1.7650.6.2.3.5.1 +---------------------------------------+ | Legend: | | | | AS: Attribute Assertion Value Syntax | | VS: Attribute Value Syntax | | MR: Matching Rule | | AT: Attribute Type | | OC: Object Class | +---------------------------------------+ Figure 2 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. Pluta & Hommel Expires September 26, 2010 [Page 19] Internet-Draft LDAP Server Side Current Time Matching March 2010 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 11.2. Informative References [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. Authors' Addresses Daniel Pluta Technische Universitaet Muenchen Boltzmannstr. 3 Garching bei Muenchen 85748 Germany Email: pluta@tum.de Wolfgang Hommel Leibniz Supercomputing Centre Boltzmannstr. 1 Garching bei Muenchen 85748 Germany Email: hommel@lrz.de Pluta & Hommel Expires September 26, 2010 [Page 20]