Movatterモバイル変換

Network Working Group                                       B. GreenblattRequest for Comments: 2649                                     P. RichardCategory: Experimental                                        August 1999An LDAP Control and Schema for Holding Operation SignaturesStatus of this Memo   This memo defines an Experimental Protocol for the Internet   community.  It does not specify an Internet standard of any kind.   Discussion and suggestions for improvement are requested.   Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.Abstract   In many environments clients require the ability to validiate the   source and integrity of information provided by the directory.  This   document describes an LDAP message control which allows for the   retrieval of digitally signed information. This document defines an   LDAP v3 based mechanism for signing directory operations in order to   create a secure journal of changes that have been made to each   directory entry.  Both client and server based signatures are   supported.  An object class for subsequent retrieval are "journal   entries" is also defined.  This document specifies LDAP v3 controls   that enable this functionality.  It also defines an LDAP v3 schema   that allows for subsequent browsing of the journal information.Table of Contents1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .21.1 Audit Trail Mechanism  . . . . . . . . . . . . . . . . . . .21.2. Handling the Delete Operation . . . . . . . . . . . . . . .52. Signed Results Mechanism  . . . . . . . . . . . . . . . . . .63. Security Considerations and Other Notes   . . . . . . . . . .74. References  . . . . . . . . . . . . . . . . . . . . . . . . .85. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .96. Full Copyright Statement  . . . . . . . . . . . . . . . . . .10Greenblatt & Richard          Experimental                      [Page 1]

RFC 2649                LDAP Control and Schema              August 19991.  Introduction   In many environments clients require the ability to validiate the   source and integrity of information provided by the directory.  This   document describes an LDAP message control which allows for the   retrieval of digitally signed information.  The perspective of this   document is that the origin of the information that is stored in LDAP   v3 accessible directories is the LDAP v3 client that creates the   information.  The source and integrity of the information is   guaranteed by allowing for the digital signing of the operations that   make changes to entries in the directory.  The source and integrity   of an individual LDAP connection can be guaranteed by making use of   an underlying session layer that provides such services, such as TLS.   Note that the integrity of an individual connection does not, in and   of itself guarantee the integrity of the data that comes across the   connection.  This is due to the fact that the LDAP server is only   capable of providing information that it has stored.  In distributed   and replicated environments, the fact that an entry has been   successfully retrieved from a server may not be completely   reassuring, if the entry in question was replicated from an untrusted   domain.   By making use of public key technology, and creating digitally signed   transactions that are created by the LDAP v3 client as entries are   created and modified, a complete journal of the history of the entry   is available.  Since each entry in the journal has been digitally   signed with the private key of the creator, or modifier of the entry,   the source and integrity of the directory entry can be validated by   verifying the signature of each entry in the journal.  Note that not   all of the journal entries will have been signed by the same user.1.1.  Audit Trail 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 version 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 operations.  The LDAP control is (OID =   1.2.840.113549.6.0.0):Greenblatt & Richard          Experimental                      [Page 2]

RFC 2649                LDAP Control and Schema              August 1999      SignedOperation ::= CHOICE {           signbyServer   NULL,           signatureIncluded   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 successful result of processing the control is the   creation of additional information in the directory entry that is   being modified or created. The signature of the LDAP operation is   computed on the LDAPMessage prior to the inclusion of the   SignedOperation control. The procedure is as follows:      - Build LDAPMessage without the SignedOperation control      - Compute signature on the above LDAPMessage      - Create new LDAPMessage that includes the old MessageID,        protocolOp and any control fields from the previous LDAPMessage,        plus  the computed signature formatted as an S/MIME message.   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.  The server can accept the signed operation without   verifying the signature.  Signature verification can be quite a   lengthy operation, requiring complex certificate chain traversals.   This allows a more timely creation of the audit trail by the server.   Any LDAP client browsing the directory that retrieves the 'Changes'   (defined in the following paragraphs) attributes, should verify the   signature of each value according to the local signature verification   policies.  Even if the LDAP server verifies the signature contained   in the singed operation, the LDAP client has no way of knowing what   policies were followed by the server in order to verify the   signature.   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") MAY be   included in the errorMessage of the LDAPResult.  The SignedOperation   Control MAY be marked CRITICAL, and if it is CRITICAL then if the   LDAP Server performs the LDAP operation, then must include the   signature in the signedAuditTrail information.Greenblatt & Richard          Experimental                      [Page 3]

RFC 2649                LDAP Control and Schema              August 1999      The schema definition for the signedAuditTrail information is:      ( 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:      Changes ::= SEQUENCE {           sequenceNumber [0] INTEGER (0 .. maxInt),           signedOperation [1] OCTET STRING }   The SignedOperation attribute is a multipart/signed S/MIME message.   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].   Subsequent 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.  Sequence   numbers are meaningful only within the context of a single directory   entry, and LDAP servers are not expected to maintain these sequence   numbers across all entries in the directory.   Some LDAP servers will only allow operations that include the   SignedOperation control.  This is indicated by the inclusion of a   'signedDirectoryOperationSupport' attribute in the rootDSE.  This   attribute is defined as:Greenblatt & Richard          Experimental                      [Page 4]

RFC 2649                LDAP Control and Schema              August 1999      1.2.840.113549.6.2.2      NAME 'signedDirectoryOperationSupport'      DESC 'how many of the LDAP operations must be signed'      SYNTAX 'Integer' SINGLE-VALUE )   The 'signedDirectoryOperationSupport' attribute above may have one of   the values, '0', '1' or '2' with the following meanings:      - '0' Directory Operations may be signed      - '1' Directory Operations must always be signed      - '2' Directory Operations must never be signed   Some LDAP servers will desire that the audit trail be continuous, and   not contain any gaps that would result from unsigned operations.   Such server will include a signature on each LDAP operation that   changes a directory entry, even when the LDAP client does not include   a signed-Operation control.1.2.  Handling the Delete Operation   The LDAP Delete operation represents an interesting case for Signed   Directory Operations.  This is due to the case that subsequent to the   successful completion of the Delete Operation, the object that would   have held the latest 'Changes' attribute no longer exists.  In order   to handle this situation, a new object class is defined to represent   a directory object that has been deleted.      ( 1.2.840.113549.6.1.2      NAME 'zombieObject'      SUP top      STRUCTURAL      MUST (      Cn $ Changes $ OriginalObject      )         )      The format of the OriginalObject attribute is:      ( 1.2.840.113549.6.2.1      NAME OriginalObject      DESC 'The LDAP URL of an object that has been deleted from the      directory' SYNTAX 'Binary' )   The OriginalObject attribute contains the URL of the object that was   deleted from the directory.  It is formatted in accordance withRFC2255.  Directory servers that comply with this specification SHOULD   create a zombieObject when performing the delete Operation that   contains a SignedOperation LDAPControl.  The Cn attribute of theGreenblatt & Richard          Experimental                      [Page 5]

RFC 2649                LDAP Control and Schema              August 1999   zombieObject is synthesized by the LDAP server, and may or may not be   related to the original name of the directory entry that was deleted.   All changes attributes that were attached to the original entry are   copied over to the zombieObject.  In addition the LDAP Server MUST   attach the signature of the Delete operation as the last successful   change that was made to the entry.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 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 ::=  LDAPSigType      LDAPSigType ::= BOOLEAN   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.  Some LDAP v3 servers may be configured   to sign all of their operations.  In this situation the server always   returns a SignedResult control, unless instructed otherwise by the   DemandSigne-dResult Control.  Since the SignedResult control is not   marked critical, the LDAP client is allowed to ignore it.  The   signature field below includes the signature of the enitre LDAPResult   formatted as an S/MIME pkcs-7/signature object, as defined in [2].Greenblatt & Richard          Experimental                      [Page 6]

RFC 2649                LDAP Control and Schema              August 1999   The procedure for creating the signature of the signedResult control   is the same as the procedure for the creation of the signedOperation   control.  The LDAP control in the LDAP response is (OID =   1.2.840.113549.6.0.2):      SignedResult ::= CHOICE {           signature     OCTET STRING }3.  Security Considerations and Other 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}      The complete ASN.1 module for this specification is:      SIGNEDOPERATIONS DEFINITIONS ::=      BEGIN      SignedOperation ::= CHOICE {           signbyServer   NULL,           signatureIncluded   OCTET STRING       }      Changes ::= SEQUENCE {           sequenceNumber [0] INTEGER (0 .. maxInt),           signedOperation [1] OCTET STRING }      DemandSignedResult ::=  LDAPSigType      LDAPSigType ::= BOOLEAN      SignedResult ::= CHOICE {           signature     OCTET STRING }      ENDGreenblatt & Richard          Experimental                      [Page 7]

RFC 2649                LDAP Control and Schema              August 1999   If any of the controls in this specification are supported by an LDAP   v3 server then that server MUST make available its certificate (if   any) in the userCertificate attribute of its rootDSE object.  The   UserCertificate attribute is defined in [6], and contains the public   key of the server that is used in the creation of the various   signatures defined in this specification.   It is not the intention of this specification to provide a mechanism   that guarantees the origin and integrity of LDAP v3 operations.  Such   a service is best provided by the use of an underlying protocol such   as TLS [8].  TLS defines additional features such as encryption and   compression.  This specification does not define support for   encrypted operations.   This memo proposes protocol elements for transmission and storage of   the digital signatures of LDAP operations.  Though the LDAP server   may have verified the operation signatures prior to their storage and   subsequent retrieval, it is prudent for LDAP clients to verify the   signatures contained in the chained attribute upon their retrieval.   The issuing Certification Authorities of the signer's certificate   should also be consulted in order to determine if the signer's   private key has been compromised or the certificate has been   otherwise revoked.  Security considerations are discussed throughout   this memo.4.  References   [1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5",RFC 2315, March 1998.   [2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.       Repka., "S/MIME Version 2 Message Specification",RFC 2311, March       1998.   [3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security       Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",RFC 1847, October 1995.   [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access       Protocol (v3)",RFC 2251, December 1997.   [5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for       Directory Information",RFC 2425, September 1998.   [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with       LDAPv3",RFC 2256, December 1997.Greenblatt & Richard          Experimental                      [Page 8]

RFC 2649                LDAP Control and Schema              August 1999   [7] Howes, T. and M. Smith, "The LDAP URL Format",RFC 2255, December       1997.   [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",RFC2246, January 1999.5.  Authors' Addresses   Bruce Greenblatt   San Jose, CA 95119   USA   Phone: +1-408-224-5349   EMail: bgreenblatt@directory-applications.com   Pat Richard   Xcert Software, Inc.   Suite 1001 - 701 W. Georgia   Vancouver, BC   CANADA V6G 1C9   EMail: patr@xcert.comGreenblatt & Richard          Experimental                      [Page 9]

RFC 2649                LDAP Control and Schema              August 19996.  Full Copyright Statement   Copyright (C) The Internet Society (1999).  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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Greenblatt & Richard          Experimental                     [Page 10]