draft-ietf-httpauth-hoba-07.txt   draft-ietf-httpauth-hoba-08.txt 
Network Working Group S. Farrell Network Working Group S. Farrell
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Experimental P. Hoffman Intended status: Experimental P. Hoffman
Expires: June 12, 2015 VPN Consortium Expires: June 29, 2015 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
December 9, 2014 December 26, 2014
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-07 draft-ietf-httpauth-hoba-08
Abstract Abstract
HTTP Origin-Bound Authentication (HOBA) is a digital signature based HTTP Origin-Bound Authentication (HOBA) is a digital signature based
design for an HTTP authentication method. The design can also be design for an HTTP authentication method. The design can also be
used in Javascript-based authentication embedded in HTML. HOBA is an used in Javascript-based authentication embedded in HTML. HOBA is an
alternative to HTTP authentication schemes that require passwords and alternative to HTTP authentication schemes that require passwords and
therefore avoids all problems related to passwords, such as leakage therefore avoids all problems related to passwords, such as leakage
of server-side password databases. of server-side password databases.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 12, 2015. This Internet-Draft will expire on June 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 8
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 9 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 9
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 10
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 10 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 10
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 13 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 13
6.2. Associating Additional Keys to an Exiting Account . . . . 14 6.2. Associating Additional Keys to an Existing Account . . . 14
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 15 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 15
6.2.2. Human memorable one time password (don't do this one) 15 6.2.2. Human memorable one time password (don't do this one) 15
6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 15 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 16
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 16 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 16
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. Privacy considerations . . . . . . . . . . . . . . . . . 17 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 17
8.2. localStorage Security for Javascript . . . . . . . . . . 17 8.2. localStorage Security for Javascript . . . . . . . . . . 17
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 18
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 19
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 19 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 19
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 19 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 19 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 20
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20
9.6. Hobareg HTTP Header . . . . . . . . . . . . . . . . . . . 20 9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 21
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 23 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 23
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
HTTP Origin-Bound Authentication (HOBA) is an authentication design HTTP Origin-Bound Authentication (HOBA) is an authentication design
that can be used as an HTTP authentication scheme [RFC7235] and for that can be used as an HTTP authentication scheme [RFC7235] and for
Javascript-based authentication embedded in HTML. The main goal of Javascript-based authentication embedded in HTML. The main goal of
HOBA is to offer an easy-to-implement authentication scheme that is HOBA is to offer an easy-to-implement authentication scheme that is
skipping to change at page 3, line 27 skipping to change at page 3, line 27
framework for such schemes [RFC7235]. As a JavaScript design, HOBA framework for such schemes [RFC7235]. As a JavaScript design, HOBA
demonstrates a way for clients and servers to interact using the same demonstrates a way for clients and servers to interact using the same
credentials that are used by the HTTP authentication scheme. credentials that are used by the HTTP authentication scheme.
Current username/password authentication methods such as HTTP Basic, Current username/password authentication methods such as HTTP Basic,
HTTP Digest, and web forms have been in use for many years but are HTTP Digest, and web forms have been in use for many years but are
susceptible to theft of server-side password databases. Instead of susceptible to theft of server-side password databases. Instead of
passwords, HOBA uses digital signatures as an authentication passwords, HOBA uses digital signatures as an authentication
mechanism. HOBA also adds useful features such as credential mechanism. HOBA also adds useful features such as credential
management and session logout. In HOBA, the client creates a new management and session logout. In HOBA, the client creates a new
public-private key pair for each host ("web-origin" [RFC6454]) to public-private key pair for each host ("web origin" [RFC6454]) to
which it authenticates. These keys are used in HOBA for HTTP clients which it authenticates. These keys are used in HOBA for HTTP clients
to authenticate themselves to servers in the HTTP protocol or in a to authenticate themselves to servers in the HTTP protocol or in a
Javascript authentication program. Javascript authentication program.
HOBA session management is identical to username/password session HOBA session management is identical to username/password session
management, with a server-side session management tool or script management, with a server-side session management tool or script
inserting a session cookie into the output to the browser. HOBA inserting a session cookie [RFC6265] into the output to the browser.
still requires TLS to prevent session cookie hijacking. Use of 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 HOBA keys are "bare keys", so there is no need for the semantic
overhead of PKIX certificates, particularly with respect to naming overhead of X.509 public key certificates, particularly with respect
and trust anchors. The client public key ("CPK") structures in HOBA to naming and trust anchors. The client public key ("CPK")
do not have any publicly-visible identifier for the user who structures in HOBA do not have any publicly-visible identifier for
possesses the corresponding private key, nor the web-origin with the user who possesses the corresponding private key, nor the web-
which the client is using the CPK. origin with which the client is using the CPK.
HOBA also defines some services that are required for modern HTTP HOBA also defines some services that are needed for modern HTTP
authentication: authentication:
o Servers can bind a CPK with an identifier, such as an account o Servers can bind a CPK with an identifier, such as an account
name. Servers using HOBA define their own policies for binding name. Servers using HOBA define their own policies for binding
CPKs with accounts during account registration. CPKs with accounts during account registration.
o Users are likely to use more than one device or user agent (UA) 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 for the same HTTP based service, so HOBA gives a way to associate
more than one CPK to the same account, but without having to more than one CPK to the same account, but without having to
register for each separately. register for each separately.
skipping to change at page 4, line 48 skipping to change at page 4, line 51
any password based authentication scheme. any password based authentication scheme.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] notation of [RFC5234].
Account: The term "account" is (loosely) used to refer to whatever Account: The term "account" is (loosely) used to refer to whatever
data structure(s) the server maintains that are associated with an data structure(s) the server maintains that are associated with an
identity. That will contain of at least one CPK and a web-origin; it identity. That will contain of at least one CPK and a web-origin; it
will also optionally include an HTTP "realm" as defined in the HTTP will also optionally include an HTTP "realm" as defined in the HTTP
authentication specification. [RFC7235]. It might also involve many authentication specification [RFC7235]. It might also involve many
other non-standard pieces of data that the server accumulates as part other non-standard pieces of data that the server accumulates as part
of account creation processes. An account may have many CPKs that of account creation processes. An account may have many CPKs that
are considered equivalent in terms of being usable for are considered equivalent in terms of being usable for
authentication, but the meaning of "equivalent" is really up to the authentication, but the meaning of "equivalent" is really up to the
server and is not defined here. server and is not defined here.
Client public key ("CPK"): A CPK is the public key and associated Client public key ("CPK"): A CPK is the public key and associated
cryptographic parameters needed for a server to validate a signature. cryptographic parameters needed for a server to validate a signature.
HOBA-http: We use this term when describing something that is HOBA-http: We use this term when describing something that is
skipping to change at page 5, line 48 skipping to change at page 5, line 51
client marshals an HOBA to-be-signed (TBS) blob that includes a client marshals an HOBA to-be-signed (TBS) blob that includes a
client generated nonce, the web-origin, the realm, an identifier for client generated nonce, the web-origin, the realm, an identifier for
the CPK and the challenge string; and signs that blob with the the CPK and the challenge string; and signs that blob with the
private key corresponding to the CPK for that web-origin. The private key corresponding to the CPK for that web-origin. The
formatting chosen for this TBS blob is chosen so as to make server- formatting chosen for this TBS blob is chosen so as to make server-
side signature verification as simple as possible for a wide range of side signature verification as simple as possible for a wide range of
current server tooling. current server tooling.
Figure 1 specifies the ABNF for the signature input. The term Figure 1 specifies the ABNF for the signature input. The term
"unreserved" means that the field does not have a specific format "unreserved" means that the field does not have a specific format
defined. defined and allows the characters specified in Section 2.3 of
[RFC3986].
HOBA-TBS = len ":" nonce HOBA-TBS = len ":" nonce
len ":" alg len ":" alg
len ":" origin len ":" origin
len ":" [ realm ] len ":" [ realm ]
len ":" kid len ":" kid
len ":" challenge len ":" challenge
len = 1*DIGIT len = 1*DIGIT
nonce = 1*base64urlchars nonce = 1*base64urlchars
alg = 1*2DIGIT alg = 1*2DIGIT
origin = scheme "://" authority ":" port origin = scheme "://" authority ":" port
; scheme etc are from RFC 3986
realm = unreserved realm = unreserved
; realm is to be treated as in Section 2.2 of RFC 7235
kid = 1*base64urlchars kid = 1*base64urlchars
challenge = 1*base64urlchars challenge = 1*base64urlchars
; Characters for Base64URL encoding from Table 2 of RFC 4648 ; Characters for Base64URL encoding from Table 2 of RFC 4648
; all of which are US-ASCII (see RFC 20)
base64urlchars = %x30-39 ; Digits base64urlchars = %x30-39 ; Digits
/ %x41-5A ; Uppercase letters / %x41-5A ; Uppercase letters
/ %x61-7A ; Lowercase letters / %x61-7A ; Lowercase letters
/ "-" / "_" / "=" ; Special characters / "-" / "_" / "=" ; Special characters
Figure 1: To-be-signed data for HOBA Figure 1: To-be-signed data for HOBA
The fields above contain the following: The fields above contain the following:
o len: Each field is preceeded by the number of octets of the o len: Each field is preceeded by the number of octets of the
skipping to change at page 7, line 16 skipping to change at page 7, line 19
defined in [RFC7235]. If no realm is specified for this defined in [RFC7235]. If no realm is specified for this
authentication then this is absent, but is preceeded by a length authentication then this is absent, but is preceeded by a length
of zero ("0:"). Recall both sides know when this needs to be of zero ("0:"). Recall both sides know when this needs to be
there independent of the encoding via a zero length. there independent of the encoding via a zero length.
o kid: is a key identifier - this MUST be a base64url encoded value o kid: is a key identifier - this MUST be a base64url encoded value
that is presented to the server in the HOBA client result (see that is presented to the server in the HOBA client result (see
below). below).
o challenge: MUST be a base64url encoded challenge value that the o challenge: MUST be a base64url encoded challenge value that the
server chose to send to the client 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) an at least 128-bit long random
string.
The HOBA-TBS string is the input to the client's signing process, but 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 is not itself sent over the network since some fields are already
inherent in the HTTP exchange. The challenge however is sent over inherent in the HTTP exchange. The challenge however is sent over
the network so as to make it simpler for a server to be stateless. the network so as to reduce the amount of reduce the amount of state
(One form of stateless challenge might be a ciphertext that the that needs to be maintained by servers. (One form of stateless
server decrypts and checks, but that is an implementation detail.) challenge might be a ciphertext that the server decrypts and checks,
The value that is sent over the network by the UA is the HOBA "client but that is an implementation detail.) The value that is sent over
result" which we now define. 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 The HOBA "client result" is a dot-separated string that includes the
signature and is sent in the HTTP Authorized header field value using signature and is sent in the HTTP Authorizaion header field value
the value syntax defined in Figure 2. The "sig" value is the using the value syntax defined in Figure 2. The "sig" value is the
base64url encoded version of the binary output of the signing base64url encoded version of the binary output of the signing
process. The kid, challenge and nonce are as defined above and are process. The kid, challenge and nonce are as defined above and are
also base64url encoded. also base64url encoded.
HOBA-RES = kid "." challenge "." nonce "." sig HOBA-RES = kid "." challenge "." nonce "." sig
sig = 1*base64urlchars sig = 1*base64urlchars
Figure 2: HOBA Client Result value Figure 2: HOBA Client Result value
The HOBA scheme is far from new, for example, the basic idea is The HOBA scheme is far from new, for example, the basic idea is
skipping to change at page 8, line 17 skipping to change at page 8, line 25
o The "challenge" attribute MUST be included. The challenge is the o The "challenge" attribute MUST be included. The challenge is the
string made up of the base64url encoded octets that the server string made up of the base64url encoded octets that the server
wants the client to sign in its response. The challenge MUST be wants the client to sign in its response. The challenge MUST be
unique for every HTTP 401 response in order to prevent replay unique for every HTTP 401 response in order to prevent replay
attacks from passive observers. attacks from passive observers.
o A "max-age" attribute MUST be included that specifies the number o A "max-age" attribute MUST be included that specifies the number
of seconds from the time the HTTP response is emitted for which of seconds from the time the HTTP response is emitted for which
responses to this challenge can be accepted for example "max-age: responses to this challenge can be accepted for example "max-age:
10" would indicatge ten seconds. If max-age is set to zero, then 10" would indicate ten seconds. If max-age is set to zero, then
that means that only one signature will be accepted for this that means that only one signature will be accepted for this
challenge. challenge.
o A "realm" attribute MAY be included to indicate the scope of o A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
The "realm" attribute MUST NOT appear more than once. The "realm" attribute MUST NOT appear more than once.
When the "client response" is created, the UA encodes the HOBA When the "client response" is created, the UA encodes the HOBA
client-result and returns that in the Authorization header. The client-result and returns that in the Authorization header. The
client-result is a string matching the HOBA-RES production in Figure client-result is a string matching the HOBA-RES production in Figure
2 as an auth-param with the name "result". 2 as an auth-param with the name "result".
The server MUST check the cryptographic correctness of the signature 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 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 the server cannot do that, or if the signature fails cryptographic
checks, then validation has failed. The server can use any checks, then validation has failed. The server can use any
additional mechanisms to validate the signature. If the validation additional mechanisms to validate the signature. If the validation
fails, or if the server chooses reject the signature for any reason fails, or if the server chooses reject the signature for any reason
whatsoever, the server aborts the transaction via a 401 Unauthorized whatsoever, the server fails the request with a 401 Unauthorized HTTP
HTTP response. 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- Note that a HOBA signature is good for however long a non-zero max-
age attribute allows. This means that replay is possible within the age parameter allows. This means that replay is possible within the
time window specified by the "max-age" value chosen by the server. 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 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 choose) and MAY react to such replays by responding with a second (or
subsequent) 401-status HTTP response containing a new challenge. subsequent) 401-status HTTP response containing a new challenge.
UAs MAY optimise their use of challenges by pre-fetching a challenge UAs MAY optimise their use of challenges by pre-fetching a challenge
value, for example after (max-age)/2 seconds have elapsed, using the value, for example after (max-age)/2 seconds have elapsed, using the
".well-known/hoba/getchal" scheme described later in this document. ".well-known/hoba/getchal" scheme described later in this document.
This also allows for pre-calculation of HOBA signatures, if that is This also allows for pre-calculation of HOBA signatures, if that is
required in order to produce a responsive user interface. required in order to produce a responsive user interface.
skipping to change at page 10, line 22 skipping to change at page 10, line 34
asks for HOBA-based authentication, and the client authenticates by asks for HOBA-based authentication, and the client authenticates by
signing a blob of information as described in the previous sections. signing a blob of information as described in the previous sections.
5.3. Authentication Phase 5.3. Authentication Phase
The authentication phase is completely dependent on the policies and The authentication phase is completely dependent on the policies and
practices of the server. That is, this phase involves no practices of the server. That is, this phase involves no
standardized protocol in HOBA-http; in HOBA-js, there is no suggested standardized protocol in HOBA-http; in HOBA-js, there is no suggested
interaction template. interaction template.
In the authentication phase, the server extracts the CPK from the In the authentication phase, the server uses the key identifier (kid)
signing phase and decides if it recognizes the CPK. If the server to determine the CPK from the signing phase and decides if it
recognizes the CPK, the server may finish the client authentication recognizes the CPK. If the server recognizes the CPK, the server may
process. finish the client authentication process.
If this stage of the process involves additional information for If this stage of the process involves additional information for
authentication, such as asking the user which account she wants to 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), 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 server can prompt the user for account identifying information or
the user could choose based on HTML offered by the server before the the user could choose based on HTML offered by the server before the
401 is triggered. None of this is standardized: it all follows the 401 response is triggered. None of this is standardized: it all
server's security policy and session flow. At the end of this, the follows the server's security policy and session flow. At the end of
server probably assigns or updates a session cookie for the client. this, the server probably assigns or updates a session cookie for the
client.
During the authentication phase, if the server does not recognize the During the authentication phase, if the server cannot determine the
CPK, it could use HTML and JavaScript to ask the user if they are correct CPK, it could use HTML and JavaScript to ask the user if they
really a new user or want to associate this new CPK with another CPK. are really a new user or want to associate this new CPK with another
The server can then use some out-of-band method (such as a CPK. The server can then use some out-of-band method (such as a
confirmation email round trip, SMS, or an UA that is already confirmation email round trip, SMS, or an UA that is already
enrolled) to verify that the "new" user is the same as the already- enrolled) to verify that the "new" user is the same as the already-
enrolled one. Thus, logging in on a new user agent is identical to enrolled one. Thus, logging in on a new user agent is identical to
logging in with an existing account. logging in with an existing account.
If the server does not recognize the CPK the server might send the If the server does not recognize the CPK the server might send the
client through a either a join or login-new-UA (see below) process. client through a either a join or login-new-UA (see below) process.
This process is completely up to the server, and probably entails This process is completely up to the server, and probably entails
using HTML and JavaScript to ask the user some questions in order to 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. assess whether or not the server wants to give the client an account.
skipping to change at page 11, line 38 skipping to change at page 11, line 50
HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for
performing many tasks: "https://www.example.com/.well-known/hoba". performing many tasks: "https://www.example.com/.well-known/hoba".
These URLs are based on the name of the host that the HTTP client is These URLs are based on the name of the host that the HTTP client is
accessing. accessing.
There are many use cases for these URLs to redirect to other URLs: a 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 site that does registration through a federated site, a site that
only does registration under HTTPS, and so on. Like any HTTP client, only does registration under HTTPS, and so on. Like any HTTP client,
HOBA-http clients have to be able to handle redirection of these HOBA-http clients have to be able to handle redirection of these
URLs. However, as that would potentially cause security issues when requests. However, as that would potentially cause security issues
a re-direct brings the client to a different web origin, servers when a re-direct brings the client to a different web origin, servers
implementing HOBA-http SHOULD NOT re-direct to a different web origin implementing HOBA-http SHOULD NOT re-direct to a different web origin
from below .well-known/hoba URLs. The above is considered sufficient from below .well-known/hoba URLs. The above is considered sufficient
to allow experimentation with HOBA, but if at some point HOBA is to allow experimentation with HOBA, but if at some point HOBA is
placed on the standards track then a full analysis of off-origin re- placed on the standards track then a full analysis of off-origin re-
directions would need to be documented. directions would need to be documented.
6.1. Registration 6.1. Registration
Normally, a registration (also called "joining") is expected to Normally, a registration (also called "joining") is expected to
happen after a UA receives a WWW-Authenticate for a web-origin and happen after a UA receives a 401 response for a web-origin and realm
realm (for HOBA-http) or on demand (for HOBA-js) for which it has no (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 associated CPK. The process of registration for a HOBA account on a
server is relatively light-weight. The UA generates a new key pair, server is relatively light-weight. The UA generates a new key pair,
and associates it with the web-origin/realm in question. 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 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 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 server did not wish for that outcome, then it ought to use the same
or no realm. or no realm.
The registration message for HOBA-http is sent as a POST message to 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- the URL ".well-known/hoba/register" with an HTML form (x-www-form-
encoded) described below; The registration message for HOBA-js can be encoded) (see http://www.w3.org/TR/2014/REC-html5-20141028/forms.html
in any format specified by the server, but it could be the same as #url-encoded-form-data) described below; The registration message for
the one described here for HOBA-http. It is up to the server to HOBA-js can be in any format specified by the server, but it could be
decide what kind of user interaction is required before the account the same as the one described here for HOBA-http. It is up to the
is finally set up. When the server's chosen registration flow is server to decide what kind of user interaction is required before the
completed successfully the server MUST add a Hobareg HTTP header (see account is finally set up. When the server's chosen registration
Section 6.1.1) to the HTTP response message that completes the flow is completed successfully the server MUST add a Hobareg HTTP
registration flow. header (see Section 6.1.1) to the HTTP response message that
completes the registration flow.
The registration message sent to server has one mandatory field (pub) The registration message sent to server has one mandatory field (pub)
and some optional fields that allow the UA to specify the type and 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. value of key and device identifiers that the UA wishes to use.
o pub: is a mandatory field containing the PEM formatted public key o pub: is a mandatory field containing the PEM formatted public key
of the client. See Appendix C of [RFC6376] for an example of how of the client. See Appendix C of [RFC6376] for an example of how
to generate this key format. to generate this key format.
o kidtype: contains the type of key identifier, this is a numeric o kidtype: contains the type of key identifier, this is a numeric
skipping to change at page 13, line 24 skipping to change at page 13, line 33
6.1.1. Hobareg Definition 6.1.1. Hobareg Definition
Since registration can often be a multi-step process, e.g. requiring 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 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 POST message defined above may not be the end of the registration
process even though the HTTP response has a 200 OK status. This process even though the HTTP response has a 200 OK status. This
creates an issue for the UA since, during the registration process creates an issue for the UA since, during the registration process
(e.g., while dealing with interstitial pages), the UA doesn't yet (e.g., while dealing with interstitial pages), the UA doesn't yet
know whether the CPK is good for that web origin or not. know whether the CPK is good for that web origin or not.
For this reason the server MUST add a header to the response message For this reason the server MUST add a header field to the response
when the registration has succeded to indicate the new state. The message when the registration has succeded to indicate the new state.
header to be used is "Hobareg" and the value when registration has The header to be used is "Hobareg" and the value when registration
succeeded is to be "regok". When registration is inwork (e.g. on an has succeeded is to be "regok". When registration is in an
HTTP response for an interstitial page) the server MAY add this intermediate state (e.g. on an HTTP response for an interstitial
header with a value of "reginwork". See Section 9.6 for the relevant page) the server MAY add this header with a value of "reginwork".
IANA registration of this header field. See Section 9.6 for the relevant IANA registration of this header
field.
For interstitial pages, the client MAY include a HOBA Authorization For interstitial pages, the client MAY include a HOBA Authorization
header. This is not considered a MUST as that might needlessly header. This is not considered a MUST as that might needlessly
complicate client implementations but is noted here in case a server complicate client implementations but is noted here in case a server
implementer assumes that all registration messages contain a HOBA implementer assumes that all registration messages contain a HOBA
Authorization header. Authorization header.
Hobareg-val = "regok" / "inwork" Hobareg-val = "regok" / "reginwork"
Figure 3: Hobareg Header Field Definition Figure 3: Hobareg Header Field Definition
Figure 3 provides an ABNF definition for the values allowed in the Figure 3 provides an ABNF definition for the values allowed in the
Hobareg header field. Note that these (and the header field name) Hobareg header field. Note that these (and the header field name)
are case insensitive. Section 8.3.1 of [RFC7231] calls for are case insensitive. Section 8.3.1 of [RFC7231] calls for
documenting the following details for this new header field: documenting the following details for this new header field:
o Only one single value is allowed in a Hobareg header field. o Only one single value is allowed in a Hobareg header field.
Should more than one (a list) be encountered, that should be Should more than one (a list) be encountered or any other ANBF-
interpreted as being the same as "inwork." 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 The Hobareg header field can only be used in HTTP responses.
o Since Hobareg is only meant for responses it ought not appear in a o Since Hobareg is only meant for responses it ought not appear in
PUT request. requests.
o The HTTP response code does affect the interpretation of Hobareg. o The HTTP response code does affect the interpretation of Hobareg.
Registration is only considered to have succeeded if the regok Registration is only considered to have succeeded if the regok
value is seen in a 2xx response. 4xx and other errors means that value is seen in a 2xx response. 4xx and other errors means that
registration has failed regardless of the value of Hobareg seen. registration has failed regardless of the value of Hobareg seen.
The request method has no influence on the interpretation of The request method has no influence on the interpretation of
Hobareg. Hobareg.
o Intermediaries should never insert, delete or modify a Hobareg o Intermediaries never insert, delete or modify a Hobareg header
header field. field.
o As a response-only header field, it is not appropriate to list a o As a response-only header field, it is not appropriate to list a
Hobareg in a Vary response header field. Hobareg in a Vary response header field.
o Hobareg is allowed in trailers. o Hobareg is allowed in trailers.
o As a response-only header field, Hobareg will not be preserved o As a response-only header field, Hobareg will not be preserved
across re-directs. across re-directs.
o Hobareg itself discloses little security or privacy sensitive o Hobareg itself discloses little security or privacy sensitive
information. If an attacker can somehow detect that a Hobareg information. If an attacker can somehow detect that a Hobareg
header field is being added, then that attacker would know that header field is being added, then that attacker would know that
the UA is in the process of registration which could be the UA is in the process of registration which could be
significant. However, it is likely that the set of messages significant. However, it is likely that the set of messages
between the UA and server would expose this information in many between the UA and server would expose this information in many
cases, regardless of whether or not TLS is used. Using TLS is cases, regardless of whether or not TLS is used. Using TLS is
still however a good plan. still however a good plan.
6.2. Associating Additional Keys to an Exiting Account 6.2. Associating Additional Keys to an Existing Account
From the user perspective, the UA having a CPK for a web origin will 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 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 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 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 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 from the server perspective that turns into the question of how to
safely bind different CPKs to one account. In this section, we 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 describe some ways in which this can be done, as well as one way in
which this ought not be done. which this ought not be done.
skipping to change at page 16, line 8 skipping to change at page 16, line 20
later de-references on the newest UA. The user could e-mail that URL later de-references on the newest UA. The user could e-mail that URL
to herself for example, of the web server accessed at the first UA to herself for example, of the web server accessed at the first UA
could automatically do that. could automatically do that.
Such a URL SHOULD contain at least the equivalent of 128 bits of Such a URL SHOULD contain at least the equivalent of 128 bits of
randomness. randomness.
6.3. Logging Out 6.3. Logging Out
The user can tell the server it wishes to log out. With HOBA-http, The user can tell the server it wishes to log out. With HOBA-http,
this is done by sending any HOBA-authenticated HTTP message to the this is done by sending a HOBA-authenticated POST message to the URL
URL ".well-known/hoba/logout" on the site in question. The UA SHOULD ".well-known/hoba/logout" on the site in question. The UA SHOULD
also delete session cookies associated with the session so that the also delete session cookies associated with the session so that the
user's state is no longer "logged in." user's state is no longer "logged in."
The server MUST NOT allow TLS session resumption for any logged out The server MUST NOT allow TLS session resumption for any logged out
session. session.
The server SHOULD also revoke or delete any cookies associated with The server SHOULD also revoke or delete any cookies associated with
the session. the session.
6.4. Getting a Fresh Challenge 6.4. Getting a Fresh Challenge
The UA can get a "fresh" challenge from the server. In HOBA-http, it 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, sends a POST message to ".well-known/hoba/getchal". If successful,
the response response MUST include a fresh (base64url encoded) HOBA the response response MUST contain a fresh (base64url encoded) HOBA
challenge for this origin in the body of the response. challenge for this origin in the body of the response. Whitespace in
the response MUST be ignored.
7. Mandatory-to-Implement Algorithms 7. Mandatory-to-Implement Algorithms
RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus
lengths of at least 2048 bits SHOULD be used. RSA is defined in lengths of at least 2048 bits SHOULD be used. RSA is defined in
Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].
8. Security Considerations 8. Security Considerations
If key binding was server-selected then a bad actor could bind If key binding was server-selected then a bad actor could bind
skipping to change at page 16, line 52 skipping to change at page 17, line 18
process MUST be hard to guess, for whatever level of difficulty is 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 chosen by the server. The server SHOULD NOT allow a random guess to
reveal whether or not an account exists. reveal whether or not an account exists.
When the max-age parameter is not zero, then a HOBA signature has a 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 property that is like a bearer token for the relevant number of
seconds: it can be replayed for a server-selected duration. seconds: it can be replayed for a server-selected duration.
Similarly, for HOBA-js, signatures might be replayable depending on Similarly, for HOBA-js, signatures might be replayable depending on
the specific implementation. The security considerations of the specific implementation. The security considerations of
[RFC6750] therefore apply in any case where the HOBA signature can be [RFC6750] therefore apply in any case where the HOBA signature can be
replayed. Server administrators SHOULD set the max-age to the replayed. Server administrators can set the max-age to the minimum
minimum acceptable value in such cases, which would often be expected acceptable value in such cases, which would often be expected to be
to be just a few seconds. There seems to be no reason to ever set just a few seconds. There seems to be no reason to ever set the max-
the max-age more than a few minutes; the value ought also decrease age more than a few minutes; the value ought also decrease over time
over time as device capabilities improve. The administrator will as device capabilities improve. The administrator will most likely
most likely want to set the max-age to something that is not too slow want to set the max-age to something that is not too slow on the
on the slowest signing device that is significant for that site. slowest signing device that is significant for that site.
8.1. Privacy considerations 8.1. Privacy considerations
HOBA does impact to some extent on privacy and could be considered to HOBA does impact to some extent on privacy and could be considered to
represent a super-cookie to the server, or to any entity on the path 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 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 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 that will not vary for a given key. For this reason, and others, it
is strongly RECOMMENDED to only use HOBA over server-authenticated is strongly RECOMMENDED to only use HOBA over server-authenticated
TLS and to migrate web sites using HOBA to only use "https" URLs. 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 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 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 while at the same time deleting other site information such as
cookies or non-HOBA HTML5 LocalStorage. However, as this is likely cookies or non-HOBA HTML5 LocalStorage. However, as this is likely
to be complex and appropriate user interfaces counter intutitive, we to be complex and appropriate user interfaces counter intutitive, we
exepect that UAs that implement HOBA will likely treat HOBA expect that UAs that implement HOBA will likely treat HOBA
information as just some more site data, that would disappear should information as just some more site data, that would disappear should
the user choose to "forget" that site. the user choose to "forget" that site.
8.2. localStorage Security for Javascript 8.2. localStorage Security for Javascript
Our use of localStorage will undoubtedly be a cause for concern. The use of localStorage (likely with a non-WebCrypto implementation
localStorage uses the same-origin model which says that the scheme, of HOBA-js) will undoubtedly be a cause for concern. localStorage
domain and port define a localStorage instance. Beyond that, any uses the same-origin model which says that the scheme, domain and
code executing will have access to private keying material. Of port define a localStorage instance. Beyond that, any code executing
particular concern are XSS attacks which could conceivably take the will have access to private keying material. Of particular concern
keying material and use it to create UAs under the control of an are XSS attacks which could conceivably take the keying material and
attacker. But XSS attacks are in reality across the board use it to create UAs under the control of an attacker. But XSS
devastating since they can and do steal credit card information, attacks are in reality across the board devastating since they can
passwords, perform illicit acts, etc, etc. It's not clear that we and do steal credit card information, passwords, perform illicit
introduce unique threats from which clear text passwords don't acts, etc, etc. It's not clear that we introduce unique threats from
already suffer. which clear text passwords don't already suffer.
Another source of concern is local access to the keys. That is, if 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 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 through a javascript console, or find the file(s) that implement
localStorage on the host computer. Again it's not clear that we are 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 worse in this regard because the same attacker could get at browser
password files, etc too. One possible mitigation is to encrypt the password files, etc too. One possible mitigation is to encrypt the
keystore with a password/pin the user supplies. This may sound keystore with a password/pin the user supplies. This may sound
counter intuitive, but the object here is to keep passwords off of counter intuitive, but the object here is to keep passwords off of
servers to mitigate the multiplier effect of a large scale compromise servers to mitigate the multiplier effect of a large scale compromise
skipping to change at page 18, line 34 skipping to change at page 18, line 48
to one another. Multiple entries can be kept, one for each account, to one another. Multiple entries can be kept, one for each account,
and selected by the current user. This, of course, is fraught with and selected by the current user. This, of course, is fraught with
the possibility for abuse, since a server is potentially enrolling 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 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 responsible for the credential for that long. To alleviate this
problem, the user can request that the credential be erased from the problem, the user can request that the credential be erased from the
browser. Similarly, during the enrollment phase, a user could browser. Similarly, during the enrollment phase, a user could
request that the key pair only be kept for a certain amount of time, 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. or that it not be stored beyond the current browser session.
8.4. Injective Mapping for HOBA-TBS
The repeated length fields in the HOBA-TBS structure are present in
order to ensure that there is no possibility that the catenation of
different input values can cause confusion that might lead to an
attack, either against HOBA as specified here, or else an attack
against some other protocol that re-used this to-be-signed structure.
Those fields ensure that the mapping from input fields to the HOBA-
TBS string is an injective mapping.
9. IANA Considerations 9. IANA Considerations
IANA is requested to make registrations and create new registries as IANA is requested to make registrations and create new registries as
described below. described below.
For all new registries requested by this document, please place those
beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters"
category.
9.1. HOBA Authentication Scheme 9.1. HOBA Authentication Scheme
Please register a new scheme in the HTTP Authentication Scheme Please register a new scheme in the HTTP Authentication Scheme
Registry registry as follows: Registry registry as follows:
Authentication Scheme Name: HOBA Authentication Scheme Name: HOBA
Pointer to specification text: Section 3 of [[ this document ]] Pointer to specification text: Section 3 of [[ this document ]]
Notes (optional): The HOBA scheme can be used with either HTTP Notes (optional): The HOBA scheme can be used with either HTTP
servers or proxies. When used in response to a 407 Proxy servers or proxies. When used in response to a 407 Proxy
Authentication Required indication, the appropriate proxy Authentication Required indication, the appropriate proxy
authentication header fields are used instead, as with any other HTTP authentication header fields are used instead, as with any other HTTP
authentication scheme. authentication scheme.
9.2. .well-known URI 9.2. .well-known URI
Please register a new .well-known URI in the Well-Known URIs registry Please register a new .well-known URI in the Well-Known URIs registry
as described below. as described below.
skipping to change at page 19, line 39 skipping to change at page 20, line 21
Number Meaning Number Meaning
----------- -------------------------------------------- ----------- --------------------------------------------
0 RSA-SHA256 0 RSA-SHA256
1 RSA-SHA1 1 RSA-SHA1
RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are
defined in [SHS]. defined in [SHS].
For this registry the number column should contain a small positive For this registry the number column should contain a small positive
integer. integer. Following the ABNF above, the maximum value for this is
decimal 99.
9.4. Key Identifier Types 9.4. Key Identifier Types
Please create a new HOBA Key Identifier Types registry as follows, Please create a new HOBA Key Identifier Types registry as follows,
with the specification required rule for updates. with the specification required rule for updates.
Number Meaning Number Meaning
----------- -------------------------------------------- ----------- --------------------------------------------
0 a hashed public key [RFC6698] 0 a hashed public key [RFC6698]
1 a URI [RFC3986] 1 a URI [RFC3986]
skipping to change at page 20, line 24 skipping to change at page 21, line 4
integer. integer.
9.5. Device Identifier Types 9.5. Device Identifier Types
Please create a new HOBA Device Identifier Types registry as follows, Please create a new HOBA Device Identifier Types registry as follows,
with the specification required rule for updates. with the specification required rule for updates.
Number Meaning Number Meaning
----------- -------------------------------------------- ----------- --------------------------------------------
0 an unformatted string, at the user's/UA's whim 0 an unformatted string, at the user's/UA's whim
For this registry the number column should contain a small positive For this registry the number column should contain a small positive
integer. integer.
9.6. Hobareg HTTP Header 9.6. Hobareg HTTP Header Field
Please register a new identifier in the Permanent Message Header Please register a new identifier in the Permanent Message Header
Field Names registry as described below. Field Names registry as described below.
Header field name: Hobareg Header field name: Hobareg
Applicable protocol: HTTP (RFC 7230) Applicable protocol: HTTP (RFC 7230)
Status: Experimental Status: Experimental
skipping to change at page 21, line 22 skipping to change at page 21, line 49
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to [RFC6982] "this will allow reviewers and working groups According to [RFC6982] "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, by considering the running code as evidence of valuable running code, by considering the running code as evidence of valuable
experimentation and feedback that has made the implemented protocols experimentation and feedback that has made the implemented protocols
more mature. It is up to the individual working groups to use this more mature. It is up to the individual working groups to use this
information as they see fit". information as they see fit".
At the time of writing there are two known implementations. One done At the time of writing there are three known implementations.
by Stephen Farrell of HOBA-http and a HOBA-JS variant implements the
current (-04) version of HOBA and is available from https://hoba.ie/
which site also includes a demonstration of HOBA.
There is another implementation by Michael Thomas of an HOBA-JS One done by Stephen Farrell of HOBA-http and a HOBA-JS variant
variant. implements the current (-08) version of HOBA and is available from
https://hoba.ie/ which site also includes a demonstration of HOBA.
There is another implementation by Michael Thomas of an HOBA-JS
variant.
The most recent (Dec 2014) implementation is by Portugal Telecom
and is available from https://github.com/razevedo/hoba-
authentication
11. Acknowledgements 11. Acknowledgements
Thanks to the following for good comments received during the Thanks to the following for good comments received during the
preparation of this specification: Amos Jeffries, Benjamin Kaduk, preparation of this specification: David Black, Amos Jeffries,
Watson Ladd, Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Benjamin Kaduk, Watson Ladd, Matt Lepinski, Ilari Liusvaara, James
Melnikov, Yoav Nir, Mark Nottingham, Julian Reschke, Michael Manger, Alexey Melnikov, Yoav Nir, Mark Nottingham, Julian Reschke,
Richardson, Yaron Sheffer, and Michael Sweet. All errors and Michael Richardson, Yaron Sheffer, and Michael Sweet. All errors and
stupidities are of course the editors' fault. stupidities are of course the editors' fault.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, April Uniform Resource Identifiers (URIs)", RFC 5785, April
2010. 2010.
skipping to change at page 22, line 44 skipping to change at page 23, line 34
[SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST [SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST
Special Publications , March 2012. Special Publications , March 2012.
12.2. Informative References 12.2. Informative References
[MI93] Mitchell, and Thomas, "Standardising Authentication [MI93] Mitchell, and Thomas, "Standardising Authentication
Protocols Based on Public-Key Techniques.", Journal of Protocols Based on Public-Key Techniques.", Journal of
Computer Security 2 (1993): 23-36. , 1993. Computer Security 2 (1993): 23-36. , 1993.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", STD 76, RFC 6376, Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011. September 2011.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July Code: The Implementation Status Section", RFC 6982, July
2013. 2013.
[bonneau] Bonneau, , "The science of guessing: analyzing an [bonneau] Bonneau, , "The science of guessing: analyzing an
anonymized corpus of 70 million passwords.", Security and anonymized corpus of 70 million passwords.", IEEE
Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012. Symposium on Security and Privacy , 2012.
Appendix A. Problems with Passwords Appendix A. Problems with Passwords
By far the most common mechanism for web authentication is passwords By far the most common mechanism for web authentication is passwords
that can be remembered by the user, called "human-memorable that can be remembered by the user, called "human-memorable
passwords". There is plenty of good research on how users typically passwords". There is plenty of good research on how users typically
use human-memorable passwords (e.g. see [bonneau]), but some of the use human-memorable passwords (e.g. see [bonneau]), but some of the
highlights are that users typically try hard to reuse passwords on as 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 many web sites as possible, and that web sites often use either email
addresses or users' names as the identifier that goes with these addresses or users' names as the identifier that goes with these
passwords. passwords.
If an attacker gets access to the database of memorizable passwords, If an attacker gets access to the database of memorizable passwords,
that attacker can impersonate any of the users. Even if the breach that attacker can impersonate any of the users. Even if the breach
is discovered, the attacker can still impersonate users until every is discovered, the attacker can still impersonate users until every
password is changed. Even if all the passwords are changed or at password is changed. Even if all the passwords are changed or at
least made unusable, the attacker now possesses a list of likely least made unusable, the attacker now possesses a list of likely
username/password pairs that might exist on other sites. username/password pairs that might exist on other sites.
Using memorizable passwords on unencrypted channels also poses risks Using memorizable passwords on unencrypted channels also poses risks
to the users. If a web site uses either the HTTP Plain to the users. If a web site uses either the HTTP Basic
authentication method, or an HTML form that does no cryptographic authentication method, or an HTML form that does no cryptographic
protection of the password in transit, a passive attacker can see the protection of the password in transit, a passive attacker can see the
password and immediately impersonate the user. If a hash-based password and immediately impersonate the user. If a hash-based
authentication scheme such as HTTP Digest authentication is used, a authentication scheme such as HTTP Digest authentication is used, a
passive attacker still has a high chance of being able to determine passive attacker still has a high chance of being able to determine
the password using a dictionary of known passwords. the password using a dictionary of known passwords.
Note that passwords that are not human-memorable are still subject to Note that passwords that are not human-memorable are still subject to
database attack, though are of course unlikely to be re-used across database attack, though are of course unlikely to be re-used across
many systems. Similarly, database attacks of some form or other will many systems. Similarly, database attacks of some form or other will
work against any password based authentication scheme, regardless of work against any password based authentication scheme, regardless of
the crytographic protocol used. So for example, zero-knowledge or the crytographic protocol used. So for example, zero-knowledge or
PAKE schemes, though making use of elegant cryptographic protocols, PAKE schemes, though making use of elegant cryptographic protocols,
remain as vulnerable to what is clearly the most common exploit seen remain as vulnerable to what is clearly the most common exploit seen
when it comes to passwords. HOBA is however not vulnerable to when it comes to passwords. HOBA is however not vulnerable to
database theft. database theft.
The repeated length fields in the HOBA-TBS structure are present in
order to ensure that there is no possibility that the catenation of
different input values can cause confusion that might lead to an
attack, either against HOBA as specified here, or else an attack
against some other protocol that re-used this to-be-signed structure.
Appendix B. Example Appendix B. Example
The following values show an example of HOBA-http authentication to The following values show an example of HOBA-http authentication to
the origin https://example.com:443 Carriage-returns have been added the origin https://example.com:443. Carriage-returns have been added
and need to be removed to validate the example. and need to be removed to validate the example.
Public Key: Public Key:
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t 6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8 fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
 End of changes. 61 change blocks. 
131 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/