3.Kerberos

3.1.官网

https://web.mit.edu/kerberos/

3.2.前言

3.2.1.概述

Kerberos是一种计算机网络认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。它也指由麻省理工实现此协议，并发布的一套免费软件。

它的设计主要针对客户-服务器模型，并提供了一系列交互认证——用户和服务器都能验证对方的身份。Kerberos协议可以保护网络实体免受窃听和重复攻击。

Kerberos协议基于对称密码学，并需要一个值得信赖的第三方。Kerberos协议的扩展可以为认证的某些阶段提供公钥密码学支持。

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

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

3.2.2.协议内容

协议的安全主要依赖于参加者对时间的松散同步和短周期的叫做Kerberos票据的认证声明。 下面是对这个协议的一个简化描述，将使用以下缩写：
AS（Authentication Server）= 认证服务器
KDC（Key Distribution Center）= 密钥分发中心
TGT（Ticket Granting Ticket）= 票据授权票据，票据的票据
TGS（Ticket Granting Server）= 票据授权服务器
SS（Service Server）= 特定服务提供端

1、客户端用户发送自己的用户名到KDC服务器以向AS服务进行认证。
2、KDC服务器会生成相应的TGT票据，打上时间戳，在本地数据库中查找该用户的密码，并用该密码对TGT进行加密，将结果发还给客户端用户。该操作仅在用户登录或者kinit申请的时候进行。
3、客户端收到该信息，并使用自己的密码进行解密之后，就能得到TGT票据了。这个TGT会在一段时间之后失效，也有一些程序（session manager）能在用户登录期间进行自动更新。当客户端用户需要使用一些特定服务（Kerberos术语中用”principal”表示）的时候，该客户端就发送TGT到KDC服务器中的TGS服务。当该用户的TGT验证通过并且其有访问所申请的服务时，TGS服务会生成一个该服务所对应的ticket和session key，并发给客户端。客户端将服务请求与该ticket一并发送给相应的服务端即可。具体的流程请看下面的描述。

简单地说，用户先用共享密钥从某认证服务器得到一个身份证明。随后，用户使用这个身份证明与SS通信，而不使用共享密钥。

3.2.3 3次通信和其它知识点

3.2.3.1.其它知识点

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

3.2.3.2.Kerberos会经过3次通信

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

3.2.4.第一次通信（你和验证服务）

图 1 第一次通信

如果想要获取http服务，你首先要向KDC表名你自己的身份。这个过程可以在你的程序启动时进行。Kerberos可以通过kinit获取。介绍自己通过未加密的信息发送至KDC获取Ticket Granting Ticket (TGT)。
一、信息包含
你的用户名/ID
你的IP地址
TGT的有效时间
Authentication Server收到你的请求后，会去数据库中验证，你是否存在。注意，仅仅是验证是否存在，不会验证对错。
如果存在，Authentication Server会产生一个随机的Session key(可以是一个64位的字符串)。这个key用于你和Ticket Granting Server (TGS)之间通信。
二、回送信息
Authentication Server同样会发送两部分信息给你，一部分信息为TGT，通过KDC自己的密码进行加密，包含：
你的name/ID
TGS的name/ID
时间戳
你的IP地址
TGS的生命周期
TGS session key

另外一部分通过你的密码进行加密，包含的信息有：
TGS的name/ID
时间戳
生命周期
TGS session key

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

3.2.5. 第二次通信（你和TGS）

图 2 第二次通信
如果第一部分你已经成功，你已经拥有无法解密的TGT和一个TGS Session Key。
一、请求信息
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再进行验证：
1.对比TGT中的用户名与认证器中的用户名
2.比较时间戳（网上有说认证器中的时间戳和TGT中的时间戳，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围。
3.检查是否过期
4.检查IP地址是否一致
5.检查认证器是否已在TGS缓存中（避免应答攻击）
6.可以在这部分添加权限认证服务。
TGS随机产生一个Http Service Session Key，同时准备Http Service Ticket(ST)

二、回答信息
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。

3.2.6.第三次通信（你和Http服务）

图 3 第三次通信

在前面两步成功后，以后每次获取Http服务，在Ticket没有过期，或者无更新的情况下，都可直接进行这一步。省略前面两个步骤。
一、请求信息
A:通过Http Service Session Key，加密部分。
你的name/ID
时间戳

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

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

二、应答信息
A:通过Http Service Session Key加密的信息。
Http服务name/ID
时间戳

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