java - GSSAPI:安全上下文循环

Question

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

• 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 次传递:由于请求没有 token 而失败:

C:获取dir/index.html

S:HTTP/1.1 401 未经授权

S:WWW-身份验证:协商

第 2 次传递:失败，但请求有 token

C:获取dir/index.html

C:授权:协商a87421000492aa874209af8bc028

S:HTTP/1.1 401 未经授权

S:WWW-身份验证:协商 749efa7b23409c20b92356

第 3 遍:成功

C:获取dir/index.html

C:授权:协商89a8742aa8729a8b028

S:HTTP/1.1 200 成功

S:WWW-身份验证:协商 ade0234568a4209af8bc0280289eca

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

问题 1:为什么在成功建立安全上下文之前，可能需要使用 token 从发起方多次传递到接受方？为什么上面的pass 2可能会失败，而pass 3却成功了？在这两次传递之间，发起者或接受者是否发生了变化？

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

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

但是对于具有多个客户端的 Http RESTful Web 服务器来说，这如何工作呢？我的假设是:

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

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

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

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

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

Answer 1

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

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

这需要最多 3 次往返，一次后可能会失败或完成。其他协议(protocol)可能会选择做任何他们想做的事情。

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