Add files via upload
This commit is contained in:
@@ -0,0 +1,45 @@
|
||||
### Kerberos 的原理
|
||||
|
||||
**Kerberos 的三大核心组件**
|
||||
|
||||
要理解 Kerberos,必须先了解它的三个关键角色:
|
||||
|
||||
1. **客户端(Client)**:想要访问服务的用户或机器
|
||||
2. **服务器(Server)**:提供服务的机器,例如文件服务器、Web 服务器等
|
||||
3. **密钥分发中心(KDC)**:这是 Kerberos 认证的核心,由两部分组成:
|
||||
- **认证服务器(AS - Authentication Server)**:负责验证客户端的身份
|
||||
- **票据授予服务(TGS - Ticket Granting Service)**:负责发放访问特定服务的票据
|
||||
|
||||
**Kerberos 的工作原理:三步认证流程**
|
||||
|
||||
Kerberos 的认证过程可以分为三个主要步骤。整个过程都围绕着**票据(Ticket)**和**会话密钥(Session Key)**展开。
|
||||
|
||||
**第一步:客户端获取“票据授予票据”(TGT)**
|
||||
|
||||
这是 Kerberos 认证的起点
|
||||
|
||||
1. **客户端请求**:客户端向 **AS** 发送一个认证请求,包含它的用户名。**注意,这里没有明文密码**
|
||||
2. **AS 验证**:AS 在其数据库中查找这个用户名。如果找到,它会生成一个**会话密钥**(`Client/TGS Session Key`),并用**客户端的密码哈希**对这个会话密钥进行加密
|
||||
3. **AS 颁发 TGT**:AS 还会生成一个**票据授予票据(TGT - Ticket-Granting Ticket)**。这个 TGT 包含了客户端的身份信息和前面生成的会话密钥,并用**TGS 的密钥**进行加密。AS 将加密后的会话密钥和 TGT 一起返回给客户端
|
||||
4. **客户端解密**:客户端收到响应后,会使用自己的密码哈希来解密会话密钥。**这是整个过程中唯一使用到客户端密码哈希的地方。**如果解密成功,客户端就获得了 TGT 和一个会话密钥
|
||||
|
||||
现在,客户端拥有了 TGT,它可以使用这个票据向 TGS 请求其他服务的访问权限。
|
||||
|
||||
**第二步:客户端请求“服务票据”(ST)**
|
||||
|
||||
当客户端需要访问某个服务时,它会向 **TGS** 请求一个服务票据
|
||||
|
||||
1. **客户端请求**:客户端将 **TGT** 和想要访问的**服务名**发送给 TGS
|
||||
2. **TGS 解密**:TGS 使用自己的密钥解密 TGT。如果解密成功,就证明 TGT 是合法的。TGS 从 TGT 中提取出**客户端/TGS 会话密钥**
|
||||
3. **TGS 颁发 ST**:TGS 生成一个**客户端/服务会话密钥**,并用**客户端/TGS 会话密钥**对其加密。同时,TGS 还生成一个**服务票据(ST - Service Ticket)**,包含了客户端的身份信息和客户端/服务会话密钥,并用**服务端的密钥**加密。TGS 将这两部分一起返回给客户端
|
||||
4. **客户端解密**:客户端使用自己的客户端/TGS 会话密钥来解密,从而获得**客户端/服务会话密钥**和 **ST**
|
||||
|
||||
现在,客户端拥有了 ST,它可以拿着这个票据去访问目标服务
|
||||
|
||||
**第三步:客户端访问服务**
|
||||
|
||||
这是认证的最后一步,也是 Kerberos 核心安全性的体现
|
||||
|
||||
1. **客户端请求**:客户端将 **ST** 和一个**认证数据**(Authenticator)发送给目标服务器。认证数据中包含一个时间戳,并用**客户端/服务会话密钥**加密
|
||||
2. **服务器解密**:服务器使用自己的密钥解密 **ST**,提取出**客户端/服务会话密钥**。然后,服务器使用这个会话密钥解密**认证数据**,并检查时间戳是否有效
|
||||
3. **服务器验证**:如果所有检查都通过,服务器就认为客户端是合法的,并允许其访问服务
|
||||
Reference in New Issue
Block a user