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. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
