idnits 2.17.1 draft-ietf-ldapext-sigops-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '...defined in [4]. The LDAP server MAY attempt to parse and verify the...' RFC 2119 keyword, line 130: '... to verify signature") MAY be included...' RFC 2119 keyword, line 131: '...sult. The SignedOperation Control MAY...' RFC 2119 keyword, line 142: '... MUST (...' RFC 2119 keyword, line 211: '... MUST (...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 101 has weird spacing: '...tion of addit...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 299, but not defined == Unused Reference: '7' is defined on line 346, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. '1') ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. '2') ** Obsolete normative reference: RFC 2251 (ref. '4') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2256 (ref. '6') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 2255 (ref. '7') (Obsoleted by RFC 4510, RFC 4516) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LDAP Extensions Working Group Bruce Greenblatt 3 Internet Draft Pat Richard 4 5 Expires in six months 7 Signed Directory Operations Using S/MIME 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or made obsolete by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress". 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 25 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 In many environments clients require the ability to validiate the 33 source and integrity of information provided by the directory. This 34 document describes an LDAP message control which allows for the 35 retrieval of digitally signed information. This document defines an LDAP 36 v3 based mechanism for signing directory operations in order to create a 37 secure journal of changes that have been made to each directory entry. 38 Both client and server based signatures are supported. An object class 39 for subsequent retrieval are 'journal entries' is also defined. This 40 document specifies LDAP v3 controls that enable this functionality. It 41 also defines an LDAP v3 schema that allows for subsequent browsing of 42 the journal information. 44 1. Introduction 46 In many environments clients require the ability to validiate the 47 source and integrity of information provided by the directory. This 48 document describes an LDAP message control which allows for the 49 retrieval of digitally signed information. The perspective of this doc- 50 ument is that the origin of the information that is stored in LDAP v3 51 accessible directories is the LDAP v3 client that creates the informa- 52 tion. The source and integrity of the information is guaranteed by 53 allowing for the digital signing of the operations that make changes to 54 entries in the directory. The source and integrity of an individual 55 LDAP connection can be guaranteed by making use of an underlying session 56 layer that provides such services, such as TLS. Note that the integrity 57 of an individual connection does not, in and of itself guarantee the 58 integrity of the data that comes across the connection. This is due to 59 the fact that the LDAP server is only capable of providing information 60 that it has stored. In distributed and replicated environments, the 61 fact that an entry has been successfully retrieved from a server may not 62 be completely reassuring, if the entry in question was replicated from 63 an untrusted domain. 65 By making use of public key technology, and creating digitally 66 signed transactions that are created by the LDAP v3 client as entries 67 are created and modified, a complete journal of the history of the entry 68 is available. Since each entry in the journal has been digitally signed 69 with the private key of the creator, or modifier of the entry, the 70 source and integrity of the directory entry can be validated by verify- 71 ing the signature of each entry in the journal. Note that not all of 72 the journal entries will have been signed by the same user. 74 1.1. Audit Trail Mechanism 76 Signed directory operations is a straightforward application of 77 S/MIME technology that also leverages the extensible framework that is 78 provided by LDAP version 3. LDAP version 3 is defined in [4], and 79 S/MIME is defined in [2]. The security used in S/MIME is based in the 80 definitions in [1]. The basic idea is that the submitter of an LDAP 81 operation that changes the directory information includes an LDAP ver- 82 sion 3 control that includes either a signature of the operation, or a 83 request that the LDAP server sign the operation on the behalf of the 84 LDAP client. The result of the operation (in addition to the change of 85 the directory information), is additional information that is attached 86 to directory objects, that includes the audit trail of signed opera- 87 tions. The LDAP control is (OID = 1.2.840.113549.6.0.0): 89 SignedOperation ::= CHOICE { 90 signbyServer NULL, 91 signatureIncluded OCTET STRING 92 } 94 If the SignatureIncluded CHOICE is used, then the OCTET string is 95 just an S/MIME message of the multipart/signed variety, that is composed 96 of a single piece, that is the signature of the directory operation. 97 Multipart/signed MIME objects are defined in [3]. If the SignbyServer 98 CHOICE us used, then the LDAP server creates the signature on behalf of 99 the client, using its own identity and not the identity of the client, 100 in order to produce the audit trail entry. In either case the success- 101 ful result of processing the control is the creation of additional 102 information in the directory entry that is being modified or created. 103 The signature of the LDAP operation is computed on the LDAPMessage prior 104 to the inclusion of the SignedOperation control. The procedure is as 105 follows: 107 - Build LDAPMessage without the SignedOperation control 108 - Compute signature on the above LDAPMessage 109 - Create new LDAPMessage that includes the old MessageID, protocolOp and any 110 control fields from the previous LDAPMessage, plus the computed signature 111 formatted as an S/MIME message. 113 No control is defined for the server to return in the LDAPResult as 114 defined in [4]. The LDAP server MAY attempt to parse and verify the 115 signature included in the SignedOperation control, but is not required 116 to. The server can accept the signed operation without verifying the 117 signature. Signature verification can be quite a lengthy operation, 118 requiring complex certificate chain traversals. This allows a more 119 timely creation of the audit trail by the server. Any LDAP client 120 browsing the directory that retrieves the 'Changes' (defined in the fol- 121 lowing paragraphs) attributes, should verify the signature of each value 122 according to the local signature verification policies. Even if the 123 LDAP server verifies the signature contained in the singed operation, 124 the LDAP client has no way of knowing what policies were followed by the 125 server in order to verify the signature. 127 If the LDAP server is unable to verify the signature and wishes to 128 return an error then the error code unwillingToPerform(53) should be 129 returned, and the entire LDAP operation fails. In this situation, an 130 appropriate message (e.g. "Unable to verify signature") MAY be included 131 in the errorMessage of the LDAPResult. The SignedOperation Control MAY 132 be marked CRITICAL, and if it is CRITICAL then if the LDAP Server per- 133 forms the LDAP operation, then must include the signature in the 134 signedAuditTrail information. 136 The schema definition for the signedAuditTrail information is: 138 ( 1.2.840.113549.6.1.0 139 NAME 'signedAuditTrail' 140 SUP top 141 AUXILIARY 142 MUST ( 143 Changes 144 ) 145 ) 147 The format of the Changes attribute is: 149 ( 1.2.840.113549.6.2.0 150 NAME 'Changes' 151 DESC 'a set of changes applied to an entry' 152 SYNTAX 'Binary' ) 154 The actual format of the Changes attribute is: 156 Changes ::= SEQUENCE { 157 sequenceNumber [0] INTEGER (0 .. maxInt), 158 signedOperation [1] OCTET STRING } 160 The SignedOperation attribute is a multipart/signed S/MIME mes- 161 sage. Part 1 of the message is the directory operation, and part 2 is 162 the signature. Sequence number 0 (if present) always indicates the 163 starting point directory object as represented by the definitions in "A 164 MIME Content-Type for Directory Information", as defined in [5]. Subse- 165 quent sequence numbers indicate the sequence of changes that have been 166 made to this directory object. Note that the sequence of the changes 167 can be verified due to the fact that the signed directory object will 168 have a timestamp as part of the signature object, and that the sequence 169 numbering as part of the change attribute should be considered to be an 170 unverified aid to the LDAP client. Sequence numbers are meaningful only 171 within the context of a single directory entry, and LDAP servers are not 172 expected to maintain these sequence numbers across all entries in the 173 directory. 175 Some LDAP servers will only allow operations that include the 176 SignedOperation control. This is indicated by the inclusion of a 177 'signedDirectoryOperationSupport' attribute in the rootDSE. This 178 attribute is defined as: 180 ( 1.2.840.113549.6.2.2 181 NAME 'signedDirectoryOperationSupport' 182 DESC 'how many of the LDAP operations must be signed' 183 SYNTAX 'Integer' SINGLE-VALUE ) 185 The 'signedDirectoryOperationSupport' attribute above may have one 186 of the values, '0', '1' or '2' with the following meanings: 188 - '0' Directory Operations may be signed 189 - '1' Directory Operations must always be signed 190 - '2' Directory Operations must never be signed 192 Some LDAP servers will desire that the audit trail be continuous, 193 and not contain any gaps that would result from unsigned operations. 194 Such server will include a signature on each LDAP operation that changes 195 a directory entry, even when the LDAP client does not include a signed- 196 Operation control. 198 1.2. Handling the Delete Operation 200 The LDAP Delete operation represents an interesting case for Signed 201 Directory Operations. This is due to the case that subsequent to the 202 successful completion of the Delete Operation, the object that would 203 have held the latest 'Changes' attribute no longer exists. In order to 204 handle this situation, a new object class is defined to represent a 205 directory object that has been deleted. 207 ( 1.2.840.113549.6.1.2 208 NAME 'zombieObject' 209 SUP top 210 STRUCTURAL 211 MUST ( 212 Cn $ Changes $ OriginalObject 213 ) 214 ) 216 The format of the OriginalObject attribute is: 218 ( 1.2.840.113549.6.2.1 219 NAME OriginalObject 220 DESC 'The LDAP URL of an object that has been deleted from the directory' 221 SYNTAX 'Binary' ) 222 The OriginalObject attribute contains the URL of the object that 223 was deleted from the directory. It is formatted in accordance with RFC 224 2255. Directory servers that comply with this specification SHOULD cre- 225 ate a zombieObject when performing the delete Operation that contains a 226 SignedOperation LDAPControl. The Cn attribute of the zombieObject is 227 synthesized by the LDAP server, and may or may not be related to the 228 original name of the directory entry that was deleted. All changes 229 attributes that were attached to the original entry are copied over to 230 the zombieObject. In addition the LDAP Server MUST attach the signature 231 of the Delete operation as the last successful change that was made to 232 the entry. 234 2. Signed Results Mechanism 236 A control is also defined that allows the LDAP v3 client to request 237 that the server sign the results that it returns. It is intended that 238 this control is primarily used in concert with the LDAPSearch operation. 239 This control MAY be marked as CRITICAL. If it is marked as CRITICAL and 240 the LDAP Server supports this operation, then all search results MUST be 241 returned with a signature as attached in the SignedResult control if it 242 is willing to sign results for this user. If the server supports this 243 control but does not wish to sign the results for this user then the 244 error code unwillingToPerform(53) should be returned, and the LDAP 245 search will have failed. In this situation, an appropriate message 246 (e.g. "Unwilling to sign results for you!") MUST be included in the 247 errorMessage of the LDAPResult. If the LDAPSigType has the value FALSE 248 then the client is requesting that the server not sign this operation. 249 This may be done in situations where servers are configured to always 250 sign their operations. 252 The LDAP control to include in the LDAP request is (OID = 253 1.2.840.113549.6.0.1): 255 DemandSignedResult ::= LDAPSigType 257 LDAPSigType ::= BOOLEAN 259 In response to a DemandSignedResult control, the LDAP v3 server 260 will return a SignedResult control in addition to the normal result as 261 defined by the operation (assuming that the server understands the con- 262 trol, and is willing to perform it). The SignedResult control MUST NOT 263 be marked CRITICAL. Some LDAP v3 servers may be configured to sign all 264 of their operations. In this situation the server always returns a 265 SignedResult control, unless instructed otherwise by the DemandSigne- 266 dResult Control. Since the SignedResult control is not marked critical, 267 the LDAP client is allowed to ignore it. The signature field below 268 includes the signature of the enitre LDAPResult formatted as an S/MIME 269 pkcs-7/signature object, as defined in [2]. The procedure for creating 270 the signature of the signedResult control is the same as the procedure 271 for the creation of the signedOperation control. The LDAP control in 272 the LDAP response is (OID = 1.2.840.113549.6.0.2): 274 SignedResult ::= CHOICE { 275 signature OCTET STRING } 277 Do there need to be other kinds of signed results??? 279 3. Notes 281 The base OIDs are: 283 rsadsiLdap ::= {1 2 840 113549 6} 284 rsadsiLdapControls ::= {1 2 840 113549 6 0} 285 rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1} 286 rsadsiLdapAttributes ::= {1 2 840 113549 6 2} 288 The complete ASN.1 module for this specification is: 290 SIGNEDOPERATIONS DEFINITIONS ::= 291 BEGIN 293 SignedOperation ::= CHOICE { 294 signbyServer NULL, 295 signatureIncluded OCTET STRING 296 } 298 Changes ::= SEQUENCE { 299 sequenceNumber [0] INTEGER (0 .. maxInt), 300 signedOperation [1] OCTET STRING } 302 DemandSignedResult ::= LDAPSigType 304 LDAPSigType ::= BOOLEAN 306 SignedResult ::= CHOICE { 307 signature OCTET STRING } 309 END 310 If any of the controls in this specification are supported by an 311 LDAP v3 server then that server MUST make available its certificate (if 312 any) in the userCertificate attribute of its rootDSE object. The 313 UserCertificate attribute is defined in [6], and contains the public key 314 of the server that is used in the creation of the various signatures 315 defined in this specification. 317 It is not the intention of this specification to provide a mecha- 318 nism that guarantees the origin and integrity of LDAP v3 operations. 319 Such a service is best provided by the use of an underlying protocol 320 such as TLS [8]. TLS defines additional features such as encryption and 321 compression. This specification does not define support for encrypted 322 operations. 324 4. References 326 [1] RFC 2315 PKCS 7: Cryptographic Message Syntax Version 1-5. B. 327 Kaliski. March 1998. 329 [2] RFC 2311 S/MIME Version 2 Message Specification. S. Dusse, P. 330 Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. 332 [3] RFC 1847 Security Multiparts for MIME: Multipart/Signed and 333 Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Freed. Octo- 334 ber 1995. 336 [4] RFC 2251 Lightweight Directory Access Protocol (v3). M. Wahl, 337 T. Howes, S. Kille. December 1997. 339 [5] Internet Draft, work in progress, "A MIME Content-Type for 340 Directory Information", Tim Howes, Mark Smith, Frank Dawson Jr., 341 04/22/1998. 343 [6] RFC 2256 A Summary of the X.500(96) User Schema for use with 344 LDAPv3. M. Wahl. December 1997. 346 [7] RFC 2255 The LDAP URL Format. T. Howes, M. Smith. December 347 1997. 349 [8] Internet Draft, work in progress, "The TLS Protocol Version 350 1.0", Tim Dierks, Chris Allen., 11/12/1997. 352 5. Author's Addresses 353 Bruce Greenblatt 354 San Jose, CA 95119 355 USA 356 Email: bruceg@innetix.com 357 Phone: +1-408-224-5349 359 Pat Richard 360 Xcert Software, Inc. 361 Suite 1001 - 701 W. Georgia 362 Vancouver, BC 363 CANADA V6G 1C9 364 Email: patr@xcert.com 365 Table of Contents 367 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 368 1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . . . 2 369 1.2. Handling the Delete Operation . . . . . . . . . . . . . . . . . 5 370 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . . . 6 371 3. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 372 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 373 5. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8