Subject: Passwords over the wire and WebAuthn woes

From: Michael Thomas <[email-masked]>
Date: Thu, 7 May 2020 14:05:53 -0700

Yes, yes, I know this is not w3c, hear me out if you will.

A while back, I started trying to implement a webauthn client and server 
to test it out to see if it was really the answer to our HOBA (rfc 7486) 
experimental rfc. The answer seems to be yes and no. From what I can 
tell webauthn is extremely centered on solving the problem of using 
crypto frobs to sign bits to be put on the wire. Local credential stores 
(ie, private keys sitting on your disk) seem to have been either out of 
scope, or mostly ignored. I tried to get it to work on Chrome and 
Firefox, and it seems that Chrome doesn't have the ability at all, and 
Firefox requires an about:flag that enables it. I was not able to get it 
to work.

This is really dismaying because local credential stores are completely 
adequate for a huge number of cases. If deployed it could substantially 
reduce the reuse of passwords, allowing users to just remember one 
really good local password to open their credential store.  The other 
part about introducing crypto frobs is that it makes the entire protocol 
much more difficult to understand and deploy. I wrote code way back then 
with the HOBA stuff, and webauthn was really hard to understand even 
though I knew what was happening at a high level. W3C has since then 
also released WebCrypto which gives apps the ability to roll their own 
public key auth between browser clients and server auth backends. I had 
implement some flows between client and server for joins, logins, and 
enrolling new devices once you have joined. As it turned out, the actual 
code to implement it was really straightforward: it took me about a day 
to back integrate webcrypto into my old krufty JS RSA libraries that I 
had scrounged years ago.

So here's the question: the flows that I created are definitely over the 
wire. But they are over the wire between really one party, the web site 
owner, since they control the code (= server, client js) on both ends. 
However as everybody knows, security is not easy so getting those flows 
*correct* is very hard. I have some experience here, and it's mainly 
telling me that I'm sure I got things wrong. So  what is the policy 
within IETF where a site could roll their own, but really shouldn't 
because it ought to be vetted?  Is standardizing such a thing in scope 
in IETF or other standards bodies? Because at its heart is not 
interoperability across implementation, but vetting a security design 
that goes over the wire.

Mike

PS: I am in no way bashing on w3c. they solved a hard problem, but it 
seems they left out or ignored the one I was hoping they'd solved along 
the way.

PPS: I have an implementation of this running, and a github repo if 
anybody is interested in seeing what I did

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 May 2020 22:17:40 -0700

> interoperability across implementation, but vetting a security design 

If I understand you correctly, it can be in scope to write up
(informationally, usually) a protocol for sending stuff over the wire
between two endpoints controlled by the same entity that avoids
security-relevant pitfalls.

-Ben

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 May 2020 15:10:44 -0400

It is a great pity we did not do something of the sort to describe the use
of Kerberos ticket type techniques to preserve state in encrypted HTTP
cookies.

One of the reasons we didn't is that people fussed about privacy. So we
ended up with all the privacy costs plus insecurity costs.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 May 2020 12:30:56 -0700

> security-relevant pitfalls.

I guess this begs the question why standards-track isn't appropriate? I 
mean, lots of $MEGACORPS might just as well be different organizations 
when it comes to interoperability issues. And they certainly have all of 
the same problems of each group rolling their own (badly). And of course 
standards mean that there's review, which is especially important with 
security related stuff.

Mike

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 May 2020 23:59:56 -0700

> standards mean that there's review, which is especially important with 

Standards-track is not out of the question, and could well be appropriate
in some casess.  My parenthetical was just meant to provide my unscientific
estimate of what has been done in the past.

-Ben

---

From: Michael Thomas <[email-masked]>
Date: Sun, 17 May 2020 08:13:27 -0700

> estimate of what has been done in the past.

I wonder if security related protocols are really a special case. The 
one truism is that if you don't get good external review for security 
protocols, you will screw it up. Of course we don't want to make IETF a 
job shop for everybody's favorite private security protocol to get the 
Good IETF Security Keeping seal of approval. Yet there are classes of 
problems that really transcend one-off kinds of problems that 1) nobody 
wants to roll their own and 2) nobody should be rolling their own in any 
case.

Another example along the lines of what i was thinking is, say, digest 
authentication (rfc 7616). Nobody actually uses digest auth because the 
browser UI is terrible (ditto Basic). There is no reason, however, that 
you couldn't implement a client based digest auth with Webcrypto these 
days which would allow you to make the UI as pretty as you like. But RFC 
7616 is a protocol between server and User Agent (browser), not the 
client code itself. Ought there be a standard if people want to move to 
digest to reduce passwords transmission? If there were enough demand, 
I'd think so -- companies rolling their own with bad transcriptions of 
rfc7616 would be a mess. Is this an IETF thing though? That's kind of 
what has me stumped.

Mike