kerberosv5的验证原理和应用.docVIP

Kerberos v5 的验证原理。 一直以来，都对kerberos v5 很感兴趣，同时也苦于没有机会好好的探索和使用。眼下比较有空闲，于是做了一些了解，并整理下来，希望以后会用到并对其他感兴趣的人有帮助。 我们先来看一下kerberos得原型： 这厮是冥府的守门狗。很佩服MIT，他们为这种安全协议找到的原型果然很形象，看起来也相当的安全啊。 下面就是kerberos v5 的验证原理图示。（不是很清晰）。 这张是大致的执行图，下面的是详细的运行过程。 这是维基百科给出来的图示，看起来是不是很费解呢，下面我来做一个解释： 为了能够解释清楚这个复杂的过程，首先来说明图示中的各个量值的含义。 Key[client] 用户端的密码 Key[client,TGS] 客户端和票证服务器的会话密钥 Key[TGS] 票证服务器的私钥 Key[client ,service] 客户端和最终访问服务器的会话密钥。 TGS（票证服务器 ）+AS（验证服务器） KDC 其基本的步骤如下描述： 客户机向AS---通常指的是域控制器，提出验证申请，申请中当然包含自己的用户名； 此时AS回馈，回馈信息中包含两部分，一部分是以客户端的密码加密的客户端client和票证服务器TGS通信的会话密钥key[client,TGS]，另一部分是一份票证ticket，用来对客户端进行验证，这份票证中包含了客户端存储于AS中的信息索引和客户端与票证服务器通信的会话密钥key[client,TGS]的副本。此票证用TGS的私钥加密。 客户端受到AS的回馈，用自己的密码解密，回去与TGS通信的会话密钥，开始向TGS提交验证信息，其中也包括两部分。一部分是要访问的服务器的Service的信息，以及从AS那里获得的ticket，另一部分是自己的验证信息，其中包含重要的访问时间戳。这部分就用他与TGS的会话密钥加密。 TGS受到信息后，首先用自己的私钥解密TICKET，从而间接的从AS那里获取 了客户端的信息，以及客户端与自己通信的会话秘钥。然后，用这个会话密钥解密客户端发来的信息，将两处客户端信息比对，如果一致，表明客户端合法。 此时TGS回馈client。回馈中依然是包含这样的两部分。其一，用客户端与自己通信的会话公钥加密的客户端与最终访问服务器通信的会话密钥 Key[client,services];另一部分是客户端最终访问服务器的信息和用该服务器私钥key[service]加密的关于客户端的信息，这就是新的票证，用来对服务器进行验证。其中也包含key[client,service],; 客户端受到回馈后，用key[client,TGS]解密出和最终访问服务器的会话密钥key[client,service],并用解密出来的私钥加密自己的信息和访问时间戳，同时连同新的票证发给最终访问服务器。 最终访问服务器收到数据后，用自己的私钥解密票证，获得客户端的信息和自己与客户端通信的key[client,service],并用该会话密钥解密客户端的时间戳，将两处数据对比，确认验证。 有上面的描述，可以看出，kerberos是双向的验证。而且是对称的验证模式。