idnits 2.17.1 draft-heffernan-tcp-md5-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 26, 1996) is 10045 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '1') Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Andy Heffernan 3 cisco Systems 4 September 26, 1996 6 TCP MD5 Signature Option 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any Internet 23 Draft. 25 Abstract 27 This memo describes a TCP extension to enhance security for selected 28 TCP applications. It defines a new TCP option for carrying an MD5 29 [1] digest in a TCP segment. This digest acts like a signature for 30 that segment, incorporating information known only to the connection 31 end points. Using this option in the way described in this paper 32 significantly reduces the danger from security attacks on critical 33 TCP applications on the Internet. 35 This document specifies an experimental protocol for use in the 36 Internet. 38 1.0 Introduction 40 The primary motivation for this option is to allow applications using 41 TCP as a transport to protect themselves against the introduction of 42 spoofed segments into the connection stream. Of particular concern 43 are resets. 45 To spoof a connection using the scheme described in this paper, an 46 attacker would not only have to guess sequence numbers, but would 47 also have had to obtain the password included in the MD5 digest. 48 This password never appears in the connection stream, and the actual 49 form of the password is up to the application. It could even change 50 during the lifetime of a particular connection so long as this change 51 was synchronized on both ends (although retransmission can become 52 problematical in some TCP implementations with changing passwords). 54 Finally, there is no negotiation for the use of this option in a 55 connection, rather it is purely a matter of site and/or application 56 policy whether or not its connections use the option. 58 2.0 Proposal 60 Every segment sent on a connection to be protected against spoofing 61 will contain the 16-byte MD5 digest produced by applying the MD5 62 algorithm to the following items: 64 -- the TCP pseudo-header 65 -- the TCP header, excluding options, and assuming a checksum of zero 66 -- the TCP segment data (if any) 67 -- an independently-specified key or password, known to both TCPs 68 and presumably connection-specific 70 The header and pseudo-header are in network byte order. The nature 71 of the key is deliberately left unspecified, but it must be known by 72 both ends of the connection. A particular TCP implementation will 73 determine what the application may specify as the key. 75 Upon receiving a signed segment, the receiver must validate it by 76 calculating its own digest from the same data (using its own key) and 77 comparing the two digest. A failing comparison must result in the 78 segment being dropped and must not produce any response back to the 79 sender. Logging the failure is probably advisable. 81 Unlike other proposed TCP extensions, the absence of the option in 82 the SYN,ACK segment must not cause the sender to disable its sending 83 of signatures. This negotiation is typically done to prevent some 84 TCP implementations from misbehaving upon receiving options in non- 85 SYN segments. This is not a problem, since the SYN,ACK will not be 86 signed and will thus be ignored. The connection will never be made, 87 and non-SYN segments with options will never be sent. More 88 importantly, the sending of signatures must be under the complete 89 control of the application, not at the mercy of the remote host not 90 understanding the option. 92 3.0 Syntax 94 The proposed option has the following format: 96 +---------+---------+-------------------+ 97 | Kind=19 |Length=18| MD5 digest... | 98 +---------+---------+-------------------+ 99 | | 100 +---------------------------------------+ 101 | | 102 +---------------------------------------+ 103 | | 104 +-------------------+-------------------+ 105 | | 106 +-------------------+ 108 The MD5 digest is always 16 bytes in length, and the option would 109 appear in every segment of a connection. 111 4.0 Some Implications 113 4.1 Connectionless Resets 115 Connectionless resets will be ignored by the receiver of the resets, 116 since the originator of the resets does not know the key, and so 117 cannot generate the proper signatures for the segments. This means, 118 for example, that connection attempts by a TCP which is generating 119 signatures to a port with no listener will time out instead of being 120 refused. Similarly, resets generated by a TCP in response to 121 segments sent on a stale connection will also be ignored. 123 4.2 Performance 125 The performance hit in calculating digests may inhibit the use of 126 this option. Some measurements of a sample implementation showed 127 that on a 25 MHz 68040, generating a signature for simple ACK segment 128 took an average of 0.1448 ms, while generating a signature for a data 129 segment carrying 4096 bytes of data took 4.688 ms on average. These 130 times would be applied to both the input and output paths, with the 131 input path also bearing the cost of a 16-byte compare. 133 4.3 TCP Header Size 135 As with other options that are added to every segment, the size of 136 the MD5 option must be factored into the MSS offered to the other 137 side during connection negotiation. Specifically, the size of the 138 header to subtract from the MTU (whether it is the MTU of the 139 outgoing interface or IP's minimal MTU of 576 bytes) is now at least 140 18 bytes larger. 142 The total header size is also an issue. The TCP header specifies 143 where segment data starts with a 4-bit field which gives the total 144 size of the header (including options) in 32-byte words. This means 145 that the total size of the header plus option must be less than or 146 equal to 60 bytes -- this leaves 40 bytes for options. 148 As a concrete example, 4.4BSD defaults to sending window-scaling and 149 timestamp information for connections it initiates. The most loaded 150 segment will be the initial SYN packet to start the connection. With 151 MD5 signatures, the SYN packet will contain the following: 153 -- 4 bytes MSS option 154 -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD) 155 -- 12 bytes for timestamp (4.4BSD pads the option as recommended 156 in RFC 1323 Appendix A) 157 -- 18 bytes for MD5 digest 158 -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary. 160 This sums to 40 bytes, which just makes it. 162 5.0 References 164 [1] Rivest, R, "The MD5 Message-Digest Algorithm," RFC 1321, MIT 165 Laboratory for Computer Science, April 1992. 167 Author's Address 169 Andy Heffernan 170 cisco Systems 171 170 West Tasman Drive 172 San Jose, CA 95134 USA 174 Phone: +1 408 526 8115 175 Email: ahh@cisco.com