File: rfc1798.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (507 lines) | stat: -rw-r--r-- 18,552 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
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
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507






Network Working Group                                           A. Young
Request for Comments: 1798                              ISODE Consortium
Category: Standards Track                                      June 1995


       Connection-less Lightweight X.500 Directory Access Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

X.500

   The protocol described in this document is designed to provide access
   to the Directory while not incurring the resource requirements of the
   Directory Access Protocol (DAP) [3].  In particular, it is aimed at
   avoiding the elapsed time that is associated with connection-oriented
   communication and it facilitates use of the Directory in a manner
   analagous to the DNS [5,6].  It is specifically targeted at simple
   lookup applications that require to read a small number of attribute
   values from a single entry.  It is intended to be a complement to DAP
   and LDAP [4].  The protocol specification draws heavily on that of
   LDAP.

1.  Background

   The Directory can be used as a repository for many kinds of
   information.  The full power of DAP is unnecessary for applications
   that require simple read access to a few attribute values.
   Applications addressing is a good example of this type of use where
   an application entity needs to determine the Presentation Address
   (PA) of a peer entity given that peer's Application Entity Title
   (AET). If the AET is a Directory Name (DN) then the required result
   can be obtained from the PA attribute of the Directory entry
   identified by the AET.  This is very similar to DNS.












Young                       Standards Track                     [Page 1]

RFC 1798                         CLDAP                         June 1995


   Use of DAP to achieve this functionality involves a significant
   number of network exchanges:

      ___________________________________________________________
     |_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
     |  1|  N-Connect.request       ->                          |
     |  2|                          <-    N-Connect.response    |
     |  3|  T-Connect.request       ->                          |
     |  4|                          <-    T-Connect.response    |
     |   |  S-Connect.request,                                  |
     |   |  P-Connect.request,                                  |
     |   |  A-Associate.request,                                |
     |  5|  DAP-Bind.request        ->                          |
     |   |                                S-Connect.response,   |
     |   |                                P-Connect.response,   |
     |   |                                A-Associate.response, |
     |  6|                          <-    DAP-Bind.response     |
     |  7|  DAP-Read.request        ->                          |
     |  8|                          <-    DAP-Read.response     |
     |   |  S-Release.request,                                  |
     |   |  P-Release.request,                                  |
     |   |  A-Release.request,                                  |
     |  9|  DAP-Unbind.request      ->                          |
     |   |                                S-Release.response,   |
     |   |                                P-Release.response,   |
     |   |                                A-Release.response,   |
     | 10|                          <-    DAP-Unbind.response   |
     |   |  T-Disconnect.request,                               |
     | 11|  N-Disconnect.request    ->                          |
     |   |                                T-Disconnect.response,|
     | 12|                          <-    N-Disconnect.response |
     |___|______________________________________________________|



















Young                       Standards Track                     [Page 2]

RFC 1798                         CLDAP                         June 1995


   This is 10 packets before the application can continue, given that it
   can probably do so after issuing the T-Disconnect.request.  (Some
   minor variations arise depending upon the class of Network and
   Transport service that is being used; for example use of TP4 over
   CLNS reduces the packet count by two.) LDAP is no better in the case
   where the LDAP server uses full DAP to communicate with the
   Directory:

  ____________________________________________________________________
 |__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______|
 |  1 |  TCP SYN      ->                                             |
 |  2 |               <-    TCP SYN ACK                              |
 |  3 |  BindReq      ->                                             |
 |  4 |                     N-Connect.req      ->                    |
 |  5 |                                        <-    N-Connect.res   |
 |  6 |                     T-Connect.req      ->                    |
 |  7 |                                        <-    T-Connect.res   |
 |  8 |                     DAP-Bind.req       ->                    |
 |  9 |                                        <-    DAP-Bind.res    |
 | 10 |               <-    BindRes                                  |
 | 11 |  SearchReq    ->                                             |
 | 12 |                     DAP-Search.req     ->                    |
 | 13 |                                        <-    DAP-Search.res  |
 | 14 |               <-    SearchRes                                |
 | 15 |  TCP FIN      ->                                             |
 | 16 |                     DAP-Unbind.req     ->                    |
 | 17 |                                        <-    DAP-Unbind.res  |
 | 18 |                     N-Disconnect.req   ->                    |
 | 19 |                                        <-    N-Disconnect.res|
 |____|______________________________________________________________|





















Young                       Standards Track                     [Page 3]

RFC 1798                         CLDAP                         June 1995


   Here there are 14 packets before the application can continue.  Even
   if the LDAP server is on the same host as the DSA (so packet delay is
   negligible), or if the DSA supports LDAP directly, then there are
   still 6 packets.

                  ____________________________________
                 | #|   Client     LDAP   LDAP server|
                 |__|________________________________|
                 | 1|  TCP SYN      ->               |
                 | 2|               <-    TCP SYN ACK|
                 | 3|  BindReq      ->               |
                 | 4|               <-    BindRes    |
                 | 5|  SearchReq    ->               |
                 |_6|_______________<-____SearchRes__|


   This protocol provides for simple access to the Directory where the
   delays inherent in the above exchanges are unacceptable and where the
   additional functionality provided by connection-mode operation is not
   required.

2.  Protocol Model

   CLDAP is based directly on LDAP [4] and inherits many of the key
   aspects of the LDAP protocol:

   - -  Many protocol data elements are encoding as ordinary strings
        (e.g., Distinguished Names).

   - -  A lightweight BER encoding is used to encode all protocol
        elements.

   It is different to LDAP in that:

   - -  Protocol elements are carried directly over UDP or other
        connection-less transport, bypassing much of the
        session/presentation overhead and that of connections (LDAP uses
        a connection-mode transport service).

   - -  A restricted set of operations is available.

   The definitions of most protocol elements are inherited from LDAP.

   The general model adopted by this protocol is one of clients
   performing protocol operations against servers. In this model, this
   is accomplished by a client transmitting a protocol request
   describing the operation to be performed to a server, which is then
   responsible for performing the necessary operations on the Directory.



Young                       Standards Track                     [Page 4]

RFC 1798                         CLDAP                         June 1995


   Upon completion of the necessary operations, the server returns a
   response containing any results or errors to the requesting client.

   Note that, although servers are required to return responses whenever
   such responses are defined in the protocol, there is no requirement
   for synchronous behaviour on the part of either client or server
   implementations: requests and responses for multiple operations may
   be exchanged by client and servers in any order, as long as servers
   eventually send a response for every request that requires one.

   Also, because the protocol is implemented over a connection-less
   transport service clients must be prepared for either requests or
   responses to be lost.  Clients should use a retry mechanism with
   timeouts in order to achieve the desired level of reliability.  For
   example, a client might send off a request and wait for two seconds.
   If no reply is forthcoming, the request is sent again and the client
   waits four seconds.  If there is still no reply, the client sends it
   again and waits eight seconds, and so on, until some maximun time.
   Such algorithms are widely used in other datagram-based protocol
   implementations, such as the DNS.  It is not appropriate to mandate a
   specific algorithm as this will depend upon the requirments and
   operational environment of individual CLDAP client implementations.

   It is not required that a client abandon any requests to which no
   response has been received and for which a reply is no longer
   required (because the request has been timed out), but they may do
   so.

   Consistent with the model of servers performing protocol operations
   on behalf of clients, it is also to be noted that protocol servers
   are expected to handle referrals without resorting to the return of
   such referrals to the client. This protocol makes no provisions for
   the return of referrals to clients, as the model is one of servers
   ensuring the performance of all necessary operations in the
   Directory, with only final results or errors being returned by
   servers to clients.

   Note that this protocol can be mapped to a strict subset of the
   Directory abstract service, so it can be cleanly provided by the DAP.

3.  Mapping Onto Transport Services

   This protocol is designed to run over connection-less transports,
   with all 8 bits in an octet being significant in the data stream.
   Specifications for two underlying services are defined here, though
   others are also possible.





Young                       Standards Track                     [Page 5]

RFC 1798                         CLDAP                         June 1995


3.1.  User Datagram Protocol (UDP)

   The CLDAPMessage PDUs are mapped directly onto UDP datagrams.  Only
   one request may be sent in a single datagram. Only one response may
   be sent in a single datagram.  Server implementations running over
   the UDP should provide a protocol listener on port 389.

3.2.  Connection-less Transport Service (CLTS)

   Each LDAPMessage PDU is mapped directly onto T-Unit-Data.

4.  Elements of Protocol

   CLDAP messages are defined by the following ASN.1:

    CLDAPMessage ::= SEQUENCE {
        messageID       MessageID,
        user            LDAPDN,         -- on request only --
        protocolOp      CHOICE {
                        searchRequest   SearchRequest,
                        searchResponse  SEQUENCE OF
                                            SearchResponse,
                        abandonRequest  AbandonRequest
        }
    }

   where MessageID, LDAPDN, SearchRequest, SearchResponse and
   AbandonRequest are defined in the LDAP protocol.

   The 'user' element is supplied only on requests (it should be zero
   length and is ignored in responses). It may be used for logging
   purposes but it is not required that a CLDAP server implementation
   apply any particular semantics to this field.

   Editorial note:
       There has been some discussion about the desirability of
       authentication with CLDAP requests and the addition of the fields
       necessary to support this. This might take the form of a clear
       text password (which would go against the current IAB drive to
       remove such things from protocols) or some arbitrary credentials.
       Such a field is not included.  It is felt that, in general,
       authentication would incur sufficient overhead to negate the
       advantages of the connectionless basis of CLDAP. If an
       application requires authenticated access to the Directory then
       CLDAP is not an appropriate protocol.






Young                       Standards Track                     [Page 6]

RFC 1798                         CLDAP                         June 1995


   Within a searchResponse all but the last SearchResponse has choice
   'entry' and the last SearchResponse has choice 'resultCode'.  Within
   a searchResponse, as an encoding optimisation, the value of the
   objectName LDAP DN may use a trailing '*' character to refer to the
   baseObject of the corresponding searchRequest.  For example, if the
   baseObject is specified as "o=UofM, c=US", then the following
   objectName LDAPDNs in a response would have the indicated meanings

          objectName returned   actual LDAPDN denoted
          ____________________________________________________
          "*"                   "o=UofM, c=US"
          "cn=Babs Jensen, *"   "cn=Babs Jensen, o=UofM, c=US"

4.1.  Errors

The following error code is added to the LDAPResult.resultCode
enumeration of [4]:

                             resultsTooLarge              (70),

   This error is returned when the LDAPMessage PDU containing the
   results of an operation are too large to be sent in a single
   datagram.

4.2.  Example

   A simple lookup can be performed in 4 packets. This is reduced to 2
   if either the DSA implements the CLDAP protocol, the CLDAP server has
   a cache of the desired results, or the CLDAP server and DSA are co-
   located such that there is insignificant delay between them.

    _______________________________________________________________
   |_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
   | 1|  SearchReq    ->                                          |
   | 2|                      DAP-Search.req   ->                  |
   | 3|                                       <-    DAP-Search.res|
   | 4|               <-     SearchRes                            |
   |__|___________________________________________________________|

5.  Implementation Considerations

   The following subsections provide guidance on the implementation of
   clients and servers using the CLDAP protocol.








Young                       Standards Track                     [Page 7]

RFC 1798                         CLDAP                         June 1995


5.1.  Server Implementations

   Given that the goal of this protocol is to minimise the elapsed time
   between making a Directory request and receiving the response, a
   server which uses DAP to access the directory should use techniques
   that assist in this.

   - -  A server should remain bound to the Directory during reasonably
        long idle periods or should remain bound permanently.

   - -  Cacheing of results is highly desirable but this must be
        tempered by the need to provide up-to-date results given the
        lack of a cache invalidation protocol in DAP (either implicit
        via timers or explicit) and the lack of a dontUseCopy service
        control in the protocol.

   Of course these issues are irrelevant if the CLDAP protocol is
   directly supported by a DSA.

5.2.  Client Implementations

   For simple lookup applications, use of a retry algorithm with
   multiple servers similar to that commonly used in DNS stub resolver
   implementations is recommended.  The location of a CLDAP server or
   servers may be better specified using IP addresses (simple or
   broadcast) rather than names that must first be looked up in another
   directory such as DNS.

6.  Security Considerations

   This protocol provides no facilities for authentication. It is
   expected that servers will bind to the Directory either anonymously
   or using simple authentication without a password.

7.  Bibliography

   [1] The Directory: Overview of Concepts, Models and Service.  CCITT
       Recommendation X.500, 1988.

   [2] The Directory: Models.  CCITT Recommendation X.501 ISO/IEC JTC
       1/SC21; International Standard 9594-2, 1988.

   [3] The Directory: Abstract Service Definition.  CCITT Recommendation
       X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.

   [4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
       Access Protocol", RFC 1487, Performance Systems International,
       University of Michigan, ISODE Consortium, July 1993.



Young                       Standards Track                     [Page 8]

RFC 1798                         CLDAP                         June 1995


   [5] Mockapetris, P., "Domain Names - Implementation and
       Specification", STD 13, RFC 1035, USC/Information Sciences
       Institute, November 1987.

   [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
       13, RFC 1034, USC/Information Sciences Institute, November 1987.

8.  Acknowledgements

   Many thanks to Tim Howes and Steve Kille for their detailed comments
   and to other members of the working group.

   This work was initiated by the Union Bank of Switzerland.

9.  Author's Address

   Alan Young
   ISODE Consortium
   The Dome, The Square
   RICHMOND
   GB - TW9 1DT

   Phone: +44 81 332 9091
   EMail: A.Young@isode.com
   X.400:    i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI


























Young                       Standards Track                     [Page 9]