[Samba] Encryption

[Shirish Pargaonkar]

On Fri, Jun 25, 2010 at 2:34 PM, Jeff Layton <jlayton at samba.org> wrote:
> On Fri, 25 Jun 2010 12:20:41 -0700
> Jeremy Allison <jra at samba.org> wrote:
>
>> On Fri, Jun 25, 2010 at 06:54:08PM +0000, Dan Lenski wrote:
>> > On Sun, 18 Apr 2010 10:29:38 -0400, simo wrote:
>> >
>> > > On Sun, 2010-04-18 at 10:05 -0400, Nico Kadel-Garcia wrote:
>> > >>
>> > >> Reviewing the docs, this tool requires Samba 3.2 or later on both the
>> > >> client and server sides. I'm therefore assuming that it's not
>> > >> compatible with a contemporary Windows fileserver: can you confirm
>> > >> this? Does anyone know if NetApp supports such encryption?
>> > >
>> > > It is an extension created by the Samba Team as part of unix extensions,
>> > > and at the moment the only client that implements it is smbclient. Not
>> > > even the in kernel cifs driver implements it. And we have no knowledge
>> > > of any other implementer adopting it yet.
>> >
>> > Does anyone know a time-frame for inclusion of transport encryption in
>> > the kernel CIFS driver?  I'm really looking forward to this feature!
>>
>> Steve, Jeff.... ping ? :-)
>>
>
> Sadly, there are enough bugs in this area that it may be a bit before
> we get around to adding new features. I know Shirish was poking around
> in here a while back, but I think he's working on other stuff now.
>
> I think before we can reasonably add that we really need to move all of
> the cifs crypto to use the kernel's standard crypto libs rather than the
> homegrown routines they use now. There are some definite problems wrt
> to unicode in there (not directly related to crypto, but it needs
> fixing). NTLMSSP auth is also busted which is a rather important item.
> --
> Jeff Layton <jlayton at samba.org>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

Right now, I am at a stage where NTLMv2 authentication using NTMSSP works.
(It definitely was broken against Windows 7 and Windows 2008 server).
But signing does not.  I am working on making NTLM2 Session Security work.
For signing, as I understand, I am attempting to use kernel crypto APIs
(for things like the key exchanged in type 3 message in ntlmssp)

Point of this is, I am trying to use kernel crypto APIs henceforth.
Along the way, I would
consider converting existing mac generation routine to crypto kernel APIs.
I am definitely considering implementing encryption also.  If I am
generating all these
server and client signing and sealing keys, it may be little easier to
go one step
further and implement both, signing and sealing.  I was mainly
focussing on signing
but will start investigating sealing also.

NTLM2 session security implementation looks daunting though, I am just beginging
to look into arc4 encryption to genereate ciphertext.

I do not see a problem with existing mac routines but converting them to
standard kernel crypto APIs should be way to go.
There are definitely issues in how cifs vfs client module implements
ntlmssp protocol
like how we decide/choose flags in type 1 message and how we react to
flags in type 2 message
etc.  Signing for ntlmv2 is definitely busted.