⟦a89efb02f⟧

TextFile

COMMENTS SHOULD BE SENT TO: jis@athena.mit.edu


*DRAFT*			        Page 1		       *DRAFT* 08/18/89
						    Jeffrey I. Schiller
				  Massachusetts Institute of Technology

	       The Authentication of Internet Datagrams

			 Jeffrey I. Schiller

			 STATUS OF THIS MEMO

To Be Supplied

			      Motivation

	The Internet has grown from an experimental system in the late
'70s and early '80s to the production system that it is today. Early in
the development of the Internet System some basic assumptions were made
about the authenticatability of datagrams sent over the network.
Specifically when the network consisted of just the ArpaNet, the
Interface Message Processor (IMP) (now called a Packet Switched Node or
PSN) hardware could be relied upon to verify the identity of the origin
of the datagram.

	However the advent of a truly internetworked system of routers
and networks has rendered such simplistics methods obsolete. A datagram
originating from a router will be marked not with the Internet source
address of the router, but of the original sender. A router can only
vouch for the authenticity of a datagram if it was able to verify its
origin when it received it. If every router were to verify the
authenticity of a datagram as it traveled from source to destination,
then datagram authenticity could be determined. However this would
require that a destination host have implicit trust in all of the
routers that could deliver datagrams to it. Needless to say with the
network as large as it is today, this trust may well be misplaced.

	This draft RFC will propose the creation of a new Internet option.
This option will allow two communicating Internet entities to verify
the authenticity of a datagram traveling from one to the other. A
proposed protocol will be discussed for the use of this option.

				Scope

	This draft RFC describes a protocol and IP option to allow two
communicating internet hosts to authenticate datagrams that travel from
one to the other. This authentication is limited to source, destination
IP address pair. It is up to host based mechanisms to provide
authentication between separate processes running on the same IP host.
The protocol will provide for "authentication" of the datagram, not
concealment from third party observers. By authentication I mean that
an IP host receiving a datagram claiming to be from some other IP host
will be able (if both hosts are setup to authenticate datagrams between
each other) to determine if in fact the datagram is from the host
claimed, and that it has not been altered in transit.
\f


*DRAFT*			        Page 2		       *DRAFT* 08/18/89
						    Jeffrey I. Schiller
				  Massachusetts Institute of Technology

	This protocol is targeted primarily for those protocols that
are used to manage and control the Internet. Example are EGP [???], the
OSPFIGP [???], and SNMP (FootNote 1). As such it is limited in scope.
It is worth noting that only the basic IP header and data contents of a
datagram are protected by this protocol. IP options are not protected.

	Authentication is one of those problems for which there is no
single solution. Therefore this RFC does not represent itself as the
only solution to every authentication problem. Instead it is intended
for network control and management. Even within the scope of the
proposed protocol, flexibility is provided to accommodate different
requirements.  However in order for two hosts to use this protocol, a
common agreement must exist on those options which are flexible. For
example where encryption is called for, a commonly agreed upon
algorithm must be negotiated (not to mention keys!).

		     Definition of new IP option.

	In order to operate, this protocol needs to provide to the
recipient of a datagram a Cryptographic Checksum of the contents of the
datagram. In order to avoid making modifications to existing Internet
control protocols, this checksum is provided and carried via a new IP
option. In this document the cryptographic checksum is referred to as a
Network Authentication Code (NAC). The NAC is embedded within a new IP
option (the IPNAC option). The encoding is as follows:

      IP Option number: 8 bits

This is the IP Option number of the IPNAC option (To Be Assigned)

      IP Option Length: 8 bits

This is the IP option length of the IPNAC option

      IPNAC type: 8 bits

Type of encryption protocol used to compute the IPNAC. Valid values so
far defined:

	0   - DES cryptographic checksum as defined in FIPS ??.
	1   - RSA Security use [exact method to be defined].
        2   - Diffie-Hellman Public Key Method
	255 - Private, for use when the exact algorithm is private
              and/or confidential.

      NAC: length varies according to IPNAC type.

	+----------+----------+----------+----------
	|IP Option |IP Option | IPNAC    |  NAC     ......
	|   NAC    | Length   | type     |
        +----------+----------+----------+----------
\f


*DRAFT*			        Page 3		       *DRAFT* 08/18/89
						    Jeffrey I. Schiller
				  Massachusetts Institute of Technology

			  Protocol Overview

	The NAC generation and confirmation protocol is based on a
cryptographic checksum generated over a given datagram using a
previously determined shared session key. The session key to use for a
given datagram is a function of the IP source and IP destination
address of the datagram. A procedure is used to fetch this key given
the IP source and destination addresses. Once the session key is
obtained a cryptographic checksum is generated over the IP packet using
the encryption algorithm determined by the IPNAC type. Both sender and
recipient must agree ahead of time on what this algorithm is.

	Not all fields of the IP datagram are checksummed.
Specifically only the IP source, IP destination, IP length and IP
protocol type are included in the checksum along with the entire
protocol specific portion of the packet. This design allows routers to
make the necessary changes in the IP header of a datagram it is
forwarding without jeopardizing the NAC value (including datagram
fragmentation).  In fact routers play no role in the generation or
checking of NAC values. All that is required of routers is that they
pass the option on as they forward a datagram.

			   Protocol Details

	It is intended that the generation and checking of NAC codes
would be done within a host by a common set of software routines. the
NAC module would sit between the IP layer within software and the
protocol specific layer. In practical applications it will probably be
implemented by the protocol specific software, however changes
necessary in order to add this software should only be needed at the
places where packets are accepted from the IP layer and where packets
are handed over to the IP layer.

	The NAC generation software may fail to yield a NAC code. This
would occur when no shared session key has been established (or a key
distribution protocol could not establish one) to enable the use of a
NAC. It is up to protocol designers AND host software administrators as
to what action should be taken when this occurs. Ie. to continue in an
unauthenticated mode or to abort the protocol.

	The NAC confirmation (checking) software may fail to verify a
NAC code. This may be either because there was no IPNAC option present
in a datagram or because the NAC code itself failed to correspond to
the datagram contents. It is up to host software to determine what
actions should be taken when these situations arise.
\f


*DRAFT*			        Page 4		       *DRAFT* 08/18/89
						    Jeffrey I. Schiller
				  Massachusetts Institute of Technology

	Two functions necessary for computation of a NAC are not
specified by this RFC. They are the "fetch_session_key" function and
the "cryptographic_checksum" function. These functions are instead
defined in terms of their input/output parameters. For IPNAC-type of 0
the cryptographic_checksum function is as defined by FIPS ??. The
fetch_session_key function is implementation specific, it is within
this function that issues of key distribution come up.

	The security and integrity of all computed NACs between a host
pair depend on the shared session key used by those hosts being kept
secure. (Footnote about how this applies to public key systems).

		     Input/Output characteristics

fetch_session_key - Input: 1 IP Source address of datagram
                           2 IP Destination of datagram
                    Output: Session Key

cryptographic_checksum - Input: 1 Pointer to data area.
                                2 Length of data area.
                                3 Session Key
			 Output: NAC code

	Lets define two IP addresses (representing two IP hosts) A and
B. Let K(ab) be the session key obtained by calling fetch_session_key
(A, B).  To compute the NAC code the following is done:

	Fetch K(ab) by calling fetch_session_key(A,B). If no key is
available then abort (ie. unable to authenticate this transaction).

	Take the IP datagram contents (ie. the non IP header portion)
and prepend to it an IP psuedo header consisting of:

      IP Source Address
      IP Destination Address
      IP Length
      IP Protocol type
      Padding

        +--------+--------+--------+--------+
        |        IP Source Address          |
        +--------+--------+--------+--------+
        |      IP Destination Address       |
        +--------+--------+--------+--------+
        |    IP Length    |IP type | Padding|
        +--------+--------+--------+--------+

	Use this constructed "pseudo" packet as input to the
cryptographic_checksum procedure along with the appropriate length
This length should be IP Length - IP Header Length + 12.
\f


*DRAFT*			        Page 5		       *DRAFT* 08/18/89
						    Jeffrey I. Schiller
				  Massachusetts Institute of Technology

	The cryptographic_checksum procedure should then yield the
necessary NAC code. This code is then inserted in the IP packet as the
data contents of the IPNAC option.

	Upon receipt of a datagram with an IPNAC option where A,B
represent the source IP address and destination IP address
respectively, remove the NAC from the the IPNAC option. Construct the
IP pseudo header for the packet as described above. fetch_session_key
for K(A,B). If none found then the NAC cannot be verified. The
receiving host software must then treat the datagram as
unauthenticated. Given the IP pseudo header, IP data contents and
K(A,B) call cryptographic_checksum. The resulting NAC code should
match that supplied in the IPNAC option. If the NAC codes do not
match, the datagram may have been tampered with or is outright forged
(or the key management system has failed to provide A and B with the
same K(A,B)).

			   End Of Document
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦a89efb02f⟧ TextFile

Derivation

TextFile
