jtkohl@ATHENA.MIT.EDU (John T Kohl) (07/06/89)
Following is a proposal which I'd like to get comments on before
inclusion in the draft Kerberos V5 protocol specification.
The basic idea here was first proposed by Ted Anderson (CMU ITC).
The problem: long-lived tickets are sometimes desired (e.g. to allow a
long-running computation to utilize Kerberos-mediated services), but the
exposure to stolen credentials (ticket + session key) is greatly
increased by increasing the lifetime of a ticket.
What we think people want is a way to allow long-lived tickets with a
(limited) form of revocability [Current tickets are not revocable,
they just expire].
Here's a way to achieve that which adds only a little state to the KDC
(in the form of a hot-list, described below).
Each ticket will include 4 timestamps:
"auth" time at which the initial password/key based authentication occurred
"from" time after which it can be valid
"till" time after which it can never be valid
"life" delta (a 'local' lifetime), where "life" < "till" - "from"
t(now) means the current time.
If (t(now) > "from") and (t(now) < "from" + "life"), then the ticket may be
valid, subject to the other normal restrictions (i.e. it hasn't expired).
Presenting a valid, renewable ticket (i.e. a RENEWABLE flag is set in
the ticket) to the KDC along with a request to extend the life results
in the server issuing a replacement with "from" (and possibly "life")
adjusted such that the ticket is valid for the minimum of "till"-"from"
and "life" time units from t(now), UNLESS the "auth" time of the ticket
is rejected by the "hot list" (see below).
How this is used for long-life tickets:
1) The client needing a long life ticket requests a renewable long-life
ticket. The KDC returns a ticket with "from" & "till" set as requested,
but "life" set to some site-configured value (e.g. 8 hours).
2) The client remembers the "life" value.
3) The client presents this ticket to the server.
4) If the server is of the sort which refuses continued access after the
expiration of a ticket, then the client needs to present the ticket to
the KDC and request a lifetime extension before "life" expires.
The returned ticket is used to replace the old ticket; the new ticket is
presented to the server, and the Kerberos-mediated service transaction
continues on its merry way.
If the server doesn't want to expire access granted by use of a
now-expired ticket, nothing more need be done. (e.g. current MIT
implementations of TCP-based Kerberos mediated services)
The "hot list":
The "hot list" is maintained on one (or more) of a realm's KDC. It
contains a short list of information which can be used to revoke a
renewable long-lived ticket.
The hot list needs to correlate "auth" times with tickets which are to
be revoked. [The user whose tickets have been stolen may need to contact an
administrator to put his stolen tickets on this list].
When the KDC receives a lifetime-extension request, it verifies
that the ticket presented is not on the hot list. If the ticket is on
the hot list, it logs the attempt, and rejects the request.
Notes:
1) an entry in the hot list need only be maintained in that list until
the maximum site "life" has passed. After this point, any hot-listed
ticket will no longer be valid for obtaining a replacement, as it will
have expired.
2) The hot list should be short and easy to maintain. Some possible
ways to store info:
a) put all tickets from user.inst@realm for service svc.inst
(perhaps from a given host?) issued before some specified
time on the list.
e.g. all tickets for testuser@FOO.EDU to use rcmd.atalanta
issued before 01-Jan-2001 are revoked.
-This has the disadvantage of rendering invalid any other valid
tickets for that service currently held by the user (but the
user can reauthenticate manually).
-It needs the fields <principal,service,time,[host]>
-If an entire ticket cache were stolen, this could lead to a
large number of entries per theft. An alternative would be
to allow wildcards for the service name (e.g. invalidate all
tickets from that user, rather than just the named tickets)
b) put tickets from user.inst@realm authenticated at a specified time
on the list.
e.g. all tickets for testuser@FOO.EDU to use rcmd.atalanta
issued at 08:30:43 01-Jan-2001 are revoked.
-This renders invalid only the stolen ticket, but the
user may still want to use it [tough luck].
-The hot list needs to store <principal,svc,time>
-The user may not be able to determine the correct value for <time>
if the ticket cache were removed upon theft. [An
administrator could intervene and check ticket issue logs, though.]
Possible problems:
Depending on the site-chosen value for the standard 'life', the KDC
could start fielding many more requests that currently required
(assuming that a site might wish to make this lifetime short, and by
policy issue all tickets with the renewal requirement, to reduce the
exposure to things like rebooted machines having readily available
credentials).
The hot-list probably needs duplication, and since it can change often,
this may be opening a database can of worms.chariot@ATHENA.MIT.EDU (Mark Lillibridge) (07/21/89)
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. (By 'successors', I mean the series of tickets which resulted from renewing again and again the original ticket) This is because if I know the session key for the old ticket & have watched its successors being obtained, I can figure out the session key for all of the old ticket's successors, including the one currently in use. Thus, even if I stole a renewable ticket more than the site's maximum lifetime ago, I may still be able to use it. (2) I see no reason to keep unrenewable tickets at all. Since user's have no control over a site's maximum lifetime, they have no choice but to always ask for renewable tickets if they want a minimum (renewable) lifetime. This would remove the need for a RENEWABLE flag & simplify the code. (3) Limits on what kinds of tickets could be acquired were not mentioned in the proposal but I would like to propose the following: - TGT's can be acquired with any from and till values given only that from<till. The actual lifetime of the TGT is the minimum of the requested value and the site minimum. Note that some sites may want to have a smaller minimum lifetime for TGT's than normal tickets. - Normal tickets can be requested using a TGT with from time f and till time t only with from values >=f and till values <= t. I.e., no ticket can be obtained from a TGT which gives authentication beyond the authentication interval of the TGT. Lifetime is treated as for TGT although possibly with a different site lifetime minimum. - 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 would protect against someone getting a very long lived ticket while you are momentarily away from your workstation and using it to wreck havoc later on. (4) Note that if the hotlist is kept on only one KDC and the net becomes partitioned, splitting a slave KDC off from the KDC with the hotlist, that slave KDC is no longer able to renew tickets. As this is a major loss of functionality, esp. if all tickets are renewable, I believe copies of the hotlist should be maintained on all KDC's. - Mark Lillibridge MIT Project Athena
wesommer@ATHENA.MIT.EDU (Bill Sommerfeld) (07/21/89)
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
saltzer@SRC.DEC.COM (Jerry Saltzer) (07/22/89)
Mark says,
"(2) I see no reason to keep unrenewable tickets at all. Since
user's have no control over a site's maximum lifetime, they have no
choice but to always ask for renewable tickets if they want a minimum
(renewable) lifetime. This would remove the need for a RENEWABLE flag &
simplify the code."
I agree. Rather than having a flag on RENEWABILITY, can't you
just issue a ticket with FROM = now, and TILL = now+life? What
we really have here is an opportunity for a more flexible set of
site defaults. The first settable default is life, probably set
to the current 8 hours. The second settable default is the amount
by which TILL normally exceeds FROM. That could also be set
to 8 hours, or 24 hours, or whatever seems plausible for the site.
This proposal emphasizes the usefulness of a (prospective) ticket
management utility that keeps a little window in some corner showing
what tickets you have and how long they have to live. The same utility
would be responsible for waking up just before the deadline and
automatically renewing any renewable tickets.
Jerrybcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman) (07/22/89)
Note that the message describing long-lived revocable tickets was
dated 5 July. For some reason it got stuck in a mail queue until just
a few days ago. The proposal has been revised since then. The
present plan is as follows:
We can support the features described in the original message by
simply adding a new field renew_till which only appears in renewable
tickets. A ticket can be renewed before its expiration by requesting
renewal from the KDC. The new lifetime (which is really the endtime -
the starttime) will be the minimum of the old lifetime, the requested
lifetime, and the time remaining till the renew_till field expires.
The hot list can be implemented in the same manner described in the
original message.
Here are the meanings of the variables used to describe the necessary
logic that would be implemented at the KDC.
current = time read from system clock when we started
processing this request
starttime = start time
endtime = end time
renew_till = renew_till field
authtime = time of initial authentication
life = a temporary variable
req_life = requested life from the request
(new) is the renewal, (old) is the ticket presented to the TGS
And here is the logic for generating the new values:
renew_till(new) = renew_till(old);
authtime(new) = authtime(old);
life = endtime(old) - starttime(old);
starttime(new) = current_time;
endtime(new) = MIN(starttime(new) + life, starttime(new)
+ req_life, renew_till)
The authtime would also be checked against the hot list.
Now to answer some of the questions raised in responses to the original
proposal:
We had already decided to add an authtime field. Since it is the
authtime that gets added to the hot list, all derivative tickets
(i.e. the successors that Mark describes) become invalid as well.
Just as a site can impose a maximum ticket lifetime, it can also
impose a maximum renewal lifetime. Typically, this limit would be
greater. Given this, I don't understand Mark's premise for making all
tickets renewable. As to whether we need both renewable and
non-renewable tickets, Mark has a point in that a non-renewable ticket
can be thought of as being renewable, but with a renew_till equal to
it's endtime. The majority of tickets, however, will not be renewable
(one argument is that most are for service besides the TGS). I think
explicitly making the distinction is appropriate.
As to limits on the life that may be requested, and where the checks
occur, this has already been discussed on the krb-protocol list. I
think the solution was that the KDC can set limits on the tickets it
issues, but that the end service can set more restrictive limits as
well. Additionally, the limits checked at the end service may be
based on authtime, and not just the starttime for the ticket. Thus,
an end service can refuse to accept tickets based on a renewed tgt if
the original authentication took place too long ago.
~ Cliff
rsalz@BBN.COM (Rich Salz) (07/22/89)
>Send mail if ticket lifetime greatar than say 7 days
Ick. I'd hate to see this kind of policy put into a protocol...
I want to be able to have non-revocable infinite tickets; my client and
server will conspire so that they won't be used for more than a single
transaction that lasts for 30 days. Is this possible?
/r$saltzer@SRC.DEC.COM (Jerry Saltzer) (07/22/89)
John suggests,
"1) an entry in the hot list need only be maintained in that list until
the maximum site "life" has passed. After this point, any hot-listed
ticket will no longer be valid for obtaining a replacement, as it will
have expired.
2) The hot list should be short and easy to maintain."
The initial, zero-order implementation could be just to hold the
user's name and refuse to renew any tickets for that user
until LIFE has passed. That would be a little inconvenient for
the user, but on the other hand, the use of revocation and
hot lists would probably be a very rare event; polishing to
improve the granularity of revocation is something that can
be left as a future exercise.
Jerry
chariot@ATHENA.MIT.EDU (Mark Lillibridge) (07/25/89)
> Date: Fri, 21 Jul 89 11:21:58 PDT > From: bcn@june.cs.washington.edu (Clifford Neuman) > > ... > > We can support the features described in the original message by > simply adding a new field renew_till which only appears in renewable > tickets. A ticket can be renewed before its expiration by requesting > renewal from the KDC. The new lifetime (which is really the endtime - > the starttime) will be the minimum of the old lifetime, the requested > lifetime, and the time remaining till the renew_till field expires. > The hot list can be implemented in the same manner described in the > original message. > > ... > > And here is the logic for generating the new values: > > renew_till(new) = renew_till(old); > authtime(new) = authtime(old); > > life = endtime(old) - starttime(old); > > starttime(new) = current_time; > > endtime(new) = MIN(starttime(new) + life, starttime(new) > + req_life, renew_till) > > The authtime would also be checked against the hot list. This proposal is almost identical to the previous one. To see this, make the following substitutions: renew_till -> till starttime -> from endtime - starttime -> life authtime -> auth I.e., instead of storing the lifetime of the ticket, we are storing from+life. This is not a very major change. The logic to calculate the new lifetime is different though. The inclusion of starttime(new)+life in the MIN function in the assignment to endtime(new) causes all successor tickets to have a lifetime at most that of their precessor tickets. This is a good feature because it means that when I get a long ticket I can ensure that I can revoke it in a chosen amount of time. Note that I would add the site_maximum lifetime (if any) to that MIN function. > Just as a site can impose a maximum ticket lifetime, it can also > impose a maximum renewal lifetime. Typically, this limit would be > greater. Given this, I don't understand Mark's premise for making all > tickets renewable. As to whether we need both renewable and > non-renewable tickets, Mark has a point in that a non-renewable ticket > can be thought of as being renewable, but with a renew_till equal to > it's endtime. The majority of tickets, however, will not be renewable > (one argument is that most are for service besides the TGS). I think > explicitly making the distinction is appropriate. The reasoning for making all tickets renewable is as follows. Suppose I wish to request a 10 hour ticket. Now, if I ask for a non-renewable ticket I may get one good for only 8 hours. (Due to the site maximum lifetime...) Thus, in order to be guarenteed one for 10 hours, I must ask for a renewable ticket. (this is assuming I don't want to waste an extra trip trying for a non-renewable ticket) Given this, why would I ever ask for a non-renewable ticket? (i.e., what is a non-renewable ticket better at than a renewable ticket?) Likewise, since all applications must be able to deal both with renewable & non-renewable tickets, there is no cost for asking just for renewable tickets. (They must deal with both because I the user may obtain a long lived ticket for them then destroy my TGT) Thus, by this reasoning, non-renewable tickets are useless & should be discarded. Note that non-TGT tickets are exactly the ones most in need of renewal. This is because they are the ones needed by a batch job. (I have no intention of leaving a TGT around for a batch job to use...) > As to limits on the life that may be requested, and where the checks > occur, this has already been discussed on the krb-protocol list. I > think the solution was that the KDC can set limits on the tickets it > issues, but that the end service can set more restrictive limits as > well. Additionally, the limits checked at the end service may be > based on authtime, and not just the starttime for the ticket. Thus, > an end service can refuse to accept tickets based on a renewed tgt if > the original authentication took place too long ago. The operative word here is "can". If you can request arbitary from and renew_till fields, we have lost a lot of security. Consider for instance if I temporily get a copy of your 8 hour TGT. I now request 8 hour tickets forward dated for 8 hours of each day for the next year. Now, I can act as you for the entire next year. No longer is the effects of stealing a ticket limited to the lifetime of that ticket. Similar examples exist with infinite lifetimes from finite lifetime TGT's. In order to prevent serious problems like these, we need a minimum set of restrictions on possible from, till, lifetime fields. My proposal was a first cut at these. I have noticed at least one problem with it so far. This is the fact that we can not premit arbitary from fields. This is due to the need to change kerberos master keys every so often. This also implies that all sites must have a maximum lifetime if they ever intend to change their kerberos master key. - Mark Lillibridge MIT Project Athena
chariot@ATHENA.MIT.EDU (Mark Lillibridge) (07/25/89)
> From: Rich Salz <rsalz@bbn.com> > Date: Fri, 21 Jul 89 14:24:15 EDT > > >Send mail if ticket lifetime greater than say 7 days > Ick. I'd hate to see this kind of policy put into a protocol... Err... I really meant that as a suggested implementation feature as opposed to protocol. Even then, it was only a suggestion. Since getting a very long ticket is a big security risk, it should be brought to the user's or to the administrator's attention. > I want to be able to have non-revocable infinite tickets; my client and > server will conspire so that they won't be used for more than a single > transaction that lasts for 30 days. Is this possible? My proposal allowed this although the above 'feature' would send you mail warning you every time you obtained such tickets. Out of curiosity, what application did you have in mind? - Mark Lillibridge MIT Project Athena
rsalz@BBN.COM (Rich Salz) (07/25/89)
>Since getting a very long ticket is a big security risk, it should be >brought to the user's or to the administrator's attention. Perhaps. But not as a feature of the protocol. In a large, automated distributed system such things as mail to bring to attention are bad. I can imagine a database application where the DB server has enough state so that a ticket is used only once, or a number-cruncher where I wanna factor a 500-digit possible prime, or run a simulation of a complex chemical reaction... whatever. I understand that things like long tickets are scarey, but then so is the ability to be able to do "cat >/vmunix". /r$