idnits 2.17.1 draft-stroeder-hashed-userpassword-values-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2307, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2307, updated by this document, for RFC5378 checks: 1997-09-12) -- 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 (March 13, 2013) is 4056 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hoffman-schneier-4270bis' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC4270' is defined on line 296, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-behera-ldap-password-policy-10 == Outdated reference: A later version (-02) exists of draft-hoffman-schneier-4270bis-01 -- Obsolete informational reference (is this intentional?): RFC 2829 (Obsoleted by RFC 4510, RFC 4513) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Stroeder 3 Internet-Draft Independent consultant 4 Updates: 2307 (if approved) March 13, 2013 5 Intended status: Informational 6 Expires: September 14, 2013 8 Lightweight Directory Access Protocol (LDAP): 9 Hashed Attribute values for 'userPassword' 10 draft-stroeder-hashed-userpassword-values-01 12 Abstract 14 This document describes the widely used syntax for storing hashed 15 passwords in LDAP attribute 'userPassword'. Furthermore it points 16 out some of the deficiencies of the approach. Its purpose is solely 17 to document current practice, it does not define a new standard. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 14, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Syntax for attribute 'userPassword' . . . . . . . . . . . . . 3 55 3. Implementation Issues . . . . . . . . . . . . . . . . . . . . 4 56 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 This document does not define a new standard. Its purpose is solely 67 to correctly document what is widely implemented in LDAP servers and 68 clients to avoid interop issues in case implementors have to support 69 old legacy systems using this scheme. 71 Strictly speaking the 'userPassword' attribute type, intended to be 72 used to support the LDAP [RFC4510] "simple" bind operation, was meant 73 to only store clear text passwords [RFC4519]. 75 Although [RFC3112] defined a more versatile password attribute 76 'authPassword' for storing hashed passwords this was not widely 77 implemented in server and client implementations. Instead current 78 LDAP deployments still rely on the password hashing scheme for 79 attribute 'userPassword' introduced in [RFC2307] especially since 80 this attribute type is directly used in various object classes. 82 The specification in [RFC2307] is missing some formal aspects 83 potentially leading to interop issues. Furthermore new hash 84 algorithms are used today by various implementors which were not 85 mentioned in [RFC2307]. 87 Therefore this document also updates [RFC2307] by fully specifying 88 how to store hashed password values in attribute 'userPassword' 89 optionally using the SHA-2 hash algorithms [FIPS-180-4]. For this it 90 focuses on documenting already implemented server and client 91 implementations. The password hashing scheme {crypt} was left out 92 from the syntax definition because there are many platform-specific 93 variants of possible values. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 This document is being discussed on the ldapext@ietf.org mailing 100 list. 102 2. Syntax for attribute 'userPassword' 104 userPassword values MUST be represented by following syntax: 106 userpasswordvalue = cleartext-password / prefix b64-hashandsalt 108 prefix = "{" scheme "}" 109 scheme = %x30-39 / %x41-5A / %x61-7a / %x2D-2F / %x5F 110 ;0-9, A-Z, a-z, "-", ".", "/", or "_" 112 b64-hashandsalt = 114 hashandsalt = password-hash salt 116 password-hash = 118 cleartext-password = %x00-FF 120 salt = %x00-FF 122 Field salt SHALL be treated as a randomely chosen sequence of bytes. 123 The length of the salt SHOULD be at least 64 bits but other salt 124 length MAY be recommended for specific hash algorithms. 125 Implementations MUST be prepared of handling field salt of arbitrary 126 length. salt MUST be empty for non-salted hashing schemes. 128 The field hashandsalt is generated by concatening the field password- 129 hash and the salt. The field password-hash is generated by 130 calculating the digest over the concatenation of password followed by 131 salt. 133 b64-hashandsalt is generated by encoding hashandsalt according to the 134 base64 algorithm as specified in [RFC4648]. 136 The field scheme MUST be treated case-insensitive by all server and 137 client implementations. Applications SHALL handle prefix "x-" in 138 scheme just like any other scheme value without this prefix 139 [RFC6648]. Other specifications MAY update this document by defining 140 other values for scheme. 142 +-----------+----------------------+---------------------+ 143 | prefix | Description | Algorithm reference | 144 +-----------+----------------------+---------------------+ 145 | {MD5} | MD-5 without salt | [RFC1321] | 146 | {SMD5} | salted MD-5 | [RFC1321] | 147 | {SHA} | SHA-1 without salt | [FIPS-180-4] | 148 | {SSHA} | salted SHA-1 | [FIPS-180-4] | 149 | {SHA256} | SHA-256 without salt | [FIPS-180-4] | 150 | {SSHA256} | salted SHA-256 | [FIPS-180-4] | 151 | {SHA384} | SHA-384 without salt | [FIPS-180-4] | 152 | {SSHA384} | salted SHA-384 | [FIPS-180-4] | 153 | {SHA512} | SHA-512 without salt | [FIPS-180-4] | 154 | {SSHA512} | salted SHA-512 | [FIPS-180-4] | 155 +-----------+----------------------+---------------------+ 157 Table 1: Currently used hash schemes 159 3. Implementation Issues 161 All implementations SHOULD prepare textual strings used as field 162 password like described for clear-text storage in section 2.41 in 163 [RFC4519] before deriving a hash value from them. It is up to the 164 implementation to determine what a textual password is. 166 Hashed 'userPassword' values are only suitable for directly comparing 167 it to a clear-text password. They SHOULD NOT be used in challenge- 168 response authentication schemes. 170 It is clear from the syntax specification that distinguishing clear- 171 text passwords and hashed passwords is somewhat ambigous which is a 172 well-known deficiency of this approach. Therefore implementing 173 [RFC3112] is RECOMMENDED if a better solution is strictly required. 175 Implementations SHALL first check whether a value stored in attribute 176 'userPassword' adheres to the syntax specified above. Syntax 177 checking SHALL be implemented by checking hash and optional salt 178 following the algorithm-specific rules. Any value which do not 179 adhere to this syntax MAY be treated as clear-text password by the 180 DSA when processing a LDAP simple bind request or LDAP compare 181 request. 183 Servers MAY provide local configuration items to limit the set of 184 hash schemes to be processed and for completely disabling use of 185 clear-text passwords in attribute 'userPassword'. 187 4. Acknowledgements 189 The syntax definition for 'userPassword' values in this document is 190 based on and supersedes the specification in section 5.3 of [RFC2307] 191 by L. Howard. 193 Some basics of the formal specification and security considerations 194 are based on text in [RFC3112] by K. Zeilenga. 196 5. IANA Considerations 198 There are no identifiers defined herein to be reserved by IANA. 200 6. Security Considerations 202 This document describes how authentication information may be stored 203 in a directory. Authentication information MUST be adequately 204 protected as unintended disclosure will allow attackers to gain 205 immediate access to the directory as described by [RFC2829]. 207 Hashed values in attribute 'userPassword' SHOULD be protected as if 208 they were clear text passwords because they are subject to dictionary 209 or other attacks and flaws may be discovered in the hashing algorithm 210 or with a particular implementation of the algorithm. 212 Especially it is RECOMMENDED to avoid using hashing schemes based on 213 MD-5 because of known weaknesses of this digest algorithm [RFC6151]. 215 Applications SHOULD NOT use the non-salted password hash schemes and 216 SHOULD use a sufficiently long salt value. 218 When values are transferred, privacy protections, such as IPSEC or 219 TLS, SHOULD be in place. 221 Clients SHOULD use stronger authentication mechanisms like defined in 222 [RFC5802]. 224 Servers SHOULD use stronger credential storage mechanisms like 225 defined in [RFC5803]. 227 Some password schemes may require CPU intensive operations. Servers 228 SHOULD take appropriate measures to protect against Denial of Service 229 attacks. 231 Using 'userPassword' attribute type description as defined in 232 [RFC4519] does not restrict an authentication identity to a single 233 password. An attacker who gains write access to this attribute may 234 store additional values without disabling the user's true 235 password(s). If a server supports defining additional local 236 constraints to limit the count of attribute values it is RECOMMENDED 237 to define such a constraint for 'userPassword' values to be limited 238 to one without having to change the standard schema. 240 Use of policy aware clients and servers is RECOMMENDED (see example 241 in [I-D.behera-ldap-password-policy]). 243 The level of protection offered against various attacks differ from 244 scheme to scheme. It is RECOMMENDED that servers support scheme 245 selection as a configuration item. This allows for a scheme to be 246 easily disabled if a significant security flaw is discovered. 248 7. References 250 7.1. Normative References 252 [FIPS-180-4] 253 National Institute of Standards and Technology (NIST) , 254 "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012, 255 . 258 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 259 April 1992. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 265 (LDAP): Technical Specification Road Map", RFC 4510, June 266 2006. 268 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 269 (LDAP): Schema for User Applications", RFC 4519, June 270 2006. 272 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 273 Encodings", RFC 4648, October 2006. 275 7.2. Informative References 277 [I-D.behera-ldap-password-policy] 278 Sermersheim, J., Poitou, L., and H. Chu, "Password Policy 279 for LDAP Directories", draft-behera-ldap-password- 280 policy-10 (work in progress), August 2009. 282 [I-D.hoffman-schneier-4270bis] 283 Hoffman, P. and B. Schneier, "Attacks on Cryptographic 284 Hashes in Internet Protocols", draft-hoffman-schneier- 285 4270bis-01 (work in progress), November 2012. 287 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 288 Information Service", RFC 2307, March 1998. 290 [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, 291 "Authentication Methods for LDAP", RFC 2829, May 2000. 293 [RFC3112] Zeilenga, K., "LDAP Authentication Password Schema", RFC 294 3112, May 2001. 296 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 297 Hashes in Internet Protocols", RFC 4270, November 2005. 299 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 300 "Salted Challenge Response Authentication Mechanism 301 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 303 [RFC5803] Melnikov, A., "Lightweight Directory Access Protocol 304 (LDAP) Schema for Storing Salted Challenge Response 305 Authentication Mechanism (SCRAM) Secrets", RFC 5803, July 306 2010. 308 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 309 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 310 RFC 6151, March 2011. 312 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 313 "Deprecating the "X-" Prefix and Similar Constructs in 314 Application Protocols", BCP 178, RFC 6648, June 2012. 316 Author's Address 318 Michael Stroeder 319 Independent consultant 320 Klauprechtstr. 11 321 Karlsruhe 76137 322 DE 324 Email: michael@stroeder.com 325 URI: http://www.stroeder.com