[762] in Kerberos
Re: Proposal for long-lived revocable tickets.
daemon@TELECOM.MIT.EDU (Bill Sommerfeld)
Fri Jul 21 12:58:01 1989
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: chariot@ATHENA.MIT.EDU
Cc: jtkohl@ATHENA.MIT.EDU, Kerberos@ATHENA.MIT.EDU,
In-Reply-To: Mark Lillibridge's message of Fri, 21 Jul 89 12:28:44 -0400,
Date: Fri, 21 Jul 89 12:28:44 -0400
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
Reply-To: chariot@ATHENA.MIT.EDU
Address: EC Bemis 515, 3 Ames Street, Cambridge, MA 02139
Phone: (617) 225-6554
Comments on John's proposal:
(1) Note that under the proposed system, old renewable tickets
which have expired but have a 'successor' which has not expired must be
kept secret.
Wrong; the ticket itself never has to be kept secret, and it is sent
over the wire "in the clear"; only the associated session key must be kept secret.
- I would recommend that whenever a TGT with a lifetime
greater than say 7 days is requested, a mail notice be sent to the
principal of the ticket if it is a user telling that a TGT has been
requested for X time on host X and giving explicit instructions on how
to revoke it.
This is an implementation issue, and assumes that there is a sensible
mapping from kerberos names to mail names.
When renewing a ticket, or using a ticket-granting-ticket, if the
client identity is from the local realm, does the KDC have to check
that the user in question still exists in the realm's database?
If so, then some forms of revocation short of a hotlist are possible;
however, if the kerberos database is replicated, but not strongly
consistent, I can imagine a number of unusual failure modes going on
for users which have just been added to the database.
- Bill