At 12:28 1999-09-16 +0200, Euchner Martin wrote:

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.

By this logic, and pre-knowledge of generalID_b, message 1 of phase 1 should contain generalID_b in the CryptoToken. This not only counters reflection (replay against the same receiver) but the more general case of replay against a different receiver.

The ClearToken on the other hand, could contain the identifier of the sender, so that the receiver can identify the correct cryptographic material to use to verify the signature in the CryptoToken (unless that information appears elsewhere in the message). It is a good idea to include both identifiers in the ClearToken within the signed CryptoToken.

Have I missed the H.235v2 draft somewhere? Are there APCs addressing this (and other) change(es), or are you alluding to future APCs?

While I have a number of security/cryptography texts on my bookshelf, the referenced ISO/IEC ones are not among them. I only have the ITU-T and joint ISO-ITU-T (X-series) ones.

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.

I think that it is open to replay against another receiver, at least for denial of service, while the timestamp is fresh. The receiver needs to create state and an eavesdropper could replay the message against all other gatekeepers in the domain. If the initial (unicast) GRQ is unsuccessful and the real gateway issues a new GRQ (with possibly same or different DH conmonent) to such a gatekeeper that is waiting for phase 2, what will it do?

Changing the generalID in the CryptoToken of message 1 to that of EPB will stop that.

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)

It is used in message 3 of Figure 1 also, which is what I think is being described in B.4.2.

I don't like the mechanism described in B.4.2 for the folowing reasons.

Firstly, requiring the transmission of the ciphertext of specified cleartext opens up to the known cleartext attack. If the contents are known by both parties, then a keyed hash makes more sense.

Secondly, it relies on the success of a previous exchange. If the latest random_b were returned in an ACF which was not delivered, then all subsequent messages (including the retransmission of the ARQ) would fail authentication. It would be better to send a new timestamp_a and random_a with each request, and the keyed HMAC (e.g. HMAC-SHA1-96) of that with the DH_secret (and gatekeeperID if you like, but I don't think it adds anything).

My personal favorite is to include a ClearToken in the message, which contains the timestamp of the sender, possibly a random number or sequence, and HMAC the entire message with the shared secret. The HMAC can go in the icv (for those messages that have it - H.225.0 RAS and Annex G). The preferred solution, more widely applicable, is to place the HMAC in a CryptoToken with an OID for the purpose (as in H.225.0 Annex J).

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.

Note that these methods appear to provide protection for RAS messages and media, but not for call signalling, where the parties to communication have had no prior contact, unless a certificate based public key system is used.

Regards,

Douglas