1 2 3 4 5 6 7Network Working Group M. Meredith 8Request for Comments: 3045 Novell Inc. 9Category: Informational January 2001 10 11 12 Storing Vendor Information in the LDAP root DSE 13 14Status of this Memo 15 16 This memo provides information for the Internet community. It does 17 not specify an Internet standard of any kind. Distribution of this 18 memo is unlimited. 19 20Copyright Notice 21 22 Copyright (C) The Internet Society (2001). All Rights Reserved. 23 24Abstract 25 26 This document specifies two Lightweight Directory Access Protocol 27 (LDAP) attributes, vendorName and vendorVersion that MAY be included 28 in the root DSA-specific Entry (DSE) to advertise vendor-specific 29 information. These two attributes supplement the attributes defined 30 in section 3.4 of RFC 2251. 31 32 The information held in these attributes MAY be used for display and 33 informational purposes and MUST NOT be used for feature advertisement 34 or discovery. 35 36Conventions used in this document 37 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2219] 41 421. Overview 43 44 LDAP clients discover server-specific data--such as available 45 controls, extensions, etc.--by reading the root DSE. See section 3.4 46 of [RFC2251] for details. 47 48 For display, information, and limited function discovery, it is 49 desirable to be able to query an LDAP server to determine the vendor 50 name of that server and also to see what version of that vendor's 51 code is currently installed. 52 53 54 55 56 57 58Meredith Informational [Page 1] 59 60RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 61 62 631.1 Function discovery 64 65 There are many ways in which a particular version of a vendor's LDAP 66 server implementation may be functionally incomplete, or may contain 67 software anomalies. It is impossible to identify every known 68 shortcoming of an LDAP server with the given set of server data 69 advertisement attributes. Furthermore, often times, the anomalies of 70 an implementation are not found until after the implementation has 71 been distributed, deployed, and is in use. 72 73 The attributes defined in this document MAY be used by client 74 implementations in order to identify a particular server 75 implementation so that it can 'work around' such anomalies. 76 77 The attributes defined in this document MUST NOT be used to gather 78 information related to supported features of an LDAP implementation. 79 All LDAP features, mechanisms, and capabilities--if advertised--MUST 80 be advertised through other mechanisms, preferably advertisement 81 mechanisms defined in concert with said features, mechanisms, and 82 capabilities. 83 842. Attribute Types 85 86 These attributes are an addition to the Server-specific Data 87 Requirements defined in section 3.4 of [RFC2251]. The associated 88 syntaxes are defined in section 4 of [RFC2252]. 89 90 Servers MAY restrict access to vendorName or vendorVersion and 91 clients MUST NOT expect these attributes to be available. 92 932.1 vendorName 94 95 This attribute contains a single string, which represents the name of 96 the LDAP server implementer. 97 98 All LDAP server implementations SHOULD maintain a vendorName, which 99 is generally the name of the company that wrote the LDAP Server code 100 like "Novell, Inc." 101 102 ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY 103 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 104 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 105 1062.2 vendorVersion 107 108 This attribute contains a string which represents the version of the 109 LDAP server implementation. 110 111 112 113 114Meredith Informational [Page 2] 115 116RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 117 118 119 All LDAP server implementations SHOULD maintain a vendorVersion. 120 Note that this value is typically a release value--comprised of a 121 string and/or a string of numbers--used by the developer of the LDAP 122 server product (as opposed to the supportedLDAPVersion, which 123 specifies the version of the LDAP protocol supported by this server). 124 This is single-valued so that it will only have one version value. 125 This string MUST be unique between two versions, but there are no 126 other syntactic restrictions on the value or the way it is formatted. 127 128 ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY 129 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 130 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 131 132 The intent behind the equality match on vendorVersion is to not allow 133 a less than or greater than type of query. Say release "LDAPv3 8.0" 134 has a problem that is fixed in the next release "LDAPv3 8.5", but in 135 the mean time there is also an update release say version "LDAPv3 136 8.01" that fixes the problem. This will hopefully stop the client 137 from saying it will not work with a version less than "LDAPv3 8.5" 138 when it would also work with "LDAPv3 8.01". With the equality match 139 the client would have to exactly match what it is looking for. 140 1413. Notes to Server Implementers 142 143 Server implementers may consider tying the vendorVersion attribute 144 value to the build mechanism so that it is automatically updated when 145 the version value changes. 146 1474. Notes to Client Developers 148 149 As mentioned in section 2.1, the use of vendorName and vendorVersion 150 MUST NOT be used to discover features. 151 152 It should be noted that an anomalies often on affect subset of 153 implementations reporting the same version information. Most 154 implementations support multiple platforms, have numerous 155 configuration options, and often support plug-ins. 156 157 Client implementations SHOULD be written in such a way as to accept 158 any value in the vendorName and vendorVersion attributes. If a 159 client implementation does not recognize the specific vendorName or 160 vendorVersion as one it recognizes, then for the purposes of 'working 161 around' anomalies, the client MUST assume that the server is complete 162 and correct. The client MUST work with implementations that do not 163 publish these attributes. 164 165 166 167 168 169 170Meredith Informational [Page 3] 171 172RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 173 174 1755. Security Considerations 176 177 The vendorName and vendorVersion attributes are provided only as 178 display or informational mechanisms, or as anomaly identifying 179 mechanisms. Client and application implementers must consider that 180 the existence of a given value in the vendorName or vendorVersion 181 attribute is no guarantee that the server was actually built by the 182 asserted vendor or that its version is the asserted version and 183 should act accordingly. 184 185 Server implementers should be aware that this information could be 186 used to exploit a security hole a server provides either by feature 187 or flaw. 188 1896. IANA Considerations 190 191 This document seeks to create two attributes, vendorName and 192 vendorVersion, which the IANA will primarily be responsible. This is 193 a one time effort; there is no need for any recurring assignment 194 after this stage. 195 1967. References 197 198 [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 201 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 202 3", BCP 9, RFC 2026, October 1996. 203 204 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 205 Access Protocol (v3)", RFC 2251, December 1997. 206 207 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 208 "Lightweight Directory Access Protocol (v3): Attribute 209 Syntax Definitions", RFC 2252, December 1997. 210 2118. Acknowledgments 212 213 The author would like to thank the generous input and review by 214 individuals at Novell including but not limited to Jim Sermersheim, 215 Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF 216 contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong, 217 Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers. 218 219 220 221 222 223 224 225 226Meredith Informational [Page 4] 227 228RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 229 230 2319. Author's Address 232 233 Mark Meredith 234 Novell Inc. 235 1800 S. Novell Place 236 Provo, UT 84606 237 238 Phone: 801-861-2645 239 EMail: mark_meredith@novell.com 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282Meredith Informational [Page 5] 283 284RFC 3045 LDAP Root DSE to Display Vendor Information January 2001 285 286 28710. Full Copyright Statement 288 289 Copyright (C) The Internet Society (2001). All Rights Reserved. 290 291 This document and translations of it may be copied and furnished to 292 others, and derivative works that comment on or otherwise explain it 293 or assist in its implementation may be prepared, copied, published 294 and distributed, in whole or in part, without restriction of any 295 kind, provided that the above copyright notice and this paragraph are 296 included on all such copies and derivative works. However, this 297 document itself may not be modified in any way, such as by removing 298 the copyright notice or references to the Internet Society or other 299 Internet organizations, except as needed for the purpose of 300 developing Internet standards in which case the procedures for 301 copyrights defined in the Internet Standards process must be 302 followed, or as required to translate it into languages other than 303 English. 304 305 The limited permissions granted above are perpetual and will not be 306 revoked by the Internet Society or its successors or assigns. 307 308 This document and the information contained herein is provided on an 309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 315Acknowledgement 316 317 Funding for the RFC Editor function is currently provided by the 318 Internet Society. 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338Meredith Informational [Page 6] 339 340