Kerberos认证协议认证授权流程-白话解读

本文参考了Wikipedia上面的Kerberos词条，对Kerberos的用户认证、服务授权、服务请求过程，用大白话解读。

1前言

我相信有很多人看不懂Kerberos协议，所以我终于看懂以后用大白话说一遍，让那些看不懂的人看懂，让我忘了以后变成看不懂的人的时候再次看懂。

Kerberos是一种计算机网络认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。

这是Wikipedia上面的解释。
不知道什么是Kerberos的请先读一遍Wikipedia上面的Kerberos词条（自备梯子），这个词条我认为是写得最明白的，看完后再来看本文可以加深理解，看蒙了也正常，看本文也能了解个大概。

2 Kerberos核心思想

2.1 基于密码学

Kerberos是一个基于密码学的认证体系。什么是基于密码学？在我的理解，就是

能用密钥解开内容，就说明你具有这个密钥。

我举个例子说明。
当我们进行登录时，需要将Username和Password传输到服务端，服务端根据用户名找到用户信息后，再核对密码是否正确，核对正确以后，给用户颁发一个UserToken，作为今后用户使用系统的临时凭据。
而在Kerberos登录过程中，用户将Username和Password输入到登录界面中，客户端只是将Username传送到服务端，服务端找到用户信息以后，直接给用户一个UserToken，但这个UserToken是用用户的Password加密的。因此，如果用户想得到这个UserToken，那么，用户必须输入正确的Password才能解开。
也就是说，当用户输入错误的Password时，他无法得到UserToken，就无法完成登录使用系统。当输入正确的Password时，他就得到了UserToken，可以使用系统。
在Kerberos认证协议中，大量使用了这种方式和思想。这种方式的好处就是，用户的Password不会在网络上传输，并且层层的加密保证了系统即使在一个非安全的网络（可能被监听）中也不会泄露信息。

2.2 后端服务私有密钥

这里的私有密钥指的不是公钥密码体制里面的公钥和私钥，指的是

每个服务都有一个独立的密钥

基于2.1中提到的密码学认证方式，当进行服务授权时，授权中心将服务授权票据使用服务的私有密钥加密，如果服务用私有密钥解开了票据内容，则证明这个票据是由授权中心提供的，则可以信任其中的内容。

3 认证过程解读

总的认证过程我画了这张时序图。
（由于本文基础是Wikipedia上的Kerberos词条，所以命名沿用了该词条的命名）

在这张图中，加密内容这样表示

【被加密的内容】(加密密钥)

为了在中文中醒目，客户端用Client表示，认证中心用TGS表示，后端服务器用Service表示，其他变量尽可能用英文表示。

3.1 用户认证

用户认证过程如下：

• 用户输入Username和Password后，Client将Username发送到TGS；
• TGS根据Username找出用户信息，取出Password，返回两条消息：

消息1Client与TGS之间通信的密钥: "Client/TGS SessionKey"【以上内容用"Password"加密】

消息2 "TGT""Client/TGS SessionKey"(与上条消息的Client/TGS SessionKey相同), "UserID", "UserIP", "Expires"【以上内容用TGS自己的服务密钥"TGS's SecretKey"加密】

• Client用用户输入的Password解开用Password加密的Client/TGS SessionKey就得到了他的用户凭据Client/TGS SessionKey。

此时Client就拥有了

1. "Client/TGS SessionKey" 原文2. "TGT" 密文

Client拥有了用TGS的私有密钥TGS's SecretKey加密的TGT，就可以使用TGS服务。因此，Client到此处就完成了用户认证。

3.2 服务授权

服务授权过程如下：

• 用户发送如下三条消息给TGS

消息1 "TGT"【记住该内容是"TGS"用"TGS's SecretKey"加密的】

消息2 "ServiceID" 要请求的服务的ID

消息3 "Authenticator":"UserID"，"Timestrap"【以上内容用"Client/TGS SessionKey"加密】

• TGS收到消息后，作如下处理：
  
  • 查找是否有ID为ServiceID的服务
  • 用TGS's SecretKey解开TGT，得到Client/TGS SessionKey, UserID, Expires
  • 用Client/TGS SessionKey解开Authenticator，得到UserID和Timestrap
  • 验证TGT和Authenticator，如是否过期，两者包含的UserID是否相同等
• 当以上消息均验证成功后，TGS返回如下两条消息：

消息1 "Client-Service Ticket": "Client/Service SessionKey"(Client与Service通信的密钥), "UserID", "UserIP", "Expires"【以上内容用"Service's SecretKey"加密】

消息2 "Client/Service SessionKey"【以上内容用"Client/TGS SessionKey"加密】

• Client用Client/TGS SessionKey解开消息2就得到了Client/Service SessionKey

• Client拥有了用私有密钥Service's SecretKey加密的Client-Service Ticket，就可以使用Service服务。因此，Client到此处就完成了服务授权。

  回想一下，在进行服务授权之前Client已经有了这两条内容：

  1. Client/TGS SessionKey
  2. TGT

• 此时Client就拥有了

1. "Client/TGS SessionKey" 原文2. "TGT" 密文3. "Client-Service Ticket" 密文4. "Client/Service SessionKey" 原文

3.3 服务请求

• Client发送如下两条消息给Service

消息1"Client-Service Ticket"【记住该内容是"TGS"用"Service's SecretKey"加密的】

消息2 "Authenticator":"UserID", "Timestrap"【以上内容用"Client/Service SessionKey"加密】

• Service收到后，作如下处理
  
  • 用Service's SecretKey解开Client-Service Ticket得到Client/Service SessionKey, UserID, UserIP, Expires
  • 用Client/Service SessionKey解开Authenticator得到UserID, Timestrap
  • 验证Client-Service Ticket和Authenticator，如是否过期，两者包含的UserID是否相同等
• 当以上消息均验证成功后，Service开始信任Client，返回如下消息：

"欢迎信息"【以上内容用"Client/Service SessionKey"加密】

• Client用Client/Service SessionKey解开消息得到欢迎信息。
• 服务请求完成，双方开始交流。

4 总结

当你把TGS看成一个普通的服务的时候，你会发现所有的服务都有这些共同点

• 向服务提供一个由服务SecretKey加密一个包含SessionKey的Ticket
• 服务用SecretKey解开Ticket得到SessionKey
• 用户信息是用SessionKey加密的

Kerberos实际上是双方在认证中心指导下进行的双方认证，因为：

• 对服务认证：用户的信息只能被拥有正确的SecretKey的服务解开，因为有SecretKey才能得到SessionKey，而真正的服务才拥有正确的SecretKey。
• 用户必须拿着用正确的SecretKey加密的Ticket才能去请求服务，否则服务解不开Ticket也就得不到SessionKey。

这个认证过程，实际上就是对SecretKey的认证，并且认证方法体现了密码学的思想，即能用密钥解开内容，就说明你具有这个密钥。

5 后话

自认为写得不能再白话，总比一些学术流的文章用符号，甚至数学符号表示内容要白话。
如果文中有什么不足，请大神在评论区指导。