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

[George Colley]

So when do sealing we only do it at below the tree level? Shouldn't  
the whole VC be sealed? This seems a little strange to me. Why would  
you every want to seal one tree connection and not another on the  
same VC?

George
On Mar 26, 2007, at 12:07 PM, Steve French wrote:

> Jeremy Allison wrote:
>
>> Hi Steve + UNIX CIFS fans,
>>
>> I want to grab 2 new capability bits to implement
>> the CIFS transport encryption to make us feature
>> parity with NFS.
>>
>> Here they are :
>>
>> #define CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP      0x40 /* We can do  
>> SPNEGO
>> negotiations for encryption. */
>> #define CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP    0x80 /* We
>> *must* SPNEGO negotiations for encryption. */
>>
>> If 0x40 is set the client may ask for encryption, if both 0x40
>> and 0x80 are set the client *must* ask for encryption or it will
>> be disconnected.
>>
>> Thoughts, comments ?
>>
>> Jeremy.
>>
>>
> 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).,
>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client