Kerberos 原理

分类：kerberos| 发布时间：2018-11-29 20:38:00

概述

Kerberos 是一个用于鉴定身份（authentication）的协议，它采取对称密钥加密（symmetric-key cryptography），这意味着密钥不会在网络上传输。在 Kerberos 中，未加密的密码（unencrypted password）不会在网络上传输，因此攻击者无法通过嗅探网络来偷取用户的密码。

Kerberos利用对称加密和受信任的第三方（即KDC, key distribution center）来鉴别要求使用网络服务的用户的身份。所有有 KDC 和 KDC 管理的主机构成了一个域（realm）。

关于 Kerberos 的一些概念

Principal 一个用户会以一个独一无二的身份来被 KDC 认证，该身份被称为 Principal。

一个 Principal 由三个部分组成：primary, instance 以及 realm，其组成形式为primary/instance@realm。
- primary 可以是 OS 中的 username，也可以是 service name；
- instance 用于区分属于同一个 user 或者 service 的多个 principals，该项为 optional；
- realm 类似于 DNS 中的 domain，定义了一组 principals
AS（Authentication Server）= 认证服务器
KDC（Key Distribution Center）= 密钥分发中心
TGT（Ticket Granting Ticket）= 票据授权票据，票据的票据
TGS（Ticket Granting Server）= 票据授权服务器
SS（Service Server）= 特定服务提供端

具体流程

Kerberos 的具体流程如下图所示，下面将对其进行具体说明。

用户登录

用户在客户端输入用户名和密码。类似 kinit 的认证工具支持使用密钥代替密码。
客户端将密码转换为对称密钥。这个过程会根据使用的加密方法不同而不同。

客户端认证

客户端向认证服务器发送 1 条包含用户 ID 的明文消息，申请基于该用户所应享有的服务。
认证服务器检查数据库是否存在此用户。如果存在，认证服务器会使用数据库中保存的此用户的密钥，来返回如下信息
- Message A：通过用户密钥加密的 Client/TGS Session key
- Message B：使用 TGS 本身的密钥加密的 Ticket-Granting-Ticket（TGT，包含用户 ID，客户端网络地址，ticket 有效期，和 Client/TGS Session Key）
客户端收到 Message A 和 B，尝试使用用户提供的密钥解密 Message A。如果用户提供的密钥和认证服务器保存的密钥不匹配将会导致解密失败。如果密钥正确，客户端将会得到一个 Client/TGS Session Key。客户端会缓存这个 Session key 用于接下来的通讯。（需要注意的是客户端无法解密 Message B，因为这个消息使用认证服务器的私钥加密的）。现在客户端有足够的信息来和票据授权服务器通信了。

服务授权

当要请求服务时，客户端需要向票据授权服务器发送以下信息：
- Message C：由 Message B 的 TGT 和要请求的服务的 ID 组成
- Message D：通过 Client/TGS Session Key 加密的 Authenticator（由用户 ID 和时间戳组成）
当收到 Message C 和 D 后，票据授权服务器将 Message B 从 Message C 里面提取出来，然后使用票据授权服务器的私钥解密 Message B。从解密后的 Messsage B 中能够得到 Client/TGS session key。然后使用这个密钥解密 Message D（Authenticator）然后对比 Message C 和 Message D 的用户 ID 是否一致（Message C 的用户 ID 通过解密 TGT 得到），若一致票据授权服务器将发送以下消息给客户端：
- Message E：使用请求的服务的私钥加密的 Client-to-server ticket（由用户 ID，客户端网络地址，有效期和 Client/Server Session Key 组成）
- Message F：使用 Client/TGS Session Key 加密的 Client/Server Session Key。

服务请求

当从票据授权服务器收到 Message E 和 F 后，客户端就有足够的信息来向特定服务提供端（Service Server SS，下面简称为服务器）验证自己的身份了。客户端连到服务器然后发送以下消息：
- Message E：就是上一步的 Message E，里面的内容使用服务器的私钥加密的。
- Message G：使用 Client/Session Key 加密的新的 Authenticator（包含用户 ID，时间戳）
当服务器收到 Message E 和 G 后，它首先使用自己的私钥解压 Message E 得到 Client/Server Session Key。然后服务器使用 Client/Server Session Key 解压 Authenticator（即 Message G）然后对比 Message E 和 G 的用户 ID 是否一致。如果一致服务器将发送以下消息到客户端确认验证通过：
- Message H：使用 Client/Server Session Key 加密的时间戳（在 Authenticator 中得到）
客户端解密确认消息，然后检查时间戳是否正确，如果正确客户端将认为服务器是可信的。
服务器为客户端提供服务。

总结

整个认证流程是没有任何明文密钥在网络上传输的，这就保证了即使网络数据被监听了，监听者也无法得到任何有效的密钥。
整个验证流程的关键在于客户端和特定服务提供端都信任 KDC，KDC 能提供服务的前提是它保存了客户端和特定服务提供端的私钥。
服务授权和服务请求步骤不是用户级别的行为，客户端系统会代替用户来执行这些步骤。但是用户登录和客户端认证通常需要用户调用 kinit 命令来执行。

凌云的博客

行胜于言