idnits 2.17.1 draft-farrell-httpbis-hoba-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 date (October 5, 2012) is 4219 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) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-21 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Standards Track P. Hoffman 5 Expires: April 8, 2013 VPN Consortium 6 M. Thomas 7 Phresheez 8 October 5, 2012 10 HTTP Origin-Bound Authentication (HOBA) 11 draft-farrell-httpbis-hoba-02 13 Abstract 15 HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP 16 authentication method with credentials that are not vulnerable to 17 phishing attacks, and that does not require a server-side password 18 database. The design can also be used in Javascript-based 19 authentication embedded in HTML. HOBA is an alternative to HTTP 20 authentication schemes that require passwords with all the negative 21 attributes that come with password-based systems. HOBA can be 22 integrated with account management and other applications running 23 over HTTP and supports portability, so a user can associate more than 24 one device or origin-bound key with the same service. We also 25 describe a way in which the HOBA design can be used from a Javascript 26 web client. When deployed, HOBA will be a drop-in replacement for 27 password-based HTTP authentication or JavaScript authentication. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 8, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Comparison of HOBA and Current Password Authentication . . 5 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. HOBA for Both HTTP Authentication and JavaScript . . . . . . . 6 64 3. HOBA HTTP Authentication Mechanism . . . . . . . . . . . . . . 7 65 4. Using HOBA-http . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 8 67 4.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 8 68 4.3. Authentication Phase . . . . . . . . . . . . . . . . . . . 8 69 4.4. Logging in on a New User Agent . . . . . . . . . . . . . . 9 70 5. Using HOBA-js . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.2. User Join . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.3. User Login . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.4. Enrolling a New User Agent . . . . . . . . . . . . . . . . 11 75 5.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 11 76 5.6. Signature Parameters . . . . . . . . . . . . . . . . . . . 12 77 5.7. Session Management . . . . . . . . . . . . . . . . . . . . 13 78 5.8. Multiple Accounts on One User Agent . . . . . . . . . . . 14 79 5.9. Oddities . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6. Additional Services . . . . . . . . . . . . . . . . . . . . . 14 81 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 14 82 6.2. Associating Additional Keys to an Exiting Account . . . . 15 83 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16 84 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 8.1. localStorage Security for Javascript . . . . . . . . . . . 16 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 17 89 9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 17 90 9.3. Hash names . . . . . . . . . . . . . . . . . . . . . . . . 18 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 95 Appendix A. Problems with Passwords . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 [[ Commentary is in double-square brackets, like this. As you'll see 101 there are a bunch of details still to be figured out. Feedback on 102 those is very welcome. Also note that the authors fully expect that 103 the description of HOBA-http and HOBA-js to be mostly merged in the 104 draft; they're both here now so readers can see some alternatives and 105 maybe support particular proposals. ]] 107 HTTP Origin-Bound Authentication (HOBA) is a proposal for a new 108 authentication design that can be used as an HTTP authentication 109 scheme and for Javascript-based authentication embedded in HTML. The 110 main goal of HOBA is to offer an easy-to-implement authentication 111 scheme that is not based on passwords. If deployment of HOBA reduces 112 the number of password entries in databases by any appreciable 113 amount, then it would be worthwhile. As an HTTP authentication 114 scheme, it would work in the current HTTP 1.0 and HTTP 1.1 115 authentication framework, and will very likely work with whatever 116 changes are made to the HTTP authentication scheme in HTTP 2.0. As a 117 JavaScript design, HOBA demonstrates a way for clients and servers to 118 interact using the same credentials that are use by the HTTP 119 authentication scheme. 121 The HTTP specification defines basic and digest authentication 122 methods for HTTP that have been in use for many years, but which, 123 being based on passwords, are susceptible to theft of server-side 124 databases. (See [RFC2617] for the original specification, and 125 [I-D.ietf-httpbis-p7-auth] for clarifications and updates to the 126 authentication mechanism.) Even though few large web sites use basic 127 and digest authentication, they still use username/password 128 authentication and thus have large susceptible server-side databases 129 of passwords. 131 Instead of passwords, HOBA uses digital signatures as an 132 authentication mechanism. HOBA also adds useful features such as 133 credential management and session logout. In HOBA, the client 134 creates a new public-private key pair for each host ("web-origin") to 135 which it authenticates; web-origins are defined in [RFC6454]. These 136 keys are used in HOBA for HTTP clients to authenticate themselves to 137 servers in the HTTP protocol or in a Javascript authentication 138 program. HOBA keys need not be stored in public key certificates, 139 but instead in subjectPublicKeyInfo structures from PKIX [RFC5280]. 140 Because these are generally "bare keys", there is none of the 141 semantic overhead of PKIX certificates, particularly with respect to 142 naming and trust anchors. Thus, client public keys ("CPKs") do not 143 have any publicly-visible identifier for the user who possesses the 144 corresponding private key, nor the web-origin with which the client 145 is using the CPK. 147 HOBA also defines some services that are required for modern HTTP 148 authentication: 150 o Servers can bind a CPK with an identifier, such as an account 151 name. HOBA allows servers to define their own policies for 152 binding CPKs with accounts during account registration. 154 o Users are likely to use more than one device or user agent (UA) 155 for the same HTTP based service, so HOBA gives a way to associate 156 more than one CPK to the same account, but without having to 157 register for each separately. 159 o Users are also likely to lose a private key, or the client's 160 memory of which key pair is associated with which origin. For 161 example if a user loses the computer or mobile device in which 162 state is stored. HOBA allows for clients to tell servers to 163 delete the association between a CPK and an account. 165 o Logout features can be useful for user agents, so HOBA defines a 166 way to close a current HTTP "session", and also a way to close all 167 current sessions, even if more than one session is currently 168 active from different user agents for the same account. 170 1.1. Comparison of HOBA and Current Password Authentication 172 [[ This will be a few paragraphs explaining how HOBA can be used as a 173 drop-in replacement for the common form-and-cookie authentication 174 used today. It will show how similar many of the concepts are, and 175 also point out some of the advantages sites will get by changing to 176 HOBA. ]] 178 1.2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 A client public key ("CPK") is the public key and associated 185 cryptographic parameters needed for a server to validate a signature. 187 The term "account" is (loosely) used to refer to whatever data 188 structure(s) the server maintains that are associated with an 189 identity. That will contain of at least one CPK and a web-origin; it 190 will also optionally include an HTTP "realm" as defined in the HTTP 191 authentication specification. It might also involve many other non- 192 standard pieces of data that the server accumulates as part of 193 account creation processes. An account may have many CPKs that are 194 considered equivalent in terms of being usable for authentication, 195 but the meaning of "equivalent" is really up to the server and is not 196 defined here. 198 When describing something that is specific to HOBA as an HTTP 199 authentication mechanism or HOBA as a JavaScript implementation, this 200 document uses the terms "HOBA-http" and "HOBA-js", respectively. 202 Web client: the content and javascript code that run within the 203 context of a single user agent instance (such as a tab in a web 204 browser). 206 User agent (UA): typically, but not always, a web browser doing HOBA. 208 User: a person who is running a UA. In this document, "user" does 209 not mean "user name" or "account name". 211 [[This specification may later use the Augmented Backus-Naur Form 212 (ABNF) notation of [RFC5234]. Or maybe not. ]] 214 2. HOBA for Both HTTP Authentication and JavaScript 216 A UA that implements HOBA maintains a list of web-origins and realms. 217 The UA also maintains one or more client credentials for each web- 218 origin/realm combination for which it has created a CPK. 220 [[We've discussed whether or not realms are needed. They may 221 disappear if they're not.]] 223 On receipt of a challenge from a server, the client marshals a to-be- 224 signed blob that includes the web-origin name, the realm, and the 225 challenge string; and signs that hashed blob using the hash algorithm 226 identified with the challenge and the private key corresponding to 227 the CPK for that web-origin. The client concatenates the signed blob 228 with the CPK identifier that the client and host agreed on for the 229 client. This is called the "client response". [[ Note: this is just 230 an illustrative first cut at a challenge-response protocol, real 231 design and analysis is needed for this, e.g. for security, algorithm 232 agility, etc. Ideally we can just adopt something that already has 233 some security proofs. Expect changes here.]] 235 HOBA will support the idea of multiple users on the same user agent. 236 This will be useful for the problem of "can I use your browser to 237 check my mail..." and so on. It is [[ currently ]] described only in 238 the HOBA-js section, but will apply equally to HOBA-http. [[There 239 are implications beyond the discussion in HOBA-js here in that there 240 would only be a single CPK for a set of users for a given origin 241 since normative HOBA-http has no clue at all about users and the 242 like. This needs more thought.]] 244 3. HOBA HTTP Authentication Mechanism 246 An HTTP server that supports HOBA authentication includes the "hoba" 247 auth-scheme value in a WWW-Authenticate header field when it wants 248 the client to authenticate with HOBA. 250 o If the "hoba" scheme is listed, it MUST be followed by two or more 251 auth-param values. The auth-param attributes defined by this 252 specification are below. Other auth-param attributes MAY be used 253 as well. Unknown auth-param attributes MUST be ignored by 254 clients, if present. 256 o The "challenge" attribute MUST be included. The challenge is a 257 string of characters that the server wants the client to sign in 258 its response. The challenge SHOULD be unique for every HTTP 401 259 response in order to prevent replay attacks from passive 260 observers. [[How or if replay detection is specified is TBD.]] 262 o The "hash" attribute MUST be included. This is the name of the 263 hash algorithm that the server wants the client to use in signing 264 challenge. The valid names for hash algorithms are listed in [[ 265 some IANA registry, maybe same as DKIM ]]. 267 o Note that a hash here is sufficient, given the assumption that the 268 client and server have already agreed (or are about to agree) the 269 public key and asymmetric algorithm for the CPK. 271 o A "realm" attribute MAY be included to indicate the scope of 272 protection in the manner described in HTTP/1.1, Part 7 273 [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear 274 more than once. 276 When the "client response" is created, the HOBA-http client encodes 277 the result as a b64token and returns that b64token in the 278 Authorization header. 280 The HOBA-http authentication mechanism allows for the use of cookies 281 for preserving state between protected resources in one HTTP realm. 282 This means that the server need only send the WWW-Authenticate header 283 field once, and can rely on cookie management for keeping state. 285 4. Using HOBA-http 287 [[A lot of this is similar to the HOBA-js discussion below. At some 288 point some nuclear fusion might be nice, but for now it might be best 289 to keep them separate until we understand better what can be merged, 290 and what is different.]] 292 The interaction between an HTTP client and HTTP server using HOBA 293 happens in three phases: the CPK preparation phase, the signing 294 phase, and the authentication phase. The first and second phase are 295 done in a standard fashion; the third is done using site-specific 296 methods. 298 [[ Need to describe what happens if the user bails half way through 299 the flow. ]] 301 4.1. CPK Preparation Phase 303 In the CPK preparation phase, the client determines if it already has 304 a CPK for the web-origin it is going to. If the has a CPK, the 305 client will use it; if the client does not have a CPK, it generates 306 one in anticipation of the server asking for one. 308 4.2. Signing Phase 310 In the signing phase, the client connects to the server, the server 311 asks for HOBA-based authentication, and the client authenticates by 312 signing a blob of information as described in the previous sections. 314 The user agent tries to access a protected resource on the server. 315 The server sends the HOBA WWW-Authenticate challenge. The user agent 316 receives the challenge and signs the challenge using the CPK it 317 either already had or just generated. The server validates the 318 signature. If validation fails, the server aborts the transaction. 319 [[ Or maybe it asks again? ]] 321 4.3. Authentication Phase 323 In the authentication phase, the server extracts the CPK from the 324 signing phase and decides if it recognizes the CPK. If the server 325 recognizes the CPK, the server may finish the client authentication 326 process. If the process involves a second factor of authentication, 327 such as asking the user which account it wants to use (in the case 328 where a user agent is used for multiple accounts on a site), the 329 server may prompt the user for the account identifying information. 330 None of this is standardized: it all follows the server's security 331 policy and session flow. At the end of this, the server probably 332 assigns or updates a session cookie for the client. 334 If the server does not recognize the CPK the server might send the 335 client through a either a join or login-new-user-agent (see below) 336 process. This process is completely up to the server, and probably 337 entails using HTML, JavaScript and CSS to ask the user some questions 338 in order to assess whether or not the server wants to give the client 339 an account. Completion of the joining process might entail require 340 confirmation by email, SMS, Captcha, and so on. 342 Note that there is no necessity for the server to initiate a joining 343 or login process upon completion of the signing phase. Indeed, the 344 server may desire to challenge the user agent even for unprotected 345 resources and carry along the CPK in a session cookie for later use 346 in a join or login process as it becomes necessary. For example, a 347 server might only want to offer an account to someone who had been to 348 a few pages on the web site; in such a case, the server could use the 349 CPK from an associated session cookie as a way of building reputation 350 for the user until the server wants the user to join. 352 After the UA is authenticated (if the user had to join, this could be 353 the last step of joining), the server gives the UA access to the 354 protected resource that was originally requested at the beginning of 355 the signing phase. It is quite likely that the server would also 356 update the UA's session cookie for the web site. 358 4.4. Logging in on a New User Agent 360 When a user wants to use a new user agent for an existing account, 361 the flows are similar to logging in with an already-joined UA or 362 joining for the first time. In fact, the CPK preparation phase (with 363 the UA knowing that it needs to create a new CPK) and the signing 364 phase are identical. 366 During the authentication phase, the server could use HTML, 367 JavaScript and CSS to ask the user if they are really a new user or 368 want to associate this new CPK with an already-joined CPK. The 369 server can then use some out-of-band method (such as a confirmation 370 email round trip, SMS, or an UA that is already enrolled) to verify 371 that the "new" user is the same as the already-enrolled one. 373 5. Using HOBA-js 375 [[ A description of how to use the same HOBA semantics, but doing 376 everything in Javascript in a web page. This is more of a 377 demonstration that you could get the similar semantics via JS rather 378 than a normative section.]] 380 Web sites using javascript can also perform origin-bound 381 authentication without needing to involve the http layer, and by 382 inference not needing HOBA-specific support in browsers. One element 383 is required: localStorage (see http://www.w3.org/TR/webstorage/), and 384 one when it is available will be highly desirable: WebCrypto (see 385 http://www.w3.org/TR/WebCryptoAPI). In lieu of WebCrypto, javascript 386 crypto libraries can be employed with the known deficiencies of PRNG, 387 and the general immaturity of those libraries. The following section 388 outlines a mechanism for Javascript HOBA clients to initially enroll, 389 subsequent enrollment on new clients, login, and how HOBA-js relates 390 to web based session management. As with HOBA-http, a pure 391 Javascript implementation retains the property that only CPKs are 392 stored on the server, so that server compromise doesn't suffer the 393 multiplier affect that the various recent password exposure debacles 394 have vividly demonstrated. 396 5.1. Key Storage 398 We use the new HTML 5 webstorage feature that is now widely 399 available. Conceptually an implementation stores in the origin's 400 localStorage dictionary account identifier, public key, private key 401 tuples for subsequent authentication requests. How this is actually 402 stored in localStorage is an implementation detail. We rely on the 403 security properties of the same-origin policy that localStorage 404 enforces. See the security considerations for discussion about 405 attacks on localStorage. 407 5.2. User Join 409 To join a web site, the HOBA-js client generates a public/private key 410 pair and takes as input the account identifier to which the key pair 411 should be bound. The key pair and account identifier are stored in 412 localStorage for later use. The user agent then signs the join 413 information (see below) using the private key, and forms a message 414 with the public key (CPK) and the signed data. The server receives 415 the message and verifies the signed data using the supplied key. The 416 server creates the account and adds the public key to a list of 417 public keys associated with this account. 419 5.3. User Login 421 Each time the user needs to log in to the server, it creates a login 422 message (see below) and signs the message using the relevant private 423 key stored in localStorage. The signed login message along with the 424 associated CPK identifier is sent to the server. The server receives 425 the message and verifies the signed data. If the supplied public key 426 is amongst the set of valid public keys for the supplied account, 427 then the login proceeds. See below for a discussion about replay. 429 5.4. Enrolling a New User Agent 431 When a user wants to start using a different UA, the website has two 432 choices: use a currently enrolled UA to permit the enrollment or use 433 a trusted out of band mechanism (eg email, sms, etc). To enroll a 434 new UA using an existing UA, the web site can display a one-time 435 password on the currently enrolled UA. This password is a one-time 436 password and expires in a fixed amount of time (say, 30 minutes). It 437 doesn't need to be an overly fussy password since it's one-time and 438 times out quickly. The user then inputs the one-time password and 439 the new UA generates a new asymmetric key pair and includes the one- 440 time password in the login message to the server (see below). 442 Alternatively if an enrolled UA is not available, and the site has an 443 out of band communication mechanism (eg, sms, email, etc) a user can 444 request that a one-time password be sent to the user. The server 445 generates and stores the one-time password as above. The user 446 receives the one-time password, inputs as above on the new UA, and 447 the HOBA-js client forms the login message as above. 449 In both cases, when the server receives a login message with a one- 450 time password, it checks to see if the password supplied is in a list 451 of unexpired one-time passwords associated with that account. If the 452 password matches, the server verifies the signature, expires or 453 deletes the one-time password and adds the supplied public key to the 454 list of public keys associated with the user assuming the signature 455 verified correctly. Subsequent logins proceed as above in User 456 Login. 458 5.5. Replay Protection 460 To guard against replay of a legitimate login/join message, we use 461 Kerberos-like timestamps in the expectation of synchronization 462 between the browser's and server's clocks is sufficiently reliable. 463 This saves an HTTP round trip which is desirable, though a challenge- 464 response mechanism as in HOBA-http could also be used. The client 465 puts the current system time into the URL, and the server side vets 466 it against its system time. Like Kerberos, a replay cache covering a 467 signature timeout window is required on the server. This can be done 468 using a database table that is keyed (in the database sense of the 469 term) using the signature bits. If the signature is in the replay 470 table, it ought be rejected. If the timestamp in the signature is 471 outside the current replay cache window then it also gets rejected. 473 [[ An addition of the ability for the server to reject a client with 474 potential time skew and give it a nonce (as with HOBA-http) would 475 allow the size of the replay cache to be set to just a few minutes 476 rather than a much longer period. Or the HOBA server could always 477 use a nonce method. This is worthy of more discussion. ]]. 479 5.6. Signature Parameters 481 Since we only require agreement between the server and the client 482 where the client is under the control of the server, the actual url 483 parameter names here are only advisory. For each signed url, the 484 client forms a url with the necessary login/join information. For 485 example, suppose example.com has login and join scripts with various 486 parameters: 488 o http://example.com/site/login.php?username=Mike 490 o http://example.com/site/ 491 join.php?username=Mike&email=mike@example.com&sms=555.1212 493 The client then appends a signature parameter block to the url: 495 o curtime: the time in milliseconds since unix epoch (ie, new Date 496 ().getTime ()). 498 o pubkey: the url encoded public key. See DKIM for the format of 499 the base64 encoded PEM formated key. 501 o temppass: an optional url encoded one-time password for subsequent 502 enrollment. 504 o keyalg: currently RSA. 2048 bit keys should be use if WebCrypto is 505 available 507 o digestalg: currently SHA1. SHA256 should be used if WebCrypto is 508 available. 510 o signature: empty for signing canonicalization purposes 512 [[ Signing the full url is problematic with PHP; we should take a 513 clue from what OAUTH does here; we almost certainly need to add some 514 host identifying information...]] To create the signature, the 515 canonical text includes the path portion, the site-specific url 516 parameters and appends a signature block onto the end of the url. 517 The signature block consists of the parameters listed above with an 518 empty signature parameter (ie, signature=), eg: 520 o Login: /site/ 521 login.php?username=Mike&curtime=1234567890.1234&keyalg=RSA& 522 digestalg=SHA1&signature= 524 o Join: /site/ 525 join.php?username=Mike&email=mike@ 526 example.com&curtime=1234567890.1234&keyalg=RSA&digestalg=SHA1& 527 signature= 529 o Login New User Agent: /site/ 530 login.php?username=Mike&curtime=1234567890.1234&temppass=1239678& 531 keyalg=RSA&digestalg=SHA1&signature= 533 The canonical signature text is then signed with the private key 534 associated with the account. The signature is then base64 encoded 535 and appended to the full url, and sent to the server using 536 XMLHttpRequest as usual. On receipt of the login request, the server 537 first extracts the timestamp (curtime) and determines whether the 538 timestamp is fresh (see above) rejecting the request if stale. The 539 server then removes the scheme and domain:port portion of the 540 incoming url, and removes the signature value only to create the 541 canonical signature text. The server then extracts the public key 542 along with the account and verifies the signature. If the signature 543 verifies, the server then determines whether this is an enrolled 544 public key for the user. If it is, login/join succeeds. If the key 545 is not enrolled, the server then checks to see if a one-time password 546 was supplied. If not, login/join fails. If a one-time password was 547 supplied, the server checks to see if a one-time password is valid 548 and fails if not. If valid, the server disables the one-time 549 password (eg, deletes it from its database) and adds the new public 550 key to the list of enrolled public keys for this user. 552 Once verified, the server may start up normal cookie-based session 553 management (see below). The server should send back status to the 554 HOBA-js client to determine whether the login/join was successful. 555 The details are left as an implementation detail. 557 Note: the client SHOULD use an HTTP POST for the XMLHttpRequest as 558 both the public key and signature blocks may exhaust the maximum size 559 for a GET request (typically around 2KB). 561 5.7. Session Management 563 Session Management is identical to username/password session 564 management. That is, the session management tool (such as PHP, 565 Python CGI, and so on) inserts a session cookie into the output to 566 the browser, and logging out simply removes the session cookie. 567 HOBA-js does nothing to help or hurt session cookie hijacking -- TLS 568 is still our friend. 570 5.8. Multiple Accounts on One User Agent 572 A shared UA with multiple accounts is possible if the account 573 identifier is stored along with the asymmetric key pair binding them 574 to one another. Multiple entries can be kept, one for each account, 575 and selected by the current user. This, of course, is fraught with 576 the possibility for abuse, since you're enrolling the device 577 potentially long-term. A couple of things can possibly be done to 578 combat that. First, the user can request that the credential be 579 erased from keystore. Similarly, in the enrollment phase, a user 580 could request that the key pair only be kept for a certain amount of 581 time, or that it not be stored at all. Last, it's probably best to 582 just not use shared devices at all since that's never especially 583 safe. 585 5.9. Oddities 587 With the same-origin policy, subdomains do not have access to the 588 same localStorage as parent domains do. For larger/more complex 589 sites this could be an issue that requires enrollment into subdomains 590 with the requisite hassle for users. One way to get around this is 591 to use session cookies as they can be used across subdomains. That 592 is, login using a single well-known domain, and then use session 593 cookies to navigate around a site. 595 6. Additional Services 597 HOBA uses a well-known URL [RFC5785] "hoba" as a base URI for 598 performing many tasks: "https://www.example.com/.well-known/hoba". 599 These URLs are based on the name of the host that the HTTP client is 600 accessing. There are many use cases for these URLs to redirect to 601 other URLs: a site that does registration through a federated site, a 602 site that only does registration under HTTPS, and so on. Like any 603 HTTP client, HOBA clients MUST be able to handle redirection of these 604 URLs. [[There are a bunch of security issues to consider related to 605 cases where a re-direct brings you off-origin.]] 607 All additional services MUST be done in TLS-protected sessions 608 ([RFC5246]). 610 6.1. Registration 612 Normally, a registration is expected to happen after a UA receives a 613 WWW-Authenticate for a web-origin and realm for which it has no 614 associated CPK. The (protocol part of the) process of registration 615 for a HOBA account on a server is relatively light-weight. The UA 616 generates a new key pair, and associates it with the web-origin/realm 617 in question. The UA sets up a TLS-protected session, goes to the 618 registration URL ".well-known/hoba/register", and submits the CPK 619 using a POST message. [[ More description is clearly needed here. ]] 620 It is up to the server to decide what kind of user interaction is 621 required before the account is finally set up. 623 If the UA has a CPK associated with the web-origin, but not for the 624 realm concerned, then a new registration is REQUIRED. If the server 625 did not wish for that outcome, then it ought not use a different 626 realm. 628 The POST message sent to the registration URL has one parameter, 629 called "cpksubmit", which contains the CPK that the UA will use for 630 the origin/realm combination. The CPK MUST be sent base64 encoded. 631 The value that is base64 encoded is the DER encoding of the 632 subjectPublicKeyInfo structure that is the CPK. See [RFC5280] for 633 details of that data structure. 635 6.2. Associating Additional Keys to an Exiting Account 637 It is common for a user to have multiple UAs, and to want all those 638 UAs to be able to authenticate to a single account. One method to 639 allow a user who has an existing account to be able to authenticate 640 on a second device is to securely transport the private and public 641 keys and the origin information from the first device to the second. 642 Previous history with such key transport has been spotty at best. As 643 an alternative, HOBA allows associating a CPK from the second device 644 to the account created on the first device. 646 Instead of registering on the new device, the UA generates a new key 647 pair, associates it with the web-origin/realm in question, goes to 648 the URL for starting an association, ".well-known/hoba/ 649 associate-start" in a TLS-protected session, and submits the new CPK 650 using a POST message. [[ More description is clearly needed here. ]] 651 The server's response to this request is a nonce with at least 128 652 bits of entropy. That nonce SHOULD be easy for the user to copy and 653 type, such as using Base32 encoding (see [RFC4648]). The user then 654 uses the first UA to log into the origin, goes to the URL for 655 finishing an association, ".well-known/hoba/associate-finish", and 656 submits the nonce using a POST message. [[ More description is 657 clearly needed here. ]]. The server then knows that the 658 authenticated user is associated with the second CPK. The server can 659 choose to associate the two CPKs with one account. Whether to do so 660 is entirely at the server's discretion however, but the server SHOULD 661 make the outcome clear to the user. 663 6.3. Logging Out 665 When the user wishes to logout, the UA simply goes to ".well-known/ 666 hoba/logout". The UA MAY also delete session cookies associated with 667 the session. [[Is that right?, maybe a SHOULD- or MUST-delete would 668 be better]] 670 The server-side MUST NOT allow TLS session resumption for any logged 671 out session and SHOULD also revoke or delete any cookies associated 672 with the session. 674 7. Mandatory-to-Implement Algorithms 676 [[ We should list two signature schemes (most likely RSA and ECDSA 677 with P256). We should list two hash algorithms (most likely SHA-256 678 and SHA-384). ]] 680 8. Security Considerations 682 If key binding was server-selected then a bad actor could bind 683 different accounts belonging to the user from the network with 684 possible bad consequences, especially if one of the private keys was 685 compromised somehow. 687 Binding my CPK with someone else's account would be fun and 688 profitable so SHOULD be appropriately hard. In particular the string 689 generated by the server MUST be hard to guess, for whatever level of 690 difficulty is chosen by the server. The server SHOULD NOT allow a 691 random guess to reveal whether or not an account exists. 693 [[The potential impact on privacy of HOBA needs to be addressed. If 694 a site can use a 401 and a CPK to track users without permission that 695 would be not-so-nice so some guidance on how a UA could indicate to a 696 user that HOBA stuff is going on might be needed.]] 698 [[lots more TBD, be nice to your private keys etc. etc.]] 700 8.1. localStorage Security for Javascript 702 Our use of localStorage will undoubtedly be a cause for concern. 703 localStorage uses the same-origin model which says that the scheme, 704 domain and port define a localStorage instance. Beyond that, any 705 code executing will have access to private keying material. Of 706 particular concern are XSS attacks which could conceivably take the 707 keying material and use it to create user agents under the control of 708 an attacker. But XSS attacks are in reality across the board 709 devastating since they can and do steal credit card information, 710 passwords, perform illicit acts, etc, etc. It's not clear that we 711 introduce unique threats from which clear text passwords don't 712 already suffer. 714 Another source of concern is local access to the keys. That is, if 715 an attacker has access to the UA itself, they could snoop on the key 716 through a javascript console, or find the file(s) that implement 717 localStorage on the host computer. Again it's not clear that we are 718 worse in this regard because the same attacker could get at browser 719 password files, etc too. One possible mitigation is to encrypt the 720 keystore with a password/pin the user supplies. This may sound 721 counter intuitive, but the object here is to keep passwords off of 722 servers to mitigate the multiplier effect of a large scale compromise 723 ala LinkedIn because of shared passwords across sites. 725 It's worth noting that HOBA uses asymmetric keys and not passwords 726 when evaluating threats. As various password database leaks have 727 shown, the real threat of a password breach is not just to the site 728 that was breached, it's all of the sites a user used the same 729 password on too. That is, the collateral damage is severe because 730 password reuse is common. Storing a password in localStorage would 731 also have a similar multiplier effect for an attacker, though perhaps 732 on a smaller scale than a server-side compromise: one successful 733 crack gains the attacker potential access to hundreds if not 734 thousands of sites the user visits. HOBA does not suffer from that 735 attack multiplier since each asymmetric key pair is unique per site/ 736 useragent/user. 738 9. IANA Considerations 740 9.1. HOBA Authentication Scheme 742 Authentication Scheme Name: hoba 744 Pointer to specification text: [[ this document ]] 746 Notes (optional): The HOBA scheme can be used with either HTTP 747 servers or proxies. [[But we need to figure out the proxy angle;-)]] 749 9.2. .well-known URLs 751 TBD 753 9.3. Hash names 755 TBD, hopefully re-use and existing registry 757 We probably want a new registry for the labels beneath .well-known/ 758 hoba so that other folks can add additional features in a controlled 759 way, e.g. for CPK/account revocation or whatever. 761 10. Acknowledgements 763 [[TBD]] 765 11. References 767 11.1. Normative References 769 [I-D.ietf-httpbis-p7-auth] 770 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 771 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-21 772 (work in progress), October 2012. 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 778 Specifications: ABNF", STD 68, RFC 5234, January 2008. 780 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 781 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 783 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 784 Uniform Resource Identifiers (URIs)", RFC 5785, 785 April 2010. 787 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 788 December 2011. 790 11.2. Informative References 792 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 793 Leach, P., Luotonen, A., and L. Stewart, "HTTP 794 Authentication: Basic and Digest Access Authentication", 795 RFC 2617, June 1999. 797 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 798 Encodings", RFC 4648, October 2006. 800 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 801 Housley, R., and W. Polk, "Internet X.509 Public Key 802 Infrastructure Certificate and Certificate Revocation List 803 (CRL) Profile", RFC 5280, May 2008. 805 Appendix A. Problems with Passwords 807 By far the most common mechanism for web authentication is passwords 808 that can be remembered by the user, called "memorizable passwords". 809 There is plenty of good research on how users typically use 810 memorizable passwords ([[ handful of citations goes here ]]), but 811 some of the highlights are that users typically try hard to reuse 812 passwords on as many web sites as possible, and that web sites often 813 use either email addresses or users' names as the identifier that 814 goes with these passwords. 816 If an attacker gets access to the database of memorizable passwords, 817 that attacker can impersonate any of the users. Even if the breach 818 is discovered, the attacker can still impersonate users until every 819 password is changed. Even if all the passwords are changed or at 820 least made unusable, the attacker now possesses a list of likely 821 username/password pairs that might exist on other sites. 823 Using memorizable passwords on unencrypted channels also poses risks 824 to the users. If a web site uses either the HTTP Plain 825 authentication method, or an HTML form that does no cryptographic 826 protection of the password in transit, a passive attacker can see the 827 password and immediately impersonate the user. If a hash-based 828 authentication scheme such as HTTP Digest authentication is used, a 829 passive attacker still has a high chance of being able to determine 830 the password using a dictionary of known passwords. 832 [[ Say a bit about non-memorizable passwords. Still subject to 833 database attack, although that doesn't give the attacker knowledge 834 for other systems. Safe if digest authentication is used, but that's 835 rare. ]] 837 Authors' Addresses 839 Stephen Farrell 840 Trinity College Dublin 841 Dublin, 2 842 Ireland 844 Phone: +353-1-896-2354 845 Email: stephen.farrell@cs.tcd.ie 847 Paul Hoffman 848 VPN Consortium 850 Email: paul.hoffman@vpnc.org 852 Michael Thomas 853 Phresheez 855 Email: mike@phresheez.com