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

Thu Jan 25 16:41:57 UTC 2024

Hello David, the data obtained after base64url decode is the key in encrypted form. You would use the machine transport key to decrypt this to obtain the pop key you need. Can you check if this works?

> 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

Regards,

Sreekanth Nadendla

Microsoft Windows Open Specifications

________________________________
From: David Mulder <dmulder at samba.org>
Sent: Thursday, January 25, 2024 11:11 AM
To: Sreekanth Nadendla <srenaden at microsoft.com>; William Brown <wbrown at suse.de>
Cc: Microsoft Support <supportmail at microsoft.com>; cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
Subject: Re: [EXTERNAL] [cifs-protocol] [MS-OAPXBC] Incorrect session key instructions

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<mailto:dmulder at suse.com>
http://www.suse.com<http://www.suse.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240125/ff0f80e3/attachment.htm>