Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!topaz!klinzhai!webber
From: webber@klinzhai.UUCP
Newsgroups: sci.crypt
Subject: Re: DES export restrictions bite security of DoD Internet
Message-ID: <172@brandx.klinzhai.RUTGERS.EDU>
Date: Tue, 14-Apr-87 04:58:45 EST
Article-I.D.: brandx.172
Posted: Tue Apr 14 04:58:45 1987
Date-Received: Wed, 15-Apr-87 05:06:35 EST
References: <8704070556.AA00416@ucbvax.Berkeley.EDU> <1983@hoptoad.uucp>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 62
Summary: but is it usable

[The message I am replying to is appended below.  I didn't want to
edit it, less it appear I was creating a derivative work.  Instead,
all I am doing is redistibuting it along with my reply.  Hopefully
future versions of the copyright business will be clear on the notion
of other people editing copyrighted messages.]

In the appended note, the case is made that Suns are ready to support
DES chips, but for export reasons, they do not come so equipped and
thus these chips (DES chips and related hardware support) never get
used.  My question, what would happen if you actually installed such
hardware?  Would the NFS software support it or would you then have to
make major modifications to the system software before you would
benefit from purchasing the hardware?  If you actually used such
hardware, would you notice a degradation in throughput to the disk or
does the DES hardware run DMA in parallel with the cpu and i/o
controllers?

-------------- BOB (webber@aramis.rutgers.edu ; backbone!topaz!webber)

In article <1983@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
I found this amusing message in mod.protocols.tcp-ip.  There has been a
big discussion of how an administrator at Berkeley inadvertently
scribbled a message on screens from Podunk to the Pentagon on the DoD
Internet, using the Sun "rwall" command.  Nagle seeks to put this in
perspective:

From: jbn@GLACIER.STANFORD.EDU (John B. Nagle)
Newsgroups: mod.protocols.tcp-ip
Subject: NFS security
Date: 7 Apr 87 05:43:47 GMT

       Quit worrying about "rwall".  All one can do with that is annoy
people.  Worry about Sun NFS and Berkeley RLOGIN, both of which assume
that hosts are "good guys".  Consider the following:

     If you have the means to impersonate any host by setting an interesting
number in your source IP address, and can see the replies coming back,
you can access any remotely accessable file on any NFS server.  If you are
on the same LAN, this is trivial; otherwise it may take some eavesdropping
or gateway tampering to bring it off.  Note, by the way, that large networks
constructed with low-level bridges are especially vulnerable to this type
of attack.  (This is not to be construed as an argument that IP routers
provide some kind of security).  With the advent of PC-based NFS clients,
NFS break-in can be accomplished with low-cost hardware and requires minimal 
technical sophistication.

      NFS is useful.  NFS is clever.  NFS is efficient.  NFS works.  NFS
has security holes though which one could drive an armored division.  Don't
blame Bill Joy; he's the one who insisted that SUN machines have sockets for
DES chips.  However, DoD's export controls on cryptographic equipment
discourage the use of crypto hardware in commercial equipment.  So the
socket is invariably empty.  DoD has shot itself in the foot on this one.

					John Nagle

[Nagle is right, my Suns both have sockets for an AMD encryption chip.
Both empty.  Also, the PALs that run the chip are missing, so even if I got a
DES chip and plugged it in, it wouldn't work. 		-- hoptoad!gnu]
-- 
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu