| Previous | Table of Contents | Next |
This section describes the negotiation of security contexts between a CSS and a TSS. A TSS is said to be stateless if it does
not operate in the mode of accepting reusable (that is, stateful) security contexts. A TSS that accepts reusable security
contexts is said to be stateful. A CSS is said to be stateless if it operates in the mode of establishing transient, non-reusable
(that is, stateless) security contexts. A CSS that issues requests to establish reusable security contexts is said to be stateful.
24.3.2.1 Negotiation of Statefulness
A client initiates a stateless interaction by specifying a client_context_id of 0. A client issues a request to establish
a stateful context by including a nonzero client_context_id in an EstablishContext message.
When a stateless TSS receives a request to establish a stateful session, the TSS shall attempt to validate the security tokens
bound to the request. If the validation fails, an exception containing an appropriate ContextError service context element
shall be returned to the client. If the validation succeeds, the TSS shall negotiate to stateless by responding with a CompleteEstablishContext
message with context_stateful set to false.
A client that initiates a stateful interaction shall be capable of accepting that the target negotiated the context to stateless.
24.3.2.2 Stateful/Reusable Contexts
Each transport layer session defines a context identifier number scope. The CSS selects context identifiers for use within
a scope.
A CSS may use the EstablishContext message to issue multiple concurrent requests to establish a stateful security context
within a scope.
To avoid duplicate sessions, when the stateful EstablishContext requests sent within a scope carry equivalent security contexts,
the CSS shall assign to them the same nonzero client_context_id.
Within a scope, a TSS shall reject any request to establish a stateful context that carries a different security context from
an established context with the same client_context_id. In this case, an exception containing a ContextError service context
element shall be returned to the caller.
Two security contexts are equivalent if all of the authentication, identity, and authorization tokens match both in existence
and in value. Token values shall be evaluated for equivalence by comparing the corresponding byte sequences used to carry
the tokens in EstablishContext messages.
When a target that supports stateful contexts receives a request to establish a stateful context, the TSS shall attempt to
validate the security tokens in the EstablishContext element. If the validation succeeds, the request shall be accepted, and
the reply (if there is one) shall carry a CompleteEstablishContext element that indicates (that is, context_stateful = true)
that the context is available at the TSS for the caller’s reuse. If the validation fails, an exception containing an appropriate
ContextError service context element shall be returned to the caller.
A TSS that accepts stateful contexts shall bear the responsibility for managing the lifecycle of these sessions. Clients that
reuse stateful contexts shall capable of processing replies that indicate that an established stateful context has been unilaterally
discarded by the TSS.
A TSS shall not establish a stateful context in response to a request to establish a stateless context (that is, one with
a client_context_id of zero)
A TSS that supports stateful contexts may negotiate a request to establish a stateful context to a stateless context in order
to preserve resources. It may do so only if it does not already have an established matching stateful context.
Conversely, a stateful TSS that has negotiated a request to stateless may respond statefully to a subsequent context with
the same (non-zero) client_context_id.
Relationship to Transport-Layer
A SAS context shall not persist beyond the lifetime of the transport-layer secure association over which it was established.
Stateful SAS contexts are not compatible with transports that do not make the relationship between the connection and the
association transparent.