Aseem, Douglas, and others,

while I was on my long vacation, I received this message through the reflector. Let me try to answer and comment as follows:

1. Please note, that there is an error in Aseems figure: The reply message in phase I from the GK to the EP should have Time_B instead of Time_A in the ClearToken.

The generalID of the GK could be configured in the endpoint or could be made available by some other means out of band. In the next version of H.235 (i.e. H.235v2) the ClearToken will feature both the source and the destination identifiers. Then, the EP will learn the generalID of the GK. The crucial point is still the initial GRQ which either comes with some reduced security when not including the GK-ID or with increased security but also increased complexity when the EP has to know the GK-ID by some other means a priori.

The basis for the H.235 security protocols are ISO/IEC 11770-3 (7.2) and ISO/IEC 9798-2 (5.1.2) / 9798-4 (5.1.1). These security protocols always carry the destination address/identification in their message in order to counter reflection attacks (a special variant of a replay attack). Thus, the generalID_A in the phase I reply message is correct.

2. Man-in-the-middle attacks: The security protocol shown in Fig.1/H.235 is secure against man-in-the-middle attacks as long as the Diffie-Hellman tokens are signed with the private key or are authenticated by a cryptographic MAC. The security protocol is secure even when an attacker intercepts parts or the entire message. Basically, this is stated by the Diffie-Hellman and discrete logarithm assumptions that someone cannot break the crypto system by having access to all messages exchanged on the wire. Thus, no threat arises by snooping these parameters. The Timestamp within the ClearToken is included in order for the recipient to verify the CryptoToken.

3. Please note, that the Diffie-Hellman procedure appears twice in H.235 in different contexts: The first usage of Diffie-Hellman key exchange is during RAS (as shown in Fig1/H235) where the agreed DH-secret is to encrypt the XORed sequence number (see B.4.2 of H.235) Another use of the Diffie-Hellman key agreement scheme is applied during call signaling. Here, the entities involved agree to a common shared secret (i.e. the DH-key) from which a key encryption key (master key) is derived. This master key is used by the H.323 master in order to securely transmit and update the media encryption key.

Regards,

Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

-----Original Message----- From: Aseem Agarwal [SMTP:aseem@TRILLIUM.COM] Sent: Wednesday, September 08, 1999 8:51 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Questions on H.235

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