AS-REQ with till being the epoch

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: AS-REQ with till being the epoch

Weijun Wang
More info:

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

--Max

> On Aug 29, 2017, at 9:38 PM, Weijun Wang <[hidden email]> wrote:
>
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: AS-REQ with till being the epoch

Greg Hudson
In reply to this post by Weijun Wang
On 08/29/2017 09:38 AM, Weijun Wang wrote:
> 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.

> 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.

> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: AS-REQ with till being the epoch

Weijun Wang

> On Aug 29, 2017, at 10:59 PM, Greg Hudson <[hidden email]> wrote:
>
> On 08/29/2017 09:38 AM, Weijun Wang wrote:
>> 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.


>  But it doesn't seem like an important bug, as you say.
>
>> 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?

>
>> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: AS-REQ with till being the epoch

Weijun Wang
In reply to this post by Greg Hudson

> On Aug 29, 2017, at 10:59 PM, Greg Hudson <[hidden email]> wrote:
>
> On 08/29/2017 09:38 AM, Weijun Wang wrote:
>> 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

>
> 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.
>
>> 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.
>
>> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: AS-REQ with till being the epoch

Greg Hudson
On 08/30/2017 10:34 AM, Weijun Wang wrote:
>> 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.

>   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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev