1.kerberos认证基础

简写名词：

KDC（Key Distribution Center）= 密钥分发中心
AS（Authentication Server）= 认证服务器
TGS（Ticket Granting Server）= 票据授权服务器
TGT（Ticket Granting Ticket）= 票据授权票据，票据的票据

流程图

1.AS-REQ：
1.Client向AS以明文形式发起请求，请求携带，用户名，服务名，ip，时间戳等。

2.AS-REP：
1.AS接收请求，后去Kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性。
2.如果没有该用户名，认证失败，服务结束；如果存在该用户名，则AS认证中心便认为用户存在，此时便会返回给客户端，其中包含两部分内容：

(1) 第一部分内容是使用客户端密码hash加密的一段内容，其中包括用于客户端和TGS间通信的`TGS Session Key`,客户端即将访问的TGS的Name以及TGT的有效时间，和一个当前时间戳。该部分内容使用客户端密钥加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而中断认证流程。
(2) 第二部分内容称为TGT，它叫做票据授予票据(由`krbtgt的NTML-hash`加密)，客户端需要使用TGT去KDC中的TGS(票据授予中心)获取访问网络服务所需的Ticket(服务授予票据 TS)，TGT中包含的内容有PAC（用于验证用户权限，只有KDC能制作和查看）Kerberos数据库中存在的该客户端的Name、IP、当前时间戳、客户端即将访问的TGS的Name、TGT的有效时间以及一把用于客户端和TGS间进行通信的`TGS Session Key`。整个TGT使用TGS密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情况。

3.TGS_REQ：
1.此时的客户端收到了来自KDC中AS的响应，并获取到了其中的两部分内容。客户端会用自己的密码hash将第一部分内容进行解密，分别获得时间戳，自己将要访问的TGS的信息，和用于与TGS通信时的密钥TGS Session Key。
2.首先客户端会根据时间戳判断该时间戳与自己发送请求时的时间的差值是否大于5分钟，如果大于5分钟则认为该AS是伪造的，认证至此失败。如果时间戳合理，客户端便准备向TGS发起请求，其次请求的目的是为了获取能够访问目标网络服务的服务授予票据(TS)。
3.客户端将携带三部分内容交给KDC中的TGS：

(1).客户端将使用TGS密钥（krbtgt的NTML-hash）加密的TGT也原封不动的也携带给TGS；
(2).客户端将自己想要访问的Server服务以明文的方式发送给TGS；
(3).客户端使用TGS Session Key加密将自己的客户端信息发送给TGS，其中包括客户端名、IP、时间戳；

4.TGS_REP：
1.此时KDC中的TGS(票据授予服务器)收到了来自客户端的请求。它首先根据客户端明文传输过来的Server服务信息，查看当前Kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束。如果存在，则继续接下来的认证。

2.TGS使用krbtgt用户的NTML-hash将TGT中的内容进行解密，此时它看到了经过AS认证过后并记录的用户信息，一把TGS Session Key，还有时间戳信息，他会根据时间戳判断此次通信是否真是可靠有无超出时延。

3.如果时延正常，则TGS会使用TGS Session Key对客户端的第三部分内容进行解密(使用TGS Session Key加密的客户端信息)，取出其中的用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。

4.此时TGS将返回响应给客户端，响应内容包括：

(1) 第一部分：使用TGS Session Key加密的内容，其中包括Service Session Key和时间戳，还有TGT的有效时间。由于在第一次通信的过程中，AS已将TGS Session Key通过客户端密码加密交给了客户端，且客户端解密并缓存了TGS Session Key，所以该部分内容在客户端接收到时是可以自己解密的。
(2) 第二部分：用于客户端访问网络服务使用`Server的NTML-hash`加密的ST(Server Ticket)，其中包括客户端的Name，IP，需要访问的网络服务的地址Server IP，ST的有效时间，时间戳以及用于客户端和服务端之间通信的 Service Session Key。

5.AP_REQ：
1.此时的客户端收到了来自KDC中TGS的响应，并使用缓存在本地的TGS Session Key解密了第一部分内容(第二部分内容中的ST是由Server的NTML-hash加密的，客户端无法解密)，检查时间戳无误后取出其中的Service Session Key准备向服务端发起最后的请求。
2.客户端使用Service Session Key将自己的主机信息和时间戳进行加密作为交给服务端的第二部分内容，然后将ST(服务授予票据)作为第一部分内容都发送给服务端。

6.AP_REP：
1.服务器此时收到了来自客户端的请求，它会使用自己的Server NTML-hash，将客户端第一部分内容进行解密，核对时间戳之后将其中的Service Session Key取出，使用Service Session Key将客户端发来的第二部分内容进行解密，从而获得经过TGS认证过后的客户端信息，此时它将这部分信息和客户端第一部分解密内容带来的自己的信息进行比对，最终确认该客户端就是经过KDC认证的具有真实身份的客户端，是它可以提供服务的客户端。此时服务端返回一段使用Service Session Key加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的Service Session Key解密之后也确定了服务端的身份(其实服务端在通信的过程中还会使用数字证书证明自己身份)。




客户端确定了服务端的身份后将ST缓存下来