Kerberos身份认证小结

名字起源

Kerberos 一词来源于古希腊神话中的 Cerberus —— 守护地狱之门的三头犬，本篇博客的封面上的那个三头恶犬。在古希腊神话故事中，Kerberos是一只具有三颗头颅的地狱恶犬，他守护在地狱之外，能够识别所有经此路过的亡灵，防止活着的入侵者闯入地狱。

解决的问题

简单来说，这个协议或机制解决的就是“如何证明我就是我”这个问题，即身份认证。

大家应该知道一种有中心的身份认证机制，也就是CA。一种依赖于CA的身份认证，CA认证中心是有中心的，它是采用PKI（Public Key Infrastructure）公开密钥基础架构技术，专门提供网络身份认证服务。即将讲到的Kerberos也是一种有中心的身份认证机制，KDC（Key Distribution Center）即为认证中心。

CA认证：

  • 中心化：CA是一个中心化的实体，负责颁发和管理数字证书。
  • 用途：主要用于公钥基础设施（PKI）中，用于验证和签名证书，以确保通信的安全性。
  • 证书：CA颁发数字证书，包含公钥和相关信息，用于身份验证和加密通信。

KDC认证：

  • 中心化：KDC是Kerberos协议的一部分，也是一个中心化的实体，用于分发密钥。
  • 用途：主要用于Kerberos身份验证，确保用户和服务之间的安全通信。
  • 密钥分发：KDC负责生成会话密钥，以便双方进行加密通信。

总之，CA认证主要用于数字证书的管理，而KDC认证用于Kerberos协议中的身份验证和密钥分发。

Kerberos协议的组成角色

Kerberos在古希腊神话中有三个头，而今天提到的Kerberos协议也有三个缺一不可的角色：

  • 客户端（client）：发送请求的一方
  • 服务端（Server）：接收请求的一方
  • 密钥分发中心（Key Distribution Center，KDC），而密钥分发中心一般又分为两部分，分别是：
    • AS（Authentication Server）：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT（票据授予票据）
    • TGS（Ticket Granting Ticket）：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据

Kerberos如何解决“如何证明我就是我”问题

Kerberos协议当中总共有三个不同的角色，客户端和服务端就不用多说了，一个是请求的发起者，一个是请求的接收者，那么KDC是做什么的呢？

在Kerberos协议中，通信的双方在通信之前必须相互证明自己的身份是可靠并且具有访问权限的（后面会说为什么是要具有访问权限的），那么双方都要如何证明自己呢？口说无凭，客户端的请求中需要携带自己的身份信息。可如果信息直接给服务端，服务端是没有理由直接信任这段信息就是真实的信息的，同理，服务端返回自己的身份信息给客户端，客户端也同样是无法辨别该服务器是否是自己想要访问的服务器。

例子说明：
A现在想要去访问B完成一个任务。但是AB两人之间是从来没有见过面的，他们只知道对方的名字叫A，B。此时如果A直接去找B告诉B我就是A，那么B是有理由不相信A的，因为即使A是一个冒充的他也分辨不了。同理，B也无法得到A的认可。因此就陷入了一个无法“证明我就是我”的困境。
于是AB就想了一个办法：AB找到了一个他俩共同信任的人C，且这个C既认识A又认识B。现在只要C告诉B，这个A确实就是真正的A，那么B就会信任这个A。同理，B经过C的认可后，A也会相信B的身份。此后，A在访问B之前会先去找C，C会交给A一个凭证，代表此时的A已经得到了C的认证，这时A拿着凭证再去找B，便可以得到B的信任了。

在上面的例子中，A，B分别是客户端和服务端，C担任的角色便是KDC，全称Key Distribution Center，中文名叫做密钥分发中心。KDC中包含一个叫做TGS（票据授予中心）的组件，可以理解为他就是一个发放身份认证票据的服务中心，在KDC中的组件AS（Authentication Server）认证了客户端的身份后，会给客户端发放用于访问网络服务的服务授予票据（Ticket）。由于整个Kerberos通信过程都采用对称加密的方式，密钥的获取也是从KDC中得到，所以KDC叫做密钥分发中心。

整个Kerberos认证流程可以简化描述如下：

客户端在访问每个想要访问的网络服务时，需要携带一个专门用于访问该服务并且能够证明自己身份的票据。服务端只有收到了该票据才能认定客户端身份正确，向客户端提供服务。

整个认证流程简化为两大步：

  1. 客户端向KDC请求获取想要访问的目标服务的服务授予票据（Ticket）；
  2. 客户端拿着从KDC获取的服务授予票据（Ticket）访问相应的网络服务；

Kerberos认证过程分析

上文已经提到Kerberos认证流程简化后分为两大步：

  1. 客户端向KDC请求获得他想要访问的服务的服务授予票据
  2. 拿着这张服务授予票据（Ticket）去访问服务端的服务

大致的过程确实可以看作这两步，但其中还存在一些问题：

  1. KDC怎么知道客户端就是真正的客户端？凭什么要给这个客户端发放服务授予票据（Ticket）呢？
  2. 服务端怎么知道客户端带来的服务授予票据（Ticket）就是一张真正的票据呢？

因此，笼统地把Kerberos理解为简单的两步还不够，下面对认证过程做细化分析。

整个认证流程可以简化为两大步，但其实在第一步中一共做了两件事，这两件事就是解决问题1的关键。而第二步是解决问题2的关键，最终结束认证过程建立通信。所以整个Kerberos认证流程可以细化为三个阶段，也可以理解为三次通信!

在具体描述整个认证流程之前，还需要知道几个Kerberos认证的前提条件：

  1. Kerberos协议是一个“限权”的认证协议，Kerberos中会自带一个数据库，这个数据库会由创建Kerberos的运维人员提前在库中添加好整个系统中拥有使用Kerberos认证权限的用户和网络服务。在后续的认证中也是根据数据库中是否存在该用户和服务来判断该对象是否能够通过认证服务的 拿上面的例子来说就是先让C在AB相识之前已经同时认识A和B，以便后面帮助AB互相认证
  2. 所有使用Kerberos协议的用户和网络服务，在被添加进Kerberos系统中时，都会根据自己当前的密码（一种用户密码，人为对网络服务随机生成的密码）生成一把密钥存储在Kerberos数据库中，且Kerberos数据库也会同时保存用户的基本信息（例如用户名，用户IP地址等）和网络服务的基本信息（IP，Server Name）
  3. Kerberos中存在的三个角色，只要是发生了两两之间的通信，都需要先进行身份的认证

第一次通信

为了获得能够用来访问服务端服务的票据，客户端首先需要来到KDC获得服务授予票据（Ticket）。由于客户端是第一次访问KDC，此时KDC也不确定该客户端的身份，所以第一次通信的目的为KDC认证客户端身份，确认客户端是一个可靠且拥有访问KDC权限的客户端，过程如下：

  1. 客户端用户向KDC以明文的方式发起请求。该次请求中携带了自己的用户名，主机IP，和当前时间戳；
  2. KDC当中的AS（Authentication Server）接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后，会去Kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性；
  3. 如果AS发现数据库中没有该用户名，则认证失败，服务结束；如果存在该用户名，那么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，第二次通信过程具体如下所述：

客户端行为：

  1. 客户端使用CT_SK加密将自己的客户端信息发送给KDC，其中包括客户端名，IP，时间戳；
  2. 客户端将自己想要访问的Server服务以明文的方式发送给KDC；
  3. 客户端将使用TGS密钥加密的TGT也原封不动的也携带给KDC；

TGS行为：

  1. 此时KDC中的TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的Server服务IP查看当前Kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束，。如果存在，继续接下来的认证。
  2. TGS使用自己的密钥将TGT中的内容进行解密，此时他看到了经过AS认证过后并记录的用户信息，一把Session_KEY即CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。
  3. 如果时延正常，则TGS会使用CK_SK对客户端的第一部分内容进行解密（使用CT_SK加密的客户端信息），取出其中的用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。
  4. 此时KDC将返回响应给客户端，响应内容包括：
  • 第一部分：用于客户端访问网络服务的使用Server密码加密的ST（Servre Ticket），其中包括客户端的Name，IP，需要访问的网络服务的地址Server IP，ST的有效时间，时间戳以及用于客户端和服务端之间通信的CS_SK（Session Key）。
  • 第二部分：使用CT_SK加密的内容，其中包括CS_SK和时间戳，还有ST的有效时间。由于在第一次通信的过程中，AS已将CT_SK通过客户端密码加密交给了客户端，且客户端解密并缓存了CT_SK，所以该部分内容在客户端接收到时是可以自己解密的。

至此，第二次通信完成。

第三次通信

此时的客户端收到了来自KDC（TGS）的响应，并使用缓存在本地的CT_SK解密了第二部分内容（第一部分内容中的ST是由Server密码加密的，客户端无法解密），检查时间戳无误后取出其中的CS_SK准备向服务端发起最后的请求。

客户端：

  1. 客户端使用CK_SK将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将ST（服务授予票据）作为第二部分内容都发送给服务端。

服务端：

  1. 服务器此时收到了来自客户端的请求，他会使用自己的密钥，即Server密钥将客户端第二部分内容进行解密，核对时间戳之后将其中的CS_SK取出，使用CS_SK将客户端发来的第一部分内容进行解密，从而获得经过TGS认证过后的客户端信息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了KDC认证的具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份（其实服务端在通信的过程中还会使用数字证书证明自己身份）。

至此，第三次通信完成。

此时也代表着整个Kerberos认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。

时序图

总结

整个Kerberos认证的过程较为复杂，三次通信中都使用了密钥，且密钥的种类一直在变化，并且为了防止网络拦截密钥，这些密钥都是临时生成的Session Key，即只在一次Session会话中起作用，即使密钥被劫持，等到密钥被破解可能这次会话都早已结束。
这为整个Kerberos认证过程保证了较高的安全性。