idnits 2.17.00 (12 Aug 2021) /tmp/idnits38812/draft-yusef-httpauth-srp-scheme-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2016) is 2308 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: 'HTTP-P7' is mentioned on line 84, but not defined == Missing Reference: 'RFC3261' is mentioned on line 84, but not defined == Missing Reference: 'RFC6749' is mentioned on line 85, but not defined == Missing Reference: 'RFC5389' is mentioned on line 85, but not defined ** Obsolete undefined reference: RFC 5389 (Obsoleted by RFC 8489) == Missing Reference: 'RFC7235' is mentioned on line 216, but not defined == Unused Reference: 'RFC2945' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'SRP6' is defined on line 427, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP6' Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAuth R. Shekh-Yusef 3 Internet-Draft Avaya 4 Intended status: Standards Track Y. Sheffer 5 Expires: July 21, 2016 Intuit 6 January 18, 2016 8 HTTP Secure Remote Password (SRP) Authentication Scheme 9 draft-yusef-httpauth-srp-scheme-02 11 Abstract 13 This document defines an HTTP Authentication Scheme that is based on 14 the Secure Remote Password (SRP) protocol. The SRP protocol is an 15 Augmented Password Authenticated Key Exchange (PAKE) protocol 16 suitable for authenticating users and exchanging keys over an 17 untrusted network. 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 July 21, 2016. 36 Copyright Notice 38 Copyright (c) 2016 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 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Operations Overview . . . . . . . . . . . . . . . . . . . . . 3 68 3. Protection Space . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Discovery Request . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Initial Request . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Confirmation . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. Username Hashing . . . . . . . . . . . . . . . . . . . . . . 10 75 10. Internationalization Considerations . . . . . . . . . . . . . 10 76 11. Integration with Other Protocols . . . . . . . . . . . . . . 10 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 14. Normative References . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Some protocols (e.g. HTTP [HTTP-P7], SIP [RFC3261], OAUTH 2.0 85 [RFC6749], and STUN [RFC5389]) use a general framework for access 86 control and authentication, via a set of challenge-response 87 authentication schemes, which can be used by a server to challenge a 88 client request and by a client to provide authentication information. 90 Many of these systems that use the challenge-response framework rely 91 on passwords chosen by users which usually have low entropy and weak 92 randomness, and as a result cannot be used as cryptographic keys. 93 While cannot be used directly as cryptographic keys, the passwords 94 can still be used to derive cryptographic keys. 96 This document defines an HTTP Authentication Scheme that is based on 97 the Secure Remote Password (SRP) protocol. The SRP protocol is an 98 Augmented Password Authenticated Key Exchange (PAKE) protocol 99 suitable for authenticating users and exchanging keys over an 100 untrusted network, based on a shared password, without requiring a 101 Public Key Infrastructure (PKI) or any trusted third party. 103 The SRP protocol provides many security benefits: it resists 104 dictionary attacks mounted by either passive or active network 105 intruders. It also offers perfect forward secrecy, which protects 106 past sessions and passwords against future compromises. Finally, 107 user passwords are stored in a form that is not plaintext-equivalent 108 to the password itself, so an attacker who captures the password 109 database cannot use it directly to compromise security and gain 110 immediate access to the host. 112 1.1. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 2. Operations Overview 120 The SRP protocol relies on finite field GF(large-prime), which means 121 that during its setup, the server must choose a large prime number 122 (large-prime), for the integers from 1 to (large-prime - 1) to form a 123 group under multiplication modulo large-prime. The server must also 124 choose a primitive root modulo large-prime (generator) for this 125 group. 127 All values in this document are computed modulo large-prime. 129 When a user account is created, the server selects a hash function 130 and a user salt, and uses a realm and the user password to create a 131 password-verifier as follows: 133 derived-private-key = H(username:realm:password:salt) 135 password-verifier = generator ^ derived-private-key 137 The server then discards the derived-private-key and stores the 138 following information in the database: username, hash-algorithm, 139 salt, and password-verifier. 141 The following flow describes at a high-level the flow of messages 142 based on the challenge-response framework: 144 Client Server 145 ------------------------------------------------------------------- 146 | | 147 Discovery of the protection space stage (optional) | 148 | | 149 | Authorization: SRP | 150 |------------------------------------------------------------->| 151 | | 152 | WWW-Authenticate: SRP | 153 | realm="realm" | 154 |<-------------------------------------------------------------| 155 | | 156 | | 157 Mutual AuthN and establishment of session-key stage | 158 | | 159 | Authorization: SRP | 160 | username="username" | 161 |------------------------------------------------------------->| 162 | | 163 | WWW-Authenticate: SRP | 164 | large-prime="large-prime" | 165 | generator="generator" | 166 | hash-algorithm="hash-algorithm" | 167 | salt="salt", | 168 | server-public-key="server-public-key" | 169 |<-------------------------------------------------------------| 170 | | 171 | Authorization: SRP | 172 | server-public-key="server-public-key" | 173 | client-public-key="client-public-key" | 174 | client-pop="client-pop" | 175 |------------------------------------------------------------->| 176 | | 177 | WWW-Authenticate: SRP | 178 | server-pop="server-pop" | 179 |<-------------------------------------------------------------| 180 | | 181 | | 182 | | 183 | | 185 If the client is not aware of the realm associated with the resources 186 it is trying to access, then the initial request will include the SRP 187 scheme with no parameters. This will allow the server to discover 188 the client's capabilities and to challenge the request and provide 189 the client with the realm associated with the resource. The client 190 is then expected to retry the request with the username parameter. 192 The client then initiates the authentication process with the server 193 by sending an initial request with an Authorization header with SRP 194 scheme which includes the username parameter associated with that 195 protection space. 197 The server generates its private key and calculates its associated 198 public key, then challenges the request and includes the WWW- 199 Authenticate with the large-prime, generator, hash-algorithm, salt, 200 and server-public-key. 202 The client calculates the session-key and re-tries the request and 203 includes an Authorization header with client-pop to prove to the 204 server that it is in possession of the session-key. 206 The server verifies the client-pop and calculates the server-pop to 207 prove to the client that it is in possession of the same session-key. 209 At the end of the above process, the client and the server would have 210 established a communication channel after completing a mutual 211 authentication, and each side would be in possession of the same 212 session-key. 214 3. Protection Space 216 The HTTP Authentication Framework [RFC7235] defines "protection 217 space" as a combination of the canonical root URI of the server being 218 accessed and the "realm" value. The "realm" values allow the 219 partitioning of the server resources into a set of protection spaces, 220 each with its own authentication scheme and/or authorization 221 database. 223 A protection space determines the scope of protection covered by a 224 set of credentials that can be applied automatically. If a prior 225 request has been authorized, then the client may reuse the same 226 credentials for all other requests within that protection space, for 227 a period of time determined by the server. 229 4. Discovery Request 231 If the client is not aware of the realm associated with the resource 232 it needs to access, then the discovery request MUST be sent without 233 any parameters, to allow the server to challenge the request and send 234 the realm to the client. The client is then expected to retry the 235 request with the username associated with the realm of the resource 236 being accessed to initiate the authentication process. 238 5. Initial Request 240 The initial request from the client, that starts the authentication 241 process, MUST include an Authorization header field with the SRP 242 scheme. 244 The request MUST include the following parameter: 246 username 248 The user's name in a specific realm. 250 6. Challenge 252 If a discovery request is received from the client, then the server 253 MUST challenge the request by responding with 401 and MUST include 254 the realm parameter. The client is expected to retry the request and 255 include the username parameter to start the authentication process. 257 When the server receives the request with the username parameter, the 258 server looks up the hash-algorithm, salt, and password-verifier 259 associated with the username provided by the client in the initial 260 request. 262 OPEN ISSUE: 264 { To prevent an attacker from identifying the usernames in the DB, if 265 a username does not exist in the DB, the server should still go 266 through the motion of attempting to authenticate the user and fail it 267 only during the last step, to prevent the attacker from recognizing 268 the username existence by analyzing how fast the server responds to 269 the initial request. } 271 The server generates a random number, [1, large-prime - 1], as a 272 server ephemeral private key (server-private-key), and computes the 273 associated server ephemeral public key. The server MUST generate a 274 fresh ephemeral private key for each authentication session, even if 275 the request is coming from the same user. 277 The server calculates the server-public-key as follows: 279 server-public-key = H( 3 * password-verifier + generator ^ server- 280 private-key ) 282 The server then challenges the initial request from the client by 283 responding with a "401 Unauthorized" status code and a WWW- 284 Authenticate header field with and SRP scheme. The header field MUST 285 include the following parameters: 287 large-prime 289 The large prime used to form the finite field GF(n) group, 290 selected by the server during setup, formatted as a decimal 291 integer. 293 generator 295 A finite field GF(n) group generator selected by the server 296 during setup, formatted as a decimal integer. 298 hash-algorithm 300 The hash algorithm used to create the session-key, e.g SHA256. 302 salt 304 A random string used as user's salt. 306 server-public-key 308 The server ephemeral public key associated with the server 309 ephemeral private key. 311 7. Response 313 The client generates a random number, [1, large-prime - 1], as a 314 client ephemeral private key (client-private-key), and computes the 315 associated client ephemeral public key as follows: 317 client-public-key = generator ^ client-private-key 319 The client calculates the derived-private-key, random nonce, session- 320 tag, session-key, and client-pop as follows: 322 derived-private-key = H( username:realm:password:salt ) 324 nonce = H( client-public-key : server-public-key ) 326 session-tag = ( server-public-key - 3 * generator ^ derived- 327 private-key) ^ (client-private-key + nonce * derived-private-key ) 329 session-key = H ( session-tag ) 331 client-pop = H( client-public-key : server-public-key : session- 332 tag ) 334 The client is expected to retry the request passing an Authorization 335 header field with SRP scheme. The header field MUST include the 336 following parameters: 338 server-public-key 340 The server ephemeral public key that the client received from 341 the server with the challenge request. 343 client-public-key 345 The client ephemeral public key associated with the client 346 ephemeral private key. 348 client-pop 350 A client proof-of-possession to prove to the server that the 351 client is possession of the session-key. 353 8. Confirmation 355 The server MAY use the server-public-key received from the client to 356 correlate this request with the previous response it sent to the 357 client. This especially important in the case that this request is 358 received on a different connection than the one that delivered the 359 initial request. 361 The server calculates a random nonce and the session-tag as follows: 363 nonce = H( client-public-key : server-public-key ) 365 session-tag = ( client-public-key * password-verifier ^ nonce ) ^ 366 server-private-key 368 At this stage, the server has enough information to verify the 369 client-pop by locally calculating the expected-client-pop and 370 comparing it to the one received from the client. The server 371 calculates the expected-client-pop as follows: 373 expected-client-pop = H( client-public-key : server-public-key : 374 session-tag ) 376 The server then compares the expected-client-pop to the client-pop. 377 If they are different, then the server MUST fail the request by 378 responding with a "401 Unauthorized" status code and follow the same 379 procedure used with the initial request. 381 If the expected-client-pop is the same as the client-pop received 382 from the client, the server continues the process and calculates its 383 server-pop and session-key as follows: 385 server-pop = H( client-public-key : client-pop : session-tag ) 387 session-key = H ( session-tag ) 389 The server then confirms the client's request by responding with 200 390 OK request. The 200 OK message MUST include an Authentication-Info 391 header field with the SRP scheme. The header field MUST include the 392 following parameter: 394 server-pop 396 A server proof-of-possession to prove to the client that the 397 server is possession of the session-key. 399 When the client receives the confirmation from the server it verifies 400 the server-pop by calculating the expected-server-pop and comparing 401 it to the server-pop. If these values are different, then the client 402 MUST consider the authentication process to have failed; otherwise, 403 the authentication process is complete, and both sides would be in 404 possession of the same session-key. 406 9. Username Hashing 408 TBD: https://tools.ietf.org/html/rfc7616#section-3.4.4 410 10. Internationalization Considerations 412 TBD: https://tools.ietf.org/html/rfc7616#section-4 414 11. Integration with Other Protocols 416 12. Security Considerations 418 13. IANA Considerations 419 14. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 425 RFC 2945, September 2000. 427 [SRP6] Wu, T., "SRP-6: Improvements and Refinements to the Secure 428 Remote Password Protocol", IEEE P1363 Working 429 Group http://srp.stanford.edu/srp6.ps, October 2002. 431 Authors' Addresses 433 Rifaat Shekh-Yusef 434 Avaya 435 250 Sidney Street 436 Belleville, Ontario 437 Canada 439 Phone: +1-613-967-5267 440 EMail: rifaat.ietf@gmail.com 442 Yaron Sheffer 443 Intuit 444 4 HaHarash St. 445 Hod HaSharon 4524075 446 Israel 448 EMail: yaronf.ietf@gmail.com