[281] in Kerberos
Re: Kerberos timestamps
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Tue Dec 8 16:35:18 1987
To: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: miller%erlang.DEC@decwrl.dec.com (Steve Miller)'s message of 8 Dec 87 14:46
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Steve,
Thanks for your comments. Two clarifications:
> The first, sent from a client to Kerberos and back, is really just a
> bookeeping aid for the client.
According to the protocol specification, the client's timestamp is
returned to the client in the clear, rather than in the
enciphered-in-the-client-key section of the response, so I don't see
that it has any security value. Its only use seems to be as a hint
in matching this response with the corresponding request.
> The Kerberos server COULD detect that
> the client's timestamp is too far out of whack and reject it, but in
> the version of the code I have (year and a half old) it doesn't.
> The second, the time_sec[kkds] (section 7.1.2) on the auth_reply message
> serves two purposes. First, it provides an authenticated timestamp of the
> KDC as a reference.
If the Kerberos server were to check the client timestamp to verify
that it is in range, and then return that timestamp in the
enciphered-in-the-client-key section of the response, wouldn't that
provide an equally good reference?
[Aside: An interesting addition to the protocol could be a field
returned from the Kerberos server to the client that gives the
difference between the client's timestamp and the Kerberos server's
clock. That would allow the client to know just what a server
timestamp would contain (and exactly when the tickets expire), and
also how far different the clocks are, so as to allow reporting
drift.]
Returning the client's original timestamp would also improve the
reliability of modification detection, because the client could then
look for exact match rather than for out-of-range value.
Jerry
