idnits 2.17.1 draft-ietf-svrloc-naming-directory-scheme-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 (2024-04-26) 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) 2024 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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-ieft-svrloc-naming-directory-scheme-01', but the file name used is 'draft-ietf-svrloc-naming-directory-scheme-01' == 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. 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 310 looks like a reference -- Missing reference section? '2' on line 313 looks like a reference -- Missing reference section? '3' on line 316 looks like a reference -- Missing reference section? '4' on line 319 looks like a reference -- Missing reference section? '5' on line 322 looks like a reference -- Missing reference section? '6' on line 325 looks like a reference -- Missing reference section? '7' on line 328 looks like a reference -- Missing reference section? '8' on line 261 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 Naming and Directory Service Abstract Type 8 draft-ieft-svrloc-naming-directory-scheme-01.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 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To view the entire list of current Internet-Drafts, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Distribution of this memo is unlimited. 34 Abstract 36 This document describes the Naming and Directory Service abstract 37 type. This abstract type serves as an umbrella type for all 38 services which support directory-style operations for obtaining 39 system information. This type collects a core set of attributes 40 common to all such services. 42 1. Introduction 44 This document defines a template for the naming and directory 45 service abstract type. Templates and service types are 46 defined in [1]. This type can be used with SLP [2] to 47 dynamically discover naming and directory servers. In 48 particular, this type applies to name spaces which contain 49 information intended primarily for system consumption; 50 examples of such information are UNIX-style system information 51 (such as passwd, hosts, and service tables), and public-key 52 certificates for authenticating principals such as people and 53 hosts. 55 Currently there is a wide variety of services which are used 56 to serve system information (i.e. NIS, NIS+, LDAP, NDS, etc.). 57 It is common for two or more of these services to be deployed 58 at the same time on the same network. This creates configuration 59 complexity for naming and directory clients on the network: 60 How does a client choose the right service, and once chosen, 61 how does the client find the access handle to that service? 63 The type defined by this document manages this complexity by 64 collecting attributes common to all naming and directory services, 65 allowing clients to select the right service from a 66 heterogeneous pool. This type can be used in conjunction with 67 SLP to implement a unified discovery solution. 69 Note that concrete types include all attributes defined in this 70 template; they may also define attributes specific to their 71 service. Examples of concrete type templates can be found in 72 [3], [4], and [5]. 74 2. Examples 76 This section presents two scenarios to illustrate how this type might 77 be used. For both scenarios, it is assumed that a number of naming 78 and directory services have been deployed in the network, and 79 that they are advertising their services via SLP. The following 80 list enumerates the registered servers and their attributes. Note 81 that in an actual registration, the template attributes would be 82 included in the attributes list, and all attributes and URLs would 83 be properly escaped. Here, however, these steps have been omitted 84 for the sake of brevity and readability: 86 URL: 87 service:naming-directory:nis://192.168.1.100/eng.wiz.com 88 Attributes: 89 naming-context=eng.wiz.com 90 organization=flat 91 dynamic-updates=false 92 jndi-sp-available=true 93 master=true 95 URL: 96 service:naming-directory:nis://192.168.1.200/eng.wiz.com 98 Attributes: 99 naming-context=eng.wiz.com 100 organization=flat 101 dynamic-updates=false 102 jndi-sp-available=true 103 master=false 105 URL: 106 service:naming-directory:nisplus://192.168.2.100/b17.eng.wiz.com 107 Attributes: 108 naming-context=b17.eng.wiz.com 109 organization=hierarchical 110 dynamic-updates=true 111 jndi-sp-available=false 112 master=true 113 security-mechanism=dh-ext 114 pubkey=(dh-ext)1a22345def3324f3ecbb... 116 URL: 117 service:naming-directory:ldap://192.168.3.100/dc=eng,dc=wiz,dc=com 118 Attributes: 119 naming-context=dc=eng,dc=wiz,dc=com 120 organization=hierarchical 121 dynamic-updates=true 122 jndi-sp-available=true 123 master=true 124 security-mechanism=clear,tls,kerb5 125 transport=cots 127 Note that some attributes are not defined in the template 128 given below; they are defined in the templates for the 129 particular services. 131 2.1. System Configuration 133 A number of UNIX platforms currently bundle clients for the 134 NIS, NIS+, and LDAP services. When the system initially needs 135 to configure its name service, it has no idea with what services 136 its new network has been populated. It does, however, know 137 that it wants an authenticated connection to its server, and 138 that it has been configured with Kerberos and extended DH 139 security. Also, it would like to talk to an authoritative server 140 to populate its initial configuration. 142 So, in order to discover what naming services are available, 143 the system issues the following SLP service request: 145 =service:naming-directory 146 =(&(|(security=kerb5)(security=dh-ext))(master=true)) 148 It receives the following service handles: 150 service:naming-directory:ldap://192.168.3.100/dc=eng,dc=wiz,dc=com 151 service:naming-directory:nisplus://192.168.2.100/b17.eng.wiz.com 153 Each service handle provides enough information to contact and 154 query the server. 156 The system then decides whether to use NIS+ or LDAP (or both), 157 and uses the access handle to contact the server. 159 2.2. JNDI Configuration 161 The Java Naming and Directory Interface (JNDI) [6] provides a 162 common interface to naming and directory operations. Using JNDI, 163 it is possible to write an application which accesses directories 164 without knowing which particular naming or directory service 165 it is actually talking to. 167 However, JNDI applications require some initial configuration 168 in order to find and query a service; this configuration is 169 different for each different kind of service. 171 This example demonstrates how JNDI applications can use SLP to 172 configure themselves in a unified manner. All the application needs 173 to know in advance is in what manner it wishes to use a naming or 174 directory service. 176 In this example, the JNDI application wishes to obtain authentication 177 information for a user, and to update preferences for that user in 178 the directory. Therefore the required attributes for this directory 179 are: 180 - dynamic-updates = true 181 - jndi-sp-available = true 182 The 'jndi-sp-available' attribute is used to find only those services 183 for which a JNDI service provider exists, since the application 184 needs this driver to communicate with any found services. These 185 required attributes are all the application currently "knows"; it 186 does not know the address or even the access protocol of a server, 187 nor does it have any JNDI service provider available to it. All 188 it has are the JNDI framework classes, and a Java environment. 190 In order to obtain service handles to suitable service instances, 191 the application issues the following SLP service request: 193 =service:naming-directory 194 =(&(dynamic-updates=true)(jndi-sp-available)) 196 It receives the following service handles: 198 service:naming-directory:ldap://192.168.3.100/dc=eng,dc=wiz,dc=com 200 At this point, the application now has enought configuration 201 information to contact the server. However, it does not have the 202 Java class files for the LDAP service provider implementation. It 203 can dynamically discover, download, and instantiate the necessary 204 classfiles using SLP and the JNDI Drivers service type [7]. See [7] 205 for an example of this process. 207 The JNDI application is now able to configure itself to talk to a 208 directory server, and access the necessary JNDI service provider. 210 3. The Naming and Directory Service Abstract Type 212 Names of submitters: Jonathan Wood 213 Roberto Tam 214 Language of service template: en 215 Security Considerations: 216 If these services are used as authentication repositories, and they 217 are compromised, any clients of the service become susceptible to 218 forged identities. This could result in compromised systems, forged 219 messages, etc. Some security measure, such as SLP security, should 220 be used to authenticate service advertisements. 222 In particular, it is important to understand what is trusted 223 during the process of service discovery. If no security measures 224 are used, all service advertisements are implicitly trusted. This 225 scenario allows for very trivial attacks: an attacker need only 226 insert a malicious advertisement for a bogus directory server into 227 the service name space. It should also be noted that this scenario 228 is open to inadvertant attacks. For example, someone may be testing 229 an LDAP server which advertises itself according to [5]. If the 230 test server is configured in manner similar to production servers, 231 clients will bind to the test server and find false or missing 232 data. 234 The triviality of the attacks outlined above should provide a strong 235 case for implementing security measures. However, even with security 236 measures it is important to understand trust dependencies. 237 Discovery frameworks like SLP [2] provide only the mechanism for 238 making service advertisements available and authenticated. Thus 239 advertisements obtained via the discovery framework are valid only 240 if a correct advertisement was originally injected into the 241 discovery name space. For example, if an LDAP server was incorrectly 242 configured, or became corrupted, the bogus configuration would 243 be reflected through the discovery framework to all clients. If the 244 configuration error pertained to security, the client and server may 245 end up using a weaker security flavor than necessary. 247 Public key cryptography is ideal for discovery frameworks, since it 248 lends itself to store-and-forward mechanisms which can be very 249 efficient (for example, directory agents in SLP), and can be 250 scalably deployed (see [8]). However, a PKI introduces another 251 complex set of trust considerations. For a PKI to be reasonably 252 secure, the public key of the principal to be authenticated must 253 have been obtained in a secure manner. Discovery frameworks which 254 use a PKI must thus trust that the public key or certificate it 255 is using for authentication is valid. For example, if a PKI were 256 implemented such that it dynamically retrieves a public key over 257 the network in an unsecured transfer, an attacker could substitute 258 a false public key and thus trick the discovery client into 259 believing a principal was to be trusted. The client could then be 260 tricked into using a false advertisement and connect to a bogus 261 server. [8] defines mechanisms to handle the attack just described. 262 PKI users must also trust that the site administrator has correctly 263 configured and populated the PKI. Finally, PKI users must trust the 264 method used to discover key servers. DNS is often implicitly 265 trusted in this step; insertion of a bogus address for a key server 266 into the DNS can prevent clients from accessing their PKI. 268 See also the security considerations from [2]. 270 Template text: 271 -------------------------template begins here----------------------- 272 template-type=naming-directory 274 template-version=0.0 276 template-description= 277 This is an abstract service type. This type is intended to 278 encompass all services which support directory-style operations 279 for looking up and searching system information. 281 template-url-syntax= 282 url-path= ; Depends on concrete service type. 284 naming-context= string M 285 # A list of the names of organizational units or domains which 286 # this server serves. 288 organization= string 289 # Names spaces can be either hierarchical (as in LDAP) or flat 290 # (as in NIS). 291 flat,hierarchical 293 dynamic-updates= boolean 294 # True if the service's namespace can be modified dynamically; 295 # false if the namespace is static. 297 jndi-sp-available= boolean O 298 # True if a JNDI service provider is available for this particular 299 # service. 301 master= boolean 302 # True if an instance of a service is the master or authoritative 303 # server for a namespace. For multi-master services, all masters 304 # should set this value to true. 306 --------------------------template ends here------------------------ 308 References: 310 [1] E. Guttman, C. Perkins, J. Kempf, Service Templates and service: 311 Schemes. RFC 2609, February 1999 313 [2] E. Guttman, C. Perkins, J. Veizades, M. Day. Service Location 314 Protocol. RFC 2608, April 1999 316 [3] J. Wood, R. Tam, The NIS Service Type. draft-ieft-svrloc-nis- 317 scheme-00.txt, November 1998 (work in progress) 319 [4] J. Wood, R. Tam, The NIS+ Service Type. draft-ieft-svrloc-nisplus- 320 scheme-00.txt, November 1998 (work in progress) 322 [5] J. Wood, R. Tam, The LDAP Service Type. draft-ieft-svrloc-ldap- 323 scheme-02.txt, June 1999 (work in progress) 325 [6] The Java Naming and Directory Interface (TM) Specification, 326 Sun Microsystems, Inc. Feb 1998. http://java.sun.com/jndi/. 328 [7] J. Kempf, J. Wood, The jndi-drivers Abstract Service Type. 329 draft-ietf-svrloc-jndi-drivers-00.txt, June 1998 330 (work in progress)