idnits 2.17.1 draft-ietf-ldapext-sigops-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 -- Found 10 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 4 instances of too long lines in the document, the longest one being 9 characters 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 117: '...defined in [4]. The LDAP server MAY attempt to parse and verify the...' RFC 2119 keyword, line 133: '... to verify signature") MAY be included...' RFC 2119 keyword, line 134: '...sult. The SignedOperation Control MAY...' RFC 2119 keyword, line 145: '... MUST (...' RFC 2119 keyword, line 214: '... MUST (...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 104 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 300, but not defined == Unused Reference: '7' is defined on line 358, 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 (==), 5 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 An LDAP Control and Schema for Holding Operation Signatures 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 This document is an Internet-Draft and is in full conformance with 47 all provisions of Section 10 of RFC2026. 49 In many environments clients require the ability to validiate the 50 source and integrity of information provided by the directory. This 51 document describes an LDAP message control which allows for the 52 retrieval of digitally signed information. The perspective of this doc- 53 ument is that the origin of the information that is stored in LDAP v3 54 accessible directories is the LDAP v3 client that creates the informa- 55 tion. The source and integrity of the information is guaranteed by 56 allowing for the digital signing of the operations that make changes to 57 entries in the directory. The source and integrity of an individual 58 LDAP connection can be guaranteed by making use of an underlying session 59 layer that provides such services, such as TLS. Note that the integrity 60 of an individual connection does not, in and of itself guarantee the 61 integrity of the data that comes across the connection. This is due to 62 the fact that the LDAP server is only capable of providing information 63 that it has stored. In distributed and replicated environments, the 64 fact that an entry has been successfully retrieved from a server may not 65 be completely reassuring, if the entry in question was replicated from 66 an untrusted domain. 68 By making use of public key technology, and creating digitally 69 signed transactions that are created by the LDAP v3 client as entries 70 are created and modified, a complete journal of the history of the entry 71 is available. Since each entry in the journal has been digitally signed 72 with the private key of the creator, or modifier of the entry, the 73 source and integrity of the directory entry can be validated by verify- 74 ing the signature of each entry in the journal. Note that not all of 75 the journal entries will have been signed by the same user. 77 1.1. Audit Trail Mechanism 79 Signed directory operations is a straightforward application of 80 S/MIME technology that also leverages the extensible framework that is 81 provided by LDAP version 3. LDAP version 3 is defined in [4], and 82 S/MIME is defined in [2]. The security used in S/MIME is based in the 83 definitions in [1]. The basic idea is that the submitter of an LDAP 84 operation that changes the directory information includes an LDAP ver- 85 sion 3 control that includes either a signature of the operation, or a 86 request that the LDAP server sign the operation on the behalf of the 87 LDAP client. The result of the operation (in addition to the change of 88 the directory information), is additional information that is attached 89 to directory objects, that includes the audit trail of signed opera- 90 tions. The LDAP control is (OID = 1.2.840.113549.6.0.0): 92 SignedOperation ::= CHOICE { 93 signbyServer NULL, 94 signatureIncluded OCTET STRING 95 } 97 If the SignatureIncluded CHOICE is used, then the OCTET string is 98 just an S/MIME message of the multipart/signed variety, that is composed 99 of a single piece, that is the signature of the directory operation. 100 Multipart/signed MIME objects are defined in [3]. If the SignbyServer 101 CHOICE us used, then the LDAP server creates the signature on behalf of 102 the client, using its own identity and not the identity of the client, 103 in order to produce the audit trail entry. In either case the success- 104 ful result of processing the control is the creation of additional 105 information in the directory entry that is being modified or created. 106 The signature of the LDAP operation is computed on the LDAPMessage prior 107 to the inclusion of the SignedOperation control. The procedure is as 108 follows: 110 - Build LDAPMessage without the SignedOperation control 111 - Compute signature on the above LDAPMessage 112 - Create new LDAPMessage that includes the old MessageID, protocolOp and any 113 control fields from the previous LDAPMessage, plus the computed signature 114 formatted as an S/MIME message. 116 No control is defined for the server to return in the LDAPResult as 117 defined in [4]. The LDAP server MAY attempt to parse and verify the 118 signature included in the SignedOperation control, but is not required 119 to. The server can accept the signed operation without verifying the 120 signature. Signature verification can be quite a lengthy operation, 121 requiring complex certificate chain traversals. This allows a more 122 timely creation of the audit trail by the server. Any LDAP client 123 browsing the directory that retrieves the 'Changes' (defined in the fol- 124 lowing paragraphs) attributes, should verify the signature of each value 125 according to the local signature verification policies. Even if the 126 LDAP server verifies the signature contained in the singed operation, 127 the LDAP client has no way of knowing what policies were followed by the 128 server in order to verify the signature. 130 If the LDAP server is unable to verify the signature and wishes to 131 return an error then the error code unwillingToPerform(53) should be 132 returned, and the entire LDAP operation fails. In this situation, an 133 appropriate message (e.g. "Unable to verify signature") MAY be included 134 in the errorMessage of the LDAPResult. The SignedOperation Control MAY 135 be marked CRITICAL, and if it is CRITICAL then if the LDAP Server per- 136 forms the LDAP operation, then must include the signature in the 137 signedAuditTrail information. 139 The schema definition for the signedAuditTrail information is: 141 ( 1.2.840.113549.6.1.0 142 NAME 'signedAuditTrail' 143 SUP top 144 AUXILIARY 145 MUST ( 146 Changes 147 ) 148 ) 150 The format of the Changes attribute is: 152 ( 1.2.840.113549.6.2.0 153 NAME 'Changes' 154 DESC 'a set of changes applied to an entry' 155 SYNTAX 'Binary' ) 157 The actual format of the Changes attribute is: 159 Changes ::= SEQUENCE { 160 sequenceNumber [0] INTEGER (0 .. maxInt), 161 signedOperation [1] OCTET STRING } 163 The SignedOperation attribute is a multipart/signed S/MIME mes- 164 sage. Part 1 of the message is the directory operation, and part 2 is 165 the signature. Sequence number 0 (if present) always indicates the 166 starting point directory object as represented by the definitions in "A 167 MIME Content-Type for Directory Information", as defined in [5]. Subse- 168 quent sequence numbers indicate the sequence of changes that have been 169 made to this directory object. Note that the sequence of the changes 170 can be verified due to the fact that the signed directory object will 171 have a timestamp as part of the signature object, and that the sequence 172 numbering as part of the change attribute should be considered to be an 173 unverified aid to the LDAP client. Sequence numbers are meaningful only 174 within the context of a single directory entry, and LDAP servers are not 175 expected to maintain these sequence numbers across all entries in the 176 directory. 178 Some LDAP servers will only allow operations that include the 179 SignedOperation control. This is indicated by the inclusion of a 180 'signedDirectoryOperationSupport' attribute in the rootDSE. This 181 attribute is defined as: 183 ( 1.2.840.113549.6.2.2 184 NAME 'signedDirectoryOperationSupport' 185 DESC 'how many of the LDAP operations must be signed' 186 SYNTAX 'Integer' SINGLE-VALUE ) 188 The 'signedDirectoryOperationSupport' attribute above may have one 189 of the values, '0', '1' or '2' with the following meanings: 191 - '0' Directory Operations may be signed 192 - '1' Directory Operations must always be signed 193 - '2' Directory Operations must never be signed 195 Some LDAP servers will desire that the audit trail be continuous, 196 and not contain any gaps that would result from unsigned operations. 197 Such server will include a signature on each LDAP operation that changes 198 a directory entry, even when the LDAP client does not include a signed- 199 Operation control. 201 1.2. Handling the Delete Operation 203 The LDAP Delete operation represents an interesting case for Signed 204 Directory Operations. This is due to the case that subsequent to the 205 successful completion of the Delete Operation, the object that would 206 have held the latest 'Changes' attribute no longer exists. In order to 207 handle this situation, a new object class is defined to represent a 208 directory object that has been deleted. 210 ( 1.2.840.113549.6.1.2 211 NAME 'zombieObject' 212 SUP top 213 STRUCTURAL 214 MUST ( 215 Cn $ Changes $ OriginalObject 216 ) 217 ) 219 The format of the OriginalObject attribute is: 221 ( 1.2.840.113549.6.2.1 222 NAME OriginalObject 223 DESC 'The LDAP URL of an object that has been deleted from the directory' 224 SYNTAX 'Binary' ) 225 The OriginalObject attribute contains the URL of the object that 226 was deleted from the directory. It is formatted in accordance with RFC 227 2255. Directory servers that comply with this specification SHOULD cre- 228 ate a zombieObject when performing the delete Operation that contains a 229 SignedOperation LDAPControl. The Cn attribute of the zombieObject is 230 synthesized by the LDAP server, and may or may not be related to the 231 original name of the directory entry that was deleted. All changes 232 attributes that were attached to the original entry are copied over to 233 the zombieObject. In addition the LDAP Server MUST attach the signature 234 of the Delete operation as the last successful change that was made to 235 the entry. 237 2. Signed Results Mechanism 239 A control is also defined that allows the LDAP v3 client to request 240 that the server sign the results that it returns. It is intended that 241 this control is primarily used in concert with the LDAPSearch operation. 242 This control MAY be marked as CRITICAL. If it is marked as CRITICAL and 243 the LDAP Server supports this operation, then all search results MUST be 244 returned with a signature as attached in the SignedResult control if it 245 is willing to sign results for this user. If the server supports this 246 control but does not wish to sign the results for this user then the 247 error code unwillingToPerform(53) should be returned, and the LDAP 248 search will have failed. In this situation, an appropriate message 249 (e.g. "Unwilling to sign results for you!") MUST be included in the 250 errorMessage of the LDAPResult. If the LDAPSigType has the value FALSE 251 then the client is requesting that the server not sign this operation. 252 This may be done in situations where servers are configured to always 253 sign their operations. 255 The LDAP control to include in the LDAP request is (OID = 256 1.2.840.113549.6.0.1): 258 DemandSignedResult ::= LDAPSigType 260 LDAPSigType ::= BOOLEAN 262 In response to a DemandSignedResult control, the LDAP v3 server 263 will return a SignedResult control in addition to the normal result as 264 defined by the operation (assuming that the server understands the con- 265 trol, and is willing to perform it). The SignedResult control MUST NOT 266 be marked CRITICAL. Some LDAP v3 servers may be configured to sign all 267 of their operations. In this situation the server always returns a 268 SignedResult control, unless instructed otherwise by the DemandSigne- 269 dResult Control. Since the SignedResult control is not marked critical, 270 the LDAP client is allowed to ignore it. The signature field below 271 includes the signature of the enitre LDAPResult formatted as an S/MIME 272 pkcs-7/signature object, as defined in [2]. The procedure for creating 273 the signature of the signedResult control is the same as the procedure 274 for the creation of the signedOperation control. The LDAP control in 275 the LDAP response is (OID = 1.2.840.113549.6.0.2): 277 SignedResult ::= CHOICE { 278 signature OCTET STRING } 280 3. Security Considerations and Other Notes 282 The base OIDs are: 284 rsadsiLdap ::= {1 2 840 113549 6} 285 rsadsiLdapControls ::= {1 2 840 113549 6 0} 286 rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1} 287 rsadsiLdapAttributes ::= {1 2 840 113549 6 2} 289 The complete ASN.1 module for this specification is: 291 SIGNEDOPERATIONS DEFINITIONS ::= 292 BEGIN 294 SignedOperation ::= CHOICE { 295 signbyServer NULL, 296 signatureIncluded OCTET STRING 297 } 299 Changes ::= SEQUENCE { 300 sequenceNumber [0] INTEGER (0 .. maxInt), 301 signedOperation [1] OCTET STRING } 303 DemandSignedResult ::= LDAPSigType 305 LDAPSigType ::= BOOLEAN 307 SignedResult ::= CHOICE { 308 signature OCTET STRING } 310 END 312 If any of the controls in this specification are supported by an 313 LDAP v3 server then that server MUST make available its certificate (if 314 any) in the userCertificate attribute of its rootDSE object. The 315 UserCertificate attribute is defined in [6], and contains the public key 316 of the server that is used in the creation of the various signatures 317 defined in this specification. 319 It is not the intention of this specification to provide a mecha- 320 nism that guarantees the origin and integrity of LDAP v3 operations. 321 Such a service is best provided by the use of an underlying protocol 322 such as TLS [8]. TLS defines additional features such as encryption and 323 compression. This specification does not define support for encrypted 324 operations. 326 This draft proposes protocol elements for transmission and storage 327 of the digital signatures of LDAP operations. Though the LDAP server 328 may have verified the operation signatures prior to their storage and 329 subsequent retrieval, it is prudent for LDAP clients to verify the sig- 330 natures contained in the chained attribute upon their retrieval. The 331 issuing Certification Authorities of the signer's certificate should 332 also be consulted in order to determine if the signer's private key has 333 been compromised or the certificate has been otherwise revoked. Secu- 334 rity considerations are discussed throughout this draft. 336 4. References 338 [1] RFC 2315 PKCS 7: Cryptographic Message Syntax Version 1-5. B. 339 Kaliski. March 1998. 341 [2] RFC 2311 S/MIME Version 2 Message Specification. S. Dusse, P. 342 Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. 344 [3] RFC 1847 Security Multiparts for MIME: Multipart/Signed and 345 Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Freed. Octo- 346 ber 1995. 348 [4] RFC 2251 Lightweight Directory Access Protocol (v3). M. Wahl, 349 T. Howes, S. Kille. December 1997. 351 [5] Internet Draft, work in progress, "A MIME Content-Type for 352 Directory Information", Tim Howes, Mark Smith, Frank Dawson Jr., 353 04/22/1998. 355 [6] RFC 2256 A Summary of the X.500(96) User Schema for use with 356 LDAPv3. M. Wahl. December 1997. 358 [7] RFC 2255 The LDAP URL Format. T. Howes, M. Smith. December 359 1997. 361 [8] Internet Draft, work in progress, "The TLS Protocol Version 362 1.0", Tim Dierks, Chris Allen., 11/12/1997. 364 5. Author's Addresses 366 Bruce Greenblatt 367 San Jose, CA 95119 368 USA 369 Email: bgreenblatt@directory-applications.com 370 Phone: +1-408-224-5349 372 Pat Richard 373 Xcert Software, Inc. 374 Suite 1001 - 701 W. Georgia 375 Vancouver, BC 376 CANADA V6G 1C9 377 Email: patr@xcert.com 378 TTaabbllee ooff CCoonntteennttss 380 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 381 1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . . . 2 382 1.2. Handling the Delete Operation . . . . . . . . . . . . . . . . . 5 383 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . . . 6 384 3. Security Considerations and Other Notes . . . . . . . . . . . . 7 385 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 386 5. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9