idnits 2.17.1 draft-chu-ldap-ldapi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 2007) is 6260 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chu 3 Internet-Draft Symas Corp. 4 Intended status: Informational February 28, 2007 5 Expires: September 1, 2007 7 Using LDAP Over IPC Mechanisms 8 draft-chu-ldap-ldapi-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 1, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 When both the LDAP client and server reside on the same machine, 42 communication efficiency can be greatly improved using host- specific 43 IPC mechanisms instead of a TCP session. Such mechanisms can also 44 implicitly provide the client's identity to the server for extremely 45 lightweight authentication. This document describes the 46 implementation of LDAP over Unix IPC that has been in use in OpenLDAP 47 since January 2000, including the URL format used to specify an IPC 48 session. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4 54 3. Motivation . . . . . . . . . . . . . . . . . . . . . . 5 55 4. User-Visible Specification . . . . . . . . . . . . . . 6 56 4.1. URL Scheme . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Implementation Details . . . . . . . . . . . . . . . . 7 58 5.1. Client Authentication . . . . . . . . . . . . . . . . 7 59 5.2. Other Platforms . . . . . . . . . . . . . . . . . . . 8 60 6. Security Considerations . . . . . . . . . . . . . . . 9 61 7. References . . . . . . . . . . . . . . . . . . . . . . 10 62 7.1. Normative References . . . . . . . . . . . . . . . . . 10 63 7.2. Informative References . . . . . . . . . . . . . . . . 10 64 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . 13 68 1. Introduction 70 While LDAP is a distributed access protocol, it is common for clients 71 to be deployed on the same machine that hosts the server. Many 72 applications are built on a tight integration of the client code and 73 a co-resident server. In these tightly integrated deployments, where 74 no actual network traffic is involved in the communication, the use 75 of TCP/IP is overkill. Systems like Unix offer native IPC mechanisms 76 that still provide the stream-oriented semantics of a TCP session, 77 but with much greater efficiency. 79 Since January 2000, OpenLDAP releases have provided the option to 80 establish LDAP sessions over Unix Domain sockets as well as over 81 TCP/IP. Such sessions are inherently as secure as TCP loopback 82 sessions, but they consume fewer system resources, are much faster to 83 establish and tear down, and they also provide secure identification 84 of the client without requiring any additional passwords or other 85 credentials. 87 2. Conventions 89 Imperative keywords defined in [RFC2119] are used in this document, 90 and carry the meanings described there. 92 3. Motivation 94 Many LDAP sessions consist of just one or two requests. Connection 95 setup and teardown can become a significant portion of the time 96 needed to process these sessions. Also under heavy load, the 97 constraints of the 2MSL limit in TCP become a bottleneck. For 98 example, a modest single processor dual-core AMD64 server running 99 OpenLDAP can handle over 32,000 authentication requests per second on 100 100Mbps ethernet, with one connection per request. Connected over a 101 host's loopback interface, the rate is much higher, but connections 102 get completely throttled in under one second, because all of the 103 host's port numbers have been used up and are in TIME_WAIT state. So 104 even when the TCP processing overhead is insignificant, the 105 constraints imposed in [RFC0793] create an artificial limit on the 106 server's performance. No such constraints exist when using IPC 107 mechanisms instead of TCP. 109 4. User-Visible Specification 111 The only change clients need to implement to use this feature is to 112 use a special URL scheme instead of an ldap:// URL when specifying 113 the target server. Likewise, the server needs to include this URL in 114 the list of addresses on which it will listen. 116 4.1. URL Scheme 118 The "ldapi:" URL scheme is used to denote an LDAP over IPC session. 119 The address portion of the URL is the name of a Unix Domain socket, 120 which is usually a fully qualified Unix filesystem pathname. Slashes 121 in the pathname must be percent-encoded as described in section 2.1 122 of [RFC3986] since they do not represent URL path delimiters in this 123 usage. E.g., for a socket named "/var/run/ldapi" the server URL 124 would be "ldapi://%26var%26run%26ldapi/". In all other respects, an 125 ldapi URL conforms to [RFC4516]. 127 If no specific address is supplied, a default address MAY be used 128 implicitly. In OpenLDAP the default address is a compile-time 129 constant and its value is chosen by whoever built the software. 131 5. Implementation Details 133 The basic transport uses a stream-oriented Unix Domain socket. The 134 semantics of communication over such a socket are essentially 135 identical to using a TCP session. Aside from the actual connection 136 establishment, no special considerations are needed in the client, 137 libraries, or server. 139 5.1. Client Authentication 141 Since their introduction in 4.2 BSD Unix, Unix Domain sockets have 142 also allowed passing credentials from one process to another. Modern 143 systems may provide a server with easier means of obtaining the 144 client's identity. The OpenLDAP implementation exploits multiple 145 methods to acquire the client's identity. The discussion that 146 follows is necessarily platform-specific. 148 The OpenLDAP library provides a getpeereid() function to encapsulate 149 all of the mechanisms used to acquire the identity. 151 On FreeBSD and MacOSX the native getpeereid() is used. 153 On modern Solaris systems the getpeerucred() system call is used. 155 On systems like Linux that support the SO_PEERCRED option to 156 getsockopt(), that option is used. 158 On Unix systems lacking these explicit methods, descriptor passing is 159 used. In this case, the client must send a message containing the 160 descriptor as its very first action immediately after the socket is 161 connected. The descriptor is attached to an LDAP Abandon Request 162 [RFC4511] with message ID zero, whose parameter is also message ID 163 zero. This request is a pure no-op, and will be harmlessly ignored 164 by any server that doesn't implement the protocol. 166 For security reasons, the passed descriptor must be tightly 167 controlled. The client creates a pipe and sends the pipe descriptor 168 in the message. The server receives the descriptor and does an 169 fstat() on it to determine the client's identity. The received 170 descriptor MUST be a pipe, and its permission bits MUST only allow 171 access to its owner. The owner uid and gid are then used as the 172 client's identity. 174 Note that these mechanisms are merely used to make the client's 175 identity available to the server. The server will not actually use 176 the identity information unless the client performs a SASL Bind 177 [RFC4513] using the EXTERNAL mechanism. I.e., as with any normal 178 LDAP session, the session remains in the anonymous state until the 179 client issues a Bind request. 181 5.2. Other Platforms 183 It is possible to implement the corresponding functionality on 184 Microsoft Windows-based systems using Named Pipes, but thus far there 185 has been no demand for it, so the implementation has not been 186 written. These are brief notes on the steps required for an 187 implementation. 189 The Pipe should be created in byte-read mode, and the client must 190 specify SECURITY_IMPERSONATION access when it opens the pipe. The 191 server can then retrieve the client's identity using the 192 GetNamedPipeHandleState() function. 194 Since Windows socket handles are not interchangeable with IPC 195 handles, an alternate event handler would have to be provided instead 196 of using Winsock's select() function. 198 6. Security Considerations 200 This document describes a mechanism for accessing an LDAP server that 201 is co-resident with the client machine. As such, it is inherently 202 immune to security issues associated with using LDAP across a 203 network. The mechanism also provides a means for a client to 204 authenticate itself to the server without exposing any sensitive 205 passwords. The security of this authentication is equal to the 206 security of the host machine. 208 7. References 210 7.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 216 Scheme Names", BCP 35, RFC 2717, November 1999. 218 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 219 Resource Identifier (URI): Generic Syntax", STD 66, 220 RFC 3986, January 2005. 222 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 223 (LDAP): The Protocol", RFC 4511, June 2006. 225 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 226 (LDAP): Authentication Methods and Security Mechanisms", 227 RFC 4513, June 2006. 229 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 230 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 231 June 2006. 233 7.2. Informative References 235 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 236 RFC 793, September 1981. 238 Appendix A. IANA Considerations 240 This document satisfies the requirements of [RFC2717] for 241 registration of a new URL scheme. 243 Author's Address 245 Howard Chu 246 Symas Corp. 247 18740 Oxnard Street, Suite 313A 248 Tarzana, California 91356 249 USA 251 Phone: +1 818 757-7087 252 Email: hyc@symas.com 254 Full Copyright Statement 256 Copyright (C) The IETF Trust (2007). 258 This document is subject to the rights, licenses and restrictions 259 contained in BCP 78, and except as set forth therein, the authors 260 retain all their rights. 262 This document and the information contained herein are provided on an 263 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 264 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 265 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 266 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 267 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 268 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Intellectual Property 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org. 294 Acknowledgment 296 Funding for the RFC Editor function is provided by the IETF 297 Administrative Support Activity (IASA).