Hi Please see my response inline. Regards aseem@trillium.com
***** I think that Diffie Hellman should be used ONCE either in RAS or in H.225 (in case of Direct Endpoint to Endpoint calls). Keys established by this procedure should be used for encryption on the call control channel. For changing the keys, H.245 provides messages like EncryptionUpdate. Any comments ?
Regards,
Udaya
At 10:14 1999-09-13 -0700, Aseem Agarwal wrote:
Well, from all my reading on the subject, the Identifier and TimeStamp in the signed portion (change protected) are to prevent replay attack in the following manner: a) To protect against replay attack on another destination, put in something that is specific to the *destination*. Therefore, to obtain this form of protection, the Identifier should be that of the GK (genId_b) in the first message, and that of the EP (genId_a) in the second. b) To protect against replay attack against the same destination, put in something unique - a "random" number, a sequence number, or a TimeStamp. Of these, a TimeStamp is probably the best, but since clock granularity is large, duplication can occur. A sequence number, in addition to the TimeStamp, can help make this combination unique. The TimeStamp also limits the duration for which the receiver needs to track old messages. As for how the EP knows about genId_b, it just has to be something specific to the GK. It could be the IP address to which you sent the message (theoretically).
The DH mechanism is supposed to work to create a shared secret, even when an eavesdropper knows Dh_a and Dh_b, due to the difficulty of factoring large integers. A man-in-the-middle attack is an active attack where MIM substitutes her values for the Dh_x values in the above exchange. The protection to this attack is in authenticating the Dh_x parameters, which is done here by "signing" the CryptoToken, preventing the MIM from substituting her values. I don't understand why there is a TimeStamp in the ClearToken (which can easily be changed by the MIM) unless the entire message is authenticated by a mechanism such as keyed/signed hash in the ICV. Similarly, the utility of XOR string in the third message eludes me.
With the possible exception of the gatekeeper routed call model, the RAS participants and the call signalling participants are not the same. Similarly, the call signalling and call control participants may not be the same. The DH key exchange creates a common secret, shared between the participants. A shared secret created between EP1 and GK1 by a RAS exchange cannot be used between EP1 and EP2 on a call signalling channel. If the Q.931 is GK routed, while the H.245 is direct, the same problem arises.
For changing the keys, H.245 provides messages like EncryptionUpdate. Any comments ?
And RTP has provision for identifying the key instance in effect for any given packet. Unfortunately, RAS does not. This means that a delayed packet may arrive that is encrypted with a stale key. This may also occur on retransmissions which span a key change. Care must be taken if key change is contemplated on non-media channels.
Regards,
Udaya
Douglas
participants (2)
-
Aseem Agarwal -
Douglas Clowes