INTERNET-DRAFT                                            Andy Heffernan
<draft-heffernan-tcp-md5-02.txt>                           cisco Systems
                                                      September 26, 1996

                        TCP MD5 Signature Option

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any Internet


   This memo describes a TCP extension to enhance security for selected
   TCP applications.  It defines a new TCP option for carrying an MD5
   [1] digest in a TCP segment.  This digest acts like a signature for
   that segment, incorporating information known only to the connection
   end points.  Using this option in the way described in this paper
   significantly reduces the danger from security attacks on critical
   TCP applications on the Internet.

   This document specifies an experimental protocol for use in the

1.0  Introduction

   The primary motivation for this option is to allow applications using
   TCP as a transport to protect themselves against the introduction of
   spoofed segments into the connection stream.  Of particular concern
   are resets.

   To spoof a connection using the scheme described in this paper, an

Heffernan                Expires March 26, 1997                 [Page 1]

INTERNET-DRAFT          TCP MD5 Signature Option      September 26, 1996

   attacker would not only have to guess sequence numbers, but would
   also have had to obtain the password included in the MD5 digest.
   This password never appears in the connection stream, and the actual
   form of the password is up to the application.  It could even change
   during the lifetime of a particular connection so long as this change
   was synchronized on both ends (although retransmission can become
   problematical in some TCP implementations with changing passwords).

   Finally, there is no negotiation for the use of this option in a
   connection, rather it is purely a matter of site and/or application
   policy whether or not its connections use the option.

2.0  Proposal

   Every segment sent on a connection to be protected against spoofing
   will contain the 16-byte MD5 digest produced by applying the MD5
   algorithm to the following items:

       -- the TCP pseudo-header
       -- the TCP header, excluding options, and assuming a checksum of zero
       -- the TCP segment data (if any)
       -- an independently-specified key or password, known to both TCPs
          and presumably connection-specific

   The header and pseudo-header are in network byte order.  The nature
   of the key is deliberately left unspecified, but it must be known by
   both ends of the connection.  A particular TCP implementation will
   determine what the application may specify as the key.

   Upon receiving a signed segment, the receiver must validate it by
   calculating its own digest from the same data (using its own key) and
   comparing the two digest.  A failing comparison must result in the
   segment being dropped and must not produce any response back to the
   sender.  Logging the failure is probably advisable.

   Unlike other proposed TCP extensions, the absence of the option in
   the SYN,ACK segment must not cause the sender to disable its sending
   of signatures.  This negotiation is typically done to prevent some
   TCP implementations from misbehaving upon receiving options in non-
   SYN segments.  This is not a problem, since the SYN,ACK will not be
   signed and will thus be ignored.  The connection will never be made,
   and non-SYN segments with options will never be sent.  More
   importantly, the sending of signatures must be under the complete
   control of the application, not at the mercy of the remote host not
   understanding the option.

Heffernan                Expires March 26, 1997                 [Page 2]

INTERNET-DRAFT          TCP MD5 Signature Option      September 26, 1996

3.0  Syntax

   The proposed option has the following format:

             | Kind=19 |Length=18|   MD5 digest...   |
             |                                       |
             |                                       |
             |                                       |
             |                   |

   The MD5 digest is always 16 bytes in length, and the option would
   appear in every segment of a connection.

4.0  Some Implications

4.1  Connectionless Resets

   Connectionless resets will be ignored by the receiver of the resets,
   since the originator of the resets does not know the key, and so
   cannot generate the proper signatures for the segments.  This means,
   for example, that connection attempts by a TCP which is generating
   signatures to a port with no listener will time out instead of being
   refused.  Similarly, resets generated by a TCP in response to
   segments sent on a stale connection will also be ignored.

4.2 Performance

   The performance hit in calculating digests may inhibit the use of
   this option.  Some measurements of a sample implementation showed
   that on a 25 MHz 68040, generating a signature for simple ACK segment
   took an average of 0.1448 ms, while generating a signature for a data
   segment carrying 4096 bytes of data took 4.688 ms on average.  These
   times would be applied to both the input and output paths, with the
   input path also bearing the cost of a 16-byte compare.

4.3 TCP Header Size

   As with other options that are added to every segment, the size of
   the MD5 option must be factored into the MSS offered to the other
   side during connection negotiation.  Specifically, the size of the

Heffernan                Expires March 26, 1997                 [Page 3]

INTERNET-DRAFT          TCP MD5 Signature Option      September 26, 1996

   header to subtract from the MTU (whether it is the MTU of the
   outgoing interface or IP's minimal MTU of 576 bytes) is now at least
   18 bytes larger.

   The total header size is also an issue.  The TCP header specifies
   where segment data starts with a 4-bit field which gives the total
   size of the header (including options) in 32-byte words.  This means
   that the total size of the header plus option must be less than or
   equal to 60 bytes -- this leaves 40 bytes for options.

   As a concrete example, 4.4BSD defaults to sending window-scaling and
   timestamp information for connections it initiates.  The most loaded
   segment will be the initial SYN packet to start the connection.  With
   MD5 signatures, the SYN packet will contain the following:

       -- 4 bytes MSS option
       -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
       -- 12 bytes for timestamp (4.4BSD pads the option as recommended
          in RFC 1323 Appendix A)
       -- 18 bytes for MD5 digest
       -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.

   This sums to 40 bytes, which just makes it.

5.0  References

   [1] Rivest, R, "The MD5 Message-Digest Algorithm," RFC 1321, MIT
       Laboratory for Computer Science, April 1992.

Author's Address

   Andy Heffernan
   cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134  USA

   Phone:  +1 408 526 8115
   Email:  ahh@cisco.com

Heffernan                Expires March 26, 1997                 [Page 4]