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@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 1:38 AM To: ITU-SG16@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.