Re: hoba: mixing origin-bound certs and user login

Hi James,

On 07/23/2012 03:15 PM, Manger, James H wrote:
> Stephen & Paul,
> 
> Thanks for developing HTTP Origin-Bound Authentication (HOBA) [draft-farrell-httpbis-hoba-01], but I am confused about how it works.

Thanks for the review. We're also not yet clear how it works
is the headline answer:-)

> Version -00 leveraged origin-bound certificates (OBC) [http://tools.ietf.org/html/draft-balfanz-tls-obc-01]. Version -01 still mentions OBC (eg "Signing Up … The OBC MUST be sent base64 encoded"), but I get the impression this is an HTTP-layer cert that is *totally separate* from any TLS-layer OBC. Is that true?

Right. Paul's (good) argument for the change is that its much
better to not depend on a modified TLS stack. I'm ok either way
really, but doing this at the HTTP layer was my original plan
(e.g. on the http_auth list maybe a year ago) before TLS-OBC
was published.

I'd like if we can make sure the public credential is the same
in any case, whether the authentication is done within TLS or
in HTTP, or as is maybe more likely, above HTTP. So I reckon
I'll argue to keep the OBC structure on that basis.

> 
> C <- S: WWW-Authenticate: HOBA realm="abc", challenge="123"
> C -> S: Authorization: HOBA sig=sign(origin+realm+challenge), obc=...
> 
> Q. Should you always need a round-trip to collect a challenge from the server, or can an initial HTTP request be authenticated using HOBA? Perhaps signing a timestamp instead of a challenge.

Good question for which I don't have an authoritative answer at
the moment. I guess it depends on a) what will be signed and
b) how often we feel challenges need changing vs. how much we'd
buy into use of timestamps.

Assuming hoba isn't d-o-a, for a) I think I (at least) need
to talk some more to HTTP folks in Vancouver and then to some
security of cfrg folks before proposing details, and then we'd
want to iterate a bit on that. (If hoba is to be part of HTTP
for the next long while, I think we need to do it well.)
For b) I'm wary of timestamps since there are nodes with no
clock, but I can see how the option might be handy. OTOH,
more options is bad too, so I'm just ambivalent right now;-)

> 
> Instead of POSTing a cert (OBC) to /.well-known/hoba/sign-up, the client could just use HOBA. That is, the client generates a key pair & OBC, then includes the OBC in the Authorization header when requesting the sign-up URI.
> 
> The request to /.well-known/hoba/sign-up (which can probably be a GET instead of a POST) needs to include the realm, though this could be in the HOBA Authorization header as well.

Both seem reasonable to me.

> 
> There might need to be some signal from the server once the sign-up has completed so the client knows it can now repeat the request that caused the WWW-Authenticate response that triggered the sign-up. Using a status code might work (eg 201 Created indicating the creation of an account), but a status code is a bit awkward since you need to distinguish a status code about this page of the sign-up interaction vs the status of the entire sign-up process.
> Similarly there needs to be some signal that the sign-up process failed.

I agree that those issues need consideration. Not sure
what's right myself.

> 
> Why does logout require a request to /.well-known/hoba/log-out, instead of just no longer including "Authorization: HOBA sig=..."? Is it because only 1 HOBA signature might be used to authenticate in a session, and a session cookie could be used from there? Or is it just generally useful to inform the server?

I believe the latter. But that raises UI issues for which I'm not
sure we have good answers. ("logout" is, I'm told, something that
folks have been wanting in HTTP, but the details of why aren't very
clear to me, and it may be that the requirements for a logout
operation for a scheme like hoba differ from a password based
scheme.)

> Servers not allowing TLS session resumption after getting a request to /.well-known/hoba/log-out feels strange (and unnecessary). Is the current TLS session also supposed to be terminated on logout? Can't you logout of your account, but keep browsing the site on the same connection?

Fair enough. I'd have no problem separating those fully. (Or not,
basically, whatever the WG would want.) I guess the counter argument
might be that it'd be good to keep one TLS session per login session.

> 
> Is it the idea that (after an initial sign-up) the HTTP-layer OBC would be used automatically by the client whenever accessing the site? Or automatically, but only after getting a "WWW-Authenticate: HOBA ..." response? Or is the client supposed to display a "Login" button when the user browsers to the site? Or does the client prompt to login on receiving "WWW-Authenticate: HOBA ..."?

All good questions that make it clear where we are in the
development of this. (As does the draft itself.) If the wg
choose to adopt hoba or a hoba-like thing, we're happy to
put in the effort to start answering these questions well.

S.


> 
> --
> James Manger
>

Received on Monday, 23 July 2012 14:55:32 UTC