idnits 2.17.1 draft-ietf-httpauth-hoba-10.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 (January 8, 2015) is 3396 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 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: July 12, 2015 VPN Consortium 6 M. Thomas 7 Phresheez 8 January 8, 2015 10 HTTP Origin-Bound Authentication (HOBA) 11 draft-ietf-httpauth-hoba-10 13 Abstract 15 HTTP Origin-Bound Authentication (HOBA) is a digital signature based 16 design for an HTTP authentication method. The design can also be 17 used in Javascript-based authentication embedded in HTML. HOBA is an 18 alternative to HTTP authentication schemes that require passwords and 19 therefore avoids all problems related to passwords, such as leakage 20 of server-side password databases. 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 July 12, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Step-by-step Overview of HOBA-http . . . . . . . . . . . 5 60 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 6 61 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 8 62 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 10 63 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 11 64 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 11 65 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 11 66 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 11 67 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 12 68 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 13 69 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 14 70 6.2. Associating Additional Keys to an Existing Account . . . 16 71 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 16 72 6.2.2. Human memorable one time password (don't do this one) 16 73 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 17 74 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 17 75 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 17 76 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 17 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 18 79 8.2. localStorage Security for Javascript . . . . . . . . . . 19 80 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 20 81 8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 20 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 21 84 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 21 85 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 21 86 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 22 87 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 22 88 9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 22 89 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 93 12.2. Informative References . . . . . . . . . . . . . . . . . 25 94 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 25 95 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 26 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 98 1. Introduction 100 HTTP Origin-Bound Authentication (HOBA) is an authentication design 101 that can be used as an HTTP authentication scheme [RFC7235] and for 102 Javascript-based authentication embedded in HTML. The main goal of 103 HOBA is to offer an easy-to-implement authentication scheme that is 104 not based on passwords, but that can easily replace HTTP or HTML 105 forms-based password authentication. Deployment of HOBA can reduce 106 or eliminate password entries in databases, with potentially 107 significant security benefits. 109 HOBA is an HTTP authentication mechanism that complies with the 110 framework for such schemes [RFC7235]. As a JavaScript design, HOBA 111 demonstrates a way for clients and servers to interact using the same 112 credentials that are used by the HTTP authentication scheme. 114 Current username/password authentication methods such as HTTP Basic, 115 HTTP Digest, and web forms have been in use for many years but are 116 susceptible to theft of server-side password databases. Instead of 117 passwords, HOBA uses digital signatures in a challenge-response 118 scheme as it's authentication mechanism. HOBA also adds useful 119 features such as credential management and session logout. In HOBA, 120 the client creates a new public-private key pair for each host ("web 121 origin" [RFC6454]) to which it authenticates. These keys are used in 122 HOBA for HTTP clients to authenticate themselves to servers in the 123 HTTP protocol or in a Javascript authentication program. 125 HOBA session management is identical to username/password session 126 management, with a server-side session management tool or script 127 inserting a session cookie [RFC6265] into the output to the browser. 128 Use of TLS for the HTTP session is still necessary to prevent session 129 cookie hijacking. 131 HOBA keys are "bare keys", so there is no need for the semantic 132 overhead of X.509 public key certificates, particularly with respect 133 to naming and trust anchors. The client public key ("CPK") 134 structures in HOBA do not have any publicly-visible identifier for 135 the user who possesses the corresponding private key, nor the web- 136 origin with which the client is using the CPK. 138 HOBA also defines some services that are needed for modern HTTP 139 authentication: 141 o Servers can bind a CPK with an identifier, such as an account 142 name. Servers using HOBA define their own policies for binding 143 CPKs with accounts during account registration. 145 o Users are likely to use more than one device or user agent (UA) 146 for the same HTTP based service, so HOBA gives a way to associate 147 more than one CPK to the same account, but without having to 148 register for each separately. 150 o Logout features can be useful for UAs, so HOBA defines a way to 151 close a current HTTP "session." 153 o Digital signatures can be expensive to compute, so HOBA defines a 154 way for HTTP servers to indicate how long a given challenge value 155 is valid, and a way for UAs to fetch a fresh challenge at any 156 time. 158 Users are also likely to lose a private key, or the client's memory 159 of which key pair is associated with which origin, such as when a 160 user loses the computer or mobile device in which state is stored. 161 HOBA does not define a mechanism for deleting the association between 162 an existing CPK and an account. Such a mechanism can be implemented 163 at the application layer. 165 The HOBA scheme is far from new, for example, the basic idea is 166 pretty much identical to the first two messages from "Mechanism R" on 167 page 6 of [MI93] which predates HOBA by 20 years. 169 1.1. Interfacing to Applications (Cookies) 171 HOBA can be used as a drop-in replacement for password-based user 172 authentication schemes used in common web applications. The simplest 173 way is to (re-)direct the UA to a HOBA "Login" URL and for the 174 response to a successful HTTP request containing a HOBA signature to 175 set a session cookie [RFC6265]. Further interactions with the web 176 application will then be secured via the session cookie, as is 177 commonly done today. 179 While cookies are bearer tokens, and thus weaker than HOBA 180 signatures, they are currently ubiquitously used. If non-bearer 181 token session continuation schemes are developed in future in the 182 IETF or elsewhere, then those can interface to HOBA as easily as with 183 any password based authentication scheme. 185 1.2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in RFC 190 2119 [RFC2119]. 192 This specification uses the Augmented Backus-Naur Form (ABNF) 193 notation of [RFC5234]. 195 Account: The term "account" is (loosely) used to refer to whatever 196 data structure(s) the server maintains that are associated with an 197 identity. That will contain 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 [RFC7235]. It might also involve many 200 other non-standard pieces of data that the server accumulates as part 201 of account creation processes. An account may have many CPKs that 202 are considered equivalent in terms of being usable for 203 authentication, but the meaning of "equivalent" is really up to the 204 server and is not defined here. 206 Client public key ("CPK"): A CPK is the public key and associated 207 cryptographic parameters needed for a server to validate a signature. 209 HOBA-http: We use this term when describing something that is 210 specific to HOBA as an HTTP authentication mechanism. 212 HOBA-js: We use this term when describing something that is unrelated 213 to HOBA-http but is relevant for HOBA as a design pattern that can be 214 implemented in a browser in JavaScript. 216 User agent (UA): typically, but not always, a web browser. 218 User: a person who is running a UA. In this document, "user" does 219 not mean "user name" or "account name". 221 Web client: the content and javascript code that run within the 222 context of a single UA instance (such as a tab in a web browser). 224 1.3. Step-by-step Overview of HOBA-http 226 Step-by-step, a typical HOBA-http registration and authentication 227 flow might look like this: 229 1. The client connects to the server and makes a request, and the 230 server's response includes a WWW-Authenticate header field that 231 contains the "HOBA" auth-scheme, along with associated parameters 232 (see Section 3). 234 2. If the client was not already registered with the web-origin and 235 realm it is trying to access, the "joining" process is invoked 236 (see Section 6.1). This creates a key pair and makes the CPK 237 known to the server so that the server can carry out the account 238 creation processes required. 240 3. The client uses the challenge from the HOBA auth-scheme 241 parameters, along with other information it knows about the web- 242 origin and realm, to create and sign a HOBA-TBS string (see 243 Section 2). 245 4. The client creates a HOBA client-result (HOBA-RES), using the 246 signed HOBA-TBS for the "sig" value (see Section 2). 248 5. The client includes the Authorization header field in its next 249 request, using the "HOBA" auth-scheme and putting the HOBA 250 client-result in an auth-param named "result" (see Section 3). 252 6. The server authenticates the HOBA client-result (see 253 Section 5.1). 255 7. Typically, the server's response includes a session cookie that 256 allows the client to indicate its authentication state in future 257 requests (see Section 1.1). 259 2. The HOBA Authentication Scheme 261 A UA that implements HOBA maintains a list of web-origins and realms. 262 The UA also maintains one or more client credentials for each web- 263 origin/realm combination for which it has created a CPK. 265 On receipt of a challenge (and optional realm) from a server, the 266 client marshals a HOBA to-be-signed (TBS) blob that includes a client 267 generated nonce, the web-origin, the realm, an identifier for the CPK 268 and the challenge string; and signs that blob with the private key 269 corresponding to the CPK for that web-origin. The formatting chosen 270 for this TBS blob is chosen so as to make server-side signature 271 verification as simple as possible for a wide range of current server 272 tooling. 274 Figure 1 specifies the ABNF for the signature input. The term 275 "unreserved" means that the field does not have a specific format 276 defined and allows the characters specified in Section 2.3 of 277 [RFC3986]. 279 HOBA-TBS = len ":" nonce 280 len ":" alg 281 len ":" origin 282 len ":" [ realm ] 283 len ":" kid 284 len ":" challenge 285 len = 1*DIGIT 286 nonce = 1*base64urlchars 287 alg = 1*2DIGIT 288 origin = scheme "://" authority ":" port 289 ; scheme etc are from RFC 3986 290 realm = unreserved 291 ; realm is to be treated as in Section 2.2 of RFC 7235 292 kid = 1*base64urlchars 293 challenge = 1*base64urlchars 294 ; Characters for Base64URL encoding from Table 2 of RFC 4648 295 ; all of which are US-ASCII (see RFC 20) 296 base64urlchars = %x30-39 ; Digits 297 / %x41-5A ; Uppercase letters 298 / %x61-7A ; Lowercase letters 299 / "-" / "_" / "=" ; Special characters 301 Figure 1: To-be-signed data for HOBA 303 The fields above contain the following: 305 o len: Each field is preceeded by the number of octets of the 306 following field, expressed as a decimal number in ASCII [RFC0020]. 307 Lengths are separated from field values by a colon character. So 308 if a nonce with the value "ABCD" were used then that would be 309 preceeded by "4:" (see the example in Appendix B for detail). 311 o nonce: is a random value chosen by the UA and MUST be base64url 312 encoded before being included in the HOBA-TBS value. (base64url 313 encoding is defined in [RFC4648], guidelines for randomness are 314 give in [RFC4086].) UAs MUST be able to use at least 32 bits of 315 randomness in generating a nonce. UAs SHOULD be able to use 64 or 316 more bits of randomness for nonces. 318 o alg: specifies the signature algorithm being used. See Section 7 319 for details of algorithm support requirements. 321 o The IANA registered algorithm values (see Section 9.3) are encoded 322 as one- or two-digit ASCII numbers. For example, RSA-SHA256 323 (number 0) is encoded as the ASCII character "0" (0x30), while a 324 future algorithm registered as number 17 would be encoded as the 325 ASCII characters "17" (0x3137). 327 o origin: is the web origin expressed as the concatenation of the 328 scheme, authority and port from [RFC3986]. These are not base64 329 encoded as they will be most readily available to the server in 330 plain text. For example, if accessing the URL "https:// 331 www.example.com:8080/foo" then the bytes input to the signature 332 process will be "https://www.example.com:8080". There is no 333 default for the port number, and the port number MUST be present. 335 o realm: is similarly just a string with the syntactic restrictions 336 defined in [RFC7235]. If no realm is specified for this 337 authentication then this is absent, but is preceeded by a length 338 of zero ("0:"). Recall both sides know when this needs to be 339 there, independent of the encoding via a zero length. 341 o kid: is a key identifier - this MUST be a base64url encoded value 342 that is presented to the server in the HOBA client result (see 343 below). 345 o challenge: MUST be a base64url encoded challenge value that the 346 server chose to send to the client. The challenge MUST be chosen 347 so that it is infeasible to guess, and SHOULD be indistinguishable 348 from (the base64url encoding of) an at least 128-bit long random 349 string. 351 The HOBA-TBS string is the input to the client's signing process, but 352 is not itself sent over the network since some fields are already 353 inherent in the HTTP exchange. The challenge however is sent over 354 the network so as to reduce the amount of state that needs to be 355 maintained by servers. (One form of stateless challenge might be a 356 ciphertext that the server decrypts and checks, but that is an 357 implementation detail.) The value that is sent over the network by 358 the UA is the HOBA "client result" which we now define. 360 The HOBA "client result" is a dot-separated string that includes the 361 signature and is sent in the HTTP Authorizaion header field value 362 using the value syntax defined in Figure 2. The "sig" value is the 363 base64url encoded version of the binary output of the signing 364 process. The kid, challenge and nonce are as defined above and are 365 also base64url encoded. 367 HOBA-RES = kid "." challenge "." nonce "." sig 368 sig = 1*base64urlchars 370 Figure 2: HOBA Client Result value 372 If a malformed message of any kind is received by a server, the 373 server MUST fail authenticaiton. If a malformed message of any kind 374 is received by a client, the client MUST abandon that authentication 375 attempt. (The client is of course free to start another 376 authentication attempt if it desires.) 378 3. Introduction to the HOBA-http Mechanism 379 An HTTP server that supports HOBA authentication includes the "HOBA" 380 auth-scheme value in a WWW-Authenticate header field when it wants 381 the client to authenticate with HOBA. Note that the HOBA auth-scheme 382 might not be the only one that the server includes in a WWW- 383 Authenticate header. 385 The HOBA scheme has two REQUIRED attributes (challenge and max-age) 386 and one OPTIONAL attribute (realm): 388 o The "challenge" attribute MUST be included. The challenge is the 389 string made up of the base64url encoded octets that the server 390 wants the client to sign in its response. The challenge MUST be 391 unique for every HTTP 401 response in order to prevent replay 392 attacks from passive observers. 394 o A "max-age" attribute MUST be included that specifies the number 395 of seconds from the time the HTTP response is emitted for which 396 responses to this challenge can be accepted for example "max-age: 397 10" would indicate ten seconds. If max-age is set to zero, then 398 that means that only one signature will be accepted for this 399 challenge. 401 o A "realm" attribute MAY be included to indicate the scope of 402 protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. 403 The "realm" attribute MUST NOT appear more than once. 405 When the "client response" is created, the UA encodes the HOBA 406 client-result and returns that in the Authorization header. The 407 client-result is a string matching the HOBA-RES production in Figure 408 2 as an auth-param with the name "result". 410 The server MUST check the cryptographic correctness of the signature 411 based on a public key it knows for the kid in the signatures, and if 412 the server cannot do that, or if the signature fails cryptographic 413 checks, then validation has failed. The server can use any 414 additional mechanisms to validate the signature. If the validation 415 fails, or if the server chooses reject the signature for any reason 416 whatsoever, the server fails the request with a 401 Unauthorized HTTP 417 response. 419 The server MUST check that the same web origin is used in all of the 420 server's TLS server certificates, the URL being accessed and the HOBA 421 signature. If any of those checks fail, the server treats the 422 signature as being cryptographically incorrect. 424 Note that a HOBA signature is good for however long a non-zero max- 425 age parameter allows. This means that replay is possible within the 426 time window specified by the "max-age" value chosen by the server. 428 Servers can attempt to detect any such replay (via caching if they so 429 choose) and MAY react to such replays by responding with a second (or 430 subsequent) 401-status HTTP response containing a new challenge. 432 To optimise their use of challenges, UAs MAY pre-fetch a challenge 433 value, for example after (max-age)/2 seconds have elapsed, using the 434 ".well-known/hoba/getchal" scheme described later in this document. 435 This also allows for pre-calculation of HOBA signatures, if that is 436 required in order to produce a responsive user interface. 438 4. Introduction to the HOBA-js Mechanism 440 Web sites using JavaScript can also perform origin-bound 441 authentication without needing to involve the HTTP layer, and by 442 inference not needing HOBA-http support in browsers. HOBA-js is not 443 an on-the-wire protocol like HOBA-http is: instead, it is a design 444 pattern that can be realized completely in JavaScript served in 445 normal HTML pages. 447 One thing that is highly desirable for HOBA-js is WebCrypto (see 448 http://www.w3.org/TR/WebCryptoAPI) which is (at the time of writing) 449 starting to see deployment. In lieu of WebCrypto, JavaScript crypto 450 libraries can be employed with the known deficiencies of their 451 pseudo-random number generators and the general immaturity of those 452 libraries. 454 Without Webcrypto, one element is required for HOBA-js: localStorage 455 (see http://www.w3.org/TR/webstorage/) from HTML5 can be used for 456 persistent key storage. For example, an implementation would store a 457 dictionary account identifier, public key and private key tuples in 458 the origin's localStorage for subsequent authentication requests. 459 How this information is actually stored in localStorage is an 460 implementation detail. This type of key storage relies on the 461 security properties of the same-origin policy that localStorage 462 enforces. See the security considerations for discussion about 463 attacks on localStorage. Note that IndexedDB (See http://www.w3.org/ 464 TR/IndexedDB/) is an alternative to localStorage that can also be 465 used here and that is used by WebCrypto. 467 Because of JavaScript's same-origin policy, scripts from subdomains 468 do not have access to the same localStorage that scripts in their 469 parent domains do. For larger or more complex sites, this could be 470 an issue that requires enrollment into subdomains, which could be 471 difficult for users. One way to get around this is to use session 472 cookies because they can be used across subdomains. That is, with 473 HOBA-js, the user might log in using a single well-known domain, and 474 then session cookies are used whilst the user navigates around the 475 site. 477 5. HOBA's Authentication Process 479 This section describes how clients and servers use HOBA for 480 authentication. The interaction between an HTTP client and HTTP 481 server using HOBA happens in three phases: the CPK preparation phase, 482 the signing phase, and the authentication phase. This section also 483 covers the actions that give HOBA user features similar to today's 484 password based schemes. 486 5.1. CPK Preparation Phase 488 In the CPK preparation phase, the client determines if it already has 489 a CPK for the web-origin with which it needs to authenticate. If the 490 client has a CPK, the client will use it; if the client does not have 491 a CPK, it generates one in anticipation of the server asking for one. 493 5.2. Signing Phase 495 In the signing phase, the client connects to the server, the server 496 asks for HOBA-based authentication, and the client authenticates by 497 signing a blob of information as described in the previous sections. 499 5.3. Authentication Phase 501 The authentication phase is completely dependent on the policies and 502 practices of the server. That is, this phase involves no 503 standardized protocol in HOBA-http; in HOBA-js, there is no suggested 504 interaction template. 506 In the authentication phase, the server uses the key identifier (kid) 507 to determine the CPK from the signing phase and decides if it 508 recognizes the CPK. If the server recognizes the CPK, the server may 509 finish the client authentication process. 511 If this stage of the process involves additional information for 512 authentication, such as asking the user which account she wants to 513 use (in the case where a UA is used for multiple accounts on a site), 514 the server can prompt the user for account identifying information or 515 the user could choose based on HTML offered by the server before the 516 401 response is triggered. None of this is standardized: it all 517 follows the server's security policy and session flow. At the end of 518 this, the server probably assigns or updates a session cookie for the 519 client. 521 During the authentication phase, if the server cannot determine the 522 correct CPK, it could use HTML and JavaScript to ask the user if they 523 are really a new user or want to associate this new CPK with another 524 CPK. The server can then use some out-of-band method (such as a 525 confirmation email round trip, SMS, or an UA that is already 526 enrolled) to verify that the "new" user is the same as the already- 527 enrolled one. Thus, logging in on a new user agent is identical to 528 logging in with an existing account. 530 If the server does not recognize the CPK the server might send the 531 client through a either a join or login-new-UA (see below) process. 532 This process is completely up to the server, and probably entails 533 using HTML and JavaScript to ask the user some questions in order to 534 assess whether or not the server wants to give the client an account. 535 Completion of the joining process might require confirmation by 536 email, SMS, Captcha, and so on. 538 Note that there is no necessity for the server to initiate a joining 539 or login process upon completion of the signing phase. Indeed, the 540 server may desire to challenge the UA even for unprotected resources 541 and set a session cookie for later use in a join or login process as 542 it becomes necessary. For example, a server might only want to offer 543 an account to someone who had been to a few pages on the web site; in 544 such a case, the server could use the CPK from an associated session 545 cookie as a way of building reputation for the user until the server 546 wants the user to join. 548 6. Other Parts of the HOBA Process 550 The authentication process is more than just the act of 551 authentication. In password-based authentication and HOBA, there are 552 other processes that are needed both before and after an 553 authentication step. This section covers those processes. Where 554 possible, it combines practices of HOBA-http and HOBA-js; where that 555 is not possible, the differences are called out. 557 All HOBA interactions other than those defined in Section 5 MUST be 558 performed in TLS-protected sessions ([RFC5246]). If the current HTTP 559 traffic is not running under TLS, a new session is started before any 560 of the actions described here are performed. 562 HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for 563 performing many tasks: "https://www.example.com/.well-known/hoba". 564 These URLs are based on the name of the host that the HTTP client is 565 accessing. 567 There are many use cases for these URLs to redirect to other URLs: a 568 site that does registration through a federated site, a site that 569 only does registration under HTTPS, and so on. Like any HTTP client, 570 HOBA-http clients have to be able to handle redirection of these 571 requests. However, as that would potentially cause security issues 572 when a re-direct brings the client to a different web origin, servers 573 implementing HOBA-http SHOULD NOT re-direct to a different web origin 574 from below .well-known/hoba URLs. The above is considered sufficient 575 to allow experimentation with HOBA, but if at some point HOBA is 576 placed on the standards track then a full analysis of off-origin re- 577 directions would need to be documented. 579 6.1. Registration 581 Normally, a registration (also called "joining") is expected to 582 happen after a UA receives a 401 response for a web-origin and realm 583 (for HOBA-http) or on demand (for HOBA-js) for which it has no 584 associated CPK. The process of registration for a HOBA account on a 585 server is relatively light-weight. The UA generates a new key pair, 586 and associates it with the web-origin/realm in question. 588 Note that if the UA has a CPK associated with the web-origin, but not 589 for the realm concerned, then a new registration is REQUIRED. If the 590 server did not wish for that outcome, then it ought to use the same 591 or no realm. 593 The registration message for HOBA-http is sent as a POST message to 594 the URL ".well-known/hoba/register" with an HTML form (x-www-form- 595 encoded) (see http://www.w3.org/TR/2014/REC-html5-20141028/forms.html 596 #url-encoded-form-data) described below; The registration message for 597 HOBA-js can be in any format specified by the server, but it could be 598 the same as the one described here for HOBA-http. It is up to the 599 server to decide what kind of user interaction is required before the 600 account is finally set up. When the server's chosen registration 601 flow is completed successfully the server MUST add a Hobareg HTTP 602 header (see Section 6.1.1) to the HTTP response message that 603 completes the registration flow. 605 The registration message sent to server has one mandatory field (pub) 606 and some optional fields that allow the UA to specify the type and 607 value of key and device identifiers that the UA wishes to use. 609 o pub: is a mandatory field containing the PEM formatted public key 610 of the client. See Appendix C of [RFC6376] for an example of how 611 to generate this key format. 613 o kidtype: contains the type of key identifier, this is a numeric 614 value intended to contain one of the values from Section 9.4. If 615 this is not present then the mandatory-to-implement hashed public 616 key option MUST be used. 618 o kid: contains the key identifier as a base64url encoded string 619 that is of the type indicated in the kidtype. If the kid is a 620 hash of a public key then the correct (base64url encoded) hash 621 value MUST be provided and the server SHOULD check that and refuse 622 the registration if an incorrect value was supplied. 624 o didtype: specifies a kind of device identifier intended to contain 625 one of the values from Section 9.5, if absent then the "string" 626 form of device identifier defined in Section 9.5 MUST be used. 628 o did: a UTF8 string that specifies the device identifier. This can 629 be used to help a user be confident that authentication has 630 worked, e.g., following authentication some web content might say 631 "You last logged in from device 'did' at time T." 633 Note that replay of registration (and other HOBA) messages is quite 634 possible. That however can be counteracted if challenge freshness is 635 ensured. See Section 2 for details. Note also that with HOBA-http 636 the HOBA signature does not cover the POST message body. If that is 637 required then HOBA-JS may be a better fit for registration and other 638 account management actions. 640 6.1.1. Hobareg Definition 642 Since registration can often be a multi-step process, e.g. requiring 643 a user to fill in contact details, the initial response to the HTTP 644 POST message defined above may not be the end of the registration 645 process even though the HTTP response has a 200 OK status. This 646 creates an issue for the UA since, during the registration process 647 (e.g., while dealing with interstitial pages), the UA doesn't yet 648 know whether the CPK is good for that web origin or not. 650 For this reason the server MUST add a header field to the response 651 message when the registration has succeded to indicate the new state. 652 The header to be used is "Hobareg" and the value when registration 653 has succeeded is to be "regok". When registration is in an 654 intermediate state (e.g. on an HTTP response for an interstitial 655 page) the server MAY add this header with a value of "reginwork". 656 See Section 9.6 for the relevant IANA registration of this header 657 field. 659 For interstitial pages, the client MAY include a HOBA Authorization 660 header. This is not considered a MUST as that might needlessly 661 complicate client implementations but is noted here in case a server 662 implementer assumes that all registration messages contain a HOBA 663 Authorization header. 665 Hobareg-val = "regok" / "reginwork" 667 Figure 3: Hobareg Header Field Definition 669 Figure 3 provides an ABNF definition for the values allowed in the 670 Hobareg header field. Note that these (and the header field name) 671 are case insensitive. Section 8.3.1 of [RFC7231] calls for 672 documenting the following details for this new header field: 674 o Only one single value is allowed in a Hobareg header field. 675 Should more than one (a list) be encountered or any other ANBF- 676 invalid value, that SHOULD be interpreted as being the same as 677 "reginwork." 679 o The Hobareg header field can only be used in HTTP responses. 681 o Since Hobareg is only meant for responses it ought not appear in 682 requests. 684 o The HTTP response code does affect the interpretation of Hobareg. 685 Registration is only considered to have succeeded if the regok 686 value is seen in a 2xx response. 4xx and other errors means that 687 registration has failed regardless of the value of Hobareg seen. 688 The request method has no influence on the interpretation of 689 Hobareg. 691 o Intermediaries never insert, delete or modify a Hobareg header 692 field. 694 o As a response-only header field, it is not appropriate to list a 695 Hobareg in a Vary response header field. 697 o Hobareg is allowed in trailers. 699 o As a response-only header field, Hobareg will not be preserved 700 across re-directs. 702 o Hobareg itself discloses little security or privacy sensitive 703 information. If an attacker can somehow detect that a Hobareg 704 header field is being added, then that attacker would know that 705 the UA is in the process of registration which could be 706 significant. However, it is likely that the set of messages 707 between the UA and server would expose this information in many 708 cases, regardless of whether or not TLS is used. Using TLS is 709 still however a good plan. 711 6.2. Associating Additional Keys to an Existing Account 713 From the user perspective, the UA having a CPK for a web origin will 714 often appear to be the same as having a way to sign in to an account 715 at that web site. Since users often have more than one UA, and since 716 the CPKs are, in general, UA-specific, that raises the question of 717 how the user can sign in to that account from different UAs. And 718 from the server perspective that turns into the question of how to 719 safely bind different CPKs to one account. In this section, we 720 describe some ways in which this can be done, as well as one way in 721 which this ought not be done. 723 Note that the context here is usually that the user has succeeded in 724 registering with one or more UAs (for the purposes of this section we 725 call this "the first UA" below) and can use HOBA with those, and the 726 user is now adding another UA. The newest UA might or might not have 727 a CPK for the site in question. Since it is in fact trivial, we 728 assume that the site is able to put in place some appropriate 729 quicker, easier registration for a CPK for the newest UA. The issue 730 then becomes one of binding the CPK from the newest UA with those of 731 other UAs bound to the account. 733 6.2.1. Moving private keys 735 It is common for a user to have multiple UAs, and to want all those 736 UAs to be able to authenticate to a single account. One method to 737 allow a user who has an existing account to be able to authenticate 738 on a second device is to securely transport the private and public 739 keys and the origin information from the first device to the second. 740 If this approach is taken, then there is no impact on the HOBA-http 741 or HOBA-js so this is a pure UA implementation issue and not 742 discussed further. 744 6.2.2. Human memorable one time password (don't do this one) 746 It will be tempting for implementers to use a human-memorable one- 747 time password (OTP) in order to "authenticate" binding CPKs to the 748 same account. The workflow here would likely be something along the 749 lines of some server administrative utility generating a human 750 memorable OTP such as "1234" and sending that to the user out of band 751 for the user to enter at two web pages each authenticated via the 752 relevant CPK. While this seems obvious enough and could even be 753 secure enough in some limited cases, we consider that this is too 754 risky to use in the Internet and so servers SHOULD NOT provide such a 755 mechanism. The reason this is so dangerous is that it would be 756 trivial for an automated client to guess such tokens and "steal" the 757 binding intended for some other user. At any scale, there would 758 always be some in-process bindings so that even with only a trickle 759 of guesses (and hence not being detectable via message volume) an 760 attacker would have a high probability of succeeding in registering a 761 binding with the attacker's CPK. 763 This method of binding CPKs together is therefore NOT RECOMMENDED. 765 6.2.3. Out of band URL 767 One easy binding method is to simply provide a web page where, using 768 the first UA, the user can generate a URL (containing some 769 "unguessable" cryptographically generated value) that the user then 770 later de-references on the newest UA. The user could e-mail that URL 771 to herself for example, of the web server accessed at the first UA 772 could automatically do that. 774 Such a URL SHOULD contain at least the equivalent of 128 bits of 775 randomness. 777 6.3. Logging Out 779 The user can tell the server it wishes to log out. With HOBA-http, 780 this is done by sending a HOBA-authenticated POST message to the URL 781 ".well-known/hoba/logout" on the site in question. The UA SHOULD 782 also delete session cookies associated with the session so that the 783 user's state is no longer "logged in." 785 The server MUST NOT allow TLS session resumption for any logged out 786 session. 788 The server SHOULD also revoke or delete any cookies associated with 789 the session. 791 6.4. Getting a Fresh Challenge 793 The UA can get a "fresh" challenge from the server. In HOBA-http, it 794 sends a POST message to ".well-known/hoba/getchal". If successful, 795 the response MUST contain a fresh (base64url encoded) HOBA challenge 796 for this origin in the body of the response. Whitespace in the 797 response MUST be ignored. 799 7. Mandatory-to-Implement Algorithms 801 RSA-SHA256 MUST be supported. HOBA implementations MUST use RSA- 802 SHA256 if it is provided by the underlying cryptographic libraries. 803 RSA-SHA1 MAY be used. RSA modulus lengths of at least 2048 bits 804 SHOULD be used. RSA indicates the RSASSA-PKCS1-v1_5 algorithm 805 defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are 806 defined in [SHS]. Keys with moduli shorter than 2048 bits SHOULD 807 only be used in cases where generating 2048-bit (or longer) keys is 808 impractical, e.g. on very constrained or old devices. 810 8. Security Considerations 812 Binding my CPK with someone else's account would be fun and 813 profitable so SHOULD be appropriately hard. In particular URLs or 814 other values generated by the server as part of any CPK binding 815 process MUST be hard to guess, for whatever level of difficulty is 816 chosen by the server. The server SHOULD NOT allow a random guess to 817 reveal whether or not an account exists. 819 If key binding was server-selected then a bad actor could bind 820 different accounts belonging to the user from the network with 821 possible bad consequences, especially if one of the private keys was 822 compromised somehow. 824 When the max-age parameter is not zero, then a HOBA signature has a 825 property that is like a bearer token for the relevant number of 826 seconds: it can be replayed for a server-selected duration. 827 Similarly, for HOBA-js, signatures might be replayable depending on 828 the specific implementation. The security considerations of 829 [RFC6750] therefore apply in any case where the HOBA signature can be 830 replayed. Server administrators can set the max-age to the minimum 831 acceptable value in such cases, which would often be expected to be 832 just a few seconds. There seems to be no reason to ever set the max- 833 age more than a few minutes; the value ought also decrease over time 834 as device capabilities improve. The administrator will most likely 835 want to set the max-age to something that is not too short for the 836 slowest signing device that is significant for that site. 838 8.1. Privacy considerations 840 HOBA does impact to some extent on privacy and could be considered to 841 represent a super-cookie to the server, or to any entity on the path 842 from UA to HTTP server that can see the HOBA signature. This is 843 because we need to send a key identifier as part of the signature and 844 that will not vary for a given key. For this reason, and others, it 845 is strongly RECOMMENDED to only use HOBA over server-authenticated 846 TLS and to migrate web sites using HOBA to only use "https" URLs. 848 UAs SHOULD provide users a way to manage their CPKs. Ideally, there 849 would be a way for a user to maintain their HOBA details for a site 850 while at the same time deleting other site information such as 851 cookies or non-HOBA HTML5 LocalStorage. However, as this is likely 852 to be complex and appropriate user interfaces counter intutitive, we 853 expect that UAs that implement HOBA will likely treat HOBA 854 information as just some more site data, that would disappear should 855 the user choose to "forget" that site. 857 Device identifiers are intended to specify classes of device in a way 858 that can assist with registration and with presentation to the user 859 of information about previous sessions, e.g. last login time. 860 Device identifier types MUST NOT be privacy sensitive, with values 861 that would allow tracking a user in unexpected ways. In particular, 862 using an device identifier type that is analogous to the 863 International Mobile Equipment Identifier (IMEI) would be a really 864 bad idea and is the reason for the MUST NOT above. In that case 865 "mobile phone" could be an acceptable choice. 867 If possible, implementations ought encourage use of device identifier 868 values that are not personally identifying except for the user 869 concerned, for example "Alice's mobile" is likely to be chosen and is 870 somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0" 871 would be a very bad choice. 873 8.2. localStorage Security for Javascript 875 The use of localStorage (likely with a non-WebCrypto implementation 876 of HOBA-js) will undoubtedly be a cause for concern. localStorage 877 uses the same-origin model which says that the scheme, domain and 878 port define a localStorage instance. Beyond that, any code executing 879 will have access to private keying material. Of particular concern 880 are XSS attacks which could conceivably take the keying material and 881 use it to create UAs under the control of an attacker. But XSS 882 attacks are in reality across the board devastating since they can 883 and do steal credit card information, passwords, perform illicit 884 acts, etc, etc. It's not clear that we introduce unique threats from 885 which clear text passwords don't already suffer. 887 Another source of concern is local access to the keys. That is, if 888 an attacker has access to the UA itself, they could snoop on the key 889 through a javascript console, or find the file(s) that implement 890 localStorage on the host computer. Again it's not clear that we are 891 worse in this regard because the same attacker could get at browser 892 password files, etc too. One possible mitigation is to encrypt the 893 keystore with a password/pin the user supplies. This may sound 894 counter intuitive, but the object here is to keep passwords off of 895 servers to mitigate the multiplier effect of a large scale compromise 896 [bland] because of shared passwords across sites. 898 It's worth noting that HOBA uses asymmetric keys and not passwords 899 when evaluating threats. As various password database leaks have 900 shown, the real threat of a password breach is not just to the site 901 that was breached, it's all of the sites a user used the same 902 password on too. That is, the collateral damage is severe because 903 password reuse is common. Storing a password in localStorage would 904 also have a similar multiplier effect for an attacker, though perhaps 905 on a smaller scale than a server-side compromise: one successful 906 crack gains the attacker potential access to hundreds if not 907 thousands of sites the user visits. HOBA does not suffer from that 908 attack multiplier since each asymmetric key pair is unique per site/ 909 UA/user. 911 8.3. Multiple Accounts on One User Agent 913 A shared UA with multiple accounts is possible if the account 914 identifier is stored along with the asymmetric key pair binding them 915 to one another. Multiple entries can be kept, one for each account, 916 and selected by the current user. This, of course, is fraught with 917 the possibility for abuse, since a server is potentially enrolling 918 the device for a long period and the user may not want to have to be 919 responsible for the credential for that long. To alleviate this 920 problem, the user could request that the credential be erased from 921 the browser. Similarly, during the enrollment phase, a user could 922 request that the key pair only be kept for a certain amount of time, 923 or that it not be stored beyond the current browser session. 924 However, all such features really ought be part of the operating 925 system or platform and not part of a HOBA implementation so those are 926 not discussed further. 928 8.4. Injective Mapping for HOBA-TBS 930 The repeated length fields in the HOBA-TBS structure are present in 931 order to ensure that there is no possibility that the catenation of 932 different input values can cause confusion that might lead to an 933 attack, either against HOBA as specified here, or else an attack 934 against some other protocol that re-used this to-be-signed structure. 936 Those fields ensure that the mapping from input fields to the HOBA- 937 TBS string is an injective mapping. 939 9. IANA Considerations 941 IANA is requested to make registrations and create new registries as 942 described below. 944 For all new registries requested by this document, please place those 945 beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters" 946 category. 948 9.1. HOBA Authentication Scheme 950 Please register a new scheme in the HTTP Authentication Scheme 951 Registry registry as follows: 953 Authentication Scheme Name: HOBA 955 Pointer to specification text: Section 3 of [[ this document ]] 957 Notes (optional): The HOBA scheme can be used with either HTTP 958 servers or proxies. When used in response to a 407 Proxy 959 Authentication Required indication, the appropriate proxy 960 authentication header fields are used instead, as with any other HTTP 961 authentication scheme. 963 9.2. .well-known URI 965 Please register a new .well-known URI in the Well-Known URIs registry 966 as described below. 968 URI suffix: hoba 970 Change controller: IETF 972 Specification document(s): Section 6 of [[ this document ]] 974 Related information: N/A 976 9.3. Algorithm Names 978 Please create a new HOBA signature algorithms registry as follows, 979 with the specification required rule for updates. New HOBA signature 980 algorithms SHOULD be in use with other IETF standards track protocols 981 before being added to this registry. 983 Number Meaning 984 ----------- -------------------------------------------- 985 0 RSA-SHA256 986 1 RSA-SHA1 988 RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are 989 defined in [SHS]. 991 For this registry the number column should contain a small positive 992 integer. Following the ABNF above, the maximum value for this is 993 decimal 99. 995 9.4. Key Identifier Types 997 Please create a new HOBA Key Identifier Types registry as follows, 998 with the specification required rule for updates. 1000 Number Meaning 1001 ----------- -------------------------------------------- 1002 0 a hashed public key [RFC6698] 1003 1 a URI [RFC3986] 1004 2 an unformatted string, at the user's/UA's whim 1006 For the number 0, hashed public keys are as done in DANE. [RFC6698] 1008 For this registry the number column should contain a small positive 1009 integer. 1011 9.5. Device Identifier Types 1013 Please create a new HOBA Device Identifier Types registry as follows, 1014 with the specification required rule for updates. 1016 The designated expert for this registry is to carefully pay attention 1017 to the notes on this field in Section 8.1, in particular the "MUST 1018 NOT" stated therein. 1020 Number Meaning 1021 ----------- -------------------------------------------- 1022 0 an unformatted UTF8 string, at the user's/UA's whim 1024 For this registry the number column should contain a small positive 1025 integer. 1027 9.6. Hobareg HTTP Header Field 1028 Please register a new identifier in the Permanent Message Header 1029 Field Names registry as described below. 1031 Header field name: Hobareg 1033 Applicable protocol: HTTP (RFC 7230) 1035 Status: Experimental 1037 Author/Change controller: IETF 1039 Specification document(s): Section 6.1.1 of [[ this document ]] 1041 Related information: N/A 1043 10. Implementation Status 1045 [[ Note to RFC editor - please delete this section before 1046 publication. ]] 1048 This section records the status of known implementations of the 1049 protocol defined by this specification at the time of posting of this 1050 Internet-Draft, and is based on a proposal described in [RFC6982]. 1051 The description of implementations in this section is intended to 1052 assist the IETF in its decision processes in progressing drafts to 1053 RFCs. Please note that the listing of any individual implementation 1054 here does not imply endorsement by the IETF. Furthermore, no effort 1055 has been spent to verify the information presented here that was 1056 supplied by IETF contributors. This is not intended as, and must not 1057 be construed to be, a catalog of available implementations or their 1058 features. Readers are advised to note that other implementations may 1059 exist. 1061 According to [RFC6982] "this will allow reviewers and working groups 1062 to assign due consideration to documents that have the benefit of 1063 running code, by considering the running code as evidence of valuable 1064 experimentation and feedback that has made the implemented protocols 1065 more mature. It is up to the individual working groups to use this 1066 information as they see fit". 1068 At the time of writing there are three known implementations. 1070 One done by Stephen Farrell of HOBA-http and a HOBA-JS variant 1071 implements the current version of HOBA and is available from 1072 https://hoba.ie/ which site also includes a demonstration of HOBA. 1074 There is another implementation by Michael Thomas of a HOBA-JS 1075 variant. 1077 The most recent (Dec 2014) implementation is by Portugal Telecom 1078 and is available from https://github.com/razevedo/hoba- 1079 authentication 1081 11. Acknowledgements 1083 Thanks to the following for good comments received during the 1084 preparation of this specification: Richard Barnes, David Black, 1085 Alissa Cooper, Donald Eastlake, Amos Jeffries, Benjamin Kaduk, Watson 1086 Ladd, Barry Leiba, Matt Lepinski, Ilari Liusvaara, James Manger, 1087 Alexey Melnikov, Kathleen Moriarty, Yoav Nir, Mark Nottingham, Julian 1088 Reschke, Pete Resnick, Michael Richardson, Yaron Sheffer, and Michael 1089 Sweet. All errors and stupidities are of course the editors' fault. 1091 12. References 1093 12.1. Normative References 1095 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 1096 October 1969. 1098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1099 Requirement Levels", BCP 14, RFC 2119, March 1997. 1101 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1102 Standards (PKCS) #1: RSA Cryptography Specifications 1103 Version 2.1", RFC 3447, February 2003. 1105 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1106 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1107 3986, January 2005. 1109 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1110 Encodings", RFC 4648, October 2006. 1112 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1113 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1115 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1116 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1118 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1119 Uniform Resource Identifiers (URIs)", RFC 5785, April 1120 2010. 1122 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 1123 2011. 1125 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1126 of Named Entities (DANE) Transport Layer Security (TLS) 1127 Protocol: TLSA", RFC 6698, August 2012. 1129 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1130 Framework: Bearer Token Usage", RFC 6750, October 2012. 1132 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1133 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1135 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1136 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1138 [SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST 1139 Special Publications , March 2012. 1141 12.2. Informative References 1143 [MI93] Mitchell, and Thomas, "Standardising Authentication 1144 Protocols Based on Public-Key Techniques.", Journal of 1145 Computer Security 2 (1993): 23-36. , 1993. 1147 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1148 Requirements for Security", BCP 106, RFC 4086, June 2005. 1150 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1151 April 2011. 1153 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1154 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 1155 September 2011. 1157 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1158 Code: The Implementation Status Section", RFC 6982, July 1159 2013. 1161 [bland] Sophos, , "Security Threat Report 2013", January 2013, 1162 . 1165 [bonneau] Bonneau, , "The science of guessing: analyzing an 1166 anonymized corpus of 70 million passwords.", IEEE 1167 Symposium on Security and Privacy , 2012. 1169 Appendix A. Problems with Passwords 1171 By far the most common mechanism for web authentication is passwords 1172 that can be remembered by the user, called "human-memorable 1173 passwords". There is plenty of good research on how users typically 1174 use human-memorable passwords (e.g. see [bonneau]), but some of the 1175 highlights are that users typically try hard to reuse passwords on as 1176 many web sites as possible, and that web sites often use either email 1177 addresses or users' names as the identifier that goes with these 1178 passwords. 1180 If an attacker gets access to the database of memorizable passwords, 1181 that attacker can impersonate any of the users. Even if the breach 1182 is discovered, the attacker can still impersonate users until every 1183 password is changed. Even if all the passwords are changed or at 1184 least made unusable, the attacker now possesses a list of likely 1185 username/password pairs that might exist on other sites. 1187 Using memorizable passwords on unencrypted channels also poses risks 1188 to the users. If a web site uses either the HTTP Basic 1189 authentication method, or an HTML form that does no cryptographic 1190 protection of the password in transit, a passive attacker can see the 1191 password and immediately impersonate the user. If a hash-based 1192 authentication scheme such as HTTP Digest authentication is used, a 1193 passive attacker still has a high chance of being able to determine 1194 the password using a dictionary of known passwords. 1196 Note that passwords that are not human-memorable are still subject to 1197 database attack, though are of course unlikely to be re-used across 1198 many systems. Similarly, database attacks of some form or other will 1199 work against any password based authentication scheme, regardless of 1200 the crytographic protocol used. So for example, zero-knowledge or 1201 PAKE schemes, though making use of elegant cryptographic protocols, 1202 remain as vulnerable to what is clearly the most common exploit seen 1203 when it comes to passwords. HOBA is however not vulnerable to 1204 database theft. 1206 Appendix B. Example 1208 The following values show an example of HOBA-http authentication to 1209 the origin https://example.com:443. Carriage-returns have been added 1210 and need to be removed to validate the example. 1212 Public Key: 1214 -----BEGIN PUBLIC KEY----- 1215 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28 1216 6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t 1217 fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8 1218 egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl 1219 DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS 1220 L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG 1221 DQIDAQAB 1222 -----END PUBLIC KEY----- 1224 Origin: https://example.com:443 1226 Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w 1228 Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc= 1230 Signature algorithm: RSA-SHA256 ("0") 1232 Nonce: Pm3yUW-sW5Q 1234 Signature: 1236 VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i 1237 4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz 1238 q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP 1239 tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9 1240 6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI 1241 S13qQA43m4IMExkbApqrSg 1243 Authorization Header: 1245 Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN- 1246 k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q 1247 .VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0 1248 i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU 1249 zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK 1250 PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr 1251 96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k 1252 IS13qQA43m4IMExkbApqrSg" 1254 Authors' Addresses 1256 Stephen Farrell 1257 Trinity College Dublin 1258 Dublin 2 1259 Ireland 1261 Phone: +353-1-896-2354 1262 Email: stephen.farrell@cs.tcd.ie 1264 Paul Hoffman 1265 VPN Consortium 1267 Email: paul.hoffman@vpnc.org 1268 Michael Thomas 1269 Phresheez 1271 Email: mike@phresheez.com