doc/html/_sources/basic/rcache_def.txt

   1 .. _rcache_definition:
   2
   3 replay cache
   4 ============
   5
   6 A replay cache (or "rcache") keeps track of all authenticators
   7 recently presented to a service.  If a duplicate authentication
   8 request is detected in the replay cache, an error message is sent to
   9 the application program.
  10
  11 The replay cache interface, like the credential cache and
  12 :ref:`keytab_definition` interfaces, uses `type:value` strings to
  13 indicate the type of replay cache and any associated cache naming
  14 data to use.
  15
  16 Background information
  17 ----------------------
  18
  19 Some Kerberos or GSSAPI services use a simple authentication mechanism
  20 where a message is sent containing an authenticator, which establishes
  21 the encryption key that the client will use for talking to the
  22 service.  But nothing about that prevents an eavesdropper from
  23 recording the messages sent by the client, establishing a new
  24 connection, and re-sending or "replaying" the same messages; the
  25 replayed authenticator will establish the same encryption key for the
  26 new session, and the following messages will be decrypted and
  27 processed.  The attacker may not know what the messages say, and can't
  28 generate new messages under the same encryption key, but in some
  29 instances it may be harmful to the user (or helpful to the attacker)
  30 to cause the server to see the same messages again a second time.  For
  31 example, if the legitimate client sends "delete first message in
  32 mailbox", a replay from an attacker may delete another, different
  33 "first" message.  (Protocol design to guard against such problems has
  34 been discussed in :rfc:`4120#section-10`.)
  35
  36 Even if one protocol uses further protection to verify that the client
  37 side of the connection actually knows the encryption keys (and thus is
  38 presumably a legitimate user), if another service uses the same
  39 service principal name, it may be possible to record an authenticator
  40 used with the first protocol and "replay" it against the second.
  41
  42 The replay cache mitigates these attacks somewhat, by keeping track of
  43 authenticators that have been seen until their five-minute window
  44 expires.  Different authenticators generated by multiple connections
  45 from the same legitimate client will generally have different
  46 timestamps, and thus will not be considered the same.
  47
  48 This mechanism isn't perfect.  If a message is sent to one application
  49 server but a man-in-the-middle attacker can prevent it from actually
  50 arriving at that server, the attacker could then use the authenticator
  51 (once!) against a different service on the same host.  This could be a
  52 problem if the message from the client included something more than
  53 authentication in the first message that could be useful to the
  54 attacker (which is uncommon; in most protocols the server has to
  55 indicate a successful authentication before the client sends
  56 additional messages), or if the simple act of presenting the
  57 authenticator triggers some interesting action in the service being
  58 attacked.
  59
  60 Default rcache type
  61 -------------------
  62
  63 There is currently only one implemented kind of replay cache, called
  64 **dfl**.  It stores replay data in one file, occasionally rewriting it
  65 to purge old, expired entries.
  66
  67 The default type can be overridden by the **KRB5RCACHETYPE**
  68 environment variable.
  69
  70 The placement of the replay cache file is determined by the following:
  71
  72 #. The **KRB5RCACHEDIR** environment variable;
  73
  74 #. If KRB5RCACHEDIR is unspecified, on UNIX, the library
  75    will fall back to the environment variable **TMPDIR**, and then to
  76    a temporary directory determined at configuration time such as
  77    */tmp* or */var/tmp*; on Windows, it will check the environment
  78    variables *TEMP* and *TMP*, and fall back to the directory C:\\.
  79
  80 Performance issues
  81 ------------------
  82
  83 Several known minor performance issues that may occur when replay
  84 cache is enabled on the Kerberos system include: delays due to writing
  85 the authenticator data to disk slowing down response time for very
  86 heavily loaded servers, and delays during the rewrite that may be
  87 unacceptable to high-performance services.
  88
  89 For use cases where replays are adequately defended against for all
  90 protocols using a given service principal name, or where performance
  91 or other considerations outweigh the risk of replays, the special
  92 replay cache type "none" can be specified::
  93
  94     KRB5RCACHETYPE=none
  95
  96 It doesn't record any information about authenticators, and reports
  97 that any authenticator seen is not a replay.