Kerberos协议认证原理/过程（详细易理解）

前言

为了方便理解，我们先了解一些名词，然后附上一张图片方便理解过程（最后有超精简版流程，适合详细过程记不住的小伙伴）

名词：

Client: 访问服务的客户端

Server: 提供服务的服务器

KDC (Key Distribution Center): 密钥分发中心：

       

        AS (Authentication Service): 认证服务器

        TGS (Ticket Granting Service): 票据授予服务

DC (Domain Controller): 域控制器

AD (Account Database): 用户数据库

TGT (Ticket Granting Ticket): 票证授予票证        

ST (Servre Ticket): 服务票据

流程图：

认证过程

第一阶段：客户端与认证服务器 (AS) 交互

1.客户端发起请求：客户端将自己的用户名、IP 地址和时间戳发送到 AS，标识身份并防止重放攻击。

2.AS 检查用户是否存在：AS 在 AD 中查找用户是否存在于域中（例如白名单）。如果用户存在，AS 认为用户有效，继续下一步；否则，认证失败。

3. AS 向客户端返回两部分内容：（1）TGT（票据授予票据）：包含客户端信息、IP 地址和时间戳等，经过 TGS 的密钥加密，只有 TGS 能解密和读取其中的内容。（2）会话密钥 (CT_SK) 及其他信息：包括 CT_SK（client+TGS session key）、TGS 信息、TGT有效时间和时间戳。此部分使用客户端密钥加密，客户端用自己的密钥解密以提取 CT_SK 和时间戳。

第一阶段结果：客户端成功获取了 TGT 和用于与 TGS 通信的会话密钥 CT_SK。

第二阶段：客户端与票据授予服务 (TGS) 交互

1.客户端验证 AS 响应的时间戳：客户端检查时间戳是否超过 5 分钟，避免伪造认证。验证通过后，客户端继续与 TGS 通信。

2. 客户端向 TGS 发起请求：请求内容分为三部分：（1）使用 CT_SK 加密的客户端信息、IP 地址和时间戳，用于 TGS 识别客户端身份。（2）客户端希望访问的服务（明文）。（3）TGT，由 AS 生成并加密（这个密钥只有 KDC 中的 TGS 服务知道，只有 TGS 能解密并读取 TGT 中的内容）

3. TGS 验证请求并生成服务票据 (ST)：

TGS 解密 TGT：获取到用户信息和 CT_SK，并通过时间戳确认请求是否有效。

对比信息：TGS 使用 CT_SK 解密客户端发送的第一部分，并验证用户信息一致性，确保客户端身份真实。

生成响应：（1）使用服务端密钥加密的服务票据 ST，包含客户端信息、目标服务信息、ST 有效期、时间戳和会话密钥 CS_SK（client-server session key）（用于客户端和服务端通信）。 （2）使用 CT_SK 加密的内容，包含 CS_SK、时间戳和 ST 有效期，客户端用CT_SK 解密获取这些内容。

第二阶段结果：客户端成功获得服务票据 (ST) 和客户端-服务端会话密钥 CS_SK。

第三阶段：客户端与目标服务交互

1. 客户端向服务端发起请求：请求内容包括两部分：（1）使用 CS_SK 加密的客户端信息和时间戳。（2）使用目标服务的密钥加密的 ST（TGS 返回的ST，ST中包含 CS_SK），客户端无法解密。

2.服务端验证客户端身份：

解密 ST：服务端使用自己的密钥解密 ST，获得客户端信息和会话密钥 CS_SK。

验证信息一致性：使用 CS_SK 解密客户端发送的第一部分内容，核对解密后的客户端信息是否与ST中一致，以确认客户端身份真实性。

3.双向认证确认：服务端向客户端发送确认消息，使用 CS_SK 加密。客户端解密后确认服务端的真实性，从而完成认证。

第三阶段结果：客户端与服务端成功完成双向认证，基于 CS_SK 的安全通信通道建立。至此，第三阶段通信完成，到这里整个 kerberos 认证也就完成了，接下来客户端与服务端就能放心的进行通信了。

超精简版本

第一阶段：客户端与认证服务器 (AS) 交互
结果：客户端成功获取了 TGT 和用于与 TGS 通信的会话密钥 CT_SK
第二阶段：客户端与票据授予服务 (TGS) 交互
结果：客户端成功获得服务票据 (ST) 和客户端-服务端会话密钥 CS_SK
第三阶段：客户端与目标服务交互
结果：客户端与服务端成功完成双向认证，基于 CS_SK 的安全通信通道建立。至此，第三阶段通信完成，到这里整个 kerberos 认证也就完成了，接下来客户端与服务端就能放心的进行通信了