| NT Authentication over HTTP

This document outlines how to integrate Microsoft's user authentication protocol into standard HTTP authentication messages. This is useful for supporting secure browsing on Intranets based on Windows NT Domain Security and of the Microsoft Network Internet online service which is adopting this protocol in its Web services for MSN membership.

## 1.0 WWW-Authenticate

If authentication is required for a requested resource, then the HTTP server returns a 401 (unauthorized) response message. Section 10.17 of the HTTP/1.0 RFC defines the `WWW-Authenticate` response header which must be included in the 401 response message. Furthermore, the specification provides that multiple WWW-Authenticate response headers may be returned. This indicates that multiple authentication means are available and the client may choose one of them.

The HTTP/1.0 specification defines two kinds of authentication: (1) an "Access Authentication" scheme which allows for a very simple challenge-response; and (2) the "BASIC" authentication scheme where the username/password is sent over in cleartext to the server. Obviously, the latter provides weak security unless the channel is first link encrypted with SSL or PCT. Even with link encryption, Basic Authentication is inappropriate where it is unacceptable for servers to directly see users passwords such as corporate Intranets and Internet online services comprised of third-party sites.

Although only inferred, HTTP/1.0 does permit other authentication schemes by way of "WWW-Authenticate". This extensibility allows for the more complex MSN and NT challenge-response authentication mechanisms to be implemented.

### 1.1 WWW-Authenticate and NT Authentication

The NT challenge-response sequence is a bit more complicated than that provided by the simple challenge-response scheme in the HTTP/1.0 specification. This is due, in part, to the fact that the challenge is based on the username, thus requiring more than just a single challenge-response sequence.

If authentication is required for a requested resource and NT Authentication is enabled, the server will respond with a response header as follows:

    	WWW-Authenticate = "WWW-Authenticate" ":" "NTLM" SP ntlm-chaldata CRLF

    	ntlm-chaldata   = <base64  encoding of challenge data>

The tag "NTLM" signifies NT Authentication package. The `ntlm-chaldata` is not returned in the initial response header. The protocol details are described later in this document in the section NTLM Authentication Scheme.

### 1.2 WWW-Authenticate and MSN Authentication

In an MSN authentication environment, a `WWW-Authenticate` response header may indicate that MSN authentication is available. It will be formatted as follows:

    	WWW-Authenticate = "WWW-Authenticate" ":" "MSN" SP msn-chaldata CRLF

    	msn-chaldata     = <base64 encoding of challenge data>

The MSN authentication sequence is virtually identical to the NTLM authentication sequence and is described later in this document. The `msn-chaldata` is not returned in the initial response header.

### 1.3 Privacy and Challenge-Response Authentication

Although challenge-response authentication affords some measure of security against impersonation and password compromise, many schemes are not necessarily foolproof. The idea behind a challenge-response protocol is that the password in never actually sent over the network. User authentication in Windows NT and MSN uses the NTLM challenge-response protocol.

As computers become increasingly faster and cheaper, brute force attacks on challenge & response data will become easier. However, if the challenge/response data itself is encrypted, it helps to prevent snooping and insure better security. Microsoft recommends using SSL or PCT during the challenge/response sequence.

## 2.0 NT Authentication Components

In order to understand how to layer NT Authentication on HTTP, it is helpful to understand the run-time components that are involved in the process. The components (typically DLLs) and calling model may vary slightly depending on the platform and authentication server used.

### 2.1 Security Support Provider Interface (SSPI) Specification

SSPI is an API defined by Microsoft and provided for all versions of Windows since Windows NT 3.5. Designed to isolate Windows NT and custom applications from the underlying security implementation so new security packages such as Kerberos could be easily added in the future. Application developers can use this feature by calling SSPI directly or writing to Microsoft RPC which handles these calls as part of RPC's authentication support.

See the help file issp.hlp for information on the APIs.

### 2.2 NT-LAN Manager (NTLM) Security Support Provider (SSP) Specification

Currently the only security package that ships with Windows Operating Systems is NTLM (NT-LAN Manager), a shared secret user challenge-response authentication protocol that supports pass-through authentication to a domain controller in the servers domain or in a domain trusted by the current domain's domain controller. This is implemented in SECUR32.DLL on Windows 95 and SECURITY.DLL on Windows NT. The NTLM SSP exposes an SSPI interface, callable by the operating system and applications.

### 2.3 MSN Security Support Provider (SSP) Specification

To support pass-through authentication from distributed servers owned by MSN and partners, MSN uses the NTLM protocol. The messages are the same except instead of passing requests to a domain controller which checks NT's Security Accounts Manager (SAM) database, servers pass requests to agents in the MSN data center which check MSN's accounts database and mapped returned MSN security rights to Windows NT Groups so native NT ACLs can be used for enforcing privileges. The client SSP shipped in January, 1996 with MSN 1.2 and the server components will be deployed by MSN and key partners during 1996.

## 3.0 Browser Support

Given the wide variety of Web Browsers available and the growing use of Window NT Domain Security on Intranets and MSN on the Internet, it is important to corporations to have NT Authentication supported

To support new HTTP authentication packages, Spyglass defined the SPM API which has been adopted by the Microsoft Internet Explorer. Other Web browsers can support SPM API or call SSPI directly. Microsoft has shipped an SPM module as the layer between the SPM API and SSPI to support the NTLM and MSN authentication protocols. In addition this SPM module will take care of all future SSPI pkgs. as well. Additional SPM modules don't need to be written for every SSPI package in the future.

SPM is implemented in the file SEC_SSPI.DLL that first shipped with MSN 1.2 for use with Internet Explorer 2.0 on Windows 95 and is freely available.

Microsoft will be including SSPI and therefore NT and MSN authentication support in the HTTP protocol implementation being provided in the WinInet APIs that are planned for the future. Future versions of Internet Explorer will use this API. Client software vendors are encouraged to use WinInet as well to leverage the authenticated HTTP implementation. However, one can continue to develop their own HTTP protocol using the guidelines in this document and sample code for interfacing to SSPI.

### 3.1 HTTP Keep Alives

"Keep Alives" are a useful feature initiated by browsers to maintain the HTTP and TCP sessions to eliminate frequent session creation overhead such as re-authentication.

to the same server. Keep Alives are actually critical to support NTLM in HTTP so that the complete set of challenge-response message can be exchanged before the session is terminated. Keep-alive is requted with the `Connection: Keep-Alive` attribute in the HTTP message.

### 3.2 Multiple Browser Support

It is desirable to enable NT Authentication from a variety of web browsers. Many corporations already have internal NT networks set up, along with administrative procedures therein. By enabling NT authentication, departments can properly control access to sensitive data shared through web pages. In the public network environment, corporate employees (or selected customers) may be granted access to certain web pages which may not be available to the general public. In this latter case, it is especially desirable to avoid using the HTTP Basic authentication scheme. MSN will be using this protocol and encourages browser vendors to support it to provide users with choice.

## 4.0 NTLM Authentication Scheme

The following diagram illustrates the basic NT Authentication protocol used by both Windows NT and MSN:

Typically, the virtual circuit is closed after a 401 (unauthorized) response message. When negotiating an NT authentication sequence (which requires multiple round trips), the server keeps the virtual circuit open after the client has indicated that it wishes to use NTLM authentication. The circuit is kept open for the duration of the challenge-response sequence, and may be kept alive longer.

Note that `Connection: Keep-Alive` must be included in the initial as well as the subsequent HTTP operations. Without this, the server may not offer to negotiate NTLM authentication. Whenever a virtual circuit is closed, authentication is lost. At this time, every individual virtual circuit must negotiate the authentication sequence.

Note that HTTP imposes a character count limit on the challenge and challenge-response data. Furthermore, the data is always uuencoded. This also necessitates several round trips (and is something that should be addressed in a future version of HTTP).

### 4.1 Sample Code

In order to better illustrate the protocol sequence, sample source code is included. The sample code will be an NT Command Line application which illustrates a simple HTTP "GET" operation. If NTLM authentication is indicated in the 401 response message from the server, then the sequence is negotiated. Otherwise, the application fails, indicating that NTLM authentication was not available. "Basic" authentication is not negotiated by the sample application.

The sample code is in Microsoft Visual C++ 4.0 and includes the appropriate make and header files. The code buils into a very simple program which allows the user to see the negotiated HTTP headers. The command line syntax is:

    	httpauth  [-h] [-d:<size>] [-m:<methodlist>] [-v:<verb>] [-n:<username>]
    	          [-p:<password>] [-g:gateway] [-s:storefile] <server> <path>
    		-h           - display result headers
    		<size>       - amount of client data to send
    		<verb>       - HTTP verb to use (default is GET)
    		<username>   - user name for authentication
    		<password>   - password for authentication
    		<methodlist> - comma separated list of authentication methods in order
    		               of preference (Default is to use first supported method
    		               returned by the HTTP server (e.g., -m:NTLM,BASIC)
    		<storefile>  - file where to store result message body
    		<server>     - web server to connect to (without http:)
    		<path>       - resource to get (e.g., /default.htm)

For example, the following command line retrieves the headers for http://www.server.com/doc/info.html:

    	httpget -h -m:NTLM,BASIC -v:GET -n:GUEST -p:GUEST www.server.com /doc/info.html

This command will produce the following approximate header output (assuming that the server does not allow anonymous login):

    	HTTP/1.0 401 Access Denied
    	WWW-Authenticate: Basic
    	WWW-Authenticate: NTLM
    	Content-Length: 24

    	HTTP/1.0 401 Access Denied
    	WWW-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAACgAAAABggAA0BYwmlRObo4AAAAAAAAAAA==
    	Connection: keep-alive
    	Content-Length: 24

    	HTTP/1.0 200 OK
    	Date: Tue, 27 Feb 1996 19:31:49 GMT
    	Server: Microsoft-Internet-Information-Server/1.0
    	Connection: keep-alive
    	Content-Type: text/html
    	Last-Modified: Tue, 27 Feb 1996 01:41:56 GMT
    	Content-Length: 5177

The source code is provided for reference to illustrate how a web browser would negotiate NT Authentication. An executable version for Intel platforms is included.

The include files sspi.h and issperr.h are from the Win-32 SDK, but are included for your convenience. The sample is provided "as-is".

## 5.0 Notes

1. When "BASIC" Authentication is negotiated with the Microsoft Internet Informatuion Server, the authenticated user is treated as if he or she logged on locally (meaning that as far as NT Security is concerned, the web user has the appearance of being logged in locally rather than being logged in as a "network" User).
2. If an invalid username is supplied in the NT Authentication sequence, the server will try to use the account "Guest" with no password to gain access to the resource. This occurs only with "NTLM" authentication and not "Basic" authentication. System administrators can do the following: (a) disable the Guest account; (b) give the Guest account a non-null password; or (c) set ACLs on the \wwwroot directory and file resources.