4.3 Extended Mode Authentication Retry

In extended mode (EM), failures are handled by retrying the authentication, if possible. The following example shows an authentication retry.

Figure 33: Extended mode authentication retry

In message #7, the initiator proposes TLS, Kerberos, and NTLM authentication protocols. In message #8, the responder accepts only TLS and Kerberos. The initiator begins the TLS exchange in message #9. Failures, if any, that occur during TLS in messages #9 and #10, cause empty GSS-API payloads to be sent. When the initiator constructs message #11, it attempts the next agreed upon authentication method, which is Kerberos. Whenever the initiator begins a new GSS-API exchange, it sets the GSS_NEW_GSS_EXCHANGE bit in the Flags field of the GSS-API payload. Only the initiator can begin a new GSS-API exchange. If the responder fails and wants to initiate a new GSS-API exchange, it sets the status field to a nonzero value that corresponds to the error code<22> in the next GSS-API payload. This signals the initiator to retry.