draft-ietf-httpauth-hoba-02.txt   draft-ietf-httpauth-hoba-03.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: April 21, 2014 VPN Consortium Expires: October 20, 2014 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
October 18, 2013 April 18, 2014
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-02 draft-ietf-httpauth-hoba-03
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 any 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. authentication schemes that require passwords.
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 April 21, 2014. This Internet-Draft will expire on October 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 8 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 8
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 9 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 9
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 10 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 10
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Associating Additional Keys to an Exiting Account . . . . 12 6.2. Associating Additional Keys to an Exiting Account . . . . 13
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 13 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 13
6.2.2. One time password . . . . . . . . . . . . . . . . . . 13 6.2.2. One time password . . . . . . . . . . . . . . . . . . 13
6.2.3. Out of band . . . . . . . . . . . . . . . . . . . . . 14 6.2.3. Out of band . . . . . . . . . . . . . . . . . . . . . 14
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 14 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 14
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 14 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. localStorage Security for Javascript . . . . . . . . . . 15 8.1. localStorage Security for Javascript . . . . . . . . . . 15
8.2. Multiple Accounts on One User Agent . . . . . . . . . . . 16 8.2. Multiple Accounts on One User Agent . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 5 skipping to change at page 3, line 5
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 19 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 19
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[[ Commentary is in double-square brackets, like this. Fewer things [[ Commentary is in double-square brackets, like this. Fewer things
this time.]] this time.]]
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 [RFC2616] authentication scheme and for that can be used as an HTTP authentication scheme
Javascript-based authentication embedded in HTML. The main goal of [I-D.ietf-httpbis-p7-auth] and for Javascript-based authentication
HOBA is to offer an easy-to-implement authentication scheme that is embedded in HTML. The main goal of HOBA is to offer an easy-to-
not based on passwords, but that can easily replace HTTP or HTML implement authentication scheme that is not based on passwords, but
forms-based password authentication. Deployment of HOBA can reduce that can easily replace HTTP or HTML forms-based password
or eliminate password entries in databases, with potentially authentication. Deployment of HOBA can reduce or eliminate password
significant security benefits. entries in databases, with potentially 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; see [RFC2617] for the original framework for such schemes [I-D.ietf-httpbis-p7-auth]. As a
specification, and [I-D.ietf-httpbis-p7-auth] for clarifications and JavaScript design, HOBA demonstrates a way for clients and servers to
updates to the HTTP authentication framework. As a JavaScript interact using the same credentials that are used by the HTTP
design, HOBA demonstrates a way for clients and servers to interact authentication scheme.
using the same credentials that are used by the HTTP authentication
scheme.
Current HTTP authentication methods (Basic and Digest), as well as Current HTTP authentication methods (Basic and Digest), as well as
username/password authentication using web forms, have been in use username/password authentication using web forms, have been in use
for many years, but being based on passwords, are susceptible to for many years, but being based on passwords, are susceptible to
theft of server-side databases. Instead of passwords, HOBA uses theft of server-side databases. Instead of passwords, HOBA uses
digital signatures as an authentication mechanism. HOBA also adds digital signatures as an authentication mechanism. HOBA also adds
useful features such as credential management and session logout. In useful features such as credential management and session logout. In
HOBA, the client creates a new public-private key pair for each host HOBA, the client creates a new public-private key pair for each host
("web-origin" [RFC6454]) to which it authenticates. These keys are ("web-origin" [RFC6454]) to which it authenticates. These keys are
used in HOBA for HTTP clients to authenticate themselves to servers used in HOBA for HTTP clients to authenticate themselves to servers
in the HTTP protocol or in a Javascript authentication program. in the HTTP protocol or in a Javascript authentication program.
Session management with HOBA is identical to username/password Session management with HOBA is identical to username/password
session management. Typically, the session management tool (such as session management. Typically, the session management tool (such as
PHP, Python CGI, and so on) inserts a session cookie into the output 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 to the browser. HOBA does nothing to help or hurt session cookie
hijacking; TLS is still required for that. hijacking; TLS is still required for that. If the authentication is
not bound to HTTP sessions, even TLS cannot help against all attacks.
HOBA keys are "bare keys", so there is no need for the semantic HOBA keys are "bare keys", so there is no need for the semantic
overhead of PKIX certificates, particularly with respect to naming overhead of PKIX certificates, particularly with respect to naming
and trust anchors. The client public key ("CPK") structures in HOBA and trust anchors. The client public key ("CPK") structures in HOBA
do not have any publicly-visible identifier for the user who do not have any publicly-visible identifier for the user who
possesses the corresponding private key, nor the web-origin with possesses the corresponding private key, nor the web-origin with
which the client is using the CPK. which the client is using the CPK.
HOBA also defines some services that are required for modern HTTP HOBA also defines some services that are required for modern HTTP
authentication: authentication:
skipping to change at page 5, line 49 skipping to change at page 5, line 49
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. The term
"unreserved" means that the field does not have a specific format
defined.
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. (base64url
able to use at least 32 bits of randomness in generating a nonce. encoding is defined in [RFC4648].) UAs MUST be able to use at
UAs SHOULD be able to use 64 or more bits of randomness for least 32 bits of randomness in generating a nonce. UAs SHOULD be
nonces. 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 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 default process will be "https://www.example.com:8080". There is no
for the port number, which 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 [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 7, line 17 skipping to change at page 7, line 17
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. also base64url encoded.
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. 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"
skipping to change at page 8, line 22 skipping to change at page 8, line 22
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 The server MUST check the cryptographic correctness of the signature
based on a public key it knows for the kid in the signatures, and if based on a public key it knows for the kid in the signatures, and if
the server cannot do that, or if the signature fails cryptographic the server cannot do that, or if the signature fails cryptographic
checks, then validation has failed. The server can use any checks, then validation has failed. The server can use any
additional mechanisms to validate the signature. If the validation additional mechanisms to validate the signature. If the validation
fails, or if the server chooses reject the signature for any reason fails, or if the server chooses reject the signature for any reason
whatsoever, the server aborts the transaction via a 403 Forbidden whatsoever, the server aborts the transaction via a 403 Forbidden
HTTP response. HTTP response. [[ This maybe should be 401 Unauthorized. ]]
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 possible within the time attribute allows. This means that replay is possible within the time
window specified by the "expires" value chosen by the server. window specified by the "expires" value chosen by the server.
Servers can attempt to detect any such replay and MAY react to such Servers can attempt to detect any such replay and MAY react to such
replays by responding with a second (or subsequent) 401-status HTTP replays by responding with a second (or subsequent) 401-status HTTP
response containing a new challenge. response containing a new challenge. [[ How could such detection be
done in face of cut-and-paste attacks? ]]
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 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
skipping to change at page 11, line 23 skipping to change at page 11, line 23
new session is started before any of the actions described here are new session is started before any of the actions described here are
performed. performed.
HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for
performing many tasks: "https://www.example.com/.well-known/hoba". performing many tasks: "https://www.example.com/.well-known/hoba".
These URLs are based on the name of the host that the HTTP client is These URLs are based on the name of the host that the HTTP client is
accessing. 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-http clients MUST be able to handle redirection of HTTP client, HOBA-http clients MUST be able to handle redirection of
these URLs. [[ There are a bunch of security issues to consider these URLs. [[ There are a bunch of security issues to consider
related to cases where a re-direct brings you off-origin. ]] related to cases where a re-direct brings you off-origin. ]]
6.1. Registration 6.1. Registration
Normally, a registration (also called "joining") is expected to Normally, a registration (also called "joining") is expected to
happen after a UA receives a WWW-Authenticate for a web-origin and happen after a UA receives a WWW-Authenticate for a web-origin and
realm (for HOBA-http) or on demand (for HOBA-js) for which it has no realm (for HOBA-http) or on demand (for HOBA-js) for which it has no
associated CPK. The process of registration for a HOBA account on a associated CPK. The process of registration for a HOBA account on a
server is relatively light-weight. The UA generates a new key pair, server is relatively light-weight. The UA generates a new key pair,
and associates it with the web-origin/realm in question. and associates it with the web-origin/realm in question.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
The registration message sent to server has one mandatory field (pub) The registration message sent to server has one mandatory field (pub)
and some optional fields that allow the UA to specify the type and and some optional fields that allow the UA to specify the type and
value of key and device identifiers that the UA wishes to use. value of key and device identifiers that the UA wishes to use.
o pub: is a mandatory field containing the PEM formatted public key o pub: is a mandatory field containing the PEM formatted public key
of the client. See Appendix C of [RFC6376] for an example of how of the client. See Appendix C of [RFC6376] for an example of how
to generate this key format. to generate this key format.
o kidtype: contains the type of key identifier, this is a numeric o kidtype: contains the type of key identifier, this is a numeric
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 hashed public
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 MUST be used.
skipping to change at page 12, line 45 skipping to change at page 12, line 45
window. This might be done using a database table that is keyed window. This might be done using a database table that is keyed
(in the database sense of the term) using the signature bits. If (in the database sense of the term) using the signature bits. If
the signature is in the replay table, the server will reject it. the signature is in the replay table, the server will reject it.
If the timestamp in the signature is outside the current replay If the timestamp in the signature is outside the current replay
cache window then it also gets rejected. cache window then it also gets rejected.
[[ An addition of the ability for the server to reject a client with [[ 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 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 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 rather than a much longer period. Or the HOBA server could always
use a nonce method. This is worthy of more discussion. ]]. use a nonce method. This is worthy of more discussion. ]].
[[ A comment raised on the list was: how does the UA know that the [[ A comment raised on the list was: how does the UA know that the
registration process has completed successfully or badly? That's not registration process has completed successfully or badly? That's not
yet handled. ]] yet handled. Also need to specify what happens if more data is
needed. ]]
6.2. Associating Additional Keys to an Exiting Account 6.2. Associating Additional Keys to an Exiting Account
6.2.1. Moving private keys 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.
If this approach is taken, then there is no impact on the HOBA-http If this approach is taken, then there is no impact on the HOBA-http
or HOBA-js so this is a pure UA implementation issue and not or HOBA-js so this is a pure UA implementation issue and not
discussed further. discussed further.
skipping to change at page 13, line 51 skipping to change at page 14, line 5
SMS associated with that account, the user can request that a one- 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 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 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- HOBA-http, this is done with the URL ".well-known/hoba/associate-
from-oob" using a POST message [[ more detail is clearly needed here from-oob" using a POST message [[ more detail is clearly needed here
]]. ]].
[[ Note: the hoba.ie implementation doesn't do this - I omitted a [[ Note: the hoba.ie implementation doesn't do this - I omitted a
human memorable OTP for now. The reason is I think the probability 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 that spammers would try those is too high. So maybe we should delete
this entirely? ]] this entirely? ]]
6.2.3. Out of band 6.2.3. Out of band
There are various other ways in which a server can provide ways to 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, 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 simply providing a web page where, using the first UA, the user can
generate a URL (containing some cryptographic value) that the user generate a URL (containing some cryptographic value) that the user
then later de-references on the second UA would suffice. 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 could have e-mail that URL to herself for example, of the web server
accessed at the first UA could automatically do that. accessed at the first UA could automatically do that.
[[ Need to think about how much detail to put in here. Its all [[ Need to think about how much detail to put in here. Its all
fairly obvious, but we probably should talk about the security fairly obvious, but we probably should talk about the security
considerations. The hoba.ie site btw has a few of these methods considerations. The hoba.ie site btw has a few of these methods
implemented. ]] implemented. ]]
6.3. Logging Out 6.3. Logging Out
The user can tell the server it wishes to log out. With HOBA-http, The user can tell the server it wishes to log out. With HOBA-http,
this is done by going to the URL ".well-known/hoba/logout". The UA this is done by going to the URL ".well-known/hoba/logout". The UA
SHOULD also delete or modify session cookies associated with the SHOULD also delete session cookies associated with the session so
session so that the user's state is no longer "logged in." that the user's state is no longer "logged in."
The server MUST NOT allow TLS session resumption for any logged out The server MUST NOT allow TLS session resumption for any logged out
session. [[ Need to determine if this is needed or even a good idea. session. [[ Need to determine if this is needed or even a good idea.
]] ]]
The server SHOULD also revoke or delete any cookies associated with The server SHOULD also revoke or delete any cookies associated with
the session. the session.
6.4. Getting a Fresh Challenge 6.4. Getting a Fresh Challenge
skipping to change at page 15, line 14 skipping to change at page 15, line 16
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. Any authentication
mechanism allows tracking within account. ]]
[[ 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 16, line 30 skipping to change at page 16, line 34
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. [[ Still need to figure out what it means to do servers or proxies. [[ Still need to figure out what it means to do
this through proxies. ]] 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
[[ Will most likely add an elliptic curve signature mechanism. ]]
9.4. Key Identifier Types 9.4. Key Identifier Types
"0" means a hashed public key, as done in DANE. [RFC6698] "0" means a hashed public key, as done in DANE. [RFC6698]
"1" means a URI, such as a mailto: or acct: URI, but anything "1" means a URI, such as a mailto: or acct: URI, but anything
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 [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
skipping to change at page 18, line 6 skipping to change at page 18, line 6
by Stephen Farrell of HOBA-HTTP and a HOBA-JS variant implements the by Stephen Farrell of HOBA-HTTP and a HOBA-JS variant implements the
-01 version of HOBA and is available from https://hoba.ie/ which site -01 version of HOBA and is available from https://hoba.ie/ which site
also includes a demonstration of HOBA. 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 an HOBA-JS
variant. variant.
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: Julian Reschke, James Manger, preparation of this specification: Julian Reschke, James Manger,
Michael Sweet [[ and many more to be added ]]. All errors and Michael Sweet, Ilari Liusvaara, [[ and many more to be added ]]. All
stupidities are of course the editors' fault. errors and stupidities are of course the editors' fault.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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, RFC Resource Identifier (URI): Generic Syntax", STD 66, 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.
skipping to change at page 20, line 8 skipping to change at page 19, line 46
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. Note these [[ Will add more later and probably use example.org. Note these
still use the -01 version of the "origin" abnf production. ]] 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
 End of changes. 33 change blocks. 
60 lines changed or deleted 58 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/