idnits 2.17.1 draft-ietf-httpauth-hoba-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3910 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-23 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Experimental P. Hoffman 5 Expires: January 16, 2014 VPN Consortium 6 M. Thomas 7 Phresheez 8 July 15, 2013 10 HTTP Origin-Bound Authentication (HOBA) 11 draft-ietf-httpauth-hoba-01 13 Abstract 15 HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP 16 authentication method with credentials that are not vulnerable to 17 phishing attacks, and that does not require a server-side password 18 database. The design can also be used in Javascript-based 19 authentication embedded in HTML. HOBA is an alternative to HTTP 20 authentication schemes that require passwords with all the negative 21 attributes that come with password-based systems. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 16, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 5 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 60 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . . 6 61 3. HOBA HTTP Authentication Mechanism . . . . . . . . . . . . . . 8 62 4. Using HOBA-http . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10 64 4.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10 65 4.3. Authentication Phase . . . . . . . . . . . . . . . . . . . 10 66 4.4. Logging in on a New User Agent . . . . . . . . . . . . . . 11 67 5. Using HOBA-js . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.1. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.2. User Join . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.3. User Login . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.4. Enrolling a New User Agent . . . . . . . . . . . . . . . . 12 72 5.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 13 73 5.6. Signature Parameters . . . . . . . . . . . . . . . . . . . 13 74 5.7. Session Management . . . . . . . . . . . . . . . . . . . . 15 75 5.8. Multiple Accounts on One User Agent . . . . . . . . . . . 15 76 5.9. Oddities . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 6. Additional Services . . . . . . . . . . . . . . . . . . . . . 16 78 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 16 79 6.2. Associating Additional Keys to an Exiting Account . . . . 17 80 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 18 82 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 18 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 8.1. localStorage Security for Javascript . . . . . . . . . . . 19 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 20 87 9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 20 88 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20 89 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . . 20 90 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20 91 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 96 Appendix A. Problems with Passwords . . . . . . . . . . . . . . . 23 97 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 23 98 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 25 99 C.1. WG-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 C.2. WG-00 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 103 1. Introduction 105 [[ Commentary is in double-square brackets, like this. As you'll see 106 there are a bunch of details still to be figured out. Feedback on 107 those is very welcome. Also note that the authors fully expect that 108 the description of HOBA-http and HOBA-js to be mostly merged in the 109 draft; they're both here now so readers can see some alternatives and 110 maybe support particular proposals. ]] 112 HTTP Origin-Bound Authentication (HOBA) is an authentication design 113 that can be used as an HTTP authentication scheme and for Javascript- 114 based authentication embedded in HTML. The main goal of HOBA is to 115 offer an easy-to-implement authentication scheme that is not based on 116 passwords, but that can easily replace HTTP or HTML forms-based 117 password authentication. If deployment of HOBA reduces the number of 118 password entries in databases by any appreciable amount, then it 119 would be worthwhile. As an HTTP authentication scheme, it would work 120 in the current HTTP 1.0 and HTTP 1.1 authentication framework, and 121 will very likely work with whatever changes are made to the HTTP 122 authentication scheme in HTTP 2.0. As a JavaScript design, HOBA 123 demonstrates a way for clients and servers to interact using the same 124 credentials that are use by the HTTP authentication scheme. 126 The HTTP specification defines basic and digest authentication 127 methods for HTTP that have been in use for many years, but which, 128 being based on passwords, are susceptible to theft of server-side 129 databases. (See [RFC2617] for the original specification, and 130 [I-D.ietf-httpbis-p7-auth] for clarifications and updates to the 131 authentication mechanism.) Even though few large web sites use basic 132 and digest authentication, they still use username/password 133 authentication and thus have large susceptible server-side databases 134 of passwords. 136 Instead of passwords, HOBA uses digital signatures as an 137 authentication mechanism. HOBA also adds useful features such as 138 credential management and session logout. In HOBA, the client 139 creates a new public-private key pair for each host ("web-origin") to 140 which it authenticates; web-origins are defined in [RFC6454]. These 141 keys are used in HOBA for HTTP clients to authenticate themselves to 142 servers in the HTTP protocol or in a Javascript authentication 143 program. 145 HOBA keys need not be stored in public key certificates. Because 146 these are generally "bare keys", there is none of the semantic 147 overhead of PKIX certificates, particularly with respect to naming 148 and trust anchors. Thus, client public keys ("CPKs") do not have any 149 publicly-visible identifier for the user who possesses the 150 corresponding private key, nor the web-origin with which the client 151 is using the CPK. HOBA keys are stored in subjectPublicKeyInfo 152 structures from PKIX [RFC5280] 154 HOBA also defines some services that are required for modern HTTP 155 authentication: 157 o Servers can bind a CPK with an identifier, such as an account 158 name. HOBA allows servers to define their own policies for 159 binding CPKs with accounts during account registration. 161 o Users are likely to use more than one device or user agent (UA) 162 for the same HTTP based service, so HOBA gives a way to associate 163 more than one CPK to the same account, but without having to 164 register for each separately. 166 o Users are also likely to lose a private key, or the client's 167 memory of which key pair is associated with which origin. For 168 example if a user loses the computer or mobile device in which 169 state is stored. HOBA allows for clients to tell servers to 170 delete the association between an existing CPK and an account. 172 o Logout features can be useful for UAs, so HOBA defines a way to 173 close a current HTTP "session", and also a way to close all 174 current sessions, even if more than one session is currently 175 active from different UAs for the same account. 177 o Since there are always devices and applications in which state of 178 the art digital signature mechanism runtimes are significant, and 179 since HTTP authentication in theory requires that every HTTP 180 request to a given realm have a signature in an "Authorization" 181 header field, and since HOBA is a challenge response scheme, we 182 also define a way in which HTTP servers can indicate the duration 183 for which they will consider a given challenge value to be valid. 184 As a consequence we also define a way for UAs to fetch a fresh 185 challenge. 187 1.1. Interfacing to Applications (Cookies) 189 HOBA can be used as a drop-in replacement for password-based user 190 authentication schemes used in common web applications. The simplest 191 way in which this can be done is to (re-)direct the UA to a HOBA 192 "Login" URL and for the response to a successful HTTP request 193 containing a HOBA signature to set a session cookie [RFC6265]. 194 Further interactions with the web application will then be secured 195 via the session cookie, as is commonly done today. 197 While cookies are bearer tokens, and thus weaker than HOBA 198 signatures, they are currently ubiquitously used. If non-bearer 199 token session continuation schemes are developed in future in the 200 IETF or elsewhere, then those can interface to HOBA as easily as with 201 any password based authentication scheme. 203 1.2. Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 A client public key ("CPK") is the public key and associated 210 cryptographic parameters needed for a server to validate a signature. 212 The term "account" is (loosely) used to refer to whatever data 213 structure(s) the server maintains that are associated with an 214 identity. That will contain of at least one CPK and a web-origin; it 215 will also optionally include an HTTP "realm" as defined in the HTTP 216 authentication specification. It might also involve many other non- 217 standard pieces of data that the server accumulates as part of 218 account creation processes. An account may have many CPKs that are 219 considered equivalent in terms of being usable for authentication, 220 but the meaning of "equivalent" is really up to the server and is not 221 defined here. 223 When describing something that is specific to HOBA as an HTTP 224 authentication mechanism or HOBA as a JavaScript implementation, this 225 document uses the terms "HOBA-http" and "HOBA-js", respectively. 227 Web client: the content and javascript code that run within the 228 context of a single UA instance (such as a tab in a web browser). 230 User agent (UA): typically, but not always, a web browser. 232 User: a person who is running a UA. In this document, "user" does 233 not mean "user name" or "account name". 235 This specification uses the Augmented Backus-Naur Form (ABNF) 236 notation of [RFC5234] 238 2. The HOBA Authentication Scheme 240 A UA that implements HOBA maintains a list of web-origins and realms. 241 The UA also maintains one or more client credentials for each web- 242 origin/realm combination for which it has created a CPK. 244 On receipt of a challenge (and optional realm) from a server, the 245 client marshals an HOBA to-be-signed (TBS) blob that includes a 246 client generated nonce, the web-origin, the realm, an identifier for 247 the CPK and the challenge string; and signs that hashed blob with the 248 private key corresponding to the CPK for that web-origin. The 249 formatting chosen for this TBS blob is chosen so as to make server- 250 side signature verification as simple as possible for a wide-range of 251 current server tooling. 253 Figure 1 specifies the ABNF for the signature input. 255 HOBA-TBS = nonce alg origin realm kid challenge 256 nonce = unreserved 257 alg = 1*2DIGIT 258 origin = scheme authority port 259 realm = unreserved 260 kid = unreserved 261 challenge = unreserved 263 Figure 1: To-be-signed data for HOBA 265 The fields above contain the following: 267 o nonce: is a random value chosen by the UA and MUST be base64url 268 encoded before being included in the HOBA-TBS value. UAs MUST be 269 able to use at least 32 bits of randomness in generating a nonce. 270 UAs SHOULD be able to use up to 64 bits of randomness for nonces. 272 o alg: specifies the signature algorithm being used encoded as an 273 ASCII character as defined in Section 9.3. RSA-SHA256 MUST be 274 supported, RSA-SHA1 MAY be supported. The IANA registered 275 algorithm values are encoded as ASCII numbers; for example, the 276 encoding of RSA-SHA256 is 0x30. 278 o origin: is the web origin expressed as the concatenation of the 279 scheme, authority and port are from [RFC3986]. These are not 280 base64 encoded as they will be most readily available to the 281 server in plain text. For example, if accessing the URL 282 "https://www.example.com:8080/foo" then the bytes input to the 283 signature process will be "httpswww.example.com8080" 285 o realm: is similarly just a string with the syntactic restrictions 286 defined in [I-D.ietf-httpbis-p7-auth]. If no realm is specified 287 for this authentication then this is absent. (A missing field 288 here is no problem since both sides know when it needs to be 289 there.) 291 o kid: is a key identifier - this MUST be a base64url encoded value 292 that is presented to the server in the HOBA client result (see 293 below). 295 o challenge: MUST be a base64url encoded challenge value that the 296 server chose to send to the client 298 The HOBA-TBS string is the input to the client's signing process, but 299 is not itself sent over the network since some fields are already 300 inherent in the HTTP exchange. The challenge however is sent over 301 the network so as to make it simpler for a server to be stateless. 302 (One form of stateless challenge might be a ciphertext that the 303 server decrypts and checks, but that is an implementation detail.) 304 The value that is sent over the network is the HOBA "client result" 305 which we now define. 307 The HOBA "client result" is a dot-separated string that includes the 308 signature and is sent in the HTTP Authorized header field value using 309 the value syntax defined in Figure 2. The "sig" value is the 310 base64url encoded version of the binary output of the signing 311 process. The kid, challenge and nonce are as defined above and are 312 also base64url encoded. [[Expect more changes here. This is very 313 like JOSE's compact form and maybe ought be an instance of that.]] 315 HOBA-RES = kid "." challenge "." nonce "." sig 316 sig = unreserved 318 Figure 2: HOBA Client Result value 320 The HOBA scheme is far from new, for example, the basic idea is 321 pretty much identical to the first two messages from "Mechanism R" on 322 page 6 of [MI93] which predates HOBA by 20 years. 324 3. HOBA HTTP Authentication Mechanism 326 An HTTP server that supports HOBA authentication includes the "HOBA" 327 auth-scheme value in a WWW-Authenticate header field when it wants 328 the client to authenticate with HOBA. 330 o If the "HOBA" scheme is listed, it MUST be followed by two or more 331 auth-param values. The auth-param attributes defined by this 332 specification are below. Other auth-param attributes MAY be used 333 as well. Unknown auth-param attributes MUST be ignored by 334 clients, if present. 336 o The "challenge" attribute MUST be included. The challenge is the 337 string made up of the base64url encoded octets that the server 338 wants the client to sign in its response. The challenge SHOULD be 339 unique for every HTTP 401 response in order to prevent replay 340 attacks from passive observers. 342 o An "expires" attribute MUST be included that specifies the number 343 of seconds from the time the HTTP response is emitted for which 344 responses to this challenge can be accepted. 346 o A "realm" attribute MAY be included to indicate the scope of 347 protection in the manner described in HTTP/1.1, Part 7 348 [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear 349 more than once. 351 When the "client response" is created, the UA encodes the HOBA 352 client-result (a string matching the HOBA-RES production in Figure 2 353 as an auth-param with the name "result" and returns that in the 354 Authorization header. 356 Note that a HOBA signature is good for however long the expires 357 attribute allows. This means that replay is potentially possible 358 within the time window specified by the "expires" value chosen by the 359 server. Servers SHOULD attempt to detect any such replay and MAY 360 react to such replays by responding with a second (or subsequent) 361 401-status HTTP response containing a new challenge. 363 UAs MAY optimise their use of challenges by pre-fetching a challenge 364 value, for example after "expires"/2 seconds have elapsed using the 365 ".well-known/hoba/getChal" scheme described below. This also allows 366 for pre-calculation of HOBA signatures, if that is required in order 367 to produce a responsive user interface. 369 4. Using HOBA-http 371 [[A lot of this is similar to the HOBA-js discussion below. At some 372 point some nuclear fusion might be nice, but for now it might be best 373 to keep them separate until we understand better what can be merged, 374 and what is different.]] 376 The interaction between an HTTP client and HTTP server using HOBA 377 happens in three phases: the CPK preparation phase, the signing 378 phase, and the authentication phase. The first and second phase are 379 done in a standard fashion; the third is done using site-specific 380 methods. In addition, we provide a mechanism for pre-fetching 381 challenges. 383 4.1. CPK Preparation Phase 385 In the CPK preparation phase, the client determines if it already has 386 a CPK for the web-origin it is going to. If the has a CPK, the 387 client will use it; if the client does not have a CPK, it generates 388 one in anticipation of the server asking for one. 390 4.2. Signing Phase 392 In the signing phase, the client connects to the server, the server 393 asks for HOBA-based authentication, and the client authenticates by 394 signing a blob of information as described in the previous sections. 396 The UA tries to access a protected resource on the server. The 397 server sends the HOBA WWW-Authenticate challenge. The UA receives 398 the challenge and signs the challenge using the CPK it either already 399 had or just generated. The server validates the signature. If 400 validation fails, or if the server chooses to do so for other 401 reasons, then server aborts the transaction via a 403 Unauthorized 402 HTTP response. 404 4.3. Authentication Phase 406 In the authentication phase, the server extracts the CPK from the 407 signing phase and decides if it recognizes the CPK. If the server 408 recognizes the CPK, the server may finish the client authentication 409 process. If this stage of the process involves additional 410 information for authentication, such as asking the user which account 411 she wants to use (in the case where a UA is used for multiple 412 accounts on a site), the server can prompt the user for account 413 identifying information or the user could choose based on HTML 414 offered by the server before the 401 is triggered. None of this is 415 standardized: it all follows the server's security policy and session 416 flow. At the end of this, the server probably assigns or updates a 417 session cookie for the client. 419 If the server does not recognize the CPK the server might send the 420 client through a either a join or login-new-UA (see below) process. 421 This process is completely up to the server, and probably entails 422 using HTML and JavaScript to ask the user some questions in order to 423 assess whether or not the server wants to give the client an account. 424 Completion of the joining process might require confirmation by 425 email, SMS, Captcha, and so on. 427 Note that there is no necessity for the server to initiate a joining 428 or login process upon completion of the signing phase. Indeed, the 429 server may desire to challenge the UA even for unprotected resources 430 and set a session cookie for later use in a join or login process as 431 it becomes necessary. For example, a server might only want to offer 432 an account to someone who had been to a few pages on the web site; in 433 such a case, the server could use the CPK from an associated session 434 cookie as a way of building reputation for the user until the server 435 wants the user to join. 437 After the UA is authenticated (if the user had to join, this could be 438 the last step of joining), the server gives the UA access to the 439 protected resource that was originally requested at the beginning of 440 the signing phase. It is quite likely that the server would also 441 update the UA's session cookie for the web site. 443 4.4. Logging in on a New User Agent 445 When a user wants to use a new UA for an existing account, the flows 446 are similar to logging in with an already-joined UA or joining for 447 the first time. In fact, the CPK preparation phase (with the UA 448 knowing that it needs to create a new CPK) and the signing phase are 449 identical. 451 During the authentication phase, the server could use HTML and 452 JavaScript to ask the user if they are really a new user or want to 453 associate this new CPK with an already-joined CPK. The server can 454 then use some out-of-band method (such as a confirmation email round 455 trip, SMS, or an UA that is already enrolled) to verify that the 456 "new" user is the same as the already-enrolled one. 458 5. Using HOBA-js 460 [[ A description of how to use the same HOBA semantics, but doing 461 everything in Javascript in a web page. This is more of a 462 demonstration that you could get the similar semantics via JS rather 463 than a normative section.]] 465 Web sites using javascript can also perform origin-bound 466 authentication without needing to involve the http layer, and by 467 inference not needing HOBA-specific support in browsers. One element 468 is required: localStorage (see http://www.w3.org/TR/webstorage/), and 469 one when it is available will be highly desirable: WebCrypto (see 470 http://www.w3.org/TR/WebCryptoAPI). In lieu of WebCrypto, javascript 471 crypto libraries can be employed with the known deficiencies of PRNG, 472 and the general immaturity of those libraries. The following section 473 outlines a mechanism for Javascript HOBA clients to initially enroll, 474 subsequent enrollment on new clients, login, and how HOBA-js relates 475 to web based session management. As with HOBA-http, a pure 476 Javascript implementation retains the property that only CPKs are 477 stored on the server, so that server compromise doesn't suffer the 478 multiplier affect that the various recent password exposure debacles 479 have vividly demonstrated. 481 5.1. Key Storage 483 We use HTML 5's localStorage feature for key storage. Conceptually 484 an implementation stores the dictionary account identifier, public 485 key, private key tuples in the origin's localStorage for subsequent 486 authentication requests. How this is actually stored in localStorage 487 is an implementation detail. We rely on the security properties of 488 the same-origin policy that localStorage enforces. See the security 489 considerations for discussion about attacks on localStorage. 491 5.2. User Join 493 To join a web site, the HOBA-js client generates a public/private key 494 pair and takes as input the account identifier to which the key pair 495 should be bound. The key pair and account identifier are stored in 496 localStorage for later use. The UA then signs the join information 497 (see below) using the private key, and forms a message with the 498 public key (CPK) and the signed data. The server receives the 499 message and verifies the signed data using the supplied key. The 500 server creates the account and adds the public key to a list of 501 public keys associated with this account. 503 5.3. User Login 505 Each time the user needs to log in to the server, it creates a login 506 message (see below) and signs the message using the relevant private 507 key stored in localStorage. The signed login message along with the 508 associated CPK identifier is sent to the server. The server receives 509 the message and verifies the signed data. If the supplied public key 510 is amongst the set of valid public keys for the supplied account, 511 then the login proceeds. See below for a discussion about replay. 513 5.4. Enrolling a New User Agent 515 When a user wants to start using a different UA, the website has two 516 choices: use a currently enrolled UA to permit the enrollment or use 517 a trusted out of band mechanism (eg email, sms, etc). To enroll a 518 new UA using an existing UA, the web site can display a one-time 519 password on the currently enrolled UA. This password is a one-time 520 password and expires in a fixed amount of time (say, 30 minutes). It 521 doesn't need to be an overly fussy password since it's one-time and 522 times out quickly. The user then inputs the one-time password and 523 the new UA generates a new asymmetric key pair and includes the one- 524 time password in the login message to the server (see below). 526 Alternatively if an enrolled UA is not available, and the site has an 527 out of band communication mechanism (eg, sms, email, etc) a user can 528 request that a one-time password be sent to the user. The server 529 generates and stores the one-time password as above. The user 530 receives the one-time password, inputs as above on the new UA, and 531 the HOBA-js client forms the login message as above. 533 In both cases, when the server receives a login message with a one- 534 time password, it checks to see if the password supplied is in a list 535 of unexpired one-time passwords associated with that account. If the 536 password matches, the server verifies the signature, expires or 537 deletes the one-time password and adds the supplied public key to the 538 list of public keys associated with the user assuming the signature 539 verified correctly. Subsequent logins proceed as above in User 540 Login. 542 5.5. Replay Protection 544 To guard against replay of a legitimate login/join message, we use 545 Kerberos-like timestamps in the expectation of synchronization 546 between the browser's and server's clocks is sufficiently reliable. 547 This saves an HTTP round trip which is desirable, though a challenge- 548 response mechanism as in HOBA-http could also be used. The client 549 puts the current system time into the URL, and the server side vets 550 it against its system time. Like Kerberos, a replay cache covering a 551 signature timeout window is required on the server. This can be done 552 using a database table that is keyed (in the database sense of the 553 term) using the signature bits. If the signature is in the replay 554 table, it ought be rejected. If the timestamp in the signature is 555 outside the current replay cache window then it also gets rejected. 557 [[ An addition of the ability for the server to reject a client with 558 potential time skew and give it a nonce (as with HOBA-http) would 559 allow the size of the replay cache to be set to just a few minutes 560 rather than a much longer period. Or the HOBA server could always 561 use a nonce method. This is worthy of more discussion. ]]. 563 5.6. Signature Parameters 565 Since we only require agreement between the server and the client 566 where the client is under the control of the server, the actual url 567 parameter names here are only advisory. For each signed url, the 568 client forms a url with the necessary login/join information. For 569 example, suppose example.com has login and join scripts with various 570 parameters: 572 o http://example.com/site/login.php?username=Mike 573 o http://example.com/site/ 574 join.php?username=Mike&email=mike@example.com&sms=555.1212 576 The client then appends a signature parameter block to the url: 578 o curtime: the time in milliseconds since unix epoch (ie, new Date 579 ().getTime ()). 581 o pubkey: the url encoded public key. See DKIM for the format of 582 the base64 encoded PEM formated key. 584 o temppass: an optional url encoded one-time password for subsequent 585 enrollment. 587 o keyalg: currently RSA. 2048 bit keys should be use if WebCrypto is 588 available 590 o digestalg: currently SHA1. SHA256 should be used if WebCrypto is 591 available. 593 o signature: empty for signing canonicalization purposes 595 [[ Signing the full url is problematic with PHP; we should take a 596 clue from what OAUTH does here; we almost certainly need to add some 597 host identifying information...]] To create the signature, the 598 canonical text includes the path portion, the site-specific url 599 parameters and appends a signature block onto the end of the url. 600 The signature block consists of the parameters listed above with an 601 empty signature parameter (ie, signature=), eg: 603 o Login: /site/ 604 login.php?username=Mike&curtime=1234567890.1234&keyalg=RSA& 605 digestalg=SHA1&signature= 607 o Join: /site/ 608 join.php?username=Mike&email=mike@ 609 example.com&curtime=1234567890.1234&keyalg=RSA&digestalg=SHA1& 610 signature= 612 o Login New User Agent: /site/ 613 login.php?username=Mike&curtime=1234567890.1234&temppass=1239678& 614 keyalg=RSA&digestalg=SHA1&signature= 616 The canonical signature text is then signed with the private key 617 associated with the account. The signature is then base64 encoded 618 and appended to the full url, and sent to the server using 619 XMLHttpRequest as usual. On receipt of the login request, the server 620 first extracts the timestamp (curtime) and determines whether the 621 timestamp is fresh (see above) rejecting the request if stale. The 622 server then removes the scheme and domain:port portion of the 623 incoming url, and removes the signature value only to create the 624 canonical signature text. The server then extracts the public key 625 along with the account and verifies the signature. If the signature 626 verifies, the server then determines whether this is an enrolled 627 public key for the user. If it is, login/join succeeds. If the key 628 is not enrolled, the server then checks to see if a one-time password 629 was supplied. If not, login/join fails. If a one-time password was 630 supplied, the server checks to see if a one-time password is valid 631 and fails if not. If valid, the server disables the one-time 632 password (eg, deletes it from its database) and adds the new public 633 key to the list of enrolled public keys for this user. 635 Once verified, the server may start up normal cookie-based session 636 management (see below). The server should send back status to the 637 HOBA-js client to determine whether the login/join was successful. 638 The details are left as an implementation detail. 640 Note: the client SHOULD use an HTTP POST for the XMLHttpRequest as 641 both the public key and signature blocks may exhaust the maximum size 642 for a GET request (typically around 2KB). 644 5.7. Session Management 646 Session Management is identical to username/password session 647 management. That is, the session management tool (such as PHP, 648 Python CGI, and so on) inserts a session cookie into the output to 649 the browser, and logging out simply removes the session cookie. 650 HOBA-js does nothing to help or hurt session cookie hijacking -- TLS 651 is still our friend. 653 5.8. Multiple Accounts on One User Agent 655 A shared UA with multiple accounts is possible if the account 656 identifier is stored along with the asymmetric key pair binding them 657 to one another. Multiple entries can be kept, one for each account, 658 and selected by the current user. This, of course, is fraught with 659 the possibility for abuse, since you're enrolling the device 660 potentially long-term. A couple of things can possibly be done to 661 combat that. First, the user can request that the credential be 662 erased from keystore. Similarly, in the enrollment phase, a user 663 could request that the key pair only be kept for a certain amount of 664 time, or that it not be stored at all. Last, it's probably best to 665 just not use shared devices at all since that's never especially 666 safe. 668 5.9. Oddities 670 With the same-origin policy, subdomains do not have access to the 671 same localStorage as parent domains do. For larger/more complex 672 sites this could be an issue that requires enrollment into subdomains 673 with the requisite hassle for users. One way to get around this is 674 to use session cookies as they can be used across subdomains. That 675 is, login using a single well-known domain, and then use session 676 cookies to navigate around a site. 678 6. Additional Services 680 HOBA uses a well-known URL [RFC5785] "hoba" as a base URI for 681 performing many tasks: "https://www.example.com/.well-known/hoba". 682 These URLs are based on the name of the host that the HTTP client is 683 accessing. There are many use cases for these URLs to redirect to 684 other URLs: a site that does registration through a federated site, a 685 site that only does registration under HTTPS, and so on. Like any 686 HTTP client, HOBA clients MUST be able to handle redirection of these 687 URLs. [[There are a bunch of security issues to consider related to 688 cases where a re-direct brings you off-origin.]] 690 All additional services MUST be done in TLS-protected sessions 691 ([RFC5246]). 693 6.1. Registration 695 Normally, a registration is expected to happen after a UA receives a 696 WWW-Authenticate for a web-origin and realm for which it has no 697 associated CPK. The (protocol part of the) process of registration 698 for a HOBA account on a server is relatively light-weight. The UA 699 generates a new key pair, and associates it with the web-origin/realm 700 in question. The UA sets up a TLS-protected session, goes to the 701 registration URL ".well-known/hoba/register", and submits the CPK 702 using a POST message as described below. It is up to the server to 703 decide what kind of user interaction is required before the account 704 is finally set up. 706 If the UA has a CPK associated with the web-origin, but not for the 707 realm concerned, then a new registration is REQUIRED. If the server 708 did not wish for that outcome, then it ought not use a different 709 realm. 711 The POST message sent to the registration URL contains an HTML form 712 (x-www-form-encoded) with one mandatory field (pub) and some optional 713 fields that allow the UA to specify the type and value of key and 714 device identifiers that the UA wishes to use. [[The device stuff is 715 just a thought.]] 717 o pub: is a mandatory field containing the PEM formatted public key 718 of the client. See Appendix C of [RFC6376] for an example of how 719 to generate this key format. 721 o kidtype: contains the type of key identifier, this is a numeric 722 value intended to contain one of the values from Section 9.4. If 723 this is not present then the mandatory to implement "DANE-hash" 724 option MUST be used. 726 o kid: contains the key identifier as a base64url encoded string 727 that is of the type indicated in the kidtype. If the kid is a 728 hash of a public key then the correct (base64url encoded) hash 729 value MUST be provided and the server SHOULD check that and refuse 730 the registration if an incorrect value was supplied. 732 o didtype: specifies a kind of device identifier intended to contain 733 one of the values from Section 9.5, if absent then the "string" 734 form of device identifier MUST be used. 736 o did: A UTF8 string that specifies the device identifier. This can 737 be used to help a user be confident that authentication has 738 worked, e.g., following authentication some web content might say 739 "You last logged in from device 'did' at time T." 741 6.2. Associating Additional Keys to an Exiting Account 743 It is common for a user to have multiple UAs, and to want all those 744 UAs to be able to authenticate to a single account. One method to 745 allow a user who has an existing account to be able to authenticate 746 on a second device is to securely transport the private and public 747 keys and the origin information from the first device to the second. 748 Previous history with such key transport has been spotty at best. As 749 an alternative, HOBA allows associating a CPK from the second device 750 to the account created on the first device. 752 Instead of registering on the new device, the UA generates a new key 753 pair, associates it with the web-origin/realm in question, goes to 754 the URL for starting an association, ".well-known/hoba/ 755 associate-start" in a TLS-protected session, and submits the new CPK 756 using a POST message. [[ More description is clearly needed here. ]] 757 The server's response to this request is a nonce with at least 128 758 bits of entropy. That nonce SHOULD be easy for the user to copy and 759 type, such as using Base32 encoding (see [RFC4648]). The user then 760 uses the first UA to log into the origin, goes to the URL for 761 finishing an association, ".well-known/hoba/associate-finish", and 762 submits the nonce using a POST message. [[ More description is 763 clearly needed here. ]]. The server then knows that the 764 authenticated user is associated with the second CPK. The server can 765 choose to associate the two CPKs with one account. Whether to do so 766 is entirely at the server's discretion however, but the server SHOULD 767 make the outcome clear to the user. 769 6.3. Logging Out 771 When the user wishes to logout, the UA simply goes to ".well-known/ 772 hoba/logout". The UA MAY also delete session cookies associated with 773 the session. [[Is that right?, maybe a SHOULD- or MUST-delete would 774 be better]] 776 The server-side MUST NOT allow TLS session resumption for any logged 777 out session and SHOULD also revoke or delete any cookies associated 778 with the session. 780 6.4. Getting a Fresh Challenge 782 If the UA would like a "fresh" challenge then it can send a POST or 783 GET message to ".well-known/hoba/getchal". A successful (200 status) 784 response MUST include a fresh (base64url encoded) HOBA challenge for 785 this origin in the body of the response. 787 7. Mandatory-to-Implement Algorithms 789 RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus 790 lengths of at least 2048 bits SHOULD be used. 792 [[Maybe we should add ECDSA with P256 for shorter signatures.]] 794 8. Security Considerations 796 If key binding was server-selected then a bad actor could bind 797 different accounts belonging to the user from the network with 798 possible bad consequences, especially if one of the private keys was 799 compromised somehow. 801 Binding my CPK with someone else's account would be fun and 802 profitable so SHOULD be appropriately hard. In particular the string 803 generated by the server MUST be hard to guess, for whatever level of 804 difficulty is chosen by the server. The server SHOULD NOT allow a 805 random guess to reveal whether or not an account exists. 807 [[The potential impact on privacy of HOBA needs to be addressed. If 808 a site can use a 401 and a CPK to track users without permission that 809 would be not-so-nice so some guidance on how a UA could indicate to a 810 user that HOBA stuff is going on might be needed.]] 812 [[lots more TBD, be nice to your private keys etc. etc.]] 814 8.1. localStorage Security for Javascript 816 Our use of localStorage will undoubtedly be a cause for concern. 817 localStorage uses the same-origin model which says that the scheme, 818 domain and port define a localStorage instance. Beyond that, any 819 code executing will have access to private keying material. Of 820 particular concern are XSS attacks which could conceivably take the 821 keying material and use it to create UAs under the control of an 822 attacker. But XSS attacks are in reality across the board 823 devastating since they can and do steal credit card information, 824 passwords, perform illicit acts, etc, etc. It's not clear that we 825 introduce unique threats from which clear text passwords don't 826 already suffer. 828 Another source of concern is local access to the keys. That is, if 829 an attacker has access to the UA itself, they could snoop on the key 830 through a javascript console, or find the file(s) that implement 831 localStorage on the host computer. Again it's not clear that we are 832 worse in this regard because the same attacker could get at browser 833 password files, etc too. One possible mitigation is to encrypt the 834 keystore with a password/pin the user supplies. This may sound 835 counter intuitive, but the object here is to keep passwords off of 836 servers to mitigate the multiplier effect of a large scale compromise 837 ala LinkedIn because of shared passwords across sites. 839 It's worth noting that HOBA uses asymmetric keys and not passwords 840 when evaluating threats. As various password database leaks have 841 shown, the real threat of a password breach is not just to the site 842 that was breached, it's all of the sites a user used the same 843 password on too. That is, the collateral damage is severe because 844 password reuse is common. Storing a password in localStorage would 845 also have a similar multiplier effect for an attacker, though perhaps 846 on a smaller scale than a server-side compromise: one successful 847 crack gains the attacker potential access to hundreds if not 848 thousands of sites the user visits. HOBA does not suffer from that 849 attack multiplier since each asymmetric key pair is unique per site/ 850 UA/user. 852 9. IANA Considerations 853 9.1. HOBA Authentication Scheme 855 Authentication Scheme Name: HOBA 857 Pointer to specification text: [[ this document ]] 859 Notes (optional): The HOBA scheme can be used with either HTTP 860 servers or proxies. [[But we need to figure out the proxy angle;-)]] 862 9.2. .well-known URLs 864 We probably want a new registry for the labels beneath .well-known/ 865 hoba so that other folks can add additional features in a controlled 866 way, e.g. for CPK/account revocation or whatever. 868 9.3. Algorithm Names 870 TBD, hopefully re-use and existing registry 872 "0" means RSA-SHA256 874 "1" means RSA-SHA1 876 9.4. Key Identifier Types 878 "0" means a hashed public key, as done in DANE. [RFC6698] 880 "1" means a URI, such as a mailto: or acct: URI, but anything 881 conforming to [RFC3986] is ok.i 883 "2" means an unformatted string, at the user's/UA's whim 885 9.5. Device Identifier Types 887 "0" means an unformatted nickname, at the user's/UA's whim 889 10. Implementation Status 891 [[Note to RFC editor - please delete this section before 892 publication.]] 894 This section records the status of known implementations of the 895 protocol defined by this specification at the time of posting of this 896 Internet-Draft, and is based on a proposal described in 897 [I-D.sheffer-running-code]. The description of implementations in 898 this section is intended to assist the IETF in its decision processes 899 in progressing drafts to RFCs. Please note that the listing of any 900 individual implementation here does not imply endorsement by the 901 IETF. Furthermore, no effort has been spent to verify the 902 information presented here that was supplied by IETF contributors. 903 This is not intended as, and must not be construed to be, a catalog 904 of available implementations or their features. Readers are advised 905 to note that other implementations may exist. 907 According to [RFC Editor: replace by a reference to this document], 908 "this will allow reviewers and working groups to assign due 909 consideration to documents that have the benefit of running code, by 910 considering the running code as evidence of valuable experimentation 911 and feedback that has made the implemented protocols more mature. It 912 is up to the individual working groups to use this information as 913 they see fit". 915 At the time of writing there are two known implementations. One done 916 by Stephen Farrell of HOBA-HTTP and a HOBA-JS variant and another by 917 Michael Thomas of an HOBA-JS variant. More details will be provided 918 in future drafts as those implementations mature and e.g. open-source 919 licensing terms and release schedules are figured out. 921 11. Acknowledgements 923 Thanks to the following for good comments received during the 924 preparation of this specification: Julian Reschke [[and many more to 925 be added]. All errors and stupidities are of course the editors' 926 fault. 928 12. References 930 12.1. Normative References 932 [I-D.ietf-httpbis-p7-auth] 933 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 934 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-23 935 (work in progress), July 2013. 937 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 938 Requirement Levels", BCP 14, RFC 2119, March 1997. 940 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 941 Resource Identifier (URI): Generic Syntax", STD 66, 942 RFC 3986, January 2005. 944 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 945 Specifications: ABNF", STD 68, RFC 5234, January 2008. 947 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 948 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 950 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 951 Uniform Resource Identifiers (URIs)", RFC 5785, 952 April 2010. 954 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 955 December 2011. 957 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 958 of Named Entities (DANE) Transport Layer Security (TLS) 959 Protocol: TLSA", RFC 6698, August 2012. 961 12.2. Informative References 963 [I-D.sheffer-running-code] 964 Sheffer, Y. and A. Farrel, "Improving Awareness of Running 965 Code: the Implementation Status Section", 966 draft-sheffer-running-code-06 (work in progress), 967 June 2013. 969 [MI93] Mitchell and Thomas, "Standardising Authentication 970 Protocols Based on Public-Key Techniques.", Journal of 971 Computer Security 2 (1993): 23-36. , 1993. 973 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 974 Leach, P., Luotonen, A., and L. Stewart, "HTTP 975 Authentication: Basic and Digest Access Authentication", 976 RFC 2617, June 1999. 978 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 979 Encodings", RFC 4648, October 2006. 981 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 982 Housley, R., and W. Polk, "Internet X.509 Public Key 983 Infrastructure Certificate and Certificate Revocation List 984 (CRL) Profile", RFC 5280, May 2008. 986 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 987 April 2011. 989 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 990 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 991 July 2013. 993 Appendix A. Problems with Passwords 995 By far the most common mechanism for web authentication is passwords 996 that can be remembered by the user, called "memorizable passwords". 997 There is plenty of good research on how users typically use 998 memorizable passwords ([[ handful of citations goes here ]]), but 999 some of the highlights are that users typically try hard to reuse 1000 passwords on as many web sites as possible, and that web sites often 1001 use either email addresses or users' names as the identifier that 1002 goes with these passwords. 1004 If an attacker gets access to the database of memorizable passwords, 1005 that attacker can impersonate any of the users. Even if the breach 1006 is discovered, the attacker can still impersonate users until every 1007 password is changed. Even if all the passwords are changed or at 1008 least made unusable, the attacker now possesses a list of likely 1009 username/password pairs that might exist on other sites. 1011 Using memorizable passwords on unencrypted channels also poses risks 1012 to the users. If a web site uses either the HTTP Plain 1013 authentication method, or an HTML form that does no cryptographic 1014 protection of the password in transit, a passive attacker can see the 1015 password and immediately impersonate the user. If a hash-based 1016 authentication scheme such as HTTP Digest authentication is used, a 1017 passive attacker still has a high chance of being able to determine 1018 the password using a dictionary of known passwords. 1020 [[ Say a bit about non-memorizable passwords. Still subject to 1021 database attack, although that doesn't give the attacker knowledge 1022 for other systems. Safe if digest authentication is used, but that's 1023 rare. ]] 1025 Appendix B. Examples 1027 [[Will add more later and probably use example.org.]] 1029 The following values show an example of HOBA-HTTP authentication to 1030 the origin https://hoba-local.ie. Carriage-returns have been added 1031 and need to be removed to validate the example. 1033 -----BEGIN PRIVATE KEY----- 1034 MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDNF6tZUbsM7ZrO 1035 5Lyzvn15lJAfOz7j7xdc3hmeSOfh/DCiJWwE5qqffrOvOvXYN+qUTlsXPeBYdrz/ 1036 my0YYC02u2QFhDbFRvpM/EuMzZUWTQzkKyU7nSjtPqlLZJJ/Rh6PnjTgImoIMn92 1037 JZgJZgl/vzd29K5Z94JzdJ4Z5bNmQ/gCpjlv0Wvi+GpJ3lDo1csDEyxATxyTUx1J 1038 K73+/RPoNgUF9nrXN6kqeH7RkERRz+PFhfGM6r3tU5povJxOP0bzVl6R4kptWLn2 1039 GqDb5LS9iwzsk6YHWQcLOIAMVZ9ITPN2PSuQX0ym81B9qB1V6fTfo2r0Yo1Djn6C 1040 YRX62p4dAgMBAAECggEBAJiyWLcFrPhxJ2OG1iAVYaJVxAAcwjQ+XOydyAEbUtnk 1041 Q+lVZ1k2zC43zVxXz5aN+y80L4ncXd4/eXPteuO9J6yqVEvvJkA3GkCbTzykC64w 1042 67otjWkXF9ObZbxmQtRTxokzRzbhKIS15ER4tPu6ZrQgEBGXFwCQ0SVY3CV36dvm 1043 xU2Y90wf98BGQF5VO47S9h8N/VtBn1ttI/6BhQHGsM+TbRR0b6oT9Mp/kqh5jZ2P 1044 dH/l7Q6aj6zeFYljvI6HUpjc0mVOSKPAO0qYLZNYC0sqXxW9vCtEODziFZwrO2tL 1045 jm14/H8+AZvtR6ZvbzP8h3G95PNdG4Z1eGZv5pOoJoECgYEA8omsyssjVgLIon60 1046 Q6h3EjOi8I+mfvXYXcAZhv/1MnojFZgMLmuZ13Lgi3dIHYFNYGFRi8g9iYU/Ljtf 1047 G3B9o6PQsvL0yym85TZzF/yn+kbinHR2yQUiA1Ck1rnrFx8dla/BjAplPxumyh/z 1048 HyNFplVbOeRQS4K5F72wScuB9DECgYEA2Hnq1OSLetl4lrGAEHDoiIKw++ACQ/Tn 1049 w5O+xAxOXr9iOmczwpHls+zFSQHty4za8C/tBLxg6HCHKZSO4lh+p5SR21UNgwfr 1050 X6xBZ4xoH9zHTFdD2yrHdxAoItdT5oMTAUNHxDS8kcSY1+YcjRs2T4kcONIxeBlp 1051 O++dxK9I6a0CgYEAp52WGSCCbzLFTeea1RdcEuw0s2PTgPKOcVwNSEskPZpDHO1T 1052 ndEnJMpzfG8XG6z8uJsJLD1aqeu4Wk8Vz3TSn4Da/pEBtFZIAXC74dvuivzqJ44l 1053 eY9ejkPxZ6RdYEFUxNoOPKYCiralchLahq5tuCJNRZkQFN9m441og9dtHEECgYEA 1054 qnvRqlpXUqfEZYFi5w/UwfWTJrozbouInylTOpiqe8njtTUjuV8ndPzKHoYrXXwP 1055 zMshsfIdq9E7UU7S/IVPMfE6sW6ZVpE9GDrTw5X7RuSb/I5ZPVjCgA00XsQQKmEd 1056 7YesFGSoAXDAIn/yClrc+eR0WneHSBtTGkXKjWSyWn0CgYAlHdG3wj/sOL+JI7p8 1057 fgSoRpkrbjfrczqSCDVFbT84sUz3dXObZecrI3v0XUZySakIDha5ZbxXNST/bfea 1058 kReKsoeFY9J7os0hbfGwxiCQwD3wN9tS2yJbJYl1mCFc45YfylkXBzB0S2V/i6rv 1059 vCWW1nijRb+WhpUF8HyKW64bxA== 1060 -----END PRIVATE KEY----- 1062 Key Identifier: Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vqWw 1064 Challenge: zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0= 1066 Nonce: xXSFdZ-7ahM 1068 Tbsorigin: httpshoba-local.ie443 1070 The resulting signature is: 1072 r1ZXAWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfo 1073 K__W_Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hK 1074 t4bCtP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19J 1075 LTUyaisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7 1076 qf6lORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq 1077 8meaqRXMhoQWHGLweFTNYw 1079 The final HTTP header field sent with a request is then: 1081 Authorization: result="Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vq 1082 Ww.zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0=.xXSFdZ-7ahM.r1ZX 1083 AWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfoK__W 1084 _Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hKt4bC 1085 tP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19JLTUy 1086 aisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7qf6l 1087 ORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq8mea 1088 qRXMhoQWHGLweFTNYw" 1090 Appendix C. Changes 1092 [[Note to RFC editor - please delete this section before 1093 publication.]] 1095 C.1. WG-01 1097 o A few clarifications/fixes. 1099 o Added getchal interface and expires attribute 1101 o Added Implementation Status section 1103 o Added examples 1105 C.2. WG-00 1107 o First WG draft, replacing draft-farrell-httpbis-hoba-02 1109 o Fleshed out HTTP scheme some more. 1111 o Fleshed out registration form more. 1113 Authors' Addresses 1115 Stephen Farrell 1116 Trinity College Dublin 1117 Dublin, 2 1118 Ireland 1120 Phone: +353-1-896-2354 1121 Email: stephen.farrell@cs.tcd.ie 1122 Paul Hoffman 1123 VPN Consortium 1125 Email: paul.hoffman@vpnc.org 1127 Michael Thomas 1128 Phresheez 1130 Email: mike@phresheez.com