二、 Kerberos V5身份验证协议如何工作
Kerberos V5身份验证协议（RFC 1510定义），提供一个在开放的、潜在不安全的网络环境中验证主体身份的方法。这一节讨论RFC标准的Kerberos V5在Windows Server 2003如何使用
这节分为以下四个子章节：
l Kerberos SSP结构：说明Windows Server 2003的SSPI怎样提供一个访问SSP的机制。
l Kerberos 物理结构：讨论Windows Server 2003中实现Kerberos 身份验证的组件。这些组件包括密钥、票据和密钥分发中心（KDC）
l Kerberos V5身份验证协议过程和相互作用：说明Kerberos 身份验证在不同的情形下怎样被使用，Kerberos 消息的细节，并讨论其他相关技术。例子将给出完整的过程，包括没有被Kerberos 身份验证协议定义的相关的组件和过程。一些过程（比如怎样发现一个验证服务，什么信任证书会被通过，信任证书被存放在哪）在Windows系统是特殊的，可能与其他的Kerberos 协议的实现有所不同。
l Kerberos V5协议使用的网络端口：以表格形式展现在Kerberos 身份验证期间使用到的端口。
1、 Kerberos SSP架构
Windows Server 2003 以Security Support Provider (SSP)来实现Kerberos V5身份验证协议，一个操作系统的动态链接库（DLL）。Windows Server 2003另外还包括针对NTLM的SSP。缺省的启动时Windows Server 2003的Local Security Authority (LSA) 把两个SSP都装载进来，系统能够两个SSP中的任意一个来验证网络登录和客户端/服务器的连接。使用哪一个SSP取决于连接另一端的机器的能力和个别应用的参数选择。
Microsoft SSPI是Windows Server 2003中身份验证的基础，就是说，要求身份验证的应用和底层服务都使用SSPI接口。
SSPI是Generic Security Service API (GSSAPI)在Windows Server 2003中的实现，关于GSSAPI的更多信息，请参考RFC 2743 和 RFC 2744。
Windows Server 2003中默认的SSPs（Negotiate (SPNEGO), Kerberos, NTLM, Schannel, 和摘要身份验证（Digest authentication protocols））以DLL的形式插入到SSPI，其它的SSP如果能够同SSPI交互也能被插进来。
SSPI 架构图示：
Windows Server 2003中的SSPI提供一个在客户端和服务端已存在的连接上传送身份验证令牌的机制。当两个实体为了能相互安全的通讯需要身份验证时，身份验证的请求被路由到SSPI，SSPI不管当前正在使用什么网络协议完成身份验证过程，并返回一个透明的（transparent）两进制大对象给连接的另一边的应用。SSPI允许一个应用在一个机器上或网络上使用多种安全模型而不用改变安全系统的接口。
下表是被插入到SSPI的组件的描述。表中的Windows Server 2003中的每个协议都以不同方法来提升不安全网络环境中的通信的安全性。
SSP 层组件：
|
组件 |
描述 |
|
Kerberos V5 身份验证 |
一个用口令或者智能卡交互登录的工业标准。它也是Windows 2000 and Windows Server 2003首选身份验证的方式。 |
|
NTLM 身份验证 |
一个质询回应（challenge-response）协议使用来提供比Windows 2000更早的系统的兼容性 |
|
摘要身份验证 |
用于Windows Server 2003 LDAP和web身份认证的工业标准，摘要身份的信任凭证被MD5散列后在网上传输。 |
|
Schannel |
一个实现安全套接层（SSL）和传输层安全（TLS）因特网标准身份验证协议的SSP。Schannel被用于基于web的服务器身份验证，象当一个用户试图访问一个安全的web服务器。 |
|
Negotiate |
被用于协商使用哪个特定协议的SSP。当一个应用通过SSPI登录到网络，它能够指定一个SSP处理这个登录请求，当应用指定Negotiate，Negotiate分析这个请求并选取对客户端配置的安全策略来说最好的SSP处理这个请求 |
2、 Kerberos 物理结构
Kerberos在开放的网络（在网络上传输的数据包可以被随意的监听和修改）上提供客户端和服务端双向的身份验证的机制。为了提供安全的身份验证，Kerberos身份验证使用对称密钥、加密的对象和Kerberos服务。
Kerberos 组件
2.1、 身份验证中使用的密钥
2.1.1 为什么需要密钥?
Kerberos协议严重的依赖于一个验证技术共享密钥。基本的共享密钥的概念十分简单：如果一个秘密只有两个人知道，任何一个人都可以通过他们之间共享的秘密来确定对方的身份。
比如，假设Alice经常给Bob传送信息，Bob在使用这个信息前需要确定这个信息真的就是Alice传送过来的。他们决定通过在他们选择一个只有他们两个人知道一个秘密来解决这个问题，如果一个信息声称来自Alice的，并能以某种方式出示发送者知道的密码，那Bob就能确信发送者就是Alice。
剩下的问题就是Alice和Bob需要解决Alice怎么出示她知道的密码。她可以把密码包含在她发送的信息里面，多半是在最后的签名 － Alice, Our$ecret。 这是简单而有效率的如果他们能确信没有人能够看到他们之间的传送的信息。不幸的是，他们的信息通过的网络上有个用户Carol，他用网络分析工具扫描网络通讯希望有一天能够发现这个密码。因此，Alice不能在她发送的信息里提供密码。为了保持密码的保密性，她必须要能出示这个密码但又不能暴露它。
Kerberos协议用密钥来解决这个问题。替代共享的密码，通讯的双方共享一个密钥，他们使用这个密钥的知识验证另一方的身份。为了使这个技术正常工作，他们共享的密钥必须是对称的，就是说，一个密钥既能够用来加密，又能够用于解密。密钥的一部分知识用来加密，另一部分知识用来解密。
Kerberos身份验证依赖于几个不同类型密钥，密钥的类型有长期对称密钥，长期非对称密钥和短期对称密钥。身份验证协议被设计为使用对称加密，意味着发送端和接收端使用共享的密钥加密和解密。
2.1.2 长期对称密钥：User, System, Service, Inter-realm Keys
长期对称密钥源于一个密码。明码文本的密码通过加密功能被转换为一个密钥（所有的Kerberos V5的实现必须支持DES-CBC-MD5），这里使用DES-CBC-MD5加密的方式把明码文本的密码转换一个密钥。
User keys
当建立一个用户时，用户口令将被用来建立一个user key。在活动目录域，user key和用户对象一起存放在活动目录里，在工作站，用户对象在用户登录时被建立。
System keys
当一个工作站或服务器加入到域，它会收到一个密码，跟用户帐户相似，这个密码用来建立一个system key。
Service keys
服务用的密钥基于登录到服务的帐户的密码
所有在同一领域的KDC使用同一个服务密钥。这个密钥基于跟krbtgt帐户关联的口令，每个活动目录月都有这个内建的帐户。
Inter-realm keys
为了跨领域的身份验证的需要，KDC必须共享一个inter-realm key，因为他们共享一个inter-realm key所以领域能够彼此信任，有父子关系的活动目录域共享一个inter-realm key。这个inter-realm key基于Windows 2000 和 Windows Server 2003的信任传递。如果一个shortcut trust关系被建立，两个域将会交换这个密钥
Kerberos SSP 加密密钥长度
Kerberos SSP支持不同的加密类型，密钥的长度也各不相同。虽然密钥的长度决定着这种加密方法保护程度，密钥的长度不意味着票据的强度。下表列出Kerberos SSP支持的不通加密方法的密钥长度。
不通加密类型的密钥长度
|
加密算法 |
密钥长度 |
|
RC4-HMAC |
128 |
|
DES-CBC-CRC |
56 |
|
DES-CBC-MD5 |
56 |
l 关于明文密码通过DES-CBC-MD5产生密钥：
Kerberos 定义了一种对用户密码进行处理以生成一个密钥的算法。在获得 TGT 的过程中 Kerberos 客户机将用这个密钥进行解密，这就是DES-CBC-MD5，CBC（密码分组链接 cipher block chaining）模式下的 DES（数据加密标准）。DES 是一个 FIPS（联邦信息处理标准 Federal Information Processing Standards）发表，它描述了一种将要加密的数据（纯文本）和密钥作为输入传递给加密过程的加密算法。根据 DES 算法对密钥和纯文本统一处理以生成一个加密的（密文）形式的纯文本数据。
CBC 是一种加密操作模式，其中纯文本数据分为同样大小的数据块。例如，在 64 位 DES-CBC 加密中，数据会分为 8 字节的块。如果纯文本数据中的字节数不是您希望每一个块所具有的字节数的整数倍，就要在最后一块中加上适当的数量的字节以使它的大小与其他的块相同。
然后创建一个与您的块具有同样大小的字节数组。这个字节数组称为 初始矢量 (IV)。Kerveros 规范定义了所有基于 Kerberos 的应用程序的初始矢量（类似地，其他使用 DES-CBC 的规范定义了它们使用的 IV 值）。之后，取这个 IV、纯文数据的第一块以及密钥并根据 DES 算法对它们共同进行处理，以构成对应于纯文本数据第一个数据块的密文。然后取第一个数据块的密文形式作为第二个块的初始矢量并进行同样的 DES 加密过程以生成第二个纯文本数据块的密文形式。以这种方式继续一块接一块地生成每一个块的密文形式。最后，串接所有密文块以得到全部纯文本数据的密文形式。
下面讨论用户密码经过DES-CBC-MD5处理生成密钥的过程
将用户密码、KDC 域名和用户的用户名串接到一起以构成一个字符串。Kerberos 利用这个串接的字符串而不仅仅是密码生成密钥。为什么要在密钥生成中加入域名和用户名呢？许多用户会在不同的服务器上使用同样的密码。如果我只使用密码生成密钥，那么一个给定的密码在所有 Kerberos 服务器上总是会生成同样的密钥。因而，如果一个黑客可以取得用户在一台 Kerberos 服务器上的密钥，那么，他就可以在所有 Kerberos 服务器上使用同一个密钥。另一方面，如果加入了域名和用户名，那么一个受到这种攻击的密钥将只会侵害特定的域。
得到第 1 步中串接的字符串的字节数组表达。
统计第 2 步中字节数组中的字节数。在这个字节串的后面附加适当数量的零字节以使它成为 8 的整数倍。例如，如果这个字节数组包含 53 个字节，那么就在这个字节数组的最后附加三个字节使它具有 56 个字节。
将第 3 步中附加了字节后的字节数组分为大小相同的块，每一块有 8 个字节。
每隔一个块倒转块的位顺序。换句话说，第一块保持不变，第二块的位顺序应该倒转，第三块应保持不变，第中块的位顺序应倒转，以此类推。
取第一个（未改变的）块并与第二个（倒转的）块进行每一位的 exclusive OR。然后将第一次 exclusive OR 操作得到的结果与第三个（未改变的）块进行另一次 exclusive OR 操作。继续 exclusive OR 操作直到完成了所有块。所有 exclusive OR 操作的最后结果是一个 8 字节长的块。
修正在第 6 步中得到的 8 字节块的奇偶性。每一块的最低有效位保留为奇偶位。统计 8 字节块中每字节中的 1 的个数，如果 1 的个数为偶数，那么就设置最低位为 1 使它成为奇数。例如，如果一个字节的值为 00000000，那么就要将它改为 00000001。如果一个字节中 1 的个数已经为奇数，那么就将它的最低位设置为零。例如，如果一个字节为 00000010，那么就不需要为修正其奇偶性做任何改变。
DES 定义了一些弱的、因而不适合用于加密的密钥。我们的密钥生成过程的第八步是要检查奇偶修正后的字节数组是否是一个弱的密钥。如果是的话，就要用 0xf0（11110000）与奇偶修正过的 8 字节块进行 exclusive OR。如果奇偶修正得到的不是弱密钥，那么就不需要进行这种 exclusive OR 操作。经过这种弱密钥处理的字节数组是一个临时密钥。
现在我要使用这个临时密钥以 DES-CBC 算法加密第 3 步中得到的附加后的字节数组。这个临时密钥同时作为密钥的值和 DES-CBC 加密的初始矢量的值。回想在前面的讨论中说过，CBC 要求密文块链接。第 9 步的结果是最后 8 字节块的加密结果（放弃所以以前的密文块）。因此，这一步的结果是另一个 8 字节块。
现在我修正第 9 步产生的 8 字节块中的每一个字节的奇偶性。在上面第 7 步中我解释了奇偶性修正。
现在再次检查第 10 步得到的经过奇偶修正的 8 字节块是不是弱密钥（就像在第 8 步中所做的那样）。
第 11 步的结果是一个 Kerveros 客户机可以用来与 Kerberos 服务器进行通信的密钥。
