[6087] in Kerberos
Re: error in "krb5_sendto_kdc" logic
daemon@ATHENA.MIT.EDU (Jonathan Kamens)
Wed Nov 1 10:08:20 1995
To: kerberos@MIT.EDU
Date: 1 Nov 1995 14:48:19 GMT
From: jik@jik.datasrv.co.il (Jonathan Kamens)
In article <9510312343.AA13383@bilbo.suite.com>, jim@bilbo.suite.com (Jim Miller) writes:
|> If the client's KDC request never reached the KDC, then it is ok for the
|> client to re-send the request. However, if the request *did* reach the
|> KDC but the KDC's reply got lost, then it is not ok for the client to
|> re-send the request because the second attempt (bit for bit identical to
|> the first) would just be discarded by the KDC as a replayed kdc message.
That's not true -- the KDC (at least the one that MIT distributes, and any KDC
sold or distributed by someone besides MIT that doesn't have this feature is
arguably broken) has code in it whose specific purpose is to avoid the problem
you describe.
In particular, the KDC caches in a lookaside buffer the actual on-the-wire
contents of recent requests, as well as the responses that were sent to them.
Each time it gets a new request, it checks to see if it exactly matches a
request in the lookaside buffer; if it does, then the exact same response (as
cached in the lookaside buffer) is sent.
To understand why the lookaside buffer caches the exact contents of requests
and the exact responses to them, you have to understand the purpose of the
replay cache. The replay cache prevents two different kinds of attack: (1)
User sends a request to the KDC, attacker intercepts the request and sends it
to the server again, over a different TCP stream, to get the same response
(e.g., to do a cryptanalysis attack on it); (2) Attacker sends the same
request, slightly modified, to the KDC many times in a short period of time,
in order to obtain responses that differ in their contents in only a few
bytes, since cryptanalysis attacks are easier when multiple chunks of
ciphertext with known similarities and differences are available.
Now, if the KDC were to allow multiple identical requests from a client in a
short period of time and respond to all of them with newly formatted
responses, rather than rejecting them as replays, then it would be allowing
attack (2) to occur. However, if it verifies that the request is precisely
the same as a previous recent request, and then sends exactly the same
response (bit-for-bit) as it sent to the previous one, then it isn't allowing
(2), since the attacker can't obtain multiple responses with known
similarities and differences. That's why a lookaside buffer is used.
You suggested this:
|> To correctly handle this case, you need to send additional information
|> when you re-send ticket requests. Something so the KDCs can distinguish
|> re-tries from previous attempts or replay attacks. However, this may
|> create backwards incompatibilities.
Your suggestion is vulnerable as I've described above, because if the KDC
isn't keeping a lookaside buffer, it's going to have to reformulate its
response for each new request from the client, which means that the attacker
will get multiple responses with known similarities and differences.
Furthermore, if a legitimate client can send "additional information" to
enable the KDC to distinguish between a previous attempt and a replay attack,
then what's to stop an attacker to send the same "additional information" in
to enable him to do a replay on a request he captured from another user?
