< draft-farrell-httpbis-hoba-00.txt   draft-farrell-httpbis-hoba-01.txt >
Network Working Group S. Farrell Network Working Group S. Farrell
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Standards Track June 13, 2012 Intended status: Standards Track P. Hoffman
Expires: December 15, 2012 Expires: January 17, 2013 VPN Consortium
July 16, 2012
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-farrell-httpbis-hoba-00 draft-farrell-httpbis-hoba-01
Abstract Abstract
This memo proposes a way of using origin-bound certificates for HTTP HTTP Origin-Bound Authentication (HOBA) is an HTTP authentication
authentication, called HOBA. HOBA is an HTTP authentication method method with credentials that are not vulnerable to simple phishing
with credentials that are not vulnerable to simple phishing attacks, attacks, and that does not require a server-side password database.
and that does not require a server-side password database, both major It is an alternative to HTTP authentication that requires passwords
potential positives, if deployed. HOBA can be integrated with and all the negative attributes that come with password-based
account management and other applications running over HTTP and systems. HOBA can be integrated with account management and other
supports portability, so a user can associate more than one device or applications running over HTTP and supports portability, so a user
origin-bound certificate with the same service. This also provides a can associate more than one device or origin-bound certificate with
mechanism to handle state-loss, if one of a user's credentials is the same service. HOBA has many other useful features such as a
lost. HOBA also provides a logout mechanism. mechanism to handle state-loss if one of a user's credentials is lost
and a logout mechanism.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2012. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A teeny bit of Terminology . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. HOBA HTTP Authentication . . . . . . . . . . . . . . . . . . . 5 2. HOBA HTTP Authentication . . . . . . . . . . . . . . . . . . . 5
4. Authenticating . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Additional Services . . . . . . . . . . . . . . . . . . . . . 6
5. Signing Up . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Signing Up . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Binding Additional Keys . . . . . . . . . . . . . . . . . . . 7 3.2. Binding Additional Keys . . . . . . . . . . . . . . . . . 7
7. Logging Out . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 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
1. Introduction 1. Introduction
[[Text in double square brackets (like this) is commentary.]] [[Text in double square brackets (like this) is commentary.]]
[[This is an initial proposal for a new HTTP authentication scheme [[This is a proposal for a new HTTP authentication scheme that might
that might be adopted by the httpbis WG as part of their work on be adopted by the httpbis WG as part of their work on HTTP/2.0. It
HTTP/2.0. It is also aimed to be usable with earlier versions of is also usable with HTTP 1.0 and HTTP 1.1. The main goal of HOBA is
HTTP. At present, there is no code for this, so a) its early days, to offer an easy-to-implement HTTP authentication scheme that is not
but b) it can easily be changed if the basic idea is attractive, but based on passwords. If deployment of HOBA reduces the number of
details are wrong. If someone wants to help out with this, that help password entries in databases by any appreciable amount then it would
would be welcome. The main overall goal is to end up with an HTTP be worthwhile. While application layer (above HTTP) authentication
authentication scheme that is not based on using passwords. There is is also very common today - and better schemes are needed there too -
no claim here that this will solve world hunger, but if deployment of that does not mean that we ought not have one for HTTP as well. If
HOBA reduces the number of password entries in databases by any we want to reduce password use, then both will be needed.]]
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 [[The authors admit that the current organization of the document
database leak involved a database of 6,458,020 apparently valid leaves much to be desired. This can easily be fixed if the WG adopts
hashed passwords. Within days, there was a claim that 2,000,000 (or the document.]]
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 Databases of passwords cause huge security problems. Large password
keys are an order or magnitude safer than databases of passwords. datasets seem to leak out onto the Internet with increasing
That is compelling and certainly sufficient to say that an frequency. Once leaked those reveal passwords that are used across
authentication scheme that is not based on passwords is needed. 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 RFC 2617 [RFC2617] defines basic and digest authentication methods
for HTTP that have been in use for many years, but which, being based for HTTP that have been in use for many years, but which, being based
on passwords, are susceptible to theft of server-side databases. on passwords, are susceptible to theft of server-side databases. The
HTTP authentication framework [I-D.ietf-httpbis-p7-auth] describes
The HTTP authentication framework [I-D.ietf-httpbis-p7-auth] how more modern HTTP authentication methods should be defined. HOBA
describes how more modern HTTP authentication methods should be takes the best features of digest authentication (that is, the ones
defined. that are easy to implement and are interoperable) and gets rid of the
passwords. It also adds features that people have wanted in HTTP
"Origin-Bound Certificates" (OBC) [I-D.balfanz-tls-obc] provides a authentication for over a decade, such as credential management and
way to use per-origin, self-signed client certificates for TLS session logout.
[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 [I-D.balfanz-tls-obc] describes per-origin, self-signed "Origin-Bound
TLS server authentication methods. 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.
In addition to providing a way to handle the leap-of-faith for one The HOBA spec also defines many services that are required for modern
OBC, users are likely to use more than one device or user agent (UA) HTTP authentication:
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 o For HOBA to be usable, the server needs some way to bind the OBC
device or for many other reasons. Another way in which state can be with some identifier for, usually, an account of some sort. HOBA
lost is if the OBC expires, at which point the leap-of-faith needs to allows servers to define their own policies for binding OBC
be handled again. certificates with user accounts during account sign-up.
The approach taken here to handle loss of state this is the same as o Users are likely to use more than one device or user agent (UA)
for handling portability - allow the user to bind more than one OBC for the same HTTP based service, so there needs to be a way to
to the same account, this time so that even if state is lost from one bind more than one OBC to the same account, but without having to
user agent, that user agent can be easily bound to the other OBC for sign up for each separately. Sign-up may involve the user
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.
While portability or state-loss could be handled using the same o Users are also likely to lose a private key, if they lose a mobile
mechanism, that might not be desirable if onerous user interaction is device or for many other reasons. Another way in which state can
needed. In many cases it is possible to do better once an initial be lost is if the OBC expires, at which point the sign-up needs to
OBC exists for an account. Here we provide a mechanism that results happen again. The approach taken here to handle loss of state is
in display of a short code, in an authhenticated session, so that the same as for handling portability - allow the user to bind more
that short code can be entered into a second device or UA resulting than one OBC to the same account, this time so that even if state
in the second OBC also being associated with the same account. The is lost from one user agent, that user agent can be easily bound
second device or UA uses the same mechanism but this time supplies to another OBC for the user.
the short-code as an input.
Logout features can be useful for user agents, so we define a way to o Logout features can be useful for user agents, so we define a way
close a current "session" over and above just closing the TLS to close a current "session" over and above just closing the
session, and also a way to close all current sessions, even if more [[TLS]] session, and also a way to close all current sessions,
than one session is currently active from different user agents for even if more than one session is currently active from different
the same account. user agents for the same account.
2. A teeny bit of Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This specification uses [[or will use:-)]] the Augmented Backus-Naur This specification uses [[or will use:-)]] the Augmented Backus-Naur
Form (ABNF) notation of [RFC5234]. Form (ABNF) notation of [RFC5234].
A HOBA client credential consists of an asymmetric private key and an A HOBA client credential consists of an asymmetric private key and an
associated origin-bound certificate (OBC). On the server-side, the associated origin-bound certificate (OBC). On the server-side, the
term credential means just the OBC. [[That's a different use of 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 term from [I-D.ietf-httpbis-p7-auth]. Maybe a better term is
needed.]] needed.]]
The term "account" is (loosely) used to refer to whatever data The term "account" is (loosely) used to refer to whatever data
structure(s) the server maintains that are associated with the user structure(s) the server maintains that are associated with the user
and a given HTTP authentication realm. [I-D.ietf-httpbis-p7-auth] 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 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 might involve many other non-standard pieces of data that the server
accumulates as part of an account creation processes. An "account" accumulates as part of an account creation processes. An account may
may have many OBCs that are considered equivalent in terms of being have many OBCs that are considered equivalent in terms of being
usable for authentication to that realm, however, the meaning of the usable for authentication to that realm, however, the meaning of the
word "equivalent" here is really up to the server and not defined word equivalent here is really up to the server and not defined here.
here.
3. HOBA HTTP Authentication 2. HOBA HTTP Authentication
An HTTP server that supports HOBA authentication MAY include the An HTTP server that supports HOBA authentication MAY include the
"hoba" auth-scheme value in a WWW-Authenticate header field as "hoba" auth-scheme value in a WWW-Authenticate header field as
required. required.
This scheme MUST be followed by two or more auth-param values. The 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 defined by this specification are below. Other
auth-param attributes MAY be used as well. Unknown auth-param auth-param attributes MAY be used as well. Unknown auth-param
attributes MUST be ignored by clients, if present. [[If that's ok, attributes MUST be ignored by clients, if present. [[If that's ok,
need to think about it a bit.]] 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 The "challenge" attribute MUST be included. The challenge is a
it mean to sign up at some other DNS name? Sounds nice business-wise string of characters that the server wants the client to sign in its
but dodgy security wise. Or should we require the same web-origin or response. The challenge MUST be unique for every HTTP request and
what? Needs thought.]] sufficiently difficult to guess in advance in order to prevent replay
attacks from passive observers.
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 A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1, Part 7 protection in the manner described in HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear
more than once. 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 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 realms for each of those. The UA MUST maintain one or more client
credentials for each origin/realm combination. [[Note: credentials for each origin/realm combination. [[Note:
[I-D.balfanz-tls-obc] says *at most* one OBC per web-origin, but here [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 we're saying one OBC per (web-origin,realm) pair. Something needs to
change there.]] change there.]]
On receipt of a WWW-Authenticate for a given realm, in order to On receipt of a WWW-Authenticate for a given realm, the client
authenticate, the UA establishes an OBC TLS connection with the marshals a to-be-signed blob that consists of the origin name, the
server using the appropriate client credential, if an appropriate realm name, and the challenge string, and signs that blob. It
client credential is available. concatenates the signed blob with the OBC identifier that the client
and host agreed on for the client, and encodes the result as a
[[Question: Is there value in having a challenge/response as part of b64token. The client then returns that b64token in the Authorization
HOBA at the HTTP layer? Something based on TLS channel bindings header. [[Note: this is just an illustrative first cut at a
might be worthwhile, but need to think about that.]] 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.]]
If the UA has no client credential for the realm in question, the UA 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 MAY (possibly involving user input) choose to sign up for that realm
by using the HOBA sign up procedure described below. by using the HOBA sign up procedure described below.
5. Signing Up 3. Additional Services
In this section we describe how to sign up to a service with HOBA. HOBA uses well-known URLs [RFC5785] for performing many tasks:
Normally, this is expected to happen after a UA receives a WWW- "http://hostname/.well-known/hoba/". These URLs are based on the
Authenticate for an origin/realm for which it has no client- name of the origin host that the HTTP client is accessing. There are
credential. 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.]]
The process of signing up for a HOBA "account" on a server is simple 3.1. Signing Up
- a new client credential is generated for the web-origin/realm in
question and is submitted to the signup URL (using a POST message) Normally, a sign-up is expected to happen after a UA receives a WWW-
that was part of the WWW-Authenticate header. It is up to the server Authenticate for an origin/realm for which it has no client-
to decide what kind of user interaction is required before the credential. The process of signing up for a HOBA account on a server
account is considered "live," so that HOBA authentication for that is simple - a new client credential is generated for the web-origin/
origin/realm combination works for the client. These interactions realm in question and is submitted to the signup URL, ".well-known/
MUST take place via a TLS server authenticated session. That is, hoba/sign-up", using a POST message. It is up to the server to
signup URLs MUST be https URLs. [[The logic being there's no reason decide what kind of user interaction is required before the account
at all to not use TLS here, if there were then a SHOULD would be is considered "live," so that HOBA authentication for that origin/
appropriate.]] 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 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/ TBD]] which contains the OBC that the UA will use for the origin/
realm combination. The OBC MUST be sent base64 encoded. The value 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 that is base64 encoded is the DER encoding of the self-signed X.509
certificate structure that is the OBC. See [RFC5280] for generic certificate structure that is the OBC. See [RFC5280] for generic
details of that data structure and the OBC specification 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. [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 [[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 standardise the format of the post data. OTOH, it seems simpler
to just POST the OBC to the server using a standard attribute. to just POST the OBC to the server using a standard attribute.
Whatever fancy UI the server wants can be handled via normal web Whatever fancy UI the server wants can be handled via normal web
interactions following on from the POST message in either case.]] interactions following on from the POST message in either case.]]
6. Binding Additional Keys 3.2. 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 - Key binding will normally be required where a user has more than one
either authenticated or unauthenticated. The former case might UA she wants to use for that service. This can be triggered when the
happen if the user has two previously separate "accounts" on the UA is in one of two states - either authenticated or unauthenticated.
server and wishes these to be "merged" for whatever definition or The former case might happen if the user has two previously separate
merge the server chooses. 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 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 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 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 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 in many form fields for a second time but who can access both UAs
within a reasonable time frame. Essentially, we provide enough within a reasonable time frame. Essentially, we provide enough
protocol machinery that a server can decide to add, or not accept, 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 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 with the restriction that the user has to transfer a string, chosen
by the server, from the previously authenticated UA to the "new" UA. by the server, from the previously authenticated UA to the "new" UA.
In either the authenticated or unauthenticated cases the key binding In either the authenticated or unauthenticated cases the key binding
operation is triggered by the user, via the UA, and MUST NOT be operation is triggered by the user, via the UA, and MUST NOT be
triggered solely as a result of network interactions. triggered solely as a result of network interactions.
When key binding is triggered, the UA will de-reference the When key binding is triggered, the UA will go to ".well-known/hoba/
keybinding URL for that realm [[stored where?]]. The server can then key-binding". The server can then interact with the user however it
interact with the user however it (the server) chooses but that MUST (the server) chooses but that MUST involve two things. The first is
involve two things. The first is display of a string that the user display of a string that the user can enter into a different UA to
can enter into a different UA to bind the two accounts, and the bind the two accounts, and the second is a form that allows for entry
second is a form that allows for entry of such strings. of such strings.
If the UA triggered key binding but was not yet authenticated, then 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 the UA generates a new set of client credentials and also sends the
OBC to the server using another form field. [[More detail TBD.]] OBC to the server using another form field. [[More detail TBD.]]
If an acceptable string is entered with a new OBC in this manner, 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 then the server can choose to associate the two OBCs with one
account. Whether to do so is entirely at the server's discretion account. Whether to do so is entirely at the server's discretion
however, but the server SHOULD make the outcome clear to the user. however, but the server SHOULD make the outcome clear to the user.
skipping to change at page 9, line 14 skipping to change at page 8, line 17
generate a new OBC unless a new string is to be entered during key 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 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 URLs MUST make use of TLS with server authentication, that is the key
binding URL MUST be an https URL. binding URL MUST be an https URL.
[[Need a better term than "string" here that gets over what its for [[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 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 user to enter the "3rd, 6th and 9th numbers" from a displayed
selection etc.]] selection etc.]]
7. Logging Out 3.3. Logging Out
When a "logout" attribute was supplied and the user wishes to logout, When the user wishes to logout, the UA simply goes to ".well-known/
the UA simply de-references the appropriate URL. The UA MAY also hoba/log-out". The UA MAY also delete session cookies associated
delete session cookies associated with the session. [[Is that with the session. [[Is that right?, maybe a SHOULD- or MUST-delete
right?, maybe a SHOULD- or MUST-delete would be better]] would be better]]
The server-side MUST NOT allow TLS session resumption for any logged The server-side MUST NOT allow TLS session resumption for any logged
out session and SHOULD also revoke or delete any cookies associated out session and SHOULD also revoke or delete any cookies associated
with the session. with the session.
Logging out all sessions is pretty obvious really:-) Note that if a Logging out all sessions is pretty obvious really:-) Note that if a
user follows the "logoutall" URL, then it is quite likely that user follows the ".well-known/hoba/log-out-all" URL, then it is quite
another of the user's devices might experience an unexpected session likely that another of the user's devices might experience an
termination, and the user SHOULD be notified of this, if possible. unexpected session termination, and the user SHOULD be notified of
[[How? How do we know that's the reason for the failure? Might need this, if possible. [[How? How do we know that's the reason for the
a 4xx rule I guess.]] failure? Might need a 4xx rule maybe.]]
8. Security Considerations 4. Security Considerations
If key binding was server-selected then a bad actor could bind If key binding was server-selected then a bad actor could bind
different accounts belonging to the user from the network with different accounts belonging to the user from the network with
possible bad consequences, especially if one of the private keys was possible bad consequences, especially if one of the private keys was
compromised somehow. compromised somehow.
Binding my OBC with someone else's account would be fun and Binding my OBC with someone else's account would be fun and
profitable so SHOULD be hard. In particular the string generated by profitable so SHOULD be hard. In particular the string generated by
the server MUST be hard to guess, for whatever level of difficulty is 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 chosen by the server. The server SHOULD NOT allow a random guess to
reveal whether or not an account exists. reveal whether or not an account exists.
[[lots more TBD, be nice to your private keys etc. etc.]] [[lots more TBD, be nice to your private keys etc. etc.]]
9. IANA Considerations 5. IANA Considerations
5.1. HOBA Authentication Scheme
Authentication Scheme Name: hoba Authentication Scheme Name: hoba
Pointer to specification text: [[ this document ]] Pointer to specification text: [[ this document ]]
Notes (optional): The HOBA scheme can be used with either HTTP Notes (optional): The HOBA scheme can be used with either HTTP
servers or proxies. [[But I need to figure out the proxy angle;-)]] servers or proxies. [[But we need to figure out the proxy angle;-)]]
10. Acknowledgements 5.2. .well-known URLs
[[TBD]] TBD
11. References 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.
11.1. Normative References 6. Acknowledgements
[I-D.balfanz-tls-obc] [[TBD]]
Balfanz, D., Smetters, D., and A. Barth, "TLS Origin-Bound
Certificates", draft-balfanz-tls-obc-01 (work in 7. References
progress), November 2011.
7.1. Normative References
[I-D.ietf-httpbis-p7-auth] [I-D.ietf-httpbis-p7-auth]
Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in 7: Authentication", draft-ietf-httpbis-p7-auth-20 (work in
progress), March 2012. progress), July 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011. December 2011.
11.2. Informative References 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., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
Author's Address 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
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 Stephen Farrell
Trinity College Dublin Trinity College Dublin
Dublin, 2 Dublin, 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
 End of changes. 46 change blocks. 
217 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35