Subject: [http-auth] HOBA code released

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Aug 2013 20:42:29 +0100

Hiya,

As I said in Berlin, I've been planning to release our
HOBA code. That's done now. (*)

Go to [1] for a pointer to the sourceforge project. That
implements the -01 version of the draft.

There's a separate list for stuff related to this code
(signup at [2]) that isn't relevant for the WG.

If someone has a chance to play about with it, I'd
really appreciate feedback here or there as appropriate.

Cheers,
S.

[1] https://hoba.ie/download.html
[2] https://hoba.ie/hobalist.html

(*) At least I think it is. 1st time I've used git to
create a new sf project so who knows how I messed up;-)

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Aug 2013 16:20:06 -0700

On 8/6/13 12:42 PM, Stephen Farrell wrote:
[]

I've asked this of Stephen and Paul before what motivates the need for .well-known,
and after perusing the code I still have the same question. At the very least if there
is actually a good reason for it, we really need to put it into the draft.

It seems to me that the only good reason for .well-known is when there is no
communication path to get agreement between the server and client implementations
of where to send a given http request. That doesn't normally happen in the web
world because the web server is ultimately in charge of both itself, and what ends
up in the client sandbox. Looking at the code, it looks pretty much like mine wrt
url creation, except Stephen is saying it needs to be standardized, and mine doesn't
care.

The one thing I can think of is if the actual browser code (eg firefox not javascript)
is reflexively answering the 401 coming back from the web server demanding hoba
authentication. Even in that case, could we not either reuse the Location: header
to redirect it to wherever the server wants it to go (including right back to the page
it initially requested)? Or if that would amount to a bad overloading of Location:
functionality, perhaps we could, instead, define a new HOBA-redirect header with
its own specific semantics?

In general the use of .well-known makes me sort of nervous. Not affecting the server
login/join flow will make it easier to drop it in as a replacement to typical password
schemes since it would look pretty much like basic, digest and non-http layer auth.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Aug 2013 00:35:59 +0100

Hi Mike,

Thanks for bringing this up. I just didn't get the problem when
we mailed before, and still don't (so I definitely didn't do it
justice in Berlin though I tried.) Maybe the wg will be better
able to figure it out.

> is actually a good reason for it, we really need to put it into the draft.

Fair point.

> schemes since it would look pretty much like basic, digest and non-http

So I don't share your nervousness but that might well be due to
my ignorance of web deployments.

As to the .well-known's we have I would justify 'em as follows:

- getchal - needed for very slow signers (e.g. old phone via JS)
but where web worker's work - this saves the day
- logout - where else should one go?
- register - this could be part of applications but seems much
better to be a place to which applications can send the browser
(if HOBA becomes popular then applications would only have to
know "hoba" and not a "hoba, URL" pair)
- login - if you assume that applications care about cookies
then this seems simpler

Having said that, yes a reflexive (*) approach also works with HOBA
and with my code. (Check out [1], starting from a not-logged-in
state.) So, if there were a cost to registering these .well-known
URLs then we could survive, but I don't see the big cost of
doing the IANA stuff.

S.

[1] https://hoba.ie/mimic401.php

(*) BTW, is "reflexive" a term of art here? I figure I know
what you mean but am not sure if its a term you coined for HTTP
auth or is more generally known. Seems useful though.

> 
> Mike
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Aug 2013 17:46:02 -0700

> my ignorance of web deployments.

My nervousness is on a couple of fronts. One is that it seems that you'd need
access to mod_rewrite in order to redirect the .well-known/hoba/xxx to your,
say, php script. And that's just apache, of course. That might be problematic
on, say, a hosted server. And even if it's not, it may be a configuration step
too far.

Similarly, things that expect RESTful behavior may not be all that happy about
being forced to redirect to somewhere else... I've been playing with RoR lately and it
definitely has an opinion on the way things ought to flow, so dropping these kinds of
requirements onto it -- while surely possible - may be quite painful.

So it's born mostly out of not wanting to rock the boat, so we can slip hoba
into running deployments.

> but where web worker's work - this saves the day

For js implementations, you never need .well-known because the client
and server can agree like usual. For browser-based hoba, this isn't an issue
at all... it's plenty fast enough.
> - logout - where else should one go?

Assuming that there isn't a hoba Authorization: header generated each http
request, that means you're carrying session state somehow else (typically
cookies). If that's true, you don't need logout. The problem with Basic is
that it keeps sending the Authorization: header and there's no way to tell
the browser to stop sending it. I don't think that's the case here.

> - login - if you assume that applications care about cookies

I look at this the other way around: I want to start a (slow) transition
to non-password based authentication with as little change to my server
code/flow as possible. That means that whatever is putting up the authentication
barrier probably wants to handle the new auth scheme (hoba) in addition to
password based mechanisms. It would be nice if it didn't involve vectoring
it through a different URL first and then redirect back to what they were
trying to access.

That is, why can't we just do as normal http auth does and retry the same url
with the proper Authorization: header? That would leave it completely up to the
server to decide whether it wants to redirect or not.

[I looked up my Location: suggestion and as I suspected it's wrong, but the
  .well-known could always be emulated by doing a 3xx redirect followed by the 401 hoba.]

> URLs then we could survive, but I don't see the big cost of

I'm not worried about IANA.

> auth or is more generally known. Seems useful though.

I've sort of stolen "reflexive" from Christian Huitema from back in the MGCP
days. Not sure if he originated it, or whether it's a term of art, but I do like
it too.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Aug 2013 22:34:54 -0400

> requirements onto it -- while surely possible - may be quite painful.

Not really. A single map line on config/routes.rb
(doing RoR since 2007)

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Aug 2013 11:34:47 +0100

Hi Mike,

> into running deployments.

I'm fully sympathetic there. Maybe what we need to do is craft
text that shows that there's a benefit in each of the .well-known's
we register and also text that shows that you don't have to
use them if your application context would make that difficult.

> and server can agree like usual. 

Disagree. Its true that you don't need this getchal but its
also true that JS on some devices/UAs is dog slow. And some of
those slow devices/UAs do support web workers. This .well-known
means you can offload the signing to a worker and have a
fresh response (signed challenge) ready when the UI needs one.
(Our code does that when it can and it makes a huge difference
to responsiveness.)

> For browser-based hoba, this isn't an
> issue

Sure, that's true of modern browsers, but there could be other
HTTP UAs that are slow. I agree that's a bit speculative since
I don't know of one such.

> the browser to stop sending it. I don't think that's the case here.

Oddly, lots of web application people do seem to want logout.
While I don't fully get why that's the case, I've heard it
from quite a few folks now.

> server to decide whether it wants to redirect or not.

Yes, you can do that. I think that having register and login
will make that easier for some sites though. For example, the
wordpress plugin we did was simpler because of the .well-known's.

> I'm not worried about IANA.

Me neither:-)

> days. Not sure if he originated it, or whether it's a term of art, but I

Yup. So going back to the top of this mail I think what we need
to do is to craft text that talks about how either the reflexive
or .well-known approaches can both work.

S.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Aug 2013 09:04:31 -0700

> (Our code does that when it can and it makes a huge difference

We're not communicating. I'm not saying that it's not useful. I'm
saying that it doesn't require .well-known to achieve that functionality.
If it's javascript code, it never requires .well-known because the server
that caused the code to ultimately be loaded knows the url which implements
the service. The server has to know. Therefore it can inform the js where to
get it in the usual ways.

> I don't know of one such.

We're talking about crypto written in C here, so I think it's ignorable.
> from quite a few folks now.

I'd like to see an actual use case where it's needed. I fully sympathize with the
problems of Basic -- I've bitten by it too. But if we're not shipping an Authorization:
header with each http request, I don't think there's a problem.

BTW: I've looked several times in the text to try to figure out whether hoba-http
does or does not require the Authorization: header to be applied to each request
from the UA and couldn't find it. So I think we need to have some clarifying text,
and/or maybe a couple of ladder diagrams.
> wordpress plugin we did was simpler because of the .well-known's.

I still don't think we're communicating. I have no issue at all vectoring
the auth pieces off onto its own page -- some sites will find that convenient,
some won't. I just question whether we need to use .well-known to do that.
If we don't absolutely, positively need to use .well-known, I'd rather we not.

As far I can see, we can achieve the same functionality for the reflexive case by:

UA -------------> Protected Resource at https://example.com/foo.html

UA <------------- 30x, Location: https://example.com/hobalogin.php

UA --------------> (to https://example.com/hobalogin.php)

// the next two are optional, but probably typical:

UA <-------------- (login/join/whatever page)

UA --------------> (submit form, do XHR, etc to "login/join/whatever")

UA <-------------- 401 hoba

UA --------------> Authorization: hoba

[server can now redirect back to https://example.com/foo.html, or whatever else
  it wants to do]

If this is all messed up, can you fix what's wrong... and maybe we can put it
into the draft? :) Note that this is pretty much the way you'd do it with non-hoba
as well -- my feeling is that if we're stuck requiring .well-known, we're probably
not thinking about it right.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Aug 2013 17:16:58 +0100

On 08/07/2013 05:04 PM, Michael Thomas wrote:
> We're not communicating. 

Yeah, I think we're agreeing actually, except about whether
having the .well-known's defined is useful even if they're
not always necessary.

> I'm not saying that it's not useful. I'm

In the case of getchal though, the worker has to know where to
go and without having a side-effect on the application so I think
that one is really useful to the point that we defo want it in.

> We're talking about crypto written in C here, so I think it's ignorable.

That's probably fair.

> and/or maybe a couple of ladder diagrams.

Yep.

> If we don't absolutely, positively need to use .well-known, I'd rather

And its only on that last sentence that we disagree I think.
I would like that we define the .well-knowns and that sites
using hoba would make those available.

I'm fine if an application on the site doesn't need 'em.

> not thinking about it right.

I agree. I don't think we require .well-known's (other than getchal)
are used but I do think its beneficial if we define 'em and say that
sites MUST/SHOULD/MAY offer 'em. (I'm not so fussed on the 2119
keyword we pick I think, maybe SHOULD is right.)

I fully agree that we need to describe all this better.

S.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Aug 2013 10:20:23 -0700

> that one is really useful to the point that we defo want it in.

Sure, but in the js case which is what you're talking about the server
can just insert:

<script type=text/javascript>

var placeToGetHobaChallenge = "http://example.com/hobagetchallenge.py";

</script>

So it's not really needed.

>> header with each http request, I don't think there's a problem.

So do we agree that we should lose logout unless somebody can really show
why it's really necessary?

>> and/or maybe a couple of ladder diagrams.
Since I've already done one ladder diagram below, I guess I can take the action
to generalize/finish it. I personally find ladder diagrams enormously helpful to
understand what's going on.

> keyword we pick I think, maybe SHOULD is right.)
I think if we keep them, it should be optional at most. If we find later that
they are more than optional -- ie, that there is actually some really interesting
things that it enables -- then we could bump it up to should/must in a -bis
draft IMO (and I can't imagine that we won't do a -bis if this becomes popular :)

Mike