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 <tim.cappa...@microsoft.com> 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 <tls-boun...@ietf.org> on behalf of Phillip Hallam-Baker < > ph...@hallambaker.com> > *Date: *Sunday, May 22, 2022 at 23:28 > *To: *tls@ietf.org <tls@ietf.org> > *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. > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
