Network Working Group S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Standards Track P. Hoffman
Expires: January 17, 2013 VPN Consortium
July 16, 2012
HTTP Origin-Bound Authentication (HOBA)
draft-farrell-httpbis-hoba-01
Abstract
HTTP Origin-Bound Authentication (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.
It is an alternative to HTTP authentication that requires passwords
and all the negative attributes that come with password-based
systems. 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. HOBA has many other useful features such as a
mechanism to handle state-loss if one of a user's credentials is lost
and 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 January 17, 2013.
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
Farrell & Hoffman Expires January 17, 2013 [Page 1]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. HOBA HTTP Authentication . . . . . . . . . . . . . . . . . . . 5
3. Additional Services . . . . . . . . . . . . . . . . . . . . . 6
3.1. Signing Up . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Binding Additional Keys . . . . . . . . . . . . . . . . . 7
3.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 9
5.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. HOBA Using TLS Inside of HTTP . . . . . . . . . . . . 10
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 11
B.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Farrell & Hoffman Expires January 17, 2013 [Page 2]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
1. Introduction
[[Text in double square brackets (like this) is commentary.]]
[[This is a 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 usable with HTTP 1.0 and HTTP 1.1. The main goal of HOBA is
to offer an easy-to-implement HTTP authentication scheme that is not
based on passwords. 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.]]
[[The authors admit that the current organization of the document
leaves much to be desired. This can easily be fixed if the WG adopts
the document.]]
Databases of passwords cause huge security problems. 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) described here is one such scheme.
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. HOBA
takes the best features of digest authentication (that is, the ones
that are easy to implement and are interoperable) and gets rid of the
passwords. It also adds features that people have wanted in HTTP
authentication for over a decade, such as credential management and
session logout.
[I-D.balfanz-tls-obc] describes per-origin, self-signed "Origin-Bound
Certificates" (OBCs) that are used for authenticating clients. [[We
should consider whether the self-signed format described in that
draft is really needed here. One can imagine that cert signed by a
trusted CA that had the rest of the the properties needed.]] These
certificates are used in HOBA for HTTP clients to authenticate
themselves to servers in the HTTP protocol.
The HOBA spec also defines many services that are required for modern
HTTP authentication:
Farrell & Hoffman Expires January 17, 2013 [Page 3]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
o For HOBA to be usable, the server needs some way to bind the OBC
with some identifier for, usually, an account of some sort. HOBA
allows servers to define their own policies for binding OBC
certificates with user accounts during account sign-up.
o 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
sign up for each separately. Sign-up 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.
o 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 sign-up needs to
happen again. The approach taken here to handle loss of state 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 another OBC for the user.
o 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.
1.1. 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
Farrell & Hoffman Expires January 17, 2013 [Page 4]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
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.
2. 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 one 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 "challenge" attribute MUST be included. The challenge is a
string of characters that the server wants the client to sign in its
response. The challenge MUST be unique for every HTTP request and
sufficiently difficult to guess in advance in order to prevent replay
attacks from passive observers.
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.
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, the client
marshals a to-be-signed blob that consists of the origin name, the
realm name, and the challenge string, and signs that blob. It
concatenates the signed blob with the OBC identifier that the client
and host agreed on for the client, and encodes the result as a
b64token. The client then returns that b64token in the Authorization
header. [[Note: this is just an illustrative first cut at a
challenge-response protocol, real design and analysis is needed for
this, e.g. for security, algorithm agility, etc. Ideally we can just
adopt something that already has some security proofs. Expect
changes here.]]
Farrell & Hoffman Expires January 17, 2013 [Page 5]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
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.
3. Additional Services
HOBA uses well-known URLs [RFC5785] for performing many tasks:
"http://hostname/.well-known/hoba/". These URLs are based on the
name of the origin host that the HTTP client is accessing. There are
many use cases for these URLs to redirect to other URLs: a site that
does sign-up through a federated site, a site that only does sign-up
under HTTPS, and so on. Like any HTTP client, HOBA clients MUST be
able to handle redirection of these .well-known URLs which is quite
likely to happen. [[There are a bunch of security issues to consider
related to cases where a re-direct brings you off-site.]]
3.1. Signing Up
Normally, a sign-up 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, ".well-known/
hoba/sign-up", using a POST message. 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.]]
Farrell & Hoffman Expires January 17, 2013 [Page 6]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
3.2. Binding Additional Keys
Key binding will normally be required where a user has more than one
UA she wants to use for that service. This 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 go to ".well-known/hoba/
key-binding". 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
Farrell & Hoffman Expires January 17, 2013 [Page 7]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
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.]]
3.3. Logging Out
When the user wishes to logout, the UA simply goes to ".well-known/
hoba/log-out". 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 ".well-known/hoba/log-out-all" 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 maybe.]]
4. 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.]]
Farrell & Hoffman Expires January 17, 2013 [Page 8]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
5. IANA Considerations
5.1. HOBA Authentication Scheme
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 we need to figure out the proxy angle;-)]]
5.2. .well-known URLs
TBD
We probably want a new registry for the labels beneath .well-known/
hoba so that other folks can add additional features in a controlled
way, e.g. for OBC/account revocation or whatever.
6. Acknowledgements
[[TBD]]
7. References
7.1. Normative References
[I-D.ietf-httpbis-p7-auth]
Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
7: Authentication", draft-ietf-httpbis-p7-auth-20 (work in
progress), July 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
Farrell & Hoffman Expires January 17, 2013 [Page 9]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
December 2011.
7.2. Informative References
[I-D.balfanz-tls-obc]
Balfanz, D., Smetters, D., and A. Barth, "TLS Origin-Bound
Certificates", draft-balfanz-tls-obc-01 (work in
progress), November 2011.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Appendix A. HOBA Using TLS Inside of HTTP
The -00 version of this proposal used a completely different method
of using HOBA, namely to follow [I-D.balfanz-tls-obc] literally and
use TLS 1.2 ([RFC5246]) inside of HTTP to do the authentication.
This appendix copies the earlier proposal in case the WG wants to go
with that instead of the method described in the main sections of
this document.
[[Note that re-using [I-D.balfanz-tls-obc] has pros and cons. The
benefit if OBC was widely deployed would be that HOBA would be quite
a simple layer on top. The downsides however are that HOBA would
then need a modified TLS implementation on both client and server and
HOBA would also be less proxy-friendly in particular for HTTP/1.1.
The alternative, that the authors are happy to explore should the WG
wish, is to basically do the OBC trick in the HTTP layer itself,
where the server issues a challenge that is to be signed by the
client. A downside of that is that we need to define that challenge
response security protocol, but that can be done relatively easily.
This is an issue that would need discussion in the wg - from a
security and authentication point of view, it could work fine either
way, so the decision should probably be driven by what's easier to
develop/deploy.]]
In this context, we assume that server authentication uses the normal
TLS server authentication methods.
On receipt of a WWW-Authenticate for a given realm, in order to
Farrell & Hoffman Expires January 17, 2013 [Page 10]
Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012
authenticate, the UA establishes an OBC TLS connection with the
server using the appropriate client credential, if an appropriate
client credential is available.
Appendix B. Changes
B.1. Changes from -00 to -01
o Added Paul Hoffman as co-author
o Changed the mechanism to do signing in HTTP itself; moved the old
mechanism to Appendix A.
o Started using .well-known/hoba/foo etc. rather than auth params
Authors' Addresses
Stephen Farrell
Trinity College Dublin
Dublin, 2
Ireland
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
Farrell & Hoffman Expires January 17, 2013 [Page 11]