Re: [TLS] Better TLS Client Authentication

[Phillip Hallam-Baker <[e-mail]>]

If we are looking at installed footprint, then TLS Client Auth wins. Don't
accuse me of re-inventing the wheel because TLS Client Auth predates FIDO
by decades.

It is a completely different application though. FIDO was designed to
enable use of physical authenticator tokens. As far as I can see, soft
tokens are an afterthought, they don't have a strategy for provisioning
multiple devices with a private key bound to the same account.

My starting point here was that I was looking at how to make use of the
Mesh to support FIDO auth without the need for a physical token. That is
the route I expected to take. It was only when I looked into it that I
suddenly realized that I don't need any of that, I can do everything I need
with legacy browsers and legacy servers. The only thing that changes is a
client enrollment app on the client side and an authorization module in the
server.

No protocol changes, just a certificate profile.

At this point FIDO has far less deployed base than TLS Client Auth, I am
happy to support FIDO as well but why wouldn't we want both?
I really don't think I am the person suffering from Not Invented Here.


I can provide the same key mobility capabilities in WebAuthn so that users
can register for a Web site with their phone browser and then log in from
their laptop without requiring an additional registration while maintaining
the End-to-End security of the private keys. But that would require some
significant extensions to FIDO and be more of a FIDO3.

The security properties of WebAuthn and TLS Client Auth are very
different.TLS Client Auth is not limited to Web for a start. We could use
it to secure IMAP, POP3 and SUBMIT client auth.



On Tue, May 24, 2022 at 1:11 AM Tim Cappalli <[e-mail]>
wrote:

> 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.
>
>
>
>
>