Re: [TLS] Better TLS Client Authentication

[Tim Cappalli <[e-mail]>]

You mentioned FIDO, but I didn't see a reason why you don't want to use it. The industry has largely accepted the mature FIDO standards stack (WebAuthn & CTAP) as the strong authentication method that replaces passwords in a privacy preserving and phishing resistant manner.

Why create something new, especially using technologies that are not very user friendly?

tim

From: TLS <[e-mail]> on behalf of Phillip Hallam-Baker <[e-mail]>
Date: Sunday, May 22, 2022 at 23:28
To: [e-mail] <[e-mail]>
Subject: [TLS] Better TLS Client Authentication
I am looking for people interested in discussing the following proposal to create a profile of TLS Client Authentication certificates to enable transparent Web Site authentication in Philadelphia:

I have a three step plan for eliminating Password Authentication

1) Deploy an open standards based, E2E secure password vault
2) Transition Web sites to use of public key authentication
3) Deploy a 2FA type scheme to address 'ceremony' use cases

I don't want to get into detail here, but I believe the trick to eliminating passwords is to deploy a password management solution in phase 1 that creates a sufficiently large base of users whose devices are provisioned with the necessary private keys to make use of public key auth practical.

So, I had assumed that this was all about enabling FIDO. But when I look at what I want to achieve and what legacy deployments provide, I suddenly realized I can do everything I need using TLS client auth. The only question is what the BEST way to do it is going to be.


So I have running code that can provision key pairs and credentials to every device Alice owns:

https://www.youtube.com/watch?v=zrBv717w8yY<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DzrBv717w8yY&data=05%7C01%7Ctim.cappalli%40microsoft.com%7C8d2d1c84b14944a8b65308da3c3a07e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637888517206896679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4V4ijtshBNU5dTiZ49BgQibcjpXnaRtgpjvuvgLolCQ%3D&reserved=0>

It would not take a great deal of extra effort to provision certificates into the Windows/MAC/etc keystores so that IE, Edge, Firefox, Chrome, Safari, etc. etc. can all make use of the certificates. Its just a question of writing a script.


I am pretty sure I can get 'something' to work. But I would appreciate some help from folk who are closer to the real-world implementations.

Reading through the specs, I think we can make it so that after an (optional) one time registration, Alice can just use the Web site without the need to ever log in ever again.

The only reason Alice would ever need to repeat registration is if the Web Site had some policy requiring Alice to affirm that yes, this really is her device and she agrees to terms. That is what I call 'ceremony' and it is not an authentication issue. I have another way of addressing that issue.


As far as I can tell, all that I really need is to write a certificate profile for BTCA certificates.

The thing that I am dropping here is the notion that certificates are bound to anything other than a key. So all this is telling the site is that this is the same person who came to the site before. It is not providing the user credential PKIX is really all about.

I do have some questions though. In particular whether using X.448/Ed448 certs is practical.

The big downside to my current approach is that the certs that are used are going to be super-linking identifiers. But we are currently losing that fight.