Network Working Group A. Ramaiah Internet-Draft S. Mynam Expires: May 27, 2006 C. Appanna Cisco Systems November 23, 2005 Key rollover schemes for TCP connections employing a shared key model. draft-ramaiah-key-rollover-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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." 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 May 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes mechanisms to achieve Key rollover for TCP connections that are using the TCP MD5 digest as described in RFC 2385. The mechanisms presented here do not require TCP protocol changes. The mechanisms are not just limited to TCP MD5 digest Key rollover but can be used for any shared Key based TCP security option. Ramaiah, et al. Expires May 27, 2006 [Page 1] Internet-Draft Key Rollover November 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Active-Passive Key Rollover. . . . . . . . . . . . . . . . . . 5 4. Volume based Key Rollover or TCP Sequence Number based Key Rollover. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Time Based Key Rollover or Key Rollover using the TCP Timestamp option . . . . . . . . . . . . . . . . . . . . . . . 8 6. Key Rollover using Signaling . . . . . . . . . . . . . . . . . 10 7. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 11 8. Application Considerations . . . . . . . . . . . . . . . . . . 12 8.1. Examples of Key Rollover Configuration . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Ramaiah, et al. Expires May 27, 2006 [Page 2] Internet-Draft Key Rollover November 2005 1. Introduction RFC 2385 [RFC2385] specifies a scheme for protecting BGP [RFC1771] sessions using the keyed TCP [RFC0793] MD5 [RFC1321] signature option . Both the ends of the TCP connection need to be configured with the same key (password). The key is used to construct and verify the MD5 hash which is sent as part of the TCP MD5 option. Many applications that use the TCP MD5 option like BGP and LDP, have very long lived TCP connections. Therefore the applications would prefer that the keys be changed multiple times during the lifetime of the connection in order to avoid MD5 collision vulnerability and other security issues. This document describes multiple mechanisms for MD5 Key Rollover without disruption the BGP session (and the underlying TCP connection). First a mechanism is presented that can be used for scenarios wherein the one end of the connection is ready to accept a key change but the actual key change is initiated by the other end of the connection whenever it is ready. Second, a volume based key rollover mechanism is presented that can change keys based on the amount of data exchanged in a connection. Third, a mechanism is presented that can change keys based on time elapsed since the last key change. Finally, a mechanism based on explicit signaling of key change is presented. All the mechanisms described in the document do not require any change to the TCP protocol. Ramaiah, et al. Expires May 27, 2006 [Page 3] Internet-Draft Key Rollover November 2005 2. Terminology 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 [3]. Ramaiah, et al. Expires May 27, 2006 [Page 4] Internet-Draft Key Rollover November 2005 3. Active-Passive Key Rollover. The mechanism is motivated by scenarios where one end is ready for a Key change but 'passively' waits for the other end to 'actively' trigger the actual Key change. The 'passive' end of the key change will get ready to accept a new key but not change to the new key until the 'active' end initiates the key change. The 'passive' end will continue to verify the digest on incoming TCP segments with the old key until such time. If an incoming TCP segment digest does not verify with the old key, then the 'passive' end will attempt to verify the digest with the new key. If it verifies with the new key, that will indicate that the 'active' end has switched to the new key and from then on the 'passive' end will verify all subsequent (post TCP sequence number of the first TCP segment that verifies with the new key) TCP segments with the new key only. In addition the 'passive' end will also send all subsequent outgoing TCP segments with digests based on the new key. This mechanism is particularly useful in Service Provider environments where each provider-edge router is servicing multiple customer-edge routers which are controlled by a different organization. In other words it is possible and usually the case that the configuration change on the customer-edge routers will happen sometime later than when the provider-edge router is configured for the key change. To illustrate with an example, assume that Router-Passive is a provider-edge router. Router-passive will be configured to accept a key change for all the relevant TCP connection end points on it. Let us assume that it wants to change key to Key-New anytime after Monday 11:00 am for all the connections that it has to its customer-edge routers. The Router-Passive end of each relevant TCP connection will be configured to accept rollover from a time starting at Monday 11:00 AM (or a few hours earlier based on skew required to accommodate differences in time between the two ends - more details will follow in a later section). Router-active will change its key to Key-New sometime after Monday 11:00 am. From that point on it will send the subsequent outgoing TCP segments with new MD5 key instead of the old MD5 key. When the Router-Passive receives the first of those TCP segments that decode with Key-New it also switches over to decoding all further TCP segments with Key-New. Also to be pointed out here is that while in the Passive mode, Router-Passive must attempt to authenticate the incoming TCP segment first with the old MD5 key and if that does not match then with the new MD5 key. Further regarding the issue of accommodating clock skews, it can be Ramaiah, et al. Expires May 27, 2006 [Page 5] Internet-Draft Key Rollover November 2005 accomplished multiple ways. Either a window of time can be configured to provide a window of opportunity such that only during that the key can be changed. Such a window for the illustration above could be between Monday 6:00 AM and Tuesday 6:00 AM. Any customer-edge router that does not change its key within this duration will simply lose the connection and that could very well be the desired policy. Or one can support skew by explicitly specifying a 'skew' parameter while configuring the time of change. For the illustration above, it would be something like Monday 11:00 AM with a skew allowance of -5 hours and +18 hours. The Active-Passive mechanism only requires only the 'passive' end to have additional support for key change. The 'active' end only needs the ability to configure a new key on an existing TCP connection. Ramaiah, et al. Expires May 27, 2006 [Page 6] Internet-Draft Key Rollover November 2005 4. Volume based Key Rollover or TCP Sequence Number based Key Rollover. This mechanism provides a very simple and robust solution to do key rollovers based on the amount of data exchanged on a TCP connection. The TCP Sequence Number is used as a measure of amount of data exchanged in units of bytes. The two ends of the TCP connection both change keys at the same time based on a pre-configured data exchange amount in bytes. This method can be used independently in either direction of data flow in a single TCP connection for separate keys and key changes. For illustration consider the case where each end is configured to rollover to the new password after N bytes of data are exchanged in either direction. Let us assume the TCP sequence number for a direction of data flow when the connection is setup is X-Seq (which would be the ISN). Adding N to X-Seq and will provide a Y-Seq. It should be noted here that the Y-Seq calculation will also have to consider the TCP sequence space wrap-around. All TCP segments that are sent at one end, and received at the other end, with sequence numbers greater than Y-Seq will use the next key in the key rollover chain. These procedures have to be implemented for both data-flow directions of a TCP connection. Even when only one key is used for a TCP connection for both data flow directions, the key change procedure will still happen independently in each direction as per rules described. The operation section will provide an example the uses this method for implementing a key chain with regular key rollover. Ramaiah, et al. Expires May 27, 2006 [Page 7] Internet-Draft Key Rollover November 2005 5. Time Based Key Rollover or Key Rollover using the TCP Timestamp option A Time based Key Rollover scheme allows the two application endpoints associated with a TCP connection to change MD5 Keys based on calendar time or based on time elapsed since last Key change. The TCP timestamp option [RFC1323] is used to indicate the elapsed time to each end. It is also a very simple scheme like the previously described TCP Sequence number based rollover scheme. This scheme is based on a simple agreement between the two sides about the time-unit associated with the timestamp value in the TCP Timestamp option. The recommendation is that the unit be in milliseconds but will work with any other unit as well. For the rest of the description of this scheme, milliseconds is assumed to be the unit. It is also assumed that each TCP end point has a clock that can track elapsed time and that the value in an instance of the TCP timestamp option represents the time in ms since the value in the last instance on the TCP timestamp option originated by it. In other words, the timestamp value tracks a relative clock in milliseconds. Clock skews are permitted and there is no requirement to synchronize the clocks at the two endpoints. The agreement between the two endpoints can happen via a mechanism such as a capability negotiation between the two endpoints. After a TCP connection is established the application end-points can exchange a capability that advertises a Time based Key Rollover scheme based on ms units in the TCP timestamp option. This is described in greater detail in the 'Application Considerations' section later in the document. Both sides keep track of time elapsed at the other end by tracking the values being advertised in the TCP timestamp option. The TCP timestamp option should be sent at least once every x seconds (for the agreed unit of ms). When a TCP segment is received with a TCP timestamp value that shows that the required time has elapsed at the sending end, the receiving end should use the next key to authenticate all TCP segments received with a sequence number greater than that for this received segment. Again, this mechanism can be applied to either direction of traffic flow in a connection to have unique keys in each direction. Even when only one key is used for a TCP connection for both data flow directions, the key change procedure will still happen independently in each direction as per rules described. Just like in the TCP Sequence number base mechanism, wrap-arounds should be handled. In this case the wrap-around is of the value in the TCP Timestamp option. Each end should send multiple TCP Ramaiah, et al. Expires May 27, 2006 [Page 8] Internet-Draft Key Rollover November 2005 timestamp options within the duration of a wrap-around. The minimum requirement is that it must send at least one TCP timestamp option before every wrap-around. Ramaiah, et al. Expires May 27, 2006 [Page 9] Internet-Draft Key Rollover November 2005 6. Key Rollover using Signaling This scheme utilizes explicit signaling to accomplish a key change initiated by one end of a TCP connection. The other end of the connection will change the key for all subsequent segments on receiving the signal. The initiating end will change the key once the segment associated with the signal has been acknowledged by the other end. This means once the key validity timer expires on an end- point, it signals the other end using in the next outgoing TCP segment. Once the other ends gets this it should start using the new Key to authenticate subsequent incoming TCP segments. The signal can be implemented in multiple ways but this proposal describes one that reuses an existing TCP protocol property. The URG bit in the TCP segment header is the proposed signaling mechanism here. The key change initiator will send a TCP segment with the URG bit set and the URGENT pointer set to '0' bytes. This will mark the other end to rollover to the next key in the key chain. All subsequent packets are sent using the new key. On receiving the signal, the other end of the TCP connection should switch to the new key to verify all subsequent TCP segments. In the event that the TCP segment with the URG bit set is delayed or lost, out-of-order segments will not verify with the old key but that will recover as soon as the TCP segment with the URG bit gets through. An alternate implementation is discussed later, but this one has the advantage that all incoming TCP segments are always verified against one key only. The same procedures are applied for either direction of data flow - the control with this model lies with the originator of a data flow in either direction. For the just one key for a TCP connection for both sides, each side will follow the same rules and change over to the next key. While the reuse of the URG bit in this manner seems unconventional, note that we are not violating the TCP RFC since it clearly states that the interpretation of the URG bit is left entirely to the application. Also, from an implementation perspective there are two choices for the initiator after it has sent out a TCP segment signaling a key change. Until it gets an acknowledgement for that TCP segment it can choose to send further TCP segments with digests generated with the old key. Similarly, the stack at the other end also can choose to attempt to verify digests using both the old key and the new key after receiving the signal. As soon as it receives a TCP segment that verifies with the new key, it must verify all subsequent segments with the new key only. Ramaiah, et al. Expires May 27, 2006 [Page 10] Internet-Draft Key Rollover November 2005 7. Asymmetric Keys It is generally assumed that for a TCP connection there is a single key (password). However there have been suggestions that there should be one key in each direction of data flow in a TCP connection. All of the schemes except the Active-Passive method work well with this requirement and each section does describe how this would work. In the case of the Active-Passive method this requirement can also be met by having the originator of the data flow for a direction be the Active for that direction and the side be the Passive for the same direction. Again it is worth pointing out here that the current TCP MD5 option already allows a key for each data flow direction. It is not widely used with different keys but as far as the protocol is concerned there is no difference if the key is same or not in either direction. The fact that most applications like BGP are used with the same key configured at both ends is just an implementation choice. Ramaiah, et al. Expires May 27, 2006 [Page 11] Internet-Draft Key Rollover November 2005 8. Application Considerations Applications like BGP can implement a new BGP Capability that will allow 2 BGP speakers to negotiate which key rollover mechanism they would like to use over a TCP connection between them. All TCP connections will start out with a pre-configured key and once the BGP negotiation is complete, they will choose whatever method is agreed to for subsequent key changes. LDP can also handle this negotiation similarly. More details about the BGP Capability will follow. LDP can also follow a similar LDP Capability model. 8.1. Examples of Key Rollover Configuration In this section we present an example that automates the key rollover process. A key rollover matrix (table) is configured at either end of the TCP connection which describes when and on the basis of what, keys should be rolled over. This is illustrated below for the volume based key rollover method. One end of the TCP connection would configure : ------------------------------------------- | Key | Volume (bytes) | Data Flow | ---------- ---------------- --------------- | Key1 | 100000 | Egress | --------- ---------------- --------------- | Key2 | 50000 | Ingress | ------------------------------------------- | Key3 | 200000 | Egress | --------- ---------------- --------------- | Key4 | 60000 | Ingress | ------------------------------------------- | Key5 | 60000 | Ingress/Egress| ------------------------------------------- In the matrix above, keys are configured for each direction of data flow. Key1 will be used for the first 100000 bytes of data originated by this end. At this point a key rollover will happen to Key3 which is the egress key. The ingress Keys are used to verify incoming TCP segments and so for the first 50000 bytes of data, Key1 will be used. After that the verification key will be rolled over to Key4. The last row in the table illustrates that after 60000 bytes of data since the last key change, the key is rolled over to Key5 in both data flow directions, i.e. each data flow originator will switch to the same key. Other end of the TCP connection would configure : Ramaiah, et al. Expires May 27, 2006 [Page 12] Internet-Draft Key Rollover November 2005 ------------------------------------------- | Key | Volume (bytes) | Data Flow | ---------- ---------------- --------------- | Key1 | 100000 | Ingress | --------- ---------------- --------------- | Key2 | 50000 | Egress | ------------------------------------------- | Key3 | 200000 | Ingress | --------- ---------------- --------------- | Key4 | 60000 | Egress | ------------------------------------------- | Key5 | 60000 | Ingress/Egress| ------------------------------------------- If a single key model is desired, then the configuration could just use one data flow direction to configure key changes triggers on either end, i.e. key changes based on egress data flow on one end and based on ingress data flow at the other end. The tables for such a configuration is described below. Configuration table at one end : --------------------------------------- | Key | Volume (bytes) | Data Flow | ---------- ---------------- ----------- | Key1 | 100000 | Ingress | --------- ---------------- ----------- | Key2 | 50000 | Egress | --------------------------------------- | Key3 | 200000 | Ingress | --------- ---------------- ----------- | Key4 | 60000 | Egress | --------------------------------------- Configuration table at the other end : --------------------------------------- | Key | Volume (bytes) | Data Flow | ---------- ---------------- ----------- | Key1 | 100000 | Ingress | --------- ---------------- ----------- | Key2 | 50000 | Egress | --------------------------------------- | Key3 | 200000 | Ingress | --------- ---------------- ----------- | Key4 | 60000 | Egress | --------------------------------------- Ramaiah, et al. Expires May 27, 2006 [Page 13] Internet-Draft Key Rollover November 2005 For Time based Key Rollover the key-rollover matrix would replace the 'Volume' column with a 'Time Elapsed' column. Time Elapsed could be in seconds, minutes, hours and days and would be converted into milliseconds underneath. Configuration table at one end : --------------------------------------- | Key | Time Elapsed | Data Flow | ---------- ---------------- ----------- | Key1 | 1 Week | Ingress | --------- ---------------- ----------- | Key2 | 2 Weeks | Egress | --------------------------------------- | Key3 | 1 Week | Ingress | --------- ---------------- ----------- | Key4 | 2 Weeks | Egress | --------------------------------------- Configuration table at the other end : --------------------------------------- | Key | Time Elapsed | Data Flow | ---------- ---------------- ----------- | Key1 | 1 Week | Egress | --------- ---------------- ----------- | Key2 | 2 Weeks | Ingress | --------------------------------------- | Key3 | 1 Week | Egress | --------- ---------------- ----------- | Key4 | 2 Weeks | Ingress | --------------------------------------- The examples above assume that the digest algorithm is MD5. However, these examples will apply to any other such shared key based digest algorithm - if any are added to TCP in the future. Ramaiah, et al. Expires May 27, 2006 [Page 14] Internet-Draft Key Rollover November 2005 9. Acknowledgements Martin Djernaes was a key part of discussions where the time based solution evolved. We would also like to thank Brian Weis and Tanya Shastri for providing feedback on the draft. Ramaiah, et al. Expires May 27, 2006 [Page 15] Internet-Draft Key Rollover November 2005 10. References 10.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 10.2. Informative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2082] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 Authentication", RFC 2082, January 1997. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. Ramaiah, et al. Expires May 27, 2006 [Page 16] Internet-Draft Key Rollover November 2005 Authors' Addresses Anantha Ramaiah Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-525-6486 Email: ananth@cisco.com Satish Mynam Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-525-3599 Email: mynam@cisco.com Chandrashekhar Appanna Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-6198 Email: achandra@cisco.com Ramaiah, et al. Expires May 27, 2006 [Page 17] Internet-Draft Key Rollover November 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ramaiah, et al. Expires May 27, 2006 [Page 18]