[2878] in Kerberos
variable message lifetime idea
daemon@ATHENA.MIT.EDU (Jim Miller)
Thu Oct 28 21:01:55 1993
From: jim@bilbo.suite.com (Jim Miller)
Date: Thu, 28 Oct 93 19:29:02 -0500
To: kerberos@MIT.EDU
Reply-To: Jim_Miller@suite.com
Looking through the Kerberos 5 code I see that there is a hard-coded 5 minute
clock skew threshhold:
In "krb5_rd_req_decoded" we see...
if (!in_clock_skew(tktauthent->authenticator->ctime)) {
retval = KRB5KRB_AP_ERR_SKEW;
goto cleanup;
}
Where "in_clock_skew" is...
#define in_clock_skew(date) (abs((date)-currenttime) < krb5_clockskew)
and "krb5_clockskew" = 5 minutes
There is similar code in "krb5_rd_safe" and "krb5_rd_priv".
Basically, this code says that the clock on the sending side must be within 5
minutes of the clock on the receiving side. However, there is another way of
interpreting this code.
For a system that doesn't use sockets (imagine a reliable datagram mechanism)
the above code can be interpreted as the datagram lifetime. In other words,
datagrams (messages) must reach their destinations within five minutes, or they
will expire. (Well, the code really tests clockskew + datagram transmission
time, but assume the clocks are pretty close.)
Once you begin to think about things this way, you soon think that it might not
be a bad idea to be able to dynamically specify the message lifetime.
In some environments you could reduce it down to a few seconds. In others, you
could increase it to many tens of minutes (or hours, if you're brave enough).
Here's an idea for doing variable message lifetimes...
Create a new field in the ticket called "message lifetime".
Create a new field in the TGS_REQ message called "message lifetime".
When a client requests a ticket, it will specify the message lifetime. The KDC
will load this value into the "message lifetime" ticket field. The ticket is
returned to the client in the usual manner.
The client uses the ticket in the usual manner.
The recipient of the ticket will notice the "message lifetime" value in the
ticket and will use it, instead of "krb5_clockskew", to test the timeliness of
the message (and any other messages that depend on that ticket).
Pretty simple, but is it a good idea?
I realize that as you increase the lifetime of a message, you increase you're
vulnerablility to "delayed message attacks" (my term, don't know the official
term)
A bad guy captures your message, waits for a while, then sends the message on
to the destination. He didn't modified the message and the message didn't
expire, therefore the destination app considers it valid. However, by delaying
it, the bad guy could still cause damage.
If the message was a request to buy stock and he delayed it for an hour, the
price of the stock could have changed significantly by the time the message
reached the destination app. You would not want to use long lived messages for
this kind of application, but it does illustrate the point. The longer
messages remain valid, the longer a bad guy could delay them.
Even so, I can see the usefulness of a dynamically adjustable message lifetime
in some environments.
Any comments?
Jim_Miller@suite.com
