Hi Daniel,
Please use security type number 20.
Thanks,
--
Wez @ RealVNC Ltd
> -Original Message-
> From: vnc-list-ad...@realvnc.com [mailto:vnc-list-ad...@realvnc.com] On
> Behalf Of Daniel P. Berrange
> Sent: 14 December 2008 16:54
> To: vnc-list@realvnc.com
> Subject: Request for allocation of new security type code for SASL auth
>
> I have defined a mapping of the SASL authentication scheme into the RFB
> authentication protocol. Please could you allocate an official security
> type code for use with this auth scheme, under the name "SASL".
>
> There are a number of reasons why it is desirable to support SASL in
> the RFB protocol
>
> - It is an official internet RFC with API support across all OS
> platforms,
>providing for both authentication and session data encryption.
>
> - The SASL protocol is independant of authentication mechanism
> allowing
>new mechanisms to be plugged in without any application code changes
>
> - The DIGEST-MD5 SASL mechanism will provide a simple
> username+password
>based alternative to the existing "VNC" security type, but with
> stronger
>security, and session data encryption.
>
> - The GSSAPI SASL mechanism will provider integration with Kerberos
> for
>Single-Sign-On capabilities, again also having session data
> encryption
>
> There are a variety of other plugins that will be useful to many people
> such as passwd auth against a SQL database, auth against LDAP, one-
> time
> passwords, and NTLM.
>
> I intend to implement client side support for this "SASL" security type
> in the GTK-VNC client, the GNOME VINO server (remote desktop), and the
> QEMU built-in VNC server (OS virtualization).
>
> My current security type protocol spec documentation follows, though I
> may
> well refine details of it as I finish the implementations. I currently
> have GTK-VNC and QEMU operational, without session encryption.
>
> NB, the protocol description that follows, just picks security code 100
> out of the hat. This will obviously be updated to reflect the actual
> security type code officially allocated.
>
> Daniel
>
> 6.2.100 SASL Authentication
> ===
>
> SASL authentication is to be used, optionally with a encryption
> capability for the protocol data to be negotiated between the
> client and server. The author recommends that an SSF layer always
> be requested during negotiation unless it is known that the
> connection is secured by a prior authentication exchange such as
> TLS / VeNCrypt, or externally via a SSH tunnel.
>
> The SASL negotiation is a multi-step protocol, initiated by the
> server. The precise number of steps required for the complete
> negotiation is determined by the SASL mechanism chosen for auth.
> Compliant implementations must expect an arbitrary number of
> steps.
>
> The SASL protocol is defined in RFC . Recommended libraries
> for implementation on either client or server end are Cyrus-SASL
> and gSASL.
>
>
> 6.2.100.1 SASL server initialization message
>
>
> The server initializes the SASL authentication process by sending
> the list of mechanisms it is prepared to accept from the client.
>
> # of bytes | Type | Description
> -+--+
> 4 | u32 | mechlist-length
> mechlist-length | u8 array | mechlist-string
> -
>
> The "mechlist-string" is a list of SASL mechanism names, each
> separated by a comma. The "mechlist-length" is the number of
> characters in the string. The trailing '\0' is not transmitted
> on the wire. Some example "mechlist-string" values are
>
> "DIGEST-MD5,GSSAPI"
> "ANONYMOUS,KERBEROS_V4,DIGEST-MD5"
>
> The "mechlist-string" is typically generated on the server by
> a call to the function:
>
> err = sasl_listmech(vs->saslconn,
> NULL,
> "", /* Prefix */
> ",", /* Separator */
> "", /* Suffix */
> &mechlist,
> NULL,
> NULL);
>
> The library used for the SASL implementation will usually
> provide a means for the adminsitrator to configure exactly
> what mechanisms are enabled.
>
>
> 6.2.100.2 SASL client start message
> ---
>
> Upon receiving the list of mechanisms allowed by the server,
> the client may choose a specific mechanism from the list, or
> allow the SASL library to make the choice.
>
> The client shall call "sasl_client_start" providing either
> a specific mechanism name, or the full list supported by the
> server. The client shall normally supply a list of prompts
> it is prepared to support for collecting credentials from
> the user.
>
> If the "sasl_client_start" call is successfull, the returned
> "clientout" data will need to be sent to the se
