5.1 Security Considerations for Implementers

The transaction processing protocol that is defined by this specification is intended for use in an environment where all participants are trusted to collaborate in driving transactions toward a final outcome.

Misuse of the Two-Phase Commit Protocol can enable participants to perform simple denial of service attacks on their transaction managers. Because transaction managers generally communicate with multiple participants simultaneously, this condition represents a denial of service to other participants.

Consequently, implementers need to take the following steps to ensure that transaction processing occurs in a secure environment:

• Each participant is expected to initialize [MS-CMPO] sessions by using Mutual Authentication, as specified in [MS-CMPO] section 3.2.1.1. For information on Security Level authentication values see section 3.2.1.

• All transaction manager and resource manager implementations uphold the following principles:

  • Every transaction reaches a common outcome for all participants, in accord with a correctly executed Two-Phase Commit Protocol.

  • No transaction remains In Doubt for a longer period of time than the application's higher-layer business logic accepts. This specific determination is implementation-specific.

• When authentication credentials are available, the acceptor is expected authorize Incoming Connections to ensure that the initiator is entitled to perform the actions that it is requesting. Implementations are recommended to adhere to the following authorization policies:

  1. The following connection types need to be accepted only for authenticated principals that have administrator privileges:

     • CONNTYPE_TXUSER_RESOLVE

     • CONNTYPE_TXUSER_TRACE

     When Incoming Authentication is available, the above connection types are required to be established by a user identity that is authenticated as an administrator.

  2. The following connection types need to be accepted only for authenticated principals whose principal name takes the form of <DomainName>\<MachineName>$:

     • CONNTYPE_PARTNERTM_PROPAGATE

     • CONNTYPE_PARTNERTM_REDELIVERCOMMIT

     • CONNTYPE_PARTNERTM_CHECKABORT

     • CONNTYPE_PARTNERTM_BRANCH

     When mutual authentication is required, the above connection types are required to be established by a user identity whose principal name takes the form of <DomainName>\<MachineName>$ where <DomainName> is a NetBIOS domain name and <MachineName> matches the NetBIOS host name of the machine initiating the connection.

  3. Transaction manager implementations need to ensure that the remote participant is a transaction manager for connection types that are used only between a superior transaction manager and a subordinate transaction manager.

An implementation can further restrict the set of supported connection types through configuration. These restrictions are reflected in the values of the grfNetworkDtcAccess, grfXaTransactions, and grfOptions fields of the TXUSER_GETSECURITYFLAGS_MTAG_FETCHED message.