From e3a5562089c1364bc0981df78ecc7dd466a0a417 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Wed, 30 Aug 2000 22:23:40 +0000 Subject: [PATCH] rev 04 --- doc/drafts/draft-ietf-ldapext-locate-xx.txt | 60 +++++++++++---------- 1 file changed, 31 insertions(+), 29 deletions(-) diff --git a/doc/drafts/draft-ietf-ldapext-locate-xx.txt b/doc/drafts/draft-ietf-ldapext-locate-xx.txt index 12a176963e..88d6cd2b01 100644 --- a/doc/drafts/draft-ietf-ldapext-locate-xx.txt +++ b/doc/drafts/draft-ietf-ldapext-locate-xx.txt @@ -1,7 +1,7 @@ INTERNET-DRAFT Michael P. Armijo - Levon Esibov -July, 2000 Paul Leach -Expires: January, 2001 Microsoft Corporation + Levon Esibov +August, 2000 Paul Leach +Expires: February, 2001 Microsoft Corporation R.L. Morgan University of Washington @@ -29,7 +29,7 @@ Status of this Memo http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. It is filed as , and expires on January 14, 2001. + ietf-ldapext-locate-04.txt>, and expires on February 25, 2001. Please send comments to the authors. @@ -92,16 +92,17 @@ Status of this Memo DNs cannot be converted into a domain name. Converted DNs result in a fully qualified domain name. - The output domain name is initially empty. For each RDN component - of the DN, beginning with the rightmost and working left, if the - attribute type is "DC", then the attribute value is used as a domain - name component (label). - The first such value becomes the most significant (i.e., rightmost) - domain name component, and successive values occupy less significant - positions (i.e., extending leftward), in order. If the attribute - type is not "DC", then processing stops. If the final RDN component - of the DN is not of type "DC" then the DN cannot be converted to a - domain name. + The output domain name is initially empty. The DN is processed in + right-to-left order (i.e., beginning with the first RDN in the + sequence of RDNs). An RDN is able to be converted if it (1) + consists of a single AttributeTypeAndValue; (2) the attribute type + is "DC"; and (3) the attribute value is non-null. If it can be + converted, the attribute value is used as a domain name component + (label). The first such value becomes the rightmost (i.e., most + significant) domain name component, and successive converted RDN + values extend to the left. If an RDN cannot be converted, + processing stops. If the output domain name is empty when + processing stops, the DN cannot be converted into a domain name. For DN: @@ -128,18 +129,16 @@ Status of this Memo _._. where is always "ldap", and is a protocol that can - be either "udp" or "tcp". "_ldap._tcp" applies to services - compatible with LDAPv2 [7] or LDAPv3 [1]. "_ldap._udp" - applies to services compatible with CLDAP [8]. is - the domain name formed by converting the DN of a naming context - mastered by the LDAP Server into a domain name using the algorithm in - Section 3. Note that "ldap" is the symbolic name for the LDAP service - in Assigned Numbers[6], as required by [5]. + be either "udp" or "tcp". is the domain name formed by + converting the DN of a naming context mastered by the LDAP Server + into a domain name using the algorithm in Section 3. Note that + "ldap" is the symbolic name for the LDAP service in Assigned + Numbers[6], as required by [5]. Presence of such records enables clients to find the LDAP servers using standard DNS query [4]. A client (or server) seeking an LDAP server for a particular DN converts that DN to a domain name using - the algorithm of Section 2, does a SRV record query using the DNS + the algorithm of Section 3, does a SRV record query using the DNS name formed as described in the preceding paragraph, and interprets the response as described in [5] to determine a host (or hosts) to contact. As an example, a client that searches for an LDAP server @@ -163,10 +162,16 @@ Status of this Memo 5. Security Considerations + DNS responses can typically be easily spoofed. Clients using this + location method SHOULD ensure, via use of strong security + mechanisms, that the LDAP server they contact is the one they + intended to contact. See [7] for more information on security + threats and security mechanisms. + This document describes a method that uses DNS SRV records to discover LDAP servers. All security considerations related to DNS SRV records are inherited by this document. See the security - considerations section in [6] for more details. + considerations section in [5] for more details. 6. References @@ -191,11 +196,8 @@ Status of this Memo [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. - [7] Yeong, W., Howes, T. and Kille, S., "Lightweight Directory Access - Protocol", RFC 1777, March 1995 - - [8] Young, A., "Connection-less Lightweight Directory Access Protocol", - RFC 1798, June 1995 + [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R., + "Authentication Methods for LDAP", RFC 2829, May 2000. 7. Authors' Addresses @@ -225,7 +227,7 @@ Status of this Memo EMail: rlmorgan@washington.edu URI: http://staff.washington.edu/rlmorgan/ - Expires January, 2001 + Expires February 25, 2001 -- 2.39.5