7.2. KDC 消息传递和 IP 传输

7.2. KDC Messaging: IP Transports

Kerberos 定义了两种用于客户端与服务器之间通信的 IP 传输机制：UDP/IP 和 TCP/IP。

7.2.1. UDP/IP 传输

支持 IP 传输的 Kerberos 服务器（KDC）必须接受 UDP 请求，并且应当监听端口 88（十进制），除非被特别配置为监听其他 UDP 端口。当在同一主机上为多个 realm 运行多个 KDC 时，可以使用替代端口。

支持 IP 传输的 Kerberos 客户端应当支持发送 UDP 请求。客户端应当使用 KDC 发现 [7.2.3] 来识别其将要发送请求所至的 IP 地址和端口。

当使用 UDP/IP 传输联系 KDC 以发送 KRB_KDC_REQ 请求时，客户端应发送一个只包含请求编码的 UDP 数据报给 KDC。KDC 将使用一个只包含回复消息（KRB_ERROR 或 KRB_KDC_REP）编码的回复数据报，发往发送方 IP 地址上的发送端口。通过 UDP/IP 传输发出的请求，其响应也必须使用 UDP/IP 传输。如果响应无法用 UDP 处理（例如因为响应过大），则 KDC 必须返回 KRB_ERR_RESPONSE_TOO_BIG，强制客户端改用 TCP 传输重试该请求。

7.2.2. TCP/IP 传输

支持 IP 传输的 Kerberos 服务器（KDC）必须接受 TCP 请求，并且应当监听端口 88（十进制），除非被特别配置为监听其他 TCP 端口。当在同一主机上为多个 realm 运行多个 KDC 时，可以使用替代端口。

客户端必须支持发送 TCP 请求，但也可以先尝试使用 UDP 传输发送请求。客户端应当使用 KDC 发现 [7.2.3] 来识别其将要发送请求所至的 IP 地址和端口。

实现说明：如果涉及任何不支持 TCP 传输的客户端或 KDC，Kerberos 协议的某些扩展将无法成功。RFC 1510 的实现并不要求支持 TCP/IP 传输。

当 KRB_KDC_REQ 消息通过 TCP 流发送给 KDC 时，响应（KRB_KDC_REP 或 KRB_ERROR 消息）必须返回到为请求所建立的同一 TCP 流上。KDC 可以在发送响应后关闭 TCP 流，但如果预期会有后续请求，也可以将流保持开放一段合理的时间。必须小心管理 KDC 上的 TCP/IP 连接，以防止基于开放 TCP/IP 连接数量的拒绝服务攻击。

客户端必须做好准备，在收到响应后的任何时刻，流都可能被 KDC 关闭。流关闭不应被视为致命错误。相反，如果需要多次交换（例如某些形式的预认证），客户端可能需要在准备发送后续消息时建立一个新的连接。

客户端可以在收到响应后关闭流，并且如果预期不会发送后续消息，则应当关闭流。

客户端可以在收到响应之前发送多个请求，尽管它必须准备好处理在第一个响应之后连接被关闭的情况。

通过 TCP 流发送的每一个请求（KRB_KDC_REQ）和响应（KRB_KDC_REP 或 KRB_ERROR）之前，都带有请求的长度，以 4 个八位组按网络字节序表示。长度的最高位保留供未来扩展使用，当前必须设为零。如果一个不理解如何解释长度编码中最高位置位的 KDC 收到了长度最高位置位的请求，它必须返回一条错误为 KRB_ERR_FIELD_TOOLONG 的 KRB-ERROR 消息，并且必须关闭该 TCP 流。

如果在单个 TCP 连接上发送了多个请求，且 KDC 发送了多个响应，则不要求 KDC 按相应请求的顺序发送响应。这允许某些实现在每条响应准备就绪时立即发送，即使更早的请求仍在处理中（例如正在等待来自外部设备或数据库的响应）。

7.2.3. IP 网络上的 KDC 发现

Kerberos 客户端实现必须提供一种手段，使客户端能够确定 Kerberos 密钥分发中心（KDC）的位置。传统上，Kerberos 实现将此类配置信息存储在每台客户端机器上的一个文件中。经验表明，这种存储配置信息的方法会带来信息过时和扩展性问题，尤其是在使用跨 realm 认证时。本节描述了一种使用域名系统 [RFC1035] 来存储 KDC 位置信息的方法。

7.2.3.1. DNS 与 Kerberos：Realm 名称的大小写敏感性

在 Kerberos 中，realm 名称是区分大小写的。尽管强烈建议所有 realm 名称都使用全大写，但并非所有站点都采纳了这一建议。有些站点使用全小写名称，有些则使用混合大小写。另一方面，DNS 对查询是不区分大小写的。由于 realm 名称 "MYREALM"、"myrealm" 和 "MyRealm" 都各不相同，但在域名系统中解析结果相同，因此 realm 名称中只能使用大写和小写字符的一种可能组合。

7.2.3.2. 使用 DNS SRV 记录指定 KDC 位置信息

KDC 位置信息使用 DNS SRV 资源记录 [RFC2782] 存储。该资源记录的格式如下：

_Service._Proto.Realm TTL Class SRV Priority Weight Port Target

Kerberos 的服务名始终为 "kerberos"。

Proto 可以是 "udp" 或 "tcp"。如果要使用这些 SRV 记录，则所有 KDC 部署都必须同时指定 "udp" 和 "tcp" 记录。

Realm 是该记录所对应的 Kerberos realm。该 realm 必须是一个域名风格的 realm 名称。

TTL、Class、SRV、Priority、Weight 和 Target 具有 RFC 2782 中定义的标准含义。

按照 RFC 2782，用于 "_udp" 和 "_tcp" SRV 记录的端口号应当是由互联网编号分配机构（IANA）分配给 "kerberos" 的值：88（十进制），除非 KDC 被配置为监听其他 TCP 端口。

实现说明：许多现有的客户端实现不支持 KDC 发现，并被配置为向 IANA 分配的端口（88 十进制）发送请求，因此强烈建议 KDC 配置为监听该端口。

7.2.3.3. IP 网络上域名风格 Realm 名称的 KDC 发现

以下是 Kerberos realm EXAMPLE.COM 的 DNS 记录。它有两台 Kerberos 服务器：kdc1.example.com 和 kdc2.example.com。根据指定的优先级，查询应首先发往 kdc1.example.com。在这些示例记录中未使用权重。

_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.