Re: 128-bit CAST and US export controls

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Ron Hoffman (rhoffman@stny.rr.com)
Date: 03/27/02-10:14:38 AM Z 

Message-ID: <000601c1d5aa$7e80a040$6501a8c0@STNY.RR.COM>
From: "Ron Hoffman" <rhoffman@stny.rr.com>
Subject: Re: 128-bit CAST and US export controls
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

----- Original Message -----
From: "RJ Atkinson" <rja@extremenetworks.com>
To: "Ron Hoffman" <rhoffman@stny.rr.com>
Cc: "nfsv4-wg" <nfsv4-wg@sunroof.eng.sun.com>
Sent: Wednesday, March 27, 2002 9:46 AM
Subject: Re: 128-bit CAST and US export controls


>
> On Tuesday, March 26, 2002, at 04:38 , Ron Hoffman wrote:
>
> > The CAST5-CBC encryption algorithm uses 128-bit keys and thus is
subject
> > 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
>
>

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:38 AM Z CST