home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1798 < prev    next >
Text File  |  1995-06-20  |  19KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           A. Young
  8. Request for Comments: 1798                              ISODE Consortium
  9. Category: Standards Track                                      June 1995
  10.  
  11.  
  12.        Connection-less Lightweight X.500 Directory Access Protocol
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. X.500
  23.  
  24.    The protocol described in this document is designed to provide access
  25.    to the Directory while not incurring the resource requirements of the
  26.    Directory Access Protocol (DAP) [3].  In particular, it is aimed at
  27.    avoiding the elapsed time that is associated with connection-oriented
  28.    communication and it facilitates use of the Directory in a manner
  29.    analagous to the DNS [5,6].  It is specifically targeted at simple
  30.    lookup applications that require to read a small number of attribute
  31.    values from a single entry.  It is intended to be a complement to DAP
  32.    and LDAP [4].  The protocol specification draws heavily on that of
  33.    LDAP.
  34.  
  35. 1.  Background
  36.  
  37.    The Directory can be used as a repository for many kinds of
  38.    information.  The full power of DAP is unnecessary for applications
  39.    that require simple read access to a few attribute values.
  40.    Applications addressing is a good example of this type of use where
  41.    an application entity needs to determine the Presentation Address
  42.    (PA) of a peer entity given that peer's Application Entity Title
  43.    (AET). If the AET is a Directory Name (DN) then the required result
  44.    can be obtained from the PA attribute of the Directory entry
  45.    identified by the AET.  This is very similar to DNS.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Young                       Standards Track                     [Page 1]
  59.  
  60. RFC 1798                         CLDAP                         June 1995
  61.  
  62.  
  63.    Use of DAP to achieve this functionality involves a significant
  64.    number of network exchanges:
  65.  
  66.       ___________________________________________________________
  67.      |_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
  68.      |  1|  N-Connect.request       ->                          |
  69.      |  2|                          <-    N-Connect.response    |
  70.      |  3|  T-Connect.request       ->                          |
  71.      |  4|                          <-    T-Connect.response    |
  72.      |   |  S-Connect.request,                                  |
  73.      |   |  P-Connect.request,                                  |
  74.      |   |  A-Associate.request,                                |
  75.      |  5|  DAP-Bind.request        ->                          |
  76.      |   |                                S-Connect.response,   |
  77.      |   |                                P-Connect.response,   |
  78.      |   |                                A-Associate.response, |
  79.      |  6|                          <-    DAP-Bind.response     |
  80.      |  7|  DAP-Read.request        ->                          |
  81.      |  8|                          <-    DAP-Read.response     |
  82.      |   |  S-Release.request,                                  |
  83.      |   |  P-Release.request,                                  |
  84.      |   |  A-Release.request,                                  |
  85.      |  9|  DAP-Unbind.request      ->                          |
  86.      |   |                                S-Release.response,   |
  87.      |   |                                P-Release.response,   |
  88.      |   |                                A-Release.response,   |
  89.      | 10|                          <-    DAP-Unbind.response   |
  90.      |   |  T-Disconnect.request,                               |
  91.      | 11|  N-Disconnect.request    ->                          |
  92.      |   |                                T-Disconnect.response,|
  93.      | 12|                          <-    N-Disconnect.response |
  94.      |___|______________________________________________________|
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Young                       Standards Track                     [Page 2]
  115.  
  116. RFC 1798                         CLDAP                         June 1995
  117.  
  118.  
  119.    This is 10 packets before the application can continue, given that it
  120.    can probably do so after issuing the T-Disconnect.request.  (Some
  121.    minor variations arise depending upon the class of Network and
  122.    Transport service that is being used; for example use of TP4 over
  123.    CLNS reduces the packet count by two.) LDAP is no better in the case
  124.    where the LDAP server uses full DAP to communicate with the
  125.    Directory:
  126.  
  127.   ____________________________________________________________________
  128.  |__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______|
  129.  |  1 |  TCP SYN      ->                                             |
  130.  |  2 |               <-    TCP SYN ACK                              |
  131.  |  3 |  BindReq      ->                                             |
  132.  |  4 |                     N-Connect.req      ->                    |
  133.  |  5 |                                        <-    N-Connect.res   |
  134.  |  6 |                     T-Connect.req      ->                    |
  135.  |  7 |                                        <-    T-Connect.res   |
  136.  |  8 |                     DAP-Bind.req       ->                    |
  137.  |  9 |                                        <-    DAP-Bind.res    |
  138.  | 10 |               <-    BindRes                                  |
  139.  | 11 |  SearchReq    ->                                             |
  140.  | 12 |                     DAP-Search.req     ->                    |
  141.  | 13 |                                        <-    DAP-Search.res  |
  142.  | 14 |               <-    SearchRes                                |
  143.  | 15 |  TCP FIN      ->                                             |
  144.  | 16 |                     DAP-Unbind.req     ->                    |
  145.  | 17 |                                        <-    DAP-Unbind.res  |
  146.  | 18 |                     N-Disconnect.req   ->                    |
  147.  | 19 |                                        <-    N-Disconnect.res|
  148.  |____|______________________________________________________________|
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Young                       Standards Track                     [Page 3]
  171.  
  172. RFC 1798                         CLDAP                         June 1995
  173.  
  174.  
  175.    Here there are 14 packets before the application can continue.  Even
  176.    if the LDAP server is on the same host as the DSA (so packet delay is
  177.    negligible), or if the DSA supports LDAP directly, then there are
  178.    still 6 packets.
  179.  
  180.                   ____________________________________
  181.                  | #|   Client     LDAP   LDAP server|
  182.                  |__|________________________________|
  183.                  | 1|  TCP SYN      ->               |
  184.                  | 2|               <-    TCP SYN ACK|
  185.                  | 3|  BindReq      ->               |
  186.                  | 4|               <-    BindRes    |
  187.                  | 5|  SearchReq    ->               |
  188.                  |_6|_______________<-____SearchRes__|
  189.  
  190.  
  191.    This protocol provides for simple access to the Directory where the
  192.    delays inherent in the above exchanges are unacceptable and where the
  193.    additional functionality provided by connection-mode operation is not
  194.    required.
  195.  
  196. 2.  Protocol Model
  197.  
  198.    CLDAP is based directly on LDAP [4] and inherits many of the key
  199.    aspects of the LDAP protocol:
  200.  
  201.    - -  Many protocol data elements are encoding as ordinary strings
  202.         (e.g., Distinguished Names).
  203.  
  204.    - -  A lightweight BER encoding is used to encode all protocol
  205.         elements.
  206.  
  207.    It is different to LDAP in that:
  208.  
  209.    - -  Protocol elements are carried directly over UDP or other
  210.         connection-less transport, bypassing much of the
  211.         session/presentation overhead and that of connections (LDAP uses
  212.         a connection-mode transport service).
  213.  
  214.    - -  A restricted set of operations is available.
  215.  
  216.    The definitions of most protocol elements are inherited from LDAP.
  217.  
  218.    The general model adopted by this protocol is one of clients
  219.    performing protocol operations against servers. In this model, this
  220.    is accomplished by a client transmitting a protocol request
  221.    describing the operation to be performed to a server, which is then
  222.    responsible for performing the necessary operations on the Directory.
  223.  
  224.  
  225.  
  226. Young                       Standards Track                     [Page 4]
  227.  
  228. RFC 1798                         CLDAP                         June 1995
  229.  
  230.  
  231.    Upon completion of the necessary operations, the server returns a
  232.    response containing any results or errors to the requesting client.
  233.  
  234.    Note that, although servers are required to return responses whenever
  235.    such responses are defined in the protocol, there is no requirement
  236.    for synchronous behaviour on the part of either client or server
  237.    implementations: requests and responses for multiple operations may
  238.    be exchanged by client and servers in any order, as long as servers
  239.    eventually send a response for every request that requires one.
  240.  
  241.    Also, because the protocol is implemented over a connection-less
  242.    transport service clients must be prepared for either requests or
  243.    responses to be lost.  Clients should use a retry mechanism with
  244.    timeouts in order to achieve the desired level of reliability.  For
  245.    example, a client might send off a request and wait for two seconds.
  246.    If no reply is forthcoming, the request is sent again and the client
  247.    waits four seconds.  If there is still no reply, the client sends it
  248.    again and waits eight seconds, and so on, until some maximun time.
  249.    Such algorithms are widely used in other datagram-based protocol
  250.    implementations, such as the DNS.  It is not appropriate to mandate a
  251.    specific algorithm as this will depend upon the requirments and
  252.    operational environment of individual CLDAP client implementations.
  253.  
  254.    It is not required that a client abandon any requests to which no
  255.    response has been received and for which a reply is no longer
  256.    required (because the request has been timed out), but they may do
  257.    so.
  258.  
  259.    Consistent with the model of servers performing protocol operations
  260.    on behalf of clients, it is also to be noted that protocol servers
  261.    are expected to handle referrals without resorting to the return of
  262.    such referrals to the client. This protocol makes no provisions for
  263.    the return of referrals to clients, as the model is one of servers
  264.    ensuring the performance of all necessary operations in the
  265.    Directory, with only final results or errors being returned by
  266.    servers to clients.
  267.  
  268.    Note that this protocol can be mapped to a strict subset of the
  269.    Directory abstract service, so it can be cleanly provided by the DAP.
  270.  
  271. 3.  Mapping Onto Transport Services
  272.  
  273.    This protocol is designed to run over connection-less transports,
  274.    with all 8 bits in an octet being significant in the data stream.
  275.    Specifications for two underlying services are defined here, though
  276.    others are also possible.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Young                       Standards Track                     [Page 5]
  283.  
  284. RFC 1798                         CLDAP                         June 1995
  285.  
  286.  
  287. 3.1.  User Datagram Protocol (UDP)
  288.  
  289.    The CLDAPMessage PDUs are mapped directly onto UDP datagrams.  Only
  290.    one request may be sent in a single datagram. Only one response may
  291.    be sent in a single datagram.  Server implementations running over
  292.    the UDP should provide a protocol listener on port 389.
  293.  
  294. 3.2.  Connection-less Transport Service (CLTS)
  295.  
  296.    Each LDAPMessage PDU is mapped directly onto T-Unit-Data.
  297.  
  298. 4.  Elements of Protocol
  299.  
  300.    CLDAP messages are defined by the following ASN.1:
  301.  
  302.     CLDAPMessage ::= SEQUENCE {
  303.         messageID       MessageID,
  304.         user            LDAPDN,         -- on request only --
  305.         protocolOp      CHOICE {
  306.                         searchRequest   SearchRequest,
  307.                         searchResponse  SEQUENCE OF
  308.                                             SearchResponse,
  309.                         abandonRequest  AbandonRequest
  310.         }
  311.     }
  312.  
  313.    where MessageID, LDAPDN, SearchRequest, SearchResponse and
  314.    AbandonRequest are defined in the LDAP protocol.
  315.  
  316.    The 'user' element is supplied only on requests (it should be zero
  317.    length and is ignored in responses). It may be used for logging
  318.    purposes but it is not required that a CLDAP server implementation
  319.    apply any particular semantics to this field.
  320.  
  321.    Editorial note:
  322.        There has been some discussion about the desirability of
  323.        authentication with CLDAP requests and the addition of the fields
  324.        necessary to support this. This might take the form of a clear
  325.        text password (which would go against the current IAB drive to
  326.        remove such things from protocols) or some arbitrary credentials.
  327.        Such a field is not included.  It is felt that, in general,
  328.        authentication would incur sufficient overhead to negate the
  329.        advantages of the connectionless basis of CLDAP. If an
  330.        application requires authenticated access to the Directory then
  331.        CLDAP is not an appropriate protocol.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Young                       Standards Track                     [Page 6]
  339.  
  340. RFC 1798                         CLDAP                         June 1995
  341.  
  342.  
  343.    Within a searchResponse all but the last SearchResponse has choice
  344.    'entry' and the last SearchResponse has choice 'resultCode'.  Within
  345.    a searchResponse, as an encoding optimisation, the value of the
  346.    objectName LDAP DN may use a trailing '*' character to refer to the
  347.    baseObject of the corresponding searchRequest.  For example, if the
  348.    baseObject is specified as "o=UofM, c=US", then the following
  349.    objectName LDAPDNs in a response would have the indicated meanings
  350.  
  351.           objectName returned   actual LDAPDN denoted
  352.           ____________________________________________________
  353.           "*"                   "o=UofM, c=US"
  354.           "cn=Babs Jensen, *"   "cn=Babs Jensen, o=UofM, c=US"
  355.  
  356. 4.1.  Errors
  357.  
  358. The following error code is added to the LDAPResult.resultCode
  359. enumeration of [4]:
  360.  
  361.                              resultsTooLarge              (70),
  362.  
  363.    This error is returned when the LDAPMessage PDU containing the
  364.    results of an operation are too large to be sent in a single
  365.    datagram.
  366.  
  367. 4.2.  Example
  368.  
  369.    A simple lookup can be performed in 4 packets. This is reduced to 2
  370.    if either the DSA implements the CLDAP protocol, the CLDAP server has
  371.    a cache of the desired results, or the CLDAP server and DSA are co-
  372.    located such that there is insignificant delay between them.
  373.  
  374.     _______________________________________________________________
  375.    |_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
  376.    | 1|  SearchReq    ->                                          |
  377.    | 2|                      DAP-Search.req   ->                  |
  378.    | 3|                                       <-    DAP-Search.res|
  379.    | 4|               <-     SearchRes                            |
  380.    |__|___________________________________________________________|
  381.  
  382. 5.  Implementation Considerations
  383.  
  384.    The following subsections provide guidance on the implementation of
  385.    clients and servers using the CLDAP protocol.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Young                       Standards Track                     [Page 7]
  395.  
  396. RFC 1798                         CLDAP                         June 1995
  397.  
  398.  
  399. 5.1.  Server Implementations
  400.  
  401.    Given that the goal of this protocol is to minimise the elapsed time
  402.    between making a Directory request and receiving the response, a
  403.    server which uses DAP to access the directory should use techniques
  404.    that assist in this.
  405.  
  406.    - -  A server should remain bound to the Directory during reasonably
  407.         long idle periods or should remain bound permanently.
  408.  
  409.    - -  Cacheing of results is highly desirable but this must be
  410.         tempered by the need to provide up-to-date results given the
  411.         lack of a cache invalidation protocol in DAP (either implicit
  412.         via timers or explicit) and the lack of a dontUseCopy service
  413.         control in the protocol.
  414.  
  415.    Of course these issues are irrelevant if the CLDAP protocol is
  416.    directly supported by a DSA.
  417.  
  418. 5.2.  Client Implementations
  419.  
  420.    For simple lookup applications, use of a retry algorithm with
  421.    multiple servers similar to that commonly used in DNS stub resolver
  422.    implementations is recommended.  The location of a CLDAP server or
  423.    servers may be better specified using IP addresses (simple or
  424.    broadcast) rather than names that must first be looked up in another
  425.    directory such as DNS.
  426.  
  427. 6.  Security Considerations
  428.  
  429.    This protocol provides no facilities for authentication. It is
  430.    expected that servers will bind to the Directory either anonymously
  431.    or using simple authentication without a password.
  432.  
  433. 7.  Bibliography
  434.  
  435.    [1] The Directory: Overview of Concepts, Models and Service.  CCITT
  436.        Recommendation X.500, 1988.
  437.  
  438.    [2] The Directory: Models.  CCITT Recommendation X.501 ISO/IEC JTC
  439.        1/SC21; International Standard 9594-2, 1988.
  440.  
  441.    [3] The Directory: Abstract Service Definition.  CCITT Recommendation
  442.        X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
  443.  
  444.    [4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
  445.        Access Protocol", RFC 1487, Performance Systems International,
  446.        University of Michigan, ISODE Consortium, July 1993.
  447.  
  448.  
  449.  
  450. Young                       Standards Track                     [Page 8]
  451.  
  452. RFC 1798                         CLDAP                         June 1995
  453.  
  454.  
  455.    [5] Mockapetris, P., "Domain Names - Implementation and
  456.        Specification", STD 13, RFC 1035, USC/Information Sciences
  457.        Institute, November 1987.
  458.  
  459.    [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
  460.        13, RFC 1034, USC/Information Sciences Institute, November 1987.
  461.  
  462. 8.  Acknowledgements
  463.  
  464.    Many thanks to Tim Howes and Steve Kille for their detailed comments
  465.    and to other members of the working group.
  466.  
  467.    This work was initiated by the Union Bank of Switzerland.
  468.  
  469. 9.  Author's Address
  470.  
  471.    Alan Young
  472.    ISODE Consortium
  473.    The Dome, The Square
  474.    RICHMOND
  475.    GB - TW9 1DT
  476.  
  477.    Phone: +44 81 332 9091
  478.    EMail: A.Young@isode.com
  479.    X.400:    i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI
  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. Young                       Standards Track                     [Page 9]
  507.  
  508.