Re: [TLS] Better TLS Client Authentication

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

Let me be clear here, I was not asking for permission. I am just asking for
people with technical contributions to the proposal.

WebAuthn is not going to work for non Web applications of TLS.

You know, this type of response is the reason people stop coming to the
IETF to get things done. I am well aware of the work in question, it
attempts to address a different need. It is not a new proposal by any
means, it has seen some use but they are still looking at a user
authentication model which is hardly going to work for Web Service to Web
Service.


On Thu, May 26, 2022 at 8:38 AM Blumenthal, Uri - 0553 - MITLL <
[e-mail]> wrote:

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