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

[Steve French]

Jeremy Allison wrote:

>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.
>
>  
>
I thought that we already have flags in the SPNEGO/Kerberos negotiation 
(as we have in NTLMSSP negotiation by simply setting
flag 0x00000020) for session encryption.   Even if this (setting the 
equivalent of NTLMSSP flag 0x0000000020) doesn't
work with CIFS yet, it does already work for NTLMSSP with other 
protocols and looks simpler.

I like your idea of having a SetFSInfo for this capability, but don't 
like the idea of having it be the only "global" (rather than
per-tid) property.   The good news about the SMB header is that the tid 
is one of the first fields - so we can encrypt
starting with the next byte and get pid/uid/mid/wordcount etc. encrypted 
- which is good enough - and better than NFS in
some ways.   If we use a flag in spnego negotiation itself to negotiate 
encryption someday down the road - why don't
we first simply do the easier SetFSInfo based encryption of the portion 
of the SMB that follows tid.   I doubt that
exposing smb flags/flags2 is very harmful, and although having SMB 
command and error in the clear is not ideal from
one perspective.  If the header (up to mid) were in the clear it would 
be a huge performance win - with the advantage
of allowing the client to discard some easy response frames that don't 
have to be returned back for parsing (there are
lots of "empty" responses - for which all we need to know is that the rc 
was zero and that the frame was signed properly).