5.4.2.1 Negotiation-Based Approach

The client advertises the security protocols which it supports by appending an RDP Negotiation Request (section 2.2.1.1.1) structure to the X.224 Connection Request PDU (section 2.2.1.1).

Upon receipt of the RDP Negotiation Request, the server examines the client request and selects the protocol to use. The server indicates its response to the client by appending an RDP Negotiation Response (section 2.2.1.2.1) structure to the X.224 Connection Confirm PDU (section 2.2.1.2). If the server does not support any of the protocols requested by the client, or if there was an error setting up the External Cryptographic Protocol Provider, then the server appends an RDP Negotiation Failure (section 2.2.1.2.2) structure to the X.224 Connection Confirm PDU.

If the server selects an External Security Protocol via the RDP Negotiation Response and the client accepts the server's choice, then the security protocol is instantiated by the client by calling into an External Cryptographic Protocol Provider. Once the External Security Protocol (section 5.4.5) handshake has successfully run to completion, the RDP messages resume, continuing with (a) the MCS Connect Initial PDU (section 2.2.1.3); or (b) the Early User Authorization Result PDU (section 2.2.10.2) followed by the MCS Connect Initial PDU. From this point all RDP traffic is encrypted using the External Security Protocol.

Figure 12: Negotiation-based security-enhanced connection sequence

Because both the RDP Negotiation Request and RDP Negotiation Response are initially exchanged in the clear, they are re-exchanged in the reverse direction after the External Security Protocol handshake as part of the Basic Settings Exchange phase of the RDP Connection Sequence (section 1.3.1.1). This step ensures that no tampering has taken place. The client replays the server's protocol choice in the Client Core Data (section 2.2.1.3.2), while the server replays the client's requested protocols in the Server Core Data (section 2.2.1.4.2).