| Platform SDK: Logon Authentication |
Most of the protocols implemented by Schannel provide a way to redo connection. A redo of a connection is a re-negotiation of the connection to change the encryption credentials or to restart the connection. An application can request a redo through an extension to the SSPI semantics. A redo is often used to request credentials from a client that connected to a server anonymously.
There are two sides to redo—handling incoming redo requests and generating outgoing redo requests.
Incoming redo requests are detected in an input buffer during calls to DecryptMessage. When an incoming redo request is detected, DecryptMessage returns the SEC_I_RENEGOTIATE error code. If there is data as well as redo request in the input buffer, DecryptMessage unpacks and decrypts the data and returns it in the normal buffer.
When a redo request is detected, the application returns to the negotiation loop and calls AcceptSecurityContext or InitializeSecurityContext again as it did when establishing the secure connection in the first place.
Note Empty input buffers are passed to the AcceptSecurityContext or InitializeSecurityContext in this first call.
Outgoing redo requests are generated by calling AcceptSecurityContext or InitializeSecurityContext while an Schannel connection exists. Optionally, changes such as new credentials or a request for client authentication can be made.
The application continues to process incoming messages with DecryptMessage until DecryptMessage returns SEC_I_RENEGOTIATE. Upon receipt of SEC_I_RENEGOTIATE, the application proceeds as if it received a real redo request. See Incoming Redo Requests.
The application must not immediately start the negotiation loop directly after the first call because some application protocols allow normal data transfer to continue after a redo request is sent.