Kerberos安全体系简介

1.  Kerberos简介

1.1. 功能

一个安全认证协议

用tickets验证

避免本地保存密码和在互联网上传输密码

包含一个可信任的第三方

使用对称加密

客户端与服务器（非KDC）之间能够相互验证

 

Kerberos只提供一种功能——在网络上安全的完成用户的身份验证。它并不提供授权功能或者审计功能。

 

1.2. 概念

首次请求，三次通信方

 

the AuthenticationServer

 

the Ticket GrantingServer

 

the Service or host machine that you’re wanting access to.

其他知识点

 

每次通信，消息包含两部分，一部分可解码，一部分不可解码

服务端不会直接有KDC通信

KDC保存所有机器的账户名和密码

KDC本身具有一个密码

 

2.  3次通信

 

第一次通信

 

2.1. 你和验证服务

如果想要获取http服务，你首先要向KDC表名你自己的身份。这个过程可以在你的程序启动时进行。Kerberos可以通过kinit获取。介绍自己通过未加密的信息发送至KDC获取Ticket Granting Ticket (TGT)。

 

（1）请求信息

你的用户名/ID

你的IP地址

TGT的有效时间

 

　　AuthenticationServer收到你的请求后，会去数据库中验证，你是否存在。注意，仅仅是验证是否存在，不会验证对错。

 

如果存在，AuthenticationServer会产生一个随机的Session key(可以是一个64位的字符串)。这个key用于你和Ticket Granting Server (TGS)之间通信。

 

（2）回送信息

　　AuthenticationServer同样会发送两部分信息给你，一部分信息为TGT，通过KDC自己的密码进行加密，包含：

 

你的name/ID

TGS的name/ID

时间戳

你的IP地址

TGT的生命周期

TGS session key

 

另外一部分通过你的密码进行加密，包含的信息有

TGS的name/ID

时间戳

生命周期

TGS session key

 

第一次通信交换的信息

 

如果你的密码是正确的，你就能解密第二部分信息，获取到TGS session key。如果，密码不正确，无法解密，则认证失败。第一部分信息TGT，你是无法解密的，但需要展示缓存起来。

 

 

 

第二次通信

 

2.2. 你和TGS

如果第一部分你已经成功，你已经拥有无法解密的TGT和一个TGS Session Key。

（1）      请求信息

a)  通过TGS Session Key加密的认证器部分：

你的name/ID

时间戳

b)明文传输部分：

请求的Http服务名（就是请求信息）

HTTP Service的Ticket生命周期

 

c) TGT部分

 

　　Ticket GrantingServer收到信息后，首先检查数据库中是否包含有你请求的Http服务名。如果无，直接返回错误信息。

 

如果存在，则通过KDC的密码解密TGT，这个时候。我们就能获取到TGSSession key。然后，通过TGS Session key去解密你传输的第一部分认证器，获取到你的用户名和时间戳。

 

TGS再进行验证：

 

对比TGT中的用户名与认证器中的用户名

比较时间戳（网上有说认证器中的时间戳和TGT中的时间戳，个人觉得应该是认证器中的时间戳和系统的时间戳？），不能超过一定范围

检查是否过期

检查IP地址是否一致

检查认证器是否已在TGS缓存中（避免应答攻击）

可以在这部分添加权限认证服务

　　TGS随机产生一个HttpService Session Key, 同时准备Http Service Ticket(ST)。

 

（2）      回答信息

 

a)通过Http服务的密码进行加密的信息（ST）：

你的name/ID

Http服务name/ID

你的IP地址

时间戳

ST的生命周期

Http Service Session Key

 

b)通过TGS Session Key加密的信息

Http服务name/ID

时间戳

ST的生命周期

Http Service Session Key

　　你收到信息后，通过TGS Session Key解密，获取到了Http Service Session Key，但是你无法解密ST。

 

第二次通信交换的信息

 

 

第三次通信

 

2.3. 你和Http服务

　　在前面两步成功后，以后每次获取Http服务，在Ticket没有过期，或者无更新的情况下，都可直接进行这一步。省略前面两个步骤。

 

（1）      请求信息

 

a)通过Http Service Session Key，加密部分

你的name/ID

时间戳

 

b)ST

检查认证器是否已在HTTP服务端的缓存中（避免应答攻击）

 

Http服务端通过自己的密码解压ST（KDC是用Http服务的密码加密的），这样就能够获取到Http Service Session Key，解密第一部分。

服务端解密好ST后，进行检查

 

对比ST中的用户名（KDC给的）与认证器中的用户名

比较时间戳（网上有说认证器中的时间错和TGT中的时间错，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围

检查是否过期

检查IP地址是否一致

 

(2)应答信息

 

a)通过Http Service Session Key加密的信息

Http服务name/ID

时间戳

 

第三次通信交换的信息

 

你在通过缓存的Http ServiceSession Key解密这部分信息，然后验证是否是你想要的服务器发送给你的信息。完成你的服务器的验证。

 

至此，整个过程全部完成。