Hi Dan,
On Wed, 2007-01-10 at 23:59 +0000, Daniel P. Berrange wrote:
> I now have the QEMU backend working with full wire encryption using the
> TLS protocol, and so ready to start thinking about various authentication
> related issues.
If only we had decent SSH infrastructure. I'd love if apps could easily
use a library to request an SSH connection to a host, authenticate and
then apps could request tunnels over that shared per-user connection.
> - The client needs to have the certificate of the CA in order to
> validate the signature on the remote server's certificate
> (aka, just like web browsers need a set of CA certificates)
>
> Currently I just have it loading 'cert.pem' out of the current
> working directory of the app using libvirt. Obviously this is not
> a real solution.
Personally, I'd start with the assumption that essentially no-one will
install a CA signed cert for the libvirt server. So, first and foremost,
the client needs to be present self-signed certs to the user.
As for the CA certs, we should use /etc/pki/tls/cert.pem by default,
right? And perhaps allow users and admins to install other CA certs just
for libvirt.
> - The server end can optionally require the client to present a
> certificate too, as its means of authenticating the client.
>
> This obviously requires a way of specifying the client certificate
> and secret key in libvirt when opening the connection.
For the networks stuff, I think the server will also need to be able to
connect to (and authenticate and be authenticated by) other servers.
Also, as much as it sucks, I think we'll want password based
authentication as well as certificate based authentication. Very few
people will copy the client cert over to the server, I think.
> As a rough stab at an API my thoughts are:
>
> typedef enum {
> VIR_CERT_CA_CERT,
> VIR_CERT_CA_CRL,
> VIR_CERT_CLIENT_KEY,
> VIR_CERT_CLIENT_CERT,
> } virConnectCertDataType;
>
> /**
> * dataType: one of the virConnectCertDataType constants
> * data: base64, PEM encoded certificate/key data
> */
> int virConnectAddCertData(int dataType, const char *data);
>
> /**
> * dataType: one of the virConnectCertDataType constants
> * dataFile: file containing base64, PEM encoded certificate/key data
> */
> int virConnectAddCertDataFile(int dataType, const char *dataFile);
Seems reasonable, I can't think of anything better.
> Virt-manager would use the latter API to load in its client certificate,
> CA certs, etc to libvirt prior to opening a connection to a TLS enabled
> server. This means libvirt doesn't have to make the policy on where to
> store its client cert data. On the otherhand, we probably want the
> files to be in a common location for virsh & virt-manager so both can
> use the same data. On yet another hand, virt-manager will also likely
> end up using TLS to connect to VNC, so needs access to the files
> independant on libvirt / virsh for that. So we should probably have
> these flexible APIs, but recommend that all apps use a pre-defined
> directory unless they have a particular need not to, eg
>
> $HOME/.libvirt/tls/
> |
> +- ca
> | |
> | +- cert.pem
> | +- ca-crl.pem
> |
> +- client
> | |
> | +- cert.pem
> | +- key.pem
> |
> +- server
> |
> +- trusted.pem
Not entirely unreasonable, but I think I'd expect it to be in
~/.virt-manager and have a ~/.virshrc which you could point at it.
If it was ~/.libvirt, then I'd expect virt-manager to access the certs
through e.g. virConnectGetCertData() rather than making the directory
structure part of the API.
One final point on all that - "uggh".
> /**
> * hostname: canonical name of remote host providing certiifcate
> * cert: base64, PEM encoded certificate data
> *
> * Invoked to let client application decide whether to accept a
> * server certificate. The certificate wil already have been
> * validated against the CA cert, and its expiration date, etc
> * checked. This callback is intended to allow the end user to
> * accept/reject the certificate. The trusted flag indicates
> * whether the server is present in the list of known servers.
> */
> typedef int (*virConnectCertificateValidator)(const char *hostname, const char *cert);
>
> int virConnectSetCertificateValidator(virConnectCertificateValidator cb)
>
> The applications like virt-manager would probably want to present the
> certificate details to the user for validation, also optionally maintaining
> a list of previously trusted server certs.
The callback approach seems fine. I'd think about adding a
virConnectCertificate structure whose contents are only available
through accessor functions and passing that to the callback, though. For
future expansion.
Cheers,
Mark.