Paswordless PKI mode (with CRL for revocation)

[wociscz]

I've tried pki setup with lxd server and lxc clients - works perfect. But i was little bit dissapointed because there still need to be "paired" or "trusted" clients and servers with password. With your own CA the advantage of it is only you shouldn't check fingerprints of certificates. Wouldn't be more useful when - if you using your own CA - you should omit passwords in trusting - the trust is replaced with CA where you could revoke certificates?

Don't know if i am clear in my idea - I'd like to have trusted everything without password, based only on validity of certificates issued by my own CA. Before i started with pki in lxd i imagined that this should supposed to work like that. Is this bad idea in some crypto best practices or security risk at some point (not security expert)? Maybe some switch/config parameters when pki is in action some lxc config core.trust_passwordless true? so PKI mode should be passwordless and "standard" self-generating certificates mode should be password-present?

(i know, i can add fingerprints/certificates before trusting, with lxc config trust)

[stgraber]

So the main issue right now is that there is no CRL handling in LXD. So the need for the client to be added to the server's trust store is the only mechanism in place to allow you to remove a client.

[wociscz]

Ah, so when (if) crl/ocsp support will be added - this shoud be possible.. so do you have some kind of "wish list"?

[stgraber]

Yeah, I think once we support having a .crl file on both the client and server, then we can add a flag allowing for password-less trust.

[wociscz]

Thanks!

[stgraber]

PKI mode isn't something we're spending very much time on so I may get to it at some point on my spare time, but if you want this implemented quickly, it may be faster for you to send a branch.

[miranda0615]

Hi @stgraber , I'm a student from UT Austin. I am taking a virtualization class that requires us to work on an open source project, so I was wondering if you are still looking for people to contribute to this. If so, can I get more information on this issue? Thank you very much!

[stgraber]

@miranda0615 yes, we are!

When dealing with remote clients, LXD mostly uses TLS based authentication, where the client will connect using a client certificate and if it's in LXD's database, the access will be allowed.

Those certificates can be added remotely if the user known the the trust password (core.trust_password).

Now, by default both LXD and the client use independently generated TLS certificates, with the initial connection from the client causing a prompt showing the server's fingerprint and asking the user if it's correct (few actually compare it with the expected one, but they at least can if they want).

Organizations do sometimes have a properly setup internal certificate authority which can issue client and server certificates for use by their users and servers. That's where LXD's PKI mode comes in.

In that mode, the organization will issue or sign a server certificate, resulting in a public/private key pair for use by the server (server.crt and server.key). Similarly for the client, organization's CA will issue or sign a client certificate (client.crt and client.key). Both sides will be provided by the CA certificate (ca.crt) which is then used to validate that connections are in fact coming from an organization issued certificate and that the server you're connecting to is signed by the organization too.

That's the extent of what we have today. Adding a server even with PKI mode enabled will still request the trust password and then add the client's certificate to the database.

What this issue is about is supporting another method where the server will automatically trust anyone connecting with a client certificate that's valid according to the server side ca.crt. To do this safely, we need a way to revoke bad certificates and have LXD confirm that the client isn't using a revoked certificate. That's where ca.crl comes in, this is a standard TLS certificate revocation list which lists all certificates ever revoked by the CA, that file would typically be automatically updated by some company system on all servers.

Fixing this issue will include:

• Add support for a ca.crl, used when ca.crt is detected and confirming that any revoked client certificate is immediately rejected during authentication
• Add a configuration option to allow connections by anyone using a certificate issued by the CA. core.trust_ca_certificates as a boolean would control that behavior, defaulting to false.
• Extend the existing pki test to cover this new option (and validate that we can interact with a server without ever having set trust_password) AND confirm that a revoked certificate cannot connect.

[stgraber]

@wociscz would the above cover your use case?

[wociscz]

@wociscz would the above cover your use case?

Yes, exactly! And it'd be nice to add also ocsp mechanism beside crl, and taking these parameters/variables from certificates themselves would be excellent.

[wociscz]

(sorry missclick)

[sz17]

Hello @stgraber , we are students from the same virtualization class as Miranda and we would be interested in working on this issue. Is it still available? Thank you!

[miranda0615]

Hi @stgraber , thanks so much for the reply! Would you mind assigning the issue to my group then? Thank you very much!

[stgraber]

Assigned to the two of you

[sz17]

@stgraber I unassigned myself, since @miranda0615 group will take this issue. Thank you!

[stgraber]

We've now implemented the logic discussed in this issue.