Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-RT-Original-Encoding: us-ascii
Content-Length: 1298


I have a short running yet frequently run app that gets a TGT with a
keytab and then does a TGS request.  From time to time the TGS_REQ is
denied with KRB5KRB_AP_ERR_REPEAT "Request is a replay".

Turns out that as part of the TGT request, get_in_tkt.c
verify_as_reply() calls krb5_set_real_time() to account for the time
offset between client and server.  Since only seconds come from the
server it is called with microseconds of 0 which effectively sets the
microseconds in the client to 0.  (Effectively since these values are
offsets that the client library applies to the real system time.)

Since the app code between the AS_REQ and TGS_REQ is the same from
invocation to invocation, the time between them is often the same, and
so if there are multiple invocations in the same second (frequently
run app), the time in the authenticator (seconds and microseconds) is
occasionally the same, running afoul of the replay detection on the
KDC.

As a workaround, the krb5.conf can have:

[libdefaults]
   kdc_timesync = 0

but that disables all time synchronization which is not desirable.

Attached are 2 patches.  One to leave the microseconds unchanged, and one 
debugging hack to see the time values in the authenticator.

-nik

Nik Conwell
nik@bu.edu
Boston University Information Technology