Re: Request for allocation of new security type code for SASL auth

Peter Rosin <peda@xxxxxxxxxxxxxx> · Thu, 18 Dec 2008 23:19:44 +0100

Den 2008-12-17 11:53 skrev Daniel P. Berrange:

On Wed, Dec 17, 2008 at 08:56:02AM +0100, Peter Rosin wrote:

*snip*

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. 

Ok, cool. Thanks for clarifying!
BTW, I didn't expect "serious" complications either... :-)

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).

But can you really use the VeNCrypt security type like that without
extending its spec (or using unofficial numbers)? What VeNCrypt subtypes
do you plan to use to activate TLS/X509 and at the same time trigger
the SASL security type? It seems that there is need for two new
VeNCrypt subtypes (TLSSASL and X509SASL or something) for VeNCrypt and
SASL to mix nicely.

Ah, and also, can you please "register" the SASL security type with the
Tight project (they need a four character "vendor" representing either
a person, an organization or a product and an eight character "name",
both padded with underscores. I.e. something like product:"VINO" and
name:"SASL____") so that someone can request the SASL security type
after opening the Tight security type.

*snip*

Thanks for the corrections/typos spotted in the spec

My pleasure :-)

Cheers,
Peter
_______________________________________________
VNC-List mailing list
VNC-List@xxxxxxxxxxx
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list