3.2.5.3.4 Processing MCS Connect Response PDU with GCC Conference Create Response
The structure and fields of the MCS Connect Response PDU with GCC Conference Create Response are specified in section 2.2.1.4. A basic high-level overview of the nested structure for the MCS Connect Response PDU is illustrated in section 1.3.1.1, in the figure specifying the MCS Connect Response PDU.
If Enhanced RDP Security (section 5.4) is in effect, the External Security Protocol (section 5.4.5) MUST be used to decrypt and verify the integrity of the entire PDU prior to any processing taking place.
The embedded length fields within the tpktHeader field ([T123] section 8) MUST be examined for consistency with the received data. If there is any discrepancy, the connection SHOULD be dropped.
The MCS Connect Response PDU (embedded within the mcsCrsp field) is specified in [T125] section 7, part 2. The client ignores the calledConnectId and domainParameters fields of this PDU. If the result field is set to rt-successful (0) the client MUST send the MCS Erect Domain Request PDU to the server (section 3.2.5.3.5). If the result field is set to any other value, the client SHOULD drop the connection.
The mcsCrsp field of the MCS Connect Response PDU contains the GCC Conference Create Response data (embedded within the gccCCrsp field). The GCC Conference Create Response is described in [T124] section 8.7 and appended as user data to the MCS Connect Response PDU using the format specified in [T124] sections 9.5 and 9.6. The client MUST ignore the specified length of the MCS Connect Response PDU user data.
The client ignores all of the GCC Conference Create Response fields, except for the userData field. The userData field of the GCC Conference Create Response MUST contain basic server settings data blocks (sections 2.2.1.4.2 through 2.2.1.4.4). The client MUST check that the server-to-client H.221 nonstandard key embedded at the start of the x224Data field ([T124] section 8.7 for a description of the structure of user data) MUST be the ANSI character string "McDn". If this is not the case, the connection SHOULD be dropped.
All of the encoded lengths within the MCS Connect Response PDU and the GCC Conference Create Response (except for those already noted) MUST also be examined for consistency with the received data. If there is any discrepancy, the connection SHOULD be dropped.
Once the mcsCrsp and gccCCrsp fields have been successfully parsed the client examines the basic server settings data blocks and stores the received data in the Received Server Data store (section 3.2.1.1). However, before the data is stored the Basic Server Settings Data Blocks are checked for validity.
The clientRequestedProtocols field in the Server Core Data (section 2.2.1.4.2) is examined to ensure that it contains the same flags that the client sent to the server in the RDP Negotiation Request (section 2.2.1.1.1). If this is not the case, the client SHOULD drop the connection. In the event that this optional field is not present, the value PROTOCOL_RDP (0) MUST be assumed.
Select settings in the Server Security Data (section 2.2.1.4.3) are validated using the following rules.
|
Server security data field |
Validation rule |
|---|---|
|
encryptionMethod |
If this field does not contain a valid Encryption Method identifier, the client SHOULD drop the connection. If the client does not support the selected Encryption Method it SHOULD disconnect because further communication with the server will not be possible. |
|
encryptionLevel |
If this field contains a nonzero value and there is not enough data to read the data in the serverRandom or serverCertificate fields, the client SHOULD drop the connection. |
|
serverRandomLen |
If this field does not contain a value of 32, the client SHOULD drop the connection. |
|
serverCertificate |
If this field does not contain a valid certificate, the client SHOULD drop the connection. Proprietary certificates (sections 3.2.5.3.1 and 5.3.3.1) SHOULD be tested for validity using the techniques specified in section 5.3.3.1.3. |
The channelCount and channelIdArray fields in the Server Network Data (section 2.2.1.4.4) MUST be examined for consistency to ensure that the packet contains enough data to extract the specified number of channel IDs. If there is not enough data, the client SHOULD drop the connection. The MCS channel IDs returned in the channelIdArray MUST be saved in the Static Virtual Channel IDs store (section 3.2.1.2), while the MCSChannelId field MUST be saved in the I/O Channel ID store (section 3.2.1.3). The MCSChannelId field in the Server Message Channel Data (section 2.2.1.4.5) MUST be saved in the Message Channel ID store (section 3.2.1.4). These IDs MUST be used by the client when sending MCS Channel Join Request PDUs (sections 2.2.1.8 and 3.2.5.3.8).
Once the basic server settings data blocks have been processed successfully, the client MUST send the MCS Attach User Request PDU (section 3.2.5.3.6) to the server.