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