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(a)research.nokia.com wrote:
"EXT Lior Moscovici" <Lior_Moscovici(a)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
