LDAP Extensions Working Group Bruce Greenblatt Internet Draft Pat Richard <draft-ietf-ldapext-sigops-00.txt> Expires in six months Signed Directory Operations Using S/MIME Status of this Memo This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document defines an LDAP v3 based mechanism for signing direc- tory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signa- tures are supported. An object class for subsequent retrieval are 'journal entries' is also defined. This document specifies LDAP v3 con- trols that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information. Greenblatt and Richard [Page 1]
Internet Draft May 1998 1. Mechanism Signed directory operations is a straightforward application of S/MIME technology that also leverages the extensible framework that is provided by LDAP version 3. LDAP version 3 is defined in [4], and S/MIME is defined in [2]. The security used in S/MIME is based in the definitions in [1]. The basic idea is that the submitter of an LDAP operation that changes the directory information includes an LDAP ver- sion 3 control that includes either a signature of the operation, or a request that the LDAP server sign the operation on the behalf of the LDAP client. The result of the operation (in addition to the change of the directory information), is additional information that is attached to directory objects, that includes the audit trail of signed opera- tions. The LDAP control is (OID = 1.2.840.113549.6.0.0): SignedOperation ::= CHOICE { SignbyServer [0] BOOLEAN SignatureIncluded [1] OCTET STRING } If the SignatureIncluded CHOICE is used, then the OCTET string is just an S/MIME message of the multipart/signed variety, that is composed of a single piece, that is the signature of the directory operation. Multipart/signed MIME objects are defined in [3]. If the SignbyServer CHOICE us used, then the LDAP server creates the signature on behalf of the client, using its own identity and not the identity of the client, in order to produce the audit trail entry. In either case the success- ful result of processing the control is the creation of additional information in the directory entry that is being modified or created. No control is defined for the server to return in the LDAPResult as defined in [4]. The LDAP server MAY attempt to parse and verify the signature included in the SignedOperation control, but is not required to. If the LDAP server is unable to verify the signature and wishes to return an error then the error code unwillingToPerform(53) should be returned, and the entire LDAP operation fails. In this situation, an appropriate message (e.g. "Unable to verify signature") MUST be included in the errorMessage of the LDAPResult. The Control MAY be marked CRITI- CAL, and if it is CRITICAL then if the LDAP Server performs the LDAP operation, then must include the signature in the signedAuditTrail information. The schema definition for the signedAuditTrail information is: Greenblatt and Richard [Page 2]
Internet Draft May 1998 ( 1.2.840.113549.6.1.0 NAME 'signedAuditTrail' SUP top AUXILIARY MUST ( Changes ) ) The format of the Changes attribute is: ( 1.2.840.113549.6.2.0 NAME 'Changes' DESC 'a set of changes applied to an entry' SYNTAX 'Binary' ) The actual format of the Changes attribute is: Change ::= SEQUENCE { SequenceNumber [0] INTEGER (0 .. maxInt), SignedOperation [1] OCTET STRING } The SignedOperation attribute is a multipart/signed S/MIME mes- sage. Part 1 of the message is the directory operation, and part 2 is the signature. Sequence number 0 (if present) always indicates the starting point directory object as represented by the definitions in "A MIME Content-Type for Directory Information", as defined in [5]. Subse- quent sequence numbers indicate the sequence of changes that have been made to this directory object. Note that the sequence of the changes can be verified due to the fact that the signed directory object will have a timestamp as part of the signature object, and that the sequence numbering as part of the change attribute should be considered to be an unverified aid to the LDAP client. 2. Signed Results Mechanism A control is also defined that allows the LDAP v3 client to request that the server sign the results that it returns. It is intended that this control is primarily used in concert with the LDAPSearch operation. This control MAY be marked as CRITICAL. If it is marked as CRITICAL and the LDAP Server supports this operation, then all search results MUST be returned with a signature as attached in the SignedResult control if it is willing to sign results for this user. If the server supports this control but does not wish to sign the results for this user then the Greenblatt and Richard [Page 3]
Internet Draft May 1998 error code unwillingToPerform(53) should be returned, and the LDAP search will have failed. In this situation, an appropriate message (e.g. "Unwilling to sign results for you!") MUST be included in the errorMessage of the LDAPResult. If the LDAPSigType has the value FALSE then the client is requesting that the server not sign this operation. This may be done in situations where servers are configured to always sign their operations. The LDAP control to include in the LDAP request is (OID = 1.2.840.113549.6.0.1): DemandSignedResult ::= { signatureSpan LDAPSigType } LDAPSigType ::= { BOOLEAN DEFAULT TRUE } In response to a DemandSignedResult control, the LDAP v3 server will return a SignedResult control in addition to the normal result as defined by the operation (assuming that the server understands the con- trol, and is willing to perform it). The SignedResult control MUST not be marked CRITICAL. LDAP v3 servers MAY be configured to sign all of their operations. In this situation the server always returns a Signe- dResult control, unless instructed otherwise by the DemandSignedResult Control. The signature field below includes the signature of the enitre LDAPResult formatted as an S/MIME pkcs-7/signature object, as defined in [2]. The LDAP control in the LDAP response is (OID = 1.2.840.113549.6.0.2): SignedResult ::= CHOICE { signature OCTET STRING } 3. Notes The base OIDs are: rsadsiLdap ::= {1 2 840 113549 6} rsadsiLdapControls ::= {1 2 840 113549 6 0} rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1} rsadsiLdapAttributes ::= {1 2 840 113549 6 2} If any of the controls in this specification are supported by an LDAP v3 server then that server MUST make available its certificate in the userCertificate attribute of its rootDSE object. The UserCertifi- cate attribute is defined in [6]. Greenblatt and Richard [Page 4]
Internet Draft May 1998 4. References [1] RFC 2315 PKCS 7: Cryptographic Message Syntax Version 1-5. B. Kaliski. March 1998. [2] RFC 2311 S/MIME Version 2 Message Specification. S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. [3] RFC 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Freed. Octo- ber 1995. [4] RFC 2251 Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes, S. Kille. December 1997. [5] Internet Draft, work in progress, "A MIME Content-Type for Directory Information", Tim Howes, Mark Smith, Frank Dawson Jr., 04/22/1998. [6] RFC 2256 A Summary of the X.500(96) User Schema for use with LDAPv3. M. Wahl. December 1997. 5. Author's Addresses Bruce Greenblatt RSA Data Security 100 Marine Parkway, Suite 500 Redwood City, CA 94065 USA Email: bgreenblatt@rsa.com Phone: +1-650-595-1282 x569 Pat Richard Xcert Software, Inc. Suite 1001 - 701 W. Georgia Vancouver, BC CANADA V6G 1C9 Email: patr@xcert.com Greenblatt and Richard [Page 5]
Internet Draft May 1998 Table of Contents 1. Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . . . . 2 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . . . 3 3. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Greenblatt and Richard [Page 6]
