SMB2.1 or later is probably fine (and we note SMB2.1 or 3) for most cases in our mount warning message. But this FIPS compliance issue reminds me that we should get the other auth mechanisms working that are 'peer to peer' (so not forced to be domain joined). krb5 is great, but Macs support 'peer-to-peer kerberos' and also SCRAM (RFC 7677) so we could also presumably get FIPS compliant login for peer-to-peer cases if we implement on or both of those other auth mechanisms. Anyone have some Macs or Mac VMs to test against ...? On Fri, Apr 1, 2022 at 12:41 PM Enzo Matsumiya <ematsumiya@xxxxxxx> wrote: > > On 04/01, Tom Talpey wrote: > >On 4/1/2022 11:25 AM, Enzo Matsumiya wrote: > >>On 04/01, Tom Talpey wrote: > >>>Is SMB2 really FIPS compliant? Even if it is, a server that doesn't > >>>support anything higher is obviously far out of date. > >> > >>It's more that the crypto stuff used by SMB1 is *not* compliant. > > > >Sure, but that's not the point here. It's time to simply state > >"don't use SMB1". > > I 100% agree. > > But, actually, that's the whole point of my commit. I just wanted to add > what will work with mount.cifs on a FIPS compliant environment. Nothing > else. > > Stating "don't use SMB1" (either FIPS or not) could come in a different > commit. > > (Personally, I would've nuked all SMB1 from the kernel altogether :P) > > >I don't think the crypto algorithm is enough. SMB2 is vulnerable > >to man-in-the-middle attacks and therefore the crypto type is > >only a part of the picture. SMB3 is much stronger, even with the > >same crypto algs. > > Again, I agree. But I'd say it's up to FIPS to mandate that. Even > because their requirements only cover the crypto modules, not > filesystems and/or versions as a whole AFAIK. > > >The Microsoft FIPS statement only refers to SMB3, for example: > > > > > >https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation > > > > Is SMB3 (Server Message Block) FIPS 140 compliant in Windows? > > > > SMB3 can be FIPS 140 compliant, if Windows is configured to operate in > > FIPS 140 mode on both client and server. In FIPS mode, SMB3 relies on > > the underlying Windows FIPS 140 validated cryptographic modules for > > cryptographic operations. > > But that's on a product (OS) level. We're preparing similar > documentation for SUSE as well, for example. > > >I think anyone who is serious enough to want FIPS should darn well > >be advised that the best security means running the strongest version > >of the protocol, and the doc should not waffle around with discussion > >of SMB1 or SMB2. > > And again, I also agree. My intent was to rather have specified in the > docs what's supported in FIPS mode. Suggesting/enforcing a particular > version or security mode was out of scope of my patch. > > > Cheers, > > Enzo -- Thanks, Steve
