The NTLM Authentication Protocol and Security Support Provider

This article seeks to describe the NTLM authentication protocol and related security support provider functionality at an intermediate to advanced level of detail, suitable as a reference for implementors. It is hoped that this document will evolve into a comprehensive description of NTLM; at this time there are omissions, both in the author's knowledge and in his documentation, and almost certainly inaccuracies. However, this document should at least be able to provide a solid foundation for further research. The information presented herein was used as the basis for the implementation of NTLM authentication in the open-source jCIFS library, available at http://jcifs.samba.org. This documentation is based on independent research by the author and analysis of functionality implemented in the Samba software suite.

NTLM Terminology

The NTLM Message Header Layout

The NTLM Flags

Flag	Name	Description
`0x00000001`	Negotiate Unicode	Indicates that Unicode strings are supported for use in security buffer data.
`0x00000002`	Negotiate OEM	Indicates that OEM strings are supported for use in security buffer data.
`0x00000004`	Request Target	Requests that the server's authentication realm be included in the Type 2 message.
`0x00000008`	unknown	This flag's usage has not been identified.
`0x00000010`	Negotiate Sign	Specifies that authenticated communication between the client and server should carry a digital signature (message integrity).
`0x00000020`	Negotiate Seal	Specifies that authenticated communication between the client and server should be encrypted (message confidentiality).
`0x00000040`	Negotiate Datagram Style	Indicates that datagram authentication is being used.
`0x00000080`	Negotiate Lan Manager Key	Indicates that the Lan Manager Session Key should be used for signing and sealing authenticated communications.
`0x00000100`	Negotiate Netware	This flag's usage has not been identified.
`0x00000200`	Negotiate NTLM	Indicates that NTLM authentication is being used.
`0x00000400`	unknown	This flag's usage has not been identified.
`0x00000800`	Negotiate Anonymous	Sent by the client in the Type 3 message to indicate that an anonymous context has been established. This also affects the response fields (as detailed in the "Anonymous Response" section).
`0x00001000`	Negotiate Domain Supplied	Sent by the client in the Type 1 message to indicate that the name of the domain in which the client workstation has membership is included in the message. This is used by the server to determine whether the client is eligible for local authentication.
`0x00002000`	Negotiate Workstation Supplied	Sent by the client in the Type 1 message to indicate that the client workstation's name is included in the message. This is used by the server to determine whether the client is eligible for local authentication.
`0x00004000`	Negotiate Local Call	Sent by the server to indicate that the server and client are on the same machine. Implies that the client may use the established local credentials for authentication instead of calculating a response to the challenge.
`0x00008000`	Negotiate Always Sign	Indicates that authenticated communication between the client and server should be signed with a "dummy" signature.
`0x00010000`	Target Type Domain	Sent by the server in the Type 2 message to indicate that the target authentication realm is a domain.
`0x00020000`	Target Type Server	Sent by the server in the Type 2 message to indicate that the target authentication realm is a server.
`0x00040000`	Target Type Share	Sent by the server in the Type 2 message to indicate that the target authentication realm is a share. Presumably, this is for share-level authentication. Usage is unclear.
`0x00080000`	Negotiate NTLM2 Key	Indicates that the NTLM2 signing and sealing scheme should be used for protecting authenticated communications. Note that this refers to a particular session security scheme, and is not related to the use of NTLMv2 authentication. This flag can, however, have an effect on the response calculations (as detailed in the "NTLM2 Session Response" section).
`0x00100000`	Request Init Response	This flag's usage has not been identified.
`0x00200000`	Request Accept Response	This flag's usage has not been identified.
`0x00400000`	Request Non-NT Session Key	This flag's usage has not been identified.
`0x00800000`	Negotiate Target Info	Sent by the server in the Type 2 message to indicate that it is including a Target Information block in the message. The Target Information block is used in the calculation of the NTLMv2 response.
`0x01000000`	unknown	This flag's usage has not been identified.
`0x02000000`	unknown	This flag's usage has not been identified.
`0x04000000`	unknown	This flag's usage has not been identified.
`0x08000000`	unknown	This flag's usage has not been identified.
`0x10000000`	unknown	This flag's usage has not been identified.
`0x20000000`	Negotiate 128	Indicates that 128-bit encryption is supported.
`0x40000000`	Negotiate Key Exchange	Indicates that the client will provide an encrypted master key in the "Session Key" field of the Type 3 message.
`0x80000000`	Negotiate 56	Indicates that 56-bit encryption is supported.

The Type 1 Message

	Description	Content
0	NTLMSSP Signature	Null-terminated ASCII "NTLMSSP" (`0x4e544c4d53535000`)
8	NTLM Message Type	`long` (`0x01000000`)
12	Flags	`long`
(16)	Supplied Domain (Optional)	security buffer
(24)	Supplied Workstation (Optional)	security buffer
(32)	OS Version Structure (Optional)	8 bytes
(32) (40)	start of data block (if required)

	Description	Content
0	Major Version Number	1 byte
1	Minor Version Number	1 byte
2	Build Number	`short`
4	Unknown	`0x0000000f`

This is a "Version 1" Type 1 message containing only the NTLMSSP signature, the NTLM message type, and the minimal set of flags (Negotiate NTLM and Negotiate OEM).

Type 1 Message Example

The Type 2 Message

	Description	Content
0	NTLMSSP Signature	Null-terminated ASCII "NTLMSSP" (`0x4e544c4d53535000`)
8	NTLM Message Type	`long` (`0x02000000`)
12	Target Name	security buffer
20	Flags	`long`
24	Challenge	8 bytes
(32)	Context (optional)	8 bytes (two consecutive `long`s)
(40)	Target Information (optional)	security buffer
(48)	OS Version Structure (Optional)	8 bytes
32 (48) (56)	start of data block

The target information is a security buffer containing a Target Information block, which is used in calculating the NTLMv2 response (discussed later). This is composed of a sequence of subblocks, each consisting of:

Field Content Description

Type

short

Indicates the type of data in this subblock:

1 (`0x0100`):	Server name
2 (`0x0200`):	Domain name
3 (`0x0300`):	Fully-qualified DNS host name (i.e., `server.domain.com`)
4 (`0x0400`):	DNS domain name (i.e., `domain.com`)

Length short Length in bytes of this subblock's content field

Content Unicode string Content as indicated by the type field. Always sent in Unicode, even when OEM is indicated by the message flags.

The sequence is terminated by a terminator subblock; this is a subblock of type "0", of zero length. Subblocks of type "5" have also been encountered, apparently containing the "parent" DNS domain for servers in subdomains; it may be that there are other as-yet-unidentified subblock types as well.

As with the Type 1 message, there are a few versions of the Type 2 that have been observed:

This message contains the NTLMSSP signature, the NTLM message type, an empty target name, minimal flags (Negotiate NTLM and Negotiate OEM), and the challenge.

Type 2 Message Example

The Type 3 Message

The LM/LMv2 and NTLM/NTLMv2 responses are security buffers containing replies created from the user's password in response to the Type 2 challenge; the process for generating these responses is outlined in the next section.

The target name is a security buffer containing the authentication realm in which the authenticating account has membership (a domain name for domain accounts, or server name for local machine accounts). This is either Unicode or OEM, depending on the negotiated encoding.

The user name is a security buffer containing the authenticating account name. This is either Unicode or OEM, depending on the negotiated encoding.

The workstation name is a security buffer containing the client workstation's name. This is either Unicode or OEM, depending on the negotiated encoding.

	Description	Content
0	NTLMSSP Signature	Null-terminated ASCII "NTLMSSP" (`0x4e544c4d53535000`)
8	NTLM Message Type	`long` (`0x03000000`)
12	LM/LMv2 Response	security buffer
20	NTLM/NTLMv2 Response	security buffer
28	Target Name	security buffer
36	User Name	security buffer
44	Workstation Name	security buffer
(52)	Session Key (optional)	security buffer
(60)	Flags (optional)	`long`
(64)	OS Version Structure (Optional)	8 bytes
52 (64) (72)	start of data block

The session key value is used by the session security mechanism during key exchange; this is discussed in more detail in the Session Security section.

When "Negotiate Local Call" has been established in the Type 2 message, the security buffers in the Type 3 message are typically all empty (zero length). The client "adopts" the SSPI context sent in the Type 2 message, effectively circumventing the need to calculate an appropriate response.

Format	Type 3 Field Content	Notes
`DOMAIN\user`	User Name = "`user`" Target Name = "`DOMAIN`"	This is the "normal" format; the User Name field contains the Windows user name, and the Target Name contains the NT-style NetBIOS domain or server name.
`domain.com\user`	User Name = "`user`" Target Name = "`domain.com`"	Here, the Target Name field in the Type 3 message is populated with the DNS domain/realm name (or fully-qualified DNS host name in the case of local machine accounts).
`user@DOMAIN`	User Name = "`user@DOMAIN`" Target Name is empty	In this case, the Target Name field is empty (zero-length), and the User Name field uses the Kerberos-style "user@realm" format; however, the NetBIOS domain name is used instead of the DNS domain. It has been observed that this format is not supported for local machine accounts; additionally, this form does not appear to be supported under NTLMv2/LMv2 authentication.
`user@domain.com`	User Name = "`user@domain.com`" Target Name is empty	Here, the Target Name field in the Type 3 message is empty; the User Name field contains the Kerberos-style "user@realm" format, with the DNS domain. This form does not appear to be supported for local machine accounts.

Responding to the Challenge

The responses serve as an indirect proof of knowledge of the password. The password is used by the client to derive the LM and/or NTLM hash (discussed in the next section); these values are in turn used to calculate an appropriate response to the challenge. The domain controller (or server for local machine accounts) stores the LM and NTLM hashes for the password; when the response is received from the client, these stored values are used to calculate the appropriate response values which are compared to those sent by the client. A match yields a successful authentication of the user.

Note that unlike Unix password hashes, the LM and NTLM hash are password-equivalents in the context of the response calculations; they must be protected, as they can be used to authenticate users across the network even without knowledge of the actual password itself.

The LM Response

In the event that the user's password is longer than 15 characters, the host or domain controller will not store the LM hash for the user; the LM response cannot be used to authenticate the user in this case. A response is still generated and placed in the LM Response field, using a 16-byte null value (0x00000000000000000000000000000000) as the LM hash in the calculation. This value is ignored by the target.

The response calculation process is best illustrated with a detailed example. Consider a user with the password "SecREt01", responding to the Type 2 challenge "0x0123456789abcdef".

There are several weaknesses in this algorithm which make it susceptible to attack. While these are covered in detail in the Hertel text, the most prominent problems are:

Note that only the calculation of the hash value differs from the LM scheme; the response calculation is the same. To illustrate this process, we will apply it to our previous example (a user with the password "SecREt01", responding to the Type 2 challenge "0x0123456789abcdef").

Let's look at an example. Since we need a bit more information to calculate the NTLMv2 response, we will use the following values from the examples presented previously:

	Description	Content
0	Blob Signature	`0x01010000`
4	Reserved	`long` (`0x00000000`)
8	Timestamp	Little-endian, 64-bit signed value representing the number of tenths of a microsecond since January 1, 1601.
16	Client Nonce	8 bytes
24	Unknown	4 bytes
28	Target Information	Target Information block (from the Type 2 message).
(variable)	Unknown	4 bytes

Target:	`DOMAIN`
Username:	`user`
Password:	`SecREt01`
Challenge:	`0x0123456789abcdef`
Target Information:	0x02000c0044004f00 4d00410049004e00 01000c0053004500 5200560045005200 0400140064006f00 6d00610069006e00 2e0063006f006d00 0300220073006500 7200760065007200 2e0064006f006d00 610069006e002e00 63006f006d000000 0000

We will illustrate this process with a brief example using our tried-and-true sample values:

Target:	`DOMAIN`
Username:	`user`
Password:	`SecREt01`
Challenge:	`0x0123456789abcdef`

To demonstrate this with our previous example values (a user with the password "SecREt01", responding to the Type 2 challenge "0x0123456789abcdef"):

Type 3 Message Example

NTLM Version 2

(LMCompatibility on Win9x-based systems). This is a REG_DWORD entry, and can be set to one of the following values:

Level	Sent by Client	Accepted by Server
0	LM NTLM	LM NTLM LMv2 NTLMv2
1	LM NTLM	LM NTLM LMv2 NTLMv2
2	NTLM	LM NTLM LMv2 NTLMv2
3	LMv2 NTLMv2	LM NTLM LMv2 NTLMv2
4	LMv2 NTLMv2	NTLM LMv2 NTLMv2
5	LMv2 NTLMv2	LMv2 NTLMv2

In all levels, NTLM2 session security is supported and negotiated when available (most available documentation indicates that NTLM2 session security is only enabled on levels 1 and above, but it is seen in practice with Level 0 as well). By default, only the LM response is supported on Windows 95 and Windows 98 platforms; installing the Directory Services client makes NTLMv2 available on these hosts as well (and enables the LMCompatibility setting, although only levels 0 and 3 are available).

In Level 2, clients send the NTLM response twice (in both the LM and NTLM response fields). At Level 3 and higher, the LMv2 and NTLMv2 responses replace the LM and NTLM responses, respectively.

When NTLM2 session security has been negotiated (indicated by the "Negotiate NTLM2 Key" flag), the NTLM2 session response can be used in Levels 0, 1, and 2 as a replacement for the weaker LM and NTLM responses. This offers heightened protection over NTLMv1 against server-based precomputed dictionary attacks; the client's response to a given challenge is made variable by adding a random client nonce to the calculation.

The NTLM2 session response is interesting in that it can be negotiated between a client and server that support the newer schemes, even in the presence of an older domain controller that does not. In a typical scenario, the server in an authentication transaction does not actually possess the user's password hash; that is instead held at the domain controller. When a machine is joined to an NT-style domain, it establishes an encrypted, mutually-authenticated channel to the domain controller (colloquially deemed the "NetLogon pipe"). When a client authenticates to the server using the "vanilla" NTLMv1 handshake, the following transactions occur in the background:

In the case of the NTLM2 Session Response, it is possible that a client and server have been upgraded to allow the newer protocol, but the domain controller has not. To allow for this contingency, the handshake described above is modified slightly as follows:

Essentially, this allows upgraded clients and servers to use the NTLM2 Session Response in networks where the domain controller has not yet been upgraded to NTLMv2 (or where the network administrator has not yet configured the LMCompatibilityLevel registry setting to use NTLMv2).

Related to the LMCompatibilityLevel setting are the NtlmMinClientSec and NtlmMinServerSec settings; these specify minimum requirements for NTLM contexts established by the NTLMSSP. Both are REG_WORD entries, and are bitfields specifying a combination of the following NTLM flags:

Windows provides a security framework known as SSPI - the Security Support Provider interface. This is the Microsoft equivalent of the GSS-API (Generic Security Service Application Program Interface, RFC 2743), and allows for a very high-level, mechanism-independent means of applying authentication, integrity, and confidentiality primitives. SSPI supports several underlying providers; one of these is the NTLMSSP (NTLM Security Support Provider), which provides the NTLM authentication mechanism we have been discussing thus far. SSPI supplies a flexible API for handling opaque, provider-specific authentication tokens; the NTLM Type 1, Type 2, and Type 3 messages are such tokens, specific to and processed by the NTLMSSP. The API provided by SSPI abstracts away almost all the details of NTLM. The application developer doesn't even have to be aware that NTLM is being used, and another authentication mechanism (such as Kerberos) can be swapped in with little or no changes at the application level.

We aren't going to delve too deeply into the SSPI framework, but this is a good point to look at the SSPI authentication handshake as applied to NTLM:

Session Security - Signing & Sealing Concepts

The User Session Key

The NTLM User Session Key

The LMv2 User Session Key

The NTLMv2 User Session Key

The NTLM2 Session Response User Session Key

The Null User Session Key

The Lan Manager Session Key

Key Exchange

Key Weakening

NTLM1 Session Security

NTLM POP3 Authentication

The POP3 NTLM authentication handshake occurs during the POP3 "authorization" state, and works as follows:

After successful authentication has occurred, the POP3 session enters the "transaction" state, allowing messages to be retrieved by the client.

NTLM IMAP Authentication

Appendix C: Sample NTLMSSP Operation Decompositions

NTLMv1 Authentication; NTLM1 Signing and Sealing Using the NTLM User Session Key

import java.security.Key;
import java.security.MessageDigest;

import javax.crypto.Cipher;

import javax.crypto.spec.SecretKeySpec;

/**
 * Calculates the various Type 3 responses.
 */
public class Responses {

    /**
     * Calculates the LM Response for the given challenge, using the specified
     * password.
     *
     * @param password The user's password.
     * @param challenge The Type 2 challenge from the server.
     *
     * @return The LM Response.
     */
    public static byte[] getLMResponse(String password, byte[] challenge)
            throws Exception {
        byte[] lmHash = lmHash(password);
        return lmResponse(lmHash, challenge);
    }

    /**
     * Calculates the NTLM Response for the given challenge, using the
     * specified password.
     *
     * @param password The user's password.
     * @param challenge The Type 2 challenge from the server.
     *
     * @return The NTLM Response.
     */
    public static byte[] getNTLMResponse(String password, byte[] challenge)
            throws Exception {
        byte[] ntlmHash = ntlmHash(password);
        return lmResponse(ntlmHash, challenge);
    }

    /**
     * Calculates the NTLMv2 Response for the given challenge, using the
     * specified authentication target, username, password, target information
     * block, and client nonce.
     *
     * @param target The authentication target (i.e., domain).
     * @param user The username. 
     * @param password The user's password.
     * @param targetInformation The target information block from the Type 2
     * message.
     * @param challenge The Type 2 challenge from the server.
     * @param clientNonce The random 8-byte client nonce. 
     *
     * @return The NTLMv2 Response.
     */
    public static byte[] getNTLMv2Response(String target, String user,
            String password, byte[] targetInformation, byte[] challenge,
                    byte[] clientNonce) throws Exception {
        byte[] ntlmv2Hash = ntlmv2Hash(target, user, password);
        byte[] blob = createBlob(targetInformation, clientNonce);
        return lmv2Response(ntlmv2Hash, blob, challenge);
    }

    /**
     * Calculates the LMv2 Response for the given challenge, using the
     * specified authentication target, username, password, and client
     * challenge.
     *
     * @param target The authentication target (i.e., domain).
     * @param user The username.
     * @param password The user's password.
     * @param challenge The Type 2 challenge from the server.
     * @param clientNonce The random 8-byte client nonce.
     *
     * @return The LMv2 Response. 
     */
    public static byte[] getLMv2Response(String target, String user,
            String password, byte[] challenge, byte[] clientNonce)
                    throws Exception {
        byte[] ntlmv2Hash = ntlmv2Hash(target, user, password);
        return lmv2Response(ntlmv2Hash, clientNonce, challenge);
    }

    /**
     * Calculates the NTLM2 Session Response for the given challenge, using the
     * specified password and client nonce.
     *
     * @param password The user's password.
     * @param challenge The Type 2 challenge from the server.
     * @param clientNonce The random 8-byte client nonce.
     *
     * @return The NTLM2 Session Response.  This is placed in the NTLM
     * response field of the Type 3 message; the LM response field contains
     * the client nonce, null-padded to 24 bytes.
     */
    public static byte[] getNTLM2SessionResponse(String password,
            byte[] challenge, byte[] clientNonce) throws Exception {
        byte[] ntlmHash = ntlmHash(password);
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        md5.update(challenge);
        md5.update(clientNonce);
        byte[] sessionHash = new byte[8];
        System.arraycopy(md5.digest(), 0, sessionHash, 0, 8);
        return lmResponse(ntlmHash, sessionHash);
    }

    /**
     * Creates the LM Hash of the user's password.
     *
     * @param password The password.
     *
     * @return The LM Hash of the given password, used in the calculation
     * of the LM Response.
     */
    private static byte[] lmHash(String password) throws Exception {
        byte[] oemPassword = password.toUpperCase().getBytes("US-ASCII");
        int length = Math.min(oemPassword.length, 14);
        byte[] keyBytes = new byte[14];
        System.arraycopy(oemPassword, 0, keyBytes, 0, length);
        Key lowKey = createDESKey(keyBytes, 0);
        Key highKey = createDESKey(keyBytes, 7);
        byte[] magicConstant = "KGS!@#$%".getBytes("US-ASCII");
        Cipher des = Cipher.getInstance("DES/ECB/NoPadding");
        des.init(Cipher.ENCRYPT_MODE, lowKey);
        byte[] lowHash = des.doFinal(magicConstant);
        des.init(Cipher.ENCRYPT_MODE, highKey);
        byte[] highHash = des.doFinal(magicConstant);
        byte[] lmHash = new byte[16];
        System.arraycopy(lowHash, 0, lmHash, 0, 8);
        System.arraycopy(highHash, 0, lmHash, 8, 8);
        return lmHash;
    }

    /**
     * Creates the NTLM Hash of the user's password.
     *
     * @param password The password.
     *
     * @return The NTLM Hash of the given password, used in the calculation
     * of the NTLM Response and the NTLMv2 and LMv2 Hashes.
     */
    private static byte[] ntlmHash(String password) throws Exception {
        byte[] unicodePassword = password.getBytes("UnicodeLittleUnmarked");
        MessageDigest md4 = MessageDigest.getInstance("MD4");
        return md4.digest(unicodePassword);
    }

    /**
     * Creates the NTLMv2 Hash of the user's password.
     *
     * @param target The authentication target (i.e., domain).
     * @param user The username.
     * @param password The password.
     *
     * @return The NTLMv2 Hash, used in the calculation of the NTLMv2
     * and LMv2 Responses. 
     */
    private static byte[] ntlmv2Hash(String target, String user,
            String password) throws Exception {
        byte[] ntlmHash = ntlmHash(password);
        String identity = user.toUpperCase() + target;
        return hmacMD5(identity.getBytes("UnicodeLittleUnmarked"), ntlmHash);
    }

    /**
     * Creates the LM Response from the given hash and Type 2 challenge.
     *
     * @param hash The LM or NTLM Hash.
     * @param challenge The server challenge from the Type 2 message.
     *
     * @return The response (either LM or NTLM, depending on the provided
     * hash).
     */
    private static byte[] lmResponse(byte[] hash, byte[] challenge)
            throws Exception {
        byte[] keyBytes = new byte[21];
        System.arraycopy(hash, 0, keyBytes, 0, 16);
        Key lowKey = createDESKey(keyBytes, 0);
        Key middleKey = createDESKey(keyBytes, 7);
        Key highKey = createDESKey(keyBytes, 14);
        Cipher des = Cipher.getInstance("DES/ECB/NoPadding");
        des.init(Cipher.ENCRYPT_MODE, lowKey);
        byte[] lowResponse = des.doFinal(challenge);
        des.init(Cipher.ENCRYPT_MODE, middleKey);
        byte[] middleResponse = des.doFinal(challenge);
        des.init(Cipher.ENCRYPT_MODE, highKey);
        byte[] highResponse = des.doFinal(challenge);
        byte[] lmResponse = new byte[24];
        System.arraycopy(lowResponse, 0, lmResponse, 0, 8);
        System.arraycopy(middleResponse, 0, lmResponse, 8, 8);
        System.arraycopy(highResponse, 0, lmResponse, 16, 8);
        return lmResponse;
    }

    /**
     * Creates the LMv2 Response from the given hash, client data, and
     * Type 2 challenge.
     *
     * @param hash The NTLMv2 Hash.
     * @param clientData The client data (blob or client nonce).
     * @param challenge The server challenge from the Type 2 message.
     *
     * @return The response (either NTLMv2 or LMv2, depending on the
     * client data).
     */
    private static byte[] lmv2Response(byte[] hash, byte[] clientData,
            byte[] challenge) throws Exception {
        byte[] data = new byte[challenge.length + clientData.length];
        System.arraycopy(challenge, 0, data, 0, challenge.length);
        System.arraycopy(clientData, 0, data, challenge.length,
                         clientData.length);
        byte[] mac = hmacMD5(data, hash);
        byte[] lmv2Response = new byte[mac.length + clientData.length];
        System.arraycopy(mac, 0, lmv2Response, 0, mac.length);
        System.arraycopy(clientData, 0, lmv2Response, mac.length,
                         clientData.length);
        return lmv2Response;
    }

    /**
     * Creates the NTLMv2 blob from the given target information block and
     * client nonce.
     *
     * @param targetInformation The target information block from the Type 2
     * message.
     * @param clientNonce The random 8-byte client nonce.
     *
     * @return The blob, used in the calculation of the NTLMv2 Response.
     */
    private static byte[] createBlob(byte[] targetInformation,
            byte[] clientNonce) {
        byte[] blobSignature = new byte[] {
            (byte) 0x01, (byte) 0x01, (byte) 0x00, (byte) 0x00
        };
        byte[] reserved = new byte[] {
            (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00
        };
        byte[] unknown1 = new byte[] {
            (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00
        };
        byte[] unknown2 = new byte[] {
            (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00
        };
        long time = System.currentTimeMillis();
        time += 11644473600000l; // milliseconds from January 1, 1601 -> epoch.
        time *= 10000; // tenths of a microsecond.
        // convert to little-endian byte array.
        byte[] timestamp = new byte[8];
        for (int i = 0; i < 8; i++) {
            timestamp[i] = (byte) time;
            time >>>= 8;
        }
        byte[] blob = new byte[blobSignature.length + reserved.length +
                               timestamp.length + clientNonce.length +
                               unknown1.length + targetInformation.length +
                               unknown2.length];
        int offset = 0;
        System.arraycopy(blobSignature, 0, blob, offset, blobSignature.length);
        offset += blobSignature.length;
        System.arraycopy(reserved, 0, blob, offset, reserved.length);
        offset += reserved.length;
        System.arraycopy(timestamp, 0, blob, offset, timestamp.length);
        offset += timestamp.length;
        System.arraycopy(clientNonce, 0, blob, offset,
                         clientNonce.length);
        offset += clientNonce.length;
        System.arraycopy(unknown1, 0, blob, offset, unknown1.length);
        offset += unknown1.length;
        System.arraycopy(targetInformation, 0, blob, offset,
                         targetInformation.length);
        offset += targetInformation.length;
        System.arraycopy(unknown2, 0, blob, offset, unknown2.length);
        return blob;
    }

    /**
     * Calculates the HMAC-MD5 hash of the given data using the specified
     * hashing key.
     *
     * @param data The data for which the hash will be calculated. 
     * @param key The hashing key.
     *
     * @return The HMAC-MD5 hash of the given data.
     */
    private static byte[] hmacMD5(byte[] data, byte[] key) throws Exception {
        byte[] ipad = new byte[64];
        byte[] opad = new byte[64];
        for (int i = 0; i < 64; i++) {
            ipad[i] = (byte) 0x36;
            opad[i] = (byte) 0x5c;
        }
        for (int i = key.length - 1; i >= 0; i--) {
            ipad[i] ^= key[i];
            opad[i] ^= key[i];
        }
        byte[] content = new byte[data.length + 64];
        System.arraycopy(ipad, 0, content, 0, 64);
        System.arraycopy(data, 0, content, 64, data.length);
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        data = md5.digest(content);
        content = new byte[data.length + 64];
        System.arraycopy(opad, 0, content, 0, 64);
        System.arraycopy(data, 0, content, 64, data.length);
        return md5.digest(content);
    }

    /**
     * Creates a DES encryption key from the given key material.
     *
     * @param bytes A byte array containing the DES key material.
     * @param offset The offset in the given byte array at which
     * the 7-byte key material starts.
     *
     * @return A DES encryption key created from the key material
     * starting at the specified offset in the given byte array.
     */
    private static Key createDESKey(byte[] bytes, int offset) {
        byte[] keyBytes = new byte[7];
        System.arraycopy(bytes, offset, keyBytes, 0, 7);
        byte[] material = new byte[8];
        material[0] = keyBytes[0];
        material[1] = (byte) (keyBytes[0] << 7 | (keyBytes[1] & 0xff) >>> 1);
        material[2] = (byte) (keyBytes[1] << 6 | (keyBytes[2] & 0xff) >>> 2);
        material[3] = (byte) (keyBytes[2] << 5 | (keyBytes[3] & 0xff) >>> 3);
        material[4] = (byte) (keyBytes[3] << 4 | (keyBytes[4] & 0xff) >>> 4);
        material[5] = (byte) (keyBytes[4] << 3 | (keyBytes[5] & 0xff) >>> 5);
        material[6] = (byte) (keyBytes[5] << 2 | (keyBytes[6] & 0xff) >>> 6);
        material[7] = (byte) (keyBytes[6] << 1);
        oddParity(material);
        return new SecretKeySpec(material, "DES");
    }

    /**
     * Applies odd parity to the given byte array.
     *
     * @param bytes The data whose parity bits are to be adjusted for
     * odd parity.
     */
    private static void oddParity(byte[] bytes) {
        for (int i = 0; i < bytes.length; i++) {
            byte b = bytes[i];
            boolean needsParity = (((b >>> 7) ^ (b >>> 6) ^ (b >>> 5) ^
                                    (b >>> 4) ^ (b >>> 3) ^ (b >>> 2) ^
                                    (b >>> 1)) & 0x01) == 0;
            if (needsParity) {
                bytes[i] |= (byte) 0x01;
            } else {
                bytes[i] &= (byte) 0xfe;
            }
        }
    }

}

Negotiate Unicode (`0x00000001`)	The client sets this flag to indicate that it supports Unicode strings.
Negotiate OEM (`0x00000002`)	This is set to indicate that the client supports OEM strings.
Request Target (`0x00000004`)	This requests that the server send the authentication target with the Type 2 reply.
Negotiate NTLM (`0x00000200`)	Indicates that NTLM authentication is supported.
Negotiate Domain Supplied (`0x00001000`)	When set, the client will send with the message the name of the domain in which the workstation has membership.
Negotiate Workstation Supplied (`0x00002000`)	Indicates that the client is sending its workstation name with the message.
Negotiate Always Sign (`0x00008000`)	Indicates that communication between the client and server after authentication should carry a "dummy" signature.
Negotiate NTLM2 Key (`0x00080000`)	Indicates that this client supports the NTLM2 signing and sealing scheme; if negotiated, this can also affect the response calculations.
Negotiate 128 (`0x20000000`)	Indicates that this client supports strong (128-bit) encryption.
Negotiate 56 (`0x80000000`)	Indicates that this client supports medium (56-bit) encryption.

`0x05`	(major version 5)
`0x01`	(minor version 1; Windows XP)
`0x280a`	(build number 2600 in hexadecimal little-endian)
`0x0000000f`	(unknown/reserved)

0	`0x4e544c4d53535000`	NTLMSSP Signature
8	`0x01000000`	Type 1 Indicator
12	`0x07320000`	Flags: Negotiate Unicode (`0x00000001`) Negotiate OEM (`0x00000002`) Request Target (`0x00000004`) Negotiate NTLM (`0x00000200`) Negotiate Domain Supplied (`0x00001000`) Negotiate Workstation Supplied (`0x00002000`)
16	`0x0600060033000000`	Supplied Domain Security Buffer: Length: 6 bytes (`0x0600`) Allocated Space: 6 bytes (`0x0600`) Offset: 51 bytes (`0x33000000`)
24	`0x0b000b0028000000`	Supplied Workstation Security Buffer: Length: 11 bytes (`0x0b00`) Allocated Space: 11 bytes (`0x0b00`) Offset: 40 bytes (`0x28000000`)
32	`0x050093080000000f`	OS Version Structure: Major Version: 5 (`0x05`) Minor Version: 0 (`0x00`) Build Number: 2195 (`0x9308`) Unknown/Reserved (`0x0000000f`)
40	`0x574f524b53544154494f4e`	Supplied Workstation Data ("`WORKSTATION`")
51	`0x444f4d41494e`	Supplied Domain Data ("`DOMAIN`")

Negotiate Unicode (`0x00000001`)	The server sets this flag to indicate that it will be using Unicode strings. This should only be set if the client indicates (in the Type 1 message) that it supports Unicode. Either this flag or Negotiate OEM should be set, but not both.
Negotiate OEM (`0x00000002`)	This flag is set to indicate that the server will be using OEM strings. This should only be set if the client indicates (in the Type 1 message) that it will support OEM strings. Either this flag or Negotiate Unicode should be set, but not both.
Request Target (`0x00000004`)	This flag is often set in the Type 2 message; while it has a well-defined meaning within the Type 1 message, its semantics here are unclear.
Negotiate NTLM (`0x00000200`)	Indicates that NTLM authentication is supported.
Negotiate Local Call (`0x00004000`)	The server sets this flag to inform the client that the server and client are on the same machine. The server provides a local security context handle with the message.
Negotiate Always Sign (`0x00008000`)	Indicates that communication between the client and server after authentication should carry a "dummy" signature.
Target Type Domain (`0x00010000`)	The server sets this flag to indicate that the authentication target is being sent with the message and represents a domain.
Target Type Server (`0x00020000`)	The server sets this flag to indicate that the authentication target is being sent with the message and represents a server.
Target Type Share (`0x00040000`)	The server apparently sets this flag to indicate that the authentication target is being sent with the message and represents a network share. This has not been confirmed.
Negotiate NTLM2 Key (`0x00080000`)	Indicates that this server supports the NTLM2 signing and sealing scheme; if negotiated, this can also affect the client's response calculations.
Negotiate Target Info (`0x00800000`)	The server sets this flag to indicate that a Target Information block is being sent with the message.
Negotiate 128 (`0x20000000`)	Indicates that this server supports strong (128-bit) encryption.
Negotiate 56 (`0x80000000`)	Indicates that this server supports medium (56-bit) encryption.

`0x01010000`	(the blob signature)
`0x00000000`	(reserved value)
`0x0090d336b734c301`	(our timestamp)
`0xffffff0011223344`	(a random client nonce)
`0x00000000`	(unknown, but zero will work)
0x02000c0044004f00 4d00410049004e00 01000c0053004500 5200560045005200 0400140064006f00 6d00610069006e00 2e0063006f006d00 0300220073006500 7200760065007200 2e0064006f006d00 610069006e002e00 63006f006d000000 0000	(our target information block)
`0x00000000`	(unknown, but zero will work)

0	`0x4e544c4d53535000`	NTLMSSP Signature
8	`0x03000000`	Type 3 Indicator
12	`0x180018006a000000`	LM Response Security Buffer: Length: 24 bytes (`0x1800`) Allocated Space: 24 bytes (`0x1800`) Offset: 106 bytes (`0x6a000000`)
20	`0x1800180082000000`	NTLM Response Security Buffer: Length: 24 bytes (`0x1800`) Allocated Space: 24 bytes (`0x1800`) Offset: 130 bytes (`0x82000000`)
28	`0x0c000c0040000000`	Target Name Security Buffer: Length: 12 bytes (`0x0c00`) Allocated Space: 12 bytes (`0x0c00`) Offset: 64 bytes (`0x40000000`)
36	`0x080008004c000000`	User Name Security Buffer: Length: 8 bytes (`0x0800`) Allocated Space: 8 bytes (`0x0800`) Offset: 76 bytes (`0x4c000000`)
44	`0x1600160054000000`	Workstation Name Security Buffer: Length: 22 bytes (`0x1600`) Allocated Space: 22 bytes (`0x1600`) Offset: 84 bytes (`0x54000000`)
52	`0x000000009a000000`	Session Key Security Buffer: Length: 0 bytes (`0x0000`) Allocated Space: 0 bytes (`0x0000`) Offset: 154 bytes (`0x9a000000`)
60	`0x01020000`	Flags: Negotiate Unicode (`0x00000001`) Negotiate NTLM (`0x00000200`)
64	0x44004f004d004100 49004e00	Target Name Data ("`DOMAIN`")
76	`0x7500730065007200`	User Name Data ("`user`")
84	0x57004f0052004b00 5300540041005400 49004f004e00	Workstation Name Data ("`WORKSTATION`")
106	0xc337cd5cbd44fc97 82a667af6d427c6d e67c20c2d3e77c56	LM Response Data
130	0x25a98c1c31e81847 466b29b2df4680f3 9958fb8c213a9cc6	NTLM Response Data

Negotiate Lan Manager Key	When set, the Lan Manager Session Key is used as the basis for the signing and sealing keys (rather than the User Session Key). If not established, the User Session Key will be used for key derivation.
Negotiate 56	Indicates support for 56-bit keys. If not negotiated, 40-bit keys will be used. This is only applicable in combination with "Negotiate Lan Manager Key"; User Session Keys are not weakened under NTLM1 (as they are already weak).
Negotiate Key Exchange	Indicates that key exchange will be performed to negotiate a secondary key for signing and sealing.

Negotiate NTLM2 Key	Indicates support for NTLM2 session security.
Negotiate 56	Indicates support for 56-bit keys. If neither this flag nor "Negotiate 128" are specified, 40-bit keys will be used.
Negotiate 128	Indicates support for 128-bit keys. If neither this flag nor "Negotiate 56" are specified, 40-bit keys will be used.
Negotiate Key Exchange	Indicates that key exchange will be performed to negotiate a secondary base key for signing and sealing.

The NTLM Authentication Protocol and Security Support Provider

Abstract

Contents

What is NTLM?

Name Variations

The NTLM Response

The NTLMv2 Response

The LMv2 Response

The NTLM2 Session Response

The Anonymous Response

NTLMSSP and SSPI

Local Authentication

Datagram Authentication

The LM User Session Key

Master Key Negotiation

NTLM2 Session Security

Master Key Negotiation

Signing

Sealing

Miscellaneous Session Security Topics

Datagram Signing & Sealing

Appendix A: Links and References

Appendix B: Application Protocol Usage of NTLM

NTLM HTTP Authentication

NTLM SMTP Authentication

NTLMv1 Authentication; NTLM1 Signing and Sealing Using the LM User Session Key

NTLMv1 Authentication; NTLM1 Signing and Sealing Using the 56-bit Lan Manager Session Key

NTLMv1 Authentication; NTLM1 Signing and Sealing Using the 40-bit Lan Manager Session Key

NTLMv1 Datagram-Style Authentication; NTLM1 Signing and Sealing Using the 40-bit Lan Manager Session Key With Key Exchange Negotiated

NTLMv1 Authentication; NTLM1 "Dummy" Signing and Sealing Using the NTLM User Session Key

NTLM2 Session Response Authentication; NTLM2 Signing and Sealing Using the 128-bit NTLM2 Session Response User Session Key With Key Exchange Negotiated

NTLM2 Session Response Authentication; NTLM2 Signing and Sealing Using the 40-bit NTLM2 Session Response User Session Key

NTLMv2 Authentication; NTLM1 Signing and Sealing Using the 40-bit NTLMv2 User Session Key

NTLMv2 Authentication; NTLM2 Signing and Sealing Using the 56-bit NTLMv2 User Session Key

Anonymous NTLMv1 Authentication; NTLM2 Signing and Sealing Using the 128-bit Null User Session Key With Key Exchange Negotiated

Local NTLMv1 Authentication; NTLM2 Signing and Sealing Using an Unknown Session Key With Key Exchange Negotiated (Analysis Incomplete)

Appendix D: Java Implementation of the Type 3 Response Calculations