idnits 2.17.1 draft-ietf-httpauth-hoba-08.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 (December 26, 2014) is 3407 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 (~~), 2 warnings (==), 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: June 29, 2015 VPN Consortium 6 M. Thomas 7 Phresheez 8 December 26, 2014 10 HTTP Origin-Bound Authentication (HOBA) 11 draft-ietf-httpauth-hoba-08 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 June 29, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . 8 61 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 9 62 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 10 63 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10 64 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10 65 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 10 66 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11 67 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 12 68 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 13 69 6.2. Associating Additional Keys to an Existing Account . . . 14 70 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 15 71 6.2.2. Human memorable one time password (don't do this one) 15 72 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 16 73 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 16 75 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 17 78 8.2. localStorage Security for Javascript . . . . . . . . . . 17 79 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18 80 8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 18 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 19 83 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 19 84 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20 85 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 20 86 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20 87 9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 21 88 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 12.2. Informative References . . . . . . . . . . . . . . . . . 23 93 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 23 94 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Introduction 99 HTTP Origin-Bound Authentication (HOBA) is an authentication design 100 that can be used as an HTTP authentication scheme [RFC7235] and for 101 Javascript-based authentication embedded in HTML. The main goal of 102 HOBA is to offer an easy-to-implement authentication scheme that is 103 not based on passwords, but that can easily replace HTTP or HTML 104 forms-based password authentication. Deployment of HOBA can reduce 105 or eliminate password entries in databases, with potentially 106 significant security benefits. 108 HOBA is an HTTP authentication mechanism that complies with the 109 framework for such schemes [RFC7235]. As a JavaScript design, HOBA 110 demonstrates a way for clients and servers to interact using the same 111 credentials that are used by the HTTP authentication scheme. 113 Current username/password authentication methods such as HTTP Basic, 114 HTTP Digest, and web forms have been in use for many years but are 115 susceptible to theft of server-side password databases. Instead of 116 passwords, HOBA uses digital signatures as an authentication 117 mechanism. HOBA also adds useful features such as credential 118 management and session logout. In HOBA, the client creates a new 119 public-private key pair for each host ("web origin" [RFC6454]) to 120 which it authenticates. These keys are used in HOBA for HTTP clients 121 to authenticate themselves to servers in the HTTP protocol or in a 122 Javascript authentication program. 124 HOBA session management is identical to username/password session 125 management, with a server-side session management tool or script 126 inserting a session cookie [RFC6265] into the output to the browser. 127 Use of TLS for the HTTP session is still necessary to prevent session 128 cookie hijacking. 130 HOBA keys are "bare keys", so there is no need for the semantic 131 overhead of X.509 public key certificates, particularly with respect 132 to naming and trust anchors. The client public key ("CPK") 133 structures in HOBA do not have any publicly-visible identifier for 134 the user who possesses the corresponding private key, nor the web- 135 origin with which the client is using the CPK. 137 HOBA also defines some services that are needed 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 Logout features can be useful for UAs, so HOBA defines a way to 150 close a current HTTP "session", and also a way to close all 151 current sessions, even if more than one session is currently 152 active from different UAs for the same account. 154 o Digital signatures can be expensive to compute, so HOBA defines a 155 way for HTTP servers to indicate how long a given challenge value 156 is valid, and a way for UAs to fetch a fresh challenge at any 157 time. 159 Users are also likely to lose a private key, or the client's memory 160 of which key pair is associated with which origin, such as when a 161 user loses the computer or mobile device in which state is stored. 162 HOBA does not define a mechanism for deleting the association between 163 an existing CPK and an account. Such a mechanism can be implemented 164 at the application layer. 166 1.1. Interfacing to Applications (Cookies) 168 HOBA can be used as a drop-in replacement for password-based user 169 authentication schemes used in common web applications. The simplest 170 way is to (re-)direct the UA to a HOBA "Login" URL and for the 171 response to a successful HTTP request containing a HOBA signature to 172 set a session cookie [RFC6265]. Further interactions with the web 173 application will then be secured via the session cookie, as is 174 commonly done today. 176 While cookies are bearer tokens, and thus weaker than HOBA 177 signatures, they are currently ubiquitously used. If non-bearer 178 token session continuation schemes are developed in future in the 179 IETF or elsewhere, then those can interface to HOBA as easily as with 180 any password based authentication scheme. 182 1.2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in RFC 187 2119 [RFC2119]. 189 This specification uses the Augmented Backus-Naur Form (ABNF) 190 notation of [RFC5234]. 192 Account: The term "account" is (loosely) used to refer to whatever 193 data structure(s) the server maintains that are associated with an 194 identity. That will contain of at least one CPK and a web-origin; it 195 will also optionally include an HTTP "realm" as defined in the HTTP 196 authentication specification [RFC7235]. It might also involve many 197 other non-standard pieces of data that the server accumulates as part 198 of account creation processes. An account may have many CPKs that 199 are considered equivalent in terms of being usable for 200 authentication, but the meaning of "equivalent" is really up to the 201 server and is not defined here. 203 Client public key ("CPK"): A CPK is the public key and associated 204 cryptographic parameters needed for a server to validate a signature. 206 HOBA-http: We use this term when describing something that is 207 specific to HOBA as an HTTP authentication mechanism. 209 HOBA-js: We use this term when describing something that is unrelated 210 to HOBA-http but is relevant for HOBA as a design pattern that can be 211 implemented in a browser in JavaScript. 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 Web client: the content and javascript code that run within the 219 context of a single UA instance (such as a tab in a web browser). 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 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 and allows the characters specified in Section 2.3 of 239 [RFC3986]. 241 HOBA-TBS = len ":" nonce 242 len ":" alg 243 len ":" origin 244 len ":" [ realm ] 245 len ":" kid 246 len ":" challenge 247 len = 1*DIGIT 248 nonce = 1*base64urlchars 249 alg = 1*2DIGIT 250 origin = scheme "://" authority ":" port 251 ; scheme etc are from RFC 3986 252 realm = unreserved 253 ; realm is to be treated as in Section 2.2 of RFC 7235 254 kid = 1*base64urlchars 255 challenge = 1*base64urlchars 256 ; Characters for Base64URL encoding from Table 2 of RFC 4648 257 ; all of which are US-ASCII (see RFC 20) 258 base64urlchars = %x30-39 ; Digits 259 / %x41-5A ; Uppercase letters 260 / %x61-7A ; Lowercase letters 261 / "-" / "_" / "=" ; Special characters 263 Figure 1: To-be-signed data for HOBA 265 The fields above contain the following: 267 o len: Each field is preceeded by the number of octets of the 268 following field, expressed as a decimal number in ASCII [RFC0020]. 269 Lengths are separated from field values by a colon character. So 270 if a nonce with the value "ABCD" were used then that would be 271 preceeded by "4:" (see the example in Appendix B for detail). 273 o nonce: is a random value chosen by the UA and MUST be base64url 274 encoded before being included in the HOBA-TBS value. (base64url 275 encoding is defined in [RFC4648].) UAs MUST be able to use at 276 least 32 bits of randomness in generating a nonce. UAs SHOULD be 277 able to use 64 or more bits of randomness for nonces. 279 o alg: specifies the signature algorithm being used encoded as an 280 ASCII character as defined in Section 9.3. RSA-SHA256 MUST be 281 supported, RSA-SHA1 MAY be supported. The IANA registered 282 algorithm values are encoded as ASCII numbers; for example, the 283 encoding of RSA-SHA256 is 0x30. 285 o origin: is the web origin expressed as the concatenation of the 286 scheme, authority and port from [RFC3986]. These are not base64 287 encoded as they will be most readily available to the server in 288 plain text. For example, if accessing the URL "https:// 289 www.example.com:8080/foo" then the bytes input to the signature 290 process will be "https://www.example.com:8080". There is no 291 default for the port number, and the port number MUST be present. 293 o realm: is similarly just a string with the syntactic restrictions 294 defined in [RFC7235]. If no realm is specified for this 295 authentication then this is absent, but is preceeded by a length 296 of zero ("0:"). Recall both sides know when this needs to be 297 there independent of the encoding via a zero length. 299 o kid: is a key identifier - this MUST be a base64url encoded value 300 that is presented to the server in the HOBA client result (see 301 below). 303 o challenge: MUST be a base64url encoded challenge value that the 304 server chose to send to the client. The challenge MUST be chosen 305 so that it is infeasible to guess, and SHOULD be indistinguishable 306 from (the base64url encoding of) an at least 128-bit long random 307 string. 309 The HOBA-TBS string is the input to the client's signing process, but 310 is not itself sent over the network since some fields are already 311 inherent in the HTTP exchange. The challenge however is sent over 312 the network so as to reduce the amount of reduce the amount of state 313 that needs to be maintained by servers. (One form of stateless 314 challenge might be a ciphertext that the server decrypts and checks, 315 but that is an implementation detail.) The value that is sent over 316 the network by the UA is the HOBA "client result" which we now 317 define. 319 The HOBA "client result" is a dot-separated string that includes the 320 signature and is sent in the HTTP Authorizaion header field value 321 using the value syntax defined in Figure 2. The "sig" value is the 322 base64url encoded version of the binary output of the signing 323 process. The kid, challenge and nonce are as defined above and are 324 also base64url encoded. 326 HOBA-RES = kid "." challenge "." nonce "." sig 327 sig = 1*base64urlchars 329 Figure 2: HOBA Client Result value 331 The HOBA scheme is far from new, for example, the basic idea is 332 pretty much identical to the first two messages from "Mechanism R" on 333 page 6 of [MI93] which predates HOBA by 20 years. 335 3. Introduction to the HOBA-http Mechanism 337 An HTTP server that supports HOBA authentication includes the "HOBA" 338 auth-scheme value in a WWW-Authenticate header field when it wants 339 the client to authenticate with HOBA. Note that the HOBA auth-scheme 340 might not be the only one that the server includes in a WWW- 341 Authenticate header. 343 The HOBA scheme has two REQUIRED attributes (challenge and max-age) 344 and one OPTIONAL attribute (realm): 346 o The "challenge" attribute MUST be included. The challenge is the 347 string made up of the base64url encoded octets that the server 348 wants the client to sign in its response. The challenge MUST be 349 unique for every HTTP 401 response in order to prevent replay 350 attacks from passive observers. 352 o A "max-age" attribute MUST be included that specifies the number 353 of seconds from the time the HTTP response is emitted for which 354 responses to this challenge can be accepted for example "max-age: 355 10" would indicate ten seconds. If max-age is set to zero, then 356 that means that only one signature will be accepted for this 357 challenge. 359 o A "realm" attribute MAY be included to indicate the scope of 360 protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. 361 The "realm" attribute MUST NOT appear more than once. 363 When the "client response" is created, the UA encodes the HOBA 364 client-result and returns that in the Authorization header. The 365 client-result is a string matching the HOBA-RES production in Figure 366 2 as an auth-param with the name "result". 368 The server MUST check the cryptographic correctness of the signature 369 based on a public key it knows for the kid in the signatures, and if 370 the server cannot do that, or if the signature fails cryptographic 371 checks, then validation has failed. The server can use any 372 additional mechanisms to validate the signature. If the validation 373 fails, or if the server chooses reject the signature for any reason 374 whatsoever, the server fails the request with a 401 Unauthorized HTTP 375 response. 377 The server MUST check that the same web origin is used in all of the 378 server's TLS server certificates, the URL being accessed and the HOBA 379 signature. If any of those checks fail, the server treats the 380 signature as being cryptographically incorrect. 382 Note that a HOBA signature is good for however long a non-zero max- 383 age parameter allows. This means that replay is possible within the 384 time window specified by the "max-age" value chosen by the server. 385 Servers can attempt to detect any such replay (via caching if they so 386 choose) and MAY react to such replays by responding with a second (or 387 subsequent) 401-status HTTP response containing a new challenge. 389 UAs MAY optimise their use of challenges by pre-fetching a challenge 390 value, for example after (max-age)/2 seconds have elapsed, using the 391 ".well-known/hoba/getchal" scheme described later in this document. 392 This also allows for pre-calculation of HOBA signatures, if that is 393 required in order to produce a responsive user interface. 395 4. Introduction to the HOBA-js Mechanism 397 Web sites using JavaScript can also perform origin-bound 398 authentication without needing to involve the HTTP layer, and by 399 inference not needing HOBA-http support in browsers. HOBA-js is not 400 an on-the-wire protocol like HOBA-http is: instead, it is a design 401 pattern that can be realized completely in JavaScript served in 402 normal HTML pages. 404 One element is required for HOBA-js: localStorage (see http:// 405 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key 406 storage. For example, an implementation would store a dictionary 407 account identifier, public key and private key tuples in the origin's 408 localStorage for subsequent authentication requests. How this 409 information is actually stored in localStorage is an implementation 410 detail. This type of key storage relies on the security properties 411 of the same-origin policy that localStorage enforces. See the 412 security considerations for discussion about attacks on localStorage. 413 Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an 414 alternative to localStorage that can also be used here. 416 Because of JavaScript's same-origin policy, scripts from subdomains 417 do not have access to the same localStorage that scripts in their 418 parent domains do. For larger or more complex sites, this could be 419 an issue that requires enrollment into subdomains, which could be a 420 hassle for users. One way to get around this is to use session 421 cookies because they can be used across subdomains. That is, with 422 HOBA-js, the user might log in using a single well-known domain, and 423 then the server uses session cookies to navigate around a site. 425 Another element will be highly desirable for HOBA-js when it becomes 426 available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In 427 lieu of WebCrypto, JavaScript crypto libraries can be employed with 428 the known deficiencies of their pseudo-random number generators and 429 the general immaturity of those libraries. 431 5. HOBA's Authentication Process 433 This section describes how clients and servers use HOBA for 434 authentication. The interaction between an HTTP client and HTTP 435 server using HOBA happens in three phases: the CPK preparation phase, 436 the signing phase, and the authentication phase. This section also 437 covers the actions that give HOBA similar user features as today's 438 passwords have. 440 5.1. CPK Preparation Phase 442 In the CPK preparation phase, the client determines if it already has 443 a CPK for the web-origin with which it needs to authenticate. If the 444 client has a CPK, the client will use it; if the client does not have 445 a CPK, it generates one in anticipation of the server asking for one. 447 5.2. Signing Phase 449 In the signing phase, the client connects to the server, the server 450 asks for HOBA-based authentication, and the client authenticates by 451 signing a blob of information as described in the previous sections. 453 5.3. Authentication Phase 455 The authentication phase is completely dependent on the policies and 456 practices of the server. That is, this phase involves no 457 standardized protocol in HOBA-http; in HOBA-js, there is no suggested 458 interaction template. 460 In the authentication phase, the server uses the key identifier (kid) 461 to determine the CPK from the signing phase and decides if it 462 recognizes the CPK. If the server recognizes the CPK, the server may 463 finish the client authentication process. 465 If this stage of the process involves additional information for 466 authentication, such as asking the user which account she wants to 467 use (in the case where a UA is used for multiple accounts on a site), 468 the server can prompt the user for account identifying information or 469 the user could choose based on HTML offered by the server before the 470 401 response is triggered. None of this is standardized: it all 471 follows the server's security policy and session flow. At the end of 472 this, the server probably assigns or updates a session cookie for the 473 client. 475 During the authentication phase, if the server cannot determine the 476 correct CPK, it could use HTML and JavaScript to ask the user if they 477 are really a new user or want to associate this new CPK with another 478 CPK. The server can then use some out-of-band method (such as a 479 confirmation email round trip, SMS, or an UA that is already 480 enrolled) to verify that the "new" user is the same as the already- 481 enrolled one. Thus, logging in on a new user agent is identical to 482 logging in with an existing account. 484 If the server does not recognize the CPK the server might send the 485 client through a either a join or login-new-UA (see below) process. 486 This process is completely up to the server, and probably entails 487 using HTML and JavaScript to ask the user some questions in order to 488 assess whether or not the server wants to give the client an account. 489 Completion of the joining process might require confirmation by 490 email, SMS, Captcha, and so on. 492 Note that there is no necessity for the server to initiate a joining 493 or login process upon completion of the signing phase. Indeed, the 494 server may desire to challenge the UA even for unprotected resources 495 and set a session cookie for later use in a join or login process as 496 it becomes necessary. For example, a server might only want to offer 497 an account to someone who had been to a few pages on the web site; in 498 such a case, the server could use the CPK from an associated session 499 cookie as a way of building reputation for the user until the server 500 wants the user to join. 502 6. Other Parts of the HOBA Process 504 The authentication process is more than just the act of 505 authentication. In password-based authentication and HOBA, there are 506 other processes that are needed both before and after an 507 authentication step. This section covers those processes. Where 508 possible, it combines practices of HOBA-http and HOBA-js; where that 509 is not possible, the differences are called out. 511 All HOBA interactions other than those defined in Section 5 MUST be 512 performed in TLS-protected sessions ([RFC5246]). If the current HTTP 513 traffic is not running under TLS, a new session is started before any 514 of the actions described here are performed. 516 HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for 517 performing many tasks: "https://www.example.com/.well-known/hoba". 518 These URLs are based on the name of the host that the HTTP client is 519 accessing. 521 There are many use cases for these URLs to redirect to other URLs: a 522 site that does registration through a federated site, a site that 523 only does registration under HTTPS, and so on. Like any HTTP client, 524 HOBA-http clients have to be able to handle redirection of these 525 requests. However, as that would potentially cause security issues 526 when a re-direct brings the client to a different web origin, servers 527 implementing HOBA-http SHOULD NOT re-direct to a different web origin 528 from below .well-known/hoba URLs. The above is considered sufficient 529 to allow experimentation with HOBA, but if at some point HOBA is 530 placed on the standards track then a full analysis of off-origin re- 531 directions would need to be documented. 533 6.1. Registration 535 Normally, a registration (also called "joining") is expected to 536 happen after a UA receives a 401 response for a web-origin and realm 537 (for HOBA-http) or on demand (for HOBA-js) for which it has no 538 associated CPK. The process of registration for a HOBA account on a 539 server is relatively light-weight. The UA generates a new key pair, 540 and associates it with the web-origin/realm in question. 542 Note that if the UA has a CPK associated with the web-origin, but not 543 for the realm concerned, then a new registration is REQUIRED. If the 544 server did not wish for that outcome, then it ought to use the same 545 or no realm. 547 The registration message for HOBA-http is sent as a POST message to 548 the URL ".well-known/hoba/register" with an HTML form (x-www-form- 549 encoded) (see http://www.w3.org/TR/2014/REC-html5-20141028/forms.html 550 #url-encoded-form-data) described below; The registration message for 551 HOBA-js can be in any format specified by the server, but it could be 552 the same as the one described here for HOBA-http. It is up to the 553 server to decide what kind of user interaction is required before the 554 account is finally set up. When the server's chosen registration 555 flow is completed successfully the server MUST add a Hobareg HTTP 556 header (see Section 6.1.1) to the HTTP response message that 557 completes the registration flow. 559 The registration message sent to server has one mandatory field (pub) 560 and some optional fields that allow the UA to specify the type and 561 value of key and device identifiers that the UA wishes to use. 563 o pub: is a mandatory field containing the PEM formatted public key 564 of the client. See Appendix C of [RFC6376] for an example of how 565 to generate this key format. 567 o kidtype: contains the type of key identifier, this is a numeric 568 value intended to contain one of the values from Section 9.4. If 569 this is not present then the mandatory-to-implement hashed public 570 key option MUST be used. 572 o kid: contains the key identifier as a base64url encoded string 573 that is of the type indicated in the kidtype. If the kid is a 574 hash of a public key then the correct (base64url encoded) hash 575 value MUST be provided and the server SHOULD check that and refuse 576 the registration if an incorrect value was supplied. 578 o didtype: specifies a kind of device identifier intended to contain 579 one of the values from Section 9.5, if absent then the "string" 580 form of device identifier MUST be used. 582 o did: a UTF8 string that specifies the device identifier. This can 583 be used to help a user be confident that authentication has 584 worked, e.g., following authentication some web content might say 585 "You last logged in from device 'did' at time T." 587 Note that replay of registration (and other HOBA) messages is quite 588 possible. That however can be counteracted if challenge freshness is 589 ensured. See Section 2 for details. Note also that with HOBA-http 590 the HOBA signature does not cover the POST message body. If that is 591 required then HOBA-JS may be a better fit for registration and other 592 account management actions. 594 6.1.1. Hobareg Definition 596 Since registration can often be a multi-step process, e.g. requiring 597 a user to fill in contact details, the initial response to the HTTP 598 POST message defined above may not be the end of the registration 599 process even though the HTTP response has a 200 OK status. This 600 creates an issue for the UA since, during the registration process 601 (e.g., while dealing with interstitial pages), the UA doesn't yet 602 know whether the CPK is good for that web origin or not. 604 For this reason the server MUST add a header field to the response 605 message when the registration has succeded to indicate the new state. 606 The header to be used is "Hobareg" and the value when registration 607 has succeeded is to be "regok". When registration is in an 608 intermediate state (e.g. on an HTTP response for an interstitial 609 page) the server MAY add this header with a value of "reginwork". 610 See Section 9.6 for the relevant IANA registration of this header 611 field. 613 For interstitial pages, the client MAY include a HOBA Authorization 614 header. This is not considered a MUST as that might needlessly 615 complicate client implementations but is noted here in case a server 616 implementer assumes that all registration messages contain a HOBA 617 Authorization header. 619 Hobareg-val = "regok" / "reginwork" 621 Figure 3: Hobareg Header Field Definition 623 Figure 3 provides an ABNF definition for the values allowed in the 624 Hobareg header field. Note that these (and the header field name) 625 are case insensitive. Section 8.3.1 of [RFC7231] calls for 626 documenting the following details for this new header field: 628 o Only one single value is allowed in a Hobareg header field. 629 Should more than one (a list) be encountered or any other ANBF- 630 invalid value, that SHOULD be interpreted as being the same as 631 "reginwork." 633 o The Hobareg header field can only be used in HTTP responses. 635 o Since Hobareg is only meant for responses it ought not appear in 636 requests. 638 o The HTTP response code does affect the interpretation of Hobareg. 639 Registration is only considered to have succeeded if the regok 640 value is seen in a 2xx response. 4xx and other errors means that 641 registration has failed regardless of the value of Hobareg seen. 642 The request method has no influence on the interpretation of 643 Hobareg. 645 o Intermediaries never insert, delete or modify a Hobareg header 646 field. 648 o As a response-only header field, it is not appropriate to list a 649 Hobareg in a Vary response header field. 651 o Hobareg is allowed in trailers. 653 o As a response-only header field, Hobareg will not be preserved 654 across re-directs. 656 o Hobareg itself discloses little security or privacy sensitive 657 information. If an attacker can somehow detect that a Hobareg 658 header field is being added, then that attacker would know that 659 the UA is in the process of registration which could be 660 significant. However, it is likely that the set of messages 661 between the UA and server would expose this information in many 662 cases, regardless of whether or not TLS is used. Using TLS is 663 still however a good plan. 665 6.2. Associating Additional Keys to an Existing Account 667 From the user perspective, the UA having a CPK for a web origin will 668 often appear to be the same as having a way to sign in to an account 669 at that web site. Since users often have more than one UA, and since 670 the CPKs are, in general, UA-specific, that raises the question of 671 how the user can sign in to that account from different UAs. And 672 from the server perspective that turns into the question of how to 673 safely bind different CPKs to one account. In this section, we 674 describe some ways in which this can be done, as well as one way in 675 which this ought not be done. 677 Note that the context here is usually that the user has succeeded in 678 registering with one or more UAs (for the purposes of this section we 679 call this "the first UA" below) and can use HOBA with those, and the 680 user is now adding another UA. The newest UA might or might not have 681 a CPK for the site in question. Since it is in fact trivial, we 682 assume that the site is able to put in place some appropriate 683 quicker, easier registration for a CPK for the newest UA. The issue 684 then becomes one of binding the CPK from the newest UA with those of 685 other UAs bound to the account. 687 6.2.1. Moving private keys 689 It is common for a user to have multiple UAs, and to want all those 690 UAs to be able to authenticate to a single account. One method to 691 allow a user who has an existing account to be able to authenticate 692 on a second device is to securely transport the private and public 693 keys and the origin information from the first device to the second. 694 If this approach is taken, then there is no impact on the HOBA-http 695 or HOBA-js so this is a pure UA implementation issue and not 696 discussed further. 698 6.2.2. Human memorable one time password (don't do this one) 700 It will be tempting for implementers to use a human-memorable one- 701 time password (OTP) in order to "authenticate" binding CPKs to the 702 same account. The workflow here would likely be something along the 703 lines of some server administrative utility generating a human 704 memorable OTP such as "1234" and sending that to the user out of band 705 for the user to enter at two web pages each authenticated via the 706 relevant CPK. While this seems obvious enough and could even be 707 secure enough in some limited cases, we consider that this is too 708 risky to use in the Internet and so servers SHOULD NOT provide such a 709 mechanism. The reason this is so dangerous is that it would be 710 trivial for an automated client to guess such tokens and "steal" the 711 binding intended for some other user. At any scale, there would 712 always be some in-process bindings so that even with only a trickle 713 of guesses (and hence not being detectable via message volume) an 714 attacker would have a high probability of succeeding in registering a 715 binding with the attacker's CPK. 717 This method of binding CPKs together is therefore NOT RECOMMENDED. 719 6.2.3. Out of band URL 721 One easy binding method is to simply provide a web page where, using 722 the first UA, the user can generate a URL (containing some 723 "unguessable" cryptographically generated value) that the user then 724 later de-references on the newest UA. The user could e-mail that URL 725 to herself for example, of the web server accessed at the first UA 726 could automatically do that. 728 Such a URL SHOULD contain at least the equivalent of 128 bits of 729 randomness. 731 6.3. Logging Out 733 The user can tell the server it wishes to log out. With HOBA-http, 734 this is done by sending a HOBA-authenticated POST message to the URL 735 ".well-known/hoba/logout" on the site in question. The UA SHOULD 736 also delete session cookies associated with the session so that the 737 user's state is no longer "logged in." 739 The server MUST NOT allow TLS session resumption for any logged out 740 session. 742 The server SHOULD also revoke or delete any cookies associated with 743 the session. 745 6.4. Getting a Fresh Challenge 747 The UA can get a "fresh" challenge from the server. In HOBA-http, it 748 sends a POST message to ".well-known/hoba/getchal". If successful, 749 the response response MUST contain a fresh (base64url encoded) HOBA 750 challenge for this origin in the body of the response. Whitespace in 751 the response MUST be ignored. 753 7. Mandatory-to-Implement Algorithms 755 RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus 756 lengths of at least 2048 bits SHOULD be used. RSA is defined in 757 Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. 759 8. Security Considerations 761 If key binding was server-selected then a bad actor could bind 762 different accounts belonging to the user from the network with 763 possible bad consequences, especially if one of the private keys was 764 compromised somehow. 766 Binding my CPK with someone else's account would be fun and 767 profitable so SHOULD be appropriately hard. In particular URLs or 768 other values generated by the server as part of any CPK binding 769 process MUST be hard to guess, for whatever level of difficulty is 770 chosen by the server. The server SHOULD NOT allow a random guess to 771 reveal whether or not an account exists. 773 When the max-age parameter is not zero, then a HOBA signature has a 774 property that is like a bearer token for the relevant number of 775 seconds: it can be replayed for a server-selected duration. 776 Similarly, for HOBA-js, signatures might be replayable depending on 777 the specific implementation. The security considerations of 778 [RFC6750] therefore apply in any case where the HOBA signature can be 779 replayed. Server administrators can set the max-age to the minimum 780 acceptable value in such cases, which would often be expected to be 781 just a few seconds. There seems to be no reason to ever set the max- 782 age more than a few minutes; the value ought also decrease over time 783 as device capabilities improve. The administrator will most likely 784 want to set the max-age to something that is not too slow on the 785 slowest signing device that is significant for that site. 787 8.1. Privacy considerations 789 HOBA does impact to some extent on privacy and could be considered to 790 represent a super-cookie to the server, or to any entity on the path 791 from UA to HTTP server that can see the HOBA signature. This is 792 because we need to send a key identifier as part of the signature and 793 that will not vary for a given key. For this reason, and others, it 794 is strongly RECOMMENDED to only use HOBA over server-authenticated 795 TLS and to migrate web sites using HOBA to only use "https" URLs. 797 UAs SHOULD provide users a way to manage their CPKs. Ideally, there 798 would be a way for a user to maintain their HOBA details for a site 799 while at the same time deleting other site information such as 800 cookies or non-HOBA HTML5 LocalStorage. However, as this is likely 801 to be complex and appropriate user interfaces counter intutitive, we 802 expect that UAs that implement HOBA will likely treat HOBA 803 information as just some more site data, that would disappear should 804 the user choose to "forget" that site. 806 8.2. localStorage Security for Javascript 808 The use of localStorage (likely with a non-WebCrypto implementation 809 of HOBA-js) will undoubtedly be a cause for concern. localStorage 810 uses the same-origin model which says that the scheme, domain and 811 port define a localStorage instance. Beyond that, any code executing 812 will have access to private keying material. Of particular concern 813 are XSS attacks which could conceivably take the keying material and 814 use it to create UAs under the control of an attacker. But XSS 815 attacks are in reality across the board devastating since they can 816 and do steal credit card information, passwords, perform illicit 817 acts, etc, etc. It's not clear that we introduce unique threats from 818 which clear text passwords don't already suffer. 820 Another source of concern is local access to the keys. That is, if 821 an attacker has access to the UA itself, they could snoop on the key 822 through a javascript console, or find the file(s) that implement 823 localStorage on the host computer. Again it's not clear that we are 824 worse in this regard because the same attacker could get at browser 825 password files, etc too. One possible mitigation is to encrypt the 826 keystore with a password/pin the user supplies. This may sound 827 counter intuitive, but the object here is to keep passwords off of 828 servers to mitigate the multiplier effect of a large scale compromise 829 ala LinkedIn because of shared passwords across sites. 831 It's worth noting that HOBA uses asymmetric keys and not passwords 832 when evaluating threats. As various password database leaks have 833 shown, the real threat of a password breach is not just to the site 834 that was breached, it's all of the sites a user used the same 835 password on too. That is, the collateral damage is severe because 836 password reuse is common. Storing a password in localStorage would 837 also have a similar multiplier effect for an attacker, though perhaps 838 on a smaller scale than a server-side compromise: one successful 839 crack gains the attacker potential access to hundreds if not 840 thousands of sites the user visits. HOBA does not suffer from that 841 attack multiplier since each asymmetric key pair is unique per site/ 842 UA/user. 844 8.3. Multiple Accounts on One User Agent 846 A shared UA with multiple accounts is possible if the account 847 identifier is stored along with the asymmetric key pair binding them 848 to one another. Multiple entries can be kept, one for each account, 849 and selected by the current user. This, of course, is fraught with 850 the possibility for abuse, since a server is potentially enrolling 851 the device for a long period and the user may not want to have to be 852 responsible for the credential for that long. To alleviate this 853 problem, the user can request that the credential be erased from the 854 browser. Similarly, during the enrollment phase, a user could 855 request that the key pair only be kept for a certain amount of time, 856 or that it not be stored beyond the current browser session. 858 8.4. Injective Mapping for HOBA-TBS 860 The repeated length fields in the HOBA-TBS structure are present in 861 order to ensure that there is no possibility that the catenation of 862 different input values can cause confusion that might lead to an 863 attack, either against HOBA as specified here, or else an attack 864 against some other protocol that re-used this to-be-signed structure. 865 Those fields ensure that the mapping from input fields to the HOBA- 866 TBS string is an injective mapping. 868 9. IANA Considerations 870 IANA is requested to make registrations and create new registries as 871 described below. 873 For all new registries requested by this document, please place those 874 beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters" 875 category. 877 9.1. HOBA Authentication Scheme 879 Please register a new scheme in the HTTP Authentication Scheme 880 Registry registry as follows: 882 Authentication Scheme Name: HOBA 884 Pointer to specification text: Section 3 of [[ this document ]] 886 Notes (optional): The HOBA scheme can be used with either HTTP 887 servers or proxies. When used in response to a 407 Proxy 888 Authentication Required indication, the appropriate proxy 889 authentication header fields are used instead, as with any other HTTP 890 authentication scheme. 892 9.2. .well-known URI 894 Please register a new .well-known URI in the Well-Known URIs registry 895 as described below. 897 URI suffix: hoba 899 Change controller: IETF 901 Specification document(s): Section 6 of [[ this document ]] 903 Related information: N/A 905 9.3. Algorithm Names 907 Please create a new HOBA signature algorithms registry as follows, 908 with the specification required rule for updates. New HOBA signature 909 algorithms SHOULD be in use with other IETF standards track protocols 910 before being added to this registry. 912 Number Meaning 913 ----------- -------------------------------------------- 914 0 RSA-SHA256 915 1 RSA-SHA1 917 RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are 918 defined in [SHS]. 920 For this registry the number column should contain a small positive 921 integer. Following the ABNF above, the maximum value for this is 922 decimal 99. 924 9.4. Key Identifier Types 926 Please create a new HOBA Key Identifier Types registry as follows, 927 with the specification required rule for updates. 929 Number Meaning 930 ----------- -------------------------------------------- 931 0 a hashed public key [RFC6698] 932 1 a URI [RFC3986] 933 2 an unformatted string, at the user's/UA's whim 935 For the number 0, hashed public keys are as done in DANE. [RFC6698] 937 For this registry the number column should contain a small positive 938 integer. 940 9.5. Device Identifier Types 942 Please create a new HOBA Device Identifier Types registry as follows, 943 with the specification required rule for updates. 945 Number Meaning 946 ----------- -------------------------------------------- 947 0 an unformatted string, at the user's/UA's whim 948 For this registry the number column should contain a small positive 949 integer. 951 9.6. Hobareg HTTP Header Field 953 Please register a new identifier in the Permanent Message Header 954 Field Names registry as described below. 956 Header field name: Hobareg 958 Applicable protocol: HTTP (RFC 7230) 960 Status: Experimental 962 Author/Change controller: IETF 964 Specification document(s): Section 6.1.1 of [[ this document ]] 966 Related information: N/A 968 10. Implementation Status 970 [[ Note to RFC editor - please delete this section before 971 publication. ]] 973 This section records the status of known implementations of the 974 protocol defined by this specification at the time of posting of this 975 Internet-Draft, and is based on a proposal described in [RFC6982]. 976 The description of implementations in this section is intended to 977 assist the IETF in its decision processes in progressing drafts to 978 RFCs. Please note that the listing of any individual implementation 979 here does not imply endorsement by the IETF. Furthermore, no effort 980 has been spent to verify the information presented here that was 981 supplied by IETF contributors. This is not intended as, and must not 982 be construed to be, a catalog of available implementations or their 983 features. Readers are advised to note that other implementations may 984 exist. 986 According to [RFC6982] "this will allow reviewers and working groups 987 to assign due consideration to documents that have the benefit of 988 running code, by considering the running code as evidence of valuable 989 experimentation and feedback that has made the implemented protocols 990 more mature. It is up to the individual working groups to use this 991 information as they see fit". 993 At the time of writing there are three known implementations. 995 One done by Stephen Farrell of HOBA-http and a HOBA-JS variant 996 implements the current (-08) version of HOBA and is available from 997 https://hoba.ie/ which site also includes a demonstration of HOBA. 999 There is another implementation by Michael Thomas of an HOBA-JS 1000 variant. 1002 The most recent (Dec 2014) implementation is by Portugal Telecom 1003 and is available from https://github.com/razevedo/hoba- 1004 authentication 1006 11. Acknowledgements 1008 Thanks to the following for good comments received during the 1009 preparation of this specification: David Black, Amos Jeffries, 1010 Benjamin Kaduk, Watson Ladd, Matt Lepinski, Ilari Liusvaara, James 1011 Manger, Alexey Melnikov, Yoav Nir, Mark Nottingham, Julian Reschke, 1012 Michael Richardson, Yaron Sheffer, and Michael Sweet. All errors and 1013 stupidities are of course the editors' fault. 1015 12. References 1017 12.1. Normative References 1019 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 1020 October 1969. 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1026 Standards (PKCS) #1: RSA Cryptography Specifications 1027 Version 2.1", RFC 3447, February 2003. 1029 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1030 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1031 3986, January 2005. 1033 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1034 Encodings", RFC 4648, October 2006. 1036 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1037 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1039 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1040 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1042 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1043 Uniform Resource Identifiers (URIs)", RFC 5785, April 1044 2010. 1046 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 1047 2011. 1049 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1050 of Named Entities (DANE) Transport Layer Security (TLS) 1051 Protocol: TLSA", RFC 6698, August 2012. 1053 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1054 Framework: Bearer Token Usage", RFC 6750, October 2012. 1056 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1057 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1059 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1060 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1062 [SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST 1063 Special Publications , March 2012. 1065 12.2. Informative References 1067 [MI93] Mitchell, and Thomas, "Standardising Authentication 1068 Protocols Based on Public-Key Techniques.", Journal of 1069 Computer Security 2 (1993): 23-36. , 1993. 1071 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1072 April 2011. 1074 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1075 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 1076 September 2011. 1078 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1079 Code: The Implementation Status Section", RFC 6982, July 1080 2013. 1082 [bonneau] Bonneau, , "The science of guessing: analyzing an 1083 anonymized corpus of 70 million passwords.", IEEE 1084 Symposium on Security and Privacy , 2012. 1086 Appendix A. Problems with Passwords 1088 By far the most common mechanism for web authentication is passwords 1089 that can be remembered by the user, called "human-memorable 1090 passwords". There is plenty of good research on how users typically 1091 use human-memorable passwords (e.g. see [bonneau]), but some of the 1092 highlights are that users typically try hard to reuse passwords on as 1093 many web sites as possible, and that web sites often use either email 1094 addresses or users' names as the identifier that goes with these 1095 passwords. 1097 If an attacker gets access to the database of memorizable passwords, 1098 that attacker can impersonate any of the users. Even if the breach 1099 is discovered, the attacker can still impersonate users until every 1100 password is changed. Even if all the passwords are changed or at 1101 least made unusable, the attacker now possesses a list of likely 1102 username/password pairs that might exist on other sites. 1104 Using memorizable passwords on unencrypted channels also poses risks 1105 to the users. If a web site uses either the HTTP Basic 1106 authentication method, or an HTML form that does no cryptographic 1107 protection of the password in transit, a passive attacker can see the 1108 password and immediately impersonate the user. If a hash-based 1109 authentication scheme such as HTTP Digest authentication is used, a 1110 passive attacker still has a high chance of being able to determine 1111 the password using a dictionary of known passwords. 1113 Note that passwords that are not human-memorable are still subject to 1114 database attack, though are of course unlikely to be re-used across 1115 many systems. Similarly, database attacks of some form or other will 1116 work against any password based authentication scheme, regardless of 1117 the crytographic protocol used. So for example, zero-knowledge or 1118 PAKE schemes, though making use of elegant cryptographic protocols, 1119 remain as vulnerable to what is clearly the most common exploit seen 1120 when it comes to passwords. HOBA is however not vulnerable to 1121 database theft. 1123 Appendix B. Example 1125 The following values show an example of HOBA-http authentication to 1126 the origin https://example.com:443. Carriage-returns have been added 1127 and need to be removed to validate the example. 1129 Public Key: 1131 -----BEGIN PUBLIC KEY----- 1132 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28 1133 6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t 1134 fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8 1135 egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl 1136 DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS 1137 L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG 1138 DQIDAQAB 1139 -----END PUBLIC KEY----- 1141 Origin: https://example.com:443 1143 Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w 1145 Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc= 1147 Nonce: Pm3yUW-sW5Q 1149 Signature: 1151 VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i 1152 4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz 1153 q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP 1154 tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9 1155 6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI 1156 S13qQA43m4IMExkbApqrSg 1158 Authorization Header: 1160 Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN- 1161 k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q 1162 .VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0 1163 i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU 1164 zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK 1165 PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr 1166 96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k 1167 IS13qQA43m4IMExkbApqrSg" 1169 Authors' Addresses 1171 Stephen Farrell 1172 Trinity College Dublin 1173 Dublin 2 1174 Ireland 1176 Phone: +353-1-896-2354 1177 Email: stephen.farrell@cs.tcd.ie 1179 Paul Hoffman 1180 VPN Consortium 1182 Email: paul.hoffman@vpnc.org 1183 Michael Thomas 1184 Phresheez 1186 Email: mike@phresheez.com