[19651] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: AS-REQ with till being the epoch

daemon@ATHENA.MIT.EDU (Weijun Wang)
Wed Aug 30 10:35:20 2017

Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Weijun Wang <weijun.wang@oracle.com>
In-Reply-To: <6ca5c3a9-1b86-739e-5b17-1145c3960bcd@mit.edu>
Date: Wed, 30 Aug 2017 22:34:56 +0800
Message-Id: <EF7312D0-5DF6-46C6-8ADE-6B41D0D89E66@oracle.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu


> On Aug 29, 2017, at 10:59 PM, Greg Hudson <ghudson@mit.edu> 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             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post