On Wed, Dec 17, 2008 at 08:56:02AM +0100, Peter Rosin wrote: > Hi! > > Den 2008-12-14 17:53 skrev Daniel P. Berrange: > > 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". > > *snip* > > I looked a bit at this and spotted a few typos, see diff in > attachment (I replaced 100 with 20 before making the diff, I figured > those changes were not very interesting). > > I also have a couple of questions: > > 1. Is there any compelling reason to *not* sasl_encode/sasl_decode > the 6.1.3 SecurityResult message when there is a SSF layer? I think > using sasl_encode/sasl_decode on that message as well would simplify > implementations, as the need to hook in after the SecurityResult > disappears. It would be enough to make the needed stream modification > while still running in "sasl territory".
One of the possible reasons for sending back a 'failed' SecurityResult is if the server determines that the negotiated SASL SSF layer is not suitably strong for its needs, or if the authenticated username was not allowed by the ACL. In such a scenario, the server may not wish to go to the bother of using sasl_encode on the securityresult when it knows it is sending back a reject/failure message & dropping the connection. I've got proof of concept implementations of this spec for QEMU and VINO (based of libvncserver) and its not caused any serious complications in the code so far. NB, there are only two common SASL mechanisms which provide SSF layers, GSSAPI (Kerberos) and DIGEST-MD5. DIGEST-MD5 is deprecated as it is considered to be an insufficiently secure negiation. The other SASL mechanisms all rely on the underlying connection to provide encryption. As such, with exception of people using Kerberos, for SASL to be secure you'd want to have the VeNCrypt security type active with one of its x590 based modes, or tunnelling over SSH, or another TLS like protocol extension (VINO has one - Security type 18, TLS - but as currently implemented it is not sufficiently strong because it uses anonymous diffie-hellman credentials instead of x590 certs - this is to be fixed). > 2. Not knowing much about SASL, I'm curious to know if this security > type is useful on reversed connections? Are there any implications > to consider? By reversed connections I assume you mean the scenario where the client does the socket listen(), and the server does the connect(). Since the RFB protocol negotiation still proceeds in the same direction regardless of who initiaited the connection, I see no reason why it shouldn't be applicable. SASL at the end of the day though is just a generic specification for security mechanisms. The actual security characteristics of the apps using SASL depends entirely on what mechanism(s) is(are) configured. Some mechanisms support mutual auth (ie the client verifies the identity of the server, as well as the server verifying the client). This chart gives a high level summary: http://that1site.gotdns.com/docs/cyrus-sasl-2.1.19/mechanisms.html Though the RFC's are a good to reason for comphrensive analysis of the security characteristics & limitations of each mechanism. > 3. And finally, does this security type spec have a home somewhere on > the Internet? It will do in the near future. I'll likely host it on the GTK-VNC project website once I've finalized the spec. I'll post a message here when I have a URL for it.... Thanks for the corrections/typos spotted in the spec Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
