idnits 2.17.1 draft-yusef-httpauth-srp-scheme-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (May 31, 2015) is 3251 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 82, but not defined == Missing Reference: 'RFC3261' is mentioned on line 82, but not defined == Missing Reference: 'RFC6749' is mentioned on line 83, but not defined == Missing Reference: 'RFC5389' is mentioned on line 83, but not defined ** Obsolete undefined reference: RFC 5389 (Obsoleted by RFC 8489) == Missing Reference: 'RFC7235' is mentioned on line 187, but not defined ** Obsolete undefined reference: RFC 7235 (Obsoleted by RFC 9110) == Unused Reference: 'SRP6' is defined on line 424, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP6' Summary: 3 errors (**), 0 flaws (~~), 8 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: December 2, 2015 Intuit 6 May 31, 2015 8 HTTP Secure Remote Password (SRP) Authentication Scheme 9 draft-yusef-httpauth-srp-scheme-00 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 December 2, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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. Initial Request . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Username Hashing . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Internationalization Considerations . . . . . . . . . . . . . 10 74 9. Integration with Other Protocols . . . . . . . . . . . . . . 10 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Some protocols (e.g. HTTP [HTTP-P7], SIP [RFC3261], OAUTH 2.0 83 [RFC6749], and STUN [RFC5389]) use a general framework for access 84 control and authentication, via a set of challenge-response 85 authentication schemes, which can be used by a server to challenge a 86 client request and by a client to provide authentication information. 88 Many of these systems that use the challenge-response framework rely 89 on passwords chosen by users which usually have low entropy and weak 90 randomness, and as a result cannot be used as cryptographic keys. 91 While cannot be used directly as cryptographic keys, the passwords 92 can still be used to derive cryptographic keys. 94 This document defines an HTTP Authentication Scheme that is based on 95 the Secure Remote Password (SRP) protocol. The SRP protocol is an 96 Augmented Password Authenticated Key Exchange (PAKE) protocol 97 suitable for authenticating users and exchanging keys over an 98 untrusted network, based on a shared password, without requiring a 99 Public Key Infrastructure (PKI) or any trusted third party. 101 The SRP protocol provides many security benefits: it resists 102 dictionary attacks mounted by either passive or active network 103 intruders, allowing even weak passphrases to be used safely. It also 104 offers perfect forward secrecy, which protects past sessions and 105 passwords against future compromises. Finally, user passwords are 106 stored in a form that is not plaintext-equivalent to the password 107 itself, so an attacker who captures the password database cannot use 108 it directly to compromise security and gain immediate access to the 109 host. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Operations Overview 119 During its setup, the server must choose a large-prime, and as a 120 result the integers from 1 to (large-prime - 1) form a group under 121 multiplication mod large-prime, and a generator for this group is 122 also chosen. 124 When a user account is created, the server selects a hash function 125 and a user salt, and uses a realm and the user password to create a 126 password-verifier as follows: 128 derived-private-key = H(username:realm:password:salt) 130 password-verifier = generator ^ derived-private-key 132 Note that all values in this document are computed modulo large- 133 prime. 135 The server then stores the following information in the database: 137 o username 139 o hash-algorithm 141 o salt 143 o password-verifier 144 The following flow describes at a high-level the flow of messages 145 based on the challenge-response framework: 147 Client Server 148 ------------------------------------------------------------------- 149 | | 150 Discovery of the protection space stage (optional) | 151 | | 152 | Authorization: SRP | 153 |------------------------------------------------------------->| 154 | | 155 | WWW-Authenticate: SRP | 156 | realm="realm" | 157 |<-------------------------------------------------------------| 158 | | 159 | | 160 Mutual AuthN and establishment of session-key stage | 161 | | 162 | Authorization: SRP | 163 | username="username" | 164 |------------------------------------------------------------->| 165 | | 166 | WWW-Authenticate: SRP | 167 | large-prime="large-prime" | 168 | generator="generator" | 169 | hash-algorithm="hash-algorithm" | 170 | salt="salt", | 171 | server-public-key="server-public-key" | 172 |<-------------------------------------------------------------| 173 | | 174 | Authorization: SRP | 175 | client-public-key="client-public-key" | 176 | client-pop="client-pop" | 177 |------------------------------------------------------------->| 178 | | 179 | WWW-Authenticate: SRP | 180 | server-pop="server-pop" | 181 |<-------------------------------------------------------------| 182 | | 183 | | 184 | | 185 | | 187 The HTTP Authentication Framework [RFC7235] defines "protection 188 space" as a combination of the canonical root URI of the server being 189 accessed and the "realm" value. The "realm" values allow the 190 partitioning of the server resources into a set of protection spaces, 191 each with its own authentication scheme and/or authorization 192 database. 194 A protection space determines the scope of protection covered by a 195 set of credentials that can be applied automatically. If a prior 196 request has been authorized, then the client may reuse the same 197 credentials for all other requests within that protection space, for 198 a period of time determined by the authentication scheme. 200 If the client is aware of the realm associated with the protection 201 space it is trying to access, then the client initiates the 202 communication to the server by sending an initial request with an 203 Authorization header with SRP scheme which includes the username 204 parameter associated with that protection space. 206 Otherwise, If the client is not aware of the realm associated with 207 the resources it is trying to access, then the initial request will 208 include the SRP scheme with no parameters. This will allow the 209 server to challenge the request and provide the client with the realm 210 associated with the resource. The client is then expected to retry 211 the request with the username parameter. 213 The server generates its private key and calculates its associated 214 public key, then challenges the request and includes the WWW- 215 Authenticate with the large-prime, generator, hash-algorithm, salt, 216 and server-public-key. 218 The client calculates the session-key and re-tries the request and 219 includes an Authorization header with client-pop to prove to the 220 server that it is in possession of the session-key. 222 The server verifies the client-pop and calculates the server-pop to 223 prove to the client that it is in possession of the same session-key. 225 At the end of the above process, the client and the server would have 226 established a communication channel after completing a mutual 227 authentication, and each side would be in possession of the same 228 session-key. 230 3. Initial Request 232 The initial request from the client MUST include an Authorization 233 header field with the SRP scheme. 235 If the client is aware of the realm associated with the resource it 236 is trying to access, then the client MUST include the following 237 parameter: 239 username 241 The user's name in a specific realm. 243 Otherwise, the initial request MUST be sent without any parameters, 244 to allow the server to challenge the request and send the realm to 245 the client. The client is then expected to retry the request with 246 the username associated with the realm of the resource being 247 accessed. 249 4. Challenge 251 If the initial request received from the client does not have a 252 username parameter, then the server MUST challenge the request by 253 responding with 401 and MUST include the realm parameter. The client 254 is expected to retry the request and include the username parameter. 256 When the server receives the request with the username parameter, the 257 server looks up the hash-algorithm, salt, and password-verifier 258 associated with the username provided by the client in the initial 259 request. 261 OPEN ISSUE: 262 { 263 To prevent an attacker from identifying the usernames in the DB, if a 264 username does not exist in the DB, the server should still go through 265 the motion of attempting to authenticate the user and fail it only 266 during the last step, to prevent the attacker from recognizing the 267 username existence by analyzing how fast the server responds to the 268 initial request. 269 } 270 The server generates a random number, [1, large-prime - 1], as a 271 server ephemeral private key (server-private-key), and computes the 272 associated server ephemeral public key. The server MUST generate a 273 fresh ephemeral private key for each authentication session, even if 274 the request is coming from the same user. 276 The server calculates the server-public-key as follows: 278 server-public-key = H( 3 * password-verifier + generator ^ server- 279 private-key ) 281 The server then challenges the initial request from the client by 282 responding with a "401 Unauthorized" status code and a WWW- 283 Authenticate header field with and SRP scheme. The header field MUST 284 include the following parameters: 286 large-prime 288 The large prime used to form the finite field GF(n) group, 289 selected by the server during setup, formatted as a decimal 290 integer. 292 generator 294 A finite field GF(n) group generator selected by the server 295 during setup, formatted as a decimal integer. 297 hash-algorithm 299 The hash algorithm used to create the session-key, e.g SHA256. 301 salt 303 A random string used as user's salt. 305 server-public-key 307 The server ephemeral public key associated with the server 308 ephemeral private key. 310 5. Response 312 The client generates a random number, [1, large-prime - 1], as a 313 client ephemeral private key (client-private-key), and computes the 314 associated client ephemeral public key as follows: 316 client-public-key = generator ^ client-private-key 318 The client calculates the derived-private-key, random nonce, session- 319 tag, session-key, and client-pop as follows: 321 derived-private-key = H( username:realm:password:salt ) 323 nonce = H( client-public-key : server-public-key ) 325 session-tag = ( server-public-key - 3 * generator ^ derived- 326 private-key) ^ (client-private-key + nonce * derived-private-key ) 328 session-key = H ( session-tag ) 330 client-pop = H( client-public-key : server-public-key : session ) 332 The client is expected to retry the request passing an Authorization 333 header field with SRP scheme. The header field MUST include the 334 following parameters: 336 server-public-key 338 The server ephemeral public key that the client received from 339 the server with the challenge request. 341 client-public-key 343 The client ephemeral public key associated with the client 344 ephemeral private key. 346 client-pop 348 A client proof-of-possession to prove to the server that the 349 client is possession of the session-key. 351 6. Confirmation 353 The server MAY use the server-public-key received from the client to 354 correlate this request with the previous response it sent to the 355 client. This especially important in the case that this request is 356 received on a different connection than the one that delivered the 357 initial request. 359 The server calculates a random nonce and the session-tag as follows: 361 nonce = H( client-public-key : server-public-key ) 363 session-tag = ( client-public-key * password-verifier ^ nonce ) ^ 364 server-private-key 366 At this stage, the server has enough information to verify the 367 client-pop by locally calculating the expected-client-pop and 368 comparing it to the one received from the client. The server 369 calculates the expected-client-pop as follows: 371 expected-client-pop = H( client-public-key : server-public-key : 372 session ) 374 The server then compares the expected-client-pop to the client-pop. 375 If they are different, then the server MUST fail the request by 376 responding with a "401 Unauthorized" status code and follow the same 377 procedure used with the initial request. 379 If the expected-client-pop is the same as the client-pop received 380 from the client, the server continues the process and calculates its 381 server-pop and session-key as follows: 383 server-pop = H( client-public-key : client-pop : session ) 385 session-key = H ( session-tag ) 387 The server then confirms the client's request by responding with 200 388 OK request. The 200 OK message MUST include an Authentication-Info 389 header field with the SRP scheme. The header field MUST include the 390 following parameter: 392 server-pop 394 A server proof-of-possession to prove to the client that the 395 server is possession of the session-key. 397 When the client receives the confirmation from the server it verifies 398 the server-pop by calculating the expected-server-pop and comparing 399 it to the server-pop. If these values are different, then the client 400 MUST consider the authentication process to have failed; otherwise, 401 the authentication process is complete, and both sides would be in 402 possession of the same session-key. 404 7. Username Hashing 406 TBD: https://tools.ietf.org/html/draft-ietf-httpauth-digest- 407 19#section-3.4.4 409 8. Internationalization Considerations 411 TBD: https://tools.ietf.org/html/draft-ietf-httpauth-digest- 412 19#section-4 414 9. Integration with Other Protocols 416 10. Security Considerations 418 11. IANA Considerations 419 12. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [SRP6] Wu, T., "SRP-6: Improvements and Refinements to the Secure 425 Remote Password Protocol", IEEE P1363 Working Group 426 http://srp.stanford.edu/srp6.ps, October 2002. 428 Authors' Addresses 430 Rifaat Shekh-Yusef 431 Avaya 432 250 Sidney Street 433 Belleville, Ontario 434 Canada 436 Phone: +1-613-967-5267 437 EMail: rifaat.ietf@gmail.com 439 Yaron Sheffer 440 Intuit 441 4 HaHarash St. 442 Hod HaSharon 4524075 443 Israel 445 EMail: yaronf.ietf@gmail.com