On Wed, May 25, 2011 at 04:33:13PM -0400, Brian Hinz wrote: > Hi, > > I was going to submit a request to RealVNC for an official allocation for a > new security type, but I wanted to run past you guys first for some > feedback. Basically it's an extension that allows a server side daemon to > act as a manager that just redirects clients to the port where user's > session is running (possibly spawning a new server as part of the process). > This makes administration easier by removing the need to keep files (ie: > /etc/sysconfig/vncservers, /etc/xinetd.d/Xvnc) synchronized between hosts. > In my case the daemon is written in perl and also allows users to change > preferences like geometry and depth in a ~/.vncrc file that the daemon > parses before spawning a new Xvnc session. Please let me know if you have > any suggestions. > > Thanks, > -brian > > --- rfbproto.rst 2011-05-05 07:11:30.550460536 -0400 > +++ rfbproto.managed.rst 2011-05-25 16:13:41.104307847 -0400 > @@ -603,6 +603,35 @@ > Note that the `ServerInit`_ message is extended when the Tight security > type has been activated. > > +Managed Security Type > +--------------------- > + > +The Managed security type is designed to allow a server-side daemon to > +respond to incoming requests and redirect those clients to another RFB > +port on a per-user basis. The protocol is simple, after the server > +and client agree upon this security type, the client informs the > +server of the length of the username string, followed by the string > +itself. > + > +=================== =================== =================================== > +No. of bytes Type Description > +=================== =================== =================================== > +1 ``U8`` *length of username* > +*username-length* ``U8`` array *username-string* > +=================== =================== =================================== > + > +The server responds by sending the port number that the > +client should attempt to reconnect on. > + > +=================== =================== =================================== > +No. of bytes Type Description > +=================== =================== =================================== > +2 ``U16`` *port-number* > +=================== =================== =================================== > + > +The connection is then closed and the client initializes a connection on > +the new port.
I think this protocol is a little too limited and could be made to be interoperable with existing auth schemes better. Several of the existing auth schemes include a username (eg SASL, or the VeNCrypt sub-auth 'PLAIN' type), or an identifier that can be used in the same way (eg x509 distinguished name from certificate avialable with x509 based VeNCrypt subauth types). If you just want to be able to provide a username without any password, then i think VeNCrypt sub-auth could already accomplish that. It expects a username+password, but the password could be configured zero-length to allow access freely. So I think just building a server that leverages one of the existing auth types is a practical way for the server to get a username string. For the server initiated redirection message, I think it makes sense for that to be able to be sent at any time during the session. eg when migrating a QEMU guest from one host, to another host, the server could send a message telling the client where the QEMU process has relocated to, allowing the client to reconnect on the new host. QEMU in fact already has support for this with SPICE, and it would be trivial to wire up QEMU's VNC server, and GTK-VNC client too, if we had a formal protocol spec for it. I think this would be best done as a new framebuffer psuedo encoding, rather than security type, since this allows relocation at any time, rather than just during initial connection negotiation. So you'd want to get a new framebuffer encoding allocated and call it CLIENT_RELOCATE or something like that. Declare the that pseduo encoding's x, y, width & height fields are unused and should be set to 0. They are then followed by a payload that looks something like this: =================== =================== =================================== No. of bytes Type Description =================== =================== =================================== 2 U16 *port-number* 4 U32 *hostname-len* hostname-string U8 array *hostname-string* (UTF8) 4 U32 *x509subject-len* x509subject-string U8 array *x509subject-string* (UTF8) =================== =================== =================================== Passing of a (optional) x509subject-string is an idea I borrow from SPICE. Normally when connecting to a VNC server that uses x509 certs, an important security step is to match the x509 hostname field against the initial hostname that the VNC client was given by the user. During relocation though, this isn't possible, so instead the relocation message would include the expected x509 subject string. The client can then validate that instead of the hostname during relocation. Of course this string would be empty if x509 was irrelevant for the current security types. For 'hostname-string' we should declare that either a hostname or a numeric address is valid data. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
