HTTP Origin-Bound Authentication (HOBA)
draft-farrell-httpbis-hoba-00

Abstract

This memo proposes a way of using origin-bound certificates for HTTP authentication, called HOBA. HOBA is an HTTP authentication method with credentials that are not vulnerable to simple phishing attacks, and that does not require a server-side password database, both major potential positives, if deployed. HOBA can be integrated with account management and other applications running over HTTP and supports portability, so a user can associate more than one device or origin-bound certificate with the same service. This also provides a mechanism to handle state-loss, if one of a user's credentials is lost. HOBA also provides a logout mechanism.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 13, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

• 1. Introduction
• 2. A teeny bit of Terminology
• 3. HOBA HTTP Authentication
• 4. Authenticating
• 5. Signing Up
• 6. Binding Additional Keys
• 7. Logging Out
• 8. Security Considerations
• 9. IANA Considerations
• 10. Acknowledgements
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Author's Address

1. Introduction

[[Text in double square brackets (like this) is commentary.]]

[[This is an initial proposal for a new HTTP authentication scheme that might be adopted by the httpbis WG as part of their work on HTTP/2.0. It is also aimed to be usable with earlier versions of HTTP. At present, there is no code for this, so a) its early days, but b) it can easily be changed if the basic idea is attractive, but details are wrong. If someone wants to help out with this, that help would be welcome. The main overall goal is to end up with an HTTP authentication scheme that is not based on using passwords. There is no claim here that this will solve world hunger, but if deployment of HOBA reduces the number of password entries in databases by any appreciable amount then it would be worthwhile. While application layer (above HTTP) authentication is also very common today - and better schemes are needed there too - that does not mean that we ought not have one for HTTP as well. If we want to reduce password use, then both will be needed probably.]]

Passwords are the enemy. In particular databases of passwords. And large password datasets seem to leak out onto the Internet with increasing frequency. Once leaked those reveal passwords that are used across multiple systems. This is a threat to the Internet that would be mitigated by the development and deployment of non-password based HTTP authentication schemes. The HTTP Origin Bound Authentication (HOBA) scheme is one such.

Some may disagree that passwords are the enemy. One recent password database leak involved a database of 6,458,020 apparently valid hashed passwords. Within days, there was a claim that 2,000,000 (or 30%) of those had been cracked with no special equipment. (See http://www.net-security.org/article.php?id=1727) Digital signature based authentication schemes have existed for many years, but have not seen sufficient deployment for client authentication outside of enterprise use cases. TLS server authentication has however been widely deployed. And that gives a useful comparison - in February 2012, Lenstra et. al. (see http://eprint.iacr.org/2012/064) found approximately 270,000 of 6,400,000 RSA public keys (4%) might be problematic. The main reason was probably re-use of public keys, which can be valid, but this is the "worst" figure reported so should be an overestimate. For unique keys, they found real problems with only 0.2% resulting in a claim that RSA is "99.8% secure."

That means that we now have (some) evidence that databases of public keys are an order or magnitude safer than databases of passwords. That is compelling and certainly sufficient to say that an authentication scheme that is not based on passwords is needed.

RFC 2617 [RFC2617] defines basic and digest authentication methods for HTTP that have been in use for many years, but which, being based on passwords, are susceptible to theft of server-side databases.

The HTTP authentication framework [I-D.ietf-httpbis-p7-auth] describes how more modern HTTP authentication methods should be defined.

"Origin-Bound Certificates" (OBC) [I-D.balfanz-tls-obc] provides a way to use per-origin, self-signed client certificates for TLS [RFC5246] that allows for strong TLS mutual authentication if the "leap-of-faith" problem for the server can be solved. The leap-of-faith problem for the server here is that the server needs some way to bind the OBC with some identifier for, usually, an account of some sort. The HTTP authentication method defined here provides a URL at which a user can do whatever account creation steps are required.

In this context, we assume that server authentication uses the normal TLS server authentication methods.

In addition to providing a way to handle the leap-of-faith for one OBC, users are likely to use more than one device or user agent (UA) for the same HTTP based service, so there needs to be a way to bind more than one OBC to the same account, but without having to solve the leap-of-faith problem for each separately. (The leap of faith may involve the user entering values, or closing a mail loop or other time consuming operations.) To handle this the server can supply the client with the information required to bind together two OBCs, so that either can be used for the same account.

Users are also likely to lose a private key, if they lose a mobile device or for many other reasons. Another way in which state can be lost is if the OBC expires, at which point the leap-of-faith needs to be handled again.

The approach taken here to handle loss of state this is the same as for handling portability - allow the user to bind more than one OBC to the same account, this time so that even if state is lost from one user agent, that user agent can be easily bound to the other OBC for the user.

While portability or state-loss could be handled using the same mechanism, that might not be desirable if onerous user interaction is needed. In many cases it is possible to do better once an initial OBC exists for an account. Here we provide a mechanism that results in display of a short code, in an authhenticated session, so that that short code can be entered into a second device or UA resulting in the second OBC also being associated with the same account. The second device or UA uses the same mechanism but this time supplies the short-code as an input.

Logout features can be useful for user agents, so we define a way to close a current "session" over and above just closing the TLS session, and also a way to close all current sessions, even if more than one session is currently active from different user agents for the same account.

2. A teeny bit of Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

This specification uses [[or will use:-)]] the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].

A HOBA client credential consists of an asymmetric private key and an associated origin-bound certificate (OBC). On the server-side, the term credential means just the OBC. [[That's a different use of the term from [I-D.ietf-httpbis-p7-auth]. Maybe a better term is needed.]]

The term "account" is (loosely) used to refer to whatever data structure(s) the server maintains that are associated with the user and a given HTTP authentication realm. [I-D.ietf-httpbis-p7-auth] That will normally contain of at least one OBC and the realm, but might involve many other non-standard pieces of data that the server accumulates as part of an account creation processes. An "account" may have many OBCs that are considered equivalent in terms of being usable for authentication to that realm, however, the meaning of the word "equivalent" here is really up to the server and not defined here.

3. HOBA HTTP Authentication

An HTTP server that supports HOBA authentication MAY include the "hoba" auth-scheme value in a WWW-Authenticate header field as required.

This scheme 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. [[If that's ok, need to think about it a bit.]]

The "signup" attribute MUST be included, and MUST have a relative URL as its value. This URL is where a client can sign up for a HOBA account for this service.

[[Question: Ought absolute URLs be ok for HOBA auth-params? What'd it mean to sign up at some other DNS name? Sounds nice business-wise but dodgy security wise. Or should we require the same web-origin or what? Needs thought.]]

The "keybind" attribute MUST be included, and MUST have a relative URL as its value. That URL is where a client can associate an additional key with a HOBA account for this service for portability reasons or to recover from state-loss (assuming that at least one OBC remains usable).

The "logout" attribute MAY be included, and if included MUST have a relative URL as its value. That URL is where a client can cause a logout of the current session.

The "logoutall" attribute MAY be included, and if included MUST have a relative URL as its value. That relative URL is where a client can cause a logout of all current sessions associated with that account.

The above attributes MUST NOT appear more than once.

A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear more than once.

4. Authenticating

In this section we describe how to authenticate using HOBA.

A UA using HOBA MUST maintain a list of web origins [RFC6454] and realms for each of those. The UA MUST maintain one or more client credentials for each origin/realm combination. [[Note: [I-D.balfanz-tls-obc] says *at most* one OBC per web-origin, but here we're saying one OBC per (web-origin,realm) pair. Something needs to change there.]]

On receipt of a WWW-Authenticate for a given realm, in order to authenticate, the UA establishes an OBC TLS connection with the server using the appropriate client credential, if an appropriate client credential is available.

[[Question: Is there value in having a challenge/response as part of HOBA at the HTTP layer? Something based on TLS channel bindings might be worthwhile, but need to think about that.]]

If the UA has no client credential for the realm in question, the UA MAY (possibly involving user input) choose to sign up for that realm by using the HOBA sign up procedure described below.

5. Signing Up

In this section we describe how to sign up to a service with HOBA. Normally, this is expected to happen after a UA receives a WWW-Authenticate for an origin/realm for which it has no client-credential.

The process of signing up for a HOBA "account" on a server is simple - a new client credential is generated for the web-origin/realm in question and is submitted to the signup URL (using a POST message) that was part of the WWW-Authenticate header. It is up to the server to decide what kind of user interaction is required before the account is considered "live," so that HOBA authentication for that origin/realm combination works for the client. These interactions MUST take place via a TLS server authenticated session. That is, signup URLs MUST be https URLs. [[The logic being there's no reason at all to not use TLS here, if there were then a SHOULD would be appropriate.]]

The POST message sent to the signup URL has one parameter [[name TBD]] which contains the OBC that the UA will use for the origin/realm combination. The OBC MUST be sent base64 encoded. The value that is base64 encoded is the DER encoding of the self-signed X.509 certificate structure that is the OBC. See [RFC5280] for generic details of that data structure and the OBC specification [I-D.balfanz-tls-obc] for the profile of X.509 that is used for OBC.

[[It might be better to use a template for this so that we don't have to standardise the format of the post data. OTOH, it seems simpler to just POST the OBC to the server using a standard attribute. Whatever fancy UI the server wants can be handled via normal web interactions following on from the POST message in either case.]]

6. Binding Additional Keys

In this section we describe how to bind additional keys to a HOBA "account." This will normally be required where a user has more than one UA she wants to use for that service.

Key binding can be triggered when the UA is in one of two states - either authenticated or unauthenticated. The former case might happen if the user has two previously separate "accounts" on the server and wishes these to be "merged" for whatever definition or merge the server chooses.

The latter case can happen if a user has gone through the sign up process with one UA and now wishes to add another OBC, used by another UA, to that account. This can be useful if the sign up process is cumbersome for the user, who doesn't want to have to fill in many form fields for a second time but who can access both UAs within a reasonable time frame. Essentially, we provide enough protocol machinery that a server can decide to add, or not accept, the new OBC for that account using whatever UI the sever chooses, but with the restriction that the user has to transfer a string, chosen by the server, from the previously authenticated UA to the "new" UA.

In either the authenticated or unauthenticated cases the key binding operation is triggered by the user, via the UA, and MUST NOT be triggered solely as a result of network interactions.

When key binding is triggered, the UA will de-reference the keybinding URL for that realm [[stored where?]]. The server can then interact with the user however it (the server) chooses but that MUST involve two things. The first is display of a string that the user can enter into a different UA to bind the two accounts, and the second is a form that allows for entry of such strings.

If the UA triggered key binding but was not yet authenticated, then the UA generates a new set of client credentials and also sends the OBC to the server using another form field. [[More detail TBD.]]

If an acceptable string is entered with a new OBC in this manner, then the server can choose to associate the two OBCs with one account. Whether to do so is entirely at the server's discretion however, but the server SHOULD make the outcome clear to the user.

Note that the security level associated with key binding is entirely up to the server. The server can use any mechanism it chooses to make it less likely that a user manages to associate their OBC with someone else's account. That will typically involve trade-offs between security and usability based on the length of the string, the duration for which the string will be accepted etc.

The strings used here are only intended be used once. However, error handling might cause a sensible server to allow a string to be used more than once. If the same string is used more than once then the same OBC MUST be associated with that string. The UA MUST NOT generate a new OBC unless a new string is to be entered during key binding. Since the string can be entered more than once, key binding URLs MUST make use of TLS with server authentication, that is the key binding URL MUST be an https URL.

[[Need a better term than "string" here that gets over what its for but also allows e.g. the server to display a long value and ask the user to enter the "3rd, 6th and 9th numbers" from a displayed selection etc.]]

7. Logging Out

When a "logout" attribute was supplied and the user wishes to logout, the UA simply de-references the appropriate URL. The UA MAY also delete session cookies associated with the session. [[Is that right?, maybe a SHOULD- or MUST-delete would be better]]

The server-side MUST NOT allow TLS session resumption for any logged out session and SHOULD also revoke or delete any cookies associated with the session.

Logging out all sessions is pretty obvious really:-) Note that if a user follows the "logoutall" URL, then it is quite likely that another of the user's devices might experience an unexpected session termination, and the user SHOULD be notified of this, if possible. [[How? How do we know that's the reason for the failure? Might need a 4xx rule I guess.]]

8. Security Considerations

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.

Binding my OBC with someone else's account would be fun and profitable so SHOULD be hard. In particular the string generated by the server MUST be hard to guess, for whatever level of difficulty is chosen by the server. The server SHOULD NOT allow a random guess to reveal whether or not an account exists.

[[lots more TBD, be nice to your private keys etc. etc.]]

9. IANA Considerations

Authentication Scheme Name: hoba

Pointer to specification text: [[ this document ]]

Notes (optional): The HOBA scheme can be used with either HTTP servers or proxies. [[But I need to figure out the proxy angle;-)]]

10. Acknowledgements

[[TBD]]

11. References

11.1. Normative References

11.2. Informative References

Author's Address