Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Fri, Mar 30, 2007 at 11:09:17AM +0200, Stefan (metze) Metzmacher wrote: So I think it would be much better to use the vuid as enc-ctx, but check for each call to a specific tid that the call was encrypted or not. And maybe also allow plain requests with the vuid, or force the client to create a new vuid for plain traffic. Full ack from here. Key generation is a per-session setup thing, so the encryption context should be the same. The fact that we have contexts broken in Samba3 should not influence the design ;-) Volker pgpKkNk0hWEkj.pgp Description: PGP signature
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Bartlett schrieb: I agree that the trans2 stuff is ugly, but at least it is in an already reserved space in the protocol. Whatever we do, we should continue to allow a re-key modal (despite the issues it then has with credentials expiring/passwords changing). We could also create a new call at SMB level maybe SMBsesssetup2? There're a lot of free message numbers. Are there also some ranges defined? Or were the number randomly picked by the first implementor of a call? metze -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGDNuvm70gjA5TCD8RApINAJ0YrlrEoTWDMqPkAgnNmnzMJ5WCTQCgxfd2 47HOznxArhbxAT8GyVIdlUE= =+3fP -END PGP SIGNATURE-
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Fri, Mar 30, 2007 at 11:43:11AM +0200, Stefan (metze) Metzmacher wrote: We could also create a new call at SMB level maybe SMBsesssetup2? There're a lot of free message numbers. Are there also some ranges defined? Or were the number randomly picked by the first implementor of a call? Naa, I would not go there. If we have to pass stuff through trans2, that's what it costs. Volker pgpIiCp0rjSgM.pgp Description: PGP signature
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan (metze) Metzmacher schrieb: So I think it would be much better to use the vuid as enc-ctx, but check for each call to a specific tid that the call was encrypted or not. And maybe also allow plain requests with the vuid, or force the client to create a new vuid for plain traffic. and for replies without vuid (oplock breaks) we should use the same context as used by smb signing (first session setup wins). does smb signing still work when the first vuid is closed? metze -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGDOXRm70gjA5TCD8RAqzxAJ0R1OyS4LlKnwILHqBkTwEH7FCmbQCgg3Lx 7GV13/Z6M96MJzAi4U3pBu8= =JFzT -END PGP SIGNATURE-
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Volker Lendecke schrieb: On Fri, Mar 30, 2007 at 11:43:11AM +0200, Stefan (metze) Metzmacher wrote: We could also create a new call at SMB level maybe SMBsesssetup2? There're a lot of free message numbers. Are there also some ranges defined? Or were the number randomly picked by the first implementor of a call? Naa, I would not go there. If we have to pass stuff through trans2, that's what it costs. Then I'd say it should be a trans2 call on the IPC$ share. Is that trans2 call a replacement for the session setup? or is it just an 'switch on encryption for the next request' on the already created gssapi session? metze -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGDOcwm70gjA5TCD8RAkE1AJ9GbYPcO9kp5bh0sWTl0dVllJuNKwCgroN7 P3YztByDabafdRyajWJCwi8= =o1fg -END PGP SIGNATURE-
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Fri, Mar 30, 2007 at 11:09:17AM +0200, Stefan (metze) Metzmacher wrote: So I think it would be much better to use the vuid as enc-ctx, but check for each call to a specific tid that the call was encrypted or not. And maybe also allow plain requests with the vuid, or force the client to create a new vuid for plain traffic. Yep, after chatting with Andrew Bartlett I agree. And for the case vuid == enc-ctx we can better add a new session setup variant instead of using a trans2 call. As soon as you clear that with Microsoft, then we're good to go on that one Metze. :-). Jeremy.
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Fri, Mar 30, 2007 at 11:43:11AM +0200, Stefan (metze) Metzmacher wrote: We could also create a new call at SMB level maybe SMBsesssetup2? There're a lot of free message numbers. Are there also some ranges defined? Or were the number randomly picked by the first implementor of a call? A lesson in SMB politics. The top level numbers are defined by Microsoft who reserve the right to allocate new ones at any time and for any reason. The space *we* have reserved to allocate from is the trans2 space defined in the UNIX extensions. We can't create new calls at the SMB level. Jeremy.
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Fri, Mar 30, 2007 at 12:32:16PM +0200, Stefan (metze) Metzmacher wrote: Then I'd say it should be a trans2 call on the IPC$ share. Yep, that's what we decided on. Is that trans2 call a replacement for the session setup? or is it just an 'switch on encryption for the next request' on the already created gssapi session? It's a replacement for the session setup in creating an encryption context. Jeremy.
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Fri, Mar 30, 2007 at 09:36:11AM -0700, Jeremy Allison wrote: A lesson in SMB politics. The top level numbers are defined by Microsoft who reserve the right to allocate new ones at any time and for any reason. The space *we* have reserved to allocate from is the trans2 space defined in the UNIX extensions. We can't create new calls at the SMB level. How much is that BTW? We might have to reserve a sub-trans 32 bit soon if the development continues at the current pace :-) Volker pgpnzWxMm3pV9.pgp Description: PGP signature
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: Author: jra Date: 2007-03-27 21:13:31 + (Tue, 27 Mar 2007) New Revision: 21991 WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=revroot=sambarev=21991 Log: I hate Steve French :-). Add support for encryption contexts Jeremy. Hi Jeremy, can you explain that a bit more? What is the typical request sequence to establish the encryption context? So the encryption context is attached to the connection_struct (which is a tree connect in samba3)? Wouldn't it be better to attach it to the session id instead of the tree id, as a tree id can be used by multiple sessions. (I assume in SMB2 the signing is also attached to the session) It would be really nice to have a specification of all this in our wiki or so. metze -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGC22jm70gjA5TCD8RAsKfAJ9o+4tG341Mr/psVf0TYEhkgo01pQCcD5hd peSo13i2hapfDJ+YG4Zav1Y= =CHe0 -END PGP SIGNATURE-
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Thu, Mar 29, 2007 at 09:41:23AM +0200, Stefan (metze) Metzmacher wrote: Log: I hate Steve French :-). Add support for encryption contexts Jeremy. Hi Jeremy, can you explain that a bit more? What - the hating Steve French (that's obvious) or the encryption contexts ? What is the typical request sequence to establish the encryption context? trans2 setfsinfo. So the encryption context is attached to the connection_struct (which is a tree connect in samba3)? That's the plan - not yet implemented. Context zero represents the global context for fully encrypted traffic on all tid's. Wouldn't it be better to attach it to the session id instead of the tree id, as a tree id can be used by multiple sessions. No. The use case Steve bugged me about was the ability to have some shares (tid's) encrypted and some not on the same session. In this case encryption is a property of the tid, not the sessionid. It would be really nice to have a specification of all this in our wiki or so. Yes it would, wouldn't it. As soon as it's in a form where it's worth specifying, I'll specify it :-). Jeremy.
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Thu, Mar 29, 2007 at 09:55:52AM +0200, Stefan (metze) Metzmacher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=revroot=sambarev=21991 Log: I hate Steve French :-). Add support for encryption contexts Jeremy. Hi Jeremy, also using 4-byte len + 0xFF + 'S' + 2-byte encctx, is bad as encctx 'M' + 'B' will be confusing! maybe it would be better to use 0xFD + 'S' + 2-byte encctx or 0xFF + 'E' + 2-byte encctx or something simular. Actually, ethereal seems to cope very nicely. It sees it as a NetBIOS session message and doesn't look at the 'S' + enc. ctx at all. Jeremy.
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Mar 29, 2007, at 9:31 AM, Jeremy Allison wrote: On Thu, Mar 29, 2007 at 09:41:23AM +0200, Stefan (metze) Metzmacher wrote: Log: I hate Steve French :-). Add support for encryption contexts Jeremy. Hi Jeremy, can you explain that a bit more? What - the hating Steve French (that's obvious) or the encryption contexts ? What is the typical request sequence to establish the encryption context? trans2 setfsinfo. So the encryption context is attached to the connection_struct (which is a tree connect in samba3)? That's the plan - not yet implemented. Context zero represents the global context for fully encrypted traffic on all tid's. Wouldn't it be better to attach it to the session id instead of the tree id, as a tree id can be used by multiple sessions. No. The use case Steve bugged me about was the ability to have some shares (tid's) encrypted and some not on the same session. In this case encryption is a property of the tid, not the sessionid. Why is having the ability to do this a good thing? If a client wants to do unencrypted traffic it can always set up a new session. -- James Peach | [EMAIL PROTECTED]
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Thu, Mar 29, 2007 at 10:23:57AM -0700, James Peach wrote: Why is having the ability to do this a good thing? If a client wants to do unencrypted traffic it can always set up a new session. Yes, but the thing that convinced me was the ability to have the following : [share_secure] encryption = mandatory path = / [share_unsecure] encryption = auto (or no) path = /yyy If we want the server to be able to make encryption mandatory and we don't allow it per share then we disallow that server from serving any unencrypted (currently Windows) clients. People probably want the ability to serve both encrypted and non encrypted shares from the saem server. Currently the point is moot as the implmentation only supported encryption context zero - ie. encrypt everything. But the goal is not to contrain the design. Jeremy.
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Mar 29, 2007, at 10:35 AM, Jeremy Allison wrote: On Thu, Mar 29, 2007 at 10:23:57AM -0700, James Peach wrote: Why is having the ability to do this a good thing? If a client wants to do unencrypted traffic it can always set up a new session. Yes, but the thing that convinced me was the ability to have the following : [share_secure] encryption = mandatory path = / [share_unsecure] encryption = auto (or no) path = /yyy If we want the server to be able to make encryption mandatory and we don't allow it per share then we disallow that server from serving any unencrypted (currently Windows) clients. You probably also want to allow shares to have different levels of encryption. For example, [share_really_secure] encryption = mandatory minimum encryption = the_best_algorithm_we_implement [homes] encryption = mandatory minimum encryption = the_faster_but_weaker_algorithm People probably want the ability to serve both encrypted and non encrypted shares from the saem server. Currently the point is moot as the implmentation only supported encryption context zero - ie. encrypt everything. But the goal is not to contrain the design. There's 2 issues - the first is supporting the configuration above, the second is that the only space we have in the protocol is in trans2 levels which require a tree connection. If you wanted encryption to be a property of the VC, you could connect to [Samba$] and negotiate it there which would work around the second issue. If some shares require encryption and some don't you can just set up different VCs to handle it. That said, we can live with having encryption as a property of the TID :) -- James Peach | [EMAIL PROTECTED]
Re: svn commit: samba r21991 - in branches/SAMBA_3_0/source: include lib libsmb smbd
On Thu, Mar 29, 2007 at 11:32:59AM -0700, James Peach wrote: You probably also want to allow shares to have different levels of encryption. For example, [share_really_secure] encryption = mandatory minimum encryption = the_best_algorithm_we_implement [homes] encryption = mandatory minimum encryption = the_faster_but_weaker_algorithm I'm going to leave this up to the /etc/krb5.conf as I'm using gss-api for this. I don't think we need to get that fancy. For connection via IP (ie. non-krb5) we'll default to NTLM encryption. If you don't want that then turn off NTLM via the normal mechanisms. People who are this security aware will be using krb5 anyway and will turn off NTLM auth alltogether. Actually, looking at our code it looks like currently we don't have a way to turn off NTLMv2 and force krb5 only for auth. We probably need to add this. There's 2 issues - the first is supporting the configuration above, the second is that the only space we have in the protocol is in trans2 levels which require a tree connection. Life sucks :-). If you wanted encryption to be a property of the VC, you could connect to [Samba$] and negotiate it there which would work around the second issue. If some shares require encryption and some don't you can just set up different VCs to handle it. I think it'd be IPC$, rather than Samba$, but the idea is the same. That said, we can live with having encryption as a property of the TID :) Cool ! Now all I need do is work with Andrew Bartlett on where the NTLM signature should be for maximum compatibility with SSPI. We're making progress (although you can see the sausage being made and it's not pretty :-) :-). Jeremy.
