Kerberos 协议学习

=Start=

缘由：

其实很早就想好好学习了解一下 Kerberos 协议，但苦于这个协议确实不容易理解，且没有遇到合适的场景帮助消化，所以之前只是收集了一堆资料，看了几张图，对于实际的数据交互流程以及为什么这么设计，能解决什么问题还是不够了解，懵懵懂懂的。上次刚好找机会研究了一下 CAS 协议，了解到CAS协议的设计思路吸收了 Kerberos 协议的思想，再加上找到了几篇很好的文章，这次终于对 Kerberos 协议有了一定的了解，简单记录一下，方便以后参考、复习。

正文：

参考解答：

Kerberos 协议的目标和作用

Kerberos 协议旨在在开放且不安全的网络上提供可靠的身份验证。在这种网络环境中，主机之间的通信可能会被拦截或监听，但是网络中的主机本身是安全可信的，即可信主机在不可信网络上的身份验证。

为什么需要 Kerberos 协议

Kerberos 协议的目的是身份验证。既然是身份验证，那我直接输入用户名密码不就好了，为何要有Kerberos这样一个复杂的东西？举例来说，有A、B、C三个服务器，分别提供不同的服务，user要访问A、B、C都需要输入用户名密码（这还是不同服务使用相同密码的简单情况），但是A、B、C没必要都存一份user的密码，所以就衍生出一个中央服务器D来专门存储用户名密码；如果user通过了D的认证，那就是合法的身份，就可以使用A、B、C中的任何一个服务，所以user需要告诉A、B、C它通过了D的认证。如何证明这个事情，以及信息在网络传输过程如何防止被截获篡改而假冒等等，解决这些问题就靠 Kerberos 协议。

以上这些看上去是不是和现在大家常听到和用到的 SSO 协议解决的问题很像？前段时间我在看 CAS 协议时就有文章提到 CAS 协议的设计参考了 Kerberos 协议的思想，而CAS协议现在是使用非常广泛的 SSO 协议，也是一个简单而强大的基于票据的(ticket-based)协议。

Kerberos 协议中的一些概念、名词解释

Kerberos的标志是三头狗，狗头分别代表以下角色：

Client
KDC(Key Distribution Center)
Service

KDC 负责票据的管理，但是 KDC 不是一个独立的服务，它主要由以下两服务组成：

AS, Authentication Service 对client进行认证并生成TGT
TGS, Ticket Granting Service 为client生成特定服务的ST

在深入了解 Kerberos 协议的原理之前，先整理介绍一下 Kerberos 协议的几个大前提，有助于理解：

在 Kerberos 协议中不仅用户(client)有密码，服务(service)也有密码，而 KDC 知道所有的密码，密码存储在单个集中式数据库中。
Kerberos 协议基于 Ticket 实现身份认证，而非密码，且密码不会以明文形式通过网络发送。如果客户端无法利用用户密钥，解密出 KDC 返回的加密Ticket，则认证无法通过，也就没有后续流程。
客户端(client)将依次与 Authentication Service, Ticket Granting Service 以及目标Service进行交互，共三次交互。
客户端(client)与其他服务交互时，都将获取到主要包含两条内容的返回，其中一条可以通过用户密钥解密出，另外一条将无法解密出（需要用会话密钥或服务密钥才能解出）。
客户端(client)想要访问的目标服务(service)，将不会直接与KDC交互，而是通过能否正确解密出客户端的请求来进行认证。

Kerberos 协议的认证流程

AS_REQ is the initial user authentication request (i.e. made with kinit) This message is directed to the KDC component known as Authentication Server (AS);
AS_REP is the reply of the Authentication Server to the previous request. Basically it contains the TGT (encrypted using the TGS secret key) and the session key (encrypted using the secret key of the requesting user)——会话密钥1，由AS随机生成;
TGS_REQ is the request from the client to the Ticket Granting Server (TGS) for a service ticket. This packet includes the TGT obtained from the previous message and an authenticator generated by the client and encrypted with the session key;
TGS_REP is the reply of the Ticket Granting Server to the previous request. Located inside is the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS（——会话密钥2，由TGS随机生成） and encrypted using the previous session key generated by the AS;
AP_REQ is the request that the client sends to an application server to access a service. The components are the service ticket obtained from TGS with the previous reply and an authenticator again generated by the client, but this time encrypted using the service session key (generated by TGS);
AP_REP is the reply that the application server gives to the client to prove it really is the server the client is expecting. This packet is not always requested. The client requests the server for it only when mutual authentication is necessary.

Kerberos 认证流程中的数据交互

PrincipalClient 可以简单理解为 username-用户名；
PrincipalService 是 servicename-服务名；
IP_list 可以理解为可合法使用ticket的网络地址范围（如果解密出来的IP地址不在IP_list范围内，可以认为此ticket无效）；
Lifetime 可以理解为过期时间或者说有效生命周期范围；
TgtRealm 可以理解为签发tgt的主体
Timestamp 签发日期时间戳

SK_TGS 由 AS 随机生成的在 client 和 TGS 之间共享的会话密钥(sessionkey)
SK_Service 由 TGS 随机生成的在 client 和 Service 之间共享的会话密钥(sessionkey)，和 Authenticator 一起验证互相的身份

K_User 是用户的密码，只有用户和 KDC(AS+TGS) 知道
K_TGS 是 TGS 的密码，只有 KDC(AS+TGS) 知道
K_Service 是 Service 的密码，只有 Service 和 KDC(AS+TGS) 知道

Authenticator 身份验证器，由 client 生成的起到验证身份作用的内容，是使用各阶段的会话密钥(sessionkey)对 {PrincipalClient, Timestamp} 进行加密生成的

请求1：
AS_REQ = ( PrincipalClient , PrincipalService , IP_list , Lifetime )
>>> 由 client 向 AS 发起的请求，内容包含自己的用户名、目标服务名、网络地址、申请票证有效期等主要信息


响应1：
TGT = ( PrincipalClient , TgtRealm , IP_list , Timestamp , Lifetime , SK_TGS )
AS_REP = { PrincipalService , Timestamp , Lifetime , SK_TGS }K_User { TGT }K_TGS
>>> 由 AS 返回给 client 的响应，内容是 使用用户密码加密的{目标服务名、签发日期时间戳、票证有效期、client和TGS共享的会话密钥} + 使用TGS密码加密的TGT ，其中TGT里面包含了一个client和TGS共享的会话密钥，是由 AS 随机生成的，TGS只有在用自己的密码成功解密之后才能提取出这个会话密钥


请求2：
Authenticator = { PrincipalClient , Timestamp }SK_TGS
TGS_REQ = ( PrincipalService , Lifetime , Authenticator) { TGT }K_TGS
>>> 由 client 向 TGS 发起的请求，内容包含目标服务名、票证有效期和身份验证器Authenticator-1（这个身份验证器是用上面的会话密钥进行加密生成的内容，用来验证 client 的身份），还有一个用TGS密码加密的TGT


响应2：
ServiceTicket = ( PrincipalClient , PrincipalService , IP_list , Timestamp , Lifetime , SK_Service )
TGS_REP = { PrincipalService , Timestamp , Lifetime , SK_Service }SK_TGS { ServiceTicket }K_Service
>>> 由 TGS 返回给 client 的响应，内容是 使用上一步中会话密钥加密的{目标服务名、签发日期时间戳、票证有效期、client和Service共享的会话密钥} + 使用服务密码加密的ServiceTicket ，client和Service共享的会话密钥是由 TGS 随机生成的，Service 只有在用自己的密码成功解密之后才能提取出这个会话密钥


请求3：
Authenticator = { PrincipalClient , Timestamp }SK_Service
AP_REQ = Authenticator { ServiceTicket }K_Service
>>> 由 client 向 Service 发起的请求，内容包含身份验证器Authenticator-2（这个身份验证器是用上面的会话密钥进行加密生成的内容，用来验证 client 的身份）+ 使用 Service 密码加密的 ServiceTicket


响应3：
AP_REP 是服务端给客户端的响应包，用来证明我确实是 client 所期望的 service ，因为我有 SK_Service 能正确解密上一步你提供的 Authenticator 从而完成了双向认证（一般不需要，一般情况下只需要 service 能够验证 client 是真的就行，client 很少要求 service 也是真的）。

参考链接：

Designing an Authentication System: a Dialogue in Four Scenes
http://web.mit.edu/kerberos/dialogue.html

KERBEROS PROTOCOL TUTORIAL
https://www.kerberos.org/software/tutorial.html

Explain like I’m 5: Kerberos
https://www.roguelynn.com/words/explain-like-im-5-kerberos/

一文搞定Kerberos
https://zhuanlan.zhihu.com/p/266491528

Kerberos-FAQ
http://www.di-srv.unisa.it/~ads/corso-security/www/CORSO-0001/kerberos/ref/kerberos-faq.html

关于 Kerberos 每个人都应该知道这些
https://mp.weixin.qq.com/s/gLg0pdVRWl3hJMB5au61rw

=END=

11 11 月, 2022

Docker

KnowledgeBase, Security

KDC, Kerberos, SSO, TGT, 会话密钥, 认证协议