[Libvir] PATCH: 2/10: SASL encryption support

[Daniel P. Berrange]

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  -=|