Such an attack can be made even when there is only one GK, but it is more "reasonable" to attack a different GK. I think the best solution is to include both IDs (A & B) in the token, contrary to what you say, I don't see any hint to that in the standard itself (there's no room for two IDs).

LiorM -------- On 01/26/98 03:06 PM Pekka.Pessi@research.nokia.com wrote:

"EXT Lior Moscovici" Lior_Moscovici@VOCALTEC.COM writes:

Here are some comments on the last H.235 draft: They following relate to the authentication scheme in 10.3: In 10.3: We think it would be more appropriate that the party that proves its identity send its own ID in the authentication token, rather that the ID of the authenticating party. In other words, in the diagrams, EP A would rather send a token containg generalID_A, rather than generalID_B, and vice versa.

ISO/IEC 9898-2 notes: Distinguishing idenitifier B [generalID_B] is included in the token AB [token sent from A to B] to prevent the re-use of TokenAB on entity A by an adversary masquerading as entity B. ... Their [generalID] inclusion is made optional so that, in environments where such attacks cannot occur, one or both may be omitted. I can imagine some scenarios, where such attacks are possible. Let's suppose there are two gatekeepers, B and C, which use the same passwords to authenticate terminals. Terminal A sends an authorisation token to B. Now, if the generalID_B is not included in the token, an eavesdropper can send the same token to C. Pekka Pessi