draft-ietf-httpauth-hoba-00.txt   draft-ietf-httpauth-hoba-01.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: November 2, 2013 VPN Consortium Expires: January 16, 2014 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
may 2013 July 15, 2013
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-00 draft-ietf-httpauth-hoba-01
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 a 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 with all the negative
attributes that come with password-based systems. HOBA can be attributes that come with password-based systems.
integrated with account management and other applications running
over HTTP and supports portability, so a user can associate more than
one device or origin-bound key with the same service. We also
describe a way in which the HOBA design can be used from a Javascript
web client. When deployed, HOBA will be a drop-in replacement for
password-based HTTP authentication or JavaScript authentication.
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 November 2, 2013. This Internet-Draft will expire on January 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Comparison of HOBA and Current Password Authentication . . 5 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . . 6 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . . 6
3. HOBA HTTP Authentication Mechanism . . . . . . . . . . . . . . 8 3. HOBA HTTP Authentication Mechanism . . . . . . . . . . . . . . 8
4. Using HOBA-http . . . . . . . . . . . . . . . . . . . . . . . 9 4. Using HOBA-http . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9 4.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10
4.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Authentication Phase . . . . . . . . . . . . . . . . . . . 10 4.3. Authentication Phase . . . . . . . . . . . . . . . . . . . 10
4.4. Logging in on a New User Agent . . . . . . . . . . . . . . 11 4.4. Logging in on a New User Agent . . . . . . . . . . . . . . 11
5. Using HOBA-js . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Using HOBA-js . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. User Join . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. User Join . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. User Login . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. User Login . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Enrolling a New User Agent . . . . . . . . . . . . . . . . 12 5.4. Enrolling a New User Agent . . . . . . . . . . . . . . . . 12
5.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 13 5.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 13
5.6. Signature Parameters . . . . . . . . . . . . . . . . . . . 13 5.6. Signature Parameters . . . . . . . . . . . . . . . . . . . 13
5.7. Session Management . . . . . . . . . . . . . . . . . . . . 15 5.7. Session Management . . . . . . . . . . . . . . . . . . . . 15
5.8. Multiple Accounts on One User Agent . . . . . . . . . . . 15 5.8. Multiple Accounts on One User Agent . . . . . . . . . . . 15
5.9. Oddities . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.9. Oddities . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Additional Services . . . . . . . . . . . . . . . . . . . . . 16 6. Additional Services . . . . . . . . . . . . . . . . . . . . . 16
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Associating Additional Keys to an Exiting Account . . . . 17 6.2. Associating Additional Keys to an Exiting Account . . . . 17
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 18
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 18 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. localStorage Security for Javascript . . . . . . . . . . . 18 8.1. localStorage Security for Javascript . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 19 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 20
9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 19 9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 20
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 19 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . . 20 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . . 20
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Problems with Passwords . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Problems with Passwords . . . . . . . . . . . . . . . 23
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 23
C.1. WG-00 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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. As you'll see
there are a bunch of details still to be figured out. Feedback on there are a bunch of details still to be figured out. Feedback on
those is very welcome. Also note that the authors fully expect that 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 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 draft; they're both here now so readers can see some alternatives and
maybe support particular proposals. ]] maybe support particular proposals. ]]
HTTP Origin-Bound Authentication (HOBA) is a proposal for an HTTP Origin-Bound Authentication (HOBA) is an authentication design
authentication design that can be used as an HTTP authentication that can be used as an HTTP authentication scheme and for Javascript-
scheme and for Javascript-based authentication embedded in HTML. The based authentication embedded in HTML. The main goal of HOBA is to
main goal of HOBA is to offer an easy-to-implement authentication offer an easy-to-implement authentication scheme that is not based on
scheme that is not based on passwords, but that can easily replace passwords, but that can easily replace HTTP or HTML forms-based
HTTP or HTML forms-based password authentication. If deployment of password authentication. If deployment of HOBA reduces the number of
HOBA reduces the number of password entries in databases by any password entries in databases by any appreciable amount, then it
appreciable amount, then it would be worthwhile. As an HTTP would be worthwhile. As an HTTP authentication scheme, it would work
authentication scheme, it would work in the current HTTP 1.0 and HTTP in the current HTTP 1.0 and HTTP 1.1 authentication framework, and
1.1 authentication framework, and will very likely work with whatever will very likely work with whatever changes are made to the HTTP
changes are made to the HTTP authentication scheme in HTTP 2.0. As a authentication scheme in HTTP 2.0. As a JavaScript design, HOBA
JavaScript design, HOBA demonstrates a way for clients and servers to demonstrates a way for clients and servers to interact using the same
interact using the same credentials that are use by the HTTP credentials that are use by the HTTP authentication scheme.
authentication scheme.
The HTTP specification defines basic and digest authentication The HTTP specification defines basic and digest authentication
methods for HTTP that have been in use for many years, but which, methods for HTTP that have been in use for many years, but which,
being based on passwords, are susceptible to theft of server-side being based on passwords, are susceptible to theft of server-side
databases. (See [RFC2617] for the original specification, and databases. (See [RFC2617] for the original specification, and
[I-D.ietf-httpbis-p7-auth] for clarifications and updates to the [I-D.ietf-httpbis-p7-auth] for clarifications and updates to the
authentication mechanism.) Even though few large web sites use basic authentication mechanism.) Even though few large web sites use basic
and digest authentication, they still use username/password and digest authentication, they still use username/password
authentication and thus have large susceptible server-side databases authentication and thus have large susceptible server-side databases
of passwords. of passwords.
Instead of passwords, HOBA uses digital signatures as an Instead of passwords, HOBA uses digital signatures as an
authentication mechanism. HOBA also adds useful features such as authentication mechanism. HOBA also adds useful features such as
credential management and session logout. In HOBA, the client credential management and session logout. In HOBA, the client
creates a new public-private key pair for each host ("web-origin") to creates a new public-private key pair for each host ("web-origin") to
which it authenticates; web-origins are defined in [RFC6454]. These which it authenticates; web-origins are defined in [RFC6454]. These
keys are used in HOBA for HTTP clients to authenticate themselves to keys are used in HOBA for HTTP clients to authenticate themselves to
servers in the HTTP protocol or in a Javascript authentication servers in the HTTP protocol or in a Javascript authentication
program. HOBA keys need not be stored in public key certificates, program.
but instead in subjectPublicKeyInfo structures from PKIX [RFC5280].
Because these are generally "bare keys", there is none of the HOBA keys need not be stored in public key certificates. Because
semantic overhead of PKIX certificates, particularly with respect to these are generally "bare keys", there is none of the semantic
naming and trust anchors. Thus, client public keys ("CPKs") do not overhead of PKIX certificates, particularly with respect to naming
have any publicly-visible identifier for the user who possesses the and trust anchors. Thus, client public keys ("CPKs") do not have any
publicly-visible identifier for the user who possesses the
corresponding private key, nor the web-origin with which the client corresponding private key, nor the web-origin with which the client
is using the CPK. is using the CPK. HOBA keys are stored in subjectPublicKeyInfo
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. HOBA allows servers to define their own policies for
binding CPKs with accounts during account registration. binding 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. For
example if a user loses the computer or mobile device in which example if a user loses the computer or mobile device in which
state is stored. HOBA allows for clients to tell servers to state is stored. HOBA allows for clients to tell servers to
delete the association between a CPK and an account. delete the association between an existing CPK and an account.
o Logout features can be useful for user agents, so HOBA defines a o Logout features can be useful for UAs, so HOBA defines a way to
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 user agents for the same account. active from different UAs for the same account.
1.1. Comparison of HOBA and Current Password Authentication o Since there are always devices and applications in which state of
the art digital signature mechanism runtimes are significant, and
since HTTP authentication in theory requires that every HTTP
request to a given realm have a signature in an "Authorization"
header field, and since HOBA is a challenge response scheme, we
also define a way in which HTTP servers can indicate the duration
for which they will consider a given challenge value to be valid.
As a consequence we also define a way for UAs to fetch a fresh
challenge.
[[ This will be a few paragraphs explaining how HOBA can be used as a 1.1. Interfacing to Applications (Cookies)
drop-in replacement for the common form-and-cookie authentication
used today. It will show how similar many of the concepts are, and HOBA can be used as a drop-in replacement for password-based user
also point out some of the advantages sites will get by changing to authentication schemes used in common web applications. The simplest
HOBA. ]] way in which this can be done is to (re-)direct the UA to a HOBA
"Login" URL and for the response to a successful HTTP request
containing a HOBA signature to set a session cookie [RFC6265].
Further interactions with the web application will then be secured
via the session cookie, as is commonly done today.
While cookies are bearer tokens, and thus weaker than HOBA
signatures, they are currently ubiquitously used. If non-bearer
token session continuation schemes are developed in future in the
IETF or elsewhere, then those can interface to HOBA as easily as with
any password based authentication scheme.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
A client public key ("CPK") is the public key and associated A client public key ("CPK") is the public key and associated
cryptographic parameters needed for a server to validate a signature. cryptographic parameters needed for a server to validate a signature.
skipping to change at page 6, line 14 skipping to change at page 6, line 33
account creation processes. An account may have many CPKs that are account creation processes. An account may have many CPKs that are
considered equivalent in terms of being usable for authentication, considered equivalent in terms of being usable for authentication,
but the meaning of "equivalent" is really up to the server and is not but the meaning of "equivalent" is really up to the server and is not
defined here. defined here.
When describing something that is specific to HOBA as an HTTP When describing something that is specific to HOBA as an HTTP
authentication mechanism or HOBA as a JavaScript implementation, this authentication mechanism or HOBA as a JavaScript implementation, this
document uses the terms "HOBA-http" and "HOBA-js", respectively. document uses the terms "HOBA-http" and "HOBA-js", respectively.
Web client: the content and javascript code that run within the Web client: the content and javascript code that run within the
context of a single user agent instance (such as a tab in a web context of a single UA instance (such as a tab in a web browser).
browser).
User agent (UA): typically, but not always, a web browser doing HOBA. User agent (UA): typically, but not always, a web browser.
User: a person who is running a UA. In this document, "user" does User: a person who is running a UA. In this document, "user" does
not mean "user name" or "account name". not mean "user name" or "account name".
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] notation of [RFC5234]
2. The HOBA Authentication Scheme 2. The HOBA Authentication Scheme
A UA that implements HOBA maintains a list of web-origins and realms. A UA that implements HOBA maintains a list of web-origins and realms.
The UA also maintains one or more client credentials for each web- The UA also maintains one or more client credentials for each web-
origin/realm combination for which it has created a CPK. origin/realm combination for which it has created a CPK.
On receipt of a challenge (and optional realm) from a server, the On receipt of a challenge (and optional realm) from a server, the
client marshals an HOBA to-be-signed (TBS) blob that includes the 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 using the CPK and the challenge string; and signs that hashed blob with the
the hash algorithm identified with the challenge and the private key private key corresponding to the CPK for that web-origin. The
corresponding to the CPK for that web-origin. The formatting chosen formatting chosen for this TBS blob is chosen so as to make server-
for this TBS blob is chosen so as to make server-side signature side signature verification as simple as possible for a wide-range of
verification as simple as possible for a wide-range of current server current server tooling.
tooling, e.g. including relatviely simple PHP scripts. [[ref for
PHP?]]
[[Note - we do support different forms of key identifier, but
currently only implicitly. The idea is that when you register a CPK
then you get to say what type of key identifier you're using (if that
is needed or even makes sense). When authenticating, the site
doesn't need to be told that again since it can find the CPK or not
based on the key identifier value. One could argue that the type of
key indentifier here would allow a site to support two octet-wise
identical key identifier values but with different types. Not sure
how useful that is, migth be for those who want keys to be 3rd party
validated.]]
Figure 1 specifies the abnf for the signature input. [[This Figure 1 specifies the ABNF for the signature input.
definition is core to the security of HOBA and should ideally be
based on some cryptographic protocol that's been well known and
studied for ages. We do plan to go looking for such a protocol,
(maybe ideally more than 20 years old;-) but have yet to do that.]]
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. UAs MUST be able to use at least 32 bits of randomness encoded before being included in the HOBA-TBS value. UAs MUST be
in generating a nonce. UAs SHOULD be able to use up to 64 bits of able to use at least 32 bits of randomness in generating a nonce.
randomness for nonces. [[Not sure what's right here. Also - UAs SHOULD be able to use up to 64 bits of randomness for nonces.
might be better to add a "nonce-type" as well, so we could have
e.g. TLS channel bindings as an option.]]
o alg: specifies the signature algorithm being used encoded as an o alg: specifies the signature algorithm being used encoded as an
ASCII charecter 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. supported, RSA-SHA1 MAY be supported. The IANA registered
algorithm values are encoded as ASCII numbers; for example, the
encoding of RSA-SHA256 is 0x30.
o origin: is the web origin expressed as the catentation 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 are from [RFC3986]. These are not
base64 encoded as they will be most readily available to the base64 encoded as they will be most readily available to the
server in plain text. server in plain text. For example, if accessing the URL
"https://www.example.com:8080/foo" then the bytes input to the
signature process will be "httpswww.example.com8080"
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 30 skipping to change at page 8, line 34
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. [[Expect more changes here. This is very
like JOSE's compact form and maybe ought be an instance of that.]] 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
HOBA will support the idea of multiple users on the same user agent.
This will be useful for the problem of "can I use your browser to
check my mail..." and so on. It is [[ currently ]] described only in
the HOBA-js section, but will apply equally to HOBA-http. [[There
are implications beyond the discussion in HOBA-js here in that there
would only be a single CPK for a set of users for a given origin
since normative HOBA-http has no clue at all about users and the
like. This needs more thought.]]
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. HOBA HTTP Authentication 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.
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 a o The "challenge" attribute MUST be included. The challenge is the
string of base64url encoded octets that the server wants the string made up of the base64url encoded octets that the server
client to sign in its response. The challenge SHOULD be unique wants the client to sign in its response. The challenge SHOULD be
for every HTTP 401 response in order to prevent replay attacks unique for every HTTP 401 response in order to prevent replay
from passive observers. attacks from passive observers.
o An "expires" attribute MUST be included that specifies the number
of seconds from the time the HTTP response is emitted for which
responses to this challenge can be accepted.
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 HOBA-http client encodes When the "client response" is created, the UA encodes the HOBA
the HOBA client-result (a string matching the HOBA-RES production in client-result (a string matching the HOBA-RES production in Figure 2
Figure 2 as an auth-param with the name "result" and returns that in as an auth-param with the name "result" and returns that in the
the Authorization header. Authorization header.
The HOBA-http authentication mechanism allows for the use of cookies Note that a HOBA signature is good for however long the expires
for preserving state between protected resources in one HTTP realm. attribute allows. This means that replay is potentially possible
This means that the server need only send the WWW-Authenticate header within the time window specified by the "expires" value chosen by the
field once, and can rely on cookie management for keeping state. server. Servers SHOULD attempt to detect any such replay and MAY
react to such replays by responding with a second (or subsequent)
401-status HTTP response containing a new challenge.
UAs MAY optimise their use of challenges by pre-fetching a challenge
value, for example after "expires"/2 seconds have elapsed using the
".well-known/hoba/getChal" scheme described below. This also allows
for pre-calculation of HOBA signatures, if that is required in order
to produce a responsive user interface.
4. Using HOBA-http 4. Using HOBA-http
[[A lot of this is similar to the HOBA-js discussion below. At some [[A lot of this is similar to the HOBA-js discussion below. At some
point some nuclear fusion might be nice, but for now it might be best point some nuclear fusion might be nice, but for now it might be best
to keep them separate until we understand better what can be merged, to keep them separate until we understand better what can be merged,
and what is different.]] and what is different.]]
The interaction between an HTTP client and HTTP server using HOBA The interaction between an HTTP client and HTTP server using HOBA
happens in three phases: the CPK preparation phase, the signing happens in three phases: the CPK preparation phase, the signing
phase, and the authentication phase. The first and second phase are phase, and the authentication phase. The first and second phase are
done in a standard fashion; the third is done using site-specific done in a standard fashion; the third is done using site-specific
methods. methods. In addition, we provide a mechanism for pre-fetching
challenges.
[[ Need to describe what happens if the user bails half way through
the flow. ]]
4.1. CPK Preparation Phase 4.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 has a CPK, the
client will use it; if the client does not have a CPK, it generates client will use it; if the client does not have a CPK, it generates
one in anticipation of the server asking for one. one in anticipation of the server asking for one.
4.2. Signing Phase 4.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 user agent tries to access a protected resource on the server. The UA tries to access a protected resource on the server. The
The server sends the HOBA WWW-Authenticate challenge. The user agent server sends the HOBA WWW-Authenticate challenge. The UA receives
receives the challenge and signs the challenge using the CPK it the challenge and signs the challenge using the CPK it either already
either already had or just generated. The server validates the had or just generated. The server validates the signature. If
signature. If validation fails, the server aborts the transaction. validation fails, or if the server chooses to do so for other
[[ Or maybe it asks again? ]] reasons, then server aborts the transaction via a 403 Unauthorized
HTTP response.
4.3. Authentication Phase 4.3. Authentication Phase
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 the process involves a second factor of authentication, process. If this stage of the process involves additional
such as asking the user which account it wants to use (in the case information for authentication, such as asking the user which account
where a user agent is used for multiple accounts on a site), the she wants to use (in the case where a UA is used for multiple
server may prompt the user for the account identifying information. accounts on a site), the server can prompt the user for account
None of this is standardized: it all follows the server's security identifying information or the user could choose based on HTML
policy and session flow. At the end of this, the server probably offered by the server before the 401 is triggered. None of this is
assigns or updates a session cookie for the client. standardized: it all follows the server's security policy and session
flow. At the end of this, the server probably assigns or updates a
session cookie for the client.
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-user-agent (see below) client through a either a join or login-new-UA (see below) process.
process. This process is completely up to the server, and probably This process is completely up to the server, and probably entails
entails using HTML, JavaScript and CSS to ask the user some questions using HTML and JavaScript to ask the user some questions in order to
in order to assess whether or not the server wants to give the client assess whether or not the server wants to give the client an account.
an account. Completion of the joining process might entail require Completion of the joining process might require confirmation by
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 user agent even for unprotected server may desire to challenge the UA even for unprotected resources
resources and carry along the CPK in a session cookie for later use and set a session cookie for later use in a join or login process as
in a join or login process as it becomes necessary. For example, a it becomes necessary. For example, a server might only want to offer
server might only want to offer an account to someone who had been to an account to someone who had been to a few pages on the web site; in
a few pages on the web site; in such a case, the server could use the such a case, the server could use the CPK from an associated session
CPK from an associated session cookie as a way of building reputation cookie as a way of building reputation for the user until the server
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 After the UA is authenticated (if the user had to join, this could be
the last step of joining), the server gives the UA access to the the last step of joining), the server gives the UA access to the
protected resource that was originally requested at the beginning of protected resource that was originally requested at the beginning of
the signing phase. It is quite likely that the server would also the signing phase. It is quite likely that the server would also
update the UA's session cookie for the web site. update the UA's session cookie for the web site.
4.4. Logging in on a New User Agent 4.4. Logging in on a New User Agent
When a user wants to use a new user agent for an existing account, When a user wants to use a new UA for an existing account, the flows
the flows are similar to logging in with an already-joined UA or are similar to logging in with an already-joined UA or joining for
joining for the first time. In fact, the CPK preparation phase (with the first time. In fact, the CPK preparation phase (with the UA
the UA knowing that it needs to create a new CPK) and the signing knowing that it needs to create a new CPK) and the signing phase are
phase are identical. identical.
During the authentication phase, the server could use HTML, During the authentication phase, the server could use HTML and
JavaScript and CSS to ask the user if they are really a new user or JavaScript to ask the user if they are really a new user or want to
want to associate this new CPK with an already-joined CPK. The associate this new CPK with an already-joined CPK. The server can
server can then use some out-of-band method (such as a confirmation then use some out-of-band method (such as a confirmation email round
email round trip, SMS, or an UA that is already enrolled) to verify trip, SMS, or an UA that is already enrolled) to verify that the
that the "new" user is the same as the already-enrolled one. "new" user is the same as the already-enrolled one.
5. Using HOBA-js 5. Using HOBA-js
[[ A description of how to use the same HOBA semantics, but doing [[ A description of how to use the same HOBA semantics, but doing
everything in Javascript in a web page. This is more of a everything in Javascript in a web page. This is more of a
demonstration that you could get the similar semantics via JS rather demonstration that you could get the similar semantics via JS rather
than a normative section.]] than a normative section.]]
Web sites using javascript can also perform origin-bound Web sites using javascript can also perform origin-bound
authentication without needing to involve the http layer, and by authentication without needing to involve the http layer, and by
skipping to change at page 11, line 49 skipping to change at page 12, line 9
outlines a mechanism for Javascript HOBA clients to initially enroll, outlines a mechanism for Javascript HOBA clients to initially enroll,
subsequent enrollment on new clients, login, and how HOBA-js relates subsequent enrollment on new clients, login, and how HOBA-js relates
to web based session management. As with HOBA-http, a pure to web based session management. As with HOBA-http, a pure
Javascript implementation retains the property that only CPKs are Javascript implementation retains the property that only CPKs are
stored on the server, so that server compromise doesn't suffer the stored on the server, so that server compromise doesn't suffer the
multiplier affect that the various recent password exposure debacles multiplier affect that the various recent password exposure debacles
have vividly demonstrated. have vividly demonstrated.
5.1. Key Storage 5.1. Key Storage
We use the new HTML 5 webstorage feature that is now widely We use HTML 5's localStorage feature for key storage. Conceptually
available. Conceptually an implementation stores in the origin's an implementation stores the dictionary account identifier, public
localStorage dictionary account identifier, public key, private key key, private key tuples in the origin's localStorage for subsequent
tuples for subsequent authentication requests. How this is actually authentication requests. How this is actually stored in localStorage
stored in localStorage is an implementation detail. We rely on the is an implementation detail. We rely on the security properties of
security properties of the same-origin policy that localStorage the same-origin policy that localStorage enforces. See the security
enforces. See the security considerations for discussion about considerations for discussion about attacks on localStorage.
attacks on localStorage.
5.2. User Join 5.2. User Join
To join a web site, the HOBA-js client generates a public/private key 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 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 should be bound. The key pair and account identifier are stored in
localStorage for later use. The user agent then signs the join localStorage for later use. The UA then signs the join information
information (see below) using the private key, and forms a message (see below) using the private key, and forms a message with the
with the public key (CPK) and the signed data. The server receives public key (CPK) and the signed data. The server receives the
the message and verifies the signed data using the supplied key. 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 server creates the account and adds the public key to a list of
public keys associated with this account. public keys associated with this account.
5.3. User Login 5.3. User Login
Each time the user needs to log in to the server, it creates a 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 message (see below) and signs the message using the relevant private
key stored in localStorage. The signed login message along with the key stored in localStorage. The signed login message along with the
associated CPK identifier is sent to the server. The server receives associated CPK identifier is sent to the server. The server receives
the message and verifies the signed data. If the supplied public key the message and verifies the signed data. If the supplied public key
skipping to change at page 18, line 10 skipping to change at page 18, line 21
When the user wishes to logout, the UA simply goes to ".well-known/ When the user wishes to logout, the UA simply goes to ".well-known/
hoba/logout". The UA MAY also delete session cookies associated with hoba/logout". The UA MAY also delete session cookies associated with
the session. [[Is that right?, maybe a SHOULD- or MUST-delete would the session. [[Is that right?, maybe a SHOULD- or MUST-delete would
be better]] be better]]
The server-side MUST NOT allow TLS session resumption for any logged The server-side MUST NOT allow TLS session resumption for any logged
out session and SHOULD also revoke or delete any cookies associated out session and SHOULD also revoke or delete any cookies associated
with the session. with the session.
6.4. Getting a Fresh Challenge
If the UA would like a "fresh" challenge then it can send a POST or
GET message to ".well-known/hoba/getchal". A successful (200 status)
response MUST include a fresh (base64url encoded) HOBA 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.]] [[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
skipping to change at page 18, line 44 skipping to change at page 19, line 16
[[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 user agents under the control of keying material and use it to create UAs under the control of an
an attacker. But XSS attacks are in reality across the board attacker. But XSS attacks are in reality across the board
devastating since they can and do steal credit card information, devastating since they can and do steal credit card information,
passwords, perform illicit acts, etc, etc. It's not clear that we passwords, perform illicit acts, etc, etc. It's not clear that we
introduce unique threats from which clear text passwords don't introduce unique threats from which clear text passwords don't
already suffer. already suffer.
Another source of concern is local access to the keys. That is, if Another source of concern is local access to the keys. That is, if
an attacker has access to the UA itself, they could snoop on the key an attacker has access to the UA itself, they could snoop on the key
through a javascript console, or find the file(s) that implement through a javascript console, or find the file(s) that implement
localStorage on the host computer. Again it's not clear that we are localStorage on the host computer. Again it's not clear that we are
worse in this regard because the same attacker could get at browser worse in this regard because the same attacker could get at browser
skipping to change at page 19, line 27 skipping to change at page 19, line 45
when evaluating threats. As various password database leaks have when evaluating threats. As various password database leaks have
shown, the real threat of a password breach is not just to the site shown, the real threat of a password breach is not just to the site
that was breached, it's all of the sites a user used the same that was breached, it's all of the sites a user used the same
password on too. That is, the collateral damage is severe because password on too. That is, the collateral damage is severe because
password reuse is common. Storing a password in localStorage would password reuse is common. Storing a password in localStorage would
also have a similar multiplier effect for an attacker, though perhaps also have a similar multiplier effect for an attacker, though perhaps
on a smaller scale than a server-side compromise: one successful on a smaller scale than a server-side compromise: one successful
crack gains the attacker potential access to hundreds if not crack gains the attacker potential access to hundreds if not
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/
useragent/user. UA/user.
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. [[But we need to figure out the proxy angle;-)]]
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
skipping to change at page 20, line 19 skipping to change at page 20, line 40
"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. Acknowledgements 10. Implementation Status
[[Note to RFC editor - please delete this section before
publication.]]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in
[I-D.sheffer-running-code]. The description of implementations in
this section is intended to assist the IETF in its decision processes
in progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog
of available implementations or their features. Readers are advised
to note that other implementations may exist.
According to [RFC Editor: replace by a reference to this document],
"this will allow reviewers and working groups to assign due
consideration to documents that have the benefit of running code, by
considering the running code as evidence of valuable experimentation
and feedback that has made the implemented protocols more mature. It
is up to the individual working groups to use this information as
they see fit".
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
Michael Thomas of an HOBA-JS variant. More details will be provided
in future drafts as those implementations mature and e.g. open-source
licensing terms and release schedules are figured out.
11. Acknowledgements
Thanks to the following for good comments received during the Thanks to the following for good comments received during the
prepartion of this specification: Julian Reschke [[and many more to preparation of this specification: Julian Reschke [[and many more to
be added]. All errors and stupidities are of course the editors' be added]. All errors and stupidities are of course the editors'
fault. fault.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-httpbis-p7-auth] [I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-23
(work in progress), February 2013. (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.
[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 3986, January 2005. RFC 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.
skipping to change at page 21, line 13 skipping to change at page 22, line 19
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010. April 2010.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011. December 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.
11.2. Informative References 12.2. Informative References
[I-D.sheffer-running-code]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: the Implementation Status Section",
draft-sheffer-running-code-06 (work in progress),
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., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. 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., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376, Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011. 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 22, line 23 skipping to change at page 23, line 39
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
TBD, but will add next time. [[Will add more later and probably use example.org.]]
The following values show an example of HOBA-HTTP authentication to
the origin https://hoba-local.ie. Carriage-returns have been added
and need to be removed to validate the example.
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDNF6tZUbsM7ZrO
5Lyzvn15lJAfOz7j7xdc3hmeSOfh/DCiJWwE5qqffrOvOvXYN+qUTlsXPeBYdrz/
my0YYC02u2QFhDbFRvpM/EuMzZUWTQzkKyU7nSjtPqlLZJJ/Rh6PnjTgImoIMn92
JZgJZgl/vzd29K5Z94JzdJ4Z5bNmQ/gCpjlv0Wvi+GpJ3lDo1csDEyxATxyTUx1J
K73+/RPoNgUF9nrXN6kqeH7RkERRz+PFhfGM6r3tU5povJxOP0bzVl6R4kptWLn2
GqDb5LS9iwzsk6YHWQcLOIAMVZ9ITPN2PSuQX0ym81B9qB1V6fTfo2r0Yo1Djn6C
YRX62p4dAgMBAAECggEBAJiyWLcFrPhxJ2OG1iAVYaJVxAAcwjQ+XOydyAEbUtnk
Q+lVZ1k2zC43zVxXz5aN+y80L4ncXd4/eXPteuO9J6yqVEvvJkA3GkCbTzykC64w
67otjWkXF9ObZbxmQtRTxokzRzbhKIS15ER4tPu6ZrQgEBGXFwCQ0SVY3CV36dvm
xU2Y90wf98BGQF5VO47S9h8N/VtBn1ttI/6BhQHGsM+TbRR0b6oT9Mp/kqh5jZ2P
dH/l7Q6aj6zeFYljvI6HUpjc0mVOSKPAO0qYLZNYC0sqXxW9vCtEODziFZwrO2tL
jm14/H8+AZvtR6ZvbzP8h3G95PNdG4Z1eGZv5pOoJoECgYEA8omsyssjVgLIon60
Q6h3EjOi8I+mfvXYXcAZhv/1MnojFZgMLmuZ13Lgi3dIHYFNYGFRi8g9iYU/Ljtf
G3B9o6PQsvL0yym85TZzF/yn+kbinHR2yQUiA1Ck1rnrFx8dla/BjAplPxumyh/z
HyNFplVbOeRQS4K5F72wScuB9DECgYEA2Hnq1OSLetl4lrGAEHDoiIKw++ACQ/Tn
w5O+xAxOXr9iOmczwpHls+zFSQHty4za8C/tBLxg6HCHKZSO4lh+p5SR21UNgwfr
X6xBZ4xoH9zHTFdD2yrHdxAoItdT5oMTAUNHxDS8kcSY1+YcjRs2T4kcONIxeBlp
O++dxK9I6a0CgYEAp52WGSCCbzLFTeea1RdcEuw0s2PTgPKOcVwNSEskPZpDHO1T
ndEnJMpzfG8XG6z8uJsJLD1aqeu4Wk8Vz3TSn4Da/pEBtFZIAXC74dvuivzqJ44l
eY9ejkPxZ6RdYEFUxNoOPKYCiralchLahq5tuCJNRZkQFN9m441og9dtHEECgYEA
qnvRqlpXUqfEZYFi5w/UwfWTJrozbouInylTOpiqe8njtTUjuV8ndPzKHoYrXXwP
zMshsfIdq9E7UU7S/IVPMfE6sW6ZVpE9GDrTw5X7RuSb/I5ZPVjCgA00XsQQKmEd
7YesFGSoAXDAIn/yClrc+eR0WneHSBtTGkXKjWSyWn0CgYAlHdG3wj/sOL+JI7p8
fgSoRpkrbjfrczqSCDVFbT84sUz3dXObZecrI3v0XUZySakIDha5ZbxXNST/bfea
kReKsoeFY9J7os0hbfGwxiCQwD3wN9tS2yJbJYl1mCFc45YfylkXBzB0S2V/i6rv
vCWW1nijRb+WhpUF8HyKW64bxA==
-----END PRIVATE KEY-----
Key Identifier: Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vqWw
Challenge: zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0=
Nonce: xXSFdZ-7ahM
Tbsorigin: httpshoba-local.ie443
The resulting signature is:
r1ZXAWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfo
K__W_Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hK
t4bCtP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19J
LTUyaisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7
qf6lORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq
8meaqRXMhoQWHGLweFTNYw
The final HTTP header field sent with a request is then:
Authorization: result="Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vq
Ww.zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0=.xXSFdZ-7ahM.r1ZX
AWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfoK__W
_Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hKt4bC
tP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19JLTUy
aisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7qf6l
ORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq8mea
qRXMhoQWHGLweFTNYw"
Appendix C. Changes Appendix C. Changes
[[Note to RFC editor - please delete this section before [[Note to RFC editor - please delete this section before
publication.]] publication.]]
C.1. WG-00 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 First WG draft, replacing draft-farrell-httpbis-hoba-02
o Fleshed out HTTP scheme some more. o Fleshed out HTTP scheme some more.
o Fleshed out registration form more. o Fleshed out registration form more.
Authors' Addresses Authors' Addresses
Stephen Farrell Stephen Farrell
 End of changes. 60 change blocks. 
190 lines changed or deleted 311 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/