Transport Area Working Group K. Sood Internet Draft Corrent Corp. File: draft-sood-tcp-config-sign-option-00.txt Expires: July 2004 January 2004 TCP Configurable Signature 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 signature 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 Configurable Signature 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 signature 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 - July 2004 [Page 1] TCP Configurable Signature Option January 2004 Table of Contents 1. Introduction...................................................2 2. TCP Configurable Signature Option Specification................3 2.1 Processing.................................................3 2.2 Input Data Items for Digest Creation.......................3 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 4. Performance....................................................6 5. Security Considerations........................................7 6. References.....................................................7 6.1 Normative References.......................................7 6.2 Informative References.....................................8 7. Acknowledgements...............................................8 8. AuthorÆs Address...............................................8 9. Intellectual Property Statement................................8 10. Full Copyright Notice.........................................9 1. Introduction TCP is a transport protocol [RFC-0793], widely deployed and used in current networks. MD5 is a digest algorithm used in signature-based 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 identity of the peer. RFC 2385 discusses a current practice used for securing BGP against spoofed TCP segments, especially the TCP resets. This current practice requires an attacker to guess the sequence number and the password. This password is used in computing the MD5 digest for each TCP segment. This proposal is an attempt to formalize this mechanism, and enable it to be used by all TCP applications, if they choose to. In addition, various weaknesses in MD5 [Dobb-96] have been identified. Therefore, the selection of MD5 as the digest algorithm is not only limiting the applications, and is also less secure than, say SHA1 [FIPS-180-1] and HMAC [RFC-2104]. Sood Expires - July 2004 [Page 2] TCP Configurable Signature Option January 2004 This document describes how to add an option to the TCP header, called the Configurable Signature option, which allows a configurable digest to be applied to TCP connections. RFC-2385 prescribes the use of MD5 for BGP peers. This document maintains the same set of steps that are described in RFC-2385 for the creation of the digest. 2. TCP Configurable Signature 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 of the digest (Bytes) 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 signatures, when using this option. In other words, this option should be used by a sending application, as per the applications requirement for being 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 Signature option, and the receiver must verify the signature. This option includes the computation of the digest value by the sender, using the senderÆs shared key for that connection. The steps required for creation of this digest are described in Section 2.2. The receiver of every TCP segment must re-compute the value of the digest for every segment received. Receiver follows the same steps as the sender, and uses the receiverÆs shared key for this connection, for digest computation. The receiver then validates the received digest value contained in the option, with the computed digest value. TCP segments are accepted for additional processing after the digest values have been compared to be the same. Any TCP connection initiated with a signed SYN segment dictates that all following segments in the connection (including SYN/ACK, Data), must also be signed. Receiver discards TCP segments for which the digests do not match. No further processing is done for those segments. The receiver also discards unsigned segments for this connection. 2.2 Input Data Items for Digest Creation Sood Expires - July 2004 [Page 3] TCP Configurable Signature Option January 2004 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 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 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 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 | +---------+---------+-------------------+ | Digest...(possibly, truncated/padded) | +---------------------------------------+ | | +---------------------------------------+ | | +-------------------+-------------------+ | | +-------------------+ The fields are defined below: 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 the digest (in Bytes) included in this option. This must be less than or equal to 16. Sood Expires - July 2004 [Page 4] TCP Configurable Signature Option January 2004 Digest 16 Octets: Computed 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 the size of this option must also be considered in the impacts on the TCP headers. The Configurable Signature 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 MTU of the interface should now subtract an additional 20 Bytes for effective MTU calculation. Larger TCP headers lead to a lower effective throughput, which can have differing impacts, based on the packet sizes of the application. Applications must appropriately determine the impacts of these larger header sizes on their traffic patterns. Sood Expires - July 2004 [Page 5] TCP Configurable Signature Option January 2004 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, and also discussed in RFC 2385: . 4 Bytes of MSS option . 4 Bytes window scale option . 12 Bytes for time-stamp [RFC-1323] . 20 Bytes for Configurable Signature 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 TCP header. 3.2 TCP Connectionless Resets As discussed in RFC-2385, the receiver of the reset will ignore connectionless resets, since the sender of the reset does not know the shared secret key between communicating TCP peers. The intruding peer sending these connectionless resets will either generate incorrect signatures 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. This will also be true for cases when the usual TCP resets are not generated in response to stale connections or for connection attempts to a peer without a listener on that TCP port. 4. Performance Local computation of the digest and comparing it with the 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 signature generation is generally faster than the corresponding SHA1-1 signature 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: Sood Expires - July 2004 [Page 6] TCP Configurable Signature Option January 2004 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. The receiver will also bear the additional cost of performing the compare operation. 5. Security Considerations This document defines a digest based security mechanism for TCP peers, based on a pre-shared common secret between the peers. The proposal is designed to use one of the defined digest algorithms, and as such, is as secure as the underlying security considerations 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 communicated between the TCP connection peers is beyond the scope of this document. This proposal also prescribes truncation of the calculated digest value to accommodate in the available options field space. Different 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. Sood Expires - July 2004 [Page 7] TCP Configurable Signature Option January 2004 [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. 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. 7. Acknowledgements I would like to thank Raman Sud, Veeneshwar LLC for his comments and 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 - July 2004 [Page 8] TCP Configurable Signature Option January 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 - July 2004 [Page 9]