<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">William, David</span>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Are you decrypting with the machine key (device transport key) ? Also have you been
able to separate header, encryptedkey, iv, payload and authentication Tag from the response ? I want to see what was sent in these fields and ensure that the parsing scheme is valid.</span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">If the Algorithm is dir instead of
</span><span style="font-family: "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">RSA-OAEP</span><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">,
is your implementation working ?</span></div>
<div class="elementToProof" style="margin: 0px;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div id="Signature">
<p style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px; color: black;">Regards,</span></p>
<p style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px; color: black;">Sreekanth Nadendla</span></p>
<p style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px; color: black;">Microsoft Windows Open
Specifications</span></p>
<p style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px; color: black;"><br>
</span></p>
</div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> William Brown <wbrown@suse.de><br>
<b>Sent:</b> Wednesday, January 24, 2024 7:45 PM<br>
<b>To:</b> David Mulder <dmulder@samba.org><br>
<b>Cc:</b> Sreekanth Nadendla <srenaden@microsoft.com>; Interoperability Documentation Help <dochelp@microsoft.com><br>
<b>Subject:</b> Re: [EXTERNAL] [cifs-protocol] [MS-OAPXBC] Incorrect session key instructions</span>
<div> </div>
</div>
<div><span style="font-size: 11pt;">[You don't often get email from wbrown@suse.de. Learn why this is important at
<a href="https://aka.ms/LearnAboutSenderIdentification" id="OWA4945f8fd-f7d0-6a18-c173-41b065f5b481" class="OWAAutoLink" data-auth="NotApplicable" data-loopstyle="linkonly">
https://aka.ms/LearnAboutSenderIdentification</a> ]<br>
<br>
> On 25 Jan 2024, at 08:07, David Mulder <dmulder@samba.org> wrote:<br>
><br>
><br>
> On 1/24/24 2:34 PM, Sreekanth Nadendla wrote:<br>
>> Hello David, William,<br>
>> You are correct i.e. the individual fields are sent after base64 encoding in the response.<br>
>><br>
>> So, the following data needs to be Base64URL decoded first in order to decrypt<br>
>> 1) iv, payload, tag ( used when decrypting using dir algorithm. )<br>
>><br>
>> 2) encrypted Key parsed out from response (when decrypting using RSA-OAEP algorithm, device transport key, account info is used to decrypt)<br>
>><br>
>> Have you been able to parse the response header and verify which algorithm is used ? "Direct use of a shared symmetric key as CEK" vs "RSAES using OAEP".<br>
>> It's value will be either RSA-OAEP or dir in the header.<br>
> Here's an example:<br>
> Header:<br>
> {"enc":"A256GCM","alg":"RSA-OAEP"}<br>
> CEK field:<br>
> EGzWVAJryfCZcHTBuh2GlgpsSJ07_uJYJzxHugaMcs0fRqPCuyJbmnPUF4RAIA52NuxIIvUX2IQZbkip81SbSyDQdZc9qrMTBGBij4X3vTq_lRX6AVu9qY_S8CmOp1Uj0fwwuJ0JZBB9gyaIVz55aSmh0EpJLD6sZaWoCQ_yW4zi2Zkh76Ejj6oXdg4N4EcuT_BE_BYa-k4C6rzEZOC56tFhLeajJiaQZjkS9sDFFCqD954yakiK6OITMQWCgrxWnouXBzIgXIeeLHfoBpV2FKjLgUW9j_W_PSj02awvzPxCCgxCoMttuH0gSg_nIBslqsRUOtV7Z6-R4PRQCvu7bBBMCatoGEDCIcSDOsxGXi4qWebJDDV8lwRJDnX6fj0XlWiaSw37<br>
><br>
> Which if we decode with base64url, it's 294 bytes long (which can't be decrypted because it is too long).<br>
> Here's a whole session_key_jwe we're getting back from MS:<br>
> eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.EGzWVAJryfCZcHTBuh2GlgpsSJ07_uJYJzxHugaMcs0fRqPCuyJbmnPUF4RAIA52NuxIIvUX2IQZbkip81SbSyDQdZc9qrMTBGBij4X3vTq_lRX6AVu9qY_S8CmOp1Uj0fwwuJ0JZBB9gyaIVz55aSmh0EpJLD6sZaWoCQ_yW4zi2Zkh76Ejj6oXdg4N4EcuT_BE_BYa-k4C6rzEZOC56tFhLeajJiaQZjkS9sDFFCqD954yakiK6OITMQWCgrxWnouXBzIgXIeeLHfoBpV2FKjLgUW9j_W_PSj02awvzPxCCgxCoMttuH0gSg_nIBslqsRUOtV7Z6-R4PRQCvu7bBBMCatoGEDCIcSDOsxGXi4qWebJDDV8lwRJDnX6fj0XlWiaSw37.fGFa6aVfmf83em7B.EA.O8wTp91cEL3-bACPGhi3iA<br>
><br>
> I'm consistently getting this sort of response, with a garbled CEK.<br>
><br>
> I tried putting this JWE through Powershell, and attempted decrypting the CEK with `System.Security.Cryptography.RSAOAEPKeyExchangeDeformatter`. This fails with:<br>
> MethodInvocationException: /home/dmulder/.local/share/powershell/Modules/AADInternals/0.9.2/PRT_Utils.ps1:754<br>
> Line |<br>
> 754 | … $CEK = [System.Security.Cryptography.RSAOAEPKeyExchang …<br>
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
> | Exception calling "DecryptKeyExchange" with "1" argument(s): "The length of the data to decrypt is not valid<br>
> | for the size of this key."<br>
><br>
<br>
It is worth pointing out that this data being 294 bytes in length may indicate a buffer over-read or similar data leak. While it may not be a valid CEK, you may internally need to raise this with your security teams.<br>
<br>
Generally there shouldn't be a case where you are yielding any extra data than the 256 bytes of signed CEK.<br>
<br>
<br>
--<br>
Sincerely,<br>
<br>
William Brown<br>
<br>
Senior Software Engineer,<br>
Identity and Access Management<br>
SUSE Labs, Australia<br>
<br>
</span></div>
</body>
</html>