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]
