Questions on H.235

Fri Sep 17 06:01:07 EDT 1999

Douglas,

as I pointed out in a former email, I'm adding the source identifier to the ClearToken in H.235v2. As you said this will improve the security.

On the other hand however, there is a specific problem using the destination identifier on multicast RAS messages like GRQ for example: Most of the recipients would then think that the received message is not destined for them. This was therefore the reason to use the source identifier instead of the destination identifier on GRQ (in violation of ISO protocols).

For unicast RAS messages, I could add the destination identifier of course. But I do not know how to handle the multicast RAS message in a better way. Using This would result at least in a partial improvement.

Yes, H.235v2 is on its way and I am already preparing a new, improved version. You will see this version at the upcoming Rapporteurs meeting in October soon. So far, no modified version of H.235 has been presented.

Denial of service attacks: It seems that this is an issue as you described. A good countermeasure is to include a sequence number into the signed message. The receiver should check the sequence number and should verify the signature before proceeding any further. This should be fixed as well in H.235v2.

Generally, I agree with you that the procedure described in B.4.2 using the XOR does not really provide any reasonable security. This method just provides a certain (instance) authentication of just one message field (the GK-identifier); any other field in the RAS message is not authenticated or protected by any means; thus replay or modification attacks on these parts are possible without detection. To be honest with you, I don't like procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak security is therefore not part of H.323 Annex J.

A much more secure protocol is thus being applied in H.323 Annex J: Protection of the entire RAS message using either HMAC-SHA1 (with a symmetric key/password) and rapid integrity checking, or an RSA-SHA1/RSA-MD5 digital signature.

Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used.

Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two scenarios: In a small closed environment with shared secrets among all the participants. Then "signing" Diffie-Hellman tokens can be done by the shared secret and using an HMAC-SHA1 (see the baseline profile). The much more scaleable scenario is satisfied with digital certificates and cryptographic signature upon the Diffie-Hellman tokens (see the sophisticated profile).

Regards,

Martin.

-----------------------------------------------------------------------
| Dipl.-Inf.                     Phone: +49 89 636-46201
| Martin Euchner                 Fax  : +49 89 636-48000
| Siemens AG
| ZT IK 3                        mailto:Martin.Euchner at 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:   Douglas Clowes [SMTP:dclowes at OZEMAIL.COM.AU]
        Sent:   Friday, September 17, 1999 1:41 AM
        To:     ITU-SG16 at mailbag.cps.intel.com
        Subject:        Re: Questions on H.235

        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