Kerberos协议主要用于计算机网络的身份鉴别(Authentication),
其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting
ticket)访问多个服务，即SSO(Single Sign
On)。由于在每个Client和Service之间建立了共享密钥，使得该协议具有相当的安全性。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
KDC - (Key Distribution Center) 密钥分发中心，一般由 AS 和 TGS组成
AS (Authentication Server) ：为用户分发TGT
TGT (Ticket Granting Ticket) ： 用户向TGS证明自己身份的Ticket，（初始票证）
TGS (Ticket Granting Server)：为用户分发到最终目的Ticket的服务器
Principal：在Kerberos中，Principal是参加认证的基本实体。一般来说有两种，一种用来表示Kerberos数据库中的用户，另一种用来代表某一特定主机，也就是说Principal是用来表示客户端和服务端身份的实体,
Principal的格式采用ASN.1标准,即Abstract Syntax Notation One，来准确定义)，Principal是由三个部分组成：名字（name），实例（instance），REALM（域）。比如一个标准的 Kerberos的用户是：name/instance@REALM
，主机是：host
。
Name：第一部分。在代表客户方的情况，它是一个用户名；在代表主机的情况，它是写成host。
Instance：第二部分。对name的进一步描述，例如name所在的主机名或name的类型等,可省略。它与第一部分之间用‘ / ’分隔，但是作为主机的描述时写成host/Instance。
Realm：第三部分。是Kerberos在管理上的划分，在 KDC中所负责的一个域数据库称作为Realm。这个数据库中存放有该网络范围内的所有Principal和它们的密钥，数据库的内容被Kerberos
的认证服务器AS和票据授权服务器TGS所使用。Realm通常是永远是大写的字符,并且在大多数Kerberos系统的配置中，一般Realm和该网络环境的DNS域是一致的。与第二部分之间用分隔，缺省为本地的Realm。
Credential：Ticket和与它相联系的会话密钥合在一起称为Credential。之所以有这个概念是因为它们是客户端在向服务器证明自己的身份时必需的两样东西．在一个Ticket的生存期内客户端会将这两样东
西以Credential为单位保存在一个Cache文件中。
Ticket：一个Ticket是一个用于安全的传递用户身份
所需要的信息的集合。它不仅包含该用户的身份，而且包含其它一些相关的信息。一般来说，它主要包括客户方 Principal，目的服务方Principal，客户方IP地址，时间戳（分发该Ticket的时间），该Ticket的生存期，以及会话密钥等内容。它的格式亦用ASN.1来准确定义。
Authenticator:
在客户端向服务端进行认证时，伴随Ticket一起发送的另外一个部分，它的作用是证明发送Ticket
的用户就是拥有Ticket的用户，即防止重放攻击。它的主要内容是一个时间戳（客户端发送Ticket的时间），在rfc1510中有它的完整的 ASN.1定义
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Kerberos协议的前提条件：
Client与KDC， KDC与Server
在协议工作前已经有了各自的共享密钥，并且由于协议中的消息无法穿透防火墙，这些条件就限制了Kerberos协议往往用于一个组织的内部
Kerberos协议分为两个部分：
1 .
Client向KDC发送自己的身份信息，KDC从TGS得到TGT，并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。此
过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式
2. Client利用之前获得的TGT向KDC请求其他Service的Ticket，从而通过其他Server的身份鉴别。
－－－－－－－－－－－－－－－－－－－－－－－－－
第二部分主要简介
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。
－－－－－－－－－－－－－－－－－－－－－－－－－－
认证过程
1) Client →
KDC（AS）：用户向密钥分配中心（KDC）申请TGT；
2) KDC → Client：通过KDC的用户密码认证，cnhawk得到KDC发放的TGT；
（之前要在KDC数据库中增加用户)
3) Client → KDC（TGS）：申请取得用户所
需要的host/s （）；
4) KDC → Client：KDC根据用户提供的TGT，KDC向用户发放host/s；
5) Client → Server：用户向Server提供用户名，TGT和host/s ；Server根据主机的上保存的host/s和用户的信息来验
证用户的登陆申请。
6) Server → Client：Server确认，发送信息给Client允许用户登陆Server。
