Help requested !

[Gregory]

Brian,

  Although you don't say, I assume you are referring to encryption of
the RTP data. Signalling encryption is easy - just use a standard
SSL/TLS channel.

  I'm curious as to why you feel a H.245 channel is needed for H.235.
There is the ability to include cryptoTokens in the SETUP and CONNECT
packets, similar to fastStart.

  One problem with the approach ofered is that is does not allow an
endpoint to provide multiple choices for the encryption algorithm. This
could be fixed by using a SEQUENCE with OPTIONAL elements, although you
would need to add storage for the keys for each method. The
capabilities-based approach in H.235 is more flexible in this regard.

  Also, please consider adding a nonStandard option to the CHOICE, with
an associated vendor ID and nonStandardField like most other H.323
options have. This allows vendors to implement private encryption
options within a number space that cannot be compromised by future
extensions to the list of standard encryption options. Again, H.235
capabilities allows this.

  Craig

On Thu, 21 Mar 2002 11:08:52 -0800
"Brian C. Wiles" <brian at STREAMCOMM.COM> wrote:

>    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

--
Craig Southeren <craigs at equival.com.au>