AS-REQ with till being the epoch

[Weijun Wang]

It looks like if I set the till field in AS-REQ to the epoch, the issued ticket will have a very big endtime (Ex: now it's 2106-02-07 06:28:15 (UTC)).

Well, this is OK.

But if I call kvno with this TGT in ccache, I see a "Ticket expired while getting credentials" error. Maybe somewhere in the KDC that very big endtime is mistakenly treated as a very small number?

My KDC is compiled from the head of https://github.com/krb5/krb5.git/.

Thanks
Max


_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Weijun Wang]

More info:

The KRB-ERROR reply to TGS-REQ has a strange ctime: 1974-12-10 21:52:23 (UTC).

--Max

Post by Weijun Wang
It looks like if I set the till field in AS-REQ to the epoch, the issued ticket will have a very big endtime (Ex: now it's 2106-02-07 06:28:15 (UTC)).
Well, this is OK.
But if I call kvno with this TGT in ccache, I see a "Ticket expired while getting credentials" error. Maybe somewhere in the KDC that very big endtime is mistakenly treated as a very small number?
My KDC is compiled from the head of https://github.com/krb5/krb5.git/.
Thanks
Max

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Weijun Wang
It looks like if I set the till field in AS-REQ to the epoch, the issued ticket will have a very big endtime (Ex: now it's 2106-02-07 06:28:15 (UTC)).

I guess you have also configured the KDC not to have any ticket lifetime
limits, so the KDC winds up using kdc_infinity (2**32-1) as the ticket
end time.

If "set the till field in AS-REQ to the epoch" you mean the client is
sending "19700101000000Z" in the till field, this is technically a bug
since the client requested a never-valid ticket, not a ticket valid for
a long time. But it doesn't seem like an important bug, as you say.

Post by Weijun Wang
But if I call kvno with this TGT in ccache, I see a "Ticket expired while getting credentials" error. Maybe somewhere in the KDC that very big endtime is mistakenly treated as a very small number?

The y2038 changes on master are only intended to work up until times
near 2106, so this behavior isn't surprising. I suspect the KDC is
adding the clock skew (300) to 2**32-1 with 32-bit unsigned arithmetic,
producing a small number.

Post by Weijun Wang
The KRB-ERROR reply to TGS-REQ has a strange ctime: 1974-12-10
21:52:23 (UTC).

Apparently we set the KRB-ERROR ctime to the client nonce, for both AS
and TGS replies. I had no idea we did this; it is clearly broken, as
there is no good reason to believe that the client is using its system
time as the nonce. Even going back to RFC 1510, a random nonce is
recommended for KDC requests. I will fix it (by not setting the ctime
field).
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Weijun Wang]

Post by Greg Hudson

Post by Weijun Wang
It looks like if I set the till field in AS-REQ to the epoch, the issued ticket will have a very big endtime (Ex: now it's 2106-02-07 06:28:15 (UTC)).

I guess you have also configured the KDC not to have any ticket lifetime
limits, so the KDC winds up using kdc_infinity (2**32-1) as the ticket
end time.
If "set the till field in AS-REQ to the epoch" you mean the client is
sending "19700101000000Z" in the till field, this is technically a bug
since the client requested a never-valid ticket, not a ticket valid for
a long time.

According to https://tools.ietf.org/html/rfc4120#section-5.4.1:

till
This field contains the expiration date requested by the client in
a ticket request. It is not optional, but if the requested
endtime is "19700101000000Z", the requested ticket is to have the
maximum endtime permitted according to KDC policy. Implementation
note: This special timestamp corresponds to a UNIX time_t value of
zero on most systems.

Post by Greg Hudson
But it doesn't seem like an important bug, as you say.

Post by Weijun Wang
But if I call kvno with this TGT in ccache, I see a "Ticket expired while getting credentials" error. Maybe somewhere in the KDC that very big endtime is mistakenly treated as a very small number?

The y2038 changes on master are only intended to work up until times
near 2106, so this behavior isn't surprising. I suspect the KDC is
adding the clock skew (300) to 2**32-1 with 32-bit unsigned arithmetic,
producing a small number.

Will this be fixed?

Post by Greg Hudson

Post by Weijun Wang
The KRB-ERROR reply to TGS-REQ has a strange ctime: 1974-12-10
21:52:23 (UTC).

Apparently we set the KRB-ERROR ctime to the client nonce, for both AS
and TGS replies. I had no idea we did this; it is clearly broken, as
there is no good reason to believe that the client is using its system
time as the nonce. Even going back to RFC 1510, a random nonce is
recommended for KDC requests. I will fix it (by not setting the ctime
field).

I see.

Thanks
Max



_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Weijun Wang]

Post by Greg Hudson

Post by Weijun Wang
It looks like if I set the till field in AS-REQ to the epoch, the issued ticket will have a very big endtime (Ex: now it's 2106-02-07 06:28:15 (UTC)).

I guess you have also configured the KDC not to have any ticket lifetime
limits, so the KDC winds up using kdc_infinity (2**32-1) as the ticket
end time.

No. I have "max_life = 10h 0m 0s" for the realm in kdc.conf.

The problem seems to be in src/kdc/kdc_util.c:

1753 void
1754 kdc_get_ticket_endtime(kdc_realm_t *kdc_active_realm,
1755 krb5_timestamp starttime,
1756 krb5_timestamp endtime,
1757 krb5_timestamp till,
1758 krb5_db_entry *client,
1759 krb5_db_entry *server,
1760 krb5_timestamp *out_endtime)
1761 {
1762 krb5_timestamp until, life;
1763
1764 if (till == 0)
1765 till = kdc_infinity;

My till is 0, so it's now -1.

1766
1767 until = ts_min(till, endtime);

endtime is always kdc_infinity for AS-REQ, still -1.

1768
1769 life = ts_delta(until, starttime);

life is now a negative number.

1770
1771 if (client != NULL && client->max_life != 0)
1772 life = min(life, client->max_life);

Why not call ts_min here? And below.

1773 if (server->max_life != 0)
1774 life = min(life, server->max_life);
1775 if (kdc_active_realm->realm_maxlife != 0)
1776 life = min(life, kdc_active_realm->realm_maxlife);
1777
1778 *out_endtime = ts_incr(starttime, life);
1779 }

BTW, I'm on macOS 10.12.6.

--Max

Post by Greg Hudson
If "set the till field in AS-REQ to the epoch" you mean the client is
sending "19700101000000Z" in the till field, this is technically a bug
since the client requested a never-valid ticket, not a ticket valid for
a long time. But it doesn't seem like an important bug, as you say.

Post by Weijun Wang
But if I call kvno with this TGT in ccache, I see a "Ticket expired while getting credentials" error. Maybe somewhere in the KDC that very big endtime is mistakenly treated as a very small number?

The y2038 changes on master are only intended to work up until times
near 2106, so this behavior isn't surprising. I suspect the KDC is
adding the clock skew (300) to 2**32-1 with 32-bit unsigned arithmetic,
producing a small number.

Post by Weijun Wang
The KRB-ERROR reply to TGS-REQ has a strange ctime: 1974-12-10
21:52:23 (UTC).

Apparently we set the KRB-ERROR ctime to the client nonce, for both AS
and TGS replies. I had no idea we did this; it is clearly broken, as
there is no good reason to believe that the client is using its system
time as the nonce. Even going back to RFC 1510, a random nonce is
recommended for KDC requests. I will fix it (by not setting the ctime
field).

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Weijun Wang

Post by Greg Hudson
I guess you have also configured the KDC not to have any ticket lifetime
limits, so the KDC winds up using kdc_infinity (2**32-1) as the ticket
end time.

No. I have "max_life = 10h 0m 0s" for the realm in kdc.conf.

Ah, then this is definitely a regression in the y2038 work, and it is
good that you noticed it.

Post by Weijun Wang
1769 life = ts_delta(until, starttime);
life is now a negative number.
1770
1771 if (client != NULL && client->max_life != 0)
1772 life = min(life, client->max_life);
Why not call ts_min here? And below.

The theory was that ts_min() and related functions are necessary when
operating on timestamps, not intervals, because the goal of the y2038
work was to handle timestamps after 2038, not intervals larger than 2^31
seconds. But that theory obviously breaks down when we compute
intervals between the new kdc_infinity (2^32-1, up from 2^31-1) and the
current time as we do here. I will fix it. I will also look harder at
other uses of krb5_deltat.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev