Re: [PATCH 00/11] cifs: overhaul of auth selection code (try #2)

On Sat, 24 Apr 2010 15:43:48 -0500
Steve French <[email protected]> wrote:

> FYI - I think this would be a good time to change to prefer NTLMv2
> auth - certainly if we (Shirish etc.) fix any signing bugs.
> 

(cc'ing the list since this concerns other folks working on it too...)

I'd rather not make that change in the context of this patchset. With
any change as large as this, we stand the chance of regression and it
would be good to keep the behavioral changes to a minimum. Let's plan
to make that change after this goes in.

I too would like to see us prefer NTLMv2, but as Andrew B. points out,
a lot of servers have poor support for it and we need a fallback path
to NTLMv1. We also can't make such a change abruptly -- users must be
given warning that the change is coming or we risk breaking some setups.

Here's how I'd eventually like to see this work:

In the absence of a sec= option, CIFS does the NEGOTIATE request with
the extended security flag2 set regardless of auth type. Assuming that
the server supports NTLMSSP then we use that to authenticate. If the
NEGOTIATE reply comes back indicating that the server doesn't support
NTLMSSP, then the authentication should work more or less like it does
today (use NTLMv1).

If NTLMSSP is negotiated, then try the authentication with NTLMv2 first
and then fall back to NTLMv1. This should probably be tunable too so
that people could require NTLMv2 auth with NTLMSSP.

If sec= option is specified then set the extended security bit in the
NEGOTIATE depending on what method was specified (basically only for
sec=krb5 and sec=ntlmssp).

I think we also need SPNEGO encapsulation for maximum compatibility. As
we're finding out, some windows boxes don't have good support for
NTLMSSP without it.

In any case, I don't think we can reasonably make any changes to the
defaults until NTLMSSP support is working fully (including signing and
SPNEGO), and only then with a defined release for the change so that we
can notify users that it's coming.

What may be best is to implement trying NTLMv2 first and then fall back
to NTLMv1. Then you could pop a printk for servers that only support v1
warning people that they need to add "sec=ntlm" to their mount options.
Do this for a release or two and then you can disable NTLMv1 by
default. Again though, I'd prefer to see that happen after this
patchset goes in.

-- 
Jeff Layton <[email protected]>