On Mon, Jul 19, 2010 at 05:40:14PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 19, 2010 at 02:08:30PM +0200, Adam Tkac wrote:
> > +VeNCrypt
> > +--------
>
> > +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.
>
> There's one exception here. With Plain (256) subtype no TLS handshake
> is done, it is completely cleartext. All the others do a anonymous
> of x509 based handshake.
I've restructured the "VeNCrypt subtypes" section a little and this
ambiguity should no longer exist.
> > +
> > +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.
>
> Shouldn't this say that it continues to the 'SecurityResult' message ?
> Actually we should probably just link to section `None`_ since has
> a different sequence depending on RFB version.
Right you are, fixed.
> > +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.
>
> Should we declare what happens for RFB version < 3.8 that don't
> have the securityresult message support ?
If I read RFB protocol correctly all versions (3.3, 3.7 and 3.8) have
SecurityResult support. Difference between 3.{3,7} and 3.8 is that 3.8
sends string which describes what exactly failed.
Next revision of VeNCrypt spec is attached.
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
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,153 @@
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.
+
+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.
+
+Subtypes with TLS or X509 prefix
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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 handshake is not successful, detailed information of failure
+can be obtained from underlying TLS stream and both sides must close the
+connection.
+
+In case TLS handshake is successful and TLS channel is estabilished,
+VeNCrypt authentication can continue.
+
+Subtypes with None suffix
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After TLS handshake, authentication is successful and both sides
+can continue with the `SecurityResult`_ message.
+
+Subtypes with Vnc suffix
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Authentication continues with the `VNC Authentication`_ method when
+TLS handshake is completed.
+
+Plain subtype
+~~~~~~~~~~~~~
+
+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.
+
+Subtypes with Plain suffix
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Authentication continues with the `Plain subtype`_ method when TLS handshake
+is completed.
+
+Subtypes with SASL suffix
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Authentication continues with the SASL method when TLS handshake is completed.
+
+..
+ 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
