idnits 2.17.1 draft-ietf-ldapext-authmeth-00.txt: ** The Abstract section seems to be numbered 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-25) 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. == 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 Introduction section. ** 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.) ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (November 7, 1997) is 9666 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 section? '1' on line 181 looks like a reference -- Missing reference section? '2' on line 185 looks like a reference -- Missing reference section? '3' on line 188 looks like a reference -- Missing reference section? '4' on line 191 looks like a reference -- Missing reference section? '5' on line 194 looks like a reference -- Missing reference section? '6' on line 198 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET DRAFT Critical Angle Inc. 3 Expire in six months November 7, 1997 5 Authentication Methods for LDAP 6 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 2. Abstract 28 LDAP version 3 [1] uses the SASL [2] framework for exchanging 29 authentication information between the client and server. This 30 document specifies particular SASL mechanisms which are recommended 31 for use in the LDAP protocol. Two means of authentication are 32 provided, based on password hashing and public/private keys. 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 36 this document are to be interpreted as described in RFC 2119 [3]. 38 3. Anonymous authentication 40 Anonymous authentication is suitable for users which do not intend to 41 modify directory entries and do not require access to protected 42 attributes or entries. 44 An LDAP client which has not successfully completed a bind operation 45 on a connection is anonymously authenticated. 47 An LDAP client may also specify anonymous authentication in a bind 48 request by using a zero-length OCTET STRING with the simple 49 authentication choice. 51 As LDAP includes a native anonymous authentication mechanism already 52 widely used, the "ANONYMOUS" SASL mechanism is not used with LDAP. 54 4. Password-based authentication 56 A user who has a directory entry containing a userPassword attribute 57 may authenticate to the directory by performing a protected password 58 bind sequence based on the CRAM-MD5 mechanism [4]. 60 An LDAP client may determine whether the server supports this 61 mechanism by performing a search request on the root DSE, requesting 62 the supportedSASLMechanisms attribute, and checking whether the 63 string "CRAM-MD5" is present as a value of this attribute. 65 In the first stage of authentication, the client sends a bind 66 request in which the version number is 3, the name field is the name 67 of the user's entry, the authentication choice is sasl, the sasl 68 mechanism name is "CRAM-MD5", and the credentials are absent. The 69 client then waits for a response from the server to this request. 71 The server shall generate a challenge and return a bind response in 72 which the resultCode is saslBindInProgress, and the serverSaslCreds 73 field is present. The contents of the serverSaslCreds string is 74 the challenge, which is not base64 encoded. An example challenge is 75 "<1896.697170952@postoffice.reston.mci.net>". Note that in this 76 stage of the mechanism, the server need not access the user's entry. 77 The server will save the challenge internally, associated with the 78 connection, until the next stage of the bind operation is completed. 80 Upon receipt of the challenge, the client will generate the response 81 digest value, which is a string of 32 hexadecimal digits. An 82 example digest derived from the above challenge and the password 83 "tanstaaftanstaaf" is "b913a602c7eda7a495b4e6e7334d3890". The client 84 will send a bind request, with a different message id, in which the 85 version number is 3, the name field is the name of the user's entry, 86 the authentication choice is sasl, the sasl mechanism name is 87 "CRAM-MD5", and the credentials field contains the digest string. 88 The client then will waits for another response from the server. 90 The server will then, for each value of the userPassword attribute 91 in the named user's entry, generate the digest value itself, and 92 compare the result with the client's presented digest. If there is 93 a match, then the server will respond with resultCode success, 94 otherwise the server will respond with resultCode invalidCredentials. 95 The serverSaslCreds field will be absent. 97 If the client does not complete the SASL negotiation, the server 98 MUST delete the challenge from memory, as challenge strings MUST 99 never be used twice. A client MUST NOT send more than one bind 100 request containing response digest values in which the same challenge 101 string was used. If a client wishes to change authentication, it 102 MUST start from the beginning and request a new challenge. 104 4.1. "simple" authentication choice 106 The LDAP "simple" authentication choice is present for compatibility 107 with existing applications. It is suitable for intranet environments 108 where the underlying network service is secured against 109 eavesdropping. It is not suitable for authentication on the Internet 110 where there is no network or transport layer confidentiality, or the 111 underlying security service does not provide sufficient protection 112 against decryption by eavesdroppers (e.g. 40 bit DES). 114 The "PLAIN" SASL mechanism is not used, as LDAP already provides 115 equivalent functionality. 117 5. Certificate-based authentication 119 A user who has a public/private key pair in which the public key has 120 been signed by a Certification Authority may use this key pair to 121 authenticate to the directory server. The user's certificate 122 subject field must be the name of the user's directory entry, and 123 the Certification Authority must be sufficiently trusted by the 124 directory server to have issued the certificate. 126 The client will use the Start TLS operation [5] to negotiate the 127 use of TLS security [6] on the connection to the LDAP server. The 128 client need not have bound to the directory beforehand. 130 In the TLS negotiation, the server MUST request a certificate. The 131 client will provide its certificate to the server, and MUST perform 132 a private key-based encryption, proving it has it private key 133 associated with the certificate. 135 The server MUST verify that the client's certificate is valid, 136 issued by a known CA, and not on the CA's current revocation list. 138 Following the successful completion of TLS negotiation, the client 139 will send an LDAP bind request. The version number is 3, the name 140 field is either the empty string or the name of the user's entry, 141 the authentication choice is sasl, the sasl mechanism name is 142 "EXTERNAL", and the credentials field is empty. The client will 143 then wait for the response from the server. 145 The server will verify that the name field of the bind request, if 146 not empty, matches the subject field of the client's certificate, 147 and that there is an entry in the directory identified by this name 148 of an object class strongAuthenticationUser. If this is correct, 149 the server will respond with the resultCode success, otherwise it 150 will respond with the result code invalidCredentials. 152 If the server receives a bind request with the EXTERNAL sasl 153 mechanism name and TLS has not been negotiated, it SHOULD return a 154 resultCode of invalidCredentials. 156 6. Limited Use 158 The following SASL-based authentication methods are not considered 159 in this document: KERBEROS_V4, GSSAPI and SKEY. 161 7. Security Considerations 163 Servers are encouraged to prevent DIT modifications by anonymous 164 users. Servers may also wish to minimize denial of service attacks 165 by timing out idle connections, and returning the unwillingToPerform 166 result code rather than performing computationally expensive 167 operations requested by unauthorized clients. 169 A connection on which the client has not performed the Start TLS 170 operation to initiate connection integrity and encryption services is 171 subject to man-in-the-middle attacks to view and modify information 172 in transit. 174 Additional security considerations relating to the CRAM-MD5 175 mechanism can be found in [4], and security considerations relating 176 to the EXTERNAL mechanism to negotiate TLS can be found in [2], [5] 177 and [6]. 179 8. Bibliography 181 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 182 Protocol (v3)", Nov. 1997, INTERNET DRAFT 183 . 185 [2] J. Myers, "Simple Authentication and Security Layer (SASL)", 186 Oct. 1997, RFC 2222. 188 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement 189 Levels", RFC 2119. 191 [4] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize 192 Extension for Simple Challenge/Response", Sep. 1997, RFC 2195. 194 [5] J. Hodges, RL Morgan, M. Wahl, "LDAPv3 Extension for Transport 195 Layer Security", Aug. 1997, INTERNET DRAFT 196 . 198 [6] T. Diers, C. Allen, "The TLS Protocol Version 1.0", Oct. 1997, 199 INTERNET DRAFT . 201 9. Authors Address 203 Mark Wahl 204 Critical Angle Inc. 205 4815 West Braker Lane #502-385 206 Austin, TX 78759 USA 208 EMail: M.Wahl@critical-angle.com