Hi
Please see my response inline.
Regards aseem@trillium.com
From udayas@hss.hns.com Thu Sep 9 20:49 PDT 1999 Received: from turin.trillium.com (turin.trillium.com [206.216.108.218]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id UAA16738 for aseem@aiglos.trillium.com; Thu, 9 Sep 1999 20:49:10 -0700 (PDT) Received: from tapti.hss.hns.com ([139.85.242.19]) by turin.trillium.com (8.8.7/8.8.7) with ESMTP id UAA11451 for aseem@trillium.com; Thu, 9 Sep 1999 20:49:07 -0700 (PDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA20043 for aseem@trillium.com; Fri, 10 Sep 1999 10:45:03 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 652567E8.0014F3FA ; Fri, 10 Sep 1999 09:18:51 +0530 From: udayas@hss.hns.com X-Lotus-FromDomain: HSSBLR To: aseem@trillium.com (Aseem Agarwal) Message-ID: 652567E8.00146863.00@sampark.hss.hns.com Date: Fri, 10 Sep 1999 09:18:46 +0530 Subject: Re: Questions on H.235 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 2920 Status: OR
Hi i have the following questions about H.235 procedures:
The Diffie Hellman exchange as depicted in Fig 1/H.235 is as follows:
EP GK ClrTkn(Dh_a, Time_a) CryptoTkn[(genId_a, time_a,Dh_a)Sign_a] ---------------------------------------------------------------------->
ClrTkn(Dh_b, Random_b, Time_a) CryptoTkn[{genId_a,Time_b,Dh_b}Sign_b] -------<----------------------------------------------------------------------- ___________________________________________________________________________ __
ClrTkn[{(genId_b XOR Random_b XOR (x)}EHD-secret)] ----------------------------------------------------------------------------->
ClrTkn[ (genId_a, Random_b) ]<-----------------------------------------------------------------------
1.In the phase II procedure above, how does the EP know about genId_b ? I feel that the genId in cryptoToken in phase I message from GK to EP (second line in the diagram) should have genId_b and not genId_a. Is my understanding correct ? 2.As applied to RAS protocol in H.323 context, for a non subscription based authentication case: Dh_a and Dh_b have public keys for EP and Gk respectively. (x) is requestSeqNum. genId_b has gkId in GCF. What does genId_a have in GRQ ? The above exchange is NOT immune to man-in-the-middle attacks. A third party can easily snoop in and find out Dh_a, Dh_b, GkId and IntegrityMechanism algorithms as these are passed un-ecrypted in GRQ-GCF exchange. How is this authentication procedure any different from just passing a GK assigned dynamic identifier (e.g. EndPointId) in all messages to the GK ?? How is this procedure affected if the EP knows Gk's id apriori (through provisioning or out of band methods as in manual discovery)? 3. H.235 also mentions that this procedures may be used on the call signalling channel as well. The scope of the Key generated as a result of this procedure is not clearly specified. Is this key used for encryption on the call control channel or is it valid only for call signalling channel ? Any pointers would be appreciated. thanks, aseem@trillium.com
- I agree with what you say.
- Since the key is established through RAS messages like GRQ and RRQ, changing the key for call control channel may require using nonstandard fields in some messages. I do not think this is a good idea as this may lead to inter-operability problems.
***** 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:
Hi
Please see my response inline.
Regards aseem@trillium.com
From udayas@hss.hns.com Thu Sep 9 20:49 PDT 1999 Received: from turin.trillium.com (turin.trillium.com [206.216.108.218]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id UAA16738 for aseem@aiglos.trillium.com; Thu, 9 Sep 1999 20:49:10 -0700 (PDT) Received: from tapti.hss.hns.com ([139.85.242.19]) by turin.trillium.com (8.8.7/8.8.7) with ESMTP id UAA11451 for aseem@trillium.com; Thu, 9 Sep 1999 20:49:07 -0700 (PDT) Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA20043 for aseem@trillium.com; Fri, 10 Sep 1999 10:45:03 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) id 652567E8.0014F3FA ; Fri, 10 Sep 1999 09:18:51 +0530
From: udayas@hss.hns.com X-Lotus-FromDomain: HSSBLR To: aseem@trillium.com (Aseem Agarwal) Message-ID: 652567E8.00146863.00@sampark.hss.hns.com Date: Fri, 10 Sep 1999 09:18:46 +0530 Subject: Re: Questions on H.235 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 2920 Status: OR
Hi i have the following questions about H.235 procedures:
The Diffie Hellman exchange as depicted in Fig 1/H.235 is as follows:
EP GK ClrTkn(Dh_a, Time_a) CryptoTkn[(genId_a, time_a,Dh_a)Sign_a] ---------------------------------------------------------------------->
ClrTkn(Dh_b, Random_b, Time_a) CryptoTkn[{genId_a,Time_b,Dh_b}Sign_b] -------<----------------------------------------------------------------------- ___________________________________________________________________________ __
ClrTkn[{(genId_b XOR Random_b XOR (x)}EHD-secret)] ----------------------------------------------------------------------------->
ClrTkn[ (genId_a, Random_b) ]<-----------------------------------------------------------------------
1.In the phase II procedure above, how does the EP know about genId_b ? I feel that the genId in cryptoToken in phase I message from GK to EP (second line in the diagram) should have genId_b and not genId_a. Is my understanding correct ?
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).
2.As applied to RAS protocol in H.323 context, for a non subscription based authentication case: Dh_a and Dh_b have public keys for EP and Gk respectively. (x) is requestSeqNum. genId_b has gkId in GCF. What does genId_a have in GRQ ? The above exchange is NOT immune to man-in-the-middle attacks. A third party can easily snoop in and find out Dh_a, Dh_b, GkId and IntegrityMechanism algorithms as these are passed un-ecrypted in GRQ-GCF exchange. How is this authentication procedure any different from just passing a GK assigned dynamic identifier (e.g. EndPointId) in all messages to the GK ?? How is this procedure affected if the EP knows Gk's id apriori (through provisioning or out of band methods as in manual discovery)?
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.
- H.235 also mentions that this procedures may be used on the call
signalling channel as well. The scope of the Key generated as a result of this procedure is not clearly specified. Is this key used for encryption on the call control channel or is it valid only for call signalling channel ? Any pointers would be appreciated. thanks, aseem@trillium.com
- I agree with what you say.
- Since the key is established through RAS messages like GRQ and RRQ, changing the key for call control channel may require using nonstandard fields in some messages. I do not think this is a good idea as this may lead to inter-operability problems.
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.
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