Hobareg-val = "regok" / "reginwork"
        

Figure 3: Hobareg Header Field Definition

Figure 3 provides an ABNF definition for the values allowed in the Hobareg header field. Note that these (and the header field name) are case insensitive. Section 8.3.1 of [RFC7231] calls for documenting the following details for this new header field:

• Only one single value is allowed in a Hobareg header field. Should more than one (a list) be encountered or any other ANBF-invalid value, that SHOULD be interpreted as being the same as "reginwork."
• The Hobareg header field can only be used in HTTP responses.
• Since Hobareg is only meant for responses it ought not appear in requests.
• The HTTP response code does affect the interpretation of Hobareg. Registration is only considered to have succeeded if the regok value is seen in a 2xx response. 4xx and other errors means that registration has failed regardless of the value of Hobareg seen. The request method has no influence on the interpretation of Hobareg.
• Intermediaries never insert, delete or modify a Hobareg header field.
• As a response-only header field, it is not appropriate to list a Hobareg in a Vary response header field.
• Hobareg is allowed in trailers.
• As a response-only header field, Hobareg will not be preserved across re-directs.
• Hobareg itself discloses little security or privacy sensitive information. If an attacker can somehow detect that a Hobareg header field is being added, then that attacker would know that the UA is in the process of registration which could be significant. However, it is likely that the set of messages between the UA and server would expose this information in many cases, regardless of whether or not TLS is used. Using TLS is still however a good plan.

6.2. Associating Additional Keys to an Existing Account

From the user perspective, the UA having a CPK for a web origin will often appear to be the same as having a way to sign in to an account at that web site. Since users often have more than one UA, and since the CPKs are, in general, UA-specific, that raises the question of how the user can sign in to that account from different UAs. And from the server perspective that turns into the question of how to safely bind different CPKs to one account. In this section, we describe some ways in which this can be done, as well as one way in which this ought not be done.

Note that the context here is usually that the user has succeeded in registering with one or more UAs (for the purposes of this section we call this "the first UA" below) and can use HOBA with those, and the user is now adding another UA. The newest UA might or might not have a CPK for the site in question. Since it is in fact trivial, we assume that the site is able to put in place some appropriate quicker, easier registration for a CPK for the newest UA. The issue then becomes one of binding the CPK from the newest UA with those of other UAs bound to the account.

6.2.1. Moving private keys

It is common for a user to have multiple UAs, and to want all those UAs to be able to authenticate to a single account. One method to allow a user who has an existing account to be able to authenticate on a second device is to securely transport the private and public keys and the origin information from the first device to the second. If this approach is taken, then there is no impact on the HOBA-http or HOBA-js so this is a pure UA implementation issue and not discussed further.

6.2.2. Human memorable one time password (don't do this one)

It will be tempting for implementers to use a human-memorable one-time password (OTP) in order to "authenticate" binding CPKs to the same account. The workflow here would likely be something along the lines of some server administrative utility generating a human memorable OTP such as "1234" and sending that to the user out of band for the user to enter at two web pages each authenticated via the relevant CPK. While this seems obvious enough and could even be secure enough in some limited cases, we consider that this is too risky to use in the Internet and so servers SHOULD NOT provide such a mechanism. The reason this is so dangerous is that it would be trivial for an automated client to guess such tokens and "steal" the binding intended for some other user. At any scale, there would always be some in-process bindings so that even with only a trickle of guesses (and hence not being detectable via message volume) an attacker would have a high probability of succeeding in registering a binding with the attacker's CPK.

This method of binding CPKs together is therefore NOT RECOMMENDED.

6.2.3. Out of band URL

One easy binding method is to simply provide a web page where, using the first UA, the user can generate a URL (containing some "unguessable" cryptographically generated value) that the user then later de-references on the newest UA. The user could e-mail that URL to herself for example, of the web server accessed at the first UA could automatically do that.

Such a URL SHOULD contain at least the equivalent of 128 bits of randomness.

6.3. Logging Out

The user can tell the server it wishes to log out. With HOBA-http, this is done by sending a HOBA-authenticated POST message to the URL ".well-known/hoba/logout" on the site in question. The UA SHOULD also delete session cookies associated with the session so that the user's state is no longer "logged in."

The server MUST NOT allow TLS session resumption for any logged out session.

The server SHOULD also revoke or delete any cookies associated with the session.

6.4. Getting a Fresh Challenge

The UA can get a "fresh" challenge from the server. In HOBA-http, it sends a POST message to ".well-known/hoba/getchal". If successful, the response response MUST contain a fresh (base64url encoded) HOBA challenge for this origin in the body of the response. Whitespace in the response MUST be ignored.

7. Mandatory-to-Implement Algorithms

RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus lengths of at least 2048 bits SHOULD be used. RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].

8. Security Considerations

If key binding was server-selected then a bad actor could bind different accounts belonging to the user from the network with possible bad consequences, especially if one of the private keys was compromised somehow.

Binding my CPK with someone else's account would be fun and profitable so SHOULD be appropriately hard. In particular URLs or other values generated by the server as part of any CPK binding process MUST be hard to guess, for whatever level of difficulty is chosen by the server. The server SHOULD NOT allow a random guess to reveal whether or not an account exists.

When the max-age parameter is not zero, then a HOBA signature has a property that is like a bearer token for the relevant number of seconds: it can be replayed for a server-selected duration. Similarly, for HOBA-js, signatures might be replayable depending on the specific implementation. The security considerations of [RFC6750] therefore apply in any case where the HOBA signature can be replayed. Server administrators can set the max-age to the minimum acceptable value in such cases, which would often be expected to be just a few seconds. There seems to be no reason to ever set the max-age more than a few minutes; the value ought also decrease over time as device capabilities improve. The administrator will most likely want to set the max-age to something that is not too slow on the slowest signing device that is significant for that site.

8.1. Privacy considerations

HOBA does impact to some extent on privacy and could be considered to represent a super-cookie to the server, or to any entity on the path from UA to HTTP server that can see the HOBA signature. This is because we need to send a key identifier as part of the signature and that will not vary for a given key. For this reason, and others, it is strongly RECOMMENDED to only use HOBA over server-authenticated TLS and to migrate web sites using HOBA to only use "https" URLs.

UAs SHOULD provide users a way to manage their CPKs. Ideally, there would be a way for a user to maintain their HOBA details for a site while at the same time deleting other site information such as cookies or non-HOBA HTML5 LocalStorage. However, as this is likely to be complex and appropriate user interfaces counter intutitive, we expect that UAs that implement HOBA will likely treat HOBA information as just some more site data, that would disappear should the user choose to "forget" that site.

8.2. localStorage Security for Javascript

The use of localStorage (likely with a non-WebCrypto implementation of HOBA-js) will undoubtedly be a cause for concern. localStorage uses the same-origin model which says that the scheme, domain and port define a localStorage instance. Beyond that, any code executing will have access to private keying material. Of particular concern are XSS attacks which could conceivably take the keying material and use it to create UAs under the control of an attacker. But XSS attacks are in reality across the board devastating since they can and do steal credit card information, passwords, perform illicit acts, etc, etc. It's not clear that we introduce unique threats from which clear text passwords don't already suffer.

Another source of concern is local access to the keys. That is, if an attacker has access to the UA itself, they could snoop on the key through a javascript console, or find the file(s) that implement localStorage on the host computer. Again it's not clear that we are worse in this regard because the same attacker could get at browser password files, etc too. One possible mitigation is to encrypt the keystore with a password/pin the user supplies. This may sound counter intuitive, but the object here is to keep passwords off of servers to mitigate the multiplier effect of a large scale compromise ala LinkedIn because of shared passwords across sites.

It's worth noting that HOBA uses asymmetric keys and not passwords when evaluating threats. As various password database leaks have shown, the real threat of a password breach is not just to the site that was breached, it's all of the sites a user used the same password on too. That is, the collateral damage is severe because password reuse is common. Storing a password in localStorage would also have a similar multiplier effect for an attacker, though perhaps on a smaller scale than a server-side compromise: one successful crack gains the attacker potential access to hundreds if not thousands of sites the user visits. HOBA does not suffer from that attack multiplier since each asymmetric key pair is unique per site/UA/user.

8.3. Multiple Accounts on One User Agent

A shared UA with multiple accounts is possible if the account identifier is stored along with the asymmetric key pair binding them to one another. Multiple entries can be kept, one for each account, and selected by the current user. This, of course, is fraught with the possibility for abuse, since a server is potentially enrolling the device for a long period and the user may not want to have to be responsible for the credential for that long. To alleviate this problem, the user can request that the credential be erased from the browser. Similarly, during the enrollment phase, a user could request that the key pair only be kept for a certain amount of time, or that it not be stored beyond the current browser session.

8.4. Injective Mapping for HOBA-TBS

The repeated length fields in the HOBA-TBS structure are present in order to ensure that there is no possibility that the catenation of different input values can cause confusion that might lead to an attack, either against HOBA as specified here, or else an attack against some other protocol that re-used this to-be-signed structure. Those fields ensure that the mapping from input fields to the HOBA-TBS string is an injective mapping.

9. IANA Considerations

IANA is requested to make registrations and create new registries as described below.

For all new registries requested by this document, please place those beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters" category.

9.1. HOBA Authentication Scheme

Please register a new scheme in the HTTP Authentication Scheme Registry registry as follows:

Authentication Scheme Name: HOBA

Pointer to specification text: Section 3 of [[ this document ]]

Notes (optional): The HOBA scheme can be used with either HTTP servers or proxies. When used in response to a 407 Proxy Authentication Required indication, the appropriate proxy authentication header fields are used instead, as with any other HTTP authentication scheme.

9.2. .well-known URI

Please register a new .well-known URI in the Well-Known URIs registry as described below.

URI suffix: hoba

Change controller: IETF

Specification document(s): Section 6 of [[ this document ]]

Related information: N/A

9.3. Algorithm Names

Please create a new HOBA signature algorithms registry as follows, with the specification required rule for updates. New HOBA signature algorithms SHOULD be in use with other IETF standards track protocols before being added to this registry.

            
Number       Meaning                                       
-----------  --------------------------------------------  
0            RSA-SHA256 
1            RSA-SHA1
          

RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].

For this registry the number column should contain a small positive integer. Following the ABNF above, the maximum value for this is decimal 99.

9.4. Key Identifier Types

Please create a new HOBA Key Identifier Types registry as follows, with the specification required rule for updates.

            
Number       Meaning                                       
-----------  --------------------------------------------  
0            a hashed public key [RFC6698]
1            a URI [RFC3986]
2            an unformatted string, at the user's/UA's whim
          

For the number 0, hashed public keys are as done in DANE. [RFC6698]

For this registry the number column should contain a small positive integer.

9.5. Device Identifier Types

Please create a new HOBA Device Identifier Types registry as follows, with the specification required rule for updates.

            
Number       Meaning                                       
-----------  --------------------------------------------  
0            an unformatted string, at the user's/UA's whim
          

For this registry the number column should contain a small positive integer.

9.6. Hobareg HTTP Header Field

Please register a new identifier in the Permanent Message Header Field Names registry as described below.

Header field name: Hobareg

Applicable protocol: HTTP (RFC 7230)

Status: Experimental

Author/Change controller: IETF

Specification document(s): Section 6.1.1 of [[ this document ]]

Related information: N/A

10. Implementation Status

[[ Note to RFC editor - please delete this section before publication. ]]

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC6982] "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

At the time of writing there are three known implementations.

• One done by Stephen Farrell of HOBA-http and a HOBA-JS variant implements the current (-08) version of HOBA and is available from https://hoba.ie/ which site also includes a demonstration of HOBA.
• There is another implementation by Michael Thomas of an HOBA-JS variant.
• The most recent (Dec 2014) implementation is by Portugal Telecom and is available from https://github.com/razevedo/hoba-authentication

11. Acknowledgements

Thanks to the following for good comments received during the preparation of this specification: David Black, Amos Jeffries, Benjamin Kaduk, Watson Ladd, Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Melnikov, Yoav Nir, Mark Nottingham, Julian Reschke, Michael Richardson, Yaron Sheffer, and Michael Sweet. All errors and stupidities are of course the editors' fault.

12. References

12.1. Normative References

[RFC0020]	Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3447]	Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3986]	Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4648]	Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC5234]	Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246]	Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5785]	Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC6454]	Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6698]	Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6750]	Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC7231]	Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7235]	Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
[SHS]	NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST Special Publications , March 2012.

12.2. Informative References

[MI93]	Mitchell, and Thomas, "Standardising Authentication Protocols Based on Public-Key Techniques.", Journal of Computer Security 2 (1993): 23-36. , 1993.
[RFC6265]	Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6376]	Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6982]	Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, July 2013.
[bonneau]	Bonneau, , "The science of guessing: analyzing an anonymized corpus of 70 million passwords.", IEEE Symposium on Security and Privacy , 2012.

Appendix A. Problems with Passwords

By far the most common mechanism for web authentication is passwords that can be remembered by the user, called "human-memorable passwords". There is plenty of good research on how users typically use human-memorable passwords (e.g. see [bonneau]), but some of the highlights are that users typically try hard to reuse passwords on as many web sites as possible, and that web sites often use either email addresses or users' names as the identifier that goes with these passwords.

If an attacker gets access to the database of memorizable passwords, that attacker can impersonate any of the users. Even if the breach is discovered, the attacker can still impersonate users until every password is changed. Even if all the passwords are changed or at least made unusable, the attacker now possesses a list of likely username/password pairs that might exist on other sites.

Using memorizable passwords on unencrypted channels also poses risks to the users. If a web site uses either the HTTP Basic authentication method, or an HTML form that does no cryptographic protection of the password in transit, a passive attacker can see the password and immediately impersonate the user. If a hash-based authentication scheme such as HTTP Digest authentication is used, a passive attacker still has a high chance of being able to determine the password using a dictionary of known passwords.

Note that passwords that are not human-memorable are still subject to database attack, though are of course unlikely to be re-used across many systems. Similarly, database attacks of some form or other will work against any password based authentication scheme, regardless of the crytographic protocol used. So for example, zero-knowledge or PAKE schemes, though making use of elegant cryptographic protocols, remain as vulnerable to what is clearly the most common exploit seen when it comes to passwords. HOBA is however not vulnerable to database theft.

Appendix B. Example

The following values show an example of HOBA-http authentication to the origin https://example.com:443. Carriage-returns have been added and need to be removed to validate the example.

Public Key:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG
DQIDAQAB
-----END PUBLIC KEY-----

Origin: https://example.com:443

Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w

Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=

Nonce: Pm3yUW-sW5Q

Signature:

VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i
4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz
q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP
tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9
6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI
S13qQA43m4IMExkbApqrSg

Authorization Header:

Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-
k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q
.VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0
i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU
zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK
PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr
96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k
IS13qQA43m4IMExkbApqrSg"

Authors' Addresses