Go go go go!! We´ll buy you a ticket to fly anywhere outside your island as prize :P
On Wed, Mar 30, 2011 at 9:16 AM, Gabriel ilardi <[email protected]>wrote: > 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 >
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
