1.3. Choosing a Principal with Which to Communicate (选择通信主体)

1.3. Choosing a Principal with Which to Communicate (选择通信主体)

Kerberos 协议提供了验证 (受第 1.6 节中假设的约束) 与之通信的实体与使用声称的身份 (主体名称) 向 KDC 注册的实体是同一实体的方法。仍然需要确定该身份是否对应于打算与之通信的实体。

当预先交换了适当的数据时, 应用程序可以根据应用协议规范、用户提供的信息和配置文件在语法上执行此确定。例如, telnet 服务器的服务器主体名称 (包括域) 可以从用户指定的主机名 (来自 telnet 命令行)、应用协议规范中指定的 "host/" 前缀以及从指定主机名的域部分和来自本地 Kerberos 域数据库的信息在语法上派生的 Kerberos 域映射中派生。

人们还可以依靠受信任的第三方来进行此确定, 但仅当从第三方获得的数据在驻留在第三方服务器上和传输时得到适当的完整性保护时才可以。因此, 例如, 不应依赖未受保护的 DNS 记录将主机别名映射到服务器的主名称, 并接受主名称作为打算联系的一方, 因为攻击者可以修改映射并冒充该方。

Kerberos 和基于 Kerberos 的协议的实现绝对不能 (MUST NOT) 使用不安全的 DNS 查询来规范化服务主体名称的主机名组件 (即, 它们绝对不能使用不安全的 DNS 查询将一个名称映射到另一个名称以确定要与之通信的主体名称的主机部分)。在没有安全名称服务的环境中, 应用程序作者可以 (MAY) 在将名称传递给安全机制之前将静态配置的域名附加到不合格的主机名, 但他们不应该做更多的事情。如果可用, 可以信任安全名称服务设施进行主机名规范化, 但 KDC 实现不应该 (SHOULD NOT) 要求客户端进行此类规范化。

实现说明: 许多当前实现对提供的服务名称进行某种程度的规范化, 通常使用 DNS, 尽管它会产生安全问题。但是, 关于服务名称是折叠为小写还是使用反向解析, 各个实现之间没有一致性。为了最大化互操作性和安全性, 应用程序应该 (SHOULD) 向安全机制提供通过将用户输入的名称折叠为小写而不执行任何其他修改或规范化所产生的名称。