Kerberos简介

Kerberos协议：

Kerberos协议主要用于计算机网络的身份鉴别(Authentication), 其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务，即SSO(Single Sign On)。由于在每个Client和Service之间建立了共享密钥，使得该协议具有相当的安全性。

条件

先来看看Kerberos协议的前提条件：

Client与KDC， KDC与Service 在协议工作前已经有了各自的共享密钥，并且由于协议中的消息无法穿透防火墙，这些条件就限制了Kerberos协议往往用于一个组织的内部， 使其应用场景不同于X.509 PKI。

 

过程

Kerberos协议分为两个部分：

1 . Client向KDC发送自己的身份信息，KDC从Ticket Granting Service得到TGT(ticket-granting ticket)， 并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。

此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密，从而获得TGT。

（此过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式）

2. Client利用之前获得的TGT向KDC请求其他Service的Ticket，从而通过其他Service的身份鉴别。

 Kerberos协议的重点在于第二部分，简介如下：

 

1．    Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址（IP），服务名，有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service， 不过Kerberos协议并没有直接将Ticket发送给Service，而是通过Client转发给Service.所以有了第二步。

2．    此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个秘密(KDC在第一步为它们创建的Session Key)， KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。

3．    为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥，所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址（IP）打包成Authenticator用Session Key加密也发送给Service。

4．    Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址（IP），服务名，有效期。然后再用Session Key将Authenticator解密从而获得用户名，用户地址（IP）将其与之前Ticket中解密出来的用户名，用户地址（IP）做比较从而验证Client的身份。

5．    如果Service有返回结果，将其返回给Client。

kinit - Obtain and cache Kerberos ticket-granting ticket

kinit is used to obtain and cache Kerberos ticket-granting tickets. This tool is similar in functionality to the kinit tool that are commonly found in other Kerberos implementations, such as SEAM and MIT Reference implementations.

The user must be registered as a principal with the Key Distribution Center (KDC) prior to running kinit.

SYNOPSIS

kinit [ commands ] []

总结

概括起来说Kerberos协议主要做了两件事

1．    Ticket的安全传递。

2．    Session Key的安全发布。

再加上时间戳的使用就很大程度上的保证了用户鉴别的安全性。并且利用Session Key，在通过鉴别之后Client和Service之间传递的消息也可以获得Confidentiality(机密性), Integrity(完整性)的保证。不过由于没有使用非对称密钥自然也就无法具有抗否认性，这也限制了它的应用。不过相对而言它比X.509 PKI的身份鉴别方式实施起来要简单多了。

具体流程

（注意：此流程使用了；此流程发生在某一个Kerberos领域中；小写字母c,d,e是客户机发出的消息，大写字母A,B,E,F,G,H是各个服务器发回的消息。）

首先，用户使用客户机（用户自己的机器）上的程序登录：

1. 用户输入用户ID和密码到客户机。
2. 客户机程序运行一个（大多数为杂凑）把密码转换成密钥，这个就是客户机（用户）的"用户密钥"（K_client）。受信任的AS通过某些安全的途径也获取了与此密钥相同的密钥。

随后，客户机认证（客户机从AS获取票据的票据（TGT））：

1. 客户机向AS发送1条消息（注意：用户不向AS发送密钥（K_client），也不发送密码）：
• 包含用户ID的明文消息，例如"用户Sunny想请求服务"（Sunny是用户ID）
2. AS检查用户ID有效性，而后返回2条消息：
• 消息A：用户密钥（K_client）加密后的"客户机-TGS会话密钥"(K_TGS-session)（会话密钥用在将来客户机与TGS的通信（会话）上）
• 消息B：TGS密钥（K_TGS）加密后的"票据授权票据"(TGT)（TGT包括：客户机-TGS会话密钥（K_TGS-session），用户ID，用户网址，TGT有效期）
3. 客户机用自己的密钥（K_client）解密A，得到客户机-TGS会话密钥（K_TGS-session）。（注意：客户机不能解密消息B，因为B是用TGS密钥（K_TGS）加密的）。

然后，服务授权（客户机从TGS获取票据（T））：

1. 客户机向TGS发送以下2条消息：
• 消息c：即消息B（K_TGS加密后的TGT），和想获取的服务的服务ID（注意：不是用户ID）
• 消息d：客户机-TGS会话密钥（K_TGS-session）加密后的"认证符"（认证符包括：用户ID，时间戳）
2. TGS用自己的密钥（K_TGS）解密c中的B得到TGT，从而得到AS提供的客户机-TGS会话密钥（K_TGS-session）。再用这个会话密钥解密d得到用户ID（认证），而后返回2条消息：
• 消息E：服务器密钥（K_SS）加密后的"客户机-服务器票据"(T)（T包括：客户机-SS会话密钥（K_SS-session），用户ID，用户网址，T有效期）
• 消息F：客户机-TGS会话密钥（K_TGS-session）加密后的"客户机-SS会话密钥"(K_SS_session)
3. 客户机用客户机-TGS会话密钥（K_TGS-session）解密F，得到客户机-SS会话密钥（K_SS_session）。（注意：客户机不能解密消息E，因为E是用SS密钥（K_SS）加密的）。

最后，服务请求（客户机从SS获取服务）：

1. 客户机向SS发出2条消息：
• 消息e：即消息E
• 消息g：客户机-服务器会话密钥（K_SS_session）加密后的"新认证符"（新认证符包括：用户ID，时间戳）
2. SS用自己的密钥（K_SS）解密e/E得到T，从而得到TGS提供的客户机-服务器会话密钥（K_SS_session）。再用这个会话密钥解密g得到用户ID（认证），而后返回1条消息（确认函：确证身份真实，乐于提供服务）：
• 消息H：客户机-服务器会话密钥（K_SS_session）加密后的"新时间戳"（新时间戳是：客户机发送的时间戳加1）
3. 客户机用客户机-服务器会话密钥（K_SS_session）解密H，得到新时间戳。
4. 客户机检查时间戳被正确地更新，则客户机可以信赖服务器，并向服务器（SS）发送服务请求。
5. 服务器（SS）提供服务。

缺陷

• 失败于单点：它需要中心服务器的持续响应。当Kerberos服务结束前，没有人可以连接到服务器。这个缺陷可以通过使用复合Kerberos服务器和缺陷认证机制弥补。
• Kerberos要求参与通信的主机的时钟同步。票据具有一定有效期，因此，如果主机的时钟与Kerberos服务器的时钟不同步，认证会失败。默认设置要求时钟的时间相差不超过10分钟。在实践中，通常用网络时间协议后台程序来保持主机时钟同步。
• 管理协议并没有标准化，在服务器实现工具中有一些差别。描述了密码更改。
• 因为所有用户使用的密钥都存储于中心服务器中，危及服务器的安全的行为将危及所有用户的密钥。
• 一个危险客户机将危及用户密码。

Reference:
http://idior.cnblogs.com/archive/2006/03/20/354027.html
http://bey2nd.blog.163.com/blog/static/12063183120141275250466/