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

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

本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


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

版权所有(c)2015 IETF信托基金和确定为文件作者的人员。版权所有。

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

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

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
   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
     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
     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
1. 介绍

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.

当前的用户名/密码身份验证方法(如HTTP Basic、HTTP摘要和web表单)已使用多年,但容易被服务器端密码数据库窃取。HOBA在质询-响应方案中使用数字签名作为其身份验证机制,而不是密码。HOBA还添加了一些有用的功能,如凭证管理和会话注销。在HOBA中,客户机为其认证的每个主机(“web源”[RFC6454])创建一个新的公私密钥对。这些密钥在HOBA中用于HTTP客户机向HTTP协议或JavaScript身份验证程序中的服务器进行身份验证。

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


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 服务器可以使用标识符(如帐户名)绑定CPK。使用HOBA的服务器定义自己的策略,以便在帐户注册期间将CPK与帐户绑定。

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 用户可能会为同一个基于HTTP的服务使用多个设备或用户代理(UA),因此HOBA提供了一种方法,可以将多个CPK关联到同一个帐户,而无需分别注册。

o Logout features can be useful for UAs, so HOBA defines a way to close a current HTTP "session".

o 注销功能对UAs很有用,所以HOBA定义了一种关闭当前HTTP“会话”的方法。

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.

o 数字签名的计算成本很高,因此HOBA为HTTP服务器定义了一种指示给定质询值有效时间的方法,并为UAs定义了一种随时获取新质询的方法。

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)
1.1. 应用程序接口(cookie)

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 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
1.2. 术语

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

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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.

HOBA js:我们在描述与HOBA http无关但与HOBA相关的设计模式时使用这个术语,该设计模式可以在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).


1.3. Step-by-Step Overview of HOBA-http
1.3. HOBA http的分步概述

Step-by-step, a typical HOBA-http registration and authentication flow might look like this:

一步一步,典型的HOBA http注册和身份验证流程可能如下所示:

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

1. 客户端连接到服务器并发出请求,服务器的响应包括一个WWW Authenticate头字段,该字段包含“HOBA”身份验证方案以及相关参数(请参见第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.

2. 如果客户机尚未向其试图访问的web源和域注册,则会调用“加入”过程(参见第6.1节)。这将创建一个密钥对,并使服务器知道CPK,以便服务器可以执行所需的帐户创建过程。

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

3. 客户机使用来自HOBA auth方案参数的质询,以及它知道的有关web源和领域的其他信息,来创建和签署HOBA待签名(HOBA-TBS)字符串(请参阅第2节)。

4. The client creates a HOBA client-result (HOBA-RES), using the signed HOBA-TBS for the "sig" value (see Section 2).

4. 客户端使用签名的HOBA-TBS作为“sig”值创建HOBA客户端结果(HOBA-RES)(参见第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).

5. 客户机在其下一个请求中包括Authorization header字段,使用“HOBA”身份验证方案,并将HOBA客户机结果放入名为“result”的身份验证参数中(参见第3节)。

6. The server authenticates the HOBA client-result (see Section 5.1).

6. 服务器验证HOBA客户端结果(参见第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).

7. 通常,服务器的响应包括一个会话cookie,该cookie允许客户端在将来的请求中指示其身份验证状态(请参阅第1.1节)。

2. The HOBA Authentication Scheme
2. HOBA认证方案

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

在从服务器接收质询(和可选领域)时,客户端封送一个HOBA-TBS blob,其中包括客户端生成的nonce、web源、领域、CPK标识符和质询字符串,并使用与该web源的CPK对应的私钥对该blob进行签名。所选格式

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.

为此,选择TBS blob是为了使服务器端签名验证尽可能简单,适用于当前广泛的服务器工具。

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
      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 len:每个字段前面都有以下字段的八位字节数,用ASCII[RFC20]中的十进制数表示。长度与字段值之间用冒号分隔。因此,如果使用了值为“ABCD”的nonce,则其前面将加上“4:”(有关详细信息,请参见附录B中的示例)。

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.

o nonce:UA选择的一个随机值,在包含在HOBA-TBS值中之前必须进行base64url编码。(base64url编码在[RFC4648]中定义;随机性准则在[RFC4086]中给出)。UAs必须能够在生成nonce时使用至少32位随机性。UAs应该能够为nonce使用64位或更多的随机性。

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 alg:指定正在使用的签名算法。有关算法支持要求的详细信息,请参见第7节。IANA注册算法值(见第9.3节)编码为一位或两位ASCII数字。例如,RSA-SHA256(数字0)编码为ASCII字符“0”(0x30),而注册为数字17的未来算法将编码为ASCII字符“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 "", 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 来源:web来源,表示为[RFC3986]中方案、权限和端口的连接。这些不是base64编码的,因为它们最容易以纯文本形式提供给服务器。例如,如果访问URL“,则输入到签名进程的字节将为". 端口号没有默认值,端口号必须存在。

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 领域:具有[RFC7235]中定义的语法限制的字符串。如果没有为此身份验证指定域,则不存在该域,但前面的长度为零(“0:”)。回想一下,双方都知道何时需要这样做,这与通过零长度进行编码无关。

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 孩子:一个关键标识符。这必须是在HOBA客户端结果中呈现给服务器的base64url编码值(见下文)。

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.

o 质询:必须是服务器选择发送给客户端的base64url编码的质询值。必须选择质询,使其无法猜测,并且与至少128位长的随机字符串(的base64url编码)无法区分。

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.


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

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
3. HOBA http机制简介

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.

支持HOBA身份验证的HTTP服务器希望客户端使用HOBA进行身份验证时,会在WWW Authenticate标头字段中包含“HOBA”身份验证方案值。注意,HOBA auth方案可能不是服务器在WWW-Authenticate头中包含的唯一方案。

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 必须包括“挑战”属性。挑战是由base64url编码的八位字节组成的字符串,服务器希望客户端在其响应中签名。为了防止被动观察者的重播攻击,每个401 HTTP响应的质询必须是唯一的。

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 必须包含“最大年龄”属性。它指定从HTTP响应发出开始的秒数,可以接受对此质询的响应;例如,“最大年龄:10”表示10秒。如果“最大年龄”设置为零,则表示此质询只接受一个签名。

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.

o 可以包括“realm”属性,以按照HTTP/1.1认证[RFC7235]中描述的方式指示保护范围。“realm”属性不能出现多次。

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

请注意,无论非零max age参数允许多长时间,HOBA签名都是有效的。这意味着可以在服务器选择的“最大年龄”值指定的时间窗口内重播。服务器可以尝试检测任何此类重播(如果他们选择的话,可以通过缓存),并且可以通过使用第二个(或后续的)包含新质询的401 HTTP响应来响应此类重播。

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
4. HOBA-js机制简介

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.

使用JavaScript的网站也可以执行源代码绑定的身份验证,而无需涉及HTTP层,并且可以推断浏览器中不需要HTTP支持。HOBA js不像HOBA http那样是在线协议;相反,它是一种设计模式,完全可以在普通HTML页面中提供的JavaScript中实现。

One thing that is highly desirable for HOBA-js is WebCrypto (see <>), 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.

HOBA js非常需要的一件事是WebCrypto(参见<>),它(在编写本文时)开始看到部署。可以使用JavaScript加密库代替WebCrypto,因为它们的伪随机数生成器存在已知的缺陷,而且这些库通常还不成熟。

Without Webcrypto, one element is required for HOBA-js; localStorage (see <>) 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

如果没有Webcrypto,HOBA js需要一个元素;本地存储(请参阅<>)从HTML5可以用于持久密钥存储。例如,实现将字典帐户标识符以及公钥和私钥元组存储在源本地存储中,以供后续身份验证请求使用。如何在localStorage中实际存储此信息是一个实现细节。这种类型的密钥存储依赖于localStorage实施的同源策略的安全属性。有关的讨论,请参见安全注意事项

attacks on localStorage. Note that IndexedDB (see <>) 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.

由于JavaScript的同源策略,子域中的脚本无法访问与其父域中的脚本相同的本地存储。对于更大或更复杂的站点,这可能是一个需要注册到子域的问题,这对用户来说可能很困难。解决这个问题的一种方法是使用会话cookie,因为它们可以跨子域使用。也就是说,使用HOBA js,用户可以使用单个已知域登录,然后在用户浏览站点时使用会话cookie。

5. HOBA's Authentication Process
5. HOBA的认证过程

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
5.1. CPK制备阶段

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
5.2. 签署阶段

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
5.3. 认证阶段

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.

身份验证阶段完全依赖于服务器的策略和实践。也就是说,这个阶段不涉及HOBA http中的标准化协议;在HOBA js中,没有建议的交互模板。

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.


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
6. HOBA流程的其他部分

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.


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: "". These URIs are based on the name of the host that the HTTP client is accessing.

HOBA http使用众所周知的URI[RFC5785]“HOBA”作为执行许多任务的基本URI:". 这些URI基于HTTP客户端正在访问的主机的名称。

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.

这些URL有许多重定向到其他URL的用例:通过联邦站点进行注册的站点,仅通过HTTPS进行注册的站点,等等。与任何HTTP客户端一样,HOBA HTTP客户端必须能够处理这些请求的重定向。但是,当重新定向将客户端带到不同的web源时,这可能会导致安全问题,因此实现HOBA http的服务器不应从下面的“.well-known/HOBA”URL重定向到不同的web源。上述内容被认为足以进行HOBA试验,但如果在某一点上HOBA被置于标准轨道上,则需要记录对异地重定向的完整分析。

6.1. Registration
6.1. 登记

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.

通常,注册(也称为“加入”)预计在UA收到401响应后发生,该响应针对的是它没有关联CPK的web源和领域(对于HOBA http)或按需(对于HOBA js)。在服务器上注册HOBA帐户的过程相对较轻。UA生成一个新的密钥对,并将其与相关的web源/域相关联。

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

HOBA http的注册消息作为POST消息发送到URL“.well-known/HOBA/register”,带有HTML表单(x-www-form-encoded,请参阅< html#url编码表单数据>),如下所述。hobajs的注册消息可以是服务器指定的任何格式,但它可以与这里描述的hobahttp的格式相同。在最终设置帐户之前,由服务器决定需要何种用户交互。当服务器选择的注册流成功完成时,服务器必须向完成注册流的HTTP响应消息中添加Hobareg HTTP头(参见第6.1.1节)。

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 pub:包含客户端隐私增强邮件(PEM)格式公钥的必填字段。有关如何生成此密钥格式的示例,请参见[RFC6376]的附录C。

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 kidtype:包含密钥标识符的类型。这是一个数字值,旨在包含第9.4节中的一个值。如果不存在此选项,则必须使用强制实现哈希公钥选项。

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 kid:包含密钥标识符,作为基德类型中指定类型的base64url编码字符串。如果kid是公钥的散列,则必须提供正确的(base64url编码的)散列值,并且服务器应检查该散列值,如果提供的值不正确,则拒绝注册。

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 didtype:指定一种设备标识符,用于包含第9.5节中的一个值。如果没有,则必须使用第9.5节中定义的设备标识符的“字符串”形式。

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

o did:指定设备标识符的UTF-8字符串。这可用于帮助用户确信身份验证已起作用,例如,在身份验证之后,某些web内容可能会说“您上次从设备‘did’登录是在时间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.

请注意,注册(和其他HOBA)消息的重播是完全可能的。然而,如果保证了挑战新鲜度,这一点可以抵消。详见第2节。还请注意,对于HOBA http,HOBA签名不包括POST消息体。如果需要,那么HOBA-JS可能更适合注册和其他帐户管理操作。

6.1.1. Hobareg Definition
6.1.1. 霍巴雷定义

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.

由于注册通常可以是一个多步骤的过程,例如,要求用户填写联系人详细信息,因此对上面定义的HTTP POST消息的初始响应可能不是注册过程的结束,即使HTTP响应具有200 OK状态。这给UA带来了一个问题,因为在注册过程中(例如,在处理中间页面时),UA还不知道CPK是否适合该web源。

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


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

图3为Hobareg header字段中允许的值提供了ABNF定义。请注意,这些字段(以及标题字段名)不区分大小写。[RFC7231]第8.3.1节要求记录此新标题字段的以下详细信息:

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 Hobareg头字段中只允许有一个值。如果遇到多个(列表)或任何其他ABNF无效值,应解释为与“reginwork”相同。

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

o Hobareg标头字段只能在HTTP响应中使用。

o Since Hobareg is only meant for responses, it ought not appear in requests.

o 因为Hobareg只用于响应,所以它不应该出现在请求中。

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 HTTP响应代码确实会影响Hobareg的解释。只有在2xx响应中看到regok值时,才认为注册成功。4xx和其他错误意味着注册失败,无论看到的Hobareg值是多少。请求方法对Hobareg的解释没有影响。

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

o 中介机构从不插入、删除或修改Hobareg头字段。

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

o 作为仅响应标头字段,在Vary响应标头字段中列出Hobareg是不合适的。

o Hobareg is allowed in trailers.

o 允许在拖车中使用Hobareg。

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

o 作为仅响应标头字段,Hobareg将不会在重定向中保留。

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.

o Hobareg本身很少披露安全或隐私敏感信息。如果攻击者能够以某种方式检测到正在添加Hobareg头字段,那么该攻击者将知道UA正在注册,这可能非常重要。然而,无论是否使用TLS,UA和服务器之间的消息集在许多情况下都可能会公开此信息。然而,使用TLS仍然是一个好计划。

6.2. Associating Additional Keys to an Existing Account
6.2. 将其他密钥关联到现有帐户

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
6.2.1. 移动私钥

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.

一个用户通常拥有多个UAs,并希望所有这些UAs都能够对单个帐户进行身份验证。允许具有现有帐户的用户能够在第二设备上认证的一种方法是将私钥和公钥以及源信息从第一设备安全地传输到第二设备。如果采用这种方法,那么对HOBA http或HOBA js没有影响,因此这是一个纯粹的UA实现问题,没有进一步讨论。

6.2.2. Human-Memorable One-Time Password (Don't Do This One)
6.2.2. 人工记忆一次性密码(不要使用此密码)

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
6.2.3. 带外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
6.3. 注销

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

用户可以告诉服务器它希望注销。使用HOBA http,这是通过向相关站点上的URL“.well-known/HOBA/logout”发送一条经过HOBA验证的POST消息来完成的。UA还应删除与会话相关联的会话cookie,以便用户的状态不再为“已登录”

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
6.4. 接受新的挑战

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.


7. Mandatory-to-Implement Algorithms
7. 强制执行算法

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
8. 安全考虑

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.

当max age参数不为零时,HOBA签名的属性类似于相关秒数的承载令牌:它可以在服务器选择的持续时间内重播。类似地,对于HOBA js,签名可能是可重放的,具体取决于具体的实现。因此,[RFC6750]的安全注意事项适用于可以重放HOBA签名的任何情况。在这种情况下,服务器管理员可以将max age设置为可接受的最小值,通常只需几秒钟。似乎没有理由将最大年龄设定在几分钟以上;随着设备性能的提高,该值也会随着时间的推移而降低。管理员很可能希望将“最大年龄”设置为对最慢的签名设备而言不太短的值,这对该站点非常重要。

8.1. Privacy Considerations
8.1. 隐私考虑

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.


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.

UAs应该为用户提供一种管理其CPK的方法。理想情况下,用户可以在删除其他站点信息(如cookie或非HOBA HTML5 localStorage)的同时维护其站点的HOBA详细信息。然而,由于这可能很复杂,并且适当的用户界面违反直觉,我们预计实现HOBA的UAs可能会将HOBA信息视为更多的站点数据,如果用户选择“忘记”该站点,这些数据将消失。

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.

如果可能的话,实现应该鼓励使用除相关用户之外没有个人识别的设备标识符值;例如,“Alice的手机”可能会被选中,并且在某种程度上具有识别性,但“Alice的手机:UUID 1234-5567-89abc-def0”将是一个非常糟糕的选择。

8.2. localStorage Security for JavaScript
8.2. 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.

localStorage的使用(可能与HOBA js的非WebCrypto实现一起)无疑会引起关注。localStorage使用与方案、域和端口定义localStorage实例相同的源模型。除此之外,任何执行的代码都可以访问私钥材料。特别值得关注的是跨站点脚本(XSS)攻击,可以想象,这种攻击会获取密钥材料,并使用它在攻击者的控制下创建UAs。实际上,XSS攻击是毁灭性的,因为它们可以而且确实会窃取信用卡信息、密码、执行非法行为等。我们引入的独特威胁并不明显,明文密码还没有受到影响。

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


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
8.3. 一个用户代理上有多个帐户

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


9. IANA Considerations
9. IANA考虑

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
9.1. HOBA认证方案

A new scheme has been registered in the HTTP Authentication Scheme Registry as follows:


Authentication Scheme Name: HOBA


Reference: Section 3 of RFC 7486

参考:RFC 7486第3节

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
9.2. .众所周知的URI

A new .well-known URI has been registered in the Well-Known URIs registry as described below.

一个新的.well-known URI已在众所周知的URI注册表中注册,如下所述。

URI Suffix: hoba


Change Controller: IETF


Reference: Section 6 of RFC 7486

参考:RFC 7486第6节

Related Information: N/A


9.3. Algorithm Names
9.3. 算法名称

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
   Number       Meaning                         Reference
   -----------  ------------------------------  ------------
   0            RSA-SHA256                      RFC 7486
   1            RSA-SHA1                        RFC 7486

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
9.4. 密钥标识符类型

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
   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
9.5. 设备标识符类型

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


9.6. Hobareg HTTP Header Field
9.6. Hobareg HTTP头字段

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)

协议:http(RFC 7230)

Status: experimental


Author/Change controller: IETF


Reference: Section 6.1.1 of RFC 7486

参考:RFC 7486第6.1.1节

Related information: N/A


10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <>.

[RFC20]Cerf,V.,“网络交换的ASCII格式”,STD 80,RFC 20,1969年10月<>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月<>.

[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <>.

[RFC3447]Jonsson,J.和B.Kaliski,“公钥密码标准(PKCS)#1:RSA密码规范版本2.1”,RFC 3447,2003年2月<>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <>.

[RFC3986]Berners Lee,T.,Fielding,R.,和L.Masinter,“统一资源标识符(URI):通用语法”,STD 66,RFC 3986,2005年1月<>.

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


[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <>.

[RFC5234]Crocker,D.,Ed.和P.Overell,“语法规范的扩充BNF:ABNF”,STD 68,RFC 5234,2008年1月<>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <>.

[RFC5246]Dierks,T.和E.Rescorla,“传输层安全(TLS)协议版本1.2”,RFC 5246,2008年8月<>.

[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010, <>.

[RFC5785]诺丁汉,M.和E.Hammer Lahav,“定义众所周知的统一资源标识符(URI)”,RFC 57852010年4月<>.

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

[RFC6454]Barth,A.,“网络起源概念”,RFC 64542011年12月<>.

[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, <>.

[RFC6698]Hoffman,P.和J.Schlyter,“基于DNS的命名实体认证(DANE)传输层安全(TLS)协议:TLSA”,RFC 6698,2012年8月<>.

[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012, <>.

[RFC6750]Jones,M.和D.Hardt,“OAuth 2.0授权框架:承载令牌使用”,RFC 67502012年10月<>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, <>.

[RFC7231]Fielding,R.,Ed.和J.Reschke,Ed.,“超文本传输协议(HTTP/1.1):语义和内容”,RFC 72312014年6月<>.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, <>.

[RFC7235]Fielding,R.,Ed.和J.Reschke,Ed.,“超文本传输协议(HTTP/1.1):认证”,RFC 7235,2014年6月<>.

[SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012.

[SHS]NIST,“安全哈希标准(SHS)”,FIPS PUB 180-42012年3月。

10.2. Informative References
10.2. 资料性引用

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

[RFC4086]Eastlake 3rd,D.,Schiller,J.,和S.Crocker,“安全的随机性要求”,BCP 106,RFC 40862005年6月<>.

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


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

[RFC6376]Crocker,D.,Ed.,Hansen,T.,Ed.,和M.Kucherawy,Ed.,“域密钥识别邮件(DKIM)签名”,STD 76,RFC 63762011年9月<>.

[ThreatReport] Sophos, "Security Threat Report 2013", January 2013, < sophossecuritythreatreport2013.pdf>.

【威胁报告】Sophos,“2013年安全威胁报告”,2013年1月< sophossecuritythreatreport2013.pdf>。

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.


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.

以下值显示了到源站的HOBA http身份验证示例”". 已添加回车,需要删除回车以验证示例。

Public Key:


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

Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w


   Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=
   Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=

Signature algorithm: RSA-SHA256 ("0")


Nonce: Pm3yUW-sW5Q




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

2.一个中国政府对一个中国政府提出了一个中国政府对一个中国政府对一个中国政府在一个中国政府对一个中国政府在一个中国政府对一个中国政府对一个中国政府对一个中国政府的4个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府对一个中国政府的一个中国政府对一个中国政府的一个中国政府对中国政府对中国政府的一个中国政府对一个中国政府在一个中国政府对一个中国政府一个中国政府一个中国政府对中国政府一个中国政府对中国政府的政府的政策的一个中国政府一个中国政府在一个中国政府对中国政府对中国政府的政策的政策的承诺承诺,在一个中国政府在一个中国政府对中国政府在一个中国政府对中国政府对中国政府的政府的政府的政策的承诺在在中国政府的承诺BK34EUWG9KI 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"




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
   Phone: +353-1-896-2354

Paul Hoffman VPN Consortium



Michael Thomas Phresheez