Kerberos协议原理

Kerberos协议是一种基于第三方可信主机的计算机网络协议，它允许两个实体之间在非安全网络环境（可能被窃听、被重放攻击）下以一种安全的方式证明自己的身份。

Kerberos协议解决的问题的本质是：

假设A和B共有一个秘密，在一个非安全网络环境中，A怎样才能向B证明自己就是A。
最简单的方式就是，A直接将秘密发送给B，由B来判断这个秘密的真伪。但在非安全网络环境中，秘密可能会被窃听或中间人攻击，所以这种方式不可取。接下来考虑的是，A用秘密作为密钥加密一段文字生成一段密文，然后将文字本身和密文一起发给B，B接收后用秘密解密密文得到文字，然后和接收的文字对比，如果两者一致，那么也能证明秘密的正确性，从而也能验证A的身份。
但如果该认证请求被窃听，攻击者能得到加密后密文和加密前的明文，只要时间允许，总能推导出密钥的数值，也就是秘密肯定会被窃取。所以密码界有个规定，长期存在的密钥不适合在网络中传输，否则总会有被窃取的风险。
不使用长期存在的密钥，那使用短期存在的密钥进行验证应该是没问题的，关键是，谁来提供这个短期存在密钥给A和B？于是就出现了第三方可信机构KeyDistribution
Center，KDC。
在请求认证之前，Client-A先去向KDC申请本次向Server-B认证需要的SessionKey，由KDC将SessionKey分发给Client-A和Server-B，最后Client-A就可以利用这个SessionKey向Server-B进行认证了。为了SessionKey不被窃取，该SessioKey用A和B自身的密码分别加密：

过程中会有两个问题：

（1）A向KDC申请SessionKey，它可能很快就收到SessionKey，但B可能因为网络环境原因，很晚或者根本收不到SessionKey，这样就导致认证无法进行，解决办法就是，KDC将两份加密的SessionKey都发给A，由A在向B发出认证请求时将原本属于Server-B的SessionKey一同发送给Server-B

（2）A提出SessionKey的申请时，KDC凭什么就生成了SessionKey给了A，也就是说，KDC缺乏对A的认证，所以在分发SessionKey之前，KDC需要增加对A的认证，解决办法就是，将KDC机构分成两部分：

AS：Authentication Service，用于KDC对A的认证
TGS：Ticket Granting Service，用于KDC向A和B分发Session Key

另外，还有一点需要注意的是，为了对短期有效的SessionKey进行验证，Kerberos协议要求系统内的所有主机基于时间同步，所以Client-A向Server-B进行认证就直接用SessionKey加密当前时间即可。

到此为止，整个Kerberos协议大体框架就已经出来了：

需要注意的是，这里涉及到两个SessionKey的申请，一个是SessionKeya-kdc，另一个是SessionKeya-b，这是因为基于刚才的三方认证以及尽量使用短期有效密钥的思想，本协议变成了两次三方认证：
当 Client 想要访问 Server 上的某个服务时,需要先向 AS证明自己的身份,验证通过后AS会发放的一个TGT,随后Client再次向TGS证明自己的身份,验证通过后TGS会发放一个ST,最后Client向Server 发起认证请求。

（1）AS作为Client-A与TGS之间的第三方，需要完成对A进行认证，同时为Client-A向TGS提出SessionKeya-b请求提供一个SessionKeya-kdc，根据刚才的分析，为了防止TGS无法收到SessionKey，如图第②步，原本需要发往TGS的SessionKeya-kdc（被KDC密码加密为TGT）会一同发往Client-A，由Client-A在第③步中转交给TGS

（2）TGS作为Client-A与Server-B之间的第三方，需要为A和B分别提供SessionKeya-b，为了防止Server-B无法收到SessionKey，如图第④步，原本需要发往Server-B的SessionKeya-b（被Server-B密码加密为service
Ticket）会一同发往Client-A，由Client-A在第⑤步中转交给Server-B

上述过程也就是Kerberos协议的基本框架，基于微软对Kerberos的介绍，上面其实对应的是下面微软提供的Kerberos协议流程：

具体来说，Kerberos协议分为以下步骤（第六步可选）：

①：KRB_AS_REQ：Client-A发送Authenticator向KDC的AS服务认证自己的身份（通过提供自身密码加密的一个时间戳TimeStamp）

②：KRB_AS_REP：AS通过KDC数据库中存储的Client-A密码的副本，解密收到的Authenticator，如果解密出的TimeStamp符合要求，则AS服务认为Client-A就是所谓的Client-A。认证成功后，AS服务生成一个短期有效的SessionKeya-kdc，将该Key使用A的密码副本加密成密文1，另外将Key连同时间戳标志（控制该SessionKey的有效时间）通过TGS服务的密码也就是KDC的密码加密为密文2（称为TGT），将这两个密文组合成KRB_AS_REP返回给Client-A

③：KRB_TGS_REQ：Client-A在接收到KRB_AS_REP后，首先使用自身密码解密密文1得到SessionKeya-kdc，此时需要注意的是，密文2（TGT）是被KDC的密码加密的，所以Client-A无法解密，这也是Kerberos协议设计的精妙之处，既解决了Server端（TGS相对于Client-A也称之为Server端）无法及时接收SessionKey的问题，又不怕Client-A对该TGT的伪造，因为Client-A不知道Server端的密码

得到SessionKeya-kdc后，Client-A利用其加密时间戳生成Authenticator用于向TGS申请Client-A与Client-B进行认证所需的SessionKeya-b，连同刚才KRB_AS_REP接收的TGT一同组合成KRB_TGS_REQ发送给TGS

④：KRB_TGS_REP：TGS在接收到KRB_TGS_REQ之后，利用KDC密码解密TGT获得本来就该发送给自己的SessionKeya-kdc，然后用其解密KRB_TGS_REQ中的Authenticator得到Client-A发送过来的时间戳，如果时间戳符合要求，则生成一个短期有效的SessionKeya-b，注意此时利用SessionKeya-kdc将SessionKeya-b加密为密文1，然后利用Server-B的密码将SessionKeya-b加密为密文2（称为ServiceTicket），两个密文一同构成KRB_TGS_REP返回给Client-A

⑤：KRB_AP_REQ：Client-A在接收到KRB_TGS_REP之后，首先使用缓存的SessionKeya-kdc将密文1中的SessionKeya-b解密出来，然后利用其加密时间戳生成Authenticator用于向B进行对自身的验证，另外，和刚才TGT一样，密文2也就是ServiceTicket是用Server-B的密码加密的，所以Client-A无法解密，也就无法伪造，这也同样解决了在三方认证中作为Server端的B无法及时接收SessionKey的问题，又不怕Client-A对ServiceTicket的伪造

⑥：KRB_AP_REP：Server-B受到KRB_AP_REQ之后，利用自身密码解密ServiceTicket，得到SessionKeya-b，然后用SessionKeya-b解密Authenticator得到时间戳，验证A的身份

这就是整个Kerberos协议的基本流程。