GSSAPI：安全上下文循环

Question

Oracle GSSAPI Java 示例和各种 SPNEGO / GSSAPI IETF RFC 表明 GSS 发起方（客户端）和接收方（服务器）都应该有一个循环来建立安全上下文，并且客户端可能需要进行多次传递在建立安全上下文之前使用 GSS 令牌。

• Oracle GSSAPI 示例： https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/BasicClientServer.html

• 通用安全服务 (GSS) 协商循环的结构： https://www.rfc-editor.org/rfc/rfc7546

• Microsoft Windows 中基于 SPNEGO 的 Kerberos 和 NTLM HTTP 身份验证： https://www.rfc-editor.org/rfc/rfc4559

例如 RFC4559 给出了这个例子：

通过 1： 失败，因为请求没有令牌：

C: 获取目录/index.html

S：HTTP/1.1 401 未经授权

S: WWW-Authenticate: Negotiate

通过 2：失败，但请求有令牌

C: 获取目录/index.html

C：授权：协商a87421000492aa874209af8bc028

S：HTTP/1.1 401 未经授权

S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356

通过 3： 成功

C: 获取目录/index.html

C：授权：协商89a8742aa8729a8b028

S：HTTP/1.1 200 成功

S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca

这里建立了安全上下文，因此请求在第三次通过时被验证。即在从客户端 (C) 到服务器 (S) 的第二次传递中，使用令牌。

问题 1： 为什么在成功建立安全上下文之前，可能需要使用令牌从发起者到接受者多次传递？ 为什么上面通过 2 可能失败，但通过 3 成功？ 在这 2 次通过之间，发起方或接受方是否发生了变化？

问题 2： 我的直觉是发起者和接受者循环都应该有防止无限循环的保护。 例如，如果 x 次尝试未建立上下文，则启动器可能会中止。 是否有任何关于通过次数的经验法则/指标可以合理地预期建立安全上下文？ 例如如果第 5 遍还没有建立安全上下文 --> 中止。

问题 3： 在 Oracle GSSAPI 示例中，客户端和服务器通过套接字进行通信。 服务器构建一个专用于单个客户端的 GSSContext 对象，一直保存到服务器关闭，因此可用于多次传递以建立安全上下文。

但是这对于具有多个客户端的 Http RESTful WebServer 来说是如何工作的呢？ 我的假设是：

a) 建立安全上下文的请求的每一次传递都应该针对同一个 GSSContext 对象（而不是针对新的 GSSContext 实例）。

b) Http 服务器应该为每个新的客户端请求建立一个新的 GSSContext 实例。 （即 GSSContext 对象不应在多个客户端/请求之间共享/重用）。

如果我的假设是正确的，服务器必须区分：

i) 针对尚未建立安全上下文的现有请求的后续传递。 --> 应该使用现有的 GSSContext 对象和循环。

ii) 全新请求的第一次传递（来自相同或来自不同客户端）。 --> 应该使用一个新的 GSSContext 对象和循环。

Answer 1

使用Negotiate 作为示例协议，考虑它的运行方式很有用。

1. 服务器向客户端指示它可以支持协商。
2. 客户端同意并推断服务器可能支持的内容。
3. 客户端根据它认为服务器支持的内容（例如 Kerberos）创建一个令牌，然后创建一个其他可能的令牌类型（例如 NTLM）的列表。
4. 客户端将令牌和列表都发送到服务器。
5. 服务器要么接受初始令牌，要么决定从列表中选择其他内容。
6. 服务器向客户端表明它需要其他东西。
7. 然后客户端发送另一个首选类型的令牌。
8. 服务器接受或拒绝并适当地响应客户端。

这需要最多三个往返，并且可能会在一个之后失败或完成。其他协议可能会选择为所欲为。

您可能想要跟踪往返次数，并在达到任意高的数字后将其终止。所需资源并不高，但在负载下它会耗尽系统。