Queries on RAS security !!

[Aparna Saha]

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.

>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.

>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.

>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.

>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.

>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.

>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).

I agree with you there, but wonder if it's better to sign the entire
message, just the DH component, or both.

Regards,

Douglas

>Regards,
>
>Martin.