The problem stems from a lack of explicit type information in keys. Several cryptologists have observed that strong typing is important in cryptographic protocols. Without it, it is too easy to replay messages containing ciphertext, using those messages in a manner different from the intended purpose.
Several examples of replay attacks fall into this category. In particular, there have been several published attacks that use signed nonces as signed keys, or vice versa. Keys and nonces are especially prone to this sort of abuse because the misuse is hard to recognize; both are seemingly arbitrary or random bit-strings. Explicit types should be coupled with nonces and keys prior to signing them.
In the X9.17 protocol the ciphertext for encrypted session keys is not always notarized. An attacker can replay un-notorized ciphertext to impersonate a party making a seemingly legitimate request for key translation. Details of the attack are presented in the novel. In short, the attacker conducts the first part of an exchange with a Key Distribution Center. Then, the attacker uses a weakly-typed ciphertext produced by the Key Distribution Center to forge a message in a seperate exchange with a Key Translation Center. Based upon this forgery (replay), the Key Translation Center will produce a ciphertext that the attacker cannot decrypt but one where the attacker knows the corresponding plaintext. The attacker can use this ciphertext, which is an encrypted key, to convince other legitimate parties to use a key which they believe to be secure. The attack is described in detail in Chapter 17 of The Electronic Money Mill.
The flaw can be exploited by an attacker to cause two parties to use a session key that the attacker chooses. Or, the attacker can fool a party, B, into executing a session with him when B believes B is talking to some other legitimate party, say A. In other words, the attacker can choose to eavesdrop on a secret exchange between two parties, or the attacker can choose to impersonate a legitimate party.
The architecture is not really relevant since the attack is possible in either architecture. If the two-layer architecture is used, then data-encrypting keys can be compromised. If the three-layer architecture is used then key-encrypting keys can be compromised.
It is the "environments" that must be used in an unusual manner before this flaw becomes a concern. The flaw involves a weakness introduced by the interaction between the Key Distribution Environment and the Key Translation Environment. The flaw requires that parties participate in both environments and that they use the same key-encrypting keys to communicate with both. Is this typical? It seems unlikely. More likely, each bank opts for one of the three environments. If any banks actually do use more than one environment, they probably use different keys to communicate with the different types of key centers.
Nonetheless, with the right configuration, the flaw is real. Nowhere in the standard is there any indication that using multiple environments is discouraged. Furthermore, FIPS-171, which contains numerous recommendations for the use of X9.17 does not discourage configurations where this flaw occurs. FIPS-171 actually encourages the use of X9.17 in a broad set of applications involving various trust models. Even if the wholesale banking networks do not use multiple key centers in the way described in the book (and permitted by X9.17), surely it is unreasonable to think that no application will... unless there is some advisory against doing so....
So be advised: if you plan to develop or use a product based on X9.17, read Chapter 17 of The Electronic Money Mill and be sure not to allow an impersonation or eavesdropping attack based upon the interplay of Key Translation and Key Distribtion centers.