Andrew, The trace you sent previously lines up with expected behavior the documentation defines (This was also verified with a review of the code also). You can see starting with packet 530 that the client tells the server that it does support signing but the server responds in packet 534 that it does not. From there in frames 535-538 show the client and server not using header signing for the remainder of the conversation which is in line with the documentation. We do see the client and server encrypting the body of the request as per the authentication level being set to Privacy.
Can you send a capture that exhibits the behavior you describe with NTLMv2 as well as clarify your comments about behavior you have seen in the past? Basically I need as much information as you can provide on the behavior you have experienced to help understand the problem. This would help to isolate the behavior you are seeing and complete additional analysis as required. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 "Las Colinas - LC2" Tel: +1 469 775 7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -----Original Message----- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 5:26 PM To: Richard Guthrie Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional On Wed, 2008-07-30 at 08:45 -0700, Richard Guthrie wrote: > Andrew, > We have completed our review of your request to update the > documentation and would like to point out the following text from > MS-RPCE section 3.3.1.5.2.2. > > Using this mechanism, the client and server agree if header signing > should be done for this connection. Once agreed, the client and server > apply protection to request and response PDUs in the same way. > > Based on this verbiage as well as the trace you sent previously > (Packet 537) the documentation is correct that this is flag is used to > negotiate whether header signing or integrity checking will be used in > conjunction with the set authentication level. The client will set > this bit to 1 on the initial BIND and the server will then set it to 1 > or 0 to negotiate whether header signing will be utilized on all > subsequent request/response in the conversation according to the > guidelines for authentication level in section 3.3.1.5.2.2. Please > let us know if you have any further questions on this issue. No, this does not resolve the request. I agree that this is what reading the docs would tell you, but please consider this more deeply, and make enquires with the actual code (not the spec...) - please read Metze's and my additional observations and inquire into the code. We know that AEAD (Authenticated Encryption with Additional Data, aka header signing) which is what this feature is meant to negotiate is still used, because we have had to implement it for NTLM2, without setting either of these flags. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
