draft-ietf-httpauth-hoba-01.txt   draft-ietf-httpauth-hoba-02.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: January 16, 2014 VPN Consortium Expires: April 21, 2014 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
July 15, 2013 October 18, 2013
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-01 draft-ietf-httpauth-hoba-02
Abstract Abstract
HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP
authentication method with credentials that are not vulnerable to authentication method with credentials that are not vulnerable to
phishing attacks, and that does not require a server-side password phishing attacks, and that does not require any server-side password
database. The design can also be used in Javascript-based database. The design can also be used in Javascript-based
authentication embedded in HTML. HOBA is an alternative to HTTP authentication embedded in HTML. HOBA is an alternative to HTTP
authentication schemes that require passwords with all the negative authentication schemes that require passwords.
attributes that come with password-based systems.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 16, 2014. This Internet-Draft will expire on April 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 5 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . . 6 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5
3. HOBA HTTP Authentication Mechanism . . . . . . . . . . . . . . 8 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7
4. Using HOBA-http . . . . . . . . . . . . . . . . . . . . . . . 9 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 8
4.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9
4.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9
4.3. Authentication Phase . . . . . . . . . . . . . . . . . . . 10 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Logging in on a New User Agent . . . . . . . . . . . . . . 11 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 9
5. Using HOBA-js . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 10
5.1. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11
5.2. User Join . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Associating Additional Keys to an Exiting Account . . . . 12
5.3. User Login . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 13
5.4. Enrolling a New User Agent . . . . . . . . . . . . . . . . 12 6.2.2. One time password . . . . . . . . . . . . . . . . . . 13
5.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 13 6.2.3. Out of band . . . . . . . . . . . . . . . . . . . . . 14
5.6. Signature Parameters . . . . . . . . . . . . . . . . . . . 13 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 14
5.7. Session Management . . . . . . . . . . . . . . . . . . . . 15 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 14
5.8. Multiple Accounts on One User Agent . . . . . . . . . . . 15 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 14
5.9. Oddities . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Additional Services . . . . . . . . . . . . . . . . . . . . . 16 8.1. localStorage Security for Javascript . . . . . . . . . . 15
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Multiple Accounts on One User Agent . . . . . . . . . . . 16
6.2. Associating Additional Keys to an Exiting Account . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 16
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 18 9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . 16
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 18 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 17
8.1. localStorage Security for Javascript . . . . . . . . . . . 19 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 18
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 19
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Problems with Passwords . . . . . . . . . . . . . . . 23
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 23
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 25
C.1. WG-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
C.2. WG-00 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[[ Commentary is in double-square brackets, like this. As you'll see [[ Commentary is in double-square brackets, like this. Fewer things
there are a bunch of details still to be figured out. Feedback on this time.]]
those is very welcome. Also note that the authors fully expect that
the description of HOBA-http and HOBA-js to be mostly merged in the
draft; they're both here now so readers can see some alternatives and
maybe support particular proposals. ]]
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 and for Javascript- that can be used as an HTTP [RFC2616] authentication scheme and for
based authentication embedded in HTML. The main goal of HOBA is to Javascript-based authentication embedded in HTML. The main goal of
offer an easy-to-implement authentication scheme that is not based on HOBA is to offer an easy-to-implement authentication scheme that is
passwords, but that can easily replace HTTP or HTML forms-based not based on passwords, but that can easily replace HTTP or HTML
password authentication. If deployment of HOBA reduces the number of forms-based password authentication. Deployment of HOBA can reduce
password entries in databases by any appreciable amount, then it or eliminate password entries in databases, with potentially
would be worthwhile. As an HTTP authentication scheme, it would work significant security benefits.
in the current HTTP 1.0 and HTTP 1.1 authentication framework, and
will very likely work with whatever changes are made to the HTTP
authentication scheme in HTTP 2.0. As a JavaScript design, HOBA
demonstrates a way for clients and servers to interact using the same
credentials that are use by the HTTP authentication scheme.
The HTTP specification defines basic and digest authentication HOBA is an HTTP authentication mechanism that complies with the
methods for HTTP that have been in use for many years, but which, framework for such schemes; see [RFC2617] for the original
being based on passwords, are susceptible to theft of server-side specification, and [I-D.ietf-httpbis-p7-auth] for clarifications and
databases. (See [RFC2617] for the original specification, and updates to the HTTP authentication framework. As a JavaScript
[I-D.ietf-httpbis-p7-auth] for clarifications and updates to the design, HOBA demonstrates a way for clients and servers to interact
authentication mechanism.) Even though few large web sites use basic using the same credentials that are used by the HTTP authentication
and digest authentication, they still use username/password scheme.
authentication and thus have large susceptible server-side databases
of passwords.
Instead of passwords, HOBA uses digital signatures as an Current HTTP authentication methods (Basic and Digest), as well as
authentication mechanism. HOBA also adds useful features such as username/password authentication using web forms, have been in use
credential management and session logout. In HOBA, the client for many years, but being based on passwords, are susceptible to
creates a new public-private key pair for each host ("web-origin") to theft of server-side databases. Instead of passwords, HOBA uses
which it authenticates; web-origins are defined in [RFC6454]. These digital signatures as an authentication mechanism. HOBA also adds
keys are used in HOBA for HTTP clients to authenticate themselves to useful features such as credential management and session logout. In
servers in the HTTP protocol or in a Javascript authentication HOBA, the client creates a new public-private key pair for each host
program. ("web-origin" [RFC6454]) to which it authenticates. These keys are
used in HOBA for HTTP clients to authenticate themselves to servers
in the HTTP protocol or in a Javascript authentication program.
HOBA keys need not be stored in public key certificates. Because Session management with HOBA is identical to username/password
these are generally "bare keys", there is none of the semantic session management. Typically, the session management tool (such as
PHP, Python CGI, and so on) inserts a session cookie into the output
to the browser. HOBA does nothing to help or hurt session cookie
hijacking; TLS is still required for that.
HOBA keys are "bare keys", so there is no need for the semantic
overhead of PKIX certificates, particularly with respect to naming overhead of PKIX certificates, particularly with respect to naming
and trust anchors. Thus, client public keys ("CPKs") do not have any and trust anchors. The client public key ("CPK") structures in HOBA
publicly-visible identifier for the user who possesses the do not have any publicly-visible identifier for the user who
corresponding private key, nor the web-origin with which the client possesses the corresponding private key, nor the web-origin with
is using the CPK. HOBA keys are stored in subjectPublicKeyInfo which the client is using the CPK.
structures from PKIX [RFC5280]
HOBA also defines some services that are required for modern HTTP HOBA also defines some services that are required 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. HOBA allows servers to define their own policies for name. Servers using HOBA define their own policies for binding
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 Users are also likely to lose a private key, or the client's o Users are also likely to lose a private key, or the client's
memory of which key pair is associated with which origin. For memory of which key pair is associated with which origin, such as
example if a user loses the computer or mobile device in which when a user loses the computer or mobile device in which state is
state is stored. HOBA allows for clients to tell servers to stored. HOBA allows for clients to tell servers to delete the
delete the association between an existing CPK and an account. association between an existing CPK and an account.
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", and also a way to close all
current sessions, even if more than one session is currently current sessions, even if more than one session is currently
active from different UAs for the same account. active from different UAs for the same account.
o Since there are always devices and applications in which state of o Since there are always devices and applications in which state of
the art digital signature mechanism runtimes are significant, and the art digital signature mechanism runtimes are significant, and
since HTTP authentication in theory requires that every HTTP since HTTP authentication in theory requires that every HTTP
request to a given realm have a signature in an "Authorization" request to a given realm have a signature in an "Authorization"
skipping to change at page 7, line 8 skipping to change at page 5, line 46
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 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 hashed blob with the the CPK and the challenge string; and signs that hashed 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. Figure 1 specifies the ABNF for the signature input.
HOBA-TBS = nonce alg origin realm kid challenge HOBA-TBS = nonce alg origin [ realm ] kid challenge
nonce = unreserved nonce = unreserved
alg = 1*2DIGIT alg = 1*2DIGIT
origin = scheme authority port origin = scheme "://" authority ":" port
realm = unreserved realm = unreserved
kid = unreserved kid = unreserved
challenge = unreserved challenge = unreserved
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 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. UAs MUST be encoded before being included in the HOBA-TBS value. UAs MUST be
able to use at least 32 bits of randomness in generating a nonce. able to use at least 32 bits of randomness in generating a nonce.
UAs SHOULD be able to use up to 64 bits of randomness for nonces. UAs SHOULD be able to use 64 or more bits of randomness for
nonces.
o alg: specifies the signature algorithm being used encoded as an o alg: specifies the signature algorithm being used encoded as an
ASCII character as defined in Section 9.3. RSA-SHA256 MUST be ASCII character as defined in Section 9.3. RSA-SHA256 MUST be
supported, RSA-SHA1 MAY be supported. The IANA registered supported, RSA-SHA1 MAY be supported. The IANA registered
algorithm values are encoded as ASCII numbers; for example, the algorithm values are encoded as ASCII numbers; for example, the
encoding of RSA-SHA256 is 0x30. encoding of RSA-SHA256 is 0x30.
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 are from [RFC3986]. These are not scheme, authority and port from [RFC3986]. These are not base64
base64 encoded as they will be most readily available to the encoded as they will be most readily available to the server in
server in plain text. For example, if accessing the URL plain text. For example, if accessing the URL "https://
"https://www.example.com:8080/foo" then the bytes input to the www.example.com:8080/foo" then the bytes input to the signature
signature process will be "httpswww.example.com8080" process will be "https://www.example.com:8080" There is no default
for the port number, which 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 [I-D.ietf-httpbis-p7-auth]. If no realm is specified defined in [I-D.ietf-httpbis-p7-auth]. If no realm is specified
for this authentication then this is absent. (A missing field for this authentication then this is absent. (A missing field
here is no problem since both sides know when it needs to be here is no problem since both sides know when it needs to be
there.) there.)
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).
skipping to change at page 8, line 26 skipping to change at page 7, line 15
(One form of stateless challenge might be a ciphertext that the (One form of stateless challenge might be a ciphertext that the
server decrypts and checks, but that is an implementation detail.) server decrypts and checks, but that is an implementation detail.)
The value that is sent over the network is the HOBA "client result" The value that is sent over the network is the HOBA "client result"
which we now define. 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 Authorized header field value using
the value syntax defined in Figure 2. The "sig" value is the 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. [[Expect more changes here. This is very also base64url encoded.
like JOSE's compact form and maybe ought be an instance of that.]]
HOBA-RES = kid "." challenge "." nonce "." sig HOBA-RES = kid "." challenge "." nonce "." sig
sig = unreserved sig = unreserved
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
pretty much identical to the first two messages from "Mechanism R" on pretty much identical to the first two messages from "Mechanism R" on
page 6 of [MI93] which predates HOBA by 20 years. page 6 of [MI93] which predates HOBA by 20 years.
3. HOBA HTTP Authentication 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. the client to authenticate with HOBA. Note that the HOBA auth-scheme
might not be the only one that the server includes in a WWW-
Authenticate.
o If the "HOBA" scheme is listed, it MUST be followed by two or more o If the "HOBA" scheme is listed, it MUST be followed by two or more
auth-param values. The auth-param attributes defined by this auth-param values. The auth-param attributes defined by this
specification are below. Other auth-param attributes MAY be used specification are below. Other auth-param attributes MAY be used
as well. Unknown auth-param attributes MUST be ignored by as well. Unknown auth-param attributes MUST be ignored by
clients, if present. clients, if present.
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 SHOULD be wants the client to sign in its response. The challenge SHOULD be
skipping to change at page 9, line 25 skipping to change at page 8, line 15
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 protection in the manner described in HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear
more than once. 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 (a string matching the HOBA-RES production in Figure 2 client-result (a string matching the HOBA-RES production in Figure 2
as an auth-param with the name "result" and returns that in the as an auth-param with the name "result" and returns that in the
Authorization header. Authorization header.
The server MUST check the cryptographic correctness of the signature
based on a public key it knows for the kid in the signatures, and if
the server cannot do that, or if the signature fails cryptographic
checks, then validation has failed. The server can use any
additional mechanisms to validate the signature. If the validation
fails, or if the server chooses reject the signature for any reason
whatsoever, the server aborts the transaction via a 403 Forbidden
HTTP response.
Note that a HOBA signature is good for however long the expires Note that a HOBA signature is good for however long the expires
attribute allows. This means that replay is potentially possible attribute allows. This means that replay is possible within the time
within the time window specified by the "expires" value chosen by the window specified by the "expires" value chosen by the server.
server. Servers SHOULD attempt to detect any such replay and MAY Servers can attempt to detect any such replay and MAY react to such
react to such replays by responding with a second (or subsequent) replays by responding with a second (or subsequent) 401-status HTTP
401-status HTTP response containing a new challenge. 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 "expires"/2 seconds have elapsed using the value, for example after expires/2 seconds have elapsed, using the
".well-known/hoba/getChal" scheme described below. This also allows ".well-known/hoba/getChal" scheme described later in this document.
for pre-calculation of HOBA signatures, if that is required in order This also allows for pre-calculation of HOBA signatures, if that is
to produce a responsive user interface. required in order to produce a responsive user interface.
4. Using HOBA-http 4. Introduction to the HOBA-js Mechanism
[[A lot of this is similar to the HOBA-js discussion below. At some Web sites using JavaScript can also perform origin-bound
point some nuclear fusion might be nice, but for now it might be best authentication without needing to involve the HTTP layer, and by
to keep them separate until we understand better what can be merged, inference not needing HOBA-http support in browsers. HOBA-js is not
and what is different.]] an on-the-wire protocol like HOBA-http is: instead, it is a design
pattern that can be realized completely in JavaScript served in
normal HTML pages.
The interaction between an HTTP client and HTTP server using HOBA One element is required for HOBA-js: localStorage (see http://
happens in three phases: the CPK preparation phase, the signing www.w3.org/TR/webstorage/) from HTML5. is used for persistent key
phase, and the authentication phase. The first and second phase are storage. For example, an implementation would store a dictionary
done in a standard fashion; the third is done using site-specific account identifier, public key, private key tuples in the origin's
methods. In addition, we provide a mechanism for pre-fetching localStorage for subsequent authentication requests. How this
challenges. 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.
4.1. CPK Preparation Phase Because of JavaScript's same-origin policy, scripts from subdomains
do not have access to the same localStorage that scripts in their
parent domains do. For larger or more complex sites, this could be
an issue that requires enrollment into subdomains, which could be a
hassle for users. One way to get around this is to use session
cookies because they can be used across subdomains. That is, with
HOBA-js, the user might log in using a single well-known domain, and
then the server uses session cookies to navigate around a site.
Another element will be highly desirable for HOBA-js when it becomes
available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In
lieu of WebCrypto, JavaScript crypto libraries can be employed with
the known deficiencies of PRNG, and the general immaturity of those
libraries.
5. HOBA's Authentication Process
This section describes how clients and servers use HOBA for
authentication. The interaction between an HTTP client and HTTP
server using HOBA happens in three phases: the CPK preparation phase,
the signing phase, and the authentication phase. This section also
covers the actions that give HOBA similar user features as today's
passwords have.
5.1. CPK Preparation Phase
In the CPK preparation phase, the client determines if it already has In the CPK preparation phase, the client determines if it already has
a CPK for the web-origin it is going to. If the has a CPK, the a CPK for the web-origin it is going to. If the client has a CPK,
client will use it; if the client does not have a CPK, it generates the client will use it; if the client does not have a CPK, it
one in anticipation of the server asking for one. generates one in anticipation of the server asking for one.
4.2. Signing Phase 5.2. Signing Phase
In the signing phase, the client connects to the server, the server In the signing phase, the client connects to the server, the server
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.
The UA tries to access a protected resource on the server. The 5.3. Authentication Phase
server sends the HOBA WWW-Authenticate challenge. The UA receives
the challenge and signs the challenge using the CPK it either already
had or just generated. The server validates the signature. If
validation fails, or if the server chooses to do so for other
reasons, then server aborts the transaction via a 403 Unauthorized
HTTP response.
4.3. Authentication Phase The authentication phase is completely dependent on the policies and
practices of the server. That is, this phase involves no
standardized protocol in HOBA-http; in HOBA-js, there is no suggested
interaction template.
In the authentication phase, the server extracts the CPK from the In the authentication phase, the server extracts the CPK from the
signing phase and decides if it recognizes the CPK. If the server signing phase and decides if it recognizes the CPK. If the server
recognizes the CPK, the server may finish the client authentication recognizes the CPK, the server may finish the client authentication
process. If this stage of the process involves additional process.
information for authentication, such as asking the user which account
she wants to use (in the case where a UA is used for multiple If this stage of the process involves additional information for
accounts on a site), the server can prompt the user for account authentication, such as asking the user which account she wants to
identifying information or the user could choose based on HTML use (in the case where a UA is used for multiple accounts on a site),
offered by the server before the 401 is triggered. None of this is the server can prompt the user for account identifying information or
standardized: it all follows the server's security policy and session the user could choose based on HTML offered by the server before the
flow. At the end of this, the server probably assigns or updates a 401 is triggered. None of this is standardized: it all follows the
session cookie for the client. server's security policy and session flow. At the end of this, the
server probably assigns or updates a session cookie for the client.
During the authentication phase, if the server does not recognize the
CPK, it could use HTML and JavaScript to ask the user if they are
really a new user or want to associate this new CPK with an already-
joined CPK. The server can then use some out-of-band method (such as
a confirmation email round trip, SMS, or an UA that is already
enrolled) to verify that the "new" user is the same as the already-
enrolled one. Thus, logging in on a new user agent is identical to
logging in with an existing account.
If the server does not recognize the CPK the server might send the 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.
Completion of the joining process might require confirmation by Completion of the joining process might require confirmation by
email, SMS, Captcha, and so on. email, SMS, Captcha, and so on.
Note that there is no necessity for the server to initiate a joining Note that there is no necessity for the server to initiate a joining
or login process upon completion of the signing phase. Indeed, the or login process upon completion of the signing phase. Indeed, the
server may desire to challenge the UA even for unprotected resources server may desire to challenge the UA even for unprotected resources
and set a session cookie for later use in a join or login process as and set a session cookie for later use in a join or login process as
it becomes necessary. For example, a server might only want to offer it becomes necessary. For example, a server might only want to offer
an account to someone who had been to a few pages on the web site; in an account to someone who had been to a few pages on the web site; in
such a case, the server could use the CPK from an associated session such a case, the server could use the CPK from an associated session
cookie as a way of building reputation for the user until the server cookie as a way of building reputation for the user until the server
wants the user to join. wants the user to join.
After the UA is authenticated (if the user had to join, this could be 6. Other Parts of the HOBA Process
the last step of joining), the server gives the UA access to the The authentication process is more than just the act of
protected resource that was originally requested at the beginning of authentication. In password-based authentication and HOBA, there are
the signing phase. It is quite likely that the server would also other processes that are needed both before and after an
update the UA's session cookie for the web site. authentication step. This section covers those processes. Where
possible, it combines practices of HOBA-http and HOBA-js; where that
4.4. Logging in on a New User Agent is not possible, the differences are called out.
When a user wants to use a new UA for an existing account, the flows
are similar to logging in with an already-joined UA or joining for
the first time. In fact, the CPK preparation phase (with the UA
knowing that it needs to create a new CPK) and the signing phase are
identical.
During the authentication phase, the server could use HTML and
JavaScript to ask the user if they are really a new user or want to
associate this new CPK with an already-joined CPK. The server can
then use some out-of-band method (such as a confirmation email round
trip, SMS, or an UA that is already enrolled) to verify that the
"new" user is the same as the already-enrolled one.
5. Using HOBA-js
[[ A description of how to use the same HOBA semantics, but doing
everything in Javascript in a web page. This is more of a
demonstration that you could get the similar semantics via JS rather
than a normative section.]]
Web sites using javascript can also perform origin-bound
authentication without needing to involve the http layer, and by
inference not needing HOBA-specific support in browsers. One element
is required: localStorage (see http://www.w3.org/TR/webstorage/), and
one when it is available will be highly desirable: WebCrypto (see
http://www.w3.org/TR/WebCryptoAPI). In lieu of WebCrypto, javascript
crypto libraries can be employed with the known deficiencies of PRNG,
and the general immaturity of those libraries. The following section
outlines a mechanism for Javascript HOBA clients to initially enroll,
subsequent enrollment on new clients, login, and how HOBA-js relates
to web based session management. As with HOBA-http, a pure
Javascript implementation retains the property that only CPKs are
stored on the server, so that server compromise doesn't suffer the
multiplier affect that the various recent password exposure debacles
have vividly demonstrated.
5.1. Key Storage
We use HTML 5's localStorage feature for key storage. Conceptually
an implementation stores the dictionary account identifier, public
key, private key tuples in the origin's localStorage for subsequent
authentication requests. How this is actually stored in localStorage
is an implementation detail. We rely on the security properties of
the same-origin policy that localStorage enforces. See the security
considerations for discussion about attacks on localStorage.
5.2. User Join
To join a web site, the HOBA-js client generates a public/private key
pair and takes as input the account identifier to which the key pair
should be bound. The key pair and account identifier are stored in
localStorage for later use. The UA then signs the join information
(see below) using the private key, and forms a message with the
public key (CPK) and the signed data. The server receives the
message and verifies the signed data using the supplied key. The
server creates the account and adds the public key to a list of
public keys associated with this account.
5.3. User Login
Each time the user needs to log in to the server, it creates a login
message (see below) and signs the message using the relevant private
key stored in localStorage. The signed login message along with the
associated CPK identifier is sent to the server. The server receives
the message and verifies the signed data. If the supplied public key
is amongst the set of valid public keys for the supplied account,
then the login proceeds. See below for a discussion about replay.
5.4. Enrolling a New User Agent
When a user wants to start using a different UA, the website has two
choices: use a currently enrolled UA to permit the enrollment or use
a trusted out of band mechanism (eg email, sms, etc). To enroll a
new UA using an existing UA, the web site can display a one-time
password on the currently enrolled UA. This password is a one-time
password and expires in a fixed amount of time (say, 30 minutes). It
doesn't need to be an overly fussy password since it's one-time and
times out quickly. The user then inputs the one-time password and
the new UA generates a new asymmetric key pair and includes the one-
time password in the login message to the server (see below).
Alternatively if an enrolled UA is not available, and the site has an
out of band communication mechanism (eg, sms, email, etc) a user can
request that a one-time password be sent to the user. The server
generates and stores the one-time password as above. The user
receives the one-time password, inputs as above on the new UA, and
the HOBA-js client forms the login message as above.
In both cases, when the server receives a login message with a one-
time password, it checks to see if the password supplied is in a list
of unexpired one-time passwords associated with that account. If the
password matches, the server verifies the signature, expires or
deletes the one-time password and adds the supplied public key to the
list of public keys associated with the user assuming the signature
verified correctly. Subsequent logins proceed as above in User
Login.
5.5. Replay Protection
To guard against replay of a legitimate login/join message, we use
Kerberos-like timestamps in the expectation of synchronization
between the browser's and server's clocks is sufficiently reliable.
This saves an HTTP round trip which is desirable, though a challenge-
response mechanism as in HOBA-http could also be used. The client
puts the current system time into the URL, and the server side vets
it against its system time. Like Kerberos, a replay cache covering a
signature timeout window is required on the server. This can be done
using a database table that is keyed (in the database sense of the
term) using the signature bits. If the signature is in the replay
table, it ought be rejected. If the timestamp in the signature is
outside the current replay cache window then it also gets rejected.
[[ An addition of the ability for the server to reject a client with
potential time skew and give it a nonce (as with HOBA-http) would
allow the size of the replay cache to be set to just a few minutes
rather than a much longer period. Or the HOBA server could always
use a nonce method. This is worthy of more discussion. ]].
5.6. Signature Parameters
Since we only require agreement between the server and the client
where the client is under the control of the server, the actual url
parameter names here are only advisory. For each signed url, the
client forms a url with the necessary login/join information. For
example, suppose example.com has login and join scripts with various
parameters:
o http://example.com/site/login.php?username=Mike
o http://example.com/site/
join.php?username=Mike&email=mike@example.com&sms=555.1212
The client then appends a signature parameter block to the url:
o curtime: the time in milliseconds since unix epoch (ie, new Date
().getTime ()).
o pubkey: the url encoded public key. See DKIM for the format of
the base64 encoded PEM formated key.
o temppass: an optional url encoded one-time password for subsequent
enrollment.
o keyalg: currently RSA. 2048 bit keys should be use if WebCrypto is
available
o digestalg: currently SHA1. SHA256 should be used if WebCrypto is
available.
o signature: empty for signing canonicalization purposes
[[ Signing the full url is problematic with PHP; we should take a
clue from what OAUTH does here; we almost certainly need to add some
host identifying information...]] To create the signature, the
canonical text includes the path portion, the site-specific url
parameters and appends a signature block onto the end of the url.
The signature block consists of the parameters listed above with an
empty signature parameter (ie, signature=), eg:
o Login: /site/
login.php?username=Mike&curtime=1234567890.1234&keyalg=RSA&
digestalg=SHA1&signature=
o Join: /site/
join.php?username=Mike&email=mike@
example.com&curtime=1234567890.1234&keyalg=RSA&digestalg=SHA1&
signature=
o Login New User Agent: /site/
login.php?username=Mike&curtime=1234567890.1234&temppass=1239678&
keyalg=RSA&digestalg=SHA1&signature=
The canonical signature text is then signed with the private key
associated with the account. The signature is then base64 encoded
and appended to the full url, and sent to the server using
XMLHttpRequest as usual. On receipt of the login request, the server
first extracts the timestamp (curtime) and determines whether the
timestamp is fresh (see above) rejecting the request if stale. The
server then removes the scheme and domain:port portion of the
incoming url, and removes the signature value only to create the
canonical signature text. The server then extracts the public key
along with the account and verifies the signature. If the signature
verifies, the server then determines whether this is an enrolled
public key for the user. If it is, login/join succeeds. If the key
is not enrolled, the server then checks to see if a one-time password
was supplied. If not, login/join fails. If a one-time password was
supplied, the server checks to see if a one-time password is valid
and fails if not. If valid, the server disables the one-time
password (eg, deletes it from its database) and adds the new public
key to the list of enrolled public keys for this user.
Once verified, the server may start up normal cookie-based session
management (see below). The server should send back status to the
HOBA-js client to determine whether the login/join was successful.
The details are left as an implementation detail.
Note: the client SHOULD use an HTTP POST for the XMLHttpRequest as
both the public key and signature blocks may exhaust the maximum size
for a GET request (typically around 2KB).
5.7. Session Management
Session Management is identical to username/password session
management. That is, the session management tool (such as PHP,
Python CGI, and so on) inserts a session cookie into the output to
the browser, and logging out simply removes the session cookie.
HOBA-js does nothing to help or hurt session cookie hijacking -- TLS
is still our friend.
5.8. Multiple Accounts on One User Agent
A shared UA with multiple accounts is possible if the account
identifier is stored along with the asymmetric key pair binding them
to one another. Multiple entries can be kept, one for each account,
and selected by the current user. This, of course, is fraught with
the possibility for abuse, since you're enrolling the device
potentially long-term. A couple of things can possibly be done to
combat that. First, the user can request that the credential be
erased from keystore. Similarly, in the enrollment phase, a user
could request that the key pair only be kept for a certain amount of
time, or that it not be stored at all. Last, it's probably best to
just not use shared devices at all since that's never especially
safe.
5.9. Oddities
With the same-origin policy, subdomains do not have access to the
same localStorage as parent domains do. For larger/more complex
sites this could be an issue that requires enrollment into subdomains
with the requisite hassle for users. One way to get around this is
to use session cookies as they can be used across subdomains. That
is, login using a single well-known domain, and then use session
cookies to navigate around a site.
6. Additional Services All additional services MUST be performed in TLS-protected sessions
([RFC5246]). If the current HTTP traffic is not running under TLS, a
new session is started before any of the actions described here are
performed.
HOBA 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. There are many use cases for these URLs to redirect to accessing. There are many use cases for these URLs to redirect to
other URLs: a site that does registration through a federated site, a other URLs: a site that does registration through a federated site, a
site that only does registration under HTTPS, and so on. Like any site that only does registration under HTTPS, and so on. Like any
HTTP client, HOBA clients MUST be able to handle redirection of these HTTP client, HOBA-http clients MUST be able to handle redirection of
URLs. [[There are a bunch of security issues to consider related to these URLs. [[ There are a bunch of security issues to consider
cases where a re-direct brings you off-origin.]] related to cases where a re-direct brings you off-origin. ]]
All additional services MUST be done in TLS-protected sessions
([RFC5246]).
6.1. Registration 6.1. Registration
Normally, a registration is expected to happen after a UA receives a Normally, a registration (also called "joining") is expected to
WWW-Authenticate for a web-origin and realm for which it has no happen after a UA receives a WWW-Authenticate for a web-origin and
associated CPK. The (protocol part of the) process of registration realm (for HOBA-http) or on demand (for HOBA-js) for which it has no
for a HOBA account on a server is relatively light-weight. The UA associated CPK. The process of registration for a HOBA account on a
generates a new key pair, and associates it with the web-origin/realm server is relatively light-weight. The UA generates a new key pair,
in question. The UA sets up a TLS-protected session, goes to the and associates it with the web-origin/realm in question.
registration URL ".well-known/hoba/register", and submits the CPK
using a POST message as described below. It is up to the server to Note that if the UA has a CPK associated with the web-origin, but not
for the realm concerned, then a new registration is REQUIRED. If the
server did not wish for that outcome, then it ought to use the same
or no realm.
The registration message for HOBA-http is sent as a POST message to
the URL ".well-known/hoba/register" with an HTML form (x-www-form-
encoded) described below; The registration message for HOBA-js can be
in any format specified by the server, but it could be the same as
the one described here for HOBA-http. It is up to the server to
decide what kind of user interaction is required before the account decide what kind of user interaction is required before the account
is finally set up. is finally set up.
If the UA has a CPK associated with the web-origin, but not for the The registration message sent to server has one mandatory field (pub)
realm concerned, then a new registration is REQUIRED. If the server and some optional fields that allow the UA to specify the type and
did not wish for that outcome, then it ought not use a different value of key and device identifiers that the UA wishes to use.
realm.
The POST message sent to the registration URL contains an HTML form
(x-www-form-encoded) with one mandatory field (pub) and some optional
fields that allow the UA to specify the type and value of key and
device identifiers that the UA wishes to use. [[The device stuff is
just a thought.]]
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
value intended to contain one of the values from Section 9.4. If value intended to contain one of the values from Section 9.4. If
this is not present then the mandatory to implement "DANE-hash" this is not present then the mandatory to implement "DANE-hash"
option MUST be used. 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 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."
o curtime: the number of milliseconds since the Unix epoch,
formatted as [[ not yet specified ]]. This is based on the
expectation that the synchronization between the browser's and
server's clocks is sufficiently reliable. This is used to guard
against the replay of a legitimate registration message. The
server needs to have a replay cache covering a signature timeout
window. This might be done using a database table that is keyed
(in the database sense of the term) using the signature bits. If
the signature is in the replay table, the server will reject it.
If the timestamp in the signature is outside the current replay
cache window then it also gets rejected.
[[ An addition of the ability for the server to reject a client with
potential time skew and give it a nonce (as with HOBA-http) would
allow the size of the replay cache to be set to just a few minutes
rather than a much longer period. Or the HOBA server could always
use a nonce method. This is worthy of more discussion. ]].
[[ A comment raised on the list was: how does the UA know that the
registration process has completed successfully or badly? That's not
yet handled. ]]
6.2. Associating Additional Keys to an Exiting Account 6.2. Associating Additional Keys to an Exiting Account
6.2.1. Moving private keys
It is common for a user to have multiple UAs, and to want all those It is common for a user to have multiple UAs, and to want all those
UAs to be able to authenticate to a single account. One method to UAs to be able to authenticate to a single account. One method to
allow a user who has an existing account to be able to authenticate allow a user who has an existing account to be able to authenticate
on a second device is to securely transport the private and public on a second device is to securely transport the private and public
keys and the origin information from the first device to the second. keys and the origin information from the first device to the second.
Previous history with such key transport has been spotty at best. As If this approach is taken, then there is no impact on the HOBA-http
an alternative, HOBA allows associating a CPK from the second device or HOBA-js so this is a pure UA implementation issue and not
to the account created on the first device. discussed further.
Instead of registering on the new device, the UA generates a new key 6.2.2. One time password
pair, associates it with the web-origin/realm in question, goes to
the URL for starting an association, ".well-known/hoba/ To enroll a new UA using an existing UA, the user requests a one-time
associate-start" in a TLS-protected session, and submits the new CPK password that will be entered in the new UA. On HOBA-http, this is
using a POST message. [[ More description is clearly needed here. ]] done with the URL ".well-known/hoba/associate-start" using a POST
The server's response to this request is a nonce with at least 128 message [[ more detail is clearly needed here ]]. The server
bits of entropy. That nonce SHOULD be easy for the user to copy and displays a one-time password that expires in a short amount of time
type, such as using Base32 encoding (see [RFC4648]). The user then (such as 30 minutes) on the currently enrolled UA. The new UA
uses the first UA to log into the origin, goes to the URL for generates a new CPK and sends it to the server. In HOBA-http, this
finishing an association, ".well-known/hoba/associate-finish", and is done with a POST to ".well-known/hoba/associate-finish" [[ more
submits the nonce using a POST message. [[ More description is detail needed here ]].
clearly needed here. ]]. The server then knows that the
authenticated user is associated with the second CPK. The server can The one-time password should be easy for a user to type into the new
choose to associate the two CPKs with one account. Whether to do so UA, but at the same time needs to have enough randomness to prevent
is entirely at the server's discretion however, but the server SHOULD an attacker from succeeding if they try to use the password during
make the outcome clear to the user. its short lifetime. After the server gets the password in the new
UA, it verifies the signature and verifies that the password supplied
is in a list of unexpired one-time passwords. If so, the server
knows that the authenticated user is associated with the second CPK.
The server can choose to associate the two CPKs with one account.
Whether to do so is entirely at the server's discretion however, but
the server needs make the outcome clear to the user.
Alternatively, if an already-enrolled UA is not available to the user
when they want to associate a new UA with an existing account, and
the site has an out-of-band communication mechanism such as email or
SMS associated with that account, the user can request that a one-
time password be sent to the user out of band. The user receives the
one-time password and, using the new UA, tells it to the server. On
HOBA-http, this is done with the URL ".well-known/hoba/associate-
from-oob" using a POST message [[ more detail is clearly needed here
]].
[[ Note: the hoba.ie implementation doesn't do this - I omitted a
human memorable OTP for now. The reason is I think the probability
that spammers would try those is too high. So maybe we should delete
this entirely? ]]
6.2.3. Out of band
There are various other ways in which a server can provide ways to
allow a new UA to be registered to the same account. For example,
simply providing a web page where, using the first UA, the user can
generate a URL (containing some cryptographic value) that the user
then later de-references on the second UA would suffice. The user
could have e-mail that URL to herself for example, of the web server
accessed at the first UA could automatically do that.
[[ Need to think about how much detail to put in here. Its all
fairly obvious, but we probably should talk about the security
considerations. The hoba.ie site btw has a few of these methods
implemented. ]]
6.3. Logging Out 6.3. Logging Out
When the user wishes to logout, the UA simply goes to ".well-known/ The user can tell the server it wishes to log out. With HOBA-http,
hoba/logout". The UA MAY also delete session cookies associated with this is done by going to the URL ".well-known/hoba/logout". The UA
the session. [[Is that right?, maybe a SHOULD- or MUST-delete would SHOULD also delete or modify session cookies associated with the
be better]] session so that the user's state is no longer "logged in."
The server-side MUST NOT allow TLS session resumption for any logged The server MUST NOT allow TLS session resumption for any logged out
out session and SHOULD also revoke or delete any cookies associated session. [[ Need to determine if this is needed or even a good idea.
with the session. ]]
The server SHOULD also revoke or delete any cookies associated with
the session.
6.4. Getting a Fresh Challenge 6.4. Getting a Fresh Challenge
If the UA would like a "fresh" challenge then it can send a POST or The UA can get a "fresh" challenge from the server. In HOBA-http, it
GET message to ".well-known/hoba/getchal". A successful (200 status) sends a POST message to ".well-known/hoba/getchal". If successful,
response MUST include a fresh (base64url encoded) HOBA challenge for the response response MUST include a fresh (base64url encoded) HOBA
this origin in the body of the response. challenge for this origin in the body of the response.
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. lengths of at least 2048 bits SHOULD be used.
[[Maybe we should add ECDSA with P256 for shorter signatures.]]
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
different accounts belonging to the user from the network with different accounts belonging to the user from the network with
possible bad consequences, especially if one of the private keys was possible bad consequences, especially if one of the private keys was
compromised somehow. 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 the string profitable so SHOULD be appropriately hard. In particular the string
generated by the server MUST be hard to guess, for whatever level of generated by the server MUST be hard to guess, for whatever level of
difficulty is chosen by the server. The server SHOULD NOT allow a difficulty is chosen by the server. The server SHOULD NOT allow a
random guess to reveal whether or not an account exists. random guess to reveal whether or not an account exists.
[[The potential impact on privacy of HOBA needs to be addressed. If [[ The potential impact on privacy of HOBA needs to be addressed. If
a site can use a 401 and a CPK to track users without permission that a site can use a 401 and a CPK to track users without permission that
would be not-so-nice so some guidance on how a UA could indicate to a would be not-so-nice so some guidance on how a UA could indicate to a
user that HOBA stuff is going on might be needed.]] user that HOBA stuff is going on might be needed. ]]
[[lots more TBD, be nice to your private keys etc. etc.]] [[ Lots more TBD, be nice to your private keys etc. etc. ]]
8.1. localStorage Security for Javascript 8.1. localStorage Security for Javascript
Our use of localStorage will undoubtedly be a cause for concern. Our use of localStorage will undoubtedly be a cause for concern.
localStorage uses the same-origin model which says that the scheme, localStorage uses the same-origin model which says that the scheme,
domain and port define a localStorage instance. Beyond that, any domain and port define a localStorage instance. Beyond that, any
code executing will have access to private keying material. Of code executing will have access to private keying material. Of
particular concern are XSS attacks which could conceivably take the particular concern are XSS attacks which could conceivably take the
keying material and use it to create UAs under the control of an keying material and use it to create UAs under the control of an
attacker. But XSS attacks are in reality across the board attacker. But XSS attacks are in reality across the board
skipping to change at page 19, line 47 skipping to change at page 16, line 7
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
thousands of sites the user visits. HOBA does not suffer from that thousands of sites the user visits. HOBA does not suffer from that
attack multiplier since each asymmetric key pair is unique per site/ attack multiplier since each asymmetric key pair is unique per site/
UA/user. UA/user.
8.2. Multiple Accounts on One User Agent
A shared UA with multiple accounts is possible if the account
identifier is stored along with the asymmetric key pair binding them
to one another. Multiple entries can be kept, one for each account,
and selected by the current user. This, of course, is fraught with
the possibility for abuse, since a server is potentially enrolling
the device for a long period and the user may not want to have to be
responsible for the credential for that long. To alleviate this
problem, the user can request that the credential be erased from the
browser. Similarly, during the enrollment phase, a user could
request that the key pair only be kept for a certain amount of time,
or that it not be stored beyond the current browser session.
9. IANA Considerations 9. IANA Considerations
9.1. HOBA Authentication Scheme 9.1. HOBA Authentication Scheme
Authentication Scheme Name: HOBA Authentication Scheme Name: HOBA
Pointer to specification text: [[ this document ]] Pointer to specification text: [[ 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. [[But we need to figure out the proxy angle;-)]] servers or proxies. [[ Still need to figure out what it means to do
this through proxies. ]]
9.2. .well-known URLs 9.2. .well-known URLs
We probably want a new registry for the labels beneath .well-known/ We probably want a new registry for the labels beneath .well-known/
hoba so that other folks can add additional features in a controlled hoba so that other folks can add additional features in a controlled
way, e.g. for CPK/account revocation or whatever. way, e.g. for CPK/account revocation or whatever.
9.3. Algorithm Names 9.3. Algorithm Names
TBD, hopefully re-use and existing registry TBD, hopefully re-use and existing registry
"0" means RSA-SHA256 "0" means RSA-SHA256
"1" means RSA-SHA1 "1" means RSA-SHA1
9.4. Key Identifier Types 9.4. Key Identifier Types
skipping to change at page 20, line 42 skipping to change at page 17, line 20
conforming to [RFC3986] is ok.i conforming to [RFC3986] is ok.i
"2" means an unformatted string, at the user's/UA's whim "2" means an unformatted string, at the user's/UA's whim
9.5. Device Identifier Types 9.5. Device Identifier Types
"0" means an unformatted nickname, at the user's/UA's whim "0" means an unformatted nickname, at the user's/UA's whim
10. Implementation Status 10. Implementation Status
[[Note to RFC editor - please delete this section before [[ Note to RFC editor - please delete this section before
publication.]] publication. ]]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in Internet-Draft, and is based on a proposal described in [RFC6982].
[I-D.sheffer-running-code]. The description of implementations in The description of implementations in this section is intended to
this section is intended to assist the IETF in its decision processes assist the IETF in its decision processes in progressing drafts to
in progressing drafts to RFCs. Please note that the listing of any RFCs. Please note that the listing of any individual implementation
individual implementation here does not imply endorsement by the here does not imply endorsement by the IETF. Furthermore, no effort
IETF. Furthermore, no effort has been spent to verify the has been spent to verify the information presented here that was
information presented here that was supplied by IETF contributors. supplied by IETF contributors. This is not intended as, and must not
This is not intended as, and must not be construed to be, a catalog be construed to be, a catalog of available implementations or their
of available implementations or their features. Readers are advised features. Readers are advised to note that other implementations may
to note that other implementations may exist. exist.
According to [RFC Editor: replace by a reference to this document], According to [RFC6982] "this will allow reviewers and working groups
"this will allow reviewers and working groups to assign due to assign due consideration to documents that have the benefit of
consideration to documents that have the benefit of running code, by running code, by considering the running code as evidence of valuable
considering the running code as evidence of valuable experimentation experimentation and feedback that has made the implemented protocols
and feedback that has made the implemented protocols more mature. It more mature. It is up to the individual working groups to use this
is up to the individual working groups to use this information as information as they see fit".
they see fit".
At the time of writing there are two known implementations. One done At the time of writing there are two known implementations. One done
by Stephen Farrell of HOBA-HTTP and a HOBA-JS variant and another by by Stephen Farrell of HOBA-HTTP and a HOBA-JS variant implements the
Michael Thomas of an HOBA-JS variant. More details will be provided -01 version of HOBA and is available from https://hoba.ie/ which site
in future drafts as those implementations mature and e.g. open-source also includes a demonstration of HOBA.
licensing terms and release schedules are figured out.
11. Acknowledgements There is another implementation by Michael Thomas of an HOBA-JS
variant.
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: Julian Reschke [[and many more to preparation of this specification: Julian Reschke, James Manger,
be added]. All errors and stupidities are of course the editors' Michael Sweet [[ and many more to be added ]]. All errors and
fault. stupidities are of course the editors' fault.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-23
(work in progress), July 2013.
[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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence,
S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[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, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005.
[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, Uniform Resource Identifiers (URIs)", RFC 5785, April
April 2010. 2010.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
December 2011. 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
12.2. Informative References 12.2. Informative References
[I-D.sheffer-running-code] [I-D.ietf-httpbis-p7-auth]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
Code: the Implementation Status Section", (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22
draft-sheffer-running-code-06 (work in progress), (work in progress), February 2013.
June 2013.
[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.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[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, July
July 2013. 2013.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July
2013.
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 "memorizable passwords". that can be remembered by the user, called "memorizable passwords".
There is plenty of good research on how users typically use There is plenty of good research on how users typically use
memorizable passwords ([[ handful of citations goes here ]]), but memorizable passwords ([[ handful of citations goes here ]]), but
some of the highlights are that users typically try hard to reuse some of the highlights are that users typically try hard to reuse
passwords on as many web sites as possible, and that web sites often passwords on as many web sites as possible, and that web sites often
use either email addresses or users' names as the identifier that use either email addresses or users' names as the identifier that
skipping to change at page 23, line 35 skipping to change at page 20, line 8
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.
[[ Say a bit about non-memorizable passwords. Still subject to [[ Say a bit about non-memorizable passwords. Still subject to
database attack, although that doesn't give the attacker knowledge database attack, although that doesn't give the attacker knowledge
for other systems. Safe if digest authentication is used, but that's for other systems. Safe if digest authentication is used, but that's
rare. ]] rare. ]]
Appendix B. Examples Appendix B. Examples
[[Will add more later and probably use example.org.]] [[ Will add more later and probably use example.org. Note these
still use the -01 version of the "origin" abnf production. ]]
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://hoba-local.ie. Carriage-returns have been added the origin https://hoba-local.ie. Carriage-returns have been added
and need to be removed to validate the example. and need to be removed to validate the example.
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDNF6tZUbsM7ZrO MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDNF6tZUbsM7ZrO
5Lyzvn15lJAfOz7j7xdc3hmeSOfh/DCiJWwE5qqffrOvOvXYN+qUTlsXPeBYdrz/ 5Lyzvn15lJAfOz7j7xdc3hmeSOfh/DCiJWwE5qqffrOvOvXYN+qUTlsXPeBYdrz/
my0YYC02u2QFhDbFRvpM/EuMzZUWTQzkKyU7nSjtPqlLZJJ/Rh6PnjTgImoIMn92 my0YYC02u2QFhDbFRvpM/EuMzZUWTQzkKyU7nSjtPqlLZJJ/Rh6PnjTgImoIMn92
JZgJZgl/vzd29K5Z94JzdJ4Z5bNmQ/gCpjlv0Wvi+GpJ3lDo1csDEyxATxyTUx1J JZgJZgl/vzd29K5Z94JzdJ4Z5bNmQ/gCpjlv0Wvi+GpJ3lDo1csDEyxATxyTUx1J
skipping to change at page 25, line 14 skipping to change at page 21, line 28
Authorization: result="Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vq Authorization: result="Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vq
Ww.zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0=.xXSFdZ-7ahM.r1ZX Ww.zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0=.xXSFdZ-7ahM.r1ZX
AWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfoK__W AWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfoK__W
_Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hKt4bC _Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hKt4bC
tP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19JLTUy tP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19JLTUy
aisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7qf6l aisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7qf6l
ORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq8mea ORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq8mea
qRXMhoQWHGLweFTNYw" qRXMhoQWHGLweFTNYw"
Appendix C. Changes
[[Note to RFC editor - please delete this section before
publication.]]
C.1. WG-01
o A few clarifications/fixes.
o Added getchal interface and expires attribute
o Added Implementation Status section
o Added examples
C.2. WG-00
o First WG draft, replacing draft-farrell-httpbis-hoba-02
o Fleshed out HTTP scheme some more.
o Fleshed out registration form more.
Authors' Addresses Authors' Addresses
Stephen Farrell Stephen Farrell
Trinity College Dublin Trinity College Dublin
Dublin, 2 Dublin 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
Michael Thomas Michael Thomas
Phresheez Phresheez
Email: mike@phresheez.com Email: mike@phresheez.com
 End of changes. 80 change blocks. 
550 lines changed or deleted 403 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/