On Thu, Jul 15, 2010 at 04:09:59PM +0100, Daniel P. Berrange wrote:
Hello Dan,
thanks for your input.
> On Thu, Jul 15, 2010 at 04:45:40PM +0200, Adam Tkac wrote:
> > +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
> > +=============== =============== =======================================
>
> We should list all codes in this doc, even if they aren't described,
> so that we have a full record. There are 9 so far
Included in the version 2 of the patch.
> > +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.).
>
> I think this could be clarified a little, since it doesn't make it
> clear whether the u32 byte confirm from the server is sent in clear
> or under TLS.
>
> We should say something like
>
> "After receiving the u32 confirmation of the VeNCrypt subtype,
> the TLS handshake is performed between the client & server.
> If the handshake is unsuccessful the connection must be closed
> and no further RFB protocol messages attempted"
In my opinion both clauses are clear enough but yours is more verbose
so I used it instead of mine.
> > + 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*
> > +========================== ============= ==============================
>
> This isn't correct. There is no confirmation of TLS handshake
> completion at the RFB protocol level. After the TLS handshake
> completes, the RFB protocol proceeds to the auth subtype.
Right you are, I've completely removed this clause.
Patch which incorporates your suggestions is attached.
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,139 @@
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
+=============== =============== =======================================
+256 Plain Plain authentication (should be never used)
+257 TLSNone TLS encryption with no authentication
+258 TLSVnc TLS encryption with VNC authentication
+259 TLSPlain TLS encryption with Plain authentication
+260 X509None X509 encryption with plain password
+261 X509Vnc X509 encryption with VNC authentication
+262 X509Plain X509 encryption with Plain authentication
+263 TLSSASL TLS encryption with SASL authentication
+264 X509SASL X509 encryption with SASL authentication
+=============== =============== =======================================
+
+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.
+
+After receiving the U32 confirmation of the VeNCrypt subtype,
+the TLS handshake is performed between the client and server.
+If the handshake is unsuccessful the connection must be closed
+and no further RFB protocol messages attempted.
+
+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 must 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.
+
+If VeNCrypt subtype has Plain suffix, then authentication continues and
+client sends the username and password in the following form:
+
+=============== ============= =========================================
+No. of bytes Type Description
+=============== ============= =========================================
+4 ``U32`` Username length
+4 ``U32`` Password length
+Username length ``U8`` array Username
+Password length ``U8`` array Password
+=============== ============= =========================================
+
+After that server verifies if supplied credentials are correct and
+continues with the *SecurityResult* message.
+
+If VeNCrypt subtype has SASL suffix, then authentication continues with
+the SASL authentication.
+
+..
+ XXX: Correct link to the SASL method when it gets accepted.
+
+
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
