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。
总结
概括起来说Kerberos协议主要做了两件事
1． Ticket的安全传递。
2． Session Key的安全发布。
再加上时间戳的使用就很大程度上的保证了用户鉴别的安全性。并且利用Session Key，在通过鉴别之后Client和Service之间传递的消息也可以获得Confidentiality(机密性), Integrity(完整性)的保证。不过由于没有使用非对称密钥自然也就无法具有抗否认性，这也限制了它的应用。不过相对而言它比X.509 PKI的身份鉴别方式实施起来要简单多了。
历史
麻省理工研发了Kerberos协议来保护Project Athena提供的网络服务器。这个协议以希腊神话中的人物Kerberos（或者Cerberus）命名，他在希腊神话中是Hades的一条凶猛的三头保卫神犬。目前该协议存在一些版本，版本1-3都只有麻省理工内部发行。
Kerberos版本4的主要设计者Steve Miller和Clifford Neuman，在1980年末发布了这个版本。这个版本主要针对Project Athena。版本5由John Kohl和Clifford Neuman设计，在1993年作为RFC 1510颁布（在2005年由RFC 4120取代），目的在于克服版本4的局限性和安全问题。
麻省理工在版权许可的情况下，制作了一个Kerberos的免费实现工具，这种情况类似于BSD。在2007年，麻省理工组成了一个Kerberos协会，以此推动Kerberos的持续发展。
因为使用了DES加密算法（用56比特的密钥），美国出口管制当局把Kerberos归类为军需品，并禁止其出口。一个非美国设计的Kerberos版本4的实现工具KTH-KRB由瑞典皇家理工研制，它使得这套系统在美国更改密码出口管理条例（2000年）前，在美国境外就可以使用。瑞典的实现工具基于一个叫做eBones的版本，而eBones基于麻省理工对外发行的基于Kerberos版本4的补丁9的Bones（跳过了加密公式和对它们的函数调用）。这些在一定程度上决定了Kerberos为什么没有被叫做eBones版。Kerbberos版本5的实现工具，Heimdal，基本上也是由发布KTH-KRB的同一组人发布。
Windows2000和后续的操作系统都默认Kerberos为其默认认证方法。RFC 3244记录整理了微软的一些对Kerberos协议软件包的添加。RFC4757"微软Windows2000Kerberos修改密码并设定密码协议"记录整理了微软用RC4密码的使用。虽然微软使用了Kerberos协议，却并没有用麻省理工的软件。
苹果的Mac OS X也使用了Kerberos的客户和服务器版本。
Red Hat Enterprise Linux4 和后续的操作系统使用了Kerberos的客户和服务器版本。
IETF Kerberos的工作小组在2005年更新了说明规范，最近的更新包括：
"加密和校验和细则"（RFC 3961）
"针对Kerberos版本5的高级加密算法（AES）加密"（RFC 3962）
Kerberos版本5说明规范的新版本"Kerberos网络认证服务（版本5）"（RFC 4120）。这个版本废弃了早先的RFC 1510，用更细化和明确的解释说明了协议的一些细节和使用方法。
GSS-API的一个新版本"Kerberos版本5 普通的安全服务应用软件交互机制：版本2"（RFC 4121） [1]