[6086] in Kerberos
Re: error in "krb5_sendto_kdc" logic
daemon@ATHENA.MIT.EDU (Ed Phillips)
Wed Nov 1 08:44:39 1995
Date: Wed, 1 Nov 1995 08:43:28 -0500 (EST)
From: Ed Phillips <flaregun@UDel.Edu>
To: Jim_Miller@bilbo.suite.com
Cc: krb5-bugs@MIT.EDU, kerberos@MIT.EDU
In-Reply-To: <9510312343.AA13383@bilbo.suite.com>
On Tue, 31 Oct 1995, Jim Miller wrote:
>
> [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.
The KDC used to just retransmit the same response (or at least
that's what the KDC's log would indicate). I don't know when this would
have changed. I don't see anything wrong with having the KDC retransmit
the response to the same requestor.
>
> 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
>
+-------------------------------------------------------------------------+
| Ed Phillips <flaregun@udel.edu> University of Delaware (302) 831-6082 |
| Jr Systems Programmer, Network and Systems Services, Info. Technologies |
| Public key footprint: 1C D4 AC C2 A3 D5 97 AA DB 3B D8 85 88 E7 40 B8 |
| Finger flaregun@udel.edu for PGP public key |
+-------------------------------------------------------------------------+
