Our research showed that it is sufficient to support four authentication schemes: Basic, Digest, NTLM, and Negotiate. We already support Basic, Digest, and NTLM, and plan to add support for Negotiate.

The Basic and Digest schemes are specified in RFC 2617. NTLM is a Microsoft proprietary protocol. The Negotiate scheme is specified in RFC 4559 and can be used to negotiate either Kerberos or NTLM.

The remaining work is:

• support the Negotiate scheme. This needs to use GSS-API on Mac and Linux and SSPI on Windows.
• automatic logon to intranet sites when NTLM or Negotiate is used. This single-signon-like behavior is important to some users; to them, it is not NTLM without the automatic logon. We need to figure how to determine if a site is on the intranet, or enumerate the intranet sites in a preference as Firefox does.
• support NTLMv2.  Our portable NTLM code supports NTLMv1 only.

We created the authentication handler framework when we implemented the Basic and Digest authentication schemes. This framework needs to be extended to handle the NTLM and Negotiate schemes, which differ from the Basic and Digest schemes in a few aspects.

• The NTLM and Negotiate schemes are connection-based (Microsoft calls it session-based). The authentication consists of two rounds of requests and responses over a keep-alive connection. Then, additional requests can be made over that keep-alive connection without authentication.
• The authentication handlers for Basic and Digest can be shared by multiple transactions, so the handlers can be cached and reused for preemptive authentication. It is not clear whether the authentication handlers for NTLM and Negotiate can be shared because they seem to contain state specific to each transaction, and therefore we can't reuse cached handlers for NTLM and Negotiate.

When a server or proxy accepts multiple authentication schemes, our network stack selects the authentication scheme with the highest score:

• Basic: 1
• Digest: 2
• NTLM: 3
• Negotiate: 4 (proposed, not yet implemented)

The Basic scheme has the lowest score because it sends the username/password unencrypted to the server or proxy.

So we choose the most secure scheme, and we ignore the server or proxy's preference, indicated by the order in which the schemes are listed in the WWW-Authenticate or Proxy-Authenticate response headers. This could be a source of compatibility problems because MSDN documents that "WinInet chooses the first method it recognizes." Note: In IE7 or later, WinInet chooses the first non-Basic method it recognizes.

Since the Basic authentication scheme sends the username/password encrypted, we should warn users in the login dialog if we are going to perform Basic authentication over HTTP or to a proxy.