[cifs-protocol] [EXTERNAL] [MS-OAPXBC] Incorrect session key instructions

Thu Jan 25 16:11:37 UTC 2024

On 1/24/24 8:53 PM, Sreekanth Nadendla wrote:
>
> It's unclear how the base64decoded followed by decrypted key varies in 
> size randomly. I will investigate this tomorrow and get back to you.

I got the JWE with the correctly sized CEK from a Windows machine using 
Powershell code. I'm making what I believe is exactly the same request 
from Linux Rust code and getting the incorrectly sized one. So it's not 
random. It works consistently on Windows. It fails consistently on 
Linux. I've mirrored all the parameters from the Powershell request, but 
still something about my request is causing your servers to trip up on 
something.

My guess is it's not the PRT request that's directly causing the 
failure, but perhaps it's a side effect of a previous request.

Here are the steps I'm taking:

1. Authenticate using username and password, requesting the DRS scope 
("01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default").

2. Create an Rsa2048 public/private key pair. I use this both for the 
transport key and for creating the CSR (I'm doing the same on Windows 
using powershell).

3. Generate a CSR with the CN "7E980AD9-B86D-4306-9425-9AC066FB014A".

4. Send a join request as per 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dvrj/e60e3298-f5bf-4203-97af-2082e08118cc 
. Note that for testing, I've set the device type to 'Windows' and the 
OSVersion to '10.0.22631.3007'. I've tested this with 'Linux' and a 
custom distribution version, and neither seem to effect the join or PRT 
request in any way. I've tried join types 0, 4, and 8. All work as 
expected and don't effect the PRT request.

5. Store the returned signed certificate and the private key in the HSM.

6. Send a PRT request with a Jwt signed by the transport key created in 
step 2. The Jwt header contains an x5c which is the Certificate returned 
during step 5. The Jwt is modeled after 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oapxbc/6da94507-af2e-41ed-a8da-e6edd4cbc2ca 
and 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oapxbc/1c277b53-36c6-4730-8772-631f9d3ab2ab 
(username/password auth). I've also tried authenticating with a refresh 
token (obtained using a DAG request with the 
"1b730954-1685-4b74-9bfd-dac224a7b894/.default" scope). I see the exact 
same issue of the incorrectly sized CEK on both the username/password 
PRT and the refresh token PRT response.

Here's an example JWT for the PRT request:

{ "alg": "RS256", "typ": "JWT", "x5c": "MIID8jCC...<redacted>...bUA1US" 
}.{ "client_id": "38aa3b87-a06d-4817-b275-7a316988d93b", 
"request_nonce": "AwABAAEAAAACAOz_BQ...<redacted>...5Fp0UgAA", "scope": 
"openid aza ugs", "win_ver": "10.0.18363.0", "grant_type": "password", 
"username": "admin@<redacted>", "password": "<redacted>" }.[Signature]

The request_nonce was obtained as described in 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oapxbc/451d1710-2428-4cec-9c6f-96c35d809d16

Here is an example request body:

windows_api_version=2.0&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&request=eyJhbG...<redacted>...T8tmkPg&client_info=1

Where the `request` parameter is the JWT, each section 
(header/payload/signature) base64url encoded and separated by periods.

Here is an example response from MS:

*{*
***"token_type"**: *"Bearer"*,*
***"expires_in"**: *"1209599"*,*
***"ext_expires_in"**: *"0"*,*
***"expires_on"**: *"1707407869"*,*
***"refresh_token"**: *"0.AbcAblw...<redacted>...o4LbS"*,*
***"refresh_token_expires_in"**: *1209599*,*
***"id_token"**: *"eyJ0eXAiOiJK...<redacted>...yIjoiMS4wIn0."*,*
***"client_info"**: *"eyJ1aWQi...<redacted>...NlMjRiIn0"*,*
***"session_key_jwe"**: 
*"eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.Lwx1oUwtrOVhZoHkPlNCVfvmInTIVfkpY4daNtS7fiL-dL-G2pgnSbCG23vwmk8VF9dbQPKkN4ERiWsXA8hjaZPE4XcWsylUrbT65hyO3U_r3nXLGxAYX06rRP21L8ak1qoFAl9wodJI30yHmBqYdsrO3BNa0QRXNmvliRF1fNnvzuRj5VQiqFi78-8as7rwKtUQ117R11q3EvaoYgwQUJS1JdDAiRDRHuVpVmfH8Gf279EpRuhKlyEN1gtjXCcK1U9cj3Oco47JeS3AuCZOrU0Q0rRSt0hWBFC21mLxqQ64hXTG3NOb5O-DFoN7sIf7vDBdQloZ2Sxq5gDVdegfmcsKTnjD3nooJIOuT8mmCyTeqdHlio-sYNBm0QzSsLPP3Dngl1bK.yLJM5ZkeigtBz5Cl.TA.lBRRBpOedY0K62Ti7jDqNA"*,*
***"device_tenant_id"**: *"68355c6e-0a63-442d-a2ec-71cc6bb3e24b"
*}*

I should note that all the other fields in the PRT can be parsed and are 
sensible responses. Only the `session_key_jwe` has a problem.

 > python3

 >>> session_key_jwe = 
"eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.Lwx1oUwtrOVhZoHkPlNCVfvmInTIVfkpY4daNtS7fiL-dL-G2pgnSbCG23vwmk8VF9dbQPKkN4ERiWsXA8hjaZPE4XcWsylUrbT65hyO3U_r3nXLGxAYX06rRP21L8ak1qoFAl9wodJI30yHmBqYdsrO3BNa0QRXNmvliRF1fNnvzuRj5VQiqFi78-8as7rwKtUQ117R11q3EvaoYgwQUJS1JdDAiRDRHuVpVmfH8Gf279EpRuhKlyEN1gtjXCcK1U9cj3Oco47JeS3AuCZOrU0Q0rRSt0hWBFC21mLxqQ64hXTG3NOb5O-DFoN7sIf7vDBdQloZ2Sxq5gDVdegfmcsKTnjD3nooJIOuT8mmCyTeqdHlio-sYNBm0QzSsLPP3Dngl1bK.yLJM5ZkeigtBz5Cl.TA.lBRRBpOedY0K62Ti7jDqNA"
 >>> session_key_jwe_parts = session_key_jwe.split('.')
 >>> len(base64.urlsafe_b64decode(session_key_jwe_parts[1]+'=='))
294

-- 
David Mulder
Labs Software Engineer, Samba
SUSE
1221 S Valley Grove Way, Suite 500
Pleasant Grove, UT 84062
(P)+1 385.208.2989
dmulder at suse.com
http://www.suse.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240125/db49bd18/attachment.htm>