kerberosv5的验证原理和应用

Kerberos v5 的验证原理。

一直以来，都对kerberos v5 很感兴趣，同时也苦于没有机会好好的探索和使用。眼下比较有空闲，于是做了一些了解，并整理下来，希望以后会用到并对其他感兴趣的人有帮助。

我们先来看一下kerberos得原型：

这厮是冥府的守门狗。很佩服MIT，他们为这种安全协议找到的原型果然很形象，看起来也相当的安全啊。

下面就是kerberos v5 的验证原理图示。（不是很清晰）。

这张是大致的执行图，下面的是详细的运行过程。

这是维基百科给出来的图示，看起来是不是很费解呢，下面我来做一个解释：

为了能够解释清楚这个复杂的过程，首先来说明图示中的各个量值的含义。

Key[client]=用户端的密码

Key[client,TGS]=客户端和票证服务器的会话密钥

Key[TGS]=票证服务器的私钥

Key[client ,service]=客户端和最终访问服务器的会话密钥。

TGS（票证服务器）+AS（验证服务器）=KDC

其基本的步骤如下描述：

1.客户机向AS---通常指的是域控制器，提出验证申请，申请中当然包含自己的用户名；

2.此时AS回馈，回馈信息中包含两部分，一部分是以客户端的密码加密的客户端client和票证服务器

TGS通信的会话密钥key[client,TGS]，另一部分是一份票证ticket，用来对客户端进行验证，这份票证中包含了客户端存储于AS中的信息索引和客户端与票证服务器通信的会话密钥key[client,TGS]的副本。此票证用TGS的私钥加密。

3.客户端受到AS的回馈，用自己的密码解密，回去与TGS通信的会话密钥，开始向TGS提交验证信息，

其中也包括两部分。一部分是要访问的服务器的Service的信息，以及从AS那里获得的ticket，另一

部分是自己的验证信息，其中包含重要的访问时间戳。这部分就用他与TGS的会话密钥加密。

4.TGS受到信息后，首先用自己的私钥解密TICKET，从而间接的从AS那里获取了客户端的信息，以及

客户端与自己通信的会话秘钥。然后，用这个会话密钥解密客户端发来的信息，将两处客户端信息比对，如果一致，表明客户端合法。

5.此时TGS回馈client。回馈中依然是包含这样的两部分。其一，用客户端与自己通信的会话公钥加密

的客户端与最终访问服务器通信的会话密钥Key[client,services];另一部分是客户端最终访问服务器的信息和用该服务器私钥key[service]加密的关于客户端的信息，这就是新的票证，用来对服务器进行验证。其中也包含key[client,service],;

6.客户端受到回馈后，用key[client,TGS]解密出和最终访问服务器的会话密钥key[client,service],并用解密

出来的私钥加密自己的信息和访问时间戳，同时连同新的票证发给最终访问服务器。

7.最终访问服务器收到数据后，用自己的私钥解密票证，获得客户端的信息和自己与客户端通信的

key[client,service],并用该会话密钥解密客户端的时间戳，将两处数据对比，确认验证。

有上面的描述，可以看出，kerberos是双向的验证。而且是对称的验证模式。