[krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent

[rmdyer@uncc.edu via RT]

MIT Kerberos Bug Support,

Sam Hartman, Tom Yu

We have projects in our group that we need to get moved forward.  Since it 
looks like the replay packet problem is going to drag out for some time 
I've decided to accept a quick fix from Microsoft.  My Microsoft support 
Kerberos developer in Redmond has hacked up a change to the WinXP 
"kerberos.dll" that includes a "Sleep()" function call at a critial 
location in the code.  He said that this may produce performance problems 
(an improper and poor fix), but that it should solve my issue.  I have 
tested his hacked dll and it does solve the problem.  I no longer get 
replay packets back from the MIT KDC.

I believe the hack will be made into a hotfix, at least my Microsoft tech 
rep said he was pushing it through QFE.  I don't know if it will be a 
public or private fix yet.

I do however anticipate that the issue with MIT's replay cache will be 
resolved, and that Microsoft will work well with a finalized Kerberos RFC 
that both organizations agree on.  I am somewhat unhappy with the response 
so far from both organizations, but I suppose due to the levels at which 
this problem plays out, I shouldn't be too impatient.

It does look like this this is a two part problem.  On the one hand, MIT's 
code does not cache the entire authenticator.  On the other, Microsoft 
really shouldn't be sending two auth requests with the same time in the 
microsecond field (my opinion).  It would be nice to be notified by 
Microsoft/MIT when this issue is taken care of, but I'm not holding my breath.

Thanks for the help,

Rodney

Rodney M. Dyer
x86 Systems Programmer
College of Engineering Computing Services
University of North Carolina at Charlotte
Email rmdyer at uncc.edu
Phone (704)687-3518
Help Desk Line (704)687-3150
FAX (704)687-2352
Office  267 Smith Building


At 10:32 PM 10/8/2002 -0400, you wrote:
>Hi, it seems very likely that you have encountered a bug in replay
>detection.  There are many places to which we might assign blame for
>this one.  These include the MIT krb5 implementation of the replay
>cache, the protocol specification itself, and the Windows krb5 client
>implementation.
>
>Basically, the replay cache in MIT krb5 only stores the tuple of {client
>principal, server principal, time, microseconds}.  If two authenticators
>have identical such tuples, the second is considered to be a replay,
>even if it is different from the first.  This behavior, while not
>explicitly required by RFC 1510 (the specification of the Kerberos v5
>protocol), is strongly suggested by some wording in the RFC.
>
>A complicating factor is the historical behavior of the gettimeofday()
>system call on Unix.  This system call returns monotonically increasing
>microsecond values for multiple calls within the same second, regardless
>of whether the callers are different processes.  Additionally, I believe
>that the PC hardware clock only has a resolution of 55ms.  If Windows is
>using this hardware clock to retrieve microsecond values for
>constructing authenticators, it is quite possible for two authenticators
>for distinct requests to have identical {client principal, servver
>principal, time, microseconds} tuples.
>
>In your packet trace, I see four distinct TGS-REQ messages.  Of
>particular interest are the third and fourth TGS-REQ messages.  The
>third, issued at 14:51:20.868353, asking for a
>cifs/adcsm2.test.uncc.edu at UNCC.EDU ticket, receives a KRB-ERROR due to a
>request for a non-existent service.  The fourth, issued at
>14:51:20.877389, asking for a ticket for krbtgt/TEST.UNCC.EDU at UNCC.EDU,
>receives a replay error.  Note that fewer than 55ms have elapsed between
>these requests.
>
>I cannot verify my hypothesis directly, since I do not have access to
>the session key used to encrypt the authenticators in question.  I can
>observe from the packet trace that they are not identical.  At the very
>least, the checksums inside the authenticators would have to be
>different, as they intend to authenticate requests asking for different
>tickets.
>
>I will attempt to correspond with some contacts at Microsoft to discover
>whether my hypothesis regarding the Windows generation of microseconds
>values for authenticators is likely to be correct.  Meanwhile, I will
>investigate correcting this bug in the MIT implementation, though it
>does seem potentially difficult because of assumptions made in the API
>design.  Also, I have begun discussion in the IETF Kerberos working
>group to discover if there are any security vulnerabilities that might
>be introduced by making the replay detection procedure only compare the
>encrypted authenticators.
>
>---Tom