Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!apple!bionet!agate!shelby!ALLSPICE.LCS.MIT.EDU!Saltzer
From: Saltzer@ALLSPICE.LCS.MIT.EDU (Jerry Saltzer)
Newsgroups: comp.protocols.kerberos
Subject: Change in Export Rules
Message-ID: <8906211835.AA08567@PTT.LCS.MIT.EDU>
Date: 21 Jun 89 18:35:51 GMT
References: <890621.094116.lawrence@s47.Prime.COM>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 80


   From: Scott Lawrence <lawrence@s47.prime.com>
   Date:       Wed, 21 Jun 89 09:41:16 EST

   At last weeks NIST OSI Implementors Workshop Security SIG meeting, Lou Giles
   of the NSA said that the government is officially relaxing some of the
   restrictions on export of strong cryptography.  Wherever cryptography is used
   only to provide authentication and integrity services, but does not provide a
   confidentiality service, export will be permitted regardless of the strength
   of the cryptography (I specifically asked about both DES and RSA).  Licenses
   will be issued by the Dept of Commerce rather than the Dept of State, which
   will continue to control export of cryptography for confidentiality purposes.

   He expects the official announcement of the policy change to appear in the
   Federal Register in the next few weeks.

   For those of us who intend to build exportable products incorporating
   Kerberos, this is very good news.  We will have to remove the privacy
   routines, but otherwise it looks like Kerberos can be made exportable.
   ---

Unfortunately, at least on the surface this welcome change doesn't
appear to help the Kerberos export situation quite as much as one
might hope.  But it should help some.

We explored the avenue of "removing the privacy routines" quite
carefully last summer and fall, because even under the old rules it
was apparent that approval of export would be greatly expedited.

The problem is as follows: the key subroutines in question, the ones
that do encryption/decryption for authentication, are also capable of
doing encryption/decryption for confidentiality; the only way to
"remove" them from the point of view of confidentiality would be to
make them uncallable by users other than the authentication library.
That would be reasonably straightforward in a binary-only distribution
of already-loaded Kerberos clients.  As I understand it, it doesn't
matter if the code is in there, as long as there isn't an exposed
interface.  Although a sufficiently motivated hacker could expose
an interface that apparently is is not considered the main threat.

(One client would have a problem with this removal--the one that
allows users to change their own passwords, but let's leave that issue
aside for the moment, because maybe one could finesse that problem
with a restriction that one changes passwords by visiting the central
office.)

It would be somewhat harder, though perhaps still possible, to make
the encryption subroutines uncallable in a binary-only distribution of
the Kerberos library.  The method would be to bind together a copy of
the DES binary with each calling binary, and suppress the DES entry
points in the result.  To avoid ending up with 13 copies of the DES
binary, one would probably bind all of the Kerberos library into one
giant binary.  Slightly awkward, but doable.

The real hangup is that in a source distribution, we couldn't imagine
any way to suppress access to the ability of the DES encryption and
decryption routines to be used for privacy.  So we still can't get
Kerberos to foreign vendors, foreign customers of domestic vendors who
require source, and foreign universities who want to do research on
authentication based on Kerberos.

Thus the situation is mixed.  For binary products, the new rules
may be very helpful.  For source export they may not help at all.

Nevertheless, it will be worth studying the new rules very carefully,
to see if any other previously closed avenues are opened up, or if
there is some interpretation by which they can be made to apply even
to source distributions.  Thanks for the report.

Incidentally, another completely different approach was suggested by
Li Gong at the University of Cambridge last week.  He pointed out that
it is possible (with much redesign) to construct a version of the
Kerberos protocols that performs authentication using ONLY
one-way-encryption operations.  Such a protocol would be of interest
for export because it would seem to be within the scope of the new
rules to ship out a source distribution with the DES encryption
subroutine used in a one-way mode, and the DES decryption subroutine
completely omitted.

					Jerry Saltzer