Kerberos 认证协议

Kerberos 认证协议

Kerberos 认证协议是基于对称密钥的认证协议，在详细描述 Kerberos 之前，要先讲两个重要的概念：

1. Master Key：又叫 Long-term Key，这样的 Key 可能长期保持不变，用其加密的数据应该尽可能少的在网络中传输。因为一旦这些数据包被截获，只要有充足的时间，总是可以被破解的。
2. Session Key，又叫 Short-term Key，因为 Long-term Key 加密的数据要尽量少的在网络中传输，所以使用 Short-term Key 来加密平常传输的数据。这种 Key 只存在一段时间，所以即使加密的包被截获被破解了，Key 也可能早已过期了。

身份认证解决的是“如何证明某个人确确实实就是他或她所声称的那个人”的问题。一个基本的方法是：如果一个秘密（secret）仅仅存在于 A 和 B，那么有个人对 B 声称自己就是 A，B 通过让 A 提供这个秘密来证明这个人就是他或她所声称的 A。这个过程涉及到三个方面：

1. Secret 如何表示？
2. A 如何向 B 提供 Secret
3. B 如何识别 Secret

在 Kerberos 协议里，KDC（Key Distribution Center）负责协调 Client、Server 之间的通信，为其分配 Secret。
Client、Server 与 KDC 交互时靠什么做身份认证呢？同样有一个 Secret，这里叫 Master Key，是“管理员”预先分配好的，KDC 里保存了所有用户（包含 Client、Server）的 Master Key。相对的 Client、Server 交互使用的 Secret 可以称为 Session Key。

上图的设计有两个问题：

1. Server 要记录每一个 Client 的 Session Key，太耗费资源
2. 同一个 Key 要同时同步到 Session Key、Server 是比较难的，当 Session Key 需要定期更新时同步就更难了

Kerberos 是如何解决这两个问题的呢？KDC 返给 Client 两份数据，一份是用 Client Master Key 加密的 Session Key，一份是用 Server Master Key 加密的 Ticket，包含以下内容：Session Key、Client 身份标识、有效期 Timestamp。第一份数据可供 Client 解密拿到 Session Key，第二份数据即 Ticket 需要 Client 访问 Server 时带上，Server 解密即可得到 Session Key。

按照 master key 要尽量少用的原则来看，上述交互还有两个个问题：

1. Client 与 KDC 交互用的是 Master Key
2. Ticket 加密用的还是 Server 的 Master Key

针对问题 1，将 KDC 拆分为两个：AS 和 TGS，Client 在启动时去 AS 拿一个凭据 TGT 和后续与 TGS 交互的 Session Key，这里 TGT 的作用和 Client、Server 交互使用的 Ticket 类似，也就是 Client 与 TGS 交互的 Ticket。拿到 TGT 后，Client 可带着 TGT 去 TGS 来拿与 Server 交互的 Ticket。

针对问题 2，可以让 Client 先去 Server 拿一下 Server 与 TGS 交互的 TGT，然后带着一起去 TGS 拿 Ticket，TGS 会解密 Server 的 TGS 拿到 Server 与 TGS 交互的 Session Key，用其来加密 Ticket。

经过这两个改造后，Master Key 仅用在 Client 刚启动时获取 TGT 上了，其他交互都使用了 Session Key，完整的交互流程如下图所示，可分为四步：

1. Client 使用 Master Key 加密身份信息和数据，访问 AS，得到与 TGS 交互的 TGT 和 Session Key
2. Client 获取 Server 与 TGS 交互的 TGT
3. Client 使用 TGS 的 Session Key 加密身份信息和数据，并带着 client 的 TGT、server 的 TGT 访问 TGS，拿到与 Server 交互的 Ticket 和 Session Key
4. Client 用 Session Key 加密身份信息和数据，并带着 Ticket 访问 Server