1.1. 功能

• 一个安全认证协议
• 用tickets验证
• 避免本地保存密码和在互联网上传输密码
• 包含一个可信任的第三方
• 使用对称加密
• 客户端与服务器（非KDC）之间能够相互验证
  
  

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

1.2. 概念

首次请求，三次通信方

• the Authentication Server
• the Ticket Granting Server
• the Service or host machine that you’re wanting access to.
  

图 1‑1 角色

其他知识点

• 每次通信，消息包含两部分，一部分可解码，一部分不可解码
• 服务端不会直接有KDC通信
• KDC保存所有机器的账户名和密码
• KDC本身具有一个密码
  

2.  3次通信

　　我们这里已获取服务器中的一张表（数据）的服务以为，为一个http服务。

2.1. 你和验证服务

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

（1）信息包含

• 你的用户名/ID
• 你的IP地址
• TGT的有效时间
  

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

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

（2）回送信息

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

• 你的name/ID
• TGS的name/ID
• 时间戳
• 你的IP地址
• TGT的生命周期
• TGS session key
  

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

• TGS的name/ID
• 时间戳
• 生命周期
• TGS session key
  

图 2‑1 第一次通信

　　如果你的密码是正确的，你就能解密第二部分信息，获取到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 Granting Server收到信息后，首先检查数据库中是否包含有你请求的Http服务名。如果无，直接返回错误信息。

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

TGS再进行验证：

• 对比TGT中的用户名与认证器中的用户名
• 比较时间戳（网上有说认证器中的时间错和TGT中的时间错，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围
• 检查是否过期
• 检查IP地址是否一致
• 检查认证器是否已在TGS缓存中（避免应答攻击）
• 可以在这部分添加权限认证服务
  

　　TGS随机产生一个Http Service 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‑2 第二次通信

2.3. 你和Http服务

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

（1）    请求信息

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

• 你的name/ID
• 时间戳
  

　　b)       ST

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

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

• 对比ST中的用户名（KDC给的）与认证器中的用户名
• 比较时间戳（网上有说认证器中的时间错和TGT中的时间错，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围
• 检查是否过期
• 检查IP地址是否一致
• 检查认证器是否已在HTTP服务端的缓存中（避免应答攻击）
  

（2）    应答信息

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

• Http服务name/ID
• 时间戳
  

图 2‑3 第三次通信

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

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

1.1. 功能

• 一个安全认证协议
• 用tickets验证
• 避免本地保存密码和在互联网上传输密码
• 包含一个可信任的第三方
• 使用对称加密
• 客户端与服务器（非KDC）之间能够相互验证
  
  

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

1.2. 概念

首次请求，三次通信方

• the Authentication Server
• the Ticket Granting Server
• the Service or host machine that you’re wanting access to.
  

图 1‑1 角色

其他知识点

• 每次通信，消息包含两部分，一部分可解码，一部分不可解码
• 服务端不会直接有KDC通信
• KDC保存所有机器的账户名和密码
• KDC本身具有一个密码
  

2.  3次通信

　　我们这里已获取服务器中的一张表（数据）的服务以为，为一个http服务。

2.1. 你和验证服务

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

（1）信息包含

• 你的用户名/ID
• 你的IP地址
• TGT的有效时间
  

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

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

（2）回送信息

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

• 你的name/ID
• TGS的name/ID
• 时间戳
• 你的IP地址
• TGT的生命周期
• TGS session key
  

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

• TGS的name/ID
• 时间戳
• 生命周期
• TGS session key
  

图 2‑1 第一次通信

　　如果你的密码是正确的，你就能解密第二部分信息，获取到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 Granting Server收到信息后，首先检查数据库中是否包含有你请求的Http服务名。如果无，直接返回错误信息。

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

TGS再进行验证：

• 对比TGT中的用户名与认证器中的用户名
• 比较时间戳（网上有说认证器中的时间错和TGT中的时间错，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围
• 检查是否过期
• 检查IP地址是否一致
• 检查认证器是否已在TGS缓存中（避免应答攻击）
• 可以在这部分添加权限认证服务
  

　　TGS随机产生一个Http Service 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‑2 第二次通信

2.3. 你和Http服务

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

（1）    请求信息

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

• 你的name/ID
• 时间戳
  

　　b)       ST

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

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

• 对比ST中的用户名（KDC给的）与认证器中的用户名
• 比较时间戳（网上有说认证器中的时间错和TGT中的时间错，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围
• 检查是否过期
• 检查IP地址是否一致
• 检查认证器是否已在HTTP服务端的缓存中（避免应答攻击）
  

（2）    应答信息

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

• Http服务name/ID
• 时间戳
  

图 2‑3 第三次通信

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

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