Network Working Group                                         S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Experimental                                 P. Hoffman
Expires: June 8, 2015                                     VPN Consortium
                                                               M. Thomas
                                                        December 5, 2014

                HTTP Origin-Bound Authentication (HOBA)


   HTTP Origin-Bound Authentication (HOBA) is a digital signature based
   design for an HTTP authentication method.  The design can also be
   used in Javascript-based authentication embedded in HTML.  HOBA is an
   alternative to HTTP authentication schemes that require passwords and
   therefore avoids all problems related to passwords, such as leakage
   of server-side password databases.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 8, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Farrell, et al.           Expires June 8, 2015                  [Page 1]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Interfacing to Applications (Cookies) . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The HOBA Authentication Scheme  . . . . . . . . . . . . . . .   5
   3.  Introduction to the HOBA-http Mechanism . . . . . . . . . . .   7
   4.  Introduction to the HOBA-js Mechanism . . . . . . . . . . . .   8
   5.  HOBA's Authentication Process . . . . . . . . . . . . . . . .   9
     5.1.  CPK Preparation Phase . . . . . . . . . . . . . . . . . .   9
     5.2.  Signing Phase . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Authentication Phase  . . . . . . . . . . . . . . . . . .   9
   6.  Other Parts of the HOBA Process . . . . . . . . . . . . . . .  10
     6.1.  Registration  . . . . . . . . . . . . . . . . . . . . . .  11
       6.1.1.  Hobareg Definition  . . . . . . . . . . . . . . . . .  12
     6.2.  Associating Additional Keys to an Exiting Account . . . .  14
       6.2.1.  Moving private keys . . . . . . . . . . . . . . . . .  14
       6.2.2.  Human memorable one time password (don't do this one)  14
       6.2.3.  Out of band URL . . . . . . . . . . . . . . . . . . .  15
     6.3.  Logging Out . . . . . . . . . . . . . . . . . . . . . . .  15
     6.4.  Getting a Fresh Challenge . . . . . . . . . . . . . . . .  15
   7.  Mandatory-to-Implement Algorithms . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     8.1.  Privacy considerations  . . . . . . . . . . . . . . . . .  16
     8.2.  localStorage Security for Javascript  . . . . . . . . . .  17
     8.3.  Multiple Accounts on One User Agent . . . . . . . . . . .  18
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     9.1.  HOBA Authentication Scheme  . . . . . . . . . . . . . . .  18
     9.2.  .well-known URI . . . . . . . . . . . . . . . . . . . . .  18
     9.3.  Algorithm Names . . . . . . . . . . . . . . . . . . . . .  19
     9.4.  Key Identifier Types  . . . . . . . . . . . . . . . . . .  19
     9.5.  Device Identifier Types . . . . . . . . . . . . . . . . .  19
     9.6.  Hobareg HTTP Header . . . . . . . . . . . . . . . . . . .  20
   10. Implementation Status . . . . . . . . . . . . . . . . . . . .  20
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     12.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Appendix A.  Problems with Passwords  . . . . . . . . . . . . . .  22
   Appendix B.  Example  . . . . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

Farrell, et al.           Expires June 8, 2015                  [Page 2]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

1.  Introduction

   HTTP Origin-Bound Authentication (HOBA) is an authentication design
   that can be used as an HTTP authentication scheme [RFC7235] and for
   Javascript-based authentication embedded in HTML.  The main goal of
   HOBA is to offer an easy-to-implement authentication scheme that is
   not based on passwords, but that can easily replace HTTP or HTML
   forms-based password authentication.  Deployment of HOBA can reduce
   or eliminate password entries in databases, with potentially
   significant security benefits.

   HOBA is an HTTP authentication mechanism that complies with the
   framework for such schemes [RFC7235].  As a JavaScript design, HOBA
   demonstrates a way for clients and servers to interact using the same
   credentials that are used by the HTTP authentication scheme.

   Current username/password authentication methods such as HTTP Basic,
   HTTP Digest, and web forms have been in use for many years but are
   susceptible to theft of server-side password databases.  Instead of
   passwords, HOBA uses digital signatures as an authentication
   mechanism.  HOBA also adds useful features such as credential
   management and session logout.  In HOBA, the client creates a new
   public-private key pair for each host ("web-origin" [RFC6454]) to
   which it authenticates.  These keys are used in HOBA for HTTP clients
   to authenticate themselves to servers in the HTTP protocol or in a
   Javascript authentication program.

   HOBA session management is identical to username/password session
   management, with a server-side session management tool or script
   inserting a session cookie into the output to the browser.  HOBA
   still requires TLS to prevent session cookie hijacking.

   HOBA keys are "bare keys", so there is no need for the semantic
   overhead of PKIX certificates, particularly with respect to naming
   and trust anchors.  The client public key ("CPK") structures in HOBA
   do not have any publicly-visible identifier for the user who
   possesses the corresponding private key, nor the web-origin with
   which the client is using the CPK.

   HOBA also defines some services that are required for modern HTTP

   o  Servers can bind a CPK with an identifier, such as an account
      name.  Servers using HOBA define their own policies for binding
      CPKs with accounts during account registration.

   o  Users are likely to use more than one device or user agent (UA)
      for the same HTTP based service, so HOBA gives a way to associate

Farrell, et al.           Expires June 8, 2015                  [Page 3]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

      more than one CPK to the same account, but without having to
      register for each separately.

   o  Logout features can be useful for UAs, so HOBA defines a way to
      close a current HTTP "session", and also a way to close all
      current sessions, even if more than one session is currently
      active from different UAs for the same account.

   o  Digital signatures can be expensive to compute, so HOBA defines a
      way for HTTP servers to indicate how long a given challenge value
      is valid, and a way for UAs to fetch a fresh challenge at any

   Users are also likely to lose a private key, or the client's memory
   of which key pair is associated with which origin, such as when a
   user loses the computer or mobile device in which state is stored.
   HOBA does not define a mechanism for deleting the association between
   an existing CPK and an account.  Such a mechanism can be implemented
   at the application layer.

1.1.  Interfacing to Applications (Cookies)

   HOBA can be used as a drop-in replacement for password-based user
   authentication schemes used in common web applications.  The simplest
   way is to (re-)direct the UA to a HOBA "Login" URL and for the
   response to a successful HTTP request containing a HOBA signature to
   set a session cookie [RFC6265].  Further interactions with the web
   application will then be secured via the session cookie, as is
   commonly done today.

   While cookies are bearer tokens, and thus weaker than HOBA
   signatures, they are currently ubiquitously used.  If non-bearer
   token session continuation schemes are developed in future in the
   IETF or elsewhere, then those can interface to HOBA as easily as with
   any password based authentication scheme.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234]

   Account: The term "account" is (loosely) used to refer to whatever
   data structure(s) the server maintains that are associated with an

Farrell, et al.           Expires June 8, 2015                  [Page 4]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   identity.  That will contain of at least one CPK and a web-origin; it
   will also optionally include an HTTP "realm" as defined in the HTTP
   authentication specification.  [RFC7235].  It might also involve many
   other non-standard pieces of data that the server accumulates as part
   of account creation processes.  An account may have many CPKs that
   are considered equivalent in terms of being usable for
   authentication, but the meaning of "equivalent" is really up to the
   server and is not defined here.

   Client public key ("CPK"): A CPK is the public key and associated
   cryptographic parameters needed for a server to validate a signature.

   HOBA-http: We use this term when describing something that is
   specific to HOBA as an HTTP authentication mechanism.

   HOBA-js: We use this term when describing something that is unrelated
   to HOBA-http but is relevant for HOBA as a design pattern that can be
   implemented in a browser in JavaScript.

   User agent (UA): typically, but not always, a web browser.

   User: a person who is running a UA.  In this document, "user" does
   not mean "user name" or "account name".

   Web client: the content and javascript code that run within the
   context of a single UA instance (such as a tab in a web browser).

2.  The HOBA Authentication Scheme

   A UA that implements HOBA maintains a list of web-origins and realms.
   The UA also maintains one or more client credentials for each web-
   origin/realm combination for which it has created a CPK.

   On receipt of a challenge (and optional realm) from a server, the
   client marshals an HOBA to-be-signed (TBS) blob that includes a
   client generated nonce, the web-origin, the realm, an identifier for
   the CPK and the challenge string; and signs that blob with the
   private key corresponding to the CPK for that web-origin.  The
   formatting chosen for this TBS blob is chosen so as to make server-
   side signature verification as simple as possible for a wide range of
   current server tooling.

   Figure 1 specifies the ABNF for the signature input.  The term
   "unreserved" means that the field does not have a specific format

   HOBA-TBS = nonce alg origin [ realm ] kid challenge
   nonce = 1*base64urlchars

Farrell, et al.           Expires June 8, 2015                  [Page 5]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   alg = 1*2DIGIT
   origin = scheme "://" authority ":" port
   realm = unreserved
   kid = 1*base64urlchars
   challenge = 1*base64urlchars
   ; Characters for Base64URL encoding from Table 2 of RFC 4648
   base64urlchars = %x30-39             ; Digits
                    / %x41-5A           ; Uppercase letters
                    / %x61-7A           ; Lowercase letters
                    / "-" / "_" / "="   ; Special characters

                   Figure 1: To-be-signed data for HOBA

   The fields above contain the following:

   o  nonce: is a random value chosen by the UA and MUST be base64url
      encoded before being included in the HOBA-TBS value. (base64url
      encoding is defined in [RFC4648].)  UAs MUST be able to use at
      least 32 bits of randomness in generating a nonce.  UAs SHOULD be
      able to use 64 or more bits of randomness for nonces.

   o  alg: specifies the signature algorithm being used encoded as an
      ASCII character as defined in Section 9.3.  RSA-SHA256 MUST be
      supported, RSA-SHA1 MAY be supported.  The IANA registered
      algorithm values are encoded as ASCII numbers; for example, the
      encoding of RSA-SHA256 is 0x30.

   o  origin: is the web origin expressed as the concatenation of the
      scheme, authority and port from [RFC3986].  These are not base64
      encoded as they will be most readily available to the server in
      plain text.  For example, if accessing the URL "https://" then the bytes input to the signature
      process will be "".  There is no
      default for the port number, and the port number MUST be present.

   o  realm: is similarly just a string with the syntactic restrictions
      defined in [RFC7235].  If no realm is specified for this
      authentication then this is absent.  (A missing field here is no
      problem since both sides know when it needs to be there.)

   o  kid: is a key identifier - this MUST be a base64url encoded value
      that is presented to the server in the HOBA client result (see

   o  challenge: MUST be a base64url encoded challenge value that the
      server chose to send to the client

Farrell, et al.           Expires June 8, 2015                  [Page 6]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   The HOBA-TBS string is the input to the client's signing process, but
   is not itself sent over the network since some fields are already
   inherent in the HTTP exchange.  The challenge however is sent over
   the network so as to make it simpler for a server to be stateless.
   (One form of stateless challenge might be a ciphertext that the
   server decrypts and checks, but that is an implementation detail.)
   The value that is sent over the network by the UA is the HOBA "client
   result" which we now define.

   The HOBA "client result" is a dot-separated string that includes the
   signature and is sent in the HTTP Authorized header field value using
   the value syntax defined in Figure 2.  The "sig" value is the
   base64url encoded version of the binary output of the signing
   process.  The kid, challenge and nonce are as defined above and are
   also base64url encoded.

   HOBA-RES = kid "." challenge "." nonce "." sig
   sig = 1*base64urlchars

                    Figure 2: HOBA Client Result value

   The HOBA scheme is far from new, for example, the basic idea is
   pretty much identical to the first two messages from "Mechanism R" on
   page 6 of [MI93] which predates HOBA by 20 years.

3.  Introduction to the HOBA-http Mechanism

   An HTTP server that supports HOBA authentication includes the "HOBA"
   auth-scheme value in a WWW-Authenticate header field when it wants
   the client to authenticate with HOBA.  Note that the HOBA auth-scheme
   might not be the only one that the server includes in a WWW-
   Authenticate header.

   The HOBA scheme has two REQUIRED attributes (challenge and max-age)
   and one OPTIONAL attribute (realm):

   o  The "challenge" attribute MUST be included.  The challenge is the
      string made up of the base64url encoded octets that the server
      wants the client to sign in its response.  The challenge MUST be
      unique for every HTTP 401 response in order to prevent replay
      attacks from passive observers.

   o  A "max-age" attribute MUST be included that specifies the number
      of seconds from the time the HTTP response is emitted for which
      responses to this challenge can be accepted for example "max-age:
      10" would indicatge ten seconds.  If max-age is set to zero, then

Farrell, et al.           Expires June 8, 2015                  [Page 7]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

      that means that only one signature will be accepted for this

   o  A "realm" attribute MAY be included to indicate the scope of
      protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
      The "realm" attribute MUST NOT appear more than once.

   When the "client response" is created, the UA encodes the HOBA
   client-result and returns that in the Authorization header.  The
   client-result is a string matching the HOBA-RES production in Figure
   2 as an auth-param with the name "result".

   The server MUST check the cryptographic correctness of the signature
   based on a public key it knows for the kid in the signatures, and if
   the server cannot do that, or if the signature fails cryptographic
   checks, then validation has failed.  The server can use any
   additional mechanisms to validate the signature.  If the validation
   fails, or if the server chooses reject the signature for any reason
   whatsoever, the server aborts the transaction via a 401 Unauthorized
   HTTP response.

   Note that a HOBA signature is good for however long a non-zero max-
   age attribute allows.  This means that replay is possible within the
   time window specified by the "max-age" value chosen by the server.
   Servers can attempt to detect any such replay (via caching if they so
   choose) and MAY react to such replays by responding with a second (or
   subsequent) 401-status HTTP response containing a new challenge.

   UAs MAY optimise their use of challenges by pre-fetching a challenge
   value, for example after (max-age)/2 seconds have elapsed, using the
   ".well-known/hoba/getchal" scheme described later in this document.
   This also allows for pre-calculation of HOBA signatures, if that is
   required in order to produce a responsive user interface.

4.  Introduction to the HOBA-js Mechanism

   Web sites using JavaScript can also perform origin-bound
   authentication without needing to involve the HTTP layer, and by
   inference not needing HOBA-http support in browsers.  HOBA-js is not
   an on-the-wire protocol like HOBA-http is: instead, it is a design
   pattern that can be realized completely in JavaScript served in
   normal HTML pages.

   One element is required for HOBA-js: localStorage (see http:// from HTML5 can be used for persistent key
   storage.  For example, an implementation would store a dictionary
   account identifier, public key and private key tuples in the origin's
   localStorage for subsequent authentication requests.  How this

Farrell, et al.           Expires June 8, 2015                  [Page 8]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   information is actually stored in localStorage is an implementation
   detail.  This type of key storage relies on the security properties
   of the same-origin policy that localStorage enforces.  See the
   security considerations for discussion about attacks on localStorage.
   Note that IndexedDB (See is an
   alternative to localStorage that can also be used here.

   Because of JavaScript's same-origin policy, scripts from subdomains
   do not have access to the same localStorage that scripts in their
   parent domains do.  For larger or more complex sites, this could be
   an issue that requires enrollment into subdomains, which could be a
   hassle for users.  One way to get around this is to use session
   cookies because they can be used across subdomains.  That is, with
   HOBA-js, the user might log in using a single well-known domain, and
   then the server uses session cookies to navigate around a site.

   Another element will be highly desirable for HOBA-js when it becomes
   available: WebCrypto (see  In
   lieu of WebCrypto, JavaScript crypto libraries can be employed with
   the known deficiencies of their pseudo-random number generators and
   the general immaturity of those libraries.

5.  HOBA's Authentication Process

   This section describes how clients and servers use HOBA for
   authentication.  The interaction between an HTTP client and HTTP
   server using HOBA happens in three phases: the CPK preparation phase,
   the signing phase, and the authentication phase.  This section also
   covers the actions that give HOBA similar user features as today's
   passwords have.

5.1.  CPK Preparation Phase

   In the CPK preparation phase, the client determines if it already has
   a CPK for the web-origin with which it needs to authenticate.  If the
   client has a CPK, the client will use it; if the client does not have
   a CPK, it generates one in anticipation of the server asking for one.

5.2.  Signing Phase

   In the signing phase, the client connects to the server, the server
   asks for HOBA-based authentication, and the client authenticates by
   signing a blob of information as described in the previous sections.

5.3.  Authentication Phase

   The authentication phase is completely dependent on the policies and
   practices of the server.  That is, this phase involves no

Farrell, et al.           Expires June 8, 2015                  [Page 9]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   standardized protocol in HOBA-http; in HOBA-js, there is no suggested
   interaction template.

   In the authentication phase, the server extracts the CPK from the
   signing phase and decides if it recognizes the CPK.  If the server
   recognizes the CPK, the server may finish the client authentication

   If this stage of the process involves additional information for
   authentication, such as asking the user which account she wants to
   use (in the case where a UA is used for multiple accounts on a site),
   the server can prompt the user for account identifying information or
   the user could choose based on HTML offered by the server before the
   401 is triggered.  None of this is standardized: it all follows the
   server's security policy and session flow.  At the end of this, the
   server probably assigns or updates a session cookie for the client.

   During the authentication phase, if the server does not recognize the
   CPK, it could use HTML and JavaScript to ask the user if they are
   really a new user or want to associate this new CPK with another CPK.
   The server can then use some out-of-band method (such as a
   confirmation email round trip, SMS, or an UA that is already
   enrolled) to verify that the "new" user is the same as the already-
   enrolled one.  Thus, logging in on a new user agent is identical to
   logging in with an existing account.

   If the server does not recognize the CPK the server might send the
   client through a either a join or login-new-UA (see below) process.
   This process is completely up to the server, and probably entails
   using HTML and JavaScript to ask the user some questions in order to
   assess whether or not the server wants to give the client an account.
   Completion of the joining process might require confirmation by
   email, SMS, Captcha, and so on.

   Note that there is no necessity for the server to initiate a joining
   or login process upon completion of the signing phase.  Indeed, the
   server may desire to challenge the UA even for unprotected resources
   and set a session cookie for later use in a join or login process as
   it becomes necessary.  For example, a server might only want to offer
   an account to someone who had been to a few pages on the web site; in
   such a case, the server could use the CPK from an associated session
   cookie as a way of building reputation for the user until the server
   wants the user to join.

6.  Other Parts of the HOBA Process

   The authentication process is more than just the act of
   authentication.  In password-based authentication and HOBA, there are

Farrell, et al.           Expires June 8, 2015                 [Page 10]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   other processes that are needed both before and after an
   authentication step.  This section covers those processes.  Where
   possible, it combines practices of HOBA-http and HOBA-js; where that
   is not possible, the differences are called out.

   All HOBA interactions other than those defined in Section 5 MUST be
   performed in TLS-protected sessions ([RFC5246]).  If the current HTTP
   traffic is not running under TLS, a new session is started before any
   of the actions described here are performed.

   HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for
   performing many tasks: "".
   These URLs are based on the name of the host that the HTTP client is

   There are many use cases for these URLs to redirect to other URLs: a
   site that does registration through a federated site, a site that
   only does registration under HTTPS, and so on.  Like any HTTP client,
   HOBA-http clients have to be able to handle redirection of these
   URLs.  However, as that would potentially cause security issues when
   a re-direct brings the client to a different web origin, servers
   implementing HOBA-http SHOULD NOT re-direct to a different web origin
   from below .well-known/hoba URLs.  The above is considered sufficient
   to allow experimentation with HOBA, but if at some point HOBA is
   placed on the standards track then a full analysis of off-origin re-
   directions would need to be documented.

6.1.  Registration

   Normally, a registration (also called "joining") is expected to
   happen after a UA receives a WWW-Authenticate for a web-origin and
   realm (for HOBA-http) or on demand (for HOBA-js) for which it has no
   associated CPK.  The process of registration for a HOBA account on a
   server is relatively light-weight.  The UA generates a new key pair,
   and associates it with the web-origin/realm in question.

   Note that if the UA has a CPK associated with the web-origin, but not
   for the realm concerned, then a new registration is REQUIRED.  If the
   server did not wish for that outcome, then it ought to use the same
   or no realm.

   The registration message for HOBA-http is sent as a POST message to
   the URL ".well-known/hoba/register" with an HTML form (x-www-form-
   encoded) described below; The registration message for HOBA-js can be
   in any format specified by the server, but it could be the same as
   the one described here for HOBA-http.  It is up to the server to
   decide what kind of user interaction is required before the account
   is finally set up.  When the server's chosen registration flow is

Farrell, et al.           Expires June 8, 2015                 [Page 11]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   completed successfully the server MUST add a Hobareg HTTP header (see
   Section 6.1.1) to the HTTP response message that completes the
   registration flow.

   The registration message sent to server has one mandatory field (pub)
   and some optional fields that allow the UA to specify the type and
   value of key and device identifiers that the UA wishes to use.

   o  pub: is a mandatory field containing the PEM formatted public key
      of the client.  See Appendix C of [RFC6376] for an example of how
      to generate this key format.

   o  kidtype: contains the type of key identifier, this is a numeric
      value intended to contain one of the values from Section 9.4.  If
      this is not present then the mandatory-to-implement hashed public
      key option MUST be used.

   o  kid: contains the key identifier as a base64url encoded string
      that is of the type indicated in the kidtype.  If the kid is a
      hash of a public key then the correct (base64url encoded) hash
      value MUST be provided and the server SHOULD check that and refuse
      the registration if an incorrect value was supplied.

   o  didtype: specifies a kind of device identifier intended to contain
      one of the values from Section 9.5, if absent then the "string"
      form of device identifier MUST be used.

   o  did: a UTF8 string that specifies the device identifier.  This can
      be used to help a user be confident that authentication has
      worked, e.g., following authentication some web content might say
      "You last logged in from device 'did' at time T."

   Note that replay of registration (and other HOBA) messages is quite
   possible.  That however can be counteracted if challenge freshness is
   ensured.  See Section 2 for details.  Note also that with HOBA-http
   the HOBA signature does not cover the POST message body.  If that is
   required then HOBA-JS may be a better fit for registration and other
   account management actions.

6.1.1.  Hobareg Definition

   Since registration can often be a multi-step process, e.g.  requiring
   a user to fill in contact details, the initial response to the HTTP
   POST message defined above may not be the end of the registration
   process even though the HTTP response has a 200 OK status.  This
   creates an issue for the UA since, during the registration process
   (e.g., while dealing with interstitial pages), the UA doesn't yet
   know whether the CPK is good for that web origin or not.

Farrell, et al.           Expires June 8, 2015                 [Page 12]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   For this reason the server MUST add a header to the response message
   when the registration has succeded to indicate the new state.  The
   header to be used is "Hobareg" and the value when registration has
   succeeded is to be "regok".  When registration is inwork (e.g. on an
   HTTP response for an interstitial page) the server MAY add this
   header with a value of "reginwork".  See Section 9.6 for the relevant
   IANA registration of this header field.

   For interstitial pages, the client MAY include a HOBA Authorization
   header.  This is not considered a MUST as that might needlessly
   complicate client implementations but is noted here in case a server
   implementer assumes that all registration messages contain a HOBA
   Authorization header.

   Hobareg-val = "regok" / "inwork"

                 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:

   o  Only one single value is allowed in a Hobareg header field.
      Should more than one (a list) be encountered, that should be
      interpreted as being the same as "inwork."

   o  The Hobareg header field can only be used in HTTP responses.

   o  Since Hobareg is only meant for responses it ought not appear in a
      PUT request.

   o  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

   o  Intermediaries should never insert, delete or modify a Hobareg
      header field.

   o  As a response-only header field, it is not appropriate to list a
      Hobareg in a Vary response header field.

   o  Hobareg is allowed in trailers.

Farrell, et al.           Expires June 8, 2015                 [Page 13]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   o  As a response-only header field, Hobareg will not be preserved
      across re-directs.

   o  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 Exiting 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)

Farrell, et al.           Expires June 8, 2015                 [Page 14]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   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

6.3.  Logging Out

   The user can tell the server it wishes to log out.  With HOBA-http,
   this is done by sending any HOBA-authenticated HTTP 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

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

6.4.  Getting a Fresh Challenge

Farrell, et al.           Expires June 8, 2015                 [Page 15]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   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 include a fresh (base64url encoded) HOBA
   challenge for this origin in the body of the response.

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 SHOULD 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.

Farrell, et al.           Expires June 8, 2015                 [Page 16]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   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
   exepect 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

   Our use of localStorage 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/

Farrell, et al.           Expires June 8, 2015                 [Page 17]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

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.

9.  IANA Considerations

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

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

Farrell, et al.           Expires June 8, 2015                 [Page 18]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

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

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

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

Farrell, et al.           Expires June 8, 2015                 [Page 19]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

9.6.  Hobareg HTTP Header

   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

   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 two known implementations.  One done
   by Stephen Farrell of HOBA-http and a HOBA-JS variant implements the
   current (-04) version of HOBA and is available from
   which site also includes a demonstration of HOBA.

Farrell, et al.           Expires June 8, 2015                 [Page 20]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   There is another implementation by Michael Thomas of an HOBA-JS

11.  Acknowledgements

   Thanks to the following for good comments received during the
   preparation of this specification: Amos Jeffries, Benjamin Kaduk,
   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

   [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.

   [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

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December

   [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.

Farrell, et al.           Expires June 8, 2015                 [Page 21]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   [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.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              April 2011.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
              September 2011.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982, July

   [bonneau]  Bonneau, , "The science of guessing: analyzing an
              anonymized corpus of 70 million passwords.", Security and
              Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 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

   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

Farrell, et al.           Expires June 8, 2015                 [Page 22]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014

   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 Plain
   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  Carriage-returns have been added
   and need to be removed to validate the example.

   -----BEGIN PUBLIC KEY-----
   -----END PUBLIC KEY-----

   Key Identifier: kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267UetbAfkWHbw

   Challenge: z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs=

   Nonce: LV_WTVyHFfE


   The resulting signature is:

Farrell, et al.           Expires June 8, 2015                 [Page 23]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)        December 2014


   The final HTTP header field sent with a request is then:

   Authorization: HOBA result="kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267Uetb

Authors' Addresses

   Stephen Farrell
   Trinity College Dublin
   Dublin  2

   Phone: +353-1-896-2354

   Paul Hoffman
   VPN Consortium


   Michael Thomas


Farrell, et al.           Expires June 8, 2015                 [Page 24]