当Kerboros 认证的时到底认证什么

参考维基百科Kerberos (protocol) - Wikipedia

User Client-based logon

1. 用户输入密码，或者根据 pkinit (RFC 4556)使用公钥 

2. 将密码转换成对称密码的key

AS -  Authentication Server - 授权服务器

TGS - Tticket-Granting Service - 票据授权服务

SS - Service Server - 服务服务器

Client Authentication

1. 客户端将用户 ID 以明文发送给 AS（），AS 代表用户来请求服务。注意在这个过程中秘钥和密码都没有传输给 AS。

2. AS 检查数据库中是否有该用户，如果有发现则AS通过哈希密码产生秘钥，并向客户端返回两个消息：

消息A - 用客户端/用户的秘钥加密的 Client/TGS Session Key

消息B - 票据授权票据Ticket-Granting-Ticket（包含客户ID，客户网络地址，票据有效时间，Client/TGS Session Key），使用TGS的秘钥加密。

3. 收到消息A、B后，将用户输入密码生成的秘钥尝试用来解密消息A，如果用户输入的密码和 AS数据库中的不匹配，那解密会失败。一个有效的密码和秘钥可以解密获得 Client/TGS Session Key，据此来和 TGS 进行通信。（消息B是客户是无法解密的，因为是用TGS的秘钥加密）

---

Client Service Authorization

1. 当请求服务时，客户端将下列消息发给 TGS：

    消息C：由消息B的TGT和请求服务的ID组成。

    消息D：认证者 Authenticator （由客户端 ID 和时间戳组成），使用 Client/TGS Session Key 加密

2. 根据收到的消息C、D，TGS 从消息C中检索消息B，用TGS Session Key 解密消息B 来获得 client/TGS session key， 再据此解密消息D，并比较消息C和D中的客户端ID。若匹配，服务器向客户端返回两个消息：

    消息E：Client-to-server ticket （包含客户端ID，客户端网络地址，有效时间和 Client/Server Session Key），使用服务秘钥加密。

    消息F： Client/Server Session Key，用 Client/TGS Session Key 加密。

---

Client Service Request

1. 收到消息E、F后，客户端有足够信息向 SS 证实自己。客户端连接 SS 发送两个消息:

    消息E： 从上步获取。

    消息G：新的认证者，包含 Client ID，时间戳，用Client/Server Session Key 加密。

2. SS用自己的秘钥解密消息E来获取Client/Server Session Key，据此来解密认证者获取客户端ID并比较消息E、G中的客户端ID。若匹配则发送如下信息来确认客户端的真实身份和提供服务的意愿：

    消息H：客户端的认证者中的时间戳，用Client/Server Session Key加密。

3. 客户端用Client/Server Session Key 解密确认（消息H）来检查时间戳是否正确。若正确，客户端开始信任服务端并发起服务请求。

4. 服务端提供请求的服务。