NTLM keys and sundry stuff
Recently I worked on issues related to NTLM and SMB signing. Reading MS-NLMP made me realize that NTLM has quite a few different keys, and based on version and features, the signing and sealing key can be calculated differently. I decided to summarize what the meanings of different keys are. Reading this in conjunction with MS-NTLM should help you understand NTLM a little better.
The following is a list of keys and their definitions mentioned and used in MS-NLMP. Anything that you see here that I do not explain (e.g. NTOWF) is described in MS-NLMP. MS-NLMP is available at
https://msdn.microsoft.com/en-us/library/cc236621.aspx . You can simply bing MS-NLMP and bing will find it for you.
RandomSessionKey is a Random 128 bit key generated by client. It is calculated as Nonce(16) . MS-NLMP uses RandomSessionKey and Nonce(16) interchangeably.
SessionBaseKey is the first key calculated by client. It differs based on NTLM version. Its value is:
SessionBaseKey is equal to |
When |
MD4(NTOWF) |
NTLMv1 |
HMAC_MD5(ResponseKeyNT, NTProofStr) |
NTLMv2 |
KeyExchangeKey is a key that is calculated to encrypt the RandomSessionKey. This is needed since the client calculates the RandomSessionKey and sends it to the server on the wire. To protect the RandomSessionKey, it is encrypted with KeyExchangeKey, which a client and server can calculate based upon the shared secret. The derivation of KeyExchangeKey depends on several factors as follows:
KeyExchangeKey is equal to |
When |
ConcatenationOf(DES(SessionBaseKey[0..6], LmChallengeResponse[0..7]), DES(ConcatenationOf(SessionBaseKey[7], 0xBDBDBDBDBDBD), LmChallengeResponse[0..7])) |
NTLMv1 and NTLMSSP_NEGOTIATE_LMKEY |
ConcatenationOf(LMOWF[0..7], Z(8)) |
NTLMv1 and NTLMSSP_REQUEST_NON_NT_SESSION_KEY |
SessionBaseKey |
NTLMv1 and not NTLMSSP_REQUEST_NON_NT_SESSION_KEY |
HMAC_MD5(SessionBaseKey, ConcatenationOf(ServerChallenge, LmChallengeResponse [0..7])) |
NTLMv1 with Extended Session Security |
SessionBaseKey |
NTLMv2 |
ExportedSessionKey is used to calculate the signing and sealing key for the session. It is also, as you might expect, calculated based on version and features negotiated.
ExportedSessionKey is equal to |
When |
Nonce(16) |
NTLMSSP_NEGOTIATE_KEY_EXCH |
KeyExchangeKey |
not NTLMSSP_NEGOTIATE_KEY_EXCH |
EncryptedRandomSessionKey is self-explanatory (finally something that is self-explantory). Its calculation is affected by the negotiated value of NTLMSSP_NEGOTIATE_KEY_EXCH. This is an odd ball here, since it is just an encrypted version of ExportedSessionKey, done so to send it to the server securely.
EncryptedRandomSessionKey is equal to |
When |
RC4K(KeyExchangeKey, ExportedSessionKey) |
NTLMSSP_NEGOTIATE_KEY_EXCH |
NIL |
not NTLMSSP_NEGOTIATE_KEY_EXCH |
We are not done yet. The keys used to sign (integrity) and seal (confidentiality) are still not available. They are derived from ExportedSessionKey as follows:
ClientSigningKey |
= |
SIGNKEY(NegFlg, ExportedSessionKey, "Client") |
|
ServerSigningKey |
= |
SIGNKEY(NegFlg,ExportedSessionKey, "Server") |
|
ClientSealingKey |
= |
SEALKEY(NegFlg, ExportedSessionKey, "Client") |
|
ServerSealingKey |
= |
SEALKEY(NegFlg, ExportedSessionKey, "Server") |
As you can expect, SIGNKEY and SEALKEY are defined in MS-NLMP.
So, why it is so complicated? Well, I guess it has a lot to do with history and backward compatibility. NTLM is fairly old protocol and as time went, there was a need to make it more robust. You may notice that key calculation is fairly straight forward for NTLMv2.
NTLM Extended Session Security and SMB Extended Security
These two terms can confuse people reading MS-NTLM and MS-SMB together. While their names are similar and a casual reader may even think that they are same, they are not.
Extended Session Security (ESS) in NTLM world means: NTLMv1 with Extended Session Security. So right off the bat, it is NTLMv1 and not NTLMv2. [1] refers to it as NTLM2 and that may give a wrong impression that it is NTLMv2.
Unlike plain NTLMv1 or NTLMv2, NTLMv1 w/ ESS is actually negotiated between a client and a server (NTLMv1 and NTLMv2 are configured using security key LmCompatibilityLevel). It is negotiated by setting a bit in NegotiateFlags, called P bit (MS-NLMP, section 2.2.2.5). Another name for this field is NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY. Yet another name for this flag that I found is “Negotiate NTLM2 Key”[1].
If a client supports NTLMv1 w/ESS, it will set the P bit in the Negotiate message to the server and if server also supports NTLMv1 w/ ESS, it will also set this bit in the Challenge message. The calculation for responses differs quite a bit from plain NTLMv1. NTLMv1 w/ ESS was an attempt to make NTLMv1 more robust, and my impression is that the NTLM developer community generally has a consensus on this. Again, for details, see MS-NLMP. In case of pass-through authentication, the challenge that is sent to DC by server for authentication is not the same as the one sent to client by the server. For details, please see MS-APDS section 3.1.5.2.
SMB extended security is a very different beast. SMB extended security means that an SMB server and client are using GSS API for generating security blobs that are sent in SessionSetupAndX messages. The server shows the client that it supports Extended Security by setting the CAP_EXTENDED_SECURITY flag in SMB negotiation. The client then MUST use GSS API to generate the security blob for SessionSetupAndX. For details, see MS-SMB.
References
[1] The NTLM Authentication Protocol and Security Support Provider
[MS-APDS] Authentication Protocol Domain Support Specification
[MS-NLMP] NT LAN Manager (NTLM) Authentication Protocol Specification