Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!FLASH.BELLCORE.COM!karn
From: karn@FLASH.BELLCORE.COM (Phil R. Karn)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Authentication (was: No more NFS flames)
Message-ID: <8701090516.AA00786@flash.bellcore.com>
Date: Fri, 9-Jan-87 00:16:58 EST
Article-I.D.: flash.8701090516.AA00786
Posted: Fri Jan  9 00:16:58 1987
Date-Received: Fri, 9-Jan-87 04:47:47 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 32
Approved: tcp-ip@sri-nic.arpa

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