Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!GVAX.CS.CORNELL.EDU!jqj
From: jqj@GVAX.CS.CORNELL.EDU (J Q Johnson)
Newsgroups: mod.protocols.tcp-ip
Subject: Authentication (was: No more NFS flames)
Message-ID: <8701081234.AA26850@gvax.cs.cornell.edu>
Date: Thu, 8-Jan-87 07:34:16 EST
Article-I.D.: gvax.8701081234.AA26850
Posted: Thu Jan  8 07:34:16 1987
Date-Received: Thu, 8-Jan-87 21:38:28 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson)
Organization: Cornell Univ. CS Dept. Ithaca NY
Lines: 47
Approved: tcp-ip@sri-nic.arpa

In his message earlier this week Joe Pallas did, I think, an excellent
job of clearing the air on SUN NFS.  I would, though, be interested in
people's comments on the issues of authentication raised during the
discussion.  I had argued that authentication was necessary at the NFS
(or RFS, or whatever) level, not just in the transport mechanism (RPC;
Note that this is the transport *mechanism* required by SMI for SUN
NFS, but that it is not, of course, in the ISO transport *layer*).
Brad Taylor disagreed, arguing that it was natural to place in the RPC
layer those things (presumably including authentication) common to
different RPC applications in the common RPC code.

My position is that in a layered network protocol suite ANY layer is a
candidate for some form of authentication or credentials.  As an
example, any file-specific authentication in a remote file system (e.g.
an encryption key, or an account string [perhaps password protected] to
be associated with a file) is necessarily idiosyncratic to the remote
file system, and hence is arguably a proper part of the RFS rather than
the underlying RPC layer.

Arguing the kinds of authentication appropriate to other layers takes
me further out on a limb, but as a first attempt:
  physical layer	should allow verification of sender's physical
     (e.g. Ethernet)	address
  network/datagram	should allow verification of sender's logical
     layer (e.g. IP)	address
  transport/stream	should allow verification that all component
     layer (e.g. TCP)	packets in fact are part of the stream
  session layer		should allow verification of user ids, etc.
			i.e. traditional "login"-style authentication
  application layer	whatever...

It should be noted that the TCP/IP suite is woefully inadequate in
providing the kinds of authentication I'd like to see possible at the
lower levels of a protocol suite.  It is trivial for an intruder with
access to the transmission media to interject false traffic, masquerade
as any host, and even insert data in the middle of a TCP stream (though
that implies that the receiver will probably get 2 different IP packets
with the same sequence number, which might set off an alarm in some
implementations...).  In the days when most IP traffic was restricted
to the ARPAnet this was not a problem but nowadays who knows by what
devious paths my packets may wend their way across country?

Note that their are provisions for "security" at the IP level; so far as
I can see they are totally useless.  What I have in mind might (?) be
implemented as an (optional) public-key encryption of a packet checksum,
where the public key was distributed along with the network address of
the destination by the domain name server.