Re: Request for allocation of new security type code for SASL auth
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Den 2008-12-17 11:53 skrev Daniel P. Berrange:
On Wed, Dec 17, 2008 at 08:56:02AM +0100, Peter Rosin wrote:
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 seriouscomplications 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 SASLmechanisms 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 currentlyimplemented 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
[Books] [Home] [Photo] [Yosemite] [Hot Springs] [VNC Home] [PDAs] [Open Source Now] [Epson Inkjet]