Subject: 128-bit CAST and US export controls

From: "Ron Hoffman" <[email-masked]>
Date: Tue, 26 Mar 2002 16:38:30 -0500

The CAST5-CBC encryption algorithm uses 128-bit keys and thus is subject
to US export controls.  My first thought was to fall back to 56-bit
DES-CBC if 128-bit keys could not be used.  However, there is really no
way to inform
the application that the default confidentiality algorithm is using
56-bit keys instead of 128-bit keys (I'm assuming that applications will
specify GSS_C_QOP_DEFAULT when calling gss_wrap).  This means security
would be
downgraded without the knowledge of the application, which really isn't
a good idea.

So now I'm thinking of not providing confidentiality services at all if
128-bit keys cannot be used.  The application would be informed of this
action because the GSS_C_CONF_FLAG would not be set in the return flags
from gss_init_sec_context/gss_accept_sec_context and the confidentiality
state would be set to 0 on return from gss_wrap.

Does anybody have any thoughts on this?  Should we fall back to DES-CBC
if CAST5-CBC is not available?  Or should we disable confidentiality
services (given that CAST5-CBC is a mandatory algorithm)?

Ron Hoffman ([email-masked])

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 27 Mar 2002 09:46:19 -0500

On Tuesday, March 26, 2002, at 04:38 , Ron Hoffman wrote:

> to US export controls.

IETF policy on standards is to ignore any national restrictions
(for any country), because the IETF operates globally.  So from
a standards perspective, any US export controls are irrelevant
to the standards making process.  Of course particular implementations
might have to make implementation choices based on their own
circumstances, but that ought not be driving the IETF specs.

IMHO,

Ran

---

From: "Ron Hoffman" <[email-masked]>
Date: Wed, 27 Mar 2002 11:14:38 -0500

Agreed.  My problem stems from the fact that CAST5-CBC with 128-bit keys
is a mandatory algorithm and not a recommended algorithm for RFC 2847.
So I'm left with either violating the RFC or not providing LIPKEY on
those systems which are not allowed to use 128-bit keys.

I think I'm going to add a new GSS-API routine to return the available
integrity and confidentiality algorithms for a given security context
(this is something that I've wanted for Kerberos anyways since the
available Kerberos algorithms depend upon the session key type).  The
application can then decide whether or not to use the context based upon
the available algorithms.

So, for systems without 128-bit encryption support, I will not negotiate
CAST5-CBC and will use DES-CBC instead (assuming the other side offers
DES-CBC).  Otherwise, the GSS_C_CONF_FLAG will not be returned to the
application, indicating confidentiality services are not available.

From an interoperability point of view, a portable application could
specify the QOP using the STRONG/MEDIUM/WEAK designations instead of
using GSS_C_QOP_DEFAULT.  The gss_wrap() request would then return 0 for
the conf_state if 128-bit CAST5-CBC was not available.

Ron