From Fedora Project Wiki
(New page: = Virtualization VNC Authentication = == Summary == == Owner == <!--This should link to your home wiki page so we know who you are--> * Name: Your Name <!-- I...)
 
No edit summary
Line 1: Line 1:
= Virtualization VNC Authentication =
= Virtualization VNC Authentication =


== Summary ==
== 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 ==
== Owner ==
<!--This should link to your home wiki page so we know who you are-->
* Name: [[User:FASAcountName| Your Name]]


<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
* Name: [[User:berrange| Daniel Berrange]]
* email: <your email address so we can contact you, invite you to meetings, etc.>
* email: berrange@fedoraproject.org


== Current status ==
== Current status ==
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  
* Targeted release: [[Releases/11 | 11 ]]  
* Last updated: (DATE)
* Last updated: (DATE)
* Percentage of completion: XX%
* Percentage of completion: 30%
 
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->


== Detailed Description ==
== Detailed Description ==
Line 39: Line 34:
== Scope ==
== Scope ==


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


- Obtain an officially allocated VNC security type code for the new SASL protocol
== How To Test ==
- Write a specification for mapping SASL into the VNC protocol


Server side work
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


- Implement the core SASL protocol in QEMU's VNC server
Recommended testing auth configurations
- Implement a means to define the user ACL for authentication in QEMU
- Get code reviewed & accepted in upstream QEMU
- Encourage QEMU to produce a new release in time for Fedora 11, or backport the accepted patches to QEMU 0.9.1
- Extend libvirt to allow configuration of SASL authentication for QEMU


Client side work
=== Plain TCP + GSSAPI. Aka Kerberos single-sign-on ===


- Implement the core SASL protocol in GTK-VNC client
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 [http://freeipa.org FreeIPA server] which is easy to deploy and manage.


For extra credit
TBD: Fill in how to configure this


- Implement the core SASL protocol in VINO's VNC server (TBD: move to a separate feature page ?)
=== Plain TCP + Digest-MD5 ====


== How To Test ==
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 this
 
=== SSL/TLS + Plain ====
 
A simple password based authentication mechanism, requiring that the server use TLS for encryption
 
TBD: Fill in how to configure this


<!--
<!--
Line 75: Line 81:


== User Experience ==
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
 
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 ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? -->
 
This work is spread across a number of packages
 
  - qemu, kvm (and maybe 'xen')
  - gtk-vnc
- Possibly vino


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. -->
 
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 ==
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->


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 ==
== Release Notes ==


<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
TBD
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
 
== Comments and Discussion ==
== Comments and Discussion ==


* See [[Talk:Features/YourFeatureName]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/YourFeatureName]]   
 


----
----

Revision as of 13:14, 16 December 2008

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

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

+ [SPEC] Obtain an officially allocated VNC security type code for the new SASL protocol + [SPEC] Write a specification for mapping SASL into the VNC protocol + [SERVER] Implement the core SASL protocol in QEMU's VNC server + [SERVER] Implement a means to define the user ACL for authentication in QEMU + [SERVER] Get code reviewed & accepted in upstream QEMU + [SERVER] Encourage QEMU to produce a new release in time for Fedora 11, or backport the accepted patches to QEMU 0.9.1 + [MANAGEMENT] Extend libvirt to allow configuration of SASL authentication for QEMU + [CLIENT] Implement the core SASL protocol in GTK-VNC client + [BONUS] Implement the core SASL protocol in VINO's VNC server (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 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 this

SSL/TLS + Plain =

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

TBD: Fill in how to configure 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