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@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@ozemail.com.au] Sent: Monday, September 20, 1999 3:00 AM To: Euchner Martin Cc: El-Gebaly, Hani; inowag@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