1 2 3 4 5 6 7Network Working Group B. Greenblatt 8Request for Comments: 2649 P. Richard 9Category: Experimental August 1999 10 11 12 An LDAP Control and Schema for Holding Operation Signatures 13 14Status of this Memo 15 16 This memo defines an Experimental Protocol for the Internet 17 community. It does not specify an Internet standard of any kind. 18 Discussion and suggestions for improvement are requested. 19 Distribution of this memo is unlimited. 20 21Copyright Notice 22 23 Copyright (C) The Internet Society (1999). All Rights Reserved. 24 25Abstract 26 27 In many environments clients require the ability to validiate the 28 source and integrity of information provided by the directory. This 29 document describes an LDAP message control which allows for the 30 retrieval of digitally signed information. This document defines an 31 LDAP v3 based mechanism for signing directory operations in order to 32 create a secure journal of changes that have been made to each 33 directory entry. Both client and server based signatures are 34 supported. An object class for subsequent retrieval are "journal 35 entries" is also defined. This document specifies LDAP v3 controls 36 that enable this functionality. It also defines an LDAP v3 schema 37 that allows for subsequent browsing of the journal information. 38 39Table of Contents 40 41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 42 1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . 2 43 1.2. Handling the Delete Operation . . . . . . . . . . . . . . . 5 44 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . 6 45 3. Security Considerations and Other Notes . . . . . . . . . . 7 46 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 47 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 48 6. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 49 50 51 52 53 54 55 56 57 58Greenblatt & Richard Experimental [Page 1] 59 60RFC 2649 LDAP Control and Schema August 1999 61 62 631. Introduction 64 65 In many environments clients require the ability to validiate the 66 source and integrity of information provided by the directory. This 67 document describes an LDAP message control which allows for the 68 retrieval of digitally signed information. The perspective of this 69 document is that the origin of the information that is stored in LDAP 70 v3 accessible directories is the LDAP v3 client that creates the 71 information. The source and integrity of the information is 72 guaranteed by allowing for the digital signing of the operations that 73 make changes to entries in the directory. The source and integrity 74 of an individual LDAP connection can be guaranteed by making use of 75 an underlying session layer that provides such services, such as TLS. 76 Note that the integrity of an individual connection does not, in and 77 of itself guarantee the integrity of the data that comes across the 78 connection. This is due to the fact that the LDAP server is only 79 capable of providing information that it has stored. In distributed 80 and replicated environments, the fact that an entry has been 81 successfully retrieved from a server may not be completely 82 reassuring, if the entry in question was replicated from an untrusted 83 domain. 84 85 By making use of public key technology, and creating digitally signed 86 transactions that are created by the LDAP v3 client as entries are 87 created and modified, a complete journal of the history of the entry 88 is available. Since each entry in the journal has been digitally 89 signed with the private key of the creator, or modifier of the entry, 90 the source and integrity of the directory entry can be validated by 91 verifying the signature of each entry in the journal. Note that not 92 all of the journal entries will have been signed by the same user. 93 941.1. Audit Trail Mechanism 95 96 Signed directory operations is a straightforward application of 97 S/MIME technology that also leverages the extensible framework that 98 is provided by LDAP version 3. LDAP version 3 is defined in [4], and 99 S/MIME is defined in [2]. The security used in S/MIME is based in 100 the definitions in [1]. The basic idea is that the submitter of an 101 LDAP operation that changes the directory information includes an 102 LDAP version 3 control that includes either a signature of the 103 operation, or a request that the LDAP server sign the operation on 104 the behalf of the LDAP client. The result of the operation (in 105 addition to the change of the directory information), is additional 106 information that is attached to directory objects, that includes the 107 audit trail of signed operations. The LDAP control is (OID = 108 1.2.840.113549.6.0.0): 109 110 111 112 113 114Greenblatt & Richard Experimental [Page 2] 115 116RFC 2649 LDAP Control and Schema August 1999 117 118 119 SignedOperation ::= CHOICE { 120 signbyServer NULL, 121 signatureIncluded OCTET STRING 122 } 123 124 If the SignatureIncluded CHOICE is used, then the OCTET string is 125 just an S/MIME message of the multipart/signed variety, that is 126 composed of a single piece, that is the signature of the directory 127 operation. Multipart/signed MIME objects are defined in [3]. If the 128 SignbyServer CHOICE us used, then the LDAP server creates the 129 signature on behalf of the client, using its own identity and not the 130 identity of the client, in order to produce the audit trail entry. 131 In either case the successful result of processing the control is the 132 creation of additional information in the directory entry that is 133 being modified or created. The signature of the LDAP operation is 134 computed on the LDAPMessage prior to the inclusion of the 135 SignedOperation control. The procedure is as follows: 136 137 - Build LDAPMessage without the SignedOperation control 138 - Compute signature on the above LDAPMessage 139 - Create new LDAPMessage that includes the old MessageID, 140 protocolOp and any control fields from the previous LDAPMessage, 141 plus the computed signature formatted as an S/MIME message. 142 143 No control is defined for the server to return in the LDAPResult as 144 defined in [4]. The LDAP server MAY attempt to parse and verify the 145 signature included in the SignedOperation control, but is not 146 required to. The server can accept the signed operation without 147 verifying the signature. Signature verification can be quite a 148 lengthy operation, requiring complex certificate chain traversals. 149 This allows a more timely creation of the audit trail by the server. 150 Any LDAP client browsing the directory that retrieves the 'Changes' 151 (defined in the following paragraphs) attributes, should verify the 152 signature of each value according to the local signature verification 153 policies. Even if the LDAP server verifies the signature contained 154 in the singed operation, the LDAP client has no way of knowing what 155 policies were followed by the server in order to verify the 156 signature. 157 158 If the LDAP server is unable to verify the signature and wishes to 159 return an error then the error code unwillingToPerform(53) should be 160 returned, and the entire LDAP operation fails. In this situation, an 161 appropriate message (e.g. "Unable to verify signature") MAY be 162 included in the errorMessage of the LDAPResult. The SignedOperation 163 Control MAY be marked CRITICAL, and if it is CRITICAL then if the 164 LDAP Server performs the LDAP operation, then must include the 165 signature in the signedAuditTrail information. 166 167 168 169 170Greenblatt & Richard Experimental [Page 3] 171 172RFC 2649 LDAP Control and Schema August 1999 173 174 175 The schema definition for the signedAuditTrail information is: 176 177 ( 1.2.840.113549.6.1.0 178 NAME 'signedAuditTrail' 179 SUP top 180 AUXILIARY 181 MUST ( 182 Changes 183 ) 184 ) 185 186 The format of the Changes attribute is: 187 188 ( 1.2.840.113549.6.2.0 189 NAME 'Changes' 190 DESC 'a set of changes applied to an entry' 191 SYNTAX 'Binary' ) 192 193 The actual format of the Changes attribute is: 194 195 Changes ::= SEQUENCE { 196 sequenceNumber [0] INTEGER (0 .. maxInt), 197 signedOperation [1] OCTET STRING } 198 199 The SignedOperation attribute is a multipart/signed S/MIME message. 200 Part 1 of the message is the directory operation, and part 2 is the 201 signature. Sequence number 0 (if present) always indicates the 202 starting point directory object as represented by the definitions in 203 "A MIME Content-Type for Directory Information", as defined in [5]. 204 Subsequent sequence numbers indicate the sequence of changes that 205 have been made to this directory object. Note that the sequence of 206 the changes can be verified due to the fact that the signed directory 207 object will have a timestamp as part of the signature object, and 208 that the sequence numbering as part of the change attribute should be 209 considered to be an unverified aid to the LDAP client. Sequence 210 numbers are meaningful only within the context of a single directory 211 entry, and LDAP servers are not expected to maintain these sequence 212 numbers across all entries in the directory. 213 214 Some LDAP servers will only allow operations that include the 215 SignedOperation control. This is indicated by the inclusion of a 216 'signedDirectoryOperationSupport' attribute in the rootDSE. This 217 attribute is defined as: 218 219 220 221 222 223 224 225 226Greenblatt & Richard Experimental [Page 4] 227 228RFC 2649 LDAP Control and Schema August 1999 229 230 231 1.2.840.113549.6.2.2 232 NAME 'signedDirectoryOperationSupport' 233 DESC 'how many of the LDAP operations must be signed' 234 SYNTAX 'Integer' SINGLE-VALUE ) 235 236 The 'signedDirectoryOperationSupport' attribute above may have one of 237 the values, '0', '1' or '2' with the following meanings: 238 239 - '0' Directory Operations may be signed 240 - '1' Directory Operations must always be signed 241 - '2' Directory Operations must never be signed 242 243 Some LDAP servers will desire that the audit trail be continuous, and 244 not contain any gaps that would result from unsigned operations. 245 Such server will include a signature on each LDAP operation that 246 changes a directory entry, even when the LDAP client does not include 247 a signed-Operation control. 248 2491.2. Handling the Delete Operation 250 251 The LDAP Delete operation represents an interesting case for Signed 252 Directory Operations. This is due to the case that subsequent to the 253 successful completion of the Delete Operation, the object that would 254 have held the latest 'Changes' attribute no longer exists. In order 255 to handle this situation, a new object class is defined to represent 256 a directory object that has been deleted. 257 258 ( 1.2.840.113549.6.1.2 259 NAME 'zombieObject' 260 SUP top 261 STRUCTURAL 262 MUST ( 263 Cn $ Changes $ OriginalObject 264 ) 265 ) 266 267 The format of the OriginalObject attribute is: 268 269 ( 1.2.840.113549.6.2.1 270 NAME OriginalObject 271 DESC 'The LDAP URL of an object that has been deleted from the 272 directory' SYNTAX 'Binary' ) 273 274 The OriginalObject attribute contains the URL of the object that was 275 deleted from the directory. It is formatted in accordance with RFC 276 2255. Directory servers that comply with this specification SHOULD 277 create a zombieObject when performing the delete Operation that 278 contains a SignedOperation LDAPControl. The Cn attribute of the 279 280 281 282Greenblatt & Richard Experimental [Page 5] 283 284RFC 2649 LDAP Control and Schema August 1999 285 286 287 zombieObject is synthesized by the LDAP server, and may or may not be 288 related to the original name of the directory entry that was deleted. 289 All changes attributes that were attached to the original entry are 290 copied over to the zombieObject. In addition the LDAP Server MUST 291 attach the signature of the Delete operation as the last successful 292 change that was made to the entry. 293 2942. Signed Results Mechanism 295 296 A control is also defined that allows the LDAP v3 client to request 297 that the server sign the results that it returns. It is intended 298 that this control is primarily used in concert with the LDAPSearch 299 operation. This control MAY be marked as CRITICAL. If it is marked 300 as CRITICAL and the LDAP Server supports this operation, then all 301 search results MUST be returned with a signature as attached in the 302 SignedResult control if it is willing to sign results for this user. 303 If the server supports this control but does not wish to sign the 304 results for this user then the error code unwillingToPerform(53) 305 should be returned, and the LDAP search will have failed. In this 306 situation, an appropriate message (e.g. "Unwilling to sign results 307 for you!") MUST be included in the errorMessage of the LDAPResult. 308 If the LDAPSigType has the value FALSE then the client is requesting 309 that the server not sign this operation. This may be done in 310 situations where servers are configured to always sign their 311 operations. 312 313 The LDAP control to include in the LDAP request is (OID = 314 1.2.840.113549.6.0.1): 315 316 DemandSignedResult ::= LDAPSigType 317 318 LDAPSigType ::= BOOLEAN 319 320 In response to a DemandSignedResult control, the LDAP v3 server will 321 return a SignedResult control in addition to the normal result as 322 defined by the operation (assuming that the server understands the 323 con- trol, and is willing to perform it). The SignedResult control 324 MUST NOT be marked CRITICAL. Some LDAP v3 servers may be configured 325 to sign all of their operations. In this situation the server always 326 returns a SignedResult control, unless instructed otherwise by the 327 DemandSigne-dResult Control. Since the SignedResult control is not 328 marked critical, the LDAP client is allowed to ignore it. The 329 signature field below includes the signature of the enitre LDAPResult 330 formatted as an S/MIME pkcs-7/signature object, as defined in [2]. 331 332 333 334 335 336 337 338Greenblatt & Richard Experimental [Page 6] 339 340RFC 2649 LDAP Control and Schema August 1999 341 342 343 The procedure for creating the signature of the signedResult control 344 is the same as the procedure for the creation of the signedOperation 345 control. The LDAP control in the LDAP response is (OID = 346 1.2.840.113549.6.0.2): 347 348 SignedResult ::= CHOICE { 349 signature OCTET STRING } 350 3513. Security Considerations and Other Notes 352 353 The base OIDs are: 354 355 rsadsiLdap ::= {1 2 840 113549 6} 356 rsadsiLdapControls ::= {1 2 840 113549 6 0} 357 rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1} 358 rsadsiLdapAttributes ::= {1 2 840 113549 6 2} 359 360 361 The complete ASN.1 module for this specification is: 362 363 SIGNEDOPERATIONS DEFINITIONS ::= 364 BEGIN 365 366 SignedOperation ::= CHOICE { 367 signbyServer NULL, 368 signatureIncluded OCTET STRING 369 } 370 371 Changes ::= SEQUENCE { 372 sequenceNumber [0] INTEGER (0 .. maxInt), 373 signedOperation [1] OCTET STRING } 374 375 DemandSignedResult ::= LDAPSigType 376 377 LDAPSigType ::= BOOLEAN 378 379 SignedResult ::= CHOICE { 380 signature OCTET STRING } 381 382 383 END 384 385 386 387 388 389 390 391 392 393 394Greenblatt & Richard Experimental [Page 7] 395 396RFC 2649 LDAP Control and Schema August 1999 397 398 399 If any of the controls in this specification are supported by an LDAP 400 v3 server then that server MUST make available its certificate (if 401 any) in the userCertificate attribute of its rootDSE object. The 402 UserCertificate attribute is defined in [6], and contains the public 403 key of the server that is used in the creation of the various 404 signatures defined in this specification. 405 406 It is not the intention of this specification to provide a mechanism 407 that guarantees the origin and integrity of LDAP v3 operations. Such 408 a service is best provided by the use of an underlying protocol such 409 as TLS [8]. TLS defines additional features such as encryption and 410 compression. This specification does not define support for 411 encrypted operations. 412 413 This memo proposes protocol elements for transmission and storage of 414 the digital signatures of LDAP operations. Though the LDAP server 415 may have verified the operation signatures prior to their storage and 416 subsequent retrieval, it is prudent for LDAP clients to verify the 417 signatures contained in the chained attribute upon their retrieval. 418 The issuing Certification Authorities of the signer's certificate 419 should also be consulted in order to determine if the signer's 420 private key has been compromised or the certificate has been 421 otherwise revoked. Security considerations are discussed throughout 422 this memo. 423 4244. References 425 426 [1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5", 427 RFC 2315, March 1998. 428 429 [2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. 430 Repka., "S/MIME Version 2 Message Specification", RFC 2311, March 431 1998. 432 433 [3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 434 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 435 RFC 1847, October 1995. 436 437 [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 438 Protocol (v3)", RFC 2251, December 1997. 439 440 [5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for 441 Directory Information", RFC 2425, September 1998. 442 443 [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with 444 LDAPv3", RFC 2256, December 1997. 445 446 447 448 449 450Greenblatt & Richard Experimental [Page 8] 451 452RFC 2649 LDAP Control and Schema August 1999 453 454 455 [7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 456 1997. 457 458 [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 459 2246, January 1999. 460 4615. Authors' Addresses 462 463 Bruce Greenblatt 464 San Jose, CA 95119 465 USA 466 467 Phone: +1-408-224-5349 468 EMail: bgreenblatt@directory-applications.com 469 470 471 Pat Richard 472 Xcert Software, Inc. 473 Suite 1001 - 701 W. Georgia 474 Vancouver, BC 475 CANADA V6G 1C9 476 477 EMail: patr@xcert.com 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506Greenblatt & Richard Experimental [Page 9] 507 508RFC 2649 LDAP Control and Schema August 1999 509 510 5116. Full Copyright Statement 512 513 Copyright (C) The Internet Society (1999). All Rights Reserved. 514 515 This document and translations of it may be copied and furnished to 516 others, and derivative works that comment on or otherwise explain it 517 or assist in its implementation may be prepared, copied, published 518 and distributed, in whole or in part, without restriction of any 519 kind, provided that the above copyright notice and this paragraph are 520 included on all such copies and derivative works. However, this 521 document itself may not be modified in any way, such as by removing 522 the copyright notice or references to the Internet Society or other 523 Internet organizations, except as needed for the purpose of 524 developing Internet standards in which case the procedures for 525 copyrights defined in the Internet Standards process must be 526 followed, or as required to translate it into languages other than 527 English. 528 529 The limited permissions granted above are perpetual and will not be 530 revoked by the Internet Society or its successors or assigns. 531 532 This document and the information contained herein is provided on an 533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 539Acknowledgement 540 541 Funding for the RFC Editor function is currently provided by the 542 Internet Society. 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562Greenblatt & Richard Experimental [Page 10] 563 564