RFC 2649

An LDAP Control and Schema for Holding Operation Signatures

📅 published August 1999, from ietf

RFC 2649: An LDAP Control and Schema for Holding Operation Signatures 🎀

okay bestie, let's get into this one. it's an Experimental doc from August 1999, written by B. Greenblatt and P. Richard 💅 it's not a standard, it's a "try it out and tell us what you think" kind of vibe. it doesn't list anything it obsoletes or updates, so it's a clean slate 🦋

Status of this Memo ✨

this memo defines an Experimental Protocol for the Internet community 🧪 it does not specify an Internet standard of any kind. the authors want feedback and suggestions for improvement, and the memo can be distributed freely, no limits 💜

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌈

okay so the big problem here is that clients often need to check that the info a directory gives them is actually from who it says it's from, and hasn't been messed with 😭 this doc describes an LDAP message control that lets you get back digitally signed info. it's an LDAP v3 way to sign directory operations, which creates a secure journal of every change made to each entry 📜 both client-side and server-side signatures are supported ✨ it also defines an object class called "journal entries" for looking through that journal later. the doc specifies the LDAP v3 controls that make all this happen, plus an LDAP v3 schema so you can browse the journal info 🫶

Table of Contents 🧚

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
1.1 Audit Trail Mechanism  . . . . . . . . . . . . . . . . . . .   2
1.2. Handling the Delete Operation . . . . . . . . . . . . . . .   5
2. Signed Results Mechanism  . . . . . . . . . . . . . . . . . .   6
3. Security Considerations and Other Notes   . . . . . . . . . .   7
4. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
5. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .   9
6. Full Copyright Statement  . . . . . . . . . . . . . . . . . .  10

1. Introduction 💖

okay so the intro basically repeats the abstract's vibe, but with more detail 💅 clients need to check the source and integrity of directory info, and this doc describes an LDAP message control that lets you get digitally signed stuff back 🔥 the main idea is that the LDAP v3 client is the origin of the info that gets stored in LDAP v3 directories. the client makes the info, so the client is the one who should prove it's legit 👑

the source and integrity of a single LDAP connection can be guaranteed by using an underlying session layer that provides those services, like TLS 🔐 but ngl, a secure connection doesn't guarantee the data itself is good 💀 the server can only give back what it has stored. in distributed and replicated setups, finding an entry on a server isn't totally reassuring if that entry got replicated from an untrusted domain 🙈

so here's the fix. using public key tech, the client creates digitally signed transactions every time an entry is created or modified 🦋 that gives you a complete history of the entry, a whole journal ✨ each journal entry has been signed with the private key of whoever created or modified it, so you can check the source and integrity of the directory entry by verifying the signature on every journal entry 🧚 and not all of those entries are necessarily signed by the same person, which is kinda the whole point 🌈

1.1. Audit Trail Mechanism 📜

signed directory operations are a pretty straightforward use of S/MIME, and they also use the extensible framework that LDAP version 3 gives you 🎀 LDAP version 3 is defined in [4], and S/MIME is defined in [2]. the security part of S/MIME is based on the definitions in [1] 🔐

the basic idea is this: whoever submits an LDAP operation that changes the directory info includes an LDAP version 3 control. that control either has a signature of the operation, or asks the LDAP server to sign the operation on behalf of the LDAP client 🫶 the result of the operation (on top of the actual change to the directory info) is extra info attached to directory objects, which holds the audit trail of signed operations 📜 the LDAP control has OID 1.2.840.113549.6.0.0:

   SignedOperation ::= CHOICE {
        signbyServer   NULL,
        signatureIncluded   OCTET STRING
    }

so if the SignatureIncluded CHOICE is used, the OCTET string is just an S/MIME message of the multipart/signed kind 💅 it's made of a single piece, which is the signature of the directory operation. multipart/signed MIME objects are defined in [3] ✨ if the SignbyServer CHOICE is used instead, the LDAP server makes the signature for the client, using its own identity and not the client's, so it can make the audit trail entry 🧚 either way, the successful result of processing the control is that extra info gets created in the directory entry being modified or created 💖

the signature of the LDAP operation is computed on the LDAPMessage before the SignedOperation control is added. the steps go like this:

  • Build LDAPMessage without the SignedOperation control
  • Compute signature on the above LDAPMessage
  • Create new LDAPMessage that includes the old MessageID, protocolOp and any control fields from the previous LDAPMessage, plus the computed signature formatted as an S/MIME message.

no control is defined for the server to return in the LDAPResult as defined in [4] 🙈 the LDAP server MAY attempt to parse and verify the signature included in the SignedOperation control, but it is not required to. it can accept the signed operation without verifying the signature at all 🌸 that's because signature verification can be a super long process with complex certificate chain traversals, and skipping it lets the server create the audit trail faster ⏩

any LDAP client browsing the directory that retrieves the 'Changes' attributes (explained in the next paragraphs) should verify the signature of each value using its own local signature verification policies 🔍 and even if the server does verify the signature in the signed operation, the client has no way of knowing what policies the server followed to do it 🤷‍♀️ trust but verify, babe 💜

if the LDAP server can't verify the signature and wants to return an error, the error code unwillingToPerform(53) should be returned, and the whole LDAP operation fails 😭 in that case, a message like "Unable to verify signature" MAY be included in the errorMessage of the LDAPResult 🫠 the SignedOperation Control MAY be marked CRITICAL. if it is CRITICAL, then when the LDAP Server performs the LDAP operation, it must include the signature in the signedAuditTrail information 🔥

the schema definition for the signedAuditTrail information is:

   ( 1.2.840.113549.6.1.0
   NAME 'signedAuditTrail'
   SUP top
   AUXILIARY
   MUST (
   Changes
   )
      )

the format of the Changes attribute is:

   ( 1.2.840.113549.6.2.0
   NAME 'Changes'
   DESC 'a set of changes applied to an entry'
   SYNTAX 'Binary' )

and the actual format of the Changes attribute is:

   Changes ::= SEQUENCE {
        sequenceNumber [0] INTEGER (0 .. maxInt),
        signedOperation [1] OCTET STRING }

the SignedOperation attribute is a multipart/signed S/MIME message 💅 part 1 is the directory operation, and part 2 is the signature. sequence number 0 (if it's there) always points to the starting directory object, as represented by the definitions in "A MIME Content-Type for Directory Information", which is cited as [5] ✨ after that, the sequence numbers show the order of the changes made to that directory object 🧚 the order can actually be verified, because the signed directory object has a timestamp as part of its signature 🕰️ so the sequence numbering in the change attribute should only be treated as an unverified helper for the LDAP client 🫶 also, sequence numbers only mean something inside one directory entry, and LDAP servers aren't expected to keep them unique across every entry in the directory 🌈

some LDAP servers will only allow operations that include the SignedOperation control 🔒 you can tell because the rootDSE includes a 'signedDirectoryOperationSupport' attribute, which is defined like this:

   1.2.840.113549.6.2.2
   NAME 'signedDirectoryOperationSupport'
   DESC 'how many of the LDAP operations must be signed'
   SYNTAX 'Integer' SINGLE-VALUE )

the 'signedDirectoryOperationSupport' attribute above may have one of the values '0', '1' or '2', and they mean:

  • '0' Directory Operations may be signed
  • '1' Directory Operations must always be signed
  • '2' Directory Operations must never be signed

some LDAP servers want the audit trail to be continuous, with no gaps from unsigned operations 🧩 those servers will include a signature on every LDAP operation that changes a directory entry, even when the LDAP client doesn't include a SignedOperation control 💜

2. Signed Results Mechanism ✨

okay bestie, so there's a control that lets the LDAP v3 client ask the server to sign the results it sends back 🖋️💖 It's meant to be used mostly with the LDAPSearch operation, obvi 💅 This control MAY be marked as CRITICAL. If it is marked as CRITICAL and the LDAP Server supports this operation, then all search results MUST be returned with a signature attached in the SignedResult control, as long as the server is willing to sign results for this user 🔥

If the server supports the control but doesn't wanna sign the results for this user, the error code unwillingToPerform(53) should be returned, and the LDAP search will have failed 💀 In that situation, an appropriate message (e.g. "Unwilling to sign results for you!") MUST be included in the errorMessage of the LDAPResult 😭 If the LDAPSigType has the value FALSE, then the client is asking the server to not sign this operation 🙈 This may be done when servers are configured to always sign their operations, so it's giving "I'm opting out, thanks" 🌸

The LDAP control that goes in the LDAP request is (OID = 1.2.840.113549.6.0.1):

DemandSignedResult ::=  LDAPSigType

LDAPSigType ::= BOOLEAN

When the LDAP v3 server gets a DemandSignedResult control, it will return a SignedResult control along with the normal result that the operation defines 🎀 (assuming the server understands the control and is willing to perform it). The SignedResult control MUST NOT be marked CRITICAL 🫶 Some LDAP v3 servers may be configured to sign all of their operations. In that case the server always returns a SignedResult control, unless it's told otherwise by the DemandSignedResult control 👑 Since the SignedResult control isn't marked critical, the LDAP client is allowed to ignore it, which is very chill 🧚 The signature field includes the signature of the entire LDAPResult, formatted as an S/MIME pkcs-7/signature object, as defined in [2] 💜

The procedure for creating the signature of the SignedResult control is the same as the procedure for creating the signedOperation control 🦋 The LDAP control in the LDAP response is (OID = 1.2.840.113549.6.0.2):

SignedResult ::= CHOICE {
     signature     OCTET STRING }

3. Security Considerations and Other Notes

The base OIDs are, in case you need them 🍓:

rsadsiLdap ::= {1 2 840 113549 6}
rsadsiLdapControls ::=  {1 2 840 113549 6 0}
rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1}
rsadsiLdapAttributes ::= {1 2 840 113549 6 2}

The complete ASN.1 module for this specification is 🧩:

SIGNEDOPERATIONS DEFINITIONS ::=
BEGIN

SignedOperation ::= CHOICE {
     signbyServer   NULL,
     signatureIncluded   OCTET STRING
 }

Changes ::= SEQUENCE {
     sequenceNumber [0] INTEGER (0 .. maxInt),
     signedOperation [1] OCTET STRING }

DemandSignedResult ::=  LDAPSigType

LDAPSigType ::= BOOLEAN

SignedResult ::= CHOICE {
     signature     OCTET STRING }


END

If any of the controls in this specification are supported by an LDAP v3 server, then that server MUST make available its certificate (if any) in the userCertificate attribute of its rootDSE object 🔐 The UserCertificate attribute is defined in [6], and it contains the public key of the server that's used to create the various signatures defined in this specification 🗝️

It is not the intention of this specification to provide a mechanism that guarantees the origin and integrity of LDAP v3 operations 🙅‍♀️ Honestly, that job is better handled by an underlying protocol like TLS [8], which also brings extra features like encryption and compression ✨ This specification does not define support for encrypted operations, so don't expect that here 💅

This memo proposes protocol elements for transmitting and storing the digital signatures of LDAP operations 📦 Even though the LDAP server may have verified the operation signatures before storing and later retrieving them, it's prudent for LDAP clients to verify the signatures contained in the chained attribute when they retrieve them 🧐 The issuing Certification Authorities of the signer's certificate should also be consulted, so you can check whether the signer's private key has been compromised or the certificate has been otherwise revoked 🚨 Security considerations are discussed throughout this memo, so pay attention, babe 😤

4. References

  • [1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5", RFC 2315, March 1998. 📚
  • [2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka., "S/MIME Version 2 Message Specification", RFC 2311, March 1998. 📚
  • [3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. 📚
  • [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. 📚
  • [5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for Directory Information", RFC 2425, September 1998. 📚
  • [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. 📚
  • [7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. 📚
  • [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 📚

5. Authors' Addresses

Bruce Greenblatt
San Jose, CA 95119
USA

Phone: +1-408-224-5349
EMail: bgreenblatt@directory-applications.com


Pat Richard
Xcert Software, Inc.
Suite 1001 - 701 W. Georgia
Vancouver, BC
CANADA V6G 1C9

EMail: patr@xcert.com

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 💖

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫶

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🎀

📦 where this page comes from