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

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0020.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.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 RFC6265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.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 RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC6750 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml">
<!ENTITY RFC6982 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml">
<!ENTITY RFC7231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7231.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 

Add a full HTTP request/response example.

-->

<?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-10">
<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 digital signature based design for
an HTTP authentication method.  The design can also be used in Javascript-based
authentication embedded in HTML. HOBA is an alternative to HTTP authentication
schemes that require passwords and therefore avoids all problems related to
passwords, such as leakage of server-side password databases. 
</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 username/password authentication methods such as HTTP Basic,
HTTP Digest, and web forms have been in use for many years but are
susceptible to theft of server-side password databases.
Instead of passwords, HOBA uses digital
signatures in a challenge-response scheme as it's 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>
HOBA session management is identical to username/password session
management, with a server-side session management tool or script
inserting a session cookie <xref target="RFC6265"/> 
into the output to the browser.  
Use of TLS for the HTTP session is still necessary to prevent
session cookie hijacking.
</t>

<t>
HOBA keys are "bare keys", so there is no need for the semantic overhead of 
X.509 public key 
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 needed 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>
Logout features can be useful for UAs, so HOBA defines a way to close a
current HTTP "session."
</t>

<t>
Digital signatures can be expensive to compute, so HOBA defines a
way for HTTP servers to indicate how long a given challenge value is
valid, and a way for UAs to fetch a fresh challenge at any time.

</t>

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

<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 title="Interfacing to Applications (Cookies)" anchor="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 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>
This specification uses the Augmented Backus-Naur
Form (ABNF) notation of <xref target="RFC5234"/>.
</t>

<t>
Account: 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 at least one CPK and a web-origin; it will also optionally include an
HTTP "realm" as defined in the HTTP authentication specification
<xref target="RFC7235"/>.
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>Client public key ("CPK"): A CPK is the public key and associated cryptographic parameters
needed for a server to validate a signature.</t>

<t>
HOBA-http: 
We use this term when describing something that is specific to HOBA as an 
HTTP authentication mechanism.
</t>

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

</section>

<section title="Step-by-step Overview of HOBA-http">
<t>
Step-by-step, a typical HOBA-http registration and authentication flow might look like this:
<list style="numbers">

<t>The client connects to the server and makes a request, and the server's 
response includes a WWW-Authenticate header field that contains the "HOBA" 
auth-scheme, along with associated parameters (see <xref target="s3"/>).
</t>

<t>
If the client was not already registered with the web-origin and realm it is 
trying to access, the "joining" process is invoked (see <xref target="s6.1"/>).  This 
creates a key pair and makes the CPK known to the server so that the
server can carry out the account creation processes required.
</t>

<t>The client uses the challenge from the HOBA auth-scheme parameters, along 
with other information it knows about the web-origin and realm, to create 
and sign a HOBA-TBS string (see <xref target="scheme"/>).
</t>

<t>The client creates a HOBA client-result (HOBA-RES), using the signed 
HOBA-TBS for the "sig" value (see <xref target="scheme"/>).
</t>
<t>The client includes the Authorization header field in its next request, 
using the "HOBA" auth-scheme and putting the HOBA client-result in an 
auth-param named "result" (see <xref target="s3"/>).
</t>
<t>The server authenticates the HOBA client-result (see <xref target="phase"/>).
</t>
<t>Typically, the server's response includes a session cookie that allows 
the client to indicate its authentication state in future requests (see 
<xref target="cookies"/>).
</t>
</list>
</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 a 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 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 and allows the characters specified in 
Section 2.3 of <xref target="RFC3986"/>.
</t>

        <figure title="To-be-signed data for HOBA" anchor="fig_tbs">
        <artwork type="abnf" align="left">

   HOBA-TBS = len ":" nonce 
           len ":" alg 
           len ":" origin 
           len ":" [ realm  ]
           len ":" kid 
           len ":" challenge
   len = 1*DIGIT
   nonce = 1*base64urlchars
   alg = 1*2DIGIT
   origin = scheme "://" authority ":" port 
   ; scheme etc are from RFC 3986
   realm = unreserved
   ; realm is to be treated as in Section 2.2 of RFC 7235
   kid = 1*base64urlchars
   challenge = 1*base64urlchars
   ; Characters for Base64URL encoding from Table 2 of RFC 4648
   ; all of which are US-ASCII (see RFC 20)
   base64urlchars = %x30-39             ; Digits
                 / %x41-5A           ; Uppercase letters
                 / %x61-7A           ; Lowercase letters
                 / "-" / "_" / "="   ; Special characters
        </artwork>
        </figure>

<t>
The fields above contain the following:

<list style="symbols">

<t>
len: Each field is preceeded by the number of octets of the following
field, expressed as a decimal
number in ASCII <xref target="RFC0020"/>. 
Lengths are separated from field values by a colon
character.
So if a nonce with
the value "ABCD" were used then that would be preceeded
by "4:" (see the example in <xref target="examples"/>
for detail).

</t>

<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"/>, guidelines for randomness are
give in <xref target="RFC4086"/>.)
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. See
<xref target="mti"/> for details of algorithm support
requirements.
</t>

<!--  
<t.
RSA-SHA256
MUST be supported, RSA-SHA1 MAY be supported.  RSA-SHA1 MUST
NOT be used, except in cases where SHA256 is unavailable, say
if some development platform has to be used that is quite out
of date.
</t>
-->

<t>
The IANA
registered algorithm values (see <xref target="sec_alg"/>) are encoded as one-
or two-digit ASCII numbers.  For example, RSA-SHA256 (number 0) 
is encoded as the ASCII character "0" (0x30), while a future
algorithm registered as number 17 would be encoded as the
ASCII characters "17" (0x3137).
</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, but is preceeded by a
length of zero ("0:"). Recall
both sides know when this needs to be there, independent of
the encoding via a zero length.
</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. The challenge MUST be chosen
      so that it is infeasible to guess, and SHOULD be indistinguishable
      from (the base64url encoding of) an at least 128-bit long random 
      string. </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 
reduce the amount of state that needs to be
maintained by servers.
(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 by the UA 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 Authorizaion 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="left">

   HOBA-RES = kid "." challenge "." nonce "." sig
   sig = 1*base64urlchars

		</artwork>
		</figure>

<t>
If a malformed message of any kind is received by a server,
the server MUST fail authenticaiton. If a malformed message
of any kind is received by a client, the client MUST
abandon that authentication attempt. (The client is of
course free to start another authentication attempt if
it desires.)
</t>


</section>

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

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

<t>
The HOBA scheme has two REQUIRED attributes (challenge and max-age) and one OPTIONAL 
attribute (realm):

<list style="symbols">

<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 MUST be unique for every HTTP 401 response in order to prevent replay
attacks from passive observers. 
</t>

<t>
A "max-age" 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 for example "max-age: 10" would indicate ten
seconds. If max-age is set to zero, then that means that
only one signature will be accepted for this challenge. 

</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 and returns that in the Authorization header.
The client-result is a string matching the HOBA-RES
production in <xref target="fig_res"/> as an auth-param with the 
name "result".  
</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 fails the request with a 401 Unauthorized HTTP
response. 
</t>

<t>The server MUST check that the same web origin
is used in all of the server's TLS server certificates,
the URL being accessed and the HOBA signature. If
any of those checks fail, the server treats the 
signature as being cryptographically incorrect.</t>

<t>
Note that a HOBA signature is good for however long a
non-zero 
max-age parameter allows. This means that replay is 
possible within the 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 choose) and MAY react to such replays by 
responding with a second (or subsequent) 401-status HTTP
response containing a new challenge. 
</t>

<t>
To optimise their use of challenges, UAs MAY pre-fetch a challenge
value, for example after (max-age)/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 thing that is highly desirable for HOBA-js 
is WebCrypto (see http://www.w3.org/TR/WebCryptoAPI) which is
(at the time of writing) starting to see deployment.
In lieu of WebCrypto, JavaScript crypto libraries can be employed with
the known deficiencies of their pseudo-random number generators and
the general immaturity of those libraries.  </t>

<t>
Without Webcrypto, one element is required for HOBA-js: localStorage (see http://www.w3.org/TR/webstorage/) from HTML5
can be used for persistent key storage. For example, an
implementation would store a dictionary account identifier, public key and 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.
Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an alternative to localStorage that can also be used here and that is used by WebCrypto.
</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 difficult
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 session cookies are used whilst the user navigates around the site.
</t>


</section>

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

<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
user features similar to today's password based schemes.
</t>

<section title="CPK Preparation Phase" anchor="phase">

<t>
In the CPK preparation phase, the client determines if it already has a CPK for
the web-origin with which it needs to authenticate. 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 uses the key identifier
(kid) to determine 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 response 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 cannot determine the 
correct 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 another 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" anchor="s6">

<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 HOBA interactions other than those defined in <xref target="hobaauth"/>  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 requests. 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" anchor="s6.1">

<t>
Normally, a registration (also called "joining") is expected to happen after a UA receives a
401 response 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)
(see http://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data)
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. When the server's chosen registration flow is 
completed successfully the server MUST add a Hobareg HTTP header 
(see <xref target="hrdef"/>) to 
the HTTP response message that completes the registration flow.
</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 defined in <xref target="sec_didtypes"/> 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>

<section title="Hobareg Definition" anchor="hrdef">

<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 field to the 
response message when the registration has succeded 
to indicate the new state. The header to be used is
"Hobareg" and the value when registration has 
succeeded is to be "regok". When registration is 
in an intermediate state (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>

        <figure title="Hobareg Header Field Definition" anchor="fig_hrdef">
        <artwork type="abnf" align="left">

   Hobareg-val = "regok" / "reginwork"

        </artwork>
        </figure>

<t>
<xref target="fig_hrdef"/> 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 <xref target="RFC7231"/> calls
for documenting the following details for this
new header field:

<list style="symbols">

<t>Only one single value is allowed in a Hobareg header field. Should
more than one (a list) be encountered or any other ANBF-invalid value, 
that SHOULD be interpreted as
being the same as "reginwork."
</t>

<t>The Hobareg header field can only be used in HTTP responses.</t>

<t>Since Hobareg is only meant for responses it ought not appear in requests.</t>

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

<t>Intermediaries never insert, delete or modify a Hobareg
header field.</t>

<t>As a response-only header field, it is not appropriate to list a Hobareg in a Vary response header field.</t>

<t>Hobareg is allowed in trailers.</t>

<t>As a response-only header field, Hobareg will not be preserved across re-directs.</t>

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

</list>
</t>

</section>
</section>

<section title="Associating Additional Keys to an Existing 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 a
HOBA-authenticated POST 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 MUST 
contain
a fresh (base64url encoded) HOBA challenge for this origin in the body of the
response. Whitespace in the response MUST be ignored.
</t>

</section>

</section>

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

<t>
RSA-SHA256 MUST be supported. 
HOBA implementations MUST use RSA-SHA256 if it is provided by the underlying cryptographic libraries.
RSA-SHA1 MAY be used.
RSA modulus lengths of at least 2048 bits SHOULD be used.
RSA indicates the RSASSA-PKCS1-v1_5 algorithm defined in Section 8.2 of <xref target="RFC3447"/>, and
SHA-1 and SHA-256 are defined in <xref target="SHS"/>.
Keys with moduli shorter than 2048 bits SHOULD only be
used in cases where generating 2048-bit (or longer)
keys is impractical, e.g. on very constrained or old
devices.
</t>

<!-- 
This is already stated above!
<t>RSA public keys with at least 2048 bit moduli SHOULD be used for
HOBA. Shorter keys might exceptionally be needed for devices where
key generation has to be done in the foreground and takes minutes,
which is the case with some older phone/Javascript engine combinations.
</t>
-->

</section>

<section title="Security Considerations">

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

<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>
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 <xref target="RFC6750"/> therefore apply in any case where the
HOBA signature can be replayed. Server administrators
can 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 short for the slowest signing device that is 
significant for that site.
</t>

<section title="Privacy considerations" anchor="privacy">

<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 expect 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>

<t>Device identifiers are intended to specify
classes of device in a way that can assist with
registration and with presentation to the user
of information about previous sessions, e.g.
last login time. Device identifier types MUST
NOT be privacy sensitive, with values that
would allow tracking a user in unexpected ways. 
In particular, using an device identifier type 
that is analogous 
to the International
Mobile Equipment Identifier (IMEI) 
would be a really bad idea and is the reason
for the MUST NOT above.
In that case "mobile phone" could be an
acceptable choice.
</t>

<t>
If possible, implementations ought encourage
use of device identifier values that are not
personally identifying except for the user
concerned, for example "Alice's mobile" is
likely to be chosen and is somewhat identifying
but "Alice's phone: UUID 1234-5567-89abc-def0"
would be a very bad choice. 
</t>


</section>

<section title="localStorage Security for Javascript">

<t>
The use of localStorage (likely with a non-WebCrypto implementation of
HOBA-js) 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 
<xref target="bland"/>
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 could 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. However, all such features really ought be part of
the operating system or platform and not part of a HOBA implementation 
so those are not discussed further.
</t>

</section>

<section title="Injective Mapping for HOBA-TBS">

<t>The repeated length fields in the HOBA-TBS structure are
present in order to ensure that there is no possibility
that the catenation of different input values can cause
confusion that might lead to an attack, either against HOBA
as specified here, or else an attack against some other
protocol that re-used this to-be-signed structure. Those
fields ensure that the mapping from input fields to the
HOBA-TBS string is an injective mapping.</t>

</section>

</section>

<section title="IANA Considerations">

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

<t>For all new registries requested by this
document, please place those beneath a new
"HTTP Origin-Bound Authentication (HOBA)
Parameters" category.</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: <xref target="s3"/> of [[ 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):  <xref target="s6"/> of [[ 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. New HOBA signature 
algorithms SHOULD be in use with other IETF
standards track protocols before being added
to this registry.</t>

        <figure>
          <artwork>
            <![CDATA[
Number       Meaning                                       
-----------  --------------------------------------------  
0            RSA-SHA256 
1            RSA-SHA1]]>
          </artwork>
        </figure>

<t>RSA is defined in Section 8.2 of <xref target="RFC3447"/>, and
SHA-1 and SHA-256 are defined in <xref target="SHS"/>.</t>

<t>For this registry the number column should contain a small positive integer.
Following the ABNF above, the maximum value for this is decimal 99.</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>


        <figure>
          <artwork>
            <![CDATA[
Number       Meaning                                       
-----------  --------------------------------------------  
0            a hashed public key [RFC6698]
1            a URI [RFC3986]
2            an unformatted string, at the user's/UA's whim]]>
          </artwork>
        </figure>

<t>
For the number 0, hashed public keys are as done in DANE. <xref target="RFC6698"/> 
</t>

<t>For this registry the number column should contain a small positive integer.</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>The designated expert for this registry is to
carefully pay attention to the notes on this field
in <xref target="privacy"/>, in particular the 
"MUST NOT" stated therein.
</t>


        <figure>
          <artwork>
            <![CDATA[
Number       Meaning                                       
-----------  --------------------------------------------  
0            an unformatted UTF8 string, at the user's/UA's whim]]>
          </artwork>
        </figure>

<t>For this registry the number column should contain a small positive integer.</t>

</section>

<section title="Hobareg HTTP Header Field" 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): <xref target="hrdef"/> of [[ 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 three known implementations. 

<list>

<t>One done by Stephen
Farrell of HOBA-http and a HOBA-JS variant implements the current 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 a
HOBA-JS variant. 

</t>

<t>The most recent (Dec 2014) implementation is by Portugal Telecom 
and is available from https://github.com/razevedo/hoba-authentication</t>

</list>

</t>


</section>

<section title="Acknowledgements">

<t>
Thanks to the following for good comments received
during the preparation of this specification:
Richard Barnes,
David Black,
Alissa Cooper,
Donald Eastlake,
Amos Jeffries, 
Benjamin Kaduk, 
Watson Ladd,
Barry Leiba,
Matt Lepinski,
Ilari Liusvaara, 
James Manger, 
Alexey Melnikov,
Kathleen Moriarty,
Yoav Nir, 
Mark Nottingham,
Julian Reschke, 
Pete Resnick,
Michael Richardson,
Yaron Sheffer, 
and
Michael Sweet.
All errors and stupidities are of course the 
editors' fault.
</t>

</section>

</middle>

<back>
<references title="Normative References">
&RFC0020;
&RFC2119;
&RFC3447;
&RFC3986;
&RFC4648;
&RFC5234;
&RFC5246;
&RFC5785;
&RFC6454;
&RFC6698;
&RFC6750;
&RFC7231;
&RFC7235;

<reference anchor="SHS">
   	<front>
		<title>Secure Hash Standard (SHS), FIPS PUB 180-4</title>
		<author surname="NIST" fullname="National Institute of Standards and Technology"></author>
		<date year="2012" month="March"/>
	</front>
	<seriesInfo name="NIST Special Publications" value=""/>
</reference>

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

<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="IEEE Symposium on Security and Privacy" value=""/>
</reference>

<!--
		<reference anchor="lin" target="https://en.wikipedia.org/w/index.php?title=2012_LinkedIn_hack&oldid=627073049">
			<front>
				<title>2012 LinkedIn Hack</title>
				<author surname="Wikipedia contributors" fullname="Wikipedia contributors"/>
				<date month="September" year="2014"/>
			</front>
		</reference>
-->

		<reference anchor="bland" target="http://www.sophos.com/en-us/medialibrary/pdfs/other/sophossecuritythreatreport2013.pdf">
			<front>
				<title>Security Threat Report 2013</title>
				<author surname="Sophos" fullname="Sophos"/>
				<date month="January" year="2013"/>
			</front>
		</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 Basic 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://example.com:443.
Carriage-returns have been added and need to be removed to
validate the example. 
</t>

<t>
Public Key:  
</t>
<figure><artwork><![CDATA[
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG
DQIDAQAB
-----END PUBLIC KEY-----
]]></artwork></figure>

<t>
Origin:  https://example.com:443
</t>
<t>
Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w
</t>
<t>
Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=
</t>
<t>
Signature algorithm: RSA-SHA256 ("0")
</t>
<t>
Nonce: Pm3yUW-sW5Q
</t>
<t>
Signature:
</t>
<figure><artwork><![CDATA[
VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i
4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz
q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP
tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9
6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI
S13qQA43m4IMExkbApqrSg
]]></artwork></figure>

<t>
Authorization Header:
</t>
<figure><artwork><![CDATA[
Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-
k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q
.VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0
i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU
zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK
PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr
96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k
IS13qQA43m4IMExkbApqrSg"
]]></artwork></figure>

</section>

</back>
</rfc>