3.2.5.2 Sent TLS/SSL Negotiation Packet State

If the response contains a structurally valid TLS/SSL response message (TDS packet Type 0x12), the TDS client MUST pass the TLS/SSL message contained in it to the TLS/SSL layer and MUST proceed as follows:

  • If the TLS/SSL layer indicates that further handshake is needed, the TDS client MUST send to the server the TLS/SSL message obtained from the TLS/SSL layer encapsulated in TDS packet(s) of Type PRELOGIN (0x12).

  • If the TLS/SSL layer indicates successful completion of the TLS/SSL handshake, the TDS client MUST send a Login message to the server that contains the authentication scheme that is specified by the user. The TDS client then enters one of the following three states, depending on the message sent:

    • "Sent LOGIN7 record with Complete Authentication Token" state, if a Login message that contains either of the following was sent:

      • Standard authentication.

      • FEDAUTH FeatureId<55> that indicates a client library that does not need any additional information from the server for authentication.

    • The "Sent LOGIN7 record with SPNEGO packet" state, if a Login message with SPNEGO authentication was sent.

    • "Sent LOGIN7 record with Federated Authentication Information Request" state, if a Login message with FEDAUTH FeatureExt that indicates a client library that needs additional information from server for authentication was sent.

    The TDS specification does not prescribe the authentication protocol if SSPI [SSPI] authentication or federated authentication is used. The current implementation of SSPI supports NTLM [MSDN-NTLM] and Kerberos [RFC4120].

  • If login-only encryption was negotiated as described in section 2.2 in the PRELOGIN message description, then the first TDS packet of the Login message MUST be encrypted using TLS/SSL and encapsulated in a TLS/SSL message. All other TDS packets sent or received MUST be in plaintext.

  • If full encryption was negotiated as described in section 2.2 in the PRELOGIN message description, then all subsequent TDS packets sent or received from this point on MUST be encrypted using TLS/SSL and encapsulated in a TLS/SSL message.

  • If the TLS/SSL layer indicates an error, the TDS client MUST close the underlying transport connection, indicate an error to the upper layer, and enter the "Final State" state.

If the response received from the server does not contain a structurally valid TLS/SSL response or it contains a structurally valid response indicating an error, the TDS client MUST close the underlying transport connection, indicate an error to the upper layer, and enter the "Final State" state.

Show: