idnits 2.17.1 draft-ietf-ldapext-sigops-01.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.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. ** 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 178: '... 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 283 looks like a reference -- Missing reference section? '2' on line 276 looks like a reference -- Missing reference section? '1' on line 273 looks like a reference -- Missing reference section? '0' on line 124 looks like a reference -- Missing reference section? '3' on line 279 looks like a reference -- Missing reference section? '5' on line 286 looks like a reference -- Missing reference section? '6' on line 290 looks like a reference -- Missing reference section? '8' on line 296 looks like a reference -- Missing reference section? '7' on line 293 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 11 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 This document defines an LDAP v3 based mechanism for signing direc- 33 tory operations in order to create a secure journal of changes that have 34 been made to each directory entry. Both client and server based signa- 35 tures are supported. An object class for subsequent retrieval are 36 'journal entries' is also defined. This document specifies LDAP v3 con- 37 trols that enable this functionality. It also defines an LDAP v3 schema 38 that allows for subsequent browsing of the journal information. 40 1. Audit Trail Mechanism 42 Signed directory operations is a straightforward application of 43 S/MIME technology that also leverages the extensible framework that is 44 provided by LDAP version 3. LDAP version 3 is defined in [4], and 45 S/MIME is defined in [2]. The security used in S/MIME is based in the 46 definitions in [1]. The basic idea is that the submitter of an LDAP 47 operation that changes the directory information includes an LDAP ver- 48 sion 3 control that includes either a signature of the operation, or a 49 request that the LDAP server sign the operation on the behalf of the 50 LDAP client. The result of the operation (in addition to the change of 51 the directory information), is additional information that is attached 52 to directory objects, that includes the audit trail of signed opera- 53 tions. The LDAP control is (OID = 1.2.840.113549.6.0.0): 55 SignedOperation ::= CHOICE { 56 SignbyServer [0] BOOLEAN 57 SignatureIncluded [1] OCTET STRING } 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 88 following paragraphss) attributes, should verify the signature of each 89 value according to the local signature verification policies. Even if 90 the LDAP server verifies the signature contained in the singed opera- 91 tion, the LDAP client has no way of knowing what policies were followed 92 by the 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]. Subse- 132 quent sequence numbers indicate the sequence of changes that have been 133 made to this directory object. Note that the sequence of the changes 134 can be verified due to the fact that the signed directory object will 135 have a timestamp as part of the signature object, and that the sequence 136 numbering as part of the change attribute should be considered to be an 137 unverified aid to the LDAP client. Sequence numbers are meaningful only 138 within the context of a single directory entry, and LDAP servers are not 139 expected to maintain these sequence numbers across all entries in the 140 directory. 142 Some LDAP servers will only allow operations that include the 143 SignedOperation control. This is indicated by the inclusion of a 144 'signedDirectoryOperationSupport' attribute in the rootDSE. This 145 attribute is defined as: 147 ( 1.2.840.113549.6.2.2 148 NAME 'signedDirectoryOperationSupport' 149 DESC 'how many of the LDAP operations must be signed' 150 SYNTAX 'Integer' SINGLE-VALUE ) 152 The 'signedDirectoryOperationSupport' attribute above may have one 153 of the values, '0', '1' or '2' with the following meanings: 155 - '0' Directory Operations may be signed 156 - '1' Directory Operations must always be signed 157 - '2' Directory Operations must never be signed 159 Some LDAP servers will desire that the audit trail be continuous, 160 and not contain any gaps that would result from unsigned operations. 161 Such server will include a signature on each LDAP operation that changes 162 a directory entry, even when the LDAP client does not include a signed- 163 Operation control. 165 1.1. Handling the Delete Operation 167 The LDAP Delete operation represents an interesting case for Signed 168 Directory Operations. This is due to the case that subsequent to the 169 successful completion of the Delete Operation, the object that would 170 have held the latest 'Changes' attribute no longer exists. In order to 171 handle this situation, a new object class is defined to represent a 172 directory object that has been deleted. 174 ( 1.2.840.113549.6.1.2 175 NAME 'zombieObject' 176 SUP top 177 STRUCTURAL 178 MUST ( 179 Cn $ Changes $ OriginalObject 180 ) 181 ) 183 The format of the OriginalObject attribute is: 185 ( 1.2.840.113549.6.2.1 186 NAME OriginalObject 187 DESC 'The LDAP URL of an object that has been deleted from the 188 directory' 189 SYNTAX 'Binary' ) 191 The OriginalObject attribute contains the URL of the object that 192 was deleted from the directory. It is formatted in accordance with RFC 193 2255. Directory servers that comply with this specification SHOULD cre- 194 ate a zombieObject when performing the delete Operation that contains a 195 SignedOperation LDAPControl. The Cn attribute of the zombieObject is 196 synthesized by the LDAP server, and may or may not be related to the 197 original name of the directory entry that was deleted. All changes 198 attributes that were attached to the original entry are copied over to 199 the zombieObject. In addition the LDAP Server MUST attach the signature 200 of the Delete operation as the last successful change that was made to 201 the entry. 203 2. Signed Results Mechanism 205 A control is also defined that allows the LDAP v3 client to request 206 that the server sign the results that it returns. It is intended that 207 this control is primarily used in concert with the LDAPSearch operation. 208 This control MAY be marked as CRITICAL. If it is marked as CRITICAL and 209 the LDAP Server supports this operation, then all search results MUST be 210 returned with a signature as attached in the SignedResult control if it 211 is willing to sign results for this user. If the server supports this 212 control but does not wish to sign the results for this user then the 213 error code unwillingToPerform(53) should be returned, and the LDAP 214 search will have failed. In this situation, an appropriate message 215 (e.g. "Unwilling to sign results for you!") MUST be included in the 216 errorMessage of the LDAPResult. If the LDAPSigType has the value FALSE 217 then the client is requesting that the server not sign this operation. 218 This may be done in situations where servers are configured to always 219 sign their operations. 221 The LDAP control to include in the LDAP request is (OID = 222 1.2.840.113549.6.0.1): 224 DemandSignedResult ::= { signatureSpan LDAPSigType } 226 LDAPSigType ::= { BOOLEAN DEFAULT TRUE } 228 In response to a DemandSignedResult control, the LDAP v3 server 229 will return a SignedResult control in addition to the normal result as 230 defined by the operation (assuming that the server understands the con- 231 trol, and is willing to perform it). The SignedResult control MUST NOT 232 be marked CRITICAL. Some LDAP v3 servers may be configured to sign all 233 of their operations. In this situation the server always returns a 234 SignedResult control, unless instructed otherwise by the DemandSigne- 235 dResult Control. Since the SignedResult control is not marked critical, 236 the LDAP client is allowed to ignore it. The signature field below 237 includes the signature of the enitre LDAPResult formatted as an S/MIME 238 pkcs-7/signature object, as defined in [2]. The procedure for creating 239 the signature of the signedResult control is the same as the procedure 240 for the creation of the signedOperation control. The LDAP control in 241 the LDAP response is (OID = 1.2.840.113549.6.0.2): 243 SignedResult ::= CHOICE { 244 signature OCTET STRING } 246 Note that the signatureSpan field is still TBD! 248 3. Notes 250 The base OIDs are: 252 rsadsiLdap ::= {1 2 840 113549 6} 253 rsadsiLdapControls ::= {1 2 840 113549 6 0} 254 rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1} 255 rsadsiLdapAttributes ::= {1 2 840 113549 6 2} 257 If any of the controls in this specification are supported by an 258 LDAP v3 server then that server MUST make available its certificate (if 259 any) in the userCertificate attribute of its rootDSE object. The 260 UserCertificate attribute is defined in [6], and contains the public key 261 of the server that is used in the creation of the various signatures 262 defined in this specification. 264 It is not the intention of this specification to provide a mecha- 265 nism that guarantees the origin and integrity of LDAP v3 operations. 266 Such a service is best provided by the use of an underlying protocol 267 such as TLS [8]. TLS defines additional features such as encryption and 268 compression. This specification does not define support for encrypted 269 operations. 271 4. References 273 [1] RFC 2315 PKCS 7: Cryptographic Message Syntax Version 1-5. B. 274 Kaliski. March 1998. 276 [2] RFC 2311 S/MIME Version 2 Message Specification. S. Dusse, P. 277 Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. 279 [3] RFC 1847 Security Multiparts for MIME: Multipart/Signed and 280 Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Freed. Octo- 281 ber 1995. 283 [4] RFC 2251 Lightweight Directory Access Protocol (v3). M. Wahl, 284 T. Howes, S. Kille. December 1997. 286 [5] Internet Draft, work in progress, "A MIME Content-Type for 287 Directory Information", Tim Howes, Mark Smith, Frank Dawson Jr., 288 04/22/1998. 290 [6] RFC 2256 A Summary of the X.500(96) User Schema for use with 291 LDAPv3. M. Wahl. December 1997. 293 [7] RFC 2255 The LDAP URL Format. T. Howes, M. Smith. December 294 1997. 296 [8] Internet Draft, work in progress, "The TLS Protocol Version 297 1.0", Tim Dierks, Chris Allen., 11/12/1997. 299 55.. AAuutthhoorr''ss AAddddrreessss 301 Bruce Greenblatt 302 RSA Data Security 303 2955 Campus Drive, Suite 400 304 San Mateo, CA 94403 305 USA 306 Email: bgreenblatt@rsa.com 307 Phone: +1-650-295-7569 308 Pat Richard 309 Xcert Software, Inc. 310 Suite 1001 - 701 W. Georgia 311 Vancouver, BC 312 CANADA V6G 1C9 313 Email: patr@xcert.com 314 Table of Contents 316 1. Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . . . . 2 317 1.1. Handling the Delete Operation . . . . . . . . . . . . . . . . . 4 318 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . . . 5 319 3. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 320 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 321 5. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7