H.235 Comments

[Sengodan Senthil NRC/Boston]

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 at research.nokia.com  wrote:



"EXT Lior Moscovici" <Lior_Moscovici at 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