Subject: [http-auth] HOBA mutual auth - could do it but too complex

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Aug 2013 12:19:04 +0100

I had a discussion with Yaron after the httpauth session
about the fact that HOBA -01 isn't doing mutual auth and
so does depend to an extent on using TLS for server auth.
Yaron is understandably keen that we try do mutual-auth
if we can. I guess I'm less concerned since our main
design goal is to try be a drop-in but better replacement
for passwords.

We did sketch out a possible mutual authentication feature
for HOBA - that'd involve the server signing the challenges
and the server telling the UA the server's public key (for
verifying challenges) as part of the registration flow.

Later when I was chatting with Paul about this, we figured
that it wasn't so simple really, if you consider that a
web origin might have loads of servers, each with a different
challenge-signing key and where those keys get changed now
and then.

My conclusion for now is that that'd be about as complex
as server key pinning and so we shouldn't do it, but we do
need to properly document how and why HOBA needs server
auth TLS and what can go wrong if you don't have that.
(Basically, a MITM could try replay within the validity
window of a challenge, depending on how the server
constructs challenges. We also need to look at the
registration flow and say what a MITM could do then
too.)

I also plan to look at an option to use TLS channel
bindings if the UA and server support that. I need to
check out what'd work for that in practice though. Anyone
know what, if anything, really works easily there?

Cheers,
S.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 07 Aug 2013 16:26:59 +0300

Hi,

I may be mis-remembering, but I think the idea mutated a little since we 
discussed it. I was thinking of a per-user (actually, per-UA) public key 
for the server, so that the public key is generated on registration, and 
has the same life cycle as the user's credentials. So you don't need to 
synch it between servers and this doesn't become similar to key pinning.

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Aug 2013 14:30:30 +0100

> synch it between servers and this doesn't become similar to key pinning.

Yeah, but per-UA keys have a catch-22 - which key to use to sign a
challenge before you know who's going to respond? (Same gotcha
as a symmetric scheme would have). Which leads to per-origin keys
which leads to the level of complexity of HPKP. (I think,
corrections welcome;-)

S.

---

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

On 8/7/13 6:26 AM, Yaron Sheffer wrote:
> Hi,
>
> I may be mis-remembering, but I think the idea mutated a little since we discussed it. I was thinking of a per-user (actually, per-UA) public key 
> for the server, so that the public key is generated on registration, and has the same life cycle as the user's credentials. So you don't need to 

Yaron -- one thing that we should for sure do is make certain that we're future-proofed
such that future versions could be made backward compatible for things like mutual.
I'm not sure if the current message structure is amenable to that or not. Maybe take a
look and see if you could graft your idea on later assuming that Stephen is right here?

Mike, especially since this is destined for experimental status

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 08 Aug 2013 19:12:01 +0300

I'm not sure I understand the protocol's details well enough to say. A 
few message-level examples would certainly help.

One way we could add mutual authentication using a per-UA server public 
key is by having the client send a header containing a non-secret 
"hint", a pointer to the client's identity on the server. The client 
could add the header to any interaction with the host (like a cookie, 
sigh) or maybe just to accesses to .well-known/hoba/*.

	Hoba-mutual-auth-hint: qwerty123456asdf

This assumes that after registration, the UA knows what origins are 
associated with its CPK, and so, also with the SPK.

Thanks,
	Yaron

On 2013-08-07 22:07, Michael Thomas wrote:
>> I may be mis-remembering, but I think the idea mutated a little since
>> we discussed it. I was thinking of a per-user (actually, per-UA)
>> public key for the server, so that the public key is generated on
>> registration, and has the same life cycle as the user's credentials.
>> So you don't need to synch it between servers and this doesn't become
>> similar to key pinning.
>>
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth