Security - H.235 message integrity

Euchner Martin Martin.Euchner at MCHP.SIEMENS.DE
Mon Sep 20 13:08:50 EDT 1999


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.

All my comments are in the text below.

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 3:00 AM
        To:     Euchner Martin
        Cc:     El-Gebaly, Hani; inowag at imtc.org
        Subject:        RE: Security

        At 14:10 1999-09-17 +0200, Euchner Martin wrote:
        >Douglas and Hani,
        >
        >
        >first I would like to confirm, that Annex J applies the method as
        described by Hani in a previous mail.
        >
        >Let's assign some mnemonics to the procedures on the table for easier
        discussion and let's call this method the "emptying method" as the ICV/hash
        field is emptied before the calculation.
        >
        >Douglas proposed two alternative methods for computing ICVs or hash values:
        >The first method - let's call it the "substitution method" for short -
        works in a similar way as the emptying method except that there is only one
        ASN.1 pass and the hash/icv value has to be located in the coded ASN.1 by a
        particular (unambiguous) bit pattern.
        >
        >I would name the other proposed method as the "envelope method" as new
        ASN.1 syntax is put around the protected message.
        >
        >While it is true that the emptying method suffers from the versioning
        problem, I do not quite understand why this does not apply also to the
        substitution method. How does a receiver with a lower protocol version know
        which fields to exclude the recomputation of? Also I doubt that the trail
        and error method for locating the bitpattern is efficient.

        Firstly, I am assuming that the Message Authentication Code ((H)MAC) is
        being performed over the entire message. I'm not sure if this assumption is
        common to us all, hence I am explicitly stating it here. This implies that
        there are *no* fields to be excluded from any recomputation.
        This is correct. In "authenticaton & integrity" mode of Annex J, the (H)MAC is computed over the entire message after the message has been ASN.1 encoded into a bitstring. This step is done by the sender as well as the receiver.

        For your substitution method, I think you are right and the method described should work without any versioning problems.

        I guess that the crucial procedure at the receiver is roughly as follows:
1)      receive the message
2)      locate and find the sender's hash value; call this result RV.
Actually, how does the receiver know where to find the hash bits in the message bitstring? The position of the hash value may vary from one RAS message to another. This sounds like a problem.... Any ideas please?
The only way I could think of is to ASN.1 decode the message, and then re-encode it with a known (default) pattern and find that pattern in the received message. The position of the hash value in the received message should correspond to the found position of the known pattern. Is it guaranteed that this procedure works independently of protocol versions???
3)      reset the hash value bits in the received message to some default pattern, then recompute the keyed hash over the message; call the result HV
4)      compare HV == RV etc ....



         Since the
        computation is over a bit string of unknown/indeterminate construction,
        versioning cannot affect the result, because at the time you generate or
        check the hash, you don't even care that it's an encoded message, much less
        PER encoded, or even ASN.1, or even RAS/Annex G - it's just a bit string.

        If I'm not clear on that, let me know and I'll try again to explain it.

        Secondly, as long as the "bitpattern" is sufficiently random, it is very
        unlikely to occur in the message randomly - one in 2^96, 2^128, or 2^160
        depending on algorithm. Of course, if one uses zeroes or spaces or the
        gatekeeperId, it's more likely, but if one uses the HMAC from the previous
        message as the bitpattern, you might get a collision every few years/millenia.

        >
        >I'm not quite certain whether I fully understood the envelope method. Is
        it true that the BESTP could be a RRQ for example, while the ABESTP would
        be the actual message sent through the wire? How does this method address
        the versioning issue? What happens when BESTP sees some extensions?

        Again, the versioning is not an issue, because the thing that is being
        signed/encrypted is just a bitstring. The checking/decrypting independent
        of the contents. It's an encapsulation or tunnelling mechanism, independent
        of what is being encapsulated or tunnelled.

        >If this is the case then it is probably already far too late for changing
        to the envelope method if it works at all. It appears to me that H.225.0
        would have to be changed fundamentally.

        Well, not really too late, and it could be made to work, but that is more
        properly a subject for the SG16 list, rather than the iNOW! list. Since the
        GRQ/GCF can indicate that the enveloped method is supported, and should be
        employed, it's just a simple versioning issue.

        This will test my understanding of ASN.1 and PER encoding... (someone
        correct me if I'm wrong).

        In H.225.0, RasMessage is a PDU and is identified in the encoded message by
        a tag value. I believe that H323-UserInformation is another. These are
        differentiated in an inbound PDU by their tag value (and channel).

        Let's invent a new H.225.0 PDU call SecurityMessage, defined as:

        SecurityMessage ::= SEQUENCE
        {
          encryptionAlgorithm   OBJECT IDENTIFIER OPTIONAL,
          encryptionParams      ParamS OPTIONAL,
          signatureAlgorithm    OBJECT IDENTIFIER OPTIONAL,
          signatureParams       ParamS OPTIONAL,
          messageText           OCTET STRING,
          signatureText         OCTET STRING OPTIONAL
        }

        toBeSecured             TYPE-IDENTIFIER.&Type(RasMessage)

        The message could be signed, or encrypted, or signed and encrypted, or
        neither (in which case it should be just a plain RAS message).

        *  Signed only: encode the RAS PDU into the toBeSecured octet string, and
        place in the messageText OCTET string. Compute the signature into
        signatureText. Set signatureAlgorithm and signatureParams with appropriate
        values.

        *  Encrypted only: encode the RAS PDU into the toBeSecured OCTET string and
        encrypt, placing the ciphertext result into messageText. Set
        encryptionAlgorithm and encryptionParams with appropriate values.

        *  Signed and Encrypted: encode the RAS PDU into the toBeSecure OCTET
        STRING. Compute the signature into signatureText. Encrypt toBeSecured into
        messageText. Set the algorithm OIDs and params with appropriate values.

        Possible variations include:

        o  Encrypt the signatureText with the same algorithm and params used on
        messageText.

        o  Next the signature structure within the encrypted structure -

        SecurityMessage ::= SEQUENCE
        {
          encryptionAlgorithm   OBJECT IDENTIFIER OPTIONAL,
          encryptionParams      ParamS OPTIONAL,
          encryptedText         OCTET STRING,
        }

        SignedRasMessage
        {
          signatureAlgorithm    OBJECT IDENTIFIER OPTIONAL,
          signatureParams       ParamS OPTIONAL,
          signatureText         OCTET STRING OPTIONAL,
          signedText            OCTET STRING
        }

        ToBeEncrypted           TYPE-IDENTIFIER.&Type(SignedRasMessage)

        ToBeSigned              TYPE-IDENTIFIER.&Type(RasMessage)

        The process: encode the RAS message, as ToBeSigned, into signedText. If
        signing, set signatureAlgorithm and signatureParams and calculate
        signatureText. Encode SignedMessage into encryptedText. If encrypting, set
        encryptionAlgorithm and encryptionParams, and encrypt encryptedText.

        In either case, and in H.235 as it stands, ParamS would be redefined as:

        ParamS ::= SEQUENCE
        {
          ranInt           INTEGER OPTIONAL,
          iv8              IV8 OPTIONAL,
          ...,
          keySequenceId    INTEGER(0..??) OPTIONAL
        }

        to accommodate a change in keys for delayed and out of order message delivery.
        >Finally, the ICV field is no longer always at the end of the message as
        certain H.225.0 v3 RAS messages have been extended by new fields since
        version 2.

        Well, I had the H.225.0 AnnexG messages in mind when I said that, and even
        then, it's not literally true. But it doesn't matter logically, as long as
        you can find the correct part.

        >Comments please.
        >
        >
        >Regards
        >
        >Martin.
        >

        Regards,

        Douglas



More information about the sg16-avd mailing list