Security - H.235 message integrity

Euchner Martin Martin.Euchner at MCHP.SIEMENS.DE
Tue Sep 21 11:52:04 EDT 1999


Douglas,

thanks a lot for the detailed explanation. I'm quite convinced now that the substitution method really works without the versioning drawback of the emptying method.

As I do not have a clear feeling what the other people think about this approach; I added your substitution method as proposal to the Annex J profile for the time being. Discussion should resolve which way to go....

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 11:55 PM
        To:     ITU-SG16 at mailbag.cps.intel.com
        Subject:        Re: Security    - H.235 message integrity

        Martin,

        Firstly, I hope that the mechanism for encoding the HMAC is well
        understood, and the reason for using HMAC-SHA1-96 (RFC-2404).

        Secondly, the decoding:

        The message which arrives is a bucket of bits, inside a TPKT. (It would be
        nice to have something in the TPKT to tell us whether the message contained
        is encrypted, but it doesn't. :-( ) If it's encrypted, assume you can tell
        and decrypt it. This is what the HMAC has been calculated over, with the
        HMAC field set to zeroes.

        Decode the message and extract the HMAC from the data tree. This bit string
        occurs in the message where the HMAC is stored, and it is a random pattern
        produced by the HMAC function of the sender - it is *very* unlikely to
        occur in the message more than once.

        Search the message for the bitstring, if you don't find it, check your
        source code and PER decoder. To be safe, copy the message to a buffer, set
        the located bitstring to zero in the copy, and compute the HMAC. If it
        matches, the message is OK.

        If the HMAC does not match, search from the previously located bitstring
        plus one. If you get a second match - copy, zero-fill, compute-HMAC and
        compare as before. Repeat until you get to the end of the message or match
        the HMAC.

        No re-encoding of the message is required, nor is it desirable. Apart from
        retrieving the HMAC from the message, the HMAC location and recomputation
        is completely independent of whether the message is RAS or Annex G, much
        less which version. Hence it is completely version-safe.

        For non-repudiation, you must use public-private key pairs and
        certificates. The message is signed by computing the HASH as above, and
        then encrypting that hash with the private key.The receiver computes the
        HASH as before, decrypts with the public key,  and compares the result. If
        they match, the message is OK, and was created by the holder of the private
        key.

        If a proxy is to change components, then the proxy will have to recompute
        the MAC (keyed or signed) using its own credentials. In this case it is the
        proxy that is attempting to guarantee the integrity and authenticity of the
        message, so the EP MAC is destroyed.

        If you want to just authenticate just a few fields, so a proxy/firewall can
        change parts of the message, and the other endpoint can check the few, it
        is best to compute the authentication code on the unencoded fields. This
        can be done in a hashed CryptoToken, with the hashed values included or not
        in the CryptoToken. Extreme care must be taken to ensure that the rules for
        encoding the ToBeHashed are well specified.

        Regards,

        Douglas

        At 19:08 1999-09-20 +0200, Euchner Martin wrote:
        >Douglas,
        >
        >first of all, I'm glad to see a very interesting and fruitful discussion
        here. Thus, I would rather carry on these specific topics about the syntax
        and procedures on the SG16 discussion list and hear also other people's
        opinions about that.
        >
        [snip]



More information about the sg16-avd mailing list