Allow multiple certificates per user

[cinderblock]

This has been asked years ago in this feature request. Maybe what I'm looking for is possible already with certificate signing, as was mentioned in the original feature request.

Assuming there isn't, I think there are more reasons to add multiple certificates per user.

Using a single cert per user and forcing them to copy the cert to all devices makes it equivalent to a password in most respects. One of the key features of using certificates to authenticate a user is that stolen/lost certificates can be revoked on the server, the stolen key is worthless, and all the other devices work just fine.

This would also be a nice solution for #1832

[mkrautz]

I agree that it's desirable. But how would you do it in practice? (This is assuming the multi-device scenario.)

Say you're on your phone, and want to register yourself with that certificate, and couple that registration to your existing user. How would you design that?

Ideally, it should be possible to authenticate the new certificate yourself -- without admin intervention. Why? Because the admin cannot know if the new device and certificate is in fact you. It could be an imposter performing a social engineering attack.

If we want to allow yourself to perform the operation, the only sound flow I can come up with is:

1. Connect to the server with your desktop client
2. Connect to the server with your phone client
3. From the desktop client, tell the server to add its certificate to your user registration.
4. The same user is now connected twice, but using two different certificates.

Step 4 is something that we don't support today. Currently, only a single instance of a registered user can be on the server at any given point in time.

But that's another feature that would be nice to have -- to be able to connect from both your phone and your desktop at the same time -- having access to the same groups, permissions, and so on on both devices.

Thoughts?

[cinderblock]

The implementation that I think would be best would follow the practices of SSH.

For each client that I want to connect from via SSH, I generate a public/private key pair (sometimes with, sometimes without, passphrases). I manually distribute those keys (using a handful of techniques) to all the (authorized_keys file on) servers I want to authenticate to. Yes, the keys are a little bit of a hassle to distribute, especially for the novice. Yet this is the easiest way to achieve passwordless logins everywhere while enabling key revocation practices.

There is however an even better option, though a little more confusing to set up. SSH supports signing client certificates so that they don't need to even be distributed by the users in the first place. The client certificates need only be signed once by an administrator. See this example by DigitalOcean.

Adding password support to log in like SSH allows has many merits and drawbacks. I won't go into those here as I'm sure it's been discussed elsewhere. For the record, I like Mumble's (nearly) entirely passwordless system.

How to make this all built into the mumble client? Not sure, but forcing a user to email their public key from a phone to get it onto their desktop client to load it onto the server isn't that horrible imho. It's a small price to pay for being the same user on two machines.

As for how to handle concurrent connections from the same user, that's a good question. How about each instance of the logged in user is actually treated as a separate user? They can local mute each other for instance. Permissions would be the same. Friend functions would be disabled between the same user. If usernames' strings are used as unique identifiers internally, a reserved character (assuming there is one) followed by an id could be used to distinguish between the user's multiple instances.

[raspbeguy]

I wish this feature to be realized.

[ViBE-HU]

oh boy. and now it's 2021...

[Krzmbrzl]

@ViBE-HU feel free to take up the work and implement it. We'd certainly appreciate a PR :point_up:

[ViBE-HU]

@ViBE-HU feel free to take up the work and implement it. We'd certainly appreciate a PR ☝️

sadly i'm not a coder guy. i just wondered that this option is not available and no exact statement about it after many years while i see the development goes on. i only participate in the translation project. i know it's a weightless thing.

[Krzmbrzl]

To my knowledge nobody has taken up the work on this yet nor is anyone planning on doing so in the near future :shrug:

[trymeouteh]

Would like to see the ability to have more than one certificate in mumble and be able to easily switch between each certificate.

[ghost]

This is probably a duplicate of https://github.com/mumble-voip/mumble/issues/1832

What would make more sense is a device ID. Meaning, the installed application would need to generate a random ID that pairs to the device and allow sessions for more that one device with the same user id. I would strongly suggest that the user be authenticated as a requirement or at least an ACL so servers don't end up getting botted heavily.

[cinderblock]

I don't think this is a duplicate exactly. But if #1832's proposal is done, that would cover this, but this is a different solution.

This issue is asking for the ability to have multiple sign-in certificates because certs/private keys should basically never be transmitted away from the device they're intended to be used on. We would need some different mechanism to identify users because right now it's using a user's single public key as their unchangeable ID.

Maybe a solution would be a full signing service on the server so that when a user connects with a new device, once authenticated, that device's key is signed and used for future logins.

[Krzmbrzl]

We'll track this in https://github.com/mumble-voip/mumble/issues/6065