idnits 2.17.1 draft-ietf-osids-cldap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2023-01-30) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-osids-cldap-02', but the file name used is 'draft-ietf-osids-cldap-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 260 has weird spacing: '...eturned actu...' -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 338 looks like a reference -- Missing reference section? '5' on line 345 looks like a reference -- Missing reference section? '6' on line 348 looks like a reference -- Missing reference section? '4' on line 342 looks like a reference -- Missing reference section? '1' on line 332 looks like a reference -- Missing reference section? '2' on line 335 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Alan Young 2 INTERNET-DRAFT ISODE Consortium 3 Expires 01 Jan 95 5 Connection-less Lightweight Directory Access Protocol 7 1. Status of this Memo 9 This draft document will be submitted to the RFC Editor as a standards 10 document. Distribution of this memo is unlimited. Please send comments 11 to the author, or the discussion group . 13 This document is an Internet Draft. Internet Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its Areas, and its 15 Working Groups. Note that other groups may also distribute working docu- 16 ments as Internet Drafts). 18 Internet Drafts are draft documents valid for a maximum of six months. 19 Internet Drafts may be updated, replaced, or obsoleted by other docu- 20 ments at any time. It is not appropriate to use Internet Drafts as ref- 21 erence material or to cite them other than as a "working draft" or "work 22 in progress." 24 Please check the I-D abstract listing contained in each Internet Draft 25 directory to learn the current status of this or any other Internet 26 Draft. 28 2. X.500 30 The protocol described in this document is designed to provide access to 31 the Directory while not incurring the resource requirements of the 32 Directory Access Protocol (DAP)[3]. In particular, it is aimed at 33 avoiding the elapsed time that is associated with connection-oriented 34 communication and it facilitates use of the Directory in a manner 35 analagous to the DNS [5,6]. It is specifically targeted at simple 36 lookup applications that require to read a small number of attribute 37 values from a single entry. It is intended to be a complement to DAP 38 and LDAP [4]. The protocol specification draws heavily on that of LDAP. 40 3. Background 42 The Directory can be used as a repository for many kinds of information. 43 The full power of DAP is unnecessary for applications that require sim- 44 ple read access to a few attribute values. Applications addressing is a 45 good example of this type of use where an application entity needs to 46 CLDAP June 1994 48 determine the Presentation Address (PA) of a peer entity given that 49 peer's Application Entity Title (AET). If the AET is a Directory Name 50 (DN) then the required result can be obtained from the PA attribute of 51 the Directory entry identified by the AET. This is very similar to DNS. 53 Use of DAP to achieve this functionality involves a significant number 54 of network exchanges: 56 +---+------------------------------------------------------+ 57 |# | Client (DUA) DAP Server (DSA) | 58 +---+------------------------------------------------------+ 59 | 1 | N-Connect.request -> | 60 | 2 | <- N-Connect.response | 61 | 3 | T-Connect.request -> | 62 | 4 | <- T-Connect.response | 63 | | S-Connect.request, | 64 | | P-Connect.request, | 65 | | A-Associate.request, | 66 | 5 | DAP-Bind.request -> | 67 | | S-Connect.response, | 68 | | P-Connect.response, | 69 | | A-Associate.response, | 70 | 6 | <- DAP-Bind.response | 71 | 7 | DAP-Read.request -> | 72 | 8 | <- DAP-Read.response | 73 | | S-Release.request, | 74 | | P-Release.request, | 75 | | A-Release.request, | 76 | 9 | DAP-Unbind.request -> | 77 | | S-Release.response, | 78 | | P-Release.response, | 79 | | A-Release.response, | 80 |10 | <- DAP-Unbind.response | 81 | | T-Disconnect.request, | 82 |11 | N-Disconnect.request -> | 83 | | T-Disconnect.response, | 84 |12 | <- N-Disconnect.response | 85 +---+------------------------------------------------------+ 86 This is 10 packets before the application can continue, given that it 87 can probably do so after issuing the T-Disconnect.request. (Some minor 88 variations arise depending upon the class of Network and Transport ser- 89 vice that is being used; for example use of TP4 over CLNS reduces the 90 packet count by two.) LDAP is no better in the case where the LDAP 91 server uses full DAP to communicate with the Directory: 93 CLDAP June 1994 95 +----+--------------------------------------------------------------+ 96 | # | Client LDAP LDAP server DAP DSA | 97 +----+--------------------------------------------------------------+ 98 | 1 | TCP SYN -> | 99 | 2 | <- TCP SYN ACK | 100 | 3 | BindReq -> | 101 | 4 | N-Connect.req -> | 102 | 5 | <- N-Connect.res | 103 | 6 | T-Connect.req -> | 104 | 7 | <- T-Connect.res | 105 | 8 | DAP-Bind.req -> | 106 | 9 | <- DAP-Bind.res | 107 |10 | <- BindRes | 108 |11 | SearchReq -> | 109 |12 | DAP-Search.req -> | 110 |13 | <- DAP-Search.res | 111 |14 | <- SearchRes | 112 |15 | TCP FIN -> | 113 |16 | DAP-Unbind.req -> | 114 |17 | <- DAP-Unbind.res | 115 |18 | N-Disconnect.req -> | 116 |19 | <- N-Disconnect.res | 117 +----+--------------------------------------------------------------+ 118 Here there are 14 packets before the application can continue. Even if 119 the LDAP server is on the same host as the DSA (so packet delay is neg- 120 ligible), or if the DSA supports LDAP directly, then there are still 6 121 packets. 123 +--+--------------------------------+ 124 |# | Client LDAP LDAP server | 125 +--+--------------------------------+ 126 |1 | TCP SYN -> | 127 |2 | <- TCP SYN ACK | 128 |3 | BindReq -> | 129 |4 | <- BindRes | 130 |5 | SearchReq -> | 131 |6 | <- SearchRes | 132 +--+--------------------------------+ 134 This protocol provides for simple access to the Directory where the 135 delays inherent in the above exchanges are unacceptable and where the 136 additional functionality provided by connection-mode operation is not 137 required. 139 4. Protocol Model 141 CLDAP is based directly on LDAP [4] and inherits many of the key aspects 142 of the LDAP protocol: 144 CLDAP June 1994 146 - Many protocol data elements are encoding as ordinary strings (e.g., 147 Distinguished Names). 149 - A lightweight BER encoding is used to encode all protocol elements. 151 It is different to LDAP in that: 153 - Protocol elements are carried directly over UDP or other connec- 154 tion-less transport, bypassing much of the session/presentation 155 overhead and that of connections (LDAP uses a connection-mode 156 transport service). 158 - A restricted set of operations is available. 160 The definitions of most protocol elements are inherited from LDAP. 162 The general model adopted by this protocol is one of clients performing 163 protocol operations against servers. In this model, this is accomplished 164 by a client transmitting a protocol request describing the operation to 165 be performed to a server, which is then responsible for performing the 166 necessary operations on the Directory. Upon completion of the necessary 167 operations, the server returns a response containing any results or 168 errors to the requesting client. 170 Note that, although servers are required to return responses whenever 171 such responses are defined in the protocol, there is no requirement for 172 synchronous behaviour on the part of either client or server implementa- 173 tions: requests and responses for multiple operations may be exchanged 174 by client and servers in any order, as long as servers eventually send a 175 response for every request that requires one. 177 Also, because the protocol is implemented over a connection-less trans- 178 port service clients must be prepared for either requests or responses 179 to be lost. Clients should use a retry mechanism with timeouts in order 180 to achieve the desired level of reliability. It is not required that a 181 client abandon any requests to which no response has been received and 182 for which a reply is no longer required (because the request has been 183 timed out), but they may do so. 185 Consistent with the model of servers performing protocol operations on 186 behalf of clients, it is also to be noted that protocol servers are 187 expected to handle referrals without resorting to the return of such 188 referrals to the client. This protocol makes no provisions for the 189 return of referrals to clients, as the model is one of servers ensuring 190 the performance of all necessary operations in the Directory, with only 191 final results or errors being returned by servers to clients. 193 Note that this protocol can be mapped to a strict subset of the 194 CLDAP June 1994 196 Directory abstract service, so it can be cleanly provided by the DAP. 198 5. Mapping Onto Transport Services 200 This protocol is designed to run over connection-less transports, with 201 all 8 bits in an octet being significant in the data stream. Specifica- 202 tions for two underlying services are defined here, though others are 203 also possible. 205 5.1. User Datagram Protocol (UDP) 207 The CLDAPMessage PDUs are mapped directly onto UDP datagrams. Only one 208 request may be sent in a single datagram. Only one response may be sent 209 in a single datagram. Server implementations running over the UDP 210 should provide a protocol listener on port 389. 212 5.2. Connection-less Transport Service (CLTS) 214 Each LDAPMessage PDU is mapped directly onto T-Unit-Data. 216 6. Elements of Protocol 218 CLDAP messages are defined by the following ASN.1: 220 CLDAPMessage ::= SEQUENCE { 221 messageID MessageID, 222 user LDAPDN, -- on request only -- 223 protocolOp CHOICE { 224 searchRequest SearchRequest, 225 searchResponse SEQUENCE OF 226 SearchResponse, 227 abandonRequest AbandonRequest 228 } 229 } 231 where MessageID, LDAPDN, SearchRequest, SearchResponse and AbandonRe- 232 quest are defined in the LDAP protocol. 234 The 'user' element is supplied only on requests (it should be zero 235 length and is ignored in responses). It may be used for logging purposes 236 but it is not required that a CLDAP server implementation apply any par- 237 ticular semantics to this field. 239 Editor's note: 240 There has been some discussion about the desirability of authenti- 241 cation with CLDAP requests and the addition of the fields necessary 242 to support this. This might take the form of a clear text password 243 (which would go against the current IAB drive to remove such things 244 CLDAP June 1994 246 from protocols) or some arbitrary credentials. Such a field is not 247 included. It is felt that, in general, authentication would incur 248 sufficient overhead to negate the advantages of the connectionless 249 basis of CLDAP. If an application requires authenticated access to 250 the Directory then CLDAP is not an appropriate protocol. 252 Within a searchResponse all but the last SearchResponse has choice 253 'entry' and the last SearchResponse has choice 'resultCode'. Within a 254 searchResponse, as an encoding optimisation, the value of the objectName 255 LDAP DN may use a trailing '*' character to refer to the baseObject of 256 the corresponding searchRequest. For example, if the baseObject is 257 specified as "o=UofM, c=US", then the following objectName LDAPDNs in a 258 response would have the indicated meanings 260 objectName returned actual LDAPDN denoted 261 ----------------------------------------------------- 262 "*" "o=UofM, c=US" 263 "cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US" 265 6.1. Errors 267 The following error code is added to the LDAPResult.resultCode enumera- 268 tion of [4]: 270 resultsTooLarge (70), 272 This error is returned when the LDAPMessage PDU containing the results 273 of an operation are too large to be sent in a single datagram. 275 6.2. Example 277 A simple lookup can be performed in 4 packets. This is reduced to 2 if 278 either the DSA implements the CLDAP protocol, the CLDAP server has a 279 cache of the desired results, or the CLDAP server and DSA are co-located 280 such that there is insignificant delay between them. 282 +--+-----------------------------------------------------------+ 283 |# | Client CLDAP CLDAP server DAP DSA | 284 +--+-----------------------------------------------------------+ 285 |1 | SearchReq -> | 286 |2 | DAP-Search.req -> | 287 |3 | <- DAP-Search.res | 288 |4 | <- SearchRes | 289 +--+-----------------------------------------------------------+ 290 CLDAP June 1994 292 7. Implementation Considerations 294 The following subsections provide guidance on the implementation of 295 clients and servers using the CLDAP protocol. 297 7.1. Server Implementations 299 Given that the goal of this protocol is to minimise the elapsed time 300 between making a Directory request and receiving the response, a server 301 which uses DAP to access the directory should use techniques that assist 302 in this. 304 - A server should remain bound to the Directory during reasonably 305 long idle periods or should remain bound permanently. 307 - Cacheing of results is highly desirable but this must be tempered 308 by the need to provide up-to-date results given the lack of a cache 309 invalidation protocol in DAP (either implicit via timers or 310 explicit) and the lack of a dontUseCopy service control in the pro- 311 tocol. 313 Of course these issues are irrelevant if the CLDAP protocol is directly 314 supported by a DSA. 316 7.2. Client Implementations 318 For simple lookup applications, use of a retry algorithm with multiple 319 servers similar to that commonly used in DNS stub resolver implementa- 320 tions is recommended. The location of a CLDAP server or servers may be 321 better specified using IP addresses (simple or broadcast) rather than 322 names that must first be looked up in another directory such as DNS. 324 8. Security Considerations 326 This protocol provides no facilities for authentication. It is expected 327 that servers will bind to the Directory either anonymously or using sim- 328 ple authentication without a password. 330 9. Bibliography 332 [1] The Directory: Overview of Concepts, Models and Service. CCITT 333 Recommendation X.500, 1988 335 [2] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC 336 1/SC21; International Standard 9594-2, 1988 338 [3] The Directory: Abstract Service Definition. CCITT Recommendation 339 X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988 340 CLDAP June 1994 342 [4] X.500 Lightweight Directory Access Protocol. W. Yeong, T. Howes, 343 S. Kille; RFC 1487, July 1993. 345 [5] Domain names - implementation and specification. P. Mockapetris; 346 RFC 1035, November 1987. 348 [6] Domain names - concepts and facilities. P. Mockapetris; RFC 1034, 349 November 1987. 351 10. Acknowledgements 353 Many thanks to Tim Howes and Steve Kille for their detailed comments and 354 to other members of the working group. 356 This work was initiated by the Union Bank of Switzerland. 358 11. Author's Addresses 360 Alan Young 361 ISODE Consortium 362 The Dome, The Square 363 RICHMOND 364 GB - TW9 1DT 366 Phone: +44 81 332 9091 367 Internet: 368 X.400: i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI