Fwd: [PATCH 1/7] cifs: Bypass windows extended security for ntlmv2 negotiate

[Simo]

On Fri, 2014-08-22 at 14:32 +1200, Andrew Bartlett wrote:
> On Wed, 2014-08-20 at 23:51 -0500, Steve French wrote:
> > This is an unusual sounding issue.  Any comments on this from the auth experts?
> > 
> > Seems better to investigate this more if we end up enforcing a "must
> > be within 5 minutes" threshold instead of this patch.  Have we done a
> > dochelp on this before?
> 
> I am certainly nervous about this patch, as I've not ever seen this
> before.  The thing that makes me feel particularly odd about this is
> that:  In general, NTLMSSP clients don't have the server's time,

This is simply false.
Modern servers send the server timestamp in the TargetInfo Av_Pair
structure in the challenge message [see MS-NLMP 2.2.2.1].

In [MS-NLMP 3.1.5.1.2] it is explicitly mentioned that the client must
use the provided (from the server) timestamp if present or current time
if it is not.

Not only a modern server *should* send a timestamp, but a modern client,
on seeing that a timestamp is available should provide a MIC in the
Authentication message [MS-NLMP 3.1.5.1.2].

Unfortunately samba at the moment has a very limited and incomplete
implementation of the NTLM protocol and doesn't do much with targetinfo
except mocking it up a little.

An implementation that is very close to implementing all of the MS-NLMP
specification is here:
https://git.samba.org/?p=idra/gss-ntlmssp.git;a=summary
or here: https://fedorahosted.org/gss-ntlmssp/
and I hope to make samba use it eventually, when we have a more decent
set of interfaces to connect to DCs (the current winbind interfacing is
suboptimal but fixable).

> and certainly don't have the domain controller's time.

This is true but not a problem today were servers are supposed to have
the time in sync with the KDC/Domain Controller anyway.

>   (That CIFS provides
> this does not mean we should use it, NTLMSSP is a general protocol and
> adding CIFS-specific hacks indicates we are understanding it wrong, in
> my experience).  
> 
> BTW, the domain controller is the only element here that could check the
> embedded time, but I'll grant that typically servers are better in sync
> with each other than this embedded device might be. 
> 
> The 5 mins stuff probably refers to Kerberos, which does have such a
> time limit.  I've never seen NTLMSSP fail against windows due to clock
> skew. 

That's becasue a client is supposed to use the time provided by the
server, so no clockskew is really possible,

> I would like to see much more investigation here before this is done,
> because if you just trust the server's time and if you need to, to pass
> a security check, you override that check.  We need to understand why it
> is in place. 

Sorry but this makes no sense, if you can bypass a "security mechanism"
in the client, then there is *no* security mechanism.

The reason why a timestamp is provided by the server is (most probably)
to mitigate replay attacks when the client uses a MIC (as it should)
when the timestamp is provided.

Simo.