NTLM Terminology: MS-NLMP vs. http://davenport.sourceforge.net/ntlm.html

The NTLM Authentication protocol is an old relic. Microsoft, the inventor of the protocol, itself discourages its use and recommends using Kerberos.

But I expect NTLM to be around for a long time. The reason is Kerberos’s use of Key Distribution Center (KDC) and Ticket Granting Server (TGS). These two entities are generally co-located but even then, this is a third entity. In case of simple client and server authentication where the server is not KDC, Kerberos can not be used. Also, another requirement is that both the client and server should be joined to a domain. If any one of them is not, NTLM will be used.

Recently I was working on an issue regarding NTLM session security and I noticed that customer was using terminology for NTLM Authentication Protocol that is not present in [MS-NLMP], the official specification for the NTLM authentication protocol. The customer was using terminology presented in The NTLM Authentication Protocol and Security Support Provider.

This was not the first time that this had happened. We have had similar cases in the past. So, to make communication more efficient and productive, I decided to write this blog where I’ll present terminology used in The NTLM Authentication Protocol and Security Support Provider and its equivalent used in [MS-NLMP].

For the rest of this blog, I’ll use NTLM.html as an abbreviation for The NTLM Authentication Protocol and Security Support Provider. I’ll not list the terms that are not present in [MS-NLMP] but intuitive.


Type 1 message Negotiate message
Type 2 message Challenge message
Type 3 message Authenticate message
NTLM2 Session Security Extended Session Security
NTLM Response NTLM v1 Response
NTLM2 Session Response There is no equivalent term in MS-NLMP. This is the LM and NTLMv1 response combined when Extended Session Security is negotiated.
Datagram Connectionless
LM User Session Key No Equivalent
NTLM User Session Key SessionBaseKey
LMv2 User Session Key No Equivalent
NTLMv2 User Session Key SessionBaseKey
LM hash LMOWFv1
NTLMv2 hash NTOWFv2, LMOWFv2
Lan Manager Session Key This is calculated as follows:

DES(ConcatenationOf(LMOWFv1[7], 0xBDBDBDBDBDBD),

Note: I reproduced this here since at the writing of this blog, MS-NLMP has a bug. The version here is correct and will appear in a future release.

This is the sessionBaseKey when only LM authentication is used. If NTLMSSP_NEGOTIATE_KEY_EXCH is set, this becomes KeyExchangeKey when NTLMSSP_NEGOTIATE_LMKEY flag is set.

Master key This term is used for the session key that will be used to sign and seal the messages. This is 16 bit key but depending upon the flags NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128, a portion of this key may be used to sign and seal.
secondary base key, secondary key RandomSessionKey
Client nonce ClientChallenge
Key Weakening This term is not mentioned in [MS-NLMP] but the process is explained in section “ SEALKEY”. This is governed by the flag NTLMSSP_NEGOTIATE_56.
If set, session key is truncated to 7 bytes, else it is truncated to 5 bytes. These key are extended to 8 bytes. For details, please consult either document.
User Session Key This term is not used in MS-NLMP and its closest equivalent is SessionBaseKey but it should be noted that SessionBaseKey is more limited concept than the User Session key. User Session Key represents the initial session key that can be modified later based on the values of different flags. For details, please consult NTLM.html.


Now that you know what LM hash is, a note about session security when NTLMSSP_NEGOTIATE_LMKEY is set.

As explained in Knowledge Base article 299656 (http://support.microsoft.com/kb/299656), newer versions of Windows do not store the LM hash of the password. This generally does not pose a problem since most modern implementations of NTLM do not use LAN Manager (LM) authentication. Even when an LM response is sent, the NTLM response is also sent in the Authenticate message; servers use that to authenticate (if not, authentication will fail). But in a rare case, if you are sending both the LM and NTLM responses and using NTLM session security (NTLMSSP_NEGOTIATE_LMKEY is set), your authentication will succeed but you will not be able to decrypt the messages from the server and the server will not be able to decrypt your messages. The reason is that server will be using an LM hash that is all zeros, since it does not store LM hashes. This will have an effect on calculation of key exchange keys and eventually on sealing keys. To avoid this problem, use Extended Session Security.

Comments (3)
  1. Mike C says:


    This article is perfect timing – I've just started playing with [MS-NLMP]. However, there's a bit which had me scratching my head until I read "The NTLMv2 Response" in NTLM.htm. The definition of NTOWFv2 on page 59 of [MS-NLMP v20101001] would probably be clearer if it read as follows:

    Define NTOWFv2(Passwd, User, UserDom) as HMAC_MD5(

    MD4(UNICODE(Passwd)), UNICODE( ConcatenationOf( Uppercase(User), UserDom ) ) )


    My code started working once I realised it needed a UNICODE transform on the username and domain…

    Other than that, thanks for the great documentation.



  2. Marc-Andre Moreau says:


    Thanks for this clarification on the terminology. I have been using both MS-NLMP and the davenport article. I found the davenport article to be much clearer and easy to understand unlike MS-NLMP which is highly cryptic in my opinion. If MS-NLMP could have clear step-by-step examples similar to the ones from the davenport article, it would greatly enhance its readability. Terms like "NTOWFv2" aren't necessarily clear when compared to "NTLMv2 hash". As part of step-by-step examples in MS-NLMP, it would be great to have actually pre-computed values that could be used to write unit tests. In my case, I have used the examples from the davenport article to write my own unit tests and validate my code.

  3. NTLM.html was written in the dark times, before Microsoft released specifications like [MS-NLMP].  It was written by a developer, for the benefit of the community as a whole.  I have done similar work, and I can tell you that, back then, we did not have access to the nomenclature used internally by Microsoft so we had to come up with our own names for things.

    [MS-NLMP] is a specification, and it comes from within Microsoft.  It uses their internal names for things and it is designed to be detailed and specific.  It has to meet high standards for accuracy, sometimes at the expense of readability.  NTLM.html was from outside, and is really more of a developer's guide.  As such, it's focus is on transferring ideas and concepts so it needs to be more readable.

    What Obaid has done with this article is to provide a bridge between the two so that both remain useful.  What would really help, however, is an updated NTLM.html that includes the mapping Obaid has provided and the new information that is available to us in [MS-NLMP], described in easy-to-read terms.


Comments are closed.

Skip to main content