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. > 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. > 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. > 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.
Attachment:
signature.asc
Description: This is a digitally signed message part