Security - H.235 message integrity

[Euchner Martin]

Douglas,

please see my answers below in the text.

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:   Monday, September 20, 1999 1:38 AM
        To:     ITU-SG16 at mailbag.cps.intel.com
        Subject:        Re: Questions on H.235

        At 12:01 1999-09-17 +0200, Euchner Martin wrote:
        >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.

        OK, I forgot the multicast case. However, the generalId should, IMHO, be
        either that of the recipient (unicast) or not present (multicast), rather
        than that of the sender as shown.

        H.235v2 fixes this.

        >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.

        While you're at it, 10.3.2 method for forming a key from a password is
        embarrassingly weak. A short password ('X' for example) produces a key
        which is mostly zero bits. Even a longer pass phrase will prod use a key
        with high order bits set to zero in each byte, and similar characteristics
        reducing a keys strength significantly.

        Most credible schemes would use a hash function (MD5 or SHA1) over the pass
        phrase, and would not fill out the pass phrase with zeroes.

        The amount of entropy in such a key will be very low, and one should not
        use such a key for bulk encryption. To do so would provide an attacker with
        a large amount of cryptotext, some of which will be known, enabling a
        known-cryptotext attacks. An additional key generation/exchange mechanism
        should be employed.

        It is true that 10.3.2 does not provide absolute security . A more secure way would be to use hashed passwords instead of the plain PW as you wrote. However, the entropy does not increase effectively by hashing. Thus, implementations should check and avoid weak passwords by some means. Anyway, the (hashed) password is not applied to bulk encryption; rather it is used for registration and authentication purposes.

        >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.

        In UDP based protocols, strict sequencing is not possible, because message
        order and delivery and duplication are not guaranteed. An eavesdropper can
        easily generate a sequence number in the range, so a legitimate message
        will duplicate an illegitimate message sequence number.

        A signature is a more secure check.

a)      correct: strict sequencing on UDP does not work. RAS/Annex J uses the randomVal as a counter, making several messages with the same timestamp unique. This allows to detect duplicated messages.
b)      When message integrity is applied to the entire message, an attacker no longer is able to generate fake messages just by guessing the counter, as the attacker cannot compute the correct hash without possessing the password.

        >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.

        Good. It should not be part of H.235 either.

        Even if we all agree to remove B.4.2, does the ITU procedure (maintaining backwards compatibility) allow us to do?

        >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.

        I understand that HMAC-xxx-96 gives away less information on the key, and
        should be preferred for a long term password based mechanism.

        Sounds as a good suggestion. Annex J will reflect this change.

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

        Trouble is that, for a time, neither party knows that a message is lost. If
        I send you an xRQ and you send me a new random in the xCF, which random do
        you use to check my next message? It needs to be different depending on
        whether the xCF was lost or not. If you use the new one, and my next
        transmission is a retransmit of the original xRQ, will you reject it
        because it doesn't use the new random? You will have to check both.

        If I send you an xRQ that lives for a while in a router queue, receive a
        new random and use it in a message that arrives at you before the earlier
        one (out of order reception happens) and you check it against the new
        random, it matches. When the first message arrives, it has the old random.
        Will you reject it or ignore it? Either way, will I understand that I have
        to recompute it and send it again. If you reject it, I may fail the
        operation. If you ignore it, I may resend the same bit-pattern with the old
        random.

        This issue is closely linked with B.4.2; luckily, Annex J does not reference it.

        >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).

        Again, HMAC-SHA1-96 seems the preferred mechanism in IPsec (RFC-2403 and
        2402).

        see some lines above: Annex J will use the truncated hashing

        I agree with you there, but wonder if it's better to sign the entire
        message, just the DH component, or both.

        Actually, Annex J offers both methods: signing the entire message or signing only a subset including the DH params.

        Regards,

        Douglas

        >Regards,
        >
        >Martin.