jqj@GVAX.CS.CORNELL.EDU (J Q Johnson) (01/08/87)
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.karn@FLASH.BELLCORE.COM (Phil R. Karn) (01/09/87)
I am also interested in ways to add authentication to TCP/IP. The specific motivation for this is amateur packet radio. FCC rules prohibit encryption per se, though authentication based on cryptographic techniques is okay as long as the actual information content of the message is in the clear. I have therefore been thinking along the lines of adding an option to IP containing an authenticator. This field would be computed only across the data portion of the datagram (i.e., everything past the IP header) since intermediate gateways must be able to modify the IP header. The specific algorithm is open for discussion, but as an initial proposal I would suggest running the data portion of the packet through DES in the cipher block chaining mode, padding out the data to a multiple of 8 bytes with zeros if necessary. Then the final 8-byte ciphertext is put into the IP option. The receiver performs the same calculation and compares its result with the field in the IP header. Any modification or spoofing of the contents of the data field without knowledge of the DES key used to generate the authenticator would result in the received and computed authenticators being different, and the receiver would ignore the packet. Any modification or spoofing of the data field (which includes the TCP header, if TCP is in use) would cause the authentication check to fail. The normal duplicate packet detection facilities already in TCP (or other transport protocol) would protect against "playback" attacks (recording and repeating valid traffic). Basically this is a form of "checksum" or "CRC" with an algorithm complex enough to protect against deliberate attack by humans as well as random attacks from nature. Is the floor open for an RFC on this subject? Phil
Mills%udel.edu@LOUIE.UDEL.EDU.UUCP (01/09/87)
Phil, It's even easier than that. Simply encrypt the existing TCP/UDP checksum, which includes the pseudo-header. Don't bother recomputing it. I have a little toy proposal which might be used to distribute keys. If you would like to see a copy, ftp the file nsa.txt from udel2.udel.edu with anonymous/guest. Dave
karn@FLASH.BELLCORE.COM.UUCP (01/10/87)
Just encrypting the existing Internet checksum won't protect against someone monitoring good packets and modifying them in such a way that the checksum is unchanged. This is easy since Internet checksums use a simple linear algorithm; consider that swapping any pair of 16-bit integers within the message leaves the checksum unchanged. Also, since the checksum is only 16 bits, it isn't at all hard to watch the channel and construct a lookup table mapping all 65536 possible checksum values to their encrypted counterparts. The value of the cipher checksum needs to depend in a highly nonlinear and unpredictable (without the key) way on both the values and the positions of bits within the message. It needs an "error extension" property. Cipher block chaining does this. Phil
Mills%udel.edu@LOUIE.UDEL.EDU (01/10/87)
Phil, Yes, you're right; however, my model has rather less weight than yours. It is intended as a hotpatch that can be dropped into the code at a conenient place, not require a lot of computation (I assume it to be done in software) and to done for all UDP and TCP connections for a particular host. A perpetrator surely can take advantage of the weaknesses of the checksum algorithm whether encrypted checksums are used or not. I did not intend the simple function I suggested to fix that - I'd rather fix the checksum algorithm itself. As for the size of the checksum; well, we could always stuff it in an IP option. Every time I get going in this vein I drown in the tradeoffs, then try to remember I only need a lifevest, not a SAR team. Discussion on just how hard is hard with respect not only to your model and mine, but also with respect to distributed protocols such as gateway routing protocols and (heaven help me) network time protocols would be welcome (but not specifics with respect to the ciphers themselves). I would be glad to summarize comments sent to me at mills@huey.udel.edu. Dave