idnits 2.17.1 draft-ietf-httpauth-hoba-05.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 (October 7, 2014) is 3488 days in the past. Is this intentional? 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Experimental P. Hoffman 5 Expires: April 10, 2015 VPN Consortium 6 M. Thomas 7 Phresheez 8 October 7, 2014 10 HTTP Origin-Bound Authentication (HOBA) 11 draft-ietf-httpauth-hoba-05 13 Abstract 15 HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP 16 authentication method with credentials that are not vulnerable to 17 phishing attacks, and that does not require any server-side password 18 database. The design can also be used in Javascript-based 19 authentication embedded in HTML. HOBA is an alternative to HTTP 20 authentication schemes that require passwords. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 10, 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 . . . . . . . . . . . 7 61 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 8 62 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9 63 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9 64 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 9 66 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 10 67 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11 68 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 12 69 6.2. Associating Additional Keys to an Exiting Account . . . . 14 70 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 14 71 6.2.2. Human memorable one time password (don't do this one) 14 72 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 15 73 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 15 74 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 15 75 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 16 78 8.2. localStorage Security for Javascript . . . . . . . . . . 17 79 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 18 82 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 18 83 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 19 84 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 19 85 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 19 86 9.6. Hobareg HTTP Header . . . . . . . . . . . . . . . . . . . 20 87 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 12.2. Informative References . . . . . . . . . . . . . . . . . 22 92 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 22 93 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 23 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 96 1. Introduction 98 HTTP Origin-Bound Authentication (HOBA) is an authentication design 99 that can be used as an HTTP authentication scheme [RFC7235] and for 100 Javascript-based authentication embedded in HTML. The main goal of 101 HOBA is to offer an easy-to-implement authentication scheme that is 102 not based on passwords, but that can easily replace HTTP or HTML 103 forms-based password authentication. Deployment of HOBA can reduce 104 or eliminate password entries in databases, with potentially 105 significant security benefits. 107 HOBA is an HTTP authentication mechanism that complies with the 108 framework for such schemes [RFC7235]. As a JavaScript design, HOBA 109 demonstrates a way for clients and servers to interact using the same 110 credentials that are used by the HTTP authentication scheme. 112 Current username/password authentication methods such as HTTP Basic, 113 HTTP Digest, and web forms have been in use for many years but are 114 susceptible to theft of server-side password databases. Instead of 115 passwords, HOBA uses digital signatures as an authentication 116 mechanism. HOBA also adds useful features such as credential 117 management and session logout. In HOBA, the client creates a new 118 public-private key pair for each host ("web-origin" [RFC6454]) to 119 which it authenticates. These keys are used in HOBA for HTTP clients 120 to authenticate themselves to servers in the HTTP protocol or in a 121 Javascript authentication program. 123 HOBA session management is identical to username/password session 124 management, with a server-side session management tool or script 125 inserting a session cookie into the output to the browser. HOBA 126 still requires TLS to prevent session cookie hijacking. 128 HOBA keys are "bare keys", so there is no need for the semantic 129 overhead of PKIX certificates, particularly with respect to naming 130 and trust anchors. The client public key ("CPK") structures in HOBA 131 do not have any publicly-visible identifier for the user who 132 possesses the corresponding private key, nor the web-origin with 133 which the client is using the CPK. 135 HOBA also defines some services that are required for modern HTTP 136 authentication: 138 o Servers can bind a CPK with an identifier, such as an account 139 name. Servers using HOBA define their own policies for binding 140 CPKs with accounts during account registration. 142 o Users are likely to use more than one device or user agent (UA) 143 for the same HTTP based service, so HOBA gives a way to associate 144 more than one CPK to the same account, but without having to 145 register for each separately. 147 o Logout features can be useful for UAs, so HOBA defines a way to 148 close a current HTTP "session", and also a way to close all 149 current sessions, even if more than one session is currently 150 active from different UAs for the same account. 152 o Digital signatures can be expensive to compute, so HOBA defines a 153 way for HTTP servers to indicate how long a given challenge value 154 is valid, and a way for UAs to fetch a fresh challenge at any 155 time. 157 Users are also likely to lose a private key, or the client's memory 158 of which key pair is associated with which origin, such as when a 159 user loses the computer or mobile device in which state is stored. 160 HOBA does not define a mechanism for deleting the association between 161 an existing CPK and an account. Such a mechanism can be implemented 162 at the application layer. 164 1.1. Interfacing to Applications (Cookies) 166 HOBA can be used as a drop-in replacement for password-based user 167 authentication schemes used in common web applications. The simplest 168 way is to (re-)direct the UA to a HOBA "Login" URL and for the 169 response to a successful HTTP request containing a HOBA signature to 170 set a session cookie [RFC6265]. Further interactions with the web 171 application will then be secured via the session cookie, as is 172 commonly done today. 174 While cookies are bearer tokens, and thus weaker than HOBA 175 signatures, they are currently ubiquitously used. If non-bearer 176 token session continuation schemes are developed in future in the 177 IETF or elsewhere, then those can interface to HOBA as easily as with 178 any password based authentication scheme. 180 1.2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in RFC 185 2119 [RFC2119]. 187 This specification uses the Augmented Backus-Naur Form (ABNF) 188 notation of [RFC5234] 190 Account: The term "account" is (loosely) used to refer to whatever 191 data structure(s) the server maintains that are associated with an 192 identity. That will contain of at least one CPK and a web-origin; it 193 will also optionally include an HTTP "realm" as defined in the HTTP 194 authentication specification. [RFC7235]. It might also involve many 195 other non-standard pieces of data that the server accumulates as part 196 of account creation processes. An account may have many CPKs that 197 are considered equivalent in terms of being usable for 198 authentication, but the meaning of "equivalent" is really up to the 199 server and is not defined here. 201 Client public key ("CPK"): A CPK is the public key and associated 202 cryptographic parameters needed for a server to validate a signature. 204 HOBA-http: We use this term when describing something that is 205 specific to HOBA as an HTTP authentication mechanism. 207 HOBA-js: We use this term when describing something that is unrelated 208 to HOBA-http but is relevant for HOBA as a design pattern that can be 209 implemented in a browser in JavaScript. 211 User agent (UA): typically, but not always, a web browser. 213 User: a person who is running a UA. In this document, "user" does 214 not mean "user name" or "account name". 216 Web client: the content and javascript code that run within the 217 context of a single UA instance (such as a tab in a web browser). 219 2. The HOBA Authentication Scheme 221 A UA that implements HOBA maintains a list of web-origins and realms. 222 The UA also maintains one or more client credentials for each web- 223 origin/realm combination for which it has created a CPK. 225 On receipt of a challenge (and optional realm) from a server, the 226 client marshals an HOBA to-be-signed (TBS) blob that includes a 227 client generated nonce, the web-origin, the realm, an identifier for 228 the CPK and the challenge string; and signs that blob with the 229 private key corresponding to the CPK for that web-origin. The 230 formatting chosen for this TBS blob is chosen so as to make server- 231 side signature verification as simple as possible for a wide range of 232 current server tooling. 234 Figure 1 specifies the ABNF for the signature input. The term 235 "unreserved" means that the field does not have a specific format 236 defined. 238 HOBA-TBS = nonce alg origin [ realm ] kid challenge 239 nonce = 1*base64urlchars 240 alg = 1*2DIGIT 241 origin = scheme "://" authority ":" port 242 realm = unreserved 243 kid = 1*base64urlchars 244 challenge = 1*base64urlchars 245 ; Characters for Base64URL encoding from Table 2 of RFC 4648 246 base64urlchars = %x30-39 ; Digits 247 / %x41-5A ; Uppercase letters 248 / %x61-7A ; Lowercase letters 249 / "-" / "_" / "=" ; Special characters 251 Figure 1: To-be-signed data for HOBA 253 The fields above contain the following: 255 o nonce: is a random value chosen by the UA and MUST be base64url 256 encoded before being included in the HOBA-TBS value. (base64url 257 encoding is defined in [RFC4648].) UAs MUST be able to use at 258 least 32 bits of randomness in generating a nonce. UAs SHOULD be 259 able to use 64 or more bits of randomness for nonces. 261 o alg: specifies the signature algorithm being used encoded as an 262 ASCII character as defined in Section 9.3. RSA-SHA256 MUST be 263 supported, RSA-SHA1 MAY be supported. The IANA registered 264 algorithm values are encoded as ASCII numbers; for example, the 265 encoding of RSA-SHA256 is 0x30. 267 o origin: is the web origin expressed as the concatenation of the 268 scheme, authority and port from [RFC3986]. These are not base64 269 encoded as they will be most readily available to the server in 270 plain text. For example, if accessing the URL "https:// 271 www.example.com:8080/foo" then the bytes input to the signature 272 process will be "https://www.example.com:8080". There is no 273 default for the port number, and the port number MUST be present. 275 o realm: is similarly just a string with the syntactic restrictions 276 defined in [RFC7235]. If no realm is specified for this 277 authentication then this is absent. (A missing field here is no 278 problem since both sides know when it needs to be there.) 280 o kid: is a key identifier - this MUST be a base64url encoded value 281 that is presented to the server in the HOBA client result (see 282 below). 284 o challenge: MUST be a base64url encoded challenge value that the 285 server chose to send to the client 287 The HOBA-TBS string is the input to the client's signing process, but 288 is not itself sent over the network since some fields are already 289 inherent in the HTTP exchange. The challenge however is sent over 290 the network so as to make it simpler for a server to be stateless. 291 (One form of stateless challenge might be a ciphertext that the 292 server decrypts and checks, but that is an implementation detail.) 293 The value that is sent over the network by the UA is the HOBA "client 294 result" which we now define. 296 The HOBA "client result" is a dot-separated string that includes the 297 signature and is sent in the HTTP Authorized header field value using 298 the value syntax defined in Figure 2. The "sig" value is the 299 base64url encoded version of the binary output of the signing 300 process. The kid, challenge and nonce are as defined above and are 301 also base64url encoded. 303 HOBA-RES = kid "." challenge "." nonce "." sig 304 sig = 1*base64urlchars 306 Figure 2: HOBA Client Result value 308 The HOBA scheme is far from new, for example, the basic idea is 309 pretty much identical to the first two messages from "Mechanism R" on 310 page 6 of [MI93] which predates HOBA by 20 years. 312 3. Introduction to the HOBA-http Mechanism 314 An HTTP server that supports HOBA authentication includes the "HOBA" 315 auth-scheme value in a WWW-Authenticate header field when it wants 316 the client to authenticate with HOBA. Note that the HOBA auth-scheme 317 might not be the only one that the server includes in a WWW- 318 Authenticate header. 320 The HOBA scheme has two REQUIRED attributes (challenge and max-age) 321 and one OPTIONAL attribute (realm): 323 o The "challenge" attribute MUST be included. The challenge is the 324 string made up of the base64url encoded octets that the server 325 wants the client to sign in its response. The challenge MUST be 326 unique for every HTTP 401 response in order to prevent replay 327 attacks from passive observers. 329 o A "max-age" attribute MUST be included that specifies the number 330 of seconds from the time the HTTP response is emitted for which 331 responses to this challenge can be accepted for example "max-age: 332 10" would indicatge ten seconds. If max-age is set to zero, then 333 that means that only one signature will be accepted for this 334 challenge. 336 o A "realm" attribute MAY be included to indicate the scope of 337 protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. 338 The "realm" attribute MUST NOT appear more than once. 340 When the "client response" is created, the UA encodes the HOBA 341 client-result and returns that in the Authorization header. The 342 client-result is a string matching the HOBA-RES production in Figure 343 2 as an auth-param with the name "result". 345 The server MUST check the cryptographic correctness of the signature 346 based on a public key it knows for the kid in the signatures, and if 347 the server cannot do that, or if the signature fails cryptographic 348 checks, then validation has failed. The server can use any 349 additional mechanisms to validate the signature. If the validation 350 fails, or if the server chooses reject the signature for any reason 351 whatsoever, the server aborts the transaction via a 401 Unauthorized 352 HTTP response. 354 Note that a HOBA signature is good for however long a non-zero max- 355 age attribute allows. This means that replay is possible within the 356 time window specified by the "max-age" value chosen by the server. 357 Servers can attempt to detect any such replay (via caching if they so 358 choose) and MAY react to such replays by responding with a second (or 359 subsequent) 401-status HTTP response containing a new challenge. 361 UAs MAY optimise their use of challenges by pre-fetching a challenge 362 value, for example after (max-age)/2 seconds have elapsed, using the 363 ".well-known/hoba/getchal" scheme described later in this document. 364 This also allows for pre-calculation of HOBA signatures, if that is 365 required in order to produce a responsive user interface. 367 4. Introduction to the HOBA-js Mechanism 369 Web sites using JavaScript can also perform origin-bound 370 authentication without needing to involve the HTTP layer, and by 371 inference not needing HOBA-http support in browsers. HOBA-js is not 372 an on-the-wire protocol like HOBA-http is: instead, it is a design 373 pattern that can be realized completely in JavaScript served in 374 normal HTML pages. 376 One element is required for HOBA-js: localStorage (see http:// 377 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key 378 storage. For example, an implementation would store a dictionary 379 account identifier, public key and private key tuples in the origin's 380 localStorage for subsequent authentication requests. How this 381 information is actually stored in localStorage is an implementation 382 detail. This type of key storage relies on the security properties 383 of the same-origin policy that localStorage enforces. See the 384 security considerations for discussion about attacks on localStorage. 385 Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an 386 alternative to localStorage that can also be used here. 388 Because of JavaScript's same-origin policy, scripts from subdomains 389 do not have access to the same localStorage that scripts in their 390 parent domains do. For larger or more complex sites, this could be 391 an issue that requires enrollment into subdomains, which could be a 392 hassle for users. One way to get around this is to use session 393 cookies because they can be used across subdomains. That is, with 394 HOBA-js, the user might log in using a single well-known domain, and 395 then the server uses session cookies to navigate around a site. 397 Another element will be highly desirable for HOBA-js when it becomes 398 available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In 399 lieu of WebCrypto, JavaScript crypto libraries can be employed with 400 the known deficiencies of their pseudo-random number generators and 401 the general immaturity of those libraries. 403 5. HOBA's Authentication Process 405 This section describes how clients and servers use HOBA for 406 authentication. The interaction between an HTTP client and HTTP 407 server using HOBA happens in three phases: the CPK preparation phase, 408 the signing phase, and the authentication phase. This section also 409 covers the actions that give HOBA similar user features as today's 410 passwords have. 412 5.1. CPK Preparation Phase 414 In the CPK preparation phase, the client determines if it already has 415 a CPK for the web-origin with which it needs to authenticate. If the 416 client has a CPK, the client will use it; if the client does not have 417 a CPK, it generates one in anticipation of the server asking for one. 419 5.2. Signing Phase 421 In the signing phase, the client connects to the server, the server 422 asks for HOBA-based authentication, and the client authenticates by 423 signing a blob of information as described in the previous sections. 425 5.3. Authentication Phase 427 The authentication phase is completely dependent on the policies and 428 practices of the server. That is, this phase involves no 429 standardized protocol in HOBA-http; in HOBA-js, there is no suggested 430 interaction template. 432 In the authentication phase, the server extracts the CPK from the 433 signing phase and decides if it recognizes the CPK. If the server 434 recognizes the CPK, the server may finish the client authentication 435 process. 437 If this stage of the process involves additional information for 438 authentication, such as asking the user which account she wants to 439 use (in the case where a UA is used for multiple accounts on a site), 440 the server can prompt the user for account identifying information or 441 the user could choose based on HTML offered by the server before the 442 401 is triggered. None of this is standardized: it all follows the 443 server's security policy and session flow. At the end of this, the 444 server probably assigns or updates a session cookie for the client. 446 During the authentication phase, if the server does not recognize the 447 CPK, it could use HTML and JavaScript to ask the user if they are 448 really a new user or want to associate this new CPK with an already- 449 joined CPK. The server can then use some out-of-band method (such as 450 a confirmation email round trip, SMS, or an UA that is already 451 enrolled) to verify that the "new" user is the same as the already- 452 enrolled one. Thus, logging in on a new user agent is identical to 453 logging in with an existing account. 455 If the server does not recognize the CPK the server might send the 456 client through a either a join or login-new-UA (see below) process. 457 This process is completely up to the server, and probably entails 458 using HTML and JavaScript to ask the user some questions in order to 459 assess whether or not the server wants to give the client an account. 460 Completion of the joining process might require confirmation by 461 email, SMS, Captcha, and so on. 463 Note that there is no necessity for the server to initiate a joining 464 or login process upon completion of the signing phase. Indeed, the 465 server may desire to challenge the UA even for unprotected resources 466 and set a session cookie for later use in a join or login process as 467 it becomes necessary. For example, a server might only want to offer 468 an account to someone who had been to a few pages on the web site; in 469 such a case, the server could use the CPK from an associated session 470 cookie as a way of building reputation for the user until the server 471 wants the user to join. 473 6. Other Parts of the HOBA Process 475 The authentication process is more than just the act of 476 authentication. In password-based authentication and HOBA, there are 477 other processes that are needed both before and after an 478 authentication step. This section covers those processes. Where 479 possible, it combines practices of HOBA-http and HOBA-js; where that 480 is not possible, the differences are called out. 482 All additional services MUST be performed in TLS-protected sessions 483 ([RFC5246]). If the current HTTP traffic is not running under TLS, a 484 new session is started before any of the actions described here are 485 performed. 487 HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for 488 performing many tasks: "https://www.example.com/.well-known/hoba". 489 These URLs are based on the name of the host that the HTTP client is 490 accessing. 492 There are many use cases for these URLs to redirect to other URLs: a 493 site that does registration through a federated site, a site that 494 only does registration under HTTPS, and so on. Like any HTTP client, 495 HOBA-http clients have to be able to handle redirection of these 496 URLs. However, as that would potentially cause security issues when 497 a re-direct brings the client to a different web origin, servers 498 implementing HOBA-http SHOULD NOT re-direct to a different web origin 499 from below .well-known/hoba URLs. The above is considered sufficient 500 to allow experimentation with HOBA, but if at some point HOBA is 501 placed on the standards track then a full analysis of off-origin re- 502 directions would need to be documented. 504 6.1. Registration 506 Normally, a registration (also called "joining") is expected to 507 happen after a UA receives a WWW-Authenticate for a web-origin and 508 realm (for HOBA-http) or on demand (for HOBA-js) for which it has no 509 associated CPK. The process of registration for a HOBA account on a 510 server is relatively light-weight. The UA generates a new key pair, 511 and associates it with the web-origin/realm in question. 513 Note that if the UA has a CPK associated with the web-origin, but not 514 for the realm concerned, then a new registration is REQUIRED. If the 515 server did not wish for that outcome, then it ought to use the same 516 or no realm. 518 The registration message for HOBA-http is sent as a POST message to 519 the URL ".well-known/hoba/register" with an HTML form (x-www-form- 520 encoded) described below; The registration message for HOBA-js can be 521 in any format specified by the server, but it could be the same as 522 the one described here for HOBA-http. It is up to the server to 523 decide what kind of user interaction is required before the account 524 is finally set up. When the server's chosen registration flow is 525 completed successfully the server MUST add a Hobareg HTTP header (see 526 Section 6.1.1) to the HTTP response message that completes the 527 registration flow. 529 The registration message sent to server has one mandatory field (pub) 530 and some optional fields that allow the UA to specify the type and 531 value of key and device identifiers that the UA wishes to use. 533 o pub: is a mandatory field containing the PEM formatted public key 534 of the client. See Appendix C of [RFC6376] for an example of how 535 to generate this key format. 537 o kidtype: contains the type of key identifier, this is a numeric 538 value intended to contain one of the values from Section 9.4. If 539 this is not present then the mandatory-to-implement hashed public 540 key option MUST be used. 542 o kid: contains the key identifier as a base64url encoded string 543 that is of the type indicated in the kidtype. If the kid is a 544 hash of a public key then the correct (base64url encoded) hash 545 value MUST be provided and the server SHOULD check that and refuse 546 the registration if an incorrect value was supplied. 548 o didtype: specifies a kind of device identifier intended to contain 549 one of the values from Section 9.5, if absent then the "string" 550 form of device identifier MUST be used. 552 o did: a UTF8 string that specifies the device identifier. This can 553 be used to help a user be confident that authentication has 554 worked, e.g., following authentication some web content might say 555 "You last logged in from device 'did' at time T." 557 Note that replay of registration (and other HOBA) messages is quite 558 possible. That however can be counteracted if challenge freshness is 559 ensured. See Section 2 for details. Note also that with HOBA-http 560 the HOBA signature does not cover the POST message body. If that is 561 required then HOBA-JS may be a better fit for registration and other 562 account management actions. 564 6.1.1. Hobareg Definition 566 Since registration can often be a multi-step process, e.g. requiring 567 a user to fill in contact details, the initial response to the HTTP 568 POST message defined above may not be the end of the registration 569 process even though the HTTP response has a 200 OK status. This 570 creates an issue for the UA since, during the registration process 571 (e.g., while dealing with interstitial pages), the UA doesn't yet 572 know whether the CPK is good for that web origin or not. 574 For this reason the server MUST add a header to the response message 575 when the registration has succeded to indicate the new state. The 576 header to be used is "Hobareg" and the value when registration has 577 succeeded is to be "regok". When registration is inwork (e.g. on an 578 HTTP response for an interstitial page) the server MAY add this 579 header with a value of "reginwork". See Section 9.6 for the relevant 580 IANA registration of this header field. 582 For interstitial pages, the client MAY include a HOBA Authorization 583 header. This is not considered a MUST as that might needlessly 584 complicate client implementations but is noted here in case a server 585 implementer assumes that all registration messages contain a HOBA 586 Authorization header. 588 Hobareg-val = "regok" / "inwork" 590 Figure 3: Hobareg Header Field Definition 592 Figure 3 provides an ABNF definition for the values allowed in the 593 Hobareg header field. Note that these (and the header field name) 594 are case insensitive. Section 8.3.1 of [RFC7231] calls for 595 documenting the following details for this new header field: 597 o Only one single value is allowed in a Hobareg header field. 598 Should more than one (a list) be encountered, that should be 599 interpreted as being the same as "inwork." 601 o The Hobareg header field can only be used in HTTP responses. 603 o Since Hobareg is only meant for responses it ought not appear in a 604 PUT request. 606 o The HTTP response code does affect the interpretation of Hobareg. 607 Registration is only considered to have succeeded if the regok 608 value is seen in a 2xx response. 4xx and other errors means that 609 registration has failed regardless of the value of Hobareg seen. 610 The request method has no influence on the interpretation of 611 Hobareg. 613 o Intermediaries should never insert, delete or modify a Hobareg 614 header field. 616 o As a response-only header field, it is not appropriate to list a 617 Hobareg in a Vary response header field. 619 o Hobareg is allowed in trailers. 621 o As a response-only header field, Hobareg will not be preserved 622 across re-directs. 624 o Hobareg itself discloses little security or privacy sensitive 625 information. If an attacker can somehow detect that a Hobareg 626 header field is being added, then that attacker would know that 627 the UA is in the process of registration which could be 628 significant. However, it is likely that the set of messages 629 between the UA and server would expose this information in many 630 cases, regardless of whether or not TLS is used. Using TLS is 631 still however a good plan. 633 6.2. Associating Additional Keys to an Exiting Account 635 From the user perspective, the UA having a CPK for a web origin will 636 often appear to be the same as having a way to sign in to an account 637 at that web site. Since users often have more than one UA, and since 638 the CPKs are, in general, UA-specific, that raises the question of 639 how the user can sign in to that account from different UAs. And 640 from the server perspective that turns into the question of how to 641 safely bind different CPKs to one account. In this section, we 642 describe some ways in which this can be done, as well as one way in 643 which this ought not be done. 645 Note that the context here is usually that the user has succeeded in 646 registering with one or more UAs (for the purposes of this section we 647 call this "the first UA" below) and can use HOBA with those, and the 648 user is now adding another UA. The newest UA might or might not have 649 a CPK for the site in question. Since it is in fact trivial, we 650 assume that the site is able to put in place some appropriate 651 quicker, easier registration for a CPK for the newest UA. The issue 652 then becomes one of binding the CPK from the newest UA with those of 653 other UAs bound to the account. 655 6.2.1. Moving private keys 657 It is common for a user to have multiple UAs, and to want all those 658 UAs to be able to authenticate to a single account. One method to 659 allow a user who has an existing account to be able to authenticate 660 on a second device is to securely transport the private and public 661 keys and the origin information from the first device to the second. 662 If this approach is taken, then there is no impact on the HOBA-http 663 or HOBA-js so this is a pure UA implementation issue and not 664 discussed further. 666 6.2.2. Human memorable one time password (don't do this one) 667 It will be tempting for implementers to use a human-memorable one- 668 time password (OTP) in order to "authenticate" binding CPKs to the 669 same account. The workflow here would likely be something along the 670 lines of some server administrative utility generating a human 671 memorable OTP such as "1234" and sending that to the user out of band 672 for the user to enter at two web pages each authenticated via the 673 relevant CPK. While this seems obvious enough and could even be 674 secure enough in some limited cases, we consider that this is too 675 risky to use in the Internet and so servers SHOULD NOT provide such a 676 mechanism. The reason this is so dangerous is that it would be 677 trivial for an automated client to guess such tokens and "steal" the 678 binding intended for some other user. At any scale, there would 679 always be some in-process bindings so that even with only a trickle 680 of guesses (and hence not being detectable via message volume) an 681 attacker would have a high probability of succeeding in registering a 682 binding with the attacker's CPK. 684 This method of binding CPKs together is therefore NOT RECOMMENDED. 686 6.2.3. Out of band URL 688 One easy binding method is to simply provide a web page where, using 689 the first UA, the user can generate a URL (containing some 690 "unguessable" cryptographically generated value) that the user then 691 later de-references on the newest UA. The user could e-mail that URL 692 to herself for example, of the web server accessed at the first UA 693 could automatically do that. 695 Such a URL SHOULD contain at least the equivalent of 128 bits of 696 randomness. 698 6.3. Logging Out 700 The user can tell the server it wishes to log out. With HOBA-http, 701 this is done by sending any HOBA-authenticated HTTP message to the 702 URL ".well-known/hoba/logout" on the site in question. The UA SHOULD 703 also delete session cookies associated with the session so that the 704 user's state is no longer "logged in." 706 The server MUST NOT allow TLS session resumption for any logged out 707 session. 709 The server SHOULD also revoke or delete any cookies associated with 710 the session. 712 6.4. Getting a Fresh Challenge 713 The UA can get a "fresh" challenge from the server. In HOBA-http, it 714 sends a POST message to ".well-known/hoba/getchal". If successful, 715 the response response MUST include a fresh (base64url encoded) HOBA 716 challenge for this origin in the body of the response. 718 7. Mandatory-to-Implement Algorithms 720 RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus 721 lengths of at least 2048 bits SHOULD be used. RSA is defined in 722 Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. 724 8. Security Considerations 726 If key binding was server-selected then a bad actor could bind 727 different accounts belonging to the user from the network with 728 possible bad consequences, especially if one of the private keys was 729 compromised somehow. 731 Binding my CPK with someone else's account would be fun and 732 profitable so SHOULD be appropriately hard. In particular URLs or 733 other values generated by the server as part of any CPK binding 734 process MUST be hard to guess, for whatever level of difficulty is 735 chosen by the server. The server SHOULD NOT allow a random guess to 736 reveal whether or not an account exists. 738 When the max-age parameter is not zero, then a HOBA signature has a 739 property that is like a bearer token for the relevant number of 740 seconds: it can be replayed for a server-selected duration. 741 Similarly, for HOBA-js, signatures might be replayable depending on 742 the specific implementation. The security considerations of 743 [RFC6750] therefore apply in any case where the HOBA signature can be 744 replayed. Server administrators SHOULD set the max-age to the 745 minimum acceptable value in such cases, which would often be expected 746 to be just a few seconds. There seems to be no reason to ever set 747 the max-age more than a few minutes; the value ought also decrease 748 over time as device capabilities improve. The administrator will 749 most likely want to set the max-age to something that is not too slow 750 on the slowest signing device that is significant for that site. 752 8.1. Privacy considerations 754 HOBA does impact to some extent on privacy and could be considered to 755 represent a super-cookie to the server, or to any entity on the path 756 from UA to HTTP server that can see the HOBA signature. This is 757 because we need to send a key identifier as part of the signature and 758 that will not vary for a given key. For this reason, and others, it 759 is strongly RECOMMENDED to only use HOBA over server-authenticated 760 TLS and to migrate web sites using HOBA to only use "https" URLs. 762 UAs SHOULD provide users a way to manage their CPKs. Ideally, there 763 would be a way for a user to maintain their HOBA details for a site 764 while at the same time deleting other site information such as 765 cookies or non-HOBA HTML5 LocalStorage. However, as this is likely 766 to be complex and appropriate user interfaces counter intutitive, we 767 exepect that UAs that implement HOBA will likely treat HOBA 768 information as just some more site data, that would disappear should 769 the user choose to "forget" that site. 771 8.2. localStorage Security for Javascript 773 Our use of localStorage will undoubtedly be a cause for concern. 774 localStorage uses the same-origin model which says that the scheme, 775 domain and port define a localStorage instance. Beyond that, any 776 code executing will have access to private keying material. Of 777 particular concern are XSS attacks which could conceivably take the 778 keying material and use it to create UAs under the control of an 779 attacker. But XSS attacks are in reality across the board 780 devastating since they can and do steal credit card information, 781 passwords, perform illicit acts, etc, etc. It's not clear that we 782 introduce unique threats from which clear text passwords don't 783 already suffer. 785 Another source of concern is local access to the keys. That is, if 786 an attacker has access to the UA itself, they could snoop on the key 787 through a javascript console, or find the file(s) that implement 788 localStorage on the host computer. Again it's not clear that we are 789 worse in this regard because the same attacker could get at browser 790 password files, etc too. One possible mitigation is to encrypt the 791 keystore with a password/pin the user supplies. This may sound 792 counter intuitive, but the object here is to keep passwords off of 793 servers to mitigate the multiplier effect of a large scale compromise 794 ala LinkedIn because of shared passwords across sites. 796 It's worth noting that HOBA uses asymmetric keys and not passwords 797 when evaluating threats. As various password database leaks have 798 shown, the real threat of a password breach is not just to the site 799 that was breached, it's all of the sites a user used the same 800 password on too. That is, the collateral damage is severe because 801 password reuse is common. Storing a password in localStorage would 802 also have a similar multiplier effect for an attacker, though perhaps 803 on a smaller scale than a server-side compromise: one successful 804 crack gains the attacker potential access to hundreds if not 805 thousands of sites the user visits. HOBA does not suffer from that 806 attack multiplier since each asymmetric key pair is unique per site/ 807 UA/user. 809 8.3. Multiple Accounts on One User Agent 811 A shared UA with multiple accounts is possible if the account 812 identifier is stored along with the asymmetric key pair binding them 813 to one another. Multiple entries can be kept, one for each account, 814 and selected by the current user. This, of course, is fraught with 815 the possibility for abuse, since a server is potentially enrolling 816 the device for a long period and the user may not want to have to be 817 responsible for the credential for that long. To alleviate this 818 problem, the user can request that the credential be erased from the 819 browser. Similarly, during the enrollment phase, a user could 820 request that the key pair only be kept for a certain amount of time, 821 or that it not be stored beyond the current browser session. 823 9. IANA Considerations 825 IANA is requested to make registrations and create new registries as 826 described below. 828 9.1. HOBA Authentication Scheme 830 Please register a new scheme in the HTTP Authentication Scheme 831 Registry registry as follows: 833 Authentication Scheme Name: HOBA 835 Pointer to specification text: Section 3 of [[ this document ]] 837 Notes (optional): The HOBA scheme can be used with either HTTP 838 servers or proxies. When used in response to a 407 Proxy 839 Authentication Required indication, the appropriate proxy 840 authentication header fields are used instead, as with any other HTTP 841 authentication scheme. 843 9.2. .well-known URI 845 Please register a new .well-known URI in the Well-Known URIs registry 846 as described below. 848 URI suffix: hoba 850 Change controller: IETF 852 Specification document(s): Section 6 of [[ this document ]] 854 Related information: N/A 856 9.3. Algorithm Names 858 Please create a new HOBA signature algorithms registry as follows, 859 with the specification required rule for updates. New HOBA signature 860 algorithms SHOULD be in use with other IETF standards track protocols 861 before being added to this registry. 863 Number Meaning 864 ----------- -------------------------------------------- 865 0 RSA-SHA256 866 1 RSA-SHA1 868 RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are 869 defined in [SHS]. 871 For this registry the number column should contain a small positive 872 integer. 874 9.4. Key Identifier Types 876 Please create a new HOBA Key Identifier Types registry as follows, 877 with the specification required rule for updates. 879 Number Meaning 880 ----------- -------------------------------------------- 881 0 a hashed public key [RFC6698] 882 1 a URI [RFC3986] 883 2 an unformatted string, at the user's/UA's whim 885 For the number 0, hashed public keys are as done in DANE. [RFC6698] 887 For this registry the number column should contain a small positive 888 integer. 890 9.5. Device Identifier Types 892 Please create a new HOBA Device Identifier Types registry as follows, 893 with the specification required rule for updates. 895 Number Meaning 896 ----------- -------------------------------------------- 897 0 an unformatted string, at the user's/UA's whim 899 For this registry the number column should contain a small positive 900 integer. 902 9.6. Hobareg HTTP Header 904 Please register a new identifier in the Permanent Message Header 905 Field Names registry as described below. 907 Header field name: Hobareg 909 Applicable protocol: HTTP (RFC 7230) 911 Status: Experimental 913 Author/Change controller: IETF 915 Specification document(s): Section 6.1.1 of [[ this document ]] 917 Related information: N/A 919 10. Implementation Status 921 [[ Note to RFC editor - please delete this section before 922 publication. ]] 924 This section records the status of known implementations of the 925 protocol defined by this specification at the time of posting of this 926 Internet-Draft, and is based on a proposal described in [RFC6982]. 927 The description of implementations in this section is intended to 928 assist the IETF in its decision processes in progressing drafts to 929 RFCs. Please note that the listing of any individual implementation 930 here does not imply endorsement by the IETF. Furthermore, no effort 931 has been spent to verify the information presented here that was 932 supplied by IETF contributors. This is not intended as, and must not 933 be construed to be, a catalog of available implementations or their 934 features. Readers are advised to note that other implementations may 935 exist. 937 According to [RFC6982] "this will allow reviewers and working groups 938 to assign due consideration to documents that have the benefit of 939 running code, by considering the running code as evidence of valuable 940 experimentation and feedback that has made the implemented protocols 941 more mature. It is up to the individual working groups to use this 942 information as they see fit". 944 At the time of writing there are two known implementations. One done 945 by Stephen Farrell of HOBA-http and a HOBA-JS variant implements the 946 current (-04) version of HOBA and is available from https://hoba.ie/ 947 which site also includes a demonstration of HOBA. 949 There is another implementation by Michael Thomas of an HOBA-JS 950 variant. 952 11. Acknowledgements 954 Thanks to the following for good comments received during the 955 preparation of this specification: Amos Jeffries, Benjamin Kaduk, 956 Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Melnikov, Yoav 957 Nir, Mark Nottingham, Julian Reschke, Michael Richardson, Yaron 958 Sheffer, and Michael Sweet. All errors and stupidities are of course 959 the editors' fault. 961 12. References 963 12.1. Normative References 965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 966 Requirement Levels", BCP 14, RFC 2119, March 1997. 968 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 969 Standards (PKCS) #1: RSA Cryptography Specifications 970 Version 2.1", RFC 3447, February 2003. 972 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 973 Resource Identifier (URI): Generic Syntax", STD 66, RFC 974 3986, January 2005. 976 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 977 Specifications: ABNF", STD 68, RFC 5234, January 2008. 979 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 980 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 982 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 983 Uniform Resource Identifiers (URIs)", RFC 5785, April 984 2010. 986 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 987 2011. 989 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 990 of Named Entities (DANE) Transport Layer Security (TLS) 991 Protocol: TLSA", RFC 6698, August 2012. 993 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 994 Framework: Bearer Token Usage", RFC 6750, October 2012. 996 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 997 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 999 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1000 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1002 [SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST 1003 Special Publications , March 2012. 1005 12.2. Informative References 1007 [MI93] Mitchell, and Thomas, "Standardising Authentication 1008 Protocols Based on Public-Key Techniques.", Journal of 1009 Computer Security 2 (1993): 23-36. , 1993. 1011 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1012 Encodings", RFC 4648, October 2006. 1014 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1015 April 2011. 1017 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1018 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 1019 September 2011. 1021 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1022 Code: The Implementation Status Section", RFC 6982, July 1023 2013. 1025 [bonneau] Bonneau, , "The science of guessing: analyzing an 1026 anonymized corpus of 70 million passwords.", Security and 1027 Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012. 1029 Appendix A. Problems with Passwords 1031 By far the most common mechanism for web authentication is passwords 1032 that can be remembered by the user, called "human-memorable 1033 passwords". There is plenty of good research on how users typically 1034 use human-memorable passwords (e.g. see [bonneau]), but some of the 1035 highlights are that users typically try hard to reuse passwords on as 1036 many web sites as possible, and that web sites often use either email 1037 addresses or users' names as the identifier that goes with these 1038 passwords. 1040 If an attacker gets access to the database of memorizable passwords, 1041 that attacker can impersonate any of the users. Even if the breach 1042 is discovered, the attacker can still impersonate users until every 1043 password is changed. Even if all the passwords are changed or at 1044 least made unusable, the attacker now possesses a list of likely 1045 username/password pairs that might exist on other sites. 1047 Using memorizable passwords on unencrypted channels also poses risks 1048 to the users. If a web site uses either the HTTP Plain 1049 authentication method, or an HTML form that does no cryptographic 1050 protection of the password in transit, a passive attacker can see the 1051 password and immediately impersonate the user. If a hash-based 1052 authentication scheme such as HTTP Digest authentication is used, a 1053 passive attacker still has a high chance of being able to determine 1054 the password using a dictionary of known passwords. 1056 Note that passwords that are not human-memorable are still subject to 1057 database attack, though are of course unlikely to be re-used across 1058 many systems. Similarly, database attacks of some form or other will 1059 work against any password based authentication scheme, regardless of 1060 the crytographic protocol used. So for example, zero-knowledge or 1061 PAKE schemes, though making use of elegant cryptographic protocols, 1062 remain as vulnerable to what is clearly the most common exploit seen 1063 when it comes to passwords. HOBA is however not vulnerable to 1064 database theft. 1066 Appendix B. Example 1068 The following values show an example of HOBA-http authentication to 1069 the origin https://hoba-local.ie. Carriage-returns have been added 1070 and need to be removed to validate the example. 1072 -----BEGIN PUBLIC KEY----- 1073 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3TpLg0kglmnZIXNQZ6g6 1074 Aj6b9PAhHD1TojOiuJZAY8KblNu-0WbiUSwTzl1EPBCa4Og3SNR0-8omb09iDSTV 1075 nKGEYcAHxP2wvvqOFrb6f8GWFHxHw4MiODlnSTvHARx6wiogY4w7WIs57ETZfiJY 1076 MYyo6swHXO4DofteTasjuQwZ_5L4sbCR_aZx7Nsv4O4hNhCreoCfh0QD6pQQ-krW 1077 0Ny8mGEecnAG0reXRgBvCmDq2I15jV8yqXuNYqEORO-vur2-JztH8pQUoSTfTkMv 1078 h0EyVfWzq9KtykKWXyv625CGVkxR3MMAfitxKgtZit0hw9_VCXtfhvwZcfnhmhxG 1079 ZQIDAQAB 1080 -----END PUBLIC KEY----- 1082 Key Identifier: kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267UetbAfkWHbw 1084 Challenge: z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs= 1086 Nonce: LV_WTVyHFfE 1088 Tbsorigin: https://hoba-local.ie:443 1090 The resulting signature is: 1092 qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZajb 1093 zb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR84 1094 O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX57 1095 2ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDqX 1096 PwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww9 1097 XO593LaL3LnykmMn11ddiw 1099 The final HTTP header field sent with a request is then: 1101 Authorization: HOBA result="kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267Uetb 1102 AfkWHbw.z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs=.LV_WTVyHFfE 1103 .qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZaj 1104 bzb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR8 1105 4O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX5 1106 72ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDq 1107 XPwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww 1108 9XO593LaL3LnykmMn11ddiw" 1110 Authors' Addresses 1112 Stephen Farrell 1113 Trinity College Dublin 1114 Dublin 2 1115 Ireland 1117 Phone: +353-1-896-2354 1118 Email: stephen.farrell@cs.tcd.ie 1120 Paul Hoffman 1121 VPN Consortium 1123 Email: paul.hoffman@vpnc.org 1125 Michael Thomas 1126 Phresheez 1128 Email: mike@phresheez.com