May be, we can just use random instead of timestamps as described below.
1) EPA would send "generalID_A, random_A" to EPB (unauthenticated). 2) EPB would send "generalID_B, random_B" to EPA (unauthenticated). 3) In the cryptotoken, EPA would send "random_B, generalID_x, (random_B, generalID_x)f", where generalID_x could be either generalID_A or generalID_B, and (...)f is the appropriate hash/encrypting function. random_B and generalID_x need not even be sent in the clear in the cryptotoken.
This would get rid of the replay attack problem and also the problem of dealing with time skews.
- Senthil
Senthil Sengodan Nokia Research Center ---------- From: Mailing list for parties associ To: ITU-SG16 Subject: Re: H.235 Comments Date: Tuesday, January 27, 1998 12:12PM
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