Re: [ros-dev] SSPI and Interactive logon GSOC Proposal

[Gabriel ilardi]

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

>   Date: Tue, 29 Mar 2011 21:42:07 -0400
>  From: samdwise51(a)gmail.com
>  To: ros-dev(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev