[linux-cifs-client] Re: 2 New encryption capability bits in UNIX extensions.

[Jeremy Allison]

On Mon, Mar 26, 2007 at 02:07:20PM -0500, Steve French wrote:

> For the poor guys that have to deal with 80 column challenged people I 
> slightly prefer
> 
> #define CIFS_UNIX_MAY_ENCRYPT_CAP      0x40
> #define CIFS_UNIX_MUST_ENCRYPT_CAP     0x80
> 
> It may be worth defining a different meaning for 0x80 
> different from 0xC0 but I have no immediate suggestion on that.
> 
> I am assuming that this could theoretically give us
> encryption on one tid but not another which would be a wonderful
> feature and probably not something trivial for NFS (as we do
> SetFSInfo on the more granular tid rather than session).
> 
> Not sure if spnego itself could be encrypted as we don't have a shared
> secret yet - but it does mean that our tree connect and setfsinfo would
> be in the clear (which is fine with me).,

I wasn't planning on doing this. In fact it would be 
impossible I think for the same reasons as NFS finds 
it so. You can't look at the packet for a tid as
well as have it encrypted, that would be having
your cake and eating it too :-).

My "best practices" doc will suggest the following
for transport enc. 

1). Negprot.
2). SessionsetupX.
3). Tcon -> IPC$
4). UNIX extensions negotiate.
5). Set up transport encryption (if required/mandatory).

(encryption is now on).

6). tDis -> IPC$

7)..... encrypted communication.

Jeremy.