mod-os@sdcsvax.UUCP (01/05/87)
-- From: jqj@gvax.cs.cornell.edu (J Q Johnson) Reply-To: jqj@gvax.cs.cornell.edu.cs.cornell.edu (J Q Johnson) Organization: Cornell Univ. CS Dept. Ithaca NY Re: secure transmission media. One should be careful to distinguish various possible security threats and decide which ones one wants to address. For example, it is much easier to prevent forgery than to prevent passive wiretapping. On an Ethernet, the only way to prevent wiretapping is encryption of the data, which is currently too expensive (the NBS encryption chips are generally not fast enough to keep up with Ethernet bandwidths). Various schemes exist for preventing forgery. Interested readers should look at the Xerox Authentication protocol (XSIS 098404), which provides for an Authentication server on the network and uses private-key encryption of credentials to insure that clients and servers can trust each other. It's a nice design -- too bad the tcp/ip community hasn't adopted it. A similar scheme from the tcp/ip community is the SUN NFS authentication (Goldberg & Taylor, Usenix 1986) proposal. --
mod-os@sdcsvax.UUCP (01/07/87)
-- In article <2416@sdcsvax.UCSD.EDU> you write: >Re: secure transmission media. > >[...] On an Ethernet, >the only way to prevent wiretapping is encryption of the data [...] I believe it's very important for security engineering to keep its terms in proper parlence. Encryption of data does not prevent wiretapping, it merely (and presumably) renders the envelope contents not-easily-readable. This is a significant difference. Note that the "envelope" is still available to an intruder (packet headers, message sizes, and precedence, if it's provided). Armed with this information, A good TA person could make short work of figuring out the contents, if so inclined. Preventing wiretapping (such as putting the Ethernet* inside conduit which is occasionally inspected for tampering, etc.) would eliminate the traffic analysis threat (except for situations where TEMPEST equipment might be required--which is a much more problematic setting, anyway). --
mod-os@sdcsvax.uucp (01/09/87)
--
I would like to know more about AT&T's(?) RFS. Do you know
of any technical information about it?
Thanks in advance.
Anthony Discolo
-----
Anthony Discolo
+---+---+---+---+---+---+---+
| d | i | g | i | t | a | l |
+---+---+---+---+---+---+---+
Database Systems Group
301 Rockrimmon Blvd. South
Mailstop CX01-2/N23
Colorado Springs, CO 80919
UUCP: ucbvax!decwrl!cookie.DEC!discolo
ARPA: cookie.DEC!discolo@decwrl.DEC.COM
--