Questions on H.235

[Douglas Clowes]

At 10:14 1999-09-13 -0700, Aseem Agarwal wrote:
>Hi
>
>  Please see my response inline.
>
>Regards
>aseem at trillium.com
>
>
>
>>From udayas at 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 at 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 at 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 at 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 at hss.hns.com
>>X-Lotus-FromDomain: HSSBLR
>>To: aseem at trillium.com (Aseem Agarwal)
>>Message-ID: <652567E8.00146863.00 at 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.

>>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 at trillium.com
>>
>>
>>>1. I agree with what you say.
>>
>>>3. 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