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

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

引用

CSDN

1.

https://blog.csdn.net/m0_62832001/article/details/143863132

前言

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

名词：

• Client：访问服务的客户端
• Server：提供服务的服务器
• KDC (Key Distribution Center)：密钥分发中心
• AS (Authentication Service)：认证服务器
• TGS (Ticket Granting Service)：票据授予服务
• DC (Domain Controller)：域控制器
• AD (Account Database)：用户数据库
• TGT (Ticket Granting Ticket)：票据授予票证
• ST (Server 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认证也就完成了，接下来客户端与服务端就能放心的进行通信了