Whilst I strongly support Client Authentication use-cases, I think framing it in terms of getting rid of the password is unhelpful.
Removing the password and just using a single key stored as a file makes the implicit assumption that everyone always has a secure physical environment. This is not the case. Everyone from victims of domestic violence to dissident journalists to people passing through airports has an insecure physical environment at least some of the time. Although moving away from "something-you-know" is probably fine for many people much of the time, the cases where it fails are very impactful. (TLS) Client authentication is, in practice, a "something-you-have" factor. Whilst it is possible to use strings of words to memorise high-entropy keys, this is unrealistic for anyone except the most highly motivated. Certificate-based Client Auth has lots of great use-cases, for example for identifying devices or providing a second factor of auth, but it is not desirable that it replace passwords. @PHB, I think a much better way forward is working on projects such as OPAQUE + EAs. Also, IMO we should accept that legacy systems are less secure than greenfield, and rather than move towards a future where every environment is somewhat secure most of the time, push towards the most secure possible environments we can, knowing that we'll never get everyone all the way there. Regards, Jonathan On Tue, 24 May 2022 at 12:25, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote: > +1 for FIDO > > Regards, > Uri > > On May 24, 2022, at 01:11, Tim Cappalli <Tim.Cappalli= > 40microsoft....@dmarc.ietf.org> 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
