idnits 2.17.1 draft-melnikov-ldap-distr-auth-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.5 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages -- Found 8 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 129 has weird spacing: '...on. The reque...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (July 2004) is 7196 days in the past. Is this intentional? 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: 'BER' is mentioned on line 130, but not defined -- Looks like a reference, but probably isn't: '0' on line 136 -- Looks like a reference, but probably isn't: '1' on line 104 -- Looks like a reference, but probably isn't: '2' on line 87 -- Looks like a reference, but probably isn't: '3' on line 88 -- Looks like a reference, but probably isn't: '4' on line 89 -- Looks like a reference, but probably isn't: '5' on line 90 == Missing Reference: 'RFC2396' is mentioned on line 118, but not defined ** Obsolete undefined reference: RFC 2396 (Obsoleted by RFC 3986) == Unused Reference: 'ABNF' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'SASL' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC 2396' is defined on line 270, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 3383 (Obsoleted by RFC 4520) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 15 errors (**), 0 flaws (~~), 11 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet Draft Isode Limited 4 Document: draft-melnikov-ldap-distr-auth-00.txt Kurt D. Zeilenga 5 Expires in six months OpenLDAP Foundation 6 July 2004 8 Distributed SASL authentication in LDAP 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that 17 other groups may also distribute working documents as Internet 18 Drafts. Internet Drafts are draft documents valid for a maximum of 19 six months. Internet Drafts may be updated, replaced, or obsoleted 20 by other documents at any time. It is not appropriate to use 21 Internet Drafts as reference material or to cite them other than as 22 ``work in progress''. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 A revised version of this draft document will be submitted to the RFC 31 editor as a Draft Standard for the Internet Community. Discussion 32 and suggestions for improvement are requested. Distribution of this 33 draft is unlimited. 35 Internet DRAFT Distributed authentication in LDAP 12 July 2004 37 Abstract 39 This document was prompted by a desire to allow deployments of 40 distributed SASL implementations, so that all authentication can be 41 performed in a one central place. It tries to fulfill the following 42 requirements: 44 1) The SASL framework is client/server authentication, but it doesn't 45 preclude either the client or the server implementations from being 46 distributed. 48 2) It might be also desirable to proxy an authentication exchange 49 whether it was initiated over LDAP or another SASL-supporting 50 protocol. 52 This document defines a Distributed Authentication LDAP extended 53 operation, that enables applications (including LDAP proxies and 54 gateways) that authenticate using SASL, to use LDAP for performing 55 authentication, by forwarding the SASL authentication requests to an 56 LDAP server. 58 1. Conventions used in this document 60 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 61 in this document are to be interpreted as defined in "Key words for 62 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 64 All Basic Encoding Rules (BER)[BER] encodings follow the conventions 65 found in Section 5.1 of [RFC2251]. 67 2. Distributed authentication Request and Response 69 2.1. Distributed authentication Request 71 The Distributed authentication Request is sent as an LDAP extended 72 operation. The requestName is 1.3.6.1.4.1.453.23.1. The requestValue 73 is the BER [BER] encoding of the following ChainedAuthRequestValue 74 ASN.1 definition. 76 ChainedAuthRequestValue ::= SEQUENCE { 77 bindRequest BindRequest, 78 chainingAuthArguments ChainingAuthArguments } 80 ChainingAuthArguments ::= SEQUENCE { 82 Internet DRAFT Distributed authentication in LDAP 12 July 2004 84 serviceName [0] LDAPString DEFAULT '6C646170'H, 85 -- the default value is string "ldap" 86 serviceProtocol [1] ServiceProtocol DEFAULT (0), 87 serverHostname [2] HostName, 88 clientEndpoint [3] Endpoint OPTIONAL, 89 serverEndpoint [4] Endpoint OPTIONAL, 90 controls [5] Controls OPTIONAL, 91 ... } 93 Endpoint ::= CHOICE { 94 ipv4 [0] Ipv4Endpoint, 95 ipv6 [1] Ipv6Endpoint, 96 ... } 98 Ipv4Endpoint ::= SEQUENCE { 99 ipAddress [0] Ipv4Address, 100 port [1] INTEGER (1 .. 65535) } 102 Ipv6Endpoint ::= SEQUENCE { 103 ipAddress [0] Ipv6Address, 104 port [1] INTEGER (1 .. 65535) } 106 ServiceProtocol ::= ENUMERATED { 107 tcp (0), 108 udp (1), 109 ... } 111 Ipv4Address ::= OCTET STRING -- UTF-8 encoded 112 -- Constrained to [RFC2373] 114 Ipv6Address ::= OCTET STRING -- UTF-8 encoded 115 -- Constrained to [RFC2373] 117 HostName ::= OCTET STRING -- UTF-8 encoded 118 -- Constrained to [RFC2396] 120 BindRequest and Controls are defined in [RFC2251]. 122 <> 126 2.2. Distributed authentication Response 128 The Distributed authentication Response is sent as an LDAP extended 129 operation. The requestName is omitted. The requestValue is the BER 130 [BER] encoding of the following ChainedAuthResponse ASN.1 definition. 132 Internet DRAFT Distributed authentication in LDAP 12 July 2004 134 ChainedAuthResponse ::= SEQUENCE { 135 bindResponse BindResponse, 136 controls [0] Controls OPTIONAL, 137 ... } 139 <> 142 <> 144 BindResponse and Controls are defined in [RFC2251]. 146 2.3. Semantics of Distributed authentication Request and Response 148 In order to avoid confusion, this section will use the following 3 149 terms to define parties involved in a Distributed Authentication 150 exchange. The term "server" refers to an LDAP server which is the 151 recipient of Distribution Authentication Request. The term "client" 152 refers to an LDAP client which sends the Distribution Authentication 153 Request. The "client" also acts as a SASL server (in a normal sense 154 of this word) for another authentication exchange, which is happening 155 between an "application" and the "client". The authentication 156 exchange may be carried by any SASL-supporting protocol, which is not 157 necessarily LDAP. 159 A Distributed authentication Request consist of a bind Request 160 information, together with some additional information that would 161 enable the server to perform authentication on client's behalf. The 162 additional information is described by chainingAuthArguments. 164 In a case when the client is an application level gateway between 165 another SASL-supporting protocol and LDAP, the 166 chainingAuthArguments.serviceName must be set to the service name 167 [GSSAPI] of the protocol used to carry out authentication exchange 168 between the application and the client. For example, if the client 169 is an SMTP server [SMTP] this value would be set to "smtp". 171 The chainingAuthArguments.serviceProtocol is set to 0 (i.e. TCP) by 172 default. This field is reserved for future extensibility when the 173 authentication exchange between the application and the client 174 doesn't happen over TCP. 176 The chainingAuthArguments.serverHostname is the fully qualified 177 hostname that was used by the client when it has accepted the 178 original authentication request from the application. This field is 179 required, because the client may, for example, listen on multiple 180 interfaces that may have different hostnames associated with them. 182 Internet DRAFT Distributed authentication in LDAP 12 July 2004 184 The chainingAuthArguments.clientEndpoint and 185 chainingAuthArguments.serverEndpoint define connection endpoint 186 information for the authentication exchange carried out between the 187 application and the client respectively. 189 The chainingAuthArguments.controls member contains controls that are 190 associated with the bindResponse. The controls serve the same purpose 191 as controls attached to a bind request. 193 <> 195 3. Security considerations 197 Distributed authentication extended operation assumes that both 198 endpoints are secure. A compromise of one endpoint may make it 199 possible to use the operation to mount a MITM attack. <> 202 An LDAP server should (<>) only accept Distributed 203 authentication Requests from trusted peers and only over properly 204 protected channel. It is recommended that before issuing the 205 Distributed authentication operation the protocol peers: 207 - establish each other identities through appropriate authentication 208 mechanism, 209 - establish appropriate data integrity, data confidentiality, and 210 other protections, 211 - establish an LDAP association between the initiating peer and the 212 responding peer. 214 Servers may place access control or other restrictions upon the use 215 of this operation. 217 As with any other extended operations, general LDAP security 218 considerations [RFC3377] apply. 220 4. IANA Considerations 222 This OID 1.3.6.1.4.1.453.23.1 to identify the LDAP Distributed 223 authentication extended operation. This OID was assigned by Isode 224 Limited, under its IANA-assigned private enterprise allocation 225 [PRIVATE], for use in this specification. 227 Registration of this protocol mechansism is requested [RFC3383]. 229 Internet DRAFT Distributed authentication in LDAP 12 July 2004 231 Subject: Request for LDAP Protocol Mechanism Registration 233 Object Identifier: 1.3.6.1.4.1.453.23.1 235 Description: Distributed bind operation 237 Person & email address to contact for further information: 238 Alexey Melnikov 240 Usage: Extended Operation 242 Specification: RFCxxxx 244 Author/Change Controller: IESG 246 Comments: none 248 5. References 250 5.1. Normative References 252 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 253 Requirement Levels", RFC 2119, March 1997 255 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 256 Specifications: ABNF", RFC 2234, November 1997. 258 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 259 Access Protocol (v3)", RFC 2251, December 1997. 261 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 262 Protocol (v3): Technical Specification", RFC 3377, September 2002. 264 [SASL] Melnikov, A. (editor), "Simple Authentication and Security 265 Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 267 [RFC2373] Hinden, R., Deering, S., "IP Version 6 Addressing 268 Architecture", RFC 2373, July 1998. 270 [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 271 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 273 [GSSAPI] Linn, J., "Generic Security Service Application Program 274 Interface, Version 2, Update 1", RFC 2743, January 2000. 276 Internet DRAFT Distributed authentication in LDAP 12 July 2004 278 5.2. Informative References 280 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 281 Considerations for the Lightweight Directory Access Protocol (LDAP)", 282 RFC 3383, September 2002. 284 [PRIVATE] IANA, "Private Enterprise Numbers", 285 http://www.iana.org/assignments/enterprise-numbers. 287 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 288 2001. 290 <<[LDAP-AUTHMECH] Harrison, R. (Editor), "LDAP: Authentication 291 Methods and Connection Level Security Mechanisms", work in progress, 292 draft-ietf-ldapbis-authmeth-xx.txt>> 294 6. Author's Address 296 Alexey Melnikov 297 Isode Limited 298 5 Castle Business Village 299 36 Station Road 300 Hampton, Middlesex 301 TW12 2BX, United Kingdom 303 Email: Alexey.Melnikov@isode.com 304 URI: http://www.melnikov.ca/ 306 Kurt D. Zeilenga 307 OpenLDAP Foundation 309 Email: Kurt@OpenLDAP.org 311 7. Acknowledgments 313 Thanks to Steve Kille and Chris Ridd for providing useful feedback 314 and suggestions. 316 8. IPR Disclosure Acknowledgement 318 By submitting this Internet-Draft, I certify that any applicable 319 patent or other IPR claims of which I am aware have been disclosed, 320 and any of which I become aware will be disclosed, in accordance with 322 Internet DRAFT Distributed authentication in LDAP 12 July 2004 324 RFC 3668. 326 9. Full Copyright Statement 328 Copyright (C) The Internet Society (2004). This document is subject 329 to the rights, licenses and restrictions contained in BCP 78, and 330 except as set forth therein, the authors retain all their rights. 332 This document and the information contained herein are provided on an 333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 335 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 336 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 337 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 340 Acknowledgement 342 Funding for the RFC Editor function is currently provided by the 343 Internet Society. 345 10. Intellectual Property 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at ietf- 367 ipr@ietf.org.