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

From: [email-masked]
Date: Mon, 15 Jul 2013 14:04:54 -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-01.txt
	Pages           : 26
	Date            : 2013-07-15

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.

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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-01

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Jul 2013 22:10:06 +0100

Just a few minor updates here mostly based on implementation
work we've been doing. One of us'll be happy to present the
changes and open issues in Berlin. Optimistically, I'd say
we're shooting for a WGLC for -02 ish since that implementation
seems to indicate that this all just works as expected (or
better IMO:-)

S.

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

---

From: Michael Sweet <[email-masked]>
Date: Tue, 16 Jul 2013 10:34:54 -0400

All,

Some (mostly editorial) comments on draft-ietf-httpauth-hoba-01:

- Can we drop the "with all the negative attributes that come with password-based systems" from the end of the abstract? I don't think it adds anything to the description and might turn some people off from reading the rest of the (otherwise excellent) document.

- Section 1
  - I don't think we need "If deployment of HOBA reduces the number of password entries in databases by any appreciable amount, then it would be worthwhile."
  - Reword: "As an HTTP authentication scheme, it WORKS in the current HTTP 1.0 and HTTP 1.1 authentication framework.", and don't talk about HTTP/2.0 unless there is something definitive to say.
  - Typo: "... using the same credentials that are USED by ..."
  - "The HTTP /Authentication/ specification [RFC2617] ..." - the HTTP spec doesn't define Basic and Digest, the separate Auth spec does...
  - The last sentence "Even though few large web sites" is a bit confusing; maybe something like "While few large web sites use Basic or Digest authentication, they still use authentication schemes based on server-side usernames and passwords."

- Section 3
  - Can we add something here as a reminder that HOBA might be one of several listed (comma-delimited) mechanisms in the WWW-Authenticate header?
  - In a similar vein, I would love to see some more discussion of implementation/fallback strategies. Right now I see a lot of potential uses for this authentication scheme, but I could not deploy it widely/exclusively (e.g. for CUPS and in printers) until HOBA support was in all of the major browsers and print clients.

- Section 4.2:
  - Status 403 is "Forbidden".  Status 401 is "Unauthorized".  Which is intended here?

- Section 6.1
  - Here I think we need more discussion of what the UA and server do. From reading this section it sounds like the UA would redirect to the well-known URL to perform registration, but I don't see how the UA knows that registration was successful and the original request can be retried.
  - In 4.x and 5.x you mention some possible ways the server can verify a user's identity (for which I might also include PIN verification on a printer), but you don't say anything about that here.

- Section 12.1
  - Add reference to RFC 2616, which defines HTTP and the auth headers
  - Move RFC 2617 here, which defines the general format of auth headers

- Section 12.2
  - Remove RFC 2617 (now in 12.1)
  - Add references to httpbis drafts made throughout document
  - Add references to example code/implementations?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Jul 2013 19:52:54 +0100

Hi Michael,

Thanks for the review. Comments below.

I've put a version at [1] with the changes indicated below in
case that helps. Note that I've not confirmed that with Paul
and Mike, so we might need to revert some changes if I;ve
messed up:-)

> - Can we drop the "with all the negative attributes that come with password-based systems" from the end of the abstract? I don't think it adds anything to the description and might turn some people…

Fair enough. I guess we can assume that readers know all the
many downsides of passwords, but yeah that probably doesn't
belong there.

>   - I don't think we need "If deployment of HOBA reduces the number of password entries in databases by any appreciable amount, then it would be worthwhile."

I've rephrased that to:

  "Deployment of HOBA can reduce the number
   of, or eliminate password entries in databases, with potentially
   significant security benefits."

>   - The last sentence "Even though few large web sites" is a bit confusing; maybe something like "While few large web sites use Basic or Digest authentication, they still use authentication schemes…

Yeah that was clunky text;-) I've tried to fix it along the lines
you suggest. See what ya think.

>   - Can we add something here as a reminder that HOBA might be one of several listed (comma-delimited) mechanisms in the WWW-Authenticate header?

Good point. Added:

  "Note that the HOBA auth-scheme might not be the
   only one that the server includes in a WWW-Authenticate."

>   - In a similar vein, I would love to see some more discussion of implementation/fallback strategies. Right now I see a lot of potential uses for this authentication scheme, but I could not deploy…

I guess that's non editorial:-) To date we've not seen browser
interest but I do hope that might change in future. If it helps,
you can implement HOBA-HTTP in JS also (my code does that) and
even though that's low assurance (as it depends on localStorage
until we get webcrypto) and is a bit clunky, ('cause it needs
XHR) I hope it'll provide a way to use this without having to
get all (or any) browsers on board. I'll be able to say more on
that after I get my code released, so would suggest we come
back to this as we build some experience. Sound ok?

>   - Status 403 is "Forbidden".  Status 401 is "Unauthorized".  Which is intended here?

Sorry - should be 403 Forbidden there I guess. Good catch.

>   - Here I think we need more discussion of what the UA and server do. From reading this section it sounds like the UA would redirect to the well-known URL to perform registration, but I don't see…

What I've done is have the register kick off a signup process
that's application driven and then next time the browser sees
a HOBA 401 for that origin, it just tries HOBA. (If someone's
interested in playing with that before I get the code released,
just drop me a note. I hoped to have the code released before
Berlin but time seems to be catching up with me;-)

But I've not really done much of a signup process (I more-or-less
just take any good looking public key and return 200 OK). I guess
there could be issues if the user abandons the signup half way
through though. Maybe we need a /.well-known/hoba/regconfirm or
something - do you think having that signal the end of register
work ok?

>   - In 4.x and 5.x you mention some possible ways the server can verify a user's identity (for which I might also include PIN verification on a printer), but you don't say anything about that here.

Fair point. I'm gonna leave that for now though - we've planned
to figure out (but haven't yet) how to merge the HOBA-JS stuff
with the rest. So this sounds like a bit of text that we should
look at then. Sound ok?

>   - Add references to httpbis drafts made throughout document

Done.

>   - Add references to example code/implementations?

Will be added to section 10 as per draft-sheffer-running-code as
we go. (I figured there was no point in details until my code
was released;-)

Thanks again,
S.

[1] http://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-02-pre.txt

---

From: Michael Sweet <[email-masked]>
Date: Wed, 17 Jul 2013 08:33:46 -0400

Stephen,

I like the changes you've made.  Some responses inline below...

On 2013-07-16, at 2:52 PM, Stephen Farrell <[email-masked]> wrote:
> ...

Sure, sounds like a plan.

>> ...

I'm thinking you might instead want to add a HTTP response header ("HOBA-Registration: state"?) to any registration pages.  The sequence for a confirmation form might look like the following:

    POST /.well-known/hoba/registration HTTP/1.1
    ... initial form data ...

        HTTP/1.1 200 OK
        ...
        HOBA-Registration: in-progress
        ...
        Web form asking for more information, PIN, etc.

    POST /.well-known/hoba/registration HTTP/1.1
    ... subsequent form data ...

        HTTP/1.1 200 OK
        ...
        HOBA-Registration: complete
        ...
        "Success" page

For a failed registration the sequence might look like:

    POST /.well-known/hoba/registration HTTP/1.1
    ... initial form data ...

        HTTP/1.1 200 OK
        ...
        HOBA-Registration: in-progress
        ...
        Web form asking for more information, PIN, etc.

    POST /.well-known/hoba/registration HTTP/1.1
    ... subsequent form data ...

        HTTP/1.1 200 OK
        ...
        HOBA-Registration: failed reason="Some reason"
        ...
        "Failure" page

Obviously there could be multiple web forms shown or none at all (initial response to POST is HOBA-Registration complete or failed).  The new response header would allow a common UA to participate without requiring site-specific Javascript or other hacks, and HTTP-based service applications can display an embedded web page viewer to display the registration page(s).

I'd avoid returning a different status code (e.g. 401 or 403) for these since UAs don't always show the web content attached to such responses.

(I also thought about defining standard verification fields that could be requested, but I think that is overkill and would limit the possible uses of HOBA)

> with the rest. So this sounds like a bit of text that we should

OK, I'll keep an eye out for changes...

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jul 2013 14:56:39 +0200

> you suggest. See what ya think.

draft-httpbis-p7 obsoletes the authentication framework bits from RFC 
2617, so you really should have a normative reference to httpbis-p7 here.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 17 Jul 2013 08:59:21 -0400

Julian,

On Jul 17, 2013, at 8:56 AM, Julian Reschke <[email-masked]> wrote:
> ...
> draft-httpbis-p7 obsoletes the authentication framework bits from RFC 2617, so you really should have a normative reference to httpbis-p7 here.

I guess that depends on the timeline for that spec; you can't make a normative reference to a draft, so doing that would hold up HOBA.  OTOH, normatively referencing RFC 2617 will point people in the right direction when httpbis-p7 is published.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jul 2013 15:03:32 +0200

> I guess that depends on the timeline for that spec; you can't make a normative reference to a draft, so doing that would hold up HOBA.  OTOH, normatively referencing RFC 2617 will point people in t…

draft-httpbis-p7 is past WGLC, so in theory (yes, yes) it ought to be 
finished soon.

In any case, the newly defined scheme needs to conform to everything 
what httpbis-p7 says (I believe it does, but I haven't checked lately).

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2013 14:45:08 +0100

Hiya,

On 07/17/2013 02:03 PM, Julian Reschke wrote:
>> I guess that depends on the timeline for that spec; you can't make a
>> normative reference to a draft, so doing that would hold up HOBA. 
>> OTOH, normatively referencing RFC 2617 will point people in the right
>> direction when httpbis-p7 is published.
> 

Fair 'nuff. OTOH, I thought the same for what turned into RFC6920:-)
6920 was much less related to p7 than hoba so it is more of a deal
here.

> what httpbis-p7 says (I believe it does, but I haven't checked lately).

I agree that we need to conform with that and also think we do (and
if not we'll fix). I'd say for now let's see how the land lies when
hoba gets to WGLC and beyond and then make sure that we have the
right normative/informative refs.

To be fair, it would be a totally reasonable IETF LC comment to say
that hoba ought have draft-httpbis-p7 as a normative ref. It might
be reasonable to weasel-word around that if everyone figured that'd
stick hoba in the RFC editor queue for ever, but I hope that won't
be the case.

Anyway, I guess the same will apply for all the httpauth drafts so
the httpauth wg will probably want to handle this the same for 'em
all. So the first wg draft out the door will be the one that sorts
this out probably.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2013 14:49:30 +0100

> I like the changes you've made.  Some responses inline below...

Great. On the registration thing I need to think about it a
bit but what you suggest certainly doesn't sound crazy. So I'll
get back to you on it when I've thought about coding it up.

Anyone else got an opinion? (Nico - does your scheme have the
same or similar issues?)

S.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Jul 2013 10:19:43 -0700

> something - do you think having that signal the end of register

Here's a question I have: can you combine 401 with Location: to achieve
the effect you want? Or perhaps the server could do a Location: first
which in turn does the 401 if needed? In general, I'd prefer not to have
hard wired url's unless there truly isn't any other alternative.

Mike