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

[William Brown]

> 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