GSSAPI：安全上下文循环

Oracle GSSAPI Java示例和各种SPNEGO / GSSAPI IETF RFC指出，GSS发起方（客户端）和接受方（服务器）都应具有一个循环来建立安全上下文，并且客户端可能需要与建立安全上下文之前的GSS令牌。

例如，RFC4559给出了此示例：

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

C：GET dir / index.html

S：HTTP / 1.1 401未经授权

S：WWW认证：协商

Pass 2：失败，但是请求具有令牌

C：GET dir / index.html

C：授权：协商a87421000492aa874209af8bc028

S：HTTP / 1.1 401未经授权

S：WWW认证：协商749efa7b23409c20b92356

Pass 3：成功

C：GET dir / index.html

C：授权：协商89a8742aa8729a8b028

S：HTTP / 1.1 200成功

S：WWW认证：协商ade0234568a4209af8bc0280289eca

此处建立了安全上下文，因此在第三遍验证请求。也就是使用令牌从客户端（C）到服务器（S）的第二次传递。

问题1：在成功建立安全上下文之前，为什么需要从发起者到接受者带有令牌的多次传递？为什么通过以上2次失败，但是通过3次成功？这两次传递之间的发起者或接受者是否有所变化？

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

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

但是对于具有多个客户端的Http RESTful WebServer，这怎么办？我的假设是：

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

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

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

i）对尚未为其建立安全上下文的现有请求的后续遍历。 ->应该使用现有的GSSContext对象和循环。

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