Network Working Group S. Viswanathan Internet-Draft B. Weis Intended status: Informational Cisco Systems Expires: April 12, 2007 R. Bonica Juniper Networks A. Lange Alcatel O. Wheeler BT October 9, 2006 Authentication-Key Rollover mechanism for Routing and Management Protocols draft-viswanathan-keyrollover-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 April 12, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Viswanathan, et al. Expires April 12, 2007 [Page 1] Internet-Draft Key Rollover October 2006 Abstract This memo discusses the authentication for routing and management protocols based on preconfigured keys,the need and basis for key rollover, and an mechanism to seamlessly rollover the authentication keys. It is intended for an application where secure administrative access to all the end-points of the protocol connection is normally available. The strategy described herein improves upon the current practice where a key is preconifigured at all endpoints and the key rollover is done manually within a short synchronized window to avoid connection drops due to key mismatch. Table of Contents 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Key Chain Attributes . . . . . . . . . . . . . . . . . . . . . 7 6. Key rollover criteria . . . . . . . . . . . . . . . . . . . . 9 7. Active Key Selection . . . . . . . . . . . . . . . . . . . . . 10 8. Key Eligibility . . . . . . . . . . . . . . . . . . . . . . . 11 9. Clock Synchronization . . . . . . . . . . . . . . . . . . . . 12 9.1. Overlapping lifetime . . . . . . . . . . . . . . . . . . . 12 9.2. Accept tolerance . . . . . . . . . . . . . . . . . . . . . 12 10. Application Considerations . . . . . . . . . . . . . . . . . . 13 11. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 14 12. Operational Considerations . . . . . . . . . . . . . . . . . . 15 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Viswanathan, et al. Expires April 12, 2007 [Page 2] Internet-Draft Key Rollover October 2006 1. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Viswanathan, et al. Expires April 12, 2007 [Page 3] Internet-Draft Key Rollover October 2006 2. Terminology The following terms are used in this document: key-list - A data structure used by the routing or management protocols.The key-list is a list of keys. Key identifier - An identifier that signifies the key attributes associated with the authentication. key - A member of the key-list. Each key contains an identifier, information that can be used to authenticate the protocol message, information that determines when the key can be used to authenticate an outbound message and information that determines when the key can be used to authenticate an inbound protocol message. key lifetime - Denotes the window when a key remains in active state. active key - A key used to generate authentication information for an outbound protocol message. Each key chain contains exactly one active key. The "active flag" on a key indicates whether a particular key qualifies to be active. eligible key - Each key-list contains zero or more eligible keys. The receiving stattion uses the shared secret from a key to authenticate an incoming protocol message only if that key is eligible. The "eligible flag" on a key indicates whether a particular key is eligible. Viswanathan, et al. Expires April 12, 2007 [Page 4] Internet-Draft Key Rollover October 2006 3. Introduction Many routing protocols authenticate messages by including a message authentication code (MAC) in message. To spoof a message, an attacker would not only have to approximate a valid message, but would also have to obtain the key that was used to calculate the MAC. This key never appears in the message stream. RFC 3562 addresses key management considerations regarding one such MD5 based authentication scheme. Based upon the strength of the MD5 hashing algorithm, RFC 3562 recommends that keys be changed at least every 90 days. Unfortunately, the authentication mechanisms described above permit keys to be changed during the lifetime of a routing adjacency only so long as the change is synchronized at both ends. This limitation has proven to be a significant deterrent to the effective deployment. This memo addresses that limitation. Using other out-of-band key negotiation protocols like IKE present a different set of overheads and requirements that is out-of-scope for this document. The need for an automated mechanism to rollover the keys at both endpoints is critical, and this document addresses a scheme to meet this requirement using the preconfigured keys. Viswanathan, et al. Expires April 12, 2007 [Page 5] Internet-Draft Key Rollover October 2006 4. Proposal This memo proposes an authentication-key rollover mechanism for routing and management applications by extending the pre-configured key usage to a key-list as follows: Network operators associate a key-list with each protected protocol connection. Each key-list includes a list of keys.Each key is associated with a unique identifier and several other data items that are described in Section 5 of this document. The key identifier and the associated key used for computing the digest from the sending station must be identically configured on all the authenticating receiving stations. Whenever the protocol generates an outbound message,it searches the key-list for an active key. Section 6 of this document describes the active key selection criteria. If it does not find an active key, it discards the outbound message. However, if the protocol finds an active key, it calculates a MAC using information from the active key as per the protocol specification for authentication. The receiving application associates its inbound message with a local key-list based upon its configuration. It then searches the associated key-list for a key whose identifier matches that which was specified by the incoming protocol message option. If it finds such a key and that key satisfies the eligibility criteria described in Section 7 of this document, the application uses the information from that key to calculate and verify the MAC as per its authentication handling specification. If no matching eligible key is found then it MUST declare an authentication failure and discard the protocol message. Viswanathan, et al. Expires April 12, 2007 [Page 6] Internet-Draft Key Rollover October 2006 5. Key Chain Attributes This section describes information requirements for the key-list. It does not mandate any specific implementation. A keychain is a set of keys, where each key is {A[i], K[i], V[i], S[i], T[i], S'[i], T'[i],F[i], F'[i]}: For the purpose of this document, key[i] is defined as the key whose identifer is equal to i. i - Key identifier, integer. The key identier range depends on the procotol specifics. AK - Active key, integer. Indicates the choice of the key[i] amongst all the keys in the key-list to generate MAC by the sender. AT - Accept tolerance, integer. It indicates the level of tolerance of clock skews. A[i] - Authentication algorithm to use with key[i]. K[i] - Shared secret to use with key[i]. V[i] - A vector that determines whether key[i] is to be used to generate MACs for inbound protocol messages, outbound protocol messages, or both. S[i] - Start time from which key[i] can be used by the sender. T[i] - End time after which key[i] cannot be used by the sender. S'[i] - Start time from which key[i] can be used by the receiver. T'[i] - End time after which key[i] cannot be used by the receiver. F[i] - Active flag that denotes the choice of the key for generating MACs for the outbound protocol messages. Only one key from the entire key-list is chosen as the active key. F'[i]- Elibile flag that denotes the eligibility of the key for generating MACs for the verification of inbound protocol messages. A[i] and K[i] MUST be configured symmetrically on all peers. That is, if key[i] is configured on two peer systems, A[i] and K[i] must be configured identically on each system. S[i], T[i], S'[i] and T'[i] are measured from a defined epoch that must have a known relationship to UTC. For the purposes of discussion, times are assumed to be measured in seconds since that epoch, although this is not a requirement. The range of values that can be specified for S[i], T[i], S'[i] and T'[i] includes two special values. The first special value is called NOW, and it represents the system time when the key is examined (as opposed to when the key is configured). The second special value, called INFINITY, represents a time beyond the end of the epoch. Viswanathan, et al. Expires April 12, 2007 [Page 7] Internet-Draft Key Rollover October 2006 S[i] and T[i] define a time-window during which a key can be used for sending. S'[i] and T'[i] define a time-window during which a key can be used for receiving. AT, the accept tolerance defines the connection's tolerance to clock- skew on either system. The accept tolerance can be measured in the order of seconds, though a special tag for INFINITY can be provisioned. Within a key-list, time-windows for sending can overlap. Likewise, within a key-list, time-windows for receiving can overlap. Typically, network operators will configure key-lists so that there are no gaps between time-windows for either sending or receiving. Implementations should issue a warning when network operators configure key-lists with gaps between time-windows. A gap of sufficient length can cause the the protocol connection/session to fail due to timeout. The active flag F[i] is set when the system time >= the S[i] and is reset when the the system time equals or exceeds T[i]. In general, network operators should avoid reusing shared secrets. The degree to which an operator can reuse keys is defined by local security policy. During the lifetime of a protocol connection/session, network operators may add and delete keys from the keychain. However, the network operator must ensure that an active key is always configured on all endpoints. Implementations are free to implement key chains in any manner that satisfies the above stated information requirements. For example, implementations can translate the above stated information requirements directly into a data structure. Alternatively, they can implement one key-list for sending and another for receiving. In this case, the implementation may omit data items that do not apply to either the sending or receiving key-list. Likewise, implementations can implement S[i] and T[i] as a start-time and an end-time. Alternatively, implementations can implement S[i] and T[i] as a start-time and a duration, or they can infer the T[i] from the S[i] of the next key. Viswanathan, et al. Expires April 12, 2007 [Page 8] Internet-Draft Key Rollover October 2006 6. Key rollover criteria The key usage is strictly bound by the lifetime specification. It can only be used between S[i] and T[i], or between S'[i] and T'[i]. However, there may be a need to rollover a key while will within its active lifetime window. The authenticating protocol semantics(like sequence number wrap arounds) may also dictate a rollover based on the volume of data authenticated using the key K[i] triggering a rollover to the next active key. Viswanathan, et al. Expires April 12, 2007 [Page 9] Internet-Draft Key Rollover October 2006 7. Active Key Selection The following paragraphs describe how the sending application selects the active key from its key-list. Implementations SHOULD support this key selection process; implementations MAY also support other active key selection mechanisms as a configurable option. First, the application identifies all candidate keys that meet the following requirements: - V[i] specifies that the key can be used for either sending or sending and receiving. - the system time >= S[i] - the system time < T[i] - Active flag F[i] is set Because the time-windows specified by S[i] and T[i] can overlap, it is possible that multiple keys will satisfy the above stated criteria. When this occurs, TCP chooses between the candidate keys by applying following rules in the order that they are listed below: - prefer the youngest key (i.e., the key whose value for S[i] is greatest) - When there is a tie based upon the above stated criterion, select the key whose identifier is numerically smallest. In the case that an active key has already been deemed rolledover due the volume based criteria imposed by the application, then that key's active flag is reset, and the active key selection process is repeated. The selection process described above is guaranteed to return zero or one active keys. If no active key is returned, the protocol discards the outbound message. Viswanathan, et al. Expires April 12, 2007 [Page 10] Internet-Draft Key Rollover October 2006 8. Key Eligibility When the application receives a protocol message that includes the Authentication Option, it searches that connection's key-list for a key whose identifier is identical to Key ID specified by the incoming authentication Option. It uses that key to authenticate the incoming protocol message providing that the key is eligible to be used. Implementations SHOULD support the following process for determining key eligibility; implementations MAY also support other eligible key selection mechanisms as a configurable option. A key is eligible if all of the following criteria are met: - V[i] specifies that the key can be used for either receiving or sending and receiving. - A[i] is equal to the algorithm specified by the Authentication Option from the incoming protocol message - the system time >= S'[i] - the system time < T'[i] If the protocol does not find a key whose identifier is identical to the Key ID specified by the incoming authentication Option, it MUST declare an authentication failure and discard the message. Likewise, it MUST declare an authentication failure if it finds the key but the key is not eligible. Viswanathan, et al. Expires April 12, 2007 [Page 11] Internet-Draft Key Rollover October 2006 9. Clock Synchronization 9.1. Overlapping lifetime Clocks do not need to be synchronized accurately between the sending and receiving systems. The only requirements are that the key used to generate the MAC on the sending system is also configured on the receiving system and that the time ovelap between sender's active key and the receiver's eligible key is great enough to compensate for clock skew. Receipt of a protocol message whose authentication data was generated using a key other than the one that is currently active on the receiving system does not constitute an error. It may indicate only that clocks are not synchronized between the sending and receiving systems. 9.2. Accept tolerance To overcome the issues due to clock skews at the endpoints without needing to configure overlapping lifetime, a configurable tolerance level that the operator perceives to be acceptable is proposed. The tolerance level indicates the window of tolerance where-in a key is still considered eligible. In other words, a key is considered eligible from AT seconds prior to S'[i], upto AT seconds after T'[i]. Viswanathan, et al. Expires April 12, 2007 [Page 12] Internet-Draft Key Rollover October 2006 10. Application Considerations The mechanisms described in this memo are intended for use with routing and management applications that manipulate key set contents. The Key identifier is the critical component in handling keyrollover detection optimally. Protocols specifications that do not carry the key identifier in their authentication option header present an overhead in rollover detection. Depending on the number of eligible keys that are configured, the MAC computation and verification may need to be done on one or more of those. Viswanathan, et al. Expires April 12, 2007 [Page 13] Internet-Draft Key Rollover October 2006 11. Implications 11.1. Performance The performance hit in calculating digests may inhibit the use of authentication option. Performance will vary depending upon processor type, authentication algorithm, packet size and number of MAC calculations per second.Protocols that do not carry the key identifier in its authentication option may at worst need to repeat the MAC caluculations for all keys that are eligble, thereby affecting performance. Viswanathan, et al. Expires April 12, 2007 [Page 14] Internet-Draft Key Rollover October 2006 12. Operational Considerations Network operators may experience an operational need to make a key become both active and eligible immediately. In order to satisfy this need, the network operator should execute the following sequence: Configure the key on both TCP peers with i equal to the lowest free value. On both systems, set S[i] and T[i] to INFINITY. This will cause the key to be perpetually inactive (for sending). Also set S'[i] to NOW and T'[i] to INFINITY. This will cause the key to be perpetually eligible (for receiving). Once the above step has been completed, on both systems, set S[i] to NOW. This will cause the key[i] to become active. Now it is safe to remove or deactivate all other keys. Viswanathan, et al. Expires April 12, 2007 [Page 15] Internet-Draft Key Rollover October 2006 13. Contributors The following individuals contributed to this document: Chandrashekhar Appanna (achandra@cisco.com) Anantha Ramaiah (ananth@cisco.com) David McGrew (mcgrew@cisco.com) Satish Mynam (mynam@cisco.com) Andy Heffernan (ahh@juniper.net) Kapil Jain (kapil@juniper.net) Viswanathan, et al. Expires April 12, 2007 [Page 16] Internet-Draft Key Rollover October 2006 14. Security Considerations Management of authentication keys has been a significant operational problem, both in terms of key synchronization and key selection. For example, current guidance [RFC3562] warns against sharing RFC 2385 keys between systems, and recommends changing keys according to a schedule. The same general operational issues are relevant for the management of MAC keys. Viswanathan, et al. Expires April 12, 2007 [Page 17] Internet-Draft Key Rollover October 2006 15. IANA Considerations None. Viswanathan, et al. Expires April 12, 2007 [Page 18] Internet-Draft Key Rollover October 2006 16. References 16.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 16.2. Informative References [I-D.bonica-tcp-auth] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. Wheeler, "Authentication for TCP-based Routing and Management Protocols, draft-bonica-tcp-auth-05 (work in progress)", July 2006. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. Viswanathan, et al. Expires April 12, 2007 [Page 19] Internet-Draft Key Rollover October 2006 Authors' Addresses Sriram Viswanathan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-527-8830 Email: sriram_v@cisco.com Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-6198 Email: rbonica@juniper.net Ronald Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US Email: bew@cisco.com Andrew Lange Alcatel 710 E. Middlefield Road Mountain View, CA 94043 US Email: andrew.lange@alcatel.com Viswanathan, et al. Expires April 12, 2007 [Page 20] Internet-Draft Key Rollover October 2006 Owen N. Wheeler BT British Telecommunications plc Adastral Park Martlesham Heath IPSWICH, Suffolk IP5 3RE GB Email: owen.wheeler@bt.com Viswanathan, et al. Expires April 12, 2007 [Page 21] Internet-Draft Key Rollover October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Viswanathan, et al. Expires April 12, 2007 [Page 22]