Internet-Draft D.W.Chadwick PKIX WG University of Salford Intended Category: Standards Track Expires: 12 December 1999 12 June, 1999 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3 STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all the provisions of Section 10 of RFC2026. 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 expires on December 12, 1999. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the PKIX working group discussion list: or directly to the author. ABSTRACT This document describes the features of the Lightweight Directory Access Protocol v3 that are needed in order to support a public key infrastructure based on X.509 certificates and CRLs. 1. Introduction RFC 2559 [1] specifies the subset of LDAPv2 [2] that is necessary to retrieve X.509 [9] certificates and CRLs from LDAP servers. However LDAPv2 has a number of deficiencies that may limit its usefulness in certain circumstances. The most notable of these are: - LDAPv2 distinguished names must be composed from the IA5 character set and cannot contain accented or non-latin characters, - LDAPv2 only has a limited number of supported authentication schemes for binding to the server, in particular the use of hashed passwords or TLS [3] are not supported, - LDAPv2 only supports a single directory server. It is the responsibility of the user to pre-configure his client with the required set of LDAP servers, and to choose the correct one for each certificate and CRL retrieval. It is for these reasons (and others not listed here) that the IETF have stopped the standardisation of the LDAPv2 protocol and have replaced it with the LDAPv3 protocol [4]. However the LDAPv3 protocol is much more complex than the LDAPv2 protocol and many of its features are not essential for simple PKIX use. This document describes the features of LDAPv3 that are essential, or not required, or are optional for servers to support a PKI based on X.509. 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 [5]. 2. Features Of Ldapv3 That MUST Be Supported Attribute descriptions are a superset of attribute type definitions. They allow attribute subtyping to be specified in the LDAPv3 protocol. The ;binary option is exception to this. This option allows certificates and CRLs to be asked for and returned as binary values encoded using the Basic Encoding Rules [11]. The mechanism described in PKIX LDAPv2 [1] is fully compliant with the ;binary option of LDAPv3. The ;binary option of attribute descriptions MUST be supported by all implementations. Other attribute description options SHOULD NOT be supported by clients. Servers MAY choose to support them at their discretion. UTF8 encoding [12] allows the full ISO 10646 character set to be used in the creation of distinguished names. UTF8 encoding of distinguished names MUST be supported as specified in RFC2253 [6]. The altServer attribute is used by servers to point to alternative servers that may be contacted if this server is temporarily unavailable. This attribute MUST be stored in the root DSE of the server and MUST be available to clients for retrieval. If no alternative servers exist this attribute MUST point to the current server. Clients MAY make use of this feature but do not need to. Servers MAY store any other operational attributes in the root DSE, but do not need to. 3. Features Of Ldapv3 That SHOULD Be Supported In a distributed directory with multiple servers, LDAPv3 supports referrals as the mechanism to allow one server that cannot fulfil a client's request, to refer the client to another server that might be better able to fulfil the request. Servers SHOULD be able to return referrals to clients. Clients SHOULD be able to receive referrals, although they are not required to automatically process them and support multiple asynchronous outgoing connections. As a minimum, clients SHOULD be able to ask the user if the referrals are be cached locally and added to the set of servers known to the client. Partial Search results are returned when a server only has a subset of the certificates requested by the client. Referrals to other servers are embedded in the SearchResultReference field. Clients and servers SHOULD be able to handle SearchResultReferences in the same way as they handle referrals. 4. Features Of Ldapv3 That SHOULD NOT Be Supported The client SHOULD NOT support the ModifyDN, Compare and Abandon operations. The server MAY choose to support these operations at its discretion. The LDAPv3 protocol is infinitely extensible via two mechanisms: extended operations and controls on existing operations. The client SHOULD NOT generate any LDAPv3 protocol extensions (extended operations or controls). The server SHOULD NOT return any LDAPv3 protocol extensions (extended operations or controls). LDAPv3 has the concept of unsolicited notifications that can be sent from the server to the client. The server SHOULD NOT generate any unsolicited notifications. LDAPv3 allows the subschema supported by the server to be published in a subschema subentry. Subschema publishing is not needed for normal PKI use, therefore the client SHOULD NOT try to retrieve either the contents of the subschema subentry or the pointer to it (held in the subschemaSubentry attribute of the root DSE) from the server. The server MAY publish its subschema at its discretion. Operational attributes are attributes stored by the server that hold administrative information. Clients SHOULD NOT request any operational attributes from the server other than the altServer attribute, and the server need not store any operational attributes other than altServer. 5. Features Of Ldapv3 That MAY Be Supported If the CPS allows unauthenticated anonymous access to the server, then the server MUST allow a client to perform a Search operation (for a "read" or "search" type request) without issuing a prior Bind operation. The server MUST also allow the client to present a Bind request with the simple authentication choice and a zero-length OCTET STRING. If the CPS allows weak password based authentication for "read" or "search" access to the server, the client and the server SHOULD support the DIGEST-MD5 mechanism [7] as specified in [8], and may support a simple password Bind sequence following the negotiation of a TLS ciphersuite to provide connection confidentiality, as specified in [10]. If the CPS requires strong authentication for access to the server then the client and the server SHOULD support certificate based authentication as specified in [10]. The parameters of the Search operation for "read" or "search" type queries will usually be set as specified in RFC 2559. However, X.509(1997) [9] supports flexible certificate matching by the server, via the certificateMatch MATCHING-RULE. For example, a client may search for certificates with a particular validity time, key usage, policy or other field. If the server supports flexible matching, then the extensibleMatch filter item MUST be supported. Clients MAY support the extensibleMatch filter item. 6. Security Considerations The PKI information to be retrieved from LDAPv3 servers (certificates and CRLs) is digitally signed and therefore additional integrity services are NOT REQUIRED. The CPS will specify whether the information should be publicly available or not. If publicly available, privacy services will NOT be REQUIRED for retrieval requests. If not publicly available, privacy services MAY be REQUIRED and these can be provided by a TLS ciphersuite as specified in clause 5. For update of the information by CAs either strong authentication or weaker password based authentication MUST be supported as specified in clause 5. Additional access controls SHOULD be provided. Organizations are NOT REQUIRED to provide external CAs or users with access to their directories. 7 Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 8. References [1] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999 [2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access Protocol", RFC 1777, March 1995. [3] T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", Dec. 1997, RFC 2251 [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC2253, December 1997. [7] Digest md5 [8] P. Leach, C. Newman, "Using Digest Authentication as a SASL Mechanism", INTERNET DRAFT , November 1998. [9] X.509(97) [10] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan. "Authentication Methods for LDAP" , November 1998 [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994. [12] F. Yergeau. "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 10 Authors Address David Chadwick IS Institute University of Salford Salford England M5 4WT Email: d.w.chadwick@iti.salford.ac.uk Internet-Draft PKIX Operational Protocols - LDAPv3 12 June 1999