Features/VirtVNCAuth

Virtualization VNC Authentication

Summary

Define a mapping of SASL authentication into the VNC protocol, and implement it for QEMU and GTK-VNC, providing strongly authenticated, securely encrypted remote access of virtual guest consoles.

Owner

• Name: Daniel Berrange
• email: berrange@fedoraproject.org

Current status

• Targeted release: 11
• Last updated: (DATE)
• Percentage of completion: 30%

Detailed Description

The Fedora 8 release introduced the new feature [| VirtSecurity] which comprised supporting the SSL/TLS protocol and x590 certificate in the libvirt RPC layer and VNC protocol. The Fedora 9 release extended this work to add the new feature [SASL authentication] to the libvirt RPC layer. The next logical piece in the security puzzle for virtualization is thus SASL authentication in the VNC protocol. That is the purpose of this new feature for Fedora 11.

VNC has been lacking in serious authentication capabilities since the day it was invented. Various projects have invented new authentication types eg, UltraVNC's MS-Logon integration, but no one has ever attempted to define an portable & extensible standard for VNC authentication that can easily be used across any client/server implementation.

The SASL protocol is well documented Internet specification (RF 4422) that has multiple implementations (cyrus-sasl, gsasl, Java SASL) portable to every major operating system. It defines a protocol that is independent of the authentication mechanism, so as new mechanisms are invented/implemented they can be plugged into existing SASL enabled applications without needing further code / protocol changes.

Of particular interest is the GSSAPI mechanism, which enables Kerberos single-sign-on. Other mechanisms include plain username/password (checkable against files, LDAP, SQL database, etc), one-time passwords, and more).

Benefit to Fedora

A number of virtualization platforms use QEMU for their host device model, and the primary protocol for interacting with QEMU remotely is VNC. Until now the only truly secure means of accessing VNC remotely is to tunnel the VNC connection over SSH. This is not a satisfactory approach for many virtualization hosts, since it entails opening SSH access to the virtualization for guest administrators. Supporting SASL in the VNC protocol, in concert with the previously added SSL/TLS feature, will allow strongly authenticated, securely encrypted remote access to VNC server without any need for tunnelling.

With a little extra effort, the work to support VNC+SASL in the virtualization arena, can be extended to desktop users, by adding SASL to the VINO remote desktop service in GNOME. This will provide Fedora users with a strongly authenticated, securely encrypted remote desktop service.

Scope

1. [SPEC] Obtain an officially allocated VNC security type code for the new SASL protocol [DONE]
2. [SPEC] Write a specification for mapping SASL into the VNC protocol [DONE]
3. [SERVER] Implement the core SASL protocol in QEMU's VNC server [DONE]
4. [SERVER] Implement a means to define the user ACL for authentication in QEMU [NOT STARTED]
5. [SERVER] Get code reviewed & accepted in upstream QEMU [NOT STARTED]
6. [SERVER] Encourage QEMU to produce a new release in time for Fedora 11, or backport the accepted patches to QEMU 0.9.1 [NOT STARTED]
7. [MANAGEMENT] Extend libvirt to allow configuration of SASL authentication for QEMU [NOT STARTED]
8. [CLIENT] Implement the core SASL protocol in GTK-VNC client [NOT STARTED]
9. [BONUS] Implement the core SASL protocol in VINO's VNC server [IN PROGRESS] (TBD: move to a separate feature page ?)

How To Test

SASL supports a number of pluggable authentication mechanisms. Some mechanisms (GSSAPI, DIGEST-MD5) provide session data encryption, while others rely on security of the underlying data channel, thus requiring use of TLS/x509 to be secure

Recommended testing auth configurations

Plain TCP + GSSAPI. Aka Kerberos single-sign-on

The GSSAPI mechanism provides data encryption as well as authentication, thus does not require use of TLS. To test this requires a Kerberos server. Fedora includes the FreeIPA server which is easy to deploy and manage.

TBD: Fill in how to configure & test this

Plain TCP + Digest-MD5

The SASL DIGEST-MD5 auth mechanism is considered to no longer provide satisfactory security, but it is easy to setup without needing TLS, so is a useful way to test the core infrastructure in apps, even if not suitable for production deployment

TBD: Fill in how to configure & test this

SSL/TLS + Plain

A simple password based authentication mechanism, requiring that the server use TLS for encryption

TBD: Fill in how to configure & test this

User Experience

In a site which has Kerberos/FreeIPA deployed, users will be able to configure their virtual guests to use SASL authentication with GSSAPI. Using client tools such as virt-viewer, virt-manager or vinagre they will be able to access their guest virtual machine desktops using Kerberos Single-sign-on, avoiding any need for passwords.

In a site without Kerberos, users will be able to cofnigure their virtual guests with TLS + x590 certificates, and then authenticate with passwords. The virt-viewer/manager/vinagre client will store their passwords in the GNOME keyring, so after the initial connection, all subsequent connections will be passwordless

The user will never have to setup SSH tunnels for accessing VNC servers again.

Dependencies

This work is spread across a number of packages

- qemu, kvm (and maybe 'xen')
- gtk-vnc
- Possibly vino

Contingency Plan

No existing functionality is impacted, so in event of problems this feature will be postponed to a later Fedora release and users will continue with their current deployment / remote access methods.

Documentation

TBD: Link to the VNC SASL security specification. Written, but needs permanent home website TBD: Link to the QEMU documentation on configuring SASL (to be written :-) TBD: Link to the libvirt documentation on configuring SASL for VNC (to be written :)

Release Notes

TBD

Comments and Discussion

• See Talk:Features/VirtVNCAuth

---