3.6.4 Message Processing Events and Sequencing Rules

This protocol asks the RPC runtime to perform a strict NDR data consistency check at target level 7.0 for all methods unless otherwise specified, as specified in [MS-RPCE] section 1.3.

All the methods implemented by the RDG server SHOULD enforce appropriate security measures to make sure that the RDG client has the required permissions to execute the routines. All methods MUST be RPC calls. However, these methods MUST be called in a sequence specified in section 1.3.

The methods MAY throw an exception and the RDG client MUST handle these exceptions appropriately. The methods called by the RDG client MUST be sequential in order, as specified in section 1.3.1.1. The method details are specified in section 3.2.6.

A RDG client's invocation of each method is typically the result of local application activity. The local application at the RDG client specifies values for all input parameters. No other higher-layer triggered events are processed.

The RDG client SHOULD process errors returned from the RDG server and notify the application invoker of the error received in the higher layer.

Sequential processing rules for connection process:

  1. The RDG client MUST call TsProxyCreateTunnel to create a tunnel to the gateway.

  2. If the call fails, the RDG client MUST end the protocol and MUST NOT perform the following steps.

  3. The RDG client MUST initialize the following ADM elements using TsProxyCreateTunnel out parameters:

    1. The RDG client MUST initialize the ADM element Tunnel id with the tunnelId out parameter.

    2. The RDG client MUST initialize the ADM element Tunnel Context Handle with the tunnelContext out parameter. This Tunnel Context Handle is used for subsequent tunnel-related calls.

    3. If TSGPacketResponse->packetId is TSG_PACKET_TYPE_CAPS_RESPONSE, where TSGPacketResponse is an out parameter,

      1. The RDG client MUST initialize the ADM element Nonce with TSGPacketResponse->TSGPacket.packetCapsResponse->pktQuarEncResponse.nonce.

      2. The RDG client MUST initialize the ADM element Negotiated Capabilities with TSGPacketResponse->TSGPacket.packetCapsResponse->pktQuarEncResponse.versionCaps->TSGCaps[0].TSGPacket.TSGCapNap.capabilities.

    4. If TSGPacketResponse->packetId is TSG_PACKET_TYPE_QUARENC_RESPONSE, where TSGPacketResponse is an out parameter,

      1. The RDG client MUST initialize the ADM element Nonce with TSGPacketResponse->TSGPacket.packetQuarEncResponse->nonce.

      2. The RDG client MUST initialize the ADM element Negotiated Capabilities with TSGPacketResponse->TSGPacket.packetQuarEncResponse->versionCaps->TSGCaps[0].TSGPacket.TSGCapNap.capabilities.

  4. The RDG client MUST get its statement of health (SoH) by calling NAP EC API.<59> Details of the SoH format are specified in [TNC-IF-TNCCSPBSoH]. If the SoH is received successfully, then the RDG client MUST create an enveloped data message for the server that encrypts the SoH using the Triple Data Encryption Standard algorithm and encode it using one of PKCS #7 or X.509 encoding types, whichever is supported by the RDG server certificate context available in the ADM element CertChainData. Details about creating an enveloped data message are provided in [MSDN-ENVLOPED-DATA].

  5. The RDG client MUST copy the ADM element Nonce to TSGPacket.packetQuarRequest->data and append the encrypted SoH message into TSGPacket.packetQuarRequest->data. The RDG client MUST set the TSGPacket.packetQuarRequest->dataLen to the sum of the number of bytes in the encrypted SoH message and number of bytes in the ADM element Nonce, where TSGpacket is an input parameter of TsProxyAuthorizeTunnel. The format of the packetQuarRequest field is specified in section 2.2.9.2.1.4.

  6. The RDG client MUST call TsProxyAuthorizeTunnel to authorize the tunnel.

  7. If the call succeeds or fails with error E_PROXY_QUARANTINE_ACCESSDENIED, follow the steps later in this section. Else, the RDG client MUST end the protocol and MUST NOT follow the steps later in this section.

  8. If the ADM element Negotiated Capabilities contains TSG_NAP_CAPABILITY_IDLE_TIMEOUT, then the ADM element Idle Timeout Value SHOULD be initialized with first 4 bytes of TSGPacketResponse->TSGPacket.packetResponse->responseData and the Statement of health response variable MUST be initialized with the remaining bytes of responseData, where TSGPacketResponse is an out parameter of TsProxyAuthorizeTunnel. The format of the responseData member is specified in section 2.2.9.2.1.5.1.

  9. If the ADM element Negotiated Capabilities doesn't contain TSG_NAP_CAPABILITY_IDLE_TIMEOUT, then the ADM element Idle Timeout Value SHOULD be initialized to zero and the Statement of health response variable MUST be initialized with all the bytes of TSGPacketResponse->TSGPacket.packetResponse->responseData.

  10. Verify the signature of the Statement of health response variable using SHA-1 hash and decode it using the RDG server certificate context available in the ADM element CertChainData using one of PKCS #7 or X.509 encoding types, whichever is supported by the RDG Server certificate. The SoHR is processed by calling the NAP EC API INapEnforcementClientConnection::GetSoHResponse.

  11. If the call TsProxyAuthorizeTunnel fails with error E_PROXY_QUARANTINE_ACCESSDENIED, the RDG client MUST end the protocol and MUST NOT follow the steps later in this section.

  12. If the ADM element Idle Timeout Value is nonzero, the RDG client SHOULD start the idle time processing as specified in section 3.6.2.1.1 and SHOULD end the protocol when the connection has been idle for the specified Idle Timeout Value.

  13. If the ADM element Negotiated Capabilities contains TSG_MESSAGING_CAP_SERVICE_MSG, a TsProxyMakeTunnelCall call MAY be made by the client, with TSG_TUNNEL_CALL_ASYNC_MSG_REQUEST as the parameter, to receive messages from the RDG server.

  14. The RDG client MUST call TsProxyCreateChannel to create a channel to the target server name as specified by the ADM element Target Server Name (section 3.5.1).

  15. If the call fails, the RDG client MUST end the protocol and MUST not follow the below steps.

  16. The RDG client MUST initialize the following ADM elements using TsProxyCreateChannel out parameters.

    1. The RDG client MUST initialize the ADM element Channel id with the channelId out parameter.

    2. The RDG client MUST initialize the ADM element Channel Context Handle with the channelContext out parameter. This Channel Context Handle is used for subsequent channel-related calls.

Sequential processing rules for data transfer:

  1. The RDG client MUST call TsProxySetupReceivePipe to receive data from the target server, via the RDG server.

  2. The RDG client MUST call TsProxySendToServer to send data to the target server via the RDG server, and if the Idle Timeout Timer is started, the RDG client SHOULD reset the Idle Timeout Timer.

  3. If TsProxyMakeTunnelCall is returned, the RDG client MUST process the message and MAY call TsProxyMakeTunnelCall again with TSG_TUNNEL_CALL_ASYNC_MSG_REQUEST as the parameter.

  4. The RDG client MUST end the protocol after it receives the final response to TsProxySetupReceivePipe. The final response format is specified in section 2.2.9.4.3.

Sequential processing rules for ending the protocol:

  1. If a channel was successfully created in the connection process, the RDG client MUST call TsProxyCloseChannel to close the channel.

  2. If the RDG client called TsProxyMakeTunnelCall during the connection process and the call has not yet returned, the RDG client MUST call TsProxyMakeTunnelCall with the TSG_TUNNEL_CANCEL_ASYNC_MSG_REQUEST parameter to cancel the previous pending call.

  3. If the tunnel was successfully created during the connection process, the RDG client MUST call TsProxyCloseTunnel to close the tunnel.

Sequential processing rules when the RDG client receives a reauthentication message from the RDG server:

  1. The RDG client MUST start a new connection by calling TsProxyCreateTunnel. The packetId member of the TSGPacket MUST be set to TSG_PACKET_TYPE_REAUTH. Also, TSGPacket->packetReauth.tunnelContext MUST be initialized by the TSGPacketResponse->packetMsgResponse->messagePacket.reauthMessage->tunnelContext, which is received in the TsProxyMakeTunnelCall response.

  2. If TsProxyCreateTunnel fails, go to step 6.

  3. On successful completion of TsProxyCreateTunnel, the RDG client MUST call TsProxyAuthorizeTunnel.

  4. If TsProxyAuthorizeTunnel fails, go to step 6.

  5. On successful completion of TsProxyAuthorizeTunnel, the RDG client MUST call TsProxyCreateChannel.

  6. End of processing reauthentication message.

Other than the above, no other special message processing is required on the RDG client beyond the processing required in the underlying RPC protocol, as specified in [MS-RPCE].