[283] in Kerberos
More re Kerberos
daemon@TELECOM.MIT.EDU (Steve Miller)
Wed Dec 9 14:23:11 1987
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
(Sorry about the misdirected message re threads et al. Ignore it.
This is the one that was intended-- it may be a duplicate.)
From: ERLANG::MILLER "Steve Miller" 8-DEC-1987 17:36
To: MILLER,MILLER
Subj: Kerberos
Jerry,
First set of your clarifications, agreed -- that is all that I meant.
>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?
>
Almost agreed. There is a subtle difference. The kkds time represents
events, and their sequence, at the Kerberos server(s), and is embedded in the
ticket and used for calculating expiration times. This both gives a more
uniform time reference, since the Kerberos server(s) are centrally managed,
and creates a better partial ordering of events at the server and on the
network. This is useful for debugging and auditing. For example, alternatively,
if the time embedded in the ticket was the workstation time, you could get
anomalous situations where the ticket was granted with a timestamp that
preceeds the time at the Kerberos server when the client or server was
defined (or modified, etc.,) in the Kerberos database.
>[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.]
Fine, as long as it is encrypted. Is it worth the price of encryption?
>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.
True, but not of practical concern. Even a single bit modification to
the ciphertext will change roughly half of the following bits, so
between the timestamp range and changes to the preceeding fields,
all modifications will almost certainly be detected. In the worst
case, checking the range will cause roughly 300/4,000,000,000 undetected
errors, while checking the specific value will be lower by the factor
of 300 (5minutes).
Steve (enjoying a little bit of a diversion).
