idnits 2.17.1 draft-bellovin-hpw-00.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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 4, 2012) is 4495 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bellovin 3 Internet-Draft Columbia University 4 Intended status: Standards Track January 4, 2012 5 Expires: July 7, 2012 7 Hashed Password Exchange 8 draft-bellovin-hpw-00.txt 10 Abstract 12 Many systems (e.g., cryptographic protocols relying on symmetric 13 cryptography) require that plaintext passwords be stored. Given how 14 often people reuse passwords on different systems, this poses a very 15 serious risk if a single machine is compromised. We propose a scheme 16 to derive passwords limited to a single machine from a typed 17 password, and explain how a protocol definition can specify this 18 scheme. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 7, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 Today, despite the lessons of more than 30 years [[cite Morris and 55 Thomson]], many systems store plaintext passwords. This is often 56 done for good reasons, such as authenticating cryptographic exchanges 57 or as a convenience to users with many passwords; see, for example, 58 the password store in many browsers or the Keychain in MacOS. That 59 said, this practice does pose a security risk to users, since their 60 passwords are in danger if the system is compromised. 62 The big problem is not compromise of the actual password used on that 63 system; while regrettable, it is inherent in the service definition. 64 Rather, the problem is that users tend to reuse passwords on 65 different systems. If a password is compromised on one machine, the 66 user is at risk on many different systems. Accordingly, we describe 67 a scheme for storing a single-site-only password, derived from the 68 user's typed password; a compromise of a service thus affects just 69 that service. 71 To accomplish this, we specify a "Hashed Password Exchange" standard, 72 or rather, a metastandard. Rather than specifying a precise way to 73 store and use hashed passwords, we give rules for specifying hashed 74 passwords for use in a given protocol or application. We take 75 advantage of the fact that unlike 1979, when users used very dumb 76 terminals to transmit passwords directly to the receiving 77 applications, most passwords these days are entered into user- 78 controlled software; these programs in turn transmit the passwords to 79 the verifying applications. There is thus intelligence on the user's 80 side; we will use this to irreversibly transform the entered password 81 into some other string. By the same token, the receiving system must 82 apply the same transform to the authenticator supplied at user 83 enrollment time or password change time. Because two independent 84 pieces of software must apply the same transformation, the algorithm 85 must be precisely specified in standards documents. 87 1.1. Requirements Notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Definitions and Goals 95 We use the following definitions: 97 Username An arbitrary string, the syntax of which is application- 98 dependent, employed by both the user and the verifying system to 99 uniquely identify a given user. 101 Entered Password The authenticator typed by the user to his or her 102 own software. The usual quality rules (length, special 103 characters, etc.) can be applied; that is out of the scope of this 104 standard. 106 Effective Password The actual, over-the-wire, string transmitted by 107 the user's software. 109 Service A particular application on a particular machine or cluster 110 of machines appearing as a single machine 112 Service URI A URI [RFC3986] for which this effective password should 113 be valid. Only the scheme name, userinfo, and host name portions 114 are discussed here; use of path information is protocol-dependent. 115 In the userinfo field, only the username is used. An example is 116 given below. 118 Our scheme has the following goals: 120 1. No two users of a given service should have the same effecive 121 password, even if the entered passwords are the same. 123 2. No two effective passwords for the same user should be the same 124 for different services, even if the entered passwords are the 125 same. 127 3. It should be infeasible to invert the hashing function to 128 retrieve the entered password from an effective password and 129 service URI. 131 4. It should be computationally expensive to mount dictionary 132 attacks on compromised effective passwords. 134 3. The Hashed Password Scheme 136 Fundamentally, we calculate the effective password by iterating HMAC 137 [RFC2104], using the entered password as the key and the service URI 138 as the data. This meets all four of our goals: 140 1. Since the username is part of the service URI, different users 141 will have different URIs, and hence different effective 142 passwords. 144 2. Since the hostname is part of the URI, different services for any 145 given user will have different URIs, and hence different 146 effective passwords. 148 3. For any reasonable underlying hash function, it is believed to be 149 infeasible to invert HMAC; see [RFC2104] for details. 151 4. By iterating a sufficient number of times, dictionary attacks can 152 be made arbitrarily expensive. 154 We do not use a salt in this scheme. The primary purposes of a salt 155 are to achieve our first and second goals, which we achieve in other 156 ways. A salt also protects against precomputation of possible 157 passwords of known users in anticipation of a later password file 158 compromise; however, since the salt must be used in calculating the 159 effective password, it would have to be known to the user as well as 160 the server, and users typically have multiple devices on which they 161 enter passwords. Using a salt would require that users know it and 162 reenter it, which we regard as infeasible and of limited benefit. 164 Usernames and the hostname portions of service URIs must be 165 canonicalized before applying HMAC. Legal characters in a username 166 are upper and lower case US-ASCII letters, period, hyphen, 167 underscore, and digits. All other characters MUST be percent- 168 encoded, per section 2.1 of [RFC3986]. Hostnames MUST be 169 canonicalized per [RFC5890][RFC5891] and converted to lower case. 170 How usernames and hostnames are entered is application- and 171 implementation-dependent, and not part of this specification. The 172 hostname used is either the string users type or unambiguously 173 derivable from it per specified rules. 175 The URI scheme name is given by the protocol specification and MUST 176 NOT be entered directly by the user. 178 The iteration count is protocol- and use-dependent, and given in the 179 protocol specification. 181 The effective password, then, is calculated by iterating HMAC some 182 number of times over the message 184 scheme://username@hostname 186 with the entered password as the key. 188 3.1. Examples 190 ipsec://someuser@gw.example.net 191 imap://someuser@mail.example.com 192 submission://someuser@mail.example.com 194 Note that although someuser can specify the same entered password for 195 both 'imap' and 'submission' on mail.example.com, the effective 196 passwords will be different. 198 4. Specifying Hashed Password Exchange 200 The following elements must be in any protocol specification that 201 uses Hashed Password Exchange. 203 o The scheme name MUST be specified. Generally, this will be taken 204 from the IANA name assigned to the port, but this is not required. 205 Thus, a mail submission URI (TCP port 587) might use the scheme 206 name "submission". 208 o The rules for deriving the hostname from what users enter MUST be 209 specified. They may be as simple as "use the name the user 210 specifies, e.g., imap.example.com", or they may account for common 211 alternatives: "If the specified host name does not begin with 212 'www.', prepend it; thus, both 'example.com' and 'www.example.com' 213 would use the hostname 'www.example.com' in forming the URI. 215 o The iteration count MUST be specified. The value -- typically in 216 the hundreds of thousands with today's technology -- SHOULD be 217 different for different services, and MAY be adjusted based on the 218 platforms on which the calculations are typically done. Note that 219 the iteration is done at password change time rather than run- 220 time, so expense is not a major concern. (Just how long the 221 iterations should take will depend on the protocol designers' 222 understanding of likely platforms and usage patterns. Something 223 that will be run exclusively on fast devices and with stored 224 hashed passwords should use a higher count; something where run- 225 time user password entry on a slow device is considered likely 226 should use a lower count.) 228 o The rules, if any, for canonicalizing the entered password MUST be 229 specified. It is perfectly acceptable to accept an arbitrary 230 octet string here, but that is not required. 232 o The hash function to be used with HMAC MUST be specified. MD5 233 [RFC1321] is more than sufficient; however, the tradeoff is likely 234 to be between what code is likely to be available in 235 implenetations versus the iteration count. SHA-512 [RFC6234] is 236 much slower than MD5, but since the goal is constant time, this 237 matters very little; thus, MD5 would have a higher iteration count 238 than SHA-512 would for the same protocol. 240 o The encoding rules for sending the effective password over the 241 wire. The output of HMAC is an arbitrary byte string. Given the 242 length of typical HMAC output and the infrequency with which they 243 are sent, transmission efficiency is not a major concern, so a 244 simple hexadecimal encoding is fine. Implementations MAY specify 245 truncation; however, they SHOULD NOT use effective passwords 246 shorter than 16 octets before encoding. 248 o If the protocol permits negotiation of authentication methods, a 249 separate code point MUST be assigned to this scheme. 251 How passwords are changed -- that is, how new effective passwords are 252 supplied to the verifying machine -- is beyond the scope of this 253 specification. If the entered password is sent directly at password 254 change time, quality checks can be enforced; however, this exposes 255 entered passwords to attacks who have compromised the verifying 256 machine. This is not a major risk, since the rate of password change 257 is low. Conversely, client-side code (e.g., Javascript) can make 258 advisory recommendations on password strength; while the server 259 cannot enforce this, since it will see only effective passwords, very 260 few users will have the will and the skill to override this. 262 If effective passwords are used only for the usual password 263 verification and not for cryptographic purposes, they should be 264 treated with the care used for ordinary password, i.e., salted, 265 hashed, etc. There is little need for extra iterations, though, 266 since the iteration used in calculating them already provides strong 267 protection against dictionary attacks, and it is unlikely that the 268 extra server-side iterations will be significantly larger than the 269 iterations already performed to comply with this specification. 271 5. Security Considerations 273 To be written. 275 6. Normative References 277 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 278 April 1992. 280 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 281 Hashing for Message Authentication", RFC 2104, 282 February 1997. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 288 Resource Identifier (URI): Generic Syntax", STD 66, 289 RFC 3986, January 2005. 291 [RFC5890] Klensin, J., "Internationalized Domain Names for 292 Applications (IDNA): Definitions and Document Framework", 293 RFC 5890, August 2010. 295 [RFC5891] Klensin, J., "Internationalized Domain Names in 296 Applications (IDNA): Protocol", RFC 5891, August 2010. 298 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 299 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 301 Author's Address 303 S.M. Bellovin 304 Columbia University 305 1214 Amsterdam Avenue 306 MC 0401 307 New York, NY 10027 308 US 310 Phone: +1 212 939 7149 311 Email: bellovin@acm.org