[PATCH][SMB3.1.1] Add defines for new signing context

[Steve French]

> suggest wrapping this context and the integrity algs in some kind of conditional

I have a couple patches to send the context (which I haven't merged
yet, because, similar to what you suggested, I wanted to make sure
they were disabled by default).

Tentative plan was to have them disabled by default, and sending the
new context can be enabled for testing by a module parameter (e.g.
"echo 1 >  /sys/modules/cifs/parameters/enable_signing_context"  or
some similar config variable name)

On Thu, Oct 15, 2020 at 1:15 PM Tom Talpey <tom at talpey.com> wrote:
>
> On 10/12/2020 5:50 AM, Aurélien Aptel wrote:
> > Patch LGTM
> >
> > Reviewed-by: Aurelien Aptel <aaptel at suse.com>
> >
> > Stefan Metzmacher via samba-technical <samba-technical at lists.samba.org>
> >> This isn't in MS-SMB2 yet.
> >>
> >> Is this AES_128?
> >
> > This is returned in latest Windows Server Insider builds but it's not
> > documented yet.
> >
> > https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver
> >
> > I've asked dochelp about it during the SDC plugfest and they gave me
> > this:
> >
> >      The new ContextType is:
> >      SMB2_SIGNING_CAPABILITIES 0x0008
> >      The Data field contains a list of signing algorithms.
> >      •    It adds a new negotiate context, which enables SMB to decouple signing algorithms from dialects. E.g. if both client and server supports it, a session may use HMAC-SHA256 with SMB 3.1.1.
> >      •    It adds the AES-GMAC algorithm.
> >
> >      SigningAlgorithmCount (2 bytes): Count of signing algorithms
> >      SigningAlgorithms (variable): An array of SigningAlgorithmCount 16-bit integer IDs specifying the supported signing algorithms.
> >
> >      The following IDs are assigned:
> >      0 = HMAC-SHA256
> >      1 = AES-CMAC
> >      2 = AES-GMAC
> >
> >
> > I've been CCed in a Microsoft email thread later on and it seems to be
> > unclear why this was missed/wasn't documented. Maybe this is subject to
> > change so take with a grain of salt.
>
> Just curious if you've heard back on this. Insider builds will sometimes
> support things that don't make it to the release. Even Preview docs can
> change. However, AES_GMAC has been on the radar since 2015 (*) so
> perhaps the time has come!
>
> I'd suggest wrapping this context and the integrity algs in some kind of
> conditional, in case this is delayed...
>
> Tom.
>
> (*) slide 29+
> https://www.snia.org/sites/default/files/SDC15_presentations/smb/GregKramer_%20SMB_3-1-1_rev.pdf



-- 
Thanks,

Steve