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@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 11:55 PM To: ITU-SG16@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]