Skip Menu |

Download (untitled) / with headers
text/plain 2.6KiB
From Mon Sep 18 15:20:16 2000
by (8.9.3/8.9.3) with SMTP id PAA06286
for <bugs@RT-11.MIT.EDU>; Mon, 18 Sep 2000 15:20:16 -0400 (EDT)
Received: from by MIT.EDU with SMTP
id AA13527; Mon, 18 Sep 00 15:20:51 EDT
Received: from by
via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU []) with SMTP; 18 Sep 2000 19:20:15 UT
Received: (from nocturne@localhost)
by (8.8.8/8.8.8) id LAA00748;
Sun, 17 Sep 2000 11:21:07 -0400 (EDT)
Message-Id: <>
Date: Sun, 17 Sep 2000 11:21:07 -0400 (EDT)
From: Eric Mumpower <>
To: krb5-bugs@MIT.EDU
Subject: vast clock skew allows negative-life tickets
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 889
>Category: krb5-kdc
>Synopsis: vast clock skew allows negative-life tickets
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Mon Sep 18 15:21:01 EDT 2000
>Originator: Eric Mumpower

Show quoted text
>Release: krb5-1.1.1

System: NetBSD dr-teeth 1.4.1 NetBSD 1.4.1 (TEETH) #1: Fri Sep 15 18:27:55 EDT 2000 nocturne@dr-teeth:/usr/src/sys/arch/i386/compile/TEETH i386

Show quoted text

If a client's clock is skewed a day into the past, it is possible to
obtain tickets with a negative lifetime.

Show quoted text

Arepa kerberos version is MIT 1.1.1 with applied bugfixes for KDC and
buffer overrun vulnerabilities.

When one's clock is skewed about a day into the past, using an
1.1.1+bufpat client against either the Arepa 1.1.1+bufpat KDC _OR_ the
current MIT KDC:

allows one to fetch kerberos tickets that look like this:

Show quoted text
> dr-teeth% klist -c -f -e
> Ticket cache: /tmp/krb5cc_606
> Default principal: nocturne@AREPA.COM
> Valid starting Expires Service principal
> 09/18/00 15:04:26 09/17/00 21:05:18 krbtgt/AREPA.COM@AREPA.COM
> Flags: FI, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32

Show quoted text
> dr-teeth> klist -c -f -e
> Ticket cache: /tmp/krb5cc_606.ath
> Default principal: nocturne@ATHENA.MIT.EDU
> Valid starting Expires Service principal
> 09/18/00 15:04:34 09/17/00 21:05:25 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
> Flags: FI, Etype (skey, tkt): DES cbc mode with CRC-32, etype 28679

Note that these tickets expire 18 hours before they become valid.

Show quoted text
Show quoted text
Date: Fri, 24 Jan 2003 14:49:13 -0500
From: Arun A Tharuvai <aatharuv@MIT.EDU>
To: krb5-bugs@MIT.EDU
Cc: aatharuv@MIT.EDU
Subject: getting tickets that expire before start date
I accidentally tried getting negative length kerberos tickets (both v5
and v4), and it succeeded, giving me krb5 tickets that expired before
they were valid, and krb4 tickets that lasted for exactly 5 minutes.


arun@w20-spare-pokemon:~$ kinit aatharuv -5 -4 -l -100d -r 100d
Password for aatharuv@ATHENA.MIT.EDU:
kinit(v524): Ticket expired getting V5 credentials
arun@w20-spare-pokemon:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: aatharuv@ATHENA.MIT.EDU

Valid starting Expires Service principal
01/24/03 14:47:19 10/16/02 15:47:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
renew until 01/31/03 14:47:19

Kerberos 4 ticket cache: /tmp/tkt1000
Principal: aatharuv@ATHENA.MIT.EDU

Issued Expires Principal
01/24/03 14:47:22 01/24/03 14:52:22 krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU

Arun A Tharuvai
aatharuv (at) mit (dot) edu
aat (at) alum (dot) mit (dot) edu
Subject: vast clock skew allows negative-life tickets
#7063 (discovered by Simo and I) may shed some light on why these huge
negative clock skews get recorded in the first place.

It's a matter of reasonable debate whether an AS request should pay
attention to the recorded clock skew of an existing ticket cache. On
the one side, perhaps every kinit should be a "blank slate"; after all,
the only reason we even look at the existing ticket cache is to figure
out what principal name to use. On the other hand, if the recorded
clock skew is legitimate, it could help get the correct end time for the
new tickets.

Simo suggests that we could look at the resulting ticket and, if its
lifetime varies wildly from the requested lifetime, we could try again.
I don't know if that's worth the complexity. Fixing #7063 should
eliminate most practical causes of this issue, although it can still
arise if there's a big adjustment in the system clock between one kinit
and another.
Subject: vast clock skew allows negative-life tickets
The fix for #7063 should also fix this issue.
Subject: KDC bug remains
Reopening. There is a KDC_ERR_NEVER_VALID error code defined in RFC 4120, and present in
the error tables, but never emitted by the KDC. The KDC should return that error code instead of
producing useless tickets.