Metze, Yes, your initial observation is right. Checksum is only 8 bytes and the cofounder follows with 8 bytes of checksum. I filed a request to update the document.
I will look at the code and compare it with the documentation and Windows implementation. I will let you know. Thanks! Hongwei -----Original Message----- From: Stefan (metze) Metzmacher [mailto:[email protected]] Sent: Thursday, September 17, 2009 11:17 AM To: Hongwei Sun; [email protected]; [email protected]; Nick Meier; Guenther Deschner Subject: Re: [Pfif] MS-NRPC: AES Schannel problems Hi Hongwei, Nick just told me that Windows seems to have a bug there and I tried to "reproduce" this bug in our code, but I still can't get windows to accept signed or sealed traffic from us. See the attached capture: Frames 178 and 179 are with signing Frames 330 and 331 are with sealing You can take a look at my code here (see the top 5 commits) http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel metze > -----Original Message----- > From: Stefan (metze) Metzmacher [mailto:[email protected]] > Sent: Wednesday, September 16, 2009 1:46 PM > To: Hongwei Sun > Cc: [email protected]; [email protected]; Nick Meier; Guenther > Deschner > Subject: Re: [Pfif] MS-NRPC: AES Schannel problems > > Hi Hongwei, > >> I think that Nick already informed you that AES 128 with 8 bit CFB mode >> has to be used. I filed a request to add the information into 3.1.4.4 of >> MS-NRPC. I also noticed that in mxnrpc.c you attached , you used >> AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential. >> Please let us know if you have resolved the issue and if we can provide >> further help. > > Yes, he does and we got that part working. Thanks! > using AES_cfb8_encrypt() instead of AES_cfb128_encrypt(). > > However we have the next challenge, the Netlogon SSPI provider. > > I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't > work. > > Looking at the frame 308 and the following in > w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap. > > I think there's a bug in w2k8r2 in the docs. > > The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values. > > It seem that the checksum is still 8 byte and the confounder directly > follows. The last 24 bytes are just uninitalized memory. > > They are: > Frame 308: > > 32 00 2e 00 33 00 31 00 > 2e 00 39 00 2e 00 32 00 > 31 00 34 00 00 00 00 00 > > Frame 310: > > 35 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 > 00 00 02 00 00 00 00 00 > > Frame 311: (I think it's random because the pdu is so long and point > memory in other aeas) > > 51 03 21 9b 41 84 cc 90 > e7 e8 70 1c 52 60 55 5a > 64 0c 6a 17 be 07 de 80 > > Looks like a unicode string instead of parts of a checksum and a confounder. > > metze > >> Meanwhile, I provide some sample values that I captured from debugger > for you to verify your logic. >> OWF Password : >> >> 13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3 >> >> Client Challenge: >> >> 25 63 e3 5f 69 e1 5a 24 >> >> Server Challenge: >> >> 9C 66 5F 90 D9 83 DF 43 >> >> Session Key calculated: >> >> c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70 >> >> Client Credential: >> >> 58 6a df 53 ef 72 78 d9 >> >> Server Credential >> >> E1 41 62 09 B2 3E 57 51 >> > > It would be great if you could add this values to the docs. > > metze > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
