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： 获取目录/索引。html

S： HTTP/1.1 401未经授权

S： WWW身份验证：协商

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

C： 获取目录/索引。html

C： 授权：协商a87421000492aa874209af8bc028

S： HTTP/1.1 401未经授权

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

通过3：成功

C： 获取目录/索引。html

C： 授权：协商89a8742aa8729a8b028

S：HTTP/1.1 200成功

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

这里建立了安全上下文，因此在第三次传递时对请求进行身份验证。i、 e.第二次从客户端（C）传递到服务器（S）时，使用令牌。

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

问题2：我的直觉是，发起者和接受者循环都应该有防止无休止循环的保护。例如，如果x次尝试未建立上下文，则启动器可能会中止。对于建立安全上下文可能合理预期的传递次数，是否有任何经验法则/指标？e、 g.如果在第5次通过之前未建立安全上下文--

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

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

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

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

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

i） 尚未建立安全上下文的现有请求的后续传递--

ii）全新请求的第一次传递（来自同一客户机或来自不同客户机）--

Answer 1

使用协商协议作为示例协议，考虑它的操作方式很有用。

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

这最多需要三次往返，一次后可能会失败或完成。其他html" target="_blank">协议可能会选择做任何他们想做的事情。

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