Daniel,
After I read Pierre's comments, I also thought a VeNCrypt subtype would be a
better way to implement authentication than trying to re-invent the wheel.
Anyone object to going with Daniel's implementation instead?
Thanks,
-brian
On Thu, May 26, 2011 at 8:37 AM, Daniel P. Berrange <d...@berrange.com>wrote:
> 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
