INTERNET DRAFT Joel N. Weber II June 20, 2003 Expires December 20, 2003 Kerberos Clock Synchronization draft-weber-krb-wg-kerberos-clock-synchronization-01.txt This document is an Internet-Draft and is subject to all the provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html The distribution of this memo is unlimited. It is filed as draft- weber-krb-wg-kerberos-clock-synchronization-01.txt, and expires 20 December 2003. Please send comments to the author or to ietf-krb- wg@anl.gov ABSTRACT This document discusses the security vulnerabilities that can exist in the Kerberos protocol and related protocols when clock synchronization is insecure, alternative methods that could be used to reduce or eliminate dependency on secure clock synchronization, and sanity checks which can be used when setting the system clock using an insecure time source as a reference in order to remove security vulnerabilities. INTRODUCTION The Kerberos protocol [KERBEROS] assumes that accurate time is available from the system clock. If an attacker can influence the clock on a system running Kerberos, this may create vulnerabilities. Weber Kerberos Clock Synchronization [Page 1] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 Specifically, application protocols which rely on a replay cache to prevent replay attacks become vulnerable to replays if an attacker can set the clock backwards. Also, accurately determining whether a ticket is expired requires an accurate clock. There are a variety of insecure time sources that may be used. Most widely deployed network time synchronization configurations do not use any cryptographic authentication, and are vulnerable to spoofing. The commonly used radio time synchronization services, such as GPS and WWV, are also vulnerable to spoofing. [GPS01] Furthurmore, the entity running a Kerberos realm is usually different than the entity which is the ultimate source of time information. This document assumes that an insecure time source will be used to set the system clock, and explores what precautions need to be taken in order to avoid weakening Kerberos's security. It also discusses ways of using the Kerberos protocol that reduce Kerberos's dependence on time. When a secure, trusted, accurate external time reference is not available, another possible solution is to allow the clocks to drift and have the Kerberos client and application server use the KRB_AS_REQ and KRB_AS_REP messages as described in [KERBEROS] and [DGT96] to determine what the KDC's idea of the current time is. This can be done whenever there is a need to read the clock, although the overhead of such an approach may make doing so a bad idea. Another option is to periodically determine the offset between the local system clock and the KDC's clock, followed by adjusting by that offset whenever Kerberos software reads the system clock; however, if this is done in conjunction with insecure system clock synchronization, the sanity checks described in this document MUST be used. 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]. UPTIME COLCK An operating system can provide a function which will return the time elapsed since booting in a way that is unaffected by changing the time of day clock. If this is available, this SHOULD be used when doing operations that require only relative time from the operating system, as doing so will remove the potential for a naive or inept system administrator to create security vulnerabilities by changing the clock. However, care should be taken to make sure that the uptime really is Weber Kerberos Clock Synchronization [Page 2] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 independent of the clock which can be changed by network time synchronization protocols; for example, the ``uptime'' command on NetBSD simply checks the time of day clock, and the time the system was booted, and subtracts. Also, when using this approach, state MUST be discarded when the system is rebooted. REPLAYS A replay attack is one in which an attacker eavesdrops network traffic, and then later repeats it back. An eavesdropper can do this without breaking the cryptosystem or understanding what the contents of the encrypted data are. Application protocols generally need to explicitly prevent replay attacks involving Kerberos authenticators. For example, if a file transfer protocol does not prevent replay attacks, it may be possible for an attacker to replace a newer version of a file with an older version, if multiple versions of a file are uploaded to the same location on the same day. Remote login protocols need to protect against the possibility that a command that the user had intended be run only once could be repeated as a result of a replay attack. The authenticator is not the only ciphertext that can be replayed, but preventing replay of authenticators from succeeding combined with secure integrity protection will cause any other replays to be rejected. The Kerberos authentication service protocol and the Kerberos ticket granting service protocol have their own mechanisms for dealing with replays. Because this does not depend on accurate clock synchronization, it is beyond the scope of this document. However, protocols for updating the KDC's database may have properties identical to the application protcols discussed by this document. REPLAY CACHE Some application protocols based on Kerberos use a replay cache to prevent replay attacks. The replay cache contains enough information to determine if an authenticator has been seen before; if it has, the authenticator will be rejected. The replay cache normally only contains information about authenticators seen within the allowed clock skew interval; authenticators from too far in the future or past are simply rejected before consulting the replay cache. If an attacker can induce the clock on an application server to run at a wrong rate, but does not have the ability to set the application Weber Kerberos Clock Synchronization [Page 3] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 server's clock backwards, a denial of service attack may be easier than it otherwise would be, but no additional vulnerability exists with respect to replays, as the clock which is running at the wrong rate causes the discarding of replay cache entries at the same rate as it causes the rejection of authenticators as having out of bound timestamps. Servers using a replay cache SHOULD store along with the replay cache the timestamp of the newest discarded entry, and reject all authenticators with equal or earlier timestamps. Doing so will remove any vulnerabilities that may be present if the clock is set backwards, as long as the replay cache is not lost. Replay cache entries from before the clock skew interval MAY be stored, in order to allow the clock to be set backwards somewhat without a denial of service. If an attacker can cause the clock to be set backwards, and there is no data stored alongside the replay cache indicating the time of the most recent discarded authenticator, then it is possible that an authenticator that had been removed from the replay cache would be sent again. Therefore, an application server which is running one or more protocols which rely on a replay cache to prevent replays MUST NOT allow the system clock to be set backwards unless some other measure is taken to prevent such authenticators from being accepted (such as changing the host key, as is described later in this document). Applications which rely on a replay cache MUST make sure that there is no vulnerability if an authenticator is sent before it is valid, and then replayed while it is valid; in particular, the clients for such protocols MUST make sure that the authenticator is not rejected as having a time which is out of bounds before sending additional data across the network connection if replaying that data could have negative consequences. REPLAY CACHE ALTERNATIVES New application protocols MAY be designed to avoid the use of the replay cache. The use of sub-session keys, as described in [KERBEROS], can remove the need for a replay cache, depending on how the generation of sub- session keys is done. Another option is the challenge-response method described in [Bellovin91]. Weber Kerberos Clock Synchronization [Page 4] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 Yet another alternative is the use of the challenge-response method described below which also removes the application server's clock from the ticket expiration process. When using a method of avoiding the replay cache which uses random numbers, proper cryptographic random number generation techniques MUST be used. [RFC1750] PROTOCOL DOCUMENTATION The security considerations section of IETF documents describing application proctocols that support the use of Kerberos SHOULD explicitly describe whether the use of a replay cache is required by the design of the protocol. TICKET EXPIRATION The only time Kerberos verifies that a principal has knowlege of the long term key is at the time tickets are initially issued. This has the advantage that the client does not need to store the long term key in memory. However, because application servers will accept tickets until they expire, a stolen ticket will continue to work even if the long term key is changed or disabled. Whether the ticket expiration time has been reached is checked both by the ticket granting service, and by application servers. The checking is only accurate if the clock on the server doing the checking is accurate. Ticket expiration times seem to be choosen to be a reasonable tradeoff between making the occasional stolen ticket cease to function, and the convenience of not having to type passwords constantly. Because there is imprecision in determining ticket lifetimes, it is not clear that additional imprecision in the exact effective lifetime that might be introduced by imprecise clocks is a problem. However, it is important that tickets expire within a reasonable approximation of the intended lifetime, perhaps on the order of within 50% of the intended time. A scheme which uses the KRB_AS_REQ and KRB_AS_REP to determine whether tickets are within this range is likely to be sufficient, as long as it is not vulnerable an attack based on it caching information about the offset between the system clock and the KDC's clock where the system clock can be manipulated backwards or substantially slowed by an attacker. It is also worth noting that with sufficient clock drift drift, users of an application server which gets a reasonable amount of use may notice and complain to the application server's administrator, thus limiting the length of time during which expired tickets will be Weber Kerberos Clock Synchronization [Page 5] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 accepted, if the host gets a reasonably large amount of use. However, this may not be the case if the application server is not checking the time in tickets for anti-replay purposes, and assumes that the amount of drift that is allowed in a given amount of time is somewhat limited. CHALLENGE-RESPONSE EXPIRATION Application protocols MAY send a nonce from the server to the client, requiring the client to present Kerberos credentials which contain the nonce in the authorization data field. As long as the nonce is long enough and random enough that it would be impractical for a client to get tickets for that value of the nonce without having actually recieved it from the server, the application server can be sure that the tickets are unexpired, without needing accurate clock synchronization. Such a nonce MAY have some of its entropy derived from the application server's system clock. If the only entropy source in generating the nonce is the system clock, there will be a vulnerability if the clock is set backwards, and precautions MUST be taken to prevent an attacker from setting the system clock backwards and then using expired tickets. An application server using a nonce in the authorization data field of the Kerberos credentials MAY send a new nonce for every connection. This has the advantage that the application server's clock is not used at all in the determination of whether tickets are expired. This will also be sufficient to prevent replays. However, this approach SHOULD NOT be used for protocols where repeated connections in a short period of time are common, as such usage would substantially increase load on the KDC. An application server MAY send the same nonce to all clients that connect, changing the nonce at some interval SHOULD default to the default clock skew interval. For a protocol such as HTTP where clients are expected to repeatedly connect, this will result in significantly less load on the KDC. However, this requires being able to reliably know that sufficiently little time has passed that the nonce does not yet need to be changed, and if the only source of time information is a clock which is synchronized to network time insecurely, this may negate some of the point of using a nonce instead of the clock in the first place. Also note that when using the same nonce over an interval of time, tickets may be accepted after they have expired by an amount of time Weber Kerberos Clock Synchronization [Page 6] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 up to the interval between changing the nonce. If only a single nonce is available which is changed at a periodic interval, there are cases where a client making many connections in a period of time which is a small fraction of the nonce changing interval will need to get tickets twice, because the nonce will change in the middle of its usage. A furthur refinement would be to keep a handful of nonces active at any one time, sending the client a list of nonces, with the most recently generated nonce being the prefered nonce; if the client already has a ticket cached with any of the active nonces, it can send that ticket, and otherwise it can request a new ticket from the KDC with the prefered nonce. For example, with five active nonces and a five minute window, the oldest nonce would be disabled and replaced with a new once once every minute, with the effect that a ticket could potentially continue to work for up to five minutes after it expires, and a guarentee that the ticket will work for at least four minutes after it is issued. If the operating system provides an uptime function which is unaffected by changing the time of day clock, as described above, this SHOULD be used to determine when to replace the nonce, as doing so will protect Kerberos's ticket expiration checking against bogus insecure network time updates. When using this approach, the nonce or nonces MUST be discarded when the system is rebooted. Some application servers terminate or suspend sessions when tickets expire. When such application servers are using this challenge- response approach to verifying that tickets are unexpired, application servers MUST determine the length of time that the tickets are usable for by subtracting the ticket issue time from the ticket expiration time, and MUST compute the expiration time in terms of the local clock by adding the length of time which the ticket is usable to the current time read from the system clock or to the current value read from the uptime clock. If an application server using the challenge-response method of checking for ticket expiration encounters a client which does not support the challenge-response method, it MUST provide a mechanism by which the client can still connect, and SHOULD use the KRB_AS_REQ and KRB_AS_REP method of checking the KDC's current time with the same frequency at which it replaces nonces. Note also that the use of KRB_AS_REQ and KRB_AS_REP in this fashion does not prevent replays. The challenge-response method has the potential disadvantages that existing protocols would require modification to support it, and that depending on the details of how the application protocol is designed, Weber Kerberos Clock Synchronization [Page 7] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 it may require an additional round trip in the initial protocol setup. KDC CLOCK ACCURACY If the KDC can be induced to issue tickets which expire significantly in the future, revoking all of the tickets it issues is likely to be challenging; while changing all application server host keys would be an appropriate way of recovering from this situation, it is likely to be a substantial amount of work for even a moderately large site, and if the hosts in the realm have many administrators which do not work closely together, it may be impossible to get all host keys changed. It is RECOMMENDED that tight limits be placed on how much the rate of advance of the KDC's clock can be increased by an insecure time source versus the KDC's own internal clock. When there are multiple KDCs in a realm, their clocks MUST be kept set at the same time, modulo a reasonable small offset that can be allowed for by network latency etc. SANITY CHECKS ON INSECURE TIME SOURCES A time source MUST be regarded as insecure if there is no mechanism for verifying that the time source being consulted is actually the intended time source. A time source MUST also be regarded as insecure if it is not as trusted as the KDC. If an application server is relying on accurate clock synchronization to prevent replays and/or to check whether tickets have expired, and it is using an insecure time source, it MUST NOT ever allow the clock to be set backwards in response to data from an insecure time source, and it MUST NOT allow the clock to run at a rate which differs from the rate of its internal clock by more than the expected drift factor, as described below. The sanity checks described in the previous paragraph are REQUIRED if ticket expiration is determined by directly comparing the expiration time in the ticket to the system clock. Unless an uptime clock which is independent of external time synchronization is used, these sanity checks are also REQUIRED if a nonce is used which is not changed for each new session, or if the session terminates or is suspended when the tickets expire. If a KDC is using an insecure time source, it MUST NOT allow the clock to be set backwards, and MUST NOT allow the clock to be run at a rate which differs from the expected factor, as described below. Weber Kerberos Clock Synchronization [Page 8] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 The expected factor SHOULD be a configurable option, and the system administrator SHOULD set it reasonably tightly. For an application server, +/- 10% is likely to be a reasonable value. For a KDC, a value no looser than about +/- 1% is RECOMMENDED. An even better solution is likely to be a highly accurate reference clock such as a cesium clock which is updated by some mechanism such as GPS, with a much tighter expected drift factor. Such a clock reference SHOULD be controlled by the same person, people, or organization that controls the KDC. Precautions SHOULD be taken to make sure an attacker cannot induce small amounts of clock skew repeatedly in order to get the system administrator to loosen the amount of clock skew which is allowed before the clock synchronization software stops functioning. It is not clear how this can be accomplished. Sanity checks MAY be done by comparing multiple clocks within the host against an external reference. For example, many computer systems have both a battery powered clock that runs all the time, and a clock which generates interrupts at a periodic interval while the computer is turned on. If the normal rate of drift between these these two internal sources and an external source is noted, error messages pinpointing which source has become inaccurate will become possible. CHANGING HOST KEYS If an application server's clock needs to be set back, or if a replay cache needs to be reset if the application server is keeping track of the time of the most recently discarded entry, any host keys which are used for any application protocol which relies on a replay cache MUST be changed, unless some other means of preventing old authenticators from being used is available. If this is done, the services running on the application server which depend on the replay cache MUST be disabled before the steps of changing the clock backwards and changing the host key are done, and once those steps are done, the services can be reenabled. It is important to note that there are some inconveniences to this approach. There may be a race condition in which the KDC has already updated the host key in its database, but the application server crashes or the network connection fails before the application server can update its idea of what the host key is, requiring system administrator intervention to recover. Clients with cached tickets may not deal gracefully with a host key changing abrubtly. And database propagation between KDCs may not be instantaneous, causing a partial outage until propagation happens. Weber Kerberos Clock Synchronization [Page 9] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 HUMAN FACTORS An attacker which can make an application server's clock run too fast by attacking an insecure time synchronization mechanism may be able to induce the person running the application server to set the clock backwards in an insecure fashion, if the person is not adaquately familiar with the proper procedures; this MUST be taken into account when considering whether insecure time synronization is an overall security risk. SECURITY CONSIDERATIONS This entire document is about security considerations. ACKNOWLEDGEMENTS The author would like to thank Sam Hartman and Nicolas Williams for their invaluable assistance with this document. AUTHOR'S ADDRESS Joel N. Weber II 185 Lowell St #2 Somerville MA 02144-2629 Email: weber@joelweber.com NORMATIVE REFERENCES [KERBEROS] RFC-Editor: To be replaced by RFC number for draft-ietf- krb-wg-kerberos-clarifications. [RFC2026] S. Bradner, RFC2026, BCP 9: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC 2119, BCP 14: "Key words for use in RFCs to Indicate Requirement Levels", March 1997. INFORMATIVE REFERENCES [Bellovin91] Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos Authentication System", in Proceedings of the Winter 1991 Usenix Security Conference, January, 1991. [DGT96] Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks Adrift: History, Protocols, and Implementation", USENIX Computing Systems 9:1 (January 1996). Weber Kerberos Clock Synchronization [Page 10] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 [GPS01] Volpe, John, "Vulnerability Assessment of the Transportation Infrastructure Relying on the Global Positioning System", August 2001. [RFC1750] D. Eastlake, 3rd, S. Crocker, J. Schiller, RFC 1750: "Randomness Recommendations for Security", December 1994. IPR NOTICES The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. COPYRIGHT NOTICE Copyright (C) The Internet Society 2003. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be Weber Kerberos Clock Synchronization [Page 11] draft-weber-krb-wg-kerberos-clock-synchronization-01.txt June 20 2003 revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Weber Kerberos Clock Synchronization [Page 12]