[3994] in Kerberos
K V replay cache problem
daemon@ATHENA.MIT.EDU (Charles L. Athey III)
Wed Oct 5 13:32:06 1994
Date: Wed, 5 Oct 94 10:12:37 PDT
From: athey@lorien.ocf.llnl.gov (Charles L. Athey III)
To: krb5-bugs@MIT.EDU, kerberos@MIT.EDU
Cc: auth-pilot@es.net
We have found a problem with the backward compatibility of Kerberos V with
Kerberos IV. Specifically, a Kerberos IV client making a request to the
backwardward compatibility port of a Kerberos V KDC can get an incorrect
ticket back. The version IV request has no information in it identifying the
requestor. The version V KDC places this request and the response into the
replay cache. A version IV response is generated specifically for the IP address
of the requestor. If a subsequent request for the same service is received
within 1 second of the first request, but from a different requestor/IP address
the version V KDC notes that the request is identically to the previous one
and sends the previous response--since the new requestor is at a different
IP address the ticket it receives is not valid for it. This, unfortunately,
is not as unlikely a situation as one might think. We have a 256 node Meiko
running Solaris 2.3. When using Kerberized NFS, which uses the K IV protocol,
a TGT for each node must be requested when a user logs in. Thus, 256
requests for a TGT are generated, most within 1 second. Only one of the
nodes, the first to make the request, gets a valid TGT--all the rest of the
nodes get the first requestor's TGT which is not valid for them.
We solved this by disabling the replay cache for version IV requests. Another
possible solution would be to add the requestor's address to the replay
cache entry in addition to the actual request.
Chuck Athey
ESNet Authentication Pilot Project
Lawrence Livermore Nat'l. Lab.
athey@llnl.gov
