2.2.3.1 GSS-API Payload (Payload Type 0x81) Packet

This is the GSS-API payload (as specified in [GSS] section 3.3.3) without the vendor-encoding field and with additional status and flag fields.

The following diagram shows the GSS-API Payload 0x81 packet structure.

Status (4 bytes): On failure, a 4-byte error code is returned by GSS-API. This value MUST be 0x00000000 on success. Error logging SHOULD<6> be implemented.

Flags (1 byte): The following table shows the possible flag values.

Value	Meaning
0x01	GSS_NEW_GSS_EXCHANGE This flag indicates the start of a new authentication exchange. It is only valid on messages sent by an initiator.
0x02	GSS_IMPERSONATION_ACTIVE This flag indicates that the GSS-API security principal name for this exchange is to be interpreted as a user security principal name. It is only valid on messages sent by an initiator. When this flag is set, the corresponding security association (Main mode or Extended mode) MUST have the Impersonation active flag set to TRUE (see section 3.1.1).
0x04	GSS_RETRY_CURRENT_AUTHENTICATION This flag is set by the initiator or the responder to indicate the retry of the current authentication exchange with different credentials. It is valid on messages sent by an initiator or a responder.
0x08	GSS_EXPLICIT_CREDENTIALS This flag indicates that explicit credentials are being used for this GSS-API exchange. It is only valid on messages sent by an initiator. When this flag is set, the corresponding security association (main mode or extended mode) MUST have the explicit credentials flag set to TRUE (see section 3.1.1).
0x10	GSS_RESPONDER_AUTH_COMPLETE This flag is set by the responder to indicate that the authentication has completed successfully. It is only valid on messages sent by a responder.

All other flag fields MUST be set to 0 on the initiator and ignored on the responder. For more details on flag semantics, see section 3.1.1.

GSS-API_Token (variable): As specified in [GSS] section 3.3. For anonymous authentication, the GSS-API data field has a zero length. This token is obtained from the GSS subsystem as described in [GSS] section 3, with the following differences. The conf_req_flag MUST always be specified. When using Kerberos authentication, the mutual_req_flag MUST always be specified. When using Kerberos via proxy authentication, the mutual_req_flag and the UseKerberosProxyURL string (as defined in section 3.1.1) SHOULD<7> be specified. When using NTLM, the mutual_req_flag MUST NOT be specified. Because TLS allows both mutual as well as one-way authentication, the mutual_req_flag reflects the authentication mode as follows: when using mutual authentication in TLS, the mutual_req_flag MUST be specified, and when using one-way authentication in TLS, the mutual_req_flag MUST NOT be specified.

If the [GSS] subsystem on the responder has successfully completed but the [GSS] subsystem does not return GSS-API_Token data to send back to the initiator, the responder MUST send a 0-byte GSS-API_Token payload with a 0-byte GSS-API_Token.

For Kerberos, the GSS-API_Token is as specified in [RFC1964] section 1. For NTLM, the GSS-API_Token is in the format specified in [MS-NLMP], section 3.1.5.2.1 for initiator tokens, and section 3.2.5.2.1 and section 3.2.5.2.2 for responder tokens. There is no additional GSS encapsulation over what is specified in [MS-NLMP] for the tokens. For TLS, the GSS-API_Token is as specified in [RFC5246] section 7.3. The initiator tokens are the client messages, and the responder tokens are the server messages as defined in [RFC5246] section 7.3. As with NTLM, there is no additional GSS encapsulation. For anonymous, the GSS-API_Token must be 0 bytes. No additional GSS methods are supported.

Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) is not supported in AuthIP. See section 2.2.3.4 for specific GSS method negotiation.