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.
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.
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.
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.
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.
Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used.
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).
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: Friday, September 17, 1999 1:41 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Questions on H.235
At 12:28 1999-09-16 +0200, Euchner Martin wrote:
>The generalID of the GK could be configured in the endpoint or could be made available by some other means out of band. >In the next version of H.235 (i.e. H.235v2) the ClearToken will feature both the source and the destination identifiers. Then, the EP will learn the generalID of the GK. The crucial point is still the initial GRQ which either comes with some reduced security when not including the GK-ID or with increased security but also increased complexity when the EP has to know the GK-ID by some other means a priori. > >The basis for the H.235 security protocols are ISO/IEC 11770-3 (7.2) and ISO/IEC 9798-2 (5.1.2) / 9798-4 (5.1.1). These security protocols always carry the destination address/identification in their message in order to counter reflection attacks (a special variant of a replay attack). Thus, the generalID_A in the phase I reply message is correct.
By this logic, and pre-knowledge of generalID_b, message 1 of phase 1 should contain generalID_b in the CryptoToken. This not only counters reflection (replay against the same receiver) but the more general case of replay against a different receiver.
The ClearToken on the other hand, could contain the identifier of the sender, so that the receiver can identify the correct cryptographic material to use to verify the signature in the CryptoToken (unless that information appears elsewhere in the message). It is a good idea to include both identifiers in the ClearToken within the signed CryptoToken.
Have I missed the H.235v2 draft somewhere? Are there APCs addressing this (and other) change(es), or are you alluding to future APCs?
While I have a number of security/cryptography texts on my bookshelf, the referenced ISO/IEC ones are not among them. I only have the ITU-T and joint ISO-ITU-T (X-series) ones.
>2. Man-in-the-middle attacks: The security protocol shown in Fig.1/H.235 is secure against man-in-the-middle attacks as long as the Diffie-Hellman tokens are signed with the private key or are authenticated by a cryptographic MAC. The security protocol is secure even when an attacker intercepts parts or the entire message. Basically, this is stated by the Diffie-Hellman and discrete logarithm assumptions that someone cannot break the crypto system by having access to all messages exchanged on the wire. Thus, no threat arises by snooping these parameters. >The Timestamp within the ClearToken is included in order for the recipient to verify the CryptoToken.
I think that it is open to replay against another receiver, at least for denial of service, while the timestamp is fresh. The receiver needs to create state and an eavesdropper could replay the message against all other gatekeepers in the domain. If the initial (unicast) GRQ is unsuccessful and the real gateway issues a new GRQ (with possibly same or different DH conmonent) to such a gatekeeper that is waiting for phase 2, what will it do?
Changing the generalID in the CryptoToken of message 1 to that of EPB will stop that.
>3. Please note, that the Diffie-Hellman procedure appears twice in H.235 in different contexts: The first usage of Diffie-Hellman key exchange is during RAS (as shown in Fig1/H235) where the agreed DH-secret is to encrypt the XORed sequence number (see B.4.2 of H.235)
It is used in message 3 of Figure 1 also, which is what I think is being described in B.4.2.
I don't like the mechanism described in B.4.2 for the folowing reasons.
Firstly, requiring the transmission of the ciphertext of specified cleartext opens up to the known cleartext attack. If the contents are known by both parties, then a keyed hash makes more sense.
Secondly, it relies on the success of a previous exchange. If the latest random_b were returned in an ACF which was not delivered, then all subsequent messages (including the retransmission of the ARQ) would fail authentication. It would be better to send a new timestamp_a and random_a with each request, and the keyed HMAC (e.g. HMAC-SHA1-96) of that with the DH_secret (and gatekeeperID if you like, but I don't think it adds anything).
My personal favorite is to include a ClearToken in the message, which contains the timestamp of the sender, possibly a random number or sequence, and HMAC the entire message with the shared secret. The HMAC can go in the icv (for those messages that have it - H.225.0 RAS and Annex G). The preferred solution, more widely applicable, is to place the HMAC in a CryptoToken with an OID for the purpose (as in H.225.0 Annex J).
>Another use of the Diffie-Hellman key agreement scheme is applied during call signaling. Here, the entities involved agree to a common shared secret (i.e. the DH-key) from which a key encryption key (master key) is derived. This master key is used by the H.323 master in order to securely transmit and update the media encryption key.
Note that these methods appear to provide protection for RAS messages and media, but not for call signalling, where the parties to communication have had no prior contact, unless a certificate based public key system is used.
Regards,
Douglas