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 <dmul...@samba.org>
Sent: Thursday, January 25, 2024 11:11 AM
To: Sreekanth Nadendla <srena...@microsoft.com>; William Brown <wbr...@suse.de>
Cc: Microsoft Support <supportm...@microsoft.com>;
cifs-protocol@lists.samba.org <cifs-protocol@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
dmul...@suse.com<mailto:dmul...@suse.com>
http://www.suse.com<http://www.suse.com/>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
