Re: Vino: proposal for inclusion in GNOME 2.8

[Keith Sharp <kms passback co uk>]

On Tue, 2004-07-13 at 10:15 -0400, Colin Walters wrote:
> On Mon, 2004-07-12 at 20:40 +0100, Mark McLoughlin wrote:
> 
> >     Another point worth noting about the SSL support is that (for now) 
> >     it uses anonymous diffie hellman key exchange which still leaves you
> >     vulnerable to man in the middle attacks. Using the SSL support you 
> >     are only making it more difficult for someone to snoop your session.
> >     On an untrusted network, I'd recommend using an SSH tunnel rather 
> >     than the SSL support in Vino.
> 
> This situation seems like an ideal application of user-to-user Kerberos
> authentication.  Vino is heavily targeting the enterprise space, where
> Kerberos will likely be in use.
> 
> http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#u2uauth
> 
> This was actually designed for authenticating X connections:
> 
> http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbxwin
> 
> There is also some work on extending GSSAPI to support this (although
> you can use the Kerberos API directly of course):
> 
> http://www.ietf.org/proceedings/98aug/I-D/draft-ietf-cat-user2user-02.txt

I've been getting interested in Kerberos lately so I had a quick look
into what it would take to add support to Vino.  A few thoughts that
have occurred to me, in no particular order:

1) The current version of the RFB protocol has very simple support for
additional authentication protocols.  Adding Kerberos in addition to
rfbVncAuth and rfbTLS looks quite simple.  The one thing that is needed
is a numeric value to represent Kerberos authentication, this would have
to come from RealVNC - they own the protocol spec.

2) Adding an rfbKerb5 authentication type would give us both mutual
authentication and session encryption.  I would imagine implementing
this as a compile time option, much like TLS.

3) I would recommend implementing Kerberos using the native krb5_* API.
Care would need to be taken to support both MIT and Heimdal
implementations as the C APIs differ slightly.

4) Ultimately the correct way to add stronger authentication and
encryption to RFB is to change the protocol to use a proper security
framework.  From a quick bit of googling it looks like the RealVNC
people are thinking about SASL for the next major version of RFB.

5) All of the code changes would need to be made in the libvncserver
component, it is not clear what Marks policy about changes to the
private copy of libvncserver vs upstream development are.  The README
file mentions a HACKING file, but that doesn't exist in my CVS checkout.

6) For simplicity a first attempt would probably just create a service
principal for each users desktop (not sure how this would work with
multiple hosts, this whole area need more thought) once Vino had used
Kerberos to authenticate who was trying to connect a decision could be
made about whether they should be allowed to connect.  Later versions
could use the User2User protocol that Colin mentions.

I should point out that I am a relative newbie to Kerberos, but I am
interested in pursing this - once I get my test environment working :-)

Keith.