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]