翻譯，NTLM和頻道綁定哈希（EPA）

爲了過NTLM 的EPA認證， 參考了這篇文章，如今翻譯過來，備查。

若是你知道NTLM，而且須要過EPA， 那麼這篇文章必定是你最想知道的。

原文地址：

NTLM and Channel Binding Hash (aka Extended Protection for Authentication) – Microsoft Open Spec

 

=======================

Extended Protection for Authnetication (EPA) was introduced in Windows 7/WS2008R2 to thwart reflection attacks. This blog describes the changes in the implementation of NTLM Authentication that are needed to successfully authenticate to servers that have EPA enabled. Windows 7/WS 2008R2 and Windows 8/ WS2012 have EPA enabled out of the box.

認證的擴展保護(EPA) 在Windows7/WS2008R2 中引進, 用來對抗反射攻擊. 本文介紹了要經過服務器端EPA認證,NTLM實現上的必要的改變.  Windows7/WS2008R2 和Windows8/WS2012默認開啓了EPA.

You can read the details about EPA here http://technet.microsoft.com/en-us/security/advisory/973811

這裏有EPA進一步的細節.

The concept in EPA is that authentication packets should be bound to the secure channel on which they are transmitted. This concept is not new and is known as channel binding (RFC 5056). RFC 5929 describes channel bindings for TLS that Winodws uses to bind the secure channel to authentication. Please note that EPA also uses Service Pricipal Name (SPN) but it is not used for TLS and we will not discuss it here.

EPA的概念是認證的數據包應該綁定到傳輸它的安全頻道上.  這個概念並非全新的, 它就是衆所周知的頻道綁定(RFC5056).  RFC5929描述了描述了Tls的頻道綁定, Windows用它綁定安全頻道到認證.  請注意, EPA一樣也使用了服務主體名稱(SPN), 可是這沒有被用於TLS, 咱們在這不討論它.

Let’s take an example of HTTPS, a protocol that uses TLS. Once a secure channel is established and cipher change has happened, HTTP traffic starts flowing. In this example, we are only considering services that require authentication. NTLM or Kerberos will be used if you are using Windows authentication. You are most likely to use NTLM since the whole point of using HTTP and TLS is to allow clients to connect over internet (In Windows 8, Kerberos can be used on the internet but we will concentrate on NTLM here). In case of Windows client, these are the steps that are taken to incorporate channel binding in the authentication process after secure channel has been established:

咱們看看HTTPS協議, 它使用了TLS.  一旦安全頻道創建,而且密碼交換完成, HTTP就開始傳輸.  在這個例子中, 咱們只關心須要認證的服務.  若是你正在使用Wndows認證的話, NTLM或者Kerberos將會被應用.你極可能會使用NTLM,  由於在TLS上使用HTTP的所有緣由就是容許客戶端經過Internet鏈接. (在Windows8中, Kerberos也能引用於internet, 可是咱們仍然集中在NTLM上.) 對於Windows客戶端,  在安全頻道創建以後, 認證過程當中, 構成頻道綁定的步驟以下:

1. The hashing algorithm for the signature in the certificate is identified, if present.

若是存在, 證書籤名的哈希算法先被識別出來.

2. SSPI calculates a hash (almost always SHA256 hash, see below for details/exceptions) of the certificate, appends other data relevent to the type of channel bindings and returns it to the application.

SSPI 計算證書的哈希值(一般是SHA256, 後面會有細節和例外),  加上頻道綁定類型的相關數據, 而後返回給應用程序.

4. SSPI calculates the MD5 hash of channel bindings and uses it in the calculation of NTLM version 2 response.

SSPI 計算頻道綁定的MD5哈希值,  用於計算 NTLM version 2 的回覆

5. When server recives authenticate message, it queries SSPI for channel bindings. SSPI does exactly the same thing as on the client side and returns the data to the service. The service includes it in the call to method Accept Security Context (ASC)

當服務器接收到認證消息以後, 它像SSPI查詢頻道綁定.  SSPI 進行域客戶端徹底同樣的操做, 並把數據返回給服務.  服務端在 接受安全上下文(ASC)的調用中包含這個數據.

6. In the process of verifying authenticate message, SSPI also takes into account the channel bindings. It calculates the MD5 hash of the channel bindings that were provided by the application (service) and compares it to the one sent by the client. If they match and rest of the authentication requirements are met, authentication is successful.

在校驗的認證消息的過程當中, SSPI一樣要考慮頻道綁定. 它會計算應用(服務)提供的頻道綁定的MD5值, 而且和客戶端發送過來的值進行對比.  若是匹配, 而且人權衡的其餘條件知足, 則認證成功.

I’ll now elaborate on each of the step listed above with a concrete example of RPC-over-HTTP traffic. The TLS network traffic is encrypted and I used Network Monitor expert Network Monitor Decryption Expert (NmDecrypt) to decrypt it. The decrypted network trace is attached to this blog.

下面使用一個具體的 RPC-over-HTTP 的傳輸來具體描述上面的每一步.  Tls的網絡傳輸都是加密的, 我使用了 Network Monitor expert Network Monitor Decryption Expert (NmDecrypt) 來解密. 解密的網絡跟蹤在帖子的附件中.

If you open the network trace in Network Monitor, you’ll see that in frame 16 server sends a certificate to client, as below (copied and pasted from the trace):

打開 網絡跟蹤日誌, 你會發如今第16幀, 服務端發送了一個證書給客戶端, 以下:

……

After secure channel is established and cipher change has taken place, HTTP traffic starts flowing.

在安全頻道創建以後,而且密碼交換完成, HTTP傳輸就開始了.

In this example, HTTP is being used as a transport for RPC and RPC server requires authentication. For authentication, the client application first calculates the channel binding by using the following process(in Windows this is done by SSPI but that is not important in this discussion ). This process is based on RFC 5929.

在這個例子中, HTTP用來傳輸RPC, 而且RPC服務器要求認證.  對於認證, 客戶端首先計算頻道綁定, 過程以下(在Windows中, 由SSPI完成, 但這不重要): 這個過程基於RFC5929.

1. The channel binding type for this example is "tls-server-end-point" since a certificate is used in handshake (RFC5929).

頻道綁定類型在本例中是 "tls-server-end-point", 由於在握手時使用了證書.

2. The client calculates a hash of the certificate. The hashing algorithm is SHA-256, unless all of the following conditions are met, in which case the signature algorithm in the certificate will be used.

客戶端計算證書的哈希值. 哈希算法是SHA256, 除非下面的條件都知足, 此時將會使用證書的簽名算法.

A certificate signature algorithm exist

證書籤名算法存在

The algorithm is only implemented in CNG (ALG_ID is CALG_OID_INFO_CNG_ONLY)

(證書籤名)算法只在CNG中實現(ALG_ID 爲 CALG_OID_INFO_CNG_ONLY).

The algorithm has a corresponding CNG algorithm identifier string (pwszCNGAlgid)

(證書籤名)算法有相應的CNG算法標示字符串(pwszCNGAlgid)

The algorithm is not SHA1

算法不是SHA1

The algorithm is not MD5

算法不是MD5

3. The SHA-256 hash of the above certificate is: ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95

上面證書的SHA-256哈希值是:  ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95

4. The Channel binding unique prefix (RFC5929) "tls-server-end-point" is prefixed to the hash above (with a colon), resulting in 

74 6c 73 2d 73 65 72 76 65 72 2d 65 6e 64 2d 70 6f 69 6e 74 3a ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95

頻道綁定前綴"tls-server-end-point"被附加到這個hash值得前面(冒號分隔):

74 6c 73 2d 73 65 72 76 65 72 2d 65 6e 64 2d 70 6f 69 6e 74 3a ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95

5. The above value is inserted as the value of application_data field of gss_channel_bindings_struct structure, as pointed out by MS-NLMP section 2.2.2.1

上面這個值插入到 gss_channel_bindings_struct 結構的 application_data 字段 .  這個字段在  MS-NLMP section 2.2.2.1 描述.

6. Windows always sets the other fields of gss_channel_bindings_struct as zeros (SEC_CHANNEL_BINDINGS

structure). The resulting gss_channel_bindings_struct is as follows (little endian format):

Windows 老是將 gss_channel_bindings_struct 機構的其餘字段設爲 0.  gss_channel_bindings_struct 結構的結果以下(小端格式):

00 00 00 00 //initiator_addtype 

00 00 00 00 //initiator_address length

00 00 00 00 //initiator_address pointer

00 00 00 00 //acceptor_addrtype

00 00 00 00 //acceptor_address length

00 00 00 00 //acceptor_address pointer

35 00 00 00 //application_data length (53 bytes)

20 00 00 00 //application_data pointer (32 bytes from start of this structure)

74 6c 73 2d //application data, as calculated above

73 65 72 76

65 72 2d 65

6e 64 2d 70

6f 69 6e 74

3a ea 05 fe

fe cc 6b 0b

d5 71 db bc

5b aa 3e d4

53 86 d0 44

68 35 f7 b7

4c 85 62 1b

99 83 47 5f

95

After calculating channel binding, the client application starts authentication and include channel binding as part of authentication. In case of NTLM, the gss_channel_bindings_struct is called ClientChannelBindingUnhashed (MS-NLMP section 3.1.1.2). As explained in MS-NLMP section 3.1.5.1.2, the client adds an AV_PAIR structure and set the AvId field to MsvAvChannelBindings and the Value field to MD5(ClientChannelBindingsUnhashed). The MD5 hash of the above gss_channel_bindings_struct turns out to be:

頻道綁定完成以後, 客戶端開始認證, 將頻道綁定做爲認證的一部分包含進來.  對於NTLM, gss_channel_bindings_struct 結構 被叫作: ClientChannelBindingUnhashed (MS-NLMP section 3.1.1.2). 正如  MS-NLMP section 3.1.5.1.2, 中所介紹的,  客戶端添加一個AV_PAIR  結構, AvId字段設爲 MsvAvChannelBindings, 而Value字段設爲 MD5(ClientChannelBindingsUnhashed). 上面的gss_channel_bindings_struct  結構的MD5值以下: 
65 86 E9 9D 81 C2 FC 98 4E 47 17 2F D4 DD 03 10

This value is part of the AUTHENTICATE_MESSAGE in frame 27 in the network trace attached (in the network trace it is shown in Base64 encoding as 45 41 42 6C 68 75 6D 64 67 63 4C 38 6D 45 35 48 46 79 2F 55 33 51 4D 51 with AvLen) .

這個值做爲AUTHENTICATE_MESSAGE 認證消息的一部分, 在附件的第27幀(附件中顯示爲Base64的編碼值:   45 41 42 6C 68 75 6D 64 67 63 4C 38 6D 45 35 48 46 79 2F 55 33 51 4D 51 包含 AvLen   ).

When server receives the AUTHENTICATE_MESSAGE, in addition to the regular authentication processing, it also verifies the channel binding hash by calculating it the same way the client did. If the channel binding hash does not match, the authentication will not be successful. The subsequent behavior is server dependent. In this example (IIS), the server will stop communication on unsuccessful authentication.

當服務端收到 AUTHENTICATE_MESSAGE 認證消息以後, 除了作常規的認證處理以外, 它還校驗頻道綁定數據, 與客戶端一樣計算一遍. 若是頻道綁定數據不匹配, 認證就失敗. 以後的行爲就和服務器相關. 在這個例子中(IIS), 服務器會中止通訊.

Please note that two step hashing is being employed here. First the application creates a hash of the certificate which becomes a part of gss_channel_bindings_struct structure. This structure is MD5 hashed again to be included in AUTHENTICATE_MESSAGE.

請注意, 這裏應用了2步哈希. 首先應用程序計算證書的哈希值, 使其成爲 gss_channel_bindings_struct結構的一部分.  這個結構又被計算MD5 哈希值, 用來包含在 AUTHENTICATE_MESSAGE中.

There are configurations on both Windows client and server side to disable the EPA. For the server side, please consult the server specific documentation. As for the server in this example, IIS, please consult http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication/extendedprotection.

在Windows客戶端和服務端都有配置來禁用EPA.  對於服務端, 請參考服務端規範. 對於本例中使用的IIS, 請參考:

http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication/extendedprotection

On the client side, there is a registry setting that is described in KB976918 (http://support.microsoft.com/kb/976918) that can be used to configure EPA.

對於客戶端,  KB976918 描述了一個註冊表設置(http://support.microsoft.com/kb/976918) 能用來配置EPA.

 

==============================

歡迎你們訪問個人我的獨立博客： blog.byneil.com

本文不是徹底對照翻譯，可是力求主題意思清楚。  請參考原文閱讀：

NTLM and Channel Binding Hash (aka Extended Protection for Authentication) – Microsoft Open Spec

 

歡迎你們交流討論。

byNeil
byNeil.com