I addressed my issue, and wanted to share my findings so that others can benefit.

My C code attempts to communicate with SqlServer 2005 EndPoint via Soap.
Thus, I needed to write a socket application that communicated on port 80 and handle the corresponding authentication. In my case the SqlServer 2005 Soap EndPoint utilizes NTLM.

Because I was dealing with so many components I was bound to have a bug some place.
I isolated my issue by changing from HTTP POST to SqlServer EndPoint, to HTTP GET to a “Hello World” ASP page. After validating that it worked properly, I then enabled NTLM authentication on that directory.

The webserver in question is Windows 2003 server, and I am using my workstation for running the client on a Windows XP professional. We are also dealing with default registry entries as outlined in The NTLM Authentication Protocol and Security Support Provider.
Meaning, the registry key LMCompatibilityLevel at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel is set to 0 and 2 for windows XP professional, and windows 2003 server, respectively.

As mentioned earlier, I was able to verify my function hashing values from examples found in above sources, however, I was unable to authenticate the application.
By utilizing Windows Network Monitor, I captured the traffic for a client that utilized MSXML2.ServerXMLHTTP and evaluated LM and NTLM response for message3.
Because both NTLM and LM responses were 24-bit (3 bytes), I was not sure if NTLMv1 or NTLMv2 was utilized. During my exploration, the evaluation of flags for message1, 2, and 3 were not very useful, because I was still unsure if NTLMv1 or NTLMv2 was being utilized.
I repeated the same experiment with FireFox, and found that only the first byte of LM was set while the remaining two bytes were zero. This lead me to conclusion that “NTLM2 Session Response” was utilized (The NTLM Authentication Protocol and Security Support Provider)
Once again, I utilized the challenge key from message2 (8 bytes key at offset 24), and the client challenge from message3 (8 bytes key set in beginning of LM response where the remaining 16 bytes are zeros) to test my own functions to insure the correct keys were being generated.

After I insured that I was able to mimic the request/response of FireFox, I turned to debugging my application, which addressed my original issue.

You may be interested to know that I was able to connect via NTLMv1 and “NTLM2 Session Response” by utilizing the following flags for my message1:
NEGOTIATE_UNICODE // 0x00000001
| NEGOTIATE_OEM // 0x00000002
| REQUEST_TARGET // 0x00000004
| NEGOTIATE_NTLM // 0x00000200
| NEGOTIATE_ALWAYS_SIGN // 0x00000010
| NEGOTIATE_NTLM2_KEY // 0x00080000 – ONLY for NLTM2 session response, otherwise remove this

Note that “NTLM2 Session Response” required the flag “NEGOTIATE_NTLM2_KEY”, and it was ommited for NTLMv1

Also, for message3 flags, I simply copied the flags that were returned by message2.

In conclusion, I have been able to connect with both NTLMv1 and “NTLM2 Session Response” to
a sample ASP page as well as SqlServer 2005 soap EndPoint that require NTLM authentication.

I hope this info will be helpful for someone else.
Best Regards,
Edvin Eshagh