draft-ietf-httpauth-hoba-09.txt   draft-ietf-httpauth-hoba-10.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: July 3, 2015 VPN Consortium Expires: July 12, 2015 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
December 30, 2014 January 8, 2015
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-09 draft-ietf-httpauth-hoba-10
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 July 3, 2015. This Internet-Draft will expire on July 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 1.3. Step-by-step Overview of HOBA-http . . . . . . . . . . . 5
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 6
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 8 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 8
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 9 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 10
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 10 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 11
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 11
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 10 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 11
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 12
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 13 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 14
6.2. Associating Additional Keys to an Existing Account . . . 15 6.2. Associating Additional Keys to an Existing Account . . . 16
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 15 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 16
6.2.2. Human memorable one time password (don't do this one) 16 6.2.2. Human memorable one time password (don't do this one) 16
6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 16 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 17
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 17
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 17 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 17
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 17 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Privacy considerations . . . . . . . . . . . . . . . . . 17 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 18
8.2. localStorage Security for Javascript . . . . . . . . . . 18 8.2. localStorage Security for Javascript . . . . . . . . . . 19
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 19 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 20
8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 19 8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 19 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 21
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 20 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 21
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 21
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 20 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 22
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 21 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 22
9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 21 9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 22
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 24 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 25
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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
not based on passwords, but that can easily replace HTTP or HTML not based on passwords, but that can easily replace HTTP or HTML
forms-based password authentication. Deployment of HOBA can reduce forms-based password authentication. Deployment of HOBA can reduce
or eliminate password entries in databases, with potentially or eliminate password entries in databases, with potentially
significant security benefits. significant security benefits.
HOBA is an HTTP authentication mechanism that complies with the HOBA is an HTTP authentication mechanism that complies with the
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 in a challenge-response
mechanism. HOBA also adds useful features such as credential scheme as it's authentication mechanism. HOBA also adds useful
management and session logout. In HOBA, the client creates a new features such as credential management and session logout. In HOBA,
public-private key pair for each host ("web origin" [RFC6454]) to the client creates a new public-private key pair for each host ("web
which it authenticates. These keys are used in HOBA for HTTP clients origin" [RFC6454]) to which it authenticates. These keys are used in
to authenticate themselves to servers in the HTTP protocol or in a HOBA for HTTP clients to authenticate themselves to servers in the
Javascript authentication program. HTTP protocol or in a 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 [RFC6265] into the output to the browser. inserting a session cookie [RFC6265] into the output to the browser.
Use of TLS for the HTTP session is still necessary to prevent session Use of TLS for the HTTP session is still necessary to prevent session
cookie hijacking. 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 X.509 public key certificates, particularly with respect overhead of X.509 public key certificates, particularly with respect
to naming and trust anchors. The client public key ("CPK") to naming and trust anchors. The client public key ("CPK")
skipping to change at page 4, line 11 skipping to change at page 4, line 11
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.
o Logout features can be useful for UAs, so HOBA defines a way to o Logout features can be useful for UAs, so HOBA defines a way to
close a current HTTP "session", and also a way to close all close a current HTTP "session."
current sessions, even if more than one session is currently
active from different UAs for the same account.
o Digital signatures can be expensive to compute, so HOBA defines a o Digital signatures can be expensive to compute, so HOBA defines a
way for HTTP servers to indicate how long a given challenge value 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 is valid, and a way for UAs to fetch a fresh challenge at any
time. time.
Users are also likely to lose a private key, or the client's memory 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 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. user loses the computer or mobile device in which state is stored.
HOBA does not define a mechanism for deleting the association between HOBA does not define a mechanism for deleting the association between
an existing CPK and an account. Such a mechanism can be implemented an existing CPK and an account. Such a mechanism can be implemented
at the application layer. 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. Interfacing to Applications (Cookies)
HOBA can be used as a drop-in replacement for password-based user HOBA can be used as a drop-in replacement for password-based user
authentication schemes used in common web applications. The simplest authentication schemes used in common web applications. The simplest
way is to (re-)direct the UA to a HOBA "Login" URL and for the 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 response to a successful HTTP request containing a HOBA signature to
set a session cookie [RFC6265]. Further interactions with the web set a session cookie [RFC6265]. Further interactions with the web
application will then be secured via the session cookie, as is application will then be secured via the session cookie, as is
commonly done today. commonly done today.
skipping to change at page 5, line 34 skipping to change at page 5, line 37
implemented in a browser in JavaScript. implemented in a browser in JavaScript.
User agent (UA): typically, but not always, a web browser. User agent (UA): typically, but not always, a web browser.
User: a person who is running a UA. In this document, "user" does User: a person who is running a UA. In this document, "user" does
not mean "user name" or "account name". not mean "user name" or "account name".
Web client: the content and javascript code that run within the 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). context of a single UA instance (such as a tab in a web browser).
1.3. Step-by-step Overview of HOBA-http
Step-by-step, a typical HOBA-http registration and authentication
flow might look like this:
1. The client connects to the server and makes a request, and the
server's response includes a WWW-Authenticate header field that
contains the "HOBA" auth-scheme, along with associated parameters
(see Section 3).
2. If the client was not already registered with the web-origin and
realm it is trying to access, the "joining" process is invoked
(see Section 6.1). This creates a key pair and makes the CPK
known to the server so that the server can carry out the account
creation processes required.
3. The client uses the challenge from the HOBA auth-scheme
parameters, along with other information it knows about the web-
origin and realm, to create and sign a HOBA-TBS string (see
Section 2).
4. The client creates a HOBA client-result (HOBA-RES), using the
signed HOBA-TBS for the "sig" value (see Section 2).
5. The client includes the Authorization header field in its next
request, using the "HOBA" auth-scheme and putting the HOBA
client-result in an auth-param named "result" (see Section 3).
6. The server authenticates the HOBA client-result (see
Section 5.1).
7. Typically, the server's response includes a session cookie that
allows the client to indicate its authentication state in future
requests (see Section 1.1).
2. The HOBA Authentication Scheme 2. The HOBA Authentication Scheme
A UA that implements HOBA maintains a list of web-origins and realms. 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- The UA also maintains one or more client credentials for each web-
origin/realm combination for which it has created a CPK. origin/realm combination for which it has created a CPK.
On receipt of a challenge (and optional realm) from a server, the On receipt of a challenge (and optional realm) from a server, the
client marshals an HOBA to-be-signed (TBS) blob that includes a client marshals a HOBA to-be-signed (TBS) blob that includes a client
client generated nonce, the web-origin, the realm, an identifier for generated nonce, the web-origin, the realm, an identifier for the CPK
the CPK and the challenge string; and signs that blob with the and the challenge string; and signs that blob with the private key
private key corresponding to the CPK for that web-origin. The corresponding to the CPK for that web-origin. The formatting chosen
formatting chosen for this TBS blob is chosen so as to make server- for this TBS blob is chosen so as to make server-side signature
side signature verification as simple as possible for a wide range of verification as simple as possible for a wide range of current server
current server tooling. 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 and allows the characters specified in Section 2.3 of defined and allows the characters specified in Section 2.3 of
[RFC3986]. [RFC3986].
HOBA-TBS = len ":" nonce HOBA-TBS = len ":" nonce
len ":" alg len ":" alg
len ":" origin len ":" origin
len ":" [ realm ] len ":" [ realm ]
skipping to change at page 6, line 44 skipping to change at page 7, line 35
if a nonce with the value "ABCD" were used then that would be if a nonce with the value "ABCD" were used then that would be
preceeded by "4:" (see the example in Appendix B for detail). preceeded by "4:" (see the example in Appendix B for detail).
o nonce: is a random value chosen by the UA and MUST be base64url o nonce: is a random value chosen by the UA and MUST be base64url
encoded before being included in the HOBA-TBS value. (base64url encoded before being included in the HOBA-TBS value. (base64url
encoding is defined in [RFC4648], guidelines for randomness are encoding is defined in [RFC4648], guidelines for randomness are
give in [RFC4086].) UAs MUST be able to use at least 32 bits of give 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 randomness in generating a nonce. UAs SHOULD be able to use 64 or
more bits of randomness for nonces. more bits of randomness for nonces.
o alg: specifies the signature algorithm being used encoded as a o alg: specifies the signature algorithm being used. See Section 7
single octet as defined in Section 9.3. RSA-SHA256 MUST be for details of algorithm support requirements.
supported, RSA-SHA1 MAY be supported. The IANA registered
algorithm values are encoded as ASCII numbers; for example, the o The IANA registered algorithm values (see Section 9.3) are encoded
encoding of RSA-SHA256 is 0x30. as one- or two-digit ASCII numbers. For example, RSA-SHA256
(number 0) is encoded as the ASCII character "0" (0x30), while a
future algorithm registered as number 17 would be encoded as the
ASCII characters "17" (0x3137).
o origin: is the web origin expressed as the concatenation of the o origin: is the web origin expressed as the concatenation of the
scheme, authority and port from [RFC3986]. These are not base64 scheme, authority and port from [RFC3986]. These are not base64
encoded as they will be most readily available to the server in encoded as they will be most readily available to the server in
plain text. For example, if accessing the URL "https:// plain text. For example, if accessing the URL "https://
www.example.com:8080/foo" then the bytes input to the signature www.example.com:8080/foo" then the bytes input to the signature
process will be "https://www.example.com:8080". There is no process will be "https://www.example.com:8080". There is no
default for the port number, and the port number MUST be present. default for the port number, and the port number MUST be present.
o realm: is similarly just a string with the syntactic restrictions o realm: is similarly just a string with the syntactic restrictions
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. The challenge MUST be chosen server chose to send to the client. The challenge MUST be chosen
so that it is infeasible to guess, and SHOULD be indistinguishable so that it is infeasible to guess, and SHOULD be indistinguishable
from (the base64url encoding of) an at least 128-bit long random from (the base64url encoding of) an at least 128-bit long random
string. string.
skipping to change at page 8, line 11 skipping to change at page 8, line 48
sig = 1*base64urlchars sig = 1*base64urlchars
Figure 2: HOBA Client Result value Figure 2: HOBA Client Result value
If a malformed message of any kind is received by a server, the If a malformed message of any kind is received by a server, the
server MUST fail authenticaiton. If a malformed message of any kind server MUST fail authenticaiton. If a malformed message of any kind
is received by a client, the client MUST abandon that authentication is received by a client, the client MUST abandon that authentication
attempt. (The client is of course free to start another attempt. (The client is of course free to start another
authentication attempt if it desires.) authentication attempt if it desires.)
The HOBA scheme is far from new, for example, the basic idea is
pretty much identical to the first two messages from "Mechanism R" on
page 6 of [MI93] which predates HOBA by 20 years.
3. Introduction to the HOBA-http Mechanism 3. Introduction to the HOBA-http Mechanism
An HTTP server that supports HOBA authentication includes the "HOBA" An HTTP server that supports HOBA authentication includes the "HOBA"
auth-scheme value in a WWW-Authenticate header field when it wants auth-scheme value in a WWW-Authenticate header field when it wants
the client to authenticate with HOBA. Note that the HOBA auth-scheme 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- might not be the only one that the server includes in a WWW-
Authenticate header. Authenticate header.
The HOBA scheme has two REQUIRED attributes (challenge and max-age) The HOBA scheme has two REQUIRED attributes (challenge and max-age)
and one OPTIONAL attribute (realm): and one OPTIONAL attribute (realm):
o The "challenge" attribute MUST be included. The challenge is the o The "challenge" attribute MUST be included. The challenge is the
skipping to change at page 9, line 16 skipping to change at page 10, line 4
response. response.
The server MUST check that the same web origin is used in all of the 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 server's TLS server certificates, the URL being accessed and the HOBA
signature. If any of those checks fail, the server treats the signature. If any of those checks fail, the server treats the
signature as being cryptographically incorrect. 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 parameter 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 To optimise their use of challenges, UAs MAY pre-fetch 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.
4. Introduction to the HOBA-js Mechanism 4. Introduction to the HOBA-js Mechanism
Web sites using JavaScript can also perform origin-bound Web sites using JavaScript can also perform origin-bound
authentication without needing to involve the HTTP layer, and by authentication without needing to involve the HTTP layer, and by
inference not needing HOBA-http support in browsers. HOBA-js is not 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 an on-the-wire protocol like HOBA-http is: instead, it is a design
pattern that can be realized completely in JavaScript served in pattern that can be realized completely in JavaScript served in
normal HTML pages. normal HTML pages.
One element is required for HOBA-js: localStorage (see http:// One thing that is highly desirable for HOBA-js is WebCrypto (see
www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key http://www.w3.org/TR/WebCryptoAPI) which is (at the time of writing)
storage. For example, an implementation would store a dictionary starting to see deployment. In lieu of WebCrypto, JavaScript crypto
account identifier, public key and private key tuples in the origin's libraries can be employed with the known deficiencies of their
localStorage for subsequent authentication requests. How this pseudo-random number generators and the general immaturity of those
information is actually stored in localStorage is an implementation libraries.
detail. This type of key storage relies on the security properties
of the same-origin policy that localStorage enforces. See the Without Webcrypto, one element is required for HOBA-js: localStorage
security considerations for discussion about attacks on localStorage. (see http://www.w3.org/TR/webstorage/) from HTML5 can be used for
Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an persistent key storage. For example, an implementation would store a
alternative to localStorage that can also be used here. dictionary account identifier, 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
attacks on localStorage. Note that IndexedDB (See http://www.w3.org/
TR/IndexedDB/) is an alternative to localStorage that can also be
used here and that is used by WebCrypto.
Because of JavaScript's same-origin policy, scripts from subdomains Because of JavaScript's same-origin policy, scripts from subdomains
do not have access to the same localStorage that scripts in their do not have access to the same localStorage that scripts in their
parent domains do. For larger or more complex sites, this could be parent domains do. For larger or more complex sites, this could be
an issue that requires enrollment into subdomains, which could be a an issue that requires enrollment into subdomains, which could be
hassle for users. One way to get around this is to use session difficult for users. One way to get around this is to use session
cookies because they can be used across subdomains. That is, with 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 HOBA-js, the user might log in using a single well-known domain, and
then the server uses session cookies to navigate around a site. then session cookies are used whilst the user navigates around the
site.
Another element will be highly desirable for HOBA-js when it becomes
available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In
lieu of WebCrypto, JavaScript crypto libraries can be employed with
the known deficiencies of their pseudo-random number generators and
the general immaturity of those libraries.
5. HOBA's Authentication Process 5. HOBA's Authentication Process
This section describes how clients and servers use HOBA for This section describes how clients and servers use HOBA for
authentication. The interaction between an HTTP client and HTTP authentication. The interaction between an HTTP client and HTTP
server using HOBA happens in three phases: the CPK preparation phase, server using HOBA happens in three phases: the CPK preparation phase,
the signing phase, and the authentication phase. This section also the signing phase, and the authentication phase. This section also
covers the actions that give HOBA user features similar to today's covers the actions that give HOBA user features similar to today's
password based schemes. password based schemes.
skipping to change at page 13, line 22 skipping to change at page 14, line 9
key option MUST be used. key option MUST be used.
o kid: contains the key identifier as a base64url encoded string 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 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 hash of a public key then the correct (base64url encoded) hash
value MUST be provided and the server SHOULD check that and refuse value MUST be provided and the server SHOULD check that and refuse
the registration if an incorrect value was supplied. the registration if an incorrect value was supplied.
o didtype: specifies a kind of device identifier intended to contain o didtype: specifies a kind of device identifier intended to contain
one of the values from Section 9.5, if absent then the "string" one of the values from Section 9.5, if absent then the "string"
form of device identifier MUST be used. form of device identifier defined in Section 9.5 MUST be used.
o did: a UTF8 string that specifies the device identifier. This can o did: a UTF8 string that specifies the device identifier. This can
be used to help a user be confident that authentication has be used to help a user be confident that authentication has
worked, e.g., following authentication some web content might say worked, e.g., following authentication some web content might say
"You last logged in from device 'did' at time T." "You last logged in from device 'did' at time T."
Note that replay of registration (and other HOBA) messages is quite Note that replay of registration (and other HOBA) messages is quite
possible. That however can be counteracted if challenge freshness is possible. That however can be counteracted if challenge freshness is
ensured. See Section 2 for details. Note also that with HOBA-http 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 the HOBA signature does not cover the POST message body. If that is
skipping to change at page 17, line 15 skipping to change at page 17, line 46
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 MUST contain a fresh (base64url encoded) HOBA challenge the response MUST contain a fresh (base64url encoded) HOBA challenge
for this origin in the body of the response. Whitespace in the for this origin in the body of the response. Whitespace in the
response MUST be ignored. 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. HOBA implementations MUST use RSA-
lengths of at least 2048 bits SHOULD be used. RSA is defined in SHA256 if it is provided by the underlying cryptographic libraries.
Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. 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. Security Considerations
If key binding was server-selected then a bad actor could bind
different accounts belonging to the user from the network with
possible bad consequences, especially if one of the private keys was
compromised somehow.
Binding my CPK with someone else's account would be fun and Binding my CPK with someone else's account would be fun and
profitable so SHOULD be appropriately hard. In particular URLs or profitable so SHOULD be appropriately hard. In particular URLs or
other values generated by the server as part of any CPK binding other values generated by the server as part of any CPK binding
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.
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 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 can set the max-age to the minimum replayed. Server administrators can set the max-age to the minimum
acceptable value in such cases, which would often be expected to be 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- 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 age more than a few minutes; the value ought also decrease over time
as device capabilities improve. The administrator will most likely as device capabilities improve. The administrator will most likely
want to set the max-age to something that is not too slow on the want to set the max-age to something that is not too short for 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
skipping to change at page 18, line 17 skipping to change at page 19, line 14
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
expect 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.
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 an 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 encourage use of device identifier
values that are not personally identifying except for the user
concerned, for example "Alice's mobile" is likely to be chosen and is
somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0"
would be a very bad choice.
8.2. localStorage Security for Javascript 8.2. localStorage Security for Javascript
The use of localStorage (likely with a non-WebCrypto implementation The use of localStorage (likely with a non-WebCrypto implementation
of HOBA-js) will undoubtedly be a cause for concern. localStorage of HOBA-js) will undoubtedly be a cause for concern. localStorage
uses the same-origin model which says that the scheme, domain and uses the same-origin model which says that the scheme, domain and
port define a localStorage instance. Beyond that, any code executing port define a localStorage instance. Beyond that, any code executing
will have access to private keying material. Of particular concern will have access to private keying material. Of particular concern
are XSS attacks which could conceivably take the keying material and are XSS attacks which could conceivably take the keying material and
use it to create UAs under the control of an attacker. But XSS use it to create UAs under the control of an attacker. But XSS
attacks are in reality across the board devastating since they can attacks are in reality across the board devastating since they can
skipping to change at page 18, line 40 skipping to change at page 20, line 14
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
ala LinkedIn because of shared passwords across sites. [bland] because of shared passwords across sites.
It's worth noting that HOBA uses asymmetric keys and not passwords It's worth noting that HOBA uses asymmetric keys and not passwords
when evaluating threats. As various password database leaks have when evaluating threats. As various password database leaks have
shown, the real threat of a password breach is not just to the site shown, the real threat of a password breach is not just to the site
that was breached, it's all of the sites a user used the same that was breached, it's all of the sites a user used the same
password on too. That is, the collateral damage is severe because password on too. That is, the collateral damage is severe because
password reuse is common. Storing a password in localStorage would password reuse is common. Storing a password in localStorage would
also have a similar multiplier effect for an attacker, though perhaps also have a similar multiplier effect for an attacker, though perhaps
on a smaller scale than a server-side compromise: one successful on a smaller scale than a server-side compromise: one successful
crack gains the attacker potential access to hundreds if not crack gains the attacker potential access to hundreds if not
skipping to change at page 19, line 16 skipping to change at page 20, line 38
8.3. Multiple Accounts on One User Agent 8.3. Multiple Accounts on One User Agent
A shared UA with multiple accounts is possible if the account A shared UA with multiple accounts is possible if the account
identifier is stored along with the asymmetric key pair binding them identifier is stored along with the asymmetric key pair binding them
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 could request that the credential be erased from
browser. Similarly, during the enrollment phase, a user could the 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.
However, all such features really ought 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. Injective Mapping for HOBA-TBS
The repeated length fields in the HOBA-TBS structure are present in The repeated length fields in the HOBA-TBS structure are present in
order to ensure that there is no possibility that the catenation of order to ensure that there is no possibility that the catenation of
different input values can cause confusion that might lead to an different input values can cause confusion that might lead to an
attack, either against HOBA as specified here, or else an attack attack, either against HOBA as specified here, or else an attack
against some other protocol that re-used this to-be-signed structure. against some other protocol that re-used this to-be-signed structure.
Those fields ensure that the mapping from input fields to the HOBA- Those fields ensure that the mapping from input fields to the HOBA-
TBS string is an injective mapping. 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 For all new registries requested by this document, please place those
beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters" beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters"
skipping to change at page 21, line 14 skipping to change at page 22, line 38
For the number 0, hashed public keys are as done in DANE. [RFC6698] For the number 0, hashed public keys are as done in DANE. [RFC6698]
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.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.
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 Number Meaning
----------- -------------------------------------------- ----------- --------------------------------------------
0 an unformatted UTF8 string, at the user's/UA's whim 0 an unformatted UTF8 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 Field 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
Author/Change controller: IETF Author/Change controller: IETF
skipping to change at page 22, line 19 skipping to change at page 23, line 47
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 three known implementations. At the time of writing there are three known implementations.
One done by Stephen Farrell of HOBA-http and a HOBA-JS variant One done by Stephen Farrell of HOBA-http and a HOBA-JS variant
implements the current (-08) version of HOBA and is available from implements the current version of HOBA and is available from
https://hoba.ie/ which site also includes a demonstration of HOBA. https://hoba.ie/ which site also includes a demonstration of HOBA.
There is another implementation by Michael Thomas of an HOBA-JS There is another implementation by Michael Thomas of a HOBA-JS
variant. variant.
The most recent (Dec 2014) implementation is by Portugal Telecom The most recent (Dec 2014) implementation is by Portugal Telecom
and is available from https://github.com/razevedo/hoba- and is available from https://github.com/razevedo/hoba-
authentication 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: David Black, Donald Eastlake, Amos preparation of this specification: Richard Barnes, David Black,
Jeffries, Benjamin Kaduk, Watson Ladd, Matt Lepinski, Ilari Alissa Cooper, Donald Eastlake, Amos Jeffries, Benjamin Kaduk, Watson
Liusvaara, James Manger, Alexey Melnikov, Kathleen Moriarty, Yoav Ladd, Barry Leiba, Matt Lepinski, Ilari Liusvaara, James Manger,
Nir, Mark Nottingham, Julian Reschke, Michael Richardson, Yaron Alexey Melnikov, Kathleen Moriarty, Yoav Nir, Mark Nottingham, Julian
Sheffer, and Michael Sweet. All errors and stupidities are of course Reschke, Pete Resnick, Michael Richardson, Yaron Sheffer, and Michael
the editors' fault. Sweet. All errors and 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.
skipping to change at page 24, line 13 skipping to change at page 25, line 41
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.
[bland] Sophos, , "Security Threat Report 2013", January 2013,
<http://www.sophos.com/en-us/medialibrary/pdfs/other/
sophossecuritythreatreport2013.pdf>.
[bonneau] Bonneau, , "The science of guessing: analyzing an [bonneau] Bonneau, , "The science of guessing: analyzing an
anonymized corpus of 70 million passwords.", IEEE anonymized corpus of 70 million passwords.", IEEE
Symposium on Security and Privacy , 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
 End of changes. 39 change blocks. 
109 lines changed or deleted 181 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/