In reading H.235, it seems to be vary vague with regards to how to
setup encryption profiles. Also, I see no mention of other crypto
algorithms such as Blowfish. To me, the H.235 support for
encryption seems too complicated for something that should just needs to
exchange keys and algorithms.
In developing our H.323 stack, we decided to use SSL and a couple
of simple non-standard parameters to provide the key exchange and
algorithm negotiation. The reasons we did this was because:
So, unless there are any objections, I propose we add 2 parameters
to the H.225 Setup and Connect messages:
CryptoAlgorithm would then be defined as:
CryptoAlgorithm ::= CHOICE
{
}
The cryptoKey would be the raw binary data for the key as the
algorithm accepts. Since the program would know the length of the
octet string, it could calculate the number of bits, if needed.
Other algoritmhs could be added. We should probably set a
requirement that all crypto-capable endpoints be able to use one of the
above algorithms, to increase the chances of making a secure call.
I would vote for Blowfish, but I'm not going to go against the majority
if something else wins.
Hopefully, I have explained this clearly. I think it's about
time we came up with a simple solution that is easy to add new algorithms
rather than having to use profiles. Our stack has employed
essentially this same technique with non-standard parameters, and it has
proved very efficient and stable. Plus, it's about time more H.323
endpoints support crypto since the regulations have been relaxed in the
U.S.
Any comments/flames?