Skip Menu |
 

Download (untitled) / with headers
text/plain 4.8KiB
From rmdyer@uncc.edu Thu Aug 29 16:46:31 2002
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by krbdev.mit.edu (8.9.3) with ESMTP
id QAA04556; Thu, 29 Aug 2002 16:46:31 -0400 (EDT)
Received: from ms-sm2.uncc.edu (ms-sm2.uncc.edu [152.15.11.175])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA20280
for <krb5-bugs@mit.edu>; Thu, 29 Aug 2002 16:46:30 -0400 (EDT)
Received: from mws384.uncc.edu (mws384.uncc.edu [152.15.13.147])
by ms-sm2.uncc.edu (8.10.2+Sun/8.9.0) with ESMTP id g7TKkT406799
for <krb5-bugs@mit.edu>; Thu, 29 Aug 2002 16:46:29 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020829161551.01375790@coeimap2.uncc.edu>
X-Sender: rmdyer@coeimap2.uncc.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 29 Aug 2002 16:46:26 -0400
To: krb5-bugs@mit.edu
From: Rodney M Dyer <rmdyer@uncc.edu>
Subject: Possible Kerberos Server Bug?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

We are experiencing an interoperability issue with Microsoft Windows XP Pro
and a MIT Kerberos 1.2.2 KDC server. We have setup a cross-realm trust
between two domains. This works fine. We are able to authenticate to
XP/Active Directory domain and the MIT kerberos realm just fine. The
problem we are having is that the XP machine isn't always allowing us
access to the AD domain shares.

I have been in contact with Microsoft support on this issue for quite some
time. Microsoft's support rep put me in contact with their Kerberos
developer group in Redmond. The Redmond support has checked and rechecked
the kerberos code on their side. The've made some changes to their
"kerberos.dll" that have been worse, or better, but the problem still persists.

We did some network traffic sniffs from both the client and the server
sides. We've found something curious that we think may point the problem
to MIT's developer group. In the network capture, we found return packets
from the MIT server with the phrase "Request is a replay.". It seems that
the MIT server is responding to the client, suggesting that it sent
redundant packets. We know from the captures that we didn't send two
redundant packets, and the MIT server never received two.

We also see messages in the kerberos logs such as...

Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
PROCESS_TGS: authtime 0, <unknown client> for
krbtgt/TEST.UNCC.EDU@UNCC.EDU, Request is a replay

... Why is the client unknown in this log message? Why is the authtime zero?

Here is a bit more of the log...

Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): AS_REQ 152.15.11.60(88):
NEEDED_PREAUTH: trng07@UNCC.EDU for krbtgt/UNCC.EDU@UNCC.EDU, Additional
pre-authentication required
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): AS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/UNCC.EDU@UNCC.EDU
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/TEST.UNCC.EDU@UNCC.EDU
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
UNKNOWN_SERVER: authtime 1030637982, trng07@UNCC.EDU for
cifs/adcsm2.test.uncc.edu@UNCC.EDU, Server not found in Kerberos database
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
PROCESS_TGS: authtime 0, <unknown client> for
krbtgt/TEST.UNCC.EDU@UNCC.EDU, Request is a replay
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
UNKNOWN_SERVER: authtime 1030637982, trng07@UNCC.EDU for
cifs/adcsm2.test.uncc.edu@UNCC.EDU, Server not found in Kerberos database
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/TEST.UNCC.EDU@UNCC.EDU

The only thing sitting between the client and the server are a couple of
switched hubs. Microsoft seems to indicate that this replay packet is the
problem. I'm not sure I agree, but I would like some second
opinions. This appears to be some strange time issue because it doesn't
always fail. Most of the time we get access to the Microsoft AD shares
correctly. But, it does fail often enough that it can't be used in a
production capacity. Everytime it fails we see a "replay" packet message.

We built a couple of MIT Kerberos test servers. One server was 1.2.4, the
other was 1.2.2. We put them on the same switched hub as the XP client and
AD server. We didn't see any problems then. What is going on?

Is this a kerberos bug?

MIT Kerberos server is a Sun workstation running Solaris 8, MIT Kerberos 5
v1.2.2
Microsoft Windows XP Pro. on a Gateway PIII

Help is appreciated. Thanks,

Rodney

Rodney M. Dyer
PC Systems Programmer
College of Engineering Computing Services
University of North Carolina at Charlotte
Email rmdyer@uncc.edu
Phone (704)687-3518
Help Desk Line (704)687-3150
FAX (704)687-2352
Office 267 Smith Building
Download (untitled) / with headers
text/plain 4.8KiB
From rmdyer@uncc.edu Tue Sep 3 11:25:37 2002
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by krbdev.mit.edu (8.9.3) with ESMTP
id LAA03008; Tue, 3 Sep 2002 11:25:37 -0400 (EDT)
Received: from ms-sm2.uncc.edu (ms-sm2.uncc.edu [152.15.11.175])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA19904
for <krb5-bugs@mit.edu>; Tue, 3 Sep 2002 11:25:36 -0400 (EDT)
Received: from mws384.uncc.edu (mws384.uncc.edu [152.15.13.147])
by ms-sm2.uncc.edu (8.10.2+Sun/8.9.0) with ESMTP id g83FPW416921
for <krb5-bugs@mit.edu>; Tue, 3 Sep 2002 11:25:32 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020903112528.01f48010@coeimap2.uncc.edu>
X-Sender: rmdyer@coeimap2.uncc.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 03 Sep 2002 11:25:31 -0400
To: krb5-bugs@mit.edu
From: Rodney M Dyer <rmdyer@uncc.edu>
Subject: Possible Kerberos Server Bug?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

We are experiencing an interoperability issue with Microsoft Windows XP Pro
and a MIT Kerberos 1.2.2 KDC server. We have setup a cross-realm trust
between two domains. This works fine. We are able to authenticate to
XP/Active Directory domain and the MIT kerberos realm just fine. The
problem we are having is that the XP machine isn't always allowing us
access to the AD domain shares.

I have been in contact with Microsoft support on this issue for quite some
time. Microsoft's support rep put me in contact with their Kerberos
developer group in Redmond. The Redmond support has checked and rechecked
the kerberos code on their side. The've made some changes to their
"kerberos.dll" that have been worse, or better, but the problem still persists.

We did some network traffic sniffs from both the client and the server
sides. We've found something curious that we think may point the problem
to MIT's developer group. In the network capture, we found return packets
from the MIT server with the phrase "Request is a replay.". It seems that
the MIT server is responding to the client, suggesting that it sent
redundant packets. We know from the captures that we didn't send two
redundant packets, and the MIT server never received two.

We also see messages in the kerberos logs such as...

Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
PROCESS_TGS: authtime 0, <unknown client> for
krbtgt/TEST.UNCC.EDU@UNCC.EDU, Request is a replay

... Why is the client unknown in this log message? Why is the authtime zero?

Here is a bit more of the log...

Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): AS_REQ 152.15.11.60(88):
NEEDED_PREAUTH: trng07@UNCC.EDU for krbtgt/UNCC.EDU@UNCC.EDU, Additional
pre-authentication required
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): AS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/UNCC.EDU@UNCC.EDU
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/TEST.UNCC.EDU@UNCC.EDU
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
UNKNOWN_SERVER: authtime 1030637982, trng07@UNCC.EDU for
cifs/adcsm2.test.uncc.edu@UNCC.EDU, Server not found in Kerberos database
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
PROCESS_TGS: authtime 0, <unknown client> for
krbtgt/TEST.UNCC.EDU@UNCC.EDU, Request is a replay
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
UNKNOWN_SERVER: authtime 1030637982, trng07@UNCC.EDU for
cifs/adcsm2.test.uncc.edu@UNCC.EDU, Server not found in Kerberos database
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/TEST.UNCC.EDU@UNCC.EDU

The only thing sitting between the client and the server are a couple of
switched hubs. Microsoft seems to indicate that this replay packet is the
problem. I'm not sure I agree, but I would like some second
opinions. This appears to be some strange time issue because it doesn't
always fail. Most of the time we get access to the Microsoft AD shares
correctly. But, it does fail often enough that it can't be used in a
production capacity. Everytime it fails we see a "replay" packet message.

We built a couple of MIT Kerberos test servers. One server was 1.2.4, the
other was 1.2.2. We put them on the same switched hub as the XP client and
AD server. We didn't see any problems then. What is going on?

Is this a kerberos bug?

MIT Kerberos server is a Sun workstation running Solaris 8, MIT Kerberos 5
v1.2.2
Microsoft Windows XP Pro. on a Gateway PIII

Help is appreciated. Thanks,

Rodney

Rodney M. Dyer
PC Systems Programmer
College of Engineering Computing Services
University of North Carolina at Charlotte
Email rmdyer@uncc.edu
Phone (704)687-3518
Help Desk Line (704)687-3150
FAX (704)687-2352
Office 267 Smith Building
To: rt@krbdev.mit.edu
Subject: [krbdev.mit.edu #1168] Replay with MIT KDC
Date: Wed, 11 Sep 2002 17:23:10 -0400 (EDT)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:


Please run the network traces on the MIT KDC itself using tcpdump or
snoop capturing the full packets and confirming you are not seeing
replays. There is some chance that your network equiment is
malfunctioning. As such you should look for the replays on the KDC
machine itself.

Note that for network level replays you should not see that error but
we may have a bug. But let's determine if you have network level
replays then go from there.
Date: Thu, 12 Sep 2002 17:33:41 -0400
To: rt-comment@krbdev.mit.edu
From: Rodney M Dyer <rmdyer@uncc.edu>
Subject: Re: [krbdev.mit.edu #1168] Replay with MIT KDC
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB
Mr. Hartman,

Thank you for your reply. Since I sent the email about the problem there
have been some developments. I don't want to go into details except to say
that we have verified that MIT Kerberos 1.2.2 definitely has a problem with
Microsoft Windows XP Pro. We are switching to 1.2.4 which seems to solve
the problems. Microsoft agreed with this assesment and we are proceeding
to close our support case with them. Unless you want further specific
information about the problem you can assume we have fixed this problem,
and I require no further assistance from you.

Thanks,

Rodney

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


At 05:23 PM 9/11/2002 -0400, you wrote:


Show quoted text
>Please run the network traces on the MIT KDC itself using tcpdump or
>snoop capturing the full packets and confirming you are not seeing
>replays. There is some chance that your network equiment is
>malfunctioning. As such you should look for the replays on the KDC
>machine itself.
>
>Note that for network level replays you should not see that error but
>we may have a bug. But let's determine if you have network level
>replays then go from there.
Date: Mon, 30 Sep 2002 15:45:03 -0400
To: krb5-bugs@mit.edu
From: Rodney M Dyer <rmdyer@uncc.edu>
Subject: Possible Kerberos Server Bug?
Download (untitled) / with headers
text/plain 4.7KiB
Hi,

This email is another request for help on the issue discussed below. In
the past I sent this mail, got a reply, then turned down help based on the
fact that we thought we had the problem solved. The problem has now
resurfaced with MIT K5 v1.2.6. I would very much appreciate any help you
can offer.

Original problem...

We are experiencing an interoperability issue with Microsoft Windows XP Pro
and a MIT Kerberos 1.2.2 (and 1.2.6, possibly 1.2.4) KDC server. We have
setup a cross-realm trust between two kerberos realms. This works
fine. We are able to authenticate to XP/Active Directory domain and the
MIT kerberos realm just fine. The problem we are having is that the XP
machine isn't always allowing us access to the AD domain shares.

I have been in contact with Microsoft support on this issue for quite some
time. Microsoft's support rep put me in contact with their Kerberos
developer group in Redmond. The Redmond support has checked and rechecked
the kerberos code on their side. The've made some changes to their
"kerberos.dll" that have been worse, or better, but the problem still persists.

We did some network traffic sniffs from both the client and the server
sides. We've found something curious that we think may point the problem
to MIT's developer group. In the network capture, we found return packets
from the MIT server with the phrase "Request is a replay.". It seems that
the MIT server is responding to the client, suggesting that it sent
redundant packets. We know from the captures that we didn't send two
redundant packets, and the MIT server never received two.

We also see messages in the kerberos logs such as...

Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
PROCESS_TGS: authtime 0, <unknown client> for
krbtgt/TEST.UNCC.EDU@UNCC.EDU, Request is a replay

... Why is the client unknown in this log message? Why is the authtime zero?

Here is a bit more of the log...

Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): AS_REQ 152.15.11.60(88):
NEEDED_PREAUTH: trng07@UNCC.EDU for krbtgt/UNCC.EDU@UNCC.EDU, Additional
pre-authentication required
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): AS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/UNCC.EDU@UNCC.EDU
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/TEST.UNCC.EDU@UNCC.EDU
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
UNKNOWN_SERVER: authtime 1030637982, trng07@UNCC.EDU for
cifs/adcsm2.test.uncc.edu@UNCC.EDU, Server not found in Kerberos database
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
PROCESS_TGS: authtime 0, <unknown client> for
krbtgt/TEST.UNCC.EDU@UNCC.EDU, Request is a replay
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
UNKNOWN_SERVER: authtime 1030637982, trng07@UNCC.EDU for
cifs/adcsm2.test.uncc.edu@UNCC.EDU, Server not found in Kerberos database
Aug 29 12:19:42 kdc-sm2 krb5kdc[8093](info): TGS_REQ 152.15.11.60(88):
ISSUE: authtime 1030637982, trng07@UNCC.EDU for krbtgt/TEST.UNCC.EDU@UNCC.EDU

The only thing sitting between the client and the server are a couple of
switched hubs. Microsoft seems to indicate that this replay packet is the
problem. I'm not sure I agree, but I would like some second
opinions. This appears to be some strange time issue because it doesn't
always fail. Most of the time we get access to the Microsoft AD shares
correctly. But, it does fail often enough that it can't be used in a
production capacity. Everytime it fails we see a "replay" packet message.

We built a couple of MIT Kerberos test servers. One server was 1.2.4, the
other was 1.2.2. We put them on the same switched hub as the XP client and
AD server. We didn't see any problems then. What is going on?

Current situation...

With Microsoft's latest private test "kerberos.dll" that they have been
working on for me, I have not been able to reproduce the problem with MIT
KDC v1.2.4, but I have been able to produce the problem with v1.2.6. Both
of the MIT test servers are in the same room, and on the same switched hub
as the XP client.

I am including the Solaris snoop capture binary from the 1.2.6 kdc that
shows the "replay packet" that seems to be the cause of the problem.

Is this a kerberos bug?

MIT Kerberos server is a Sun workstation running Solaris 8, MIT Kerberos 5
v1.2.2, v1.2.6
Microsoft Windows XP Pro. on a Gateway PIII

Help is appreciated. Thanks,

Rodney

Rodney M. Dyer
PC Systems Programmer
College of Engineering Computing Services
University of North Carolina at Charlotte
Email rmdyer@uncc.edu
Phone (704)687-3518
Help Desk Line (704)687-3150
FAX (704)687-2352
Office 267 Smith Building
Download snoop_kdc_1_2_6.bin
application/octet-stream 5.6KiB

Message body not shown because it is not plain text.

To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent
From: Sam Hartman <hartmans@mit.edu>
Date: Fri, 04 Oct 2002 00:05:59 -0400
RT-Send-Cc:

Hi. Could you please confirm that the attached trace was taken on the
KDC machine and includes all Kerberos packets either from the client
machine or involving the principal trng7 either from that client or
any other client during the period of the trace?


The reason that the client and authtime are zero on replay packets is
that the KDC does not parse the request enough to find out what the
client name is before determining it is a replay. At the point it
determines the request is a replay it should stop processing the
request and return the cached response.

However since you seem to be seeing an error packet, that may not be
happening.



I do see a replay error in the trace and I'm not really sure what the
KDC thinks it is a replay of.

It's also generating an error not returning a cached response.

Thanks for the trace; we should look at it in the next few days and
see if we can come up with any additional data.

For the benefit of others I'm attaching a decoding of the trace to the
ticket.
Download (untitled) / with headers
text/plain 24.2KiB

Message body is not shown because sender requested not to inline it.

Date: Fri, 04 Oct 2002 12:55:25 -0400
To: rt-comment@krbdev.mit.edu
From: Rodney M Dyer <rmdyer@uncc.edu>
Subject: Re: [krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB
Mr. Hartman,

Yes, the MIT kdc is a Solaris 8 machine. We used the Solaris snoop process
to capture the packets on the same box. The capture does include all
kerberos client packets involving the trng07 principle.

Windows XP Pro Client (mws215.uncc.edu)
Sun Solaris 8 Server running MIT KDC v1.2.6 (ws470.uncc.edu)

Rodney

At 12:06 AM 10/4/2002 -0400, you wrote:

Show quoted text
>Hi. Could you please confirm that the attached trace was taken on the
>KDC machine and includes all Kerberos packets either from the client
>machine or involving the principal trng7 either from that client or
>any other client during the period of the trace?
>
>
>The reason that the client and authtime are zero on replay packets is
>that the KDC does not parse the request enough to find out what the
>client name is before determining it is a replay. At the point it
>determines the request is a replay it should stop processing the
>request and return the cached response.
>
>However since you seem to be seeing an error packet, that may not be
>happening.
>
>
>
>I do see a replay error in the trace and I'm not really sure what the
>KDC thinks it is a replay of.
>
>It's also generating an error not returning a cached response.
>
>Thanks for the trace; we should look at it in the next few days and
>see if we can come up with any additional data.
>
>For the benefit of others I'm attaching a decoding of the trace to the
>ticket.
Subject: kdc returns replay when replayed request not apparent
Download (untitled) / with headers
text/plain 2.6KiB
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@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@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
Date: Tue, 19 Nov 2002 17:16:21 -0500
To: rt-comment@krbdev.mit.edu
From: Rodney M Dyer <rmdyer@uncc.edu>
Subject: Re: [krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent
RT-Send-Cc:
Download (untitled) / with headers
text/plain 3.3KiB
MIT Kerberos Bug Support,

Sam Hartman, Tom Yu

Does anyone know the status of this problem? I'm still trying to work out
support through Microsoft, but I haven't heard a peep out of the MIT
people. I'd really prefer that Microsoft not gloss over this with a hack
to make it work. It would be better if there was some standardization of
the protocol in place first.

Thanks,

Rodney

Rodney M. Dyer
x86 Systems Programmer
College of Engineering Computing Services
University of North Carolina at Charlotte
Email rmdyer@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:
Show quoted text
>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@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@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
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent
From: Sam Hartman <hartmans@mit.edu>
Date: Wed, 20 Nov 2002 11:15:59 -0500
RT-Send-Cc:
Hi. We're still working with some people at Microsoft on this issue.
We have a general understanding of the issue but not a specific
problem. IT seems that the Microsoft client is sending requests
within the same second that do not differ in the microsecond field.
The MIT implementation is correct to reject these requests according
to RFC 1510.

The MIT code could be improved to be more robust in replay detection
and revisions to the Kerberos protocol will allow this. We do plan to
implement the improvement, but will probably not ship it for a year or
two; it ends up being rather complicated to implement.

Once we find the specific problem on the Microsoft side we'll let you
know.
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent
From: Sam Hartman <hartmans@mit.edu>
Date: Wed, 20 Nov 2002 11:23:08 -0500
RT-Send-Cc:
Hi. We're still working with some people at Microsoft on this issue.
We have a general understanding of the issue but not a specific
problem. IT seems that the Microsoft client is sending requests
within the same second that do not differ in the microsecond field.
The MIT implementation is correct to reject these requests according
to RFC 1510.

The MIT code could be improved to be more robust in replay detection
and revisions to the Kerberos protocol will allow this. We do plan to
implement the improvement, but will probably not ship it for a year or
two; it ends up being rather complicated to implement.

Once we find the specific problem on the Microsoft side we'll let you
know.
Date: Mon, 09 Dec 2002 16:25:46 -0500
To: rt-comment@krbdev.mit.edu
From: Rodney M Dyer <rmdyer@uncc.edu>
Subject: Re: [krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent
RT-Send-Cc:
Download (untitled) / with headers
text/plain 4.5KiB
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@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:
Show quoted text
>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@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@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
From: ghudson@mit.edu
Subject: SVN Commit

Add message hash support to the replay interface, using extension
records (with an empty client string) to retain compatibility with old
code. For rd_req, the ciphertext of the authenticator (with no ASN.1
wrapping) is hashed; for other uses of the replay cache, no message
hash is used at this time.

This commit adds a command-line tool for testing the replay cache but
does not add any automated tests.


https://github.com/krb5/krb5/commit/529e72785f09c36a9aa34fd7f3fc30fb41a1c92e
Commit By: ghudson
Revision: 21723
Changed Files:
U trunk/src/include/k5-int.h
U trunk/src/kdc/kdc_preauth.c
U trunk/src/lib/krb5/krb/mk_cred.c
U trunk/src/lib/krb5/krb/mk_priv.c
U trunk/src/lib/krb5/krb/mk_safe.c
U trunk/src/lib/krb5/krb/rd_cred.c
U trunk/src/lib/krb5/krb/rd_priv.c
U trunk/src/lib/krb5/krb/rd_req_dec.c
U trunk/src/lib/krb5/krb/rd_safe.c
U trunk/src/lib/krb5/libkrb5.exports
U trunk/src/lib/krb5/rcache/Makefile.in
U trunk/src/lib/krb5/rcache/rc_conv.c
U trunk/src/lib/krb5/rcache/rc_dfl.c
A trunk/src/lib/krb5/rcache/t_replay.c
U trunk/src/tests/threads/t_rcache.c
From: ghudson@mit.edu
Subject: SVN Commit

Rework the replay cache extensions to make the hash extension records
stand alone. Otherwise, reordering of records during an expunge could
cause the hash to be applied to the wrong record.

Also add an "expunge" option to the t_replay program, and clean up some
memory-handling inconsistencies.


https://github.com/krb5/krb5/commit/95aebaa7f2ebdc1db54ef9a141deaace83a4a7f9
Commit By: ghudson
Revision: 21751
Changed Files:
U trunk/src/lib/krb5/rcache/rc_dfl.c
U trunk/src/lib/krb5/rcache/t_replay.c