draft-ietf-httpauth-hoba-05.txt   draft-ietf-httpauth-hoba-06.txt 
Network Working Group S. Farrell Network Working Group S. Farrell
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Experimental P. Hoffman Intended status: Experimental P. Hoffman
Expires: April 10, 2015 VPN Consortium Expires: June 8, 2015 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
October 7, 2014 December 5, 2014
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-05 draft-ietf-httpauth-hoba-06
Abstract Abstract
HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP HTTP Origin-Bound Authentication (HOBA) is a digital signature based
authentication method with credentials that are not vulnerable to design for an HTTP authentication method. The design can also be
phishing attacks, and that does not require any server-side password used in Javascript-based authentication embedded in HTML. HOBA is an
database. The design can also be used in Javascript-based alternative to HTTP authentication schemes that require passwords and
authentication embedded in HTML. HOBA is an alternative to HTTP therefore avoids all problems related to passwords, such as leakage
authentication schemes that require passwords. of server-side password databases.
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 April 10, 2015. This Internet-Draft will expire on June 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 10, line 23 skipping to change at page 10, line 23
authentication, such as asking the user which account she wants to 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), 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 server can prompt the user for account identifying information or
the user could choose based on HTML offered by the server before the the user could choose based on HTML offered by the server before the
401 is triggered. None of this is standardized: it all follows the 401 is triggered. None of this is standardized: it all follows the
server's security policy and session flow. At the end of this, the server's security policy and session flow. At the end of this, the
server probably assigns or updates a session cookie for the client. server probably assigns or updates a session cookie for the client.
During the authentication phase, if the server does not recognize the During the authentication phase, if the server does not recognize the
CPK, it could use HTML and JavaScript to ask the user if they are CPK, it could use HTML and JavaScript to ask the user if they are
really a new user or want to associate this new CPK with an already- really a new user or want to associate this new CPK with another CPK.
joined CPK. The server can then use some out-of-band method (such as The server can then use some out-of-band method (such as a
a confirmation email round trip, SMS, or an UA that is already 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) 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 enrolled one. Thus, logging in on a new user agent is identical to
logging in with an existing account. logging in with an existing account.
If the server does not recognize the CPK the server might send the 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. client through a either a join or login-new-UA (see below) process.
This process is completely up to the server, and probably entails This process is completely up to the server, and probably entails
using HTML and JavaScript to ask the user some questions in order to 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. assess whether or not the server wants to give the client an account.
Completion of the joining process might require confirmation by Completion of the joining process might require confirmation by
skipping to change at page 11, line 9 skipping to change at page 11, line 9
6. Other Parts of the HOBA Process 6. Other Parts of the HOBA Process
The authentication process is more than just the act of The authentication process is more than just the act of
authentication. In password-based authentication and HOBA, there are authentication. In password-based authentication and HOBA, there are
other processes that are needed both before and after an other processes that are needed both before and after an
authentication step. This section covers those processes. Where authentication step. This section covers those processes. Where
possible, it combines practices of HOBA-http and HOBA-js; where that possible, it combines practices of HOBA-http and HOBA-js; where that
is not possible, the differences are called out. is not possible, the differences are called out.
All additional services MUST be performed in TLS-protected sessions All HOBA interactions other than those defined in Section 5 MUST be
([RFC5246]). If the current HTTP traffic is not running under TLS, a performed in TLS-protected sessions ([RFC5246]). If the current HTTP
new session is started before any of the actions described here are traffic is not running under TLS, a new session is started before any
performed. of the actions described here are performed.
HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for
performing many tasks: "https://www.example.com/.well-known/hoba". 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 These URLs are based on the name of the host that the HTTP client is
accessing. accessing.
There are many use cases for these URLs to redirect to other URLs: a 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 site that does registration through a federated site, a site that
only does registration under HTTPS, and so on. Like any HTTP client, only does registration under HTTPS, and so on. Like any HTTP client,
HOBA-http clients have to be able to handle redirection of these HOBA-http clients have to be able to handle redirection of these
 End of changes. 7 change blocks. 
17 lines changed or deleted 17 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/