Kerberos

历史和发展

麻省理工学院开发了Kerberos来保护雅典娜项目提供的网络服务。该协议以希腊神话人物Kerberos(或Cerberus)命名，在希腊神话中被称为哈迪斯的怪异三头护卫犬。该协议有几个版本，其中第1-3版只在麻省理工学院内部使用。

Steve Miller和Clifford Neuman是Kerberos第4版（使用56位密钥的DES加密算法）的主要设计者，他们在1989年发布了该版本，尽管他们主要是针对雅典娜项目的。

版本 5 是由 John Kohl 和 Clifford Neuman 设计的， 在 1993 年作为 RFC 1510 出现 (2005 年被 RFC 4120 所淘汰)， 其目的是为了克服版本 4 的局限性和安全问题。麻省理工学院以类似于BSD许可证的软件许可方式，免费提供了Kerberos第五版的实现。

一些公司在商业软件中使用了Kerberos第5版，包括：

·         微软的Windows 2000及以后的版本使用Kerberos作为其默认的认证方法。RFC 3244"Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols"中记载了微软对Kerberos协议套件的
一些补充。
RFC 4757记录了微软对RC4密码的
使用。
虽然微软使用了Kerberos协议，但它并没有使用MIT软件[1]。

·         苹果的Mac OS X也在其客户端和服务器版本中使用了Kerberos。

·         Red Hat Linux 4及以后的版本在客户端和服务器版本中都使用了Kerberos。

2005年，IETF Kerberos工作组为Kerberos第5版推出了新的更新规范[2].更新内容包括。

·         "加密和校验规范"（RFC 3961）；

·         "Kerberos 5的高级加密标准(AES)加密"(RFC 3962)。

·         Kerberos第5版规范"The Kerberos Network Authentication Service (V5)"(RFC 4120)的新版本。该版本废除了RFC 1510，以更详细明确的解释澄清了协议的各个方面和预期用途。

·         新版GSS-API规范"Kerberos第5版通用安全服务应用程序接口（GSS-API）机制。第二版"(RFC 4121)。

2007年，麻省理工学院成立了Kerberos联盟，继续发展。

议定书

Kerberos使用Needham-Schroeder协议作为其基础。它利用一个被称为"密钥分配中心（KDC）"的可信第三方认证，它由两个逻辑上独立的部分组成：一个认证服务器（AS）和一个票据授予服务器（TGS）。Kerberos的工作原理是基于"门票"（称为Kerberos门票），它的作用是证明用户的身份。

Kerberos 数据库。密钥分配中心(KDC)有一个秘密密钥数据库；网络上的每个实体 -- -- 无论是客户机还是服务器 -- -- 都共享一个只有自己和KDC知道的秘密密钥。对这个密钥的了解可以证明每个实体的身份。对于两个实体之间的通信，KDC产生一个会话密钥，它们可以用它来保证通信的安全。

术语"Kerberos 服务器"一般指的是 KDC。为了保证可靠性，可以使用备份 KDC。这些KDC被称为"Kerberos从服务器"。所有的从服务器都会从主 Kerberos 服务器同步它们的数据库。

术语"Kerberized 应用服务器"通常指的是客户端使用 Kerberos 票据进行认证的 Kerberized 程序。例如， Kerberos telnet 服务器就是一个 Kerberized 应用服务器的例子。而术语"Kerberized applications"则用于指 Kerberized 应用程序服务器的客户端，例如，Kerberos telnet 客户端就是一个 Kerberized 应用程序的例子。

协议的安全性在很大程度上取决于：

1. 参与者保持松散的同步时间。
2. 短暂的真实性声明：Kerberos票。

协议的简化说明

将使用以下缩写：

·         AS = 认证服务器

·         TGS = 票务批准服务器

·         SS 或 Server = 服务服务器(请求其服务的服务器用户，如打印服务器、文件服务器等...)

·         TGT = Ticket Granting Ticket（TGS的Kerberos票据，由AS准备，然后用于与TGS对话）。

简而言之，客户端使用长期共享秘密向AS进行身份验证，并从AS获得一张票。之后，客户端可以使用这个票据来获得SS使用相同共享秘密的额外票据。这些票据可以用来证明对SS的认证。

更详细的协议

基于用户客户端的登录步骤。

1. 用户在客户端机器上输入用户名和密码。
2. 客户端对输入的密码执行单向函数（主要是Hash函数），这就成为客户端/用户的秘钥。

客户端认证步骤。

1. 客户端代表用户向AS发送请求服务的明文消息。
   消息示例。"用户XYZ想请求服务"
   注：秘钥和密码都不发送给AS。
2. AS检查客户端是否在其数据库中。如果在，AS就向客户机发回以下两条信息：
• 消息A：客户端/TGS会话密钥使用客户端/用户的秘钥进行加密。
• 消息B：使用TGS的秘钥加密的TGT（包括客户端ID、客户端网络地址、票据有效期和客户端/TGS会话密钥）。
3. 客户端收到消息A和B后，对消息A进行解密，获得客户端/TGS会话密钥。这个会话密钥用于与TGS的进一步通信。此时，客户端有足够的信息向TGS认证自己。
   注意：客户端不能解密消息B，因为它是用TGS的秘钥加密的。

客户服务授权步骤。

1. 在请求服务时，客户端向TGS发送以下两条消息。
• 消息C：由消息B的TGT和请求服务的ID组成。
• 消息D．认证器（由客户端ID和时间戳组成），使用客户端/TGS会话密钥加密。
2. 收到消息C和D后，TGS从消息C中检索出消息B，并使用TGS秘钥对消息B进行解密。这就给了它客户端/TGS会话密钥。使用该密钥，TGS解密消息D（Authenticator）并向客户端发送以下两条消息。
• 消息E：客户端到服务器的票据（包括客户端ID、客户端网络地址、有效期和客户端/服务器会话密钥）使用SS秘钥加密。
• 消息F：客户端/服务器会话密钥与客户端/TGS会话密钥加密。

客户服务请求步骤。

1. 当收到TGS发来的消息E和F后，客户端有足够的信息向SS认证自己。客户端连接到SS，并发送以下两个消息。
• 消息E：来自上一步（客户端到服务器的票据，使用SS秘钥加密）。
• 消息G：一个新的验证器，其中包括客户端ID、时间戳，并使用客户端/服务器会话密钥进行加密。
2. SS使用自己的秘钥对票据进行解密，取回客户端/服务器会话密钥。SS使用会话密钥解密Authenticator，并向客户端发送以下消息，以确认其真实身份和服务客户的意愿。
• 消息H：在客户端的Authenticator中找到的时间戳加1，使用客户端/服务器会话密钥加密。
3. 客户端使用客户端/服务器会话密钥解密确认，并检查时间戳是否正确更新。如果是，那么客户端就可以信任服务器，并开始向服务器发出服务请求。
4. 服务器向客户端提供请求的服务。

缺点

• 单点故障。它需要一个中央服务器的持续可用性。当Kerberos服务器宕机时，没有人可以登录。这可以通过使用多个Kerberos服务器和应急认证机制来解决。
• Kerberos 要求所有参与的主机的时钟都要同步。票有一个时间可用期，如果主机时钟与Kerberos服务器时钟不同步，认证将失败。默认配置要求时钟时间的间隔不超过10分钟。在实际操作中，通常使用网络时间协议 (NTP) 来保持所有主机的同步。
• 管理协议不是标准化的，在服务器实现之间存在差异。密码的更改在RFC 3244中描述。
• 由于所有用户的秘钥都存储在中央服务器上，如果该服务器被破坏，所有用户的秘钥都会被破坏。
• 泄露的客户端会泄露用户的密码。

相关网页

• 身份管理
• 安全远程密码协议（SRP）
• 通用安全服务应用程序接口(GSS-API)