SMB Signing TODO

[Andrew Bartlett]

As I've noted in my previous message, we now have NTLMv2 working with
SMB signing.  This is great progress, but does not help us with the next
major issue:

NTLMSSP and Kerberos signing of SMB connections.

I've had a couple of offers of help on this already, however this stuff
is very complex.  The assistance of somebody with a much better
knowledge of kerberos would also be very useful, as this will probably
be easier than the NTLMSSP stuff.

>From my previous mail:

> One of the features we would like to get for Samba 3.0 is SMB signing
> support.  

> 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'.
> 
> 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.

Ethereal also decodes a lot of this - and the first step in any NTLMSSP
implementation would be to try and match Win2k's flags in the NTLMSSP
exchange.  The problem is, we don't know how to support half the things
these flags indicate.  It would also be possible to use smbfilter to
make win2k use less flags, and figure out how to go from there.

> 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 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/20030510/1a1a4a74/attachment.bin