SMB Signing, kerberos, NTLMv2 TODO

[Andrew Bartlett]

One of the features we would like to get for Samba 3.0 is SMB signing
support.  Another big feature is NTLMv2 - a more secure version of NTLM,
the authentication method used in CIFS, before you move up to kerberos.

SMB Signing provides 2-way verification that the client and server are
not being intercepted by a man-in-the-middle attack.

Traditionally, this has not been a high priority for CIFS servers,
particularly as it is thought to kill performance, and makes zero-copy
techniques impossible.

However, Microsoft clients and in particular Microsoft Win2003 servers
will often require SMB signing on their connections.  This is
particularly important to them, because it has been realized that you
can tamper with a 'group policy object' via simple SMB spoofing. 
Naturally, this has serious implications.  

So, there are very good reasons for Samba to support this, both as a
client, and as a server.  However, until now there was no good reference
for what we do and don't know about SMB signing:

Introductory Document
---------------------

Readers should read http://www.ubiqx.org/cifs/SMB.html#SMB.8 before you
start.  

NTLMSSP has a bit of documentation at:
http://www.opengroup.org/comsource/techref2/NCH1222X.HTM

(this is a much earlier version, but it's a good start)

Basic Terms
-----------

LM authentication:
 - Authentication using the DES-based challenge-response and 

NTLM authentication:
 - Authentication using the DES-based challnege-response and the
md4(unicode password) (the nt hash).

NTLMv2 and LMv2 authentication:
 - Authentication using the newer MD5-base challenge-reposnse and the
md4(unicode passsword) (the nt hash).

NTLMSSP:
 - Microsoft's generalized 'blob based' encapsulation for LM/NTLM/NTLMv2
authentication

SPNEGO:
 - A common wrapping for this above encapsulation, which allows kerberos
and the like to also be used. 

Session key:
 - A shared secret, based on the password that is given to the member
server by the DC.  This is used in the Signing code to prove that the
message is authentic.

What we do know
---------------

SMB signing works, for authentication using the NTLM authentication
scheme, when not using 'extended security', and not using NTLMv2.

NTLMv2 works, as does LMv2 for all things that don't require the
'session key'.  

We know how to obtain the session key from the domain controller, and we
know how to do both the client and server end.  There is a client
implementation in Samba 3.0.

What is just broken (we know what to do, just have not done it)
-------------------

SMB signing doesn't work for large data transfers, particularly as shown
by the 'RW?' tests in smbtorture.  This is due to the fact that there is
more than one outstanding packet, and we need to tie the expected
response to the reply, not to the next packet we receive.

Server-side 'basic' SMB signing would not be difficult,

What is unknown
---------------

We don't know how to do SMB signing with NTLMv2.  This would be a
interesting, small research project for somebody, as the possible inputs
are pretty well known.  My guess is that we are getting the NTLMv2
response wrong in the client, and causing the server to think we have
not negotiated use of a session key.

(Adding an ethereal dissector for the NTLMv2 response would probably be
a very good place to start, there is a description of the format in
Implementing CIFS, and code in Samba TNG libsmb/smbencrypt.c).

We don't know how to do SMB signing with NTLMSSP - this means that in
the default mode of operation, we can't sign our connection, and Win2003
servers will reject us.  

We have had NTLMSSP code in Samba for a while, and I've tried to take
the signing code from that older implementation and put it in
libsmb/ntlmssp_sign.c, but I can't get it to work.  Indeed, our basic
negotation code in libsmb/ntlmssp.c won't even get a signed reply out of
Win2k.  Win2003 gives us a signed reply, but not the one we expect.

We also don't know how SMB signing works with kerberos.  It has been
noted that without a kerberos replay cache - and even with one -
kerberos authentication and SMB are subject to very easy MITM attacks. 
Having gained the security of kerberos, it seems a pity to loose it all
again so quickly.  If we knew how SMB signing was applied, we could
solve this particular issue.

If people have the time to attack some of this, I'll see what help I can
be.  Mainly it needs time, research and a well-stocked test lab...

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030501/e668a8bb/attachment.bin