LDAP Extensions Working Group R. Salz Internet Draft CertCo, Inc. Document: draft-salzr-ldap-repsig-00.txt May 1, 2000 Intended Category: Standards Track Expires: November 1, 2000 LDAP Controls for Reply Signatures Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [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. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com This document expires on November 1, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 1. Abstract In many environments the final step of certificate issuance is publishing the certificate to a repository. Unfortunately, there is no way for a Certification Authority (CA) to have a secure application-level acknowledgement that the proper repository did, in fact, receive the certificate. This issue is of greater concern when considering the publication of Certificate INTERNET DRAFT Expires November 1, 2000 Page 1 LDAP Controls for Reply Signatures May 1, 2000 Revocation Lists (CRLs) -- if an adversary manages to interpose itself between the CA and its intended repository, then clients could end up relying on outdated revocation lists. This document defines a set of controls so that an LDAP client, such as a CA, can receive a cryptographically secure acknowledgement that an LDAP server has received a request, and that the integrity of the server's reply has not been compromised. Whenever possible, the definitions here use mechanisms and datatypes defined by the IETF PKIX working group. This document references RFC 2459 [RFC2459]. Knowledge of the RFC is required for proper implementation of this document, although it should be possible to understand this document without much knowledge of that RFC. It is expected that future versions of this document will reference 2459's successor(s). 2. Conventions used in this document 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]. 3. The Nonce Control A "nonce" is an arbitrary series of bytes used to cryptographically bind a request and a response. A nonce is not the same as a "transaction identifier." It is arbitrary because it may have meaning to the creator, but it should be treated as opaque data by all other recipients. This is a critical control. It has the following syntax: id-ldapext-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp-nonce } Nonce ::= OCTET STRING If a client includes a nonce, then the server MUST include the nonce in all its response PDUs. It is RECOMMENDED that a client generate a nonce whenever it requests a reply signature. 4. Reply Signature Controls INTERNET DRAFT Expires November 1, 2000 Page 2 LDAP Controls for Reply Signatures May 1, 2000 In many environments the final step of certificate issuance is publishing the certificate to a repository. Unfortunately, there is no way for a Certification Authority (CA) to have a secure application-level acknowledgement that the proper repository did, in fact, receive the certificate. This issue is of greater concern when considering the publication of Certificate Revocation Lists (CRLs) -- if an adversary manages to interpose itself between the CA and its intended repository, then clients could end up relying on outdated revocation lists. A Reply Signature is, as the name implies, a signature included as part of a server's reply to a client. In order to prove (in a non-legal sense) that a server received the client's request, the server MUST include the original request PDU in the signature. In order to similarly prove that the reply is in response to that particular request, the server's reply must be part of the signed data. When a Reply Signature control is present, the order of the controls in the response PDU is important: the signature includes the messageID and protocolOP fields, and all controls that appear in the PDU before the Reply Signature control, in the order that they appear in the PDU. The need to sign intermediate search results (the SearchResultEntry, SearchResultDone, and SearchResultReference PDU's) will vary according to the environment. For example, a query to a corporate address book over an internal network might not need any such signatures. Depending on the flags value in the Reply Signature Request control (and the server's willingness to perform the request), the results can be left unprotected, included in the reply signature, or individually signed. 4.1 Reply Signature Request Control A client that wants a reply signature includes the reply signature request control. This is a critical control. It has the following syntax: id-replysignaturerequest OBJECT IDENTIFIER ::= { id-ldapext-signing 1 } ReplySignatureRequest ::= SEQUENCE { flags ENUMERATED { none (0), signSearchResults (1), hashSearchResults (2) } keysKnown [0] EXPLICIT SEQUENCE OF SubjectKeyIdentifier OPTIONAL } INTERNET DRAFT Expires November 1, 2000 Page 3 LDAP Controls for Reply Signatures May 1, 2000 A server that understands the control but does not support this feature MUST return an unwillingToPerform (54) error. The signSearchResults flag value indicates that the client wants each search response PDU to include a signature. As this is likely to put a heavy computational burden on the server, support for this flag is OPTIONAL. If a server receives a request with this flag, and the feature is not available, it MUST return an unwillingtoPerform error. A server that supports the feature MAY, during initial query evaluation -- but before any results are sent to the client -- determine that the signing cost will be excessive. In this case, too, the server MUST return an unwillingToPerform error. A server MAY NOT mix signed and unsigned search results. If this were allowed, then an active adversary could insert erroneous results into the data stream. The hashSearchResults provides intermediate protection: tamper- evidence of the entire response. It is less robust in the face of an active attack, because modification (or interception) of a single entry invalidates the entire query. The Search Results Sent control, described below, can be used to strengthen the protection provided by hashSearchResults as it enables the client to distinguish between modification and deletion of results. It can also be used by itself to provide a minimal level of protection. The none flag value indicates that, for purposes of hashing or signing, the result and entry PDU's are to be ignored. While not recommended, this may be suitable in some environments (e.g., an interactive corporate addressbook within a suitably protected network). A server might have multiple signing keys. A client can include the identifiers of the keys it knows about. The format of the each key identifier is defined in RFC 2459 [4]. A server MAY use this information to determine which key (and therefore, what signing algorithm) to use when generating signatures. Servers SHOULD use one of the requested keys if it is available and valid. How a client obtains the server key(s) is beyond the scope of this document. It must be done using an out-of-band mechanism that leverages an external trust mechanism. For example, the server's administrators could send it on a CDROM via certified mail; the client could obtain it from the server during part of the registration process, etc. INTERNET DRAFT Expires November 1, 2000 Page 4 LDAP Controls for Reply Signatures May 1, 2000 4.2 Reply Signature Control A server uses a reply signature control to send signatures to the client. This is a non-critical control, as a client is always free to ignore the signature. It has the following syntax: id-replysignature OBJECT IDENTIFIER ::= { id-ldapext-signing 3 } ReplySignature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier signatureValue EXPLICIT BIT STRING keyUsed [0] EXPLICIT SubjectKeyIdentifier OPTIONAL } The suite of signing algorithms, their identifiers, and required level of support thereof are defined in RFC 2459. 4.3 Search Results Sent Control A server MAY include a Search Results Count control in its SearchResultDone PDU. This is a non-critical control with the following syntax: id-searchresultssent OBJECT IDENTIFIER ::= { id-ldapext-signing 2 } SearchResultsSent ::= MessageID The value is the number of search results that the server sent to the client. If this control is sent, the server SHOULD include it within the reply signature, in order to provide minimal protection of the data stream. 5. Security Considerations This entire memo discusses security. 6. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. INTERNET DRAFT Expires November 1, 2000 Page 5 LDAP Controls for Reply Signatures May 1, 2000 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. 7. Acknowledgments Some fools at CertCo provided many helpful comments on earlier versions of this document. 8. Author's Address Rich Salz CertCo, Inc. 100 CambridgePark Drive Phone: +1 617-499-4075 Email: salzr@certco.com Full Copyright Statement "Copyright (C) The Internet Society (2000). 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. INTERNET DRAFT Expires November 1, 2000 Page 6 LDAP Controls for Reply Signatures May 1, 2000 Appendix A: Complete ASN.1 IETF-LDAPEXT-REPLY-SIGNATURES -- XXX Do we need an OID, or a better name? DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS -- X.509 AlgorithmIdentifier FROM AuthenticationFramework { joint-iso-itu-t(2) ds(5) module(1) authenticationFramework(7) 3 } -- IETF RFC 2459 SubjectKeyIdentifier FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2) } -- IETF RFC 2560. The OID below is "to be published." id-pkix-ocsp-nonce FROM OCSP { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) ocsp(14) } ; -- The base for any OID's defined here. -- We expect that this will be changed. :) id-ldapext-signing OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) us(840) company(1) certco(113731) ietf-ldapext(2) } -- A nonce. id-ldapext-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp-nonce } Nonce ::= OCTET STRING -- Reply signature request control id-replysignaturerequest OBJECT IDENTIFIER ::= { id-ldapext-signing 1 } ReplySignatureRequest ::= SEQUENCE { INTERNET DRAFT Expires November 1, 2000 Page 7 LDAP Controls for Reply Signatures May 1, 2000 flags ENUMERATED { none (0), signSearchResults (1), hashSearchResults (2) } keysKnown [0] EXPLICIT SEQUENCE OF SubjectKeyIdentifier OPTIONAL } -- A count of the searchResults sent back. id-searchresultssent OBJECT IDENTIFIER ::= { id-ldapext-signing 2 } SearchResultsSent ::= MessageID -- Reply signature id-replysignature OBJECT IDENTIFIER ::= { id-ldapext-signing 3 } ReplySignature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier signatureValue EXPLICIT BIT STRING keyUsed [0] EXPLICIT SubjectKeyIdentifier OPTIONAL } END INTERNET DRAFT Expires November 1, 2000 Page 8