On Wednesday, June 29, 2022 7:44:30 PM CEST Jeff McCashland (He/him) wrote: > Hi Andreas,
Hi Jeff, > Thank you for the clarification. A better approach would be to determine why > your Windows server is failing the operation. I would like to collect LSASS > traces from your Windows Server for analysis. I think it would help if you > use the test data for the trial run. > > I have created a File Transfer workspace to exchange files related to this > issue (credentials and link below). If you still have the instructions and > tools from when I requested LSASS traces in March, you can use those. > Otherwise, you can find 'PartnerTTDRecorder_x86_x64.zip' on the workspace > for download. I've created a time trace and a network capture and uploaded it to the workspace. ./bin/rpcclient ncacn_np:earth.milkyway.site -U'Administrator%Secret007!' -c 'setuserinfo2 bob 31 Pa$$w0rd@2' result was NT_STATUS_INVALID_PARAMETER Best regards Andreas > To collect the needed traces: > 1. From an elevated command prompt, execute: tasklist /FI "IMAGENAME eq > lsass.exe" 2. Note the PID of the lsass process from the output of the > above command. 3. Execute: C:\TTD\TTTracer.exe -attach PID, where PID is > the number from above. 4. Wait for a little window to pop up in top left > corner of your screen, titled "lsass01.run" 5. start a network trace on the > Server side > 6. Repro the attempted operation > 7. Stop the network trace and save it > 8. CAREFULLY: uncheck the checkbox next to "Tracing" in the small > "lsass01.run" window. Do not close or exit the small window or you will > need to reboot. 9. The TTTracer.exe process will generate a trace file, > then print out the name and location of the file. Compress the *.run file > into a .zip archive before uploading with the matching network trace. > > Log in as: 2206210040006850_andr...@dtmxfer.onmicrosoft.com > 1-time: [KOGh3@j > > Workspace link: > https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSU > zI1NiJ9.eyJ3c2lkIjoiM2I3YTRiZjUtMTVlNi00ZDQ3LWJlMzUtMzMyZGMwMjI0NWNjIiwic3Ii > OiIyMjA2MjEwMDQwMDA2ODUwIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNi > ZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI5YWZlNDk3Yi01NzE1 > LTRiYWYtYmRkNS1mNTIzYzliODQ4ZmQiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWlj > cm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NjQzMDAyMjUsIm5iZiI6MTY1 > NjUyNDIyNX0.WUjcO-UT6NMWT3eR4TJkmmwzbiHQLyqeinUgX-DmvUuQo4UaiIPFrNPoTFN_czY2 > -ihGY3N3bwnIt5AcE5f4JaR2qyT81r691J79n-IZgo8TFkdJMW6XjtVoIUkgOGh-RkyDKCAjhsj8 > p6ddgiL-7UbxX58a7RWvOH9Yu0NzQdW8KKnyEUcFgFGPo42Sqy1igpkqxqcyAVOKFYicPRf2ux39 > SdHeoa9ptL78XLFsIuvNFkh6c77U1iEoaV3eqjQSu1rNriwv73cyu3WRJ0-dEiZDVpzHP71JfdCE > lYBe8lDjmnEWPm0_99Iudoi4RjIgtclS4zdAS_X9efCBKkIeOA&wid=3b7a4bf5-15e6-4d47-be > 35-332dc02245cc > > Best regards, > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol > Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | > Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone > number found here: http://support.microsoft.com/globalenglish | Extension > 1138300 We value your feedback. My manager is Stacy Gray (stacygr), +1 > (469) 775-4055 > > -----Original Message----- > From: Andreas Schneider <a...@samba.org> > Sent: Wednesday, June 29, 2022 7:24 AM > To: Jeff McCashland (He/him) <je...@microsoft.com> > Cc: cifs-protocol@lists.samba.org; Jeff McCashland > <je...@microsoftsupport.com>; Obaid Farooqi <oba...@microsoft.com> Subject: > Re: [EXTERNAL] Re: [MS-SAMR] AEAD-AES-256-CBC-HMAC-SHA512 - > TrackingID#2206210040006850 > On Tuesday, June 28, 2022 6:41:40 PM CEST Jeff McCashland (He/him) wrote: > > Hi Andreas, > > Hi Jeff, > > > Can you not use the test data provided in the RFC [AEX-CBC] that you > > originally referenced? > > I have an implementation of AEAD-AES-256-CBC-HMAC-SHA512 and implemented it > in rpcclient, but it doesn't work against a Windows server. There are so > many little details which can be different. > > ./bin/rpcclient ncacn_np:earth.milkyway.site -U'Administrator%Secret007!' -c > 'setuserinfo2 bob 31 Pa$$w0rd@2' > > > From MS-SAMR 3.2.2.4 AES Cipher Usage > > ================ > > The data MUST be encrypted and decrypted using AEAD-AES-256-CBC-HMAC-SHA512 > as follows: > > Let IV be a random 16-byte number. > > Then the encryption is done as follows: > > Let enc_key ::= HMAC-SHA-512(CEK, SAM_AES256_ENC_KEY_STRING) > > Let mac_key ::= HMAC-SHA-512(CEK, SAM_AES256_MAC_KEY_STRING) > > Let Cipher ::= AES-CBC(enc_key, IV, secret_plaintext) > > Let AuthData ::= HMAC-SHA-512(mac_key, versionbyte + IV + Cipher + > versionbyte_length) > > ================ > > As my implementation doesn't work against Windows it can be that my size of > SAM_AES256_ENC_KEY_STRING is wrong. > > 2.2.1.18 has: > > SAM_AES256_ENC_KEY_STRING_LENGTH sizeof(SAM_AES256_ENC_KEY_STRING) > > The sizeof() in C would include the \0 terminator of a string, however I > think that actually strlen() is meant. > > Same for the mac key ... > > Also there is truncation of keys happening. Like the enc_key is truncated to > 32 bytes. > > For calculating the authdata it isn't clear what data type > versionbyte_length is. I would guess it is uint8_t but it could also be > uint32_t ... > > Is the AuthData truncated to 32 byte? In the RFC it is, but in MS-SAMR > 2.2.6.32 the struct member for AuthData is 64 bytes. If truncation is > happening will the rest be filled with 0 bytes? > > Either I provide you the all unclear details and you figure it out for me. > Or you provide the hexdumps and I figure it out and ask better questions > :-) > > > Here is some pseudo C code of my implementation: > > #define SAMR_AES_VERSION_BYTE 0x01 > #define SAMR_AES_VERSION_BYTE_LEN 1 > > #define SAMR_AES256_ENC_KEY_STRING \ > "Microsoft SAM encryption key AEAD-AES-256-CBC-HMAC-SHA512 16" > #define SAMR_AES256_ENC_KEY_STRING_LEN 60 > > #define SAMR_AES256_MAC_KEY_STRING \ > "Microsoft SAM MAC key AEAD-AES-256-CBC-HMAC-SHA512 16" > #define SAMR_AES256_MAC_KEY_STRING_LEN 53 > > uint8_t version_byte = SAMR_AES_VERSION_BYTE; /* 0x01 */ > uint8_t version_byte_len = SAMR_AES_VERSION_BYTE_LEN; /* 1 */ > > uint8_t enc_key_data[64]; > uint8_t mac_key_data[64]; > > /* Calculate encryption key */ > /* cek_key is just 16 bytes if a SMB session key is used? */ > rc = gnutls_hmac_fast(GNUTLS_MAC_SHA512, > cek_key.data, > cek_key.size, > SAMR_AES256_ENC_KEY_STRING, > SAMR_AES256_ENC_KEY_STRING_LEN, > enc_key_data); > > enc_key.data = mac_key_data; > enc_key.size = 32; /* truncation from 64 to 32 bytes */ > > /* Encrypt plaintext */ > rc = gnutls_cipher_init(&cipher_hnd, > GNUTLS_CIPHER_AES_256_CBC, > &enc_key, > &iv); > > rc = gnutls_cipher_encrypt2(cipher_hnd, > secret->data, > secret->length, > ctext, > ctext_len); > > /* Calculate mac key */ > rc = gnutls_hmac_fast(GNUTLS_MAC_SHA512, > cek_key.data, > cek_key.size, > SAMR_AES256_MAC_KEY_STRING, > SAMR_AES256_MAC_KEY_STRING_LEN, > mac_key_data); > > mac_key.data = mac_key_data; > mac_key.size = 32; /* truncation from 64 to 32 bytes */ > > /* Generate auth tag */ > rc = gnutls_hmac_init(&hmac_hnd, > GNUTLS_MAC_SHA512, > mac_key.data, > mac_key.size); > > rc = gnutls_hmac(hmac_hnd, > &version_byte, > sizeof(uint8_t)); > > rc = gnutls_hmac(hmac_hnd, > iv.data, > iv.size); > > rc = gnutls_hmac(hmac_hnd, > ctext, > ctext_len); > > rc = gnutls_hmac(hmac_hnd, > &version_byte_len, > sizeof(uint8_t)); > > gnutls_hmac_deinit(hmac_hnd, auth_data); > /* Is auth_data truncated? */ > > > Best regards > > > Andreas > > > It appears to have all or most of what you're looking for: > > K (secret input key) > > MAC_KEY > > ENC_KEY > > P (plaintext) > > IV (initialization vector) > > A (associated data) > > PS (padding string) > > AL (associated data length) > > S (ciphertext - intermediate) > > T (authentication tag) > > C (ciphertext) > > > > Best regards, > > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol > > Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm > > | > > Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone > > number found here: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport. > > microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%7C2 > > aef7356a401488aa28b08da59db101c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 > > %7C637921094670609275%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3F5A%2B2t > > LvyvS8LOk%2FOx6BeqCckryLWLucxcaxKPNoCI%3D&reserved=0 | Extension > > 1138300 We value your feedback. My manager is Stacy Gray (stacygr), +1 > > (469) 775-4055 > > > > -----Original Message----- > > From: Jeff McCashland (He/him) > > Sent: Monday, June 27, 2022 11:55 AM > > To: Andreas Schneider <a...@samba.org> > > Cc: cifs-protocol@lists.samba.org; Jeff McCashland > > <je...@microsoftsupport.com>; Obaid Farooqi <oba...@microsoft.com> > > Subject: > > RE: [EXTERNAL] Re: [MS-SAMR] AEAD-AES-256-CBC-HMAC-SHA512 - > > TrackingID#2206210040006850 > > > > Hi Andreas, > > > > Our plan is to capture traffic where AEAD-AES-256-CBC-HMAC-SHA512 is used. > > > > We're working on setting up a Windows repro. However, Windows uses LDAP > > instead of SAMR, so we're working out how to configure it to use SAMR. > > > > I'll keep you posted. > > > > Best regards, > > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol > > Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm > > | > > Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone > > number found here: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport. > > microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%7C2 > > aef7356a401488aa28b08da59db101c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 > > %7C637921094670614268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u4WbTdU%2 > > F6GSFcjspR21MPDStD8Ag2dtpPeNJ5nEgFH8%3D&reserved=0 | Extension 1138300 > > We value your feedback. My manager is Stacy Gray (stacygr), +1 (469) > > 775-4055 > > > > -----Original Message----- > > From: Andreas Schneider <a...@samba.org> > > Sent: Monday, June 27, 2022 4:56 AM > > To: Jeff McCashland (He/him) <je...@microsoft.com> > > Cc: cifs-protocol@lists.samba.org; Jeff McCashland > > <je...@microsoftsupport.com>; Obaid Farooqi <oba...@microsoft.com> > > Subject: > > [EXTERNAL] Re: [MS-SAMR] AEAD-AES-256-CBC-HMAC-SHA512 - > > TrackingID#2206210040006850 > > > > On Wednesday, June 22, 2022 8:09:34 PM CEST Jeff McCashland (He/him) wrote: > > > Hi Andreas, > > > > Hi Jeff, > > > > > I will research your question and see what we can come up with for > > > test data. > > > > thank you very much. Looking forward to hear from you :-) > > > > Andreas > > > > > Best regards, > > > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft > > > Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | > > > Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) > > > Local country phone number found here: > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > com%7Cb133cf48cfa147d4956b08da5833fc38%7C72f988bf86f141af91ab2d7cd011d > > > b47%7C1%7C0%7C637919277699900369%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C& > > > amp;sdata=%2BJdN4TiV%2Bvqq4dqYGpq7mGhZ1vh3gQrrvgjqsBuBXbg%3D&reser > > > ved=0 | Extension > > > 1138300 We value your feedback. My manager is Stacy Gray (stacygr), > > > +1 > > > (469) 775-4055 > > > > > > -----Original Message----- > > > From: Obaid Farooqi <oba...@microsoft.com> > > > Sent: Tuesday, June 21, 2022 9:08 AM > > > To: Andreas Schneider <a...@samba.org> > > > Cc: cifs-protocol@lists.samba.org; Obaid Farooqi > > > <oba...@microsoftsupport.com> Subject: [EXTERNAL] [MS-SAMR] > > > AEAD-AES-256-CBC-HMAC-SHA512 - TrackingID#2206210040006850 > > > > > > Hi Andreas: > > > Thanks for contacting Microsoft. I have created a case to track this > > > issue. > > > A member of the open specifications team will be in touch soon. > > > > > > Regards, > > > Obaid Farooqi > > > Escalation Engineer | Microsoft > > > > > > -----Original Message----- > > > From: Andreas Schneider <a...@samba.org> > > > Sent: Tuesday, June 21, 2022 8:00 AM > > > To: Interoperability Documentation Help <doch...@microsoft.com> > > > Cc: cifs-protocol@lists.samba.org > > > Subject: [EXTERNAL] [MS-SAMR] AEAD-AES-256-CBC-HMAC-SHA512 > > > > > > Hello Dochelp, > > > > > > I'm trying to implement support for AEAD-AES-256-CBC-HMAC-SHA512 from > > > [MS- SAMR] 3.2.2.4 AES Cipher Usage. > > > > > > This is not really easy as there are some details unclear. I would > > > love to write a unit test for AEAD-AES-256-CBC-HMAC-SHA512. > > > > > > Could you please provide hexdump of the buffers used in encryption > > > from a > > > SamrSetInformationUser2 level 31 from a test platform. > > > > > > When it performs the following: > > > > > > Let enc_key ::= HMAC-SHA-512(CEK, SAM_AES256_ENC_KEY_STRING) Let > > > mac_key ::= HMAC-SHA-512(CEK, SAM_AES256_MAC_KEY_STRING) Let Cipher > > > > > > ::= AES-CBC(enc_key, IV, secret_plaintext) Let AuthData ::= > > > > > > HMAC-SHA-512(mac_key, versionbyte + IV + Cipher + versionbyte_length) > > > > > > > > > I would like to have hexdumps of the following buffers: > > > > > > * cek (16byte sesssion key) > > > * enc_key > > > * mac_key > > > * IV > > > * secret_plaintext > > > * cipher > > > * authdata > > > > > > The RFC implementation provides something like that, see: > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool > > > s.ietf%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb133cf48cfa147d49 > > > 56b08da5833fc38%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637919277 > > > 699900369%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi > > > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ihsJ1PYjg2cT7 > > > 4D3zmlfdDV3UEVNtpJeOX%2BPWQYmg%2FI%3D&reserved=0 > > > .org%2Fid%2Fdraft-mcgrew-aead-aes-cbc-hmac-sha2-03.html%23rfc.section. > > > 5.4&am > > > p;data=05%7C01%7Cjeffm%40microsoft.com%7C382019859d9f4eb7cc1b08da53a03 > > > c24%7C > > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637914244951310820%7CUnknow > > > n%7CTW > > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > > > Mn0%3D > > > %7C3000%7C%7C%7C&sdata=jzVMJ8GS%2BP30uF6pHSTfJf8ioOzDOK69Y%2ByyFKD > > > zpKo%3 > > > D&reserved=0 > > > > > > This would allow me to write a unit test and figure out the details > > > what in my implementation something goes wrong. I can then provide > > > feedback to improve the documentation. > > > > > > > > > Thank you very much! > > > > > > > > > Best regards > > > > > > Andreas Schneider > > > > > > -- > > > Andreas Schneider a...@samba.org > > > Samba Team > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sam > > > ba%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C2aef7356a401488aa28b08d > > > a59db101c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63792109467061926 > > > 7%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > > > 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UWJ4c8%2BpOSJ8UiaN%2FeH7l > > > marEwwyiVx1ECnPk03Awk4%3D&reserved=0 > > > %2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb133cf48cfa147d4956b08da > > > 583 > > > 3fc38%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637919277699900369%7 > > > CUn > > > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw > > > iLC > > > JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Q04le03I8jml11uEltlzIssEEkpVMfFe > > > HjD Ydw2cPIU%3D&reserved=0. > > > org%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C382019859d9f4eb7cc1b > > > 08da53 > > > a03c24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637914244951310820 > > > %7CUnk > > > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw > > > iLCJXV > > > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=0VU8ycMe9EFGOAEV7JROkmRRoQCDje5N%2Fx > > > AI > > > bz qpbI4%3D&reserved=0 GPG-ID: > > > 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D -- Andreas Schneider a...@samba.org Samba Team www.samba.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D _______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol