idnits 2.17.1 draft-ietf-ldapext-sigops-02.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 8 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 81: '...defined in [4]. The LDAP server MAY attempt to parse and verify the...' RFC 2119 keyword, line 97: '... to verify signature") MAY be included...' RFC 2119 keyword, line 98: '...sult. The SignedOperation Control MAY...' RFC 2119 keyword, line 109: '... MUST (...' RFC 2119 keyword, line 179: '... MUST (...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 66 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 section? '4' on line 307 looks like a reference -- Missing reference section? '2' on line 300 looks like a reference -- Missing reference section? '1' on line 297 looks like a reference -- Missing reference section? '0' on line 269 looks like a reference -- Missing reference section? '3' on line 303 looks like a reference -- Missing reference section? '5' on line 310 looks like a reference -- Missing reference section? '6' on line 314 looks like a reference -- Missing reference section? '8' on line 320 looks like a reference -- Missing reference section? '7' on line 317 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 LDAP Extensions Working Group Bruce Greenblatt 2 Internet Draft Pat Richard 3 4 Expires in six months 6 Signed Directory Operations Using S/MIME 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months. Internet-Drafts may be updated, replaced, or made obsolete by 17 other documents at any time. It is not appropriate to use Internet- 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress". 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 24 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 25 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 This document defines an LDAP v3 based mechanism for signing direc- 32 tory operations in order to create a secure journal of changes that have 33 been made to each directory entry. Both client and server based signa- 34 tures are supported. An object class for subsequent retrieval are 35 "journal entries" is also defined. This document specifies LDAP v3 con- 36 trols that enable this functionality. It also defines an LDAP v3 schema 37 that allows for subsequent browsing of the journal information. 39 1. Audit Trail Mechanism 41 Signed directory operations is a straightforward application of 42 S/MIME technology that also leverages the extensible framework that is 43 provided by LDAP version 3. LDAP version 3 is defined in [4], and 44 S/MIME is defined in [2]. The security used in S/MIME is based in the 45 definitions in [1]. The basic idea is that the submitter of an LDAP 46 operation that changes the directory information includes an LDAP ver- 47 sion 3 control that includes either a signature of the operation, or a 48 request that the LDAP server sign the operation on the behalf of the 49 LDAP client. The result of the operation (in addition to the change of 50 the directory information), is additional information that is attached 51 to directory objects, that includes the audit trail of signed opera- 52 tions. The LDAP control is (OID = 1.2.840.113549.6.0.0): 54 SignedOperation ::= CHOICE { 55 signbyServer [0] BOOLEAN, 56 signatureIncluded [1] OCTET STRING 57 } 59 If the SignatureIncluded CHOICE is used, then the OCTET string is 60 just an S/MIME message of the multipart/signed variety, that is composed 61 of a single piece, that is the signature of the directory operation. 62 Multipart/signed MIME objects are defined in [3]. If the SignbyServer 63 CHOICE us used, then the LDAP server creates the signature on behalf of 64 the client, using its own identity and not the identity of the client, 65 in order to produce the audit trail entry. In either case the success- 66 ful result of processing the control is the creation of additional 67 information in the directory entry that is being modified or created. 68 The signature of the LDAP operation is computed on the LDAPMessage prior 69 to the inclusion of the SignedOperation control. The procedure is as 70 follows: 72 - Build LDAPMessage without the SignedOperation control 73 - Compute signature on the above LDAPMessage 74 - Create new LDAPMessage that includes the old MessageID, protocolOp 75 and any 76 control fields from the previous LDAPMessage, plus the computed 77 signature 78 formatted as an S/MIME message. 80 No control is defined for the server to return in the LDAPResult as 81 defined in [4]. The LDAP server MAY attempt to parse and verify the 82 signature included in the SignedOperation control, but is not required 83 to. The server can accept the signed operation without verifying the 84 signature. Signature verification can be quite a lengthy operation, 85 requiring complex certificate chain traversals. This allows a more 86 timely creation of the audit trail by the server. Any LDAP client 87 browsing the directory that retrieves the 'Changes' (defined in the fol- 88 lowing paragraphs) attributes, should verify the signature of each value 89 according to the local signature verification policies. Even if the 90 LDAP server verifies the signature contained in the singed operation, 91 the LDAP client has no way of knowing what policies were followed by the 92 server in order to verify the signature. 94 If the LDAP server is unable to verify the signature and wishes to 95 return an error then the error code unwillingToPerform(53) should be 96 returned, and the entire LDAP operation fails. In this situation, an 97 appropriate message (e.g. "Unable to verify signature") MAY be included 98 in the errorMessage of the LDAPResult. The SignedOperation Control MAY 99 be marked CRITICAL, and if it is CRITICAL then if the LDAP Server per- 100 forms the LDAP operation, then must include the signature in the 101 signedAuditTrail information. 103 The schema definition for the signedAuditTrail information is: 105 ( 1.2.840.113549.6.1.0 106 NAME 'signedAuditTrail' 107 SUP top 108 AUXILIARY 109 MUST ( 110 Changes 111 ) 112 ) 114 The format of the Changes attribute is: 116 ( 1.2.840.113549.6.2.0 117 NAME 'Changes' 118 DESC 'a set of changes applied to an entry' 119 SYNTAX 'Binary' ) 121 The actual format of the Changes attribute is: 123 Changes ::= SEQUENCE { 124 sequenceNumber [0] INTEGER (0 .. maxInt), 125 signedOperation [1] OCTET STRING } 127 The SignedOperation attribute is a multipart/signed S/MIME mes- 128 sage. Part 1 of the message is the directory operation, and part 2 is 129 the signature. Sequence number 0 (if present) always indicates the 130 starting point directory object as represented by the definitions in "A 131 MIME Content-Type for Directory Information", as defined in [5]. 133 Subsequent sequence numbers indicate the sequence of changes that have 134 been made to this directory object. Note that the sequence of the 135 changes can be verified due to the fact that the signed directory object 136 will have a timestamp as part of the signature object, and that the 137 sequence numbering as part of the change attribute should be considered 138 to be an unverified aid to the LDAP client. Sequence numbers are mean- 139 ingful only within the context of a single directory entry, and LDAP 140 servers are not expected to maintain these sequence numbers across all 141 entries in the directory. 143 Some LDAP servers will only allow operations that include the 144 SignedOperation control. This is indicated by the inclusion of a 145 'signedDirectoryOperationSupport' attribute in the rootDSE. This 146 attribute is defined as: 148 ( 1.2.840.113549.6.2.2 149 NAME 'signedDirectoryOperationSupport' 150 DESC 'how many of the LDAP operations must be signed' 151 SYNTAX 'Integer' SINGLE-VALUE ) 153 The 'signedDirectoryOperationSupport' attribute above may have one 154 of the values, '0', '1' or '2' with the following meanings: 156 - '0' Directory Operations may be signed 157 - '1' Directory Operations must always be signed 158 - '2' Directory Operations must never be signed 160 Some LDAP servers will desire that the audit trail be continuous, 161 and not contain any gaps that would result from unsigned operations. 162 Such server will include a signature on each LDAP operation that changes 163 a directory entry, even when the LDAP client does not include a signed- 164 Operation control. 166 1.1. Handling the Delete Operation 168 The LDAP Delete operation represents an interesting case for Signed 169 Directory Operations. This is due to the case that subsequent to the 170 successful completion of the Delete Operation, the object that would 171 have held the latest 'Changes' attribute no longer exists. In order to 172 handle this situation, a new object class is defined to represent a 173 directory object that has been deleted. 175 ( 1.2.840.113549.6.1.2 176 NAME 'zombieObject' 177 SUP top 178 STRUCTURAL 179 MUST ( 180 Cn $ Changes $ OriginalObject 181 ) 182 ) 184 The format of the OriginalObject attribute is: 186 ( 1.2.840.113549.6.2.1 187 NAME OriginalObject 188 DESC 'The LDAP URL of an object that has been deleted from the 189 directory' 190 SYNTAX 'Binary' ) 192 The OriginalObject attribute contains the URL of the object that 193 was deleted from the directory. It is formatted in accordance with RFC 194 2255. Directory servers that comply with this specification SHOULD cre- 195 ate a zombieObject when performing the delete Operation that contains a 196 SignedOperation LDAPControl. The Cn attribute of the zombieObject is 197 synthesized by the LDAP server, and may or may not be related to the 198 original name of the directory entry that was deleted. All changes 199 attributes that were attached to the original entry are copied over to 200 the zombieObject. In addition the LDAP Server MUST attach the signature 201 of the Delete operation as the last successful change that was made to 202 the entry. 204 2. Signed Results Mechanism 206 A control is also defined that allows the LDAP v3 client to request 207 that the server sign the results that it returns. It is intended that 208 this control is primarily used in concert with the LDAPSearch operation. 209 This control MAY be marked as CRITICAL. If it is marked as CRITICAL and 210 the LDAP Server supports this operation, then all search results MUST be 211 returned with a signature as attached in the SignedResult control if it 212 is willing to sign results for this user. If the server supports this 213 control but does not wish to sign the results for this user then the 214 error code unwillingToPerform(53) should be returned, and the LDAP 215 search will have failed. In this situation, an appropriate message 216 (e.g. "Unwilling to sign results for you!") MUST be included in the 217 errorMessage of the LDAPResult. If the LDAPSigType has the value FALSE 218 then the client is requesting that the server not sign this operation. 219 This may be done in situations where servers are configured to always 220 sign their operations. 222 The LDAP control to include in the LDAP request is (OID = 223 1.2.840.113549.6.0.1): 225 DemandSignedResult ::= LDAPSigType 227 LDAPSigType ::= BOOLEAN 229 In response to a DemandSignedResult control, the LDAP v3 server 230 will return a SignedResult control in addition to the normal result as 231 defined by the operation (assuming that the server understands the con- 232 trol, and is willing to perform it). The SignedResult control MUST NOT 233 be marked CRITICAL. Some LDAP v3 servers may be configured to sign all 234 of their operations. In this situation the server always returns a 235 SignedResult control, unless instructed otherwise by the DemandSigne- 236 dResult Control. Since the SignedResult control is not marked critical, 237 the LDAP client is allowed to ignore it. The signature field below 238 includes the signature of the enitre LDAPResult formatted as an S/MIME 239 pkcs-7/signature object, as defined in [2]. The procedure for creating 240 the signature of the signedResult control is the same as the procedure 241 for the creation of the signedOperation control. The LDAP control in 242 the LDAP response is (OID = 1.2.840.113549.6.0.2): 244 SignedResult ::= CHOICE { 245 signature OCTET STRING } 247 Do there need to be other kinds of signed results??? 249 3. Notes 251 The base OIDs are: 253 rsadsiLdap ::= {1 2 840 113549 6} 254 rsadsiLdapControls ::= {1 2 840 113549 6 0} 255 rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1} 256 rsadsiLdapAttributes ::= {1 2 840 113549 6 2} 258 The complete ASN.1 module for this specification is: 260 SIGNEDOPERATIONS DEFINITIONS ::= 261 BEGIN 263 SignedOperation ::= CHOICE { 264 signbyServer [0] BOOLEAN, 265 signatureIncluded [1] OCTET STRING 266 } 268 Changes ::= SEQUENCE { 269 sequenceNumber [0] INTEGER (0 .. maxInt), 270 signedOperation [1] OCTET STRING } 272 DemandSignedResult ::= LDAPSigType 274 LDAPSigType ::= BOOLEAN 276 SignedResult ::= CHOICE { 277 signature OCTET STRING } 279 END 281 If any of the controls in this specification are supported by an 282 LDAP v3 server then that server MUST make available its certificate (if 283 any) in the userCertificate attribute of its rootDSE object. The 284 UserCertificate attribute is defined in [6], and contains the public key 285 of the server that is used in the creation of the various signatures 286 defined in this specification. 288 It is not the intention of this specification to provide a mecha- 289 nism that guarantees the origin and integrity of LDAP v3 operations. 290 Such a service is best provided by the use of an underlying protocol 291 such as TLS [8]. TLS defines additional features such as encryption and 292 compression. This specification does not define support for encrypted 293 operations. 295 4. References 297 [1] RFC 2315 PKCS 7: Cryptographic Message Syntax Version 1-5. B. 298 Kaliski. March 1998. 300 [2] RFC 2311 S/MIME Version 2 Message Specification. S. Dusse, P. 301 Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. 303 [3] RFC 1847 Security Multiparts for MIME: Multipart/Signed and 304 Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Freed. Octo- 305 ber 1995. 307 [4] RFC 2251 Lightweight Directory Access Protocol (v3). M. Wahl, 308 T. Howes, S. Kille. December 1997. 310 [5] Internet Draft, work in progress, "A MIME Content-Type for 311 Directory Information", Tim Howes, Mark Smith, Frank Dawson Jr., 312 04/22/1998. 314 [6] RFC 2256 A Summary of the X.500(96) User Schema for use with 315 LDAPv3. M. Wahl. December 1997. 317 [7] RFC 2255 The LDAP URL Format. T. Howes, M. Smith. December 318 1997. 320 [8] Internet Draft, work in progress, "The TLS Protocol Version 321 1.0", Tim Dierks, Chris Allen., 11/12/1997. 323 5. Author's Address 325 Bruce Greenblatt 326 RSA Data Security 327 2955 Campus Drive, Suite 400 328 San Mateo, CA 94403 329 USA 330 Email: bgreenblatt@rsa.com 331 Phone: +1-650-295-7569 333 Pat Richard 334 Xcert Software, Inc. 335 Suite 1001 - 701 W. Georgia 336 Vancouver, BC 337 CANADA V6G 1C9 338 Email: patr@xcert.com 339 Table of Contents 341 1. Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . . . . 2 342 1.1. Handling the Delete Operation . . . . . . . . . . . . . . . . . 4 343 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . . . 5 344 3. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 345 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 346 5. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8