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) 向安全机制提供通过将用户输入的名称折叠为小写而不执行任何其他修改或规范化所得到的名称。