为了过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.
==============================
本文不是完全对照翻译，但是力求主题意思清楚。 请参考原文阅读：
NTLM and Channel Binding Hash (aka Extended Protection for Authentication) - Microsoft Open Spec
欢迎大家交流讨论。