Sounds cool, I'd love to see this implemented...

> Date: Tue, 29 Mar 2011 21:42:07 -0400
> From: samdwise51@gmail.com
> To: ros-dev@reactos.org
> Subject: [ros-dev] SSPI and Interactive logon GSOC Proposal
>
> 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).
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev