GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7486

Internet Engineering Task Force (IETF) S. Farrell Request for Comments: 7486 Trinity College Dublin Category: Experimental P. Hoffman ISSN: 2070-1721 VPN Consortium

                                                             M. Thomas
                                                             Phresheez
                                                            March 2015
              HTTP Origin-Bound Authentication (HOBA)

Abstract

 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 document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7486.

Farrell, et al. Experimental [Page 1] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

Copyright Notice

 Copyright (c) 2015 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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 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 . . . . . . . . . . . . . . . . . . . . . . .   5
   1.3.  Step-by-Step Overview of HOBA-http  . . . . . . . . . . .   6
 2.  The HOBA Authentication Scheme  . . . . . . . . . . . . . . .   6
 3.  Introduction to the HOBA-http Mechanism . . . . . . . . . . .   9
 4.  Introduction to the HOBA-js Mechanism . . . . . . . . . . . .  10
 5.  HOBA's Authentication Process . . . . . . . . . . . . . . . .  11
   5.1.  CPK Preparation Phase . . . . . . . . . . . . . . . . . .  11
   5.2.  Signing Phase . . . . . . . . . . . . . . . . . . . . . .  11
   5.3.  Authentication Phase  . . . . . . . . . . . . . . . . . .  11
 6.  Other Parts of the HOBA Process . . . . . . . . . . . . . . .  12
   6.1.  Registration  . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.1.  Hobareg Definition  . . . . . . . . . . . . . . . . .  14
   6.2.  Associating Additional Keys to an Existing Account  . . .  16
     6.2.1.  Moving Private Keys . . . . . . . . . . . . . . . . .  16
     6.2.2.  Human-Memorable One-Time Password (Don't Do This One)  16
     6.2.3.  Out-of-Band URL . . . . . . . . . . . . . . . . . . .  17
   6.3.  Logging Out . . . . . . . . . . . . . . . . . . . . . . .  17
   6.4.  Getting a Fresh Challenge . . . . . . . . . . . . . . . .  17
 7.  Mandatory-to-Implement Algorithms . . . . . . . . . . . . . .  18
 8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   8.1.  Privacy Considerations  . . . . . . . . . . . . . . . . .  18
   8.2.  localStorage Security for JavaScript  . . . . . . . . . .  19
   8.3.  Multiple Accounts on One User Agent . . . . . . . . . . .  20
   8.4.  Injective Mapping for HOBA-TBS  . . . . . . . . . . . . .  20
 9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   9.1.  HOBA Authentication Scheme  . . . . . . . . . . . . . . .  21
   9.2.  .well-known URI . . . . . . . . . . . . . . . . . . . . .  21
   9.3.  Algorithm Names . . . . . . . . . . . . . . . . . . . . .  21
   9.4.  Key Identifier Types  . . . . . . . . . . . . . . . . . .  22

Farrell, et al. Experimental [Page 2] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

   9.5.  Device Identifier Types . . . . . . . . . . . . . . . . .  22
   9.6.  Hobareg HTTP Header Field . . . . . . . . . . . . . . . .  23
 10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
   10.1.  Normative References . . . . . . . . . . . . . . . . . .  23
   10.2.  Informative References . . . . . . . . . . . . . . . . .  24
 Appendix A.  Problems with Passwords  . . . . . . . . . . . . . .  26
 Appendix B.  Example  . . . . . . . . . . . . . . . . . . . . . .  27
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  28
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

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 in a challenge-response
 scheme as its 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 [RFC6265] into the output to the browser.
 Use of Transport Layer Security (TLS) for the HTTP session is still
 necessary to prevent session cookie hijacking.
 HOBA keys are "bare keys", so there is no need for the semantic
 overhead of X.509 public key certificates, particularly with respect
 to naming and trust anchors.  The Client Public Key (CPK) structures

Farrell, et al. Experimental [Page 3] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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 needed for modern HTTP
 authentication:
 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
    more than one CPK to the same account 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".
 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
    time.
 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.
 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.

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.

Farrell, et al. Experimental [Page 4] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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 the 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",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "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
 identity.  That will contain 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).

Farrell, et al. Experimental [Page 5] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

1.3. Step-by-Step Overview of HOBA-http

 Step-by-step, a typical HOBA-http registration and authentication
 flow might look like this:
 1.  The client connects to the server and makes a request, and the
     server's response includes a WWW-Authenticate header field that
     contains the "HOBA" auth-scheme, along with associated parameters
     (see Section 3).
 2.  If the client was not already registered with the web origin and
     realm it is trying to access, the "joining" process is invoked
     (see Section 6.1).  This creates a key pair and makes the CPK
     known to the server so that the server can carry out the account
     creation processes required.
 3.  The client uses the challenge from the HOBA auth-scheme
     parameters, along with other information it knows about the web
     origin and realm, to create and sign a HOBA to-be-signed (HOBA-
     TBS) string (see Section 2).
 4.  The client creates a HOBA client-result (HOBA-RES), using the
     signed HOBA-TBS for the "sig" value (see Section 2).
 5.  The client includes the Authorization header field in its next
     request, using the "HOBA" auth-scheme and putting the HOBA
     client-result in an auth-param named "result" (see Section 3).
 6.  The server authenticates the HOBA client-result (see
     Section 5.1).
 7.  Typically, the server's response includes a session cookie that
     allows the client to indicate its authentication state in future
     requests (see Section 1.1).

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 a HOBA-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

Farrell, et al. Experimental [Page 6] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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
 defined and allows the characters specified in Section 2.3 of
 [RFC3986].
    HOBA-TBS = len ":" nonce
            len ":" alg
            len ":" origin
            len ":" [ realm  ]
            len ":" kid
            len ":" challenge
    len = 1*DIGIT
    nonce = 1*base64urlchars
    alg = 1*2DIGIT
    origin = scheme "://" authority ":" port
    ; scheme, etc., are from RFC 3986
    realm = unreserved
    ; realm is to be treated as in Section 2.2 of RFC 7235
    kid = 1*base64urlchars
    challenge = 1*base64urlchars
    ; Characters for Base64URL encoding from Table 2 of RFC 4648
    ; all of which are US-ASCII (see RFC 20)
    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  len: Each field is preceded by the number of octets of the
    following field, expressed as a decimal number in ASCII [RFC20].
    Lengths are separated from field values by a colon character.  So
    if a nonce with the value "ABCD" were used, then that would be
    preceeded by "4:" (see the example in Appendix B for details).
 o  nonce: 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]; guidelines for randomness are
    given in [RFC4086].)  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.

Farrell, et al. Experimental [Page 7] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 o  alg: specifies the signature algorithm being used.  See Section 7
    for details of algorithm support requirements.  The IANA-
    registered algorithm values (see Section 9.3) are encoded as one-
    or two-digit ASCII numbers.  For example, RSA-SHA256 (number 0) is
    encoded as the ASCII character "0" (0x30), while a future
    algorithm registered as number 17 would be encoded as the ASCII
    characters "17" (0x3137).
 o  origin: 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://www.example.com:8080/foo", then the bytes input to the
    signature process will be "https://www.example.com:8080".  There
    is no default for the port number, and the port number MUST be
    present.
 o  realm: a string with the syntactic restrictions defined in
    [RFC7235].  If no realm is specified for this authentication, then
    this is absent but is preceeded by a length of zero ("0:").
    Recall that both sides know when this needs to be there,
    independent of the encoding via a zero length.
 o  kid: a key identifier.  This MUST be a base64url-encoded value
    that is presented to the server in the HOBA client result (see
    below).
 o  challenge: MUST be a base64url-encoded challenge value that the
    server chose to send to the client.  The challenge MUST be chosen
    so that it is infeasible to guess and SHOULD be indistinguishable
    from (the base64url encoding of) a random string that is at least
    128 bits long.
 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 reduce the amount of state that needs to be
 maintained by servers.  (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 Authorization 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.

Farrell, et al. Experimental [Page 8] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

    HOBA-RES = kid "." challenge "." nonce "." sig
    sig = 1*base64urlchars
                  Figure 2: HOBA Client Result Value
 If a malformed message of any kind is received by a server, the
 server MUST fail authentication.  If a malformed message of any kind
 is received by a client, the client MUST abandon that authentication
 attempt.  (The client is, of course, free to start another
 authentication attempt if it desires.)

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 401 HTTP response in order to prevent replay
    attacks from passive observers.
 o  A "max-age" attribute MUST be included.  It 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 indicate ten seconds.  If max-age is set to zero,
    then that means that only one signature will be accepted for this
    challenge.
 o  A "realm" attribute MAY be included to indicate the scope of
    protection in the manner described in HTTP/1.1, Authentication
    [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

Farrell, et al. Experimental [Page 9] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 additional mechanisms to validate the signature.  If the validation
 fails, or if the server chooses to reject the signature for any
 reason whatsoever, the server fails the request with a 401
 Unauthorized HTTP response.
 The server MUST check that the same web origin is used in all of the
 server's TLS server certificates, the URL being accessed, and the
 HOBA signature.  If any of those checks fail, the server treats the
 signature as being cryptographically incorrect.
 Note that a HOBA signature is good for however long a non-zero max-
 age parameter 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 HTTP response containing a new challenge.
 To optimize their use of challenges, UAs MAY prefetch 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 precalculation 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 thing that is highly desirable for HOBA-js is WebCrypto (see
 <http://www.w3.org/TR/WebCryptoAPI>), which is (at the time of
 writing) starting to see deployment.  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.
 Without Webcrypto, one element is required for HOBA-js; localStorage
 (see <http://www.w3.org/TR/webstorage/>) from HTML5 can be used for
 persistent key storage.  For example, an implementation would store a
 dictionary account identifier as well as public key and private key
 tuples in the origin's localStorage for subsequent authentication
 requests.  How this 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

Farrell, et al. Experimental [Page 10] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 attacks on localStorage.  Note that IndexedDB (see
 <http://www.w3.org/TR/IndexedDB/>) is an alternative to localStorage
 that can also be used here and that is used by WebCrypto.
 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
 difficult 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 session cookies are used whilst the user navigates around the
 site.

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 features similar to today's
 password-based schemes.

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
 standardized protocol in HOBA-http; in HOBA-js, there is no suggested
 interaction template.
 In the authentication phase, the server uses the key identifier (kid)
 to determine 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 process.

Farrell, et al. Experimental [Page 11] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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 response 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 cannot determine the
 correct 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 a 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 UA is identical to logging in with an
 existing account.
 If the server does not recognize the CPK, the server might send the
 client through 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
 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.

Farrell, et al. Experimental [Page 12] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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 URI [RFC5785] "hoba" as a base URI for
 performing many tasks: "https://www.example.com/.well-known/hoba".
 These URIs are based on the name of the host that the HTTP client is
 accessing.
 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
 requests.  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 redirect 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 redirections would need to be documented.

6.1. Registration

 Normally, a registration (also called "joining") is expected to
 happen after a UA receives a 401 response 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 lightweight.  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, see <http://www.w3.org/TR/2014/REC-html5-20141028/
 forms.html#url-encoded-form-data>), 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 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.

Farrell, et al. Experimental [Page 13] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 The registration message sent to the 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: a mandatory field containing the Privacy Enhanced Mail (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 defined in Section 9.5 MUST be used.
 o  did: a UTF-8 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.
 For this reason, the server MUST add a header field to the response
 message when the registration has succeeded in order to indicate the
 new state.  The header to be used is "Hobareg", and the value when

Farrell, et al. Experimental [Page 14] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 registration has succeeded is to be "regok".  When registration is in
 an intermediate state (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" / "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:
 o  Only one single value is allowed in a Hobareg header field.
    Should more than one (a list) be encountered, or any other ABNF-
    invalid value, that SHOULD be interpreted as being the same as
    "reginwork".
 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
    requests.
 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 mean that
    registration has failed regardless of the value of Hobareg seen.
    The request method has no influence on the interpretation of
    Hobareg.
 o  Intermediaries 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.
 o  As a response-only header field, Hobareg will not be preserved
    across re-directs.

Farrell, et al. Experimental [Page 15] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

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

Farrell, et al. Experimental [Page 16] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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 dereferences on the newest UA.  The user could email that URL
 to herself, for example, or 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 MUST contain a fresh (base64url-encoded) HOBA challenge
 for this origin in the body of the response.  Whitespace in the
 response MUST be ignored.

Farrell, et al. Experimental [Page 17] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

7. Mandatory-to-Implement Algorithms

 RSA-SHA256 MUST be supported.  HOBA implementations MUST use RSA-
 SHA256 if it is provided by the underlying cryptographic libraries.
 RSA-SHA1 MAY be used.  RSA modulus lengths of at least 2048 bits
 SHOULD be used.  RSA indicates the RSASSA-PKCS1-v1_5 algorithm
 defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are
 defined in [SHS].  Keys with moduli shorter than 2048 bits SHOULD
 only be used in cases where generating 2048-bit (or longer) keys is
 impractical, e.g., on very constrained or old devices.

8. Security Considerations

 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.
 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.
 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 short for the
 slowest signing device that is significant for that site.

8.1. Privacy Considerations

 HOBA does, to some extent, impact 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. Experimental [Page 18] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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 counterintuitive, 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.
 Device identifiers are intended to specify classes of device in a way
 that can assist with registration and with presentation to the user
 of information about previous sessions, e.g., last login time.
 Device identifier types MUST NOT be privacy sensitive, with values
 that would allow tracking a user in unexpected ways.  In particular,
 using a device identifier type that is analogous to the International
 Mobile Equipment Identifier (IMEI) would be a really bad idea and is
 the reason for the "MUST NOT" above.  In that case, "mobile phone"
 could be an acceptable choice.
 If possible, implementations ought to encourage the use of device
 identifier values that are not personally identifying except for the
 user concerned; for example, "Alice's mobile" is likely to be chosen
 and is somewhat identifying, but "Alice's phone: UUID 1234-5567-
 89abc-def0" would be a very bad choice.

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 that 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 Cross-Site Scripting (XSS) attacks, which could conceivably take
 the keying material and use it to create UAs under the control of an
 attacker.  XSS attacks are, in reality, devastating across the board
 since they can and do steal credit card information, passwords,
 perform illicit acts, etc.  It's not evident that we are introducing
 unique threats from which cleartext 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 that the user supplies.  This may sound
 counterintuitive, but the object here is to keep passwords off of

Farrell, et al. Experimental [Page 19] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 servers to mitigate the multiplier effect of a large-scale compromise
 (e.g., [ThreatReport]) 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 also to all of the sites on which a user used
 the same password.  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 could 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.
 However, all such features really ought to be part of the operating
 system or platform and not part of a HOBA implementation, so those
 are not discussed further.

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 reused this to-be-signed structure.
 Those fields ensure that the mapping from input fields to the HOBA-
 TBS string is an injective mapping.

Farrell, et al. Experimental [Page 20] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

9. IANA Considerations

 IANA has made registrations and created new registries as described
 below.
 All new registries have been placed beneath a new "HTTP Origin-Bound
 Authentication (HOBA) Parameters" category.

9.1. HOBA Authentication Scheme

 A new scheme has been registered in the HTTP Authentication Scheme
 Registry as follows:
 Authentication Scheme Name: HOBA
 Reference: Section 3 of RFC 7486
 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

 A new .well-known URI has been registered in the Well-Known URIs
 registry as described below.
 URI Suffix: hoba
 Change Controller: IETF
 Reference: Section 6 of RFC 7486
 Related Information: N/A

9.3. Algorithm Names

 A new HOBA signature algorithms registry has been created as follows,
 with Specification Required as the registration procedure.  New HOBA
 signature algorithms SHOULD be in use with other IETF Standards Track
 protocols before being added to this registry.
 Number       Meaning                         Reference
 -----------  ------------------------------  ------------
 0            RSA-SHA256                      RFC 7486
 1            RSA-SHA1                        RFC 7486

Farrell, et al. Experimental [Page 21] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 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 in Figure 1, the maximum value for this
 is decimal 99.

9.4. Key Identifier Types

 A new HOBA Key Identifier Types registry has been created as follows,
 with Specification Required as the registration procedure.
 Number       Meaning                         Reference
 -----------  ------------------------------  ------------
 0            a hashed public key             [RFC6698]
 1            a URI                           [RFC3986]
 2            an unformatted string, at the   RFC 7486
              user's/UA's whim
 For the number 0, hashed public keys are as done in DNS-Based
 Authentication of Named Entities (DANE) [RFC6698].
 For this registry, the number column should contain a small positive
 integer.

9.5. Device Identifier Types

 A new HOBA Device Identifier Types registry has been created as
 follows, with Specification Required as the registration procedure.
 The designated expert for this registry is to carefully pay attention
 to the notes on this field in Section 8.1, in particular, the "MUST
 NOT" stated therein.
 Number       Meaning                         Reference
 -----------  ------------------------------  -----------
 0            an unformatted string, at the   RFC 7486
              user's/UA's whim
 For this registry, the number column should contain a small positive
 integer.

Farrell, et al. Experimental [Page 22] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

9.6. Hobareg HTTP Header Field

 A new identifier has been registered in the Permanent Message Header
 Field Names registry as described below.
 Header Field Name: Hobareg
 Protocol: http (RFC 7230)
 Status: experimental
 Author/Change controller: IETF
 Reference: Section 6.1.1 of RFC 7486
 Related information: N/A

10. References

10.1. Normative References

 [RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
            RFC 20, October 1969,
            <http://www.rfc-editor.org/info/rfc20>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
            Standards (PKCS) #1: RSA Cryptography Specifications
            Version 2.1", RFC 3447, February 2003,
            <http://www.rfc-editor.org/info/rfc3447>.
 [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66, RFC
            3986, January 2005,
            <http://www.rfc-editor.org/info/rfc3986>.
 [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
            Encodings", RFC 4648, October 2006,
            <http://www.rfc-editor.org/info/rfc4648>.
 [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234, January 2008,
            <http://www.rfc-editor.org/info/rfc5234>.

Farrell, et al. Experimental [Page 23] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246, August 2008,
            <http://www.rfc-editor.org/info/rfc5246>.
 [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
            Uniform Resource Identifiers (URIs)", RFC 5785, April
            2010, <http://www.rfc-editor.org/info/rfc5785>.
 [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December
            2011, <http://www.rfc-editor.org/info/rfc6454>.
 [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
            of Named Entities (DANE) Transport Layer Security (TLS)
            Protocol: TLSA", RFC 6698, August 2012,
            <http://www.rfc-editor.org/info/rfc6698>.
 [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
            Framework: Bearer Token Usage", RFC 6750, October 2012,
            <http://www.rfc-editor.org/info/rfc6750>.
 [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
            June 2014, <http://www.rfc-editor.org/info/rfc7231>.
 [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014,
            <http://www.rfc-editor.org/info/rfc7235>.
 [SHS]      NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March
            2012.

10.2. Informative References

 [Bonneau]  Bonneau, J., "The Science of Guessing: Analyzing an
            Anonymized Corpus of 70 Million Passwords", IEEE Symposium
            on Security and Privacy 538-552, 2012.
 [MI93]     Mitchell, C. and A. Thomas, "Standardising authentication
            protocols based on public key techniques", Journal of
            Computer Security Volume 2, 23-36, 1993.
 [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
            "Randomness Requirements for Security", BCP 106, RFC 4086,
            June 2005, <http://www.rfc-editor.org/info/rfc4086>.
 [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
            April 2011, <http://www.rfc-editor.org/info/rfc6265>.

Farrell, et al. Experimental [Page 24] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

 [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
            "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
            RFC 6376, September 2011,
            <http://www.rfc-editor.org/info/rfc6376>.
 [ThreatReport]
            Sophos, "Security Threat Report 2013", January 2013,
            <http://www.sophos.com/en-us/medialibrary/pdfs/other/
            sophossecuritythreatreport2013.pdf>.

Farrell, et al. Experimental [Page 25] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

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 identifiers that go 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 they are of course unlikely to be reused
 across many systems.  Similarly, database attacks of some form or
 other will work against any password-based authentication scheme,
 regardless of the cryptographic protocol used.  So for example, zero-
 knowledge or Password-Authenticated Key Exchange (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.

Farrell, et al. Experimental [Page 26] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

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:
  1. —-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=
 Signature algorithm: RSA-SHA256 ("0")
 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"

Farrell, et al. Experimental [Page 27] RFC 7486 HTTP Origin-Bound Auth (HOBA) March 2015

Acknowledgements

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

Authors' Addresses

 Stephen Farrell
 Trinity College Dublin
 Dublin  2
 Ireland
 Phone: +353-1-896-2354
 EMail: stephen.farrell@cs.tcd.ie
 Paul Hoffman
 VPN Consortium
 EMail: paul.hoffman@vpnc.org
 Michael Thomas
 Phresheez
 EMail: mike@phresheez.com

Farrell, et al. Experimental [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7486.txt · Last modified: 2015/03/11 00:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki