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

[John Dunning]

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.

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).

What is unclear here is how the sequence numbers, exchanged in this message, are expected to be updated.  For example, with a WinXP clients, and arcfour-hmac-md5 encryption, the sequence number (as maintained by the client, and seen on the server) is unaffected by the receipt of this extra message.

In Heimdal's implementation here, we reset the sequence numbers after verifying the AP_REP at line 690.

http://git.samba.org/?p=samba.git;a=blob;f=source/heimdal/lib/gssapi/krb5/accept_sec_context.c;h=73b93ceba4c6bb472c546afd52981bcf13051173;hb=v4-0-test

However, when GSSAPI CFX is used, and therefore an AES key is negotiated by a Windows Vista client to a Samba4 server, the client seems to require that the remote (from the server's persective) sequence number be increased by 1.

(ie, adding 1 to r_seq_number at like 690 allows the next gss_unwrap to match the expected sequence number correctly, in the DRSUAPI bind portion of a Vista SP1 domain join).

Simiarly, you will note in line 606, that we must disable timestamp verification.

While the client code (like 663) is comparatively sane...
http://git.samba.org/?p=samba.git;a=blob;f=source/heimdal/lib/gssapi/krb5/init_sec_context.c;h=c455a5dc8b7246c0c8e795206be5b9c3db114cb8;hb=v4-0-test

It seems that this is more than a simple role reversal, and the docs need to be expanded to clarify this."

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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.

I hope this helps to clarify my request.

Thanks
John


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Monday, July 28, 2008 6:39 PM
To: John Dunning
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: Regarding [MS-KILE] 3.4.5.1 Three-Leg DCE-Style Mutual Authentication

On Mon, 2008-07-28 at 15:31 -0700, John Dunning wrote:
> Hello Andrew,
>
>    I wanted to touch bases with you to let you know that I am
> researching your question. In your email you indicated that Windows XP
> seems to take care of the sequence numbers correctly and I wanted to
> make sure I understood this. Are you saying that you are only seeing
> this behavior with Vista? Would it be possible for you to obtain a
> network trace of the case where it fails; when you don't add 1 to the
> sequence number around line 690 of your code?

That is the trace already supplied.  (As we fault anyway, just a few
more lines down the gsskrb5_unwrap() processing, , because we don't
match the checksum, even if we match the sequence number)

Andrew Bartlett
--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com