draft-ietf-httpauth-hoba-04.txt   draft-ietf-httpauth-hoba-05.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: February 15, 2015 VPN Consortium Expires: April 10, 2015 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
August 14, 2014 October 7, 2014
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-04 draft-ietf-httpauth-hoba-05
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 February 15, 2015. This Internet-Draft will expire on April 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 10 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 9
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11 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 . . . . 13 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 12
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 13 6.2. Associating Additional Keys to an Exiting Account . . . . 14
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 14
6.2.2. Human memorable one time password (don't do this one) 14 6.2.2. Human memorable one time password (don't do this one) 14
6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 14 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 15
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 15 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 15
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 15 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. Privacy considerations . . . . . . . . . . . . . . . . . 15 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 16
8.2. localStorage Security for Javascript . . . . . . . . . . 15 8.2. localStorage Security for Javascript . . . . . . . . . . 17
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 16 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 17 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 18
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 17 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 18
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 17 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 19
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 18 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 19
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 18 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 19
9.6. HOBAREG HTTP Header . . . . . . . . . . . . . . . . . . . 18 9.6. Hobareg HTTP Header . . . . . . . . . . . . . . . . . . . 20
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 20 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 22
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
HTTP Origin-Bound Authentication (HOBA) is an authentication design HTTP Origin-Bound Authentication (HOBA) is an authentication design
that can be used as an HTTP authentication scheme [RFC7235] and for that can be used as an HTTP authentication scheme [RFC7235] and for
Javascript-based authentication embedded in HTML. The main goal of Javascript-based authentication embedded in HTML. The main goal of
HOBA is to offer an easy-to-implement authentication scheme that is HOBA is to offer an easy-to-implement authentication scheme that is
not based on passwords, but that can easily replace HTTP or HTML not based on passwords, but that can easily replace HTTP or HTML
forms-based password authentication. Deployment of HOBA can reduce forms-based password authentication. Deployment of HOBA can reduce
or eliminate password entries in databases, with potentially or eliminate password entries in databases, with potentially
significant security benefits. significant security benefits.
HOBA is an HTTP authentication mechanism that complies with the HOBA is an HTTP authentication mechanism that complies with the
skipping to change at page 3, line 18 skipping to change at page 3, line 21
not based on passwords, but that can easily replace HTTP or HTML not based on passwords, but that can easily replace HTTP or HTML
forms-based password authentication. Deployment of HOBA can reduce forms-based password authentication. Deployment of HOBA can reduce
or eliminate password entries in databases, with potentially or eliminate password entries in databases, with potentially
significant security benefits. significant security benefits.
HOBA is an HTTP authentication mechanism that complies with the HOBA is an HTTP authentication mechanism that complies with the
framework for such schemes [RFC7235]. As a JavaScript design, HOBA framework for such schemes [RFC7235]. As a JavaScript design, HOBA
demonstrates a way for clients and servers to interact using the same demonstrates a way for clients and servers to interact using the same
credentials that are used by the HTTP authentication scheme. credentials that are used by the HTTP authentication scheme.
Current HTTP authentication methods (Basic and Digest), as well as Current username/password authentication methods such as HTTP Basic,
username/password authentication using web forms, have been in use HTTP Digest, and web forms have been in use for many years but are
for many years, but being based on passwords, are susceptible to susceptible to theft of server-side password databases. Instead of
theft of server-side databases. Instead of passwords, HOBA uses passwords, HOBA uses digital signatures as an authentication
digital signatures as an authentication mechanism. HOBA also adds mechanism. HOBA also adds useful features such as credential
useful features such as credential management and session logout. In management and session logout. In HOBA, the client creates a new
HOBA, the client creates a new public-private key pair for each host public-private key pair for each host ("web-origin" [RFC6454]) to
("web-origin" [RFC6454]) to which it authenticates. These keys are which it authenticates. These keys are used in HOBA for HTTP clients
used in HOBA for HTTP clients to authenticate themselves to servers to authenticate themselves to servers in the HTTP protocol or in a
in the HTTP protocol or in a Javascript authentication program. Javascript authentication program.
Session management with HOBA is identical to username/password HOBA session management is identical to username/password session
session management. Typically, the session management tool (such as management, with a server-side session management tool or script
PHP, Python CGI, and so on) inserts a session cookie into the output inserting a session cookie into the output to the browser. HOBA
to the browser. HOBA does nothing to help or hurt session cookie still requires TLS to prevent session cookie hijacking.
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:
o Servers can bind a CPK with an identifier, such as an account o Servers can bind a CPK with an identifier, such as an account
name. Servers using HOBA define their own policies for binding name. Servers using HOBA define their own policies for binding
CPKs with accounts during account registration. CPKs with accounts during account registration.
o Users are likely to use more than one device or user agent (UA) o Users are likely to use more than one device or user agent (UA)
for the same HTTP based service, so HOBA gives a way to associate for the same HTTP based service, so HOBA gives a way to associate
more than one CPK to the same account, but without having to more than one CPK to the same account, but without having to
register for each separately. register for each separately.
o Users are also likely to lose a private key, or the client's
memory of which key pair is associated with which origin, such as
when a user loses the computer or mobile device in which state is
stored. HOBA allows for clients to tell servers to delete the
association between an existing CPK and an account.
o Logout features can be useful for UAs, so HOBA defines a way to o Logout features can be useful for UAs, so HOBA defines a way to
close a current HTTP "session", and also a way to close all close a current HTTP "session", and also a way to close all
current sessions, even if more than one session is currently current sessions, even if more than one session is currently
active from different UAs for the same account. active from different UAs for the same account.
o Since there are always devices and applications in which state of o Digital signatures can be expensive to compute, so HOBA defines a
the art digital signature mechanism runtimes are significant, and way for HTTP servers to indicate how long a given challenge value
since HTTP authentication in theory requires that every HTTP is valid, and a way for UAs to fetch a fresh challenge at any
request to a given realm have a signature in an "Authorization" time.
header field, and since HOBA is a challenge response scheme, we
also define a way in which HTTP servers can indicate the duration Users are also likely to lose a private key, or the client's memory
for which they will consider a given challenge value to be valid. of which key pair is associated with which origin, such as when a
As a consequence we also define a way for UAs to fetch a fresh user loses the computer or mobile device in which state is stored.
challenge. HOBA does not define a mechanism for deleting the association between
an existing CPK and an account. Such a mechanism can be implemented
at the application layer.
1.1. Interfacing to Applications (Cookies) 1.1. Interfacing to Applications (Cookies)
HOBA can be used as a drop-in replacement for password-based user HOBA can be used as a drop-in replacement for password-based user
authentication schemes used in common web applications. The simplest authentication schemes used in common web applications. The simplest
way in which this can be done is to (re-)direct the UA to a HOBA way is to (re-)direct the UA to a HOBA "Login" URL and for the
"Login" URL and for the response to a successful HTTP request response to a successful HTTP request containing a HOBA signature to
containing a HOBA signature to set a session cookie [RFC6265]. set a session cookie [RFC6265]. Further interactions with the web
Further interactions with the web application will then be secured application will then be secured via the session cookie, as is
via the session cookie, as is commonly done today. commonly done today.
While cookies are bearer tokens, and thus weaker than HOBA While cookies are bearer tokens, and thus weaker than HOBA
signatures, they are currently ubiquitously used. If non-bearer signatures, they are currently ubiquitously used. If non-bearer
token session continuation schemes are developed in future in the token session continuation schemes are developed in future in the
IETF or elsewhere, then those can interface to HOBA as easily as with IETF or elsewhere, then those can interface to HOBA as easily as with
any password based authentication scheme. any password based authentication scheme.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
A client public key ("CPK") is the public key and associated This specification uses the Augmented Backus-Naur Form (ABNF)
cryptographic parameters needed for a server to validate a signature. notation of [RFC5234]
The term "account" is (loosely) used to refer to whatever data Account: The term "account" is (loosely) used to refer to whatever
structure(s) the server maintains that are associated with an data structure(s) the server maintains that are associated with an
identity. That will contain of at least one CPK and a web-origin; it identity. That will contain of at least one CPK and a web-origin; it
will also optionally include an HTTP "realm" as defined in the HTTP will also optionally include an HTTP "realm" as defined in the HTTP
authentication specification. It might also involve many other non- authentication specification. [RFC7235]. It might also involve many
standard pieces of data that the server accumulates as part of other non-standard pieces of data that the server accumulates as part
account creation processes. An account may have many CPKs that are of account creation processes. An account may have many CPKs that
considered equivalent in terms of being usable for authentication, are considered equivalent in terms of being usable for
but the meaning of "equivalent" is really up to the server and is not authentication, but the meaning of "equivalent" is really up to the
defined here. server and is not defined here.
When describing something that is specific to HOBA as an HTTP Client public key ("CPK"): A CPK is the public key and associated
authentication mechanism or HOBA as a JavaScript implementation, this cryptographic parameters needed for a server to validate a signature.
document uses the terms "HOBA-http" and "HOBA-js", respectively.
Web client: the content and javascript code that run within the HOBA-http: We use this term when describing something that is
context of a single UA instance (such as a tab in a web browser). specific to HOBA as an HTTP authentication mechanism.
HOBA-js: We use this term when describing something that is unrelated
to HOBA-http but is relevant for HOBA as a design pattern that can be
implemented in a browser in JavaScript.
User agent (UA): typically, but not always, a web browser. User agent (UA): typically, but not always, a web browser.
User: a person who is running a UA. In this document, "user" does User: a person who is running a UA. In this document, "user" does
not mean "user name" or "account name". not mean "user name" or "account name".
This specification uses the Augmented Backus-Naur Form (ABNF) Web client: the content and javascript code that run within the
notation of [RFC5234] context of a single UA instance (such as a tab in a web browser).
2. The HOBA Authentication Scheme 2. The HOBA Authentication Scheme
A UA that implements HOBA maintains a list of web-origins and realms. A UA that implements HOBA maintains a list of web-origins and realms.
The UA also maintains one or more client credentials for each web- The UA also maintains one or more client credentials for each web-
origin/realm combination for which it has created a CPK. origin/realm combination for which it has created a CPK.
On receipt of a challenge (and optional realm) from a server, the On receipt of a challenge (and optional realm) from a server, the
client marshals an HOBA to-be-signed (TBS) blob that includes a client marshals 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 blob with the
private key corresponding to the CPK for that web-origin. The private key corresponding to the CPK for that web-origin. The
formatting chosen for this TBS blob is chosen so as to make server- formatting chosen for this TBS blob is chosen so as to make server-
side signature verification as simple as possible for a wide range of side signature verification as simple as possible for a wide range of
current server tooling. current server tooling.
Figure 1 specifies the ABNF for the signature input. The term Figure 1 specifies the ABNF for the signature input. The term
"unreserved" means that the field does not have a specific format "unreserved" means that the field does not have a specific format
defined. defined.
HOBA-TBS = nonce alg origin [ realm ] kid challenge HOBA-TBS = nonce alg origin [ realm ] kid challenge
nonce = unreserved nonce = 1*base64urlchars
alg = 1*2DIGIT alg = 1*2DIGIT
origin = scheme "://" authority ":" port origin = scheme "://" authority ":" port
realm = unreserved realm = unreserved
kid = unreserved kid = 1*base64urlchars
challenge = unreserved challenge = 1*base64urlchars
; Characters for Base64URL encoding from Table 2 of RFC 4648
base64urlchars = %x30-39 ; Digits
/ %x41-5A ; Uppercase letters
/ %x61-7A ; Lowercase letters
/ "-" / "_" / "=" ; Special characters
Figure 1: To-be-signed data for HOBA Figure 1: To-be-signed data for HOBA
The fields above contain the following: The fields above contain the following:
o nonce: is a random value chosen by the UA and MUST be base64url o nonce: is a random value chosen by the UA and MUST be base64url
encoded before being included in the HOBA-TBS value. (base64url encoded before being included in the HOBA-TBS value. (base64url
encoding is defined in [RFC4648].) UAs MUST be able to use at encoding is defined in [RFC4648].) UAs MUST be able to use at
least 32 bits of randomness in generating a nonce. UAs SHOULD be least 32 bits of randomness in generating a nonce. UAs SHOULD be
able to use 64 or more bits of randomness for nonces. able to use 64 or more bits of randomness for nonces.
skipping to change at page 7, line 4 skipping to change at page 7, line 9
that is presented to the server in the HOBA client result (see that is presented to the server in the HOBA client result (see
below). below).
o challenge: MUST be a base64url encoded challenge value that the o challenge: MUST be a base64url encoded challenge value that the
server chose to send to the client server chose to send to the client
The HOBA-TBS string is the input to the client's signing process, but The HOBA-TBS string is the input to the client's signing process, but
is not itself sent over the network since some fields are already is not itself sent over the network since some fields are already
inherent in the HTTP exchange. The challenge however is sent over inherent in the HTTP exchange. The challenge however is sent over
the network so as to make it simpler for a server to be stateless. the network so as to make it simpler for a server to be stateless.
(One form of stateless challenge might be a ciphertext that the (One form of stateless challenge might be a ciphertext that the
server decrypts and checks, but that is an implementation detail.) server decrypts and checks, but that is an implementation detail.)
The value that is sent over the network is the HOBA "client result" The value that is sent over the network by the UA is the HOBA "client
which we now define. result" which we now define.
The HOBA "client result" is a dot-separated string that includes the The HOBA "client result" is a dot-separated string that includes the
signature and is sent in the HTTP Authorized header field value using signature and is sent in the HTTP 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 = 1*base64urlchars
Figure 2: HOBA Client Result value Figure 2: HOBA Client Result value
The HOBA scheme is far from new, for example, the basic idea is The HOBA scheme is far from new, for example, the basic idea is
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"
auth-scheme value in a WWW-Authenticate header field when it wants auth-scheme value in a WWW-Authenticate header field when it wants
the client to authenticate with HOBA. Note that the HOBA auth-scheme the client to authenticate with HOBA. Note that the HOBA auth-scheme
might not be the only one that the server includes in a WWW- might not be the only one that the server includes in a WWW-
Authenticate. Authenticate header.
o If the "HOBA" scheme is listed, it MUST be followed by two or more The HOBA scheme has two REQUIRED attributes (challenge and max-age)
auth-param values. The auth-param attributes defined by this and one OPTIONAL attribute (realm):
specification are below. Other auth-param attributes MAY be used
as well. Unknown auth-param attributes MUST be ignored by
clients, if present.
o The "challenge" attribute MUST be included. The challenge is the o The "challenge" attribute MUST be included. The challenge is the
string made up of the base64url encoded octets that the server string made up of the base64url encoded octets that the server
wants the client to sign in its response. The challenge SHOULD be wants the client to sign in its response. The challenge MUST be
unique for every HTTP 401 response in order to prevent replay unique for every HTTP 401 response in order to prevent replay
attacks from passive observers. attacks from passive observers.
o An "expires" attribute MUST be included that specifies the number o A "max-age" attribute MUST be included that specifies the number
of seconds from the time the HTTP response is emitted for which of seconds from the time the HTTP response is emitted for which
responses to this challenge can be accepted. responses to this challenge can be accepted for example "max-age:
10" would indicatge ten seconds. If max-age is set to zero, then
that means that only one signature will be accepted for this
challenge.
o A "realm" attribute MAY be included to indicate the scope of o A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
The "realm" attribute MUST NOT appear more than once. The "realm" attribute MUST NOT appear more than once.
When the "client response" is created, the UA encodes the HOBA When the "client response" is created, the UA encodes the HOBA
client-result (a string matching the HOBA-RES production in Figure 2 client-result and returns that in the Authorization header. The
as an auth-param with the name "result" and returns that in the client-result is a string matching the HOBA-RES production in Figure
Authorization header. 2 as an auth-param with the name "result".
The server MUST check the cryptographic correctness of the signature The server MUST check the cryptographic correctness of the signature
based on a public key it knows for the kid in the signatures, and if based on a public key it knows for the kid in the signatures, and if
the server cannot do that, or if the signature fails cryptographic the server cannot do that, or if the signature fails cryptographic
checks, then validation has failed. The server can use any checks, then validation has failed. The server can use any
additional mechanisms to validate the signature. If the validation additional mechanisms to validate the signature. If the validation
fails, or if the server chooses reject the signature for any reason fails, or if the server chooses reject the signature for any reason
whatsoever, the server aborts the transaction via a 401 Unauthorized whatsoever, the server aborts the transaction via a 401 Unauthorized
HTTP response. HTTP response.
Note that a HOBA signature is good for however long the expires Note that a HOBA signature is good for however long a non-zero max-
attribute allows. This means that replay is possible within the time age attribute allows. This means that replay is possible within the
window specified by the "expires" value chosen by the server. time window specified by the "max-age" value chosen by the server.
Servers can attempt to detect any such replay (via caching if they so Servers can attempt to detect any such replay (via caching if they so
choose) and MAY react to such replays by responding with a second (or choose) and MAY react to such replays by responding with a second (or
subsequent) 401-status HTTP response containing a new challenge. subsequent) 401-status HTTP response containing a new challenge.
UAs MAY optimise their use of challenges by pre-fetching a challenge UAs MAY optimise their use of challenges by pre-fetching a challenge
value, for example after expires/2 seconds have elapsed, using the value, for example after (max-age)/2 seconds have elapsed, using the
".well-known/hoba/getChal" scheme described later in this document. ".well-known/hoba/getchal" scheme described later in this document.
This also allows for pre-calculation of HOBA signatures, if that is This also allows for pre-calculation of HOBA signatures, if that is
required in order to produce a responsive user interface. required in order to produce a responsive user interface.
4. Introduction to the HOBA-js Mechanism 4. Introduction to the HOBA-js Mechanism
Web sites using JavaScript can also perform origin-bound Web sites using JavaScript can also perform origin-bound
authentication without needing to involve the HTTP layer, and by authentication without needing to involve the HTTP layer, and by
inference not needing HOBA-http support in browsers. HOBA-js is not inference not needing HOBA-http support in browsers. HOBA-js is not
an on-the-wire protocol like HOBA-http is: instead, it is a design an on-the-wire protocol like HOBA-http is: instead, it is a design
pattern that can be realized completely in JavaScript served in pattern that can be realized completely in JavaScript served in
normal HTML pages. normal HTML pages.
One element is required for HOBA-js: localStorage (see http:// One element is required for HOBA-js: localStorage (see http://
www.w3.org/TR/webstorage/) from HTML5. is used for persistent key www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key
storage. For example, an implementation would store a dictionary storage. For example, an implementation would store a dictionary
account identifier, public key, private key tuples in the origin's account identifier, public key and private key tuples in the origin's
localStorage for subsequent authentication requests. How this localStorage for subsequent authentication requests. How this
information is actually stored in localStorage is an implementation information is actually stored in localStorage is an implementation
detail. This type of key storage relies on the security properties detail. This type of key storage relies on the security properties
of the same-origin policy that localStorage enforces. See the of the same-origin policy that localStorage enforces. See the
security considerations for discussion about attacks on localStorage. security considerations for discussion about attacks on localStorage.
Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an
alternative to localStorage that can also be used here.
Because of JavaScript's same-origin policy, scripts from subdomains Because of JavaScript's same-origin policy, scripts from subdomains
do not have access to the same localStorage that scripts in their do not have access to the same localStorage that scripts in their
parent domains do. For larger or more complex sites, this could be parent domains do. For larger or more complex sites, this could be
an issue that requires enrollment into subdomains, which could be a an issue that requires enrollment into subdomains, which could be a
hassle for users. One way to get around this is to use session hassle for users. One way to get around this is to use session
cookies because they can be used across subdomains. That is, with cookies because they can be used across subdomains. That is, with
HOBA-js, the user might log in using a single well-known domain, and HOBA-js, the user might log in using a single well-known domain, and
then the server uses session cookies to navigate around a site. then the server uses session cookies to navigate around a site.
Another element will be highly desirable for HOBA-js when it becomes Another element will be highly desirable for HOBA-js when it becomes
available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In
lieu of WebCrypto, JavaScript crypto libraries can be employed with lieu of WebCrypto, JavaScript crypto libraries can be employed with
the known deficiencies of PRNG, and the general immaturity of those the known deficiencies of their pseudo-random number generators and
libraries. the general immaturity of those libraries.
5. HOBA's Authentication Process 5. HOBA's Authentication Process
This section describes how clients and servers use HOBA for This section describes how clients and servers use HOBA for
authentication. The interaction between an HTTP client and HTTP authentication. The interaction between an HTTP client and HTTP
server using HOBA happens in three phases: the CPK preparation phase, server using HOBA happens in three phases: the CPK preparation phase,
the signing phase, and the authentication phase. This section also the signing phase, and the authentication phase. This section also
covers the actions that give HOBA similar user features as today's covers the actions that give HOBA similar user features as today's
passwords have. passwords have.
5.1. CPK Preparation Phase 5.1. CPK Preparation Phase
In the CPK preparation phase, the client determines if it already has In the CPK preparation phase, the client determines if it already has
a CPK for the web-origin it is going to. If the client has a CPK, a CPK for the web-origin with which it needs to authenticate. If the
the client will use it; if the client does not have a CPK, it client has a CPK, the client will use it; if the client does not have
generates one in anticipation of the server asking for one. a CPK, it generates one in anticipation of the server asking for one.
5.2. Signing Phase 5.2. Signing Phase
In the signing phase, the client connects to the server, the server In the signing phase, the client connects to the server, the server
asks for HOBA-based authentication, and the client authenticates by asks for HOBA-based authentication, and the client authenticates by
signing a blob of information as described in the previous sections. signing a blob of information as described in the previous sections.
5.3. Authentication Phase 5.3. Authentication Phase
The authentication phase is completely dependent on the policies and The authentication phase is completely dependent on the policies and
skipping to change at page 12, line 7 skipping to change at page 11, line 51
for the realm concerned, then a new registration is REQUIRED. If the for the realm concerned, then a new registration is REQUIRED. If the
server did not wish for that outcome, then it ought to use the same server did not wish for that outcome, then it ought to use the same
or no realm. or no realm.
The registration message for HOBA-http is sent as a POST message to The registration message for HOBA-http is sent as a POST message to
the URL ".well-known/hoba/register" with an HTML form (x-www-form- the URL ".well-known/hoba/register" with an HTML form (x-www-form-
encoded) described below; The registration message for HOBA-js can be encoded) described below; The registration message for HOBA-js can be
in any format specified by the server, but it could be the same as in any format specified by the server, but it could be the same as
the one described here for HOBA-http. It is up to the server to the one described here for HOBA-http. It is up to the server to
decide what kind of user interaction is required before the account decide what kind of user interaction is required before the account
is finally set up. is finally set up. When the server's chosen registration flow is
completed successfully the server MUST add a Hobareg HTTP header (see
Section 6.1.1) to the HTTP response message that completes the
registration flow.
The registration message sent to server has one mandatory field (pub) The registration message sent to server has one mandatory field (pub)
and some optional fields that allow the UA to specify the type and and some optional fields that allow the UA to specify the type and
value of key and device identifiers that the UA wishes to use. value of key and device identifiers that the UA wishes to use.
o pub: is a mandatory field containing the PEM formatted public key o pub: is a mandatory field containing the PEM formatted public key
of the client. See Appendix C of [RFC6376] for an example of how of the client. See Appendix C of [RFC6376] for an example of how
to generate this key format. to generate this key format.
o kidtype: contains the type of key identifier, this is a numeric o kidtype: contains the type of key identifier, this is a numeric
skipping to change at page 12, line 44 skipping to change at page 12, line 43
worked, e.g., following authentication some web content might say worked, e.g., following authentication some web content might say
"You last logged in from device 'did' at time T." "You last logged in from device 'did' at time T."
Note that replay of registration (and other HOBA) messages is quite Note that replay of registration (and other HOBA) messages is quite
possible. That however can be counteracted if challenge freshness is possible. That however can be counteracted if challenge freshness is
ensured. See Section 2 for details. Note also that with HOBA-http ensured. See Section 2 for details. Note also that with HOBA-http
the HOBA signature does not cover the POST message body. If that is the HOBA signature does not cover the POST message body. If that is
required then HOBA-JS may be a better fit for registration and other required then HOBA-JS may be a better fit for registration and other
account management actions. account management actions.
6.1.1. Hobareg Definition
Since registration can often be a multi-step process, e.g. requiring Since registration can often be a multi-step process, e.g. requiring
a user to fill in contact details, the initial response to the HTTP a user to fill in contact details, the initial response to the HTTP
POST message defined above may not be the end of the registration POST message defined above may not be the end of the registration
process even though the HTTP response has a 200 OK status. This process even though the HTTP response has a 200 OK status. This
creates an issue for the UA since, during the registration process creates an issue for the UA since, during the registration process
(e.g., while dealing with interstitial pages), the UA doesn't yet (e.g., while dealing with interstitial pages), the UA doesn't yet
know whether the CPK is good for that web origin or not. know whether the CPK is good for that web origin or not.
For this reason the server MUST add a header to the response message For this reason the server MUST add a header to the response message
when the registration has succeded to indicate the new state. The when the registration has succeded to indicate the new state. The
header to be used is "HOBA-REG" and the value when registration has header to be used is "Hobareg" and the value when registration has
succeeded is to be "regok". When registration is in-work (e.g. on an succeeded is to be "regok". When registration is inwork (e.g. on an
HTTP response for an interstitial page) the server MAY add this HTTP response for an interstitial page) the server MAY add this
header with a value of "reginwork". See Section 9.6 for the relevant header with a value of "reginwork". See Section 9.6 for the relevant
IANA registration of this header field. IANA registration of this header field.
For interstitial pages, the client MAY include a HOBA Authorization For interstitial pages, the client MAY include a HOBA Authorization
header. This is not considered a MUST as that might needlessly header. This is not considered a MUST as that might needlessly
complicate client implementations but is noted here in case a server complicate client implementations but is noted here in case a server
implementer assumes that all registration messages contain a HOBA implementer assumes that all registration messages contain a HOBA
Authorization header. Authorization header.
Hobareg-val = "regok" / "inwork"
Figure 3: Hobareg Header Field Definition
Figure 3 provides an ABNF definition for the values allowed in the
Hobareg header field. Note that these (and the header field name)
are case insensitive. Section 8.3.1 of [RFC7231] calls for
documenting the following details for this new header field:
o Only one single value is allowed in a Hobareg header field.
Should more than one (a list) be encountered, that should be
interpreted as being the same as "inwork."
o The Hobareg header field can only be used in HTTP responses.
o Since Hobareg is only meant for responses it ought not appear in a
PUT request.
o The HTTP response code does affect the interpretation of Hobareg.
Registration is only considered to have succeeded if the regok
value is seen in a 2xx response. 4xx and other errors means that
registration has failed regardless of the value of Hobareg seen.
The request method has no influence on the interpretation of
Hobareg.
o Intermediaries should never insert, delete or modify a Hobareg
header field.
o As a response-only header field, it is not appropriate to list a
Hobareg in a Vary response header field.
o Hobareg is allowed in trailers.
o As a response-only header field, Hobareg will not be preserved
across re-directs.
o Hobareg itself discloses little security or privacy sensitive
information. If an attacker can somehow detect that a Hobareg
header field is being added, then that attacker would know that
the UA is in the process of registration which could be
significant. However, it is likely that the set of messages
between the UA and server would expose this information in many
cases, regardless of whether or not TLS is used. Using TLS is
still however a good plan.
6.2. Associating Additional Keys to an Exiting Account 6.2. Associating Additional Keys to an Exiting Account
From the user perspective, the UA having a CPK for a web origin will From the user perspective, the UA having a CPK for a web origin will
often appear to be the same as having a way to sign in to an account often appear to be the same as having a way to sign in to an account
at that web site. Since users often have more than one UA, and since at that web site. Since users often have more than one UA, and since
the CPKs are, in general, UA-specific, that raises the question of the CPKs are, in general, UA-specific, that raises the question of
how the user can sign in to that account from different UAs. And how the user can sign in to that account from different UAs. And
from the server perspective that turns into the question of how to from the server perspective that turns into the question of how to
safely bind different CPKs to one account. In this section, we safely bind different CPKs to one account. In this section, we
describe some ways in which this can be done, as well as one way in describe some ways in which this can be done, as well as one way in
skipping to change at page 15, line 6 skipping to change at page 16, line 4
also delete session cookies associated with the session so that the also delete session cookies associated with the session so that the
user's state is no longer "logged in." user's state is no longer "logged in."
The server MUST NOT allow TLS session resumption for any logged out The server MUST NOT allow TLS session resumption for any logged out
session. session.
The server SHOULD also revoke or delete any cookies associated with The server SHOULD also revoke or delete any cookies associated with
the session. the session.
6.4. Getting a Fresh Challenge 6.4. Getting a Fresh Challenge
The UA can get a "fresh" challenge from the server. In HOBA-http, it The UA can get a "fresh" challenge from the server. In HOBA-http, it
sends a POST message to ".well-known/hoba/getchal". If successful, sends a POST message to ".well-known/hoba/getchal". If successful,
the response response MUST include a fresh (base64url encoded) HOBA the response response MUST include a fresh (base64url encoded) HOBA
challenge for this origin in the body of the response. challenge for this origin in the body of the response.
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. RSA is defined in
Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].
8. Security Considerations 8. Security Considerations
If key binding was server-selected then a bad actor could bind If key binding was server-selected then a bad actor could bind
different accounts belonging to the user from the network with different accounts belonging to the user from the network with
possible bad consequences, especially if one of the private keys was possible bad consequences, especially if one of the private keys was
compromised somehow. compromised somehow.
Binding my CPK with someone else's account would be fun and Binding my CPK with someone else's account would be fun and
profitable so SHOULD be appropriately hard. In particular URLs or profitable so SHOULD be appropriately hard. In particular URLs or
other values generated by the server as part of any CPK binding other values generated by the server as part of any CPK binding
process MUST be hard to guess, for whatever level of difficulty is process MUST be hard to guess, for whatever level of difficulty is
chosen by the server. The server SHOULD NOT allow a random guess to chosen by the server. The server SHOULD NOT allow a random guess to
reveal whether or not an account exists. reveal whether or not an account exists.
When the max-age parameter is not zero, then a HOBA signature has a
property that is like a bearer token for the relevant number of
seconds: it can be replayed for a server-selected duration.
Similarly, for HOBA-js, signatures might be replayable depending on
the specific implementation. The security considerations of
[RFC6750] therefore apply in any case where the HOBA signature can be
replayed. Server administrators SHOULD set the max-age to the
minimum acceptable value in such cases, which would often be expected
to be just a few seconds. There seems to be no reason to ever set
the max-age more than a few minutes; the value ought also decrease
over time as device capabilities improve. The administrator will
most likely want to set the max-age to something that is not too slow
on the slowest signing device that is significant for that site.
8.1. Privacy considerations 8.1. Privacy considerations
HOBA does impact to some extent on privacy and could be considered to HOBA does impact to some extent on privacy and could be considered to
represent a super-cookie to the server, or to any entity on the path represent a super-cookie to the server, or to any entity on the path
from UA to HTTP server that can see the HOBA signature. This is from UA to HTTP server that can see the HOBA signature. This is
because we need to send a key identifier as part of the signature and because we need to send a key identifier as part of the signature and
that will not vary for a given key. For this reason, and others, it that will not vary for a given key. For this reason, and others, it
is strongly RECOMMENDED to only use HOBA over server-authenticated is strongly RECOMMENDED to only use HOBA over server-authenticated
TLS and to migrate web sites using HOBA to only use "https" URLs. TLS and to migrate web sites using HOBA to only use "https" URLs.
skipping to change at page 17, line 28 skipping to change at page 18, line 31
IANA is requested to make registrations and create new registries as IANA is requested to make registrations and create new registries as
described below. described below.
9.1. HOBA Authentication Scheme 9.1. HOBA Authentication Scheme
Please register a new scheme in the HTTP Authentication Scheme Please register a new scheme in the HTTP Authentication Scheme
Registry registry as follows: Registry registry as follows:
Authentication Scheme Name: HOBA Authentication Scheme Name: HOBA
Pointer to specification text: [[ this document ]] Pointer to specification text: Section 3 of [[ this document ]]
Notes (optional): The HOBA scheme can be used with either HTTP Notes (optional): The HOBA scheme can be used with either HTTP
servers or proxies. When used in response to a 407 Proxy servers or proxies. When used in response to a 407 Proxy
Authentication Required indication, the appropriate proxy Authentication Required indication, the appropriate proxy
authentication header fields are used instead, as with any other HTTP authentication header fields are used instead, as with any other HTTP
authentication scheme. authentication scheme.
9.2. .well-known URI 9.2. .well-known URI
Please register a new .well-known URI in the Well-Known URIs registry Please register a new .well-known URI in the Well-Known URIs registry
as described below. as described below.
URI suffix: hoba URI suffix: hoba
Change controller: IETF Change controller: IETF
Specification document(s): [[ this document ]] Specification document(s): Section 6 of [[ this document ]]
Related information: N/A. Related information: N/A
9.3. Algorithm Names 9.3. Algorithm Names
Please create a new HOBA signature algorithms registry as follows, Please create a new HOBA signature algorithms registry as follows,
with the specification required rule for updates. with the specification required rule for updates. New HOBA signature
algorithms SHOULD be in use with other IETF standards track protocols
before being added to this registry.
TBD, hopefully re-use and existing registry Number Meaning
----------- --------------------------------------------
0 RSA-SHA256
1 RSA-SHA1
"0" means RSA-SHA256 RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are
defined in [SHS].
"1" means RSA-SHA1 For this registry the number column should contain a small positive
integer.
9.4. Key Identifier Types 9.4. Key Identifier Types
Please create a new HOBA Key Identifier Types registry as follows, Please create a new HOBA Key Identifier Types registry as follows,
with the specification required rule for updates. with the specification required rule for updates.
"0" means a hashed public key, as done in DANE. [RFC6698] Number Meaning
----------- --------------------------------------------
0 a hashed public key [RFC6698]
1 a URI [RFC3986]
2 an unformatted string, at the user's/UA's whim
"1" means a URI, such as a mailto: or acct: URI, but anything For the number 0, hashed public keys are as done in DANE. [RFC6698]
conforming to [RFC3986] is ok.i
"2" means an unformatted string, at the user's/UA's whim For this registry the number column should contain a small positive
integer.
9.5. Device Identifier Types 9.5. Device Identifier Types
Please create a new HOBA Device Identifier Types registry as follows, Please create a new HOBA Device Identifier Types registry as follows,
with the specification required rule for updates. with the specification required rule for updates.
"0" means an unformatted nickname, at the user's/UA's whim Number Meaning
----------- --------------------------------------------
0 an unformatted string, at the user's/UA's whim
9.6. HOBAREG HTTP Header For this registry the number column should contain a small positive
integer.
9.6. Hobareg HTTP Header
Please register a new identifier in the Permanent Message Header Please register a new identifier in the Permanent Message Header
Field Names registry as described below. Field Names registry as described below.
Header field name: HOBAREG Header field name: Hobareg
Applicable protocol: HTTP (RFC 7230) Applicable protocol: HTTP (RFC 7230)
Status: Experimental Status: Experimental
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [[ this document ]] Specification document(s): Section 6.1.1 of [[ this document ]]
Related information: N/A. Related information: N/A
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
skipping to change at page 19, line 39 skipping to change at page 21, line 11
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
current (-04) version of HOBA and is available from https://hoba.ie/ current (-04) version of HOBA and is available from https://hoba.ie/
which site also includes a demonstration of HOBA. which site also includes a demonstration of HOBA.
There is another implementation by Michael Thomas of an HOBA-JS There is another implementation by Michael Thomas of 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: Amos Jeffries, Benjamin Kaduk,
Michael Sweet, Ilari Liusvaara, [[ and any more to be added ]]. All Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Melnikov, Yoav
errors and stupidities are of course the editors' fault. Nir, Mark Nottingham, Julian Reschke, Michael Richardson, Yaron
Sheffer, and Michael Sweet. All 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.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[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 22 skipping to change at page 21, line 49
Uniform Resource Identifiers (URIs)", RFC 5785, April Uniform Resource Identifiers (URIs)", RFC 5785, April
2010. 2010.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
2011. 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
[SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST
Special Publications , March 2012.
12.2. Informative References 12.2. Informative References
[MI93] Mitchell, and Thomas, "Standardising Authentication [MI93] Mitchell, and Thomas, "Standardising Authentication
Protocols Based on Public-Key Techniques.", Journal of Protocols Based on Public-Key Techniques.", Journal of
Computer Security 2 (1993): 23-36. , 1993. Computer Security 2 (1993): 23-36. , 1993.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", STD 76, RFC 6376, Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011. September 2011.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July Code: The Implementation Status Section", RFC 6982, July
2013. 2013.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
[bonneau] Bonneau, , "The science of guessing: analyzing an [bonneau] Bonneau, , "The science of guessing: analyzing an
anonymized corpus of 70 million passwords.", Security and anonymized corpus of 70 million passwords.", Security and
Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012. Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012.
Appendix A. Problems with Passwords Appendix A. Problems with Passwords
By far the most common mechanism for web authentication is passwords By far the most common mechanism for web authentication is passwords
that can be remembered by the user, called "human-memorable that can be remembered by the user, called "human-memorable
passwords". There is plenty of good research on how users typically passwords". There is plenty of good research on how users typically
use human-memorable passwords (e.g. see [bonneau]), but some of the use human-memorable passwords (e.g. see [bonneau]), but some of the
 End of changes. 67 change blocks. 
143 lines changed or deleted 244 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/