Kerberos简介
Kerberos是一个计算机网络安全协议，旨在通过使用对称密钥加密来为客户端-服务器应用程序提供强大的身份验证。Kerberos由麻省理工学院（MIT）开发，是MIT的Athena项目的一部分，现已成为广泛使用的网络安全标准。
核心概念
- 对称密钥加密：
- Kerberos使用对称密钥加密技术，即同一个密钥用于加密和解密信息。
- 这种加密方式确保了在通信过程中，只有拥有正确密钥的双方才能解密消息。
- 票据机制：
- Kerberos使用票据（ticket）机制来验证用户身份，而不是直接传输密码。
- 票据是经过加密的凭证，证明用户的身份并允许访问特定服务。
- 可信第三方：
- Kerberos使用一个可信的第三方，称为密钥分发中心（KDC），负责管理密钥和票据。
- KDC包含两个主要组件：认证服务器（AS）和票据授予服务器（TGS）。
优势
- 强大的安全性：
- 使用对称密钥加密和票据机制，确保身份验证的安全性。
- 避免在网络上传输明文密码，减少密码泄露的风险。
- 集中化管理：
- 集中化的密钥和票据管理，使得用户和服务的身份验证更为高效和可控。
- 广泛适用性：
- 支持多种操作系统和网络协议，适用于企业级和跨平台的身份验证需求。
- 单点登录（SSO）：
- 支持单点登录功能，用户只需一次身份验证即可访问多个服务。
应用场景
- 企业网络安全：
- 用于企业内部网络的身份验证和访问控制。
- 提供安全的用户身份验证和授权管理。
- 跨平台身份验证：
- 支持Windows、Linux、Unix等多种操作系统，适用于跨平台的身份验证需求。
- 大数据和分布式系统：
- 常用于大数据平台（如Apache Hadoop）的安全认证，确保数据访问的安全性。
- 单点登录系统：
- 用于实现单点登录，简化用户的身份验证过程。
Kerberos的工作原理
Kerberos的组件
在古希腊神话故事中，Kerberos是一只具有三颗头颅的地狱恶犬，他守护在地狱之外，能够识别所有经此路过的亡灵，防止活着的入侵者闯入地狱。而真正的Kerberos协议中也存在三个角色，分别是：
- 客户端：
- 请求访问服务的用户或应用程序。
- 负责与KDC交互以获取票据。
- 密钥分发中心（KDC）：
- 负责管理用户和服务的密钥和票据。
- 包括认证服务器（AS）和票据授予服务器（TGS）。
- 服务服务器：
- 提供用户访问的资源或服务。
- 验证用户提供的票据，并根据票据授权访问。
证明我就是我
在Kerberos协议中，通信的双方在通信之前必须相互证明自己的身份是可靠并且具有访问权限的，那么双方都要如何证明自己呢？客户端的请求中携带自己的身份。信息直接给服务端，服务端是没有理由直接信任这段信息就是真实的信息的，同理，服务端返回自己的身份信息给客户端，客户端也同样是无法辨别该服务器是否是自己想要访问的服务器。
举个例子，A现在想要去访问B完成一个任务。但是AB两人之间是从来没有见过面的，他们只知道对方的名字叫A，B。此时如果A直接去找B告诉B我就是A，那么B是有理由不相信A的，因为即使A是一个冒充的他也分辨不清，B同理也得不到A的认可，他们陷入了一个无法证明我就是我的困境。于是他们就想到了一个办法，AB找到了一个他俩共同信任的人C，且这个C既认识A又认识B，所以只要C告诉B，这个A确实就是真正的A那么B就会信任这个A，同理B经过C的认可后，A也会相信B的身份。
此后，A在访问B之前会先去找C，C会交给A一个凭证，代表此时的A已经得到了C的认证，这时A拿着凭证再去找C，便可以得到C的确认了。
在上面的例子中，A，B分别是客户端和服务端，C担任的角色便是KDC，全称Key Distribution Center，中文名叫做密钥分发中心。KDC中包含一个叫做TGS（票据授予中心）的组件，我们便可以理解为他就是一个发放身份认证票据的服务中心，在KDC认证了（其实是KDC中的AS认证的）客户端的身份后，他会给客户端发放用于访问网络服务的服务授予票据（Ticket）。由于整个Kerberos通信过程都采用对称加密的方式，密钥的获取也是从KDC中得到，所以KDC叫做密钥分发中心。
整个Kerberos认证流程可以简化描述如下：
客户端在访问每个想要访问的网络服务时，他需要携带一个专门用于访问该服务并且能够证明自己身份的票据，当服务端收到了该票据他才能认定客户端身份正确，向客户端提供服务。所以整个认证流程可简化为两大步：
- 客户端向KDC请求获取想要访问的目标服务的服务授予票据（Ticket）；
- 客户端拿着从KDC获取的服务授予票据（Ticket）访问相应的网络服务；
简化认证流程图：
Kerberos认证流程
上面说到了简化版的Kerberos认证流程，基本上分为两步。第一步，客户端向KDC请求获得他想要访问的服务授予票据（可以想象成去动物园，想去买一张能够进入动物园的门票）。第二步，拿着这张服务授予票据（Ticket）去访问服务端的服务。大致的过程确实可以看作这两步，但其中还存在一些问题：
- 问题KDC怎么知道你（客户端）就是真正的客户端？凭什么给你发放服务授予票据（Ticket）呢？
- 问题服务端怎么知道你带来的服务授予票据（Ticket）就是一张真正的票据呢？
上面提到整个流程可以简化为两大步，但其实在第一步中共做了两件事，这两件事解决了上述问题中的问题1；然后第二步解决了问题2，最终结束认证过程建立通信。所以整个Kerberos认证流程可以细化为三个阶段也可以理解为三次通信。
在具体描述整个认证流程之前，我们需要知道几个Kerberos认证的前提条件：
- Kerberos协议他是一个”限权”的认证协议，Kerberos中会自带一个数据库，这个数据库会由创建Kerberos的运维人员提前在库中添加好整个系统中拥有使用Kerberos认证权限的用户和网络服务。在后续的认证中也是根据数据库中是否存在该用户和服务来判断该对象是否能够通过认证服务的。（拿上面的例子来说就是上帝先让C在AB相识之前同时认识A和B，以便后面帮助AB互相认证）
- Kerberos 中存在的三个角色，只要是发生了两两之间的通信，那么都需要先进行身份的认证
所有使用 Kerberos 协议的用户和网络服务，在他们添加进 Kerberos 系统中时，都会根据自己当前的密码（用户密码，人为对网络服务随机生成的密码）生成一把密钥存储在 Kerberos 数据库中，且 Kerberos 数据库也会同时保存用户的基本信息（例如用户名，用户 IP 地址等）和网络服务的基本信息（IP，ServerName）
第一次通信
为了获得能够用来访问服务端服务的票据，客户端首先需要来到 KDC 获得服务授予票据（Ticket）。由于客户端是第一次访问 KDC，此时 KDC 也不确定该客户端的身份，所以第一次通信的目的为 KDC 认证客户端身份，确认客户端是一个可靠且拥有访问 KDC 权限的客户端，过程如下：
- 客户端用户向 KDC 以明文的方式发起请求。该次请求中携带了自己的用户名，主机 IP，和当前时间戳；
- KDC 当中的 AS（Authentication Server）接收请求（AS 是 KDC 中专门用来认证客户端身份的认证服务器）后去 kerberos 认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性；
- 如果没有该用户名，认证失败，服务结束；如果存在该用户名，则 AS 认证中心便认为用户存在，此时便会返回响应给客户端，其中包含两部分内容：
- 第一部分内容称为 TGT，他叫做票据授予票据，客户端需要使用 TGT 去 KDC 中的 TGS（票据授予中心）获取访问网络服务所需的 Ticket（服务授予票据），TGT 中包含的内容有 kerberos 数据库中存在的该客户端的 Name，IP，当前时间戳，客户端即将访问的 TGS 的 Name，TGT 的有效时间以及一把用于客户端和 TGS 间进行通信的 Session_key(CT_SK)。整个 TGT 使用 TGS 密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情况。
- 第二部分内容是使用客户端密钥加密的一段内容，其中包括用于客户端和 TGS 间通信的 Session_key(CT_SK), 客户端即将访问的 TGS 的 Name 以及 TGT 的有效时间，和一个当前时间戳。该部分内容使用客户端密钥加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而终端认证流程。
- 至此，第一次通信完成。
第二次通信
此时的客户端收到了来自 KDC（其实是 AS）的响应，并获取到了其中的两部分内容。此时客户端会用自己的密钥将第二部分内容进行解密，分别获得时间戳，自己将要访问的 TGS 的信息，和用于与 TGS 通信时的密钥 CT_SK。首先他会根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于 5 分钟，如果大于五分钟则认为该 AS 是伪造的，认证至此失败。如果时间戳合理，客户端便准备向 TGS 发起请求，其次请求的主要目的是为了获取能够访问目标网络服务的服务授予票据 Ticket（进入动物园需要的门票）。在第二次通信请求中，客户端将携带三部分内容交给 KDC 中的 TGS，第二次通信过程具体如下所述：
客户端行为：
- 客户端使用 CT_SK 加密将自己的客户端信息发送给 KDC，其中包括客户端名，IP，时间戳；
- 客户端将自己想要访问的 Server 服务以明文的方式发送给 KDC；
- 客户端将使用 TGS 密钥加密的 TGT 也原封不动的也携带给 KDC；
TGS 行为：
- 此时 KDC 中的 TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的 Server 服务 IP 查看当前 kerberos 系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束，。如果存在，继续接下来的认证。
- TGS 使用自己的密钥将 TGT 中的内容进行解密，此时他看到了经过 AS 认证过后并记录的用户信息，一把 Session_KEY 即 CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。
- 如果时延正常，则 TGS 会使用 CK_SK 对客户端的第一部分内容进行解密（使用 CT_SK 加密的客户端信息），取出其中的用户信息和 TGT 中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。
- 此时 KDC 将返回响应给客户端，响应内容包括：
- 第一部分：用于客户端访问网络服务的使用 Server 密码加密的 ST（Server Ticket），其中包括客户端的 Name，IP，需要访问的网络服务的地址 ServerIP，ST 的有效时间，时间戳以及用于客户端和服务端之间通信的 CS_SK（Session Key）。
- 第二部分：使用 CT_SK 加密的内容，其中包括 CS_SK 和时间戳，还有 ST 的有效时间。由于在第一次通信的过程中，AS 已将 CT_SK 通过客户端密码加密交给了客户端，且客户端解密并缓存了 CT_SK，所以该部分内容在客户端接收到时是可以自己解密的。
至此，第二次通信完成。
第三次通信
此时的客户端收到了来自 KDC（TGS）的响应，并使用缓存在本地的 CT_SK 解密了第二部分内容（第一部分内容中的 ST 是由 Server 密码加密的，客户端无法解密），检查时间戳无误后取出其中的 CS_SK 准备向服务端发起最后的请求。
- 客户端：客户端使用 CK_SK 将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将 ST（服务授予票据）作为第二部分内容都发送给服务端。
- 服务端：服务器此时收到了来自客户端的请求，他会使用自己的密钥，即 Server 密钥将客户端第二部分内容进行解密，核对时间戳之后将其中的 CS_SK 取出，使用 CS_SK 将客户端发来的第一部分内容进行解密，从而获得经过 TGS 认证过后的客户端信息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了 KDC 认证的具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用 CT_SK 加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的 CS_ST 解密之后也确定了服务端的身份（其实服务端在通信的过程中还会使用数字证书证明自己身份）。
至此，第三次通信完成。此时也代表着整个 kerberos 认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。
总结
整个 kerberos 认证的过程较为复杂，三次通信中都使用了密钥，且密钥的种类一直在变化，并且为了防止网络拦截密钥，这些密钥都是临时生成的 Session Key，即他们只在一次 Session 会话中起作用，即使密钥被劫持，等到密钥被破解可能这次会话都早已结束。这为整个 kerberos 认证过程保证了较高的安全性。以下补充两个 kerberos 认证的整体流图，一个是 kerberos 认证的时序图，一个是 kerberos 认证的示意图。
示意图：
时序图：
参考链接：
