Sounds cool, I'd love to see this implemented...
> Date: Tue, 29 Mar 2011 21:42:07 -0400 > From: [email protected] > To: [email protected] > 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 > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
