Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-00.txt

From: [email-masked]
Date: Tue, 14 May 2013 11:26:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

	Title           : HTTP Origin-Bound Authentication (HOBA)
	Author(s)       : Stephen Farrell
                          Paul Hoffman
                          Michael Thomas
	Filename        : draft-ietf-httpauth-hoba-00.txt
	Pages           : 23
	Date            : 2013-05-14

Abstract:
   HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP
   authentication method with credentials that are not vulnerable to
   phishing attacks, and that does not require a server-side password
   database.  The design can also be used in Javascript-based
   authentication embedded in HTML.  HOBA is an alternative to HTTP
   authentication schemes that require passwords with 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 key with the same service.  We also
   describe a way in which the HOBA design can be used from a Javascript
   web client.  When deployed, HOBA will be a drop-in replacement for
   password-based HTTP authentication or JavaScript authentication.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-hoba-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 May 2013 19:35:02 +0100

Hi all,

As you can see we've just posted the wg-00 version of the
HOBA draft.

Not too many changes for now, mostly some more detail of the
signature and registration processes - we've tried to make it
easy enough do diff this vs. the independent draft.

Comments welcome, as always, in particular about the basic
signature scheme. We'd most particularly welcome if someone
could point us at a 20+ year old signed challenge one-way
user authentication scheme with good security analyses. I'm
sure there're some in the literature and I did find one
that's almost a perfect match but I bet there's better.

I'll send a mail later with some thoughts on hoba and
draft-cavage-http-signatures.

Cheers,
S.

On 05/14/2013 07:26 PM, [email-masked] wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 16 May 2013 23:29:24 +1000

I’m not quite sure how registration and user interaction is intended to work in HOBA-http [draft-ietf-httpauth-hoba-00].

The core HOBA-http interaction looks simple enough:
1) client makes a request;
2) server wanting authentication responds with a 401 that includes "WWW-Authenticate: HOBA challenge=...";
3) client re-tries the request with "Authorization: HOBA result=kid.challenge.nonce.sig";
4) server verifies the signature using the client’s public key.

The core interaction only works if the server already has the client’s public key. The client can register a public key by POSTing it to https://origin/.well-known/hoba/register. It looks like this registration has to occur the first time the client gets a "WWW-Authenticate: HOBA" response from the server: between steps 2 & 3 above.

The spec implies that the server decides what sort of user interaction results from the registration POST. Perhaps a server would return an HTML form prompting for a name and email address to go with the new account, for instance.

I'm not sure how the client can tell when the registration interaction is over (so it can go back to retrying the original request at step 3 above). In a user-at-a-browser situation, should the registration POST be effectively made in a popup window or the main window? What if the 401 triggering the registration wasn’t a request for a new HTML page, but a linked image for instance?

The problem is that the server cannot tell if user interaction is appropriate at this point. Presumably a whole range of client requests can result in a 401, any of which could have triggered the registration. The client might not even be a user at a browser.

Would a better approach for HOBA-http be to include the public key (and device id) in the "Authorization: HOBA" response if a new key pair has just been created? If some user interaction is required the server has to work out how that happens. Perhaps another 401 is returned, but this time with an HTML form as the response body (and no "WWW-Authenticate" header).

--
James Manger

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 May 2013 15:21:59 +0100

Hi James,

Good questions as always, thanks.

> I'm not sure how the client can tell when the registration interaction is over (so it can go back to retrying the original request at step 3 above). In a user-at-a-browser situation, should the reg…

To be honest, me neither:-) I've some code for the basic
crypto but haven't tried any UI stuff so far.

What I was thinking of was the the WWW-Authenticate with
the signature will also be part of the register POST message,
since the UA is responding to a 401.

In that case the server gets everything it needs and can
remember the key and that the signature was ok as it pushes
the user through the registration process. Once the server
is happy with that it can set cookies or whatever. And next
time the UA comes back it should be ok or not as the server
desires.

That'll also need to work as well if the user hits some
"register" button on the page before ever seeing a 401.
I suspect that the server would have to feed a 401 to the
UA at that point and then we go from there.

> The problem is that the server cannot tell if user interaction is appropriate at this point. Presumably a whole range of client requests can result in a 401, any of which could have triggered the r…

Yep. Mike brought that up too the other day in an offlist
mail. I guess there'll be all sorts of similar web things
with starting off inside a frame etc. none of which I know
much about. OTOH, its all under the server's control so
should be easy enough if you design a site with this in
mind. But we probably need to do better - to make it easy
to integrate with a site that's previously been using Basic
or web forms with passwords.

> Would a better approach for HOBA-http be to include the public key (and device id) in the "Authorization: HOBA" response if a new key pair has just been created? If some user interaction is require…

Certainly worth a look. Not sure if we'd start to hit problems
with headers being too long or not though esp. for longer RSA
moduli.

So at this point I don't have answers. But I'd sure welcome
suggestions and am happy to try 'em out as my code develops
and report back.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 May 2013 15:27:36 +0100

> since the UA is responding to a 401.

Oops - s/WWW-Authenticate/Authorization/ above sorry;-)

S.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 May 2013 08:12:48 -0700

> or web forms with passwords.

As I wrote to Paul and Stephen, the question in my mind is whether HOBA-http
ought to be thought of as reflexive like 401 is now. I'm thinking that way be dragons
because probably the singular glaring fail of the reflexive 401 is that the browser
owns the interaction and paints up a butt-ugly modal dialog. Modern web sites
MUST be able to control the login/join flow programmatically (= html/js).

James zeroed in on exactly the same thing I was thinking about though which
are <img>'s, say, when the session has expired. Obviously you can't flow a batch
of html back -- the best you could do is capture the problem with an onerror handler,
but that would be pretty ugly.

So I'm thinking that it might be better for the client (= js in browser) to be proactive
to determine the session state. Maybe it wants to inspect the session cookie to see
if it's still valid, or whatever else kind of test it might want to perform before it
interacts with the server if it knows that a session needs to be valid. Since the overall
interaction between the client and server are under control of the site, that doesn't
seem too unreasonable to me.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 May 2013 08:39:32 -0700

I just checked around and it seems even worse than I guessed: it seems
you cannot get the HTTP status code programmatically in javascript for a
<img> tag, so a HOBA-401 would show up as a generic onerror just like a 404.
I guess you could overload the prototype of the onerror property and probe
your session connectivity any time you got an error of any kind but that doesn't
seem like the mostest of elegantests of solutions.

Mike