Internet DRAFT - draft-ramaiah-key-rollover

draft-ramaiah-key-rollover







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]