[279] in Kerberos
re: timestamps in Kerberos: a question
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Tue Dec 8 13:00:11 1987
To: steiner@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU,
In-Reply-To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>'s message of Tue, 8 Dec 87 11:03:16 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Time stamps as a mechanism to detect replay in the
> user<=>kerberos interchange is unimportant (ie. nothing is gained for
> an intruder to replay a request of reply). The truely interesting case
> in in the user=>server interaction.
A standard technique in checking validity of received, encrypted,
material is that the encrypted data should always contain some item
whose value the recipient can predict; if the recipient doesn't find
that value, there is immediate warning that the receiver and sender
aren't key-synchronized. This is, of course, a probabilistic test
that improves in quality as the predictable data value grows in
bit-length. The time-stamp could serve that function, in which case
the return of the originator's time stamp would be more effective
than inserting the server's time stamp. (Looking for a range of
values isn't as good because it increases the chance that random data
will be accepted.)
In the case of the client-Kerberos interaction, there is another
predictable data value that can serve this function, the name of the
service for which this ticket is intended. If that service name is
at least as long as a timestamp, (and assuming that the client checks
the service name, which check it omits at its grave peril!) then it
can serve the validity-checking function, and the timestamp serves
only to catch certain denial-of-service attacks early in the
ticket-analysis process.
The detectable denial-of-service attack is for an interloper to
intercept the reply and hand the client instead a duplicate of a
reply to an earlier request for the same service but from months ago
when it had a different key. If there is a time-stamp in the
response, a careful client will immediately notice something amiss,
rather than being bewildered when the service rejects the ticket as
indecipherable.
Bottom line for the client-Kerberos interaction: The predictable data
in the enciphered part of the response consists of the service name
and instance, and the time stamp. (The session key and encrypted
ticket are advertised as unpredictable, the realm is filled in by
the server, possibly different from what the client expected, the
lifetime isn't controlled by the client, and even the version number
could be from a range if we are in the middle of a protocol
transition.) Since we don't control how long a service name is
(could be one byte with a null instance), it is probably a good idea
to also have the timestamp for the purpose of authenticating the
encryption key, in which case it ought to be a copy of the client's
timestamp.
Anyone else care to try an analysis? This stuff is tricky and there
are usually at least three different analyses, all of which sound
equally plausible at first. (And all of which may turn out to be
faulty.)
Jerry
