网站维护 费用外链购买平台

Kerberos快速入门之基本概念与认证基本原理

MIT Kerberos官网： MIT Kerberos

使用帮助 CentOS 7.3环境中部署Kerberos集群

Kerberos服务的简介

Kerberos 服务是一种通过网络提供安全事务处理的客户机/服务器体系结构。

拥有的服务功能：

1. 用户身份验证。
2. 校验传递的数据的有效性（完整性）
3. 对传输过程中的数据进行加密（保密性）。

Kerberos 服务是单点登录系统，这意味着您对于每个会话只需向服务进行一次自我验证，即可自动保护该会话过程中所有后续事务的安全。

基本概念

Realm

表示Kerberos 中的一个领，同一主 KDC 的一组系统的逻辑网络，类似服务网络，不同 Kerberos 环境，可以通过 realm 进行区分。一个Kerberos服务中可以包含多个领域，实现同时对多个领域的管理。实际使用过程中，为了简单化，就是一套Kerberos 服务器就只管理一个realm。

Principal

主体名称，可以理解为账户或者身份标识。

principal 主要由三部分构成：primary，instance(可选) 和 realm。包含 instance 的 principal，一般会作为 server 端的 principal。

示例

## hadoop.com域下，以nn用户启动的NameNode服务
nn/hadoop3test1-01.test.com@hadoop.com
## hadoop.com域下的普通用户
gudong@hadoop.com

创建用户 principal 时通常应使用 +requires_preauth -allow_svr 选项，以帮助减少字典攻击（请参阅 “应对字典攻击风险”）。

字典攻击

Keytab

秘钥文件，里面可以包含一个或多个Principal的密码信息的文件，可以被用来与KDC进行身份认证。

Ticket

票据，Client与KDC交互后，生成的包含身份信息的文件。

Ticket 有两种生命周期：

• Ticket Timelife： 票据生命周期，票据的过期期限。
• Renewable Lifetime：可再生周期，可以将票据的生效周期一直续期，直到达到可再生周期的限制。

KDC

Key Distribution Center，密钥分发中心有三个核心组成

1. Kerberos Database(KDB)：账户数据库，包含了一个realm下的所有账户信息。
2. Authentication Server(AS)：身份验证服务，进行用户信息认证，为客户端提供 Ticket Granting Tickets(TGT) 票证授予票证。
3. Ticket Granting Server(TGS)：票证授予服务，验证 TGT 与 Authenticator，为客户端提供 Service Tickets。

Kerberos 认证基本原理

Ticket-Granting Ticket（TGT）：票据中心授予票，Client与Kerberos认证过程中的票据。
Service Ticket：Client与Application Server通信用

1. Client发送明文消息给AS

明文消息包含：

• Client的ID/NAME(标识)
• 请求访问服务的的ID/NAME(标识)
• Client的网络地址（可以是多台机器的IP地址的列表，如果想在任何一台机器上使用，即为空）
• 请求的TGT有效期

2. AS验证

1. 检查Client的ID是否存在于KDB中
2. 若AS检查没有异常（用户不存在报异常），KDC会随意生成一个Session Key，用于Client与TGS的通信

3. AS发送消息给Client，消息为两条密文

1. 第一条消息，由Client的秘钥加密。
   • 请求访问服务的的ID/NAME
   • 时间戳
   • 有效期
   • TGS 的 Session Key
2. 第二条消息，由TGS的秘钥加密。
   • Client的ID/NAME
   • 请求访问服务的的ID/NAME
   • Client的网络地址（可以是多台机器的IP地址的列表，如果想在任何一台机器上使用，即为空）
   • TGT 的有效期
   • TGS 的 Session Key

4. Client处理AS过来的密文消息

1. 利用本地（Client）的秘钥解密第一条消息，为了获取其中的TGS Session Key，如果无法解密，则代表认证失败。
2. Client无法解密TGT，将其保存在认证缓存中。

5. Client发送消息给TGS

1. 第一条消息，消息内有：
   • 请求访问服务的的ID/NAME(标识)
   • 服务票据的有效期
2. 第二条消息，使用TGS Session Key加密的身份认证器（Authenticator），包含：
   • Client的ID/NAME
   • 时间戳
3. 第三条消息，TGT
   • 即由AS发送给Client的TGT

6. TGS验证消息

1. TGS检查Client请求访问服务的ID/NAME是否KDB中。
2. 若检查成功，则利用TGS的秘钥解析TGT，得到TGS Session Key。
3. 若TGT解析成功，再用TGS Session Key从Authenticator中解析出Client消息。
4. TGS检查项
   • 比较Authenticator中的Client ID与TGT中的Client ID
   • 比较Authenticator中的时间戳和TGT中的时间戳
   • 检查TGT的有效期是否过期
   • 检查Authenticator是否已经在TGS的缓存中（避免重放攻击）
   • 若原始请求中的网络地址不为空，则比较源IP与TGT中的网络地址（请求中的网络地址列表）
5. 若通过上述的TGS的检查项，TGS会随机生成一个请求服务的Session Key，简写为SSK。

7. TGS发送消息给Client，消息为两条密文

1. 第一条消息有TGS Session Key 加密，包含内容：
   • 请求访问服务的ID/NAME
   • 时间戳
   • 验证过票据的有效期
   • 请求访问服务的Session Key
2. 第二条消息Service Ticket，由SSK加密，包含内容：
   • Client的ID/NAME
   • 请求访问服务的ID/NAME
   • Client的网络地址（可以是多台机器的IP地址的列表，如果想在任何一台机器上使用，即为空）
   • 时间戳
   • 有效票据的有效期
   • 请求访问服务的Session Key

8. Client处理TGS过来的消息

1. 利用TGS Session Key解析第一条消息，得到请求服务的Session Key
2. Client无法解密Service Ticket。

9. Client发送消息给Appcaition Server

1. 请求服务的Service Ticket。
2. 由请求服务的Session Key加密的Authenticator，消息包含：
   • Client的ID/NAME
   • 时间戳

10. Appcaition Server验证Client的消息

1. APS利用自身的秘钥从Service Ticket中解析出SSK。
2. 再用解析出来的SSK，从Authenticator中解析出Client信息。
3. Appcaition Server检查项
   • 比较Authenticator中的Client ID与Service Ticke中的Client ID
   • 比较Authenticator的时间戳与Service Ticke中的时间戳的差值，2min以内，2min属于可配置。
   • 检查Service Ticke是否过期
   • 检查Authenticator是否已经在Appcaition Server的缓存中（避免重放攻击）
   • 若原始请求中的网络地址不为空，则比较源IP与Service Ticke中的网络地址（请求中的网络地址列表）
4. 检查通过后，Appcaition Serve将发送由SSK加密的消息给Client，消息包含：
   • Service ID
   • 时间戳

11. Client处理Appcaition Server过来的消息

1. Client使用缓存中的SSK解析消息，得到消息中的Service ID和时间戳。
2. 校验消息的内容，这个服务是不是Client需要访问的服务ID，若校验通过，则代表Client与Appcaition Server完成身份认证。
3. 继续使用缓存中的Service Ticke与Appcaition Server通信，直到服务票据过期。

参考
Explain like I’m 5: Kerberos
MIT Kerberos