Hello all,
I just finished formal VeNCrypt (v0.2) specification, proposed patch is
attached. All information was obtained directly from the original
implementation, the VeNCrypt project.
Those pieces of the specification is missing:
1. TLSPlain and X509Plain sub-encoding specification
- I will write it when I analyze *Plain authentication method in detail.
2. 0.1 version of the VeNCrypt extension
- I don't think it makes sence to waste time because I wasn't able
to find any VNC implementation which implements 0.1 version and
doesn't implement 0.2 version
Your comments are welcomed.
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
VeNCrypt security type specification.
VeNCrypt security type specification was obtained directly from code of the
original implementation, the VeNCrypt project
(http://sourceforge.net/projects/vencrypt).
Signed-off-by: Adam Tkac <at...@redhat.com>
Index: rfbproto.rst
===================================================================
--- rfbproto.rst (revision 4086)
+++ rfbproto.rst (working copy)
@@ -373,6 +373,7 @@
1 `None`_
2 `VNC Authentication`_
16 `Tight Security Type`_
+19 `VeNCrypt`_
=========== ===========================================================
Other registered security types are:
@@ -384,7 +385,6 @@
6 RA2ne
17 Ultra
18 TLS
-19 VeNCrypt
20 SASL
21 MD5 hash authentication
=========== ===========================================================
@@ -603,6 +603,137 @@
Note that the `ServerInit`_ message is extended when the Tight security
type has been activated.
+VeNCrypt
+--------
+
+The VeNCrypt security type is a generic authentication method which
+encapsulates multiple authentication subtypes. Every VeNCrypt subtype
+creates TLS stream so all VNC traffic is encrypted.
+
+After VeNCrypt security type is selected server sends the highest
+version of VeNCrypt it can support. Although two versions exist, 0.1
+and 0.2, this document describes only newer version 0.2.
+
+=============== ======= ======= =======================================
+No. of bytes Type Value Description
+=============== ======= ======= =======================================
+1 ``U8`` 0 Major version number
+1 ``U8`` 2 Minor version number
+=============== ======= ======= =======================================
+
+Then client sends back the highest VeNCrypt version it can support, up to
+version that it received from the server.
+
+=============== ======= ===============================================
+No. of bytes Type Description
+=============== ======= ===============================================
+1 ``U8`` Major version number
+1 ``U8`` Minor version number
+=============== ======= ===============================================
+
+After that server sends one byte response which indicates if everything
+is OK. Non-zero value means failure and connection will be closed. Zero
+value means success.
+
+=============== ======= ===============================================
+No. of bytes Type Description
+=============== ======= ===============================================
+1 ``U8`` Ack
+=============== ======= ===============================================
+
+Then server sends list of supported VeNCrypt subtypes.
+
+=============== =============== =======================================
+No. of bytes Type Description
+=============== =============== =======================================
+1 ``U8`` subtypes length
+subtypes length ``U32`` array subtypes
+=============== =============== =======================================
+
+Following VeNCrypt subtypes are defined in this document:
+
+=============== =============== =======================================
+Code Name Description
+=============== =============== =======================================
+257 TLSNone TLS encryption with no authentication
+258 TLSVnc TLS encryption with VNC authentication
+260 X509None X509 encryption with plain password
+261 X509Vnc X509 encryption with VNC authentication
+=============== =============== =======================================
+
+..
+ TODO: Define TLSPlain and X509Plain
+
+After that client selects one VeNCrypt subtype sends back number of that
+type.
+
+=============== ======= ===============================================
+No. of bytes Type Description
+=============== ======= ===============================================
+1 ``U32`` Selected VeNCrypt subtype
+=============== ======= ===============================================
+
+If client supports none of the VeNCrypt subtypes it terminates
+connection.
+
+When subtype is selected authentication continues as written in particular
+VeNCrypt subtype description.
+
+VeNCrypt subtypes
+~~~~~~~~~~~~~~~~~
+
+This section applies to all VeNCrypt subtypes. All those subtypes
+use TLS-encrypted stream and server use anonymous X509
+certificate (subtypes with the TLS prefix) or valid X509 certificate
+(subtypes with the X509 prefix). When session is negotiated, all
+further traffic is send via this encrypted channel.
+
+When any of the VeNCrypt subtype is decided, server tries to setup
+TLS session (load certificates etc.). After that it sends back to client
+if it was successful:
+
+=============== ======= =========== ===================================
+No. of bytes Type [Value] Description
+=============== ======= =========== ===================================
+4 ``U32`` status:
+.. 0 OK
+.. 1 failed
+=============== ======= =========== ===================================
+
+In case of failure, server sends a string with detailed description and
+closes the connection:
+
+========================== ============= ==============================
+No. of bytes Type Description
+========================== ============= ==============================
+4 ``U32`` *reason-length*
+*reason-length* ``U8`` array *reason-string*
+========================== ============= ==============================
+
+Now client sets his TLS session parameters (like CA certificate etc.).
+In case of failure it terminates the connection. When both sides have
+TLS session parameters set, TLS negotiation can start.
+
+Note about TLS parameters, like algorithm and key length. VeNCrypt
+doesn't enforce any restriction, setting should be determined by local
+security policy on client, respective server, side. This also applies
+for validity of the server certificate, client side can decide if it
+wants to accept invalid server certificate.
+
+In case TLS negotiation is not successful, detailed information of failure
+can be obtained from underlying TLS stream and both sides can close the
+connection.
+
+In case TLS negotiation is successful and TLS channel is estabilished,
+VeNCrypt authentication can continue.
+
+If VeNCrypt subtype has None suffix then authentication is successful,
+both sides can continue to `Initialisation Messages`_ section.
+
+If VeNCrypt subtype has Vnc suffix, then authentication continues with
+the standard `VNC Authentication`_ method.
+
+
Initialisation Messages
+++++++++++++++++++++++
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
