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

[Sreekanth Nadendla]

Hello David, William,
You are correct i.e. the individual fields are sent after base64 encoding in the response.

So, the following data needs to be Base64URL decoded first in order to decrypt
       1) iv, payload, tag ( used when decrypting using dir algorithm. )

             2) encrypted Key parsed out from response (when decrypting using RSA-OAEP algorithm, device transport key, account info is used to decrypt)

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".
 It's value will be either  RSA-OAEP or dir in the header.


Regards,

Sreekanth Nadendla

Microsoft Windows Open Specifications

________________________________
From: William Brown <wbrown at suse.de>
Sent: Wednesday, January 17, 2024 6:17 PM
To: David Mulder <dmulder at samba.org>
Cc: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>; William Brown <wbrown at suse.com>
Subject: [EXTERNAL] Re: [cifs-protocol] [MS-OAPXBC] Incorrect session key instructions

[Some people who received this message don't often get email from wbrown at suse.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

> On 18 Jan 2024, at 06:50, David Mulder <dmulder at samba.org> wrote:
>
>
> On 1/17/24 1:29 PM, David Mulder via cifs-protocol wrote:
>> In [MS-OAPXBC] section 3.2.5.1.2.2, it says to obtain the session key, to decrypt the base64 encoded JWE called `session_key_jwe` in the json response object. There are a couple of issues with this.
>>
>> First, the `session_key_jwe` is not base64 encoded.
> Well, technically each field of a JWE is base64 encoded prior to parsing. Perhaps this is what the [MS-OAPXBC] spec is referring to? If so, that wording is a bit confusing.

Yes, the wording is confusing. The wording implies that the whole JWE is one b64 blob, but it's not its just a JWE in compact form. So I can imagine they meant each part of the JWE. Regardless, I think you can remove the "JWE is base64 encoded prior to parsing" since it's not accurate.

>> Is there some kind of padding in the CEK field of a JWE response from MS? We've tried truncating the field to decrypt it, but to no avail. We also thought that perhaps the CEK itself was base64 encoded (which FYI would not obey the [RFC7516] spec), but that doesn't allow decryption of the field either.
> Here I meant we attempted to base64 decode the field a second time, which seems odd, but [MS-OAPXBC] isn't clear what it means.
>

Correction, we didn't try to base64 decode it again. We were speculating on possible issues that are causing the JWE to contain a potentially invalid CEK. After testing I do not believe the CEK field was base64ed twice.

> Second, it says that the key is encrypted using the JWE standard [RFC7516], but the JWE does NOT follow the standard. The CEK can't be decrypted because it is 294 bytes in length (which is greater than the maximum 245 bytes allowed).

This is a subtle thing, and it's not a violation of the JWE standard. There isn't a maximum allowed, what is the limit is RSA OAEP (as I understand it) can only decrypt k - 11 bytes, where k is the number of octets in the key modulus. For a 2048 bit key, that would be a 256 octet key, ergo 245 bytes is the maximum decrypt limit. However the provided CEK we have been supplied is 294 bytes.

This is why we suspected something like an extra layer of base64 (since that grows the size of the input data), incorrect or assumed truncation of the input, or another thought I had was that there is a concatenated rsa oaep label on the binary.

Hope that helps understand the problem we have run into here.

--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240124/601c4adf/attachment.htm>