5.4.5.3.1 RDSTLS Connection Sequence

The RDSTLS connection sequence only takes place in the context of the Negotiation-Based Approach (section 5.4.2.1) of the security-enhanced connection sequence.

The RDSTLS connection sequence

 Figure 16: The RDSTLS connection sequence

Since the RDTLS protocol is primarily used in the context of server redirection scenarios (section 1.3.8) there is a strong dependency on structures exchanged in the Server Redirection Packet (section 2.2.13.1), specifically the TargetCertificate, RedirectionGuid, UserName, Domain, and Password fields. For the purpose of server authentication in the TLS protocol, the X.509 certificate extracted from the TargetCertificate field of the Server Redirection Packet MUST be identical to the certificate that the server presents for authentication. If there is a mismatch, then the client SHOULD NOT continue the TLS handshake.

The three RDSTLS PDUs (which are encrypted and wrapped by the TLS protocol using the parameters negotiated as part of the TLS handshake) are described in section 2.2.17 and are used as follows:

  1. The server sends the RDSTLS Capabilities PDU (section 2.2.17.1) to the client, advertising the versions of the RDSTLS protocol that are supported.

  2. The client sends the RDSTLS Authentication PDU to the server. This PDU will contain either encrypted password credentials (section 2.2.17.2) or an auto-reconnect cookie (section 2.2.17.3).

  3. The server notifies the client of the authentication result by sending the RDSTLS Authentication Response PDU (section 2.2.17.4).

Upon successful completion of the RDSTLS protocol, the subsequent RDP traffic is encrypted and wrapped by the TLS protocol using the parameters negotiated as part of the TLS handshake. If the RDSTLS Authentication PDU indicates that user authentication has failed, then the client SHOULD drop the connection.