SSPI and Interactive logon GSOC Proposal - Ros-dev

30 Mar 2011

Hello fellow ReactOS developers and users,
Most of you might know me from IRC as encoded. I am a Computer Science
student at the Polytechnic University of Puerto Rico. Although at
times not the best IRC citizen, I've always had the best intentions
for ReactOS at heart. The following is my proposal/plan outline for
Implementing SSPI and secure authentication mechanisms for ReactOS,
including Interactive Logon.
First, some definitions:
Security Support Provider Interface (SSPI) allows applications to use
various security models available on a computer or network without
changing the interface to the security system. SSPI does not establish
logon credentials because that is generally a privileged operation
handled by the operating system(LSA).
Windows Challenge/Response (NTLM) is the authentication protocol used
on systems running Windows. NTLM credentials are based on data
obtained during the interactive logon process and consist of a domain
name, a user name, and a one-way hash of the user's password. NTLM
uses an encrypted challenge/response protocol to authenticate a user
without sending the user's password over the wire(in case there is a
wire). Instead, the system requesting authentication must perform a
calculation that proves it has access to the secured NTLM credentials.
Secure Channel, also known as Schannel, is a security support provider
(SSP) that contains a set of security protocols that provide identity
authentication and secure, private communication through encryption.
Mainly SSL and TLS, with a variety of cipher options.
Primary goals:
- Utilize wine secur32 as starting point for implementing SSPI.
- NTLM Security Support Provider (SSP)
-- Authentication
-- feature flags
-- SignMessage
-- VerifyMessage
-- EncryptMessage
-- DecryptMessage
- Small, low footprint, maintainable code
- Implement create credentials/logon/authentication in LSA
-- LogonUser
-- LsaConnectUntrusted
-- others, as necessary.
- Separate secur32 and schannel(wine has them unified)
Secondary goals:
- implement SSL/TLS/ptc SSP (using 3rd party libs)
-- GnuTLS, OpenSSL are huge and have many dependencies
-- secur32 is (theoretically) loaded and used by many system dlls,
would be very bad if it is a performance/memory hog.
-- Need to severely trim them down or use alternatives.
- run extensive tests/fix other system code paths that have been dormant/stubs
why wine secur32 is bad:
- Wine is a *nix program so its ok for them to use
dlopen(gnutls.so)... and use the system native library but we cant.
- Uses fork() to call a program in winbind(samba extra) package!
- if we want to use gnutls and such in reactos the following problems occur:
-- too many dependencies
-- problems running in native mode(lsa)
-- big footprint
-- too much code/hard to maintain
- Wine's implementation of schannel loads GnuTLS, and is barely functional.
- wine winhttp and wininet don't use schannel, and instead use OpenSSL
directly to implement SSL and TLS. This can lead to confusing
differences in certificate verification between applications. Ideally,
schannel would use crypt32 for certificate chain verification, and
winhttp and wininet would use schannel. (fixme later)
-- good news is, wine crypt32 is relatively good and feature complete
(at least seems that way).