Kerberos 入门实战(1)--Kerberos 基本原理
Kerberos 是一种由 MIT(麻省理工大学)提出的网络身份验证协议,它旨在通过使用密钥加密技术为客户端和服务器应用程序提供强身份验证,本文主要介绍 Kerberos 的基本原理。
1、Kerberos 是什么
Kerberos 一词取自于古希腊神话中的 Cerberus(刻耳柏洛斯),它是 Hades(哈迪斯)的一条凶猛的三头保卫神犬:
Kerberos 是一种基于加密 Ticket 的身份认证协议,主要由三个部分组成:Key Distribution Center (即KDC)、Client 和 Service:
客户端会先访问两次 KDC,然后再访问目标服务,如:HTTP 服务、Zookeeper 服务、Kafka 服务等。
2、Kerberos 基本概念
2.1、Principal
Principal 可以认为是 Kerberos 世界的用户名,用于标识身份。principal 主要由三部分构成:primary,instance(可选) 和 realm。包含 instance 的 principal,一般会作为 server 端的 principal,如:Zookeeper,NameNode,HiverServer 等;不含有 instance 的 principal,一般会作为客户端的 principal,用于身份认证。例子如下图所示:
2.2、Keytab
相当于“密码本”,包含了多个 principal 与密码的文件,用户可以利用该文件进行身份认证。
2.3、Ticket Cache
客户端与 KDC 交互完成后,包含身份认证信息的文件,短期有效,需要不断renew。
2.4、Realm
Kerberos 中的一个 namespace,不同 Kerberos 环境,可以通过 realm 进行区分。
2.5、KDC
Key Distribution Center,是 Kerberos 的核心组件,主要由三个部分组成:
Kerberos Database: 包含了一个 Realm 中所有的 principal、密码与其他信息;默认是 Berkeley DB。
Authentication Server(AS): 进行用户信息认证,为客户端提供 Ticket Granting Tickets(TGT)。
Ticket Granting Server(TGS): 验证 TGT 与 Authenticator,为客户端提供 Service Tickets。
3、Kerberos 基本原理
1.客户端与 AS 或 TGS 交互,都将获取到两条信息,其中一条可以解密,另外一条无法解密。
2.客户端想要访问目标服务不会直接与 KDC 交互。
3.KDC Database 包含有所有客户端和服务的密码。
4.密钥是密码加 salt 后经过哈希处理后得到的。密钥是由管理员生成的,并分发到客户端和服务。
5.KDC 本身使用主密钥进行加密,以增加从数据库中窃取密钥的难度。
6.Kerberos 中信息加密方式一般是对称加密,也可使用成非对称加密。
4、Kerberos 认证过程
这里以客户端访问 HTTP 服务为例,解释整个认证过程。
4.1、客户端与 Authentication Server
客户端发送包含自身信息的明文消息给 AS,消息包含如下信息:
- your name/ID
- the name/ID of the requested service (in this case, service is the Ticket Granting Server)
- your network address (may be a list of IP addresses for multiple machines, or may be null if wanting to use on any machine)
- requested lifetime for the validity of the TGT
AS 检查客户端 ID 是否在 KDC 数据库中。
如果 AS 检查没有异常(用户不存在会报异常),那么 KDC 将随机生成一个 Session Key,用于客户端与 Ticket Granting Server(TGS) 通信。随后 AS 将发送两条信息给客户端。一条消息是由客户端密钥加密,包含如下信息:
- the HTTP service name/ID
- timestamp
- lifetime (same as above)
- TGS Session Key
另一条消息是 TGT,由 TGS 的密钥加密,包含如下信息:
- your name/ID
- the HTTP service name/ID
- timestamp
- your network address (may be a list of IP addresses for multiple machines, or may be null if wanting to use on any machine)
- lifetime of the TGT (could be what you initially requested, lower if you or the TGS’s secret keys are about to expire, or another limit that was implemented during the Kerberos setup)
- TGS Session Key
客户端收到 AS 发来的消息后,利用本地的密钥解密第一条信息,并获得 TGS Session Key;如果本地密钥无法解密消息,那么认证失败。
客户端无法解密 TGT,它会被保存在认证缓存中。
4.2、客户端与 Ticket Granting Server
客户端发送如下信息给 TGS:
1.一条明文消息,包含如下信息:
- the requested HTTP Service name/ID you want access to
- lifetime of the Ticket for the HTTP Service
2.使用 TGS Session Key 加密的 Authenticator,包含如下信息:
- your name/ID, and
- timestamp.
3.TGT
TGS 检查 HTTP 服务 ID 是否在 KDC 数据库中。
TGS 检查没问题后,利用自身的密钥从 TGT 中解密出 TGS Session Key,然后利用 TGS Session Key 从 Authenticator 中解密出客户端的信息。
然后 TGS 做以下检查:
- compare your client ID from the Authenticator to that of the TGT
- compare the timestamp from the Authenticator to that of the TGT (typical Kerberos-system tolerance of difference is 2 minutes, but can be configured otherwise)
- check to see if the TGT is expired (the lifetime element)
- check that the Authenticator is not already in the TGS’s cache (for avoiding replay attacks)
- if the network address in the original request is not null, compares the source’s IP address to your network address (or within the requested list) within the TGT
所有检查都通过后,TGS 随机生成一个 HTTP Service Session Key,用于后续客户端与 HTTP Service 通信。同样地,TGS 将发送两条信息给客户端,一条消息是由 TGS Session Key 加密,包含如下信息:
- HTTP Service name/ID
- timestamp
- lifetime of the validity of the ticket,
- HTTP Service Session Key
另一条消息是 HTTP Service Ticket,由 HTTP Service 的密钥加密,包含如下信息:
- your name/ID
- HTTP Service name/ID
- your network address (may be a list of IP addresses for multiple machines, or may be null if wanting to use on any machine)
- timestamp
- lifetime of the validity of the ticket
- HTTP Service Session Key
客户端收到消息后,利用 TGS Session Key 解密出第一条信息获得 HTTP Service Session Key,另一条信息是由目标 HTTP Service 密钥加密,无法解密。
4.3 客户端与 HTTP Service
客户端发送如下信息给 HTTP Service:
1.HTTP Service Ticket
2.用 HTTP Service Session Key 加密的 Authenticator,包含如下信息:
- your name/ID
- timestamp
HTTP Service 利用自身的密钥从 HTTP Service Ticket 中解密出 HTTP Service Session Key,然后利用 HTTP Service Session Key 从 Authenticator 中解密出客户端的信息。
然后 HTTP Service 做以下检查:
- compares your client ID from the Authenticator to that of the Ticket
- compares the timestamp from the Authenticator to that of the Ticket (typical Kerberos-system tolerance of difference is 2 minutes, but can be configured otherwise)
- checks to see if the Ticket is expired (the lifetime element),
- checks that the Authenticator is not already in the HTTP Server’s cache (for avoiding replay attacks)
- if the network address in the original request is not null, compares the source’s IP address to your network address (or within the requested list) within the Ticket
检查没问题后,HTTP Service 会发送一条由 HTTP Service Session Key 加密的消息给客户端,包含如下信息
- HTTP Service ID
- timestamp
客户端使用缓存的 HTTP Service Session Key 解密出消息,且消息必须包含 HTTP Service ID 和 timestamp。
客户端验证消息没问题后,至此,客户端即与HTTP Service完成了身份认证;后续将使用缓存的 HTTP Service Ticket 来通信,直到 Ticket 过期。
5、Kerberos 的优势
1.密码无需进行网络传输;基于 Ticket 实现身份认证,保障密钥安全性。
2.双向认证;整个认证过程中,不仅需要客户端进行认证,待访问的服务也需要进行身份认证。
3.高性能;一旦 Client 获得访问某个 Service 所需的 Ticket,该 Service 就能根据这个 Ticket 实现对 Client 的验证,而无须 KDC 的再次参与。
参考:
1.https://zhuanlan.zhihu.com/p/266491528
2.https://www.roguelynn.com/words/explain-like-im-5-kerberos