Subject: | krb5 gss_accept_sec_context() does not allow clock skew |
In 1996 (before the 1.0 release), an explicit check was added to the
krb5 gss_accept_sec_context() implementation to reject the incoming
token if the ticket endtime expires before the current time. This
check may have been motivated by the need to compute a non-negative
time_rec result. If the check triggers, gss_accept_sec_context()
returns GSS_S_CREDENTIALS_EXPIRED, which is incorrect (it suggests
that the acceptor's verifier_cred_handle has expired) and is not
consistent with the behavior when krb5_rd_req_decoded() fails due to
expired tickets.
This unnecessarily strict check causes a particularly bad experience
when (a) the client's clock is slightly ahead of the server's clock,
and (b) the maximum service ticket lifetime is lower than the maximum
TGT lifetime. In that circumstance, the client will acquire a new
service ticket using the TGT if the client sees the credential as
expired, but the application will experience an authentication
failure if only the server sees the credential as expired.
A better way of dealing with the time_rec computation would be to
unconditionally add the allowed clock skew to time_rec, and to
lifetime_rec in krb5_gss_inquire_context.
There is a corresponding piece of code in the krb5
gss_init_sec_context() to "Enforce a stricter limit" on client
credentials, but it may not be operative; krb5_get_credentials() will
already ignore cached service tickets whose endtime is less than the
current time.
See also:
http://mailman.mit.edu/pipermail/krbdev/2015-October/012457.html
krb5 gss_accept_sec_context() implementation to reject the incoming
token if the ticket endtime expires before the current time. This
check may have been motivated by the need to compute a non-negative
time_rec result. If the check triggers, gss_accept_sec_context()
returns GSS_S_CREDENTIALS_EXPIRED, which is incorrect (it suggests
that the acceptor's verifier_cred_handle has expired) and is not
consistent with the behavior when krb5_rd_req_decoded() fails due to
expired tickets.
This unnecessarily strict check causes a particularly bad experience
when (a) the client's clock is slightly ahead of the server's clock,
and (b) the maximum service ticket lifetime is lower than the maximum
TGT lifetime. In that circumstance, the client will acquire a new
service ticket using the TGT if the client sees the credential as
expired, but the application will experience an authentication
failure if only the server sees the credential as expired.
A better way of dealing with the time_rec computation would be to
unconditionally add the allowed clock skew to time_rec, and to
lifetime_rec in krb5_gss_inquire_context.
There is a corresponding piece of code in the krb5
gss_init_sec_context() to "Enforce a stricter limit" on client
credentials, but it may not be operative; krb5_get_credentials() will
already ignore cached service tickets whose endtime is less than the
current time.
See also:
http://mailman.mit.edu/pipermail/krbdev/2015-October/012457.html