On Thu, Dec 14, 2023 at 8:36 AM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
> The Android password overspill vulnerability is currently going the
> rounds. It is a serious but manageable problem. The problem being that
> managing it requires an industry wide effort to deploy infrastructure
> that makes use of password managers secure and that is off message
> right now because all the majors are trying to make passwords obsolete.
I'm curious where you are seeing the "offmessage" push.
The Passkey/Fido folk I talk to seem to have this notion that if we all clap our hands and say we believe in Tinkerbell, deployment will be achieved.
> Imagine a world in which every application, of which browsers are only
> one instance, supports a common interface to a password manager that
> resides IN THE PLATFORM and connects to the password management service
> of the user's choice. OSX and Windows already have much of the
> necessary infrastructure to support that already. Call this 'Open
> Password Manager'
> Such a protocol would of course be making heavy use of public key
> cryptography behind the scenes. (And if you let me write the spec, it
> will use threshold cryptography so that the password management service
> has no access to the credentials stored.)
I think that you are proposing a kind of challenge/response protocol where
responses can be plaintext passwords, or passkeys, or something new.
I'm reminded of X9.9, and that we basically did the server side of this over
radius almost 30 years ago.
No, I am proposing people take a look at my Mesh approach and we look to build something better.
When I first proposed we do something, people said 'write a spec, write code'.
So I wrote a spec and code and now they say 'PHB is just protecting his existing code'.
The high level architecture of my solution has two parts.
1) User 'connects' all their devices together to form their own personal digital gestalt.
This is a one time operation so once I connect an iPhone to my personal Mesh, it stays connected until I disconnect it. In the case of an IoT device, it should be able to recover its connection after a factory reset. If I disconnect it, it stays disconnected.
2) Credentials are provisioned to the device according to its function.
I am not going to be provisioning my development credentials for code signing, GitHub access, commit signing to my phone or watch because I don't develop on those. I am not going to provision my IETF Datatracker password out to my coffee maker because it doesn't need it. But I do want all my devices with Web browsing capability to have access to my credentials catalog with the Web passwords and passkeys.
There are three types of credential that need to be supported:
1) Password
2) Global private key
3) Device specific private key
The last is the ideal, best practice is to use a different SSH key for each device so that if a device is lost, access can be revoked by revoking just the public key for that device. But that isn't always possible, require a paid enterprise github subscription to do that with github using SSH client certs.
I make use of threshold cryptography which means that I can revoke the use of a credential by a device if the storage mode allows for that. So if I lose my iPhone, I can prevent it accessing my Web passwords.
3) Support for non repudiable confirmation of critical actions.
Ideally, my Web browser can log in to view my bank/brokerage accounts with a single click but if I want to authorize an action like adding a payee or trading stock, I get a message to my authorized confirmation devices 'Do you want to buy 2000 shares of FTX Corp' and I say yea or nea.
The confirmation protocol could in principle be extended to make use of the threshold mechanism. So if I am signing code for a release, I might get a message on my watch asking if I confirm that action and the watch could enforce that through control of a signature key share.
Yes, I know this is three new infrastructures, but there are fewer interfaces. The application only needs to interface to the means of obtaining credentials. And that is something I would ideally want to bury into the platform so that applications can make use of the credential but cannot access the credential itself. Only the platform needs to interface with the user's choice of credential manager and if the API is properly done, this could be the Mesh or something else. And only the relying party needs to support the 2FA or confirmation protocol.
PHB
