内容
1. Kerberos 介绍
在本章中将介绍票证交换原理，密钥分发中心（简称KDC）和身份验证机制。
Kerberos的实现主要考虑了身份验证，而不是授权。通过KDC, Kerberos 解决的主要问题就是这个问题，“是的，你可以信任我，而这个人就是他声称的那个人”。
Kerberos的常见描述是安全的，支持单点登录的，可信第三方相互认证服务。它不存储有关UID，GID或主目录路径的任何信息。Kerberos仅处理身份验证服务，不执行授权服务。
Kerberos作为一种协议，有许多为不同的目的而开发的实现：
-
MIT Kerberos： 来自90年代初的Athena项目。由于出口对加密技术的限制，在瑞典开发了另一种Kerberos实现，即Heimdal；
-
Heimdal Kerberos：是MIT Kerberos的类似的实现，但 Heimdal不受出口规则的限制。最初在瑞典开发，旨在与MIT Kerberos完全兼容。自2000年麻省理工学院的出口限制被取消以来，两种实施方式都在世界范围内得到了更加广泛的应用；
-
Active Directory：是Microsoft的Active Directory服务，包含一个类似的Kerberos实现和一些其他服务（LDAP），它与MIT和Heimdal不直接兼容；
-
TrustBroker：由CyberSafe开发的Kerberos协议的商业实现。支持各种操作系统（Windows，Unix，Linux），并提供与MIT到Microsoft AD的许多现有Kerberos实现的完全互操作性；
-
Shishi： Kerberos 5的GNU实现；
接下来的章节，我们结合MIT 实现，详细介绍Kerberos的功能。
2. Kerberos 票据交换服务
Kerberos的通信基于票据， 票据是一种通过网络传输并存储在客户端的加密数据方案， 存储类型取决于客户端的操作系统和配置。 通常情况下，出于兼容性原因，票据存储在/ tmp目录中，每个操作系统都有特定的文件系统来保存票据数据。
Kerberos网络的主要核心部分是密钥分发中心（KDC），它由三部分组成：
-
身份验证服务器 （Authentication Server）：响应客户端发出的身份验证请求。 包含AS_REQUEST和AS_REPLY部分，客户端获得票证授予票证（Ticket Granting Ticket） 即TGT；
-
票证授予服务器（Ticket Granting Server）：向客户端发出票证授予服务（TGS）。 包含TGS_REQUEST和TGS_REPLY部分，客户端获取TGS，允许客户端对网络上可访问的服务进行身份验证；
-
KDC数据库: 存储所有KDC密钥（客户端和服务的密钥），以及与Kerberos帐户（创建日期，策略等）相关的一些信息；
通常情况下，KDC服务应该安装在网络上特定的服务器上，专用于提供Kerberos服务， 主要是出于安全目的：由于KDC存储包含所有密钥的数据库，如果KDC密钥数据库遭到泄漏，那么攻击者可以模拟存储在KDC数据库中的任何服务和客户端。
Kerberos帐户通过主体（Principal）命名，相当于Unix帐户的用户名。
接下来我们将专注于介绍Kerberos 5机制。
3. 身份验证机制 – 票证授予票证
身份验证机制是Kerberos认证机制中进行的第一步，它为用户提供票证授予票证（TGT），通过该票据，可以访问特定的在Kerberos KDC注册的服务，进行单点登录等。
第1步：验证服务请求-AS_REQUEST
以纯文本形式发送到KDC的第一条消息。AS_REQUEST包含：
?客户的主体名称 （Principal Name）;
?票证授予服务器的主体（称为“krbtgt principal”，用于获得TGS）；
?客户端时间戳；
?请求的票据有效期（通常为8至10小时）；
KDC收到AS_REQUEST消息，检查客户端的Principal是否在数据库中匹配，以及客户端计算机与KDC之间的时间戳是否足够接近（通常间隔为3到5分钟）。
如果必须进行预认证（Pre-Authentication），KDC将不会立即返回TGT，它将发送NEEDED_PREAUTH消息，并要求客户端在返回TGT之前提供一些预认证数据。通常情况下，使用的方法是PA-ENC-TIMESTAMP，其中当前时间戳使用用户密钥加密，客户端即是用户的密码。
在这种情况下，客户端将重新发送AS_REQUEST消息，这次包含加密时间戳。如果预认证成功，KDC将返回TGT; 接下来就是AS_REPLY步骤。
第2步：验证服务响应-AS_REPLY
上述第一步认证通过时，认证服务器（AS）会生成随机会话密钥（random session key）（”short term” key）， KDC为该随机会话密钥生成了两个副本：一个发送给客户端，添加到AS_REPLY消息中，第二个副本用于票证授予服务器（Ticket Granting Server），该会话密钥副本主要用于以后与其他有关的kerberized服务进行协商。
如果客户端成功进行了身份验证，KDC将返回包含Ticket Granting Ticket的AS_REPLY消息。它将存储在某种凭证缓存 （Credential Cache）中，以备将来使用。消息使用用户密钥加密，从而防止别的用户对其进行解码。
AS_REPLY消息由两层组成：第一层消息是由用户密钥加密的，第二层是TGT本身，首先使用Ticket Granting Server的密钥进行加密，然后使用用户密钥重新加密。这样，只有受信任的用户才能解密消息并获得TGT。
AS_REPLY消息的内容如下：
使用用户密钥进行加密的：
?用户的会话密钥副本
?票据的有效期
?krbtgt Principal 名称
使用Ticket Granting Server的密钥先加密，然后再使用用户密钥进行加密，该消息就是TGT：
?会话密钥的副本
?有效的票据有效期
?KDC时间戳
?客户端Principal (client principal)
?客户端IP地址
注意：虽然TGT已解密并缓存到客户端，但其内容却无法在客户端读取。 它使用Ticket Granting Server的密钥进行有效加密，该密钥仅在Ticket Granting Server 中保存。认证过程及机制请见下图所示：
4. 票据授予服务机制 (Ticket Granting Service)
如果客户端已经通过了身份验证机制，并且具有票证授予票证（TGT），假设 用户正在请求访问网络上的特定服务，如Web服务器和文件共享等，那么用户需要票证授予服务（TGS）。
同样，该请求分为两个步骤，TGS_REQUEST和TGS_REPLY。 出于安全原因，这两条消息都是加密的。
第1步：票证授予服务请求-TGS_REQUEST
当用户希望访问kerberized服务时，用户首先必须向服务验证用户本身。 该验证需要将TGS_REQUEST发送给票证授予服务器 （Ticket Granting Server）进行。TGS_REQUEST
消息由以下几个元素组成：
?TGS请求本身，包含服务主体（Service Principal）和请求的生命周期；
?身份验证阶段获得的TGT（成功认证后）；
? 一个 Authenticator
Authenticator是使用在AS过程中获取的临时会话密钥加密的消息，包含用户主体（User Principal）和时间戳， 这样，KDC能够确保此消息来自可以信任的客户，即首先检查先前协商的临时会话密钥，然后通过时间戳来检查消息的时间有效性。
在确认有效的TGT和正确的身份验证后，票证授予服务器将返回TGS。
第2步：票证授予服务响应-TGS_REPLY
在该阶段，KDC服务器生成一组新的会话密钥。
票证授予服务响应消息通过AS阶段获取的会话密钥进行加密， 因此，只有在身份验证阶段向KDC有效识别自己的用户才可能读取其内容，并从中提取TGS。
TGS_REPLY消息包含：
使用通过AS阶段获取的会话密钥加密：
?为用户生成的新的会话密钥
?有效的票据有效期
?服务的主体名称 (Service Principal)
首先使用KDC服务的密钥加密，然后使用AS阶段的临时会话密钥加密。TGS包含的内容如下：
?用于服务的新会话密钥
?有效的票据有效期
?KDC时间戳
?用户主体 (Client Principal)
?客户端IP地址
第3步：访问KDC注册的服务
如果用户获得了TGS，可以用TGS直接向所请求的服务验证自己。该服务可以访问其keytab，Keytab是一个存储服务密钥的文件，此密钥将允许服务解密客户端发送的TGS，并获取识别用户和创建安全上下文所需的所有信息。与TGT过程一样，TGS中的时间戳保证了消息的时效性。
通常情况下，会话密钥用于在客户端和服务之间签名或加密消息，它为客户端和服务提供了一种保证交换消息完整性的方法，并且可以创建安全的上下文，使得截获改变消息变得非常困难。
和其他安全协议相比，Kerberos是对其他安全协议的补充，如TLS / SSL或IPsec;主要区别在于它们是基于非对称加密（RSA），而Kerberos是基于对称加密（DES和AES）构建的。
以下是TGS 交互过程图示如下：
5. 结论
我们可以将Kerberos协议分为三个主要阶段：
1.认证过程(Authentication Process)，其中用户（和Host）获得票证授予票证（TGT）作为认证令牌;
2.服务请求过程(Service Request Process)，用户获得票证授予服务（TGS）以访问服务;
3.服务访问 (Service Access)，用户（和Host）使用TGS进行身份验证和访问特定服务;
图示如下：
