Kerberos 系列1 --- 简介

一、概念

Kerberos是一个网络认证协议，主要用于向C/S应用提供强认证服务。Kerberos协议有多种实现，其中MIT Kerberos (http://web.mit.edu/kerberos/www/)是最广为人知的免费实现，除此之外Heimdal Kerberos(https://github.com/heimdal/heimdal/)也是Kerberos的一个实现。

二、名词解释

1. Principal(标识符)：作为用户或者服务(User/Service)的一个唯一性标识。

2. Client(客户端)：服务调用者，C/S体系中的C，每个Client拥有一个对应的realm。

3. Realm(领域)：作为Client的一个重要标识，多个不同的Client可以拥有相同的realm。例如：一个需要用户验证的网站通常使用其域名作为realm。

4. Service(服务)：提供给Client使用的资源，比如文件服务、邮件服务、短信服务、用户中心服务等。

5. KDC(Key Distribution Center)：作为Kerberos的核心，KDC负责向C/S两端提供各种Ticket，生成临时Session Key，存储全部secret key(用于对称加密)等。KDC由两部分组成，一是认证服务(Authentication Server)，二是票据许可服务(Ticket Granting Server)

(1) 认证服务(Authentication Server)

认证服务负责核实用户身份，确认其访问某项服务的请求并向用户签发TGT(Ticket Granting Ticket)。

(2) 票据许可服务(Ticket Granting Server)

票据许可服务确认用户需要访问的服务，并向用户签发ST(Service Ticket)。

6. Session Key(临时会话密钥)：由KDC生成的，分别保存在Client和KDC，用于对称加密会话消息。

7. Client Secrect Key(用户密钥)：用于Client与KDC通信时加解密数据报文，一般通过由用户密码、用户名、realm和版本号组成的字符串经Hash后生成，如下图：

8. Ticket Granting Ticket(TGT)：由Authentication Server生成，是User和Ticket Granting Server通信的必备信息。

9. Service Ticket(ST)：由Ticket Granting Server生成，是User和具体Service通信的必备信息。

三、认证流程

1. User向KDC的Authentication Server发送访问服务的请求信息，该信息未经加密；

2. Authentication Server收到User发送的请求之后，校验User是否为KDC已知的用户，如果校验通过则生成TGT；

3. Authentication Server将TGT和其他信息一起使用User Secret Key加密后发送回User端；

4. User使用User Secret Key将信息解密得到TGT；

5. User将TGT和其他信息一起加密，发送至Ticket Granting Server；

6. Ticket Granting Server将User发送的信息解密，得到TGT，执行校验之后生成一个ST；

7. Ticket Granting Server将ST加密后返回给User；

8. User将Ticket Granting Server返回的信息解密，得到ST，创建Authenticator Message并将其与ST一起发送至具体的Service；

9. Service将User发送的信息解密，得到Authenticator Message和ST，执行检验之后生成Final Authenticator Message；

10: Service将Final Authenticator Message加密后返回给User；

11. 有了Final Authenticator Message，User可以请求Service的资源，Service收到请求后可依据Final Authenticator Message对User进行授权。

四、认证实例

我们以用户Jack访问CRM系统为例，下文中出现的“消息”和“报文”均指消息中的Payload：

1. Jack向Authentication Server发送请求访问CRM服务的明文消息，内容包括用户标识(Jack)，用户IP和服务标识(CRM)，还有TGT的有效期；

2. 作为KDC的组成部分，Authentication Server维护着所有用户和用户密钥(Client Secrect Key)数据。收到Jack发送的请求消息之后，Authentication Server首先校验报文中的User Id，如果是合法用户则读取Client Secrect Key；

3. Authentication Server创建两条消息并返回给User，第一个包含TGS(Ticket Granting Server)标识、时间戳(创建时)，TGT的有效期和TGS Session Key，该信息由Client Secrect Key进行加密；第二个是Ticket Granting Ticket(TGT)报文，包括用户标识、TGS标识、时间戳(创建时)、用户IP、TGT的有效期和TGS Session Key，该报文由TGS Secrect Key进行加密。

4. User使用自身已知的Client Secrect Key对第一条消息解密，得到TGS标识、Timestamp、TGT有效期和TGS Session Key；由于User无法得到TGS Secrect Key，所以它无法解密第二条消息(TGT报文)。此外，该步用到的Client Secrect Key由用户密码组成，所以该步骤一般需要用户输入密码。

5. User创建两个新消息，第一个消息包含需要访问的服务标识(CRM)和有效期(Service Ticket)，该条消息不加密；第二条消息是User Authenticator，包含用户标识(Jack)和时间戳(创建时)，该消息由第4步解密得到的TGS Session Key进行加密。创建完成之后，User将这两条新消息连同未解密的TGT消息(共计三个消息)一起发送至Ticket Granting Server；

6. 作为KDC的组成部分，TGS维护着所有服务和服务密钥(Client Secrect Key)数据。收到User的请求后，TGS首先校验用户消息(第二个)中的服务标识(CRM)，如果是合法服务则读取Service Secret Key，然后使用Service Secret Key将TGT消息(第一个)解密，得到用户标识(Jack)、TGS标识、时间戳(创建时)、用户IP、TGT的有效期和TGS Session Key；最后TGS使用解密得到的TGS Session Key将User Authenticator消息(第三个)解密得到用户标识(Jack)和时间戳(创建时)。

解密全部三个消息之后，TGS做如下校验:

(1) 对比TGT和User Authenticator消息中User ID，若一致则没问题；

(2) 对比TGT和User Authenticator消息中时间戳，允许时间间隔最大两分钟；

(3) 对比TGT消息中的IP地址和实际发送User Authenticator消息的IP地址，若一致则没问题；

(4) 判断TGT消息的有效期(Lifetime)，没有过期。

TGS除了维护着服务和服务密钥数据之外，还维护着一个TGS Cache，该Cache缓存着所有合法有效的User Authenticator报文(包含用户标识和时间戳)，当下一次该用户请求相同的Service时可以省略部分校验过程。在上述的校验通过之后，TGS会将User Authenticator消息保存至TGS Cache中供重复使用。

7. TGS创建两个新消息并返回给User，第一个消息包含服务标识(CRM)、时间戳、TGT的有效期和Service Session Key，该消息由TGS Session Key加密；第二个消息是Service Ticket，包含用户标识(Jack)、服务标识(CRM)、时间戳、用户IP、Service Ticket和Service Session Key，该消息由Service Secret Key加密。

8. 由于在第4步时User已经得到了TGS Session Key，所以User使用TGS Session Key解密第一条消息得到服务标识(CRM)、时间戳、TGT的有效期和Service Session Key；由于User没有Service Secret Key，所以它无法解密Service Ticket报文。

9. User创建一条新的User Authenticator消息，包含用户标识(Jack)和时间戳(创建时)，使用Service Session Key加密。User将Service Ticket和User Authenticator报文一起发送至Service(CRM)。

10. Service使用Service Secret Key解密Service Ticket报文，得到用户标识(Jack)、服务标识(CRM)、时间戳、用户IP、Service Ticket和Service Session Key；再使用Service Session Key解密User Authenticator报文，得到用户标识(Jack)和时间戳。Service做如下校验：

(1) 对比Service Ticket和User Authenticator中的用户标识，若一致则没问题；

(2) 对比Service Ticket和User Authenticator消息中时间戳，允许时间间隔最大两分钟；

(3) 对比Service Ticket消息中的IP地址和实际发送User Authenticator消息的IP地址，若一致则没问题；

(4) 判断TGT消息的有效期(Lifetime)，没有过期。

类似于TGS，Service也维护一个Service Cache用于缓存合法有效的User Authenticator报文(包含用户标识和时间戳)，当下一次该用户请求相同的Service时可以省略部分校验过程。在上述的校验通过之后，Service会将User Authenticator消息保存至Service Cache中供重复使用。

11. Service创建Service Authenticator报文并返回给User，包含服务标识(CRM)和时间戳(创建时)，使用Service Session Key加密。

12. 由于在第8步时User已经得到了Service Session Key，所以User使用Service Session Key解密Service Authenticator报文，得到服务标识(CRM)和时间戳(创建时)。User做如下校验：

(1) 确认Service Authenticator中的服务标识是自己希望访问的服务；

(2) 确认Service Authenticator中的时间戳是有效的。

类似于TGS和Service，User也通过维护一个User Cache来缓存所有有效的Service Ticket(注意不是Service Authenticator)报文。

五、参考引用

https://docs.oracle.com/cd/E24847_01/html/819-7061/intro-1.html