Transport Area Working Group K. Sood Internet Draft Corrent Corp. File: draft-sood-tcp-config-mac-option-00.txt Expires: August 2004 February 2004 TCP Configurable Message Authentication Code (MAC) Option Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society 2004. All Rights Reserved. Abstract This RFC proposes a generic and configurable message authentication code (MAC) option for TCP. This work extends the practice defined in TCP MD5 Signature Option for BGP sessions [RFC-2385]. This RFC describes a new TCP option that allows any TCP-based application to enhance security in TCP connections. This option is configurable because it allows implementers to choose the digest mechanism of choice for each TCP connection. This digest mechanism constructs a MAC for each TCP segment, using a (preferably) connection specific shared secret key and components from TCP header and data. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC-2119]. Sood Expires - August 2004 [Page 1] TCP Configurable MAC Option February 2004 Table of Contents 1. Introduction...................................................2 2. TCP Configurable MAC Option Specification......................3 2.1 Processing.................................................3 2.2 MAC Creation...............................................4 2.3 Option Syntax..............................................4 2.4 Digest Values..............................................5 3. TCP Implications...............................................5 3.1 TCP Header Size............................................5 3.2 TCP Connectionless Resets..................................6 3.3 Additional TCP Header Options..............................6 4. Performance....................................................7 5. Security Considerations........................................8 6. References.....................................................8 6.1 Normative References.......................................8 6.2 Informative References.....................................9 7. Acknowledgements...............................................9 8. AuthorÆs Address...............................................9 9. Intellectual Property Statement................................9 10. Full Copyright Notice........................................10 1. Introduction TCP is a transport protocol [RFC-0793], widely deployed and used in current networks. MD5 is a digest algorithm used in message authentication mechanisms [RFC-1321]. Additional digest algorithms have since been developed, and are good candidates for complementing MD5. The primary motivation for adding this option is to provide a stronger mechanism into the TCP protocol, which allows for both ends of a TCP connection to verify the authenticity of the TCP segments from itsÆ peer. RFC 2385 discusses a current practice used for securing BGP against spoofed TCP segments, especially the TCP resets. Spoofing TCP segments requires an attacker to guess the sequence number and the shared secret key for that connection. This shared secret key is used in computing the MD5 digest for each TCP segment. The proposal in this document is an attempt to formalize this mechanism, and enable it to be used by all TCP applications, if they choose to. Various weaknesses in MD5 [Dobb-96] have now been identified. RFC 2385 is not only limiting the application to MD5 algorithm, but also prescribing a digest mechanism that is less cryptographically secure than, say SHA1 [FIPS-180-1] and HMAC [RFC- 2104]. Sood Expires - August 2004 [Page 2] TCP Configurable MAC Option February 2004 This document describes how to add an option to the TCP header, called the Configurable Message Authentication Code (MAC) option, which allows a configurable digest to be applied to all segments of TCP connections. This document maintains the same set of steps that are described in RFC-2385 for the creation of the digest. 2. TCP Configurable MAC Option Specification Every TCP segment, which has to be protected against spoofing, will contain a digest in this option. This digest is created using the digest mechanism defined in this document. This option also defines a field for the length (in number of Bytes) of the digest, which is included in this option. The digest can be truncated for insertion into this TCP option. Unlike other TCP options (like Window Scale Option) [RFC-1323], this option is not negotiable between the peers. The sender should be independent of receiverÆs capability to verify and apply digest MACs, when using this option. In other words, this option should be used by a sending application, as per itÆs requirement for having segments authenticated by the receiving peer. 2.1 Processing Every TCP segment sent on the TCP connection, which has to be protected against spoofing, will contain the Configurable MAC Option, and the receiver must verify the MAC. This option includes the computation of the digest MAC value by the sender, using the senderÆs shared secret key for that connection. The steps required for creation of this digest MAC are described in Section 2.2. The receiver of every TCP segment must re-compute the MAC for every segment received. Receiver follows the same steps as the sender in MAC creation, but uses its shared secret key for this connection. The receiver then validates the received MAC digest contained in the option, with the computed MAC digest. TCP segments are accepted for additional processing after the MAC values have been compared to be the same. Any TCP connection initiated with a SYN segment with MAC option applied to it, dictates that all following segments in the connection (including SYN/ACK, Data), must also have the MAC computed for each segment. Receiver discards TCP segments for which the MAC values do not match. The receiver also discards follow-up segments for this connection, which do not have the MAC option. No further processing is done for discarded segments. Sood Expires - August 2004 [Page 3] TCP Configurable MAC Option February 2004 2.2 MAC Creation The sender first selects a digest algorithm to be used in this option. This can be configuration option for each TCP connection, or based on a global policy established at the senderÆs end. A shared secret key, preferably connection specific, must also be established through an out-of-band mechanism. Definition of this mechanism is outside the scope of this document. The following items are applied to the selected digest algorithm, in the order specified below. Note that this is the same order specified in RFC-2385, to minimize changes to current applications, including BGP, that use RFC-2385 proposals. 1. TCP pseudo header in the order: a. Source IP address b. Destination IP address c. Zero-padded protocol number d. Segment Length 2. TCP header, excluding options, and assuming a checksum of zero. 3. TCP segment data, if any 4. An independently specified shared secret key or password, known to both TCP peers and presumably connection specific. The TCP header and pseudo-header are in network byte order. The sending TCP host is in complete control of inserting this option, and independent of the receiving host understanding this option. A mutual implementation of this option will be necessary for the creation of authenticated TCP connections between the peers. 2.3 Option Syntax This option would appear in every segment of a connection, including the SYN, ACK/SYN, and data segments. The proposed option has the following format: +---------+---------+---------+---------+ | Kind=21 |Length=20|Dig Type |Dig Len | +---------+---------+-------------------+ | MAC Digest...(full/truncated/padded) | +---------------------------------------+ | | +---------------------------------------+ | | +-------------------+-------------------+ | | +-------------------+ The fields are defined below: Sood Expires - August 2004 [Page 4] TCP Configurable MAC Option February 2004 Kind 1 Octet: The TCP option; value = 21 decimal Length 1 Octet: Length of the option, as defined in RFC-0793; value = 20 decimal Dig Type 1 Octet: Digest algorithm to be used. Possible values are defined in section 2.4. Dig Length 1 Octet: Length of MAC digest (in Bytes) included in this option. This must be less than or equal to 16. Digest 16 Octets: Computed MAC digest, either complete, Padded or truncated, to fit the 16 octets defined in this option. The digest field must be filled starting first bytes of the computed digest value. Any pad bytes should be 0x00. Example: MD5 digest will be inserted completely, as it is 16 Bytes in length; HMAC-SHA1-96 will have 12 Bytes of digest and rest padded with 0x00; SHA1 digest, which is inherently 20 Bytes, will be truncated to first 16 Bytes. 2.4 Digest Values This section explains the digest values that can be used for filling the ôDig Typeö field in the option header. Dig Type Meaning -------- ------- 0x01 SHA-1 0x02 MD-5 0x03 HMAC-SHA1 0x04 HMAC-MD5 0x05 HMAC-SHA1-96 [RFC-2404] 0x06 HMAC-MD5-96 [RFC-2403] 0x07 DES-MAC 0x08 AES-CCM [RFC-3610] All other values are reserved. 3. TCP Implications 3.1 TCP Header Size Inclusion of TCP options increases the header size, and, therefore, the size of this option must also be considered and impacts understood. The Configurable MAC Option defined in this document specifies a total length of 20 Bytes. Calculation of the Maximum Transmission Unit (MTU) should now consider the additional 20 Bytes of header on every TCP segment. The Sood Expires - August 2004 [Page 5] TCP Configurable MAC Option February 2004 MTU of the interface should now subtract an additional 20 Bytes for effective MTU calculation. Larger TCP headers lead to a lower effective throughput. This decrease in effective throughput is dependent on the packet sizes of the application. Applications must appropriately determine the impacts of these larger header sizes on their traffic patterns. The maximum size of this option has been limited to 20 Bytes to accommodate all other options that have to be carried in a typical SYN packet. Based on TCP specifications [RFC-0793], the maximum size of TCP header is 60 Bytes. A breakup of the sizes used by various options, above the standard 20 Bytes TCP header, is defined below: . 4 Bytes of MSS option . 4 Bytes window scale option . 12 Bytes for time-stamp [RFC-1323] . 20 Bytes for Configurable MAC Option This sums to 40 Bytes. Along with the standard 20 Byte TCP header, the total reaches the maximum allowed TCP header size of 60 Bytes. Please note that, as per RFC-0793, the end-of-option-list padding is not necessary. This is because the total length of all options has reached the end of the maximum TCP header size. 3.2 TCP Connectionless Resets As discussed in RFC-2385, the receiver of the reset will ignore connectionless resets, since the sender of the spoofed reset does not know the shared secret key between communicating TCP peers. The intruding peer sending these connectionless resets will either generate incorrect MAC digests using a bad key, or send the reset without this TCP option. In either case, the resets will be ignored. Therefore, it becomes the responsibility of the TCP peer application (say, BGP) to recover from crashes of its connection peer. Additional cases where the application has to perform recovery include: TCP resets not generated in response to stale connections, and for connection attempts to a peer without a listener on that TCP port. 3.3 Additional TCP Header Options Use of the TCP configurable MAC option will use 20-bytes from the total of 40-bytes available for specifying TCP header options. One of the options that may be impacted is the use of TCP Selective Acknowledgement (SACK) Option [RFC-2018], when the TCP configurable Sood Expires - August 2004 [Page 6] TCP Configurable MAC Option February 2004 MAC option is used. The SACK option requires, at the minimum, 10- bytes to specify at least one non-contiguous block of TCP data received at the receiver. Each additional SACK block requires 8 bytes of TCP header space. Since, SACK options are not used in SYN segments, TCP header space will not be an issue for SYN segments. For TCP data segments that use configurable MAC option, the SACK option cannot be used when TCP Window Scale option and TCP time-stamp options are in use. If window-scale and time-stamp options are excluded in TCP headers, then TCP configurable MAC option and SACK/D-SACK options can co-exist in the same TCP header. The number of SACK/D-SACK blocks will, however, be limited to available TCP header size. Applications and TCP implementation at the sender, which originates the SYN, will determine the trade-offs between using the configurable MAC option, and other TCP options. Of special concern will be the desirability of establishing an authenticated TCP connection, and the advantages of having SACK/D-SACK [RFC-2883], Timestamp, and window- scale options. The choices will depend on network characteristics. 4. Performance Local computation of the MAC digest and comparing it with the MAC digest value in the TCP option header will be a pre-requisite to any further TCP processing. These two additional steps will show their impact on the normal processing rate of TCP implementations. MD5 digest generation is generally faster than the corresponding SHA1-1 digest generation. The HMAC-based algorithms are slower, albeit more secure, than their corresponding base algorithms. A sample of performance numbers (Mbps) as seen on a 730 MHz Pentium- III processor with 256K Cache is as follows: Algorithm\TCP Segment Size (Bytes) 16B 1024B ---------------------------------------------------- MD5 88 600 Mbps SHA-1 75 342 Mbps HMAC-MD5 50 442 Mbps AES-128 119 118 Mbps On this platform, a delay of 2.56 usecs (.00256 msec) is noticed for generation of signature for an ACK, using HMAC-MD5. Generation of a signature for a TCP segment with 1024 Bytes of data took 18.53 usecs (0.01853 msecs), using HMAC-MD5. Similar delays will be experienced both at the receiver and at the sender, depending on the processing speed of their respective platforms. The receiver will also bear the additional cost of performing the 16-Byte compare operation. Sood Expires - August 2004 [Page 7] TCP Configurable MAC Option February 2004 There is also a potential TCP performance and network traffic impact in not using the TCP time-stamp, window-scale, and SACK/D-SACK options, when the TCP configurable MAC option is in use. SACK/D-SACK and configurable MAC options can co-exist, but will limit the number of SACK blocks that are sent in the TCP header. 5. Security Considerations This document defines a MAC digest based message authentication security mechanism for TCP peers, computed using a pre-shared common secret between the peers. The proposal is designed to use only one of the digest algorithms, and as such, is as secure as the underlying cryptographic security of those algorithms. In addition, the shared secret value must be of sufficient length to support each digest algorithmÆs strength. Neither the length nor the selection criteria of this shared secret should downgrade the inherent strength of the algorithm in any manner. The mechanism through which the shared secret is generated and communicated between the TCP connection peers is beyond the scope of this document. This proposal also prescribes truncation of the calculated MAC digest value (like, SHA-1: 20 Bytes) to accommodate into the available options field space (16-Bytes). Various algorithms allow different characteristics when truncated. Therefore, determination of the truncation impact on the algorithm strength must be made prior to using that digest algorithm for authentication. 6. References 6.1 Normative References [RFC-0793] Postel, J., ôTransmission Control Protocolö, RFC 0793, September 1981. [RFC-1231] Rivest, R., ôThe MD-5 Digest Algorithmö, RFC 1321, April 1992. [RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R., ôHMAC: Keyed- Hashing for Message Authenticationö, February 1997. [RFC-2403] Madson, C., and Glenn, R., ôThe Use of HMAC-MD5-96 within ESP and AHö, RFC 2404, November 1998. [RFC-2404] Madson, C., and Glenn, R., ôThe Use of HMAC-SHA-1-96 within ESP and AHö, RFC 2404, November 1998. [RFC-3610] Whiting, D., Housley, R., and Ferguson, N., ôCounter with CBC-MAC (CCM)ö, RFC 3610, September 2003. Sood Expires - August 2004 [Page 8] TCP Configurable MAC Option February 2004 6.2 Informative References [Dobb-96] Dobbertin, H., ôThe Status of MD5 After a Recent Attackö, RSA LabsÆ CryptoBytes, Vol. 2 No. 2, summer 1996. http://www.rsa.com/rsalabs/pubs/cryptobytes.html [RFC-1323] Jacobson, V., Braden, R., and Borman, D., ôTCP Extensions for High Performanceö, RFC 1323, May 1992. [RFC-2026] Bradner, S., ôThe Internet Standards Process û Revision 3ö, RFC 2026, October 1996. [RFC-2119] Bradner, S., ôKey words for use in RFCs to Indicate Requirement Levelsö, RFC 2119, March 1997. [RFC-2385] Heffernan, A., ôProtection of BGP Sessions via the TCP MD5 Signature Optionö, RFC 2385, August 1998. [RFC-2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanov, A., ôTCP Selective Acknowledgement Optionsö, RFC 2018, April 1996. [RFC-2883] Floyd, S., Mahdavi, J., Mathis, M., and Podolsky, M., ôAn Extension to the Selective Acknowledgement (SACK) option for TCPö, RFC 2883, July 2000. 7. Acknowledgements I would like to express my thanks to Raman Sud (Veeneshwar LLC), and Stephen Kent (BBN) for their valuable technical discussions on these issues, and their helpful suggestions on this document. 8. AuthorÆs Address Kapil Sood Corrent Corp. 1711 W. Greentree Drive Ste #201 Tempe AZ 85284 Phone: 480.648.2331 Email: Kapil.sood@corrent.com Notice for Comments: Please direct all comments to the email address specified above: Kapil.sood@corrent.com 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in Sood Expires - August 2004 [Page 9] TCP Configurable MAC Option February 2004 this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Full Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sood Expires - August 2004 [Page 10]