tcpm S. Duan, Ed. Internet-Draft H. Wang Expires: September 3, 2010 Y. Wei ZTE Corporation March 2, 2010 Key Coordination enhancement for TCP-AO draft-duan-tcpm-tcp-ao-rekeying-00.txt Abstract TCP-AO technology was proposed to obsolete the TCP-MD5 option which was developed to protect the BGP sessions between routers. Besides of allowing users to choose which cryptographic algorithm(s) they want to use to meet their security needs, TCP-AO provides key coordination mechanism giving the ability to move from one key to another within the same connection with zero segment loss by using two ID fields i.e. KeyID and RNextKeyID. The sender uses the RNextKeyID to indicate the receiver using the preferred MKT which will authenticate the next incoming segments. However, if the sender finds its MKT which is used to authenticate the outgoing segments has been attacked and should be changed into a new one, it can do nothing but wait for receiver to send a segment which carries a different RNextKeyID. In this case, the communication becomes dangerous probably because the sender always authenticates outgoing segments by an attacked key before the receiver wants to change the incoming key. This document provides a method giving the sender ability to inform the other part change the RNextKeyID when the sender finds the key used in outgoing segment is not safe any longer. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." Duan, et al. Expires September 3, 2010 [Page 1] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 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. This Internet-Draft will expire on September 3, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 BSD License. Duan, et al. Expires September 3, 2010 [Page 2] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Review of the TCP-AO option . . . . . . . . . . . . . . . . . 4 3. The main idea . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Per-Connection TCP-AO Parameters . . . . . . . . . . . . . 7 4.2. Sending TCP Segments . . . . . . . . . . . . . . . . . . . 7 4.3. Receiving TCP Segments . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Duan, et al. Expires September 3, 2010 [Page 3] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 1. Introduction The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates TCP segments, including the TCP IPv4 pseudoheader, TCP header, and TCP data. It was developed to protect BGP sessions from spoofed TCP segments which could affect BGP data or the robustness of the TCP connection itself [RFC2385] [RFC4953]. However, due to the fatal attack on MD5 and the difficulty to changing the long-term key, TCP-AO [tcp-ao] was proposed to obsolete the TCP- MD5 option. In TCP-AO, more strong authentication algorithms are supported and two kinds of ID fields i.e. KeyID and RNextKeyID are explicitly given. The KeyID and RNextKeyID form a simple key coordination mechanism giving the ability to move from one key to another within the same connection with zero segment loss. If one part wants to change the key used to authenticate the incoming segments, it can insert the preferred ID of MKT into the RNextKeyID to notify the receiver. And the receiver could set current key to the RNextKeyID MKT when the RNextKeyID MKT is ready. It works well for changing the incoming key. However, if a sender finds its MKT which is used to authenticate outgoing segments has been attacked and should change into a new one, it can do nothing but has to wait for the receiver sending a segment which carries a different RNextKeyID. In this case, the communication becomes dangerous probably because the sender always authenticates outgoing segment by an attacked key before the receiver changes the incoming key. This paper proposes a method which the sender can trigger the other part to change the RNextKeyID when the sender finds the former outgoing key is not safe any longer. When the sender wants to change the key which is used to authenticate the outgoing segment, it sends outgoing segment with 0Xff in RNextKeyID field. The 0Xff in RNextKeyID field is used to trigger the receiver to use a new key ID in the RNextKeyID. 1.1. Requirements Language 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 [RFC2119]. 2. Review of the TCP-AO option The TCP-AO option is shown in Figure 1. Duan, et al. Expires September 3, 2010 [Page 4] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 +------------+------------+------------+------------+ | Kind | Length | KeyID | RNextKeyID | +------------+------------+------------+------------+ | MAC ... +-----------------------------------... ...-----------------+ ... MAC (con't) | ...-----------------+ Figure 1: The TCP-AO Option The TCP-AO defines the fields as follows: o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- AO uses a new Kind value of TBD-IANA-KIND. An endpoint MUST NOT use TCP-AO for the same connection in which TCP MD5 is used. When both options appear, TCP MUST silently discard the segment. A single TCP segment MUST NOT have more than one TCP-AO option. When multiple TCP-AO options appear, TCP MUST discard the segment. o Length: An unsigned 1-byte field indicating the length of the TCP-AO option in bytes, including the Kind, Length, KeyID, RNextKeyID,and MAC fields. The Length value MUST be consistent with the TCP header length; this is a consistency check and avoids overrun/underrun abuse. When the Length value is invalid, TCP MUST discard the segment. Values of 4 and other small values larger than 4 (e.g., indicating MAC fields of very short length) are of dubious utility but are not specifically prohibited. o KeyID: An unsigned 1-byte field indicating the MKT used to generate the traffic keys which were used to generate the MAC that authenticates this segment. It supports efficient key changes during a connection and/or to help with key coordination during connection establishment. Note that the KeyID has no cryptographic properties - it need not be random, nor are there any reserved values. Duan, et al. Expires September 3, 2010 [Page 5] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 KeyID values MAY be the same in both directions of a connection, but do not have to be and there is no special meaning when they are. o RNextKeyID: An unsigned 1-byte field indicating the MKT that the sender is ready use to receive authenticated segments, i.e., the desired 'receive next' KeyID. It supports efficient key change coordination. Note that the RNextKeyID has no cryptographic properties - it need not be random, nor are there any reserved values. o MAC: Message Authentication Code. Its contents are determined by the particulars of the security association. Typical MACs are 96-128 bits (12-16 bytes), but any length that fits in the header of the segment being authenticated is allowed. Required support for TCP-AO MACs are defined in [ao-crypto]; other MACs MAY be supported. 3. The main idea The problem is that if a sender finds its MKT which is used to authenticate the outgoing segment has been attacked and should change into a new one, it can do nothing but has to wait for the receiver sending a segment which carries a different RNextKeyID. The problem stems from the limitation of the RNextKeyID, that is, the RNextKeyID is only used to notify the receiver to change the key which is used to authenticate the next incoming segments but has no ability to change the sender's key which is used to authenticate its outgoing segments. The main idea of this method is that the sender can trigger receiver to change Rnext_key pointer. RNextKeyID may define 0xff as reserved message which is used for sender to trigger receiver changing Rnext_key. The sender sends a segment where the RNextKeyID field is 0Xff which means that it wants to use a new MKT to authenticate the future outgoing segments. Receiving this segment, the receiver changes its Rnext_key pointer ,sets the RNextKeyID field to the MKT ID which is indicated by the Rnext_key pointer and sends the next segment. 4. Operation Duan, et al. Expires September 3, 2010 [Page 6] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 4.1. Per-Connection TCP-AO Parameters TCP-AO uses a small number of parameters associated with each connection that uses the TCP-AO option, once instantiated. These values can be stored in the Transport Control Block (TCP) [RFC793]. These values are explained in subsequent sections of this document as noted; they include: 1. Current_key - the MKT currently used to authenticate outgoing segments, whose SendID is inserted in outgoing segments as KeyID. Incoming segments are authenticated using the MKT corresponding to the segment and the KeyID in its TCP-AO header, as matched against the MKT TCP connection identifier and the MKT RecvID. There is only one Current_key at any given time on a particular connection. 2. Rnext_key -the MKT currently preferred for incoming (received) segments, whose RecvID is inserted in outgoing segments as RNextKeyID. This parameter is changed only by manual user intervention or MKT management protocol operation. The configuration is as following: 1. If the sender wants to change a new key to authenticate his next incoming segment, then he sets the Rnext_key to a new MKT which he is ready for. 2. If the sender wants to change a new key to authenticate his future outgoing segment, then he sets the Rnext_key to a special reserved message 0Xff. 3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to prevent replay attacks. Each SNE is initialized to zero upon connection establishment. 4. One or more MKTs. These are the MKTs that match this connection's socket pair. 4.2. Sending TCP Segments The following procedure describes the modifications to TCP to support TCP-AO when a segment departs. 1. Find the per-connection parameters for the segment: a. If the segment is a SYN, then this is the first segment of a new connection. Find the matching MKT for this segment based on the segment's socket pair. Duan, et al. Expires September 3, 2010 [Page 7] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 i. If there is no matching MKT, omit the TCP-AO option. Proceed with transmitting the segment. ii. If there is a matching MKT, then set the per-connection parameters as needed. Proceed with the step 2. b. If the segment is not a SYN, then determine whether TCP-AO is being used for the connection and use the MKT as indicated by the Current_key value from the per-connection parameters and proceed with the step 2. 2. Using the per-connection parameters: a. Augment the TCP header with the TCP-AO, inserting the appropriate Length and KeyID based on the MKT indicated by Current_key (using the Current_key MKT's SendID as the TCP-AO KeyID). Update the TCP header length accordingly. b. Determine SND.SNE. c. Determine the appropriate traffic key, i.e., as pointed to by Current_key. I.e., use the send_SYN_traffic_key for SYN segments, and the send_other_traffic_key for other segments. d. Determine the RNextKeyID indicated by the Rnext_key pointer, and insert it in the TCP-AO option (using the Rnext_key MKT's RecvID as the TCP-AO RNextKeyID). e. Compute the MAC using the MKT (and cached traffic key) and data from the segment as specified in Section 7.1. f. Insert the MAC in the TCP-AO MAC field. g. Proceed with transmitting the segment. 4.3. Receiving TCP Segments The following procedure describes the modifications to TCP to support TCP-AO when a segment arrives. 1. Find the per-connection parameters for the segment: Find the matching MKT for this segment, using the segment's socket pair and its TCP-AO KeyID, matched against the MKT's TCP connection identifier and the MKT's RecvID. i. If there is no matching MKT, remove the TCP-AO option from the segment. Proceed with further TCP handling of the Duan, et al. Expires September 3, 2010 [Page 8] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 segment. ii. If there is a matching MKT, then set the per-connection parameters as needed. Proceed with the step 2. 2. Using the per-connection parameters: a. Check that the segment's TCP-AO Length matches the length indicated by the MKT. i. If lengths differ, silently discard the segment. b. Determine the segment's RCV.SNE. c. Determine the segment's traffic key from the MKT. I.e., use the receive_SYN_traffic_key for SYN segments, and receive_other_traffic_key for other segments. d. Compute the segment's MAC using the MKT (and its derived traffic key). i. If the computed MAC differs from the TCP-AO MAC field value, silently discard the segment. e. Compare the received RNextKeyID value to the currently active outgoing KeyID value (Current_key MKT's SendID). i. If they match, no further action is required. ii. If they differ, determine whether the RNextKeyID MKT is ready. If(RNextKeyID is not 0Xff) 1. If the MKT corresponding to the segment's socket pair and RNextKeyID is not available, no action is required (RNextKeyID of a received segment needs to match the MKT's SendID). 2. If the matching MKT corresponding to the segment's socket pair and RNextKeyID is available: a. Set Current_key to the RNextKeyID MKT. If(RNextKeyID is 0Xff) Set the Rnext_key to another new MKT. Duan, et al. Expires September 3, 2010 [Page 9] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 f. Proceed with TCP processing of the segment. 5. Security Considerations This document inherits all of the security considerations of the TCP-AO. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", Aug 1998. [RFC793] Postel, J., "Transmission Control Protocol", sept 1981. [ao-crypto] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for TCP's Authentication Option, TCP-AO", Mar 2010. [tcp-ao] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Jan 2010. 6.2. Informative References [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", Jul 2007. Appendix A. Additional Stuff Authors' Addresses Shili Duan (editor) ZTE Corporation No. 68, Zijinghua Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877648 Email: duan.shili@zte.com.cn Duan, et al. Expires September 3, 2010 [Page 10] Internet-Draft Key Coordination enhancement for TCP-AO March 2010 Hongyan Wang ZTE Corporation No. 68, Zijinghua Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877993 Email: wang.hongyan4@zte.com.cn Yinxing Wei ZTE Corporation No. 68, Zijinghua Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877993 Email: wei.yinxing@zte.com.cn Duan, et al. Expires September 3, 2010 [Page 11]