Assuming that Daniel's implementation is acceptable, I'm going to go ahead
and request the new framebuffer pseudo encoding per his suggestion. I'd
also like to request that the following three VeNCrypt subtypes be added to
the community spec:
+265 Ident Ident authentication
+266 TLSIdent TLS encryption with Ident authentication
+267 X509Ident X509 encryption with Ident authentication
=============== =============== =======================================
...
+Ident subtype
+~~~~~~~~~~~~~
+
+Client sends the username in the following form:
+
+=============== ============= =========================================
+No. of bytes Type Description
+=============== ============= =========================================
+4 ``U32`` Username length
+Username length ``U8`` array Username
+=============== ============= =========================================
+
+After that server verifies if supplied credentials are correct and
+continues with the `SecurityResult`_ message.
+
...
+Subtypes with Ident suffix
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Authentication continues with the `Ident subtype`_ method when TLS
handshake
+is completed.
I've attached a patch to rfbproto.rst that extends Adam's vencrypt v3 patch.
Thanks,
-brian
On Thu, May 26, 2011 at 12:52 PM, Brian Hinz
<bph...@users.sourceforge.net>wrote:
> 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 :|
>>
>
>
--- rfbproto.vencrypt3.rst 2011-05-28 13:32:58.577133148 -0400
+++ rfbproto.ident.rst 2011-05-28 13:32:09.229133118 -0400
@@ -663,6 +663,9 @@
262 X509Plain X509 encryption with Plain authentication
263 TLSSASL TLS encryption with SASL authentication
264 X509SASL X509 encryption with SASL authentication
+265 Ident Ident authentication
+266 TLSIdent TLS encryption with Ident authentication
+267 X509Ident X509 encryption with Ident authentication
=============== =============== =======================================
After that client selects one VeNCrypt subtype sends back number of that
@@ -735,12 +738,33 @@
After that server verifies if supplied credentials are correct and
continues with the `SecurityResult`_ message.
+Ident subtype
+~~~~~~~~~~~~~
+
+Client sends the username in the following form:
+
+=============== ============= =========================================
+No. of bytes Type Description
+=============== ============= =========================================
+4 ``U32`` Username length
+Username length ``U8`` array Username
+=============== ============= =========================================
+
+After that server verifies if supplied credentials are correct and
+continues with the `SecurityResult`_ message.
+
Subtypes with Plain suffix
~~~~~~~~~~~~~~~~~~~~~~~~~~
Authentication continues with the `Plain subtype`_ method when TLS handshake
is completed.
+Subtypes with Ident suffix
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Authentication continues with the `Ident subtype`_ method when TLS handshake
+is completed.
+
Subtypes with SASL suffix
~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------------------------------------------------------
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
