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:
1.) Crypto can be negotiated within the Setup and Connect messages,
2.) We wanted something that would work without an H.245 channel
(H.323 Annex F implementation for example), and
3.) We could not find any H.323 products that supported crypto
that we needed to be compatible with in the short term.
So, unless there are any objections, I propose we add 2 parameters to
the H.225 Setup and Connect messages:
cryptoKey OCTET STRING OPTIONAL
cryptoAlgorithm CryptoAlgorithm
CryptoAlgorithm would then be defined as:
CryptoAlgorithm ::= CHOICE
{
DES NULL,
Triple-DES NULL,
Blowfish NULL,
...
}
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?
-Brian
