idnits 2.17.1 draft-ietf-httpauth-hoba-03.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2014) is 3661 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-22 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 3 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: Experimental P. Hoffman 5 Expires: October 20, 2014 VPN Consortium 6 M. Thomas 7 Phresheez 8 April 18, 2014 10 HTTP Origin-Bound Authentication (HOBA) 11 draft-ietf-httpauth-hoba-03 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 any 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. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 20, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5 60 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7 61 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 8 62 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9 63 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9 64 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 9 66 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 10 67 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11 68 6.2. Associating Additional Keys to an Exiting Account . . . . 13 69 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 13 70 6.2.2. One time password . . . . . . . . . . . . . . . . . . 13 71 6.2.3. Out of band . . . . . . . . . . . . . . . . . . . . . 14 72 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 14 73 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 14 74 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 14 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8.1. localStorage Security for Javascript . . . . . . . . . . 15 77 8.2. Multiple Accounts on One User Agent . . . . . . . . . . . 16 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 16 80 9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . 16 81 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 16 82 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 17 83 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 17 84 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 12.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 19 90 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 93 1. Introduction 95 [[ Commentary is in double-square brackets, like this. Fewer things 96 this time.]] 97 HTTP Origin-Bound Authentication (HOBA) is an authentication design 98 that can be used as an HTTP authentication scheme 99 [I-D.ietf-httpbis-p7-auth] and for Javascript-based authentication 100 embedded in HTML. The main goal of HOBA is to offer an easy-to- 101 implement authentication scheme that is not based on passwords, but 102 that can easily replace HTTP or HTML forms-based password 103 authentication. Deployment of HOBA can reduce or eliminate password 104 entries in databases, with potentially significant security benefits. 106 HOBA is an HTTP authentication mechanism that complies with the 107 framework for such schemes [I-D.ietf-httpbis-p7-auth]. As a 108 JavaScript design, HOBA demonstrates a way for clients and servers to 109 interact using the same credentials that are used by the HTTP 110 authentication scheme. 112 Current HTTP authentication methods (Basic and Digest), as well as 113 username/password authentication using web forms, have been in use 114 for many years, but being based on passwords, are susceptible to 115 theft of server-side databases. Instead of passwords, HOBA uses 116 digital signatures as an authentication mechanism. HOBA also adds 117 useful features such as credential management and session logout. In 118 HOBA, the client creates a new public-private key pair for each host 119 ("web-origin" [RFC6454]) to which it authenticates. These keys are 120 used in HOBA for HTTP clients to authenticate themselves to servers 121 in the HTTP protocol or in a Javascript authentication program. 123 Session management with HOBA is identical to username/password 124 session management. Typically, the session management tool (such as 125 PHP, Python CGI, and so on) inserts a session cookie into the output 126 to the browser. HOBA does nothing to help or hurt session cookie 127 hijacking; TLS is still required for that. If the authentication is 128 not bound to HTTP sessions, even TLS cannot help against all attacks. 130 HOBA keys are "bare keys", so there is no need for the semantic 131 overhead of PKIX certificates, particularly with respect to naming 132 and trust anchors. The client public key ("CPK") structures in HOBA 133 do not have any publicly-visible identifier for the user who 134 possesses the corresponding private key, nor the web-origin with 135 which the client is using the CPK. 137 HOBA also defines some services that are required for modern HTTP 138 authentication: 140 o Servers can bind a CPK with an identifier, such as an account 141 name. Servers using HOBA define their own policies for binding 142 CPKs with accounts during account registration. 144 o Users are likely to use more than one device or user agent (UA) 145 for the same HTTP based service, so HOBA gives a way to associate 146 more than one CPK to the same account, but without having to 147 register for each separately. 149 o Users are also likely to lose a private key, or the client's 150 memory of which key pair is associated with which origin, such as 151 when a user loses the computer or mobile device in which state is 152 stored. HOBA allows for clients to tell servers to delete the 153 association between an existing CPK and an account. 155 o Logout features can be useful for UAs, so HOBA defines a way to 156 close a current HTTP "session", and also a way to close all 157 current sessions, even if more than one session is currently 158 active from different UAs for the same account. 160 o Since there are always devices and applications in which state of 161 the art digital signature mechanism runtimes are significant, and 162 since HTTP authentication in theory requires that every HTTP 163 request to a given realm have a signature in an "Authorization" 164 header field, and since HOBA is a challenge response scheme, we 165 also define a way in which HTTP servers can indicate the duration 166 for which they will consider a given challenge value to be valid. 167 As a consequence we also define a way for UAs to fetch a fresh 168 challenge. 170 1.1. Interfacing to Applications (Cookies) 172 HOBA can be used as a drop-in replacement for password-based user 173 authentication schemes used in common web applications. The simplest 174 way in which this can be done is to (re-)direct the UA to a HOBA 175 "Login" URL and for the response to a successful HTTP request 176 containing a HOBA signature to set a session cookie [RFC6265]. 177 Further interactions with the web application will then be secured 178 via the session cookie, as is commonly done today. 180 While cookies are bearer tokens, and thus weaker than HOBA 181 signatures, they are currently ubiquitously used. If non-bearer 182 token session continuation schemes are developed in future in the 183 IETF or elsewhere, then those can interface to HOBA as easily as with 184 any password based authentication scheme. 186 1.2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 A client public key ("CPK") is the public key and associated 193 cryptographic parameters needed for a server to validate a signature. 195 The term "account" is (loosely) used to refer to whatever data 196 structure(s) the server maintains that are associated with an 197 identity. That will contain of at least one CPK and a web-origin; it 198 will also optionally include an HTTP "realm" as defined in the HTTP 199 authentication specification. It might also involve many other non- 200 standard pieces of data that the server accumulates as part of 201 account creation processes. An account may have many CPKs that are 202 considered equivalent in terms of being usable for authentication, 203 but the meaning of "equivalent" is really up to the server and is not 204 defined here. 206 When describing something that is specific to HOBA as an HTTP 207 authentication mechanism or HOBA as a JavaScript implementation, this 208 document uses the terms "HOBA-http" and "HOBA-js", respectively. 210 Web client: the content and javascript code that run within the 211 context of a single UA instance (such as a tab in a web browser). 213 User agent (UA): typically, but not always, a web browser. 215 User: a person who is running a UA. In this document, "user" does 216 not mean "user name" or "account name". 218 This specification uses the Augmented Backus-Naur Form (ABNF) 219 notation of [RFC5234] 221 2. The HOBA Authentication Scheme 223 A UA that implements HOBA maintains a list of web-origins and realms. 224 The UA also maintains one or more client credentials for each web- 225 origin/realm combination for which it has created a CPK. 227 On receipt of a challenge (and optional realm) from a server, the 228 client marshals an HOBA to-be-signed (TBS) blob that includes a 229 client generated nonce, the web-origin, the realm, an identifier for 230 the CPK and the challenge string; and signs that hashed blob with the 231 private key corresponding to the CPK for that web-origin. The 232 formatting chosen for this TBS blob is chosen so as to make server- 233 side signature verification as simple as possible for a wide range of 234 current server tooling. 236 Figure 1 specifies the ABNF for the signature input. The term 237 "unreserved" means that the field does not have a specific format 238 defined. 240 HOBA-TBS = nonce alg origin [ realm ] kid challenge 241 nonce = unreserved 242 alg = 1*2DIGIT 243 origin = scheme "://" authority ":" port 244 realm = unreserved 245 kid = unreserved 246 challenge = unreserved 248 Figure 1: To-be-signed data for HOBA 250 The fields above contain the following: 252 o nonce: is a random value chosen by the UA and MUST be base64url 253 encoded before being included in the HOBA-TBS value. (base64url 254 encoding is defined in [RFC4648].) UAs MUST be able to use at 255 least 32 bits of randomness in generating a nonce. UAs SHOULD be 256 able to use 64 or more bits of randomness for nonces. 258 o alg: specifies the signature algorithm being used encoded as an 259 ASCII character as defined in Section 9.3. RSA-SHA256 MUST be 260 supported, RSA-SHA1 MAY be supported. The IANA registered 261 algorithm values are encoded as ASCII numbers; for example, the 262 encoding of RSA-SHA256 is 0x30. 264 o origin: is the web origin expressed as the concatenation of the 265 scheme, authority and port from [RFC3986]. These are not base64 266 encoded as they will be most readily available to the server in 267 plain text. For example, if accessing the URL "https:// 268 www.example.com:8080/foo" then the bytes input to the signature 269 process will be "https://www.example.com:8080". There is no 270 default for the port number, and the port number MUST be present. 272 o realm: is similarly just a string with the syntactic restrictions 273 defined in [I-D.ietf-httpbis-p7-auth]. If no realm is specified 274 for this authentication then this is absent. (A missing field 275 here is no problem since both sides know when it needs to be 276 there.) 278 o kid: is a key identifier - this MUST be a base64url encoded value 279 that is presented to the server in the HOBA client result (see 280 below). 282 o challenge: MUST be a base64url encoded challenge value that the 283 server chose to send to the client 285 The HOBA-TBS string is the input to the client's signing process, but 286 is not itself sent over the network since some fields are already 287 inherent in the HTTP exchange. The challenge however is sent over 288 the network so as to make it simpler for a server to be stateless. 289 (One form of stateless challenge might be a ciphertext that the 290 server decrypts and checks, but that is an implementation detail.) 291 The value that is sent over the network is the HOBA "client result" 292 which we now define. 294 The HOBA "client result" is a dot-separated string that includes the 295 signature and is sent in the HTTP Authorized header field value using 296 the value syntax defined in Figure 2. The "sig" value is the 297 base64url encoded version of the binary output of the signing 298 process. The kid, challenge and nonce are as defined above and are 299 also base64url encoded. 301 HOBA-RES = kid "." challenge "." nonce "." sig 302 sig = unreserved 304 Figure 2: HOBA Client Result value 306 The HOBA scheme is far from new, for example, the basic idea is 307 pretty much identical to the first two messages from "Mechanism R" on 308 page 6 of [MI93] which predates HOBA by 20 years. 310 3. Introduction to the HOBA-http Mechanism 312 An HTTP server that supports HOBA authentication includes the "HOBA" 313 auth-scheme value in a WWW-Authenticate header field when it wants 314 the client to authenticate with HOBA. Note that the HOBA auth-scheme 315 might not be the only one that the server includes in a WWW- 316 Authenticate. 318 o If the "HOBA" scheme is listed, it MUST be followed by two or more 319 auth-param values. The auth-param attributes defined by this 320 specification are below. Other auth-param attributes MAY be used 321 as well. Unknown auth-param attributes MUST be ignored by 322 clients, if present. 324 o The "challenge" attribute MUST be included. The challenge is the 325 string made up of the base64url encoded octets that the server 326 wants the client to sign in its response. The challenge SHOULD be 327 unique for every HTTP 401 response in order to prevent replay 328 attacks from passive observers. 330 o An "expires" attribute MUST be included that specifies the number 331 of seconds from the time the HTTP response is emitted for which 332 responses to this challenge can be accepted. 334 o A "realm" attribute MAY be included to indicate the scope of 335 protection in the manner described in HTTP/1.1, Part 7 336 [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear 337 more than once. 339 When the "client response" is created, the UA encodes the HOBA 340 client-result (a string matching the HOBA-RES production in Figure 2 341 as an auth-param with the name "result" and returns that in the 342 Authorization header. 344 The server MUST check the cryptographic correctness of the signature 345 based on a public key it knows for the kid in the signatures, and if 346 the server cannot do that, or if the signature fails cryptographic 347 checks, then validation has failed. The server can use any 348 additional mechanisms to validate the signature. If the validation 349 fails, or if the server chooses reject the signature for any reason 350 whatsoever, the server aborts the transaction via a 403 Forbidden 351 HTTP response. [[ This maybe should be 401 Unauthorized. ]] 353 Note that a HOBA signature is good for however long the expires 354 attribute allows. This means that replay is possible within the time 355 window specified by the "expires" value chosen by the server. 356 Servers can attempt to detect any such replay and MAY react to such 357 replays by responding with a second (or subsequent) 401-status HTTP 358 response containing a new challenge. [[ How could such detection be 359 done in face of cut-and-paste attacks? ]] 361 UAs MAY optimise their use of challenges by pre-fetching a challenge 362 value, for example after expires/2 seconds have elapsed, using the 363 ".well-known/hoba/getChal" scheme described later in this document. 364 This also allows for pre-calculation of HOBA signatures, if that is 365 required in order to produce a responsive user interface. 367 4. Introduction to the HOBA-js Mechanism 369 Web sites using JavaScript can also perform origin-bound 370 authentication without needing to involve the HTTP layer, and by 371 inference not needing HOBA-http support in browsers. HOBA-js is not 372 an on-the-wire protocol like HOBA-http is: instead, it is a design 373 pattern that can be realized completely in JavaScript served in 374 normal HTML pages. 376 One element is required for HOBA-js: localStorage (see http:// 377 www.w3.org/TR/webstorage/) from HTML5. is used for persistent key 378 storage. For example, an implementation would store a dictionary 379 account identifier, public key, private key tuples in the origin's 380 localStorage for subsequent authentication requests. How this 381 information is actually stored in localStorage is an implementation 382 detail. This type of key storage relies on the security properties 383 of the same-origin policy that localStorage enforces. See the 384 security considerations for discussion about attacks on localStorage. 386 Because of JavaScript's same-origin policy, scripts from subdomains 387 do not have access to the same localStorage that scripts in their 388 parent domains do. For larger or more complex sites, this could be 389 an issue that requires enrollment into subdomains, which could be a 390 hassle for users. One way to get around this is to use session 391 cookies because they can be used across subdomains. That is, with 392 HOBA-js, the user might log in using a single well-known domain, and 393 then the server uses session cookies to navigate around a site. 395 Another element will be highly desirable for HOBA-js when it becomes 396 available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In 397 lieu of WebCrypto, JavaScript crypto libraries can be employed with 398 the known deficiencies of PRNG, and the general immaturity of those 399 libraries. 401 5. HOBA's Authentication Process 403 This section describes how clients and servers use HOBA for 404 authentication. The interaction between an HTTP client and HTTP 405 server using HOBA happens in three phases: the CPK preparation phase, 406 the signing phase, and the authentication phase. This section also 407 covers the actions that give HOBA similar user features as today's 408 passwords have. 410 5.1. CPK Preparation Phase 412 In the CPK preparation phase, the client determines if it already has 413 a CPK for the web-origin it is going to. If the client has a CPK, 414 the client will use it; if the client does not have a CPK, it 415 generates one in anticipation of the server asking for one. 417 5.2. Signing Phase 419 In the signing phase, the client connects to the server, the server 420 asks for HOBA-based authentication, and the client authenticates by 421 signing a blob of information as described in the previous sections. 423 5.3. Authentication Phase 425 The authentication phase is completely dependent on the policies and 426 practices of the server. That is, this phase involves no 427 standardized protocol in HOBA-http; in HOBA-js, there is no suggested 428 interaction template. 430 In the authentication phase, the server extracts the CPK from the 431 signing phase and decides if it recognizes the CPK. If the server 432 recognizes the CPK, the server may finish the client authentication 433 process. 435 If this stage of the process involves additional information for 436 authentication, such as asking the user which account she wants to 437 use (in the case where a UA is used for multiple accounts on a site), 438 the server can prompt the user for account identifying information or 439 the user could choose based on HTML offered by the server before the 440 401 is triggered. None of this is standardized: it all follows the 441 server's security policy and session flow. At the end of this, the 442 server probably assigns or updates a session cookie for the client. 444 During the authentication phase, if the server does not recognize the 445 CPK, it could use HTML and JavaScript to ask the user if they are 446 really a new user or want to associate this new CPK with an already- 447 joined CPK. The server can then use some out-of-band method (such as 448 a confirmation email round trip, SMS, or an UA that is already 449 enrolled) to verify that the "new" user is the same as the already- 450 enrolled one. Thus, logging in on a new user agent is identical to 451 logging in with an existing account. 453 If the server does not recognize the CPK the server might send the 454 client through a either a join or login-new-UA (see below) process. 455 This process is completely up to the server, and probably entails 456 using HTML and JavaScript to ask the user some questions in order to 457 assess whether or not the server wants to give the client an account. 458 Completion of the joining process might require confirmation by 459 email, SMS, Captcha, and so on. 461 Note that there is no necessity for the server to initiate a joining 462 or login process upon completion of the signing phase. Indeed, the 463 server may desire to challenge the UA even for unprotected resources 464 and set a session cookie for later use in a join or login process as 465 it becomes necessary. For example, a server might only want to offer 466 an account to someone who had been to a few pages on the web site; in 467 such a case, the server could use the CPK from an associated session 468 cookie as a way of building reputation for the user until the server 469 wants the user to join. 471 6. Other Parts of the HOBA Process 472 The authentication process is more than just the act of 473 authentication. In password-based authentication and HOBA, there are 474 other processes that are needed both before and after an 475 authentication step. This section covers those processes. Where 476 possible, it combines practices of HOBA-http and HOBA-js; where that 477 is not possible, the differences are called out. 479 All additional services MUST be performed in TLS-protected sessions 480 ([RFC5246]). If the current HTTP traffic is not running under TLS, a 481 new session is started before any of the actions described here are 482 performed. 484 HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for 485 performing many tasks: "https://www.example.com/.well-known/hoba". 486 These URLs are based on the name of the host that the HTTP client is 487 accessing. There are many use cases for these URLs to redirect to 488 other URLs: a site that does registration through a federated site, a 489 site that only does registration under HTTPS, and so on. Like any 490 HTTP client, HOBA-http clients MUST be able to handle redirection of 491 these URLs. [[ There are a bunch of security issues to consider 492 related to cases where a re-direct brings you off-origin. ]] 494 6.1. Registration 496 Normally, a registration (also called "joining") is expected to 497 happen after a UA receives a WWW-Authenticate for a web-origin and 498 realm (for HOBA-http) or on demand (for HOBA-js) for which it has no 499 associated CPK. The process of registration for a HOBA account on a 500 server is relatively light-weight. The UA generates a new key pair, 501 and associates it with the web-origin/realm in question. 503 Note that if the UA has a CPK associated with the web-origin, but not 504 for the realm concerned, then a new registration is REQUIRED. If the 505 server did not wish for that outcome, then it ought to use the same 506 or no realm. 508 The registration message for HOBA-http is sent as a POST message to 509 the URL ".well-known/hoba/register" with an HTML form (x-www-form- 510 encoded) described below; The registration message for HOBA-js can be 511 in any format specified by the server, but it could be the same as 512 the one described here for HOBA-http. It is up to the server to 513 decide what kind of user interaction is required before the account 514 is finally set up. 516 The registration message sent to server has one mandatory field (pub) 517 and some optional fields that allow the UA to specify the type and 518 value of key and device identifiers that the UA wishes to use. 520 o pub: is a mandatory field containing the PEM formatted public key 521 of the client. See Appendix C of [RFC6376] for an example of how 522 to generate this key format. 524 o kidtype: contains the type of key identifier, this is a numeric 525 value intended to contain one of the values from Section 9.4. If 526 this is not present then the mandatory-to-implement hashed public 527 key option MUST be used. 529 o kid: contains the key identifier as a base64url encoded string 530 that is of the type indicated in the kidtype. If the kid is a 531 hash of a public key then the correct (base64url encoded) hash 532 value MUST be provided and the server SHOULD check that and refuse 533 the registration if an incorrect value was supplied. 535 o didtype: specifies a kind of device identifier intended to contain 536 one of the values from Section 9.5, if absent then the "string" 537 form of device identifier MUST be used. 539 o did: a UTF8 string that specifies the device identifier. This can 540 be used to help a user be confident that authentication has 541 worked, e.g., following authentication some web content might say 542 "You last logged in from device 'did' at time T." 544 o curtime: the number of milliseconds since the Unix epoch, 545 formatted as [[ not yet specified ]]. This is based on the 546 expectation that the synchronization between the browser's and 547 server's clocks is sufficiently reliable. This is used to guard 548 against the replay of a legitimate registration message. The 549 server needs to have a replay cache covering a signature timeout 550 window. This might be done using a database table that is keyed 551 (in the database sense of the term) using the signature bits. If 552 the signature is in the replay table, the server will reject it. 553 If the timestamp in the signature is outside the current replay 554 cache window then it also gets rejected. 556 [[ An addition of the ability for the server to reject a client with 557 potential time skew and give it a nonce (as with HOBA-http) would 558 allow the size of the replay cache to be set to just a few minutes 559 rather than a much longer period. Or the HOBA server could always 560 use a nonce method. This is worthy of more discussion. ]]. 562 [[ A comment raised on the list was: how does the UA know that the 563 registration process has completed successfully or badly? That's not 564 yet handled. Also need to specify what happens if more data is 565 needed. ]] 567 6.2. Associating Additional Keys to an Exiting Account 569 6.2.1. Moving private keys 571 It is common for a user to have multiple UAs, and to want all those 572 UAs to be able to authenticate to a single account. One method to 573 allow a user who has an existing account to be able to authenticate 574 on a second device is to securely transport the private and public 575 keys and the origin information from the first device to the second. 576 If this approach is taken, then there is no impact on the HOBA-http 577 or HOBA-js so this is a pure UA implementation issue and not 578 discussed further. 580 6.2.2. One time password 582 To enroll a new UA using an existing UA, the user requests a one-time 583 password that will be entered in the new UA. On HOBA-http, this is 584 done with the URL ".well-known/hoba/associate-start" using a POST 585 message [[ more detail is clearly needed here ]]. The server 586 displays a one-time password that expires in a short amount of time 587 (such as 30 minutes) on the currently enrolled UA. The new UA 588 generates a new CPK and sends it to the server. In HOBA-http, this 589 is done with a POST to ".well-known/hoba/associate-finish" [[ more 590 detail needed here ]]. 592 The one-time password should be easy for a user to type into the new 593 UA, but at the same time needs to have enough randomness to prevent 594 an attacker from succeeding if they try to use the password during 595 its short lifetime. After the server gets the password in the new 596 UA, it verifies the signature and verifies that the password supplied 597 is in a list of unexpired one-time passwords. If so, the server 598 knows that the authenticated user is associated with the second CPK. 599 The server can choose to associate the two CPKs with one account. 600 Whether to do so is entirely at the server's discretion however, but 601 the server needs make the outcome clear to the user. 603 Alternatively, if an already-enrolled UA is not available to the user 604 when they want to associate a new UA with an existing account, and 605 the site has an out-of-band communication mechanism such as email or 606 SMS associated with that account, the user can request that a one- 607 time password be sent to the user out of band. The user receives the 608 one-time password and, using the new UA, tells it to the server. On 609 HOBA-http, this is done with the URL ".well-known/hoba/associate- 610 from-oob" using a POST message [[ more detail is clearly needed here 611 ]]. 613 [[ Note: the hoba.ie implementation doesn't do this - I omitted a 614 human memorable OTP for now. The reason is I think the probability 615 that spammers would try those is too high. So maybe we should delete 616 this entirely? ]] 618 6.2.3. Out of band 620 There are various other ways in which a server can provide ways to 621 allow a new UA to be registered to the same account. For example, 622 simply providing a web page where, using the first UA, the user can 623 generate a URL (containing some cryptographic value) that the user 624 then later de-references on the second UA would suffice. The user 625 could have e-mail that URL to herself for example, of the web server 626 accessed at the first UA could automatically do that. 628 [[ Need to think about how much detail to put in here. Its all 629 fairly obvious, but we probably should talk about the security 630 considerations. The hoba.ie site btw has a few of these methods 631 implemented. ]] 633 6.3. Logging Out 635 The user can tell the server it wishes to log out. With HOBA-http, 636 this is done by going to the URL ".well-known/hoba/logout". The UA 637 SHOULD also delete session cookies associated with the session so 638 that the user's state is no longer "logged in." 640 The server MUST NOT allow TLS session resumption for any logged out 641 session. [[ Need to determine if this is needed or even a good idea. 642 ]] 644 The server SHOULD also revoke or delete any cookies associated with 645 the session. 647 6.4. Getting a Fresh Challenge 649 The UA can get a "fresh" challenge from the server. In HOBA-http, it 650 sends a POST message to ".well-known/hoba/getchal". If successful, 651 the response response MUST include a fresh (base64url encoded) HOBA 652 challenge for this origin in the body of the response. 654 7. Mandatory-to-Implement Algorithms 656 RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus 657 lengths of at least 2048 bits SHOULD be used. 659 8. Security Considerations 661 If key binding was server-selected then a bad actor could bind 662 different accounts belonging to the user from the network with 663 possible bad consequences, especially if one of the private keys was 664 compromised somehow. 666 Binding my CPK with someone else's account would be fun and 667 profitable so SHOULD be appropriately hard. In particular the string 668 generated by the server MUST be hard to guess, for whatever level of 669 difficulty is chosen by the server. The server SHOULD NOT allow a 670 random guess to reveal whether or not an account exists. 672 [[ The potential impact on privacy of HOBA needs to be addressed. If 673 a site can use a 401 and a CPK to track users without permission that 674 would be not-so-nice so some guidance on how a UA could indicate to a 675 user that HOBA stuff is going on might be needed. Any authentication 676 mechanism allows tracking within account. ]] 678 [[ Lots more TBD, be nice to your private keys etc. etc. ]] 680 8.1. localStorage Security for Javascript 682 Our use of localStorage will undoubtedly be a cause for concern. 683 localStorage uses the same-origin model which says that the scheme, 684 domain and port define a localStorage instance. Beyond that, any 685 code executing will have access to private keying material. Of 686 particular concern are XSS attacks which could conceivably take the 687 keying material and use it to create UAs under the control of an 688 attacker. But XSS attacks are in reality across the board 689 devastating since they can and do steal credit card information, 690 passwords, perform illicit acts, etc, etc. It's not clear that we 691 introduce unique threats from which clear text passwords don't 692 already suffer. 694 Another source of concern is local access to the keys. That is, if 695 an attacker has access to the UA itself, they could snoop on the key 696 through a javascript console, or find the file(s) that implement 697 localStorage on the host computer. Again it's not clear that we are 698 worse in this regard because the same attacker could get at browser 699 password files, etc too. One possible mitigation is to encrypt the 700 keystore with a password/pin the user supplies. This may sound 701 counter intuitive, but the object here is to keep passwords off of 702 servers to mitigate the multiplier effect of a large scale compromise 703 ala LinkedIn because of shared passwords across sites. 705 It's worth noting that HOBA uses asymmetric keys and not passwords 706 when evaluating threats. As various password database leaks have 707 shown, the real threat of a password breach is not just to the site 708 that was breached, it's all of the sites a user used the same 709 password on too. That is, the collateral damage is severe because 710 password reuse is common. Storing a password in localStorage would 711 also have a similar multiplier effect for an attacker, though perhaps 712 on a smaller scale than a server-side compromise: one successful 713 crack gains the attacker potential access to hundreds if not 714 thousands of sites the user visits. HOBA does not suffer from that 715 attack multiplier since each asymmetric key pair is unique per site/ 716 UA/user. 718 8.2. Multiple Accounts on One User Agent 720 A shared UA with multiple accounts is possible if the account 721 identifier is stored along with the asymmetric key pair binding them 722 to one another. Multiple entries can be kept, one for each account, 723 and selected by the current user. This, of course, is fraught with 724 the possibility for abuse, since a server is potentially enrolling 725 the device for a long period and the user may not want to have to be 726 responsible for the credential for that long. To alleviate this 727 problem, the user can request that the credential be erased from the 728 browser. Similarly, during the enrollment phase, a user could 729 request that the key pair only be kept for a certain amount of time, 730 or that it not be stored beyond the current browser session. 732 9. IANA Considerations 734 9.1. HOBA Authentication Scheme 736 Authentication Scheme Name: HOBA 738 Pointer to specification text: [[ this document ]] 740 Notes (optional): The HOBA scheme can be used with either HTTP 741 servers or proxies. [[ Still need to figure out what it means to do 742 this through proxies. ]] 744 9.2. .well-known URLs 746 We probably want a new registry for the labels beneath .well-known/ 747 hoba so that other folks can add additional features in a controlled 748 way, e.g. for CPK/account revocation or whatever. 750 9.3. Algorithm Names 752 TBD, hopefully re-use and existing registry 754 "0" means RSA-SHA256 756 "1" means RSA-SHA1 758 [[ Will most likely add an elliptic curve signature mechanism. ]] 760 9.4. Key Identifier Types 762 "0" means a hashed public key, as done in DANE. [RFC6698] 764 "1" means a URI, such as a mailto: or acct: URI, but anything 765 conforming to [RFC3986] is ok.i 767 "2" means an unformatted string, at the user's/UA's whim 769 9.5. Device Identifier Types 771 "0" means an unformatted nickname, at the user's/UA's whim 773 10. Implementation Status 775 [[ Note to RFC editor - please delete this section before 776 publication. ]] 778 This section records the status of known implementations of the 779 protocol defined by this specification at the time of posting of this 780 Internet-Draft, and is based on a proposal described in [RFC6982]. 781 The description of implementations in this section is intended to 782 assist the IETF in its decision processes in progressing drafts to 783 RFCs. Please note that the listing of any individual implementation 784 here does not imply endorsement by the IETF. Furthermore, no effort 785 has been spent to verify the information presented here that was 786 supplied by IETF contributors. This is not intended as, and must not 787 be construed to be, a catalog of available implementations or their 788 features. Readers are advised to note that other implementations may 789 exist. 791 According to [RFC6982] "this will allow reviewers and working groups 792 to assign due consideration to documents that have the benefit of 793 running code, by considering the running code as evidence of valuable 794 experimentation and feedback that has made the implemented protocols 795 more mature. It is up to the individual working groups to use this 796 information as they see fit". 798 At the time of writing there are two known implementations. One done 799 by Stephen Farrell of HOBA-HTTP and a HOBA-JS variant implements the 800 -01 version of HOBA and is available from https://hoba.ie/ which site 801 also includes a demonstration of HOBA. 803 There is another implementation by Michael Thomas of an HOBA-JS 804 variant. 806 11. Acknowledgements 807 Thanks to the following for good comments received during the 808 preparation of this specification: Julian Reschke, James Manger, 809 Michael Sweet, Ilari Liusvaara, [[ and many more to be added ]]. All 810 errors and stupidities are of course the editors' fault. 812 12. References 814 12.1. Normative References 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, March 1997. 819 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 820 Resource Identifier (URI): Generic Syntax", STD 66, RFC 821 3986, January 2005. 823 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 824 Specifications: ABNF", STD 68, RFC 5234, January 2008. 826 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 827 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 829 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 830 Uniform Resource Identifiers (URIs)", RFC 5785, April 831 2010. 833 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 834 2011. 836 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 837 of Named Entities (DANE) Transport Layer Security (TLS) 838 Protocol: TLSA", RFC 6698, August 2012. 840 12.2. Informative References 842 [I-D.ietf-httpbis-p7-auth] 843 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 844 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22 845 (work in progress), February 2013. 847 [MI93] Mitchell, and Thomas, "Standardising Authentication 848 Protocols Based on Public-Key Techniques.", Journal of 849 Computer Security 2 (1993): 23-36. , 1993. 851 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 852 Encodings", RFC 4648, October 2006. 854 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 855 April 2011. 857 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 858 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, July 859 2013. 861 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 862 Code: The Implementation Status Section", RFC 6982, July 863 2013. 865 Appendix A. Problems with Passwords 867 By far the most common mechanism for web authentication is passwords 868 that can be remembered by the user, called "memorizable passwords". 869 There is plenty of good research on how users typically use 870 memorizable passwords ([[ handful of citations goes here ]]), but 871 some of the highlights are that users typically try hard to reuse 872 passwords on as many web sites as possible, and that web sites often 873 use either email addresses or users' names as the identifier that 874 goes with these passwords. 876 If an attacker gets access to the database of memorizable passwords, 877 that attacker can impersonate any of the users. Even if the breach 878 is discovered, the attacker can still impersonate users until every 879 password is changed. Even if all the passwords are changed or at 880 least made unusable, the attacker now possesses a list of likely 881 username/password pairs that might exist on other sites. 883 Using memorizable passwords on unencrypted channels also poses risks 884 to the users. If a web site uses either the HTTP Plain 885 authentication method, or an HTML form that does no cryptographic 886 protection of the password in transit, a passive attacker can see the 887 password and immediately impersonate the user. If a hash-based 888 authentication scheme such as HTTP Digest authentication is used, a 889 passive attacker still has a high chance of being able to determine 890 the password using a dictionary of known passwords. 892 [[ Say a bit about non-memorizable passwords. Still subject to 893 database attack, although that doesn't give the attacker knowledge 894 for other systems. Safe if digest authentication is used, but that's 895 rare. ]] 897 Appendix B. Examples 899 [[ Will add more later and probably use example.org. Note these 900 still use the -01 version of the "origin" abnf production. ]] 902 The following values show an example of HOBA-HTTP authentication to 903 the origin https://hoba-local.ie. Carriage-returns have been added 904 and need to be removed to validate the example. 906 -----BEGIN PRIVATE KEY----- 907 MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDNF6tZUbsM7ZrO 908 5Lyzvn15lJAfOz7j7xdc3hmeSOfh/DCiJWwE5qqffrOvOvXYN+qUTlsXPeBYdrz/ 909 my0YYC02u2QFhDbFRvpM/EuMzZUWTQzkKyU7nSjtPqlLZJJ/Rh6PnjTgImoIMn92 910 JZgJZgl/vzd29K5Z94JzdJ4Z5bNmQ/gCpjlv0Wvi+GpJ3lDo1csDEyxATxyTUx1J 911 K73+/RPoNgUF9nrXN6kqeH7RkERRz+PFhfGM6r3tU5povJxOP0bzVl6R4kptWLn2 912 GqDb5LS9iwzsk6YHWQcLOIAMVZ9ITPN2PSuQX0ym81B9qB1V6fTfo2r0Yo1Djn6C 913 YRX62p4dAgMBAAECggEBAJiyWLcFrPhxJ2OG1iAVYaJVxAAcwjQ+XOydyAEbUtnk 914 Q+lVZ1k2zC43zVxXz5aN+y80L4ncXd4/eXPteuO9J6yqVEvvJkA3GkCbTzykC64w 915 67otjWkXF9ObZbxmQtRTxokzRzbhKIS15ER4tPu6ZrQgEBGXFwCQ0SVY3CV36dvm 916 xU2Y90wf98BGQF5VO47S9h8N/VtBn1ttI/6BhQHGsM+TbRR0b6oT9Mp/kqh5jZ2P 917 dH/l7Q6aj6zeFYljvI6HUpjc0mVOSKPAO0qYLZNYC0sqXxW9vCtEODziFZwrO2tL 918 jm14/H8+AZvtR6ZvbzP8h3G95PNdG4Z1eGZv5pOoJoECgYEA8omsyssjVgLIon60 919 Q6h3EjOi8I+mfvXYXcAZhv/1MnojFZgMLmuZ13Lgi3dIHYFNYGFRi8g9iYU/Ljtf 920 G3B9o6PQsvL0yym85TZzF/yn+kbinHR2yQUiA1Ck1rnrFx8dla/BjAplPxumyh/z 921 HyNFplVbOeRQS4K5F72wScuB9DECgYEA2Hnq1OSLetl4lrGAEHDoiIKw++ACQ/Tn 922 w5O+xAxOXr9iOmczwpHls+zFSQHty4za8C/tBLxg6HCHKZSO4lh+p5SR21UNgwfr 923 X6xBZ4xoH9zHTFdD2yrHdxAoItdT5oMTAUNHxDS8kcSY1+YcjRs2T4kcONIxeBlp 924 O++dxK9I6a0CgYEAp52WGSCCbzLFTeea1RdcEuw0s2PTgPKOcVwNSEskPZpDHO1T 925 ndEnJMpzfG8XG6z8uJsJLD1aqeu4Wk8Vz3TSn4Da/pEBtFZIAXC74dvuivzqJ44l 926 eY9ejkPxZ6RdYEFUxNoOPKYCiralchLahq5tuCJNRZkQFN9m441og9dtHEECgYEA 927 qnvRqlpXUqfEZYFi5w/UwfWTJrozbouInylTOpiqe8njtTUjuV8ndPzKHoYrXXwP 928 zMshsfIdq9E7UU7S/IVPMfE6sW6ZVpE9GDrTw5X7RuSb/I5ZPVjCgA00XsQQKmEd 929 7YesFGSoAXDAIn/yClrc+eR0WneHSBtTGkXKjWSyWn0CgYAlHdG3wj/sOL+JI7p8 930 fgSoRpkrbjfrczqSCDVFbT84sUz3dXObZecrI3v0XUZySakIDha5ZbxXNST/bfea 931 kReKsoeFY9J7os0hbfGwxiCQwD3wN9tS2yJbJYl1mCFc45YfylkXBzB0S2V/i6rv 932 vCWW1nijRb+WhpUF8HyKW64bxA== 933 -----END PRIVATE KEY----- 935 Key Identifier: Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vqWw 937 Challenge: zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0= 939 Nonce: xXSFdZ-7ahM 941 Tbsorigin: httpshoba-local.ie443 943 The resulting signature is: 945 r1ZXAWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfo 946 K__W_Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hK 947 t4bCtP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19J 948 LTUyaisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7 949 qf6lORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq 950 8meaqRXMhoQWHGLweFTNYw 952 The final HTTP header field sent with a request is then: 954 Authorization: result="Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vq 955 Ww.zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0=.xXSFdZ-7ahM.r1ZX 956 AWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfoK__W 957 _Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hKt4bC 958 tP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19JLTUy 959 aisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7qf6l 960 ORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq8mea 961 qRXMhoQWHGLweFTNYw" 963 Authors' Addresses 965 Stephen Farrell 966 Trinity College Dublin 967 Dublin 2 968 Ireland 970 Phone: +353-1-896-2354 971 Email: stephen.farrell@cs.tcd.ie 973 Paul Hoffman 974 VPN Consortium 976 Email: paul.hoffman@vpnc.org 978 Michael Thomas 979 Phresheez 981 Email: mike@phresheez.com