Summary

  • RFC 3045 defined optional vendorName and vendorVersion attributes in an LDAP server's root DSE so clients could display implementation identity or recognize a possible software anomaly.
  • It drew a bright protocol boundary: those strings must not be used to discover features. A vendor name and release label were neither authenticated provenance nor proof that a capability worked on this server or session.

An LDAP client already had a reason to inspect the root DSA-specific Entry, or root DSE. The entry could describe the particular server at the other end of a connection. RFC 3045 added two possible clues to that response: vendorName and vendorVersion. Published in January 2001, the Informational RFC allowed a server to expose who implemented its code and the product's release label. The attributes were single-valued operational data, not ordinary fields a directory user could edit.

The proposal's narrowness was deliberate. A client might display the vendor and version to an operator, or recognize a release associated with a known anomaly and try a workaround. But RFC 3045 prohibited using the same values to infer supported features. The name of a maker does not say which controls, extensions or mechanisms a particular server accepts. A release label does not say whether a feature is enabled in this configuration, available to this authenticated session, or working correctly. Capability advertisement belonged in mechanisms defined for the relevant capability itself.

That boundary protected both sides of the exchange from a tempting shortcut. A client that treated “vendor X, version Y” as a feature negotiation could skip the protocol evidence designed for that feature. It might enable an operation the server did not support—or suppress one it did. RFC 3045 instead let vendor identity serve as context around an observation, not as a substitute for the observation.

Even the version string was designed against false precision. The RFC required a vendorVersion value to be unique between versions but imposed no syntax or ordering rules. Its matching rule was equality, not “less than” or “greater than.” A client looking for a workaround could match the exact string associated with the anomaly rather than assume that 8.01 was older or newer than 8.5. Product release labels are names, not necessarily numbers on a comparable scale.

And an exact match still did not describe a whole implementation. RFC 3045 noted that an anomaly might affect only some instances reporting the same version: platforms, configuration choices and plug-ins can differ. It also warned that a returned name or version does not guarantee the server was built by that vendor or is actually running that release. In other words, even a truthful-looking label is evidence about what the server reported, not an attestation of its binary or a complete account of its behavior.

The attributes were optional too. A server could restrict their visibility, and clients were required not to expect them. An absent vendor string did not mean that the server was broken or that a client could refuse to interoperate. This matters because information useful for troubleshooting can also reveal software details to an adversary. RFC 3045 explicitly identified the risk that vendor and version data might help someone locate a weakness.

Later LDAP architecture kept the distinction between identity and capability visible. RFC 4512 describes the root DSE as a server-specific operational entry and lists separate attributes such as supportedControl, supportedExtension and supportedFeatures. Their values can depend on session conditions. The current IANA LDAP Parameters registry still lists the two OIDs assigned for vendorName and vendorVersion; that confirms the identifiers, not any server's claim or capability. RFC 3045's lesson is the division of labor: let labels help operators recognize context, but let feature-specific evidence answer what a connection can actually use.

Sources