[6083] in Kerberos
error in "krb5_sendto_kdc" logic
daemon@ATHENA.MIT.EDU (Jim Miller)
Tue Oct 31 18:44:20 1995
From: jim@bilbo.suite.com (Jim Miller)
Date: Tue, 31 Oct 95 17:43:20 -0600
To: krb5-bugs@MIT.EDU
Cc: kerberos@MIT.EDU
Reply-To: Jim_Miller@bilbo.suite.com
[This bug report is for KRB5, beta 4, patch level 3. It may also exist in
other versions. I haven't looked.]
There are two "for" loops in "krb5_sendto_kdc", one inside the other. The
inner loop iterates through each KDC in the list returned by
"krb5_locate_kdc". The outer loop increases the value of timeout until
the maximum is reached and the function returns a KRB5_KDC_UNREACH error.
The logic of the outer loop assumes that if none of the KDCs replied, then
it is ok to re-send requests and we'll just wait a little longer.
However, this logic is flawed. The success of the logic depends on the
reason why the inner loop never got a reply.
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.
For this to be a real problem, all KDCs in the list would have to receive
the original requests, and then have their replies lost. Not very likely,
but possible. The likelihood depends on the number of alternative KDCs
and the reasons why replies are getting lost.
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.
Not sure what the best solution is.
Jim_Miller@suite.com
