Context Requirements

Context requirements are expressed as a combination of bit flags passed to either the InitializeSecurityContext (General) or AcceptSecurityContext (General) function. These flags affect the context in a number of ways. Not all flags apply to all contexts. Some are valid only for the server, others only for the client.

The caller uses the fContextReq parameter of the InitializeSecurityContext (General) or AcceptSecurityContext (General) call to specify a set of flags that indicate the required capabilities. When the function returns, the pfContextAttr parameter indicates the attributes of the established context. The caller determines whether the final context attributes are acceptable.

Flags requested from or returned by InitializeSecurityContext (General) are prefixed by ISC. Those requested from or returned by AcceptSecurityContext (General) are prefixed by ASC. Flags passed into a function include REQ, while returned flags include RET. For example, a request flag for mutual authentication passed to InitializeSecurityContext (General) is ISC_REQ_MUTUAL_AUTH. A server requesting mutual authentication passes ASC_REQ_MUTUAL_AUTH to AcceptSecurityContext (General). If mutual authentication is achieved, InitializeSecurityContext (General) returns ISC_RET_MUTUAL_AUTH and AcceptSecurityContext (General) returns ASC_RET_MUTUAL_AUTH. If the caller requests mutual authentication, but the security package indicates that it cannot be performed, the caller must decide whether to cancel the context or continue.

The following table describes the various context requirement flags.

Flag Description
The server in the transport application can build new security contexts impersonating the client that will be accepted by other servers as the client's contexts. Delegate works only if MUTUAL_AUTH is set. DELEGATE is currently supported only by Kerberos. Further, Kerberos will delegate only to a server that has the flag TRUSTED_FOR_DELEGATION. Do not use this flag for constrained delegation.
The communicating parties must authenticate their identities to each other. Without MUTUAL_AUTH, the client authenticates its identity to the server. With MUTUAL_AUTH, the server also must authenticate its identity to the client.
When using the Schannel security package, the server sets the ASC_RET_MUTUAL_AUTH constant only in the last call to AcceptSecurityContext (Negotiate), after certificate mapping has successfully completed.
The security package detects replayed packets and notifies the caller if a packet has been replayed. The use of this flag implies all of the conditions specified by the INTEGRITY flag.
The context must be allowed to detect out-of-order delivery of packets later through the message support functions. Use of this flag implies all of the conditions specified by the INTEGRITY flag.
The context can protect data while in transit using the EncryptMessage (General) and DecryptMessage (General) functions. The CONFIDENTIALITY flag does not work if the generated context is for the Guest account.
A new session key must be negotiated.
If the client is an interactive user, the security package must, if possible, prompt the user for the appropriate credentials.
Package-specific credential information is available in the input buffer. The security package can use these credentials to authenticate the connection.
The supplied credentials should be cached with the supplemental credentials.
The security package must allocate memory. The caller must eventually call the FreeContextBuffer function to free memory allocated by the security package.
The caller expects a three-leg authentication transaction.
Datagram semantics must be used. For more information, see Datagram Contexts.
Connection semantics must be used. For more information, see Connection-Oriented Contexts.
Stream semantics must be used. For more information, see Stream Contexts.
Error reply messages for the peer must be generated if the context fails.
Buffer integrity can be verified but no sequencing or reply detection is enabled.
The INTEGRITY requirement is ignored.
When a server impersonates a context that has this flag set, that impersonation yields extremely limited access. Impersonation with IDENTIFY set is used to verify the client's identity.