[cifs-protocol] [EXTERNAL] Re: [MS-SAMR] 3.2.2.5 Deriving an Encryption Key fr... - TrackingID#2207140040006706

Jeff McCashland (He/him) jeffm at microsoft.com
Tue Jul 19 17:49:13 UTC 2022


Hi Andreas,

Thank you for the summaries and suggestions. I will follow up on these with our SAMR team. 

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

-----Original Message-----
From: Andreas Schneider <asn at samba.org> 
Sent: Friday, July 15, 2022 12:18 AM
To: Jeff McCashland (He/him) <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org; Jeff McCashland <jeffm at microsoftsupport.com>
Subject: [EXTERNAL] Re: [MS-SAMR] 3.2.2.5 Deriving an Encryption Key fr... - TrackingID#2207140040006706

On Friday, July 15, 2022 1:43:47 AM CEST Jeff McCashland (He/him) wrote:
> Hi Andreas,

Hi Jeff,

> Actually, I think you are correct that dkLen is 16, as the result when 
> the server calls the PBKDF2 function is 16 bytes. The failure occurs 
> because your AuthData doesn't match what we calculate.
> 
> I'm assuming P is the hash of the old password. Here are byte dumps of 
> the inputs and outputs to the PBKDF2 function from your trace:
> 
> P:  f8 48 54 de b8 36 10 33-ca ea 5c 95 96 66 99 38
> S: d5 be 4f d7 b6 85 d1 ea-fd 3b f4 29 83 ce 10 44
> c: 0x5bed
> 
> Derived Key: f1 e6 b2 6a 78 28 63 05-77 38 c9 71 d2 05 88 58

thank you very much for confirming this. I created a unit test with the values and it worked. I just had two passwords swapped and after fixing it I got it working :-)


$ ./bin/rpcclient ncacn_np:earth.milkyway.site -U'bob%Pa$$w0rd at 3' -c
'chgpasswd4 bob Pa$$w0rd at 3 Pa$$w0rd at 8' -d10 [..]
rpc_api_pipe: host earth.milkyway.site returned 4 bytes.
     samr_ChangePasswordUser4: struct samr_ChangePasswordUser4
        out: struct samr_ChangePasswordUser4
            result                   : NT_STATUS_OK



Summary:

3.2.2.5 Deriving an Encryption Key from a Plaintext Password

  The client MUST derive the CEK in the following manner:
  CEK :: = (PBKDF2(NT HASH of "OldPassword", Salt, IterationCount, 512))


This need to be clarified that 512 means that the PBKDF2 functions should use 
SHA512 internally.

It should also state the the CEK length should be 16!



3.1.5.10.4 SamrUnicodeChangePasswordUser4 (Opnum 73)

  7. If Stored-NT-Hash is not NULL and EncryptedPassword.PBKDF2Iterations is
     valid, the server will decrypt EncryptedPassword as follows:
     [..]

This has details which are missing in 3.2.2.5. It also misses some details 
(like SHA512). I would suggest you put all relevant information in 3.2.2.5 and 
point there.


Thanks for your help!


Best regards


	Andreas

> From which we calculate the mac_key:
>  95 40 fc 6d bb 63 16 46-73 ea 0c ab 26 ea 00 5a
>  68 b2 d2 20 60 34 12 31-7a 4f d7 d0 9b 38 d4 e6
>  d1 f6 cb 6c f3 71 99 9f-b4 0c d5 46 e8 d4 f5 7a
>  3c e4 49 8b eb d6 16 31-36 da b4 15 e0 78 d0 e1
> 
> That is then used generate AuthData:
>  ce bf 34 2e cf 5a a4 e7-09 f0 8e a5 41 16 c7 5f
>  e2 56 59 7c 26 ed 23 28-3f 79 23 29 9e ae 86 d2
>  ef ea 32 f8 5c d3 69 dd-48 7b de 63 6f 8e d3 61
>  0e 61 1c 1d 1a 77 23 e9-d5 7f 52 33 0c c4 2d c5
> 
> Which doesn't match what you sent:
>  92 1c bd b5 90 a5 28 23 e9 0a f0 bc f3 74 f5 ba
>  c3 13 34 c4 8b 11 3d a6 ea 28 55 41 9b 80 f0 d7
>  8e 2a 66 5b b7 c1 12 f0 3f 18 a4 fc 5d dd c4 b3
>  37 71 5b 1b b6 71 10 86 78 f5 04 db 34 b4 0a 4d
> 
> Best regards,
> Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol
> Open Specifications Team
> 
> -----Original Message-----
> From: Jeff McCashland (He/him)
> Sent: Thursday, July 14, 2022 3:03 PM
> To: Andreas Schneider <asn at samba.org>
> Cc: cifs-protocol at lists.samba.org; Jeff McCashland
> <jeffm at microsoftsupport.com> Subject: RE: [MS-SAMR] 3.2.2.5 Deriving an
> Encryption Key fr... - TrackingID#2207140040006706
> 
> Hi Andreas,
> 
> You referenced the PBKDF2 profile from the RFC:
>    PBKDF2 (P, S, c, dkLen)
> 
> And where it's used in [MS-SAMR] section 3.2.2.5:
> CEK :: = (PBKDF2(NT HASH of "OldPassword", Salt, IterationCount, 512))
> 
> P = NT HASH of "OldPassword"
> S = Salt
> c = IterationCount
> dkLen = 512
> 
> I think the 512 is actually the dkLen, rather than a reference to SHA512.
> Let me know if you still get an error using 512 as dkLen.
> 
> 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%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZS7bZUfy3%2BAbmfB2sHArgrB%2F2GMoYCWvQTNwZWFiVeY%3D&reserved=0 | Extension
> 1138300
> 
> -----Original Message-----
> From: Jeff McCashland (He/him)
> Sent: Thursday, July 14, 2022 10:53 AM
> To: Andreas Schneider <asn at samba.org>
> Cc: cifs-protocol at lists.samba.org; Jeff McCashland
> <jeffm at microsoftsupport.com> Subject: RE: [MS-SAMR] 3.2.2.5 Deriving an
> Encryption Key fr... - TrackingID#2207140040006706
> 
> [HC to BCC]
> 
> Hi Andreas,
> 
> I will assist you with this issue. I have the traces you uploaded to the
> workspace for our previous case. In general, it's best to wait for a new
> workspace link before uploading traces, so the traces are connected to the
> correct issue.
> 
> Below I've included credentials and a workspace link for this specific
> issue/case. The reason I've been setting up separate workspaces is that any
> time you update/fix your implementation, we consider subsequent concerns as
> new issues even if the operation and error are the same.
> 
> I'll analyze the traces and let you know what I find.
> 
> Credentials for any additional files related to this issue:
> Log in as: 2207140040006706_andreas at dtmxfer.onmicrosoft.com
> 1-time: 75M1vMQ]
> 
> Workspace link:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSU&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cGW24ePuV6vixdM%2BkaDphEaMDJJZc4cwu%2BHiVVJ4mts%3D&reserved=0
> zI1NiJ9.eyJ3c2lkIjoiOTQwYTI3MmYtNTA3ZC00MWRiLTg1YTUtZWJmMmRlNTIxMzJhIiwic3Ii
> OiIyMjA3MTQwMDQwMDA2NzA2IiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNi
> ZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI0NGQ3MTRmYy00NTRk
> LTRhOTgtOWFjNi0xNzcwOTJmNjcyNTgiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWlj
> cm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NjU1OTcwNzksIm5iZiI6MTY1
> NzgyMTA3OX0.TGwaNQYExmasfoHGEEd1ZeXoXkqMc0_3-vdRo02F2qIMVEL0QDNZPCjSotF_eK-2
> uCPI-uZHrqQ5nYuXKxJaQ4GFTPic0ncYkbiFdhbVPTJgwKpjyddv9AM11lV1M8_5wgtMPCQjeEeh
> KaevPB6ioCMXTMsX5cJAJ92ZGnIwCAwDuqGKILmLWltKtyQl5oYOOKRbi8zsPHFt7SKQqc3yP4YG
> b0NemT1e2tllZ_rewpEChdlqqrg9BC9-EL-UOUhnqcJRaJ5R_PzDPA4hKywK8o-5NJ3bZku7bAdg
> P1LLhMwhfFe0vMetd5o7EUMpTACriiD-UqiQTUKdyEMHQlVBbw&wid=940a272f-507d-41db-85
> a5-ebf2de52132a
> 
> 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%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZS7bZUfy3%2BAbmfB2sHArgrB%2F2GMoYCWvQTNwZWFiVeY%3D&reserved=0 | Extension
> 1138300
> 
> -----Original Message-----
> From: Hung-Chun Yu <HungChun.Yu at microsoft.com>
> Sent: Thursday, July 14, 2022 10:20 AM
> To: Andreas Schneider <asn at samba.org>
> Cc: cifs-protocol at lists.samba.org
> Subject: [MS-SAMR] 3.2.2.5 Deriving an Encryption Key fr... -
> TrackingID#2207140040006706
> 
> [BCC] dochelp
> 
> HI Andreas
> 
> Thank you for contacting Microsoft Open Specifications Support. We created
> SR Case - TrackingID#2207140040006706 to track this issue. Do leave this
> tag in the subject line for future reference. One of our engineers will be
> contacting you shortly.
> 
> Hung-Chun Yu
> Escalation Engineer
> Microsoft Open Specifications
> 
> -----Original Message-----
> From: Andreas Schneider <asn at samba.org>
> Sent: Thursday, July 14, 2022 1:03 AM
> To: Interoperability Documentation Help <dochelp at microsoft.com>
> Cc: cifs-protocol at lists.samba.org
> Subject: [EXTERNAL] [MS-SAMR] 3.2.2.5 Deriving an Encryption Key from a
> Plaintext Password
> 
> Dear Dochelp Team,
> 
> I need your help again :-)
> 
> I'm trying to implement SamrUnicodeChangePasswordUser4. However when I try
> to run my implementation against Windows. I always get
> STATUS_WRONG_PASSWORD returned.
> 
> For the SamrUnicodeChangePasswordUser4 method (section 3.1.5.10.4), the
> shared secret is the plaintext old password and the CEK is generated as
> specified in section 3.2.2.5.
> 
> 3.2.2.5 Deriving an Encryption Key from a Plaintext Password
> 
> The client MUST derive the CEK in the following manner:
> CEK :: = (PBKDF2(NT HASH of "OldPassword", Salt, IterationCount, 512))
> 
> 
> 
> Looking at the RFC 8018 section 5.2:
> 
> PBKDF2 (P, S, c, dkLen)
> 
>    Options:        PRF        underlying pseudorandom function (hLen
>                               denotes the length in octets of the
>                               pseudorandom function output)
> 
>    Input:          P          password, an octet string
>                    S          salt, an octet string
>                    c          iteration count, a positive integer
>                    dkLen      intended length in octets of the derived
>                               key, a positive integer, at most
>                               (2^32 - 1) * hLen
> 
>    Output:         DK         derived key, a dkLen-octet string
> 
> 
> The MS-SAMR document doesn't say a word about the dkLen. Which would be how
> many bytes the pbkdf2 function should return for the CEK.
> 
> I've used 16 bytes (same as the session key) as dkLen. However I get
> STATUS_WRONG_PASSWORD
> 
> 
> ./bin/rpcclient ncacn_np:earth.milkyway.site -U'bob%Pa$$w0rd at 3' -c
> 'chgpasswd4 bob Pa$$w0rd at 3 Pa$$w0rd at 6' [...]
> rpc_api_pipe: host earth.milkyway.site returned 4 bytes.
>      samr_ChangePasswordUser4: struct samr_ChangePasswordUser4
>         out: struct samr_ChangePasswordUser4
>             result                   : NT_STATUS_WRONG_PASSWORD
> 
> 
> I've uploaded traces to:
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.mi%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h1eengbZVRm1%2FnWRG3tacNgThY%2FGKk5rG6Rk1ixpXhM%3D&reserved=0
> crosoft.com%2Ffiles&data=05%7C01%7Cjeffm%40microsoft.com%7C2e7351441cdb4
> 696179208da65bd0dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63793415990
> 7789590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZnF7vMBiUpxR5NHinHK%2B0ID8g
> Xvuo%2FgzJ%2FWcXlDBojU%3D&reserved=0?
> workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiNTY5YjBlMTItMzYy
> NS00NjhlLWIwNjgtOTBiZDYyZDk2MTllIiwic3IiOiIyMjA3MTEwMDQwMDA4ODMyIiwiYXBwaWQi
> OiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJF
> eHRlcm5hbCIsInd0aWQiOiJhYzUxMDFlOS1mMTExLTQ5MGUtOGVlYS04NWMxNGMyNzMyNmIiLCJp
> c3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9z
> bWMiLCJleHAiOjE2NjU0MTQxMzEsIm5iZiI6MTY1NzYzODEzMX0.Oe0Nrl4WiClzTrLHTGeFVX6S
> - oHNH4LjSGoiVF9eXNo9wN9w-
> NyabVRaEUpWVvKheXcqukAuNYvxDGCnoj2ZbpPsE1JY4EByZfqC2l--8i6N0smD8Rtccd_YLg_hx
> 9SqGO- Dgr6Y5zLo6FMBUnfF6xQ8jhqB5a7ZJf4-
> TfMnCgXDsltrLzB_JU1rLDsVGI5ZzZfN9BEOJeKxS9PJEB3azUy8lFvcMsyq8ZL5LOzyQyhg7H2C
> glwDjzNeGmg2Wov8vdVdh3Ahk0AZ08Otf7i-7tpggx0F9FsH13oS2j6IOzEni23z2G6AqNL4j7ss
> _23sCp5njIL70rvGv3LliynERA&wid=569b0e12-3625-468e- b068-90bd62d9619e
> 
> 
> Help here would be much appreciated. Thanks you dochelp team.
> 
> 
> Best regards
> 
> 
>         Andreas
> 
> --
> Andreas Schneider                      asn at samba.org
> Samba Team                            
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.samba%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652809308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UDF1dJMf73j6gMQZ7eNnzjw01uUvW7SAFmibWjaUU9g%3D&reserved=0.
> org%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C2e7351441cdb4696179208da65
> bd0dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934159907789590%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=g%2BBw0bw7eD7Mit%2FCPz%2FBAPYvOS65NyD%2B
> q24mqS%2F4Cl0%3D&reserved=0 GPG-ID:    
> 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


-- 
Andreas Schneider                      asn at samba.org
Samba Team                             https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.samba.org%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652809308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S17HGunzIfD4VaCTpS1DG6J8RJEPLjF2sQj3gFOhT%2FU%3D&reserved=0
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D





More information about the cifs-protocol mailing list