Kerberos协议教程

当前工作需要在研究kerberos，在网站上看到《Kerberos Protocol Tutorial 》，一边学习一边尝试翻译下来，给也有需要的人。下面是部分。

``````````````````````````````````````````````````````````````````````````````````````````````

1.       介绍

Kerberos协议是设计来在开放，不安全的网路上提供可信的认证，属于这个网路上的主机间的通信会被截获。然而，人们应该意识到Kerberos对那些防护脆弱的计算机不能提供任何保证：因此，认证服务器，应用服务器（例如, IMAP, POP, SMTP, TELNET, FTP, SSH, AFS, LPR,..）和客户端必须保持经常更新，这样发出请求的用户和服务器提供者的真实性才能保证。

 

以上的观点证实了一句话:”Kerberos是为了不可信的网路上的受信主机提供身份认证的协议”。 通过举例的方式重申下这个概念：如果某人获得了一个Server的访问特权，能拷贝包含密钥的文件，则Kerberos的策略是无用的。事实上，入侵者会把这个Key放到另一台PC上，然后只需获得那个Server的一个简单的欺骗DNS或者IP地址，则对客户端来说它就是一个可信的Server。

2.       目标

在描述构成Kerberos身份认证系统的元素和看看它的操作前，先列出这个协议希望达成一些目标：

 

s   用户密码必须从未在网路上传输；

s   用户密码必须从未以任何形式存储在客户机上；它必须在使用后立即丢弃；

s   用户密码必须从未以任何不加密的形式保存在认证Server的数据库里；

s   每个工作会话（work session）用户只被要求输入密码一次。因此在这会话期间，用户能以透明方式(transparently)访问被授权的所用服务器而不必再次输入密码。这个特性叫单点登录(Single Sign-On).

s   认证信息是集中管理，驻留在认证服务器(Authentication Server). 应用服务器不必包含用户的身份认证信息。这对取得厦门的结果是必须的:

  管理员能够通过在单点位置操作就可以停用任何用户的账号，而不必去提供各种服务的多个应用服务器上做操作；

  当一个用户更改密码后，同时对所有服务生效；

  没有身份认证信息的冗余，否则它们必须在不同地方得到安全保障；

s   不仅用户必须证明他就是他说的那个人，而且当被请求时，应用服务器也必须向客户机(Clients)证明它们的真实性。这个特性就是总所周知的双向认证（Mutual authentication）;

s   随着认证和授权的结束，如果需要，客户机和服务器必须能够建立加密连接。为了这个目的，Kerberos提供了对加密数据的密钥的生成和交换的支持。

3.       Kerberos组建和术语的定义

这部分是对对象和术语的定义，这些知识对随后的Kerberos协议的描述十分关键。虽然许多定义是基于其他，但不管怎样我尽可能的以这样顺序排列他们，以使在定义术语前，这个术语的含义不会给出。不管怎样，必须阅读这部分

3.1 领域(Realm)

术语：领域就是一个身份认证管理疆域。它的目的是建立这样的边界，在边界内身份认证服务器有权对用户，主机和服务器进行认证。这并不意味必须属于同一领域的用户和服务才能认证: 如果两个对象是互相信任的不同领域的部分，则身份认证也可发生。这个被称为交互认证（Cross-Authentication）的特性将在下面描述。

 

基本上，如果，只有如果一个用户/服务和某个领域的认证服务器共享密钥，则这个用户和服务器属于一个领域。

领域的名称是大小写敏感的，也就是，大写字母和小写字母是不同的，通常情况领域名称总是以大写字母出现。在一个组织中，把领域名称设为和DNS域名（大写字母表示，虽然）相同是很好的实践。当选择领域名称时候遵循这些小技巧能显著的简化Kerberos客户端的配置，当和子域建立信任关系时候它也是所需的。举例说明，如果一个组织属于 example.com这个DNS域，则把相关的Kerberos领域是EXAMPLE.COM是合适的。

3.2 Principal

一个Principal就是用来指向认证服务器数据库中特定条目(entry)的名字。一个Principal和一个给定领域的每个用户，主机和服务相关联。Principal在Kerberos 5是下列式样：

 

组件1/组件2/…/组件N@REALM （component1/component2/…/component@REALM）

 

然而，在实践中最多用到2个组件。对指向一个用户的条目，Princiapl是下面的式样：

 

名字[/实例]@领域（Name[/Instance]/REALM）

 

实例（instance）是可选的，一般是用来更好的限定用户式样。例如管理员用户通常有一个admin实例。下面是所指用户的Principals的例子：

 

[e-mail]     admin/[e-mail]       pluto/[e-mail]

 

相反，如果条目指向服务，则princials有下列样式：

 

Service/Hostname@REALM

 

第一个组件是服务名，例如IMAP, AFS,ftp. 经常host这个词用来暗指对机器的通用访问（telnet,rsh,ssh）。第二个组件是提供服务的机器的完整主机名(FQDN)。这个组件精确匹配（以小写字母）应用服务器IP地址的DNS反响解析很重要。下面是所指服务的Principals合法样例：

 

imap/[e-mail]

host/[e-mail]

afs/[e-mail]

 

注意最后的情况是个例外因为第二个组件不是一个主机名而是Principal指向的AFS单元名。最后，有些Principals并不指向用户或者服务而是在认证系统的操作中起作用。一个完整的案例就是krbtgt/REALM@REALM和它的关联键是用来加密票据授权的票据(Ticket Granting Ticket=TGT)(我们稍后会看到它)。

 

在Kerberos4，当指向服务的principal中的hostname是短格式，而不是FQDN；从未有超过2个组件，他们是用“圆点”（”.”）而不是”/”来分隔的。下面是合格的样例：

 

[e-mail]    [e-mail]                 

 

未完待续。。。。。。。