Re: [TLS] Better TLS Client Authentication

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

This is not about what was there earlier, nor what has been in wider use so far (in which case, password clearly wins ;). 

 

Rather – what is the best (from security and usability point of view) mechanism now. I say – FIDO (or U2F, whatever) is the closest contender, if not the outright winner.

 

Thanks

-- 

V/R,

Uri

 

 

From: TLS <[e-mail]> on behalf of Phillip Hallam-Baker <[e-mail]>
Date: Wednesday, May 25, 2022 at 21:01
To: Tim Cappalli <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [TLS] Better TLS Client Authentication

 

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

 

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.