NtlmSigningAndSealing

NTLM signing and sealing is part of the push to get SingleSignOn to work in Wine.

As the logical extension of the work I did last year, see SingleSignOnSummerOfCode2005Summary, this year's project is aimed at adding message integrity and encryption support to the NTLM and Negotiate providers.

Unfortunately, my choice of tools last year proved to be suboptimal. ntlm_auth cannot be used for anything besides authentication. Because of this, I'm currently working on reimplementing last year's work the way it should have been done in the first place, linking to the GENSEC library directly. (Of course there was no "GENSEC library" last year, so I don't feel too bad.)

Luckily, using libgensec this way isn't too hard, and I already have working code for all I did last year. The bad news on this is that GENSEC still is GPL code, so it's not useable for Wine yet.

Part of my planned project is to spend time on Samba4 to help working on separating libgensec from the rest of the code. I'd like to already thank the Samba team for the nice cooperation we had on this so far.

Project update, 2006-07-24:

It looks like the GENSEC library is not the way this is going to work after all. After spending a lot of time discussing how to best move GENSEC to a LGPL license, I finally decided to stick to last year's approach. I have now extended ntlm_auth to provide the negotiated session key and the provided flags. This means that I will have to take care of the signing and sealing within wine, but this will have to do for now.

Post-mortem analysis

What the project is about

The Security System Provider Interface (SSPI) is an abstraction layer for authentication mechanisms used in Microsoft Windows that is similar to GSSAPI. At the beginning of this SummerOfCode 2005 project, Wine already had a basic implementation of the NTLM provider. As SSPI supports not only authentication but also message integrity (digital signatures of messages) and confidentiality (encryption of messages), adding this to Wine will eventually allow applications like Outlook 2003 to encrypt data in transmission when talking to a server supporting NTLM.

What is done so far

  • NTLM authentication (SingleSignOnSummerOfCode2005Summary)

    • This part now builds on last year's work, not much to tell about.
  • extend ntlm_auth to accept feature flag requests and return negotiated feature flags and the session key
    • The patches for this are now in the current SVN trees ob both Samba3 and Samba4. Dummy signing should work on the unmodified ntlm_auth binary, at least client side.

  • implement SignMessage

    • Capable of handling dummy signing and real NTLMv1 signing.

  • implement VerifyMessage

    • Capable of handling dummy signing and real NTLMv1 signing.

  • implement EncryptMessage

    • Works for real NTLMv1 encryption.

  • implement DecryptMessage

    • Works for real NTLMv1 decryption.

What is left to do

  • EncryptMessage

    • Does not handle the dummy case yet, which is used as a fallback for old ntlm_auth versions.

  • DecryptMessage

    • Also does not handle the dummy case yet.

Future (related) work

  • Based on the NTLMv1 work, NTLMv2 should be implemented. It is cryptographically more secure than NTLMv1, but harder to implement. (Done)

  • The LSA functions should be fixed to return sane values if no SEC_WINNT_AUTH_IDENTITY structure is given to InitializeSecurityContext()

  • Get together with the Samba people to work on a credentials cache for winbindd/LSA/pam.
  • Add a Kerberos provider.
  • Add a Negotiate provider that can negotiate between Kerberos and NTLM.

A look back

I initially started out implementing this stuff based on Samba4's GENSEC library. Unfortunately for me, it was not as easy as we imagined to cut all references to code that should stay GPLed of the GENSEC library, as it has numerous tricky dependencies on other areas of the Samba code. I do have a fully working patch set implementing my project based on GENSEC, but as the GENSEC license would force me to GPL the work, it will never be included in Wine.

This realization was kind of a blow to my motivation, and I started wondering if using another library from the beginning wouldn't have been the better choice after all when Volker Lendecke of the Samba team phoned me to talk about implementing this using Samba3's winbindd instead. While I investigated this idea and was about to write it off due to the really difficult dependencies and configuration complexities winbindd would add to the mix I realized that ntlm_auth was the ideal tool to use, after all, it just needed some additional commands. To my great surprise my suggestions for enhancing ntlm_auth met open ears on the Samba side and my patches will be included in coming Samba releases.

One of my big problems was (and still is) testing for all of this, After all, a successfull authentication is needed to get started with signing and sealing. I finally managed to set up a test using dummy server packages, in a sort of "degraded" mode, but it seems like encryption for a case like this is a special case and my Wine code cannot handle this yet.

Conclusions

Trying to get together two projects that have differing licenses and both emphasis a preference for as few build dependency as possible is quite exhausting. I hope the soultion using ntlm_auth is acceptable, in my opinion it provides the best tradeoff between reuse of Samba technology and code inside the Wine tree in order too keep the compile-time dependencies small.

Fixed after SoC

  • EncryptMessage

    • Does handle the dummy case now.

  • DecryptMessage

    • Also handles the dummy case now.

These errors were due to a wrong assumption when creating the NTLMv1 session key from the user password.

  • NTLMv2 support

---

NtlmSigningAndSealing (last edited 2008-05-03 02:30:46 by nathan.n)