[cifs-protocol] RE: Regarding [MS-KILE] 184.108.40.206 Three-Leg DCE-Style
johndun at microsoft.com
Fri Aug 8 18:07:47 GMT 2008
I've received feedback from the Product team and they are requesting additional clarification. To start with I would like to insure we understand the issue.
We understand the problem to be the following, please let me know if this is not correct.
The behavior SAMBA is seeing is Client authenticates to Server using KILE and the following occurs:
1. Client sends RFC std AP_REQ to server
2. Server sends RFC std AP_REP to client
in this message the sequence number is n
3. Client sends AP_Rep to server
in this message the sequence number is n in XP and n+1 in Vista only when AES is used
Please clarify what GSSAPI you are using. From the Product team's investigation they don't see a difference in behavior with AES. They are also requesting possible repro steps and Kerberos logs.
Please let me know if you have any questions regarding this information request.
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Tuesday, July 29, 2008 5:23 PM
To: John Dunning
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Regarding [MS-KILE] 220.127.116.11 Three-Leg DCE-Style Mutual Authentication
On Tue, 2008-07-29 at 13:32 -0700, John Dunning wrote:
> Hi Andrew,
> I got to thinking about this conversation and there may be some
> confusion regarding the network trace I am requesting. I spoke with
> Richard Guthrie from Microsoft who is a colleague on my team. He too
> has a issue of yours in a common area. He received a trace from you
> for that issue.
Are you subscribed to the cifs-protocol list? You will notice that my
questions tend to be batches and in related areas (as I fire them off
when I wander into a new area of the codebase) - hence the cross-over in
> The issue that I am working on is for the following information from you:
> "The documentation in MS-KILE 18.104.22.168 on DCE_STYLE is very terse, and
> fails to clarify a few points, one of which is preventing
> interoperability with Windows Vista.
> The client MUST generate an additional AP reply message exactly as the server would ([RFC4120]
> section 3.2.4) as the final message to send to the server. In GSS terms, the client must return
> success and a message to the server. It is up to the application to deliver the message to the
> The server MUST receive the additional AP reply message and verify that the message is
> constructed correctly ([RFC4120] section 3.2.5).
> The network trace I am requesting would be for the above problem with
> respect to the sequence numbers. I take it that it faults when the
> client doesn't receive the expected sequence number? If that is indeed
> the case then that would be the trace I am interested in seeing.
Correct. We have two code variants that fault in the same packet for
different reasons - one where we tried to hack around the sequence
number, but still failed due to needing AEAD (Richard's task), and the
fact that we had to hack around the sequence number at all (your task).
> I hope this helps to clarify my request.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
More information about the cifs-protocol