[cifs-protocol] RE: Regarding [MS-KILE] 3.4.5.1 Three-Leg DCE-Style Mutual Authentication

[Andrew Bartlett]

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
this part. 

> The issue that I am working on is for the following information from you:
> 
> "The documentation in MS-KILE 3.4.5.1 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
>   server.
> 
>   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.

No worries.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080730/a5700328/attachment.bin