Internet DRAFT - draft-weber-krb-wg-kerberos-clock-synchronization

draft-weber-krb-wg-kerberos-clock-synchronization








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]