idnits 2.17.1 draft-ietf-svrloc-ldap-scheme-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-ieft-svrloc-ldap-scheme-02', but the file name used is 'draft-ietf-svrloc-ldap-scheme-02' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (25 June 1999) is 9072 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? '1' on line 176 looks like a reference -- Missing reference section? '2' on line 179 looks like a reference -- Missing reference section? '3' on line 182 looks like a reference -- Missing reference section? '4' on line 185 looks like a reference -- Missing reference section? '5' on line 189 looks like a reference -- Missing reference section? '6' on line 193 looks like a reference -- Missing reference section? '7' on line 196 looks like a reference -- Missing reference section? '8' on line 199 looks like a reference -- Missing reference section? '9' on line 202 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Location Working Group Jonathan Wood 3 INTERNET DRAFT Roberto Tam 4 Sun Microsystems, Inc. 5 25 June 1999 7 The LDAP Service Type 8 draft-ieft-svrloc-ldap-scheme-02.txt 10 Status of This Memo 12 This document is a submission by the Service Location Working Group 13 of the Internet Engineering Task Force (IETF). Comments should be 14 submitted to the srvloc@srvloc.org mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes the LDAP service type. This service type 38 defines the service: URL and attributes necessary for discovering 39 LDAP servers. 41 1. Introduction 43 This document describes a template providing a service: URL and 44 attributes useful for dynamically discovering LDAP servers; this type 45 can be used with SLP [1]. Service templates and service: schemes are 46 defined in [2]. 48 LDAP (Lightweight Directory Access Protocol) [3] directories are 49 now being used as repositories for UNIX-style system information. 50 As such, LDAP service is suitable to be included in the naming- 51 directory class. This type is intended to be used as a concrete 52 portion of the abstract naming-directory type defined in [4]. The 53 LDAP type includes all attributes from the naming-directory abstract 54 type, and defines new attributes pertaining to security and access 55 protocols. 57 For usage examples for non-LDAP specific scenarios, refer to [4]. 59 2. Differentiating Servers by Authentication Mechanisms 61 Possible means of authenticating LDAP transactions are defined 62 in [5]. In order to agree on a particular authentication mechanism, 63 a client and server might need to go through a number of iterations 64 and levels of negotiation. Currently there are three levels of 65 mechanisms: The first level consists of the basic mechanisms, 66 anonymous, simple, and TLS. The second layer consists of the SASL 67 negotiation layer [6]. The third layer consists of GSSAPI [7] 68 mechanisms, and possible the GSS-SPNEGO negotiation sequence [8]. 69 Thus it is possible that a client wishing to use the Kerberos V5 70 GSSAPI mechanism may need to negotiate its way through SASL and 71 GSS-SPNEGO before coming to an agreement with the server. 73 Since LDAP clients are already aware of what mechanisms they have 74 been configured to use when connecting to an LDAP server, the 75 attributes in this template have been designed to allow clients to 76 optimize both their search for servers and the following negotiation 77 sequence for authentication mechanisms. Clients may specify as 78 little or as much of their desired negotiation path. For example, 79 all of the following SLP [1] search filters are valid: 81 (security=sasl) 83 (&(security=sasl)(|(sasl-mechs=cram-md5)(sasl-mechs=external))) 85 (&(security=sasl)(sasl-mechs=GSSAPI)(gss-mechs=1.3.5.1.5.2)) 87 The more fully a client specifies the negotiation path, the greater 88 the likelihood that the client will discover a server which 89 supports the same mechanisms as the client. If a server does not 90 support the required mechanisms, clients will need to move on to 91 other discovered servers, and repeat the negotiation process. This 92 can be a costly process. Additionally, clients should be able to 93 optimize the resulting negotiation, bypassing mechanisms which are 94 not acceptable to one of the parties. 96 The allowable values for the "security" attribute follows those 97 defined in [5]. 99 The allowable values for the "sasl-mechs" and "gss-mechs" 100 attributes are meant to be fluid, following the decisions of their 101 respective working groups. 103 3. The LDAP Service Type 105 Names of submitters: Jonathan Wood 106 Roberto Tam 107 Language of service template: en 108 Security Considerations: 109 This LDAP service type inherits the security considerations from the 110 naming-directory service type [4], the SLP specification [1]. 111 Implementors should also be aware of the security considerations 112 discussed in [5]. 114 Template text: 115 -------------------------template begins here----------------------- 116 template-type=naming-directory:ldap 118 template-version=0.0 120 template-description= 121 This is a concrete type; the abstract type for this service 122 is naming-directory (described in [4]). This type is used 123 by LDAP servers to advertise their services and LDAP clients 124 which wish to discover LDAP servers. 126 template-url=syntax= 127 url-path = ldap URL as defined in [9] 129 security=string M 130 # Security mechanisms supported by this server. Permitted values 131 # are drawn from draft-ietf-ldapext-authmeth-03 (Authentication 132 # Methods for LDAP). If SASL is supported, clients may further 133 # differentiate servers with the sasl-mechs attribute. 134 anonymous,simple,tls,sasl 136 sasl-mechs=string M 137 # SASL mechanisms supported by this server. If the GSSAPI or GSS-SPNEGO 138 # mechanisms are supported, clients may further differentiate servers 139 # with the gss-mechs attribute. SASL mechanisms are registered with 140 # IANA; legal values of this attribute are the mechanism keywords 141 # registered with IANA. SASL is defined in RFC 2222. 143 gss-mechs=string M 144 # GSSAPI mechanisms supported by this server. The mechanisms are 145 # named by their object identifiers (OIDs). GSSAPI is defined 146 # in RFC 2078, and GSS-SPNEGO is defined in RFC 2478. 148 qop= string 149 # quality of protection. The refers to how strongly messages are 150 # protected. There are three possibilities: none, integrity 151 # (meaning that the integrity and endpoints of the message can 152 # be guaranteed), and privacy (meaning that the message is 153 # encrypted). 154 none,integrity,privacy 156 transport= string 157 # the transport used to communicate with this server. Possible 158 # values are connection-oriented (cots) and connectionless 159 # (clts). 160 cots,clts 162 version= string M 163 # Which version(s) of LDAP this server supports. "v3" corresponds to 164 # the protocol as defined by RFC 2251, and "v2" corresponds to the 165 # protocol as defined by RFC 1777. 166 v2,v3 168 extensions= string M 169 # This is an open-ended attribute intended to contain any standard or 170 # non-standard (i.e. vendor-specific) extensions this server supports. 172 --------------------------template ends here------------------------ 174 References: 176 [1] E. Guttman, C. Perkins, J. Veizades, M. Day. Service Location 177 Protocol. RFC 2608, April 1999 179 [2] E. Guttman, C. Perkins, J. Kempf, Service Templates and service: 180 Schemes. RFC 2609, February 1999 182 [3] W. Yeong, T. Howes, S. Kille, Lightweight Directory Access 183 Protocol, RFC 1777 March 1995 185 [4] J. Wood, R. Tam, The Naming and Directory Service Abstract Type. 186 draft-ietf-svrloc-naming-directory-01.txt, June 1999 (work in 187 progress) 189 [5] M. Wahl, H. Alvestrand, J. Hodges, RL Morgan. Authentication 190 Methods for LDAP, draft-ietf-ldapext-authmeth-04.txt, November 191 1998 (work in progress) 193 [6] J. Meyers, Simple Authentication and Security Layer (SASL) 194 RFC 2222 October 1997 196 [7] J. Linn, Generic Security Service Application Program Interface, 197 Version 2, RFC 2078 January 1997 199 [8] E. Baize, D. Pinkas, The Simple and Protected GSS-API Negotiation 200 Mechanism, RFC 2478 December 1998 202 [9] T. Howes, M. Smith, The LDAP URL Format, RFC 2255 December 1997