idnits 2.17.1 draft-wu-srp-auth-01.txt: 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-27) 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 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 181: '... The client MUST abort authenticatio...' RFC 2119 keyword, line 183: '... The host MUST abort the authenticat...' RFC 2119 keyword, line 184: '... zero. The host MUST send B after rec...' RFC 2119 keyword, line 198: '... server MUST abort and signal an err...' RFC 2119 keyword, line 205: '...ctly, the server MUST respond with its...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1998) is 9568 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) -- Looks like a reference, but probably isn't: '0' on line 253 -- Looks like a reference, but probably isn't: '2' on line 242 -- Looks like a reference, but probably isn't: '4' on line 242 -- Looks like a reference, but probably isn't: '1' on line 253 -- Looks like a reference, but probably isn't: '3' on line 243 -- Looks like a reference, but probably isn't: '5' on line 243 -- Looks like a reference, but probably isn't: '19' on line 253 ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 1704 ** Downref: Normative reference to an Informational RFC: RFC 1760 ** Obsolete normative reference: RFC 2095 (Obsoleted by RFC 2195) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP' Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft T. Wu 2 draft-wu-srp-auth-01.txt Stanford University 3 Expires 31 August 1998 February 1998 5 The SRP Authentication and Key Exchange System 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 "work in progress." 20 To view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 24 Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 This document describes a cryptographically strong network 29 authentication mechanism known as the Secure Remote Password (SRP) 30 protocol. This mechanism is suitable for negotiating secure 31 connections using a user-supplied password, while eliminating the 32 security problems traditionally associated with reusable passwords. 33 This system also performs a secure key exchange in the process of 34 authentication, allowing security layers (privacy and/or integrity 35 protection) to be enabled during the session. Trusted key servers 36 and certificate infrastructures are not required, and clients are 37 not required to store or manage any long-term keys. SRP offers 38 both security and deployment advantages over existing challenge- 39 response techniques, making it an ideal drop-in replacement where 40 secure password authentication is needed. 42 1. Introduction 44 The lack of a secure authentication mechanism that is also easy 45 to use has been a long-standing problem with the vast majority of 46 Internet protocols currently in use. The problem is two-fold: 47 Users like to use passwords that they can remember, but most 48 password-based authentication systems offer little protection 49 against even passive attackers, especially if weak and easily- 50 guessed passwords are used. 52 Eavesdropping on a TCP/IP network can be carried out very easily 53 and very effectively against protocols that transmit passwords in 54 the clear. Even so-called "challenge-response" techniques like 55 the one described in [RFC 2095] and [RFC 1760], which are designed 56 to defeat simple sniffing attacks, can be compromised by what is 57 known as a "dictionary attack". This occurs when an attacker 58 captures the messages exchanged during a legitimate run of the 59 protocol and uses that information to verify a series of guessed 60 passwords taken from a precompiled "dictionary" of common passwords. 61 This works because users often choose simple, easy-to-remember 62 passwords, which invariably are also easy to guess. 64 Many existing mechanisms also require the password database on the 65 host to be kept secret because the password P or some private hash 66 h(P) is stored there and would compromise security if revealed. 67 That approach often degenerates into "security through obscurity" 68 and goes against the UNIX convention of keeping a "public" password 69 file whose contents can be revealed without destroying system security. 71 SRP meets the strictest requirements laid down in [RFC 1704] for a 72 non-disclosing authentication protocol. It offers complete protection 73 against both passive and active attacks, and accomplishes this 74 efficiently using a single Diffie-Hellman-style round of computation, 75 making it feasible to use in both interactive and non-interactive 76 authentication for a wide range of Internet protocols. Since it 77 retains its security when used with low-entropy passwords, it can 78 be seamlessly integrated into existing user applications. 80 2. Conventions and Terminology 82 The protocol described by this document is sometimes referred to 83 as "SRP-3" for the sake of clarity. This particular protocol is 84 described in [SRP] and is believed to have very good logical 85 and cryptographic resistance to both eavesdropping and active 86 attacks. 88 This document does not attempt to describe SRP in the context 89 of any particular Internet protocol; instead it describes an 90 abstract protocol that can be easily fitted to a particular 91 application. For example, the specific format of messages 92 (including padding) is not specified. Those issues have been 93 left to the protocol implementor to decide. 95 The one implementation issue worth specifying here is the 96 mapping between strings and integers. Internet protocols are 97 byte-oriented, while SRP performs algebraic operations on its 98 messages, so it is logical to define at least one method 99 by which integers can be converted into a string of bytes and 100 vice versa. 102 An n-byte string S can be converted to an integer as follows: 104 i = S[n-1] + 256 * S[n-2] + 256^2 * S[n-3] + ... + 256^(n-1) * S[0] 106 where i is the integer and S[x] is the value of the x'th byte 107 of S. In human terms, the string of bytes is the integer 108 expressed in base 256, with the most significant digit first. 109 When converting back to a string, S[0] must be non-zero (padding 110 is considered to be a separate, independent process). This 111 conversion method is suitable for file storage, in-memory 112 representation, and network transmission of large integer 113 values. Unless otherwise specified, this mapping will be 114 assumed. 116 If implementations require padding a string that represents an 117 integer value, it is recommended that they use zero bytes and 118 add them to the beginning of the string. The conversion back to 119 integer automatically discards leading zero bytes, making this 120 padding scheme less prone to error. 122 The SHA hash function, when used in this document, refers to the 123 SHA-1 message digest algorithm described in [SHA1]. 125 3. The SRP-SHA1 mechanism 127 This section describes an implementation of the SRP authentication 128 and key-exchange protocol that employs the SHA hash function to 129 generate session keys and authentication proofs. 131 The host stores user passwords as triplets of the form 133 { , , } 135 Password entries are generated as follows: 137 = random() 138 x = SHA( | SHA( | ":" | )) 139 = v = g^x % N 141 The | symbol indicates string concatenation, the ^ operator is the 142 exponentiation operation, and the % operator is the integer remainder 143 operation. Most implementations perform the exponentiation and 144 remainder in a single stage to avoid generating unwieldy intermediate 145 results. Note that the 160-bit output of SHA is implicitly converted 146 to an integer before it is operated upon. 148 Authentication is generally initiated by the client. 150 Client Host 151 -------- ------ 152 U = --> 153 <-- s = 155 Upon identifying himself to the host, the client will receive 156 the salt stored on the host under his username. 158 a = random() 159 A = g^a % N --> 160 v = 161 b = random() 162 <-- B = (v + g^b) % N 164 p = 165 x = SHA(s | SHA(U | ":" | p)) 167 S = (B - g^x) ^ (a + u * x) % N S = (A * v^u) ^ b % N 168 K = SHA_Interleave(S) K = SHA_Interleave(S) 169 (this function is described 170 in the next section) 172 The client generates a random number, raises g to that power modulo 173 the field prime, and sends the result to the host. The host 174 does the same thing and also adds the public verifier before 175 sending it to the client. Both sides then construct the shared 176 session key based on the respective formulae. 178 The parameter u is a 32-bit unsigned integer which takes its 179 value from the first 32 bits of the SHA1 hash of B, MSB first. 181 The client MUST abort authentication if B % N is zero. 183 The host MUST abort the authentication attempt if A % N is 184 zero. The host MUST send B after receiving A from the client, 185 never before. 187 At this point, the client and server should have a common 188 session key that is secure (i.e. not known to an outside party). 189 To finish authentication, they must prove to each other that 190 their keys are identical. 192 M = H(H(N) XOR H(g) | H(U) | s | A | B | K) 193 --> 194 <-- H(A | M | K) 196 The server will calculate M using its own K and compare 197 it against the client's response. If they do not match, the 198 server MUST abort and signal an error before it attempts to 199 answer the client's challenge. Not doing so could compromise the 200 security of the user's password. 202 If the server receives a correct response, it issues its own proof 203 to the client. The client will compute the expected response using 204 its own K to verify the authenticity of the server. If the client 205 responded correctly, the server MUST respond with its hash value. 207 The transactions in this protocol description do not necessarily 208 have a one-to-one correspondence with actual protocol messages. 209 This description is only intended to illustrate the relationships 210 between the different parameters and how they are computed. 211 It is possible, for example, for an implementation of the SRP3-SHA1 212 mechanism to consolidate some of the flows as follows: 214 Client Host 215 -------- ------ 216 U, A --> 217 <-- s, B 218 H(H(N) XOR H(g) | H(U) | s | A | B | K) 219 --> 220 <-- H(A | M | K) 222 The values of N and g used in this protocol must be agreed upon 223 by the two parties in question. They can be set in advance, or 224 the host can supply them to the client. In the latter case, the 225 host should send the parameters in the first message along with 226 the salt. For maximum security, N should be a safe prime 227 (i.e. a number of the form N = 2q + 1, where q is also prime). 228 Also, g should be a generator modulo N (see [SRP] for details), 229 which means that for any X where 0 < X < N, there exists a value 230 x for which g^x % N == X. 232 3.1. Interleaved SHA 234 The SHA_Interleave function used in SRP-SHA1 is used to generate 235 a session key that is twice as long as the 160-bit output of SHA1. 236 To compute this function, remove all leading zero bytes from the 237 input. If the length of the resulting string is odd, also remove 238 the first byte. Call the resulting string T. Extract the 239 even-numbered bytes into a string E and the odd-numbered bytes 240 into a string F, i.e. 242 E = T[0] | T[2] | T[4] | ... 243 F = T[1] | T[3] | T[5] | ... 245 Both E and F should be exactly half the length of T. Hash each 246 one with regular SHA1, i.e. 248 G = SHA(E) 249 H = SHA(F) 251 Interleave the two hashes back together to form the output, i.e. 253 result = G[0] | H[0] | G[1] | H[1] | ... | G[19] | H[19] 255 The result will be 40 bytes (320 bits) long. 257 3.2. Other Hash Algorithms 259 SRP can be used with hash functions other than SHA. 260 If the hash function produces an output of a different length 261 than SHA (20 bytes), it may change the length of some of the 262 messages in the protocol, but the fundamental operation will 263 be unaffected. 265 Earlier versions of the SRP mechanism used the MD5 hash function, 266 described in [RFC 1321]. 268 Any hash function used with SRP should produce an output of at 269 least 16 bytes and have the property that small changes in the 270 input cause significant nonlinear changes in the output. [SRP] 271 covers these issues in more depth. 273 4. Security Considerations 275 This entire draft discusses an authentication and key-exchange 276 system that protects passwords and exchanges keys across an 277 untrusted network. This system improves security by eliminating 278 the need to send cleartext passwords over the network and by 279 enabling encryption through its secure key-exchange mechanism. 281 SRP has been designed not only to counter the threat of casual 282 password-sniffing, but also to prevent a determined attacker 283 equipped with a dictionary of passwords from guessing at 284 passwords using captured network traffic. The SRP protocol 285 itself also resists active network attacks, and implementations 286 can use the securely exchanged keys to protect the session against 287 hijacking and provide confidentiality. 289 SRP also has the added advantage of permitting the host to store 290 passwords in a form that is not directly useful to an attacker. 291 Even if the host's password database were publicly revealed, 292 the attacker would still need an expensive dictionary search to 293 obtain any passwords. The exponential computation required to 294 validate a guess in this case is much more time-consuming than 295 the hash currently used by most UNIX systems. Hosts are still 296 advised, though, to try their best to keep their password files 297 secure. 299 5. References 301 [RFC 1321] R. L. Rivest, The MD5 Message-Digest Algorithm, "Request 302 For Comments (RFC) 1321", MIT and RSA Data Security, Inc., 303 April 1992 305 [RFC 1704] N. Haller and R. Atkinson, On Internet Authentication, 306 "Request for Comments (RFC) 1704", NRL, October 1994 308 [RFC 1760] N. Haller, The S/Key One-Time Password System, "Request 309 For Comments (RFC) 1760", Bellcore, Feburary 1995 311 [RFC 2095] J. Klensin, R. Catoe, P. Krumviede, IMAP/POP AUTHorize 312 Extension for Simple Challenge/Response, "Request For 313 Comments (RFC) 2095", MCI, January 1997 315 [SHA1] National Institute of Standards and Technology (NIST), 316 "Announcing the Secure Hash Standard", FIPS 180-1, U.S. 317 Department of Commerce, April 1995. 319 [SRP] T. Wu, "The Secure Remote Password Protocol", Proceedings 320 of the 1998 Internet Society Symposium on Network and 321 Distributed Systems Security, San Diego, March 1998. 323 6. Author's Address 325 Thomas Wu 326 Stanford University 327 Stanford, CA 94305 328 Email: tjw@cs.Stanford.EDU