One document matched: draft-ietf-httpauth-hoba-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY RFC6376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6376.xml">
<!ENTITY RFC6454 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml">
<!ENTITY RFC6265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml">
<!ENTITY RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC6982 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml">
<!ENTITY RFC7235 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7235.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- NOTES FOR FUTURE 

We should talk about revocation, but we should call it de-registration

-->

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="exp" ipr="trust200902" docName="draft-ietf-httpauth-hoba-04">
<front>
<title abbrev="HTTP Origin-Bound Auth (HOBA)">HTTP Origin-Bound Authentication (HOBA)</title>

<author fullname="Stephen Farrell" initials="S." 
surname="Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<city>Dublin</city>
<region></region>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
</address>
</author>

<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>VPN Consortium</organization>
<address>
<email>paul.hoffman@vpnc.org</email>
</address>
</author>

<author fullname="Michael Thomas" initials="M." surname="Thomas">
<organization>Phresheez</organization>
<address>
<email>mike@phresheez.com</email>
</address>
</author>

<date/>

<area>IETF</area>

<workgroup>Network Working Group</workgroup>
<keyword>http authentication</keyword>
<keyword>origin-bound key</keyword>

<abstract>
<t>
HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP 
authentication
method with credentials that are not vulnerable to phishing attacks,
and that does not require any server-side password database. The design can
also be used in Javascript-based authentication embedded in HTML. HOBA is an
alternative to HTTP authentication schemes that require passwords.
</t>
</abstract>
</front>

<middle>

<section title="Introduction">

<t>
HTTP Origin-Bound Authentication (HOBA) is an authentication
design that can be used as an HTTP 
authentication scheme <xref target="RFC7235"/> and for 
Javascript-based authentication embedded in HTML.
The main goal of HOBA is to offer an
easy-to-implement authentication scheme that is not based on passwords, but
that can easily replace HTTP or HTML forms-based password authentication. 
Deployment of HOBA can reduce or eliminate password entries 
in databases, with potentially significant security benefits. 
</t>

<t>
HOBA is an 
HTTP authentication mechanism that complies with the framework for such 
schemes <xref target="RFC7235"/>.
As a JavaScript design, HOBA demonstrates a way for clients and servers to interact using
the same credentials that are used by the HTTP authentication scheme.
</t>

<t>
Current HTTP authentication methods (Basic and Digest), as well as username/password
authentication using web forms,
have been in use for many years, but being based on
passwords, are susceptible to theft of server-side databases. 
Instead of passwords, HOBA uses digital
signatures as an authentication mechanism. HOBA also adds useful features such
as credential management and session logout.
In HOBA, the client creates a new public-private key pair for each host
("web-origin" 
<xref target="RFC6454"/>)
to which it authenticates.
These keys are used in HOBA for HTTP clients to
authenticate themselves to servers in the HTTP protocol or in a Javascript
authentication program.
</t>

<t>
Session management with HOBA is identical to username/password session management. Typically, the
session management tool (such as PHP, Python CGI, and so on)
inserts a session cookie into the output to the browser. HOBA does 
nothing to help or hurt session cookie hijacking; TLS is still required for that.
If the authentication is not bound to HTTP sessions, even TLS cannot
help against all attacks.
</t>

<t>
HOBA keys are "bare keys", so there is no need for the semantic overhead of PKIX
certificates, particularly with respect to naming and trust anchors.
The client public key ("CPK") structures in HOBA do not have any publicly-visible identifier for
the user who possesses the corresponding private key, nor the web-origin with which 
the client is using the CPK.
</t>

<t>
HOBA also defines some services that are required for
modern HTTP authentication:

<list style="symbols">

<t>
Servers can bind a CPK with an identifier, such as an account name. Servers using HOBA
define their own policies for binding CPKs with accounts
during account registration.
</t>

<t> 
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 more than one CPK to
the same account, but without having to register for each separately.
</t>

<t>
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.
</t>

<t>
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 current sessions, even if
more than one session is currently active from different UAs for the
same account.
</t>

<t>
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.
</t>

</list></t>

<section title="Interfacing to Applications (Cookies)">

<t>
HOBA can be used as a drop-in replacement for password-based user 
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
"Login" URL and for the response to a successful HTTP request 
containing a HOBA signature to set a 
session cookie <xref target="RFC6265"/>. Further interactions with the web application will
then be secured via the session cookie, as is commonly done today.
</t>

<t>
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.
</t>

</section>

<section title="Terminology">

<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>

<t>A client public key ("CPK") is the public key and associated cryptographic parameters
needed for a server to validate a signature.</t>

<t>
The term "account" is (loosely) used to refer to whatever 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 will also optionally include an
HTTP "realm" as defined in the HTTP authentication specification. It might
also involve many other non-standard pieces of data that the server
accumulates as part of account creation processes. An account may have many
CPKs that are considered equivalent in terms of being usable for
authentication, but the meaning of "equivalent" is really up to the server and
is not defined here.
</t>

<t>
When describing something that is specific to HOBA as an HTTP authentication
mechanism or HOBA as a JavaScript implementation, this document uses the
terms "HOBA-http" and "HOBA-js", respectively.
</t>

<t>
Web client: the content and javascript code that run within the context of a single
UA instance (such as a tab in a web browser).
</t>

<t>
User agent (UA): typically, but not always, a web browser.
</t>

<t>
User: a person who is running a UA. In this document, "user" does not mean
"user name" or "account name".
</t>

<t>
This specification uses the Augmented Backus-Naur
Form (ABNF) notation of <xref target="RFC5234"/>
</t>

</section>
</section>

<section title="The HOBA Authentication Scheme" anchor="scheme">

<t> 
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-origin/realm combination
for which it has created a CPK.
</t>

<t>
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 generated
nonce, the web-origin, the
realm, an identifier for the CPK and the challenge string; 
and signs that hashed blob 
with 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-side signature verification as simple as possible 
for a wide range of current server tooling.
</t>

<t><xref target="fig_tbs"/> specifies the ABNF for the signature
input. The term "unreserved" means that the field does not have a
specific format defined.
</t>

        <figure title="To-be-signed data for HOBA" anchor="fig_tbs">
        <artwork type="abnf">
HOBA-TBS = nonce alg origin [ realm ] kid challenge
nonce = unreserved
alg = 1*2DIGIT
origin = scheme "://" authority ":" port 
realm = unreserved
kid = unreserved
challenge = unreserved
        </artwork>
        </figure>

<t>
The fields above contain the following:

<list style="symbols">

<t>
nonce: is a random value chosen by the UA and MUST be base64url encoded
before being included in the HOBA-TBS value. (base64url encoding is
defined in <xref target="RFC4648"/>.)
UAs MUST be able to use at least 32 bits of randomness in generating
a nonce. UAs SHOULD be able to use 64 or more bits of randomness for 
nonces. 
</t>

<t>
alg: specifies the signature algorithm being used encoded as an ASCII
character as defined in <xref target="sec_alg"/>.
RSA-SHA256 MUST be 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.
</t>

<t>
origin: is the web origin expressed as the concatenation of the 
scheme, authority and port from <xref target="RFC3986"/>. These
are not base64 encoded as they will be most readily available to the 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 "https://www.example.com:8080".
There is no default for the port number, and the port number MUST be present.
</t>

<t>
realm: is similarly just a string with the syntactic restrictions
defined in 
<xref target="RFC7235"/>.
If no realm is specified for
this authentication then this is absent. (A missing field here is
no problem since both sides know when it needs to be there.)
</t>

<t>
kid: is a key identifier - this MUST be a base64url encoded value
that is presented to the server in the HOBA client result (see
below).
</t>

<t>challenge: MUST be a base64url encoded challenge value that the
server chose to send to the client</t>

</list>
</t>

<t>
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 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. (One form of stateless challenge might
be a ciphertext that the server decrypts and checks, but
that is an implementation detail.) The value that is sent
over the network is the HOBA "client result" which we now
define.
</t>

<t>
The HOBA "client result" is a dot-separated string that includes the signature
and is sent in the HTTP Authorized header field value using the value syntax
defined in <xref target="fig_res"/>. The "sig" value is the base64url encoded
version of the binary output of the signing process. The kid, challenge and
nonce are as defined above and are also base64url encoded.  
</t>

        <figure title="HOBA Client Result value" anchor="fig_res">
        <artwork type="abnf" align="center">

HOBA-RES = kid "." challenge "." nonce "." sig
sig = unreserved

		</artwork>
		</figure>

<t>
The HOBA scheme is far from new, for example, the basic idea
is pretty much identical to the first two messages from "Mechanism R"
on page 6 of <xref target="MI93"/> which predates HOBA by 20 years.
</t>

</section>

<section title="Introduction to the HOBA-http Mechanism">

<t>
An HTTP server that supports HOBA authentication includes the "HOBA"
auth-scheme value in a WWW-Authenticate header field when it wants the client
to authenticate with HOBA.  Note that the HOBA auth-scheme might not be the
only one that the server includes in a WWW-Authenticate.

<list style="symbols">

<t>
If the "HOBA" scheme is listed, it MUST be followed by two or more auth-param
values. The auth-param attributes defined by this specification are below. 
Other auth-param attributes MAY be used as well. Unknown auth-param attributes
MUST be ignored by clients, if present.
</t>

<t>
The "challenge" attribute MUST be included. The challenge is the string made up of the
base64url encoded octets that the server wants the client to sign in its response. The
challenge SHOULD be unique for every HTTP 401 response in order to prevent replay
attacks from passive observers. 
</t>

<t>
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.  

</t>

<t>
A "realm" attribute MAY be included to indicate the scope of protection in the
manner described in HTTP/1.1, Part 7 
<xref target="RFC7235"/>.
The "realm" attribute MUST NOT appear more than once.
</t> 

</list></t>

<t>
When the "client response" is created, the UA
encodes the HOBA client-result (a string matching the HOBA-RES
production in <xref target="fig_res"/> as an auth-param with the 
name "result" and returns that in the Authorization header.  
</t>

<t>
The server MUST check the cryptographic correctness of 
the signature based on a public key it knows for the 
kid in the signatures, and if the server cannot do 
that, or if the signature fails cryptographic checks, 
then validation has failed.
The server can use any additional mechanisms 
to validate the signature. If the validation fails, or 
if the server chooses reject the signature for any reason whatsoever, the
server aborts the transaction via a 401 Unauthorized HTTP
response. 
</t>

<t>
Note that a HOBA signature is good for however long the 
expires attribute allows. This means that replay is 
possible within the time window specified by the "expires"
value chosen by the server. 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 subsequent) 401-status HTTP
response containing a new challenge.
</t>

<t>
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 later in this document. This also allows for pre-calculation of
HOBA signatures, if that is required in order to produce
a responsive user interface.
</t>

</section>

<section title="Introduction to the HOBA-js Mechanism">

<t>
Web sites using JavaScript can also perform origin-bound authentication without needing
to involve the HTTP layer, and by 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 pattern
that can be realized completely in JavaScript served in normal HTML pages.
</t>

<t>
One element is required for HOBA-js: localStorage (see http://www.w3.org/TR/webstorage/) from HTML5.
is used for persistent key storage. For example, an
implementation would store a dictionary account identifier, public key, private key
tuples in the origin's localStorage for subsequent authentication requests. How this information
is actually stored in localStorage is
an implementation detail. This type of key storage relies on the security properties of the same-origin policy that 
localStorage enforces. See the security considerations for discussion about attacks on localStorage.
</t>

<t>
Because of JavaScript's same-origin policy, scripts from subdomains do not have access to the same
localStorage that scripts in their parent domains do. For larger or more complex sites, this could be
an issue that requires enrollment into subdomains, which could be a hassle
for users. One way to get around this is to use session cookies because they can be
used across subdomains. That is, with HOBA-js, the user might log in using a single well-known domain, and
then the server uses session cookies to navigate around a site.
</t>

<t>
Another element 
will be highly desirable for HOBA-js when it becomes available:
WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In lieu of WebCrypto,
JavaScript crypto libraries can be employed with the known deficiencies of PRNG, and the general immaturity of
those libraries.
</t>

</section>

<section title="HOBA's Authentication Process">

<t>
This section describes how clients and servers use HOBA for authentication.
The interaction between an HTTP client and HTTP server using HOBA
happens in three phases: the CPK preparation phase, the signing
phase, and the authentication phase. 
This section also covers the actions that give HOBA
similar user features as today's passwords have.
</t>

<section title="CPK Preparation Phase">

<t>
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, the client will use it; if the
client does not have a CPK, it generates one in anticipation of the
server asking for one.
</t>

</section>

<section title="Signing Phase">

<t>
In the signing phase, the client connects to the server, the server asks
for HOBA-based authentication, and the client authenticates by signing
a blob of information as described in the previous sections.
</t>

</section>

<section title="Authentication Phase">

<t>
The authentication phase is completely dependent on the policies
and practices of the server. That is, this phase
involves no standardized protocol in HOBA-http; in HOBA-js,
there is no suggested interaction template.
</t>

<t>
In the authentication phase, the server extracts the CPK from the
signing phase and decides if it recognizes the CPK. If the server
recognizes the CPK, the server may finish the client authentication
process.
</t> 

<t>
If this stage of the process involves additional information
for authentication, 
such as asking the user which account she wants to use (in the
case where a UA is used for multiple accounts on a site), the 
server can prompt the user for account identifying information or
the user could choose based on HTML offered by the server before
the 401 is triggered. None
of this is 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.
</t>

<t>
During the authentication phase, if the server does not recognize the CPK, 
it could use HTML and JavaScript
to ask the user if they are really a new user or want to associate
this new CPK with an already-joined CPK. The server can then use some
out-of-band method (such as a confirmation email round trip, SMS, or an UA that is 
already enrolled) to verify that the "new" user is the same as the already-enrolled one.
Thus, logging in on a new user agent is identical to logging in with an existing account.
</t>

<t>
If the server does not recognize the CPK the server might send the
client through a either a join or login-new-UA (see below) process. This process 
is completely up to the server, and probably entails using HTML and JavaScript
to ask the user some questions in order to assess whether or
not the server wants to give the client an account. Completion of the joining
process might require confirmation by email, SMS, Captcha, and so on.
</t>

<t>
Note that there is no necessity for the server to initiate a joining
or login process upon completion of the signing phase. Indeed, the server
may desire to challenge the UA even for unprotected resources and
set a session cookie for later use in a join or login
process as it becomes necessary. For example, a server might only want to offer an
account to someone who had been to a few pages on the web site;
in such a case, the server could use the CPK from an associated session cookie
as a way of building reputation for the user until the server wants the user
to join.
</t>

</section>

</section>

<section title="Other Parts of the HOBA Process">

<t>
The authentication process is more than just the act of authentication. In
password-based authentication and HOBA, there are other processes that are needed both
before and after an authentication step. This section covers those processes.
Where possible, it combines practices of HOBA-http and HOBA-js; where that
is not possible, the differences are called out.
</t>

<t>
All additional services MUST be performed in TLS-protected sessions (<xref target="RFC5246"/>).
If the current HTTP traffic is not running under
TLS, a new session is started before any of the actions described here are performed.
</t>

<t>
HOBA-http uses a well-known URL <xref target="RFC5785"/> "hoba" as a base URI
for performing many tasks: "https://www.example.com/.well-known/hoba".
These URLs
are based on the name of the host that the HTTP client is accessing.

</t>

<t>
There are many use cases for these URLs to redirect to other URLs: a site that
does registration through a federated site, a site that only does registration
under HTTPS, and so on. Like any HTTP client, HOBA-http clients have to be able to
handle redirection of these URLs. However, as that would potentially
cause security issues when a re-direct brings the client to a different
web origin, servers implementing HOBA-http SHOULD NOT re-direct to a
different web origin from below .well-known/hoba URLs. 

The above is considered sufficient to allow experimentation with HOBA,
but if at some point HOBA is placed on the standards track then 
a full analysis of off-origin re-directions would need to be 
documented.

</t>

<section title="Registration">

<t>
Normally, a registration (also called "joining") is expected to happen after a UA receives a
WWW-Authenticate for a web-origin and realm (for HOBA-http) or on demand
(for HOBA-js) for which it has no associated CPK. The
process of registration for a HOBA account on a server is relatively
light-weight. The UA generates a new key pair, and associates it with the
web-origin/realm in question.
</t>

<t>
Note that if the UA has a CPK associated with the web-origin, but not for the
realm concerned, then a new registration is REQUIRED. If the server
did not wish for that outcome, then it ought to use the same or no realm.
</t>

<t>
The registration message for HOBA-http is sent as a POST message
to the URL ".well-known/hoba/register" with an HTML form (x-www-form-encoded)
described below;
The registration message for HOBA-js can be in any format specified by
the server, but it could be the same as the one described here for HOBA-http.
It is up to the
server to decide what kind of user interaction is required before the account
is finally set up.
</t>

<t>
The registration message sent to server has
one mandatory field (pub) and some
optional fields that allow the UA to specify the type and value
of key and device identifiers that the UA wishes to use.


<list style="symbols">

<t>
pub: is a mandatory field containing the PEM formatted public key of the
client. See Appendix C of <xref target="RFC6376"/> for an example
of how to generate this key format.
</t>

<t>
kidtype: contains the type of key identifier, this is a numeric
value intended to contain one of the values from <xref target="sec_kidtypes"/>.
If this is not present then the mandatory-to-implement hashed public key
option MUST be used.
</t>

<t>
kid: contains the key identifier as a base64url encoded string 
that is of the type indicated in the kidtype. If the kid is a hash
of a public key then the correct (base64url encoded) hash value MUST be provided and
the server SHOULD check that and refuse the registration if an incorrect
value was supplied.
</t>

<t>
didtype: specifies a kind of device identifier intended to contain
one of the values from <xref target="sec_didtypes"/>, if absent then the
"string" form of device identifier MUST be used. 
</t>

<t>
did: a UTF8 string that specifies the device identifier. This can be 
used to help a user be confident that authentication has worked, e.g.,
following authentication some web content might say "You last logged
in from device 'did' at time T." 
</t>

</list>

</t>

<t>
Note that replay of registration (and other HOBA) messages is quite
possible. That however can be counteracted if challenge freshness
is ensured. See <xref target="scheme"/> for details. Note also
that with HOBA-http 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 account management actions.
</t>


<t>
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 POST message defined above may not be the end
of the registration process even though the HTTP response has
a 200 OK status. This creates an issue for the UA since,
during the registration process (e.g., while dealing with 
interstitial pages), the UA doesn't yet know whether the 
CPK is good for that web origin or not.

</t>

<t>

For this reason the server MUST add a header to the 
response message when the registration has succeded 
to indicate the new state. The header to be used is
"HOBA-REG" and the value when registration has 
succeeded is to be "regok". When registration is 
in-work (e.g. on an HTTP response for an interstitial
page) the server MAY add this header with a value
of "reginwork". See <xref target="hrheader"/> for
the relevant IANA registration of this header field.

</t>

<t>
For interstitial pages, the client MAY include a
HOBA Authorization header. This is not considered a 
MUST as that might needlessly complicate client 
implementations but is noted here in case a server
implementer assumes that all registration messages
contain a HOBA Authorization header.
</t>

</section>

<section title="Associating Additional Keys to an Exiting Account">

<t>

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 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 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 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
which this ought not be done.

</t>

<t>
Note that the context here is usually that the user
has succeeded in registering with one or more UAs
(for the purposes of this section we call this "the first UA" below)
and can use HOBA with those, and the user is now 
adding another UA. The newest UA might or might not
have a CPK for the site in question. Since it
is in fact trivial, we assume
that the site is able to put in place some 
appropriate quicker, easier registration for a 
CPK for the newest UA. The issue then becomes
one of binding the CPK from the newest UA with
those of other UAs bound to the account.

</t>


<section title="Moving private keys">

<t>
It is common for a user to have multiple UAs, and to want all those
UAs to be able to authenticate to a single account.  One method to
allow a user who has an existing account to be able to authenticate
on a second device is to securely transport the private and public
keys and the origin information from the first device to the second.
If this approach is taken, then there is no impact on the HOBA-http
or HOBA-js so this is a pure UA implementation issue and not 
discussed further.
</t>

</section>

<section title="Human memorable one time password (don't do this one)">

<t>
It will be tempting for implementers to use a human-memorable
one-time password (OTP) in order to "authenticate" binding
CPKs to the same account.
The workflow here would likely be something 
along the lines of some server administrative utility 
generating a human memorable OTP such as "1234" and sending
that to the user out of band for the user to enter at
two web pages each authenticated via the relevant CPK. While this 
seems obvious enough and could even be secure enough
in some limited cases, we consider that this is too risky
to use in the Internet and so servers SHOULD NOT
provide such a mechanism. The reason this is so dangerous
is that it would be trivial for an automated client to
guess such tokens and "steal" the binding intended
for some other user. At any scale, there would always
be some in-process bindings so that even with 
only a trickle of guesses (and hence not being detectable
via message volume) an attacker would have a high probability of
succeeding in registering a binding with the attacker's
CPK.
</t>

<t>This method of binding CPKs together is therefore
NOT RECOMMENDED.</t>

<!--


<t>
To enroll a new UA using an existing UA, the user requests a one-time password that will be entered
in the new UA. On HOBA-http, this is done with the URL ".well-known/hoba/associate-start" using a
POST message << more detail is clearly needed here ]]. The server displays a one-time password that
expires in a short amount of time (such as 30 minutes) on the currently enrolled UA. The new UA
generates a new CPK and sends it to the server. In HOBA-http, this is done with a POST to
".well-known/hoba/associate-finish" << more detail needed here ]].
</t>

<t>
The one-time password should be easy for a user to type into the new UA, but at the same time needs
to have enough randomness to prevent an attacker from succeeding if they try to use the password
during its short lifetime. After the server gets the password in the new UA, it verifies the
signature and verifies that the password supplied is in a list of unexpired one-time passwords. If
so, the server knows that the authenticated user is associated with the second CPK. The server can
choose to associate the two CPKs with one account. Whether to do so is entirely at the server's
discretion however, but the server needs make the outcome clear to the user.
</t>

<t>
Alternatively, if an already-enrolled UA is not available to the user when they want to associate a
new UA with an existing account, and the site has an out-of-band communication mechanism such as
email or SMS associated with that account, the user can request that a one-time password be sent to
the user out of band. The user receives the one-time password and, using the new UA, tells it to the
server. On HOBA-http, this is done with the URL ".well-known/hoba/associate-from-oob" using a POST
message << more detail is clearly needed here ]].
</t>

<t>
<< Note: the hoba.ie implementation doesn't do this - I omitted a human
memorable OTP for now. The reason is I think the probability that
spammers would try those is too high. So maybe we should delete this
entirely? ]]
</t>

-->

</section>

<section title="Out of band URL">

<t>
One easy binding method is to simply provide a web page 
where, using the
first UA, the user
can generate a URL (containing some "unguessable" cryptographically
generated value) that
the user then later de-references on the newest UA.
The user could e-mail that URL to herself
for example, of the web server accessed at the first UA
could automatically do that.
</t>

<t>
Such a URL SHOULD contain at least the equivalent
of 128 bits of randomness.
</t>

</section>

</section>

<section title="Logging Out">

<t>
The user can tell the server it wishes to log out.
With HOBA-http, this is done by sending any
HOBA-authenticated HTTP message to the URL
".well-known/hoba/logout" on the site in question. 
The UA SHOULD also delete
session cookies associated with the session so that
the user's state is no longer "logged in."
</t>

<t>
The server MUST NOT allow TLS session resumption for 
any logged out session.
</t>

<t>
The server SHOULD also revoke or
delete any cookies associated with the session.  
</t>

</section>

<section title="Getting a Fresh Challenge">

<t>
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, the response response MUST include
a fresh (base64url encoded) HOBA challenge for this origin in the body of the
response.
</t>

</section>

</section>

<section title="Mandatory-to-Implement Algorithms">

<t>
RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used.
RSA modulus lengths of at least 2048 bits SHOULD be used.
</t>

</section>

<section title="Security Considerations">

<t>
If key binding was server-selected then a bad actor could bind different
accounts belonging to the user from the network with possible bad consequences,
especially if one of the private keys was compromised somehow. 
</t>

<t>
Binding my CPK with someone else's account would be fun and profitable so
SHOULD be appropriately hard. In particular URLs or other values generated 
by the server as part of any CPK binding 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 reveal whether
or not an account exists.
</t>

<section title="Privacy considerations">

<t>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 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 that will not vary for a given 
key. For this reason, and others, it is strongly
RECOMMENDED to only use HOBA over server-authenticated
TLS and to migrate web sites using HOBA to 
only use "https" URLs.
</t>

<t>UAs SHOULD provide users a way to manage their
CPKs. Ideally, there would be a way for a user
to maintain their HOBA details for a site while
at the same time deleting other site information
such as cookies or non-HOBA HTML5 LocalStorage.
However, as this is likely to be complex and
appropriate user interfaces counter intutitive,
we exepect that UAs that implement HOBA will 
likely treat HOBA information as just some more
site data, that would disappear should the user
choose to "forget" that site.
</t>

</section>

<section title="localStorage Security for Javascript">

<t>
Our use of localStorage will undoubtedly be a cause for concern. localStorage uses the
same-origin model which says that the scheme, domain and port define a localStorage instance.
Beyond that, any code executing will have access to private keying material. Of 
particular concern are XSS attacks which could conceivably take the keying material and use
it to create UAs under the control of an attacker. But XSS attacks are in
reality across the board devastating since they can and do steal credit card information, 
passwords, perform illicit acts, etc, etc. It's not clear that we introduce unique threats
from which clear text passwords don't already suffer.
</t>

<t>
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 through a javascript console, or find 
the file(s) that implement 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 password files, etc too. 
One possible mitigation is to encrypt the keystore with a password/pin the user supplies. 
This may sound counter intuitive, but the object here is to keep passwords off of servers to 
mitigate the multiplier effect of a large scale compromise ala LinkedIn because of 
shared passwords across sites.
</t>

<t>
It's worth noting that HOBA uses asymmetric keys and not passwords when evaluating threats. As 
various password database leaks have 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 password on too. That is, the 
collateral damage is severe because password reuse is common. Storing a password in 
localStorage would also have a similar multiplier effect for an attacker, though perhaps on a 
smaller scale than a server-side compromise: one successful crack gains the attacker potential access 
to hundreds if not thousands of sites the user visits. HOBA does not suffer from that attack multiplier
since each asymmetric key pair is unique per site/UA/user.
</t>

</section>

<section title="Multiple Accounts on One User Agent">

<t>
A shared UA with multiple accounts is possible if the account identifier is stored along with the 
asymmetric key pair binding them to one another. Multiple entries can be kept, one for each 
account, and selected by the current user. This, of course, is fraught with the possibility 
for abuse, since a server is potentially enrolling the device for a long period and the
user may not want to have to be responsible for the credential for that long. To
alleviate this problem, the user can request that the credential be erased from the browser.
Similarly, during the enrollment phase, a user could request that the key pair only 
be kept for a certain amount of time, or that it not be stored beyond the current
browser session.
</t>

</section>

</section>

<section title="IANA Considerations">

<t>IANA is requested to make registrations and create new
registries as described below.</t>

<section title="HOBA Authentication Scheme">

<t>Please register a new scheme in the
HTTP Authentication Scheme Registry registry as follows:</t>

<t> 
Authentication Scheme Name: HOBA
</t>

<t>
Pointer to specification text: [[ this document ]]
</t>

<t>
Notes (optional): The HOBA scheme can be used with
either HTTP servers or proxies. When used in 
response to a 407 Proxy Authentication Required
indication, the appropriate proxy authentication
header fields are used instead, as with any 
other HTTP authentication scheme.
 
</t>

</section>

<section title=".well-known URI">

<t>Please register a new .well-known URI in the
Well-Known URIs registry as described below.</t>

<t>
   URI suffix:  hoba
</t><t>

   Change controller: IETF
</t><t>

   Specification document(s):  [[ this document ]]
</t><t>

   Related information:  N/A.
</t>

</section>

<section title="Algorithm Names" anchor="sec_alg">

<t>Please create a new HOBA signature algorithms
registry as follows, with the specification 
required rule for updates.</t>

<t>TBD, hopefully re-use and existing registry</t>

<t>"0" means RSA-SHA256</t>
<t>"1" means RSA-SHA1</t>

</section>

<section title="Key Identifier Types" anchor="sec_kidtypes">

<t>Please create a new HOBA Key Identifier Types
registry as follows, with the specification 
required rule for updates.</t>

<t>
"0" means a hashed public key, as done in DANE. <xref target="RFC6698"/>
</t>
<t>
"1" means a URI, such as a mailto: or acct: URI, but anything conforming
to <xref target="RFC3986"/> is ok.i
</t>
<t>
"2" means an unformatted string, at the user's/UA's whim
</t>

</section>

<section title="Device Identifier Types" anchor="sec_didtypes">

<t>Please create a new HOBA Device Identifier Types
registry as follows, with the specification 
required rule for updates.</t>


<t>
"0" means an unformatted nickname, at the user's/UA's whim
</t>

</section>

<section title="HOBAREG HTTP Header" anchor="hrheader">

<t>Please register a new identifier in the 
Permanent Message Header Field Names registry as
described below.</t>

<t>
   Header field name: HOBAREG
</t><t>

   Applicable protocol: HTTP (RFC 7230) 
</t><t>

   Status: Experimental
</t><t>

   Author/Change controller: IETF
</t><t>

   Specification document(s): [[ this document ]]
</t><t>

   Related information: N/A.

</t>

</section>


</section>

<section title="Implementation Status">
<t>[[ Note to RFC editor - please delete this section before publication. ]]</t>

<t>
    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 
      <xref target="RFC6982"/>.  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.
</t>

<t>
      According to 
      <xref target="RFC6982"/>
      "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".
</t>

<t>

At the time of writing there are two known implementations. One done 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/ which site also includes
a demonstration of HOBA.

</t>

<t>

There is another implementation by Michael Thomas of an
HOBA-JS variant. 

</t>


</section>

<section title="Acknowledgements">

<t>
Thanks to the following for good comments received
during the preparation of this specification:
Julian Reschke, James Manger, Michael Sweet, Ilari Liusvaara, [[ and any more to be added ]].
All errors and stupidities are of course the 
editors' fault.
</t>

</section>

</middle>

<back>
<references title="Normative References">
&RFC2119;
&RFC3986;
&RFC5234;
&RFC5246;
&RFC5785;
&RFC6454;
&RFC6698;

</references>
<references title="Informative References">
&RFC4648;
&RFC6265;
&RFC6376;
&RFC6982;
&RFC7235;

<reference anchor="MI93">
	<front> 
		<title>Standardising Authentication Protocols Based on Public-Key Techniques.</title>
		<author surname="Mitchell" fullname="Chris J. Mitchell"></author> 
		<author surname="Thomas" fullname="Andy Thomas"></author>
		<date year="1993"/>
	</front>
	<seriesInfo name="Journal of Computer Security 2 (1993): 23-36." value=""/>
</reference>

<reference anchor="bonneau">
	<front>
		<title>The science of guessing: analyzing an anonymized corpus of 70 million passwords.</title>
		<author surname="Bonneau" fullname="Joseph Bonneau"></author>
		<date year="2012"/>
	</front>
	<seriesInfo name="Security and Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012." value=""/>
</reference>

</references>

<section title="Problems with Passwords">

<t>
By far the most common mechanism for web authentication is passwords that can
be remembered by the user, called "human-memorable passwords".
There is plenty of good research on how users typically use human-memorable
passwords (e.g. see <xref target="bonneau"/>), but 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 use either email addresses or users' names
as the identifier that goes with these passwords.
</t>

<t>
If an attacker gets access to the database of memorizable passwords, that
attacker can impersonate any of the users. Even if the breach is discovered,
the attacker can still impersonate users until every password is changed.
Even if all the passwords are changed or at least made unusable, the
attacker now possesses a list of likely username/password pairs that might
exist on other sites.
</t>

<t>
Using memorizable passwords on unencrypted channels also poses risks to the
users. If a web site uses either the HTTP Plain authentication method, or an
HTML form that does no cryptographic protection of the password in transit, a
passive attacker can see the password and immediately impersonate the user. If
a hash-based authentication scheme such as HTTP Digest authentication is used,
a passive attacker still has a high chance of being able to determine the
password using a dictionary of known passwords.
</t>

<t>Note that passwords that are not human-memorable are still 
subject to database attack, though are of course unlikely to be
re-used across many systems. Similarly, database attacks of some
form or other will work against any password based authentication
scheme, regardless of the crytographic protocol used. So for example,
zero-knowledge or PAKE schemes, though making use of elegant 
cryptographic protocols, remain as vulnerable to what is clearly
the most common exploit seen when it comes to passwords. HOBA is
however not vulnerable to database theft.</t>


</section>

<section title="Example" anchor="examples">

<t>
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.
</t>

<figure><artwork><![CDATA[
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3TpLg0kglmnZIXNQZ6g6
Aj6b9PAhHD1TojOiuJZAY8KblNu-0WbiUSwTzl1EPBCa4Og3SNR0-8omb09iDSTV
nKGEYcAHxP2wvvqOFrb6f8GWFHxHw4MiODlnSTvHARx6wiogY4w7WIs57ETZfiJY
MYyo6swHXO4DofteTasjuQwZ_5L4sbCR_aZx7Nsv4O4hNhCreoCfh0QD6pQQ-krW
0Ny8mGEecnAG0reXRgBvCmDq2I15jV8yqXuNYqEORO-vur2-JztH8pQUoSTfTkMv
h0EyVfWzq9KtykKWXyv625CGVkxR3MMAfitxKgtZit0hw9_VCXtfhvwZcfnhmhxG
ZQIDAQAB
-----END PUBLIC KEY-----
]]></artwork></figure>


<t>
Key Identifier: kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267UetbAfkWHbw
</t>

<t>
Challenge: z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs=
</t>

<t>
Nonce: LV_WTVyHFfE
</t>

<t>
Tbsorigin: https://hoba-local.ie:443
</t>

<t>
The resulting signature is: 
</t>
<figure><artwork><![CDATA[
qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZajb
zb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR84
O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX57
2ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDqX
PwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww9
XO593LaL3LnykmMn11ddiw
]]></artwork></figure>
<t>
The final HTTP header field sent with a request is then:
</t>
<figure><artwork><![CDATA[
Authorization: HOBA result="kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267Uetb
AfkWHbw.z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs=.LV_WTVyHFfE
.qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZaj
bzb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR8
4O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX5
72ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDq
XPwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww
9XO593LaL3LnykmMn11ddiw"
]]></artwork></figure>


</section>

</back>
</rfc>