Re: Vino: proposal for inclusion in GNOME 2.8

[Keith Sharp <kms passback co uk>]

On Tue, 2004-07-13 at 14:27 -0400, Colin Walters wrote:
> On Tue, 2004-07-13 at 19:17 +0100, Keith Sharp wrote:
> 
> > 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.
> 
> Makes sense.
> 
> > 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.
> 
> Well you could dynamically load modules I guess, but that's just an
> implementation detail.

Could do, but the TLS doesn't work that way so why make it more
complicated :-)

> > 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.
> 
> Yeah I don't think you have a choice at the moment as the GSSAPI bits
> are a draft.

>From browsing the archives of the Kerberos list at MIT, they seem to
recommend using SASL if possible, then GSSAPI, and only krb5_* as a last
resort.  Having looked at the way the authentication is done in RFB and
libvncserver anything other than krb5_* looks like a nightmare.

> > 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.
> 
> Well, the issue here is that the server is not running privileged
> (correct me if I'm wrong please Mark).  So you can't use system
> authentication which is what most SASL mechanisms do.

I thought that if you added SASL support then you either got native
Kerberos authentication through SASL/GSSAPI or, if your client didn't
support GSSAPI, you used saslauthd and it took care of interacting with
the system authentication bits for you.

That's my understanding from reading Chapter 7 of "Kerberos the
Definitive Guide" by Jason Garman.

> > 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.
> 
> Makes sense.
> 
> > 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.  
> 
> I think the whole point of user-to-user is to not have to create a
> service principal for each user, and distribute the service key or the
> password for it to each client machine.

Ah, I see. Needs more investigation on my part.

One other thing I forgot to mention, at some point Kerberos support
would need to be added to vncviewer as well, other wise it is all a bit
pointless.  I haven't looked at the source for vncviewer to see how much
work this would be.

Keith.