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.
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Status |
|||||||||||||||||||||||||||||||
|
Flags |
GSS-API_Token (variable) |
||||||||||||||||||||||||||||||
|
... |
|||||||||||||||||||||||||||||||
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.