据我了解，当客户端想要使用 Kerberos 对应用程序服务器进行身份验证时，它必须首先从 KDC 请求服务票证（如果还没有票证，则可能是票证授予票证）。对于客户端无法直接连接到 KDC 但可以连接到应用程序服务器的场景（例如，当员工将笔记本电脑带回家并想通过公司网站进行身份验证时）应用程序服务器可以提供任何方式来代理消息到KDC？看起来这不会带来任何额外的风险，因为 Kerberos 已经不信任网络。另外，有什么理由这不是默认情况下的工作方式吗？仅仅是 Kerberos 是在 NAT 不太常见的时候设计的吗？
Kerberos 应用程序服务器能否提供到 KDC 的代理连接？
信息安全
kerberos
2021-08-15 02:53:49
2个回答
有这个协议叫做IAKerb. 当客户端无法看到 KDC 时，它非常旨在允许客户端通过应用程序服务器代理消息。
它与任何 Kerberos 扩展协议一样简单。当客户端找不到 KDC 时，GSS-API 堆栈将尝试捆绑原始 Kerberos 消息并将它们填充到 SPNego 消息中并将它们发送到应用程序。Kerberos 舞蹈发生在封装的消息流内部，对应用程序本身是不透明的。一旦用户从协议流中获得所需的一切，客户端就会恢复正常并为应用程序发出票证。
这里的诀窍是找到兼容的客户端和应用程序。麻省理工学院支持它。我不认为海姆达尔支持它。Windows 绝对不支持它。苹果支持它。
您可以在 IETF 工作组中找到规范：https ://datatracker.ietf.org/doc/html/draft-ietf-kitten-iakerb-03
我不知道有什么方法可以做到这一点。对于大多数安装，通过 DNS 查找 Kerberos KDC。虽然可以在系统的配置文件中指定 KDC 列表，但它对更改的抵抗力不如 DNS。
通常，人们希望能够在看到应用程序服务器之前获得票证。例如，我的系统上有一个 PAM 模块，可以在我登录时自动获取票证授予票证，我怀疑大多数 Windows 系统的工作方式类似。为了从应用程序服务器获取 TGT，密码必须保存在内存中，直到用户选择连接到需要 Kerberos 请求的服务器，这可能会更晚或永远不会。
此外，大多数组织会 (a) 将 Kerberos 服务器暴露给 Internet，这是有多少大学在工作，或者 (b) 强制所有用户连接到 VPN 以访问组织资源（包括 KDC），这更常见企业之间。在后一种情况下，NAT 通常不是问题，因为除了最大的组织之外，还有足够的专用网络空间供所有人使用。
Kerberos 也主要是基于 UDP 的协议，通常难以代理。（例如，SSH 代理 TCP 和 Unix 套接字，但不是 UDP。）因为没有建立连接，并且很难区分丢弃的数据包、防火墙端口和没有响应的协议，所以代理不会很健壮，因为在绝大多数情况下，数据包都会被防火墙保护，因此用户在尝试使用 KDC 之前必须等待超时。虽然这对于某些交互式连接可能不是问题，但对于自动化服务或脚本来说可能是一个负担。对于相对边缘情况，它还有很多额外的代码。
即使数据包是通过主传输连接发送的，也不是所有协议都能够代理这种数据。例如，HTTP 不太适合这种情况，因为它的单请求、单响应范例，其中每个请求都单独进行身份验证。即使是现在将 SPNEGO 固定在 HTTP 上的方式也是一种黑客攻击，我很确定 IETF 的 HTTP 人员会对这种方法大喊大叫。如果我是他们，我肯定会。