Questions on H.235

[Douglas Clowes]

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