On Thu, Nov 29, 2007 at 05:17:07PM +0000, Daniel P. Berrange wrote: > With the TLS socket, all data is encrypted on the wire. The TCP socket though > is still clear text. Fortunately some SASL authentication mechanism can > also supply encryption capabilities. This is called SSF in SASL terminology. > > This patch mandates the use of an SSF capable SASL authentiction mechanism > on the TCP socket. This in effect restricts you to a choise between GSSAPI > and DIGEST-MD5 as your SASL auth methods (the latter is a user/password > based scheme). We also disallow anonymous & plaintext auth methods. If you > really want to run the TCP socket in clear text & with anonymous auth, simply > turn off SASL altogether. Since TLS already provides encryptiuon, if you run > SASL over the TLS socket, we don't place any restrictions on the choice of > SASL auth mechanism. > > On the server side I have removed the 'direction' field of the client object. > This was only used on the TLS socket & was intended to track whether the > handshake process was waiting to receive or send. Rather than try to set > this in various places throughout the daemon code, we simply query the > neccessary direction at the one point where we register a FD event handle > with poll(). This makes the code clearer to follow & reduces the chance of > accidentally messing up the state. > > The send & receive functions previously would call read vs gnutls_record_recv > and write vs gnutls_record_send depending on the type of socket. If there is > a SASL SSF layer enabled, we have to first pass the outgoing data through > the sasl_encode() API, and pass incoming data through sasl_decode(). So the > send/recive APIs have changed a little, to deal with this codec need and thus > there is also some more state being tracked per connection - we may have to > cache the output for sasl_decode for future calls depending on how much > data we need in short term. > > NB, the SSF layer lets you choose a strength factor from 0 -> a large number > and the docs all talk about > > * 0 = no protection > * 1 = integrity protection only > * 40 = 40-bit DES or 40-bit RC2/RC4 > * 56 = DES > * 112 = triple-DES > * 128 = 128-bit RC2/RC4/BLOWFISH > * 256 = baseline AES > > This is incredibly misleading. The GSSAPI mechanism in SASL will never report > a strength of anything other than 56. Even if it is using triple-DES. The > true strength of the GSSAPI/Kerberos impl is impossible to figure out from > the SASL apis. To ensure that Kerberos uses strong encryption, you need to > make sure that the Kerberos principles issued only have the 3-DES cipher/keys > present. If you are truely paranoid though, you always have the option of using > TLS (which gives at least 128 bit ciphers, often 256 bit), and then just using > Kerberos for auth and ignore the SASL SSF layer. A subsequent patch will make > it possible to configure this stuff. > > qemud/internal.h | 31 +++-- > qemud/qemud.c | 248 +++++++++++++++++++++++++++++++++----------- > qemud/remote.c | 106 ++++++++++++++++++ > src/remote_internal.c | 279 ++++++++++++++++++++++++++++++++++++++++---------- > 4 files changed, 538 insertions(+), 126 deletions(-) This patch is now committed. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list